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

微博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原创首发，未经授权谢绝转载。