4.1 边车 (Sidecar) 模式
多容器部署的第一种也是最常见的模式是边车模式。 边车容器扩展并增强了主容器。 例如，主容器可能是一个 Web 服务器，它可能与一个“logsaver” 边车容器配对，后者从本地磁盘收集 Web 服务器的日志并将它们流式传输到集群存储系统。 图 1 是边车模式的示例。 另一个常见例子是 Web 服务器，它从本地磁盘内容提供服务，该内容由边车容器填充，该容器定期同步来自 git 存储库、内容管理系统或其他数据源的内容。 这两个例子在谷歌都很常见。 边车模式之所以是可能的，是因为同一台机器上的容器可以共享本地磁盘卷。
虽然总是可以将边车容器的功能构建到主容器中，但使用单独的容器有几个好处。
- 首先，容器是资源核算和分配的单位，例如，可以配置 Web 服务器容器的 cgroup [15]，以便它为查询提供持续的低延迟响应，而 logsaver 容器配置为在Web 服务器不忙时利用空闲的 CPU 周期。
- 其次，容器是打包的单位，将服务和日志保存分离到不同的容器中，可以很容易地在两个独立的编程团队之间划分他们的开发责任，并允许他们独立测试，也可以一起测试。
- 第三，容器是重用的单元，因此边车容器可以与许多不同的“主要”容器配对（例如，log saver 容器可以与任何产生日志的组件一起使用）。
- 第四，容器提供了一个故障控制边界，使得整个系统可以优雅地降级（例如，即使 log saver 程序发生故障，Web 服务器也可以继续服务）。
- 最后，容器是部署单元，它允许对每个功能进行升级，并在必要时独立回滚。 （尽管应该注意的是，最后一个好处也有一个缺点——整个系统的测试矩阵必须考虑生产中可能出现的所有容器版本组合，这可能很大，因为容器集通常不能以原子方式升级。当然，虽然单体应用没有这个问题，但组件化系统在某些方面更容易测试，因为它们是由可以独立测试的较小单元构建的。）
请注意，这五个好处适用于所有我们在本文其余部分描述的容器模式。
4.2 特使 ( ambassador ) 模式
我们观察到的下一个模式是特使模式。 特使容器代理与主容器之间的通信。例如，开发人员可能会将使用 memcache 协议的应用与 twemproxy 特使配对。该应用认为它只是与本地主机上的单个内存缓存进行通信，但实际上 twemproxy 正在将请求分片到其他位置的集群中分布式安装的多个内存缓存节点。这种容器模式在三个方面简化了程序员的生活：
- 他们只需要以应用连接到本地主机上的单个服务器的方式来思考和编程
- 他们可以通过在本地机器上运行一个真正的内存缓存实例来独立测试应用，而不是特使。
- 他们可以将 twemproxy 特使与其他应用一起重用，这些应用甚至可以用不同的语言进行编码。
特使之所以是可能的，因为同一台机器上的容器共享相同的本地主机网络接口。图 2 展示了这种模式的例子。
4.3 适配器模式
我们观察到的最后一个单节点模式是适配器模式。与向应用呈现简化的外部世界视图的特使模式相比，适配器向外部世界呈现简化、统一的应用视图。它们通过标准化跨多个容器的输出和接口来做到这一点。适配器模式的一个实际例子是，确保系统中所有容器具有相同监控接口的适配器。当今的应用使用多种方法导出其指标（例如 JMX、statsd 等）。但是，如果所有应用都呈现一致的监控接口，那么单个监控工具就更容易从一组异构应用中收集、聚合和呈现指标。在谷歌内部，我们通过编码约定实现了这一点，但这只有在您从头开始构建软件时才有可能。适配器模式使遗留和开源应用的异构世界，无需修改原始应用，就能够呈现统一的接口。主容器可以通过 localhost 或共享本地卷与适配器通信。如图 3 所示。请注意，虽然一些现有的监控解决方案能够与多种类型的后端进行通信，但它们在监控系统自身使用应用特定的代码，关注点分离 ( Separation of Concerns，SoC ) 是模糊的。
5 多节点应用模式
超越单台机器上的协作容器，模块化容器更容易构建协调一致的多节点、分布式应用。 接下来我们将描述其中的三种分布式系统模式。 与上一节中的模式一样，这些模式也需要系统支持 Pod 抽象。
5.1 领导者 ( Leader ) 选举模式
分布式系统中最常见的问题之一是领导者选举（例如 [20]）。虽然复制通常用于在一个组件的多个相同实例之间共享负载，但复制的另一个更复杂的用途是应用需要将一个副本从一组副本中区分为“领导者”。如果领导者失败，其他副本可以快速取代领导者。一个系统甚至可以并行运行多个领导者选举，例如：确定多个分片中每个分片的领导者。许多库可以执行领导者选举。它们通常很难正确理解和使用，此外，它们受到特定的实现编程语言的限制。将领导选举库链接到应用的替代方案是使用领导者选举容器。每个领导者选举容器都与需要领导者选举的应用实例共同调度，一组领导者选举容器，可以在它们之间执行选举，并且它们可以通过 localhost 向每个需要领导者选举的应用容器提供简化的 HTTP API（例如 becomeLeader、renewLeadership 等）。这些领导者选举容器可以由该复杂领域的专家构建一次，然后应用开发人员可以重复使用随后的简化接口，而不管他们选择什么实现语言。这代表了软件工程中最好的抽象和封装。
5.2 工作队列模式
尽管工作队列（如领导者选举一样）是一个经过充分研究的主题，许多框架都实现了它们，但它们也是可以从面向容器的体系结构中受益的分布式系统模式的例子。在以前的系统中，框架将程序限制在单一语言环境中（例如 Celery for Python [13]。译注：异步任务队列），或者工作和二进制文件的分发交由实现者处理（例如 Condor [21]。译注：作业调度系统）。容器实现 run() 和 mount() 接口的可能性，使得实现通用工作队列框架变得相当简单，该框架可以利用打包了任意处理代码的容器和任意数据，构建一个完整的工作队列系统。开发人员只需构建一个容器，该容器可以在文件系统上接收输入数据文件，并将其转换为输出文件；这个容器将成为工作队列的一个阶段。开发完整工作队列所涉及的所有其他工作都可以由通用工作队列框架处理，无论何时需要类似的系统都可以重用该框架。用户代码集成到此共享工作队列框架中的方式如图 4 所示。
5.3 分散/汇聚模式
我们着重突出的最后一个分布式系统模式是分散/汇聚。 在这样的系统中，外部客户端向 “根” 或 “父” 节点发送初始请求。 此根节点将请求分散到大量服务器以并行执行计算。 每个分片返回部分数据，根节点将这些数据汇聚到原始请求的单个响应中。 这种模式在搜索引擎中很常见。 开发这样一个分布式系统涉及大量样板代码：分发请求、收集响应、与客户端交互等。大部分代码都是非常通用的，同样，就像在面向对象编程中一样，可以通过这样一种方式重构，即可以提供单个实现，只要它们实现特定的接口，就可以与任意容器一起使用。 特别地，为了实现分散/汇聚系统，用户需要提供两个容器。
- 一是实现叶子节点计算的容器； 该容器执行部分计算并返回相应的结果。
- 第二个容器是合并容器； 此容器获取所有叶容器的聚合输出，并将它们组装为单个响应。
通过提供实现这些相对简单的接口的容器，很容易看出用户如何实现任意深度的散布/汇聚系统（如果需要，除了根之外，还包括父级）。这样的系统如图 5 所示。
6 相关工作
面向服务的架构 (SOA) [16] 早于基于容器的分布式系统，并与其许多特征相通。 例如，两者都强调可重用的组件，这些组件具有通过网络进行通信的定义明确的接口。 另一方面，SOA 系统中的组件往往比我们描述的多容器模式粒度更大，耦合更松散。 此外，SOA 中的组件通常实现业务活动，而我们在这里关注的组件更类似于通用库，可以更轻松地构建分布式系统。 最近出现了术语 “微服务” 来描述我们在本文中讨论的组件类型。
网络组件的标准化管理接口的概念至少可以追溯到 SNMP [19]。 SNMP 主要侧重于管理硬件组件，尚未出现管理基于微服务/容器的系统的标准。 这并没有阻止众多容器管理系统的发展，包括 Aurora [7]、ECS [17]、Docker Swarm [18]、Kubernetes [6]、Marathon [8] 和 Nomad [11]。
我们在第 5 节中提到的所有分布式算法都有悠久的历史。 人们可以在 Github 中找到许多领导者选举实现，尽管它们似乎是作为库而不是独立组件构建的。 有许多流行的工作队列实现，包括 Celery [13] 和 Amazon SQS [14]。 分散-汇聚已被识别为一种企业集成模式 [12]。
7 结论
正如面向对象编程引出了面向对象的“设计模式”的出现和规范化一样，我们看到容器体系结构引出了基于容器的分布式系统的设计模式。在本文中，我们识别了我们看到的三种类型的模式：系统管理的单容器模式、紧密协作容器的单节点模式和分布式算法的多节点模式。在所有情况下，容器都提供了许多与面向对象系统中的对象相同的好处，例如可以很容易地在多个团队之间划分实现，并在新的上下文中重用组件。此外，它们还提供了一些分布式系统独有的好处，例如使组件能够独立升级、多种语言编写，以及使整个系统能够优雅地降级。就像几十年前面向对象编程一样，我们相信，容器模式集只会增长，并且在未来几年，通过实现分布式系统开发的标准化和规范化，它们将彻底改变分布式系统编程。
8 参考文献
[1] Docker Engine http://www.docker.com
[2] rkt: a security-minded standards-based container engine https://coreos.com/rkt/
[3] Erich Gamma, John Vlissides, Ralph Johnson, Richard Helm, Design Patterns: Elements of Reusable Object-Oriented Software, AddisonWesley, Massachusetts, 1994.
[4] Jeffrey Dean, Sanjay Ghemawat, MapReduce: Simplified Data Processing on Large Clusters, Sixth Symposium on Operating System Design and Implementation, San Francisco, CA 2004.
[5] Apache Hadoop, http://hadoop.apache.org
[6] Kubernetes, http://kubernetes.io
[7] Apache Aurora, https://aurora.apache.org.
[8] Marathon: A cluster-wide init and control system for services, https://mesosphere.github.io/marathon/
[9] Managing the Activity Lifecycle, http://developer.android.com/training/basics/activitylifecycle/index.html
[10] Brendan Burns, The Distributed System ToolKit: Patterns for Composite Containers, http://blog.kubernetes.io/2015/06/the-distributedsystem-toolkit-patterns.html
[11] Nomad by Hashicorp, https://www.nomadproject.io/
[12] Gregor Hohpe, Enterprise Integration Patterns, Addison-Wesley, Massachusetts, 2004.
[13] Celery: Distributed Task Queue, http://www.celeryproject.org/
[14] Amazon Simple Queue Service, https://aws.amazon.com/sqs/
[15] https://www.kernel.org/doc/Documentation/cgroupv1/cgroups.txt
[16] Service Oriented Architecture, https://en.wikipedia.org/wiki/Serviceoriented architecture
[17] Amazon EC2 Container Service, https://aws.amazon.com/ecs/
[18] Docker Swarm https://docker.com/swarm
[19] J. Case, M. Fedor, M. Schoffstall, J. Davin, A Simple Network Management Protocol (SNMP), https://www.ietf.org/rfc/rfc1157.txt, 1990.
[20] R. G. Gallager, P. A. Humblet, P. M. Spira, A distributed algorithm for minimum-weight spanning trees, ACM Transactions on Programming Languages and Systems, January, 1983.
[21] M.J. Litzkow, M. Livny, M. W. Mutka, Condor: a hunter of idle workstations, IEEE Distributed Computing Systems, 1988.
[22] https://linuxcontainers.org/
来源：design patterns for container-based distributed systems
本文作者 ： cyningsun
本文地址 ： https://www.cyningsun.com/11-13-2022/design-patterns-for-container-based-distributed-systems-cn.html
版权声明 ：本博客所有文章除特别声明外，均采用 CC BY-NC-ND 3.0 CN 许可协议。转载请注明出处！
