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

一、设计原则之单一职责

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

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

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

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

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

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

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

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

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

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

单一职责的优点: 

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

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

实施单一职责的目的: 

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

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

二、设计原则之服务拆分 

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

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

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

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

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

【SpringCloud】设计原则之单一职责与服务拆分_第1张图片

AKF 扩展立方体 

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

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

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

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

  • 拆分应用 

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

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

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

  • 拆分数据库 

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

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

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

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

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

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

MapReduce 原理参考文章: MapReduce基本原理(详解!)_mapreduce工作原理-CSDN博客

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

一  叶  知  秋,奥  妙  玄  心

你可能感兴趣的:(SpringCloud,spring,cloud,微服务)