单体优先还是直接采用微服务？这个问题随着马丁大叔的文章Monolith First¹发布，显得再次热闹起来。

在我看来，从三个方面尝试分析这个问题。

1. 微服务架构和单体架构区别是什么？
2. 系统建立之初这些区别意味着什么？
3. 如果系统建立之初使用单体架构，后续过渡到微服务架构代价如何？

微服务架构和单体架构区别是什么？

微服务架构与单体架构的区别，本质是系统各部件间分隔的强度大小。

从下面几个方面看一看：

	微服务	单体
领域分隔	领域被分隔为微服务。分隔力度大，相互间的影响较小。微服务可以各自拥有不同的进化节奏，不同领域的创新可以分别实施、快速落地。 领域间的调用相对困难，需要一些基础服务帮助，比如服务注册和寻址等。	领域的分隔表现为模块的分隔，其间的联系简单直接。
团队分隔	团队按微服务配置。成员专注于小的领域和代码集。沟通成本低。容易学习。 需要部件之间紧密协作时相对困难，比如当代码需要在部件之间移动。	整个系统一个团队。如果系统变得庞大，成员就需要学习大量的代码和领域知识，团队内的沟通和协作也变得低效。不得不分割团队时容易按职责分割，形成竖井团队2。
技术分隔	在不同的微服务中，可以根据不同的业务特性分别选择适当的技术。包括可以分别选择适当的存储策略。	整个系统（甚至整个企业）统一的技术栈，管理起来看似简单。但有时候统一的标准并不适合所有的实际情况。
运行时分隔	各部件通常运行于不同的进程。容易进行错误隔离。可以分别伸缩。 运行时需要管理的单位较多，相对困难，需要一些专门的运营工具。	通常运行于同一个进程。部件间协作的额外开销很小。

系统建立之初这些区别意味着什么？

通过上面的罗列比较我们可以看到：对于复杂系统，微服务架构可以有效地分隔复杂度。 但微服务架构有风险：首先需要前期就对领域有良好的认识以便分割。其次需要一定的基础服务和工具。如果团队并不熟悉这种相对较新的架构，学习和适应的成本还是比较高的。 如果我们的系统在建立之初比较简单，在各个方面基本上并不需要高强度的分隔，单体架构往往就能够满足要求。

我们看看什么情况下可能有可能直接从微服务架构开始：

• 我们的系统所面对的领域规模很大，需要进行分割；同时，我们很清楚如何分隔。（……，好吧，这种情况基本没有，囧）
• 我们的团队规模太小，从一开始就无法单独承担系统的规模。
• 我的企业默认架构就是微服务，很多系统已经实践过了。
• 我的老板认为微服务很酷，必须上。
• ……

这些情况下，如果各方充分认识到微服务的代价并作出应对预案，是可以直接应用微服务架构的。

在所有的代价中，有一种最重要，值得再说一遍：领域划分不清晰的情况下请务必慎重，在微服务间移动领域逻辑是非常昂贵的。

已有单体架构系统过渡到微服务架构代价如何？

马丁大叔提出的“扼死大法”³是一种自然有效的过渡方式。但跟其他所有的方式一样。 这个办法的难度和相关代价还是取决于单体本身的结构特点。 如果单体自身拥有良好的结构，容易从中剥离出相对独立的领域逻辑。那我们可以有条不紊逐步剥离：

1. 为新特性创建微服务，单体保持不变。
2. 在单体中识别内聚的子领域，对应地各自剥离为微服务。
3. 按照业务价值和变化频度安排优先级。
4. 并不追求完全消灭单体。

另一种情况，单体本身是一个大泥球。那就没有那么幸运了，我们必须先整理单体本身。

结论

• 单体优先，同时请做好准备，你可能很快需要过渡到微服务。所以做一个“微服务友好”的单体，并适时开始基础服务和团队技能的准备。

• 读到这里仍然觉得自己应该立即微服务的同学：请不犹豫地微服务吧。