2014年，Uber發(fā)展迅速，其平臺在第一季度由原來的60座城市發(fā)展到100座，后又在第三季度拓展到200座。同時，發(fā)展最快的城市也包含在第一批發(fā)展的城市當中。

    隨著越來越多平臺工程師的加入，新的代碼部署混亂的問題也愈加明顯。因為在新版微服務投放生產(chǎn)的過程中，每個團隊都有自己慣用的shell腳本，并通過特定的服務工具對其進行手動監(jiān)測。而當主機升級出錯時，工程師唯有機械地一次重新運行一臺機器。因此，不斷擴大的工程師團隊阻礙了Uber人工服務的進一步擴展，有時甚至還會導致其長時間宕機。

    如何才能確保每天的穩(wěn)定部署？為此，Uber開發(fā)了微部署（MicroDeploy，簡稱μDeploy）。它是Uber的內(nèi)部部署系統(tǒng)，其構(gòu)建、更新和回滾服務都是基于Uber進行。

    代碼在經(jīng)過審核、接受和全部單項測試之后，被收入知識庫，從而進入預生產(chǎn)階段，這時Uber工程師就會使用到微部署。首先，工程師通過μDeploy接口挑選出一項待更新服務。之后，為了開展更新流程，他們需挑選一個部署并在Git知識庫中指定一個源碼版本。
 

圖1 Development Lifecycle

    μDeploy按需構(gòu)建服務和分布架構(gòu)，在正確的數(shù)據(jù)中心與相關主站對話，并使所有代理在部署主機上進行服務更新。通過這一進程，μDeploy用戶界面在工作流程完成之前，會提供更新狀態(tài)的視覺反饋，這讓工程師得以繼續(xù)進行其他任務。

    通過這種方法，μDeploy無論是構(gòu)建還是推出新服務，通常只需要幾分鐘。這也是工程師對此可以達到的最快速度。

    從工程師編寫代碼，到該代碼被運用到Uber生產(chǎn)系統(tǒng)當中，中間幾乎沒有過渡階段。自Uber推出首代μDeploy以來，其發(fā)展就從未減緩。2016年，工程師每周都要加緊構(gòu)建數(shù)千項服務，監(jiān)測后，會淘汰其中有10%，并將其退回原版。這意味著在工作時段，Uber系統(tǒng)的某部分每分鐘都在更新。由于更新時長往往不止一分鐘，所以該系統(tǒng)總是處在更新中的狀態(tài)。

    微部署由眾多微服務構(gòu)成，而其中的大多數(shù)又通過μDeploy部署。
 

圖2 Miceo Deploy(μDeploy) System Overview

    一個網(wǎng)絡應用UI加CLI讓工程師選擇與μDeploy交互的方法；

    μDeploy代理在Uber數(shù)據(jù)中心的每一臺機器上運行，其受主μDeploy指令調(diào)配，對服務進行安裝和配置更改。同時，代理部署也會概述各項服務，并向主部署反饋設備狀態(tài)。

    μDeploy主部署管控著數(shù)據(jù)中心內(nèi)部的μDeploy代理在所有設備上的操作方式。每個數(shù)據(jù)中心至少包含一個主部署。

    在每個數(shù)據(jù)中心內(nèi)，μDeploy聚合器會和一個主部署設備接口，以實現(xiàn)全面部署。

    uBuild系統(tǒng)在其設備的單個集群中展開前，構(gòu)建服務并隨之將其分布至各數(shù)據(jù)中心。

    μDeploy復制器負責在數(shù)據(jù)中心內(nèi)部或兩個數(shù)據(jù)中心之間復制備份最終架構(gòu)。

    μDeploy協(xié)調(diào)器以這一種分布式容錯模式對更新工作流進行管理。

    μDeploy位置處在一組負責部署服務的主機。

    uConfig系統(tǒng)支持服務配置迭代，且以服務更新的方式進行。

    一系列特性綜合造就了微部署的完整架構(gòu)和完備的部署管理系統(tǒng)。下面列舉出一些類似Uber的基礎設施系統(tǒng)，他們在構(gòu)建部署系統(tǒng)時所需的幾大要素：

    服務架構(gòu)一致性：對Uber來說，微部署是適用于各類服務的集成構(gòu)建系統(tǒng)。是支持Tornado的Python？支持Node.js的JavaScript？還是支持Docker，沒有容器的Go、Java？答案都是肯定的。μDeploy構(gòu)建系統(tǒng)利用不同的軟件棧調(diào)控多種編程語言和設備。Uber的集成構(gòu)建系統(tǒng)使其生產(chǎn)服務部署更加標準化。

    零停機更新：微部署系統(tǒng)在全球范圍內(nèi)逐步推廣，將同一版本的軟件推廣部署至多個數(shù)據(jù)中心，這些數(shù)據(jù)中心各自有不同的任務和配置。全自動化的部署便于工程師對其服務做出全球迭代。

    錯誤早期自動化檢測：微部署集成監(jiān)控系統(tǒng)，對異常現(xiàn)象做出早期監(jiān)測，而無需人工控管，其中包括I/O性能的明顯下降、未捕獲異常、HTTP錯誤代碼、請求吞吐量問題和服務器負載問題。μDeploy則通過這些監(jiān)控數(shù)據(jù)來確認在新版本推出的過程中，系統(tǒng)仍保持性能穩(wěn)定。

    預防運行中斷：面對異常情況，微部署利用監(jiān)控數(shù)據(jù)中止更新，并將其退回一個性能相對穩(wěn)定的版本。雖然誤報的情況時有發(fā)生，但比起冒險，選擇安全更為穩(wěn)妥�；貪L是自動化運行，且操作發(fā)生往往遠在全部主機完成版本更新之前。理想化狀態(tài)是使回滾發(fā)生在一個canary區(qū)，在該區(qū)域內(nèi)，極小一批設備負責阻斷任何故障的外部影響。

    穩(wěn)定更新：微部署的高配置工作流引擎協(xié)調(diào)更新各階段。作為一個分布式系統(tǒng)，在更新過程中，μDeploy可以應對所有主機和機架的異常停運（包括正在運行工作流的主機）。

    簡易使用：微部署基于的是Web應用，有著豐富用戶界面（UserInterface）且功能完善。從而所有工程師都可通過瀏覽器獲取μDeploy，并立刻部署其服務投產(chǎn)。

    深度集成RESTAPI：微部署的RESTAPI使用的是第三方工具，并深度集成到功能中。

    Uber設計微部署的目的在于避免不必要的部署進程，同時也想要借此協(xié)助更新的準確進行。如果沒有微部署，則系統(tǒng)將快速捕獲偶發(fā)性更新錯誤，從而大大降低投產(chǎn)的可能性。而有微部署的情況下，若有意外錯誤發(fā)生，系統(tǒng)仍繼續(xù)運行。和Uber其它主要工程項目類似的是，μDeploy的構(gòu)想和實現(xiàn)都是在其初始模式下進行的，且其投產(chǎn)過程的數(shù)月也是充滿趣味性的。

    開發(fā)兩月后，Uber推出了首批微部署服務，其中50%在生產(chǎn)前五月使用μDeploy，較為高產(chǎn)。

    2016年中期，在眾多數(shù)據(jù)中心當中，Uber后端以及發(fā)展成為一個不斷迭代，大規(guī)模分布式系統(tǒng)。Uber工程師亦遍布數(shù)個國家和大洲的12個工作室。99%的Uber軟件支持μDeploy。微部署在任何場合下賦予工程師的所有權(quán)都高速、自主，并且是端對端的。