微服务拆分之道

也就是说每个服务只完成自己职责内的任务，对于不是自己职责的功能交给其它服务来完成。

​

2. 闭包原则（ CCP ）

​

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

​

3. 服务自治、接口隔离原则

​

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

​

4. 持续演进原则

​

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

​

5. 拆分的过程尽量避免影响产品的日常功能迭代

​

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

​

6. 服务接口的定义要具备可扩展性

​

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

​

7. 避免环形依赖与双向依赖

​

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

​

8. 阶段性合并

​

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

​

[](()拆分的粒度是不是越细越好？

==================================================================================

​

目前很多传统的单体应用再向微服务架构进行升级改造，如果拆分粒度太细会增加运维复杂度，粒度过大又起不到效果，那么改造过程中如何平衡拆分粒度呢？

1. 弓箭原理

​

平衡拆分粒度可以从两方面进行权衡，一是业务发展的复杂度，二是团队规模的人数。如上图，它就像弓箭一样，只有当业务复杂度和团队人数足够大的时候，射出的服务拆分粒度这把剑才会飞的更远，发挥出最大的威力。

​

比如说电商的商品服务，当我们把商品从大的单体里拆分出来的时候，就商品服务本身来讲，逻辑并没有足够复杂到 2 ~ 3 个人没法维护的地步，这时我们没有必要继续将商品服务拆的更细，但是随着业务的发展，商品的业务逻辑变的越来越复杂，可能同时服务公司的多个平台，此时你会发现商品服务本身面临的问题跟单体架构阶段面临的问题基本一样，这个阶段就需要我们将商品拆成更细粒度的服务，比如，库存服务、价格服务、类目服务、商品基础信息服务等等。

虽然业务复杂度已经满足了，如果公司此时没有足够的人力（招聘不及时或员工异动比较多），服务最好也不要拆分，拆分会因为人力的不足导致更多的问题，如研发效率大幅下降（一个开发负责与其不匹配数量的服务）。这里引申另外一个问题，一个微服务究竟需要几个开发维护是比较理性的？我引用下李云华老师在"从零开始学架构“ 中的一段经典论述，可以解决此问题。

​

2. 三个火枪手原则

​

为什么说是三个人分配一个服务是比较理性的？而不是 4 个，也不是 2 个呢？

​

首先，从系统规模来讲，3 个人负责开发一个系统，系统的复杂度刚好达到每个人都能全面理解整个系统，又能够进行分工的粒度；如果是 2 个人开发一个系统，系统的复杂度不够，开发人员可能觉得无法体现自己的技术实力；如果是 4 个甚至更多人开发一个系统，系统复杂度又会无法让开发人员对系统的细节都了解很深。

​

其次，从团队管理来说，3 个人可以形成一个稳定的备份，即使 1 个人休假或者调配到其他系统，剩余 2 个人还可以支撑；如果是 2 个人，抽调 1 个后剩余的 1 个人压力很大；如果是 1 个人，这就是单点了，团队没有备份，某些情况下是很危险的，假如这个人休假了，系统出问题了怎么办？

​

最后，从技术提升的角度来讲，3 个人的技术小组既能够形成有效的讨论，又能够快速达成一致意见；如果是 2 个人，可能会出现互相坚持自己的意见，或者 2 个人经验都不足导致设计缺陷；如果是 1 个人，由于没有人跟他进行技术讨论，很可能陷入思维盲区导致重大问题；如果是 4 个人或者更多，可能有的参与的人员并没有认真参与，只是完成任务而已。

​

“三个火枪手”的原则主要应用于微服务设计和开发阶段，如果微服务经过一段时间发展后已经比较稳定，处于维护期了，无须太多的开发，那么平均 1 个人维护 1 个微服务甚至几个微服务都可以。当然考虑到人员备份问题，每个微服务最好都安排 2 个人维护，每个人都可以维护多个微服务。

​

综上所诉，拆分粒度不是越细越好，粒度需要符合弓箭原理及三个火枪手原则。

​

[](()拆分策略有哪些？

=============================================================================

​

拆分策略可以按功能和非功能维度进行考虑，功能维度主要是划分清楚业务的边界，非功能维度主要考虑六点包括扩展性、复用性、高性能、高可用、安全性、异构性。接下来详细介绍下。

功能维度

​

功能维度主要是划分清楚业务边界，采用的主要设计方法可以利用 DDD（关于 DDD 的理论知识可以参考网上其它资料），DDD 的战略设计会建立领域模型，可以通过领域模型指导微服务的拆分，主要分四步进行：

​

• 第一步，找出领域实体和值对象等领域对象。

• 第二步，找出聚合根，根据实体、值对象与聚合根的依赖关系，建立聚合。

• 第三步，根据业务及语义边界等因素，定义限界上下文。

• 第四步，每一个限界上下文可以拆分为一个对应的微服务，但也要考虑一些非功能因素。

以电商的场景为例，交易链路划分的限界上下文如下图左半部分，根据一个限界上下文可以设计一个微服务，拆解出来的微服务如下图右侧部分。

​

2. 非功能维度

​

当我们按照功能维度进行拆分后，并不是就万事大吉了，大部分场景下，我们还需要加入其它维度进一步拆分，才能最终解决单体架构带来的问题。

​

• 扩展性：区分系统中变与不变的部分，不变的部分一般是成熟的、通用的服务功能，变的部分一般是改动比较多、满足业务迭代扩展性需要的功能，我们可以将不变的部分拆分出来，作为共用的服务，将变的部分独立出来满足个性化扩展需要。同时根据二八原则，系统中经常变动的部分大约只占 20%，而剩下的 80 % 基本不变或极少变化，这样的拆分也解决了发布频率过多而影响成熟服务稳定性的问题。

• 复用性：不同的业务里或服务里经常会出现重复的功能，比如每个服务都有鉴权、限流、安全及日志监控等功能，可以将这些通过的功能拆分出来形成独立的服务，也就是微服务里面的 API 网关。在如，对于滴滴业务，有快车和顺风车业务，其中都涉及到了订单支付的功能，那么就可以将订单支付独立出来，作为通用服务服务好上层业务。如下图：

• 高性能：将性能要求高或者性能压力大的模块拆分出来，避免性能压力大的服务影响其它服务。常见的拆分方式和具体的性能瓶颈有关，例如电商的抢购，性能压力最大的是入口的排队功能，可以将排队功能独立为一个服务。同时，我们也可以基于读写分离来拆分，比如电商的商品信息，在 App 端主要是商详有大量的读取操作，但是写入端商家中心访问量确很少。因此可以对流量较大或较为核心的服务做读写分离，拆分为两个服务发布，一个负责读，另外一个负责写。还有数据一致性是另一个基于性能维度拆分需要考虑的点，对于强一致的数据，属于强耦合，尽量放在同一个服务中（但是有时会因为各种原因需要进行拆分，那就需要有响应的机制进行保证），弱一致性通常可以拆分为不同的服务。

• 高可用：将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来，然后重点保证核心服务的高可用。具体拆分的时候，核心服务可以是一个也可以是多个，只要最终的服务数量满足“三个火枪手”的原则就可以。比如针对商家服务，可以拆分一个核心服务一个非核心服务，核心服务供交易服务访问，非核心提供给商家中心访问 。

• 安全性：不同的服务可能对信息安全有不同的要求，因此把需要高度安全的服务拆分出来，进行区别部署，比如设置特定的 DMZ 区域对服务进行分区部署，可以更有针对性地满足信息安全的要求，也可以降低对防火墙等安全设备吞吐量、并发性等方面的要求，降低成本，提高效率。

• 异构性：对于对开发语言种类有要求的业务场景，可以用不同的语言将其功能独立出来实现一个独立服务。

以上几种拆分方式不是多选一，而是可以根据实际情况自由排列组合。同时拆分不仅仅是架构上的调整，也意味着要在组织结构上做出相应的适应性优化，以确保拆分后的服务由相对独立的团队负责维护。

​

[](()服务都拆了为什么还要合并？

==================================================================================

​

古希腊哲学家赫拉克利特曾经说过：“人不能两次踏进同一条河流。”随着时间的流逝，任何事物的状态都会发生变化。线上系统同样如此，即使一个系统在不同时刻的状况也绝不会一模一样。现在拆分出来的服务粒度也许合适，但谁能保证这个粒度能够一直正确呢。

服务都拆了为什么还要合，就是要不断适应新的业务发展阶段，笔者这里做个类比看大家是否清晰，拆相当于我们开发代码，合相当于重构代码，为什么要重构呢，相信你肯定知道。微服务的合也是一样的道理，随着我们对应用程序领域的了解越来越深，它们可能会随着时间的推移而变化。例如，你可能会发现由于过多的进程间通信而导致特定的分解效率低下，导致你必须把一些服务组合在一起。

​

同时因为人员和服务数量的不匹配，导致的维护成本增加，也是导致服务合并的一个重要原因。例如，今年疫情的影响导致很多企业开始大量裁员，人员流失但是服务的数量确没有变，造成服务数量和人员的不平衡，一个开发同学同时要维护至少 5 个服务的开发，效率大幅下降。

​

那么如果微服务数量过多和资源不匹配，则可以考虑合并多个微服务到服务包，部署到一台服务器，这样可以节省服务运行时的基础资源消耗也降低了维护成本。需要注意的是，虽然服务包是运行在一个进程中，但是服务包内的服务依然要满足微服务定义，以便在未来某一天要重新拆开的时候可以很快就分离。服务合并到服务包示意图如下：

​

[](()拆分过程中要注意 《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》无偿开源 威信搜索公众号【编程进阶路】 的风险