【APMCon 2016】新浪微博研发中心资深架构师付稳:新浪微博混合云DCP平台的设计与实践

如需转载请联系听云College团队成员小尹 邮箱:yinhy#tingyun.com

中国应用性能管理行业盛宴——2016中国应用性能管理大会(简称APMCon 2016)于8月18日至19日在北京新云南皇冠假日酒店隆重召开。APMCon由听云、极客邦和InfoQ联合主办的作为国内APM领域最具影响力的技术大会,首次举办的APMCon以“驱动应用架构优化与创新”为主题,致力于推动APM在国内的成长与发展。

新浪微博研发中心资深架构师 付稳于基于云架构的性能优化专场发表了题为《新浪微博混合云DCP平台的设计与实践》的演讲,现场解读了微博平台面临的挑战,设计与实现基于Docker的大规模混合云平台DCP以及微博平台Java后端服务应用混合云平台及稳定性实践。

以下为演讲实录:

1.jpg

付稳:首先做个自我介绍,我叫付稳。本次分享的主题是基于Docker的混合云架构和应用实践,我今天讲Docker不会讲底层原理、网络模式,这些大家在很多大会上都听过了。我本次主要讲的是微博面对每天百亿级的访问,四五亿用户量的情况下,我们如何在10分钟内做到快速峰值应对以及一些性能优化遇到的问题。

主要分为几个部分,首先介绍我们整个项目的背景、挑战、实现,然后会对整个基础架构的每个部分进行介绍,比如基础设施、弹性调度、服务的编排,最后简单介绍下春晚的实战和总结。

一、背景、挑战与实现

首先介绍第一部分背景与挑战,微博的用户量现在肯定是几亿+的规模,线上的服务器也是上千台的规模,任何一次迭代升级对我们来说都是一次挑战。就像前两天的宝宝事件和奥运事件,特别是宝宝事件,对我们的影响更大,我们会在10分钟之内流量翻了两三倍,从11点到11点20涨三倍,过一会儿又下去了。假如我们内网有2000台服务器,我们怎么应对这个峰值呢?这个峰值会使我们所有的服务器都呈现两倍流量的增长,假如我们再采购2000台机器,按照原来的模式,几个月就过去了。另外,我们对于春晚的应对,还有娱乐事件,都给我们提出了技术的挑战,如何在10分钟之内完成1000节点扩容能力?总的来说峰值挑战有以下几个问题:极端峰值、扩展性、成本以及业务快速迭代。

我们怎么来做呢?考察国内外之后发现现在混合云是比较大的趋势,国外的一些公司以及国内的12306都通过混合云的方式解决了峰值问题,使大型的动态调度成为可能。

2.jpg

先来说一个标准的例子,大家都了解12306,70%的流量是余票查询,使用混合云的方式在云端进行查询,使用云端的扩展来控制余票流量问题。但是,这里面的余票是每5分钟进行一次同步,用户在刷微博的时候不可能要求五分钟之后看到,我们的实时性要求更高一些。

DCP项目的成果有哪些?我们混合云内部容器数量是3000+,春晚是10分钟扩容1000个节点,春晚峰值历史新高,两天内完成1375台阿里云ECS扩容,这只是机器数量,容器的数量更多,实现无降级平滑过渡,高峰支持微博50%主体流量,包括其他的业务方都通过这个平台进行接入。每天的晚高峰,因为微博的服务特点是中午和晚上比较高,平时流量比较低,在晚高峰的时候我们会进行弹性扩容,过了12点之后会进行缩容,达到成本的节约。加上宝宝事件的时候,我们会对这些事件进行预估,达到动态扩容。

混合云的架构总结为两个方面,一个是基于Docker的弹性调度,还有就是基于基础设施的跨云。为什么这里来说基础设施的跨云呢?就是你拿到一台阿里云的主机,你什么都干不了,你怎么样快速的应用到服务,从机器的创建到服务应用,怎么样在10分钟以内做到呢?微博在2014年的时候已经做了计划,包括私有云都在建设中,去年我们主要做了混合云的架构。

3.jpg

这是微博混合云DCP的技术架构图,类似于Docker的三驾马车。编排层我们加入了不同语言的服务。比如我要申请16核16G的100台机器,会向调度层要资源,如果调度层有资源,会把资源返回给业务编排层,然后进行服务发现。但如果调度层没有资源会通过主机层创建主机,创建主机我们现在是对接多云,包括内网的私有云统一对接,对阿里云、内网私有云进行创建,然后进行成本的计算。创建主机后会进行初始化,比如Docker环境的初始化、系统环境的初始化,达到可运行的状态,之后给他资源再进行编排。当然这离不开一些周边的内容包括服务发现、镜像中心、监控中心、容量评估等,这就是整体的架构。

4.jpg

简单看下技术栈,目前采用的是CentOS 7.0、Docker 1.6.2、Host模式。为什么用Host模式?微博的访问我们是百亿级别,Web前端压力非常大,我们发现其他的网络模式对我们的性能损耗非常大,所以我们直接配置了Host模式。Docker仓库我们是V1、V2版本,在阿里云端和内网都有分布式的存储,还有一些Swarm、Mesos等等我们都是有应用的。

5.jpg

这里说一下整个混合云DCP的流程,首先是主机的申请包括内网主机和云端的申请,然后进行初始化,会有一些系统环境的初始化和Docker环境的初始化,初始化之后这台机器基本上是一个可容器调度的状态,然后进行动态调度,之后进行容器启动,然后服务发现,运行起来,之后快速下线,如果服务暂停的话要进行快速下线。整个过程中链路有四五个模块,但是可以在10分钟内完成。

二、Weibo DCP 基础设施

接下来我们说一下基础设施,在内网的概念基本上是化零为整。因为微博的业务大家了解,刷PC端大部分是中午,手机微博是晚上。假如中午的时候PC端流量比较高,我可以把手机微博的业务进行下线,放入共享池给PC端应用,就是一个资源共享池的概念,资源综合利用。

6.jpg

7.jpg

公有云上我们做了非常细致和高可用的工作,首先是阿里云的接口,通过我们自建的控制台可以大批量的同时创建,包括他们之间的性能bug我们也进行了解决。比如我们封装了阿里云的接口,封装阿里云的接口进行机器创建的时候就要注意,我们会自己定制自己的VM镜像,这个VM镜像会把我自己所需要的环境和软件构建一个快照,下次创建的时候就会用这个快照,10分钟扩容1000台,假如我们的基础镜像没有在VM里面,如果100台是70G,1000台就是700G,这么大的容量对分布式的镜像,对任何一个网络或者带宽,包括CPU都是扛不住的。所以我们把主要的镜像放在VM里面,所有需要预装的东西都放到VM镜像里面。

通过上面的介绍我的机器已经创建,现在该怎么做呢?肯定要进行初始化,把里面所有的软件进行启动并进行配置的修改。配置管理,在内网我们用的是puppet,在阿里云用的是AnsibLe。我们的配置初始化就是选择已有的VM镜像创建ECS,创建之后会进行Docker的启动以及一些初始化,通过配置管理通道进行执行,执行之后就是一个可运行的状态。

在Ansible我们做了一些优化,大家用Ansible都知道,性能瓶颈是百台规模级别,所以我们做了优化:

  • SSH开启pipelining和ControlPersist

  • Ansible前端增加调度队列,单机控制并发数

  • 在VM镜像中预先安装部分软件,如dnsmasq等

  • 自定义callback,异步向队列中写入结果

通过上面的主机创建,初始化之后,基本上拿到的就是一个Java的Host或者Php Host的可以运行的容器环境。

8.jpg

这里简单再说一下我们的Docker镜像仓库,我们一个基础镜像比如CentOS、Tomcat等等,这些大概有700M,如果我们每次从内网拉是不现实的,两端之间的带宽只有10G,我们做了分布式的镜像仓库,阿里云端进行了缓存,通过阿里云来拉,支持水平扩容。

9.jpg

镜像当然也是分层的,会有底层的CentOS层、JDK、JVM以及其他的分层设计,保证镜像拉取的力度比较少。当然还有DNS,我们在云端做了负载均衡,访问内网的数据库直接在云端进行劫持,就减少了链路之间的消耗,这都是一些实践经验,大家可以借鉴,要不然放在内网,有时候网络抖动对服务的访问影响还是非常大的。

10.jpg

在基础设施里面肯定离不开最重要的网络,我们在春晚的时候包括现在也是,通过两条专线分别处理,这两条专线都是实际的,同时我们拉到VPN网络。这两条专线任何一个断了之后,另外一个自动进行路由适配,连到阿里云的机房。当然在阿里云内部我们是自己私有的VPN网络,通过两条专线进行网络的打通。

11.jpg

公有云大概有20%的性能差,也就是和内网的实体机同等性能下只有内网机80%的性能,当然还有其他的问题,最后我会把我们遇到的问题整体做一个介绍。

经过以上模式,我们进行了主机创建,也进行了初始化,有了Docker和运行环境,我们应该进行弹性调度。

三、Weibo DCP 弹性调度

12.jpg

谈到弹性调度离不开大家都在说的Swarm,所以我们当时也做了一个很书面的调研,现在我感觉适合的就是最好的。当时我们用的是Swarm,总体来说它能满足微博的业务场景,所以我们就选择它。这里也有很多人问我选择哪种技术框架,我的建议不要太纠结,首先分析你的业务场景,然后看这个调度框架是否能满足,如果差距太大就换其他的技术框架,你要根据你的需求进行分析和定制。

13.jpg

简单看下我们的需求,我们的需求有互斥的动态扩缩容,跨数据链的调度,容量的评估与监控等等,这是我上面说的任何一个调度框架都无法满足的,所以我们做了二次的分发与适配。简单来说可以通过一个Roam层下发你的IDC、Service、调度策略,比如我要资源最少的机器,实现功能最多的机器,包括我要内存16核16G,多少台,要根据策略去选择,比如说Docker直接管理还是用Swarm管理还是用Mesos管理。

14.jpg

我们用的Swarm规模也是国内前几位的。我们用Swarm当时是1.0,现在已经1.4了,很多问题已经解决了,比如调度性能、调度算法以及高可用的调度等。

15.jpg

说到调度肯定要涉及到内存和资源调度,Swarm到底是怎么调度的?比如调度的主机分为两个部分,一个是主机和容器的过滤,还有一个是策略的选择,会根据你容器设置的标签,包括一些亲和性和依赖,或者端口的依赖,然后对剩下的每个节点进行CPU内存的计算,来确定它选择哪些资源。调度策略基本上分为以下几个方面,在同等条件下,我是选用现在资源已使用最多的节点?还是使用最少的节点?还是随机选择?通过上面的容器过滤加上策略选择,基本上能选出资源分配的节点。

16.jpg

这是调度算法最核心的代码,大家简单了解一下。把你现在用的CPU资源、内存的资源进行积分,当你的分值同时小于100会得出你的资源进行权重排序。大家用Swarm可能要注意一点,资源只与容器Create时配置有关,与运行时实际使用资源情况无关,要注意这个情况。

四、Weibo DCP 编排与实现

17.jpg

编排最重要的就是共享池这个功能。根据你的容量评估系统,你现在有100台服务器,有80台可以控制,是容器可以动态调度的。比如我们内网私有云资源进行弹性调度,如果内网资源不够,没有空闲资源的话会扩展到公有云弹性,我们的私有云与公有云同时进行弹性扩容的场景也很多。

刚才说了几个步骤,设备的申请,进行初始化,初始化就是标准化环境、配置管理、Docker环境的启动,服务上线,服务上线包括容器的动态调度、服务弹性扩缩容。

18.jpg

这里面要注意所有做语音或者做资源管理的时候都会有配额管理,我们会给每个业务方分配一个配额,都会从共享池拿资源,因为这是面向全公司的系统,各个部门都会要资源,我们会有一个配额管理,大家在设计这类系统的时候要注意。

19.jpg

这是我们真正系统的一个内部截图,就是现在阿里云创建主机的申请案例。我会选择是哪个业务方,在阿里云的哪个机房,比如说哪个交换机,刚才我说的并发瓶颈就是在这里,单机创建只有50%,包括他的机器规格、内存、申请的数量,申请之后我会选择一批网络。这里面也有基础镜像,比如这是我们的品牌活动,我把一些技术红包,比如说PC的环境放到VM镜像里面,一点确定就会进行创建。

20.jpg

然后进行初始化,可以看这个流程,设备申请会向Buffer池进行申请,然后向内网共享池要资源,要到资源之后内网通过puppet外网通过Ansible进行初始化,同时会有完整的初始化报告,比如Docker是否启动,调度详情的报告,包括有可干预的手段,初始化都是处于分钟级的完成。

21.jpg

初始化之后进行扩容,根据每个业务方有不同的服务类型,我们定制了标准化,对每个服务池预先分配了8和12G,简化了整个流程,我们的目标是10分钟之内快速扩容,定制这些标准让用户直接进行选择,批量到上面创建机器的接口。

22.jpg

大家可以看我的扩容的过程,扩容就是启动容器,看你的容器是否启动成功,如果失败了我可以重做。管理员在管理混合型平台,根据配额进行创建,创建之后进行初始化,然后调度中心申请扩缩容调度,扩容之后向服务发现模块进行申请,同时在初始化的时候会把一些监控组件进行安装,服务一启动会自动的监控。

23.jpg

刚才也提到了扩容最后一个环节是服务发现的环节,就是跨云端的服务发现,也是比较难的问题。开源解决方案大多利用Nginx的Reload机制,当你的并发量比较大的时候,其实你的Reload方案是有损耗的,性能波动是比较大的。在我们亿级的访问量下,影响也很大,我们怎么做呢?我们内部开源了一个nginx-upsync-module 版本,容器启动之后我会把容器自动注册到服务发现的中心,Nginx的core包原来是靠这个来更新配置,现在我们自己开发了一个upsync-odule模块,这个模块会读取Consul里面的服务节点进行注册,然后进行变更,时间有限我不细介绍了,大家线下可以再看一下。

经过这个服务发现基本上我们可以平滑的支持扩容,但是还有一些问题,公有云之间的性能差,我们会进行权重的调整,这些都是比较实用的经验。包括刚才也有人提到了我们的RPC服务,我们在云端部署的RPC服务,流量也支持跨IDC的动态调配,包括按权重的调配。

所有的都讲完之后,其实你真正要上线1000台,或者一个机房重塑的话肯定不是简简单单的那几步就完成了,还有一个整体的防御标准化、监控、容量评估、干预手段,也都是非常重要的。

24.jpg

简单说一下我们的监控,有作战图类的,比如现在在云端扩容了多少服务器,多少容器,包括专线的带宽,实时的容量。我们只有20G带宽,专线的带宽方面我们做了优化,我们现在的经验包括电信联通,10G的专线,用到7G之后基本上会出现瓶颈;还有一些实时报警类;还有一些QPS监控、平均耗时;还有问题定位类,比如单机slow top、资源slow top。

25.jpg

简单的监控体系不再细介绍了,就是本机产生日志,推到一个日志中心进行显示。

同时还有一个容量决策系统,会根据你的单机平均系统指标(CPU idle、mem load)、QPS、带宽、业务的综合指标来指定我需要多少台,需要扩容多少台。还有一些业务的干预手段,我们的预案、服务降级,服务降级可以针对整个代码服务的逻辑层和资源层任何一个端口,代码层的任何一个逻辑都可以进行有效的干预,干预手段包括服务降级、流量切换、限流、数据修复等等。

五、春晚实战&总结

上面说的是云架构的东西,但是我们具体在云端部署哪些服务?比如说快速扩容1000台节点是什么样的?这是我们的两个机房,基本上就是标准的机房架构。正常规模下我们白天只有5到10台,晚高峰500台或1000台,过了12点就销毁。一台4块钱,1000台4000块钱,我用四个小时扛过峰值,就把他销毁,以往我买1000台机器可能是几千万成本的消耗。内网有缓存资源,保证有两三倍的冗余,平时的命中率是99.9%,如果缓存资源进行穿透会穿透到内网,进行资源的拉取。因为我们的缓存通过上面的高可用的,可以支持至少几十万的访问到上百万的访问量是没有问题的,他会支持两到三倍乃至十倍的访问量缓存,但是Web层会有性能瓶颈。

26.jpg

最后说几个问题,大家用阿里云并发量小的时候可能不会出现,但是我们在春晚的时候,我们性能一直不上去,会出现PPS打满的情况,在阿里云A区的时候,16核16G的PPS只有五六万,这个PPS就是网络转化包的数量。还有一些比如部署的ECS,PPS、IOPS在阿里云端非常低,A区的机器只有300,C区的有一千多,但是整体来说是在压缩日志,或者写磁盘日志的时候,就是因为写日志把整个性能搞出问题。春晚的时候我们创建了1000台,有大部分的机器出现性能差,刚开始我们没有上监控的时候根本发现不了问题,当时因为知道流量随时会来,我们就直接采用云端快速创建的方法解决。再说一个资源的DNS解决失败,就是阿里云的SLB被我们打挂了,阿里云HTTP协议包设置的上限是5万到10万,我们所有的域名解析、负载均衡都是通过SLB来做的,最后我们放弃用负载均衡,而是直接访问内网的域名。还有在多云端的时候大家可能会遇到带宽的情况,如果你在北京的核心机房,他们不会让你拿80G、40G的带宽,这里面的专线带宽流量调配也是实践经验。

最后说一下这个项目,归结一句话就是10分钟怎么创建1000台节点。首先要快速申请主机,然后进行初始化、服务调度、服务发现。很多人问我你这个架构是怎么来选择的,我的建议是不要过度来设计,适合你的就是最好的。比如,我们当时用的Swarm,其实到春晚的时候我们直接容器的资源隔离,比如我需要8核8G的机器就申请,我们需要解决的问题是怎样快速拿到我的容器资源,解决我的流量问题。所以这些资源隔离层面的问题,大家先要确定你自己的业务需求是怎样的,然后再选用调度框架、初始化环境框架或者各种配置管理的框架。

最后说一下DCP的开源,我上半年都在主导这个项目的开源。开源的目的是什么呢?你拿到我们的开源产品之后就能自动对接AWS、阿里云,然后进行主机创建、服务管理,包括云端的HA的服务发现、容器的管理、容器的调度,你拿到的是一体化的、服务化的Docker容器管理平台的环境。这个项目大家正在做,也欢迎大家在我的微博提一些需求,比如在云端或者用容器化自动扩充容或服务发现有什么问题,可以提一些需求,都会纳入到我们的开源计划来,反馈给大家。本次的分享因为时间有限,分享的内容也比较多,大家可以进行线下交流。

APMCon2016 演讲PPT合集下载

链接: http://pan.baidu.com/s/1mhFwaZQ 密码: bezk 


想阅读更多技术文章,请访问听云技术博客,访问听云官方网站感受更多应用性能优化魔力。

关于作者

APMCon2016

驱动应用架构优化与创新

我要评论

评论请先登录,或注册