论文解读：Design patterns for container-based distributed systems
这是由Kubernetes创始人发表的论文，总结了基于容器的分布式系统的设计模式，让咱们来一览究竟吧。node
论文认为，继OOP（面向对象编程）所引领的软件开发革命以后，现在彷佛在分布式系统开发中也发生着一场类似的革命：基于容器化组件构建的微服务架构。web
容器的一大独特优点在于：良好的边界——刚好适合应用开发的隔离性。编程
做者总结了一些设计模式，而且分为三大类型：设计模式
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
多个容器组成一个原子单位app
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编程艺术的重申。框架