图十 业务混合云部署形态
上图是2016年春晚上典型的业务混合云部署形态。内部是典型的后端互联网服务技术站，通过四层的负载，通过Nginx实现七层负载，再往后是一些WEB层的计算和RPC服务，最下面是缓存层的资源、数据库。由于数据库的请求量和数据安全要求比较高，因此暂时没有将DB层放到公有云上。架构的最右侧是采用了负载均衡服务、之下的RPC、WEB、Nginx都是部署在 云服务器 上的。
图十一 弹性调度机制
在具体的弹性调度框架上采用了开源的解决方案，例如Swarm、Mesos等。在它们的基础上封装了统一调度的API，将原来专有云内分散的各个应用平台统一到一起，大大节省在基础运维上的时间成本。
图十二容量评估
通过在线容量评估，决策某一个服务是否需要在公有云上扩容。通过选取服务的多个业务上的指标来综合评价某一个业务是否存在流量突增或者性能的瓶颈。比如采集平均响应时间和QPS、内部计算资源线程池，最终计算出总体资源池的冗余百分比，用于决策是否需要动态扩容。
编排与容器发现
业务部署到阿里云之后，需要快速地将业务提供方与调用方快速地衔接起来，就需要编排和容器发现的机制。
图十三 业务容器编排
在实现DCP系统环节内部可能存在微博内部其他的系统，比如原有的运维系统、发布系统、监控系统等等。这些原有的系统内部需要打通，这也是业务编排的核心任务。另外一个问题就是实现自动化，扩容一台完整的微博后端业务大概需要上百步的操作，通过自动化操作避免了数据不一致问题的出现。还有一些服务发现的机制，原来通过管理员配置的服务发现机制对上千规模的弹性业务节点管理起来成本较高。
图十四 自动扩缩容
上面这张图是微博自动扩容的具体流程。首先预测流量到来时，向DCP系统发出指令进行扩容。DCP平台首先向共享池或公有云申请资源，进行资源配额模块后，在经过初始化，进入调度中心。在调度中心中根据服务之间的依赖关系，在公有云上启动该服务，比如需要先启动缓存的服务，才能再启动RPC服务，再启动WEB前端的服务，最后再启动应用的PHP服务。服务启动后需要向Consul集群进行服务注册和服务健康的检查。
图十五 服务发现
对于服务发现，业界通用服务发现机制是基于Nginx Reload本地文件来实现服务发现。这种服务发现实现管理成本高，并且不支持并发注册，会带来性能损耗。目前微博采用基于Consul配置中心实现自动发现服务，解决了Reload的性能问题。
图十六 资源的自动发现
对于资源的动态发现，原有的方式是将后端缓存、Redis等资源的配置放在配置框架中进行，在增加阿里云RDC时会导致配置文件快速膨胀。现在，微博采用将配置同步到Consul集群的方式，通过域名动态解析阿里云上资源IP变更，无需变更业务代码，对整体的弹性伸缩带来了很大的便利。