编者按:《微博混合云架构》专栏是InfoQ向新浪微博技术团队的系列约稿,本专栏包含8篇内容,详细阐述以DCP设计理念为指导思想的混合云架构实践。本文是该系列的第一篇,主要讲解了在新浪微博业务背景下DCP的核心设计思想和三大层(主机层、调度层、业务编排层)的架构。
《微博混合云架构》专栏主要包括以下8篇内容:
2011年初,新浪微博进入快速发展期,同时也开启平台化的进程,服务器设备及人力成本大量增加,业务的快速发展促使我们建立了一套完整的运维平台Jpool。虽然已稳定运行了3年,但随着公有云的逐渐成熟、Docker Container技术的兴起,我们也于14年底构建了第一版基于Docker的运维平台,并在元旦、春节、红包飞等大型活动中得到了考验。但是要想更好的应对微博的这种业务场景,我们的系统还很多局限,比如设备申请慢、业务负载饱和度不一、扩缩容流程繁琐且时间长等。基于此,我们与RD一起设计与实现了一套基于Docker的混合云平台DCP(Docker Container Platform)。
目前这套系统,已经具备10分钟内弹性扩容1000节点的能力,已经在2015年的双十一、三节(圣诞、元旦、春晚)、红包飞等场景中得到了很好的考验。目前平台容器数已经有3000+了,占平台Web业务的90%。也在公司内做了推广,像手机微博、红包飞等业务也已经接入。
先来看看春晚的战绩:2015年的春晚,在不到2天的时间内共完成1375台阿里云ECS的扩容,实现了无降级业务的情况下平滑地抗住了春晚的峰值。此外,运维与开发相对往年轻松很多。其中阿里云支撑了核心业务50%的流量。详情如下:
微博目前有8亿注册用户,日活用户数达1亿多。微博核心总体分为端和后端平台,端上主要是PC端,移动端,开放平台以及企业开放平台。后端平台主要是Java编写的各种接口层、服务层、中间件层及存储层。除此之外,微博搜索、推荐、广告、大数据平台也是非常核心的产品。从业务角度看,整体架构图如下:
我们团队主要负责的微博平台的业务与保障,平台在2015年的部署架构如下:
就平台前端来说,每日超过600亿次的API调用、超过万亿的RPC调用,产生的日志就达百T+。对于这么大体量的业务系统,对于运维的要求也很严格;就接口层来说,SLA必须达到4个9,且接口平均响应时间不能高于50ms。因此我们会面临各种各样的挑战。
业务上具有以下挑战:
我们可以来具体看下春晚时的业务模型:
每年的元旦、春晚、红包飞会为我们带来巨大的流量挑战,这些业务场景的主要特点是: 瞬间峰值高,互动时间短 。基本上一次峰值事件,互动时间都会3小时以内;而明星丑闻事件、红包飞这种业务,经常会遇到高达多倍的瞬间峰值。传统的应对手段,主要是“靠提前申请足够的设备保证冗余、降级非核心及周边的业务、生扛”这三种手段。这么做,除了成本高外,我们在对系统进行水平扩容时,耗费的时间也较长。
除了来自业务的挑战,在应对峰值事件时,对于运维的挑战也是蛮大的。大家吐槽最多的莫过于 设备申请太麻烦,时间长;扩缩容流程繁琐 。
我们来看一次具体的扩容流程:
这种扩容的方式,除了流程繁琐外,还经常遇到各服务器间,各种环境差异,无法充分利用服务器硬件资源,即使有多余的服务器也无法灵活调度。
以往,在应对红包飞或三节保障时,总会采取新申请设备进行预扩容。申请设备的流程就更麻烦了。一般设备申请是业务方及业务运维发起采购提案,然后相关方进行架构评审;评审通过,则由IT管委会评审,再由决策及成本部门评审;评审通过,进入采购流程,再上架。还经常遇到机房机架位不足,这些都导致交付周期变得很长。这也迫使我们向业务上云的思路上转。具体可看下图:
除了业务扩容的繁琐,我们发现公司内设备利用率也不均衡,主要表现在三个地方:
为了更好地应对这些挑战,我们开始设计基于Docker及公有云来构建一套具有弹性伸缩的混合云系统。利用过去的私有云加公有云,以及公司内闲置的运算资源,构建混合云平台DCP,兼具安全性与弹性扩展能力。其特点如下图:
两种云内的设备,我们如何使用呢?我觉得内部私有云设备安全性高,可控度也高,只要对硬件资源进行优化配置,用它来处理固定的工作负载。而公有云的设备则具有标准化、自动化的特性,可以快速因临时需求,在流量暴涨时,让我们快速创建大量ECS,扩容业务工作负载的能力。
而对于公司,可以利用公有云这种按需付费的机制,降低硬件的运营成本。因此采用混合云架构,就可以兼具私有云及公有云的优点,可以同时拥有安全与弹性扩容能力,使业务工作负载可以在业务间进行漂移,低负载的业务就应该使用更少的设备,反之亦然。而基于Docker来做,对于我们的情况来说,复杂度降低很多。
有了这套混合云系统后,不仅能很好的整合内部运算资源,解决内部的弹性需求外,当系统面临流量剧增的峰值事件时,也可以将过多的流量切入外部公有云,减轻内部系统的压力。
企业用户出于安全考虑,更愿意将数据存放在私有云中,但是同时又希望可以获得公有云的计算资源,在这种情况下混合云被越来越多的采用。它将公有云和私有云进行混合和匹配,以获得最佳的效果,这种个性化的解决方案,达到既省钱又安全的目的。
从业界来看,已经有越来越多的企业,开始应用混合云的架构。典型的如12306的两地三中心部署架构,主要用于余票查询。除此之外,小米的秒杀业务也有使用公有云的资源进行接入层的峰值应对。而对于我们,是否也能采取类似方案呢?我们主要从以下角度考虑:
经过长达1个月的论证,我们觉得这种弹性的方案是非常靠谱的。于是迅速组织了一批人员,全力投入到混合云的开发,也就诞生了现在的DCP。
刚开始,我们把混合云项目整体方案设计的较大,就采用了协调跨部门的资源形成虚拟团队的方式进行开发。根据系统分层方向划分成多个项目小组,小组内选出一个负责人,负责整个小组的开发方向制定,方案制定以及开发进度推进;而小组背后的主管,则不直接参与项目,但是会作为项目组的决策人员。团队最多时聚集了10位开发人员。
微博混合云平台DCP的核心设计思想,主要是借鉴银行的运作机制,在内部设立一个计算资源共享池外,既然内部私有云的需求,又引入了外部公有云,使其在设备资源的弹性能力大大提升。
而要微博实现高弹性调度资源的混合云架构,其中实现的关键则是Docker。刚开始我们思考该使用裸机还是VM架构,发现如果要采用VM,内部机房架构要进行许多改造,这样成本会更高。所以,目前微博的内部私有云使用裸机部署,而外部公有云则采用阿里云弹性计算服务(ECS)的VM架构。等平台建设成熟后,还可以应用其他家的公有云,如AWS,在主机之上均采用Docker来持续部署。
目前我们开发的DCP平台,主要包含4层架构:主机层、调度层及业务编排层,最上层则是各业务方系统。底层的混合云基础架构则架Dispatch设了专线,打通微博内部私有云以及阿里云。
主要思想:三驾马车(Machine + Swarm + Compose)
DCP混合云系统的设计理念,总共包含4个核心概念:弹性伸缩、自动化、业务导向以及专门为微博订制。混合云系统必须有弹性调度的运算能力。而DCP混合云系统并不是对外公开的产品化服务,必须以业务需求出发,因此会有包含许多微博定制的功能。
DCP系统最核心的3层架构:主机层、调度适配层及编排层:
主机层的核心是要调度运算资源。目前设计了资源共享池、Buffer资源池,配额管理,及多租户管理机制,借此实现弹性调度资源。
而调度层则通过API,把调度工具用API进行包装,而微博4种常用的调度工具组合包含:原生Docker、Swarm、Mesos及微博自主开发的Dispatch。
最上层的则是负责业务编排及服务发现。目前,微博的后端服务95%是Java环境,而PC端则是使用PHP编写,移动端则是通过调用API服务。这些业务方都将会接入DCP。编排层也包括了大数据工具Hadoop,进行大数据分析的业务场景。
我们知道,对于调度来说,最重要的就是资源管理,Mesos处理这个是最合适不过了,很多公司就专用其做资源管理,比如Netflix写了一个Titan的调度服务,其底层资源管理则是通过Mesos。当然我们的调度组件中,使用最多的还是Swarm、Dispatch.
我们可以看下面这个场景:这也是私有云内部资源流转的最佳实践:
当业务A多余的运算资源导入混合云共享池时,此时流量暴涨的业务C,可从共享池调度业务A的运算资源;峰值事件后,便可以把多余的运算资源归还至共享池。
这层主要根据业务场景模型,通过主机层、调度层的API,创建可编排的任务模型,如集群管理、服务管理、服务池管理、镜像管理、构建管理、负载均衡管理、扩缩容管理等。
从使用角度出发,我们主要划分了集群、服务池、设备Buffer等层次,以IP+Port唯一标识服务。如下图:
其中:在DCP下可以创建多个集群,每个集群为独立平台或产品线,如微博平台、红包飞、手机微博等。集群间相互独立,集群内各自的服务可自由调度,集群外的调度则设置了配额机制。在集群下,可以创建服务池,一般为同一业务的同构服务。主机只有进了集群的Buffer中,才可能被用来部署服务。
DCP对于物理主机的流转,基于资源共享池、Buffer资源池、配额管理,及多租户管理机制,还是非常复杂的,这里我们可以看一下一台物理主机的生命周期(状态流转图)
理解了DCP的核心设计思想和3大层,基本上对微博混合云的方案有了初步的了解,但是从整体角度讲,这只是冰山一角。后续我们将深入分享更多技术细节。敬请期待。