微服务拆分原则

在设计微服务的时候，我们一般会遵循以下4个原则：

1）AKF拆分原则

2）前后端分离原则

3）无状态服务

4）restful的通信风格

AKF拆分原则

对于一个规模迅速增长的系统而言，容量和性能问题当然是首当其冲的。但是随着系统规模的增长，除了面对性能与容量的问题外，还需要面对功能与模块数量上的增长带来的系统复杂性问题以及业务的变化带来的提供差异化服务问题。许多系统，在架构设计时并未充分考虑到这些问题，导致系统的重构成为常态，从而影响业务交付能力，还浪费人力财力！

对此，《可扩展的艺术》一书提出了一个更加系统的可扩展模型—— AKF 可扩展立方（Scalability Cube） 。这个立方体中沿着三个坐标轴设置分别为：X、Y、Z。

Y 轴扩展会将庞大的整体应用拆分为多个服务。每个服务实现一组相关的功能，如订单管理、客户管理等。在工程上常见的方案是 服务化架构(SOA) 。

X 轴扩展与我们前面朴素理念是一致的，通过绝对平等地复制服务与数据，以解决容量和可用性的问题。其实就是将微服务运行多个实例，做集群加负载均衡的模式。

Z 轴扩展通常是指基于请求者或用户独特的需求，进行系统划分，并使得划分出来的子系统是相互隔离但又是完整的。

前后端分离原则

前后端分离原则，简单来讲就是前端和后端的代码分离也就是技术上做分离，我们推荐的模式是最好直接采用物理分离的方式部署，进一步促使进行更彻底的分离。不要继续以前的服务端模板技术，比如JSP ，把Java JS HTML CSS 都堆到一个页面里，稍复杂的页面就无法维护。这种分离模式的方式有几个好处：

1. 前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端的用户体验优化效果会更好。
2. 分离模式下，前后端交互界面更加清晰，就剩下了接口和模型，后端的接口简洁明了，更容易维护。
3. 前端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支撑前端的web UI\ 移动App等访问。

无状态服务

阻碍单体架构变为分布式架构的关键点就在于状态的处理。如果状态全部保存在本地，无论是本地的内存，还是本地的硬盘，都会给架构的横向扩展带来瓶颈。

状态分为分发、处理、存储几个过程，如果对于一个用户的所有的信息都保存在一个进程中，则从分发阶段，就必须将这个用户分发到这个进程，否则无法对这个用户进行处理，然而当一个进程压力很大的时候，根本无法扩容，新启动的进程根本无法处理那些保存在原来进程的用户的数据，不能分担压力。所以要讲整个架构分成两个部分，无状态部分和有状态部分，而业务逻辑的部分往往作为无状态的部分，而将状态保存在有状态的中间件中，如缓存、数据库、对象存储、大数据平台、消息队列等。

这样无状态的部分可以很容易的横向扩展，在用户分发的时候，可以很容易分发到新的进程进行处理，而状态保存到后端。而后端的中间件是有状态的，这些中间件设计之初，就考虑了扩容的时候，状态的迁移，复制，同步等机制，不用业务层关心。restful的通信风格

restful通信风格，它有许多优点：

1，无状态协议HTTP，具备先天优势，扩展能力强，例如安全加密有成熟的https。

2，JSON报文序列化，轻量简单，人与机均可读，学习成本低，搜索引擎友好。

3，语言无关，各大热门语言都提供成熟的Restful API框架，相对一些其他RPC框架生态更加完善。

上面的原则十分通用，实际工作中，个人认为还应参考以下一些实践原则：

一：单一服务内部功能高内聚低耦合

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

二：闭包原则（CCP）

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

三：服务自治、接口隔离原则

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

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

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

五：服务接口的定义要具备可扩展性

比如微服务的接口因为升级把之前的三个参数改成了四个，上线后导致调用方大量报错，推荐做法服务接口的参数类型最好是对象类型，这样如果增加参数就不必变更接口的签名，而只需要在类中添加字段就可以了。

六：避免环形依赖与双向依赖

如果存在这种情况，说明功能边界没有划分清楚或者有通用的功能没有下沉。

七：持续演进原则

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

建议的服务拆分策略（仅供参考）：

一：功能维度：划分清楚业务边界

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

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

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

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

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

二：非功能维度：扩展性、复用性、高性能、高可用、安全性、异构性

1、区分系统中变与不变部分，变与不变部分拆分成不同服务；

2、不同的业务里或服务里经常会出现重复的功能，重复功能拆分独立服务；

3、将性能要求高或者性能压力大的模块拆分出来；

4、将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来；

5、把需要高度安全的服务拆分出来，进行区别部署；

6、对开发语言有要求的业务场景，可用不同的语言将其功能独立出来实现一个独立服务

————————————————
原文链接：https://blog.csdn.net/weixin_45443931/article/details/98869435