| 编辑推荐: |
本文主要讲解了在新浪微博业务背景下DCP的核心设计思想和三大层（主机层、调度层、业务编排层）的架构。
本文来自于搜狐，由火龙果软件Linda编辑、推荐。 |
|
背景
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。因此我们会面临各种各样的挑战。
挑战一：突发的峰值
业务上具有以下挑战：
产品功能迭代快，代码变更频繁；
业务模块多，且依赖关系复杂；
突发的热点事件，如典型的“周一见”、”马航370“、”刘翔摔倒”、“明星丑闻”；
大型活动及三节保障，如红包飞；
运营的各种站内，站外push，也会瞬间带量上来。
我们可以来具体看下春晚时的业务模型：
每年的元旦、春晚、红包飞会为我们带来巨大的流量挑战，这些业务场景的主要特点是：瞬间峰值高，互动时间短。基本上一次峰值事件，互动时间都会3小时以内；而明星丑闻事件、红包飞这种业务，经常会遇到高达多倍的瞬间峰值。传统的应对手段，主要是“靠提前申请足够的设备保证冗余、降级非核心及周边的业务、生扛”这三种手段。这么做，除了成本高外，我们在对系统进行水平扩容时，耗费的时间也较长。
挑战二：扩缩容繁琐
除了来自业务的挑战，在应对峰值事件时，对于运维的挑战也是蛮大的。大家吐槽最多的莫过于设备申请太麻烦，时间长；扩缩容流程繁琐。
我们来看一次具体的扩容流程：
首先基础运维做的：从采购拿到新机器录入CMDB，再根据业务运维提的需求，进行上架到相应的IDC、机架、操作系统安装、网络配置、最后分给相应的业务运维，就是一台完整的可以登录的机器了。
其次，业务运维拿到机器，需要对机器进行初始化配置，并继续服务部署。服务部署好后经过check，再挂到负载均衡上，引入流量。设备坏了自动报修，过期下架或替换。具体可看下图：
这种扩容的方式，除了流程繁琐外，还经常遇到各服务器间，各种环境差异，无法充分利用服务器硬件资源，即使有多余的服务器也无法灵活调度。
挑战三：设备申请周期长
以往，在应对红包飞或三节保障时，总会采取新申请设备进行预扩容。申请设备的流程就更麻烦了。一般设备申请是业务方及业务运维发起采购提案，然后相关方进行架构评审；评审通过，则由IT管委会评审，再由决策及成本部门评审；评审通过，进入采购流程，再上架。还经常遇到机房机架位不足，这些都导致交付周期变得很长。这也迫使我们向业务上云的思路上转。具体可看下图：
挑战四：运营成本高
除了业务扩容的繁琐，我们发现公司内设备利用率也不均衡，主要表现在三个地方：
各个业务组的服务器利用率各不相同，大家对利用率的理解不一致，导致有些设备未能得到充分利用。且由于集群多，每个集群都会有自己的Buffer，这都会导致更大的成本压力。如图：
各个业务模型不同，比如有的业务高峰是在晚22～23点，有的业务则在中午，通过错峰使用，也可以省下部分机器；
在线业务与离线业务完全分离，导致成本也高。对于离线业务，可在低峰继续跑在线业务。
为了更好地应对这些挑战，我们开始设计基于Docker及公有云来构建一套具有弹性伸缩的混合云系统。利用过去的私有云加公有云，以及公司内闲置的运算资源，构建混合云平台DCP，兼具安全性与弹性扩展能力。其特点如下图：
两种云内的设备，我们如何使用呢？我觉得内部私有云设备安全性高，可控度也高，只要对硬件资源进行优化配置，用它来处理固定的工作负载。而公有云的设备则具有标准化、自动化的特性，可以快速因临时需求，在流量暴涨时，让我们快速创建大量ECS，扩容业务工作负载的能力。
而对于公司，可以利用公有云这种按需付费的机制，降低硬件的运营成本。因此采用混合云架构，就可以兼具私有云及公有云的优点，可以同时拥有安全与弹性扩容能力，使业务工作负载可以在业务间进行漂移，低负载的业务就应该使用更少的设备，反之亦然。而基于Docker来做，对于我们的情况来说，复杂度降低很多。
有了这套混合云系统后，不仅能很好的整合内部运算资源，解决内部的弹性需求外，当系统面临流量剧增的峰值事件时，也可以将过多的流量切入外部公有云，减轻内部系统的压力。
微博混合云技术可行性
企业用户出于安全考虑，更愿意将数据存放在私有云中，但是同时又希望可以获得公有云的计算资源，在这种情况下混合云被越来越多的采用。它将公有云和私有云进行混合和匹配，以获得最佳的效果，这种个性化的解决方案，达到既省钱又安全的目的。
从业界来看，已经有越来越多的企业，开始应用混合云的架构。典型的如12306的两地三中心部署架构，主要用于余票查询。除此之外，小米的秒杀业务也有使用公有云的资源进行接入层的峰值应对。而对于我们，是否也能采取类似方案呢？我们主要从以下角度考虑：
托管方式：整个业务托管还是部分业务托管?
安全性的考量：敏感性资料该如何存放和保护呢?如何规避风险?
业务子系统的独立性：如果是部分业务托管，被指定托管业务的子系统是否能独立剥离原先系统的业务流程?
协同合作：在公有云的业务子系统的数据又如何回流与私有云的原来系统在业务上配合，协同合作呢?
数据源的传输和复制/同步：如何复制/同步私有云和公有云的数据?
资源的弹性扩展：迁移到公有云的业务子系统是否能实现按需弹性扩展，利用云计算数据中心的。
经过长达1个月的论证，我们觉得这种弹性的方案是非常靠谱的。于是迅速组织了一批人员，全力投入到混合云的开发，也就诞生了现在的DCP。
微博混合云项目的开发模式
刚开始，我们把混合云项目整体方案设计的较大，就采用了协调跨部门的资源形成虚拟团队的方式进行开发。根据系统分层方向划分成多个项目小组，小组内选出一个负责人，负责整个小组的开发方向制定，方案制定以及开发进度推进；而小组背后的主管，则不直接参与项目，但是会作为项目组的决策人员。团队最多时聚集了10位开发人员。
整个分为三个方向：决策方向、开发方向、业务改造方向。比如开发方向，则形成小组负责人制。
汇报制度：小组内结对编程；项目上，每周至少2天例会。这样就能保证不影响原有团队工作的情况下，共同完成这样一个庞大的项目。
微博混合云平台DCP核心设计思路
微博混合云平台DCP的核心设计思想，主要是借鉴银行的运作机制，在内部设立一个计算资源共享池外，既然内部私有云的需求，又引入了外部公有云，使其在设备资源的弹性能力大大提升。
而要微博实现高弹性调度资源的混合云架构，其中实现的关键则是Docker。刚开始我们思考该使用裸机还是VM架构，发现如果要采用VM，内部机房架构要进行许多改造，这样成本会更高。所以，目前微博的内部私有云使用裸机部署，而外部公有云则采用阿里云弹性计算服务（ECS）的VM架构。等平台建设成熟后，还可以应用其他家的公有云，如AWS，在主机之上均采用Docker来持续部署。
目前我们开发的DCP平台，主要包含4层架构：主机层、调度层及业务编排层，最上层则是各业务方系统。底层的混合云基础架构则架Dispatch设了专线，打通微博内部私有云以及阿里云。
主要思想：三驾马车（Machine + Swarm + Compose）
DCP混合云系统的设计理念，总共包含4个核心概念：弹性伸缩、自动化、业务导向以及专门为微博订制。混合云系统必须有弹性调度的运算能力。而DCP混合云系统并不是对外公开的产品化服务，必须以业务需求出发，因此会有包含许多微博定制的功能。
DCP系统最核心的3层架构：主机层、调度适配层及编排层：
1 主机层
主机层的核心是要调度运算资源。目前设计了资源共享池、Buffer资源池，配额管理，及多租户管理机制，借此实现弹性调度资源。
2 调度层
而调度层则通过API，把调度工具用API进行包装，而微博4种常用的调度工具组合包含：原生Docker、Swarm、Mesos及微博自主开发的Dispatch。
最上层的则是负责业务编排及服务发现。目前，微博的后端服务95%是Java环境，而PC端则是使用PHP编写，移动端则是通过调用API服务。这些业务方都将会接入DCP。编排层也包括了大数据工具Hadoop，进行大数据分析的业务场景。
我们知道，对于调度来说，最重要的就是资源管理，Mesos处理这个是最合适不过了，很多公司就专用其做资源管理，比如Netflix写了一个Titan的调度服务，其底层资源管理则是通过Mesos。当然我们的调度组件中，使用最多的还是Swarm、Dispatch.
我们可以看下面这个场景：这也是私有云内部资源流转的最佳实践：
当业务A多余的运算资源导入混合云共享池时，此时流量暴涨的业务C，可从共享池调度业务A的运算资源；峰值事件后，便可以把多余的运算资源归还至共享池。
3 业务编排层
这层主要根据业务场景模型，通过主机层、调度层的API，创建可编排的任务模型，如集群管理、服务管理、服务池管理、镜像管理、构建管理、负载均衡管理、扩缩容管理等。
从使用角度出发，我们主要划分了集群、服务池、设备Buffer等层次，以IP+Port唯一标识服务。如下图：
其中：在DCP下可以创建多个集群，每个集群为独立平台或产品线，如微博平台、红包飞、手机微博等。集群间相互独立，集群内各自的服务可自由调度，集群外的调度则设置了配额机制。在集群下，可以创建服务池，一般为同一业务的同构服务。主机只有进了集群的Buffer中，才可能被用来部署服务。
DCP对于物理主机的流转，基于资源共享池、Buffer资源池、配额管理，及多租户管理机制，还是非常复杂的，这里我们可以看一下一台物理主机的生命周期（状态流转图）
总结
理解了DCP的核心设计思想和3大层，基本上对微博混合云的方案有了初步的了解，但是从整体角度讲，这只是冰山一角。后续我们将深入分享更多技术细节。敬请期待。 |
