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

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

文章名称:Docker正在驱动一个全新的可扩展的Uber
本文来源:http://www.gawzjz.com/qtweb/news0/205950.html

网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联