我在《技术架构演进的思考》一文中提到，“当前成熟火热的微服务架构，后续会单独总结梳理”，本文便是此“单独总结”

微服务的 what

微服务是 2012～2014 年间提出和兴起的，这时分布式的各种理论体系基本成熟，虚拟化技术更加成熟易用，软硬件基础设施与生态进一步完善/完备，这是微服务能够取代如今成绩的客观条件，否则微服务恐怕只是噱头，无法在复杂庞大的业务场景中有效落地。

对微服务的认识，我觉得可以从“业务”和“技术”两个角度展开。

业务上，微服务是 SOA 的延伸，与 SOA 相通，微服务也是面向服务的，得益于其相关技术，微服务能比 SOA 把服务拆解的更小，因此服务治理更容易，可扩展性更好

技术上，微服务是 SOA 的下一代技术，区别于 SOA 的架构方案，它提供一套新的面向服务的架构，解决了 SOA 中的痛点，让系统具备更好的弹性伸缩的能力，服务的性能、稳定性、可维护性、可用性都能胜过 SOA。

此外，微服务可大可小，可伸可缩。大，微服务能取代 SOA，支撑起亿级业务量的系统；小，微服务能代替单机/单体，让这些系统带来微服务的优势。

微服务的 why

本节主要回答能解决什么问题，和微服务适用于什么场景两个问题。

从“复杂度”这个视角来审视业务，可以从“业务复杂度”和“技术复杂度”两个维度，把业务划分到四个象限中，即：

• 业务复杂度低，技术复杂度低

• 业务复杂度低，技术复杂度高

• 业务复杂度高，技术复杂度低

• 业务复杂度高，技术复杂度高

微服务擅长适用于业务复杂度高的两类场景，主要解决的正是“业务复杂度高”这个问题。

技术复杂度，反应到业务层面是业务的量级，指标上反应为性能、可用性、可扩展性、可维护性等，技术复杂度低的系统，单体/单机架构也能搞定，而技术复杂度高的系统，需要依赖分布式技术带来的水平扩展能力。因此，对于业务复杂度高、技术复杂度低的系统，微服务是对单机/单体架构的取代，对于业务复杂度高、技术复杂度也高的系统，微服务是对 SOA 的取代。

微服务应对“业务复杂度高”的难题，解决方案是合理的微服务拆分及协作，其本质上，是工作分解和任务分配，微服务的技术保证了工作分解的粗或细都能落地，保证了任务分配、协作的可靠性，所以解此难题是微服务的长项。另外，微服务解决此难题也有方法论为依托，业务层面可以应用 DDD 理论，技术层面可以借鉴面向对象的思想和原则。

对于技术复杂度低的系统，由于其业务量级本来就在单机/单体能力范围内，转型微服务，服务的拆分相对简单，可以按照实际场景做合理拆分，尽量避免服务间的调用，避免分布式事务，同时转型微服务后，系统的可扩展性只增不减，可用性大大提高，性能具备了水平扩展能力，且这里的业务量级并不要去依赖全套的微服务基础设施，技术复杂度也不会提高太多，因此这是微服务架构很好的一个应用场景。

对于技术复杂度高的系统，技术成本已经为系统开发增加了不少难度，若业务复杂度不高，没必要引入微服务进一步拔高开发难度；若业务复杂度也很高，引入微服务，虽然有可能侵入原有业务逻辑，增加幂等设计、分布式事务、调用链追踪等开发复杂度，和维护微服务基础设施的运维成本，但选用其他分布式架构，很多相同或相似的技术也不可避免，且这些架构对于拆解“业务复杂度”的能力可能弱于微服务，故综合权衡，微服务是应对业务复杂度高、技术复杂度高系统的首选方案。

综上，

1. 业务复杂度低，技术复杂度低的系统，没必要引入微服务增加无谓的成本

2. 业务复杂度低，技术复杂度高的系统，不应引入微服务提高研发的难度

3. 业务复杂度高，技术复杂度低的系统，若涉及到异构系统集成，或对系统的性能、可用性等有进一步要求时，转型微服务是有效解决方案

4. 业务复杂度高，技术复杂度高的系统，微服务是首选架构方案

微服务的 how

这里主要考虑三个方面：

1. 微服务基础设施的选择

2. 微服务框架的选择

3. 服务的拆分

微服务基础设施的选择

微服务把 SOA 的 ESB 打散为一系列的基础设施，有些以独立服务的形式存在，为防止单点需要实现集群部署，有些可以嵌入到代码框架中，天然暗含了分布式高可用的特性，这是基础设施选择时需要决策的一个点。

这些基础设施按应用可以分层划分，自底向上，可以分为基础设施层、技术支撑层、服务运行层和服务接入层，每一层均有多项不同角色的设施；在微服务建设中，并不需要一开始就把全套基础设施一股脑用起来，而是根据实际情况，如业务量级、复杂度等，选取恰当的设施应用；这是基础设施选择时的另一个决策点。

微服务的基础设施全貌，稍后用脑图梳理，其接入的取舍或优先级如下：

1. 服务运行层设施，如服务注册、服务发现

2. 服务接入层设施，如服务网关，服务流控

3. 基础设施层设施，如配置中心，日志中心

4. 技术支撑层设施，如服务监控，服务追踪

微服务框架的选择

微服务的框架，有三种模式：

1. 嵌入式 SDK

2. 反向代理式

3. Service Mesh

现在最成熟应用最广泛的，当属嵌入式 SDK 模式，如 Spring Cloud 和 Dubbo，而这三类模式的发展，也正是从微服务走向云原生的演化。

如果微服务开发的语言单一，如统一用 Java，首选 SDK 模式，多语言共存时，可以考虑方向代理模式，如 APISIX，而集群规模超大时，则可以首选 Service Mesh

服务的拆分

微服务的拆分，既可以按业务复杂度来拆分，也可以按技术复杂度来拆分。

若按业务复杂度来拆分，可以借鉴 DDD 的理论或面向对象的思想；若按技术复杂度来拆分，可以考虑按性能拆分、按稳定性拆分，或按可用性拆分。

微服务实践

微服务可用于老系统的改造或新系统的建设。

（1）老系统改造

用微服务去改造老系统时，实际工作是个见招拆招的过程，没有统一的方法论指导。只有在思想准备方面，如何做充足准备有章可循：

1. 需要从老系统的痛点出发，否则可能执行不下去，如果痛点比较多，那就从最痛的一个点下手，一个点一个点的来，贪多嚼不烂

2. 如果要改造的老系统，是业务逻辑特别复杂的单体系统，改造可能非常痛苦，痛点也可以无法一刀切下去，需要深入梳理分析业务

3. 做老系统改造，首先是确定目标，然后基于目标做深入到位的变更影响分析，如果老系统业务复杂，可能需要在变更分析的基础上，对老系统做一定的初步改造，才能把目标切出来，而对目标的改造，也有可能会在一定程度上打破原有业务逻辑，需要对老系统再做一些适配才能把新成果移植上去。

所以老系统改造，业务分析、影响分析、方案审核务必慎重、严谨，想不清楚，不要草率动手，至少要留有回滚余地。

（2）新系统建设

把微服务应用于新系统建设，由于没有包袱，会自由很多，这时最好遵循一定章法，基于行之有效的套路来开展。

我觉得把微服务应用于新系统建设，一定要脚踏实地，切记好高骛远。即按照实际的业务复杂度和量级做架构设计，不必为中远期的业务规划做太多过度设计，不要增加非必需的业务或技术复杂度，保持架构演化心态。

微服务架构设计阶段，可以按照上文的优先级逐步接入基础设施，重点做好微服务的拆分工作，总体拆分原则是先总后分，尽量避免过早草率的把微服务拆的太细。

以我个人经验，微服务拆分不合理是实践中最突出的问题。不合理的拆分，可能是出于无意识的草率，也可能是面向不熟悉的领域时，对业务的理解深度不够，或对未来业务的发展动向判断不足导致的。不合理的拆分，可能会造成指数级增长的微服务间相互调用，也可能过早的引入分布式事务、幂等设计等技术复杂度。微服务拆分时，先整体后拆分总是比先拆分后合并简单，所以微服务的拆分务必慎重。

What more

欢迎查阅本文的微信公众号链接和个人博客链接