更多云场景实践研究案例，点击这里：【云场景实践研究合集】联合不是简单的加法，而是无限的生态，谁会是下一个独角兽
每逢重要节日，微博流量会出现暴涨，2016年春晚，微博日活跃用户达到1.34亿，比去年除夕增长31%。在如此大访问量的情况下，后端服务的稳定性和性能保障任务艰巨。面对如此这样的挑战，以最低成本实现弹性能力成为了摆在新浪微博运维面前的重大挑战，DCP系统应运而生，DCP系统对外提供的功能包括集群管理、服务池之间的调度。目前使用DCP系统的业务方涵盖微博的核心业务，主要包括微博平台、红包飞、手机微博等。而DCP系统正是通过借助阿里云的力量，帮助新浪微博实现分钟级服务器规模成倍扩容。
“在使用公有云时，不仅要单单使用公有云，要将公有云和专有云结合使用，最大程度地利用公有云按需付费的特点，降低单位成本，例如在2016年春晚，微博与阿里云合作，在流量峰值到来的前几个小时才部署了相应的公有云资源。同时业务需要在公有云与专有云之间无差异化部署。”
——陈飞
新浪微博研发中心技术经理及高级技术专家
新浪微博在2016年的春晚通过阿里云动态创建了1000多个ECS实例，分流了微博60%核心流量，整体平均一次扩容的时间小于10分钟，以超过1亿/天的数量新增。
采用的阿里云产品
- 阿里云云服务器 ECS
- 阿里云弹性伸缩服务 ESS
- 阿里云负载均衡 SLB
- 阿里云对象存储 OSS
- 阿里云内容分发网络 CDN
- 阿里云专有网络 VPC
- 阿里云云监控
- 阿里云DDoS高防IP (云盾)
- 阿里云云数据库 Memcache
- 阿里云云数据库 Redis版
为什么使用阿里云
阿里云的规模能够满足新浪微博峰值流量的需求。
阿里云具有值得信赖的高可靠性保障。
阿里云的技术人员可以进行支持配合，帮助微博的架构的升级。
关于 新浪微博DCP系统
微博混合云平台DCP的核心设计思想，主要是借鉴银行的运作机制，在内部设立一个计算资源共享池外，既然内部私有云的需求，又引入了外部公有云，使其在设备资源的弹性能力大大提升。而要微博实现高弹性调度资源的混合云架构，其中实现的关键则是Docker。刚开始我们思考该使用裸机还是VM架构，发现如果要采用VM，内部机房架构要进行许多改造，这样成本会更高。所以，目前微博的内部私有云使用裸机部署，而外部公有云则采用阿里云弹性计算服务（ECS）的VM架构。
为什么选择阿里云？
新浪微博DCP混合云弹性运维调度平台设计概览
新浪微博DCP设计“初心”
DCP是微博容器化的混合云弹性调度运维平台，其诞生初衷是以最低成本实现弹性能力。DCP系统对外提供的功能包括集群管理、服务池之间的调度。目前使用DCP系统的业务方涵盖微博的核心业务，主要包括微博平台、红包飞、手机微博等。
DCP最初的设计目标主要有三点：要具有弹性能力，当时预估在春晚峰值时，需要10分钟16000核，25600GB的计算资源弹性能力；能够节约成本，设计之时希望2016年春晚的总体成本不超过2015年，且通过阿里云等公有云按需付费模式，未来可大幅降低单位成本；能提供一个标准的技术平台，拉通不同语言、运行环境差异，向微博各个业务系统提供标准的弹性能力。
新浪微博DCP混合云架构设计
当具体去设计这样一个系统架构时，由于涉及到不同的业务方、不同的部门，各个环节协调还是比较复杂的。因此在架构设计时必须遵循几个具体的原则：
混合云策略，在使用公有云时，不仅要单单使用公有云，要将公有云和专有云结合使用，最大程度利用公有云按需付费的特点，降低单位成本，例如在2016年春晚，微博与阿里云合作，在流量峰值到来的前几个小时才部署了相应的公有云资源。同时业务需要在公有云与专有云之间无差异化部署；
服务化，系统各组件之间通过Restful API而不是原来的运维干预方式进行通信。这里要求各组件应具有良好的扩展性，实现机制可插拔；
可伸缩，各系统组件可以根据管理集群的规模，实现自身的自动伸缩。各组件应无状态、无单点。运维操作自动化。
DCP架构分层
DCP架构具体分为四层。第一层是不可变基础设施，Docker的出现很大程度上改变了原有的运维方式，下文将具体介绍在容器化、系统初始化、镜像分发、带宽监控方面的实践经验。第二层主要完成弹性调度，包括业务跨云调度、调度机制的建立、容量评估。在已有基础设施资源前提下，动态合理的分配给各个业务节点。第三层主要完成服务发现，在业务弹性部署后，调用方需要快速发现服务集群分布的节点，通过配置中心、负载均衡、RPC协同快速实现发现机制。第四层主要完成容器编排，包括自动扩容和监控报警。
DCP整体架构设计
上面这张图是DCP整体架构。架构的最下层是私有云和阿里云的计算资源。各个系统之间通过API相互通信，利用阿里云的Open API动态创建所需的计算节点。再上一层是基础设施管理系统，负责虚机的创建、镜像的分发等服务抽象和实现，对外提供和专有云相同的计算环境。再上一层通过Swarm、Mesos实现了业务容器动态调度框架。最上面一层是业务系统。最左边是一套服务发现框架，该框架是基于Consul集群建立配置中心，实现服务发现机制。
不可变基础设施
微博在15年春晚就开始尝试Docker技术，当时目的是让业务与宿主机的运行环境解耦。Docker解决了业务对运行软件的版本、组件需求，将这些依赖关系封装到Docker Image中，统一了私有云、公有云之间及不同业务线之间的交互标准。
DCP对业务层提供了十分标准的基础运行环境。底层选用ECS的CentOS7.1.1503的镜像，在此之上是Docker的Devicemapper-direct-lvm文件承接系统，版本选择是Docker 1.6.2版本。中间层是调度框架的实现，使用的是Mesos 0.25和Swarm 1.0.0版本，以及一些容器级别的监控，如贡献给开源社区的cAdvisor 0.7.1.fix。PHP和Java对应不同的后端应用，微博的核心Feed、用户关系等基础服务都是用Java实现，偏业务性的系统是用PHP来实现。对应于Java和PHP的Docker体系是一致的，只是其中使用的版本不同，在Docker 1.3.2版本中需要兼容一些离线计算平台。目前Java和PHP底层运行环境已经实现归一化。
有了容器化的无差异运行环境之后，在阿里云上分钟级完成上千个计算节点的弹性扩容还需要进行性能优化。首先各Stage尽可能并行化，目前可实现4分钟内初始化上百台能力。同时通过Ansible的Callback机制，把耗时操作异步化。此外，使用Ansible自动伸缩功能，根据初始化需求规模自动伸缩，可支持分钟内千万级别初始化能力。在Docker环境和ECS计算资源准备充分之后，之后的工作就是将业务镜像进行快速部署。由于单个镜像的大小在GB级别，如果采用动态拉取的方式，需要几百台ECS专门做这个任务，大大增加了扩容成本。
微博将整个镜像进行分层，不变基础镜像放到云服务镜像环境里面，通过本地Load方式实现镜像的加载，大大减少了镜像分发的带宽需求，同时速度也有一定的提升；另外的一种操作就是反向缓存，突然之间在公有云上大规模弹性扩容时会面临冷启动的问题，即公有云上不存在相应的业务镜像，拉去业务变更的镜像会占用大量专线带宽。为了应对这种情况，在公有云上常态化部署对专有云Registry反向缓存，对专有云Registry内部变更和推送、配置都会同步到公有云的反向缓存节点上。此外也实现分发网络可自动伸缩。未来应对超过千万级别规模，微博正在尝试采用P2P进行分发。
DCP的混合云网络架构
在混合云中，最核心的就是整个网络架构。打通公有云和私有云时，网络环境、IP规划等问题都应该慎重考虑。目前微博采用阿里云的VPC服务，构建公有云与专有云一致的网络环境。另外，采用多专线确保网络高可用。路由方面，通过在核心交换上配置路由转发规则，采用就近原则，最大程度减少路由跳数，保证网络低延迟，当网络故障时，自动启动备份路由。
同时基于原有的带宽监控，实现跨云专线监控，细化到IP级别，根据每台ECS的IP自动汇聚到对应的产品线，监控其整体带宽消耗情况，确保各个业务产品线实际单宽占用不会影响。
弹性调度
不可变基础设施的部署完成后，就已经具备了在公有云上创建大规模ECS计算节点的能力。接下来面临的问题就是如何将业务合理调度到计算节点上。跨云业务部署时，应该使得业务以最小规模部署，在公有云上通过预付费方式，常态化部署业务的最小规模，并提供在线服务。另外应该尽量减少跨云专线的调用，保持带宽在可控范围之内，需要将业务后端资源Memory Cache等Loacl化，减少跨专线请求；一旦发生跨专线请求时，需要开启一些流量压缩的协议。同时，微博内部通过WMB缓存数据双向同步机制，基于消息分发策略，在专有云内部对缓存的读写以消息的方式同步到公有云的缓存上，延迟一般在毫秒级，同时在专线出现异常时，消息不会丢失，做到高可用。
新浪微博业务混合云部署形态
上图是2016年春晚上典型的业务混合云部署形态。内部是典型的后端互联网服务技术站，通过四层的负载，通过Nginx实现七层负载，再往后是一些WEB层的计算和RPC服务，最下面是缓存层的资源、数据库。由于数据库的请求量和数据安全要求比较高，因此暂时没有将DB层放到公有云上。架构的最右侧是采用了SLB服务、之下的RPC、WEB、Nginx都是部署在ECS上的。
弹性调度机制
在具体的弹性调度框架上采用了开源的解决方案，例如Swarm、Mesos等。在它们的基础上封装了统一调度的API，将原来专有云内分散的各个应用平台统一到一起，大大节省在基础运维上的时间成本。
通过在线容量评估，决策某一个服务是否需要在公有云上扩容。通过选取服务的多个业务上的指标来综合评价某一个业务是否存在流量突增或者性能的瓶颈。比如采集平均响应时间和QPS、内部计算资源线程池，最终计算出总体资源池的冗余百分比，用于决策是否需要动态扩容。
编排与容器发现
业务部署到阿里云之后，需要快速地将业务提供方与调用方快速地衔接起来，就需要编排和容器发现的机制。在实现DCP系统环节内部可能存在微博内部其他的系统，比如原有的运维系统、发布系统、监控系统等等。这些原有的系统内部需要打通，这也是业务编排的核心任务。另外一个问题就是实现自动化，扩容一台完整的微博后端业务大概需要上百步的操作，通过自动化操作避免了数据不一致问题的出现。还有一些服务发现的机制，原来通过管理员配置的服务发现机制对上千规模的弹性业务节点管理起来成本较高。
上面这张图是微博自动扩容的具体流程。首先预测流量到来时，向DCP系统发出指令进行扩容。DCP平台首先向共享池或公有云申请资源，进行资源配额模块后，在经过初始化，进入调度中心。在调度中心中根据服务之间的依赖关系，在公有云上启动该服务，比如需要先启动缓存的服务，才能再启动RPC服务，再启动WEB前端的服务，最后再启动应用的PHP服务。服务启动后需要向Consul集群进行服务注册和服务健康的检查。
对于服务发现，业界通用服务发现机制是基于Nginx Reload本地文件来实现服务发现。这种服务发现实现管理成本高，并且不支持并发注册，会带来性能损耗。目前微博采用基于Consul配置中心实现自动发现服务，解决了Reload的性能问题。
对于资源的动态发现，原有的方式是将后端缓存、Redis等资源的配置放在配置框架中进行，在增加阿里云RDC时会导致配置文件快速膨胀。现在，微博采用将配置同步到Consul集群的方式，通过域名动态解析阿里云上资源IP变更，无需变更业务代码，对整体的弹性伸缩带来了很大的便利。
关于微博DCP平台的更多实践详情：新浪微博：春节日活跃用户超一亿，探秘如何实现服务器分钟级扩容
原文发布日期：2016-04-05
云栖社区场景研究小组成员：贾子甲，仲浩。
