如果你的单体系统里包含了多个模块，并且在模块间定义了良好的 API，那么 API 之间的交互就几乎没有什么额外开销。但对于微服务来说就不是这么一回事了，因为它们一般运行在不同的机器上，它们之间需要通过网络进行交互。这样会在一定程度上拖慢整个系统。如果一个请求需要多个服务进行同步的交互，那么情况会变得更加糟糕。我曾经工作过的一个公司，他们需要调用将近 10 个服务才能处理完某些请求。处理请求的每一个步骤都需要额外的网络开销和延迟，但实际上，他们可以把这些服务放在单个软件包里，按照不同的模块来区分，或者把它们设计成异步的。这样可以为他们节省大量的基础设施成本。

3. 本地开发变得更加困难

如果你有一个单体应用，后端只有一个数据库，那么在开发过程中，在本地运行这个应用是很容易的。如果你有 100 个服务，并使用了多个数据存储系统，而且它们之间互相依赖，那么本地开发就会变成一个噩梦。即使是 Docker 也无法把你从这种复杂性泥潭中拯救出来。虽然事情原本可以简单一些，不过仍然需要处理依赖问题。理论上说，微服务不存在这些问题，因为微服务被认为是相互独立的。不过，对于成长型初创公司来说，就不是这么一回事了。技术人员一般需要在本地运行所有（或者几乎所有）的服务才能进行新功能的开发和测试。这种复杂性是对资源的巨大浪费。

4. 难以伸缩

对单体系统进行伸缩的最简单方式是在负载均衡器后面部署单体系统的多个实例。在流量增长的情况下，这是一种非常简单的伸缩方式，而且从运维角度来讲，它的复杂性是最低的。你的系统在编排平台（如 Elastic Beanstalk）上运行的时间越长越好，你和你的团队就可以集中精力构建客户需要的东西，而不是忙于解决部署管道问题。使用合适的 CI/CD 系统可以缓解这个问题，但在微服务生态系统里，事情要复杂得多，而且这些复杂性所造成的麻烦已经超过了它们所能带来的好处。

然后呢？

如果你刚好处在一个成长型初创公司里，需要对架构做一些调整，而微服务似乎不能解决你的问题，这个时候应该怎么办？

Fowler 提出的先决条件可以说是技术领域的能力成熟度模型，Fowler 在他的文章里对成熟度模型进行过介绍。如果这种成熟度模型对于公司来说是说得通的，那么我们可以按照 Fowler 提出的先决条件，并使用其他的一些中间步骤为向微服务迁移做好准备。下面的内容引用自 Fowler 的文章。

关键你要认识到，成熟度模型的评估结果并不代表你的当前水平，它们只是在告诉你需要做哪些工作才能朝着改进的目标前进。你当前的水平只是一种中间工作，用于确定下一步该获得什么样的技能。

那么，我们该做出怎样的改进，以及如何达成这些目标？我们需要经过一些简单的步骤，其中前面两步就可以解决很多在向微服务迁移过程中会出现的问题，而且不会带来相关的复杂性。

清理应用程序。确保应用程序具有良好的自动化测试套件，并使用了最新版本的软件包、框架和编程语言。

重构应用程序，atv，把它拆分成多个模块，为模块定义清晰的 API。不要让外部代码直接触及模块内部，所有的交互应该通过模块提供的 API 来进行。

从应用程序中选择一个模块，并把它拆分成独立的应用程序，部署在相同的主机上。你可以从中获得一些好处，而不会带来太多的运维麻烦。不过，你仍然需要解决这两个应用之间的交互问题，虽然它们都部署在同一个主机上。不过你可以无视微服务架构里固有的网络分区问题和分布式系统的可用性问题。

把独立出来的模块移动到不同的主机上。现在，你需要处理跨网络交互问题，不过这样可以让这两个系统之间的耦合降得更低。

如果有可能，可以重构数据存储系统，让另一个主机上的模块负责自己的数据存储。

在我所见过的公司里，如果他们能够完成前面两个步骤就算万事大吉了。如果他们能够完成前面两个步骤，那么剩下的步骤一般不会像他们最初想象的那么重要了。如果你决定在这个过程的某个点上停下来，而系统仍然具有可维护性和比刚开始时更好的状态，那么就再好不过了。

我的总结

我不能说这些想法都是独一无二的，也不能说是我所独有的。我只是从其他遭遇了相同问题的人那里收集想法，并连同观察到的现象在这里作了一次总结。还有其他很多比我更有经验的人也写过这方面的文章，他们剖析地更加深入，比如 Sander Mak 写的有关模块和微服务的文章。不管怎样，对于正在考虑对他们的未来架构做出调整的公司来说，这些经验都是非常重要的。认真地思考每一个问题，确保微服务对你们的组织来说是一个正确的选择。

最起码在完成了上述的前面两个步骤之后，再慎重考虑一下微服务对于你的组织来说是否是正确的方向。你之前的很多问题可能会迎刃而解。

文中部分内容超链接：

https://aadrake.com/posts/2017-05-15-redis-performance-triage-handbook.html

https://en.wikipedia.org/wiki/Capability_Maturity_Model

https://www.oreilly.com/ideas/modules-vs-microservices

打个小广告