单体架构与微服务架构对比，为什么采用微服务架构

小编说：微服务架构给我们带来收益的同时，也会带来副作用，我们应该在什么阶段采用微服务架构？如何拆分微服务架构？拆分粒度多大比较合适？本文内容从问题开始，带你深入微服务架构的多个角落。 本文选自《持续演进的Cloud Native：云原生架构下微服务最佳实践》

• 单体架构与微服务架构

就像很难用一个绝对的方式去判断架构好坏一样，在大多数场景下，我们也很难从一个外部的视角去判断服务拆分粒度的合理性，需要对上下文非常了解才能做出一个好决策。例如，团队规模多大，代码规模多大，有没有平台化，有没有工具链，是否需要持续交付，团队文化如何等。因此，一个外部的架构师是很难在短时间内将架构规划合理的，这需要一个过程，当真正了解这一切之后，不断权衡才能最终确定。在规划之前，有必要参考下面这张表，综合各方面的情况，最终做出决策。

单体架构与微服务架构对比

• 什么时候开始微服务架构

产品初期优先选择单体架构。面对一个新的领域，对业务的理解很难在开始阶段就比较清晰，往往是经过一段时间之后，才能逐步弄清楚。很多时候，从一个已有的单体架构中逐步划分服务，要比一开始就构建微服务简单得多。另外，在资源受限的情况下，采用微服务架构风险较大，很多优势无法体现，性能上的劣势反而会比较明显。

单体、组件化、微服务架构成本趋势，如下图。当业务复杂度达到一定程度后，微服务架构消耗的成本才会体现优势，并不是所有的场景都适合采用微服务架构，服务的划分应逐步进行，持续演进。产品初期业务复杂度不高的时候，应该尽量采用单体架构。

单体、组件化、微服务架构成本趋势

摘自Martin Fowler 博客的内容简单翻译如下。

当我听到关于使用微服务架构的故事的时候，我注意到了一种通用的模式。 1．几乎所有成功的微服务架构都是从一个巨大的单体架构开始的，并且都是由于单体架构太大而被拆分为微服务架构。 2．几乎在所有我听说过从一开始就构建为微服务架构的故事中，最终都有人遇到了巨大的麻烦。

在服务划分之前，应该保证基础设施及公共基础服务已经准备完毕。可以通过监控快速定位故障，通过工具自动化部署、管理服务，通过服务化框架降低服务开发的复杂度，通过灰度发布提升可用性，通过资源调度服务快速申请、释放资源，通过弹性伸缩快速扩展应用。

• 如何决定微服务架构的拆分粒度

微服务架构中的微字，并不代表足够小，应该解释为合适。但是“合适”过于含糊，每个人理解的合适都不尽相同。实际上，有时候对于一个对业务理解不够深入，对团队情况又不是很了解的人，根本无权协助确定服务的粒度。况且，就算本团队的架构师，也很难确定粒度。随着业务发展，开发人员水平的提升，粒度可能会发生变化。这是一个磨合的过程，一个不断演进的过程，没有绝对的对与错。

如果实在找不到合适的依据，可以参考下表。决策占比是从通用的角度考虑，并不适用所有的情况，某些公司认为团队规模是决定性的，也有些公司认为架构演进是决定性的，还有些公司认为交付速度是决定性的，找到那个你认为的决定性因素，去做合理的拆分即可。

微服务拆分粒度决策参考表

本文选自《持续演进的Cloud Native：云原生架构下微服务最佳实践》

作者从全局视角出发，全面阐释Cloud Native 的关键技术，以及其衍生出来的工具、团队文化等核心要素，对于正在部署微服务架构或开展云原生业务的企业和组织而言，终于有了面向落地的务实参考和全面指导。