单体应用产生的痛苦，微服务并不能解决……

本文作者通过分析微服务的常见优点能解决的问题，提出如何使用单体应用来缓解这些问题，最终指出采用微服务还是单体架构要根据团队实际情况，而不是为了微服务而微服务。作者最后给出建议，中小团队和新型团队，建议采用单体架构，大中型团队，可以采用微服务架构，但要充分权衡。

在 Web 软件架构方面，微服务架构非常流行，它有大量高知名度的实践者和支持者，如Facebook、Uber、Groupon、Klarna、Amazon、Netflix、eBay、Comcast等。

但是，你很可能不属于这些公司。也就是说，你的团队很可能与这些公司的团队不一样，你没有面临与他们相同的问题。

当然，如果你恰好就属于这些公司（但极大可能你不是），请停止阅读。你们可能就是需要微服务的。

微服务据说有许多好处，我们的关注点不在于微服务是否真能提供这些好处，而在于这些好处是否只能由微服务提供。

在某种程度上，大多数好处（即使不是全部）都可以通过单体应用来实现。

当有人列出微服务架构的优点时，潜台词是为了解决这些问题，你必须采用微服务模型。

现实情况是，微服务允许你“购买”间接层和灵活度来解决这些问题。

关键词是“购买”。

微服务不是免费的，众所周知，它们的构造和维护成本很高。

如果你确实需要那层额外的灵活性，那么总的来说，额外的成本会得到回报，微服务比较适合，你应该认真考虑它们。

但是如果你不需要呢？你只是过度设计了你的技术栈，并严重阻碍了你的团队为客户提供价值的能力。

让我们看看微服务最常被提到的一些好处，并考虑如何使用单体应用来缓解这些问题。

运行微服务意味着应用程序的每个功能都在自己的资源上运行，这些资源可以相互独立地进行扩展，这将使你能够对分配给这些功能的确切资源数量和类型进行高度控制。

但是你真的需要这种程度的控制吗？

你的应用程序的不同功能是否真的会经历不同级别的负载？

它们是否倾向于以不同的速度进行扩展？

它们在 CPU、内存、存储和 GPU 方面是否有不同的要求？

对于很多团队来说，通过简单地增加全面可用的盒子的大小或数量来弥补这些资源问题的差异会更便宜。也就是说，大多数情况下，不将基础设施优化到其生命周期的一英寸以内会更具成本效益。

解决单体架构中的性能问题和瓶颈可能比过渡到新的架构模式更容易。这方面的细节是和技术栈强相关的，但是你不必走得太远就可以找到有关如何收紧应用程序的想法。

如果你有多个服务器，你将在它前面运行某种负载均衡器。你可以使用此负载均衡器的配置将流量路由到你的应用程序实例的可独立扩展的集群。

你还可以将异步任务拉入具有独立可扩展队列的后台作业中。请确保你有足够的队列，以便你能对所需的盒子数进行细粒度控制，保持合理的基础设施成本。

应用程序的单个功能下架，同时不影响其他功能，这是那些设计合理的微服务架构的一大好处。

将不同类型的流量路由到集群以进行扩展的想法也可以提供一种针对故障的保护措施。

想想你的大部分历史错误来自哪里，这将为你提供有关如何最好地路由你的流量的指示。如果你正和“吵闹的邻居（noisy neighbors）”作斗争，你可能希望根据帐户 ID 进行路由。如果你有一个脆弱但次要的功能，它习惯于将所有内容都关闭，则可以将其端点路由到它自己的应用程序实例集群。如果你有有问题的后台作业，请将它们放在不影响其他作业的自己的队列中。

预防胜于治疗。如果你可以防止或至少可以减少故障数量，你可大幅减少隔离的计划。

培养健康的测试文化以确保对所上线产品的质量充满信心是关键，它不仅能可靠地提供所需的功能，也能在生产负载下这样做。

如果没有单独的服务，引入新语言和技术的选择并不多。

在大多数情况下，这更像是一个功能而不是一个错误。在选择语言和技术时，给工程师太多选择可能会导致技术栈支离破碎且过于复杂。

我更倾向于单体架构带来的简单性和一致性。

如果你确实对针对特定功能的专业语言有特定领域的要求，你可能需要考虑单独的服务。你将需要权衡任何额外技术带来的好处与维护它的额外成本。

你认为保护单体应用数据安全很难？微服务只会使这项工作变得更加复杂。通过增加技术栈的复杂性，你正在增加被攻击的表面积。

确实，将功能隔离到不同的服务中可以让你对每个服务应用不同级别的安全性和尽职调查。但是，请考虑是否需要这种级别的控制。

将整个单体应用程序保护到必要的最高级别是否更容易？

你甚至对数据有不同的安全要求吗？

我是自主跨职能团队的忠实粉丝。我对必须引入网络边界来实现这一点的想法从何而来感到有些困惑。

赋予每个团队对特定隔离系统的所有权似乎是提高团队自主性的一种方式，但实际上，它可能会与之背道而驰。

假设我的团队需要更改另一个团队拥有的功能。对于微服务架构，我可能不得不利用他们对该服务的知识和经验来对其进行更改。我甚至可能不得不等待他们来改。如果该功能在单体应用中，我很有可能已经熟悉代码或至少熟悉它的约定。

团队的自主程度取决于模块化程度和系统的一致性。无论是单体应用还是微服务都不会在这些方面保证或毁灭你。然而，微服务将迫使你的系统模块化，而单体应用往往会鼓励更高的一致性。

就其本质而言，微服务将迫使你对系统进行模块化。单体应用在这里并没有真正提供太多帮助（尽管你选择的单体应用框架可能会），但它们当然也不会妨碍你自己做这件事。

具有有限关注点的松耦合模块化代码是一个好主意，无论你是否碰巧在这些关注点之间增加了网络边界的复杂性。

尽管微服务强制执行模块化，但不能保证它是良好的模块化。如果没有充分考虑设计，微服务很容易成为紧密耦合的“分布式单体”。

如果你不能成功地模块化一个单体，你将很难构建一个成功的微服务架构。

微服务强制模块化，但使得做好模块化变得更难。

在能够独立部署服务的情况下，你可能会进行许多更改。但是为了你的面包和黄油，你的日常更改，可能会成为一个棘手的瓶颈。

跨不同服务编排大量部署的要求将使快速发布功能变得更加困难和复杂。

使用单体架构，仍然可以将复杂的、有风险的更改分解为单独的部署。一个常见的例子是让他们自己的 PR 和他们自己的部署向前和向后兼容。

这种方式和微服务一样，增加了交付功能的复杂性。你不会想轻率地使用它。但它确实提供了微服务的一些好处，而不必被迫在每次更改时都使用它。

微服务允许你为每个服务配置单独的依赖项，但你真的需要它们吗？

在大型单体应用中管理依赖关系已经够难的了。将其拆分为几个较小的列表可以简化管理每个单独的列表，但会使整个系统的操作变得复杂。

对于单体应用，迟早你会陷入“依赖地狱”，并在两个依赖项之间产生冲突。微服务不会确保你避免这种情况，但它们应该会降低出现问题的可能性。

使你的依赖关系保持最新显然是可取的。但在现实世界中，是否变成最新要由我们来控制。

保持在可用版本的最前沿实际上可能会使这个问题复杂化，因为一个依赖项比其他相关依赖项更快地向前发展。但“保持领先”并不一定意味着在所有可能的情况下都更新到最新版本。

这种好处往好了说是虚伪，往差了说，这是一个赤裸裸的谎言。

确实，每个服务都更简单，也更容易理解。但是，整个系统变得更复杂，也更难理解。你还没有消除复杂性；你增加了它，然后将它移植到其他地方。

我们不需要引入网络边界和隔离进程来使我们的代码更容易被工程师理解。

将单体分解为具有明确定义和有限关注点的模块，与分解为单独服务的系统一样容易，甚至更容易理解。

如果你遇到单体应用问题，可能是因为你的单体应用存在问题，而不是因为它是单体应用。

你的单体应用可能是代码质量、工具和模块化的闪亮灯塔。如果这就是你并且你仍然在经历痛苦，那么可能是时候开始考虑微服务了。但这可能不是你。你可能只需要改进你的单体。

构建软件很难。组织具有大量随时间演变的移动部件的大型复杂系统非常困难。

我自己就已经构建了一个糟糕的单体应用。

我不是来评判任何人的。

但是，如果你假设你面临的单体应用问题将通过微服务神奇地解决，甚至简化，那么你将进入一个痛苦的世界。

单体和微服务之间的选择通常表现为两种相互排斥的思维模式。老学校与新学校，对或者错，非此即彼。

事实上，它们都是具有不同权衡的有效方法。正确的选择是高度特定于上下文的，并且必须包括广泛的考虑因素。

选择本身就是一种错误的二分法，在某些情况下，应该逐个功能地做出选择，而不是针对整个组织的工程团队采用单一方法。

你应该考虑微服务吗？

通常这得看实际情况。你可能会真正受益于微服务架构，在某些情况下收益是大于支出的，但如果你是中小型团队或早期项目：

不，你可能不需要微服务。

询问整个行业，你会发现无数关于微服务及其给团队带来问题的警示故事。

Segment 是一个有据可查且备受瞩目的团队示例，该示例已完全启用微服务。

这同样适用于作为单体的微服务。仅仅因为它们在执行中存在问题并不意味着核心前提存在根本缺陷。

但是，如果你打算采用微服务方法，则需要睁大眼睛进入。接受权衡，并为成功完成所需的额外资源做好准备。

对于新的、小型和中型的工程团队来说，单体应用应该仍然是默认选择。微服务仍然是一种选择，但你应该有令人信服的特定于上下文的理由来证明它们的使用是合理的。

对于大中型团队，应该考虑它，但要对你的权衡有充分的考虑和理解。