不是银弹：关于微服务的一点思考

在 reddit 上看到一篇文章（被标题吸引了） Monoliths are the future——作者在吐槽微服务。

And then what they end up doing is creating 50 deployables, but it’s really a distributed monolith.

作者说，他们改造后的 50 个微服务，其实就是 50 个分布式的单体服务。进行微服务改造后，他们原来的问题并没有解决或减少，反而带来更多新的问题。最后他们又改回去单体服务。

这篇文章其实是个标题党，内容本身没什么好看的。微服务改造失败，这大概率是作者所在的团队错误应用微服务的问题——微服务不是银弹。

在过去的几年，微服务这个概念很火，容器、k8s、ServiceMesh 各种微服务基础设施如火如荼。使用微服务来构建应用程序似乎成了一种理所当然的标准——很少有人停下来思考：什么时候该用微服务？还有更重要的——什么时候不该使用微服务？

首先，当我们说起微服务的时候，我们是在说什么？ 微服务是一种应用于组件设计（服务如何分组）和部署架构（服务如何部署和通信）的软件架构风格。它利用模块化的方式组合出复杂的大型应用程序：

1. 各个服务功能内聚，实现与接口分离。
2. 各个服务高度自治、相互解耦，可以独立进行部署、版本控制和容量伸缩。
3. 各个服务之间通过 API 的方式进行通信。
4. 各个服务拥有独立的状态，并且只能通过服务本身来对其进行访问。

其次，当我们实现微服务的时候，我们想要得到什么？ 从上面对微服务特点的描述不难看出，实现微服务可以带来的好处有：

1. 迭代升级更加敏捷：不同功能的服务可以独立变更，不相互影响。
2. 服务容量更加弹性：可以根据具体的负载单独对某个服务进行扩容、缩容。
3. 系统可用性更高：某个微服务故障不会导致整个服务故障。

然而，实现微服务是需要权衡利弊（trade-off）的。

程序员知道种种优势，却对代价一无所知。 —— Rich Hickey (Clojure设计者)

1. 原来的单体服务如何切分？这是一个关键问题——切分得不好，就会像前面那篇文章的作者一样，遇到一个单体服务变成多个单体服务的问题。
2. 服务切分后，API 会成倍增加。这会引入各种 API 的管理问题，比如各种健康监控、优先级、权限等。
3. 本地调用变成远程调用会引入了网络延迟，进一步引入了分布式事务。
4. 微服务请求如何自动路由？调用链路如何追踪？如何自动进行熔断降级，防止雪崩？

等等。引入微服务的代价就是——整个系统的复杂度大大提高。

在我的经历/经验中，从单体服务到微服务其实是公司内组织架构转变的结果。 遥想当年，有一个 web 程序，最开始只有一个组几个人在做，刚开始业务也比较简单，所以所有相关业务都在上面。 后来业务发展良好，开发人数持续增长，业务越来越多、越来越复杂，随后开发人员根据具体业务/功能被拆分成几个小组。 有很长一段过渡时间，所有的变更还是在这一个程序上进行。 这个程序调用量很大，而且可能因为业务 A 的 bug，影响了其他所有业务，每次变更都有不小风险。 这个程序部署的机器比较多，每次变更的时间都比较长。 开发人员越来越多，但是没能做到随时独立变更——每次上线都要进行协调，然后合并多个人的代码一起上线。有时候解决代码冲突就要花掉一整天的时间。上线的时候，如果发现某个功能有问题，需要进行回退——其他功能就算没问题也只能一起回退——业务多而复杂的时候，这种情况很容易出现，非常影响迭代速度。

这种情况下，亟需一种能解决组内自治、快速迭代、跨团队合作的软件架构——没错，就是微服务。

设计系统的架构受制于产生这些设计的组织的沟通结构。 — M. Conway

如果只是一个紧密的小团队，在引入微服务之前，要三思——不要只顾追求时尚，不要人云亦云，适合自己的才是最好的。