如需转载请联系听云College团队成员小尹 邮箱：yinhy#tingyun.com
中国应用性能管理行业盛宴——2016中国应用性能管理大会（简称APMCon 2016）于8月18日至19日在北京新云南皇冠假日酒店隆重召开。APMCon由听云、极客邦和InfoQ联合主办的作为国内APM领域最具影响力的技术大会，首次举办的APMCon以“驱动应用架构优化与创新”为主题，致力于推动APM在国内的成长与发展。
新浪微博研发中心资深架构师 付稳于基于云架构的性能优化专场发表了题为《新浪微博混合云DCP平台的设计与实践》的演讲，现场解读了微博平台面临的挑战，设计与实现基于Docker的大规模混合云平台DCP以及微博平台Java后端服务应用混合云平台及稳定性实践。
以下为演讲实录：
付稳：首先做个自我介绍，我叫付稳。本次分享的主题是基于Docker的混合云架构和应用实践，我今天讲Docker不会讲底层原理、网络模式，这些大家在很多大会上都听过了。我本次主要讲的是微博面对每天百亿级的访问，四五亿用户量的情况下，我们如何在10分钟内做到快速峰值应对以及一些性能优化遇到的问题。
主要分为几个部分，首先介绍我们整个项目的背景、挑战、实现，然后会对整个基础架构的每个部分进行介绍，比如基础设施、弹性调度、服务的编排，最后简单介绍下春晚的实战和总结。
一、背景、挑战与实现
首先介绍第一部分背景与挑战，微博的用户量现在肯定是几亿+的规模，线上的服务器也是上千台的规模，任何一次迭代升级对我们来说都是一次挑战。就像前两天的宝宝事件和奥运事件，特别是宝宝事件，对我们的影响更大，我们会在10分钟之内流量翻了两三倍，从11点到11点20涨三倍，过一会儿又下去了。假如我们内网有2000台服务器，我们怎么应对这个峰值呢？这个峰值会使我们所有的服务器都呈现两倍流量的增长，假如我们再采购2000台机器，按照原来的模式，几个月就过去了。另外，我们对于春晚的应对，还有娱乐事件，都给我们提出了技术的挑战，如何在10分钟之内完成1000节点扩容能力？总的来说峰值挑战有以下几个问题：极端峰值、扩展性、成本以及业务快速迭代。
我们怎么来做呢？考察国内外之后发现现在混合云是比较大的趋势，国外的一些公司以及国内的12306都通过混合云的方式解决了峰值问题，使大型的动态调度成为可能。
先来说一个标准的例子，大家都了解12306，70%的流量是余票查询，使用混合云的方式在云端进行查询，使用云端的扩展来控制余票流量问题。但是，这里面的余票是每5分钟进行一次同步，用户在刷微博的时候不可能要求五分钟之后看到，我们的实时性要求更高一些。
DCP项目的成果有哪些？我们混合云内部容器数量是3000+，春晚是10分钟扩容1000个节点，春晚峰值历史新高，两天内完成1375台阿里云ECS扩容，这只是机器数量，容器的数量更多，实现无降级平滑过渡，高峰支持微博50%主体流量，包括其他的业务方都通过这个平台进行接入。每天的晚高峰，因为微博的服务特点是中午和晚上比较高，平时流量比较低，在晚高峰的时候我们会进行弹性扩容，过了12点之后会进行缩容，达到成本的节约。加上宝宝事件的时候，我们会对这些事件进行预估，达到动态扩容。
混合云的架构总结为两个方面，一个是基于Docker的弹性调度，还有就是基于基础设施的跨云。为什么这里来说基础设施的跨云呢？就是你拿到一台阿里云的主机，你什么都干不了，你怎么样快速的应用到服务，从机器的创建到服务应用，怎么样在10分钟以内做到呢？微博在2014年的时候已经做了计划，包括私有云都在建设中，去年我们主要做了混合云的架构。
这是微博混合云DCP的技术架构图，类似于Docker的三驾马车。编排层我们加入了不同语言的服务。比如我要申请16核16G的100台机器，会向调度层要资源，如果调度层有资源，会把资源返回给业务编排层，然后进行服务发现。但如果调度层没有资源会通过主机层创建主机，创建主机我们现在是对接多云，包括内网的私有云统一对接，对阿里云、内网私有云进行创建，然后进行成本的计算。创建主机后会进行初始化，比如Docker环境的初始化、系统环境的初始化，达到可运行的状态，之后给他资源再进行编排。当然这离不开一些周边的内容包括服务发现、镜像中心、监控中心、容量评估等，这就是整体的架构。
简单看下技术栈，目前采用的是CentOS 7.0、Docker 1.6.2、Host模式。为什么用Host模式？微博的访问我们是百亿级别，Web前端压力非常大，我们发现其他的网络模式对我们的性能损耗非常大，所以我们直接配置了Host模式。Docker仓库我们是V1、V2版本，在阿里云端和内网都有分布式的存储，还有一些Swarm、Mesos等等我们都是有应用的。
这里说一下整个混合云DCP的流程，首先是主机的申请包括内网主机和云端的申请，然后进行初始化，会有一些系统环境的初始化和Docker环境的初始化，初始化之后这台机器基本上是一个可容器调度的状态，然后进行动态调度，之后进行容器启动，然后服务发现，运行起来，之后快速下线，如果服务暂停的话要进行快速下线。整个过程中链路有四五个模块，但是可以在10分钟内完成。
二、Weibo DCP 基础设施
接下来我们说一下基础设施，在内网的概念基本上是化零为整。因为微博的业务大家了解，刷PC端大部分是中午，手机微博是晚上。假如中午的时候PC端流量比较高，我可以把手机微博的业务进行下线，放入共享池给PC端应用，就是一个资源共享池的概念，资源综合利用。
公有云上我们做了非常细致和高可用的工作，首先是阿里云的接口，通过我们自建的控制台可以大批量的同时创建，包括他们之间的性能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的可以运行的容器环境。
这里简单再说一下我们的Docker镜像仓库，我们一个基础镜像比如CentOS、Tomcat等等，这些大概有700M，如果我们每次从内网拉是不现实的，两端之间的带宽只有10G，我们做了分布式的镜像仓库，阿里云端进行了缓存，通过阿里云来拉，支持水平扩容。
镜像当然也是分层的，会有底层的CentOS层、JDK、JVM以及其他的分层设计，保证镜像拉取的力度比较少。当然还有DNS，我们在云端做了负载均衡，访问内网的数据库直接在云端进行劫持，就减少了链路之间的消耗，这都是一些实践经验，大家可以借鉴，要不然放在内网，有时候网络抖动对服务的访问影响还是非常大的。
在基础设施里面肯定离不开最重要的网络，我们在春晚的时候包括现在也是，通过两条专线分别处理，这两条专线都是实际的，同时我们拉到VPN网络。这两条专线任何一个断了之后，另外一个自动进行路由适配，连到阿里云的机房。当然在阿里云内部我们是自己私有的VPN网络，通过两条专线进行网络的打通。
公有云大概有20%的性能差，也就是和内网的实体机同等性能下只有内网机80%的性能，当然还有其他的问题，最后我会把我们遇到的问题整体做一个介绍。
经过以上模式，我们进行了主机创建，也进行了初始化，有了Docker和运行环境，我们应该进行弹性调度。
三、Weibo DCP 弹性调度
谈到弹性调度离不开大家都在说的Swarm，所以我们当时也做了一个很书面的调研，现在我感觉适合的就是最好的。当时我们用的是Swarm，总体来说它能满足微博的业务场景，所以我们就选择它。这里也有很多人问我选择哪种技术框架，我的建议不要太纠结，首先分析你的业务场景，然后看这个调度框架是否能满足，如果差距太大就换其他的技术框架，你要根据你的需求进行分析和定制。
简单看下我们的需求，我们的需求有互斥的动态扩缩容，跨数据链的调度，容量的评估与监控等等，这是我上面说的任何一个调度框架都无法满足的，所以我们做了二次的分发与适配。简单来说可以通过一个Roam层下发你的IDC、Service、调度策略，比如我要资源最少的机器，实现功能最多的机器，包括我要内存16核16G，多少台，要根据策略去选择，比如说Docker直接管理还是用Swarm管理还是用Mesos管理。
我们用的Swarm规模也是国内前几位的。我们用Swarm当时是1.0，现在已经1.4了，很多问题已经解决了，比如调度性能、调度算法以及高可用的调度等。
说到调度肯定要涉及到内存和资源调度，Swarm到底是怎么调度的？比如调度的主机分为两个部分，一个是主机和容器的过滤，还有一个是策略的选择，会根据你容器设置的标签，包括一些亲和性和依赖，或者端口的依赖，然后对剩下的每个节点进行CPU内存的计算，来确定它选择哪些资源。调度策略基本上分为以下几个方面，在同等条件下，我是选用现在资源已使用最多的节点？还是使用最少的节点？还是随机选择？通过上面的容器过滤加上策略选择，基本上能选出资源分配的节点。
这是调度算法最核心的代码，大家简单了解一下。把你现在用的CPU资源、内存的资源进行积分，当你的分值同时小于100会得出你的资源进行权重排序。大家用Swarm可能要注意一点，资源只与容器Create时配置有关，与运行时实际使用资源情况无关，要注意这个情况。
四、Weibo DCP 编排与实现
编排最重要的就是共享池这个功能。根据你的容量评估系统，你现在有100台服务器，有80台可以控制，是容器可以动态调度的。比如我们内网私有云资源进行弹性调度，如果内网资源不够，没有空闲资源的话会扩展到公有云弹性，我们的私有云与公有云同时进行弹性扩容的场景也很多。
刚才说了几个步骤，设备的申请，进行初始化，初始化就是标准化环境、配置管理、Docker环境的启动，服务上线，服务上线包括容器的动态调度、服务弹性扩缩容。
这里面要注意所有做语音或者做资源管理的时候都会有配额管理，我们会给每个业务方分配一个配额，都会从共享池拿资源，因为这是面向全公司的系统，各个部门都会要资源，我们会有一个配额管理，大家在设计这类系统的时候要注意。
这是我们真正系统的一个内部截图，就是现在阿里云创建主机的申请案例。我会选择是哪个业务方，在阿里云的哪个机房，比如说哪个交换机，刚才我说的并发瓶颈就是在这里，单机创建只有50%，包括他的机器规格、内存、申请的数量，申请之后我会选择一批网络。这里面也有基础镜像，比如这是我们的品牌活动，我把一些技术红包，比如说PC的环境放到VM镜像里面，一点确定就会进行创建。
然后进行初始化，可以看这个流程，设备申请会向Buffer池进行申请，然后向内网共享池要资源，要到资源之后内网通过puppet外网通过Ansible进行初始化，同时会有完整的初始化报告，比如Docker是否启动，调度详情的报告，包括有可干预的手段，初始化都是处于分钟级的完成。
初始化之后进行扩容，根据每个业务方有不同的服务类型，我们定制了标准化，对每个服务池预先分配了8和12G，简化了整个流程，我们的目标是10分钟之内快速扩容，定制这些标准让用户直接进行选择，批量到上面创建机器的接口。
大家可以看我的扩容的过程，扩容就是启动容器，看你的容器是否启动成功，如果失败了我可以重做。管理员在管理混合型平台，根据配额进行创建，创建之后进行初始化，然后调度中心申请扩缩容调度，扩容之后向服务发现模块进行申请，同时在初始化的时候会把一些监控组件进行安装，服务一启动会自动的监控。
刚才也提到了扩容最后一个环节是服务发现的环节，就是跨云端的服务发现，也是比较难的问题。开源解决方案大多利用Nginx的Reload机制，当你的并发量比较大的时候，其实你的Reload方案是有损耗的，性能波动是比较大的。在我们亿级的访问量下，影响也很大，我们怎么做呢？我们内部开源了一个nginx-upsync-module 版本，容器启动之后我会把容器自动注册到服务发现的中心，Nginx的core包原来是靠这个来更新配置，现在我们自己开发了一个upsync-odule模块，这个模块会读取Consul里面的服务节点进行注册，然后进行变更，时间有限我不细介绍了，大家线下可以再看一下。
经过这个服务发现基本上我们可以平滑的支持扩容，但是还有一些问题，公有云之间的性能差，我们会进行权重的调整，这些都是比较实用的经验。包括刚才也有人提到了我们的RPC服务，我们在云端部署的RPC服务，流量也支持跨IDC的动态调配，包括按权重的调配。
所有的都讲完之后，其实你真正要上线1000台，或者一个机房重塑的话肯定不是简简单单的那几步就完成了，还有一个整体的防御标准化、监控、容量评估、干预手段，也都是非常重要的。
简单说一下我们的监控，有作战图类的，比如现在在云端扩容了多少服务器，多少容器，包括专线的带宽，实时的容量。我们只有20G带宽，专线的带宽方面我们做了优化，我们现在的经验包括电信联通，10G的专线，用到7G之后基本上会出现瓶颈；还有一些实时报警类；还有一些QPS监控、平均耗时；还有问题定位类，比如单机slow top、资源slow top。
简单的监控体系不再细介绍了，就是本机产生日志，推到一个日志中心进行显示。
同时还有一个容量决策系统，会根据你的单机平均系统指标（CPU idle、mem load）、QPS、带宽、业务的综合指标来指定我需要多少台，需要扩容多少台。还有一些业务的干预手段，我们的预案、服务降级，服务降级可以针对整个代码服务的逻辑层和资源层任何一个端口，代码层的任何一个逻辑都可以进行有效的干预，干预手段包括服务降级、流量切换、限流、数据修复等等。
五、春晚实战&总结
上面说的是云架构的东西，但是我们具体在云端部署哪些服务？比如说快速扩容1000台节点是什么样的？这是我们的两个机房，基本上就是标准的机房架构。正常规模下我们白天只有5到10台，晚高峰500台或1000台，过了12点就销毁。一台4块钱，1000台4000块钱，我用四个小时扛过峰值，就把他销毁，以往我买1000台机器可能是几千万成本的消耗。内网有缓存资源，保证有两三倍的冗余，平时的命中率是99.9%，如果缓存资源进行穿透会穿透到内网，进行资源的拉取。因为我们的缓存通过上面的高可用的，可以支持至少几十万的访问到上百万的访问量是没有问题的，他会支持两到三倍乃至十倍的访问量缓存，但是Web层会有性能瓶颈。
最后说几个问题，大家用阿里云并发量小的时候可能不会出现，但是我们在春晚的时候，我们性能一直不上去，会出现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
分享到微信
分享到微博
