什么是混合云？

理论上，任何两个异构的云连接在一起都可称作混合云。它可以是私有云与公有云之间，公有云与公有云之间，甚至是私有云与私有云之间。但通常意义上，我们所指的混合云是指私有云与公有云的混合，而且思考角度从应用负载(workload)出发。以下讨论都基于这个通常意义上的“混合”。

 为什么要混合？

对于私有云而言，安全可控是一个很重要的特点。私有云一般会按照企业特有的安全规范去构建，其管理也与企业业务流程密切相连；它可以根据业务需要进行高度定制优化，与业务耦合度高以达到高效运营，同时具有较高稳定性和安全性，但扩展灵活度不够。而公有云，则具有即付即用的灵活性，服务的标准化，迅速的弹性伸缩等特点，以及不需考虑资产维护，只是费用支出，所以资产转变成费用（Capital to Expense），但在共享环境里，公有云的安全和隐私总是人们担心的话题之一。表1简单总结了私有云与公有云的特性。在做应用构架和部署时，如何同时利用不同云（例如，私有云和公有云）的特性进行资源最优实现与配置，就是混合云要解决的问题。

表1私有云与公有云的特性

混合云典型用户场景

IT应用负载(workload)非常复杂，很难按单一标准分类。云计算早期，曾经有人定义了一组云亲密度(Cloud Intimate Degree)参数来衡量应用负载是否适合云。现在有了混合云技术，可以说，几乎所有负载都或多或少能与云计算建立联系。下面从应用负载的两个维度介绍一些混合云典型用户场景。一个维度是应用负载的生命周期及其过程的运维服务管理；另一个维度是构建应用时如何优化其中的服务组成。

 从应用负载生命周期和运维服务来考虑

开发测试生产部署(Dev/prod economy)

对一个应用而言，其开发测试过程一般需要灵活快捷的环境搭建，而且期间经常重构，这时公有云是个不错选择，而一旦正式上线，则希望运行在安全稳定的环境中，那时就会考虑私有云。这种情况下，同一workload，不同阶段相互之间相对独立，没有直接联系，但通过构建混合云，利用DevOps流程与工具，就可同时获得公有云灵活快捷和私有云安全稳定的好处。

 容量短时扩充或调峰(Capacity Adaption)

在这个场景下，应用部署在私有云里，在某一特定时间，应用访问或使用突然增加，而企业无法很快添置硬件扩展私有云容量(往往也不需要)去适应这变化时，就可通过公有云弥补暂时的容量不足，达到调峰目的。比如，在月末或季末，企业财务系统通常都需要计算生成大量各种报表，这时就可以短暂租用公有云弥补计算资源的不足，而不是扩容私有云，否则，会造成大部分时间的资源浪费。

 灾难恢复(Disaster Recovery)

灾难恢复一般是主从架构，都用私有云的话，相对运维成本高。在混合云的架构里，可以考虑把standby部分放在公有云里，用于在主服务宕机时，短时内保证服务连续性，因此资源配置和设计可以考虑简化。通过这样混合，在保证一定服务SLA的情况下，成本得到了优化。

 备份保存(Backup & Archive)

备份保存与灾难恢复类似，但策略不同。备份的目的是希望把某一时间的数据或应用保存在一个安全可靠的地方，所以通常的场景是应用负载运行在公有云上，而备份则放在私有云里，以期达到安全稳定的目的。

 迁移优化(migration for optimization)

这个与开发测试生产场景类似，主要考虑在一个大型的企业系统里，应用如何在私有云和公有云之间依据应用的情况变化进行迁入或迁出。比如，一个企业本身有很大私有云，但当一个新服务上线试运行时，可能会考虑先部署在公有云上，如果反馈不错，用户量增加，它就可把该服务迁入私有云，假如用户不认可，也许就直接在公有云上shutdown了，这样对私有云上的业务就不会产生太大影响。或者另一个场景，企业私有云上有个服务原来很重要，但随着企业业务转型，这个服务需求下降，企业就可以考虑把这个服务迁移到公有云上，使得私有云始终服务于企业核心应用。

从应用的服务组成来考虑

IoT应用(Internet of Things)

IOT应用一般前端有与各种IoT设备交互的部分，后端则会有复杂的数据分析处理系统。对企业而言，可以考虑把前端放在公有云上，这样利用了公有云上丰富的IoT网关和增值服务等，而考虑到数据的安全性和隐私，则可以把后端处理系统部署在企业内部私有云上，从而既保证了应用交互的灵活与敏捷，又得到了数据的安全与隐私。

 服务动态调整(Services with Dynamics)

在这种情形下，企业把应用中经常动态变动的服务部署在公有云上，而把长期稳定的服务放在私有云上，组成一个既能快速响应客户需求变化，又能保证核心服务安全稳定的整体服务系统。与前面提到的服务迁移优化场景类似，只是更侧重应用内部服务本身。

混合云实现主要考虑的因素

混合云实现涉及到异构系统的连接与整合，而且跟具体业务场景相关，技术实现都需要比较高的复杂度。通常需要考虑以下一些因素：

• 不同服务目录的整合(Service Catalog Integration)；

• 不同服务的统一编排与管理(Unified Service Orchestration & Management)；

• 不同云服务之间的安全连接(Brokerage & Secure Connection)

• 统一的DevOps流程与工具(Unified DevOpsProcesses and Tools)；

• 同一的业务支持服务与门户(Single BSS & Portal)。