微博基于 Docker 的混合云平台设计与实践 编者按：高可用架构分享及传播在架构领域具有典型意义的文章，本文由王关胜投稿。转

载请注明来自高可用架构公众号 ArchNotes。

王关胜，微博研发中心运维架构师、自2011年初加入新浪，一直负责微博平台&大数据等

业务线的运维保障工作，包括产品稳定性，运维基础设施建设，工具建设等工作。工作期

间主要参与了微博平台化改造，版本升级，多机房部署，业务RPC化，Feed保障等重量级

架构改造项目。同时也在推进Docker在微博的应用，与RD一起共同推进建设了微博混合

云平台DCP. 个人比较擅长大规模分布式系统集群的管理与运维，疑难问题分析，故障定

位与处理。对运维工具平台建设，监控，应用性能跟踪及分析，数据化运维等方面有深入

的研究。

背景： 11年初，新浪微博进入快速发展期，同时也开启平台化的进程，服务器设备，及人力

成本大量增加，业务的快速发展，促使我们建立了一套完整的运维平台。虽然已稳定运行

了3年，但随着公有云的逐渐成熟，Docker Container技术的兴起，一时间各大型企业纷

纷开始升级内部运维系统，提供自动化能力的同时，更注重弹性调度。我们也于14年底构

建了第一版基于Docker的运维平台，并在元旦，春节，红包飞等大型活动中得到了考验。

但是要想更好的应对微博的这种业务场景，我们的系统局限性还很多，比如设备申请慢，

业务负载饱和度不一，扩缩容流程繁琐且时间长，基于此出发点，今年我们与RD一起设计

与实现了一套基于Docker的混合云平台。

微博的业务场景及混合云背景 微博目前有8亿注册用户，单日活跃用户数达1亿多。微博总体分为端和后端平台，端

上主要是PC端，移动端和第三方开发者，后端平台主要是Java编写的各种接口层，服务层

及存储层。就前端来说，每日超过600亿次的API调用，超过万亿的RPC调用，产生的日志

就达百T+。对于这么大体量的业务系统，对于运维的要求也很严格，就接口层来说，SLA

必须达到4个9，且接口平均响应时间不能高于50ms。因此我们会面临各种各样的挑战。

u 产品功能迭代快，代码变更频繁

u 业务模块多，且依赖关系复杂

u 突发的热点事件，如典型的#周一见# #马航370# #刘翔摔倒# #明星丑闻#

u 大型活动及三节保障，如红包飞

下面我们来具体看下春晚时的业务模型：

图 1： 春晚 feed 业务 图 2： 红包飞业务

每年的元旦，春晚，红包飞会为我们带来巨大的流量挑战，这些业务场景的主要特点

是： 瞬间峰值高，互动时间短。基本上一次峰值事件，互动时间都会3小时以内，而明星

丑闻事件，红包飞这种业务，经常会遇到高达多倍的瞬间峰值。传统的应对手段，主要是

靠提前申请足够的设备，保证冗余；降级非核心及周边的业务；生扛这三种手段。这么

做，除了成本高外，我们在对系统进行水平扩容时，耗费的时间也久。

除了来自业务的挑战，在应对峰值事件时，对于运维的挑战也蛮大的。大家吐槽 多的

莫过于：设备申请太麻烦，时间长；扩缩容流程繁琐。

我们来看一次具体的扩容流程：首先基础运维做的：从采购拿到新机器，录入CMDB，

再根据业务运维提的需求，进行上架到相应的IDC,机架，操作系统安装，网络配置， 后分

给相应的业务运维，就是一台完整的可以登录的机器了。其次，业务运维拿到机器，需要对

机器进行初始化配置，并继续服务部署。服务部署好后，经过check，再挂到负载均衡上，

引入流量。设备坏了自动报修，过期下架或替换。具体可看下图：

图3： 业务扩容流程图

这种扩容的方式，除了流程繁琐外，还经常遇到各服务器间，各种环境差异，无法充分利

用服务器硬件资源，即使有多余的服务器也无法灵活调度。若采取新申请设备，这个流程

就更麻烦了。一般设备申请是业务方及业务运维发起采购提案，然后相关方进行架构评

审，评审通过，则由IT管委会评审，再由决策及成本部门评审，评审通过，进入采购流

程，再上架，还经常遇到机房机架位不足，这些都导致交付周期变得很长。

除了业务扩容的繁琐，我们发现公司内设备利用率也不均衡，主要表现在三个地方：

1） 各个业务组的服务器利用率各不相同，大家对利用率的理解不一致，导致有些设备未

能得到充分利用，这也会导致更大的成本压力。

2） 各个业务模型不同，比如有的业务高峰是在晚22-23点，有的业务则在中午

3） 在线业务与离线业务完全分离，导致成本也高，对于离线业务，可在低峰继续跑在线

业务

正因为这些挑战，怎么能更好的解决，我们想到基于Docker，及公有云来构建一套具有弹

性伸缩的混合云系统。利用过去的私有云加公有云，以及公司内闲置的运算资源，混合

云，兼具安全性与弹性扩展能力。其特点如下图：

图4： 混合云系统特点

有了这套混合云系统后，不仅能很好的整合内部运算资源，解决内部的弹性需求外，当系

统面临流量剧增的峰值事件时，也可以将过多的流量切入外部公有云，减轻内部系统的压

力。

两种云内的设备，我们如何使用呢？我觉得内部私有云设备安全性高，可控度也高，只要

对硬件资源进行优化配置，用它来处理固定的工作负载。而公有云的设备则具有标准化，

自动化的特性，可以快速因临时需求，在流量暴涨时，让我们快速创建大量ECS，扩容业

务工作负载的能力。而对于公司，可以利用公有云这种按需付费的机制，减低硬件的运营

成本。因此采用混合云架构，就可以兼具私有云及公有云的优点，可以同时拥有安全与弹

性扩容能力，使业务工作负载可以在业务间进行漂移，低负载的业务就应该使用更少的设

备，反之亦然。而基于Docker来做，对于我们的情况来说，复杂度降低很多。

三大基础设施助力微博混合云 微博混合云系统不单只是一般的混合云，而是应用了Docker，透过Docker Container快

速部署的特性，解决海量峰值事件对微博系统带来的压力。过去公司在面对峰值事件，一

般采取的作法是，首先评估需要多少额外设备，并向外部公有云申请机器分摊流量。然

而，除了可能低估应付峰值事件所需的设备外，即使事先準备了足够的VM，其部署时间

成本也远高于Docker，无法即时帮助公司分摊过多外部请求。

而微博Docker Container平台的混合云核心设计思想，主要是借鉴银行的运作机制：民众

可以把钱存在银行，而需要使用金钱的时候，只需要提领一部分，剩余的存款银行可以拿

去进行投资。而微博则借鉴银行的这一套运作模式，在内部设立一个运算资源共享池外，

还导入了外部公有云。

而要微博实现高弹性调度资源的混合云架构，其中实现的关键则是Docker。刚开始我们思

考该要使用裸机还是VM架构，作为Docker Container的基础设施。后来，考量如果要采

用VM，内部机房架构要进行许多改造。所以，目前微博的内部私有云使用裸机部署，而

外部公有云则采用阿里云弹性计算服务（ECS）的VM架构。等平台建设成熟后，还可以应

用其他家的公有云，如AWS.

我们构建Docker Container平台基础架构的3大关键，包含Docker在裸机上的部署架构、

改进版的Docker Registry以及负载均衡组件Nginx Upsync模块。第一是Docker

Container的裸机部署方案，透过IP位址以及Port定义一个唯一的Container服务，而每台

主机上则可以开启多个Container，各个具有不同的功能。

图5 ：Docker单机部署图

每一个Container服务所产生的行为日志，会经由一个名为Scribe的Container集中收集。

而集中后的数据则可进行用户行为分析。对于容器类监控数据，则是透过建立Cadvisor

Container，将Container运行产生的资料，传送至ELK(Elasticsearch、Logstash及

Kibana)开源监控软体，进行分析。对于业务数据，通过Graphite，监控业务系统的运作

状况。

第二则是Docker Registry，我们使用Docker官方提供的Docker Registry，构建了私有的

Registry Hub，并且透过这个私有调度Docker Container需要的镜像。

图6：Docker Registry架构

在今年，我们基于V2版的Registry Hub，将存储引擎改为使用分布式开源存储平台

Ceph，并且在Docker Registry前端结合Nginx，实作负载平衡功能。这个过程中，比较

麻烦的是，在Docker版本升级过程中必须让系统能够兼容新旧版本的Registry Hub，而

前端Nginx可以分析系统需求，辨別要从新版本或是旧版本docker仓库下载镜像。而外部

公有云，则是透过镜像缓存mirror，不必像私有云一样，部署完整的镜像仓库。

对于我们的镜像服务，总共包含3层架构。包含 底层操作系统、中间层的运行环境如

Java、Tomcat，及 上层的Container。而在调度Container时，透过使用dockerignore

指令，减少不必要的文件、目录，借此减低映像档的容量。除此之外，在镜像标签命名

上，我们则禁止使用「Latest」做为镜像标签。这是由于不同使用者对于标签的理解不

一，可能会误以为是代表映像档 新的版本。

而第三则是我们架构组同事开发的Nginx Upsync模块，去年我们开始使用Container时，

将Container挂到Nginx后，必须通过重启或reload指令，使流量生效。而这个过过程

中，Nginx对于特別大的并发流量会发生运行不稳定的情形。所以我们直接开发了Nginx

Upsync模块，不通过reload指令重启，也可以保持系统稳定运作。针对两种模块进行比

较，发现流量大时，用了Nginx Upsync模块，不做reload，单机扛量多了10％的请求，

且性能并不会降低。

Nginx Upsync的核心功能主要是：

1） Fix Nginx reload时带来的服务抖动

2） Fix Web Container的服务发现

项目已开源至github上：https://github.com/weibocom/nginx-upsync-module

其架构如下：

图7：Nginx Upsync模块架构

微博混合云DCP系统设计核心：自动化，弹性调度 目前我们开发的Docker Container混合云平台，主要包含4层架构：主机层、调度层及业

务编排层， 上层则是各业务方系统。底层的混合云基础架构则架构了专线，打通微博内

部资料中心以及阿里云。

主要思想：来源于官方三驾马车（Machine + Swarm +Compose）

图8：混合云DCP系统架构

DCP混合云系统的设计理念，总共包含4个核心概念：弹性伸缩、自动化、业务导向以及

专门为微博订制。混合云系统必须有弹性调度的运算能力。而DCP混合云系统并不是对外

公开的产品化服务，必须以业务需求出发，因此会有包含许多微博定制的功能。

DCP系统， 核心3层架构：主机层、调度适配层及编排层。

主机层的核心是要调度运算资源。目前设计了资源共享池、Buffer资源池，配额管理，及

多租户管理机制，借此实现弹性调度资源。

而调度层则通过API，把调度工具用API进行包装，而微博4种常用的调度工具组合包含：

Docker、Swarm、Mesos及微博自主开发的Dispatch。

而 上层的则是负责业务编排及服务发现。目前，微博的后端服务95%是Java环境，而PC

端则是使用PHP撰写，移动端则是通过调用API。这些业务方都将会接入DCP。编排层也

包括了大数据工具Hadoop，进行大数据分析的业务场景。

我们知道，对于调度来说， 重要的就是资源管理，mesos处理这个是 合适不过了，很

多公司就专用其做资源管理，比如Netflix写了一个Titan的调度服务，其底层资源管理则是

通过mesos。当然我们的调度组件中，使用 多的还是swarm，dispatch.

我们可以看下面这个场景：这也是私有云内部资源流转的 佳实践

图9：私有云资源共享案例

当业务A多余的运算资源导入混合云共享池时，此时流量暴涨的业务C，可从

共享池调度业务A的运算资源，而峰值事件后，便可以把多余的运算资源归还

至共享池。

DCP对于物理主机的流转，基于资源共享池、Buffer资源池，配额管理，及多租户管理机

制，其实非常复杂，详情可以去看我在台湾iThome举办Container summit 2015技术大

会上分享的内容。这里我们可以看一下一台物理主机的生命周期（状态流转图）

图10：DCP 物理主机状态流转图

引入阿里云做为第3机房，实现弹性调度架构 起初，对于是否采用混合云的架构，我们也是做了一番考虑的。目前微博机房的部署架构

总共分为3层，依次是 上层域名以及负载均衡层。中间则是Web层，包含各种前端框

架，RPC层以及中间件（Middleware）。而 下层则包含MySQL、Redis、HBase等资

源架构。

微博内部总共有2个机房，两者互相做为灾难备份用途，而第3个机房则采用外部阿里云。

混合云架构总共有2种部署方案。第1种部署方案，将阿里云视为数据中心，底层架构与微

博内部机房一样部署。内部机房采用nginx做为负载均衡层，但外部公有云则SLB引入流

量。其他阿里云的中间Web层则与内部机房架构一致。不过，由于我们有数据安全性的考

虑，仍然把阿里云做为应付大量峰值时的方案，存储永久性数据的MySQL、HBase并不会

部署于阿里云。

而第2种部署方案则不将阿里云视为完整数据中心，仅是把内部机房应付峰值事件需要的

弹性计算能力，迁移到阿里云。第2种部署方案困难之处，需要把微博的内部业务进行改

造，让微博中间Web层，直接对阿里云机房进行RCP调用。此种方案部署结构相较比较简

单，也让混合云架构具有实现可行性。

而这2种方案都会依赖VPC网路，如果有没有专线，想实现公有云的弹性计算能力几乎是

不可能。因为公网调度资源的延迟时间太高，无法应付微博大量的业务。

因此，我们与跟阿里云合作，在两边建立了内部专线，让阿里云机房与微博的机房互通。

早微博机房跟阿里云建立一个1G专线，用于日常峰值，在春节则是通过10G的专线应

对。

但是后来微博发现，如果只有一条专线，在峰值事件的状况下也很难弹性调度运算计算资

源。因此微博也在另一个机房中，开启了另一条专线。透过建立私有云及公有云间的双

10G专线，「目前微博可达到高可用性的目标。」

大规模集群操作自动化：设备申请，初始化，服务上线 微博Docker Container混合云DCP设计思想，核心目标就是透过自动化操作大规模集群，

进行弹性调度资源的任务，要完成此任务，必须经过3个流程：设备申请、设备初始化及

服务上线。

弹性扩容任务所需要的设备来源是内部的集群以及外部的阿里云。而申请到足够设备后，

也必须对设备进行初始化、部署环境及配置管理。 后一步则是将服务上线，开始执行

Container调度以及弹性扩容的任务。

第1步骤则是申请设备，而设备申请借鉴于银行机制的概念。私有云的设备来源，主要来

自离线集群、低负载集群以及错峰时间空出的多余设备。具体来说：离线集群并不是时时

刻刻都在执行运算，即使稍微减少计算资源，也不会对业务产生重大影响；而工作负载较

低的集群，如果有多余的资源也可以进行调度。此外，微博有上百个业务线，每个业务线

峰值出现的时间点都不一样，而在此种状况下，各业务也可以互相支援，共享多余的计算

资源。

图11： 集群间设备流转

而不同业务的集群则各自独立，并且具有独立的资源池。集群内可以自由调度资源，例

如，缩小A服务的规模，将多余的运算资源分派给B服务。若集群要调度外部资源，我们也

有设计配额制度，控制每个集群分配到的资源。在集群外，必须看Buffer池是否有足够的

资源，如果足够的话，可以直接将Buffer池内的设备初始化，进行使用。

反之，如果Buffer池内的资源不足，也必须查看是否有足够的配额，可以直接申请机器。

当设备申请完成，直接分配给Buffer池后，随即被纳入DCP使用，所有可调度的主机只能

通过集群自己的Buffer池。

第2步骤则是设备初始化；我们已开发了工具系统：可以达到操作系统升级自动化、系统

操作API化。而服务器所依赖的基础环境、需要的软体等环境配置，透过配置管理工具

Puppet，将需要的配置写成模块，并使用RPM机制打包，进行安装。

在初始化流程中，必须要支持软件反安装模式，例如，当A业务要调度设备时，其他业务

在交付设备前，必须要先透过反安装程序，将要设备恢复为 原始的状态。

而目前业界中的一些做法也可以免去初始化的流程。例如导入为Container而生的容器操

作系统，像CoreOS、RancherOS或Red Hat Atomic。不过，虽然这样可以，但是此种做

法的可维护度高，但是缺点在于迁移设备的成本较高。

第3步骤则是利用完成初始化的设备，开始进行服务上线。目前一线的运维人员，只要在

系统页面上输入服务池名称、服务类型、Container类型、需要Container数量以及镜像地

址等参数，即可在5分钟内完成扩容，扩容完成后，系统也会产出完整的报告，列出扩容

程序中，执行的步骤，以及每件任务的成功、失败状况。

总体来说：一键扩容流程如下

图12：微博混合云DCP一键扩容流程

应用微博Docker混合云，不怕峰值事件 为了确保微博Docker混合云平台系统的高可用性，我们组建了虚拟混合云保障团队。他们

重要的任务，就是要保障系统的可用性及易用性，让系统在三节、红包飞等尖峰时段系

统运作无误。

在用微博混合云DCP时，我们会优先调度内部的共享池资源的运算资源。但是在红包飞、

春晚时，则必须调度外部的运算资源。平日的正常状况下，阿里云只需提供500个运算节

点，并且在5到10分钟内完成部署任务。但是，面对春晚、红包飞的峰值流量，则要提供

3,000个节点。这对阿里云的北京节点，其实也是有要求的。

目前我们的Docker混合云DCP平台，才在今年10月完成第一版，Container数量千级。截

止发稿，基本上手机微博，微博平台，红包飞，在今年的春晚，都会基于此系统进行峰值

应对。上线以来，达成了微博所设定每次水平扩容时间低于5分钟的目标。「有这样的弹

性调度能力时，系统面对大型活动的峰值压力就小很多。」