架构设计相关指导原则

Dear 丶 2023-02-23 07:55 212阅读 0赞

### 架构设计中的原则 ###

*  架构原则的基本概念
 *  开闭原则-OCP
 *  单一职责原则-SRP
 *  里氏替换原则-LSP
 *  接口隔离原则-ISP
 *  依赖反转原则-DIP
 *  复用与发布等同原则-REP
 *  共同闭包原则-CCP
 *  共同复用原则-CRP
 *  架构指导原则
 *   *   *  N+1设计
         *  回滚设计
         *  监控设计
         *  多活数据中心设计
         *  采用成熟的技术
         *  资源隔离原则
         *  架构水平扩展
         *  非核心则购买原则
         *  快速迭代
         *  无状态设计

# 架构原则的基本概念 #

*  **设计原则:**
    
     *  架构设计的指导思想
     *  指导如何将数据和函数组织成类,如何将类连接成组件和程序
 *  架构的主要工作就是将软件拆解为组件,而设计原则就是指导如何拆解,拆解的粒度,组件间依赖的方向,组件的解耦方式等
 *  **架构设计的主要原则:**
    
     *  **开闭原则OCP**
 *  **类和代码层级上的原则:**
    
     *  **单一职责原则SRP**
     *  **里氏替换原则LSP**
     *  **接口隔离原则ISP**
     *  **依赖反转原则DIP**
 *  **组件层级上的原则:**
    
     *  **复用,发布等同原则REP**
     *  **共同闭包原则CCP**
     *  **共同复用原则CRP**
 *  **处理组件依赖问题三原则:**
    
     *  **无依赖原则**
     *  **稳定依赖原则**
     *  **稳定抽象原则**

# 开闭原则-OCP #

*  设计良好的软件应该对扩展开放,对修改关闭
 *  这是进行架构设计的主导原则,其余原则都为这条原则服务

# 单一职责原则-SRP #

*  任何一个软件模块,都应该只有一个被修改的原因
 *  也就是说,任何模块只对一个用户价值负责,可以用这个原则来拆分组件

# 里氏替换原则-LSP #

*  当用同一接口的不同实现互相替换时,系统的行为应该保持不变
 *  里氏替换原则指导的是接口和实现方式

# 接口隔离原则-ISP #

*  不依赖任何不需要的方法,类或者组件
 *  接口隔离原则指导的是接口设计
    
     *  当我们依赖一个接口但是只用到了其中的部分方法时,其实已经依赖了不需要的方法或类
     *  当这些方法或类有变更时,会引起类的重新编译,或者引起组件的重新部署,这些都是不必要的
     *  最好定义一个小接口,将用到的方法拆分出来

# 依赖反转原则-DIP #

*  一种特定的解耦形式:
    
     *  传统的依赖关系创建在高层次上
     *  具体的策略设置则应用在低层次上
 *  使得高层次的模块不依赖于低层次的模块的实现细节,依赖关系被反转
 *  从而使得低层次模块依赖于高层次模块的需求抽象
 *  跨越组件边界的依赖方向永远与控制流的方向相反.该原则指导设计组件间的依赖方向
 *  依赖反转是一个操作性非常强的原则:
    
     *  当需要修改组件间的依赖方向时,将需要进行组件间通信的类抽象为接口
     *  接口放在边界的哪边,依赖就指向哪边

# 复用与发布等同原则-REP #

*  软件复用的最小粒度应等同于发布的最小粒度
 *  也就是说,要复用一段代码就应该抽象成组件
 *  该原则指导组件拆分的粒度

# 共同闭包原则-CCP #

*  为了相同目的而同时修改的类,应该放在同一个组件中
    
     *  对于大部分应用而言,可维护的重要性远远大于可复用性
     *  由于同一个原因引起的代码修改,最好在同一个组件中
     *  如果分散在多个组件中,那么开发,提交,部署的成本都会上升
 *  CCP原则是SRP原则在组件层面的描述
 *  该原则指导组件拆分的粒度

# 共同复用原则-CRP #

*  不要强迫一个组件依赖组件本身不需要的依赖
 *  CRP原则是ISP原则在组件层面的描述,该原则指导组件拆分的粒度

# 架构指导原则 #

*  除了上述设计原则以外,还有一些重要的指导原则:  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pld2F2ZU94Zm9yZA_size_16_color_FFFFFF_t_70]

### N+1设计 ###

*  系统中的每个组件都应该做到没有单点故障

### 回滚设计 ###

*  确保系统可以向前兼容,在系统升级时应该能有办法回滚版本

### 监控设计 ###

*  在设计阶段就要考虑监控的手段,便于有效的排查问题
 *  比如引入traceId,业务身份ID便于监控问题

### 多活数据中心设计 ###

*  如果系统需要极高的高可用,应该考虑在多地实施数据中心进行多活,至少在一个机房断电的情况下系统依然可用

### 采用成熟的技术 ###

*  刚开发或者开源的技术往往存在很多隐藏的bug
 *  应该采用有更好的技术支持的技术

### 资源隔离原则 ###

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

### 架构水平扩展 ###

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

### 非核心则购买原则 ###

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

### 快速迭代 ###

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

### 无状态设计 ###

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pld2F2ZU94Zm9yZA_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200712101656311.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0pld2F2ZU94Zm9yZA==,size_16,color_FFFFFF,t_70