设计可扩展架构
架构设计复杂度模型
【业务复杂度】
业务固有的复杂度，主要体现为难以理解、难以扩展，例如业务数量多（微信）、业务流程长（支付宝）、业务之间关系复杂（例如 ERP）。
【质量复杂度】
高性能、高可用、成本、安全等质量属性的要求。
业务复杂度和质量复杂度是正交的。
架构复杂度应对之道
架构设计环
可扩展复杂度模型
可扩展定义
可扩展 extensibility：系统适应变化的能力，包含可理解和可复用两个部分。
可伸缩 scalability：系统通过添加更多资源来提升性能的能力。
可扩展架构设计 - 拆分
拆分复杂度模型
拆分粒度 - - 两个复杂度
内部复杂度
又称为“单体复杂度”，指单个对象内部的复杂度，例如传统的单体系统，所以业务都在一个系统里面。
可以用参与的开发人数来衡量单个拆分对象的复杂度。
例如：3 个人负责一个子系统/子模块是比较合理的，20 个人来在同一个子系统上开发，则内部复杂度过高。
外部复杂度
又称为“群体复杂度”，指拆分后的多个对象之间的关系复杂度。
可以用业务流程涉及对象数量来衡量外部复杂度。
例如：一次用户请求需要 5 个子系统参与是比较合理的，如果需要 20 个子系统参与，则外部复杂度过高。
拆分粒度 - -平衡的艺术
拆分第一原则：内外平衡原则
内部复杂度和外部复杂度是天平的两端，一方降低，另一方必然升高，关键在于平衡。
拆分第二原则：先粗后细原则
如果你把握不准，那么就先拆少一些，后面发现有问题再继续拆分。
可扩展架构设计 - 封装
封装复杂度模型
预测的艺术
预测第一原则：2 年原则
只预测 2 年内的可能变化，不要试图预测 10 年后的变化
例如：你准备接入微信支付，那么预测接入支付宝是很自然的，但数字钱包就没那么必要了、
预测第二原则：3 次法则
预测没有把握就不要封装，等到需要的时候重构即可
例如：要不要支持数据库为 Oracle、MySQL、PostgreSQL？
封装的技巧
思维导图
设计高性能架构
高性能复杂度模型
单机高性能复杂度分析
集群高性能设计
集群高性能 - -任务分配
【任务分配】
将任务分配给多个服务器执行。
【复杂度分析】
1）增加“任务分配器”节点，可以是独立的服务器，也可以是 SDK。
2）任务分配器需要管理所有的服务器，可以通过配置文件，也可以通过配置服务器（例如 ZooKeeper）。
3）任务分配器需要根据不同的需求采用不同的算法分配。
任务分配器集群
集群高性能任务分配架构设计关键点
集群高性能 - -任务分解
【任务分解】
将服务器拆分为不同角色，不同服务器处理不同的业务。
【复杂度分析】
1. 增加“任务分解器”节点，可以是独立的服务器，也可以是 SDK。
2. 任务分解器需要管理所有的服务器，可以通过配置文件，也可以通过配置服务器（例如 ZooKeeper）。
3. 需要设计任务拆分的方式，任务分解器需要记录“任务”和“服务器”的映射关系。
4. 任务分解器需要根据不同的需求采用不同的算法分配。
集群高性能任务分解架构设计关键点
思维导图
设计高可用架构
高可用复杂度模型
计算高可用
计算高可用 - - 任务分配
【任务分配】
将任务分配给多个服务器执行。
【复杂度分析】
1. 增加“任务分配器”节点，可以是独立的服务器，也可以是 SDK。
2. 任务分配器需要管理所有的服务器，可以通过配置文件，也可以通过配置服务器（例如 ZooKeeper）。
3. 任务分配器需要根据不同的需求采用不同的算法分配。
4. 任务分配器需要监控业务服务器的状态，在故障时进行切换。
计算高可用任务分配架构设计关键点
计算高可用 - - 任务分解
【任务分解】
将服务器拆分为不同角色，不同服务器处理不同的业务。
【复杂度分析】
1. 增加“任务分解器”节点，可以是独立的服务器，也可以是 SDK。
2. 任务分解器需要管理所有的服务器，可以通过配置文件，也可以通过配置服务器（例如 ZooKeeper）。
3. 需要设计任务拆分的方式，任务分解器需要记录“任务”和“服务器”的映射关系。
4. 任务分配器需要根据不同的需求采用不同的算法分配。
5. 任务分解器需要监控业务服务器的状态，在故障时进行切换。
计算高可用任务分解架构设计关键点
存储高可用
存储高可用复杂度模型
存储高可用 - - 数据复制格式
思维导图
提升架构设计的质量
低成本
低成本复杂度本质
低成本手段和应用
安全性
安全性复杂度本质
架构安全
业务安全
可测试性/可维护性/可观测性
定义
可测试性
软件系统在测试环境下能否方便的支持测试各种场景的能力。
可维护性
软件系统支持定位问题、修复问题的能力。
可观测性
软件系统对外展现内部状态的能力。
可测试性
可维护性
可观测性
设计更好的架构
思维导图
