拆分还是整合：单体和微服务的技术抉择 _微服务

作者 | Ashley Davis
译者 | 明知山
策划 | 丁晓昀
持续之战：单体架构与微服务

"从许多方面来看，微服务就是一种僵尸架构，另一种拒绝死去的知识传染病菌。这种病菌从 J2EE（远程服务器 Bean，有人记得吗？）的黑暗时代开始，经历了 WS-Deathstar 的胡闹，现在又以微服务和无服务器的形式存在。"
—— David Heinemeier Hansson (来源)

随着亚马逊云科技在他们的官博中宣称他们放弃了微服务并回归单体架构，单体架构与微服务之间的战争再次爆发。
你对此有何看法？你是支持微服务还是单体？但我想说的是，这种区分有点虚幻，因为人们争论的只是一种虚构的概念：微服务与单体只是整个故事的一个组成部分。
亚马逊云科技的这篇文章被视为他们（作为微服务的长期支持者）已经回头转向单体架构的证据。
尽管文章的标题明显是为了引起关注，但从内容上看，似乎是关于他们从函数即服务向微服务架构（如果不是比微服务更大的分布式应用程序服务）的转变。
但在我看来，这并不重要。这只能说明，亚马逊云科技的一个团队承认他们尝试的架构在一段时间后不奏效，然后尝试了不同的架构，得到了更好的效果。但这又怎样？这只是好的软件开发应该经历的正常过程。
我们都希望专注于最重要的事情，为我们的客户做正确的事情，在微服务与单体的争论中选边站队只会给我们造成阻碍。有时候，我们需要微服务。有时候，我们需要单体架构。（我还不确定我是否会需要 FaaS——但我保持开放的态度）。大多数情况下，我们需要在两个极端之间找到平衡点。
为什么我们害怕微服务？
当然，与单体相比，微服务更难 —— 我承认这一点。但如果你有了自动化的微服务架构，这个论点就站不住脚了。我曾经使用过的一些无缝集成又容易使用的系统就是拥有良好自动化的微服务。另一方面，我曾经参与的一个最困难的项目是一个古老的大单体，几乎没有自动化。我们的日子不会因为选择了单体而变得轻松。
对微服务的害怕有没有可能是对微服务过度炒作的反噬？是的，微服务已经被过度炒作了。微服务不是灵丹妙药。像所有潜在的解决方案一样，它们并不适用于所有场景。当你使用一种错误的架构来解决某个问题（或更糟糕的是，管理层强制要求使用错误的架构）时，我可以理解你为什么会对这种架构充满厌恶。
是否有一部分害怕是来自微服务早期的日子？十年前，微服务确实使开发变得更加困难。但从那时起，工具和平台已经取得了长足的进步，现在比以往任何时候都更容易进行自动化，给微服务开发带来更加无缝和愉快的体验。
也许，一部分害怕来自对复杂性的感知，我认为这是其中很大的一部分。人们会自然而然地害怕（或至少想要避免）复杂性。我说可感知的复杂性，因为不仅仅是微服务会变得复杂，单体也会 —— 只是时间问题。然而，对于微服务来说，复杂性是公开的，所有人都可以看得到，我们必须早日加以应对。在我的“BootstrApping Microservices”一书中，我称之为将痛苦提前，以便能够在开发过程中更容易、以更低的成本应对复杂性。
不幸的是，在现代软件开发中，我们无法逃避复杂性。我们的应用程序正在变得越来越庞大和复杂 —— 即使是普通的单体架构也注定会变得无比复杂。
在现代的大规模软件开发中，我们无法避免复杂性。我们需要使用工具来帮我们管理复杂性，避免它们阻碍我们的开发过程或压垮我们。
为什么微服务看起来如此困难？

"你必须达到这道门槛才能使用微服务。"
—— Martin Fowler (来源)

构建分布式应用程序（不仅仅是微服务）需要更高的技术熟练度。管理大量的服务意味着我们必须拥有自动化管理工具。为了了解我们的服务在做什么，我们还需要跟踪很多东西。随着服务之间的交互变得越来越多，了解这些信息的困难程度将呈指数级增加。
假设你是一个小团队或在开发一个小项目，在不需要微服务的场景中采用了微服务，或者如果你不愿意付出构建和运行分布式系统所需的技能和技术投入，你就不能指望从中得到良好的体验。