很高兴能够参与这个【云计算】云原生可移植性的神话问题集合的解答工作。我将根据自己的知识和经验，为每个问题提供准确而有用的回答，并尽量满足大家的需求。

文章目录列表:

【云计算】云原生可移植性的神话

随着大量新 和支持工具的出现，云原生势头正在增长。 这些新 为开发人员提供了越来越多的功能，可以自动化方式快速开发，部署和管理大量微服务。

但这种势头伴随着成本，你最好准备为此付出代价。

最近我写了一篇由Kubernetes等云原生 提供的“ 开发人员的新分布式原语 ”，以及这些原语如何与用于应用程序开发的编程原语相结合。 例如，下面看看开发人员必须了解和使用多少Kubernetes概念才能有效地运行单个容器化应用程序：

请记住，此图表不包含DevOps团队的Ops部门必须管理的任何支持Kubernetes对象。在第2天操作之前也不需要额外的应用程序支持工具（用于日志管理，监视，跟踪，服务网格等）。

可能的情况是，开发人员必须编写与容器中的应用程序代码相同数量的YAML代码。更重要的是，应用程序本身将依赖于以前比以往更多的 。云本机应用程序期望 执行运行状况检查，部署，放置，服务发现，运行定期任务（cron作业）或调度原子工作单元（作业），自动扩展，配置管理等。

因此，您的应用程序已放弃并将所有这些职责委托给 ，并期望以可靠的方式处理它们。事实上，现在您的应用程序和相关团队在很多不同的级别上依赖于 ：代码，设计，体系结构，开发实践，部署和交付管道，支持过程，恢复方案，您可以为其命名。

上图显示了您的代码在Kubernetes微服务的上下文中有多小。但是，当我们谈论基于生产就绪的微服务系统时，这种情况远未完成。任何规模庞大的系统都需要集中监控，度量收集，跟踪，服务网格，集成构建和部署工具，管道等工具。

该 只是冰山一角，为了在云原生 取得成功，您需要成为完全集成的工具和公司生态系统的一部分。因此，赌注绝不是单一 ，项目或酷图书馆或一家公司。它是关于同步协同工作的整个项目生态系统，以及在未来十年左右合作并致力于事业的公司（供应商和客户）的整个生态系统。我认为这两个方面同样重要：

技术：

考虑到向云本地过渡是一个多年的旅程，只有长期成功才能带来好处，重要的是打赌一种具有未来5 - 10年潜力的技术，而不是从过去5到10年的 历史 。

文化：

云原生是通过微服务，容器，持续交付和DevOps的组合实现的。而成为云本机需要的不仅仅是为您的应用程序添加少量依赖项/库（而不是在某些会议中如何推广它）。您可能不得不改变团队结构和仪式，工作习惯和编码实践，并习惯于消耗仍然非常活跃的技术空间。如果您的公司文化在某种程度上更接近于开发或仅使用云原生 和相关工具的公司的文化，那就更容易了。诸如提出拉取请求与提交错误报告，检查上游源代码以及为即将发布的新功能公开讨论而不是等到新闻的下一次会议通知之类的小事情可以对团队是否喜欢使用 与否。文化一致性和人为因素与技术优势同等重要。

以下内容并不代表完整的环境，但我将尝试将我想到的主要云本地生态系统分组：

作为Apache Software Foundati 的一部分，Apache Mesos具有其优点（成熟的社区）和缺点（缓慢移动）。它诞生于2009年左右，是一个成熟的框架，它增加了对容器的支持（我的意思是这里的docker格式）和类似的概念，比如最近的Pods / Task组。

Cloud Foundry再次诞生于2009年左右，是云原生 的先驱之一。当Spring Cloud与Cloud Foundry一起使用时，该 与应用程序本身融为一体。服务发现，负载平衡，配置管理，重试，超时等一些功能在服务中执行（在本例中为JVM）。这是Kubernetes等 所采取的相反方法，其中所有这些职责都委托给 或其他支持容器（例如envoy，linkerd，traefik）。我在过去比较了Kubernetes和Spring Cloud（通知不是Cloud Foundry）。

虽然Docker，Inc。（该公司）仍在研究它将要开发什么以及销售什么，但亚马逊使用Docker技术作为AWS Elastic Container Services的一部分创建了一个非常可靠的产品。带有Blox的ECS（AWS的开源容器编排软件）本身可能不是什么大事，但当与所有其他AWS产品结合使用时，它是一个功能非常强大的集成 。

更不用说从虚拟机时代起成为AWS支持者的Netflix正在向容器领域过渡，并正在推动Amazon ECS的创新。

Kubernetes是此类别中最新的 之一，但同时也是有史以来最活跃，发展最快的开源项目之一。与整合的云原生计算基金会项目和支持公司相结合，使整个生态系统成为这一类别中非常有力的竞争者。

作为一个后来者（2014年），Kuebernetes的优势在于从一开始就以容器为中心的架构发展。而且它基于一个已有十年 历史 的谷歌博格，这意味着原则（不是实施）是成熟的，并在最高级别进行战斗测试。

正如您可以从Sysdig最近的报告中看到的结果，云本地用户似乎很欣赏这一切。

也许您在想，只要您将应用程序打包到容器中，就可以轻松地跨不同的云原生 移植。你错了。无论您是从Mesos，Cloud Foundry，Kubernetes，Docker Swarm，ECS开始，您都必须进行大量投资，以学习 和支持工具，了解文化和工作方式，并与这个仍然快速变化的生态系统进行互动。技术和公司。

本文的目的不是要比较这些生态系统，而是要显示它们之间的差异，并证明如果需要，它将需要大量的时间和金钱来输入一个或转移到另一个生态系统。

云原生态系统在技术，流程和文化方面非常 。但即便在他们之间也有一些整合。许多由一个 推广的概念也在向其他 传播。例如，部署单元（Pod in Kubernetes）的概念现在出现在Mesos中，它也作为任务组存在于Amazon ECS中。服务器端负载平衡（Kubernetes中的服务）和带有策略的调度/放置（Kubernetes调度程序）的概念也存在于Docker Swarm，AWS ECS等中。但这是它走多远，从一个生态系统过渡到另外，需要付出很多努力。

那么如何避免与单一供应商锁定？一种方法是坚持使用Kubernetes并接受它作为云和服务提供商之间的可移植性层。 Kubernetes如此受欢迎的原因之一是因为它不是单一的公司玩具，而是由多家大型 科技 公司支持，如谷歌，红帽（OpenShift），Docker，Mesosphere，IBM，戴尔，思科等等。

另一个原因是有许多云公司提供Kubernetes作为服务。如果您使用Kubernetes，那么您可以通过第三方服务提供商以最小的努力在Google容器引擎，Microsoft Azure，IBM Bluemix容器服务等云提供商之间移动您的应用程序，甚至可以在AWS上移动您的应用程序。这意味着Kubernetes API是云 之间应用程序的可移植性层，而不仅仅是容器。一个容器本身就是云原生海洋的一滴。

云原生2.0是企业智能升级新阶段，企业的云化从“ON Cloud”走向“IN Cloud”，当一切应用都生于云，长于云，云架构的迭代也会进入一个新的阶段。

围绕云原生2.0，华为云首席架构师顾炯炯提出了8个关键模式： 分布式云，混合调度，应用驱动基础设施，存算分离与数据治理自动化，可信、平民化DevOps，基于软总线的异构集成，多模态可迭代AI模型， 立体式云安全。

分布式云

随着云化和数字化渗透到制造类、工业互联网类场景，5G技术在to B领域应用的快速成熟，以及物联网 、AI技术的成熟，现在云的服务对象不仅是企业的后台IT支撑系统，它延伸到了前端的“现场”，类似于工业场景里的近场计算。如果还是将所有的数字化应用系统都放在集中的数据中心，它的时延无法满足实时生产系统的要求。

另外，有一些行业的敏感数据不能从现场或者数据产生地直接简单的上传到云端，它存在数据安全、 保密的问题。再比如医疗里的基因大数据、视 监控等场景，如果所有数据都上传到云端，带宽的成本非常高昂。

所以，我们必须要引入云边端协同的分布式概念，构建分布式云的架构。 这个架构可以和核心侧架构配合，覆盖核心区域、热点区域、本地机房、业务现场等不同接入时延敏感度，数据 合规要求及数据上云带宽成本的应用上云场景。

举个例子，通过这样的方式，可以把云端的很多算力和计算逻辑，甚至是训练好的AI模型推送到更加靠近用户数据产生地的位置上，进行就近的计算，将海量的数据做一定的收敛、分析、脱敏等，再发送到云端进行闭环的处理和控制反馈。

混合调度

在很多算法 的努力下，华为云通过瑶光调度 大大提高了资源的分配效率，达到甚至超过了80~90%的程度，已经接近于业界的 水平。但是资源的实际利用率仍然处在一个比较低的水平，当然业界平均也不是特别理想， 者差不多20%左右。为了解决这样的问题，华为云引入混合调动、柔性计算的能力，将 和离线的不同优先级的业务，进行QoS感知的智能调用，实现资源利用率最大化。

柔性计算不仅仅具备弹性的特征，保证了横向的资源扩展，而且它也能实现纵向资源规格的可大可小。目前，消费者云已经在内部验证了柔性计算的能力，可以在不改变上层业务的前提下提高利用率，实现性能的倍增。关于柔性计算的更多内容参考 华为云首席架构师顾炯炯：敢为人先，探索架构创新之路如何走。

应用驱动的基础设施

如今，软硬件的垂直整合，特别是靠近操作系统底层的硬件和云服务基础设施层的服务软件之间的纵向整合能力，成为新的趋势，它把基础设施服务底层的硬件和相应的服务封装层打包在一起。

云服务厂商可以设计研发定制芯片，比如存储和网络的硬件卸载的芯片、匹配深度学习逻辑处理框架的芯片等等。如果有能力构建这样的软硬件垂直整合的能力，就能拥有相比其他云服务商更优的价格优势，也得以呈现自身 的硬件、芯片优势。

有了应用驱动的基础设施之后，根据应用的性能SLA需求，来定义是使用与软件完全解耦的通用硬件资源，还是匹配应用场景特殊诉求的软硬件深度协同的卸载卡或异构计算资源。

这也能发挥华为软硬件兼长的优势，我们在硬件领域有不少核心创新：一个是 SDI， 叫软件驱动的基础设施，也就是把分布式存储\分布式网络，还有Hypervisor的一些系统能力从服务器卸载到PCI卡上，也即SDI/擎天卸载卡。二是鲲鹏硬件支撑云存储和数据湖的处理， 鲲鹏单核处理能力虽弱于X86，但核密度则达到X86 CPU的2倍，因此在对IO及内存带宽作为其性能瓶颈的大数据及分布式存储场景，是比X86更好的选择。同时，我们也在用自研的升腾NPU取代GPU构建AI ， 它在深度学习的训练推理中体现出更高的能效比。

存算分离和数据治理的自动化

未来企业的所有的数据孤岛都将汇聚到云端的数据湖，进行 生命周期的治理和管理，所以必须要解决数据计算分析的资源需求。数据湖里有各种各样的结构化、半结构化、非结构化的数据，但这些数据的分析计算和底层的存储容量之间的需求，并不是线性匹配的关系。 比如对于深度学习的场景，数据量需要不断的计算迭代，它需要更多的计算能力，相对较少的存储需求。因此在不同的业务场景下，数据分析计算和存储的要求是不一样的，最终一定要走向存算分离。

在存算分离领域里面，华为云已经积累优势，从最早的去中心化的分布式存储引擎Fusi torage开始，七年磨一剑，我们从内部验证到向外部的推广，从块存储延伸到对象存储、文件存储、分布式的集群数据库，把原先在开源架构里五花八门的底层存储技术引擎架构实现了 。经过实际的测试，在业界同样支持存算分离数据湖架构的云场景中，华为云体现了 30-60%以上性能优势。

再就是数据治理自动化。 现在的数据治理的还是人力密集型工作，整个过程非常低效，很难满足很多行业的要求。所以在这个架构模式里面，除了存算分离的数据库，还要构建数据治理自动化。

通过引入AI的技术，将数据的获取、清洗以及最终数据知识的提取，主题库的建立、数据目录的发布，都实现完全的自动化。用户只需要 入湖的数据源和所属业务主题域，系统自动化创建入湖任务，底层资源根据入湖数据量自动扩缩容，智能完成入湖数据的安全等级、分级分类、 等级等数据标签的自动识别打标。这个能力对企业数据资产的快速沉淀能力的构建是至关重要的。

可信、平民化DevOps

通过将一系列安全可信措施嵌入到敏捷开发运维模式， 构建所谓的DevSecOps流水线，实现敏捷快速迭代与严格质量管控兼顾；并通过低代码/无代码实现更多行业应用资产的沉淀， 将行业应用的开发效率再上一个新台阶。

Devops实现了应用的敏捷开发，但在面向政企时，还需要满足应用质量和安全可信的要求。因此在遵循DevOps的同时，将安全能力集成到其中，升级成为DevSecOps。使用安全左移、默认安全、运行时安全、安全服务自动化/自助化、基础设施即代码（IaC）等技术， 实现管理与协同、设计与开发、CI/CD、应用管理、运维、安全可信等各个环节的一体化趋势。

此外，由于传统政企开发投入有限，需要通过低码化 化，来实现对应用进行快速构建及改造。华为云低代码 Cube可支持多种页面类型和丰富的组件能力，基于它的服务能力编排和业务流程无代码定制，可实现灵活流程触发方式、多种权限配置方式、自定义业务编排等。

基于软件总线的异构集成

即帮助企业构建可平滑演进的IT架构， 实现老旧应用与新建云原生应用，线上与线下应用的平滑融合集成。

云原生下，企业很多应用都要进行微服务解耦，遵从微服务的治理架构，进行水平扩展的架构的设计，甚至把原来的单体架构逐步进行拆解。但这个过程不是一蹴而就的，尤其是那些包袱比较重的传统行业，他们还面临很多现实的挑战。所以我们要在企业传统IT架构和云原生架构之间搭建无缝的桥梁，在确保企业业务连续性最大化的前提下，实现平滑的切换和演进。

以Roma Connect为例，它可以通过软总线的形式，把云原生和非云原生的传统 无缝的连接起来，支持异构的应用和数据库源的对接，也可以对接到云上开发 、数据湖，实现无缝互通。

在架构的平滑演进中，首先需要将传统非云原生应用封装为REST接口与云原生应用对接，通过 接口服务层APIC进行开放，业务云原生应用通过标准接口即可获取老系统信息。同样的机制可以将线上线下，及部署在多云环境上企业IT系统的无缝互通。

其次传统Oracle/Sybase等传统数据库及中间件与设备协议接入上云：云上云原生应用通过云上标准API调用、数据库访问、消息订阅等方式即可获取传统数据。

最后，通过全生命周期的API管理能力，包含从设计、发布、上架、治理的全过程，帮助企业构建整个跨地域，跨组织、跨部门的应用网络，并沉淀行业应用资产。

多模态可迭代的AI模型

AI在行业落地面临的问题是能够获取到的训练数据是非常有限的，单纯的依赖数据驱动的深度学习训练，使得行业AI模型是非常难以泛化、通用化。

预训练大模型是解决AI应用开发定制化和碎片化的重要方法。 通过一个AI大模型实现在众多场景通用、泛化和规模化复制，减少对数据标注的依赖，赋能AI开发由作坊式转变为工业化开发，比如华为云之前推出的盘古大模型。

另外也要引入知识计算的能力， 类似于把知识图谱这样的能力和基于感知计算的数据驱动的AI模型互补结合起来。也就是说把知识模型和数据模型，在数据样本相对缺少的情况下结合在一起，更好服务于行业AI的落地。帮助企业打造自己的知识计算 ，整合分散在不同系统、多种形态的企业数据，形成带有建议性的知识体系。

的立体式云安全

1.0阶段的云安全服务更多的是孤立的安全能力：虚拟化安全，hyporvisor防逃逸能力，云防火墙能力其实都是割裂的，并没有跟所有的云服务形成互锁。

的立体式运营安全通过打通离散的云安全服务能力，将其与其他云服务及客户应用形式互锁， 构建安全Build-in的云原生应用，以及引入可信智能计算，解决跨行业数据 保护与流通碰撞、价值挖掘之间的矛盾。

首先通过可信智能计算提供四个核心能力，进行安全可信的数据计算。包括：

1、跨组织、跨行业的多方数据融合分析和多方横向与纵向联邦学习建模；

2、支持对接主流数据源和深度学习框架；

3、支持安全多方计算（例如同态加密，差分 等），并支持用户自定义 策略；

4、基于区块链的数据计算轨迹的可追溯可审计。

此外，为了 安全，还需要将全栈云（及其子集）下沉部署（连线/非连线），彻底解决敏感行业上云安全顾虑，以及将全栈云服务、企业新开发云原生应用、aPaaS/SaaS等与全栈云安全能力互锁，为用户构建体系化的云安全 。

本文分享自华为云社区，作者：技术火炬手。

好了，今天关于“【云计算】云原生可移植性的神话”的话题就讲到这里了。希望大家能够通过我的介绍对“【云计算】云原生可移植性的神话”有更全面的认识，并且能够在今后的实践中更好地运用所学知识。如果您有任何问题或需要进一步的信息，请随时告诉我。