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

    隨著越來越多平臺(tái)工程師的加入，新的代碼部署混亂的問題也愈加明顯。因?yàn)樵谛掳嫖⒎��?wù)投放生產(chǎn)的過程中，每個(gè)團(tuán)隊(duì)都有自己慣用的shell腳本，并通過特定的服務(wù)工具對(duì)其進(jìn)行手動(dòng)監(jiān)測(cè)。而當(dāng)主機(jī)升級(jí)出錯(cuò)時(shí)，工程師唯有機(jī)械地一次重新運(yùn)行一臺(tái)機(jī)器。因此，不斷擴(kuò)大的工程師團(tuán)隊(duì)阻礙了Uber人工服務(wù)的進(jìn)一步擴(kuò)展，有時(shí)甚至還會(huì)導(dǎo)致其長時(shí)間宕機(jī)。

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

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

圖1 Development Lifecycle

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

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

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

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

圖2 Miceo Deploy(μDeploy) System Overview

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

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

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

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

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

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

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

    μDeploy位置處在一組負(fù)責(zé)部署服務(wù)的主機(jī)。

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

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

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

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

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

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

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

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

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

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

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

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