中国应用性能管理行业盛宴——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容器管理平台的环境。这个项目大家正在做，也欢迎大家在我的微博提一些需求，比如在云端或者用容器化自动扩充容或服务发现有什么问题，可以提一些需求，都会纳入到我们的开源计划来，反馈给大家。本次的分享因为时间有限，分享的内容也比较多，大家可以进行线下交流。 
作者的其他文章
dell 66666 test
dell 555555 第二堂课（关于php是拍黄片的事情）
dell four test
dell three test
dell 第二堂课（关于php是拍黄片的事情）
本网页所有文字内容由 imapbox邮箱云存储,邮箱网盘, iurlBox网页地址收藏管理器 下载并得到。
ImapBox 邮箱网盘 工具地址: https://www.imapbox.com/download/ImapBox.5.5.1_Build20141205_CHS_Bit32.exe
PC6下载站地址：PC6下载站分流下载
本网页所有视频内容由 imoviebox边看边下-网页视频下载, iurlBox网页地址收藏管理器 下载并得到。
ImovieBox 网页视频 工具地址: https://www.imapbox.com/download/ImovieBox.5.1.6_Build20151120_CHS_Bit32.exe
本文章由: imapbox邮箱云存储,邮箱网盘,ImageBox 图片批量下载器,网页图片批量下载专家,网页图片批量下载器,获取到文章图片,imoviebox网页视频批量下载器,下载视频内容,为您提供.
阅读和此文章类似的: 全球云计算
官方软件产品操作指南 (170)
