架构设计复杂度模型：

架构设计复杂度模型：

• 业务复杂度：主要体现为“难以理解”、“难以扩展”例如：业务数量多、业务流程长、业务之间关系复杂

• 质量复杂度：高性能、高可用、成本、安全等质量属性的要求。

如何设计可扩展架构

鸡蛋篮子第一法则：如果一个篮子数不清，拆分到多个篮子再数

可扩展：

系统适应变化的能力，包含 “可理解”与“可复用”两个部分

可伸缩：

系统通过添加更多资源来提升 性能的能力

拆分复杂度模型：

• 拆分粒度：

• 内部复杂度： 又称为 “单体复杂度”，指单个对象内部的复杂度，例如传统的单体系统，所有业务都在一个系统里面。可以用 参与的“开发人数”来衡量单个拆分对象的复杂度

• 例如：3 个人负责一个 子系统/子模块 是比较合理的，20 个人在同一个子系统上开发，则内部复杂度过高。

• 外部复杂度：又称为“群体复杂度”，指拆分后的多个对象之间的关系复杂度。可以用业务流程“涉及到对象数量”来衡量外部复杂度。

• 例如：一次用户请求 需要 5 个子系统参与是比较合理的，如果需要 20 个子系统参与，则外部复杂度过高。

• 拆分原则：

• 内外平衡

• 先粗后细原则

可扩展性设计：封装

• 预测第一原则：2 年原则，只预测 2 年内可能的变化

• 预测第二原则：3 次法则，预测没有把握的不要封装，等到需要的时候“重构”即可

高性能复杂度模型：

鸡蛋篮子理论第二法则（叠加法则）：如果一个篮子装不下你的鸡蛋，用多个篮子

集群高性能：任务分配

• 任务分配：将任务分配给多个服务器执行

• 复杂度分析：

• 增加“任务分配器”节点，可以是独立的服务器，也可以是 SDK

• 任务分配器 需要管理所有的服务器，可以通过配置文件也可以通过配置服务器（例如：ZooKeeper）

• 任务分配器需要根据不同的需求采用不同的算法分配。

集群高性能任务分配架构设计关键点：

集群高性能：任务分解

• 任务分解：将服务器拆分为不同的角色，不同的服务器处理不同的业务。

• 复杂度分析：

• 增加“任务分解器”节点，可以是独立的服务器，也可以是 SDK

• 任务分解器要管理所有的服务器，可以通过配置文件，也可以通过配置服务器（例如 ZooKeeper）

• 需要设计任务拆分方式，任务分解器需要记录“任务”和“服务器”的映射关系

• 任务分解器需要根据不同的需求采用不同的算法分配。

集群高性能任务分解架构设计关键点

高可用复杂度模型

鸡蛋篮子理论第三法则（冗余法则）：不要把所有鸡蛋装在一个篮子，放到多个篮子！

计算高可用

• 任务分配：

• 将任务分配给多个服务器执行

• 复杂度分析：

• 增加“任务分配器”节点，可以是独立的服务器，也可以是 sdk

• 任务分配器需要管理所有的服务器，可以通过配置文件，也可以通过配置服务器（例如 ZooKeeper）。

• 任务分配器需要根究不同的需求采用不同的算法分配。

• 任务分配器需要监控业务服务器的状态，在故障时进行切换。

• 高性能任务分配考虑的是“正常处理”

• 高可用任务分配考虑的是“异常处理”

• 高可用任务分配架构设计的关键点：

• 任务分解：

• 将服务器拆分不同角色，不同的服务器处理不同的业务。

• 复杂度分析：

• 增加“任务分解器”节点，可以是独立的服务器，也可以是 SDK

• 任务分解器需要管理所有的服务器，可以通过配置文件，也可以通过配置服务器（例如 Zookeeper）

• 需要设计任务的拆分方式，任务分解器需要记录“任务”和“服务器”的映射关系

• 任务分解器需要根据不同的需求采用不同的算法分配

• 任务分解器需要监控业务服务器的状态，在故障时进行切换。

• 计算高可用任务分解器架构设计的关键点：

• 任务分解案例：

• 微服务的拆分

存储高可用

• 数据复制格式：

• 复制命令

• 优缺点：

• 实现简单，复制数据量较小；

• 数据可能不一致（SQL 函数）

• 适用场景：

• 增量复制

• 复制数据

• 优缺点：

• 实现简单

• 保证数据一致

• 复制流量可能会很大

• 适用场景

• 增量复制

• 复制文件

• 优缺点：

• 实现复杂，复制的时候数据在变

• 保证数据一致

• 数据流量可能会很大

• 适用场景：

• 全量复制

• 数据复制方式：

• 同步复制：

• 优缺点：

• 最强一致性，故障容忍度低；

• 写入性能低

• 适用场景：

• 主备/主从架构

• 异步复制

• 优缺点：

• 写入性能高，故障容忍度高；

• 容易出现数据不一致。

• 适用场景：

• 数据存储集群

• 半同步复制：

• 优缺点：

• 同步复制和异步复制的折中方案

• 适用场景：

• 数据存储集群

• 多数复制：

• 优缺点：

• 数据强一致性，最强可用性，故障容忍度高

• 写入性能不高，实现复杂

• 适用场景：

• 分布式一致性，分布式协同（OceanBase , ZooKeeper）

• 存储高可用状态决策：

• 独裁式：

• 优缺点：

• 决策逻辑简单

• 决策者要做到高可用，整体架构复杂，常用（ZooKeeper 、Raft, Keepalived）

• 数据一致性强度中等

• 应用场景：

• 绝大部分业务都可以应用

• 协商式

• 优缺点：

• 架构实现简单，决策逻辑简单，一般是心跳机制

• 如果是链路问题，会导致双主，可以用“双通道”来缓解

• 数据一致性弱

• 应用场景：

• 内部系统，网络设备（用串口相连）

• 民主式、选举式

• 优缺点：

• 决策过程复杂，决策逻辑复杂，一般用标准算法进行选举，例如：Raft,ZAB,Paxos

• 可用性最高，数据一致性最强

• 可能出现“脑裂”问题，可以采用 quorum 来控制

• 应用场景：

• 对数据一致性要求很高的场景，例如 余额、库存