#云原生征文# 浅谈云原生——从概念到趋势 原创 精华

0. 阅读完本文你将会

• 学到非常实用的云原生术语
• 了解云原生是什么
• 明白云原生的关键因素
• 洞察2022年云原生的趋势

The Cloud isn’t a place, it’s a way of doing IT.

– Michael Dell, the founder of Dell Technologies.

1. 云原生是什么？

云原生（Cloud Native），从字面上理解就是云计算和土著的意思——云计算上的原住民。

从Cloud来看，云可以看作是一种提供稳定计算存储资源的对象。为了实现这一点，云提供了虚拟化、弹性扩展、高可用、高容错性、自恢复等基本属性。

再看Native，云原生和在云上跑的传统应用不同。一些传统应用是基于SOA(Service-Oriented Architecture,面向服务架构)架构来搭建的，然后再被放到云上。这些传统应用没有充分运用到云的优势。

因为云作为一种分布式架构，它的原住民应该也是要符合这一特性的——就像我们常说的一方水土养一方人，如果水土不服那就会很糟糕！而微服务是具有分布式设计的属性的。

其次云作为一种PaaS（Plarform as a Service, 平台即服务）服务，云上的原住民的整个生命周期都应该是基于云的理念来实现的，那么就需要一套自动化的开发流程来实现。

这些是从字面上对Cloud Native的解构，然后我们再来看看云原生计算基金会(Cloud Native Computing Foundation, CNCF)提供的官方定义：

Cloud-native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

根据官方定义，我们总结下云原生就是：

• 基于容器、服务网格、微服务、不可变基础设施和声明式 API 构建的可弹性扩展的应用。

• 基于自动化技术构建具备高容错性、易管理和便于观察的松耦合系统。

• 构建一个统一的开源云技术生态，能和云厂商提供的服务解耦。

云原生是关于速度和敏捷性的。企业的业务系统正在从实现业务能力演变为加速业务速度和增长的战略转型武器。

同时，随着用户的要求更多，业务系统也变得越来越复杂。它们更加期望快速的反应能力，创新的功能，以及零停机。

性能问题、重复性的错误和无法快速迭代已不再被接受。当出现上述这些情况，你的用户将会访问你的竞争对手。

2. 云原生的关键因素

云原生的速度和敏捷性来自于许多因素。

本章我们将会讲述其中最主要的六大因素。

2.1 云架构（Cloud Infrastructure）

云原生系统充分利用了云服务模式的优势。这些系统的设计目的是为了在动态、虚拟化的云环境中茁壮成长。它们广泛使用PaaS的计算基础设施和管理服务。它们将底层基础设施视为一次性的-在几分钟内完成配置，并通过自动化按需调整、扩展或销毁。

在云原生领域，有一个类比的概念叫做Pets vs. Cattle，字面理解的意思就是宠物 vs. 牛。

1. Pets-宠物

在传统的数据中心，服务器被视为宠物：一台物理机器，被赋予一个有意义的名字，并由你照顾。你通过向同一台机器添加更多的资源来进行扩展。如果服务器生病了，你要照顾它直到恢复健康。

在这种模式下，服务器被视为不可缺少的系统组件，永远不可能停机。一般来说，它们是人工建立、管理和手动"喂养"的。这方面的例子包括大型机、单独的服务器、HA（Highly Available,高可用）负载均衡器/防火墙、主/从数据库系统等。

2. Cattle-牛

而Cattle的服务模式是不同的。你把每个实例作为一个虚拟机或容器来配置。它们是相同的，并分配给一个系统标识符。你通过创建更多的实例来进行扩展。当一个实例变得不可用时，没有人注意到。

Cattle的模式使用不可改变的基础设施。服务器不会被修复或修改。如果一个服务器出现故障或需要更新，它就会被销毁，然后配置一个新的服务器。所有这些工作都通过自动化完成。

由两台以上的服务器组成的阵列，一般使用自动化工具构建，阵列中没有哪个服务器是不可替代的。通常情况下，故障事件不需要人工干预，因为阵列表现出 "绕过故障"的属性，通过重新启动故障服务器或通过三重复制或编码擦除等策略复制数据。

这方面的例子包括网络服务器阵列，多主机数据存储，如Cassandra集群，以及几乎所有的负载平衡和多主机。

2.2 现代设计（Modern Design）

你会如何设计一个云原生应用程序？你的架构会是什么样子的？你会遵守哪些原则、模式和最佳实践？哪些基础设施和操作问题是重要的？

2.2.1 十二因素

如何构建一个云应用？业界广泛接受的一个准则就是十二因素。

12因素是一系列云原生应用架构的模式集合。这些模式可以用来说明什么样的应用才是云原生应用,可以用来衡量一个后端服务是否适合上云。

本节的反例并不是指技术本身不够好，而是指它们的一些原生特性对于开发复杂的应用不够友好。

1. CodeBase-基准代码

One codebase tracked in revision control, many deploys

一份基准代码可以多份部署，可通过版本控制进行追踪。

反例：多个无关项目、数百万行代码全部放到一个仓库；对于差异需求，直接复制项目仓库单独开发，同时维护多个仓库代码。

2. Dependencies-显式和隔离的依赖

Explicitly declare and isolate dependencies

每个微服务都可以显式声明依赖并且互不干扰，拥抱变化而不影响整个系统。

反例：Node.js之父Ryan Dahl另起炉灶创造了Deno，Deno的import远程代码就是Node世界的npm反向极端，造成了隐式依赖；Golang在1.13之前没有go module的时候，也是违反这条原则的。且不说不清晰的第三方依赖容易导致"投毒"，这对代码的问题定位、维护、交接都是很大的负担。

3. Config-配置分离至环境

Store config in the environment

配置数据和构建产物完全分离，配置数据单独管理，只在运行环境中出现。

反例：环境相关的配置，混在容器镜像、甚至代码包中，每个环境需要单独构建打包一个版本。这种做法在传统的开发模式中很常见。

4. Backing Services-分离后端服务

Treat backing services as attached resources

把后端服务当作附加资源。后端服务是指程序运行所需要的通过网络调用的各种服务，包括数据库，缓存，消息队列等。

反例：把缓存服务和应用服务打包到同一个容器镜像，通过/var/redis.sock这样的Domain Socket形式访问；或者把第三方应用服务的源码直接复制到自己的代码中，在一个进程中互相调用。

5. Build, release, run-分离构建、发布、运行

Strictly separate build and run stages

每个版本必须在构建、发布和运行阶段实行严格的分离。每个版本都应该被标记为唯一的ID，并支持回滚的能力。CI/CD系统有助于实现这一原则。

反例：开发改完代码，本地打个Patch发给运维，也不告知产品经理改了什么，直接口头告诉运维批量更换某些文件。

6. Processes-无状态的服务进程

Execute the app as one or more stateless processes

每个微服务应该在自己的进程中执行，与其他正在运行的服务隔离。如果存在状态，应该将状态外置到后端服务中，例如数据库、缓存等。

反例：应用服务的多个实例之间互相通信，共享一些内存数据；或者开发自治的集群选主、任务分发等功能。

7. Port Binding-端口绑定

Export services via port binding

每个微服务都应该是独立的，其接口和功能都暴露在自己的端口上。这样做提供了与其他微服务的隔离。

反例：提供出去部署的包的是放到Tomcat的war、放到IIS的dll，自己本身没有描述通信协议，也没有指定绑定的端口，完全依赖Tomcat/IIS的配置。

8. Concurrency-并发能力

Scale out via the process model

通过进程模型进行扩展，扩展方式有进程和线程两种。进程的方式使扩展性更好，架构更简单，隔离性更好。线程扩展使编程更复杂，但是更节省资源。

反例：把Session放到内存中。

9. Disposability-快速启动和优雅终止的易处理

Maximize robustness with fast startup and graceful shutdown

快速启动和优雅终止可最大化健壮性，只有满足快速启动和优雅终止，才能使服务更健壮。

反例：很重的Java服务启动耗时十几分钟；缩容靠kill -9强杀进程；服务也没有实现收到SIGTERM信号进入"跛脚鸭状态"，也没有等待请求处理完再关闭进程。

10. Dev/prod parity-环境等同

Keep development, staging, and production as similar as possible

尽可能地保持整个应用生命周期的环境相似，包括开发环境、预发布环境、线上环境等。

反例：开发环境不容器化，产线容器化；开发环境用的MariaDB，产线用的MySQL；开发环境数据库没主从，产线配置了主从同步。这样在MySQL读写分离时，主从同步那几毫秒的延迟导致各种奇怪Bug，在开发环境也许永远都重现不出来。

11. Logs-作为事件流的日志

Treat logs as event streams

将微服务产生的日志视为事件流。微服务架构中服务数量的爆发需要具备调用链分析能力，快速定位故障。

反例：项目中写了一堆log4xx的复杂配置，日志文件存哪个路径、多长时间轮滚、保留多久删除。传统的软件这是必备的，但云原生应用，请仅保留打印到标准输出/标准错误。还有一个反模式的例子，在应用内就通过代码把日志抛到Kafka这类Broker中，无形中也让应用服务和Kafka耦合到了一起。

很多人不相信日志打印到stdout/stderr就完事了，是因为不够了解云原生世界中，各类日志收集和处理组件的强大。我们对传统的做法习以为常，却忘记了"单一职责原则"。

12. Admin processes-分离管理类任务

Run admin/management tasks as one-off processes

把后台管理任务当作一次性进程运行，一些工具类在生产环境上的操作可能是一次性的，因此最好把它们放在生产环境中执行，而不是本地。

反例：在应用服务运行环境中安装一个数据库客户端，运维人员手动跑一堆修改数据库的SQL；或者安装一些运维脚本，放到机器的cron table定期执行一些脚本。

2.3 微服务(MicroServices)

2.3.1 微服务是什么？

微服务架构是以开发一组小型服务的方式来开发一个独立的应用系统，每个服务都以一个独立进程的方式运行，每个服务与其他服务使用轻量级（通常是 HTTP API）通信机制。

这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署，同时服务会使用最小规模的集中管理（例如 Docker）能力，也可以采用不同的编程语言和数据库。

如何确定微服务的颗粒度（Service granularity），即如何定义这个"微"字？

对于这种问题的没有共识，因为正确的答案取决于业务和组织背景。

把服务做得太小被认为是不好的做法，因为那样的话，运行时的开销和操作的复杂性就会压倒微服务的好处了。当服务变得过于精细时，必须考虑其他的方法-比如将功能打包成一个库，将功能转移到其他微服务中。

所以微服务的"微"不能简单认为是"小"的意思，我们可以理解为"合适"。

2.3.2 微服务的优势

云原生系统包含了微服务，微服务具有以下优势。

1. 由于组成服务的规模较小，它们可以从一开始就由一个或多个小团队来构建，并且划分好服务边界。这使得在需要时更容易扩大开发力度。

2. 一旦开发完成，这些服务可以独立部署，也很容易识别热门服务，并将它们独立于整个应用进行扩展。

3. 微服务还提供了更好的故障隔离，在一个服务出错的情况下，整个应用程序不一定会停止运行。当错误被修复后，可以只为相应的服务进行部署，而不是重新部署整个应用程序。

4. 微服务架构带来的另一个优势是更容易选择最适合所需功能的技术栈（编程语言、数据库等），而不是被要求采取更标准化的、一刀切的方法。

下表展示了单体架构和微服务架构的对比：

影响因素	单体	微服务	说明
交付速度	较慢	较快	服务拆分后，各个服务可以独立并行开发、测试、部署，交付效率提升，产品的更新速度会更快，用户体验更好。代码规模越大，微服务的优势越明显。
故障隔离范围	线程级	进程级	服务独立运行，通过进程的方式隔离，使故障范围得到有效控制，架构变得更简单可靠。根据业务的重要程度划分服务，把核心的业务划分为独立的服务，这样从数据库到服务可以保持有效的故障隔离，进而保持稳定。
整体可用性	较低	更高	微服务架构由于故障范围得到有效隔离，整体可用性更高，降低一点故障对整体的影响。

2.3.3 微服务的劣势

事物都有两面性，虽然微服务具有诸多的优势，但是我们也需要正视使用它带来的挑战。

1. 复杂性

首先，服务之间的通信可能很复杂。一个应用程序可能包括几十个甚至几百个不同的服务，而它们都需要安全地进行通信。

其次，微服务的调试变得更具挑战性。一个应用程序由多个微服务组成，每个微服务都有自己的日志，追踪问题的来源可能很困难。

最后，微服务的设计、开发、部署、测试会更加复杂。

2. 接口控制

每个微服务都有自己的API，应用程序依靠它来实现一致性。虽然你可以很容易地对一个微服务进行修改而不影响与之交互的外部系统，但如果你改变了API（接口），如果改变后不能向后兼容，任何使用该微服务的应用程序都会受到影响。

微服务架构模型导致了大量的API，这些API对企业的运作都是至关重要的。因此接口控制变得至关重要。

3. 成本上升

要使微服务架构在企业中发挥作用，你需要有足够的托管基础设施，并有安全和维护支持，你还需要有熟练的开发团队来理解和管理所有的服务。

如果你已经有了这些东西，转移到微服务所涉及的成本可能会更低。但大多数目前正在运行单体架构的企业将需要投资于新的基础设施和开发人员资源，以便进行转移。

2.4 容器(Containers)

2.4.1 容器是什么

Containers are a great enabler of cloud-native software.

《Cloud Native Patterns》的作者Cornelia Davis说，“容器是一个伟大的云原生推动者”。

而云原生计算基金会也将微服务容器化作为指导企业实现云原生蓝图的第一步。

容器是一种操作系统虚拟化形式。可以使用一个容器来运行从小型微服务或软件进程到大型应用程序的所有内容。

容器包含所有必要的可执行文件、二进制代码、库和配置文件。但是，与服务器或计算机虚拟化方法不同，容器不包含操作系统映像。因此，它们更轻便且可移植，其开销很小。

容器化一个微服务并不难，你只需要将软件代码和所需要的所有组件（例如库、框架和其他依赖项）打包成一个二进制文件——容器镜像。镜像存储在容器的注册表中，而注册表可以位于你的计算机上，在你的数据中心，或在一个公共云上。

当一个应用程序启动或扩展时，你会将容器镜像转化为一个正在运行的容器实例。该实例在任何安装了容器运行时引擎的计算机上运行。你可以根据需要决定拥有多少个容器化服务的实例。

下图显示了三个不同的微服务，每个微服务都在自己的容器中，并且都在同一台主机上运行。

图.容器

每个容器是单独维护自己的依赖关系和运行时间集的，它们可能彼此不同。从图上我们可以看出，不同版本的产品微服务是在同一个主机上运行的。

每个容器共享主机操作系统、内存和处理器，但是彼此是隔离的。这里很好地体现了上文中12因素的依赖性原则。

2.4.1 容器的优势

1. 轻量级、可移植性

在容器中运行的应用程序可以轻松部署到多个不同的操作系统和硬件平台。它们能够共享主机的操作系统内核，不需要为每个容器提供单独的操作系统，且允许应用在任何基础架构（裸机、云）上运行相同的操作系统，甚至在虚拟机（VM）中。

2. 成本降低

与传统或硬件虚拟机环境相比，容器所需的系统资源更少，因为它们不包含操作系统映像。

3. 改善了应用程序的开发

开发人员在一个主机环境中使用容器时，可以像在另一个主机环境中一样使用相同的工具，如此，在各个操作系统间开发和部署容器化应用就变得更加简单。而且容器支持敏捷的 DevOps工作，以加速开发测试并缩短生产周期。

容器 vs 虚拟机

虚拟机（VM）是一种创建于物理硬件系统（位于外部或内部）、充当虚拟计算机系统的虚拟环境，它模拟出了自己的整套硬件，包括 CPU、内存、网络接口和存储器。

容器化和虚拟化的相似之处在于它们都允许应用完全隔离，以便在多个环境中运行。而它们的主要区别在于尺寸大小和可移植性。

虚拟机在两者中尺寸较大，通常以千兆字节为度量单位，且包含它们自己的操作系统，所以可以同时执行多个资源密集型功能。由于虚拟机的可用资源大大增加，因此它们可以抽象、分离、复制和模拟整个服务器、操作系统、台式机、数据库和网络。

容器则要小得多，通常以兆字节为度量单位，且其中仅包含应用及其运行环境。

虚拟机高度兼容传统的单体式 IT 架构，容器则兼容更新的新兴技术，例如云、CI/CD(Continuous Delivery,持续交付；Continuous Deployment，持续部署) 和 DevOps。

由于容器的特性，微服务和容器可以很好地协同工作，因为容器中的微服务具有容器的所有的可移植性、兼容性和可扩展性。

2.4.2 容器编排(Container orchestration)

虽然像Docker这样的工具可以创建镜像和运行容器，但是你也需要工具来管理它们。我们可以使用容器编排工具来完成容器的部署、管理、扩展以及联网。容器编排可以为需要部署和管理成百上千个容器和主机的企业提供便利。

那么容器编排到底做了什么呢？

1. Scheduling-任务安排

自动提供容器实例

2. Affinity/anti-affinity-亲和/反亲和

3. Health monitorinh-健康检测

自动检测和纠正故障。

4. Failover-故障转移

自动将一个失败的实例重置到一个健康的机器上。

5. Scaling-自动扩展

自动添加或删除一个容器实例以满足需求。

6. Networking-联网

管理用于容器通信的网络层。

7. Service Discovery-服务发现

使容器能够相互定位。

8. Rolling Upgrades-滚动更新

协调增量升级，实现零停机部署，自动回滚有问题的更新。

我们可以发现容器编排体现了12因素中的易处理原则和并发性原则。

2.5 后端服务-Backing services

图.后端服务

App在运行过程中通过网络消费的任何服务都可以称为后端服务。在传统的操作系统中，这些服务可以通过网络、UNIX套接字访问，甚至可以是一个子进程。例子包括并不限于：

• 数据库（MySQL，PostgreSQL）
• 消息队列（Kafka, RabbitMQ）
• 文件存储（NFS，FTP）
• 日志服务
• 缓存系统
• SMTP服务

你可以管理自己的后端服务，也可以让云厂商代管。云厂商提供丰富的后端服务，你无需拥有该服务，而是可以直接消费。

云厂商操作大规模的资源，并承担性能、安全和维护的责任。云原生系统倾向于云厂商提供的后端服务。在这方面，我们可以在时间和劳动力上节约很多。如果是自己托管，那么遇到的运行风险会比较麻烦。

最佳实践是将后端服务视为附加资源，动态地与微服务绑定，而配置信息存储在外部配置中。这一原则在上文的12因素中得到了阐述。

12因素中的因素4规定，后端服务应该通过一个URL暴露，这样做可以使资源和应用脱钩，使其可以互换。

因素3规定，配置信息应该被移出微服务，并通过代码外的配置管理工具实现外部化。
后端服务也体现了12因素中"无状态的服务进程"原则，把依赖的服务分离出去，一些应用服务已经可以实现"无状态"了。

但有时候，还需要对应用内部做一些改造才能实现无状态。无状态是水平扩展的前提，对于Serverless应用更是必要条件。

2.6 自动化（Automation）

如你所见，云原生采用微服务以及容器化技术以实现它的速度和敏捷性。但是这还远远不够，你如何配置这些系统所运行的云环境？如何快速部署应用程序的功能和更新？

我们先来了解下IaC（Infrastructure as Code,基础设施即代码）的概念。

基础设施即代码 (IaC) 指的是通过代码而不是手动流程来管理和配置基础设施。IaC 有时也称为"可编程基础设施"，可将基础设施配置完全当作软件编程来进行。

IaC 协助将基础设施管理从数据中心内的物理硬件过渡到虚拟化、容器和云计算。对于 IaC、网络、虚拟机、负载平衡器和连接拓扑都使用高级语言进行编码，将应用开发所依靠的环境标准化。

完成编码后，DevOps 能够启动、拆解和扩展基础设施，以响应不断波动的需求。这样的敏捷性能够造就更快、更简单的软件开发、测试和部署。

2.6.1 基础设施自动化（Infrastructure Automation）

我们可以使用特定的工具（比如Azure Bicep）来对所需要的云基础设施进行声明性的编写。资源的名称、位置、容量都是参数化和动态的。你编写的脚本会受到版本控制。调用该脚本即可在不同的系统环境中配置一致的，重复性的基础设施。

你可以重复运行同一个脚本而不产生副作用。如果团队想更新资源，他们可以编辑并重新运行脚本。

在《什么是基础设施即代码》一文中，作者Sam Guckenheimer描述道：“实施IaC的团队可以快速、大规模地交付稳定的环境。他们避免手动配置环境，并通过代码来保证理想环境的一致性。采用IaC的基础设施部署是可重复的，可以防止因配置漂移（Configuration Drift）或依赖性缺失而导致的运行问题。DevOps团队可以使用一套统一的实践和工具来快速、可靠和大规模地交付应用程序及其支持的基础设施。”

2.6.2 部署自动化（Deployment Automation）

前面的12因素中的因素5提到，每个版本必须在构建、发布和运行阶段实行严格的分离。每个版本都应该被标记为唯一的ID，并支持回滚的能力。

为什么要强调"构建、发布、运行"三个阶段一定要分离开来呢？

有两个好处：

1. 职责和关注点的分离。构建是开发测试人员更关注的、发布是产品经理更关注的、运行是运维更关注的；

2. 流水线模式带来的效率提升，以及各阶段之间的缓冲空间，每个阶段有专门的工具和方法论。

怎么做到这三个阶段的分离呢？流水线的运行不是靠人力保障的，自动化系统很重要。

CI/CD系统有助于实现这一原则。它们提供独立的构建和交付步骤，帮助确保一致的、高质量的代码，并可随时提供给用户。

1. 开发者在开发环境中开发了一个功能，通过代码、运行和调试的"内循环"进行迭代。
2. 完成后，这些代码被推送到代码库中，如GitHub或BitBucket。
3. 然后CI自动构建、测试和打包应用程序。
4. 到了发布阶段，CD系统将打好的包，外部应用和环境配置信息合成一个不可变的版本。该版本被部署到一个指定的环境中。每个版本都应该是可识别的。
5. 最后，发布的功能在生产环境中运行。

使用这些技术，企业已经从根本上改变了他们发布软件的方式。许多企业已经从每季度一次的发布转变为按需更新。

以上就是云原生的六大关键因素了，下面让我们来看看云原生在2022年的新趋势。

3. 云原生的趋势

在过去几年中，IT行业见证了云原生技术的指数级增长。当我们来到2022年，我们需要关注以下五个关键的云原生趋势。

3.1 WebAssembly在云原生环境中的崛起

WebAssembly已经发展成为一个高性能、跨平台、多语言的软件沙盒环境，可用于云原生软件的组件。鉴于容器运行时和WebAssembly（WASM）之间惊人的相似性，Kubernetes可用于协调WASM组件。

WasmCloud、WasmEdge、KubeEdge和Krustlet等项目使WASM成为云原生宇宙的一等公民。

将打包成WebAssembly的软件与容器化软件一起运行是极有可能的。Kubernetes可以无缝地协调这两种组件。

3.2 云原生安全

随着网络安全越来越被重视，云原生安全在2022年也会受到更多的关注。

有两个领域会获得更多的关注——软件供应链和eBPF（Extended Berkeley Packet Filter）

1. 软件供应链

软件供应链类似于现实世界中的商业供应链。资源被消耗，然后通过一系列的步骤和过程进行转化，最后提供给客户。

现代的软件开发是将公共领域中的各种组件作为开放源码项目进行组装和整合。在复杂的软件供应链中，一个被破坏的软件会对多个部署造成严重损害。所以务必要保证软件供应链的安全性。

2. eBPF

另一个令人兴奋的趋势是eBPF，它使云原生开发人员能够构建安全的网络、服务网和可观察性组件。

3.3 Kubevirt走向主流

Kubevirt是一个开源项目，它使得Kubernetes能够像容器一样协调虚拟机。

通过运行虚拟机和容器，我们可以轻松地将传统的工作负载与基于微服务的应用程序整合起来。

2022年，我们将看到Kubevirt与Kubernetes的应用整合急剧上升。

3.4 GitOps成为持续部署的标准

GitOps为云原生工作负载的发布管理带来了熟悉的基于Git的工作流程。通过将Git作为单一可信来源来控制状态，加上快速回滚的能力，使GitOps成为一个强大的机制。

2022年，GitOps将发展到支持多租户和多集群部署，使其能够轻松管理数万个Kubernetes集群。也许GitOps将成为持续部署的黄金标准。

3.5 混合云和多云的架构

混合云服务可以将各方的优势结合在一起。需要快速和频繁访问的数据可以保存在公共服务器上，而更敏感的数据可以保存在有监控访问的私人服务器上。一个良好的整合和平衡的混合云战略给企业带来了两个世界的最佳效果。

而多云模式可以帮助企业选择最适合其个人应用环境、业务要求和可用性需求的不同云产品。展望未来，更多的企业将需要开发完全云原生的应用程序，几乎没有架构上对任何特定云厂商的依赖。

尽管很多大型企业已经采用混合云和多云战略作为标准，但2022年将见证更多企业认识到这些模式的优势，并接受它们，以享受云的弹性和敏捷性。

【本文正在参加云原生有奖征文活动】，活动链接：https://ost.51cto.com/posts/12598