混合云架构之争

混合云的概念和设计考虑

云计算最开始分为公有云、私有云、边缘云和混合云，概念非常之清晰；最近随着商业竞争运作的加剧，一些厂家开始在概念上进行创新，提出了诸如专有云、分布式云等概念，闻之令人纷繁复杂，不可获取其义，对业界的发展也确实有些迷雾的牵引。

各种云的概念每家定义和理解都不一致，很难给出确切的概念定义，这里仅给出业务的边界：

• 公有云：是云平台厂商以服务的形式将基础设施资源（IAAS）、软件中间件/组件（PAAS）和软件产品分别对租户进行租售的业务；云平台的建设、维护和软硬件投资都是云平台厂商的；公有云面向的租户对象是开发者，有一定的技能积累，非常理解平台的各种理念和玩法，并且对云平台厂商（CSP: CloudService Provider）负责的内容边界以及租户业务自身的边界有着清晰的认知和实操；

• 私有云：是将客户需要能力范围内的云平台，直接建在客户的本地数据中心，云平台的软硬件资产都是客户的，并且云平台的建设除了解决方案外，相关建设规划、维护等，责任都归属到客户；但客户并不一定是最终的该云平台的最终用户，因为该平台可能以B2B方式继续对其客户提供相关云的能力；但是对于平台提供商来讲是出售的云平台；私有云面临更多客户传统业务上云过程的业务连续性、软硬件采购云平台集成、有对云平台要负责客户解决方案和能力赋能的要求；私有云的云平台很大程度延续了原来集成商的角色，更是解决方案角色的完美演绎；

• 边缘云：边缘云是相对核心云来说的，核心云可能是私有云，也可能是在公有云上部署；核心业务部署在核心云上，比如5G基站、客户小的分支机构、交通的视频采集站点等等；而且边缘云站点因为到核心云的网络质量无法保障，所以需要一定的边缘自治能力，即与核心管控面中断一定时间内能提供包括业务面不影响、运维能力、运营/运维数据缓存、部分api/能力可执行等，否则海量的边缘云站点部署交付将是一场灾难；并且软件版本上，和中心云是解耦的，否则千万局点，只要一个边缘云有升级诉求，其他所有边缘云甚至跨租户的边缘云都要升级配套，那么该产品也基本到了生命周期的尽头；

• 混合云：客户以自身业务需要（成本考虑、容量弹性、容灾能力等）将其同时在本地私有云和公有云部署的形态，并且对业务所用的资源等能统一管理；注意，第一：这里的混合云不以是否有边缘云为要求，因为边缘云属于和其核心云对应，而不是混合云的属性要求；第二：混合云的私有云或公有云都不一定是一个资源池，尤其是公有云一侧甚至可能是多家云平台的公有云都可以部署（MCP：Multi-Cloud Platform）；

• 专有云：是公有云平台厂商为了最小代价进入私有云的市场，将其公有云平台进行适量裁剪后的版本部署到客户本地数据中心，但软硬件资产、维护责任等属于云平台厂商，需要按照租用的方式给客户提供相应基础设施和云平台特性能力；这种方式优势是能最大限度复用云平台厂商的云服务、特性能力，劣势是对客户本地的安全合规性有一定折扣、采购流程和预算制度有一定冲击、云使用技能按照开发者来要求等，而且客户的数据中心部署的这套专有云必须和云平台厂商进行网络连接和运维数据的上报同步，需要客户对云平台厂商不仅有技术/安全隐私要求，还要有充分的信任和责任边界划分；

• 分布式云：在专有云的基础上，将公有云、专有云和以公有云或专有元为核心的边缘云等进行统一管理，并在部分能力上满足政企合规等概念上提出的类似混合云的概念，提倡这些云平台能软件架构统一、云服务方式提供基础设施或特性能力、相互间有一定的网络质量保障等；

所以基于上述几种云形态，原来说的混合云概念所覆盖的内容已经有些狭隘；我们这里讨论的混合云是较为宽泛的概念，是指有客户业务有在公有云上部署，并且同时有在私有云或专有云上部署的形态；并且讨论如下几个点：

1）客户考虑混合云部署的业务范围：并不是所有的业务都可以部署在混合云的形态上，尤其是无法部署在公有云上的业务；所以这类业务通常具有互联网业务特征，能够在没有违反安全合规的情况下实现混合云部署形态，实现相关业务数据和资源的相互流动；

2）客户部署到混合云的考虑点：客户将业务部署到混合云上需要考虑一些点，除了前面说的安全合规外，还要求客户的相关人员具备开发中的技能并熟悉相关云平台的快发/运维工具，熟悉DevOps流程甚至对业务进行云原生的改造，实现业务相关开发/部署流程/环境的线上线下一致，并且业务所用的基础设施资源通过一朵云管理，提供相关平台运维/业务运维/组织流程等方面的能力；

3）云平台厂商的考虑：从构建混合云的角度来讲，客户和云平台可能不太一样，公有云平台是想客户将公有云的能力也延伸到客户本地数据中心来减少云平台厂商云平台软硬集成/开发/维护的复杂度，而客户则是先有本地云品台的部署，来选择部分合适的业务扩展到公有云里部署形成混合云；通常云平台是希望通过最近的region扩展az到客户的本地数据中心，而客户的自然想法是本地先有部署的业务资源吃Region然后从本地扩展到公有云例部署。

混合云形态还是比较复杂的，如果私有云部分平台和公有云平台是一家厂商提供，虽然可能提供较好的线上线下配合能力，但是可能会出现被厂商lockin的状态；如果私有云布平台和公有云部分平台由不同的厂商提供，二者配合提供的肯定又会有所折扣，尤其是一些高级的能力要被阉割。所以使用混合云的客户除了上面讨论的几个点外还要清楚如下几个问题：

1）混合云中的公有云部分和私有云（或专有云）部分是要能够业务协作的，所以有一定质量的网络互通是基本要求；而部署在混合云上的业务数据能否在公有云上也是需要考虑的，比如有些场景可能线上场人工智能学习、线下场景使用相应的学习结果，这个时候就需要将相应的数据同步到公有云以供训练使用；而有些场景可能仅需要互联网访问的弹性伸缩的入口，数据仍然保留在客户本地的数据中心；

2）混合云中的业务在公有云和私有云（或专有云）两部分部署时，除了业务架构有影响外，还有成本和同步能力的约束；其中成本是说根据公有云的云服务费用和本地部署所耗费的基础设施/软件成本综合评估整体成本，而其中同步能力是说两边需要的协同能力可能需要业务数据的两边同步甚至计算资源对象的迁移；具体业务是需要数据迁移还是资源对象的迁移无法一概而论，但是需求不同需要付出的成本（包括费用、协同及时性等）肯定是不同的；

3）客户在使用混合云时由于要使用公有云，需要相关人员具备对应的技能和工具使用能力，这个相比仅使用私有云的客户来讲，无疑组织团队的转型要求是很大的挑战，尤其对政企客户来讲；

4）混合云多个资源池下在一个云管理平台会获取很多益处，比如管理方便性、组织维护简易性、资源编排统一性等，但是对于公有云和私有云由不同厂商提供时，或多个公有云或多私有云之间是不同云平台提供时，云管理平台就成了很难的选择；首先，云平台唯有和自身资源池对接才能有一定配套做出较好的产品质量，而不同厂商产品的管控面对接集成由于缺少标准性往往软件质量会有折扣，并且特性能力会有丢失尤其需要紧密配合的高级能力，所以对混合云客户来说使用没有任何自厂商资源池的云管理平台将是一个不明智的选择；其次云管理平台提供的能力来讲肯定不包含认证能力，IAM认证肯定是要使用资源池自身携带的服务，不然IAM和各个资源池服务很难对接一套api完成对应所需能力的交互；其次云管理平台提供的能力应该以运维能力和集成能力为主，运营能力为辅，因为运维能力优先关注云平台自身的运维能力并且都算是能抽象出来的，而运营能力包括组织模型在每个行业甚至同行业每个客户都是不同的，只能提供一种抽象能力，但是很难满足大部分企业的组织模型需要，这部分软件架构设计一定是要做成可选的部分，否则即是架构上的耦合；

总之我们这里讲混合云是将客户业务至少有部署在两部分资源池的形态，客户本地部署的可能是私有云，也可能是专有云，但无论哪种形态对客户来说，都和纯使用公有云、纯使用私有云是不同的。从部署形态上，部署在客户本地数据中心的可能是完整的region, 也可能是属于就近公有云平台的az形态。简单对比如下。

混合云的运维能力：是否在线协维

云计算也算是有一定的技术发展历史，并且基础云服务（IAAS）相对成熟，纵观各大厂商很少有新的基础云服务或已有云服务的新能力推出，云平台厂商对基础服务在现阶段构建的多是基于这些云服务形成的垂直行业的解决方案能力。随着云平台概念普及和客户部署规模越来越大，整体云平台在面对故障时如何快速恢复业务、快速定界定为的运维能力，成为云平台选择的重要考量项；虽然整体来看混合云销售模式商业策略来定的，至少销售策略影响了混合云平台之间的运维模式，因为使用通过公有向客户本地数据中心扩az部署的局点，其云服务销售模式的云平台产品，通常需要其部署在客户本地数据中心的云平台能被CSP的公有云平台管理，而以完整region部署在客户本地数据中心的形态提供本地运维能力，可以支持云服务销售租用形态，也可以完整购买软硬件资产。我们这里重点讨论下需要从公有云连接网络到客户本地数据中心的场景，可能需要客户有哪些考虑点：

1）混合云的客户本地部分是选择私有云还是公有云，都只是一种场景和部署形态的能力，真正影响的相关业务的诉求，只是如果强制客户本地数据中心和公有云互联，会无法满足很大一部分客户的业务合规要求，尤其是银行核心业务、军工类等局点；客户使用混合云实现一致的公有云体验，其产品的前提将大的政企客户裁掉90%以上；

2）客户本地数据中心部署要连接到公有云部分时，由于维护等原因，云平台会对云平台的软硬件都有更加苛刻的要求，会对客户的软硬件采购流程、采购竞标、采购软硬件白名单合规性都产生一定的冲击；

3）此类场景通常需要云服务模式销售，对于线下客户来说其采购结算流程需要调整，这对尤其是政企客户的组织调整制度有些不匹配；

4）此类场景的客户已有部分组织结构受到威胁，因为没个整齐客户都有大量的自身业务的维护组织和网络组织，需要在云场景下找到自身的定位，因为只有客户自己才最熟悉自己的业务，内部组织也最值信赖的；毕竟业务上云甚至要改造才能上云，对于业务稳定性都是不可避免有一定的影响，前期的磨合出现的问题势必要及时响应才能将影响降到最低；

5）此类场景的云平台厂商通常是锁定的，不可能为了云平台演进让公有云扩展出一个非自己产品的az，所以当组织或客户领导有变化时，引起的云平台切换代价很大；但是相互之间的长期信任，也是深度配合做出竞争力的必要条件；

6）此类场景最终的成本高低无法给出通用计算规则，每个垂直行业可能也有所不同，但是从服务行业的通常属性来说，通常的一种商品出售，加上服务费肯定是价格要高的，而且服务费占总成本的比例往往也不低；拿公有云的云服务来说，单位成本的算力价格肯定要高于单纯本地部署的价格，其节省的费用在于cpu利用率和使用时间按需弹性申请/释放带来的；最好产品的质量稳定性，减少故障问题发生概率，要比给客户布道云软件本来就是高频率迭代的故事要实惠的多；

7）此类场景最大的约束还是客户局点连接到互联网的合规性，其中银行、军工等肯定是不被允许的，甚至在故障时要云平台员工随时出入客户数据中心也是比较犯难；而对于有合规要求的海外尤其是数据不出境的要求，需要云平台的公有云在全球有较多的region建立，否则很难建立远程运维中心；这种模式的创建者本就是和云平台厂商公有云的全球布局结合起来的，跟随者如果不具备只能被误入歧途；

8）此类场景当混合云下有边缘站点时，可能整体上一朵云下存在万千局点，如果从软件发布和测试角度，可能存在数亿的服务版本组合，软件质量很难保证；推广到边缘的核心是公有云时，维护更不可想象；

9）此类场景的费用和部署通常费用是较高的，也就是只有大型客户才有能力购买，但是大型客户往往有自己的运维团队和更加严格的合规要求，所以其商业理念和模式而言存在一定的矛盾。

当然此种模式也有一些优点，除了前面说的公有云一致的使用体验、快速复用公有云新服务能力外，也为部分仅提供数据中心留住业务数据又想享受整套云能力（云特性能力、云建设能力、云维护能力等）的客户提供了选择。所以上帝的归上帝，撒旦的归撒旦；没有任何一种技术是“银弹”，可以一招鲜、吃遍天；架构设计最重要的是明确问题和约束，然后基于设计原则来展开。

混合云的演进：数据主权和价值的冲突

如前面所说，云计算已经有一定的技术发展历史，并且基础云服务（IAAS）相对成熟，各大厂商很少有新的基础云服务或已有云服务的新能力推出；云计算不仅仅是一种IT技术的全新形态，也是商业模式的变更，作者也多次说过更是社会分工模式的变革：让所有行业都数字化/信息化后，所有从业者都更加聚焦专业的服务，不用关注底层IT资源，这样大家都发挥自己的兴趣爱好，变成从业者的强项，从而更加快速的推动社会的进步。

每个行业的数字化，会产生大量的数据，而且对数据的价值挖掘、使用等的工具都会有强烈时的诉求，包括大数据、数据库、EI等。但是数据分析的结果的可信力会成为焦点，举个例子，特斯拉电动汽车辅助驾驶在出现故障时，可能会出现司机和特斯拉厂商各执一词的情况，无法判断实际情况，需要特斯拉操作的日志记录数据放到有一个公信力的平台上，并且每辆车的相关操作都具有可验证、准确的被记录，这样当有问题时就可以准确进行还原事件真实过程；但可惜的是现在没有任何一家可以提供可靠计算力而又有公信力的数据平台。

如果以数字化为基础的云平台提供的云服务能力，将来真的能够以水电的普及度提供给每个使用者时，必然时国家的基础设施来建设，即以国家力度来提供国家级的云计算平台，这个平台的建设可能和4G运营商网络有设备商、运营商、集成商等类似，需要有硬件设备提供商、平台提供商、PAAS中间件提供商等共同支撑云平台的建设和运营。

前面讲的不同的模式来讲（本地运维或远程运维）优劣势和适用场景各有不同，无法时可以替代彼此的存在；而国家级的云平台建设和维护，由于其规模巨大、集成件众多，会导致维护极其复杂，人肉很可能无法及时支撑，需要云平台软件有较好的质量、运维有较多的工具化能力，并且可以实现统一接入点的运维能力。所以技术时发展的，云的业务场景会越来越多，云的形态也会越来越复杂，需要云平台的架构设计等研发者，与时俱进，软件不断迭代来满足需求；而对客户来说，也需要客户有足够的技能积累和提升，其业务适应云化形态，甚至要重构。混合云的架构演进，最终也会归结一种统一的形态。

路漫漫其修远兮，吾将上下而求索！

作者：

李俊武，云计算架构师，从事云计算架构设计多年

文章声明：文章内容仅为个人技术观点，与公司技术/产品没有任何关联；

↓↓ 点击"阅读原文" 【加入云技术社区】

相关阅读：

更多文章请关注

文章好看点这里[在看]👇