分布式系统/高并发系统设计原则
DID 原则 : Design - Implement - Deploy
- 设计（Design）20倍的容量。
- 实现（Implement）3倍的容量。
- 部署（Deploy）1.5倍的容量。
确保一定时间内，不会因为业务体量的变化出现对架构较大的升级调整。但尽快如此，也不能过度咯。
1、换个思路理解 DID 在软件建构领域，有一个原则叫DID, 通常用来保证资源和时间的最小化。
DID:
- 设计（Design）20倍的容量。
- 实现（Implement）3倍的容量。
- 部署（Deploy）1.5倍的容量。
这个DID一般是从资源成本的更小消耗来出发，希望将更低成本的设计发挥更大的作用，对更高成本的部署更谨慎的使用。
换个思路，在需求开发与系统设计层面出发，也应该遵循这种规律，即在前期设计层面下足功夫，用更周到的设计来实现 方案，以便在部署上线后的改动最小。
但是，往往在实际开发中这个过程都是本末倒置的，从 ‘拍脑袋就做’ 到 ‘开发中发现行不通’ 到 ‘返工’，或者更严重的上线 之后才发现问题，导致更大的返工成本。
2、过度设计 通常意义的过度设计包含两方面：
超出了需求的本意，比如我要一个一公里的代步工具你给我设计了一架飞机。 导致系统过度复杂。 我认为，还有一种也应该称之为过度设计，即设计出了合理的但是没人感兴趣的产品。比如所有人都买了一款可用但是有瑕疵的手机v1， 不到一个月，一款同款产品v2出现，虽然更完美，价格更低，但是基于成本没人会买单。
但是v2一定是推广不了的吗？也不一定，怎么推广？顺势而为。比如运营商推出5G, 只有v2支持，这叫顺势而为；国家规定，只有支持5G的手机才能使用，这也叫顺势而为。晚上做班车下班，遇到一个之前的领导，他说为什么当时order-platform可以推广，那是因为借着海外的大势…
3、精简精简在精简，拆分拆分在拆分。 这个，和过度设计想对应。和成就感相挂钩。
帕累托法则：80%的成果源于20%的时间。如果时间有限，那么尽量把时间放在容易产生成果的事情上，有成果便有产出，才有成就感。
ref: https://younghz.github.io/DID#id-1-%E6%8D%A2%E4%B8%AA%E6%80%9D%E8%B7%AF%E7%90%86%E8%A7%A3-did
KISS 原则 : Keep it Simple and Stupid
单个接口简单易用，把一个事情搞复杂是把一件简单的事，但把一个复杂的事简单化，确实一件复杂的事。
DIP 原则 ： Dependence Inversion Principle
根据接口业务场景分包、分类，可分为基础服务、公共服务、业务实现。
业务接口»公共服务»基础服务（约定俗成）
CAP 原则
- **
C**onsistency : 一致性 - **
A**vailability ： 可用性 - **
P**artition tolerance ： 分区容错性
三者不可兼得，系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之前做选择。也就是只有满足CA或满足CP。
在CAP基础上衍生了BASE原则。BASE 是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency），核心思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性。
基本可用（Basically Available）
分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。 这里的关键词是“部分”和“核心”，具体选择哪些作为可以损失的业务，哪些是必须保证的业务，是一项有挑战的工作。例如，对于一个用户管理系统来说，“登录”是核心功能，而“注册”可以算作非核心功能。因为未注册的用户本来就还没有使用系统的业务，注册不了最多就是流失一部分用户，而且这部分用户数量较少。如果用户已经注册但无法登录，那就意味用户无法使用系统。例如，充了钱的游戏不能玩了、云存储不能用了……这些会对用户造成较大损失，而且登录用户数量远远大于新注册用户，影响范围更大。
软状态（Soft State）
允许系统存在中间状态，而该中间状态不会影响系统整体可用性。这里的中间状态就是 CAP 理论中的数据不一致。
最终一致性（Eventual Consistency）
系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。
ref：https://mp.weixin.qq.com/s/YVhPawEyWuWMUeNBwTuPoQ
SMART 原则
- **
S**pecific : 明确性 - **
M**easurable : 衡量性 - **
A**ttainable : 可实现性 - **
R**elevant : 相关性 - **
T**ime-based : 时限性
TODO ： 待进一步完善