容器设计模式：从部署工具到分布式系统的积木

容器最初只是部署工具。把代码和依赖打包成一个单元，到处运行——这个故事没错，也确实有用。但这只是容器价值的一半。另一半藏在当我们不再把容器当作单个应用的交付方式，而是开始把它当作可以与其他容器组合的积木时。

软件工程经历过类似的转变。1990年代，面向对象编程给应用代码提供了清晰的边界，让我们可以基于此进行组合。从这个边界中诞生了设计模式——每个程序员最终都会内化的标准解决方案库。容器让分布式系统经历了同样的过渡。

过去十年，一些模式逐渐成形。它们按协调范围分为两类：三个模式描述容器如何在单台机器上协作，另外三个描述容器如何在多台机器间协调。这些不是规则，而是分布式系统工程师反复解决的同类问题的答案。

单节点协调模式

Sidecar（边车）是最直观的。主容器跑核心业务逻辑，边车容器跑辅助功能——日志转发、监控代理、配置重载。两者共享本地存储和网络命名空间，但生命周期独立。一个挂了不影响另一个，升级也可以分开进行。

Init Container（初始化容器）解决启动顺序问题。主容器开始前，初始化容器先跑完——拉取配置、生成证书、等待依赖就绪。它保证主容器启动时环境已经准备完毕，而且初始化失败会阻断主容器启动，避免带病运行。

Adapter（适配器）处理接口转换。老系统输出格式A，新系统需要格式B，不用改代码，加个适配器容器做转换。它让异构组件能无缝协作，是渐进式改造的关键。

多节点协调模式

Leader Election（领导者选举）解决分布式系统中的"谁说了算"。多个容器副本竞争成为领导者，胜者处理写操作，败者待命或只读。Kubernetes通过Lease API原生支持，避免脑裂。

Work Queue（工作队列）把任务生产者和消费者解耦。生产者把任务丢进队列就返回，消费者按需拉取处理。队列本身可以是Redis、RabbitMQ或云厂商服务。这种模式让扩缩容变得简单——消费者不够就加容器，任务堆积就减。

Scatter/Gather（分散/聚合）应对分片查询。请求到达后，分散到多个容器并行处理，再聚合结果返回。搜索、MapReduce都是典型场景。关键是聚合容器要处理部分失败——超时重试、降级返回、错误标记，不能一颗老鼠屎坏一锅汤。

这些模式的选择取决于你的约束。单节点模式利用本地通信的低延迟，多节点模式接受网络开销换取水平扩展。没有银弹，只有对问题的准确识别和对 trade-off 的清醒认知。

容器设计模式的价值不在于记住六个名字，而在于理解背后的思想：把系统拆成边界清晰的单元，通过标准接口组合，让每个单元可以独立演进。这和当年面向对象设计模式解决的问题本质相同，只是舞台从单机内存扩展到了分布式网络。