如何设计可扩展架构

1. 架构设计复杂度模型

• 核心概念
  架构复杂度由 业务复杂度 和 质量复杂度 正交构成：

• 业务复杂度

：业务固有的复杂性，如业务数量多（微信）、流程长（支付宝）、关系复杂（ERP）。

• 质量复杂度

：非功能性需求，如高性能、高可用、安全、低成本等。

• 复杂度等级与架构模式

等级	业务复杂度	质量复杂度	架构模式示例
1	低	低	LAMP、SSH、Ruby on Rails
2	高	低	SOA、DDD、微服务
3	低	高	集群、缓存、分片、副本
4	高	高	融合多种模式（如微服务+集群）

关键点：DDD 仅解决业务复杂度，无法降低质量复杂度。

---

2. 可扩展复杂度模型

• 可扩展（Extensibility）
  系统适应变化的能力，包含 可理解性（代码易维护）和 可复用性（组件可重复使用）。
• 可伸缩（Scalability）
  通过添加资源提升性能的能力（如横向扩展）。

区别：可扩展关注功能演进，可伸缩关注性能提升。

---

3. 可扩展架构设计：拆分

• 拆分法则

• 内部复杂度

（单体复杂度）：开发人员协作成本（如20人开发同一子系统）。

• 外部复杂度

（群体复杂度）：跨系统交互成本（如一次请求需20个子系统参与）。

• 鸡蛋篮子第一法则

：如果一个篮子数不清，拆分到多个篮子再数。

• 复杂度平衡

：

• 拆分原则

1. 内外平衡原则

：避免过度拆分导致外部复杂度激增。
2. 先粗后细原则

：初期粗粒度拆分，逐步细化（避免UC用户中心案例中的过度拆分问题）。

• 失败案例：UC用户中心

• 问题：40+子系统导致测试、部署效率低，问题定位困难。

• 教训：拆分需平衡，最终缩减为10+子系统以降低内部复杂度。

---

4. 可扩展架构设计：封装

• 封装复杂度模型
  通过抽象和隔离变化点，降低系统修改成本。需结合 预测变化 的能力：

• 预测原则

：

1. 2年原则

：仅预测未来2年内的合理变化（如支持微信支付时，可预测支付宝接入）。
2. 3次法则

：同一需求出现3次后再封装（避免过度设计）。

• 封装技巧与案例

技巧	案例	核心设计
规则引擎	美团MazeGO	规则管理、运行时模块、配置中心分离
微内核	OSGi框架	模块层、生命周期层、服务层解耦
抽象层	Linux VFS	统一文件操作接口，支持多文件系统
设计模式	工厂模式、策略模式	隔离变化点，提升可扩展性

---

随堂测验关键点

1. 判断题：

• 错误：简单需求（如“Hello World”）也可能需要架构设计（如高可用场景）。
• 正确：可扩展包含功能演进和性能提升（需区分术语）。
• 错误：子系统需平衡复杂度，而非越简单越好。
• 正确：拆分可先粗后细，逐步演化。
• 错误：预测应聚焦2年内，而非过度前瞻。

3. 思考题：微信 vs 支付宝复杂度

• 微信

：业务复杂度更高（社交功能多样，如朋友圈、小程序）。

• 支付宝

：质量复杂度更高（支付事务强一致性、高并发、金融级安全）。

---

核心结论

• 可扩展架构本质

：通过 拆分（降低内部复杂度）和 封装（隔离变化点）平衡业务与质量需求。

• 实践原则

：避免过度设计，结合演化思维（先粗后细、按需重构），优先解决当前问题。