系统架构设计：十行配置，撑起一套系统的骨架

系统架构设计，不是把中间件挨个堆上去，也不是画一张谁都看不懂的拓扑图。它只回答几个问题：系统分成哪些部分、它们怎么连、数据往哪流、出问题谁扛、以后怎么改。代码只是架构的注脚，真正的功夫在决策和权衡。

一、架构是决策，不是图

图只是快照，决策才是资产。同一个系统，可以画成微服务，也可以画成模块化单体，关键不在图好不好看，而在你为什么选它。

每个重大决策，建议写一条 ADR：背景、选项、决定、后果。比如“为什么订单和库存先不拆成两个服务”，写清楚比画十张图都有用。

二、先定非功能需求

功能决定能不能用，非功能决定能活多久。动手前先问：

• 峰值 QPS 多少，延迟要求多少？
• 能接受最终一致，还是必须强一致？
• 可用性要 99.9% 还是 99.99%？
• 团队几个人，运维能力如何？
• 预算卡在哪里？

这些问题没有答案，架构就是空中楼阁。

三、最小骨架：上下文、容器、组件、数据流

用简化版 C4 模型：先画系统上下文，再画容器，最后画组件。一个订单系统的最小骨架，用 Mermaid 十行就能表达：

flowchart LR
  U[用户] --> G[API 网关]
  G --> A[订单服务]
  A --> D[(订单库)]
  A --> M[[消息队列]]
  M --> W[通知 Worker]
  W --> E[邮件/短信]

这段“代码”不执行，但它能帮你发现：谁是入口、谁是单点、数据写到哪里、异步链路有多长。架构图的第一价值，是让团队对边界达成共识。

四、少量代码：用接口锁住依赖方向

架构分层最怕核心业务依赖具体基础设施。今天用邮件，明天换短信，如果业务代码里直接 new EmailSender()，改动就会蔓延。

用接口或 Protocol 把依赖倒置，核心业务只依赖抽象：

from typing import Protocol

class Notifier(Protocol):
    def send(self, msg: str) -> None: ...

class OrderService:
    def __init__(self, notifier: Notifier):
        self.notifier = notifier
    def place(self, order):
        self.notifier.send(f"订单 {order.id} 已创建")

这段代码不解决部署、容量和一致性，但它守住一条架构底线：业务核心不绑定具体渠道和厂商。换实现，不改核心。

五、通信：同步与异步

同步简单，异步抗压。请求-响应适合查询和强交互；事件驱动适合解耦、削峰和跨团队协作。

但别为了“高级”上消息队列。先问：能不能接受最终一致？重复消息怎么幂等？顺序要不要保证？失败后重试几次？这些问题不回答，异步只会带来更多故障。

六、数据：架构的真正难点

无状态服务好扩展，有状态数据难迁移。分库分表、读写分离、缓存、CDC，都是为数据服务。

先定一致性等级：强一致、读己之写、最终一致。再定主键、分区键、保留策略和备份恢复。数据架构一旦错了，后面改起来最疼。

七、可观测性与演进

没有日志、指标、追踪，架构就是黑盒。每个服务至少暴露健康检查、关键指标和请求追踪 ID。

架构不是一次成型，而是持续演进。用 ADR 记录重大决策，用自动化测试守住关键约束。比如“核心服务不允许直接连别人数据库”，这种底线可以用 CI 检查。

八、常见坑

• 过早微服务：团队没到，先模块化单体。
• 只追新技术：架构为业务服务，不为简历服务。
• 忽略成本：带宽、存储、跨云流量都是钱。
• 没有回滚：发布策略比选型更重要。
• 只画图不写 ADR：三个月后没人记得为什么这么设计。

九、结语

系统架构设计，代码可以只有十行，但决策要写满几页。图会过时，代码会重构，只有清晰的边界、依赖方向和权衡记录，能让系统在变化中活下来。

记住：好的架构，不是让你现在写得爽，而是让你半年后还敢改。