Uber微部署的工程实践

本贴最后更新于 3089 天前,其中的信息可能已经事过景迁

原文:UBER ENGINEERING’S MICRO DEPLOY: DEPLOYING DAILY WITH CONFIDENCE 
作者: Mathias Schwarz 
译者:仲培艺,关注数据库领域,纠错、寻求报道或者投稿请致邮:zhongpy@csdn.net。

图片描述

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

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

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

每日部署进程

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

图片描述

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

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

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

目标:稳步部署

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

图片描述

  • 一个网络应用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应用,有着丰富用户界面( User Interface)且功能完善。从而所有工程师都可通过浏览器获取μDeploy,并立刻部署其服务投产。

深度集成REST API:微部署的REST API使用的是第三方工具,并深度集成到功能中。

从任务到委托

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

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

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

本文作者Mathias Schwarz是Uber丹麦奥尔胡斯工作室的一名工程师。

 http://geek.csdn.net/news/detail/87225

  • 微服务

    微服务架构是一种架构模式,它提倡将单一应用划分成一组小的服务。服务之间互相协调,互相配合,为用户提供最终价值。每个服务运行在独立的进程中。服务于服务之间才用轻量级的通信机制互相沟通。每个服务都围绕着具体业务构建,能够被独立的部署。

    96 引用 • 155 回帖
  • Uber
    2 引用 • 5 回帖
  • deploy
    1 引用

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...