微服务拆分之道

1、微服务拆分目的

拆分的本质是为了将复杂的问题简单化

2、微服务拆分原因

在技术层面，数据库的连接数成为应用服务器扩容的瓶颈，因为连接 MySQL 的客户端连接数量是有限制的
......

3、拆分时指导原则

a. 单一服务内部功能高内聚低耦合
也就是说每个服务只完成自己职责内的任务，对于不是自己职责的功能交给其它服务来完成。

b. 闭包原则（CCP）
微服务的闭包原则就是当我们需要改变一个微服务的时候，所有依赖都在这个微服务的组件内，不需要修改其他微服务。

c. 服务自治、接口隔离原则
尽量消除对其他服务的强依赖，这样可以降低沟通成本，提升服务稳定性。服务通过标准的接口隔离，隐藏内部实现细节。
这使得服务可以独立开发、测试、部署、运行，以服务为单位持续交付。

d. 持续演进原则
在服务拆分的初期，你其实很难确定服务究竟要拆成什么样。
从微服务这几个字来看，服务的粒度貌似应该足够小，但是服务多了也会带来问题，服务数量快速增长会带来架构复杂度急剧升高，
开发、测试、运维等环节很难快速适应，会导致故障率大幅增加，可用性降低，非必要情况，应逐步划分，持续演进，避免服务数量的爆炸性增长，
这等同于灰度发布的效果，先拿出几个不太重要的功能拆分出一个服务做试验，如果出现故障，则可以减少故障的影响范围。

e. 拆分的过程尽量避免影响产品的日常功能迭代
也就是说要一边做产品功能迭代，一边完成服务化拆分。
比如优先剥离比较独立的边界服务（如短信服务等），从非核心的服务出发减少拆分对现有业务的影响，也给团队一个练习、试错的机会。
同时当两个服务存在依赖关系时优先拆分被依赖的服务。

f. 服务接口的定义要具备可扩展性
服务拆分之后，由于服务是以独立进程的方式部署，所以服务之间通信就不再是进程内部的方法调用而是跨进程的网络通信了。
在这种通信模型下服务接口的定义要具备可扩展性，否则在服务变更时会造成意想不到的错误。
比如微服务的接口因为升级把之前的三个参数改成了四个，上线后导致调用方大量报错，推荐做法服务接口的参数类型最好是封装类，
这样如果增加参数就不必变更接口的签名，而只需要在类中添加字段就可以了。

g. 避免环形依赖与双向依赖
尽量不要有服务之间的环形依赖或双向依赖，原因是存在这种情况说明我们的功能边界没有化分清楚或者有通用的功能没有下沉下来。

h. 阶段性合并
随着你对业务领域理解的逐渐深入或者业务本身逻辑发生了比较大的变化，亦或者之前的拆分没有考虑的很清楚，导致拆分后的服务边界变得越来越混乱，
这时就要重新梳理领域边界，不断纠正拆分的合理性。

3、微服务拆分策略

a.功能维度主要是：划分清楚业务的边界
b.非功能维度主要考虑六点包括：扩展性、复用性、高性能、高可用、安全性、异构性
c.以数据为维度进行拆分
d.按照使用场景拆分服务
e.重要和非重要的拆分
f.变和不变的拆分

4、要做行动派，而不是理论派

在具体怎么拆分上，也不要太纠结于是否合适，不动手怎么知道合不合适呢？
如果拆了之后发现真的不合适，在重新调整就好了。你可能会说，重新调整成本比较高。
但实际上这个问题的本质是有没有针对服务化架构搭建起一套完成的能力体系，比如服务治理平台、数据迁移工具、数据双写等等，
如果有的话，重新调整的成本是不会太高的。