KISS设计原则：（Keep It Simple,Stupid）

• 首选简单的代码和体系结构。

• 避免复杂的抽象。

• 避免使用魔术代码和奇特的算法。

• 避免大的外部依赖性。

• 减少分布式系统中活动部件的数量。

• 避免自动决策，这可能会损害群集的可用性，一致性或性能。

附：另外，还有 KISS编码原则，参见：https://www.cnblogs.com/yutiansanshou/archive/2012/12/05/2802653.html

YAGNI原则 （You Ain’t Gonna Need It）——适可而止、避免过度设计

在一个软件项目中，往往80%的时间花费在20%的功能上。

当你准备列出一个项目清单时，试着考虑以下问题：

• 通过降低抽象的层级，来实现低复杂度

• 将功能和特性区分开

• 适度接受非功能性需求

• 识别耗时的任务，并摆脱它们

功能与特性的区别是什么？

    功能可以理解为：有哪些“核心能力”，可以满足核心需求。而特色是“细节上和用户体验上的功能”，满足的是非核心需求。

什么是非功能性需求？

非功能性的需求并不会描述软件行为，它们只会描述一些可以用来判别软件质量的附加属性。例如性能、稳定性、可扩展性、可维护性等。

DRY原则 - Don't Repeat Yourself（避免重复）

顾名思义，无需解释。

三大原则之间的区别与联系：

• DRY将项目切分成可控的组件来降低复杂度，而YAGNI是通过减少组件个数来降低复杂度。

• YAGNI很像KISS原则，因为它也是致力于构建简单的方案。然而，KISS是通过尽可能容易的完成某件事情来实现精简方案；但YAGNI是通过根本就不实现它来达到精简。

AKF拆分原则（横向、纵向扩展与拆分）

    AKF，单词来源于化学领域的矿物质AKF图解（AKF diagram），其中A代表氧化铝，K代表氧化钾，F代表氧化亚铁。但这里是引申意义，理解为可扩展立方体，这个立方体中沿着三个坐标轴设置分别为：X、Y、Z。

    X轴扩展即传统的（横向扩展，增加实例，水平复制、克隆），通过绝对平等地复制服务与数据，以解决容量和可用性的问题。其实就是将微服务运行多个实例，做集群加负载均衡的模式。

    Y轴扩展会将庞大的整体应用拆分为多个服务（纵向扩展，拆分功能、服务）。每个服务实现一组相关的功能，如订单管理、客户管理等。在工程上常见的方案是 服务化架构(SOA) 。比如对于一个电子商务平台，我们可以拆分成不同的服务。

    Z轴扩展通常是指基于请求者或用户独特的需求，进行系统划分，并使得划分出来的子系统是相互隔离但又是完整的。以生产汽车的工厂来举例：福特公司为了发展在中国的业务，或者利用中国的廉价劳动力，在中国建立一个完整的子工厂，与美国工厂一样，负责完整的汽车生产。这就是一种 Z 轴扩展。

    Z轴和X轴扩展的区别在于，X轴是单纯资源的复制、克隆，而Z轴扩展是基于数据的划分。以数据库的扩展为例，X轴是单纯增加数据库节点，Y轴是做读写分离，Z轴是分库分表。

《The Art of Scalability——架构即未来》书中提到的15个架构原则

总结如下：

1、N+1设计：系统中的每个组件都应做到没有单点故障。

2、回滚设计：确保系统可以向前兼容，在系统升级时应能有办法回滚到以前发布过的任何版本；

可以通过发布系统保留历史版本，或者代码中引入动态开关切换机制 (Feature Switch)。

3、开关设计/禁用设计

能够关闭任何发布的功能。新功能隐藏在动态开关机制 (Feature Switch) 后面，可以按需一键打开，如发现问题随时关闭禁用。

4、监控设计：在设计阶段就要考虑监控的手段，而不是在实施完毕之后补充。

例如在需求阶段就要考虑关键指标监控项，这就是度量驱动开发 (Metrics Driven Development) 的理念。

5、使用成熟的技术：刚开发或开源的技术往往存在很多隐藏的bug，出了问题没有商业支持可能会是一个灾难；

尽量选择成熟好用的技术。商业组织毕竟不是研究机构，技术要落地实用，成熟的技术一般坑都被踩平了，新技术在完全成熟前一般需要踩坑躺坑，这里包含：小到成熟功能函数，大到开源或商业的组件、中间件。

6、前瞻性设计：设计时至少要有两步前瞻性，在扩展性问题发生前考虑好下一步的行动计划；

架构师的价值就体现在这里，架构设计对于流量的增长要有提前量。我们一般设计出能支撑短期目标20倍容量的目标系统架构，实现支撑5倍以上容量的架构方案开发，部署2倍容量的系统。

7、非核心则购买：非核心功能若需要占用大量的研发资源才能解决，则考虑购买成熟的产品；

如果不是你最擅长，也提供不了差异化的竞争优势则直接购买。避免凡事都要重造轮子（Not Invented Here），毕竟达成业务目标才是重点。

8、使用商品化硬件：商用硬件能有效降低硬件故障的机率；

9、架构应能水平扩展：系统只有做到能水平扩展，才能有效避免瓶颈问题；

做到水平扩展而非垂直升级，永远不要依赖更大、更快的硬件设备构建核心业务系统。

10-1、资源隔离设计：应避免单一业务占用全部资源；

10-2、隔离故障设计：实现故障隔离设计，通过断路保护避免故障传播和交叉影响。

故障隔离包括：1.基础组件内的节点屏蔽；2.单个系统单个服务降级、流控；3.全局流控降级；4.系统单元化：通过舱壁泳道等机制隔离失败单元 (Failure Unit)，一个单元的失败不至影响其它单元的正常工作；

11、无状态设计：服务接口应该做成无状态的，当前接口的访问不依赖于接口上次访问的状态。

无状态系统易于扩展，有状态系统不易扩展且状态复杂时更易出错。

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

13、快速迭代：小构建、小发布和快速试错

系统应该快速开发小功能模块，尽快上线进行验证，早日发现问题大大降低系统交付的风险；

14、自动化：如果机器可以做，就不要依赖于人。

机械化任务通过自动化工具处理，可以大大提升效率及可靠性。

15、多活数据中心设计：不要被一个数据中心的解决方案把自己限制住；

若系统需要极高的高可用，且成本和公司规模发展阶段允许，应考虑到在多地实施数据中心进行系统多活，至少在一个机房不可用的情况下系统依然可用、数据不丢失。