直播视频：
3月30日云栖社区在线实时分享顺利结束，本次由微博研发中心技术经理及高级技术专家陈飞分享了微博利用阿里云实现分钟级服务器规模成倍扩容的技术体系，包括Docker与虚机结合的使用经验、网络架构以及负载均衡、缓存架构的跨IDC服务部署的一些经验。本次视频直播的整理文章、视频、幻灯片整理完毕，如下内容。
DCP设计“初心”
图一 DCP设计初心
DCP是微博容器化的混合云弹性调度运维平台，其诞生初衷是以最低成本实现弹性能力。DCP系统对外提供的功能包括集群管理、服务池之间的调度。目前使用DCP系统的业务方涵盖微博的核心业务，主要包括微博平台、红包飞、手机微博等。
DCP最初的设计目标主要有三点：
- 要具有弹性能力，当时预估在春晚峰值时，需要10分钟16000核，25600GB的计算资源弹性能力；
- 能够节约成本，设计之时希望2016年春晚的总体成本不超过2015年，且通过阿里云等公有云按需付费模式，未来可大幅降低单位成本；
- 能提供一个标准的技术平台，拉通不同语言、运行环境差异，向微博各个业务系统提供标准的弹性能力。
DCP混合云架构设计
图二 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进行分发。
图八 混合云网络架构
在混合云中，最核心的就是整个网络架构。打通公有云和私有云时，网络环境、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变更，无需变更业务代码，对整体的弹性伸缩带来了很大的便利。
QA环节：
1、在使用阿里云产品过程中有什么经验可以分享？
答：分享一个在ECS选型时的经验，原来是使用ECS的时候，没有考虑ECS本身的特点和内部优化的细节，当时使用的比较粗放，造成业务上线之后，缓存访问的性能并没有达到预期。后来根据业务场景的特点，A区存放的更多是Web服务，计算节点存放在C区，使用IO优化来提升其性能。
2、当时微博为什么选择阿里云，考虑的出发点是？
答：一是首先阿里云的规模能够满足需求；二是阿里云的高可靠性保障；三是阿里云的技术支持配合，帮助微博的架构的升级。
3、在单个云服务器上部署单个Docker实例还是多个Docker实例？
答:在专有云的场景下，一台主机部署了多个Docker实例，使用公有云后也尝试了使用大型的ECS部署多个Docker实例，通过性能测试和陈本对比后，最终选择根据业务计算资源所需要的CPU和内存的大小量身定做ECS，也就是单个ECS里面部署一个Docker实例。
4、在设计DCP时，是否有参考同行业的模型？
答：主要参考了国外的FaceBook、Twitter运维弹性基础设施方式，也调研了Docker Machine、Docker Swarm整套的实现方案。
关于分享者
陈飞，微博研发中心技术经理及高级技术专家。目前在微博负责Feed用户关系和容器化相关工作，致力于Docker技术在生产环境中的规模化应用。
微博在2016年的春晚动态创建了1000多个ECS实例，分流了微博60%核心流量，整体平均一次扩容的时间小于10分钟，以超过1亿/天的数量新增。
