共计 1379 个字符，预计需要花费 4 分钟才能阅读完成。
这是由 Kubernetes 创始人发表的论文，总结了基于容器的分布式系统的设计模式，让我们来一览究竟吧。
论文认为，继 OOP（面向对象编程）所引领的软件开发革命之后，如今似乎在分布式系统开发中也发生着一场相似的革命：基于容器化组件构建的微服务架构。
容器的一大独特优势在于：良好的边界——恰好适合应用开发的隔离性。
作者总结了一些设计模式，并且分为三大类型：
Single-container management patterns
容器的传统接口有 run(), pause(), stop()
可以有更丰富的接口
“向上看”的视角：metrics, config, logs 等，通常用 HTTP+JSON 来暴露
“向下看”的视角：lifecycle（提供生命周期回调钩子）, priority（为了空出资源给高优先级任务，甚至能提前关掉低优先级任务），”replicate yourself”（迅速创建一组相同的服务容器来应对突发流量）
接下来两类都依赖 Pod 抽象（Kubernetes 有提供），因为都涉及容器编排了，而且已进入 Sevice Mesh 这门新概念的范围。
Single-node, multi-container application patterns
多个容器组成一个原子单位
Sidecar 模式
例如：web server + log collector
前提是容器间能共享“存储卷”之类的资源
顺带一提，为什么要用多容器，而非容器内多进程？
资源审计和分配：这点很重要，虽然多进程也勉强能做，但多容器做得更成熟
职责划分、解耦
重用：如果一个容器包含多种进程，就笨重而难以重用了，小巧的单用途容器更适合重用
故障隔离：重启一个容器，比修复容器内的故障进程要容易多了
交付隔离：每个容器能独立地升级 / 降级
Ambassador 模式
类似于 OOP 的 proxy 模式
例如：memcache + twemproxy，这类模式是单结点的，因此 twemproxy 要和其中 1 个 memcache 部署到同一结点上
前提是容器间能共享 localhost 网络接口
Adapter 模式
例如：统一的 metrics 接口（JMX，statsd 等统一收集到 HTTP 端点）
可以免于修改已有的容器（因为已经以容器作为软件开发的单位了）
Multi-node application patterns
Leader election 模式
领导者选举这件事已经有很多库了，但往往对编程语言有所限定
容器则对编程语言中立
容器只需构建一次就能重用，高度贯彻了抽象和封装的原则
Work queue 模式
传统的工作队列框架对编程语言有所限定
实现了 run(), mount() 接口的容器，可作为“工作”的抽象
基于此可打造一种通用的工作队列框架（可能是 Kubernetes 的未来方向）
虽然没给例子，但有些类似 Mesos 的可插拔调度器架构
Scatter/gather 模式
这样传递请求：client->root->server
root 结点把请求分发给很多 servers，再把它们的响应汇总到一起，交给 client
例如：搜索引擎，分布式查询引擎
多个 leaf 容器 + 1 个 merge 容器，就能实现通用的 scatter/gather 框架（可能也是 Kubernetes 的未来方向）
结语
总之，论文将容器视为软件开发的一等公民，像 OOP 的对象一样重要，提倡单用途可组合可重用的容器。这似乎是对 UNIX 编程艺术的重申。
