微服务架构实践（背景篇）

本文章为【中小型创业公司微服务架构实践】系列文章之一，主要目的是为中小型创业公司实践微服务架构提供一些参考。
不算是新东西，只不过记录下自己公司实践中的一些结论。文章的内容(包含测试结论，数据等)均由我公司具体实践操作中产生。

前言之微服务

微服务架构（Microservice Architecture）这个词在过去几年里广泛的传播，想必大家已经不会对它比较陌生（比如近两年如果你去参加过一些技术会议，少不了要拿这个出来装波逼）。我是两年多之前开始接触微服务的，我以我自己的理解（会结合自己的一些工作经历）来阐述下我心中微服务是个什么东西，个人理解，难免有些偏颇，欢迎指出来。

微服务早应该是在2014年（如果我没记错的话）提出来的，但其实很多大公司内部很早就在实践类似于微服务的架构了（微服务不是新东西，至少可以追溯到 Unix 的设计原则）。

我12年毕业后去了某大厂，当时在我们部门内部其实早就不存在巨型的单体应用了，所有的前端（客户端，web等）请求都通过接入层（类似于API Gateway）分发到后端的逻辑服务器，逻辑服务器根据业务模块划分，不同的业务会有单独的服务（类似于现在的微服务）来处理请求，逻辑服务之间互相也可以通过接口（UDP+Protobuf）访问。当时在我们内部其实没有微服务这种说法，只不过就是在后台按照业务进行模块划分，大的好处就是每个人都有自己负责的独立的模块，当某个模块出问题的时候，可以直接定位到问题找到负责人，并且不会影响其他的业务，而且在接入层可以做过载保护，服务降级，服务监控等（类似服务治理）。

15年的时候我去了某中型公司，当时的后台还是一个庞大的PHP单体应用，内部正在进行服务化拆分（因为太大了，好多次发布新功能没有测试完全导致全站挂掉），我在当时算是完整地参与了整个服务化的过程（虽然到我离职出来还没有完整的落地...）。至此，我明白了其实有很多创业公司从小到大的过程中都有这么一个过程，由一个庞大的单体应用（因为刚开始的时候单体应用比较小，开发快，部署也比较简单）到拆分成一个个子服务。

言归正传，微服务架构风格，就像是把一个单独的应用程序开发为一套小服务，每个小服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API。这些服务围绕业务能力来构建，并通过完全自动化部署机制来独立部署。

微服务问题

去年开始，我们启动了一个新项目，基于这个机会，我决定使用相对的微服务架构来实践新的产品（没有历史包袱的感觉真好）。但是，微服务架构在某些方面会确实增大我们的开发成本和运维成本：

• 错误排除 由于我们有很多的服务，一次请求可能经过多个逻辑服务器，错误散落在不同的服务中，为我们的错误排查带来了困难。
• 日志分析 服务越多，对于日志的排查就越困难，好能把服务的日志集中收集并分析。
• 基础设施 每个服务有互相独立的MySQL、Redis，公共服务方面需要高可用的服务发现，监控报警系统，调用链路分析，日志收集储存设施等。

我们在业务上拆分不同的服务后，接下去要做的所有事情几乎都是在解决上面的问题（也就是所谓的服务治理问题）。

微服务架构图

Next Things

• 服务框架
• 服务发现
• 配置中心
• API Gateway
• 日志收集
• 持续集成
• 监控报警
• APM调用链
• 服务保护（过载保护/服务降级等）
• 自动扩容缩容
• ... （未完待续）

我的微信公众号（欢迎关注留言）

周小叨（reezhoublog）