单体优先还是微服务?

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

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

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

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

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

从下面几个方面看一看:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

结论

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

  1. Monolith First
  2. “竖井团队”被认为在大部分情况下是反模式。参见“反Conway策略”
  3. StranglerApplication
1 1 收藏 评论

关于作者:聂同学

应用架构师。精通信息系统架构及开发方法。熟悉互联网、大数据、云等情形下信息系统特点和应用策略。长期从事企业信息系统架构相关工作。熟悉j2ee和web相关技术。 个人主页 · 我的文章 · 1 ·   

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部