Uber微部署的工程实践

2014年，Uber发展迅速，其平台在第一季度由原来的60座城市发展到100座，后又在第三季度拓展到200座。同时，发展最快的城市也包含在第一批发展的城市当中。

    随着越来越多平台工程师的加入，新的代码部署混乱的问题也愈加明显。因为在新版微服务投放生产的过程中，每个团队都有自己惯用的shell脚本，并通过特定的服务工具对其进行手动监测。而当主机升级出错时，工程师唯有机械地一次重新运行一台机器。因此，不断扩大的工程师团队阻碍了Uber人工服务的进一步扩展，有时甚至还会导致其长时间宕机。

    如何才能确保每天的稳定部署？为此，Uber开发了微部署（MicroDeploy，简称μDeploy）。它是Uber的内部部署系统，其构建、更新和回滚服务都是基于Uber进行。

    代码在经过审核、接受和全部单项测试之后，被收入知识库，从而进入预生产阶段，这时Uber工程师就会使用到微部署。首先，工程师通过μDeploy接口挑选出一项待更新服务。之后，为了开展更新流程，他们需挑选一个部署并在Git知识库中指定一个源码版本。
 

图1 Development Lifecycle

    μDeploy按需构建服务和分布架构，在正确的数据中心与相关主站对话，并使所有代理在部署主机上进行服务更新。通过这一进程，μDeploy用户界面在工作流程完成之前，会提供更新状态的视觉反馈，这让工程师得以继续进行其他任务。

    通过这种方法，μDeploy无论是构建还是推出新服务，通常只需要几分钟。这也是工程师对此可以达到的最快速度。

    从工程师编写代码，到该代码被运用到Uber生产系统当中，中间几乎没有过渡阶段。自Uber推出首代μDeploy以来，其发展就从未减缓。2016年，工程师每周都要加紧构建数千项服务，监测后，会淘汰其中有10%，并将其退回原版。这意味着在工作时段，Uber系统的某部分每分钟都在更新。由于更新时长往往不止一分钟，所以该系统总是处在更新中的状态。

    微部署由众多微服务构成，而其中的大多数又通过μDeploy部署。
 

图2 Miceo Deploy(μDeploy) System Overview

    一个网络应用UI加CLI让工程师选择与μDeploy交互的方法；

    μDeploy代理在Uber数据中心的每一台机器上运行，其受主μDeploy指令调配，对服务进行安装和配置更改。同时，代理部署也会概述各项服务，并向主部署反馈设备状态。

    μDeploy主部署管控着数据中心内部的μDeploy代理在所有设备上的操作方式。每个数据中心至少包含一个主部署。

    在每个数据中心内，μDeploy聚合器会和一个主部署设备接口，以实现全面部署。

    uBuild系统在其设备的单个集群中展开前，构建服务并随之将其分布至各数据中心。

    μDeploy复制器负责在数据中心内部或两个数据中心之间复制备份最终架构。

    μDeploy协调器以这一种分布式容错模式对更新工作流进行管理。

    μDeploy位置处在一组负责部署服务的主机。

    uConfig系统支持服务配置迭代，且以服务更新的方式进行。

    一系列特性综合造就了微部署的完整架构和完备的部署管理系统。下面列举出一些类似Uber的基础设施系统，他们在构建部署系统时所需的几大要素：

    服务架构一致性：对Uber来说，微部署是适用于各类服务的集成构建系统。是支持Tornado的Python？支持Node.js的JavaScript？还是支持Docker，没有容器的Go、Java？答案都是肯定的。μDeploy构建系统利用不同的软件栈调控多种编程语言和设备。Uber的集成构建系统使其生产服务部署更加标准化。

    零停机更新：微部署系统在全球范围内逐步推广，将同一版本的软件推广部署至多个数据中心，这些数据中心各自有不同的任务和配置。全自动化的部署便于工程师对其服务做出全球迭代。

    错误早期自动化检测：微部署集成监控系统，对异常现象做出早期监测，而无需人工控管，其中包括I/O性能的明显下降、未捕获异常、HTTP错误代码、请求吞吐量问题和服务器负载问题。μDeploy则通过这些监控数据来确认在新版本推出的过程中，系统仍保持性能稳定。

    预防运行中断：面对异常情况，微部署利用监控数据中止更新，并将其退回一个性能相对稳定的版本。虽然误报的情况时有发生，但比起冒险，选择安全更为稳妥。回滚是自动化运行，且操作发生往往远在全部主机完成版本更新之前。理想化状态是使回滚发生在一个canary区，在该区域内，极小一批设备负责阻断任何故障的外部影响。

    稳定更新：微部署的高配置工作流引擎协调更新各阶段。作为一个分布式系统，在更新过程中，μDeploy可以应对所有主机和机架的异常停运（包括正在运行工作流的主机）。

    简易使用：微部署基于的是Web应用，有着丰富用户界面（UserInterface）且功能完善。从而所有工程师都可通过浏览器获取μDeploy，并立刻部署其服务投产。

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

    Uber设计微部署的目的在于避免不必要的部署进程，同时也想要借此协助更新的准确进行。如果没有微部署，则系统将快速捕获偶发性更新错误，从而大大降低投产的可能性。而有微部署的情况下，若有意外错误发生，系统仍继续运行。和Uber其它主要工程项目类似的是，μDeploy的构想和实现都是在其初始模式下进行的，且其投产过程的数月也是充满趣味性的。

    开发两月后，Uber推出了首批微部署服务，其中50%在生产前五月使用μDeploy，较为高产。

    2016年中期，在众多数据中心当中，Uber后端以及发展成为一个不断迭代，大规模分布式系统。Uber工程师亦遍布数个国家和大洲的12个工作室。99%的Uber软件支持μDeploy。微部署在任何场合下赋予工程师的所有权都高速、自主，并且是端对端的。