设计可扩展架构

架构设计复杂度模型

【业务复杂度】

业务固有的复杂度，主要体现为难以理解、难以扩展，例如业务数量多（微信）、业务流程长（支付宝）、业务之间关系复杂（例如 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. 任务分解器需要监控业务服务器的状态，在故障时进行切换。

计算高可用任务分解架构设计关键点

存储高可用

存储高可用复杂度模型

存储高可用 - - 数据复制格式

思维导图

提升架构设计的质量

低成本

低成本复杂度本质

低成本手段和应用

安全性

安全性复杂度本质

架构安全

业务安全

可测试性/可维护性/可观测性

定义

可测试性

软件系统在测试环境下能否方便的支持测试各种场景的能力。

可维护性

软件系统支持定位问题、修复问题的能力。

可观测性

软件系统对外展现内部状态的能力。

可测试性

可维护性

可观测性

设计更好的架构

思维导图