网站开发5000,最小的wordpress主题,品牌建设需打持久战,百度指数热度榜一、设计原则之单一职责
设计原则很重要的一点就是简单#xff0c;单一职责也就是所谓的专人干专事
一个单元#xff08;一个类、函数或微服务#xff09;应该有且只有一个职责
无论如何#xff0c;一个微服务不应该包含多于一个的职责
职责单一的后果之一就是职责单…一、设计原则之单一职责
设计原则很重要的一点就是简单单一职责也就是所谓的专人干专事
一个单元一个类、函数或微服务应该有且只有一个职责
无论如何一个微服务不应该包含多于一个的职责
职责单一的后果之一就是职责单位微服务、类、接口、函数的数量剧增
据说 Amazon、Netflix 这些采用微服务架构的网站一个小功能就会调用几十上百个微服务
但相比较于每个函数都是多个业务逻辑或职责功能的混合体的情况维护成本还是低很多的 SRP单一职责原则 中的 “单一职责” 是个比较模糊的概念
对于函数它可能指单一的功能不涉及复杂逻辑
对于类或接口它可能指对单一对象的操作也可能是指对该对象单一属性的操作
总而言之单一职责原则就是为了让代码逻辑更加清晰可维护性更加好定位问题更快的一种设计原则 单一职责的优点
类的复杂性降低实现什么职责都有清晰明确的定义 可读性提高复杂性降低 可维护性提高可读性提高 变更引起的风险降低变更是必不可少的若接口的单一职责做得好一个接口修改只对相应的实现类有影响对其他的接口无影响这对系统的扩展性、维护性都有非常大的帮助 实施单一职责的目的
以类来隔离需求功能点这样当一个点的需求发生变化时不会影响别的类的逻辑这个和设计模式中的开闭原则类似对扩展持开放态度对修改持关闭态度 是一个原子模块级的粒度至于原子的粒度到底是什么样的应该因业务而异设计过程中同时考虑业务的扩展所以这就要求在设计的过程中必须有业务专家共同参与共同规避风险 粒度小、灵活、复用性强方便更高级别的抽象
每个微服务单独运行在独立的进程中能够实现松耦合并且独立部署 二、设计原则之服务拆分
拆分粒度不应该过分追求细粒度要考虑适中不能过大或过小
按照单一职责原则和康威定律在业务域、团队和技术上平衡粒度
拆分后的代码应该是易控制、易维护的业务职责也是明确单一的 AKF 立方体是一个叫 AKF 公司的技术专家抽象总结的应用扩展的三个维度
理论上按照这三个扩展模式可以将一个单体应用无限扩展 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博客
参考资料《微服务架构实战》—— 张锋 一 叶 知 秋奥 妙 玄 心
