e-works数字化企业网  »  文章频道  »  基础信息化  »  移动应用

Uber微部署的工程实践

2016/7/12    来源:极客头    作者:佚名      
关键字:Uber  微部署  μDeploy  
2014年,Uber发展迅速,其平台在第一季度由原来的60座城市发展到100座,后又在第三季度拓展到200座。同时,发展最快的城市也包含在第一批发展的城市当中。
    2014年,Uber发展迅速,其平台在第一季度由原来的60座城市发展到100座,后又在第三季度拓展到200座。同时,发展最快的城市也包含在第一批发展的城市当中。
 
    随着越来越多平台工程师的加入,新的代码部署混乱的问题也愈加明显。因为在新版微服务投放生产的过程中,每个团队都有自己惯用的shell脚本,并通过特定的服务工具对其进行手动监测。而当主机升级出错时,工程师唯有机械地一次重新运行一台机器。因此,不断扩大的工程师团队阻碍了Uber人工服务的进一步扩展,有时甚至还会导致其长时间宕机。
 
    如何才能确保每天的稳定部署?为此,Uber开发了微部署(MicroDeploy,简称μDeploy)。它是Uber的内部部署系统,其构建、更新和回滚服务都是基于Uber进行。
 
    每日部署进程
 
    代码在经过审核、接受和全部单项测试之后,被收入知识库,从而进入预生产阶段,这时Uber工程师就会使用到微部署。首先,工程师通过μDeploy接口挑选出一项待更新服务。之后,为了开展更新流程,他们需挑选一个部署并在Git知识库中指定一个源码版本。
 
Development Lifecycle
 
图1 Development Lifecycle
 
    μDeploy按需构建服务和分布架构,在正确的数据中心与相关主站对话,并使所有代理在部署主机上进行服务更新。通过这一进程,μDeploy用户界面在工作流程完成之前,会提供更新状态的视觉反馈,这让工程师得以继续进行其他任务。
 
    通过这种方法,μDeploy无论是构建还是推出新服务,通常只需要几分钟。这也是工程师对此可以达到的最快速度。
 
    从工程师编写代码,到该代码被运用到Uber生产系统当中,中间几乎没有过渡阶段。自Uber推出首代μDeploy以来,其发展就从未减缓。2016年,工程师每周都要加紧构建数千项服务,监测后,会淘汰其中有10%,并将其退回原版。这意味着在工作时段,Uber系统的某部分每分钟都在更新。由于更新时长往往不止一分钟,所以该系统总是处在更新中的状态。
 
    目标:稳步部署
 
    微部署由众多微服务构成,而其中的大多数又通过μDeploy部署。
 
Miceo Deploy(μDeploy) System Overview
 
图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。微部署在任何场合下赋予工程师的所有权都高速、自主,并且是端对端的。
 
责任编辑:李欢
本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐