这是我参与8月更文挑战的第18天，活动详情查看：8月更文挑战

架构原则的基本概念

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

资源隔离原则

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

架构水平扩展

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

非核心则购买原则

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

快速迭代

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

无状态设计

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