系统设计原则是指导软件架构师和工程师构建高质量、可维护、可扩展系统的根本准则。这些原则源于数十年的工程实践、学术研究和大型企业的血泪教训，它们不是教条式的规则，而是在复杂度、成本、质量之间寻求平衡的决策框架。本文系统梳理核心设计原则、权衡方法论、反面原则以及行业经典案例，为架构决策提供可操作的指导。
复杂度是软件系统的头号敌人。John Ousterhout 在《A Philosophy of Software Design》中给出了一个关键洞见：复杂度是对读者而言的，而非对写作者而言的。一段代码在编写时可能逻辑清晰，但三个月后，即使是原作者也可能难以理解。这种认知落差是技术债务累积的根源。
复杂度的本质是系统难以理解、修改和维护的程度。McCabe 于 1976 年提出的圈复杂度（Cyclomatic Complexity）提供了量化手段：
其中 为控制流图中的边数， 为节点数， 为连通分量数。对于单函数/方法，，公式简化为：
另一种等价的计算方式基于判定节点：
其中 为判定节点（if、while、for、case 等）的数量。
数值计算案例 1：圈复杂度评估
考虑一个订单状态流转函数：
// 反例：高圈复杂度 V(G) = 8
public String getOrderStatus(Order order) {
if (order == null) return "INVALID";
if (order.isDeleted()) return "DELETED";
if (order.getPayment() == null) {
if (order.isExpired()) return "EXPIRED";
return "PENDING_PAYMENT";
}
if (!order.getPayment().isPaid()) return "PAYMENT_PENDING";
if (order.getShipment() == null) return "PAID";
if (!order.getShipment().isShipped()) return "PREPARING";
if (order.getShipment().isDelivered()) return "DELIVERED";
return "SHIPPED";
}
判定节点：null 检查(1)、deleted(2)、payment null(3)、expired(4)、paid(5)、shipment null(6)、shipped(7)、delivered(8)。
根据业界标准：
| 圈复杂度范围 | 风险等级 | 测试用例数 | 维护难度 | 建议措施 |
|---|---|---|---|---|
| 1–4 | 低 | 4 | 简单 | 无需处理 |
| 5–7 | 中等 | 7 | 尚可 | 考虑重构 |
| 8–10 | 高 | 10 | 困难 | 必须重构 |
| 11–15 | 很高 | 15 | 很复杂 | 立即重构 |
| >15 | 极高 | >15 | 不可维护 | 紧急重构 |
上述 处于高风险区间。重构后：
// 正例：使用状态模式，V(G) ≈ 2（每个方法）
public interface OrderState {
String getStatus(Order order);
}
public class PendingPaymentState implements OrderState {
public String getStatus(Order order) {
return order.isExpired() ? "EXPIRED" : "PENDING_PAYMENT";
}
}
// 其他状态类...
数值计算案例 2：技术债务量化
SonarQube 采用技术债务比率（Technical Debt Ratio, TDR）进行量化：
假设一个系统有 100,000 行代码，平均开发成本为 ，修复所有代码异味需 200 小时，开发效率为 10 LOC/小时：
| TDR 范围 | 健康状态 | 年维护成本增幅 | 建议 |
|---|---|---|---|
| < 5% | 健康 | < 10% | 持续监控 |
| 5–10% | 警告 | 10–25% | 计划偿还 |
| 10–20% | 危险 | 25–50% | 立即行动 |
| > 20% | 严重 | > 50% | 停止功能开发 |
Ousterhout 指出复杂度来源于三个相互交织的维度：
1. 关联变更（Change Amplification）
看似简单的改动需要在多处修改。其量化指标为变更传播系数：
理想情况下 。某电商平台数据显示，耦合模块的 中位数为 3.2，而正交化重构后降至 1.1。
2. 认知负荷（Cognitive Load）
开发者需要掌握的信息量。心理学研究表明，工作记忆容量为 个组块（Miller, 1956）。当模块接口参数超过 9 个时，理解错误率显著上升。
| 接口参数数量 | 平均理解时间 | 错误率 | 记忆负荷 |
|---|---|---|---|
| 0–3 | 15s | 2% | 低 |
| 4–6 | 35s | 8% | 中等 |
| 7–9 | 65s | 18% | 高 |
| > 9 | 120s+ | 35% | 过载 |
3. 未知的未知（Unknown Unknowns）
代码中隐藏的依赖和副作用。其危害难以量化，但可通过静态分析中的"隐式依赖"指标间接度量。
一件事只有一种做法（One Way to Do It）
Python 的设计哲学之一。在系统设计中，这意味着：
┌─────────────────────────────────────────┐
│ 统一处理策略 │
├─────────────────────────────────────────┤
│ 错误处理 → 统一异常体系 + 错误码规范 │
│ 日志记录 → 统一日志框架 + 结构化格式 │
│ 配置管理 → 统一配置中心 + 版本控制 │
│ 数据访问 → 统一 ORM/Repository 模式 │
│ 缓存策略 → 统一缓存抽象 + 失效规则 │
└─────────────────────────────────────────┘
正交性（Orthogonality）
来自几何学的概念：两个向量正交当且仅当其内积为零。在软件中，模块 A 和 B 正交意味着修改 A 不会影响 B。
正交性度量——耦合度系数：
理想正交：；完全耦合：。
| 耦合度范围 | 正交性评级 | 维护影响 |
|---|---|---|
| 0–0.1 | 优秀 | 独立演进 |
| 0.1–0.3 | 良好 | 偶尔协调 |
| 0.3–0.5 | 一般 | 需要同步计划 |
| 0.5–0.7 | 差 | 强依赖 |
| > 0.7 | 很差 | 不可分割 |
避免创造人为知识
系统应自解释，减少需要额外文档或口头传递的"暗知识"。
| 知识类型 | 存储位置 | 可发现性 | 衰减风险 |
|---|---|---|---|
| 代码逻辑 | 源码 | 高 | 低 |
| 架构决策 | ADR 文档 | 中 | 中 |
| 业务规则 | 注释/测试 | 中 | 中 |
| 运维手册 | Wiki/Runbook | 低 | 高 |
| 口头传统 | 人脑 | 极低 | 极高 |
知识中心化的核心是确立单一可信数据源（Single Source of Truth, SSOT）。在分布式系统中，数据一致性模型决定了知识中心化的实现方式：
┌─────────────────────────────────────────────┐
│ 一致性模型谱系 │
├─────────────────────────────────────────────┤
│ │
│ 强一致性 ◄──────► 最终一致性 ◄──────► 弱一致性 │
│ │ │ │ │
│ 线性化 因果一致性 单调读 │
│ 顺序一致性 会话一致性 读己之写 │
│ 事件ual 可能旧值 │
│ │
└─────────────────────────────────────────────┘
CAP 定理约束：
对于分布式数据存储，在分区容错（P）必须满足的前提下：
提升一致性必然牺牲可用性，反之亦然。
| 系统类型 | 一致性选择 | 可用性目标 | 典型场景 |
|---|---|---|---|
| 金融核心 | 强一致性 (CP) | 99.99% | 账户余额 |
| 电商平台 | 最终一致性 (AP) | 99.999% | 库存显示 |
| 社交网络 | 弱一致性 (AP) | 99.9% | 点赞计数 |
| 日志系统 | 最终一致性 | 99% | 可接受延迟 |
大型组织中，知识孤岛是复杂度的重要来源。Google 的 DORA（DevOps Research and Assessment）研究表明：
| 指标 | 高绩效团队 | 中绩效团队 | 低绩效团队 |
|---|---|---|---|
| 部署频率 | 按需（每日多次） | 每周–每月 | 每月–每季 |
| 变更前置时间 | < 1 小时 | 1 周–1 月 | 1 月–6 月 |
| 服务恢复时间 | < 1 小时 | < 1 天 | 1 周+ |
| 变更失败率 | < 5% | 5–15% | 15–30% |
知识共享的关键机制：
┌─────────────────────────────────────────┐
│ 知识中心化机制 │
├─────────────────────────────────────────┤
│ │
│ 1. 架构决策记录 (ADR) │
│ └── /docs/adr/YYYY-MM-DD-title.md │
│ │
│ 2. 统一 API 文档 │
│ └── OpenAPI/Swagger + 自动生成 │
│ │
│ 3. 事件目录 (Event Catalog) │
│ └── 异步契约 + Schema Registry │
│ │
│ 4. 运行手册 (Runbook) │
│ └── 告警 → 诊断 → 恢复流程 │
│ │
│ 5. 代码即文档 │
│ └── 自解释命名 + 类型系统 + 测试即示例 │
│ │
└─────────────────────────────────────────┘
一致性不是单一维度，而是贯穿系统多个层面的设计属性。
| 维度 | 定义 | 一致性目标 | 维护成本 | 违反后果 |
|---|---|---|---|---|
| UI 一致性 | 界面元素、交互模式的统一 | 用户学习成本最小化 | 设计系统维护 | 用户困惑 |
| 编码一致性 | 命名规范、代码风格、模式统一 | 可读性最大化 | 代码审查 + 工具 | 维护困难 |
| 架构一致性 | 分层、通信模式、技术选型统一 | 认知负荷最小化 | 架构治理 | 技术债务 |
| API 一致性 | 端点命名、参数风格、错误格式统一 | 集成成本最小化 | API 设计规范 | 集成错误 |
| 数据模型一致性 | 实体命名、关系定义、约束统一 | 数据质量保障 | Schema 治理 | 数据混乱 |
| 运维一致性 | 部署流程、监控指标、告警规则统一 | 运维效率最大化 | 平台工程 | 故障恢复慢 |
一致性的收益遵循边际递减规律：
其中 为一致性投入， 为最大收益， 为收益系数， 为固定成本， 为单位变动成本。
数值计算案例 3：一致性投入的最优解
假设引入设计系统：
求最优投入 ：
对应收益：
| 一致性策略 | 初始成本 | 年维护成本 | 3 年 ROI | 适用规模 |
|---|---|---|---|---|
| 轻量级规范 | $10K $5K | 400% | < 10 人 | |
| 设计系统 | $200K $50K | 150% | 10–100 人 | |
| 平台工程 | $1M $300K | 120% | 100–1000 人 | |
| 企业架构 | $5M $1M | 80% | > 1000 人 |
模块化的核心命题：模块复杂度之和应小于整体复杂度。
其中 为模块 的复杂度， 为未模块化系统的复杂度。不等式成立的关键在于接口成本 的控制：
数值计算案例 4：模块化收益计算
假设一个单体系统 （任意复杂度单位）。拆分为 5 个模块：
| 模块 | 内部复杂度 | 接口数量 | 接口复杂度 |
|---|---|---|---|
| A | 150 | 3 | 20 |
| B | 120 | 2 | 15 |
| C | 180 | 4 | 25 |
| D | 100 | 2 | 10 |
| E | 90 | 1 | 5 |
模块化收益：
Eric S. Raymond 在《The Art of UNIX Programming》中定义正交性：
"正交性意味着一个系统的组成部分可以以任意组合方式使用，而不会相互干扰。"
正交系统的数学特征：
即对组合操作的结果等于分别操作后的组合。
实际案例：日志框架的抽象化
SLF4J（Simple Logging Facade for Java）是正交抽象的经典案例：
// 反例：直接依赖具体实现（非正交）
import org.apache.log4j.Logger;
public class OrderService {
private static final Logger logger = Logger.getLogger(OrderService.class);
public void createOrder() {
logger.info("Creating order...");
// 如果迁移到 Logback，需要修改所有文件
}
}
// 正例：依赖抽象（正交）
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class OrderService {
private static final Logger logger = LoggerFactory.getLogger(OrderService.class);
public void createOrder() {
logger.info("Creating order...");
// 底层实现可自由替换：Log4j、Logback、Log4j2
}
}
| 维度 | 直接依赖实现 | 依赖抽象 (SLF4J) |
|---|---|---|
| 切换成本 | 修改 N 个文件 | 修改 0 个文件 |
| 测试难度 | 需要真实日志环境 | 可注入 Mock |
| 认知负荷 | 需了解实现细节 | 只需了解接口 |
| 演进灵活性 | 低 | 高 |
抽象是强大的工具，但过度抽象会创造新的复杂度。判断抽象是否适度的标准：
| 检查项 | 过度抽象信号 | 适度抽象信号 |
|---|---|---|
| 接口数量 | 实现仅需 20% 接口 | 实现使用 80%+ 接口 |
| 间接层数 | > 3 层代理/包装 | 1–2 层足够 |
| 概念密度 | 新概念 > 业务概念 | 新概念 ≈ 业务概念 |
| 代码增量 | 抽象代码 > 业务代码 | 抽象代码 < 30% |
| 学习曲线 | 1 周+ 才能贡献代码 | 1–2 天可贡献 |
抽离决策层
将业务规则与执行机制分离：
┌─────────────────────────────────────────┐
│ 决策与执行分离 │
├─────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ 决策层 │ ──▶ │ 执行层 │ │
│ │ (Policy) │ │ (Mechanism)│ │
│ └──────────┘ └──────────┘ │
│ │ │ │
│ 业务规则引擎 技术实现 │
│ 可配置策略 稳定高效 │
│ 频繁变更 较少变更 │
│ │
└─────────────────────────────────────────┘
独立设计：服务拥有独立的领域模型、业务逻辑和演进路线。
独立运行：服务可独立部署、独立伸缩、独立故障隔离。
| 自治维度 | 理想状态 | 反模式 | 检测指标 |
|---|---|---|---|
| 设计自治 | 独立领域模型 | 共享数据库 | 数据库耦合度 |
| 部署自治 | 独立流水线 | 协调发布 | 部署频率差异 |
| 运行自治 | 独立伸缩 | 统一集群 | 资源利用率 |
| 故障自治 | 熔断降级 | 级联故障 | 故障传播范围 |
| 团队自治 | 独立决策 | 集中审批 | 决策延迟 |
Netflix 的微服务实践数据（2015 年公开数据）：
| 指标 | 数值 | 说明 |
|---|---|---|
| 微服务数量 | 500+ | 持续演进 |
| 日均部署次数 | 1000+ | 完全自动化 |
| 平均恢复时间 | < 10 分钟 | 混沌工程训练 |
| 服务间调用 | 数十亿/天 | 异步为主 |
Amazon 的"两个披萨团队"原则：团队规模控制在 6–10 人，可独立负责完整服务生命周期。
┌─────────────────────────────────────────┐
│ 服务自治架构示意 │
├─────────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────┐ ┌────────┐│
│ │ 订单服务 │ │ 库存服务 │ │ 支付服务││
│ │ Team A │ │ Team B │ │ Team C ││
│ │ ─────── │ │ ─────── │ │ ────── ││
│ │ DB: A │ │ DB: B │ │ DB: C ││
│ │ Cache:A │ │ Cache:B │ │Cache:C ││
│ │ Queue:A │ │ Queue:B │ │Queue:C ││
│ └────┬────┘ └────┬────┘ └───┬────┘│
│ │ │ │ │
│ └─────────────┴────────────┘ │
│ API Gateway / Event Bus │
│ │
└─────────────────────────────────────────┘
设计时考虑未来变化，但避免过度设计。通用性的度量：
：设计恰到好处；：过度设计；：设计不足。
扩展点设计模式：
| 模式 | 适用场景 | 实现复杂度 | 灵活性 |
|---|---|---|---|
| 策略模式 | 算法替换 | 低 | 高 |
| 插件架构 | 功能扩展 | 中 | 很高 |
| 钩子/回调 | 行为定制 | 低 | 中 |
| 配置驱动 | 规则变化 | 低 | 中 |
| 事件驱动 | 流程扩展 | 中 | 高 |
| 抽象工厂 | 产品族替换 | 中 | 高 |
数值计算案例 5：扩展点投资回报率
假设一个支付系统，当前支持 3 种支付方式，预计 2 年内扩展到 10 种：
但如果实际需求只新增 2 种：
| 预测准确性 | 设计扩展点 | 不设计扩展点 | 建议 |
|---|---|---|---|
| 高 (>80%) | 收益显著 | 机会成本 | 设计扩展点 |
| 中 (50–80%) | 可能收益 | 可能节省 | 轻量级扩展点 |
| 低 (<50%) | 大概率亏损 | 大概率节省 | 不设计，重构时引入 |
设计原则之间并非总是和谐共存，架构师需要在冲突中做出权衡。
| 冲突原则对 | 冲突场景 | 权衡策略 | 决策依据 |
|---|---|---|---|
| 一致性 vs 自治 | 跨服务数据格式 | 核心域强一致，边缘域自治 | 变更频率 |
| 通用性 vs 简单性 | 扩展点设计 | 近期确定的需求直接实现 | 需求确定性 |
| 模块化 vs 性能 | 高频跨模块调用 | 热点内联，冷点模块化 | 性能剖析数据 |
| 正交性 vs 交付速度 | 初创产品 MVP | 适度耦合，债务清单追踪 | 市场验证阶段 |
| 知识中心化 vs 团队自治 | 文档维护责任 | 代码即文档 + 轻量 ADR | 团队规模 |
┌─────────────────────────────────────────┐
│ 架构决策流程 │
├─────────────────────────────────────────┤
│ │
│ ┌─────────┐ │
│ │ 识别约束 │ │
│ │(业务/技术/组织)│ │
│ └────┬────┘ │
│ ▼ │
│ ┌─────────┐ │
│ │ 列出候选方案│ │
│ │ (≥3 个) │ │
│ └────┬────┘ │
│ ▼ │
│ ┌─────────┐ │
│ │ 原则评估 │ │
│ │ 加权评分 │ │
│ └────┬────┘ │
│ ▼ │
│ ┌─────────┐ │
│ │ 冲突消解 │ │
│ │ 明确取舍 │ │
│ └────┬────┘ │
│ ▼ │
│ ┌─────────┐ │
│ │ 记录决策 │ │
│ │ (ADR) │ │
│ └─────────┘ │
│ │
└─────────────────────────────────────────┘
决策评分表示例：
| 方案 | 复杂度控制(25%) | 可维护性(25%) | 性能(20%) | 成本(20%) | 时间(10%) | 总分 |
|---|---|---|---|---|---|---|
| A | 9 | 8 | 6 | 7 | 8 | 7.75 |
| B | 7 | 7 | 9 | 5 | 6 | 7.00 |
| C | 8 | 9 | 7 | 6 | 7 | 7.65 |
正面原则告诉我们"应该做什么"，反面原则提醒我们"不应该做什么"以及"何时停止"。
任何设计决策的影响范围应可预测、可限制、可回滚。
| 控制维度 | 理想状态 | 反模式 | 度量指标 |
|---|---|---|---|
| 范围可控 | 影响 1–3 个模块 | 全系统重构 | 变更影响范围 |
| 时间可控 | 回滚 < 5 分钟 | 数小时恢复 | MTTR |
| 数据可控 | 零数据丢失 | 不可逆变更 | RPO |
| 成本可控 | 预算内 10% | 超支 50%+ | 成本偏差 |
在满足需求的前提下，改动量最小化。这是成本与质量的权衡：
| 场景 | 最少改动策略 | 重构策略 | 选择依据 |
|---|---|---|---|
| 紧急修复 | 最小改动 | 延后 | 时间压力 |
| 技术债务偿还 | 适度扩展 | 彻底重构 | 债务严重程度 |
| 新功能开发 | 遵循现有模式 | 引入新模式 | 变更频率 |
| 架构演进 | 渐进式迁移 | 大爆炸重写 | 系统规模 |
Melvin Conway 于 1968 年提出：
"设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。"
| 组织结构 | 典型架构 | 优势 | 劣势 |
|---|---|---|---|
| 职能型（前端/后端/DBA） | 分层架构 | 专业深度 | 交付延迟 |
| 产品型（端到端团队） | 微服务 | 响应速度 | 技术重复 |
| 矩阵型 | 中台 + 前台 | 平衡 | 决策复杂 |
| 开源社区 | 插件架构 | 创新 | 方向分散 |
反面应用：如果组织沟通是层级审批制，系统必然出现中央控制器；如果团队地理分散，模块边界将反映时区边界。
来自社会学，在软件工程中：代码中的小问题如果不及时修复，会传递"这里没人管"的信号，导致更多问题累积。
| 信号 | 初期状态 | 忽视后 | 修复成本倍数 |
|---|---|---|---|
| 代码异味 | 1 处 | 蔓延至 20 处 | 5–10x |
| 测试缺失 | 1 个模块 | 半数模块 | 10–20x |
| 文档过期 | 1 页 | 全部过期 | 3–5x |
| 依赖过时 | 1 个库 | 50+ 个库 | 5–15x |
| 阶段 | 时间 | 架构 | 团队规模 | 部署频率 |
|---|---|---|---|---|
| 单体 | 1994–2002 | Perl/C++ 单体 | < 100 | 每年数次 |
| 服务化 | 2002–2006 | 面向服务 | 数百 | 每周 |
| 微服务 | 2006–2012 | 微服务 + AWS | 数千 | 每日 |
| 平台化 | 2012–至今 | 内部平台 + 微服务 | 数万 | 每秒 |
关键决策：2002 年 Jeff Bezos 的"API 强制令"——所有团队必须通过服务接口通信，违者开除。这是康威定律的主动应用。
| 指标 | 2010 | 2015 | 2020 |
|---|---|---|---|
| 服务数 | 数十 | 500+ | 1000+ |
| 区域部署 | 2 | 3 | 多区域 |
| Chaos Monkey | 随机终止 | 多维度故障 | 定向故障注入 |
| 可用性 | 99.9% | 99.99% | 99.999% |
Netflix 通过故意引入故障来验证系统的自治性和容错能力，将"未知的未知"转化为"已知的已知"。
SRE 将可靠性视为产品功能，用误差预算平衡创新与稳定：
| 可用性目标 | 年误差预算 | 月均故障时间 | 策略 |
|---|---|---|---|
| 99% | 3.65 天 | 7.3 小时 | 宽松 |
| 99.9% | 8.76 小时 | 43.8 分钟 | 平衡 |
| 99.99% | 52.6 分钟 | 5.3 分钟 | 严格 |
| 99.999% | 5.26 分钟 | 31.5 秒 | 极严格 |
当误差预算耗尽时，暂停功能发布，优先技术债务偿还。
| 维度 | Rails 单体 (2010) | JVM + 服务 (2012) |
|---|---|---|
| 峰值 TPS | 数百 | 数万 |
| 故障恢复 | 数小时 | 分钟级 |
| 团队并行度 | 低（代码冲突） | 高（服务自治） |
| 开发效率 | 快速起步 | 初期慢，长期快 |
Twitter 的教训：初创期选择开发效率，成长期必须投资架构。
Martin Fowler 倡导的演进路径：
┌─────────────────────────────────────────┐
│ 架构演进路径 │
├─────────────────────────────────────────┤
│ │
│ 单体 ──▶ 模块化单体 ──▶ 服务化 ──▶ 微服务 │
│ │ │ │ │ │
│ │ │ │ │ │
│ 验证市场 识别边界 提取服务 精细拆分│
│ <6月 6–18月 1–2年 2年+ │
│ │
│ 关键：每个阶段都有价值，不必跳过 │
│ │
└─────────────────────────────────────────┘
| 指标类别 | 具体指标 | 计算方式 | 目标值 |
|---|---|---|---|
| 复杂度 | 平均圈复杂度 | < 5 | |
| 耦合度 | 组件依赖数 | 静态分析 | < 10/组件 |
| 内聚性 | LCOM（缺乏内聚性度量） | 方法共享字段分析 | < 0.5 |
| 测试覆盖 | 行覆盖率 | > 80% | |
| 技术债务 | TDR | SonarQube 计算 | < 5% |
| 文档覆盖 | API 文档率 | > 90% | |
| 部署频率 | 日均部署 | CI/CD 统计 | > 1/天 |
| 恢复时间 | MTTR | 故障统计 | < 1 小时 |
Lack of Cohesion in Methods（LCOM）度量类的内聚性：
：完全内聚（所有方法共享字段）；：完全无内聚。
| LCOM 范围 | 内聚性评级 | 建议 |
|---|---|---|
| 0–0.25 | 优秀 | 保持 |
| 0.25–0.5 | 良好 | 监控 |
| 0.5–0.75 | 差 | 考虑拆分 |
| 0.75–1.0 | 很差 | 必须拆分 |
其中 为权重，各维度 0–10 分：
| 维度 | 权重 | 评分依据 |
|---|---|---|
| 复杂度控制 | 25% | 圈复杂度、认知负荷 |
| 知识中心化 | 15% | 文档完整性、一致性 |
| 一致性 | 15% | 规范遵循率 |
| 模块化 | 20% | 耦合度、内聚性 |
| 关注点分离 | 15% | 正交性、抽象适度 |
| 自治性 | 10% | 独立部署能力 |
| 场景 | 第一原则 | 第二原则 | 第三原则 |
|---|---|---|---|
| 初创产品 | 最少改动 | 控制复杂度 | 模块化 |
| 增长期系统 | 模块化 | 服务自治 | 一致性 |
| 企业平台 | 一致性 | 知识中心化 | 控制复杂度 |
| 遗留系统改造 | 影响可控 | 模块化 | 最少改动 |
| 高可用系统 | 服务自治 | 影响可控 | 期待变化 |
| 公式 | 用途 | 来源 |
|---|---|---|
| 圈复杂度 | McCabe | |
| 技术债务 | SonarQube | |
| 耦合度 | 本文 | |
| 变更放大 | Ousterhout | |
| 通用性度量 | 本文 | |
| 架构健康度 | 本文 | |
| 可靠性管理 | Google SRE | |
| 内聚性 | Chidamber |