高性能
可扩展性
只预测 2 年内的可能变化，不要试图预测 5 年甚至 10 年后的变化。
方案一：提炼出“变化层”和“稳定层”
第一种应对变化的常见方案是：将不变的部分封装在一个独立的“稳定层”，将“变化”封装在一个“变化层”（也叫“适配层”）。这种方案的核心思想是通过变化层来隔离变化。
方案二：提炼出“抽象层”和“实现层”
第二种常见的应对变化的方案是：提炼出一个“抽象层”和一个“实现层”。如果说方案一的核心思想是通过变化层来隔离变化，那么方案二的核心思想就是通过实现层来封装变化。方案二典型的实践就是设计模式和规则引擎。
1 写 2 抄 3 重构原则
一开始就考虑复杂的可扩展性应对方法，而是等到第三次遇到类似的实现的时候再来重构，重构的时候采取隔离或者封装的方案。
举个最简单的例子，假设你们的创新业务要对接第三方钱包，按照这个原则，就可以这样做：
- 1 写：最开始你们选择了微信钱包对接，此时不需要考虑太多可扩展性，直接快速对照微信支付的 API 对接即可，因为业务是否能做起来还不确定。
- 2 抄：后来你们发现业务发展不错，决定要接入支付宝，此时还是可以不考虑可扩展，直接把原来微信支付接入的代码拷贝过来，然后对照支付宝的 API，快速修改上线。
- 3 重构：因为业务发展不错，为了方便更多用户，你们决定接入银联云闪付，此时就需要考虑重构，参考设计模式的模板方法和策略模式将支付对接的功能进行封装。
高可用
系统无中断地执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一。这个定义的关键在于“无中断”，但恰好难点也在“无中断”上面。
高性能增加机器目的在于“扩展”处理性能；高可用增加机器目的在于“冗余”处理单元。
计算高可用复杂度
- 多机处理时，需要增加一个任务分配器。进而需要考虑性能、成本、可维护性、可用性等各方面因素。
- 任务分配器与计算机器之间需要连接和交互。合适的连接方式、连接管理(连接建立、连接检测、连接中断后处理)。
- 分配算法。常见的双机算法有主备、主主，主备方案又可以细分为冷备、温备、热备。
存储高可用复杂度
数据不一致的问题。高可用-存储架构 TODO
高可用状态决策
判断任一服务器是否正常：独裁式、协商式、民主式。
成本
低成本给架构设计带来的主要复杂度体现在，往往只有“新技术”或“自创技术”才能达到低成本目标。
安全
- 功能安全，预防常见的安全漏洞和风险(常见的 XSS 攻击、CSRF 攻击、SQL 注入等)。
- 架构安全，防止搞破坏。
- 传统的架构安全主要依靠防火墙，防火墙最基本的功能就是隔离网络，通过将网络划分成不同的区域，制定出不同区域之间的访问控制策略来控制不同信任程度区域间传送的数据流。
- 互联网 QPS 太高了，防火墙太贵了。另一方面，DDoS 攻击最大的影响是大量消耗机房的出口总带宽。不管防火墙处理能力有多强，当出口带宽被耗尽时，整个业务在用户看来就是不可用的，因为用户的正常请求已经无法到达系统了。互联网系统的架构安全目前并没有太好的设计手段来实现，更多地是依靠运营商或者云服务商强大的带宽和流量清洗的能力，较少自己来设计和实现。
规模
- 功能越来越多，导致交互或联系过于繁杂。比如 2 个系统交互变成 10 个系统交互。
- 数据越来阅读，系统复杂度升级。比如 500 万行数据变成 5 亿行数据。