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

一、设计原则之单一职责

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

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

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

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

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

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

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

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

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

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

单一职责的优点：

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

实施单一职责的目的：

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

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

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

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

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

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

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

AKF 扩展立方体

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

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

纬度	优点	缺点	场景
x 轴扩展	成本最低，实施简单	受指令集多少和数据集多少的约束。当单个产品或应用过大时，服务响应变慢，无法通过 x 轴的水平扩展提高速度	发展初期，业务复杂度低，需要增加系统容量
y 轴扩展	可以解决指令集和数据集的约束，解决代码复杂度问题，可以实现隔离故障，可以提高响应时间，可以使团队聚焦更利于团队成长	成本相对较高	业务复杂，数据量大，代码耦合度高，团队规模大
z 轴扩展	能解决数据集的约束，降低故障风险，实现渐进交付，可以带来最大的扩展性	成本最昂贵，且不一定能解决指令集的问题	用户指数级快速增长