Docker 在 Uber 服务部署中的应用

204次阅读

共计 3093 个字符，预计需要花费 8 分钟才能阅读完成。

【编者的话】快速创新的迫切要求，使得 Uber 开始在服务部署中应用 Docker。这篇文章讲述了部署方式的转变过程，强调在全面容器化之前，必须做充足的准备。

无论你对 Uber 的看法如何，Uber 无疑是创新的同义词，因为它在颠覆交通行业的同时引领了共享经济。像 Uber 这样的最快创新者，就像 Microsoft, Apple 和 Amazon 公司一样，都面临一个问题：一旦你开始创新并且取得成功，你不得不一直保持这样快的创新速度，这就导致了下面的后果：有时你看不到更远大的前景，有时会被途中的障碍绊倒。

今年初，Uber 发现自己就处于这样的境地。那时候，软件工程师 Casper S. Jensen 加入了 Uber 公司的计算机平台团队。

在 Dockercon EU 的第一天，Jensen 说 Uber 应用有非常易用的用户界面，看起来就是一个简单的应用；“实际上 Uber 是一个非常非常复杂的产品”，“应用只是冰山之一角”，底层包含了无数的功能特性。要知道，目前 Uber 面对的是 69 个国家的不同市场和法律，每天安排百万次行程，有 4,000 员工使用 Uber 平台。

那时候，Jensen 和团队中的其他四个人刚刚加入 Uber 不久。工作简直是“一团糟”，他们正在寻求一种解决方案。

这是去年冬天他们的开发流程：

编写服务 RFC（Request for Commments，请求评论）—— Uber 是一家极其依赖反馈的公司，在启动一项新服务时，他们首先描述该服务的架构和理念，发布到邮件列表中。
收集反馈——例如，“你们知道其他人也在做类似的事情吗？”——集中精力，力争在早期就找出错误。
手工列出该服务的所有依赖。
开始开发服务。
等待基础设施团队编写服务的依赖。
等待 IT 确定服务的位置。
等待基础设施团队提供服务。
部署到开发服务器，测试。
部署到生产环境的服务器。
监控迭代。

他说，步骤 5-7“是特别特别令人痛苦的部分，很容易耗费数日乃至数周的时间。”原因何在？“到不是说这些步骤特别难，大部分环节我们都有相应的脚本，”只包括大约十行的集成代码。

“简单是简单，但是这些脚本的扩展性差，因为公司里只有少数人真正地知道如何扩展且不会破坏已有的部署”，Jensen 说。再加上一些小错误——例如，本来应该是连接线，结果写成了斜线——最后导致所有的服务都慢得要命。

2015 年 2 月，在一封内部邮件中，他们设置了下列目标：

Jensen 说他们想要做到：

允许服务的拥有者有专用的服务器切片，他们自行决定安装什么，我们不干涉，但是不能影响其它的服务。
并且，他们的安装过程也不用我们参与。

必须得有所改变了，还不能破坏现有的服务。

如果一家公司有如此快速增长的基础设施，自然会有一些限定，如 Jensen 所讲，“无论如何，我们必须保证基础设施快速增长，避免拖慢开发团队的高速开发流程”。

这不仅是因为 Uber 要求 7×24 的可用性以及支持无数的本地化特性，更重要的是，“没有任何一个人能够看到 Uber 的所有服务，每个人只能看到自己从事的部分。”他列举了几个特性，像 UberPOOL、UberKITTENs、UberIceCream 和 UberEATS，每一个都在“增加新功能，好像世界末日到了一样”。Uber 的耀眼成功，是建立在全方位超快发展的基础之上的，包括数据中心、服务器和基础设施。需要找到保持增长的解决方案。

“我们希望有非常方便的流程和基础设施，这样开发者就能非常快地增加新功能。其中最重要的一个部分是创建新服务的流程，”Jensen 说，“我们意识到这不就是要用 Docker 吗。”理由很简单，“很容易向别人解释 Docker 的作用，人们早就了解过它，理解基本的概念”。每个人都有自己喜欢使用的容器，因此开发团队很容易接受 Docker。

他们心想，“我们都能写代码，这还不是小菜一叠？两天就能干完。”实际上不是那么回事。他们 2 月份作出决定，直到仲夏，才真正用上 Docker。

Jensen 解释说，用了 Docker，“一切都有所改变，思路也必须随之转换。”

采用 Docker 的最大障碍是 Uber 内部使用的集群管理系统 uDeploy。它要能在支持回滚的前提下做持续的滚动升级。它包含很多报错的触发器，像健康检查或者发生故障时的图形化显示。它还支持有错就回滚的负载测试和集成测试。uDeploy 包括：