架构原则的基本概念
-
设计原则:
- 架构设计的指导思想
- 指导如何将数据和函数组织成类,如何将类连接成组件和程序
- 架构的主要工作就是将软件拆解为组件,而设计原则就是指导如何拆解,拆解的粒度,组件间依赖的方向,组件的解耦方式等
-
架构设计的主要原则:
- 开闭原则OCP
-
类和代码层级上的原则:
- 单一职责原则SRP
- 里氏替换原则LSP
- 接口隔离原则ISP
- 依赖反转原则DIP
-
组件层级上的原则:
- 复用,发布等同原则REP
- 共同闭包原则CCP
- 共同复用原则CRP
-
处理组件依赖问题三原则:
- 无依赖原则
- 稳定依赖原则
- 稳定抽象原则
开闭原则-OCP
- 设计良好的软件应该对扩展开放,对修改关闭
- 这是进行架构设计的主导原则,其余原则都为这条原则服务
单一职责原则-SRP
- 任何一个软件模块,都应该只有一个被修改的原因
- 也就是说,任何模块只对一个用户价值负责,可以用这个原则来拆分组件
里氏替换原则-LSP
- 当用同一接口的不同实现互相替换时,系统的行为应该保持不变
- 里氏替换原则指导的是接口和实现方式
接口隔离原则-ISP
- 不依赖任何不需要的方法,类或者组件
- 接口隔离原则指导的是接口设计
- 当我们依赖一个接口但是只用到了其中的部分方法时,其实已经依赖了不需要的方法或类
- 当这些方法或类有变更时,会引起类的重新编译,或者引起组件的重新部署,这些都是不必要的
- 最好定义一个小接口,将用到的方法拆分出来
依赖反转原则-DIP
- 一种特定的解耦形式:
- 传统的依赖关系创建在高层次上
- 具体的策略设置则应用在低层次上
- 使得高层次的模块不依赖于低层次的模块的实现细节,依赖关系被反转
- 从而使得低层次模块依赖于高层次模块的需求抽象
- 跨越组件边界的依赖方向永远与控制流的方向相反.该原则指导设计组件间的依赖方向
- 依赖反转是一个操作性非常强的原则:
- 当需要修改组件间的依赖方向时,将需要进行组件间通信的类抽象为接口
- 接口放在边界的哪边,依赖就指向哪边
复用与发布等同原则-REP
- 软件复用的最小粒度应等同于发布的最小粒度
- 也就是说,要复用一段代码就应该抽象成组件
- 该原则指导组件拆分的粒度
共同闭包原则-CCP
- 为了相同目的而同时修改的类,应该放在同一个组件中
- 对于大部分应用而言,可维护的重要性远远大于可复用性
- 由于同一个原因引起的代码修改,最好在同一个组件中
- 如果分散在多个组件中,那么开发,提交,部署的成本都会上升
- CCP原则是SRP原则在组件层面的描述
- 该原则指导组件拆分的粒度
共同复用原则-CRP
- 不要强迫一个组件依赖组件本身不需要的依赖
- CRP原则是ISP原则在组件层面的描述,该原则指导组件拆分的粒度
架构指导原则
-
除了上述设计原则以外,还有一些重要的指导原则:
在这里插入图片描述
N+1设计
- 系统中的每个组件都应该做到没有单点故障
回滚设计
- 确保系统可以向前兼容,在系统升级时应该能有办法回滚版本
监控设计
- 在设计阶段就要考虑监控的手段,便于有效的排查问题
- 比如引入traceId,业务身份ID便于监控问题
多活数据中心设计
- 如果系统需要极高的高可用,应该考虑在多地实施数据中心进行多活,至少在一个机房断电的情况下系统依然可用
采用成熟的技术
- 刚开发或者开源的技术往往存在很多隐藏的bug
- 应该采用有更好的技术支持的技术
资源隔离原则
- 应避免单一业务占用全部资源
架构水平扩展
- 系统只有做到能水平扩展,才能有效避免瓶颈问题
非核心则购买原则
- 非核心功能如果需要占用大量的研发资源才能解决,那么就考虑购买成熟的产品
快速迭代
- 系统应该快速开发小功能模块,尽快上线验证,早日发现问题来大大降低系统交付的风险
无状态设计
- 服务接口应该做成无状态的
- 当前接口的访问不依赖于接口上次访问的状态
