混合云的那些事，如何做到让公有云和私有云实现1+1>2

云计算在2016年有了极大的增长。一方面，AWS、阿里云等大型公有云厂商的云计算收入呈爆发式增长且绝对值数据可观；另一方面，通过持续市场培育，云计算的价值逐步被各国政府所认可。很多大型企业也纷纷发力云计算，传统IDC采购出现增长拐点。各种声音不断提醒人们，云计算不再是雷声大雨点小的噱头，而是成为大中小企业不可或缺的基础设施。2017年，云计算真正落地的话题逐渐成为业界讨论的热门话题。

当前，私有云和公有云相争的热潮渐弱，融合两者优势的混合云开始逐渐释放巨大的市场潜力。混合云的背后不再是厂商，而是一种混合IT架构，是公有云与私有云的集成。因此，如何构建基于云计算的混合IT架构，成为CIO和CTO避不过的问题。

本文我们首先回顾公有云与私有云的优缺点，之后聊聊到底什么是混合云、使用场景与产品有哪些，紧接着重点分享架构核心思路与技术实现原则，最后来说说用户到底能在混合云平台上做些什么事。

公有云与私有云优缺点

笔者曾经在公有云厂商和私有云厂商都有过研发经历，对公有云和私有云各自能带来的优势和局限都有比较深入的体会。对于市场来说，公有云和私有云都有它们无法被取代的优势，最好的选择就是根据自身业务结合二者，这一点也已经得到了市场的普遍认同。

混合云的定义与使用场景

混合云的定义

对于混合云的定义，中国信息通信研究院曾经提出过观点，是必须要同时有公有云和私有云，这也是大多数厂商和用户的认知。笔者认为，这样的定义只是物理上的堆彻，两者之间如果不能发生化学反应，并不是真正的混合云，也无法催生出创新型应用，无法真正帮助用户提高业务价值。混合云不是简单的对公有云和私有云进行1+1=2的运算，而一定要让它们产生大于2的价值。

虚拟化与云计算的区别

为了更好的理解这点，让我们来回顾一下虚拟化与云计算的区别。虚拟化是一种技术，而云计算则是基于虚拟化技术之上的升华，它让用户能够管理一个数据中心及其增值服务，将IT资源以服务的形式交付给用户，从而让用户能够专注于业务而不是IT资源。虚拟化帮助用户提高硬件的资源利用率，而云计算则帮助用户提高整个数据中心的整体资源利用率，这中间也包括软件、网络、存储甚至于人力的资源利用率。

那么，混合云作为云计算的一种形态，它要给用户带来的价值，并不是简单的把公有云和私有云堆彻在一起，而是让两者产生碰撞，从而提高用户跨云的资源利用率，催生出新的业务。

混合云应该是帮助用户接管跨云、跨地域的IT基础设施，把用户花在底层实现上的精力解放出来，甚至可以反复尝试业务在公有云与私有云之间的组合模式而不用关心底层实现细节，从而极大提高用户的生产力和降低业务的试错成本。

故我们可以看到，混合云不是简单的一张皮，也不是完成连通的其中一个细节，它是包含了公有云各资源和产品以及私有云各资源和产品的一个有机整体系统。因此，同时存在公有云与私有云只是混合云的必要条件，而非充要条件。那么还需要有什么呢？

混合云在数据中心的价值

我们先来看看用户想要什么。在同时存在私有云和公有云的情况下，用户自然会想到如下场景：

• 将私密数据放在本地，公开访问入口放在公有云。
• 高峰期能利用公有云的资源进行无限拓展。
• 本地业务能加密备份在公有云。
• 多数据中心通过公有云实现星形连通。
• 开发测试在本地快速迭代，生产业务放在公有云。
• 内部业务放在本地数据中心，对外开放业务放在公有云，完全摒弃掉公有云控制台，在本地闭环完成所有操作。

事实上由于现在真正实施混合云的用户非常之少，还有大量未知的创新等待着聪明的用户去发掘。

那么如何来实现这些场景呢？在单一的私有云或者公有云场景下，用户不需要关心底层是如何实现的，他们使用镜像创建虚拟机，使用快照备份磁盘，搭建多个二层或三层网络并在平台上自定义路由和安全组来进行通信，使用Autoscaling或其他编排系统来进行资源自动编排，并在一个多租户场景下工作。

那么在混合云的场景下，我们则抽象出如下实现手段：

• 创建和管理(包括运维)虚拟机而不关心镜像在哪里或虚拟机在哪里。
• 创建或备份磁盘而不关心磁盘在哪里或备份在哪里。
• 搭建网络并定义它的通信目标，无论是在本地数据中心或者公有云。
• 自由编排资源，无论是在本地数据中心或者公有云。
• 统一而不是割裂的帐户管理体系。

混合云产品主要基于灾备、网络互联和多云管理

市场对混合云的声音日益庞大，但目前混合云并没有真正的标准，也没有准确的定义。目前的混合云产品主要基于以下三类：

基于灾备产品

厂商通过用户自定义的策略将用户的数据备份到公有云，并可以恢复到本地。这主要是一些存储厂商提供的产品，如英方云、数腾云、XSKY等。

基于网络互连产品

厂商主要做网络服务，帮助用户快速完成本地数据中心与公有云的对接服务，达到互联互通的目的。这主要是一些网络厂商提供的产品，如网银互联、游驰、犀思云等。

多云管理产品

厂商主要做多云管理产品，致力于帮助用户在一套管理平台上对多个公有云或私有云产品进行管理层面服务，增强用户的一致性体验，帮助用户更好管理自己的云计算资源，并提供部分运维及PaaS服务。这主要是一些CMP厂商提供的产品，如Fit2Cloud、RightCloud、行云管家等。

我们可以看到，以上几类产品分别能够帮助用户实现基于私有云和公有云的一种或多种场景。

混合云架构核心思路：连接一切IT，无缝混合体验

了解混合云的定义、使用场景和产品之后，我们来看看具体实现过程。作为云计算厂商或开发者，应该对功能矩阵非常熟悉。云计算厂商之间的比拼一个重要的层面就是功能矩阵的较量。

正是IaaS层提供了成百上千的功能点，才让用户得以轻松地进行各项业务开发。

在今天私有云和公有云都各自有了相似的巨大功能矩阵，我们仔细思考可以得出结论，大量的功能都是不需要跨云的，例如GPU直通，只需要分别在私有云端和公有云端实现，作为混合云服务商，只要把这个功能展现出来即可。但仍然有许多跨资源的关键业务，是需要混合云厂商提供帮助的。

例如公有云上的路由，这条路由可以指向公有云VPC，也应该可以指向本地数据中心的VPC。类似这样的业务，是混合云功能的重点。

ZStack作为开源的国产自研IaaS软件，进行混合云的研发己经有一段时间。根据经验来看，最重要的核心思路就是保证混合云产品拥有连接一切的能力和无缝结合的能力。

连接一切IT

连接一切IT的本质是实现数据层面的打通，这是实现混合云一切场景的前提条件。数据层面打通在今天主要是三个打通：帐户打通、网络打通、存储打通。

帐户打通：使用一套帐户管理公有云和私有云，即以私有云自身的帐户体系和多租户权限管理为主体，公有云的AK权限只是辅助。将公有云AK绑定到私有云的相应帐户上，巧妙结合私有云和公有云各自的权限体系，可以实现无比灵活的多租户场景，建立起满足企业要求的帐号管理体系。

网络打通：网络打通即指能够将本地私有云的网络和公有云的网络在二层或者三层上连通起来，实现各种自定义的网络结构，如跨数据中心连通用户的两个子业务部门等。由于网络配置非常复杂，中间涉及到多种设备，因此网络能力往往是云计算厂商综合能力的体现。

存储打通：私有云和公有云之间通常很难直接将存储系统连接或扩展。所以我们指的存储打通，是在快照和镜像层面的打通。即虚拟机或容器的快照和镜像，能够在私有云和公有云之间自由迁移，这种应该是代价极小的，如完全的增量迁移，或实时迁移等。从而可以使本地制作镜像模板直接在公有云上创建云主机，或反之。

在实现以上三个打通后，用户就可以基于混合云实现很多自定义网络，比如连接多个本地数据中心和多个公有云VPC，自由组合成星形、环形、网形等业务所需要的网络，并让镜像快照在各地之间共享。这一切的配置都可以在分钟级完成，大大加速了业务创新，彻底取缔了信息孤岛，实现全国一张网，一个系统。

无缝混合体验

无缝结合更多是从控制面的设计来讲，达到用户所有的云资源，不论是在公有云还是私有云，能得到一视同仁的处理。事实上由于公有云和私有云平台天生模型的不一致(Azure stack这样的平台例外)，很难强行把它们用相同的界面和逻辑来进行操作，而类似region，availability zone这样的概念，更是无法对用户屏蔽但私有云很难存在的概念。

所以在实现上，好的无缝体验，应该是让公有云和私有云的资源在同一个平台上操作，它们的操作内在逻辑是完全一致，而非相互割裂。此处以创建云主机和创建专线连接为例。

创建云主机

当我们创建私有云主机时，需要选择网络、主存储、镜像、资源规格、可能还有物理机、集群等。而创建公有云主机时，需要选择镜像、安全组、网络、计算规格、可能还有可用区等。相比之下，公有云不可能看到物理机，而私有云不可能看到可用区，两者的计算规格和网络的模型也可能完全不同。

我们可以将它们放在同一个页面，但一个页面还是两个页面，对用户的操作路径来说都是一步，所以意义不大。真正有意义的是让用户在操作过程中感受到完全的无缝。即创建的过程是完全相同的，所有资源都不需要到公有云控制台去进行额外的查找，本地就能闭环地完成所有操作。

创建专线连接

这是典型的跨云资源操作。连接时需要选择本地网络与公有云网络，这些选择都应该是在平台上直接进行选择或创建（例如创建一个边界路由器等），然后点击连接，混合云平台自动完成剩下的连接工作。不需要用户登录到各个云平台查看类似id、网关、cidr等属性。从体验上来说，用户的直观感受就是选择了两个网络，就创建了连接。而这背后，则是混合云平台进行了大量的建模和数据同步工作。

通过以上两个示例可以看到，因为公有云和私有云之间的模型天生是有部分差异，因此无感知的混合云并不是要强制用户使用相同的模型去套用不同的云平台，而是在建立好对应的模型后，在后台使用完全相同的逻辑去处理它们。而从API设计上来讲，私有云和公有云资源的操作分属不同的API，但它们的语义、参数都是非常相近的。

混合云架构的具体技术实现原则

在定义了连接一切、无缝体验之后，技术层面在实现它们时有哪些需要注意呢？在此提供以下一些设计原则以供大家参考：

建立完整数据模型

我们在设计私有云平台时，会建立完整的私有云数据模型，如快照、磁盘、云主机、VPC、路由器等，它们之间存在千丝万缕的关系。同样，在设计公有云平台时，也要建立相应的数据模型。那么在设计混合云时，就必须同时建立这二者的模型，并且必须是完整的，因为存在许多关联关系，导致缺少任意一个资源的模型，都不能算完整。

布设虚拟ID

公有云资源映射到本地，成为一个虚拟资源。我们需要给每一个公有云资源分配一个本地的虚拟ID，而不能直接使用公有云的ID。因为在多租户的场景下，公有云的ID在本地并非是唯一的，只有本地的ID才能保证它的唯一性。

触发同步

由于存在映射关系，所以需要进行同步，同步可以是主动触发，也可以是被动触发的。同步的目的：一是让用户在公有云控制台上做的操作也能及时反映到本地，二是保证所有的读写操作都在本地进行，让操作的流畅程度达到毫秒级。正是有了同步，混合云资源的操作速度，可以比直接在公有云控制台上操作快了两个数量级，这让用户可以放心地做更多的事。

遍历资源模型

云计算的资源模型是树状的结构，因此任何操作都需要遍历这棵树，以便让它的所有父子资源和相关资源都能得到及时的变更。例如删除或同步一个VPC，需要遍历它下面所有的交换机、安全组、云主机、EIP、NAT网关、路由表、安全规则等等，进行相应的变更，出现失败时要能按顺序进行回滚，保证操作的原子性。又比如删除一个本地网络，需要遍历所有指向它的资源，如路由设备，监控指标等等，进行路由的变更，和网络拓扑关系的自动适配，而不是简单删除就可以,下图为VPN连接的混合云数据模型。

混合云VPN连接的数据模型

区分逻辑和真实操作

对公有云资源的操作都必须区分逻辑操作和真实操作，方便管理员的管理。比如有的用户只能逻辑上删除一个公有云网络，而不允许真实删除公有云网络。又比如对可用区这种概念，用户只能逻辑性地清除它以及它的子资源，而不能真实删除一个可用区，因为这是公有云的固有属性。

升级原则

对于混合云产品来说，私有云的部分是可以随产品升级而升级的，但公有云部分的升级，则可能影响到产品的稳定性。因此要注意两个原则：

一是对公有云的操作失败范围要尽量控制在可以控制的范围内，比如错误或数据结构控制在有限的package内，避免公有云API的调用失败影响到产品整体流程。

二是对公有云上有可能变更的行为和资源保持弹性和可降级处理，比如公有云上的可用区是有可能新增和关闭的，而每个可用区内能看到的资源类型也是不对称并且会发生变化的（例如库存变化），因此需要有机制能动态地识别这种变化并进行相应处理。对于第二点来说，还需要开发人员对每个公有云本身的实现机制有深入的理解。

以上几个设计原则虽然并不轻松，但一旦建立完成，一方面可以在UI上做出许许多多令人赞叹的智能化设计。另一方面，公有云资源的操作可以达到毫秒级响应，在全异步的框架下，一个管理节点可以帮助用户管理成千上万个云资源，从而用户可以摒弃掉公有云控制台。

用户可以在混合云平台上做什么

对于用户来说，混合云帮助他屏蔽了许多实现细节，那么用户只需要按照场景去使用即可。在这里我们列举用户可以在混合云平台上做的事情。

灾备场景

用户指定本地数据中心的磁盘、镜像或云主机，可通过备份策略、备份组或直接手动的方式，备份到远端公有云。混合云平台帮助解决连通以及去重的问题。

互连场景

用户指定本地数据中心通过VPN或专线的方式连接公有云VPC，或直接连接几个公有云VPC，或把自己几个数据中心与公有云组成星形网络，互相通过内网访问。在此基础之上，用户可以让自己的业务跨云部署，或跨云使用负载均衡。至于连通的细节由混合云平台处理，用户只需要指定连通目标即可。

弹性场景

用户将本地数据中心的云主机弹到公有云，或者反过来从公有云弹到本地数据中心，从而解决业务迁移和弹性扩展问题。这个场景可以极大节省用户的资源成本，从而通过混合云平台解决数据迁移的问题。

多云管理

用户不需要再登录公有云控制台，在本地完成所有操作。本地平台还可以帮助用户解决跨帐户、跨地域管理的问题，从而可以将用户的资源管理速度提高几个数量级。

总结

本文从系统概念层面阐述了我们在研究和实践中对混合云的认知，即混合云应该是让私有云和公有云之间能进行帐号打通、网络打通、存储打通，并以流畅的用户体验极大降低用户在不同云之间的分裂体验，从而使用户能够专心于业务架构，而不用关心基础资源如何打通的问题。

针对这一全新的混合云认知，本文提出了混合云的设计目标以及围绕该目标应有的实现手段、设计原则。