译者序
本文发表于 2016 年，作者为 Borg、Omega 和 Kubernetes 的主要开发： Brendan Burns 和 David Oppenheimer， 其他相关论文包括：
- 2015 《Large-scale cluster management at Google with Borg》
- 2016 《Borg, Omega, and Kubernetes：Lessons learned from three container management systems over a decade》
文章总结了云原生下的多种设计模式，能够对如何设计分布式系统有所启发。从本论文中你也可以看到容器管理系统 ( Kubernetes )、Service Mesh (Istio)、 监控系统 ( Prometheus ) 等诸多明星系统的影子，进而推测未来云原生领域的发展方向。
1 导言
在 1980 年代末和 1990 年代初，面向对象编程彻底改变了软件开发，普及了将应用构建为模块化组件集合的方法。 今天，我们在分布式系统开发中看到了类似的革命，基于容器化软件组件构建的微服务架构越来越受欢迎。 因为容器之间的隔离优势，容器 [15] [22] [1] [2] 特别适合作为分布式系统中的基本“对象”。 随着这种架构风格的成熟，我们看到了设计模式的出现，就跟面向对象程序所做的一个道理——以对象（或容器）的方式思考抽象掉代码的低级细节，最终揭示各种应用和算法共有的高级模式。
本文描述了我们在基于容器的分布式系统观察到的三种设计模式：容器管理的单容器模式、紧密协作容器的单节点模式和分布式算法的多节点模式。 与之前的面向对象模式一样，分布式计算的这些模式实现了最佳实践，简化了开发，让使用它们的系统更可靠。
2 分布式系统设计模式
在使用面向对象编程多年之后，设计模式出现并被记录了下来[3]。 这些模式编码和规范化了解决特别常见编程问题的一般方法。 这种编码进一步提高了编程的总体水平，因为它使经验不足的程序员更容易产出高质量的代码；同时，它促进了可重用库的发展，使代码更可靠，开发速度更快。
当今分布式系统工程的最新技术看起来更像是 1980 年代早期的编程时期，而不是面向对象开发的时期。 然而，从 MapReduce 模式 [4] 将 “大数据” 编程的力量带到广阔的领域和开发者群体的成功中可以清楚地看出，建立正确的模式集可以显着提高分布式系统编程的质量、速度和可达性。 但即使 MapReduce 的成功很大程度上也仅限于单一的编程语言，因为 Apache Hadoop [5] 生态系统主要是用 Java 编写的。 为分布式系统设计开发一套真正完备的模式需要一个非常通用的、语言中立的工具来表示系统的原子元素。
值得庆幸的是，过去两年 Linux 容器技术的采用率急剧上升。容器和容器镜像正是分布式系统模式开发所需的抽象。到目前为止，容器和容器图像仅通过作为一种更好、更可靠的方法从开发到生产交付软件，就获得了广泛的应用。通过紧密的封装，依赖自治，并提供原子部署标记（“成功”/“失败”），它们极大地提升了以前在数据中心或云中部署软件的最先进技术的水平。但容器有可能不止于此——我们相信它们注定会类似于面向对象的软件系统中的对象，将使分布式系统设计模式的发展成为可能。在下面的部分中，我们解释了为什么我们认为必然如此，并描述了我们看到的一些模式，这些模式将在未来几年中规范和指导分布式系统的工程。
3 单容器管理模式
与对象边界 ( boundary) 非常相似， 容器为定义接口提供了一个自然的边界 ( boundary) 。容器不仅可以通过此接口暴露应用特定的功能，还可以为管理系统暴露钩子 (hooks)。
传统的容器管理接口非常有限。容器有效地暴露三个动词：run() pause() 和 stop()。虽然此接口很有用，但更丰富的接口可以为系统开发和运维人员提供更多能力。鉴于几乎所有现代编程语言都普遍支持 HTTP Web 服务器，并且对 JSON 等数据格式的广泛支持，因此很容易定义一个基于 HTTP的管理 API，除了其主要功能之外，还可以通过让容器在特定端点 (endpoints) 托管 Web 服务器来“实现”其他功能。
在北向方面，容器可以公开一组丰富的应用信息，包括应用特定的监控指标（QPS、应用健康状况等）、开发者感兴趣的分析 (profiling) 信息（线程、堆栈、锁争用、网络消息统计信息） 等）、组件配置信息和组件日志。 作为此的实际例子，Kubernetes [6]、Aurora [7]、Marathon [8] 和其他容器管理系统允许用户通过特定的 HTTP 端点 ( endpoints )（例如 “/health”）定义健康检查。 对我们前面所描述的之外其他元素，北向 API 的标准化支持更为罕见。
在南向方面，容器接口提供了一个自然之选来定义生命周期，这使得编写受管理系统控制的软件组件变得更加容易。例如，集群管理系统通常会为任务分配“优先级”，即使集群超额订阅，高优先级任务也能保证运行。这种保证是通过驱逐已运行中的低优先级任务来实现的，低优先级任务将不得不等待资源可用再执行。驱逐可以通过简单地杀死优先级较低的任务来实现，但这会给开发人员带来不必要的负担，让他们应对代码中任意死亡的情况。相反，如果在应用和管理系统之间定义了一个规范的生命周期，遵从定义的契约以后，应用组件将变得更易于管理；同时，开发人员依赖契约以后，系统的开发变得更容易。例如，Kubernetes 使用 Docker 的“优雅删除”功能，通过 SIGTERM 信号警告容器它将被终止，然后在应用定义的时间窗口之后再发送 SIGKILL 信号。这允许应用完成运行中的操作、将状态刷新到磁盘等再干净地终止。可以想象扩展该机制以提供对状态序列化和恢复的支持，从而使有状态分布式系统的状态管理变得更加容易。
考虑一个更复杂生命周期的例子，Android Activity 模型 [9]，它支持一系列回调（例如 onCreate()、onStart()、onStop() 等）和一个规范定义的系统如何触发回调的状态机。如果没有这个规范的生命周期，很难开发健壮、可靠的 Android 应用。 在基于容器的系统的上下文中，泛化为应用定义的在创建容器时、启动时、终止前等调用的钩子 (hooks)。另一个容器可能支持的南向 API 的例子是“复制 (replicate) 自己”（以横向扩容服务）。
4 单主机多容器应用模式
除了单个容器的接口之外，我们还看到了跨容器设计模式的出现。 我们先前确定了几种这样的模式 [10]。单节点模式由共同调度到单个主机上的共生容器组成。 容器管理系统支持将多个容器作为一个原子单元共同调度，抽象 Kubernetes 称为 “Pods”，Nomad [11] 称为“任务组”，这是启用我们在本节中描述的模式所必需的特性。
