作者|MartinFowler当听说有些团队在使用微服务架构时，我注意到了一些规律：几乎所有成功应用微服务的系统都来自于一个过于庞大的单体项目Split而来。我听说过的几乎所有系统都选择从一开始就使用微服务架构，从零开始构建，并以一系列严重的问题告终。这些规律在我的同事中引起了长期的讨论：你不应该在一个新项目的开始就采用微服务架构，即使你坚信未来应用会随着业务的发展而变得庞大。微服务是一种有用的架构，但即使是这种架构的粉丝也不得不承认，使用这种架构的额外成本意味着只有更复杂的系统才值得使用这种架构。该成本的本质是管理这些服务的基本开销。所以这是单体优先架构策略的基础。架构师在构建新系统时应该使用单体架构进行设计，即使在项目后期使用微服务架构更有价值。第一个原因是经典的Yagni原则（译者注：“YouArentGonnaNeedIt”的缩写，意在避免过度设计）。当你开始一个新的应用程序时，你如何确保应用程序的功能对用户有价值？一个成功的软件可能设计不佳且难以扩展，但它比一个设计良好但毫无价值的系统要好。正如我们现在意识到的那样，判断一个软件或一个想法是否有用的最好方法通常是构建一个简单的版本并查看它的工作情况。在第一阶段，您需要优先考虑速度（以及反馈的周期时间），因此微服务的成本是一种负担，应该避免。从微服务开始的第二个问题是，它们只有在服务之间存在良好、稳定的边界时才能正常工作——这本质上是找出正确的限界上下文的任务。因为任何服务之间的功能重构都比在单一整体中困难得多。不幸的是，即使对于在熟悉领域工作的经验丰富的架构师来说，一开始也很难建立界限。通过先构建单体应用程序，您可以在微服务设计涂上一层糖浆之前弄清楚正确的边界是什么。它还为您提供缓冲时间来开发细粒度服务所需的基础设施。据我所知，有不同的方法来实施单一优先级策略。例如，将其作为一个整体类似单个系统进行仔细的逻辑设计，注意内部的模块化设计，包括API边界和数据存储方式。做好这个，然后开发一个微服务系统。但是，如果我听过很多这样的成功案例，我会觉得这个方法比较合适，其实做起来很难。一种更常见的方法是从单体开始，逐渐从边缘剥离微服务。这种方法可能会在微服务架构的核心留下一个巨大的整体，但大多数新的开发都发生在微服务中，只是这个整体是相对稳定的。另一种常见的方法是先开发单体，然后用一组新的微服务完全替换单体。很少有人会同意这种方法，但是将单体系统构建为牺牲架构是有好处的（写）。不要害怕建造一个你会扔掉的庞然大物，尤其是当一个庞然大物可以让你快速进入市场时。此外，我遇到的其他方法都是从一些比您预期的更大的粗粒度服务开始的。使用这些粗粒度服务习惯于处理多个服务，同时享受粗粒度减少了作为最后手段必须执行的服务间重构量的事实。然后，随着边界的稳定，它分解为更细粒度的服务。虽然与我交谈的大多数人都倾向于“单体优先”策略，但这并不是绝对的。相反的论点是，从微服务开始构建新系统可以让您适应微服务环境中的开发节奏。要以足够模块化的方式构建单体系统，以便轻松分解为微服务，需要很多（如果不是太多的话）编程学科。从微服务开始，您可以让每个人从一开始就习惯于在小型独立团队中进行开发，并且通过服务边界分隔团队可以在需要时更轻松地扩展开发工作。对于更有可能在早期达到足够稳定界限的系统来说尤其如此。尽管缺乏证据，但我认为你不应该从微服务入手，除非你有很多在团队中构建微服务系统的经验。我觉得我没有足够的例子来说明如何决定是否使用“单体优先”策略。毕竟现在是微服务的早期阶段（译者注：本文发表于2015年），可供借鉴的行业案例相对较少。因此，任何人对这些问题的建议都需要保持开放，无论索赔人发誓多少。
