第 12 章 确立架构原则
孙子说： 故其战胜不忒，不忒者，其所措必胜，胜已败者也
他们进行战争的胜利不会有差错，之所以不会出现差错，是因为他们作战的措施建立在必胜的基础上，是战胜了在气势上已失败的敌人
12.1 目标和原则
原则应该广泛的支持未来和当前的目标。
好的架构原则：
- 具体的：原则不应该被混淆在他的措辞中
- 可度量的：原则不应该包含 无限 这样的词汇
- 可达到的：尽管原则应该时鼓舞人心的，他们应该能够在设计和执行上实现
- 现实的：团队应该有能力达成目标，有些原则时可以实现的，但是需要时间或天赋
- 可测试的：修改后的原则可以用于测试设计，以验证它是否符合需要
12.2 架构选择
12.3 AFK 采用的最普遍的架构原则
12.3.1 N+1 设计
确保任何你所开发的系统在发生故障时，至少有一个冗余的实例。
永远不少于两个，通常为三个
12.3.2 回滚设计
确保向后兼容。确保系统可以回滚到以前发布过的任何版本。
12.3.3 禁用设计
与其他系统或服务通信的高风险系统时，确保这些系统能够通过开关来禁用
能够关闭任何发布的功能
12.3.4 监控设计
监控做的好，不仅能发现服务的死活，检查日志文件，还能收集系统相关的数据，评估终端用户的响应时间。如果系统和应用在设计和构建时就考虑好监控，那么即使不能自我修复，也至少可以自我诊断。
在设计阶段就必须要考虑监控，而不是在实施完成后补充
12.3.5 设计多活数据中心
必须拥有多个数据中心，在设计数据中心的时候，考虑数据中心运维策略
不要被一个数据中心的解决方案把自己限制住
12.3.6 使用成熟的技术
降低开发成本，提高开发效率，提高可扩展能力，减少终端用户的响应时间。考略新技术故障问题
只用确实好用的技术
12.3.7 异步设计
只有在绝对必要的时候才进行同步调用
12.3.8 无状态系统
只要有可能，就要避免开发需要状态的产品，在必要的情况下，可以考虑存储在用户端，而不时在系统里。如果这是不可能的，考虑一个几种的状态缓存机制避免把状态数据分散存储在多个服务器上。
只有当业务确实需要的时候，才使用状态
12.3.9 水平扩展非垂直升级
永远不要依赖更大，更快的系统
12.3.10 设计至少要有两个步骤的前瞻性
在扩张性问题发生前考虑好下一步的行动计划
12.3.11 非核心则购买
如果不是你擅长的，也提供不了差异化的竞争优势则直接购买
12.3.12 使用商品化硬件
在大多数情况下，便宜的是最好的
12.3.13 小构建，小发布，快试错
全部研发要小构建，不断迭代，让系统不断地成长
12.3.14 隔离故障
故障隔离的原则类似于建立一个有断路器的电器系统，细分产品，服务，或子服务，确保服务或者子服务的故障不会影响其他的服务
实现故障隔离设计，通过断路保护避免故障传播和交叉影响
12.3.15 自动化
人常犯错误，更令人沮丧的是，他们往往会以不同的方式多次犯同样的错误。
所有系统都应该在开始设计的阶段就要考虑自动化。自动部署，构建，测试，监控甚至报警
设计和构建自动化的过程。如果机器可以做，就不要依赖于人
结论关键点
- 根据公司的目标制定架构原则，应该和公司的发展愿景和使命相符
- 原则应该足够宽泛，避免不断的修改，应该符合SMART要求
- 确保团队在制定和修改原则的过程中遵循RASCI
