优秀架构师修成之路( 二 ) _架构师

5、DIP（依赖反转原则）：指一种特定的解耦（传统的依赖关系创建在高层次上，而具体的策略设置则应用在低层次的模块上）形式，使得高层次的模块不依赖于低层次的模块的实现细节，依赖关系被颠倒（反转），从而使得低层次模块依赖于高层次模块的需求抽象。
跨越组建边界的依赖方向永远与控制流的方向相反。该原则指导我们设计组件间依赖的方向。
依赖反转原则是个可操作性非常强的原则，当你要修改组件间的依赖方向时，将需要进行组件间通信的类抽象为接口，接口放在边界的哪边，依赖就指向哪边。
6、REP（复用、发布等同原则）：软件复用的最小粒度应等同于其发布的最小粒度。直白地说，就是要复用一段代码就把它抽成组件，该原则指导我们组件拆分的粒度。
7、CCP（共同闭包原则）：为了相同目的而同时修改的类，应该放在同一个组件中。CCP 原则是 SRP 原则在组件层面的描述。该原则指导我们组件拆分的粒度。
对大部分应用程序而言，可维护性的重要性远远大于可复用性，由同一个原因引起的代码修改，最好在同一个组件中，如果分散在多个组件中，那么开发、提交、部署的成本都会上升。
8、CRP（共同复用原则）：不要强迫一个组件依赖它不需要的东西。CRP 原则是 ISP原则在组件层面的描述。该原则指导我们组件拆分的粒度。
相信你一定有这种经历，集成了组件 A，但组件 A 依赖了组件 B、C 。即使组件 B、C 你完全用不到，也不得不集成进来。这是因为你只用到了组件 A 的部分能力，组件 A 中额外的能力带来了额外的依赖。如果遵循共同复用原则，你需要把 A 拆分，只保留你要用的部分。
REP、CCP、CRP 三个原则之间存在彼此竞争的关系，REP 和 CCP 是黏合性原则，它们会让组件变得更大，而 CRP 原则是排除性原则，它会让组件变小。遵守REP、CCP 而忽略 CRP，就会依赖了太多没有用到的组件和类，而这些组件或类的变动会导致你自己的组件进行太多不必要的发布；遵守 REP、CRP 而忽略 CCP，因为组件拆分的太细了，一个需求变更可能要改 n 个组件，带来的成本也是巨大的。
指导原则除了上述设计原则，还有一些重要的指导原则如下：

文章插图

1、N+1设计：系统中的每个组件都应做到没有单点故障；
2、回滚设计：确保系统可以向前兼容，在系统升级时应能有办法回滚版本；
3、禁用设计：应该提供控制具体功能是否可用的配置，在系统出现故障时能够快速下线功能；
4、监控设计：在设计阶段就要考虑监控的手段，便于有效的排查问题，比如引入traceId、业务身份 Id 便于排查监控问题；
5、多活数据中心设计：若系统需要极高的高可用，应考虑在多地实施数据中心进行多活，至少在一个机房断电的情况下系统依然可用；
6、采用成熟的技术：刚开发的或开源的技术往往存在很多隐藏的 bug，出了问题没有很好的商业支持可能会是一个灾难；
7、资源隔离设计：应避免单一业务占用全部资源；
8、架构水平扩展设计：系统只有做到能水平扩展，才能有效避免瓶颈问题；
9、非核心则购买的原则：非核心功能若需要占用大量的研发资源才能解决，则考虑购买成熟的产品；
10、使用商用硬件：商用硬件能有效降低硬件故障的机率；
11、快速迭代：系统应该快速开发小功能模块，尽快上线进行验证，早日发现问题大大降低系统交付的风险；
12、无状态设计：服务接口应该做成无状态的，当前接口的访问不依赖于接口上次访问的状态。
架构师知道了职责，具备很好的架构思维，掌握了通用的架构框架和方法论，使用架构原则进行架构设计，不同的业务和系统要求不一样，那么有没有针对不同场景的系统架构设计？下文就针对分布式架构演进、单元化架构、面向服务 SOA 架构、微服务架构、Serverless 架构进行介绍，以便于我们在实际运用中进行参考使用。
具备架构师的思维架构师职责明确了，那么有什么架构思维可以指导架构设计呢？请看下述的架构思维。
1、自顶向下构建架构