常用的架构指导原则分析:要想做好架构设计,一定要遵循这几个设计原则!

架构原则的基本概念

  • 设计原则:
    • 架构设计的指导思想
    • 指导如何将数据和函数组织成类,如何将类连接成组件和程序
  • 架构的主要工作就是将软件拆解为组件,而设计原则就是指导如何拆解,拆解的粒度,组件间依赖的方向,组件的解耦方式等
  • 架构设计的主要原则:
    • 开闭原则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
  • 应该采用有更好的技术支持的技术

资源隔离原则

  • 应避免单一业务占用全部资源

架构水平扩展

  • 系统只有做到能水平扩展,才能有效避免瓶颈问题

非核心则购买原则

  • 非核心功能如果需要占用大量的研发资源才能解决,那么就考虑购买成熟的产品

快速迭代

  • 系统应该快速开发小功能模块,尽快上线验证,早日发现问题来大大降低系统交付的风险

无状态设计

  • 服务接口应该做成无状态的
  • 当前接口的访问不依赖于接口上次访问的状态

你可能感兴趣的:(常用的架构指导原则分析:要想做好架构设计,一定要遵循这几个设计原则!)