Docker 正在驅動一個全新的可擴展的 Uber
【原文編者的話】快速創(chuàng)新的迫切要求，使得 Uber 開始在服務部署中應用 Docker 。這篇文章講述了部署方式的轉變過程，強調在全面容器化之前，必須做充足的準備。
無論你對 Uber 的看法如何， Uber 無疑是創(chuàng)新的同義詞，因為它在顛覆交通行業(yè)的同時***了共享經濟。像Uber 這樣的最快創(chuàng)新者，就像 Microsoft, Apple 和 Amazon 公司一樣，都面臨一個問題：一旦你開始創(chuàng)新并且取得成功，你不得不一直保持這樣快的創(chuàng)新速度，這就導致了下面的后果：有時你看不到更遠大的前景，有時會被途中的障礙絆倒。
今年初， Uber 發(fā)現自己就處于這樣的境地。那時候，軟件工程師 Casper S. Jensen 加入了 Uber 公司的計算機平臺團隊。
在 Dockercon EU 的***天， Jensen 說 Uber 應用有非常易用的用戶界面，看起來就是一個簡單的應用;“實際上 Uber 是一個非常非常復雜的產品”，“應用只是冰山之一角”，底層包含了無數的功能特性。要知道，目前 Uber 面對的是 69 個國家的不同市場和法律，每天安排百萬次行程，有4,000 員工使用 Uber 平臺。
以前的軟件開發(fā)模式
那時候， Jensen 和團隊中的其他四個人剛剛加入 Uber 不久。工作簡直是“一團糟”，他們正在尋求一種解決方案。
這是去年冬天他們的開發(fā)流程：
- 編寫服務 RFC(Request for Commments，請求評論)—— Uber 是一家極其依賴反饋的公司，在啟動一項新服務時，他們首先描述該服務的架構和理念，發(fā)布到郵件列表中。
- 收集反饋——例如，“你們知道其他人也在做類似的事情嗎?”——集中精力，力爭在早期就找出錯誤。
- 手工列出該服務的所有依賴。
- 開始開發(fā)服務。
- 等待基礎設施團隊編寫服務的依賴。
- 等待 IT 確定服務的位置。
- 等待基礎設施團隊提供服務。
- 部署到開發(fā)服務器，測試。
- 部署到生產環(huán)境的服務器。
- 監(jiān)控迭代。
他說，步驟 5-7 “是特別特別令人痛苦的部分，很容易耗費數日乃至數周的時間。”原因何在?“到不是說這些步驟特別難，大部分環(huán)節(jié)我們都有相應的腳本，”只包括大約十行的集成代碼。
“簡單是簡單，但是這些腳本的擴展性差，因為公司里只有少數人真正地知道如何擴展且不會破壞已有的部署”， Jensen 說。再加上一些小錯誤——例如，本來應該是連接線，結果寫成了斜線——***導致所有的服務都慢得要命。
2015 年2 月，在一封內部郵件中，他們設置了下列目標：
Jensen 說他們想要做到：
- 允許服務的擁有者有專用的服務器切片，他們自行決定安裝什么，我們不干涉，但是不能影響其它的服務。
- 并且，他們的安裝過程也不用我們參與。
- 必須得有所改變了，還不能破壞現有的服務。
Uber 需要克服的自身問題
如果一家公司有如此快速增長的基礎設施，自然會有一些限定，如 Jensen 所講，“無論如何，我們必須保證基礎設施快速增長，避免拖慢開發(fā)團隊的高速開發(fā)流程”。
這不僅是因為 Uber 要求 7×24 的可用性以及支持無數的本地化特性，更重要的是，“沒有任何一個人能夠看到 Uber 的所有服務，每個人只能看到自己從事的部分。”他列舉了幾個特性，像 UberPOOL、UberKITTENs、UberIceCream 和 UberEATS，每一個都在“增加新功能，好像世界末日到了一樣”。 Uber 的耀眼成功，是建立在全方位超快發(fā)展的基礎之上的，包括數據中心、服務器和基礎設施。需要找到保持增長的解決方案。
“我們希望有非常方便的流程和基礎設施，這樣開發(fā)者就能非?？斓卦黾有鹿δ?。其中最重要的一個部分是創(chuàng)建新服務的流程，” Jensen 說，“我們意識到這不就是 要用 Docker 嗎。”理由很簡單，“很容易向別人解釋 Docker 的作用，人們早就了解過它，理解基本的概念”。每個人都有自己喜歡使用的容器，因此開發(fā)團隊很容易接受 Docker 。
容器帶來的痛苦
他們心想，“我們都能寫代碼，這還不是小菜一疊?兩天就能干完。”實際上不是那么回事。他們 2月份作出決定，直到仲夏，才真正用上 Docker 。
Jensen 解釋說，用了 Docker ，“一切都有所改變，思路也必須隨之轉換。”
采用 Docker 的***障礙是 Uber 內部使用的集群管理系統 uDeploy 。它要能在支持回滾的前提下做持續(xù)的滾動升級。它包含很多報錯的觸發(fā)器，像健康檢查或者發(fā)生故障時的圖形化顯示。它還支持有錯就回滾的負載測試和集成測試。 uDeploy 包括：
- 每周 4,000 次升級
- 每周 3,000 次構建
- 每周 300 次回滾
- 管理系統包含的 600 多個服務
做不到完全不使用 uDeploy ，所以 Uber 團隊決定同時部署舊有的服務和 Docker 服務。
“我為此花了很多時間，檢查每一個功能，添加支持以便能夠把它封裝為 Docker 服務，” Jensen 說，“ uDeploy 支持顯示標準輸出和標準錯誤，我們必須在 Docker 中也實現這一點。”
他們在開始使用 Docker 時，沒有那么多規(guī)劃。后來 Jensen 意識到一開始給予開發(fā)者的自由度太大。“不應該這樣，”他打了個響指，說：“你真的要考慮到基礎設施的方方面面”。
Jensen 說，如果你提前做好規(guī)劃，真正審視基礎設施以及容器在其中的一小部分作用，結果就會好很多。
Docker 正在驅動一個全新的可擴展的 Uber
現在 Uber 大約有 1/3 服務是 Docker 化的，希望不久實現***的容器化。為什么?雖然轉換的過程很痛苦，但是最終的結果符合期望，去掉了持續(xù)部署中的三個巨大的痛點。有了 Docker ，他們無需再：
- 等待基礎設施團隊編寫服務的依賴;
- 等待 IT 確定服務的位置;
- 等待基礎設施團隊提供服務。
現在，他們不再手工編寫或者復制以前項目的依賴定義，而是使用包含標準服務的配置和構建文件的工具，從而把服務提供時間從以前的幾小時、幾天縮短到現在的大約 10 分鐘。
不僅如此， Uber 認識到， Docker 消除了團隊之間的依賴，提供了更高的自由，因為不再綁定在特定的框架和版本?？蚣芎头盏膿碛姓攥F在可以嘗試新技術，管理自有的環(huán)境。
