系统架构设计：在约束中做取舍

系统架构设计不是画一张漂亮的图，也不是把热门中间件堆在一起。它要回答一个更朴素的问题：在成本、时间、团队和业务的约束下，系统如何满足关键质量属性？架构图只是结果，决策才是核心。

一、先定质量属性，再谈技术选型

可用性、一致性、延迟、吞吐、成本、安全、可演进，这些属性往往互相冲突。要强一致，就可能牺牲可用性和延迟；要极致弹性，就要接受运维复杂度。架构设计的第一步，是给这些属性排序。

没有排序，就没有架构。所有“都要”的需求，最后都会变成“都做不好”。

二、划边界，而不是先分层

边界应该按业务能力划分，而不是按技术分层。订单、库存、支付，各自有独立的生命周期和数据。边界清晰，团队才能并行，部署才能独立，故障才能隔离。

跨边界只通过接口，不直接读对方的数据库。下面这段代码很短，但它表达了一个架构约束：订单服务只依赖库存抽象，不依赖库存实现。

interface InventoryService {
    boolean reserve(String sku, int qty);
}

class OrderService {
    private final InventoryService inventory;

    OrderService(InventoryService inventory) {
        this.inventory = inventory;
    }

    void place(String sku, int qty) {
        if (!inventory.reserve(sku, qty)) {
            throw new IllegalStateException("库存不足");
        }
    }
}

库存用数据库、缓存还是远程服务，订单不关心。替换实现时，订单逻辑不动。

三、依赖方向决定变更成本

业务策略不应该依赖数据库驱动，也不应该依赖消息队列客户端。依赖方向一旦反了，换一个中间件就要改业务代码。正确的方向是：业务依赖抽象，基础设施实现抽象。

架构设计要保护的，是业务规则不被技术细节绑架。

四、数据一致性要算账

单体里一个事务能解决的问题，拆成分布式后可能变成 Outbox、Saga、幂等、补偿和对账。分布式事务不是不能做，而是成本高。多数场景下，最终一致比强一致更现实。

不要为了“微服务”三个字，把简单事务拆成复杂流程。架构的目标是解决问题，不是制造问题。

五、可观测性是架构的一部分

没有日志、指标、链路追踪，分布式系统就是黑盒。限流、降级、熔断、灰度、回滚，这些不是运维补丁，而是架构设计的一等公民。系统能不能上线，不只看功能，还看故障时能不能定位、能不能恢复。

六、架构是演进的，不是重写的

单体不是原罪，微服务也不是终点。业务早期，单体加模块化往往更快；业务复杂后，再按边界拆分。每次演进都应该让下一次变更更容易，而不是更痛苦。

系统架构设计的核心，是在约束中做取舍，在变化中划边界。代码只是约束的表达，图只是沟通的工具。真正持久的，是那些想清楚的决策原则。