猫头鹰的深夜翻译：分布式系统Toolkit模式
猫头鹰的深夜翻译：分布式系统Toolkit模式
过去几年容器逐渐成为了打包和部署代码的流行的方式。容器镜像解决很多现有的打包和部署工具所带来的问题，初次以外，还为我们提供了构建分布式应用的全新的思路。就如SOA提倡将应用拆分为模块化的内聚的服务，容器应当进一步提倡将这些服务拆分为紧密协作的模块化容器。通过构建应用边界，容器使用户能够使用模块化，可重用的组件构建其服务，从而使得服务比单机容器构建的应用程序更可靠，更具可扩展性并且构建速度更快。
从VM向容器的演变从各种角度来说就如同当年从单机应用转化为模块化的面向对象的应用程序。容器镜像提供的抽象层与面向对象编程中类的抽象边界有很大的共同点，而且也提高了开发者的效率和程序的质量。就像正确的编码方式是将关注点分离为模块化对象一样，在容器中打包应用程序的正确方法是将关注点分离为模块化容器。根本上来说，这意味着不仅要将整个应用程序分解，而且要将任何一个服务器中的各个部分分解为多个模块化容器，这些容器易于参数化和重复使用。这就像现代语言中的标准语言库，大多数应用程序开发人员可以将由其他人编写的模块化容器组合在一起，并使用更高质量的组件更快地构建应用程序。
从模块化容器方面进行思考的好处很多，特别是模块化容器提供以下内容：
加快应用的开发，因为容器可以在团队甚至是大型社区之间进行复用 支持敏捷团队，因为容器边界是一个天然的边界，划分给各个团队。 支持关注点分离，并专注于开发特定功能从而减少复杂的依赖和不可测试组件。
从模块化容器构建应用程序意味着考虑协作提供服务容器的共生组，而不是一个容器提供一个服务。在Kubernetes中，这种模块化容器服务的实施者是Pod。一个Pod是指一组共享文件系统，内核命名空间和IP地址的一组容器。Pod在K8s集群中是调度的基本单位，正是因为Pod中容器的共生特性要求它们共同安排在同一台机器上，而可靠地实现这一点的唯一方法是将容器组作为原子调度单元。
当你从Pod的角度思考时，自然会出现一些模块化应用程序开发的通用模式，这些模式会多次重复出现。我相信，随着我们在Kubernetes的开发中向前发展，将会发现更多这些模式，但这里有三个我们常见的模式：
例子1：Sidecar容器
Sidecar容器拓展并且加强主容器，他们融合当前已有的容器并且将它们完善。举个例子，假设有一个运行这Nginx web应用的容器。添加另一个容器将文件系统与git仓库同步，在容器间共享文件系统，从而实现git的提交并部署。但是这种模块化实现使得git同步器可以交给另一个容器开发，并且跨不同的web服务器复用。因为这种模块化，你只需要编写并测试单个git同步应用并且提供给多个应用使用。而如果有别的团队开发了这个工具，你甚至不需要重复开发。
例子2：Ambassador容器
Ambassador容器代理外界至本地的连接。比如，现在有一个Redis集群，包含多个读者和单个写者。 你可以创建一个Pod，包含主应用和Redis ambassador容器。ambassador容器作为代理分离读写请求分别交给对应的服务器。因为这两个容器共享一个网络命名空间，即他们共享一个IP地址，因此主应用可以用localhost访问ambassador服务，无需通过服务发现。从主应用的视角来看，就仿佛在localhost上连接了redis集群。这种方式非常方便，不仅因为不同的团队可以管理自己的组件，而且因为在开发环境中，你可以跳过代理，直接连接到Redis集群上。
例子3：Adapter容器
Adapter容器标准化输入输出。假设现在需要监控N个应用，每个应用可能使用了不同的方法来输出监控数据（比如JMX, StatsD等）。但是每个监控系统都希望用一个一致的数据模型来管理收集的数据。通过使用Adapter模式来组合容器，你可以创建一个pod将应用容器和适配器容器组合起来，从而将同质的监控数据转化为单个同一个的表现形式。同样的，因为这些Pod共享命名空间和文件系统，这两个容器间的协作简单明。