Owl深夜翻译：分布式系统工具包模式（Owl算法2.0）

总结：基本上，这意味着不仅将整个应用程序，而且还将任何一台服务器的各个部分划分为可以轻松参数化和重用的模块化容器。 那么，这个模块化容器服务的实现者就是。 指共享文件系统、内核命名空间和地址的一组容器。

过去几年，容器已成为打包和部署代码的流行方式。 容器镜像解决了现有打包和部署工具带来的许多问题。 除了是第一个之外，它们还为构建分布式应用程序提供了新的想法。 正如 SOA 鼓励将应用程序划分为模块化、内聚的服务一样，容器应该进一步鼓励将这些服务划分为紧密协调的模块化容器。 通过构建应用程序边界，容器允许用户使用模块化、可重用的组件构建服务，从而使服务比使用独立容器构建的应用程序更加可靠和可扩展，并且构建速度更快。

在很多方面，从虚拟机到容器的演变类似于从独立应用程序到模块化、面向对象的应用程序的转变。 容器镜像提供的抽象层与面向对象编程中类的抽象边界有很多共同点，也提高了开发人员的效率和程序质量。 正如正确的编码方法是将关注点划分为模块化对象一样，将应用程序打包到容器中的正确方法是将关注点划分为模块化容器。 从本质上讲，这意味着不仅将整个应用程序，而且还将单个服务器中的各个部分划分为多个可以轻松参数化和重用的模块化容器。 它就像现代语言的标准语言库，允许大多数应用程序开发人员将其他人创建的模块化容器组合在一起，以使用高质量组件更快地构建应用程序。

考虑模块化容器的好处有很多，尤其是模块化容器：

容器可以用来支持整个团队，也可以跨团队使用，以加快应用程序开发社区重用支持敏捷团队，因为容器边界是不同团队之间的自然分界线。    通过支持关注点分离并专注于开发特定功能来减少复杂的依赖关系和不可测试的组件。    

从模块化容器构建应用程序意味着要考虑协同工作以提供服务的共生容器组。而不是提供服务的容器。 在 Kubernetes 中，这种模块化容器服务的实现者是 Pod。 Pod 是一组共享文件系统、内核命名空间和 IP 地址的容器。 Pod是K8s集群中调度的基本单位。 这是因为 Pod 内容器的共生性质要求它们一起调度在同一台机器上，而可靠实现这一点的唯一方法就是使用容器组作为原子调度单元。

当您考虑 Pod 时，自然会出现模块化应用程序开发的几种常见模式。 这些问题一再出现。 我相信，随着 Kubernetes 开发的进展，您会发现更多这些模式，但以下是常见的三种模式：

示例 1：Sidecar 容器

Sidecar 容器已扩展。 加强主容器。 集成并完善现有容器。 例如，假设您有一个运行 Nginx Web 应用程序的容器。 再添加一个容器，将文件系统与git仓库同步，​​容器之间共享文件系统，实现git提交和部署。 然而，这种模块化实现允许 git 同步器在单独的容器中开发并在不同的 Web 服务器之间重用。 这种模块化允许您创建和测试单个 git 同步应用程序，然后在多个应用程序中使用它。 另外，如果另一个团队开发了这个工具，则无需重新开发它。

示例 2：Ambassador 容器

Ambassador 容器代理从外部到本地的连接。 例如，我目前有一个具有多个读取器和一个写入器的 Redis 集群。 您可以创建一个包含主应用程序和 Redis 大使容器的 pod。 大使容器充当代理，分离读写请求并将其转发到相应的服务器。 这两个容器共享一个网络命名空间，这意味着它们共享一个 IP 地址，因此主应用程序可以使用 localhost 访问大使服务，而无需通过服务发现。 从主应用程序的角度来看，redis 集群似乎已连接到本地主机。 这种方法不仅非常方便，因为它允许不同的团队进行自我管理；由于您处于开发环境中，因此您可以跳过代理并直接连接到 Redis 集群。

示例 3：适配器容器

适配器容器标准化输入和输出。 假设您当前需要监控N个应用程序。 每个应用程序可能使用不同的方法（JMX、StatsD等）来输出监控数据。 然而，所有监控系统都希望使用一致的数据模型来管理收集的数据。 通过使用适配器模式组合容器，您可以创建组合应用程序和适配器容器的 Pod，以将同类监控数据转换为单个统一的表示形式。 这些 Pod 还共享命名空间和文件系统，使两个容器之间的协作变得简单轻松。

参考

Sidecar模式
Ambassador模式