华为和中国信通院联合发布云原生2.0白皮书-内容解读

今天阅读和整理下今日华为和中国信通院在8日的华为云TechWave技术峰会上联合发布的《云原生2.0白皮书》相关内容。对于技术峰会的相关内容以及该白皮书的下载地址可以参考我前面一篇文章的详细说明。

1.云原生发展历程

云原生的技术理念始于Netflix 等厂商从 2009年开始在公有云上的开发和部署实践。 2015 年云原生基金会 CNCF 成立标志着云原生从技术理念转化为开源实现，并给出了目前被广泛接受的定义是：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

对于Cloud Native翻译为云原生，是Matt Stine提出的一个概念，它是一个思想的集合，包括DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）、康威定律（Conways Law）等，以及根据商业能力对公司进行重组。Cloud Native既包含技术（微服务，敏捷基础设施），也包含管理（DevOps，持续交付，康威定律，重组等）。

因此云原生是一系列Cloud技术、企业管理方法的集合。

对于CNCF基金会，已经我国贡献给CNCF基金会的一些开源项目介绍，我在前面专门写过一篇文章可以参考，具体如下：

一文了解我国贡献给CNCF云原生基金会开源项目

商业解决方案创新

开源项目的不断更新和逐步成熟，也促使各企业在 AI、大数据、边缘、高性能计算等新兴业务场景不断采用云原生技术技术来构建创新解决方案。

早在 2017 年 , 就有大量企业尝试使用容器替换现有人工智能、大数据的基础平台，通过容器更小粒度的资源划分，更快的扩容速度、更灵活的任务调度，以及天然的计算与存储分离架构等特点，助力人工智能、大数据在业务性能大幅提升实力的同时，更好地控制成本。

也就是说就是是商业场景和业务需求推动了云原生发展，还是说云原生技术推动了商业创新，实际上很难说谁先谁后，而是一种互相推动的过程。

如果从传统企业内部IT架构和信息化发展来说，基于业务敏捷性的需求，基于后续IT基础设施弹性扩展的需求，引入了类似微服务，容器，持续集成等关键技术和最佳实践，而这些都是推动企业上云或构建云原生技术平台的关键。

对于远行，对于我们团队来说，我在前面谈过我们自己的云原生技术平台和解决方案，则更多的是基于我们大型集团IT架构转型实践和平台建设实践的总结。

企业IT建设进入云原生阶段

白皮书里面提到企业IT建设和数字化转型的三个阶段，即从最早的服务器阶段，到云化阶段，再到云原生阶段。云化阶段可以理解为我们传统的面向资源服务提供过IaaS云服务，而到了云原生阶段，则更多的是以服务为提供的PaaS平台阶段。

在云化阶段仅仅是实现资源集中化和自动化，而到了云原生阶段重点则是实现应用自动化。这个我在前面也整理过一个演进图如下：

当时我画的第二阶段还是强调了存在部分基于虚拟机调度的传统PaaS平台内容，同时各种类似数据库，消息，缓存等共性技术服务能力没有实现完全的云服务化。而到了云原生阶段可以看到，整个PaaS平台已经演进为基于K8s+Docker的容器云PaaS平台，同时各种技术服务能力大量下沉，以服务化方式提供，上层应用构建彻底的微服务化。

为了更好地衔接上层微服务的开发和底层容器云平台，技术服务平台。需要基于DevOps最佳实践和思路提供一套完整的覆盖软件研发生命周期的过程支撑平台。

在书里面提到：

云原生阶段，企业的关注点从以资源为中心转移到以应用为中心，包括应用敏捷交付、快速弹性、平滑迁移、无损容灾等。因此，企业开始考虑如何将基础设施与业务平台融合，为业务应用提供标准的运行、监控、治理平台，并将业务的通用能力下沉到平台侧，更好地帮助企业实现应用的自动化。

以应用为中心，开启云原生2.0

对于云原生2.0时代，白皮书有一段描述：

随着企业数字化转型的深入，企业需要充分享受云计算带来的红利，需要让业务能力生于云、长于云，由现在的ON CLOUD 进阶到 IN CLOUD，同时基于云构建的新生能力与既有能力有机协同、立而不破。生于云是指基于云原生的技术、架构和服务来构建企业应用，长于云是指充分利用云的优势来助力企业应用和业务发展，将企业的数字化建设、业务智能升级带入新阶段，我们称之为云原生 2.0 时代。

华为强调的是云原生2.0，实际上不存在2.0的说法，这些内容本身就是云原生的核心。那么云原生的核心究竟是什么？

在前面文章谈到过，云原生的一个核心内容就是云平台服务的能力不断的从资源层到服务层进行上移，在上移的过程中不断的抽象和标准化各种服务能力。如果从应用构建角度来说，就是对于应用构建中，只要和业务无关的共性技术能力都应该下沉到云平台，变成一种统一的技术服务能力，然后开放给上层应用使用。

抽象和标准化是云原生的一个关键本质。

那么如何进一步理解从面向资源到面向应用？

面向应用简单来说就是一个应用从你开始做整体规划设计和需求的时候，最好就是生在云上的，基于云平台提供的基础支撑能力和服务进行的。

我们可以回顾下在传统模式下是如何使用来说阿里云或华为云服务的，简单来说更多的场景是申请云平台的虚拟机资源，拿到虚拟机后再将最终开发完成的应用部署到虚拟机里面去。当然拿到的虚拟机裸机你还需要自己去安装数据库，安装类似Tomcat，Redis，ActiveMQ等各种中间件。

简单来说就是云平台和你的交互已经是软件开发生命周期的后期，而云平台希望的则是从一开始就和你交互。如果没有一开始就交互，往往会发现云平台很多能力在后期你无法使用上，你使用了云平台的虚拟机，你自己可以去想下，你要去做计算资源的弹性动态扩展往往无法实现，这个还得你手工去做，比如手工申请新的虚拟机，自己去做集群挂接等。

面向应用的重点就是云平台提供更多的能力和服务并及早地介入到软件开发前期过程，这个介入本身又包括了两个关键点。

其一是提供一套从需求就开始的开发过程管理工具，同时提供覆盖完整的软件生命周期过程的DevOps支撑能力，让你从需求一开始就上来，将持续集成和持续交付用起来。即云平台不再是简单的只管结果，而是希望你过程也上来。

其二是在你进行系统建设的时候，在前期的规划和方案设计阶段，云平台和服务能力就介入进来。你在构建应用的时候可以使用云平台哪些服务能力，注意是服务能力而不是虚拟机资源，比如我们常说的数据库，中间件，消息，缓存等，这些你在前期就要规划好。如果你前期就没有规划好，你在前期就是按照申请虚拟机，自己装数据库来规划的，那么在后期你如何平滑的切换到可以直接使用云平台提供的数据库即服务能力？

云原生核心重点是抽象和重心上移，也就是说在云平台提供的所有产品和服务过程中，能够不用资源(虚拟机）的尽量不要用资源，而是申请和使用服务。一个完整的PaaS层应该做到屏蔽虚拟机这层，虚拟机对最终的用户不可见。

白皮书里面给出了一个云原生2.0参考架构，但是这个参考架构太想把华为云相关产品和服务全部装进去了，导致整个架构脉络和分层并不清楚。简单来说就是看了这个参考架构，你对云原生整体核心要素的理解可能更加迷糊。

远行我们自己规划和建设云原生技术平台，也给大型集团建设和实施DevOps，这个我在前面也分享了我们自己的云原生技术平台架构。基于我前面对云原生核心要素的进一步描述，我这里不给出云原生的参考架构，而是进一步构图说明云原生核心要素间的关系。

在该构图中，仍然是按资源-服务-应用三层进行。但是云原生整个技术解决方案不包含具体的应用，这里的应用更多是指云原生平台提供的应用支撑能力。而这个支撑能力应该是覆盖整个应用开发全生命周期的能力支撑。从开发框架和环境，低代码开发平台，ServerLess这些开发态支撑能力；到围绕DevOps为核心的持续集成和持续交付支撑，再到围绕AIOps为核心的智能化运维和监控服务能力提供。

对于纵向则体现安全和治理两个方面内容。安全本身包括安全规范体系和安全产品服务；治理同样包括治理规范体系和管控治理平台能力提供。

2.云原生基础设施

经过十几年的发展，云计算作为数字化转型的重要基础设施，已经由“面向云迁移应用”的阶段演进到“面向云构建建设”的阶段，即由“以资源为中心”演进到“以应用为中心”的云原生基础设施阶段。

高效算力，软硬协同的资源平台

既然谈的是基础设施，那么自然更多的是谈的资源平台层面的内容。而对于资源层一个最大的变化就是从虚拟机这种逻辑资源变化为容器这种容器资源。

对于容器资源的本身存在两种方式，一种就是先申请虚拟机，然后在虚拟机中再划分容器资源；另外一种就是裸金属架构，直接在物理机资源上创建和管理容器资源。对于第一种情况两层堆叠，往往在性能损耗，IO上都会存在一定的问题。因此当前云服务商来说为了提升效率，在云原生2.0时代，基于裸金属搭建容器服务成为一些对性能和实例隔离性要求较高用户的选择。

从这个观点来看，实际并不建议你申请云服务商的虚拟机，再构建自己的容器资源池，而是直接使用云服务商的容器服务能力。容器本身是资源，这种资源的服务能力当前可以通过类似k8s的标准API接口对外开放，也就是说通过接口服务你能够完成对容器的全生命中周期管理能力。

多元化算力支持。

随着人工智能、 5G、 HPC、边缘计算等新业务的逐渐落地和普及，对算力多样化提出了更高的要求。针对特定的业务场景采用专有的硬件可以提供更好的计算效能，越来越多的异构计算硬件如 GPU、 FPGA、 ASIC、 SoC 等被应用到了专有的领域。云原生 2.0 时代，基础设施的特征之一就是向下统一管理和支持各种异构硬件，向上屏蔽底层多种硬件的差异性。

这个确实是在新技术时期带来的一个大变化，也就是在面对特定业务场景高性能，低时延，高吞吐量各种要求的情况下，底层资源应该支持各种多元化的硬件。类似我们采用SSD存储提升IO性能，通过GPU硬件引入提升图像，视频处理性能等。

特别是在AI人工智能快速发展下，引入GPU硬件资源作为关键算力，成为一个重点。

泛在计算和统一计算，让应用有机协同

这部分实际在将跨云协同，跨云融合。这个跨云不仅仅是单个云服务商的多个云数据中心，更是跨阿里，华为，腾讯等多个云服务商；还包括了跨企业内部私有云和公有云之间的混合云管理和协同。多云管理和跨云融合是一个大趋势。

我们先看下书里面的一小段描述如下：

随着企业生产环境容器集群规模爆发式增长，越来越多的企业核心业务切换到容器，容器技术需要应对的场景也越来越复杂，单数据中心的强硬基础设施性能、单厂商跨 Region 的 Serverless 资源无感知调度，虽然可以满足企业大规模业务部署的诉求，但在某些场景下，如容灾、跨云迁移等，单独的云厂商已经无法满足用户需求。因此跨云服务商的业务部署能力成为客户重点关注对象，以满足业务连续性、降本增效等场景诉求，如：

1.解除厂商锁定，应用可以灵活地部署在不同云供应商或本地 IDC的集群中，不再依赖某一家云服务厂商；
2.跨云业务容灾，在云服务商发生故障时可以快速切换到其他的云服务商或者混合云环境中去，实现业务的容灾管理；
3.跨云弹性伸缩，利用公有云超大资源池应对短期流量高峰场景，大幅提高业务的承载能力；
4.公私云分离部署，部分核心业务部署在私有云环境，满足行业监管和数据安全要求，普通业务部署在公有云上，利用公有云强大的计算能力，同时节约成本。

在远行科技自己的DevOps产品规划中，我们很早就提出了基于DevOps来构建一个多云管理平台，当时我整理了一页PPT如下：

当然跨云场景还包括了云边协同和云边融合，对于物联网云平台，边缘计算服务器等是华为另外一个重要能力点和差异化竞争优势。这个实际在我前面文章谈华为发力智慧矿业，智慧电网，智慧家庭等各个方向的原因。

包括就在前几天华为推出的面向智慧家庭领域，基于鸿蒙生态的全屋智能解决方案，也是云边协同和云边融合的的一个典型例子。

智能调度和敏捷运维

在以应用为中心的云原生 2.0 阶段， Kubernetes + Operator 以其良好的可扩展性及较高社区活跃度，已经成为各个企业的主流选择，将极大降低云原生应用全生命周期管理的难度，加快企业业务的云原生化升级。

随着企业云原生应用数量的快速增加，对应用服务的流量治理、运行监控、访问安全以及发布等能力诉求也相应提升。

在云原生 1.0 阶段所流行的以 SDK 方式进行微服务治理框架的模式，在云原生 2.0 的阶段，逐步被非侵入式的微服务治理解决方案取代。 Istio 作为现在主流的非侵入式微服务治理框架，为用户提供了包括负载均衡、熔断、限流等多种治理能力。但原生的 Istio 无法满足用户在生产环境中的需求，还需提供以下几种能力，以提高用户对应用的治理能力：

1.服务灰度发布
2.服务网格化
3.服务流量治理

为何后期的服务治理和运维如此重要？

简单来说就是云原生阶段应用的开发基本微服务化，原有的单体拆分得更细化，其次就是调度基于容器，一个微服务在动态运行期间也可能动态调度启用几十个甚至更多的容器节点。因此可想而知，云原生阶段面对的后期运维管控和微服务治理难度和复杂度远远增加。

一个公有云服务商，如果后期的运维管控和微服务治理能力跟不上，那么对于应用开发商这些客户来说就是灾难。特别是在从资源层走到服务层后。

在传统资源层阶段，我们还可以自己登陆到虚拟机上面查看具体的系统日志或错误日志，但是到了PaaS平台和服务化阶段，虚拟机或容器对我们不可见，容器本身也存在生命周期不固定各种问题，因此必须由云服务商提供一整套的运维支撑工具，微服务治理管控工具。

对于基于服务网格的微服务治理，在在前面写过文章：

谈ServiceMesh微服务治理在云原生解决方案中作用

大家可以参考。

简单来说基于ServiceMesh的思路，一个是彻底的去中心化，一个就是真正做到无侵入，对应用开发不可见，也不需要应用在开发阶段引入SDK包，最好也做到连代码中的各种增加注解这种要求也没有。

那么这样开发完成的微服务应用，完全就能够方便在多个云平台交付和部署，而不是受到某个云平台的制约。所有对于当前类似华为云的ServiceComb微服务开发框架，阿里对应的定制后的微服务开发框架等，尽量少用。就用标准的SpingCLoud框架，不引入任何的公有云服务商个性化的东西。

3.云原生应用敏捷

应用现代化已成为业界的热点，但各厂商对应用现代化的理解不同。AWS 认为，应用现代化包括 Ownership 文化的构建、微服务化、数据管理、计算、敏捷开发、服务器运维模式、利用程序化护栏等。

谷歌认为，应用现代化应实现基础架构与应用解耦、各个团队解耦、开发与运维解耦、安全与开发和运维解耦等。微软认为，在应用模式方面上云、在开发实践方面采用 DevOps、在技术选择方面选择最适合的开发语言、框架和工具，是实现应用现代化的核心。

华为基于服务数百万企业客户的经验沉淀，以及结合自身 30 年的数字化实践总结，提出“基础设施现代化、应用架构现代化、开发运维现代化、治理运营现代化”这四个现代化是企业走向应用现代化的关键，让企业走上以业务和应用为中心的敏捷道路，重塑应用的商业价值。

这部分内容实际是在华为云ROMA应用使能平台里面。华为ROMA应用使能平台实际是协助企业传统应用上云迁移，新应用的生在云上起到关键的作用。

最底层可以看到实际是解决两个方面的问题。

其一是新应用从需求，开发，测试，部署，交付的研发全生命周期流程。其二是仅仅遗留应用之间的集成问题，叫ROMA Connect集成能力。同时在这块加入了低代码开发平台的能力。上层支持API，微服务，ServerLess，小程序，IOT，AI应用等各种开发场景。

中间这层叫ROMA Service Core应用使能核心服务，可以理解为整个云原生PaaS平台中的技术服务能力提供，来说数据库，消息中间件，缓存，CT能力，IOT能力等各种技术服务都可以纳入到这层。当你是构建一个完整的厚PaaS云原生平台的时候，这层是必须的。

最上层可以理解为传统的能力开放平台，也可以理解为我在SOA相关文章里面经常谈到的服务资产库，服务目录库。

ROMA平台既要做到支撑新应用的全流程开发，集成和交付；也要做到支撑老应用，传统IT架构的集成，重构和迁移。

应用架构的现代化

应用的架构现代化是指使用微服务、 Serverless 等技术，将应用拆分为能独立运行，满足客户需求的独立模块，实现应用的高可用、弹性扩展。应用架构现代化是应用走向敏捷开发的基础。

对于应用架构的现代化，微服务是一个核心，谈单体拆分和微服务方面，我前面文章已经很多，不再这里展开继续描述。因此只谈下另外两个点。

其一是 Serverless无服务器化架构，当面临企业级应用开发的时候实际上要完全的Serverless化相对困难，其核心原因是企业应用开发不是简单的基于技术服务API的组装就能够完成，更多的还涉及到共性业务服务API的组装，那么你共性业务服务API的能力积累和下沉就是必须。一个企业如果核心的业务中台服务能力也全部迁移上云，并以开放的API服务方式提供出来，那么实现ServerLess就更加容易。

当前低代码开发是一个很火的方向，而对于公有云服务商来说，个人理解重点不要放在零代码开发上面，而是真正放在低代码开发上。公有云的低代码开发简单来说就是基于DevOps+ServerLess+共性API能力进行的一个组合。

其次对于应用本身的高可用、弹性扩展能力，一个重要思路转变就是从使用资源到使用服务。如果你是申请的虚拟机自己，自己安装环境部署软件，那么后续应用的高可用性，弹性扩展都要你自己去考虑。但是如果你申请的是数据库服务，消息服务，那么这个服务本身云平台有义务保证其高可用和可扩展，也就是说这个不需要应用去考虑了。

开发运维现代化提升交付效率

这里的重点即是DevOps研发运维一体化能力了。

数字化时代，应用的数量爆炸性增长，应用的迭代速度越来越快，而随着微服务架构的普及，现代的应用开发必定是多团队跨地域的并行开发，每天 10 万级以上的 CICD 流水线并行执行将成为企业常态。而当前代码的抽象程度不高，软件交付过程未标准化，应用构建部署人工执行占比居高，开发和运维的“混乱之墙”都严重制约了应用敏捷交付的效率，同时也带来客户对于应用交付质量和安全的担忧。传统的应用开发和交付模式需要转变为以 DevOps 为核心的开发运维一体化模式，来加速软件交付速度，同时抽象化、模板化、自动化、智能化、立体运维是开发运维现代化的主要特征。

在这里摘录白皮书里面对于抽象化和自动化的描述如下：

抽象化：在代码中抽取出与业务逻辑无关的基础性的公共代码，使用代码框架（也称为脚手架或胶水代码）和与之匹配的研发工具链来封装这部分代码，供其他服务调用。框架和工具中应内置安全、性能、部署等最佳实践，让开发人员尽可能只关注业务逻辑，花更多的时间在写业务相关的代码上，减少写公共代码所花费的时间。

自动化：采用 DevOps 实现开发的自动化，可以使软件的生产交付过程变成可复制、可批量化的生产产流水线。 DevOps 持续集成（ CI） / 持续交付（ CD）作为自动化的最重要实践，已经让众人受益多数企业从中获益。企业的流程、治理、安全（ DevSecOps）等能力也需要内嵌在里面。 CI/CD 中让CI/CD 自动化执行的过程中也执行了企业的流程和安全检查，进一步提升了交付效率。

就远行科技来说，我们也正好是在这两个方面努力，在抽象化方面对微服务开发框架和环境进一步定制和完善，并开发类似自定义表单设计器等低代码开发平台能力。在自动化方面则是构建DevOps过程支撑平台，通过DevOps流水线打通整个研发生命周期。

治理运营现代化

据 Gartner 预测，到 2025 年 90% 的现有企业应用仍将继续使用，而随着数字化转型的深入，业务应用系统的增多，系统间相互割裂和缺乏交互，又容易导致应用间出现信息孤岛。企业的新老应用并存、业务在不同环境、多云部署等是企业应用部署的常态。治理运营现代化旨在利用云的敏捷性，实现新生应用和现有应用的有机协同，立而不破，构建可平滑演进的企业 IT 架构；通过数字资产的复用性，简化企业应用开发的复杂度，降低试错成本和风险，发挥新老应用和资产的最大价值。

对于白皮书里面提到的治理运营主要包括如下几点：

1.微服务治理：侵入方式，或ServiceMesh非侵入方式。
2.应用融合集成：跨云，跨设备，跨异构数据
3.API治理：API驱动，全生命周期管理
4.多云协同：混合云，云边协同
5.资产沉淀和运营：能力开放，数据治理

对于微服务治理，我前面专门写过文章，白皮书里面谈到的A的I治理，应用融合集成等都可以纳入到微服务治理大范畴。

具体可以参考下面这篇文章：

从SOA治理到微服务治理，对整体框架构建的再思考

今天看了白皮书后，触发一些新的思考，即就整个云原生解决方案，就企业上云迁移这件事情来说，整个治理的范畴比微服务治理更大。

也就是说这个治理应该是覆盖软件过程，底层云基础设施资源，云服务，集成协同，后期运维管控，沉淀的数据的数据治理，安全等多个方面的内容。只有这样才能够形成一个完整的云原生治理框架。

云原来完整治理框架等后续思考清楚后再进行输出。

简单来说，就是如果把云原生整个治理框架想清楚了，那么就一定形成了一套完整的可落地实践的，指导传统企业上云，传统IT架构微服务化转型的方法论。

4.云原生产业生态

云原生产业生态逐渐完善，产业链条趋于精细，分工和协作成为主流。云原生的理念不断丰富、落地、实践，进入了快速发展期， Gartner 预测，到 2024 发达国家中有 75% 大型企业将在业务应用中部署容器 。

根据《中国云原生用户调查报告（ 2020）》数据显示， 43.9%2 的用户已在生产环境中采纳容器技术，超过七成的用户已经或计划使用微服务架构进行业务开发部署。

简单来说云原生是一个大产业，需要构建的是业务和技术生态联盟，拿华为云来说核心是云产品和服务能力提供，但是协助传统企业IT架构转型和准备迁移上云是一个无法标准化的事情。也就是说需要基于企业实际的业务和IT现状，根据企业数字化转型目标来制定科学，合理的IT架构规划，上云迁移规划。

对于远行科技来说，实际上多年前就做过大型的IT咨询归类项目，本身又长期专注在SOA和云计算领域，提供相应的基础技术平台和服务设施，包括我们最近推出的面向传统企业数字化转型的微服务+DevOps+容器的云原生解决方案服务等。

因此在这块我们有充分的技术和经验积累，简单来说可以为企业提供：

当前企业的业务和IT现状诊断，问题和差距分析
给出企业数字化转型的发展演进路线，整体业务架构，数据架构，应用和技术架构规划
企业业务中台建设和数据中台建设规划思路和发展演
微服务和技术平台的搭建，选型，DevOps的成熟度评估等
企业IT架构上云规划，混合云管控治理规划

而文中谈构建生态合作伙伴也谈到了需要引入软件集成商，咨询和交付服务商两个角色，对于这两个角色白皮书里面的描述如下：

软件集成商：具备系统集成资质，有一定的客户基础和方案整合能力，能够为企业提供优质的云原生解决方案和服务。软件集成商依托自身在云原生领域的经验积累，可灵活地根据客户业务需求，提供定制化个性化的解决方案，协助企业实现从需求到方案、从方案到架构、从架构到落地的云原生改造全链路闭环。软件集成商为企业的云原生改造需求提供了完备的设备方法论与成熟的配套服务，有助于提高企业信息化智能化水平，强化创新竞争力。

咨询和交付服务商：企业在使用云原生技术进行业务系统架构设计、开发和上线过程中，面临着严苛的困难和挑战。企业缺少实际业务场景实践经验，应用云原生化改造路径不清晰、技术方案可行性难预估、价值收益难衡量等现实问题成为云原生技术的最大绊脚石。同时高可靠、高扩展、高性能和高安全的云原生技术架构的实现也对企业 IT 技术人员的专业知识储备和实践经验提出严苛要求，专业咨询服务成为企业云原生技术落地的重要助推器。

在昨天听华为云技术峰会的时候就谈到了会引入云原生合作伙伴计划，那么当前我们团队的产品和技术实践积累完全可以满足合作伙伴计划的要求。

4.云原生发展趋势

对于云原生未来趋势展望，白皮书里面提到了分布式云，基础设施可感知，安全，AI和数据智能，面向应用使能等多个方面的内容。具体详细的说明可以参考白皮书里面的内容说明，在这里我个人想强调下云原生为企业数字化转型服务的技术趋势。

可以看到我谈到的几个点，正好也是企业数字化转型的三大核心点，即连接，数据，智能方面的内容。即云原生和云服务本身也需要具备这些关键特性。

第一点就是分布式云和全连接：即从单一的公有云服务，变化为构建企业私有云和公有云的混合云和多云服务协同平台，在万物互联下构建云边协同平台。

第二点就是强化云平台和服务的数据资产能力提供和能力挖掘，在应用迁移上云后接着带来的问题就是云上沉淀的数据如何进一步处理，加工，利用和大数据分析，那么云平台必须提供全面配套的数据存储，处理工具和技术。这个不仅仅是当前常说的数据湖，数据湖仅仅是解决了最底层的数据采集，统一存储，统一数据API接口开放等。

第三点就是智能化方面的内容，即云原生平台和服务本身也应该是智能化的。这个智能化本身包括了最简单的自动化，比如现在谈到的DevOps，自动化部署等更多解决自动化层面的问题，其次则是智能化，比如当前的AIOps更多是希望整个运维，治理过程能够智能化。当然智能化还有一个更大的内容，即是基于第二步的数据资产进行的数据建模和算法积累，基于统计学的大数据分析等。整个应用发展趋势是智能化，那么整个云平台就必须要首先能够提供智能化的工具和技术支撑能力。

当然，以上三点趋势的基础要求还是从资源层需求变化为服务层需求，从资源使能变化为应用使能，实现整个云平台服务整体重心的上移和抽象化，如果这个基础点都做不到，那么上面几个趋势点也无法做到。

对于该白皮书后续还包括了云原生业务智能，云原生安全可信，云原生案例分享等章节，在这里就不再展开描述。