图五 容器化
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环境和云服务器计算资源准备充分之后，之后的工作就是将业务镜像进行快速部署。由于单个镜像的大小在GB级别，如果采用动态拉取的方式，需要几百台云服务器专门做这个任务，大大增加了扩容成本。
微博将整个镜像进行分层，不变基础镜像放到云服务镜像环境里面，通过本地Load方式实现镜像的加载，大大减少了镜像分发的带宽需求，同时速度也有一定的提升;另外的一种操作就是反向缓存，突然之间在公有云上大规模弹性扩容时会面临冷启动的问题，即公有云上不存在相应的业务镜像，拉去业务变更的镜像会占用大量专线带宽。为了应对这种情况，在公有云上常态化部署对专有云Registry反向缓存，对专有云Registry内部变更和推送、配置都会同步到公有云的反向缓存节点上。此外也实现分发网络可自动伸缩。未来应对超过千万级别规模，微博正在尝试采用P2P进行分发。
图八 混合云网络架构
在混合云中，最核心的就是整个网络架构。打通公有云和私有云时，网络环境、IP规划等问题都应该慎重考虑。目前微博采用阿里云的专有网络服务，构建公有云与专有云一致的网络环境。另外，采用多专线确保网络高可用。路由方面，通过在核心交换上配置路由转发规则，采用就近原则，最大程度减少路由跳数，保证网络低延迟，当网络故障时，自动启动备份路由。
同时基于原有的带宽监控，实现跨云专线监控，细化到IP级别，根据每台云服务器的IP自动汇聚到对应的产品线，监控其整体带宽消耗情况，确保各个业务产品线实际单宽占用不会影响。
弹性调度
不可变基础设施的部署完成后，就已经具备了在公有云上创建大规模 云服务器 计算节点的能力。接下来面临的问题就是如何将业务合理调度到计算节点上。
图九 业务跨云弹性调度
跨云业务部署时，应该使得业务以最小规模部署，在公有云上通过预付费方式，常态化部署业务的最小规模，并提供在线服务。另外应该尽量减少跨云专线的调用，保持带宽在可控范围之内，需要将业务后端资源Memory Cache等Loacl化，减少跨专线请求;一旦发生跨专线请求时，需要开启一些流量压缩的协议。同时，微博内部通过WMB缓存数据双向同步机制，基于消息分发策略，在专有云内部对缓存的读写以消息的方式同步到公有云的缓存上，延迟一般在毫秒级，同时在专线出现异常时，消息不会丢失，做到高可用。
