Docker 正在驱动一个全新的可扩展的 Uber

作者：翻译：柳泉波 2015-12-02 11:23:38

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

【原文编者的话】快速创新的迫切要求，使得 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 不久。工作简直是“一团糟”，他们正在寻求一种解决方案。

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

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

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

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

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

Jensen 说他们想要做到：

• 允许服务的拥有者有专用的服务器切片，他们自行决定安装什么，我们不干涉，但是不能影响其它的服务。
• 并且，他们的安装过程也不用我们参与。
• 必须得有所改变了，还不能破坏现有的服务。

Uber 需要克服的自身问题

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

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

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

容器带来的痛苦

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

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

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

• 每周 4,000 次升级
• 每周 3,000 次构建
• 每周 300 次回滚
• 管理系统包含的 600 多个服务

做不到完全不使用 uDeploy ，所以 Uber 团队决定同时部署旧有的服务和 Docker 服务。

“我为此花了很多时间，检查每一个功能，添加支持以便能够把它封装为 Docker 服务，” Jensen 说，“ uDeploy 支持显示标准输出和标准错误，我们必须在 Docker 中也实现这一点。”

他们在开始使用 Docker 时，没有那么多规划。后来 Jensen 意识到一开始给予开发者的自由度太大。“不应该这样，”他打了个响指，说：“你真的要考虑到基础设施的方方面面”。

Jensen 说，如果你提前做好规划，真正审视基础设施以及容器在其中的一小部分作用，结果就会好很多。

Docker 正在驱动一个全新的可扩展的 Uber

现在 Uber 大约有 1/3 服务是 Docker 化的，希望不久实现***的容器化。为什么?虽然转换的过程很痛苦，但是最终的结果符合期望，去掉了持续部署中的三个巨大的痛点。有了 Docker ，他们无需再：

• 等待基础设施团队编写服务的依赖;
• 等待 IT 确定服务的位置;
• 等待基础设施团队提供服务。

现在，他们不再手工编写或者复制以前项目的依赖定义，而是使用包含标准服务的配置和构建文件的工具，从而把服务提供时间从以前的几小时、几天缩短到现在的大约 10 分钟。

不仅如此， Uber 认识到， Docker 消除了团队之间的依赖，提供了更高的自由，因为不再绑定在特定的框架和版本。框架和服务的拥有者现在可以尝试新技术，管理自有的环境。

原文链接：http://dockone.io/article/864