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

云计算
无论你对 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

责任编辑:Ophira 来源: dockerone
相关推荐

2023-02-01 16:36:31

GNOMEChatGPTLinux

2020-03-05 09:54:54

数据驱动数据数据分析

2022-07-21 07:09:21

React前端项目

2022-04-08 11:40:51

KServe

2013-01-25 09:53:40

GitHub

2015-08-19 09:29:35

Git协议编写

2022-03-21 08:49:01

存储引擎LotusDB

2010-04-01 09:18:38

云计算

2016-01-06 09:57:23

编写PHP扩展

2015-12-04 11:36:04

SaaS架构设计可持续

2020-06-02 10:04:58

IT部门首席信息官CIO

2013-02-19 10:14:37

NexusGoogle

2014-10-15 11:01:02

Web应用测试应用

2022-04-12 14:00:05

元宇宙人工智能安全

2019-06-05 13:05:47

PHP语法糖编码

2022-01-04 12:41:37

Collabora图形后端Cairo

2021-02-02 10:41:29

Ubuntu安装程序开发人员

2022-03-28 08:00:00

数据库GraphQL公共云

2020-12-21 06:09:39

线程Java对象

2017-11-16 19:43:33

殡葬业互联网3D打印
点赞
收藏

51CTO技术栈公众号