共计 2791 个字符，预计需要花费 7 分钟才能阅读完成。
简介：多年来，随着云计算技术的蓬勃发展和落地，越来越多的企业抉择采纳云计算技术来帮忙本人疾速实现业务数字化转型，以便能更好地适应市场变动，进而博得更大的市场空间。
作者 | 郝树伟
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 隔离更高。例如企业外部不同部门部署各自独立的集群、应用多个集群来别离部署开发 / 测试 / 生产环境等。
小结
上云已是大势所趋，有些企业客户基于数据主权和平安隐衷的思考，会采纳混合云架构；还有一些企业客户基于数据主权、老本优化、晋升地区覆盖性等需要，会抉择混合云加多集群架构。混合云和多集群的架构曾经成为企业上云的新常态。
原文链接
本文为阿里云原创内容，未经容许不得转载。
