分布式系统架构设计原则和理论 --AKF 架构原则
这 15 个架构原则来自《架构即未来 (The Art of Scalability)》[附录 2] 一书，作者马丁 L. 阿伯特和迈克尔 T. 费舍尔分别是 eBay 和 PayPal 的前 CTO，他们经历过 eBay 和 PayPal 大规模分布式电商平台的架构演进，在一线实战经验的基础上总结并提炼出 15 条架构原则：
1.N + 1
集群化部署，设计永远不要少于两个，通常为三个。比方说无状态的 Web/API 一般部署至少>=2 个。
2. 回滚设计
版本发布失败，保证可回滚是至关重要的，确保系统可以回滚到以前发布过的任何版本。可以通过发布系统保留历史版本，或者代码中引入动态开关切换机制 (Feature Switch)。
3. 开关设计
能够关闭任何发布的功能。新功能隐藏在动态开关机制 (Feature Switch) 后面，可以按需一键打开，如发现问题随时关闭禁用。
4. 监控设计
在设计阶段就必须考虑监控，而不是在实施完毕之后补充。例如在需求阶段就要考虑关键指标监控项，这就是度量驱动开发 (Metrics Driven Development) 的理念。
5. 使用成熟的技术
只用确实好用的技术。商业组织毕竟不是研究机构，技术要落地实用，成熟的技术一般坑都被踩平了，新技术在完全成熟前一般需要踩坑躺坑，这里包含：小到成熟功能函数，大到开源或商业的组件、中间件。
6. 异步设计
能异步尽量用异步，只有当绝对必要或者无法异步时，才使用同步调用。
7. 无状态系统
尽可能无状态，只有当业务确实需要，才使用状态。无状态系统易于扩展，有状态系统不易扩展且状态复杂时更易出错。
8. 水平扩展而非垂直升级
永远不要依赖更大、更快的硬件设备构建核心业务系统。一般公司成长到一定阶段普遍经历过买更大、更快机器硬件的阶段，即使淘宝当年也买小型机扛流量，后来扛不住才体会这样做不 scalable，所以才有后来的去 IOE 行动。
9. 前瞻性设计
设计时至少要有两步前瞻性，在扩展性问题发生前考虑好下一步的行动计划。架构师的价值就体现在这里，架构设计对于流量的增长要有提前量。我们一般设计出能支撑短期目标20倍容量的目标系统架构，实现支撑5倍以上容量的架构方案开发，部署2倍容量的系统。
10. 非核心则购买
如果不是你最擅长，也提供不了差异化的竞争优势则直接购买。避免 Not Invented Here 症状，避免凡事都要重造轮子，毕竟达成业务目标才是重点。
11. 使用商品化硬件
在大多数情况下，便宜的就是最好的。这点和第 9 点是一致的，通过商品化硬件水平扩展，而不是买更大、更快的系统。
12. 小构建、小发布和快速试错
全部研发要小构建，不断迭代，让系统不断成长。这个和微服务理念一致。
13. 隔离故障
实现故障隔离设计，通过断路保护避免故障传播和交叉影响。
故障隔离包括：1.基础组件内的节点屏蔽；2.单个系统单个服务降级、流控；3.全局流控降级；4.系统单元化：通过舱壁泳道等机制隔离失败单元 (Failure Unit)，一个单元的失败不至影响其它单元的正常工作；
14. 自动化
设计和构建自动化的过程。如果机器可以做，就不要依赖于人。自动化是 DevOps 的基础。目前大一些的互联网公司通过自动构建和发布平台来支撑版本构建和发布，大大提升效率及可靠性。
15. 多活设计
当一个重要的交易系统发展到一定程度，多数据中心或多活站点设计就被提上日程，不要被一个数据中心的解决方案把自己限制住。当然也要考虑成本和公司规模发展阶段。