何时不采用微服务架构

作者 |托马斯·努尔凯维奇

翻译 |李腾辉

规划|鑫源

微服务不可能是“包治百病”。

现在微服务是一个很好的架构，它具有模块化、可扩展性和高容错性的优点。许多公司已经采用微服务架构并取得了巨大成功，因此，如果您正在开始一个新项目，微服务似乎是最好的选择。

然而，大多数在微服务方面取得成功的公司并不是从一开始就选择这种架构。以 Airbnb 和 Twitter 为例。在单体应用程序变得太大之后，他们选择了微服务路线，并且仍在处理由此产生的复杂性。即使是大公司仍在寻找使用微服务的最佳方法。因此，微服务是一把双刃剑，需要权衡利弊。

从单体应用程序迁移到微服务绝不是一项简单的任务。在没有测试的情况下使用微服务构建新产品更加复杂。只有在充分评估替代方案之后，您才应该认真考虑是否使用微服务架构。

1。微服务只适合成熟的产品

对于从头开始使用微服务，Martin Fowler 总结道：

1。几乎所有成功的微服务都是从太大且必须拆分的单体应用程序开始的。

2。几乎所有使用微服务从头开始构建的系统最终都会因严重问题而失败。这种情况让很多人相信，即使你确信你的应用程序会快速增长，你也不应该从一开始就采用微服务。

首版设计很难优化，新产品的前几次迭代重点是寻找用户真正的痛点。因此，成功取决于保持敏捷性并能够快速优化和重构。在这方面，微服务比单体应用差很多。如果您在不确定设计原始解决方案的情况下采用微服务，那么您的旅程将会更加困难，因为重构微服务比重构整体应用程序要困难得多。

2。您在一家初创公司或正在开发一个新项目吗？

作为一家初创公司，你已经在与时间赛跑，试图在未知的坏消息到来之前找到突破口。此时您不需要过多关注可扩展性（可能几年都不需要），那么为什么要使用复杂的架构并忽略客户的需求呢？

开发全新项目时也会出现类似的情况，这些项目不受前期工作的限制，也没有任何决策包袱。《构建微服务：设计细粒度的系统》一书的作者 Sam Newman 表示，用微服务构建一个全新的项目非常困难：

我仍然坚信，对现有遗留系统进行分区比对全新系统进行分区要容易得多。您有更多资源可以提供帮助。例如，您有可供审查的代码。您可以与使用和维护系统的人员进行交流和讨论。您还知道“好”系统是什么样子 - 基于当前的稳定运行。对你的系统进行更改，让你更容易知道哪里出了问题以及你的决定是否过于激进。

3。微服务并不是本地部署的最佳选择

由于所有组件都是动态变化的，微服务部署需要搭配更强大的自动化机制。在常规环境中，我们可以依靠持续部署管道来完成工作——任务开发人员部署微服务，消费者只需使用在线服务即可。

但是，这不适用于当地环境。如果开发者发布了一个包，消费者需要在自己的本地环境中部署和配置其他服务，这使得部署更具挑战性。

准确的说，开发本地微服务应用也是可行的，就像Semaphore（CI/CD平台）也提供了本地化的部署模式一样。然而，我们在此过程中还需要克服一些挑战：

1。本地微服务的版本控制规则需要更严格，并且必须跟踪参与发布的每个单独的微服务。

2。您必须进行完整的集成和端到端测试，因为您无法在生产环境中进行测试。

3。如果不直接访问生产环境，对微服务应用程序进行故障排除就会困难得多。

4。您的单个应用程序可能仍然可用

每个软件都有自己的生命周期。您可能想要弃用单体应用程序，因为它既旧又复杂。但摆弄一个系统可能是吃力不讨好的事情，只要付出一点努力，你也许就能从当前的系统中榨取更多价值，并让它再运行几年。

只有这两种情况，微服务重构才是不得不做出的选择：

1。代码混乱：很难在原有代码的基础上进行修改和添加新功能而不破坏其他功能

2。性能因素：扩展单个应用时遇到瓶颈

5。模块化单体

开发人员希望避免采用单体架构的一个常见原因是，单体更容易成为“代码垃圾山”。当时很难添加新功能，因为一切都是相互关联的。

但是单体不一定是一团糟。以 Shopify 为例：它拥有超过 300 万行代码，是世界上最大的单一 Rails 应用程序之一。但有一点：太大的系统会给开发者带来很大的痛苦：

应用程序非常脆弱，新代码可能会产生许多意想不到的效果。进行一些更改可能会触发一系列不相关的测试用例失败。例如，某些代码会重复用于计算运费和计算税率，因此更改计算税率的代码可能会影响运费计算的结果。这是高耦合和缺乏边界的结果，这也使得测试用例难以编写并且在 CI 上运行非常缓慢。

Shopify 没有选择将整个单体应用重写为微服务，而是选择了模块化作为解决方案。