目录 1
一、调研方向 2
二、云原生的概念 3
2.1 云原生的诞生 3
2.2 云原生的发展历程 3
2.3 Pivotal的云原生定义 4
2.4 Gartner的云原生定义 5
2.5 CNCF的云原生定义 5
2.6 云原生定义概括 5
三、 CNCF 7
3.1 云原生计算基金会CNCF 7
3.2 CNCF云原生路线图（Trail Map） 7
3.3 CNCF云原生全景图（Trail Map） 8
四、相关技术及发展趋势 10
4.1 CNCF云原生全景图详解 10
4.1.1 供应层（Provisioning） 10
4.1.2 运行时层（Runtime） 10
4.1.3 编排和管理层（Orchestration and Management） 10
4.1.4 应用定义和开发层（Application Definition and Developement) 11
4.1.5 贯穿所有层的工具 11
4.1.6 可观察性和分析（Observability and Analysis） 12
4.1.7 平台类（Platform） 12
4.1.8 小结 12
4.2 云原生核心概念 12
4.2.1 DevOps与CI/CD 13
4.2.2 微服务、API管理与集成 14
4.2.3 容器与Docker 14
4.2.4 Kubernetes与容器编排之战 15
4.3 发展趋势和未来展望 15
4.3.1 机遇和挑战 15
4.3.2 云原生2.0（华为） 18
4.3.3 未来发展趋势 18
五、参考链接 20

1 调研方向

梳理云原生的概念及相关技术和发展趋势。

https://landscape.cncf.io/
图一.1CNCF云原生全景图（详）

2 云原生的概念

2.1 云原生的诞生

随着虚拟化技术的成熟和分布式框架的普及，在容器技术、可持续交付、编排系统等开源社区的推动下，以及微服务等开发理念的带动下，应用上云已经是不可逆转的趋势。

图二.1云原生的发展史，来自CNCF基金会执行董事Dan Kohn
云计算的3层划分，即基础设施即服务(IaaS)、平台即服务(PaaS)、软件即服务(SaaS)为云原生提供了技术基础和方向指引，真正的云化不仅仅是基础设施和平台的变化，应用也需要做出改变，摈弃传统的土方法，在架构设计、开发方式、部署维护等各个阶段和方面都基于云的特点，重新设计，从而建设全新的云化的应用，即云原生应用。

2.2 云原生的发展历程

云原生（Cloud Native）最初来描述云上应用的典型架构与特性，随着容器、kubernetes、Serverless、FaaS技术的演进，CNCF（Cloud Native Computing Foundation ，云原生计算基金会）把云原生的概念更广泛地定义为“让应用更有弹性、容错性、观测性的基础技术，让应用更容易部署、管理的基础软件、让应用更容易编写、编排的运行框架等”，希望能够让开发者最好的利用云的资源、产品和交付能力。
下边大致梳理一下云原生的发展过程。

2004 年 ~ 2007 年，Google 已在内部大规模地使用像 Cgroups 这样的容器技术；
2008 年，Google 将 Cgroups 合并进入了 Linux 内核主干。
2013 年，Docker 项目正式发布。
2014 年，Kubernetes 项目也正式发布。
2015 年，CNCF （Cloud Native Computing Foundation）云原生基金会成立，CNCF 是目前云计算领域最成功的开源基金会之一，是 Kubernetes、 etcd、Envoy 等知名开源项目的托管基金会。
2017 年，CNCF 达到 170 个成员和 14 个基金项目。
2018 年，CNCF 成立三周年有了 195 个成员，19 个基金会项目和 11 个孵化项目，如此之快的发展速度在整个云计算领域都是非常罕见的。

2.3 Pivotal的云原生定义

云原生（Cloud Native）这个概念，是由Pivotal的Matt Stine于2013年首次提出，他还在2015年出版了《Migrating to Cloud-Native Application Architectures（迁移到云原生架构）》一书。
Pivotal作为云原生（Cloud Native）应用架构中先驱者和探路者，于2015年提出了云原生应用。同一年Google主导成立了云原生计算基金会（CNCF），起初CNCF对云原生的定义包含三个方面：应用容器化、面向微服务架构、应用支持容器的编排调度。
随着科技的发展，CNCF基金会对云原生进行了重新定义：云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
上面提到云原生的代表技术包括容器、服务网格（Service Mesh）、微服务、不可变基础设施和声明式API。另外一种比较主流的说法是云原生=微服务+DevOps+持续交付+容器化
Pivotal最新官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器。

2.4 Gartner的云原生定义

2019年，Gartner曾经发布报告表示云原生时代已经到来，在未来三年中将有75%的全球化企业将在生产中使用容器化的应用。
但Gartner提到云原生的定义尚不明确，却含义丰富。云原生对于不同的人和组织来讲，有着不同的理解。众多顶级技术的铸造者、Matt Stine的东家Pivotal如此定义云原生。
“Cloud native is an approach to building and running applications that fully exploit the advantages of the cloud computing model.”–云原生是一种构建和运行充分利用云计算模型优势的应用程序的方法。

2.5 CNCF的云原生定义

CNCF云原生计算基金会如此定义云原生：
“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格（Service Mesh）、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。”

2.6 云原生定义概括

云原生是指从云的原生应用角度出发，一整套设计、开发、部署、运行、维护的流程、技术栈以及背后文化理念的统称。
云原生简单来说，摈弃传统的土方法，在架构设计、开发方式、部署维护等各个阶段和方面都基于云的特点，重新设计，从而建设全新的云化的应用，即云原生应用。

3 CNCF

3.1 云原生计算基金会CNCF

提到云原生，就不能不介绍云原生计算基金会CNCF（Cloud Native Computing Foundation）。CNCF于2015 年7月由Google 牵头成立，隶属于 Linux 基金会，初衷是围绕云原生服务云计算，致力于培育和维护一个厂商中立的开源生态系统，维护和集成开源技术，支持编排容器化微服务架构应用，通过将最前沿的模式民主化，让这些创新为大众所用。
CNCF的使命包括以下三点：
• 容器化包装
• 通过中心编排系统的动态资源管理
• 面向微服务
全球主流的科技企业和云计算厂商绝大部分都是CNCF会员，其中不乏多家来自中国的科技巨头。

图二.2 CNCF黄金、白金会员

3.2 CNCF云原生路线图（Trail Map）

对于企业在复杂的基础架构之上如何推动云原生应用的更好落地，从而更好地适应环境与业务的发展，CNCF给出了路线图（Trail Map）用于对用户在整体上给出指导建议，共分成十个步骤（容器化；CI/CD；应用定义及编排；监控及分析；服务代理、发现和网格；网络、策略及安全；分布式数据库及存储；流与消息；镜像库与运行时；软件分发）进行实施，而在不同的步骤都可以结合CNCF全景图（Landscape）中列出的产品或服务进行选择。

3.3 CNCF云原生全景图（Trail Map）

CNCF全景图则列举了和云原生相关的产品及服务的完整名单，这1381个项目共同构成了恢弘庞大的云原生世界。整个全景图按照功能分为29个模块，分别归属于9种大的类别（应用定义与开发、编排与管理、运行时、配置、平台、可观察性与分析、Serverless、会员和其它）。值得注意的是其中专门有一种分类是Cards from China，列举了来自中国的145个项目，其中不乏许多大家耳熟能详的知名项目。
从CNCF的理念及野心来看，基于云原生的基础设施正在壮大和蚕食非云的市场，未来极有可能成为整个IT生态事实上的意见领袖和领导者。

4 相关技术及发展趋势

4.1 CNCF云原生全景图详解

首先，我们剥离掉所有单个的技术，仅查看类别（如下图）。图中有不同的“行”，像建筑的不同层，每层都有自己的子类别。最底层提供了构建云原生基础设施的工具。往上，你可以开始添加运行和管理应用程序所需的工具，比如运行时和调度层。在最上层，有定义和开发应用程序的工具，比如数据库、镜像构建和 CI/CD 工具（我们将在后文讨论）。
云原生全景图始于基础设施，往上的每一层都更接近实际的应用程序。这就是每层代表的意思（后面我们会讨论上图右边的两“列”）。下面我们就从最底层开始，逐层进行解析。

4.1.1 供应层（Provisioning）

供应指的是为云原生应用准备标准基础环境所涉及的工具。它包含了基础设施的创建、管理、配置流程的自动化，以及容器镜像的扫描、签名和存储等。供应层通过提供设置和实施策略，在应用程序和平台中构建身份验证和授权，以及处理密钥分发等等的工具，也拓展到了安全领域。

自动化和部署工具：帮助工程师在无需人工干预情况下即可构建计算环境；
容器注册表：存储应用程序的可执行文件；
不同安全领域的安全和合规框架；密钥管理解决方案：通过加密确保只有授权的用户才能访问特定的应用程序。
这些工具使工程师可以编写基础设施参数，使系统可以按需搭建新环境，确保了一致性和安全性。

4.1.2 运行时层（Runtime）

像很多 IT 术语一样，运行时没有严格的定义，且可以根据语境有不同的用法。狭义上讲，运行时是特定机器上准备运行应用程序的沙盒——也就是保障应用程序正常运行所需的最低配置。广义上讲，运行时是运行一个应用程序所需的所有工具。在 CNCF 云原生全景图中，运行时保障了容器化应用程序组件的运行和通信。

云原生存储：为容器化应用提供虚拟磁盘或持久化存储；
容器运行时：为容器提供隔离、资源和安全；
云网络：分布式系统的节点（机器或进程）通过其连接和通信。

4.1.3 编排和管理层（Orchestration and Management）

一旦按照安全和合规性标准（供应层）自动化基础设施供应，并安装了应用程序运行所需的工具（运行时层），工程师就需要弄清楚如何编排和管理应用程序。编排和管理层将所有容器化服务（应用程序组件）作为一个群组管理。这些容器化服务需要相互识别和通信，并需要进行协调。这一层可为云原生应用提供自动化和弹性能力，使云原生应用天然具有可扩展性。

编排和调度：部署和管理容器集群，确保它们具有弹性伸缩能力，相互之间低耦合，并且可扩展。事实上，编排工具（绝大多数情况下就是 Kubernetes）通过管理容器和操作环境构成了集群；
协调和服务发现：使得服务（应用程序组件）之间可以相互定位和通信；
远程进程调用（RPC）：使跨节点服务间通信的技术；
服务代理：服务间通信的中介。服务代理的唯一目的就是对服务之间的通信进行更多控制，而不会对通信本身添加任何内容。服务代理对下面将提到的服务网格（Service Mesh）至关重要。
API 网关：一个抽象层，外部应用可通过 API 网关进行通信；
Service Mesh：某种程度上类似于 API 网关，它是应用程序进行通信的专用基础架构层，提供基于策略的内部服务间通信。此外，它还可能包含流量加密、服务发现、应用程序监控等内容。

4.1.4 应用定义和开发层（Application Definition and Developement)

我们来到了最顶层。应用定义和开发层，顾名思义，聚集了让工程师构建和运行应用程序的工具。上述所有内容都是关于构建可靠、安全的环境，以及提供全部所需的应用程序依赖。

数据库：使应用程序能以有序的方式收集数据；
流和消息传递：使应用程序能发送和接收消息（事件和流）。它不是网络层，而是让消息成为队列并处理消息的工具；
应用程序定义和镜像构建：用于配置、维护和运行容器镜像（应用程序的可执行文件）的服务；
持续集成和持续交付（CI/CD）：使开发者可自动测试代码是否与代码库（应用程序的其余部分）兼容。如果团队足够成熟，甚至可以自动部署代码到生产环境。

4.1.5 贯穿所有层的工具

接下来我们将进入到云原生全景图右侧贯穿所有层的两列。可观察性和分析（Observability&analysis）是监控各层的工具，平台（Platforms）则将各层中不同的技术捆绑为一个解决方案。

4.1.6 可观察性和分析（Observability and Analysis）

为了限制服务中断并降低解决问题的平均时间（MRRT），你需要监控和分析应用层序的方方面面，以便在出现异常时可立即发现并纠正。复杂环境中容易出现故障，这些工具可快速识别并解决故障，从而降低故障带来的影响。由于这一类别贯穿并监控各层，因此它在侧面，而不是嵌入到某一层中。

日志工具：收集事件日志（有关进程的信息）；
监控方案：收集指标（以数字表示的系统参数，例如 RAM 可用性）；
追踪工具：追踪比监控更进了一步，它们监控用户请求的传播，与服务网格相关。
混沌工程（Chaos Engineering）：在生产环境中测试软件的工具，可识别缺陷并进行修复，减少其对服务交付的影响。

4.1.7 平台类（Platform）

仅有存储并不能提供应用程序所需的全部功能。你还需要编排工具，容器运行时，服务发现，网络，API 网关等等。平台覆盖多层，将不同的工具组合在一起，以解决更大的问题。
配置和微调不同的模块使其安全可靠，并确保它利用的技术都能及时更新、所有漏洞都打了补丁，这并不是一件容易的事情。使用平台时，用户不用额外担心这些细节问题。
你可能会注意到，所有的类别都围绕着 Kubernetes 展开。这是因为 Kubernetes 虽然只是云原生景观图这张拼图中的一块，但它却是云原生技术栈的核心。顺便说一下，CNCF 刚创建时，Kubernetes 就是其中的第一个种子项目，后来才有了其他项目。

Kubernetes 发行版：采用未经修改的开放源代码（尽管有人对其进行了修改），并根据市场需要增加了其他功能；
托管的 Kubernetes：类似于 Kubernetes 发行版，但是由提供商托管；
Kubernetes 安装程序：自动执行 Kubernetes 的安装和配置过程；
PaaS/容器服务：类似于托管的 Kubernetes，但是包含了一套更广泛的应用部署工具（通常是来自云原生景观图）。

4.1.8 小结

在每个类别中，针对相同或相似的问题，都有不同的工具可选择。有一些是适用于新现实的预云原生技术，还有一些则是全新的。区别在于它们的实现和设计方法。没有完美的技术符合你的所有需求。大多数情况下，技术受设计和架构选择的限制——始终需要权衡取舍。
在选择技术栈时，工程师必须仔细考虑每种能力和需要权衡取舍的地方，以确定最合适的选项。虽然这样会让情况变得更复杂，但在选择应用程序所需的最适合的数据存储、基础设施管理、消息系统等方案时，这样做是最可行的办法。现在，构建一个系统比云原生之前的时代容易多了。如果构建恰当，云原生技术将提供更强大的灵活性。在现如今快速变化的技术生态中，这可能是最重要的能力之一。
详细介绍云原生全景图的每一层，见 https://cloud.tencent.com/developer/article/1851558

4.2 云原生核心概念

下面的表格里代表性的列举了云原生技术层的几个领域及相关项目。

4.2.1 DevOps与CI/CD

DevOps
DevOps（Development & Operations，开发和运维）是09年提出来的概念，但一直没有太火。直到14年，容器与微服务架构的提出，DevOps才得到了快速的发展。DevOps不单是一个实现自动化的工具链，而是组织、流程与技术的结合。组织上强调全栈团队、团队特性专一、团队自治；技术上打通开发与运维；流程上强调端到端、可视化、灰度升级、A/B测试等。
持续集成
持续集成（CONTINUOUS INTEGRATION，CI）指的是开发人员频繁的（一天多次的）将所有开发者的工作合并到主干上。这些新提交在最终合并到主线之前，都需要通过编译和自动化测试流进行验证，以保障所有的提交在合并主干之后的质量问题，对可能出现的一些问题进行预警。持续集成的核心在于确保新增的代码能够与原先代码正确的集成。
持续交付
与持续集成相比，持续交付（CONTINUOUS DELIVERY，CD）的侧重点在于交付，其核心对象不在于代码，而在于可交付的产物。由于持续集成仅仅针对于新旧代码的集成过程执行了一定的测试，其变动到持续交付后还需要一些额外的流程。与持续集成相比较，持续交付添加了测试Test->模拟Staging->生产Production的流程，也就是为新增的代码添加了一个保证：确保新增的代码在生产环境中是可用的。
持续部署
持续部署（CONTINUOUS DEPLOYMENT）指的是通过自动化部署的手段将软件功能频繁的进行交付。与持续交付以及持续集成相比，持续部署强调了通过自动部署的手段，对新的软件功能进行集成。同持续交付相比持续集成的区别体现在对生产的自动化。从开发人员提交代码到编译、测试、部署的全流程不需要人工的干预，完全通过自动化的方式执行。这一策略加快了代码提交到功能上线的速度，保证新的功能能够第一时间部署到生产环境并被使用。

4.2.2 微服务、API管理与集成

微服务
微服务（Microservice）概念最早出现于2012年，2015年以后受到越来越多的关注，并且逐渐开始流行开来。其中著名技术大神Martin Fowler功不可没，他于2014年发表的一篇博客《Microservices: a definition of this new architectural term》（微服务：新技术架构的定义）清晰的定义和阐述了微服务概念。
微服务架构将单体应用，按照业务领域拆分为多个高内聚低耦合的小型服务，每个服务运行在独立进程，由不同的团队开发和维护，服务间采用轻量级通信机制，如HTTP RESTful API，独立自动部署，可以采用不同的语言及存储方式。微服务体现去中心化、天然分布式，是中台战略落地到IT系统的具体实现方式的技术架构，用来解决企业业务快速发展与创新时面临的系统弹性可扩展、敏捷迭代、技术驱动业务创新等难题。
API管理与API集成
微服务相关的两个具体领域，API管理与API集成。

全生命周期API管理
API网关：微服务基础设施
Kong：API网关独角兽
RapidAPI：全球最大API市场
Mulesoft：API集成/iPaaS/API管理领头羊

微服务2.0：服务网格与Serverless
微服务2.0的服务网格（Service Mesh）应运而生。服务网格这个词最早由著名开源服务网格项目Linkerd所在的Buoyant公司CEO William Morgan所提出。按照他的定义，服务网格是一个软件基础设施层，用于控制和监视微服务应用程序中的内部、服务到服务的流量。
Serverless是一种构建和管理基于微服务架构的完整流程，它与传统架构的不同之处在于，完全由第三方管理，由事件触发，存在于无状态、暂存的计算容器内。Serverless相关的重要概念包括FaaS（Functions as a Service，函数即服务）。开发者把函数上传到云厂商的FaaS平台，函数只在被请求时才实例化运行，然后被销毁，其它时候不占用任何服务器资源，完全实现按需使用，大幅度降低了服务器占用和成本。

4.2.3 容器与Docker

虚拟化与容器
虚拟机虽然可以隔离出很多“子电脑”，但占用空间大，启动慢，虚拟机软件可能还要花钱（例如VMware）。而容器技术恰好没有这些缺点，它不需要虚拟出整个操作系统，只需要虚拟一个小规模的环境（类似“沙箱”），启动时间很快，几秒钟就能完成。而且，它对资源的利用率很高（一台主机可以同时运行几千个Docker容器）。此外它占的空间很小，虚拟机一般要几GB到几十GB的空间，而容器只需要MB级甚至KB级。虚拟机和以Docker为代表的容器都是虚拟化技术，不过容器属于轻量级的虚拟化。
Docker
而Docker与传统的Linux容器也并不完全一致。Docker技术最初是建立在LXC技术之上的，大多数人都把LXC技术与传统的Linux容器联系在一起，尽管后来它已经摆脱了这种依赖性。LXC作为轻量级虚拟化很有用，但它没有很好的开发人员或用户体验。Docker技术带来的不仅仅是运行容器的能力，它还简化了创建和构建容器、加载镜像和镜像版本控制等过程。传统的Linux容器使用可以管理多个进程的init系统，这意味着整个应用可以作为一个整体运行。Docker鼓励将应用程序分解为它们各自的进程，并提供了实现这一点的工具，这种粒度有不少优点。

4.2.4 Kubernetes与容器编排之战

容器编排与Kubernetes
在单机上运行容器，无法发挥它的最大效能，只有形成集群，才能最大程度发挥容器的良好隔离、资源分配与编排管理的优势。所以企业需要一套管理系统，对Docker及容器进行更高级更灵活的管理，按照用户的意愿和整个系统的规则，完全自动化的处理好容器之间的各种关系，这叫做编排（Orchestration）。
Kubernetes是基于Docker的开源容器集群管理系统，为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容等整一套功能，因为容器本身可移植，所以Kubernetes容器集群能跑在私有云、公有云或者混合云上。

4.3 发展趋势和未来展望

4.3.1 机遇和挑战

机遇
每一次IT产业架构的变革都会带来巨大的机遇和行业洗牌的挑战。过去的三四十年间，IT业经历了多次重大的变革，包括20世纪七八十年代从大型机向小型机的转移、九十年代C/S架构的普及，以及21世纪初互联网的兴起，先后造就了IBM、思科、惠普、Oracle、EMC、SAP等巨头企业。
历次IT技术革命还有个共同特点：无论原有的基础软硬件公司此前有多么牢不可破的垄断地位，一旦不能符合新的IT技术变革的趋势，洗牌在所难免。
而云原生是一种理念和架构，用于以针对云环境优化的方式组装上述所有基于云的组件。因此云原生也是一个目的地：对于那些希望实现基础设施和流程现代化，甚至组织文化现代化的企业来说，最终的目标是仔细选择最适合其具体情况的云技术。
发展趋势
从统计数据和发展趋势来看，云原生被接受的程度和普及速度正在大大加快，例如下图显示，自从2016年以来容器的使用量每年都在快速上升。IDC预计，到2022年90%的应用程序将采用微服务架构和第三方代码，35%的生产应用程序将诞生于云端。由于容器和敏捷方法的采用，预计2018-2023年间将诞生5亿个新应用程序。由数字化转型，以及接受和采用新技术的需求驱动，云原生将更深入地渗透到大型企业组织中。这意味着云原生技术和方法可能会遵循敏捷和DevOps的模式，越来越多地吸引更多的利益相关者，包括管理者和业务线领导人，在未来几年内覆盖一半或更多的组织。

云原生安全领域
据CNCF统计，采用容器技术的挑战中，开发团队面临的文化挑战、安全性、复杂性、就绪性和监控分别排在前五位。

在云原生架构中，安全问题显得尤其突出的原因有以下几点：
1、快速迁移到云原生架构对企业安全状况和运营产生了深远的影响。在容器、微服务和编排框架的世界中，以持久“状态”运行在“服务器”上的“应用程序”的概念已经过时。现在，该应用程序或服务是一个分布式系统，由多个组件组成，这些组件运行在数量可变的节点上，处于几乎恒定的变化状态。依赖于机器隔离和可预测的系统状态的传统安全控制是无效的。对服务到服务的通信视而不见的安全策略以及缺乏水平可扩展的控件，根本无法跟上当今微服务应用程序的步伐。
2、随着企业将工作负载从数据中心转移到AWS、Google Cloud Platform和Microsoft Azure，它们已经改变了购买安全性的方式。他们需要独立于平台的安全工具，这样就不会被绑定到特定的云平台中。
3、复杂系统可以创建大量的警报和事件日志，这会是一项惊人的任务。安全项目被堆积如山的繁忙工作所淹没，分析师们疲惫不堪。随着分析师对惊人的数据量变得不敏感，真正的问题就从他们的手指间溜走了。
4、DevOps是一种协作方法，它将开发人员和IT操作统一起来，以加快应用程序的构建、测试和部署，它也影响了IT安全。当开发人员可以直接将他们的应用程序部署到生产服务器上，因为业务敏捷性需要它时，他们就不能停下来找出安全问题。DevOps提供了一种完全不同的安全方式，安全自动化有很多机会。
和云原生安全相关的初创企业
1、Capsule8（B轮）
2、Aqua Security（C轮）
3、Twistlock（被收购）

4.3.2 云原生2.0（华为）

随着云原生技术的成熟和市场需求的升级，云计算的发展已步入新的阶段。云原生2.0时代已经到来
从技术角度看，以容器、微服务以及动态编排为代表的云原生技术蓬勃发展，成为赋能业务创新的重要推动力，并已经应用到企业核心业务。从市场角度看，云原生技术已在金融、制造、互联网等多个行业得到广泛验证，支持的业务场景也愈加丰富，行业生态日渐繁荣。
云原生2.0，企业云化从“ON Cloud”走向“IN Cloud“，生于云、长于云且立而不破
企业新生能力基于云原生构建，使其生于云；应用、数据和AI的全生命周期云上完成，使其长于云；同时，既有能力通过立而不破的方式继承下来，并与新生能力有机协同。
智能升级新阶段，赋能“新云原生企业”
云原生2.0是企业智能升级的新阶段，企业云化从“ON Cloud”走向“IN Cloud“，成为”新云原生企业“。新生能力与既有能力立而不破、有机协同，实现资源高效、应用敏捷、业务智能，安全可信。
云原生 IN 基础设施
华为云基于“云原生 IN 基础设施”的理念，打造了以应用为中心的云原生基础设施。
目前，华为云云原生基础设施包含了云容器引擎CCE、云容器实例CCI、容器镜像服务SWR、智能边缘平台IEF、多云容器平台MCP、应用编排服务AOS等8大核心容器产品，并以此为基础构建了云原生裸金属、云原生高性能计算、云原生混合云、云原生边缘计算四大解决方案，满足企业业务智能升级过程中，对高性能基础设施、分布式业务架构、完善的云原生应用生态的诉求。

4.3.3 未来发展趋势

1、运维继续下沉，服务网格将成为主流，Serverless逐步推广
云计算的一个发展方向就是运维下沉，将和业务无关的管理功能和运维工作尽量下沉到基础设施中，应用可以聚焦在业务能力的开发和运营。这个趋势演化的过程，影响了云计算的发展方向。从一开始的虚拟化，到IaaS，到PaaS都是将应用系统的部分运维职责交给平台运维的过程。
2、软硬结合，解决虚拟化性能问题的利器
随着云计算的发展，虚拟化技术越来越多的被使用，从计算虚拟化到存储虚拟化到网络虚拟化。虚拟化技术带来了很多的好处，虚拟化是基础设施服务化的基础，通过虚拟化，可以实现基础设施即代码，大大提升了资源的可管理性和自动化程度。但是虚拟化带来了另外一个问题，就是性能的损耗和软件进程之间的相互影响问题。
为了解决这两个问题，目前一个解决思路就是软硬结合，讲云平台的管理进程，如调度管理，网络的虚拟交换机，存储的虚拟存储网关从操作系统进程中剥离出来，让这些进程跑在专门设计的服务器板卡上，这些板卡专门设计的，通常含有定制化的芯片（FPGA），可以进行编程，从而可以保持虚拟化话的优势的同时，使的管理进程和业务进程隔离，避免相互影响；同时由于通过定制芯片（如FPGA）来处理，性能会有很大提升，大大降低了虚拟化的损耗。
3、容器虚拟机进一步融合
容器和虚拟机的优势和劣势，从容器技术诞生的那天起就一直在争论。容器轻量化，良好的封装能力和部署简便的特点，特别是在Kubernetes出现后，大有取代虚拟机的气势。但是在处理重应用（如关系型数据库，大数据等）的这点上，容器技术显得有些力不从心。在这种情况下，如何实现容器技术和虚拟化技术的融合，发挥两者的长处，成为云计算的一个发展课题。目前的技术主要有三种，一种是容器虚拟机的混布；一种是轻量级虚拟机；最后是安全容器。
4、运维：可编程的Linux内核
由于引入了可扩展的Berkeley数据包过滤器（Extended Berkeley Packet Filter，eBPF），Linux内核在使用方式上有了重大变化。
5、开发：Rust逐渐替代C++
数十年来，我们的操作系统和其他重要的基础架构软件一直使用C或C ++编写，但是，如今，越来越多的系统架构师得出的结论是，由于用不安全的方式来处理内存和其他因素，要完全安全地保护用这些语言编写的程序从根本上来说是困难的。
所以最近，越来越多的拥护者选择了新的语言Rust，它不仅具有C/C ++的速度，而且还具有编写安全的应用程序所必需的组件。在2020年的AllThingsOpen虚拟会议上，微软云开发倡导者Ryan Levick 解释了为什么Microsoft逐渐改用Rust来构建其基础结构软件，而不再使用C/C ++。并鼓励其他软件行业巨头也考虑相同的问题。