当我听到关于团队使用微服务架构的故事时，我注意到了一个共同的现象。

1. 几乎所有成功的微服务故事都是从一个过于庞大的庞然大物开始的，后来这个庞然大物被拆分了
2. 我所听说的几乎所有从零开始构建微服务系统的案例，最终都陷入了严重的麻烦。

这种模式导致我的许多同事认为，你不应该用微服务开始一个新项目，即使你确信你的应用程序足够大，值得这样做。

微服务是一种有用的体系结构，但即使是它们的拥护者也说，使用它们会产生显著的微服务溢价，这意味着它们只对更复杂的系统有用。这种溢价，本质上是管理一套服务的成本，将会拖慢团队的速度，而倾向于为更简单的应用程序提供一个整体。这导致了对单体优先策略的有力论证，在这种策略中，您应该首先将新应用程序构建为单体，即使您认为它可能会在以后从微服务架构中受益。

第一个原因是经典的雅格尼。当你开始一个新的应用程序时，你有多确定它对你的用户有用?可能很难扩展一个设计糟糕但成功的软件系统，但这仍然比它的反面要好。正如我们现在所认识到的，通常发现一个软件想法是否有用的最好方法是构建一个简单的版本，然后看看它的效果如何。在第一阶段，你需要优先考虑速度(以及反馈的周期时间)，所以微服务的溢价是你应该避免的拖累。

从微服务开始的第二个问题是，只有在服务之间有良好的、稳定的边界时，它们才能很好地工作——这本质上是绘制正确的BoundedContexts集合的任务。服务之间的任何功能重构都比在一个整体中要困难得多。但是，即使是在熟悉的领域工作的经验丰富的架构师，在开始时也很难得到正确的边界。通过首先构建一个整体，您可以在微服务设计在其上刷上一层糖霜之前弄清楚正确的边界是什么。它还为您提供了开发细粒度服务所需的microservice先决条件的时间。

我听说过不同的执行“巨石优先”策略的方法。合乎逻辑的方法是仔细设计一个整体，注意软件内部的模块化，包括API边界和数据存储方式。做好这一点，向微服务的转变就相对简单了。然而，如果我听过大量这样的故事，我就会对这种方法感到更放心。

更常见的方法是从一个整体开始，逐渐剥离边缘的微服务。这样的方法可以在微服务体系结构的核心留下一个庞大的单体，但是大多数新的开发都发生在微服务中，而单体相对静止。

另一种常见的方法是完全更换巨石。很少有人认为这是一种值得骄傲的方法，然而，建造一块巨石作为祭祀建筑是有好处的。不要害怕建立一个你会抛弃的庞然大物，特别是如果一个庞然大物可以让你快速进入市场。

我遇到的另一种方法是从几个粗粒度的服务开始，这些服务比您期望的要大。使用这些粗粒度服务来习惯使用多个服务，同时享受这样的粗粒度减少了必须进行的服务间重构的数量。然后随着边界的稳定，分解成更细粒度的服务。

虽然我的大部分联系人都倾向于单一优先的方法，但这绝不是一致的。相反的观点认为，从微服务开始可以让您习惯在微服务环境中开发的节奏。以一种足够模块化的方式构建一个单体，以便它可以很容易地分解成微服务，这需要很多，也许是太多的纪律。通过从微服务开始，你可以让每个人从一开始就习惯在独立的小团队中开发，并且通过服务边界将团队分开可以在需要时更容易地扩展开发工作。这对于系统替换尤其可行，因为您有更好的机会尽早提出足够稳定的边界。

尽管证据很少，但我认为除非您在团队中具有构建微服务系统的合理经验，否则不应该从微服务开始。

我觉得我还没有足够的轶事来确定如何决定是否使用“单一优先”策略。这些都是微服务的早期阶段，相对而言，很少有趣闻轶事可以借鉴。因此，任何人在这些话题上的建议都必须被视为试探性的，无论他们多么自信地争辩。

Sam Newman描述了一个团队考虑在新项目中使用微服务的案例研究。

• 注1:
  您不能假设您可以任意取一个系统并将其分解为微服务。大多数系统的模块之间都有太多的依赖关系，因此无法合理地拆分。我听说过很多这样的例子:试图分解一块巨石，结果很快就弄得一团糟。我也听说过一些逐步实现微服务的成功案例——但这些案例需要一个相对较好的模块化设计作为开始。
• 注2:
  严格来说，我认为你应该称之为“双石”，但我认为这种方法遵循了单石优先策略的本质:从粗粒度开始获取知识，然后再拆分。

我从我的同事那里偷了很多想法:James Lewis, Sam Newman, Thiyagu Palanisamy和Evan Bottcher。斯蒂芬·蒂尔科夫(Stefan Tilkov)对早期草稿的评论在澄清我的想法方面发挥了关键作用。查德·库里创造了可爱的雕文龙。Steven Lowe, Patrick Kua, Jean Robert D’amore, Chelsea Komlo, Ashok Subramanian, Dan Siwiec, Prasanna Pendse, Kief Morris, Chris Ford和Florian Sellmayr在我们的内部邮件列表中讨论了草稿。

自从微服务第一次进入软件世界的视野以来，我和我的同事们就一直在写关于微服务的文章。本指南页面有关于何时使用微服务、开始时应该具备的实践、如何有效地测试它们以及如何分解单体的文章。 - by Martin Fowler