【SpringCloud】设计原则之单一职责与服务拆分

一、设计原则之单一职责

设计原则很重要的一点就是简单，单一职责也就是所谓的专人干专事

一个单元（一个类、函数或微服务）应该有且只有一个职责 

无论如何，一个微服务不应该包含多于一个的职责 

职责单一的后果之一就是职责单位（微服务、类、接口、函数）的数量剧增 

据说 Amazon、Netflix 这些采用微服务架构的网站一个小功能就会调用几十上百个微服务 

但相比较于每个函数都是多个业务逻辑或职责功能的混合体的情况，维护成本还是低很多的 

SRP（单一职责原则） 中的 “单一职责” 是个比较模糊的概念

对于函数，它可能指单一的功能，不涉及复杂逻辑

对于类或接口，它可能指对单一对象的操作，也可能是指对该对象单一属性的操作 

总而言之，单一职责原则就是为了让代码逻辑更加清晰，可维护性更加好，定位问题更快的一种设计原则 

单一职责的优点： 

• 类的复杂性降低，实现什么职责都有清晰明确的定义 
• 可读性提高，复杂性降低 
• 可维护性提高，可读性提高 

变更引起的风险降低，变更是必不可少的，若接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助 

实施单一职责的目的： 

• 以类来隔离需求功能点，这样当一个点的需求发生变化时，不会影响别的类的逻辑，这个和设计模式中的开闭原则类似，对扩展持开放态度，对修改持关闭态度 
• 是一个原子模块级的粒度，至于原子的粒度到底是什么样的，应该因业务而异，设计过程中同时考虑业务的扩展，所以这就要求在设计的过程中，必须有业务专家共同参与，共同规避风险 
• 粒度小、灵活、复用性强，方便更高级别的抽象 

每个微服务单独运行在独立的进程中，能够实现松耦合，并且独立部署 

二、设计原则之服务拆分 

拆分粒度不应该过分追求细粒度，要考虑适中，不能过大或过小 

按照单一职责原则和康威定律，在业务域、团队和技术上平衡粒度 

拆分后的代码应该是易控制、易维护的，业务职责也是明确单一的 

AKF 立方体是一个叫 AKF 公司的技术专家抽象总结的应用扩展的三个维度 

理论上按照这三个扩展模式，可以将一个单体应用无限扩展 

AKF 扩展立方体 

• x轴：水平复制，即在负载均衡服务器后增加多个 Web 服务器
• y轴：功能分解，将不同职能的模块分成不同的服务。从 y 轴方向扩展，才能将巨型应用分解为一组不同的服务，例如，订单管理中心、商品信息管理中心等
• z轴： 对数据库的扩展，即分库分表（分布是将关系紧密的表放在一台数据库服务器上，分表是因为一张表的数据太多，需要将一张表的数据通过 Hash 放在不同的数据库服务器上）

三个维度的扩展对比如表： 

 下面看一下 AKF 的拆分实践：

• 拆分应用 

x 轴：从单体系统或服务，水平克隆出许多系统，通过负载均衡分配请求 

y 轴： 面向服务分割，基于功能或服务分割，例如，电商网站可以将登录、搜索、下单等服务进行 y 轴拆分，每一组在进行 x 轴的扩展

z 轴： 面向查找分割，基于用户、请求或数据分割，例如，可以将不同产品的 SKU 分到不同的搜索服务，可以将用户哈希到不同的服务等

• 拆分数据库 

x 轴：从单库水平克隆为多个库上读，一个库写，通过数据库的自我复制实现，要允许一定的读写时延

y 轴：根据不同的信息类型分割为不同的数据库，即分库，例如，产品库、用户库等

z 轴： 按照一定算法进行分片，例如，将搜索按照 MapReduce 的原理进行分片，把 SKU 的数据按照不同的哈希值进行分片存储，每个分片在进行 x 轴冗余

要做好微服务的分层：梳理和抽取核心应用、公共应用，作为独立地服务下沉到核心和公共能力层，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求 

对于服务的拆分，要使用迭代演进的方式，不能一次性完成所有服务的拆分，需要确保团队可接受，粒度适中，同时需要考虑 API 的版本兼容性 

不能单纯的以代码量来对服务拆分的成果进行评估 

MapReduce 原理参考文章： MapReduce基本原理（详解！）_mapreduce工作原理-CSDN博客

参考资料：《微服务架构实战》—— 张锋

一  叶  知  秋，奥  妙  玄  心