最近花时间收集整理了了一下我们接触过的混合云案例，找出了我们的第一个混合云项目：

这是一个利用云上资源做异地灾备的案例，通过把线下生产环境中的数据定时备份到云上存储空间OSS中，一旦线下生产环境发生严重故障就利用云上的ECS服务器从OSS中恢复数据并继续提供服务，云上和云下环境通过标准的IPSEC VPN建立加密通道，从而保证内网用户可以和内网服务器一样使用云服务器。

在这样一个案例中，包含了计算（ECS）、存储（OSS）、网络（VPN）三大类的云服务资源，继续研究发现大部分的混合云项目中都有计算、存储、网络这三部分资源构成，但假如计算、存储、网络是三个演员的话，我很快发现在这些案例中，演员们的戏份并不平均，大体上是下图这样的状况：

• 网络是主角、为了保证云上云下的数据安全和通信带宽，在混合云项目中网络部分经常要占掉整体项目投入的一大块儿，过高的网络成本经常会成为项目中主要的制约因素。
• 计算是配角、在大都数的混合云项目中计算资源的投入往往都不太高，我想或许是因为云上的计算资源更容易实现弹性扩缩容，可以根据业务需要动态进行计算资源的扩容和缩容，所以固定投入并不高。
• 存储就像群演，虽然我们很早就在探讨利用云端的存储能力来存储线下海量的数据，但在仔细评估时通常都会发现移动大数据的成本非常高昂，过高的传输成本将抵消掉云端存储所能获得的好处，而在小数据方面，CAP定理以及云下云上网络的高时延，限制了在混合云环境下存储相关的应用场景。

CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance），这三个要素最多只能同时实现两点，不可能三者兼顾。

面对这样一个现象或者问题，我的建议是：

• 拉近距离、网络的成本、延时与距离成反比，毕竟纯公共云和纯专有云都不存在网络成本过高的问题。只要拉近云上和云下节点之间的距离就能降低网络的成本和通信延时。这里举一个例子：一家做基因测序的企业将自己的专业设备托管在阿里云机房的隔壁，从而用很低的成本就能获得一个大带宽低延时的云上云下网络连接。边缘计算也是类似的思路，只不过是反来了把云放到了IDC的隔壁。
• 丰富形态、计算资源交付的形态绝不仅仅只是云服务器，弹性容器节点、FC函数计算、SAE应用引擎、甚至是神龙架构下的VMWare虚拟机都是可选的计算资源交付形态，在5G时代，运营商将在传输网中引入边缘节点，从而可以直接运行容器应用，基于容器平台的knative还将进一步降低应用管理计算资源的复杂度。
• 尽可能避免移动数据、存储资源就近配置，在离数据最近的的位置配置计算资源进行计算。
• 尽可能选择合适的数据库、市面上有大量的数据库，不同的数据库适用于不同的应用场景，选对了可以事半功倍。
• 谁是主角不重要，重要的是怎么唱好混合云这台戏。