新浪微博混合云架构实践挑战之弹性调度揭秘

编者按：《微博混合云架构》专栏是 InfoQ 向新浪微博技术团队的系列约稿，本专栏包含 8 篇内容，详细阐述以 DCP 设计理念为指导思想的混合云架构实践。本文是该系列的第三篇，主要讲解了在新浪微博业务背景下 DCP 的弹性调度揭秘。

《微博混合云架构》专栏主要包括以下 8 篇内容：

1. 混合云架构挑战与概述
2. DCP 的不可变基础设施
3. DCP 的弹性调度揭秘
4. DCP 的镜像分发实战
5. DCP 的容器编排设计与实践
6. DCP 的服务发现
7. DCP 的容量决策评估
8. DCP 的监控体系

概述

微博 DCP 弹性调度的需求是快速迭代实现内网私有云计算资源统一管理调配，公有云上获得计算资源，实现快速自动化资源调度与应用部署。我们要解决的问题主要有服务池动态伸缩、单机容器灰度、多实例部署、故障自动恢复、定制的调度算法与策略、容量评估、跨 IDC 调度等。

如上图所示，不可避免的问题是，业界任一调度框架 Mesos、kubernetes、Swarm 都不能是解决微博业务现状面临的资源调度问题的“银弹”。所以我们设计了一个调度适配层生态圈系统 Roam。封装调度框架提供通用 Rest API，适配不同资源管理框架。同时自实现特定的调度伸缩策略等。本文将主要介绍新浪微博混合云架构上的可扩展、可插拔式统一弹性调度平台的建设。

弹性调度系统架构演进

第一阶段：Swarm

微博混合云刚开始阶段直接使用 Swarm。Swarm 是 Docker 官方推出容器集群管理工具，属 Docker 原生体系，提供标准标准 Docker API 对 Docker Container cluster 进行管理，接入成本低，基于标签的分组调度，满足微博业务现状需求。Swarm 管理 Docker 容器集群很简单：

1. docker run swarm-manage
2. 启动依赖服务发现 swarm join consul
3. 各节点 docker run swarm-agent

这样你便可通过 Swarm API 进行容器集群管理。由于微博开始用 Swarm 比较早，当时基本在官方还是 beta 版本，面对微博现实复杂业务场景以下几点无法满足：

• 大规模集群调度性能问题；
• 单机灰度需求；
• 特定调度策略无法支持；
• 高可用需求。

Swarm 在最开始版本发起调度有全局锁，这样整个过程就变为串行，影响调度性能。排查发现调度慢主要集中在拉镜像比较慢，改进优化为预拉镜像，提升性能。Swarm1.0 版本后改为分布锁，同步也大大提升性能。

针对以上问题我们对 Swarm 进行了二次封装，研发出调度适配层系统 Roam。Roam 对外提供 Rest API，通过 Swarm 获取 Docker 容器信息，外层自适配调度策略后下发 Swarm 集群，同时支持 Docker Deamon 直接下发。

第二阶段：Roam 演进

弹性调度 - 多 IDC、高可用、可扩展

对 Swarm 集群按照机房进行拆分，实现高可用、动态扩展。

1. Swarm Manage、Client 节点向 Consul 服务发现注册，当前 Manage 在 Consul 处于加锁状态；
2. Roam 根据 IDC 参数从 Consul 获取需要调度机房 Manage 信息；
3. Roam 弹性调度策略，访问当前 Manage，选择资源动态扩缩容；
4. Swarm Mange 从 Consul 获取节点信息，30s 缓存 Node 节点信息。

当其中一组 Master 节点宕掉，Standby Master 注册进入 Consul 成为新主节点。

自定义调度策略

简单介绍下 Swarm 的调度算法：调度 = 主机 or 容器过滤 + 策略选择

• 主机 / 容器过滤通过过滤器（标签）实现 docker run --label idc=“tc”；
• 主机 / 容器过滤后，根据各个节点的可用的 CPU， Mem 及正在运行的容器的数量来计算应该运行容器的节点进行打分，剔除掉资源不足的主机。

调度颗粒度

• Memory：docker run –m 1g …
• CPU：docker run –c 1 …

所有的调度框架分组调度都是标签，Swarm 基于 Docker Deamon Label 标签（注：Docker Label 标签修改必须重启 Docker Deamon，在最近官方 Docker 1.10.0 版本已支持 Docker Engine 配置热更新，使容器与 Docker Deamon 的耦合性大大降低）。在 Docker Label 标签基础上，对标签进行扩展和落地存储，记录和执行不同调度策略，集成 Swarm 调度算法，支持跨集群 / 服务池调度、指定 IP 规划、定时调度、多实例调度等。

离线计算资源调度

微博备战元旦峰值时，需要整合离线技术资源及公司其他业务线带来了新的挑战。离线 Hadoop 计算资源服务器大多操作系统为 CentOS6.*，CentOS6.* 支持 Docker 1.6.2 版本存在 bug，而 Swarm 调度获取内存、CPU 资源信息依赖 Docker 版本必须大于 Docker 1.6.2。以此为契机 Roam 扩展支持 Mesos + Marathon、直接 Docker Demon 下发两种调度方式。

弹性调度系统

不同调度框架按照集群进行划分，统一由 Roam 提供 Rest API 管理。完整的调度系统也依赖周报体系建设：服务编排、服务发下、容量评估等构成弹性调度生态圈，其它模块后续将由微博平台其它同学来给大家介绍，敬请关注 InfoQ 专栏。

业务跨云弹性调度

如何将业务合理调度到计算节点上？

跨云业务部署时，应该使得业务以最小规模部署，在公有云上通过预付费方式，常态化部署业务的最小规模，并提供在线服务。另外应该尽量减少跨云专线的调用，保持带宽在可控范围之内，需要将业务后端资源 Memory Cache 等本地化，减少跨专线请求；一旦发生跨专线请求时，需要开启一些流量压缩的协议。同时，微博内部通过 WMB 缓存数据双向同步机制，基于消息分发策略，在专有云内部对缓存的读写以消息的方式同步到公有云的缓存上，延迟一般在毫秒级，同时在专线出现异常时，消息不会丢失，保证高可用。

微博弹性调度离不开微博高可用多机房架构。上图是 2016 年春晚时微博的业务混合云部署形态。内部是典型的后端互联网服务技术站，通过四层的负载，用 Nginx 实现七层负载，再往后是一些 Web 层的计算和 RPC 服务，最下面是缓存层的资源、数据库。由于数据库的请求量和数据安全要求比较高，因此暂时没有将 DB 层放到公有云上。架构的中间是采用了 SLB 服务、之下的 RPC、Web、Nginx 都是部署在 ECS 上的。

春晚峰值流量来临优先弹性内网资源。阿里云常备部署不需要弹性资源如缓存 Memcache、队列处理机等依赖。Web 前端机常规 30 台机器，春晚主体弹性扩容 Web 前端机至 1000+，很好完成备战三节。

综上所述弹性调度系统采用了开源的解决方案，例如 Swarm、Mesos 等。在它们的基础上封装了统一调度的 API，将原来专有云内分散的各个应用平台统一到一起，大大节省在基础运维上的时间成本。

总结

弹性调度作为新浪微博混合云架构的重要组件，其框架选型要从业务需求出发来设计系统架构。而业务落地要考虑资源调度框架对周边技术体系建设的依赖，考虑通用性设计实现，以及技术架构的迭代升级。弹性调度后续发展方向为数据中心操作系统，整合在线、离线资源，以更大程度地提高资源利用率。

感谢魏星对本文的策划和审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。