一篇文章快速指导微服务拆分

前言

因公司战略要求，笔者之前所在的电商项目需要进行微服务拆分。因此参考微服务的一些原则和京东的架构设计总结出了如何快速指导微服务拆分。

1 微服务定义

相对于传统的大型单体应用，现在越来越多的软件开发项目采用微服务架构来进行应用拆分。

从上图可以看出，微服务架构具有以下几个特点：

1. 单一职责原则
   每个微服务仅负责一件事情。
2. 独立运行，独立部署
   每个微服务相互之间完全独立，拥有独立运行的进程和数据库。
3. 轻量级的通信机制
   比如HTTP、REST、Dubbo，甚至基于消息系统。
4. 松耦合
   更新一个微服务不会引起其它微服务的改变。

2 微服务拆分的粒度

康威定律：系统设计结构复制于组织沟通形式。
如下图，不同的组织拆分方式带来不同的团队间沟通方式，从而影响系统设计。

2 微服务拆分需考虑的因素

2.1 团队

2.1.1 团队规模

亚马逊精神：最佳团队规模是刚好分完两个比萨。
微服务架构适配的人员规模应该小而灵活，有独立自主的创新能力，沟通成本也低。

2.1.2 团队成员

团队成员应能全栈而自治，包括业务人员，产品，开发，运维。

2.1.3 团队划分

按业务进行团队划分，而不是技术。

2.2 业务

2.2.1 业务平台化

基础业务下沉。如电商领域的会员认证，商品类目等。

2.2.2 按业务分离

核心业务、非核心业务分离。核心业务精简，非核心业务多样化。

2.2.3 区分业务流程

识别主流程、辅助流程。辅流程应不阻塞主流程。

2.2.4 隔离不同类型的业务

按安全性、高可用、稳定性、性能等方面的要求，以及功能特点、访问频次等。

2.3 技术及安全

2.3.1 服务无状态

对单次请求的处理，不依赖其他请求。
方便水平伸缩。

2.3.2 服务分层分级

划分原子服务，组合服务。
消除跨DAO，跨SERVICE。
提取基础服务，公共服务，如发短信，文件存取。
原子和基础服务实现物理隔离，包括基础服务相关的数据。

2.3.3 服务可治理

构建服务治理平台（注册中心、监控中心等）。

2.3.4 服务可隔离

安全和故障隔离：线程级、进程级、容器级、VM级、物理机级。
支持服务部署到不同线程、线程池中。
核心服务和非核心服务隔离部署。
防止线程膨胀，支持共享和独占线程池策略。

3 微服务架构拆分原则

稳定性原则，不过度设计。
功能完整性，职责单一性。
按服务分层，功能与非功能隔离进行水平拆分。
按业务域进行垂直拆分，相同业务分片。
粒度适中，团队可接受。
API版本向下兼容，支持灰度。
迭代演进。

4 微服务依赖原则

4.1 核心服务依赖

核心服务不依赖非核心服务。
非核心服务可依赖核心服务。
条件：核心服务稳定。

4.2 依赖稳定部分

稳定部分不依赖易变部分。
易变部分可以依赖稳定部分。
要求：避免循环依赖。

4.3 跨域弱依赖

跨业务域调用时，尽可能异步弱依赖。

4.4 基本服务依赖

基本服务不能向上依赖流程服务。
组合服务、流程服务可以向下依赖基本服务。
条件：基本服务稳定。

4.5 非功能性服务依赖

非功能性服务不依赖功能性服务。
功能性服务可依赖非功能性服务。
条件：非功能性服务稳定。

4.6 平台服务依赖

平台服务不依赖上层应用。
上层应用可依赖平台服务。
条件：平台服务稳定。

5 微服务设计原则

5.1 无状态

尽量不要把状态数据保存在本机。
接口调用幂等性。

5.2 可复用

复用粒度是有业务逻辑的抽象服务，不是服务实现细节。
服务引用只依赖于服务抽象。

5.3 松耦合

跨业务域调用，尽可能异步解耦。
必须同步调用时，设置超时和队列大小。
相对稳定的基本服务与易变流程服务分层。

5.4 可治理

制订服务契约。
服务可降级。
服务可限流。
服务可开关。
服务可监控。
白名单机制。

6 微服务拆分方法与策略

6.1 绞杀者模式

6.1.1 拆分策略

新功能用新的方式构建为新的服务。
随着时间推移新服务逐步绞杀老的系统。
适合老旧庞大难以更改的遗留系统。

6.1.2 拆分方法示例1

不在旧的应用中添加代码，而是将新的代码放在另一个单独的微服务中
增加请求路由，通过API网关实现
增加胶水代码，实现服务与旧的应用集成

6.2 修缮者模式

6.2.1 拆分策略

如修路一样。将老旧待修缮的部分进行隔离，新的方式对其进行单独修复。
修复的同时，需保证与其他部分仍能协同功能。

6.2.2 拆分方法示例1

(1)一开始调用应用的方式：

(2)增加接口层，旧引用改为新接口调用：

(3)接口封装成API：

(4)新服务部署为新的进程：

(5)调用改成真正的服务API调用：

6.2.3 拆分方法示例2

(1)需要把MODULEZ提升成微服务：

(2)定义一对粗粒度的API，第一个接口是模块X调用模块Z的入站接口，第二个是模块Z调用模块Y的出站接口：

(3)把MODULEZ改造为独立的服务。通过RESTAPI进行调用：

6.2.3 拆分方法示例3

(1)PHP可以直接修改数据，变成PHP调成微服务修改数据：

(2)多个微服务访问同一个表的方式，演进成微服务下沉成原子服务，其他微服务升级成组合服务来访问原子服务：

(3)同一个微服务访问多表，重构成通过调用多个原子服务访问多表：

6.3 搭积木模式

6.3.1 拆分策略

把系统拆分成各种形状，大小合理的积木
按系统要求进行重新组合成不同的形状
适合新系统

7 微服务拆分样例

7.1 京东商城微服务结构

7.2 京东交易图

参考资料

《京东应用架构设计》（吴博）