架构为什么会复杂：高性能、高可用与约束取舍

系统最开始通常很简单：一个应用、一套数据库、几个接口。复杂度不是凭空出现的，而是业务规模、可用性目标和团队协作方式一起推动出来的。

问题背景

当系统需要承载更多流量、更少停机、更快交付和更低成本时，单一方案很难同时满足所有目标。架构设计真正难的地方，是承认这些目标之间会互相拉扯。

核心概念

高性能关注吞吐、延迟和资源利用率；高可用关注故障隔离、冗余和恢复；一致性关注数据是否可信；成本关注复杂度是否值得。

flowchart LR
    A["用户请求"] --> B["负载均衡"]
    B --> C["服务实例 A"]
    B --> D["服务实例 B"]
    C --> E["缓存"]
    D --> E
    C --> F["主数据库"]
    D --> F
    F --> G["只读副本 / 备份"]

实际工程场景

缓存能降低数据库压力，但会引入一致性问题。多副本能提升可用性，但会增加部署、监控和数据同步成本。服务拆分能提升团队并行度，但会引入网络、事务和观测复杂度。

常见误区

• 没有瓶颈证据就先上复杂架构。
• 把高可用理解成“多部署几个实例”。
• 只看组件选型，不看故障模式。

最佳实践

• 先明确 SLO，再谈架构。
• 用压测和监控确认瓶颈。
• 为关键链路设计降级和熔断。
• 把取舍记录下来，方便未来复盘。