这是一个创建于 3384 天前的主题，其中的信息可能已经有所发展或是发生改变。
本账号会定期推送云计算相关的场景研读系列文章，内容来自访谈或者视频直播，欢迎关注。
以下正文：
每逢重要节日，微博流量会出现暴涨， 2016 年春晚，微博日活跃用户达到 1.34 亿，比去年除夕增长 31%。在如此大访问量的情况下，后端服务的稳定性和性能保障任务艰巨。本次重点分享微博利用阿里云实现分钟级服务器规模成倍扩容的技术体系，包括 Docker 与虚机结合的使用经验、网络架构以及负载均衡等。
序
本次由微博研发中心技术经理及高级技术专家陈飞分享了微博利用阿里云实现分钟级服务器规模成倍扩容的技术体系，包括 Docker 与虚机结合的使用经验、网络架构以及负载均衡、缓存架构的跨 IDC 服务部署的一些经验。本次视频直播的整理文章、视频、幻灯片整理完毕，如下内容：
DCP 设计“初心”
DCP 是微博容器化的混合云弹性调度运维平台，其诞生初衷是以最低成本实现弹性能力。 DCP 系统对外提供的功能包括集群管理、服务池之间的调度。目前使用 DCP 系统的业务方涵盖微博的核心业务，主要包括微博平台、红包飞、手机微博等。
DCP 最初的设计目标主要有三点：
1. 要具有弹性能力，当时预估在春晚峰值时，需要 10 分钟 16000 核， 25600GB 的计算资源弹性能力；
2. 能够节约成本，设计之时希望 2016 年春晚的总体成本不超过 2015 年，且通过阿里云等公有云按需付费模式，未来可大幅降低单位成本；
3. 能提供一个标准的技术平台，拉通不同语言、运行环境差异，向微博各个业务系统提供标准的弹性能力。
DCP 混合云架构设计
当具体去设计这样一个系统架构时，由于涉及到不同的业务方、不同的部门，各个环节协调还是比较复杂的。因此在架构设计时必须遵循几个具体的原则。
1. 在使用公有云时，不仅要单单使用公有云，要将公有云和专有云结合使用，最大程度利用公有云按需付费的特点，降低单位成本，例如在 2016 年春晚，微博与阿里云合作，在流量峰值到来的前几个小时才部署了相应的公有云资源。同时业务需要在公有云与专有云之间无差异化部署；
2. 服务化，系统各组件之间通过 Restful API 而不是原来的运维干预方式进行通信。这里要求各组件应具有良好的扩展性，实现机制可插拔；
3. 可伸缩，各系统组件可以根据管理集群的规模，实现自身的自动伸缩。各组件应无状态、无单点。运维操作自动化。
DCP 架构分层
DCP 架构具体分为四层。第一层是不可变基础设施， Docker 的出现很大程度上改变了原有的运维方式，下文将具体介绍在容器化、系统初始化、镜像分发、带宽监控方面的实践经验。第二层主要完成弹性调度，包括业务跨云调度、调度机制的建立、容量评估。在已有基础设施资源前提下，动态合理的分配给各个业务节点。第三层主要完成服务发现，在业务弹性部署后，调用方需要快速发现服务集群分布的节点，通过配置中心、负载均衡、 RPC 协同快速实现发现机制。第四层主要完成容器编排，包括自动扩容和监控报警。
上面这张图是 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 进行分发。
能看到这的都是英雄，限于篇幅过长，图片太多，铜币有限，
其余内容及 PPT下载，可前往 >> http://click.aliyun.com/m/6360/
以下广告，不喜忽略（小编不容易，点点就可以）
阿里云7周年庆，买1年送 6 个月： http://click.aliyun.com/m/6361/
（活动截止9.30）
以下正文：
每逢重要节日，微博流量会出现暴涨， 2016 年春晚，微博日活跃用户达到 1.34 亿，比去年除夕增长 31%。在如此大访问量的情况下，后端服务的稳定性和性能保障任务艰巨。本次重点分享微博利用阿里云实现分钟级服务器规模成倍扩容的技术体系，包括 Docker 与虚机结合的使用经验、网络架构以及负载均衡等。
序
本次由微博研发中心技术经理及高级技术专家陈飞分享了微博利用阿里云实现分钟级服务器规模成倍扩容的技术体系，包括 Docker 与虚机结合的使用经验、网络架构以及负载均衡、缓存架构的跨 IDC 服务部署的一些经验。本次视频直播的整理文章、视频、幻灯片整理完毕，如下内容：
DCP 设计“初心”
DCP 是微博容器化的混合云弹性调度运维平台，其诞生初衷是以最低成本实现弹性能力。 DCP 系统对外提供的功能包括集群管理、服务池之间的调度。目前使用 DCP 系统的业务方涵盖微博的核心业务，主要包括微博平台、红包飞、手机微博等。
DCP 最初的设计目标主要有三点：
1. 要具有弹性能力，当时预估在春晚峰值时，需要 10 分钟 16000 核， 25600GB 的计算资源弹性能力；
2. 能够节约成本，设计之时希望 2016 年春晚的总体成本不超过 2015 年，且通过阿里云等公有云按需付费模式，未来可大幅降低单位成本；
3. 能提供一个标准的技术平台，拉通不同语言、运行环境差异，向微博各个业务系统提供标准的弹性能力。
DCP 混合云架构设计
当具体去设计这样一个系统架构时，由于涉及到不同的业务方、不同的部门，各个环节协调还是比较复杂的。因此在架构设计时必须遵循几个具体的原则。
1. 在使用公有云时，不仅要单单使用公有云，要将公有云和专有云结合使用，最大程度利用公有云按需付费的特点，降低单位成本，例如在 2016 年春晚，微博与阿里云合作，在流量峰值到来的前几个小时才部署了相应的公有云资源。同时业务需要在公有云与专有云之间无差异化部署；
2. 服务化，系统各组件之间通过 Restful API 而不是原来的运维干预方式进行通信。这里要求各组件应具有良好的扩展性，实现机制可插拔；
3. 可伸缩，各系统组件可以根据管理集群的规模，实现自身的自动伸缩。各组件应无状态、无单点。运维操作自动化。
DCP 架构分层
DCP 架构具体分为四层。第一层是不可变基础设施， Docker 的出现很大程度上改变了原有的运维方式，下文将具体介绍在容器化、系统初始化、镜像分发、带宽监控方面的实践经验。第二层主要完成弹性调度，包括业务跨云调度、调度机制的建立、容量评估。在已有基础设施资源前提下，动态合理的分配给各个业务节点。第三层主要完成服务发现，在业务弹性部署后，调用方需要快速发现服务集群分布的节点，通过配置中心、负载均衡、 RPC 协同快速实现发现机制。第四层主要完成容器编排，包括自动扩容和监控报警。
上面这张图是 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 进行分发。
能看到这的都是英雄，限于篇幅过长，图片太多，铜币有限，
其余内容及 PPT下载，可前往 >> http://click.aliyun.com/m/6360/
以下广告，不喜忽略（小编不容易，点点就可以）
阿里云7周年庆，买1年送 6 个月： http://click.aliyun.com/m/6361/
（活动截止9.30）
目前尚无回复
Select Language