笔记
今天先来看架构设计流程第 1 步：识别复杂度。
只有正确分析出了系统的复杂性，后续的架构设计方案才不会偏离方向。
架构的复杂度主要来源于“高性能”“高可用”“可扩展”等几个方面，但架构师在具体判断复杂性的时候，不能生搬硬套，认为任何时候架构都必须同时满足这三方面的要求。实际上大部分场景下，复杂度只是其中的某一个，少数情况下包含其中两个，如果真的出现同时需要解决三个或者三个以上的复杂度，要么说明这个系统之前设计的有问题，要么可能就是架构师的判断出现了失误，即使真的认为要同时满足这三方面的要求，也必须要进行优先级排序。
一个个来解决问题，不要幻想一次架构重构解决所有问题。正确的做法是将主要的复杂度问题列出来，然后根据业务、技术、团队等综合情况进行排序，优先解决当前面临的最主要的复杂度问题。
对于同一个复杂度问题，软件系统的方案可以有多个，总是可以挑出综合来看性价比最高的方案。
有经验的架构师可能一看需求就知道复杂度大概在哪里；如果经验不足，那只能采取“排查法”，从不同的角度逐一进行分析。
对于架构师来说，关注的不是一天的数据，而是 1 秒的数据，即 TPS 和 QPS。
系统设计需要考虑一定的性能余量。由于现在的基数较低，为了预留一定的系统容量应对后续业务的发展。注意，这里的设计目标设定为峰值的 4 倍是根据业务发展速度来预估的，不是固定为 4 倍，不同的业务可以是 2 倍，也可以是 8 倍，但一般不要设定在 10 倍以上，更不要一上来就按照 100 倍预估。
理解与思考
高性能、高可用和可扩展，这几项指标，只能兼顾，不能求全。可以面面俱到，但要做到样样优秀就有点过于理想化和脱离实际了，需要审视方法的可落地性了。
使用排查法，依次从高性能、高可用、可扩展、安全、低成本及其他几个方面考察系统的复杂度来源。
课后思考题
尝试用排查法分析一下你参与过或者研究过的系统的复杂度，然后与你以前的理解对比一下，看看是否有什么新发现？
当前参与的项目的复杂度分析：
- 高性能。需要处理极多的网元日志数据，时间和资源限制较严格。所以需要高性能的数据处理和分析能力。
- 高可用。只要在规定的时间内跑出数据即可，中间任务失败了可以重跑。
- 可扩展。要求不高。一般都是算法变更和新业务的开发。
