设计模式在网络架构中的实战应用

在搭建一个高并发的电商平台时，很多人会遇到同一个问题：订单服务、库存服务、支付服务之间调用混乱，改一处代码，连锁反应一大片。这种情况其实在软件开发中太常见了，而解决它的关键，往往不是靠堆代码，而是靠设计模式。

为什么网络架构需要设计模式

现代系统大多是分布式架构，模块多、交互频繁。如果没有清晰的结构，系统很容易变成“意大利面”——谁都不敢动。设计模式就像建筑中的梁柱结构，提前规划好组件之间的关系，让系统既稳定又灵活。

比如，用户下单后要通知多个服务：减库存、发短信、记日志、更新积分。如果每个都硬编码调用，新增一个“推荐优惠券”功能就得改代码。这时候用观察者模式就特别合适：订单服务只负责发布“下单成功”事件，其他服务自行订阅，各干各的，互不干扰。

public interface OrderObserver {
    void onOrderCreated(Order order);
}

public class InventoryService implements OrderObserver {
    public void onOrderCreated(Order order) {
        reduceStock(order.getProductId());
    }
}

public class SmsService implements OrderObserver {
    public void onOrderCreated(Order order) {
        sendConfirmationSms(order.getUserPhone());
    }
}

接口不稳？试试适配器模式

系统对接第三方支付时，支付宝和微信的接口参数、返回格式完全不同。如果业务代码里到处写 if-else 判断支付类型，维护起来简直是噩梦。

用适配器模式，可以把不同接口统一成一个标准接口。后续哪怕接入银联、PayPal，也只需要写一个新的适配器，老代码完全不动。

public interface PaymentAdapter {
    PaymentResult pay(BigDecimal amount, String accountId);
}

public class AlipayAdapter implements PaymentAdapter {
    private AlipayClient client;
    public PaymentResult pay(BigDecimal amount, String accountId) {
        // 转换参数，调用支付宝SDK
        return convertResult(client.invoke(amount, accountId));
    }
}

控制资源访问，单例模式不可少

数据库连接池、配置中心客户端这类资源，没必要反复创建。用单例模式确保全局只有一个实例，既能节省资源，又能避免状态不一致。

尤其是在微服务环境下，每个服务启动时都去拉一次远程配置，不仅慢还可能把配置中心压垮。通过单例加载，所有模块共用一份配置实例，效率提升明显。

扩展功能不用改代码：装饰器模式

给API响应加压缩、加密、日志等功能，最笨的办法是在每个接口里重复写逻辑。聪明的做法是用装饰器模式一层层包装。

比如原始响应是JSON，加上压缩装饰器就自动gzip，加上安全装饰器就加密。想换顺序或者去掉某一层，只要调整组合方式，核心逻辑一点不用碰。

设计模式不是炫技，而是为了应对变化。系统越复杂，越需要这些经过验证的“套路”。它们不保证让你写最少的代码，但能让你在需求变来变去的时候，依然睡得着觉。