当云原生遇到混合云：如何实现“求变”与“求稳”的平衡

Posted 2021-10-05 阿里云云栖号

简介： 多年来，随着云计算技术的蓬勃发展和落地，越来越多的企业选择采用云计算技术来帮助自己快速完成业务数字化转型，以便能更好地适应市场变化，进而赢得更大的市场空间。

作者|郝树伟

Flexera 的《RightScale2021 云状态报告》中指出 92% 的大型企业采用混合云战略。Gartner 也在一份报告中称未来 90% 中大型企业将利用混合云架构管理基础设施。

多年来，随着云计算技术的蓬勃发展和落地，越来越多的企业选择采用云计算技术来帮助自己快速完成业务数字化转型，以便能更好地适应市场变化，进而赢得更大的市场空间。其中有很大一部分企业基于降低技术开发和运维成本、享受随时随地的即时服务等原因，选择将自己的业务部署在云端；还有一部分企业由于数据主权和安全隐私方面的考虑，会选择在自己内部数据中心环境中搭建自己的专有云平台；对于公共云和专有云都有需求的企业用户会选择搭建混合云架构。

为什么需要混合云架构

企业自身业务安全性考虑

对于企业用户，特别是大型企业用户来说，把公司的关键“生命线”业务完全托付给一个外部云厂商来保障，是有一定的风险的。虽然公共云厂商通常都提供了安全可靠的冗余方案来保证企业用户服务的不间断性，但也并不是没有意外发生。使用混合云方案可以保证企业用户同时具有 A B 两套方案选择和切换，最大限度保证业务稳定性。

数据主权和安全隐私方面的监管要求

一些法律法规或者公司自身的安全策略对其企业数据所存储或驻留的地点有硬性要求，比如欧盟的“通用数据保护条例”（GDRP）等对数据控制者和数据处理者的数字监管措施，比如企业政策要求数据只能驻留在指定地点，目的是为了保护数据隐私和安全性等等。混合云云架构可以帮助企业用户满足这一类的需求。

享受云厂商的服务特性

本地云与公共云厂商提供的服务质量是有一定的差异性的，这种差异性体现在方方面面，取决于用户的实际需求和考量。比如地域覆盖面的差异性，企业用户通常在本地云中自提供的服务，在某个特定的区域内云厂商提供的服务在访问延迟上更优，企业用户在此区域有重要客户且对云服务的访问延迟有较高要求，则企业用户会选择将此区域的业务部署在公共云上，其他业务继续部署在本地云上。

成本优化

本地云在基础设施上缺乏灵活的扩缩容能力，无法在业务高峰和低谷期根据实际需求合理安排基础计算资源，造成很大程度上的资源浪费和成本增加，而云上弹性敏捷、按需扩缩容的特性，可以弥补本地云的这一缺陷。

追随技术革新

对与一些类似人工智能、机器学习、物联网等高精尖技术的技术革新和演进上，通常云厂商能够第一时间提供与之相对应的云服务，企业用户可以以更小的成本使用这些云服务，并推动企业自身的技术革新和发展，混合云架构可以让企业随时随地采用最好的云服务。

云原生如何助力混合云架构演进

公共云和本地云本身就是两朵不同的云，它们有不同的基础设施、不同的能力特性以及不同的 API 接口，构建混合云架构，一方面需要云提供商耗费大量精力在适配和整合云平台的能力上，另一方面，用户在这种架构下也无法真正按需切换云服务提供商，反而是另一种形式的绑定。传统混合云的种种缺陷，导致这种云架构无法形成标准化的生态体系，也是一直以来我们无法针对这种云架构构建统一管理、统一交付的原因。

Kubernetes 的出现让混合云云架构进入 2.0 时代，Kubernetes 的多项特性及其相关生态体系为混合云的标准化提供了可能性：

• 以 Kubernetes 为代表的云原生技术屏蔽了基础设施的差异性，目前各个云厂商以及大量的数据中心都已经落地这些技术，使得应用“一次定义，到处部署”成为可能。
• Kubernetes 标准化、声明式的 API，简化了应用的部署，让应用交付变得越来越标准化和统一化，支持在不同的云上使用相同的方式描述和编排应用。
• 网格服务技术可以跨越多个 Kubernetes 集群，实现统一的流量管理和服务治理，使得混合云云架构下的应用服务统一到一个控制平面进行管理。

在云原生时代，以 Kubernetes 为代表的云原生技术推动了以应用为中心的混合云架构的到来，Kubernetes 已经成为企业多集群管理的事实基础。

云原生混合云多集群的典型使用场景

异地多活——跨地域容灾

虽然从基础设施服务和 Kubernetes 容器平台两个维度来看，用户可以低成本搭建一个高可用应用业务架构，但对于容灾能力要求更高的一些业务，还需要通过异地多活这样的地域级容灾能力来实现。

用户可以在单一云厂商的不同区域搭建多个集群，也可以分别在线下 IDC 和线上云厂商的不同区域搭建多个集群来实现业务应用的异地多活部署。下图展示了混合云场景下 IDC 内的容器集群和公共云上的容器集群 Active-Active 部署，在异地多活架构下，应用的业务负载同时部署在多个集群上，然后使用一个全局的 DNS 服务将请求转发到对应的后端集群，当其中一个集群发生故障无法处理请求时，DNS 服务会自动处理并只转发请求到健康的集群。

低延时——就近访问

对于开展全球化国际业务的用户来说，服务的访问者分布广泛，如果服务器部署在某个特定的区域，势必会造成其他部分地区网络体验差的问题。

在这种场景下，我们就可以选择在多个地域分别部署集群，通过智能 DNS 解析将用户请求转发至距离最近的集群处理，最大限度减少网络带来的延迟。例如下图中，某应用服务分别部署于北京，成都，香港三个地域的 Kubernetes 集群，来自华北区域的用户请求会被智能解析到北京的 Kubernetes 集群，来自西南区域的用户请求会被智能解析到成都的 Kubernetes 集群，来自海外的用户请求则会被智能解析到香港的 Kubernetes 集群，这样可以最大限度地减少地理距离带来的网络延迟，为各地用户带来一致的服务体验。

降低爆炸半径

通常情况下，多个小规模的集群要比一个大规模的集群更容易进行故障隔离。集群有可能因为磁盘、网络等故障导致无法处理请求，使用多个集群可以将故障限制和隔离在某个集群，避免引起更大的连锁反应。

业务隔离

不同的业务通常需要做好业务隔离，虽然 Kubernetes 本身也有命名空间的机制来帮助用户做安全隔离，但这只是逻辑上的软隔离，不同 namespace 之间依然可以网络互通，而且也还存在资源抢占的问题，需要进一步配置网络隔离策略和资源限额等。

选择将不同的业务部署在不同的 Kubernetes 集群中，可以在物理上实现业务的彻底隔离，安全性和可靠性相比使用 namespace 隔离更高。例如企业内部不同部门部署各自独立的集群、使用多个集群来分别部署开发/测试/生产环境等。

小结

上云已是大势所趋，有些企业客户基于数据主权和安全隐私的考虑，会采用混合云架构；还有一些企业客户基于数据主权、成本优化、提升地域覆盖性等需求，会选择混合云加多集群架构。混合云和多集群的架构已经成为企业上云的新常态。

原文链接
本文为阿里云原创内容，未经允许不得转载。