| 【编者的话】作者从八个方面对当下热门的微服务、容器入手，提出一些问题与建议。读者可以通过此文理解这些技术在企业中的应用场景，其中一些问题值得读者深思熟虑。 2014注定会成为IT发展史上的重要一年。毫不夸张地说，Docker（或者说容器）和微服务正在革新交付和运行软件服务的方式。与这种革新随之而来的是开发者的兴趣和热情，当然也有很多的炒作和趋之若鹜。但在所有这些议论中，我们要牢记它真的还很年轻，不仅仅是技术，还有围绕着微服务、容器以及Docker的流程与实践。 这里有关于容器的8个问题，我认为每个公司都需要在做任何决定之前进行确定：存储、容错、交付模式、发布策略、所有权、补丁、支持和许可。 不要误会我的意思：我觉得微服务和物联网将成为我们设计与交付IT服务方式的核心部分（在越来越多的分散的计算能力与更大数据量被拉回到中央位置之间有一种有趣的张力。因为我们无法处理它，否则它将是一篇不同博文的话题）。在XebiaLabs roadmap上微服务扮演了重要的功能角色，我认为每一个公司都应该关注他们，并且容器是一个非常有前途的候选实现技术。 那些号称要“Docker化一切”的公司真的相当勇敢，用一个更微妙的方式来看它：如果你已经认同并证明了容器的优势，特别是Docker－它可 以用于应用程序的交付，那么你就会有这样一种任你自由支配的可以解决复杂的、尚未解决的问题的方案的技术资源，并且愿意去通过生产和重新实现附带任何 1.x版的技术然后并采用，现在来说它也是有道理的。 然而你要是完全基于“containers will make everything better”来容器化一切，并期待能结合现有的现成解决方案，让你的团队在一些最佳实践上训练，并迅速地有一个稳定、安全的运行平台并且在运行中，它将会给你带来很多的惊讶。 我相信微服务会是大的趋势，所以我认为企业也会不断探索容器（Docker、Mesos、Rocket或者任何不久我们将无疑会看到的其他替代品）如何融入到工作中。在最近的一些讨论的基础上，我认为2015年企业应该考虑下这八个问题。 1. 存储也许现在最明显的技术问题是：如何处理持久、可写的存储容器？如何以及在何处存储数据？如何从容器中连接到它？如何复制与备份它？在容器启动的情况下如何让数据随着容器迁移以及如何迅速地实现它？2. 容错在一个微服务环境中，寻找其它服务的常见方法是查询服务Registry，以及/或者为服务使用确定的名称并通过类似DNS 这样的方案根据名称查询。在之前的环境中，启动一个新的虚拟机可能需要几分钟，而采取服务注册或是DNS缓存来更新相对来说耗时比较少。用容器的话只需要 几秒就可以，服务的重新绑定很快会成为一个瓶颈，尤其是当有许多容器同时发生故障时。我最近看到了一个令人印象深刻的解决方案，它使用的是商品硬件，其能够从一个全机架故障中恢复－重新启动、重新挂载和重新绑定10000个容器－不超过10秒。但是这一切都是定制的引擎和实验...在货架上你得不到这种东西。 你的容错要求有哪些？你与容器会如何定位这些？ 3. 交付模式如果你要部署容器，开发商将要交付什么？他们是否要交付容器的描述符（Dockerfile或者其他类似的）？如果交付 的话，你如何传送描述所引用的所有外部资源？或者开发商是否会提供“编译过”的镜像，使之避免了外部的依赖问题但是增加了可交付的包大小并且使给接收者更 难检查或验证什么是真正要运行的。或者你是否希望避免要求开发者学习另一种“交付格式”（来让开发人员学习Puppet、Chef或类似配置的“语言”的难度是我们遇到的一些组织 试图向开发商介绍他们来作为交付方式的主要问题之一），并正在寻找某种方式从开发商交付的同一代码产品中“自动生成”容器描述或是镜像呢？ 4. 发布策略你的服务是否独立，使你能够在每一个提交或是设定的安排后都能部署每个服务到生产中？还是说你需要绑定多个服务在最新的 候选版本已经测试过的发布队列里。如果成功的话，基本上每天发布还是每周发布？如果是后者，那么你会使用多少个发行版本？企业组织一个、每个团队一个或者 每个业务部门一个呢？随着发布队列里候选版本的的数量上升，测试失败的机会通常也会增加。你是否会中止发布队列，如果有测试失败了，因为这一个问题从而可能会阻止199个“状态良好”的服务上线吗？或者尝试移除那个“烂苹果”，并重新测试其余的候选版本是否有意义呢？ 对于实际生产部署来说，你是否会创建一个完整的“mirror”环境（可能是一个您用于在发布队列里的最广泛的测试？）？还是你只是沿着现有的服 务来部署新的服务？如果是这样，你怎么处理这逐渐的血流不止的问题，请牢记新服务可能不会直接被用户使用？还是你依靠快速来回切换如果有问题的话，来代替 完全切换到新的服务呢？如果是这样，你是否会一次切换一个服务（当然是相互依存服务的集群）或者是一次切换所有的服务？ 5. 所有权关于容器的交付模式的决定部分，也是由谁拥有/负责这一块的交付成果来决定的。业务操作是否简单地提供容器运行环境以及在 容器内的发生的任何问题的开发商所要负的责任？业务操作是否还负责从每个开发商提供的容器继承的“基本的描述符”或“基础镜像”？如何确定一个问题是否由 镜像的“基础“部分造成的，还是说开发商添加的部分，特别是那些允许开发商修改或者覆盖基础镜像的技术部分所造成的？还有一个与有关安全方面的问题：你是否能充分隔离/沙箱操作你的容器，得以防止其影响其它系统？或者你只是相信，由开发团队提供的描述符/镜像不会做“坏事” - 无意或是故意的呢？ 如果你想让开发团队来责任提供完整的容器描述并且您也信任他们会做正确的事，而且他们的容器配置文件系统的条例来说，你问他们是否会愿意支持生产线上的系统？ 6. 补丁你需要有更改运行系统的能力，如应用安全补丁或其他重要变化？如果你正在考虑采取一成不变的基础设施建设的原则，你能多快更新所有受影响的容器定义或镜像，并且发布新版本？如果补丁可以应用到开发团队使用的基本描述符或镜像中，你是否能在他们的构建过程中“覆盖”基础镜像，以及是否需要开发团队来改变他们的源代码或者构建定义。如果你正在考虑修改运行的容器，请确保容器技术支持这一点，并且还提供了一个审计线索。您将如何确保对运行容器所做的任何更改可以返回到容器定义？ 7. 支持最近我听说这个故事：一个公司为了一个支持合同在一个操作系统运行Docker。但在Docker中运行容器是使用不支持的操作系统的基础镜像。突然，“机器”（即容器）都不能有效托管主机支持的应用程序。当他们面临这些问题时，他们的支持合同却帮不了他们。你是否有必需的支持解决方案无论你的容器运行在什么地方？ 8. 许可如果你在每个系统中使用的是被许可的服务组件，你是否检查了供应商的有关容器的许可政策？供应商是否考虑每个容器里是一个独 立的系统，还是说他们只是简单地认为托管容器框架是系统的进程而已？换句话说，如果你现在在一台机器上运行10个许可程序的实例，你的成本是否会保持不变 如果你在容器内运行它们，还是说在一个完整的订单或幅度内它将会增加？这么多的问题...但是答案是什么？不幸的是，基于这么多谈话，我觉得在这一点上坦率的回答是：没有人知道。在一些地区有很多有趣的想法，但还没有明显的赢家。其他的问题仅仅现在才显示在讨论的雷达中，而且在许多情况下，“正确”答案很大程度上取决于企业的具体情况。 幸运的是，鉴于正在发生的这些事，我想在明年同一时间我们会了解的多得多。这是一个令人兴奋的2015年！ 原文链接：8 Questions You Need to Ask About Microservices, Containers & Docker in 2015 （翻译：田浩浩 校对：李颖杰） ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 译者介绍 田浩浩，悉尼大学USYD硕士研究生，目前在珠海从事Android应用开发工作。业余时间专注Docker的学习与研究。希望通过DockerOne把最新最优秀的译文贡献给大家，与读者一起畅游Docker的海洋。 |
