单体架构还是微服务架构

1 http://www.cnblogs.com/redmoon/archive/2015/05/19/4515690.html

微服务架构现在越来越流行，那么是不是就意味着单体架构不再成为我们的选择了呢？个人认为这个要依情况而定。

现在谈及微服务架构的文章、演讲随处可见，似乎所有系统的架构都开始尽情拥抱微服务架构，包括笔者前久为一个异构电商平台系统设计的架构也选用了这种风格。然而，我们在选择微服务架构之前，一定要问一句“你现在面对的系统，微服务架构是一个好的选择吗？”。当然，这个问题也是我这几天在思考的。在我看来，任何互联网系统的架构发展到后期，随着复杂度越来越大，那么微服务架构是必然也是最好的选择。但是，正如《互联网系统架构的演进》提到的，系统的架构都是从小到大从简单到复杂演进的，“网站初期的架构一般采用“短平快”的架构思路，架构以简单清晰、容易开发为第一衡量指标。”

所以，微服务架构是否是一个好的选择，实际上要看系统的复杂度来决定的。对于这个问题，老马（Martin Fowler）最近发表的一篇文章《MicroservicePremium》深刻阐述了这一点。他给出了一个很关键的图：

上图直观的说明了单体架构和微服务架构在不同系统复杂度下不同的生产力，以及两者的对比关系。这篇文章谈到的很多具体内容，还需要读者自己去“阅读原文”。

综上，对于那种需要快速为商业模式提供验证的系统，其功能较少、用户很低的情况下，单体架构是更好的选择。不过，为了考虑未来的发展，一些基础性的功能（比如邮件发送之类）还是可以单独抽离封装为微服务的。且在单体架构内部，也需要更清晰的划分功能模块（尽量不让它们产生太强的耦合），数据库设计也可预先考虑未来微服务抽离的情况。

原文链接：http://martinfowler.com/bliki/MicroservicePremium.html

2  http://blog.jobbole.com/99574/

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

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

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

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

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

从下面几个方面看一看：

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

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

通过上面的罗列比较我们可以看到：对于复杂系统，微服务架构可以有效地分隔复杂度。

但微服务架构有风险：首先需要前期就对领域有良好的认识以便分割。其次需要一定的基础服务和工具。如果团队并不熟悉这种相对较新的架构，学习和适应的成本还是比较高的。

如果我们的系统在建立之初比较简单，在各个方面基本上并不需要高强度的分隔，单体架构往往就能够满足要求。

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

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

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

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

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

马丁大叔提出的“扼死大法”3是一种自然有效的过渡方式。但跟其他所有的方式一样。

这个办法的难度和相关代价还是取决于单体本身的结构特点。

如果单体自身拥有良好的结构，容易从中剥离出相对独立的领域逻辑。那我们可以有条不紊逐步剥离：

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

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

结论

• 单体优先，同时请做好准备，你可能很快需要过渡到微服务。所以做一个“微服务友好”的单体，并适时开始基础服务和团队技能的准备。
• 读到这里仍然觉得自己应该立即微服务的同学：请不犹豫地微服务吧。