阿里技术大牛：一份架构师成神路线图( 六 ) _架构师

⑥REP(复用、发布等同原则)：软件复用的最小粒度应等同于其发布的最小粒度。
直白地说，就是要复用一段代码就把它抽成组件，该原则指导我们组件拆分的粒度。
⑦CCP(共同闭包原则)：为了相同目的而同时修改的类，应该放在同一个组件中。
CCP 原则是 SRP 原则在组件层面的描述。该原则指导我们组件拆分的粒度。
对大部分应用程序而言，可维护性的重要性远远大于可复用性，由同一个原因引起的代码修改，最好在同一个组件中，如果分散在多个组件中，那么开发、提交、部署的成本都会上升。
⑧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 个组件，带来的成本也是巨大的。

文章插图

除了上述设计原则，还有一些重要的指导原则如下：

N+1 设计：系统中的每个组件都应做到没有单点故障。
回滚设计：确保系统可以向前兼容，在系统升级时应能有办法回滚版本。
禁用设计：应该提供控制具体功能是否可用的配置，在系统出现故障时能够快速下线功能。
监控设计：在设计阶段就要考虑监控的手段，便于有效的排查问题，比如引入 traceId、业务身份 Id 便于排查监控问题。
多活数据中心设计：若系统需要极高的高可用，应考虑在多地实施数据中心进行多活，至少在一个机房断电的情况下系统依然可用。
采用成熟的技术：刚开发的或开源的技术往往存在很多隐藏的 Bug ，出了问题没有很好的商业支持可能会是一个灾难。
资源隔离设计：应避免单一业务占用全部资源。
架构水平扩展设计：系统只有做到能水平扩展，才能有效避免瓶颈问题。
非核心则购买的原则：非核心功能若需要占用大量的研发资源才能解决，则考虑购买成熟的产品。
使用商用硬件：商用硬件能有效降低硬件故障的机率。
快速迭代：系统应该快速开发小功能模块，尽快上线进行验证，早日发现问题大大降低系统交付的风险。
无状态设计：服务接口应该做成无状态的，当前接口的访问不依赖于接口上次访问的状态。

架构师知道了职责，具备很好的架构思维，掌握了通用的架构框架和方法论，使用架构原则进行架构设计，不同的业务和系统要求不一样，那么有没有针对不同场景的系统架构设计?
下文就针对分布式架构演进、单元化架构、面向服务 SOA 架构、微服务架构、Serverless 架构进行介绍，以便于我们在实际运用中进行参考使用。
常见架构
分布式架构演进
①初始阶段架构