架构设计原则

软件设计原则

GRASP 通用职责分配软件模式

信息专家

为对象分配职责的通用原则 – 把职责分配给拥有足够信息可以履行职责的专家

多态

将职责分配给多个具有同名方法的多态子类，运行时根据需要动态切换子类，让系统行为变得可插拔

纯虚构

针对真实问题域中不存在，但是设计建模中有用的概念，设计虚构类并赋予职责。

间接

在两个或者多个对象间有交互的情况下，为避免直接耦合，提高重用性，创建中间类并赋予职责，对象的交互交由中间类协调。

受保护的变化

简单讲就是封装变化。识别系统中可能的不稳定或者变化，在不稳定组件上创建稳定的抽象接口，将可能的变化封装在接口之后，使得系统内部的不稳定或者变化不会对系统的其它部分产生不良影响

SOLID面向对象设计原则

S (The Single Responsibility Principle)

单一职责原则

O (The Open Closed Principle)

开放封闭原则，对扩展开放，对修改封闭。一般不要直接修改类库源码（即使你有源代码），通过继承等方式扩展。

L (The Liskov Substitution Principle)

里氏替代原则，当一个子类的实例能够被替换成任何超类的实例时，它们之间才是真正的 is-a 关系。

I (The Interface Segregation Principle)

接口分离原则，使用多个专门的接口比使用单一的大而全接口要好。

D (The Dependency Inversion Principle)

依赖倒置原则，高层模块不应该依赖于底层模块，二者都应该依赖于抽象。换句话说，依赖于抽象，不要依赖于具体实现。

分布式系统架构设计原则和理论

AKF 架构原则

N + 1 设计

永远不要少于两个，通常为三个。比方说无状态的 Web/API 一般部署至少>=2 个。

异步设计

能异步尽量用异步，只有当绝对必要或者无法异步时，才使用同步调用。

水平扩展而非垂直升级

永远不要依赖更大、更快的系统。一般公司成长到一定阶段普遍经历过买更大、更快系统的阶段，即使淘宝当年也买小型机扛流量，后来扛不住才体会这样做不 scalable

设计时至少要有两步前瞻性

在扩展性问题发生前考虑好下一步的行动计划。架构师的价值就体现在这里，架构设计对于流量的增长要有提前量。

隔离故障

实现故障隔离设计，通过断路保护避免故障传播和交叉影响。通过舱壁泳道等机制隔离失败单元 (Failure Unit)，一个单元的失败不至影响其它单元的正常工作。

CAP原理

一致性

Consistency

可用性

Availability

分区容忍性

Partition tolerance

关系型数据库 单节点 保证了数据强一致性（C）和可用性（A），但是却无法保证分区容错性（P）。
然而在分布式系统下，为了保证模块的分区容错性（P），只能在数据强一致性（C）和可用性（A）之间做平衡。具体表现为在一定时间内，可能模块之间数据是不一致的，但是通过自动或手动补偿后能够达到最终的一致。

BASE原理

基本可用

Basically Available，基本可用是指分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。比如服务降级。

软状态

Soft State，允许不同节点间副本同步的延迟就是软状态的体现

最终一致性

Eventual Consistency，系统中的所有数据副本经过一段时间后，最终能够达成一致状态

组织和系统改进原则

康威法则

如果系统架构不支持，你无法建立一个高效的组织；同样，如果你的组织架构不支持，你也无法建立一个高效的系统架构。

系统改进三原则

系统思考

也就是短板原理，最薄弱的地方，是整个产品交付的关键

强化反馈环

通过反馈，改进系统。包括企业和客户之间、组织团队间、流程上和系统内的反馈环。
反馈要基于测量，也就是要有度量值。

持续试验和学习的文化

在企业管理文化层面强调勇于试错和持续试验、学习和改进的文化。