本次由微博研发中心技术经理及高级技术专家陈飞分享了微博利用阿里云实现分钟级服务器规模成倍扩容的技术体系，包括Docker与虚机结合的使用经验、网络架构以及负载均衡、缓存架构的跨IDC服务部署的一些经验。本次视频直播的整理文章、视频、幻灯片整理完毕，如下内容。
直播视频：http://click.aliyun.com/m/6360/
幻灯片下载地址： http://click.aliyun.com/m/6360/
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自动汇聚到对应的产品线，监控其整体带宽消耗情况，确保各个业务产品线实际单宽占用不会影响。
更多内容及QA环节，请前往>> http://click.aliyun.com/m/6360/
关于分享者
陈飞，微博研发中心技术经理及高级技术专家。目前在微博负责Feed用户关系和容器化相关工作，致力于Docker技术在生产环境中的规模化应用。
微博在2016年的春晚动态创建了1000多个ECS实例，分流了微博60%核心流量，整体平均一次扩容的时间小于10分钟，以超过1亿/天的数量新增。
来源：oschina
链接：https://my.oschina.net/u/1464083/blog/751534