当我听到关于团队使用微服务架构的故事时，我注意到了一个共同的现象。
- 几乎所有成功的微服务故事都是从一个过于庞大的庞然大物开始的，后来这个庞然大物被拆分了
- 我所听说的几乎所有从零开始构建微服务系统的案例，最终都陷入了严重的麻烦。
这种模式导致我的许多同事认为，你不应该用微服务开始一个新项目，即使你确信你的应用程序足够大，值得这样做。
微服务是一种有用的体系结构，但即使是它们的拥护者也说，使用它们会产生显著的微服务溢价，这意味着它们只对更复杂的系统有用。这种溢价，本质上是管理一套服务的成本，将会拖慢团队的速度，而倾向于为更简单的应用程序提供一个整体。这导致了对单体优先策略的有力论证，在这种策略中，您应该首先将新应用程序构建为单体，即使您认为它可能会在以后从微服务架构中受益。
第一个原因是经典的雅格尼。当你开始一个新的应用程序时，你有多确定它对你的用户有用” />
自从微服务第一次进入软件世界的视野以来，我和我的同事们就一直在写关于微服务的文章。本指南页面有关于何时使用微服务、开始时应该具备的实践、如何有效地测试它们以及如何分解单体的文章。 – by Martin Fowler