设计模式与云原生：容器编排中的策略、服务网格中的代理、Serverless中的命令

云原生这个词，这几年听得耳朵都起茧了。但说实话，很多人只是把老系统拆成微服务，扔到K8s里就跑，根本没用到云原生的精髓。我个人习惯把设计模式当作「架构的语法」，在云原生场景下，这些模式换了个马甲，但内核没变。

今天咱们就聊三个最典型的映射：策略模式在容器编排里的应用、代理模式在服务网格里的变形、命令模式在Serverless里的实现。嗯，这三个场景我都在生产环境里踩过坑，咱们一个一个说。

策略模式：容器编排中的弹性伸缩与调度

先问个问题：K8s的HPA（水平自动伸缩）是怎么决定要不要扩缩容的？

你可能会说「看CPU和内存呗」。对，但也不全对。实际上，HPA背后就是一个典型的策略模式——你可以定义不同的度量策略，系统在运行时动态选择用哪个策略来决定伸缩行为。

我在项目中遇到过这样一个场景：某电商平台大促期间，CPU指标完全不准——因为业务是IO密集型的，CPU空闲但请求队列已经爆了。后来我们自定义了一个「基于请求队列深度」的策略，和默认的CPU策略并存，通过配置开关动态切换。

来看一个简化的Java实现：

// 策略接口
public interface ScalingStrategy {
    boolean shouldScaleUp(MetricSnapshot metrics);
    boolean shouldScaleDown(MetricSnapshot metrics);
}

// 具体策略：基于CPU
public class CpuScalingStrategy implements ScalingStrategy {
    @Override
    public boolean shouldScaleUp(MetricSnapshot metrics) {
        return metrics.getCpuUsage() > 0.8; // 超过80%就扩容
    }
    @Override
    public boolean shouldScaleDown(MetricSnapshot metrics) {
        return metrics.getCpuUsage() < 0.2;
    }
}

// 具体策略：基于请求队列
public class QueueDepthScalingStrategy implements ScalingStrategy {
    @Override
    public boolean shouldScaleUp(MetricSnapshot metrics) {
        return metrics.getQueueDepth() > 1000;
    }
    @Override
    public boolean shouldScaleDown(MetricSnapshot metrics) {
        return metrics.getQueueDepth() < 100;
    }
}

// 上下文：HPA控制器
public class HorizontalPodAutoscaler {
    private ScalingStrategy strategy;
    
    public void setStrategy(ScalingStrategy strategy) {
        this.strategy = strategy;
    }
    
    public void reconcile(Deployment deployment, MetricSnapshot metrics) {
        if (strategy.shouldScaleUp(metrics)) {
            deployment.scaleUp();
        } else if (strategy.shouldScaleDown(metrics)) {
            deployment.scaleDown();
        }
    }
}

你看，策略模式在这里的价值就是「开闭原则」——新增一种伸缩策略，不需要改HPA控制器的代码。我曾经见过一个团队，把所有伸缩逻辑写在一个大if-else里，加了五种策略后代码直接变成意大利面条。嗯，重构的时候他们应该早点用策略模式的。

代理模式：服务网格中的Sidecar与流量劫持

服务网格（Service Mesh）最核心的组件是什么？Sidecar代理。说白了，就是代理模式在分布式系统里的经典应用。

你想想看，在传统架构里，服务A调用服务B，需要自己处理重试、超时、熔断、负载均衡。这些逻辑散落在每个服务的代码里，改起来要命。服务网格的做法是：给每个服务实例旁边塞一个代理（Envoy/Linkerd），所有进出流量都经过这个代理。

这就是代理模式——代理对象（Sidecar）控制着对真实对象（业务服务）的访问，并且可以在转发前后插入额外逻辑。

用C++伪代码来理解这个结构：

// 抽象主题
class Service {
public:
    virtual HttpResponse handleRequest(HttpRequest req) = 0;
};

// 真实主题：业务服务
class BusinessService : public Service {
public:
    HttpResponse handleRequest(HttpRequest req) override {
        // 实际的业务逻辑
        return processBusinessLogic(req);
    }
};

// 代理：Sidecar
class SidecarProxy : public Service {
private:
    BusinessService* realService;
    CircuitBreaker* breaker;
    RetryPolicy* retry;
    LoadBalancer* lb;
    
public:
    HttpResponse handleRequest(HttpRequest req) override {
        // 前置增强：服务发现、负载均衡
        auto target = lb->selectTarget();
        
        // 熔断检查
        if (breaker->isOpen()) {
            return HttpResponse(503, "Service Unavailable");
        }
        
        // 重试逻辑
        int retries = 0;
        while (retries < retry->getMaxRetries()) {
            try {
                auto resp = realService->handleRequest(req);
                // 后置增强：指标收集
                metricsCollector->recordSuccess();
                return resp;
            } catch (...) {
                retries++;
                metricsCollector->recordFailure();
            }
        }
        
        // 后置增强：调用链追踪
        tracer->finishSpan();
        return HttpResponse(500, "All retries failed");
    }
};

我在项目中遇到过一个问题：Sidecar代理的延迟。每个请求多跳一次代理，延迟增加1-2ms，看起来不多，但高并发下积少成多。后来我们做了「连接池复用」和「零拷贝」优化，才把额外延迟压到0.3ms以内。

命令模式：Serverless中的函数调用与事件驱动

Serverless（无服务器）架构，说白了就是把「怎么运行」这件事完全交给平台，开发者只关心「做什么」。这背后就是命令模式——每个函数调用就是一个命令对象，包含了执行所需的所有信息。

你想想看，在AWS Lambda或阿里云函数计算里，你上传一段代码，平台负责调度、执行、伸缩。每个请求被封装成一个「命令」，放入队列，由工作节点消费执行。

用Java实现一个简化的Serverless引擎核心：

// 命令接口
public interface FunctionCommand {
    void execute(Context context);
}

// 具体命令：用户定义的函数
public class UserFunctionCommand implements FunctionCommand {
    private String functionName;
    private byte[] payload;
    private String requestId;
    
    public UserFunctionCommand(String functionName, byte[] payload) {
        this.functionName = functionName;
        this.payload = payload;
        this.requestId = UUID.randomUUID().toString();
    }
    
    @Override
    public void execute(Context context) {
        // 1. 从函数仓库加载代码
        FunctionCode code = FunctionRegistry.load(functionName);
        // 2. 创建沙箱环境
        Sandbox sandbox = SandboxPool.borrow();
        try {
            // 3. 执行函数
            byte[] result = sandbox.execute(code, payload);
            // 4. 保存结果
            context.setResult(requestId, result);
        } finally {
            SandboxPool.return(sandbox);
        }
    }
}

// 调用者：事件调度器
public class EventDispatcher {
    private BlockingQueue<FunctionCommand> commandQueue;
    private List<Worker> workers;
    
    public void dispatch(String functionName, byte[] payload) {
        FunctionCommand cmd = new UserFunctionCommand(functionName, payload);
        commandQueue.offer(cmd); // 异步入队
    }
    
    // 工作线程
    class Worker implements Runnable {
        public void run() {
            while (true) {
                FunctionCommand cmd = commandQueue.take();
                Context ctx = new Context();
                cmd.execute(ctx); // 执行命令
            }
        }
    }
}

命令模式在Serverless里的好处很明显：请求可以排队、可以重试、可以记录审计日志。每个命令对象包含了完整的上下文（函数名、参数、请求ID），即使执行失败，也能从队列里重新调度。

我曾经踩过一个坑：命令对象里包含了大量数据（比如几MB的图片），导致命令队列内存爆了。后来我们改成「命令只存元数据+存储路径」，真正的数据通过对象存储传递。嗯，这个教训让我记住了：命令对象要轻量。

三者对比与总结

咱们用一张SVG图来梳理这三个模式在云原生里的关系：

最后做个简单对比：

设计模式	云原生场景	核心价值	我踩过的坑
策略模式	容器编排（K8s调度/HPA）	算法可切换，开闭原则	策略切换没加冷却期，导致Pod雪崩
代理模式	服务网格（Sidecar代理）	非侵入式增强，流量管控	代理延迟优化不够，高并发下性能瓶颈
命令模式	Serverless（函数计算）	请求封装，异步调度	命令对象太大，撑爆内存队列

说白了，设计模式在云原生里不是过时的理论，而是实实在在的架构武器。你想想看，没有策略模式，K8s的调度器怎么支持那么多调度算法？没有代理模式，服务网格怎么做到零侵入？没有命令模式，Serverless怎么实现弹性伸缩？

嗯，今天就聊到这儿。这些模式看着简单，但真正用好，需要你在实际项目中反复打磨。我个人建议：别急着上新技术，先把这些基础模式吃透，云原生架构自然就通了。

---

公众号:蓝海资料掘金营，微信deep3321