微博基于Docker容器的混合云迁移实战

原文  http://h2ex.com/393

 

一、为什么要采用混合云的架构

在过去很长的时间内，大部分稍大些的互联网系统包括微博都是基于私有体系的架构，可以在某种程度理解成私有云系统。混合云，顾名思义就是指业务同 时部署在私有云和公有云，并且支持在云之间切换。实际上“为什么要采用混合云”这个问题，就等于“为什么要上公有云”。我们的考虑点主要有四个方面

业务场景

随着微博活跃度的提升，以及push常规化等运营刺激，业务应对短时极端峰值挑战，主要体现在两个方面：

• 时间短，业务需要应对分钟级或者小时级。
• 高峰值，例如话题经常出现10到20倍流量增长。

成本优势

对于短期峰值应对，常规部署，离线计算几个场景，我们根据往年经验进行成本对比发现公有云优势非常明显

效率优势

公有云可以实现5分钟千级别节点的弹性调度能力，对比我们目前的私有云5分钟百级别节点的调度能力，也具有明显优势。

业界趋势

“Amazon首次公布AWS业绩：2014年收入51.6亿美元，2015年1季度AWS收入15.7亿美元，年增速超40%。”“阿里巴巴旗 下云计算业务阿里云营收6.49亿元，比去年同期增长128%，超越亚马逊和微软的云计算业务增速，成为全球增速最快的云计算服务商。”

我们预计未来产品技术架构都会面临上云的问题，只是时间早晚问题。

安全性

基于数据安全的考虑，我们现阶段只会把计算和缓存节点上云，核心数据还放在私有云；另外考虑到公有云的技术成熟度，需要支持在多个云服务直接进行业务灵活迁移。

基于上述几点考虑，我们今年尝试了以私有云为主，公有云为辅的混合云架构。核心业务的峰值压力，会在公有云上实现，业务部署形态可参考下图

下面介绍介绍技术实现。整体技术上采用的是Docker Machine + Swarm + Consul的框架。系统分层如下图

二、跨云的资源管理与调度

跨云的资源管理与调度（即上图中的pluto部分）的作用是隔离云服务差异，对上游交付统一的Docker运行环境，支持快速弹性扩缩容及跨云调度。功能上主要包括：

• 系统初始化
• 元数据管理
• 镜像服务
• 网络
• 云服务选型
• 命令行工具
• 其他

系统界面如下图：

系统初始化

最初技术选型时认为Machine比较理想，仅需要SSH通道，不依赖任何预装的Agent。我们也几乎与阿里云官方同时向Docker Machine社区提交了Driver的PR，然后就掉进了大坑中不能自拔。

例举几个坑：

• 无法扩展，Machine的golang函数几乎都是小写，即内部实现，无法调用其API进行功能扩展。
• 不支持并发，并发创建只能通过启动多个Machine进程的方式，数量多了无法承载。
• 不支持自定义，Machine启动Docker Daemon是在代码中写死的，要定义Daemon的参数就非常ugly。

目前我们采用的是Puppet的方案，采用去Master的结构。配置在GitLab上管理，变更会通过CI推送到pluto系统，然后再推送到 各实例进行升级。在基础资源层面，我们目前正在进行大范围基础环境从CentOS 6.5升级到CentOS 7的工作。做这个升级的主要原因是由于上层基于调度系统依赖Docker新版本，而新版本在CentOS 6.5上会引发cgroup的bug，导致Kernel Panic问题。

元数据的管理

调度算法需要根据每个实例的情况进行资源筛选，这部分信息目前是通过Docker Daemon的Label实现的，这样做的好处是资源和调度可以Docker Daemon解耦。例如我们会在Daemon上记录这个实例的归属信息：

目前Docker Daemon最大的硬伤是任何元数据的改变都需要重启。所以我们计划把元数据从Daemon迁移到我们的系统中，同时尝试向社区反馈这个问题，比如动态修 改Docker Daemon Label的接口（PR被拒，官方虽然也看到了问题，但是比较纠结是否要支持API方式），动态修改registry（PR被拒，安全因素），动态修改 Docker Container Expose Port（开发中）。

镜像服务

为了提升基础资源扩缩容的效率，我们正在构建虚机镜像服务。参考Dockerfile的思路，通过描述文件定义定义虚机的配置，支持继承关系，和简单的初始化指令。通过预先创建好的镜像进行扩缩容，可以节省大约50%的初始化时间。

不过虚机镜像也有一些坑，例如一些云服务会在启动后自行修改一部分配置，例如router, dns, ntp, yum等配置。这就是上面entrypoint的由来，部分配置工作需要在实例运行后进行。

网络

网络的互联互通对业务来说非常关键，通常来说有三种方案：公网，VPC+V*N，VPC+专线。公网因为性能完全不可控，而且云服务通常是按照出 带宽收费，所以比较适合相互通信较少的业务场景。VPC+V*N实际链路也是通过公网，区别是安全性更好，而且可以按照私有云的IP段进行网络规划。专线 性能最好，但是价钱也比较好，且受运营商政策影响的风险较大。

网络上需要注意的是包转发能力，即每秒可以收发多少个数据包。一些云服务实测只能达到10万的量级，而且与CPU核数、内存无 关。也就是说你花再多的钱，转发能力也上不去。猜测是云厂商出于安全考虑在虚机层面做了硬性限制。我们在这上面也中过枪，比如像Redis主从不同步的问 题等等。建议对于QPS压力比较重的实例进行拆分。

云服务选型

我们主要使用的是虚机和软负载两种云服务。因为微博对缓存服务已经构建一套高可用架构，所以我们没有使用公有云的缓存服务，而是在虚机中直接部署缓存容器。

虚机的选型我们重点关注CPU核数，内存，磁盘几个方面。CPU调度能力，我们测试总结公有云是私有云的1.2倍，即假设业务在私有云上需要6个核，在公有云上则需要8个。

内存写入速度和带宽都不是问题，我们测试发现甚至还好于私有云，MEMCPY的带宽是私有云的1.2倍，MCBLOCK是1.7倍。所以内存主要考虑的是价钱问题。

磁盘的性能也表现较好，顺序读写带宽公有云是私有云的1.4倍，随机写是1.6倍。唯一要注意的是对于Redis这种业务，需要使用I/O优化型的虚机。

以上数据仅供参考，毕竟各家情况不一样，我们使用的性能测试工具：sysbench, mbw, fio，可自行测试。

其他方面

跨域的资源管理和调度还有很多技术环节需要处理，比如安全，基础设施（DNS、YUM等），成本核算，权限认证，由于这部分通用性不强，这里就不展开了。

三、容器的编排与服务发现

提到调度就离不开发现，Swarm是基于Consul来做节点发现的。Consul采用raft协议来保证server之间的数据一致性，采用 gossip协议管理成员和传播消息，支持多数据中心。Consul集群中的所有请求都会重定向到server，对于非leader的server会将写 请求转发给leader处理。

Consul对于读请求支持3种一致性模式：

• default ：给leader一个time window，在这个时间内可能出现两个leader（split-brain情况下），旧的leader仍然支持读的请求，会出现不一致的情况。
• consistent ：完全一致，在处理读请求之前必须经过大多数的follower确认leader的合法性，因此会多一次round trip。
• stale ：允许所有的server支持读请求，不管它是否是leader。

我们采用的是default模式。

除了Swarm是基于Consul来做发现，业务直接也是通过Consul来做发现。我们服务采用Nginx来做负载均衡，开源社区的方案例如 Consul Template，都需要进行reload操作，而reload过程中会造成大量的失败请求。我们现在基于Consul实现了一个nginx- upsync-module。

这个模块是用C语言实现的，效率已经经过线上验证，目前验证在20W QPS压力没有问题。而且这个模块代码已经开源在Github上，也欢迎大家提Issue： https://github.com/weibocom/nginx-upsync-module 。

下图是我们做的几种方案的性能对比：

当然我们的RPC框架motan也会支持Consul，实现机制同样也是利用Consul的long polling机制，等待直到监听的X-Consul-Index位置发生变化，这个功能已经在我们内网验证通过，不过由于依赖整个motan框架，所以目前还没有开源。

Consul的监控

由于Consul处于系统核心位置，一旦出现问题会导致整体所有集群失联，所以我们对Consul做了一系列保障措施，其中所有Consul Server节点监控指标如下

Leader节点监控指标如下图

Consul的坑

除了使用不当导致的问题之外，Consul Server节点通信通道UDP协议，偶发会出现server不停被摘除的现象，这个问题官方已在跟进，计划会增加TCP的通道保证消息的可靠性。

容器调度

容器调度基于Swarm实现，依赖Consul来做节点发现（话说Swarm才刚刚宣布Production Ready）。容器调度分为三级，应用-应用池-应用实例，一个应用下有多个应用池，应用池可以按机房和用途等来划分。一个应用池下有多个Docker容 器形式的应用实例。

我们利用Swarm的Filter机制，实现了适应业务的调度算法。整个调度过程分为两步：主机过滤：指定机房、内存、CPU、端口等条件，筛选 出符合条件的主机集合；策略选择：对符合条件的主机集合进行打分，选择出最合适的主机，在其上创建容器以部署应用。调度子系统Roam实现了批量的容器调 度与编排。

业务调度

容器调度是于业务无关，具体串联起资源管理，容器调度，发现等系统，完成业务容器最终跨云部署的是我们的JPool系统。JPool除了完成日常 的业务容器上线发布之外，最重要的是完成动态扩缩容功能，使业务实现一键扩容、一键缩容，降低快速扩容成本。一次扩容操示意图如下

围绕这调度和发现，需要很多工具的支撑：

例如为了使业务接入更加方便，我们提供了自动打包工具，它包括代码打包、镜像打包的解决方案，支持svn、gitlab等代码仓库，业务仅需要在工程中定义pom.xml和Dockerfile即可实现一键打包代码，一键打包镜像，过程可控，接入简单。

我们还对Docker的Registry，我们进行了一些优化，主要是针对混合云跨机房场景，提供跨机房加速功能，整个服务架构如下：

四、混合云监控体系

微博体系在经历了多年的IT建设过程后，已经初步建立了一套完整的信息化管理流程，极大地提升了微博业务能力。同时微博开展了大量的IT基础设施建设(包括网络、机房、服务器、存储设置、数据库、中间件及各业务应用系统等)。

针对于混合云体系，我们提供了一套完整的监控告警解决方案，实现对于云上IT基础架构的整体监控与预警机制，最大程度地保证了微博体系能够稳定地运行在混合云体系上，不间断地为用户提供优质的服务。监控告警解决方案实现了四个级别上的监控与预警：

• 系统级监控
• 业务级监控
• 资源级监控
• 专线网络监控

系统级监控

混合云体系支持的系统级监控（与新浪sinawatch系统的对接）包括：CPU，磁盘，网卡，IOPS，Load，内存

业务监控

混合云体系集成了目前微博业务监控平台Graphite，自动提供了业务级别(SLA)的实时监控与告警。所有的配置与操作都是系统自动完成的，不需要用户进行额外的配置操作。

业务级别的监控包括：

• JVM监控: 实时监控堆、栈使用信息、统计gc收集时间、检查JVM瓶颈等。
• 吞吐量监控： 实时监控业务系统吞吐量(QPS或TPS)。
• 平均耗时监控: 实时监控业务系统接口的平均耗时时间。
• 单机性能监控: 实时监控单台服务器的各种业务指标。
• Slow监控: 监控服务器集群，实时显示当前业务系统中最慢的性能瓶颈。

资源监控

混合云体系集成了目前微博资源监控平台sinadsp，自动提供了对各种底层资源的实时监控与告警。所有的配置与操作都是系统自动完成的，不需要用户进行额外的配置操作。

具体的监控指标包括：命中率，QPS/TPS，连接数，上行/下行带宽，CPU，内存。

五、前进路上遇到的那些坑

需要注意的坑，实际在各部分中都有提及。今天分享的主要内容就是这些了，当然业务上云，除了上面这些工作之外，还存在很多技术挑战要解决。比如跨云的消息总线，缓存数据同步，容量评估，流量调度，RPC框架，微服务化等。

Q&A

Q1 : 为什么选Consul？看中有对比Zookeeper、etcd，尤其是etcd？

我们有对比etcd和consul，主要还是看重了consul基于K-V之外额外功能，比如支持DNS，支持ACL。另外etcd不对get request做超时处理，Consul对blocking query有超时机制。

Q2 : 上面提到的方案主要是Java体系， 对于其他语言（php, nodejs, golang）体系系统的是否有很好的支持（开发、测试、发布部署、监控等）？

已经在开始php的支持。其实容器化之后，所有语言都是适用的。

Q3 : Docker registry底层存储用的是什么，怎么保障高可用的？

底层使用的Ceph，前端无状态，通过DNS做跨云智能解析，加速下载。

Q4 : Consul temple reload nginx时为什么会造成大量请求失败呢，不是graceful的吗？

是graceful的，在QPS压力较大的情况下，由于需要进行大量重连，过程中会产生较多失败请求。

Q6 : 容器跨主机通信是host网络吗？