>摘要：在云原生2.0阶段，我们到底需要构建一个什么样的架构？华为云首席架构师为你一一解答。本文分享自华为云社区[《华为云首席架构师独家分享：云原生2.0架构设计的8大关键趋势》](https://bbs.huaweicloud.com/blogs/314122?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=other&utm_content=content)，作者：技术火炬手。 云原生2.0是企业智能升级新阶段，企业的云化从“ON Cloud”走向“IN Cloud”，当一切应用都生于云，长于云，云架构的迭代也会进入一个新的阶段。 围绕云原生2.0，**华为云首席架构师顾炯炯提出了8个关键模式：** 分布式云，混合调度，应用驱动基础设施，存算分离与数据治理自动化，可信、平民化DevOps，基于软总线的异构集成，多模态可迭代AI模型，全方位立体式云安全。 # 分布式云 随着云化和数字化渗透到制造类、工业互联网类场景，5G技术在to B领域应用的快速成熟，以及物联网 、AI技术的成熟，现在云的服务对象不仅是企业的后台IT支撑系统，它延伸到了前端的“现场”，类似于工业场景里的近场计算。如果还是将所有的数字化应用系统都放在集中的数据中心，它的时延无法满足实时生产系统的要求。 另外，有一些行业的敏感数据不能从现场或者数据产生地直接简单的上传到云端，它存在数据安全、隐私保密的问题。再比如医疗里的基因大数据、视频监控等场景，如果所有数据都上传到云端，带宽的成本非常高昂。 所以，我们必须要**引入云边端协同的分布式概念，构建分布式云的架构。** 这个架构可以和核心侧架构配合，覆盖核心区域、热点区域、本地机房、业务现场等不同接入时延敏感度，数据隐私合规要求及数据上云带宽成本的应用上云场景。 举个例子，通过这样的方式，可以把云端的很多算力和计算逻辑，甚至是训练好的AI模型推送到更加靠近用户数据产生地的位置上，进行就近的计算，将海量的数据做一定的收敛、分析、脱敏等，再发送到云端进行闭环的处理和控制反馈。 # 混合调度 在很多算法专家的努力下，华为云通过瑶光调度平台大大提高了资源的分配效率，达到甚至超过了80~90%的程度，已经接近于业界的领先水平。但是资源的实际利用率仍然处在一个比较低的水平，当然业界平均也不是特别理想，领先者差不多20%左右。为了解决这样的问题，**华为云引入混合调动、柔性计算的能力，将在线和离线的不同优先级的业务，进行QoS感知的智能调用，实现资源利用率最大化。** 柔性计算不仅仅具备弹性的特征，保证了横向的资源扩展，而且它也能实现纵向资源规格的可大可小。目前，消费者云已经在内部验证了柔性计算的能力，可以在不改变上层业务的前提下提高利用率，实现性能的倍增。关于柔性计算的更多内容参考 华为云首席架构师顾炯炯：[敢为人先，探索架构创新之路如何走。](https://bbs.huaweicloud.com/blogs/314131) # 应用驱动的基础设施 如今，软硬件的垂直整合，特别是靠近操作系统底层的硬件和云服务基础设施层的服务软件之间的纵向整合能力，成为新的趋势，它把基础设施服务底层的硬件和相应的服务封装层打包在一起。 云服务厂商可以设计研发定制芯片，比如存储和网络的硬件卸载的芯片、匹配深度学习逻辑处理框架的芯片等等。如果有能力构建这样的软硬件垂直整合的能力，就能拥有相比其他云服务商更优的价格优势，也得以呈现自身独特的硬件、芯片优势。 有了应用驱动的基础设施之后，**根据应用的性能SLA需求，来定义是使用与软件完全解耦的通用硬件资源，还是匹配应用场景特殊诉求的软硬件深度协同的卸载卡或异构计算资源。** 这也能发挥华为软硬件兼长的优势，我们在硬件领域有不少核心创新：**一个是 SDI**， 叫软件驱动的基础设施，也就是把分布式存储\分布式网络，还有Hypervisor的一些系统能力从服务器卸载到PCI卡上，也即SDI/擎天卸载卡。二是**鲲鹏硬件支撑云存储和数据湖的处理**， 鲲鹏单核处理能力虽弱于X86，但核密度则达到X86 CPU的2倍，因此在对IO及内存带宽作为其性能瓶颈的大数据及分布式存储场景，是比X86更好的选择。同时，我们也在用自研的**昇腾NPU取代GPU构建AI平台**， 它在深度学习的训练推理中体现出更高的能效比。 # 存算分离和数据治理的自动化 未来企业的所有的数据孤岛都将汇聚到云端的数据湖，进行统一生命周期的治理和管理，所以必须要解决数据计算分析的资源需求。数据湖里有各种各样的结构化、半结构化、非结构化的数据，**但这些数据的分析计算和底层的存储容量之间的需求，并不是线性匹配的关系。** 比如对于深度学习的场景，数据量需要不断的计算迭代，它需要更多的计算能力，相对较少的存储需求。因此在不同的业务场景下，数据分析计算和存储的要求是不一样的，最终一定要走向存算分离。 在存算分离领域里面，华为云已经积累优势，从最早的去中心化的分布式存储引擎FusionStorage开始，七年磨一剑，我们从内部验证到向外部的推广，从块存储延伸到对象存储、文件存储、分布式的集群数据库，把原先在开源架构里五花八门的底层存储技术引擎架构实现了统一。经过实际的测试，在业界同样支持存算分离数据湖架构的云场景中，华为云体现了领先30-60%以上性能优势。 **再就是数据治理自动化。** 现在的数据治理的还是人力密集型工作，整个过程非常低效，很难满足很多行业的要求。所以在这个架构模式里面，除了存算分离的数据库，还要构建数据治理自动化。 通过引入AI的技术，将数据的获取、清洗以及最终数据知识的提取，主题库的建立、数据目录的发布，都实现完全的自动化。用户只需要指定入湖的数据源和所属业务主题域，系统自动化创建入湖任务，底层资源根据入湖数据量自动扩缩容，智能完成入湖数据的安全等级、分级分类、隐私等级等数据标签的自动识别打标。这个能力对企业数据资产的快速沉淀能力的构建是至关重要的。 # 可信、平民化DevOps **通过将一系列安全可信措施嵌入到敏捷开发运维模式，** 构建所谓的DevSecOps流水线，实现敏捷快速迭代与严格质量管控兼顾；并**通过低代码/无代码实现更多行业应用资产的沉淀**， 将行业应用的开发效率再上一个新台阶。 Devops实现了应用的敏捷开发，但在面向政企时，还需要满足应用质量和安全可信的要求。因此在遵循DevOps的同时，将安全能力集成到其中，升级成为DevSecOps。使用安全左移、默认安全、运行时安全、安全服务自动化/自助化、基础设施即代码（IaC）等技术， 实现管理与协同、设计与开发、CI/CD、应用管理、运维、安全可信等各个环节的一体化趋势。 此外，由于传统政企开发投入有限，需要通过低码化无码化，来实现对应用进行快速构建及改造。华为云低代码平台AppCube可支持多种页面类型和丰富的组件能力，基于它的服务能力编排和业务流程无代码定制，可实现灵活流程触发方式、多种权限配置方式、自定义业务编排等。 # 基于软件总线的异构集成 即帮助企业**构建可平滑演进的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等与全栈云安全能力互锁，为用户构建体系化的云安全平台。

>摘要：K8s正在向边缘计算渗透，它为边缘侧的应用部署提供了便利性，在一定程度上转变了边缘应用与硬件之间的关系，将两者的耦合度降低。 本文分享自华为云社区[《云原生在物联网中的应用【拜托了，物联网！】》](https://bbs.huaweicloud.com/blogs/301069?utm_source=zhihu&utm_medium=bbs-ex&utm_campaign=iot&utm_content=content)，作者： kaliarch。 # 前言 物联网已经产生了数量惊人的数据，随着5G网络的部署，这些数据将呈指数级增长。管理和使用这些数据是一个挑战。 无论是从交通摄像头、气象传感器、电表等会产生信息，这些信息与智能城市环境中，其他摄像头和传感器的数据相结合，在一个中心位置处理起来可能会太多，尤其是当你在预期设备会对事件做出反应时。 超大规模云计算环境中已被普遍使用的Kubernetes（简称K8s），带入到物联网边缘计算场景中。新成立的Kubernetes物联网边缘工作组将采用运行容器的理念并扩展到边缘，促进K8s在边缘环境中的适用。 - 支持将工业物联网IoT的连接设备数量扩展到百万量级，既可支持IP设备以直连方式接入K8s云平台，又可支持非IP设备通过物联网网关接入。 - 利用边缘节点，让计算更贴近设备侧，以便减少延迟、降低带宽需求和提高可靠性，满足用户实时、智能、数据聚合和安全需求： - 将流数据应用部署到边缘节点，降低设备和云平台之间通信的带宽需求。 - 部署无服务器应用框架，使得边缘侧无需与云端通讯，便可对某些紧急情况做出快速响应。 - 在混合云和边缘环境中提供通用控制平台，以简化管理和操作。 # 一 背景  ## 1.1 KubeEdge简介 KubeEdge 是一个开源的系统，可将本机容器化应用编排和管理扩展到边缘端设备。 它基于Kubernetes构建，为网络和应用程序提供核心基础架构支持，并在云端和边缘端部署应用，同步元数据。KubeEdge 还支持 **MQTT** 协议，允许开发人员编写客户逻辑，并在边缘端启用设备通信的资源约束。KubeEdge 包含云端和边缘端两部分。 ## 1.2 KubeEdge特点 **边缘计算** 通过在边缘端运行业务逻辑，可以在本地保护和处理大量数据。KubeEdge 减少了边和云之间的带宽请求，加快响应速度，并保护客户数据隐私。 **简化开发** 开发人员可以编写常规的基于 http 或 mqtt 的应用程序，容器化并在边缘或云端任何地方运行。 **Kubernetes 原生支持** 使用 KubeEdge 用户可以在边缘节点上编排应用、管理设备并监控应用程序/设备状态，就如同在云端操作 Kubernetes 集群一样。 **丰富的应用程序** 用户可以轻松地将复杂的机器学习、图像识别、事件处理等高层应用程序部署到边缘端。 # 二 KubeEdge简介 ## 2.1 KubeEdge架构  ## 2.2 架构详解 ### 2.2.1 云上部分 - CloudHub: CloudHub 是一个 Web Socket 服务端，负责监听云端的变化, 缓存并发送消息到 EdgeHub。 - EdgeController: EdgeController 是一个扩展的 Kubernetes 控制器，管理边缘节点和 Pods 的元数据确保数据能够传递到指定的边缘节点。 - DeviceController: DeviceController 是一个扩展的 Kubernetes 控制器，管理边缘设备，确保设备信息、设备状态的云边同步。 ### 2.2.2 边缘部分 - EdgeHub: EdgeHub 是一个 Web Socket 客户端，负责与边缘计算的云服务（例如 KubeEdge 架构图中的 Edge Controller）交互，包括同步云端资源更新、报告边缘主机和设备状态变化到云端等功能。 - Edged: Edged 是运行在边缘节点的代理，用于管理容器化的应用程序。 - EventBus: EventBus 是一个与 MQTT 服务器（mosquitto）交互的 MQTT 客户端，为其他组件提供订阅和发布功能。 - ServiceBus: ServiceBus是一个运行在边缘的HTTP客户端，接受来自云上服务的请求，与运行在边缘端的HTTP服务器交互，提供了云上服务通过HTTP协议访问边缘端HTTP服务器的能力。 - DeviceTwin: DeviceTwin 负责存储设备状态并将设备状态同步到云，它还为应用程序提供查询接口。 - MetaManager: MetaManager 是消息处理器，位于 Edged 和 Edgehub 之间，它负责向轻量级数据库（SQLite）存储/检索元数据。 # 三 实战部署 ## 3.1 keadm部署 注意事项： - 目前支持keadmUbuntu 和 CentOS 操作系统。RaspberryPi 支持正在进行中。 - 需要超级用户权限（或 root 权限）才能运行。 ### 3.1.1 设置云端（KubeEdge 主节点） 默认情况下10000，10002边缘节点需要可以访问 Cloudcore 中的端口和端口。 keadm init将安装 cloudcore，生成证书并安装 CRD。它还提供了一个可以设置特定版本的标志。 **重要说明：** 1. kubeconfig 或 master 中至少一个必须正确配置，以便用于验证 k8s 集群的版本和其他信息。1.请确保边缘节点可以使用云节点的本地IP连接云节点，或者您需要使用--advertise-address标志指定云节点的公共IP 。1. --advertise-address（1.3版本后才有效）是云端暴露的地址（会加入到CloudCore证书的SAN中），默认值为本地IP。 例子： `keadm init --advertise-address="THE-EXPOSED-IP"(only work since 1.3 release)` 输出： Kubernetes version verification passed, KubeEdge installation will start... ... KubeEdge cloudcore is running, For logs visit: /var/log/kubeedge/cloudcore.log ### 3.1.2 设置边缘端（KubeEdge 工作节点） - 从云端获取令牌 keadm gettoken在**云端**运行将返回令牌，该令牌将在加入边缘节点时使用。 keadm gettoken 27a37ef16159f7d3be8fae95d588b79b3adaaf92727b72659eb89758c66ffda2.eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE1OTAyMTYwNzd9.JBj8LLYWXwbbvHKffJBpPd5CyxqapRQYDIXtFZErgYE - 加入边缘节点 keadm join将安装 edgecore 和 mqtt。它还提供了一个可以设置特定版本的标志。 例子： `keadm join --cloudcore-ipport=192.168.20.50:10000 --token=27a37ef16159f7d3be8fae95d588b79b3adaaf92727b72659eb89758c66ffda2.eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE1OTAyMTYwNzd9.JBj8LLYWXwbbvHKffJBpPd5CyxqapRQYDIXtFZErgYE` - **重要说明：** 1. --cloudcore-ipportflag 是强制性标志。1. 如果要自动为边缘节点申请证书，--token则需要。1.云端和边缘端使用的kubeEdge版本要一致。 输出： Host has mosquit+ already installed and running. Hence skipping the installation steps !!! ... KubeEdge edgecore is running, For logs visit: /var/log/kubeedge/edgecore.log ## 3.2 二进制部署 注意事项： - 需要超级用户权限（或 root 权限）才能运行。 ### 3.2.1 设置云端（KubeEdge 主节点） - 创建 CRD kubectl apply -f https://raw.githubusercontent.com/kubeedge/kubeedge/master/build/crds/devices/devices_v1alpha2_device.yaml kubectl apply -f https://raw.githubusercontent.com/kubeedge/kubeedge/master/build/crds/devices/devices_v1alpha2_devicemodel.yaml kubectl apply -f https://raw.githubusercontent.com/kubeedge/kubeedge/master/build/crds/reliablesyncs/cluster_objectsync_v1alpha1.yaml kubectl apply -f https://raw.githubusercontent.com/kubeedge/kubeedge/master/build/crds/reliablesyncs/objectsync_v1alpha1.yaml - 准备配置文件 `cloudcore --minconfig > cloudcore.yaml` 详情请参考云配置。 - 运行 ` cloudcore --config cloudcore.yaml` ### 3.2.2 设置边缘端（KubeEdge 工作节点） #### 3.2.2.1 准备配置文件 - 生成配置文件 `edgecore --minconfig > edgecore.yaml` - 在云端获取代币值： `kubectl get secret -nkubeedge tokensecret -o=jsonpath='{.data.tokendata}' | base64 -d` - 更新 edgecore 配置文件中的令牌值： `sed -i -e "s|token: .*|token: ${token}|g" edgecore.yaml` 这token就是上面步骤得到的。 详情请参考edge的配置。 #### 3.2.2.2 运行 如果要在同一台主机上运行 cloudcore 和 edgecore，请先运行以下命令： export CHECK_EDGECORE_ENVIRONMENT="false" 启动边缘核： `edgecore --config edgecore.yaml` 运行edgecore -h以获取帮助信息并根据需要添加选项。 # 四 反思 K8s正在向边缘计算渗透，它为边缘侧的应用部署提供了便利性，在一定程度上转变了边缘应用与硬件之间的关系，将两者的耦合度降低。通过KubeEdge，拓展“边缘场景”，可帮助用户加速实现云边协同，在海量边、端设备上完成大规模应用的统一交付、运维与管控。 据Gartner估计，到2025年，超过75%的企业生成数据可以在传统数据中心和云之外创建和处理，像Kubernetes这样的编排系统前景光明，它已经被证明是完成这一任务的最佳工具。 # 参考资料 - kubeedge/README_zh.md at master · kubeedge/kubeedge · GitHub - https://www.cncf.io/blog/2020/09/25/kubernetes-could-be-the-one-to-make-the-internet-of-things-iot-reach-its-potential/

>摘要：CNCF（云原生计算基金会）正式接纳由华为云贡献的多云容器编排项目Karmada，迎来CNCF首个多云容器编排项目。 本文分享自华为云社区[《华为云开源的Karmada正式成为CNCF首个多云容器编排项目》](https://blog.csdn.net/devcloud/article/details/120566049?spm=1001.2014.3001.5501)，作者：华为云开发者社区 北京时间9月15日，CNCF（云原生计算基金会）正式接纳由华为云贡献的多云容器编排项目Karmada（https://github.com/karmada-io/karmada），迎来CNCF首个多云容器编排项目。Karmada 项目的加入，将CNCF的云原生版图进一步扩展至分布式云领域。 华为云在技术上一直积极回馈社区，已开源了以智能边缘项目KubeEdge和批量计算项目Volcano为代表的一系列云原生项目。Karmada项目由华为云、工商银行、小红书、中国一汽等8家企业联合发起，沉淀了各企业在多云管理领域的丰富积累，为开发者提供详实有效的实践指导与帮助，使用Karmada，可以构建无极可扩展的容器资源池，让开发者像使用单个Kubernetes集群一样使用多云集群。 # Karmada介绍 随着企业业务的快速发展，多云也逐步成为数据中心建设的基础架构，多区域容灾与多活、大规模多集群管理、跨云弹性与迁移等场景推动云原生多云相关技术的快速发展。 然而，在实际的生产落地过程中，云原生的多云仍面临如下挑战： - 集群繁多的重复劳动：运维工程师需要应对繁琐的集群配置、不同云厂商集群间的管理差异以及碎片化的API访问入口等问题； - 业务过度分散的维护难题：应用在各集群的差异化配置繁琐；业务跨云访问以及集群间的应用同步难以管理； - 集群的边界限制：应用的可用性受限于集群；资源调度、弹性伸缩受限于集群； - 厂商绑定：业务部署的黏性问题，缺少自动化故障迁移；缺少中立的开源多云容器编排项目。 Karmada结合了华为云多云容器平台MCP以及Kubernetes Federation核心实践，并融入了众多新技术：包括Kubernetes原生API支持、多层级高可用部署、多集群自动故障迁移、多集群应用自动伸缩、多集群服务发现等，并且提供原生Kubernetes平滑演进路径，让基于Karmada的多云方案无缝融入云原生技术生态，为企业提供从单集群到多云架构的平滑演进方案。  Karmada项目全景 # 生态合作 Karmada项目由华为云、工商银行、浦发银行、小红书、VIPKID、趣头条、中国一汽和T3出行联合发起，于2021年4月25日在华为开发者大会（HDC.Cloud）2021上正式宣布开源。Karmada自开源以来受到了广泛的关注和支持，目前已有30+大型企业/机构/高校参与社区开发及贡献。 >Karmada项目源自华为云多云容器平台MCP，同时融入了工商银行、小红书、中国一汽等不同行业客户在多云管理方面的经验，可以为各企业提供详实有效的落地指导与帮助，企业通过Karmada构建跨云、跨数据中心的无极可扩展的应用资源池，可以像管理单个Kubernetes集群一样简单、便捷的管理不同云、不同数据中心里的集群与应用。——华为云CTO 张宇昕>在社区贡献方面，工商银行作为 Karmada项目的头部参与单位，结合工行多年来多容器集群管理的经验，已在集群生命周期管理、核心调度控制器等核心模块进行深度定制化的开发。后续，工行将持续参与Karmada 社区的开发和管理工作，计划在多集群自动调度、多集群自动伸缩等模块继续深入研究及贡献，反哺开源社区，持续扩大业界影响力。——工商银行软件开发中心专家 鲁金彪>集团型企业同时存在多个混合容器的复杂场景，跨多云技术架构的运维难题日益突出。华为Karmada作为多集群、多云及混合云的集中化、兼容原生Kubernetes API接口的管理架构，有效解决目前容器编排多集群、多环境无法集中式管理、安全隔离机制不健全等痛点。希望Karmada在加入CNCF后，通过社区的共同维护与贡献，不断壮大其功能。期待Karmada早日从CNCF毕业，反哺云原生生态。——一汽体系数字化部技术运营主任 王广>Karmada原生兼容Kubernetes API的能力，可以不加改造地对接现有Kubernetes生态。在落地实践过程中，我们使用Karmada对接了现有的GitOps生态，极大提高了应用跨集群部署的效率。 ——VIPKID运维总监 谷玉虎>Karmada提供丰富的多集群调度策略以及开箱即用的内置策略集，可以极大的简化两地三中心、异地容灾和同城双活架构下的系统复杂性，这对于金融行业至关重要。 ——浦发银行云转型处处长 吕炳刚 # 未来可期 目前，Karmada已在华为云多云容器平台（Multi-Cloud Container Platform，MCP）商用，提供分布式云解决方案，提供跨云的多集群统一管理、应用统一部署及流量分发等关键能力。 除MCP以外，Karmada已在数十家来自金融、互联网、教育等企业中落地。 此次CNCF正式将Karmada接纳为云原生领域首个多云容器编排项目，将极大促进Karmada上下游社区生态构建及合作，吸引广大云原生企业用户深度参与，Karmada将在多集群应用管理、服务治理、高可用部署等领域发挥越来越重要的作用，华为云也将在云原生领域持续耕耘、持续引领创新、繁荣生态，助力各行业走向快速智能发展之路。

此贴为《华为云原生大数据serverless服务DLI》课后操作任务打卡专用查看更多操作任务请点击：》》点击前往《《查看全部活动任务&信息请点击：》》点击前往《《按要求完成考核打卡可获得活动积分  +20积分》》参与活动前请先点击这里报名活动《《本实验逻辑ecs用来模拟数据流流式数据通过kafka接入DLI进行流式数据分析DLI分析后的数据结果存在rds参与考核中可能会存在使用产品的情况，请提前领取课程专属免费试用：（1）https://activity.huaweicloud.com/Date-free.html（2）https://activity.huaweicloud.com/free_test/index.html领取时请注意数据中心节点与实验要求一致！！！推荐  华南-广州 实验请联系小助手开通白名单提供信息：截图中的 我的凭证-API凭证-项目ID&所属区域【项目ID】↓联系小助手企业微信↓ 操作考核方式：《华为云原生大数据serverless服务DLI》课后操作任务用户前往 》》课程报名《《 课程，并按照操作文档进行操作，按照指导完成实验，最后按照要求截图+华为云账号回复至本帖内，视为完成任务。在步骤6中项目名称使用此贴右上角华为云账号昵称需要截图截出步骤7中的结果，并显示用户名称，无名称则无效将截图回复至本帖活动规则：a. 回复非按要求的图片，视为无效楼层。b.按照规定完成打，并按照规定将帖子截图回复到本帖可获得20积分课程积分完成三个操作任务并对应回复截图后，可获得实体证书请在此问卷中登记信息：https://devcloud.huaweicloud.com/expertmobile/qtn?id=bcdc4692db4a48f5808bce295ebd0666更多活动信息请查看：https://bbs.huaweicloud.com/forum/thread-166386-1-1.html

>摘要：遥感影像，作为地球自拍照，能够从更广阔的视角，为人们提供更多维度的辅助信息，来帮助人类感知自然资源、农林水利、交通灾害等多领域信息。本文分享自华为云社区[《AI+云原生，把卫星遥感虐的死去活来》](https://bbs.huaweicloud.com/blogs/296183?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=other&utm_content=content)，作者：tsjsdbd。 # AI牛啊，云原生牛啊，所以1+1>2？ 遥感影像，作为地球自拍照，能够从更广阔的视角，为人们提供更多维度的辅助信息，来帮助人类感知自然资源、农林水利、交通灾害等多领域信息。 AI技术，可以在很多领域超过人类，关键是它是自动的，省时又省力。可显著提升遥感影像解译的工作效率，对各类地物元素进行自动化的检测，例如建筑物，河道，道路，农作物等。能为智慧城市发展&治理提供决策依据。  云原生技术，近年来可谓是一片火热。易构建，可重复，无依赖等优势，无论从哪个角度看都与AI算法天生一对。所以大家也可以看到，各领域的AI场景，大都是将AI推理算法运行在Docker容器里面的。 AI+云原生这么6，那么强强联手后，地物分类、目标提取、变化检测等高性能AI解译不就手到擒来？我们也是这么认为的，所以基于AI+Kubernetes云原生，构建了支持遥感影像AI处理的空天地平台。 不过理想是好的，过程却跟西天取经一般，九九八十一难，最终修成正果。 # 业务场景介绍 遇到问题的业务场景叫影像融合（Pansharpen），也就是对地球自拍照进行“多镜头合作美颜”功能。（可以理解成：手机的多个摄像头，同时拍照，合并成一张高清彩色大图）。  所以业务简单总结就是：读取2张图片，生成1张新的图片。该功能我们放在一个容器里面执行，每张融合后的结果图片大约5GB。 问题的关键是，一个批次业务量需要处理的是3000多张卫星影像，所以每批任务只需要同时运行完成3000多个容器就OK啦。云原生YYDS！ # 业务架构图示 为了帮助理解，这里分解使用云原生架构实现该业务场景的逻辑图如下：  在云上，原始数据，以及结果数据，一定是要存放在对象存储桶里面的。因为这个数据量，只有对象存储的价格是合适的。（对象存储，1毛钱/GB。文件存储则需要3毛钱/GB） 因为容器之间是互相独立无影响的，每个容器只需要处理自己的那幅影像就行。例如1号容器处理 1.tif影像；2号容器处理2.tif影像；一次类推。 所以管理程序，只需要投递对应数量的容器（3000+），并监控每个容器是否成功执行完毕就行（此处为简化说明，实际业务场景是一个pipeline处理流程）。那么，需求已经按照云原生理想的状态分解，咱们开始起(tang)飞(keng)吧~ 注：以下描述的问题，是经过梳理后呈现的，实际问题出现时是互相穿插错综复杂的。 # K8s死掉了 当作业投递后，不多久系统就显示作业纷纷失败。查看日志报调用K8s接口失败，再一看，K8s的Master都已经挂了。。。 K8s-Master处理过程，总结版： 1. 发现Master挂是因为CPU爆了 2. 所以扩容Master节点（此次重复N次）； 3. 性能优化：扩容集群节点数量； 4. 性能优化：容器分批投放； 5. 性能优化：查询容器执行进度，少用ListPod接口； 详细版： 看监控Master节点的CPU已经爆掉了，所以最简单粗暴的想法就是给Master扩容呀，嘎嘎的扩。于是从4U8G * 3 一路扩容一路测试一路失败，扩到了32U64G * 3。可以发现CPU还是爆满。看来简单的扩容是行不通了。  3000多个容器，投给K8s后，大量的容器都处于Pending状态（集群整体资源不够，所以容器都在排队呢）。而正在Pending的Pod，K8s的Scheduler会不停的轮训，去判断能否有资源可以给它安排上。所以这也会给Scheduler巨大的CPU压力。扩容集群节点数量，可以减少排队的Pod数量。  另外，既然排队的太多，不如就把容器分批投递给K8s吧。于是开始分批次投递任务，想着别一次把K8s压垮了。每次投递数量，减少到1千，然后到500，再到100。 同时，查询Pod进度的时候，避免使用ListPod接口，改为直接查询具体的Pod信息。因为List接口，在K8s内部的处理会列出所有Pod信息，处理压力也很大。 这一套组合拳下来，Master节点终于不挂了。不过，一头问题按下去了，另一头问题就冒出来了。 # 容器跑一半，挂了 虽然Master不挂了，但是当投递1~2批次作业后，容器又纷纷失败。 容器挂掉的处理过程，总结版： 1. 发现容器挂掉是被eviction驱逐了； 2. Eviction驱逐，发现原因是节点报Disk Pressure（存储容量满了）； 3. 于是扩容节点存储容量； 4. 延长驱逐容器（主动kill容器）前的容忍时间； 详细版： （注：以下问题是定位梳理后，按顺序呈现给大家。但其实出问题的时候，顺序没有这么友好） 容器执行失败，首先想到的是先看看容器里面脚本执行的日志呗：结果报日志找不到~  于是查询Pod信息，从event事件中发现有些容器是被Eviction驱逐干掉了。同时也可以看到，驱逐的原因是 DiskPressure（即节点的存储满了）。  当Disk Pressure发生后，节点被打上了驱逐标签，随后启动主动驱逐容器的逻辑：  由于节点进入Eviction驱逐状态，节点上面的容器，如果在5分钟后，还没有运行完，就被Kubelet主动杀死了。（因为K8s想通过干掉容器来腾出更多资源，从而尽快退出Eviction状态）。  这里我们假设每个容器的正常运行时间为1~2个小时，那么不应该一发生驱动就马上杀死容器（因为已经执行到一半的容器，杀掉重新执行是有成本浪费的）。我们期望应该尽量等待所有容器都运行结束才动手。所以这个 pod-eviction-timeout 容忍时间，应该设置为24小时（大于每个容器的平均执行时间）。 Disk Pressure的直接原因就是本地盘容量不够了。所以得进行节点存储扩容，有2个选择：1）使用云存储EVS（给节点挂载云存储）。 2）扩容本地盘（节点自带本地存储的VM）。 由于云存储（EVS）的带宽实在太低了，350MB/s。一个节点咱们能同时跑30多个容器，带宽完全满足不了。最终选择使用 i3类型的VM。这种VM自带本地存储。并且将8块NVMe盘，组成Raid0，带宽还能x8。 # 对象存储写入失败 容器执行继续纷纷失败。 容器往对象存储写入失败处理过程，总结版： 1. 不直接写入，而是先写到本地，然后cp过去。 2. 将普通对象桶，改为支持文件语义的并行文件桶。 详细版： 查看日志发现，脚本在生成新的影像时，往存储中写入时出错：  我们整集群是500核的规模，同时运行的容器数量大概在250个（每个2u2g）。这么多的容器同时往1个对象存储桶里面并发追加写入。这个应该是导致该IO问题的原因。 对象存储协议s3fs，本身并不适合大文件的追加写入。因为它对文件的操作都是整体的，即使你往一个文件追加写入1字节，也会导致整个文件重新写一遍。 最终这里改为：先往本地生成目标影像文件，然后脚本的最后，再拷贝到对象存储上。相当于增加一个临时存储中转一下。  在临时中转存储选择中，2种本地存储都试过： 1）块存储带宽太低，350MB/s影响整体作业速度。2）可以选择带本地存储的VM，多块本地存储组成Raid阵列，带宽速度都杠杠滴。 同时，华为云在对象存储协议上也有一个扩展，使其支持追加写入这种的POSIX语义，称为并行文件桶。后续将普通的对象桶，都改为了文件语义桶。以此来支撑大规模的并发追加写入文件的操作。 # K8s计算节点挂了 So，继续跑任务。但是这容器作业，执行又纷纷失败鸟~ 计算节点挂掉，定位梳理后，总结版： 1. 计算节点挂掉，是因为好久没上报K8s心跳了。 2. 没上报心跳，是因为kubelet（K8s节点的agent）过得不太好（死掉了）。 3. 是因为Kubelet的资源被容器抢光了（由于不想容器经常oom kill，并未设置limit限制） 4. 为了保护kubelet，所有容器全都设置好limit。 详细版，直接从各类奇葩乱象等问题入手： - 容器启动失败，报超时错误。  - 然后，什么PVC共享存储挂载失败：  - 或者，又有些容器无法正常结束（删不掉）。  - 查询节点Kubelet日志，可以看到充满了各种超时错误：  啊，这么多的底层容器超时，一开始感觉的Docker的Daemon进程挂了，通过重启Docker服务来试图修复问题。 后面继续定位发现，K8s集群显示，好多计算节点Unavailable了（节点都死掉啦）。  继续分析节点不可用（Unavailable），可以发现是Kubelet好久没有给Master上报心跳了，所以Master认为节点挂了。说明不仅仅是Docker的Daemon受影响，节点的Kubelet也有受影响。 那什么情况会导致Kubelet，Docker这些主机进程都不正常呢？这个就要提到Kubernetes在调度容器时，所设计的Request和Limit这2个概念了。 Request是K8s用来调度容器到空闲计算节点上的。而Limit则会传递给Docker用于限制容器资源上限（触发上限容易被oom killer 杀掉）。前期我们为了防止作业被杀死，仅为容器设置了Request，没有设置Limit。也就是每个容器实际可以超出请求的资源量，去抢占额外的主机资源。大量容器并发时，主机资源会受影响。 考虑到虽然不杀死作业，对用户挺友好，但是平台自己受不了也不是个事。于是给所有的容器都加上了Limit限制，防止容器超限使用资源，强制用户进程运行在容器Limit资源之内，超过就Kill它。以此来确保主机进程（如Docker，Kubelet等），一定是有足够的运行资源的。 # K8s计算节点，又挂了 于是，继续跑任务。不少作业执行又双叒失败鸟~ 节点又挂了，总结版： 1. 分析日志，这次挂是因为PLEG（Pod Lifecycle Event Generator）失败。 2. PLEG异常是因为节点上面存留的历史容器太多（>500个），查询用时太久超时了。 3. 及时清理已经运行结束的容器（即使跑完的容器，还是会占用节点存储资源）。 4. 容器接口各种超时（cpu+memory是有limit保护，但是io还是会被抢占）。 5. 提升系统磁盘的io性能，防止Docker容器接口（如list等）超时。 详细版： 现象还是节点Unavailable了，查看Kubelet日志搜索心跳情况，发现有PLEG is not healthy 的错误：  于是搜索PLEG相关的Kubelet日志，发现该错误还挺多：  这个错误，是因为kubelet去list当前节点所有容器（包括已经运行结束的容器）时，超时了。看了代码：https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/pleg/generic.go#L203 kubelet判断超时的时间，3分钟的长度是写死的。所以当pod数量越多，这个超时概率越大。很多场景案例表明，节点上的累计容器数量到达500以上，容易出现PLEG问题。（此处也说明K8s可以更加Flexible一点，超时时长应该动态调整）。 缓解措施就是及时的清理已经运行完毕的容器。但是运行结束的容器一旦清理，容器记录以及容器日志也会被清理，所以需要有相应的功能来弥补这些问题（比如日志采集系统等）。 List所有容器接口，除了容器数量多，IO慢的话，也会导致超时。 这时，从后台可以看到，在投递作业期间，大量并发容器同时运行时，云硬盘的写入带宽被大量占用：  对存储池的冲击也很大：  这也导致了IO性能变很差，也会一定程度影响list容器接口超时，从而导致PLEG错误。 该问题的解决措施：尽量使用的带本地高速盘的VM，并且将多块数据盘组成Raid阵列，提高读写带宽。  这样，该VM作为K8s的节点，节点上的容器都直接读写本地盘，io性能较好。（跟大数据集群的节点用法一样了，强依赖本地shuffle~）。 在这多条措施实施后，后续多批次的作业都可以平稳的运行完。

说到数据库，大家并不陌生，因为数据库是企业的数据底座。在曾庆聪从业的多年里，可以明显感觉到相比从前，数据库变得非常热门，业务也已经不满足于传统集中式的数据库了，分布式数据库、云数据库、云原生，自主可控等技术话题被广泛讨论。这些现象的背后是数据库正在经历一个云+分布式的重要里程碑，这将深刻的影响企业对数据库的选型，乃至企业的数字化转型。曾庆聪是华为云数据库NoSQL域高级产品经理，曾就职于大型国企、外企，担任DBA和研发工作，获得Oracle OCP认证。在华为云也曾担任MySQL域产品经理，负责推动RDS、GaussDB(for MySQL)的上线和商用。在华为云负责数据库产品这些年来，他也见证了企业使用数据库方式的变革。为了满足不同业务场景的需求，华为云GaussDB也从单一的数据库升级为一个产品家族、一个统一的数据库品牌。GaussDB代表了华为先进的计算存储分离的架构，遵循“日志即数据”的原则，使用了算子下推先进的云内生性等技术，满足金融、政企、大型企业等的核心业务方方面面诉求。下面，曾庆聪将从生态和业务两方面解读华为云GaussDB的产品能力。开源到自研，开放的数据库生态GaussDB坚持开放，可以分为2大生态：上半部分是广泛认知的生态，下半部分是华为自有生态，不同的生态意味着不同的自主程度，可以适应企业的不同选择。广泛认知的生态兼容市面上主流开源数据库，其中关系型数据库有GaussDB(for MySQL)、NoSQL有GaussDB for Mongo、for Canssandra、for Redis、for Influx，和社区一样的用法但拥有更优秀的能力。华为自有生态包含两条线：一套是社区版本，一套是云上版本，两者同源。以openGauss为例，去年openGauss社区正式开源，云上的单机和主备版本下沉到了社区，经过一段时间发展后于上个月发布了第二大版本，上线了许多关键能力，社区主备版可以平滑切换至云上分布式。同时华为将持续运营社区，一同与合作伙伴、高校、开发者来促进生态繁荣。 从架构看GaussDB层次解耦的存算分离华为云GaussDB支持混合云方案，互联网和中小企业可以直接通过华为云订阅云数据库服务，而金融、政企、大企业则可以通过华为stack，在本地部署和云上体验一致的云服务，共享华为云的创新能力，并实现无缝的升级和演进。说完生态，我们来介绍一下GaussDB的架构。GaussDB架构的核心就是计算存储分离，我们先看下图右边的物理情况：上面是无状态的计算层、CPU和内存，下面是有状态的数据存储层。云原生数据库如果要实现一套统一的架构，同时支持不同的多种数据模型接入。那么它必然面临2个问题：不同的数据库SQL语法不同，数据组织形式和访问形式也不同。所以计算层又分为2个逻辑层：SQL接口层和数据索引组织层来解决这个问题。SQL接口层面向的是生态，负责兼容语法，考虑到不同的数据库SQL语法不相同，所以这一层设计无法做到统一，它的要点是接口接入，做到生态兼容。数据索引组织层面向的是数据的组织和访问，A数据库的数据组织和B数据库的数据组织是不一样的，关系型数据库和非关系型数据库数据组织也是完全不同的，所以这一层也无法做到统一，它的设计要点是插件化接入。存储层面向的是数据，这一层可以做到统一，它提供脱离语义的数据理解能力，只聚焦数据。分布式存储提供基础的分布式一致性可扩展存储能力，跨AZ、Region的部署模式，所有的数据引擎都可以部署到统一的存储层。总结下这样的架构：计算层面负责无状态的SQL语义和数据组织，通过存储管理模块与存储层进行通讯。存储层面负责有状态的数据持久化，上层无需关心数据的分布式一致性。这样全面解耦的架构，是目前所看到的最先进的分布式云原生数据库架构，通过层次解耦的存算分离，向生态兼容，数据融合，多模接入走出了关键一步。 如何解决热点数据问题，保证数据0丢失？ 基于云原生存算分离的架构，GaussDB能够轻松地解决一些长期存在的问题，比如这套架构可以避免数据库层分库分表难以优雅处理的数据分片热点问题。在分库分表中，如果分片容量不够大，就很容易出现某个分片访问压力特别大。但是存算分离的架构，加上华为存储的软硬件深度整合的数据库插件，可以做到在存储层实现数据分片的映射，打散IO。而且经由我们各研究所的算法专家，尤其是俄研所的数学家们研发的分布算法，能基于大小、IO等因素均匀分布数据块。另一方面，由于存算分离后计算层无状态，因此可以做到RTO低于10秒。基于华为DFV分布式存储软件的能力，可以做到存储RPO=0。数据库和存储深度融合，实现多副本强一致。基于存储快照级别备份，实现分钟级别的备份性能。在与500家以上不同行业的政企客户深度交流和研讨过程中，我们发现客户将其核心数据安全上云方面主要有3个顾虑：一方面，数据库繁杂的类型造成选型难与核心数据业务强绑定，所以不影响业务是客户首要考虑的问题。另一方面，客户上层应用与业务的改造范围希望尽量小，且成本在可接受范围内。第三个顾虑是上云后的核心数据是否好管理、好运维。基于多年的企业客户服务经验，以及华为自身对云化、数字化的理解，华为云提供全场景、全开放的数据库生态选择，不必担心被封闭生态锁定。同时为解决客户核心数据上云的痛点，我们打造了一站式的数据库架构+应用+数据一体化迁移方案。下面，我将分别介绍华为云GaussDB数据库的产品特性，帮助大家理解云原生数据库的技术优势是如何解决业务难点的。 GaussDB(for OpenGauss)GaussDB(for openGauss)定位是华为自有生态下的金融级+分布式数据库，该产品具备企业级复杂事务混合负载能力，同时支持优异的分布式事务，同城跨AZ部署，数据0丢失。支持1000+扩展能力，PB级海量存储等企业级数据库特性。GaussDB(for openGauss)拥有云上高可用、高可靠、高安全、弹性伸缩、一键部署、快速备份恢复、监控告警等关键能力，能为企业提供功能全面、稳定可靠、扩展性强、性能优越的企业级数据库服务。同时，开源openGauss单机主备社区版本，鼓励更多伙伴、开发者共同繁荣中国数据库生态。 GaussDB (for MySQL)GaussDB (for MySQL)定位是一写多读云原生数据库，是云原生元素最多的一款产品。通过这个架构，GaussDB for MySQL可以提供超高的性能，很好的扩展性，极高的可靠性，以及高度兼容MySQL。单节点读轻松达到100W，写50W，可以创建15个只读副本。有高达128T的存储空间，提供存储级别的跨AZ部署，数据三副本强一致，四个九的可用性，也能配合DRS服务实现MySQL的在线迁移。它非常适合对数据库有高吞吐、高可用、高可靠、异地容灾、弹性伸缩、大数据量处理需求的行业。常言道，软件优化到一定程度，不如硬件一个小的提升。华为DFV存储原生具备算子下推能力，所以GaussDB (for MySQL)在DFV上实现了算子下推的多个算子，例如聚合、MVCC等。同时也在Server层上实现优化器的并行查询，以及NDP的感知，可以判断查询是否触发NDP。同时支持PQ+NDP结合，多线程批量操作下发，以Count（*）计数操作为例，在PQ+NDP的双重加持下，有超百倍的性能提升，网络传输减少到趋于1次，仅仅返回计数结果即可。GaussDB NoSQLGaussDB NoSQL 属于云原生多模NoSQL数据库，包括MongoDB、Cassandra、Redis和InfluxDB 4种开源接口，相比较自建NoSQL数据库，它们的优势明显。基于计算存储分离架构构建，计算节点和存储可以分别扩容，以MongoDB为例，添加分片的时候不需要数据的rebalance，可以在5分钟内即添加好一个分片，效率非常高，并且在添加分片的时候对数据库性能无影响，相比于自建NoSQL数据库添加分片，效率达到了百倍的提高。计算存储分离还带来了极致的高可用，理论上可以达到N-1个节点故障容忍。举个例子：假设一个GaussDB NoSQL集群具备12个节点的分片，可以容忍11个节点故障的情况下还能提供访问。GaussDB NoSQL单个集群最大可支持96TB的数据存储，而且计算和存储之间通过高速的RDMA直连网络，带来极大的性能提升，在相同资源消耗情况下，比自建NoSQL集群性能有平均3倍的提升。在可靠性方面，DFV存储池实现数据三副本，支持业务无感的坏块修复。DFV池化技术使单台存储设备故障对数据库无影响，支持跨3AZ部署。另外，数据库存储通过DFV快照技术实现极速的备份和恢复能力，带来极致的备份恢复体验。 大规模商用正在进行时业界有句俗话叫狗粮自己吃，华为云数据库在向外部客户推出前，已经在内部的消费者云得到充分验证。消费者云整体数据量达到PB级别，单业务最大数据容量超过100T，有900套数据库遍布全球。消费者云最开始是多AZ四副本架构，由第三方组件来选主，单点故障后会选择新的主节点接替服务，实现准强一致。但是遇到AZ级别的故障，却无法依靠数据库本身来确保绝对安全。升级到GaussDB(for MySQL)之后，基于DFV存储底座的3AZ强一致，消费者云物理存储从8份（有RAID）减少到3份，从准强一致升级到强一致。分布式存储可以动态均衡压力，也能避免单点数据库访问过热，大大提升了消费者云的数据库服务能力并降低了成本。NoSQL生态方面，GaussDB帮助天地图为4亿客户提供了最佳体验。在GaussDB的架构和能力下，客户数据库系统的备份性能提高了20倍，数据恢复速度提升7倍，扩容速度和性能提升3倍，大大提升了客户数据库的可维护性和可靠性。当前，华为云GaussDB案例已经覆盖全场景客户，在1000+大客户的业务上规模化商用。无论是泛金融、政府、运营商，还是快递、电商领域，都有华为云数据库的身影。华为云数据库将继续努力，做好技术提升和帮助客户成功，为更多企业上云数字化转型提供坚实可靠的数据库底座。数据组织形式和访问形式也不同。

华为云1024程序员节云原生应用敏捷最佳实践，模拟真实操作场景，快速调动资源，深度学习和体验，帮助客户应用敏捷、业务智能，安全可信，面向未来持续演进参与活动赢大礼包！点击了解活动详情>>>活动链接：https://developer.huaweicloud.com/activity/paas.html活动时间：即日起至11月21日

华为云1024程序员节云原生应用敏捷最佳实践，模拟真实操作场景，快速调动资源，深度学习和体验，帮助客户应用敏捷、业务智能，安全可信，面向未来持续演进参与活动赢大礼包！点击了解活动详情>>>活动链接：https://developer.huaweicloud.com/activity/paas.html活动时间：即日起至11月21日

Gartner于今日发布企业机构在2022年需要探索的重要战略技术趋势。分析师们在本周四举行的Gartner IT Symposium/Xpo峰会美洲站期间公布了他们的研究结果。Gartner研究副总裁David Groombridge表示：“首席执行官和董事会正在设法通过与客户建立直接数字联系来实现增长，因此首席信息官的优先事项必须满足这些业务要求，而这些要求贯穿于Gartner的2022年重要战略技术趋势。”“首席信息官必须找到能够成倍增加IT力量的方法，从而实现增长和创新并创建可扩展、有韧性的技术基础，通过这一可扩展性释放用于数字投资的现金。这些要求构成了今年趋势的三个主题：工程化信任、塑造变化和加速增长。”2022年重要战略技术趋势有：生成式人工智能（GenerativeArtificial Intelligence）即将上市的生成式人工智能是最引人注目和最强大的人工智能技术之一。该机器学习方法从其数据中学习内容或对象，并运用数据生成全新、完全原创的实际工件。生成式人工智能可用于多种活动，如创建软件代码、促进药物研发和有针对性的营销，但该技术也会被滥用于诈骗、欺诈、政治造谣、伪造身份等。Gartner预计到2025年，生成式人工智能将占所有生成数据的10%，而目前这一比例还不到1%。数据编织（Data Fabric）在过去的十年里，数据和应用孤岛的数量激增，而数据和分析（D&A）团队的技能型人才数量却保持不变，甚至下降。作为一种跨平台和业务用户的灵活、弹性数据整合方式，数据编织能够简化企业机构的数据整合基础设施并创建一个可扩展架构来减少大多数数据和分析团队因整合难度上升而出现的技术债务。数据编织的真正价值在于它能够通过内置的分析技术动态改进数据的使用，使数据管理工作量减少70%并加快价值实现时间。分布式企业（DistributedEnterprise）随着远程和混合工作模式的增加，以办公室为中心的传统企业机构正在演变成由分散在各地的工作者组成的分布式企业。Groombridge表示：“这就要求首席信息官通过重大技术和服务变革提供无摩擦工作体验，不过事情总有两面性：这项技术会对业务模式产生影响。从零售到教育，每家企业机构都必须重新配置交付模式才能支持分布式服务。两年前，全世界没有人想到自己能在数字试衣间里试穿衣服。”Gartner预计，到2023年，75%充分发挥分布式企业效益的企业机构将实现比竞争对手快25%的收入增长。云原生平台（Cloud-NativePlatform，CNP）为了真正能够在任何地方提供数字能力，企业必须放弃熟悉的“直接迁移”并转向CNP。CNP运用云计算的核心能力，向使用互联网技术的技术创造者提供可扩展的弹性IT相关能力“即服务”，从而加快价值实现时间并降低成本。因此，Gartner预测到2025年，云原生平台将成为95%以上新数字倡议的基础，而在2021年这一比例只有不到40%。自治系统（Autonomic Systems）随着企业的发展，传统的编程或简单的自动化将无法扩展。自治系统是可以从所在环境中学习的自我管理型物理或软件系统。与自动化甚至自主系统不同，自治系统无需外部软件更新就可以动态修改自己的算法，使它们能够像人类一样迅速适应现场的新情况。Groombridge表示：“自治行为已因为近期被部署在复杂的安全环境中而为人所知。而从长远看，这项技术将被普遍应用于机器人、无人机、制造机器和智能空间等物理系统。”决策智能（DecisionIntelligence，DI）一家企业机构的决策能力是其竞争优势的重要来源，而如今这个时代对这项能力的要求也越来越高。决策智能是一门实用的学科。该学科通过清楚理解并精心设计做出决策的方式以及根据反馈评估、管理和改进结果的方式来改进决策。Gartner预测在未来两年，三分之一的大型企业机构将使用决策智能实现结构化决策，进而提高竞争优势。组装式应用程序（Composable Applications）在不断变化的业务环境中，业务适应性需求能够引导企业转向支持快速、安全和高效应用变化的技术架构。可组合的应用架构增强了这种适应性，而采用可组合方法的企业机构在新功能的实现速度上将比竞争对手快80%。Groombridge表示：“在动荡的时代，可组合的业务原则帮助企业机构驾驭对业务韧性和增长至关重要的加速变化。没有它的现代企业机构可能会失去在市场中的前进动力和客户忠诚度。”超级自动化（Hyperautomation）超自动化通过快速识别、审核和自动执行尽可能多的流程来实现加速增长和业务韧性。Groombridge表示：“Gartner的研究表明，表现最好的超自动化团队专注于三个关键优先事项：提高工作质量、加快业务流程和增强决策敏捷性。在过去的一年中，业务技术专家平均支持4.2项自动化倡议。”隐私增强计算（Privacy-EnhancingComputation，PEC）除了应对不断成熟的国际隐私和数据保护法律外，首席信息官还必须避免因隐私事件而导致客户信任下降。因此，Gartner预计到2025年，60%的大型企业机构将使用一种或多种隐私增强计算技术。在数据、软件或硬件层面保护个人和敏感信息的PEC技术能够在不影响保密性或隐私的情况下安全地共享、汇集和分析数据。目前这项技术被应用于许多垂直领域以及公有云基础设施（例如可信的执行环境）。网络安全网格（Cybersecurity Mesh）Groombridge表示：“数据贯穿了今年的许多趋势，但只有当企业能够信任数据时，数据才会变得有用。如今，资产和用户可能出现在任何地方，这意味着传统的安全边界已经消失。这就需要有网络安全网格架构（CSMA）。”CSMA帮助提供一体化安全结构和态势，为任何位置的任何资产提供安全保障。到2024年，使用CSMA一体化安全工具组成一个合作生态系统的企业机构能够将单项安全事件的财务影响平均减少90%。人工智能工程化（AI Engineering）IT领导人想方设法地将人工智能集成到应用中，在从未投入生产的人工智能项目上浪费时间和金钱或在人工智能解决方案发布后努力保持它们的价值。人工智能工程化是一种实现人工智能模型操作化的综合方法。Groombridge表示：“从事人工智能工作的混合团队是否真正能够为他们的企业机构实现差异化，取决于他们通过快速人工智能变革不断提升价值的能力。到2025年，10%建立人工智能工程化最佳实践的企业从其人工智能工作中产生的价值将至少比90%未建立该实践的企业高出三倍。”全面体验（Total Experience，TX）全面体验是一项结合客户体验（CX）、员工体验（EX）、用户体验（UX）和多重体验（MX）学科的业务战略。TX的目标是提升客户和员工的信心、满意度、忠诚度和拥护度。企业机构将通过实现具有适应性和韧性的TX业务成果来增加收入和利润。文章转载至云技术公众号 https://mp.weixin.qq.com/s/4nsMspbnAq_o5JY_pyDndg  免责声明：转载文章版权归原作者所有。如涉及作品内容、版权等问题，请及时联系文章编辑！

一个时代有一个时代的基调，“Open Source is eating the world”的声音言犹在耳，一个属于云计算的时代早就不经意来临。十年前，中国的云计算市场尚处于襁褓之中，市场规模只有10余亿。此后十年，云计算市场迎来爆发式增长，年均增速超过50%，2020年市场规模已超过2000亿元，成为中国数字化升级的“顶梁柱”产业。倏忽十载，云计算产业从弱小到强大，从单一的云基础服务裂变为混合云、云原生、云安全等更契合企业业务需求的多元云服务，迈进了百花齐放的大繁荣时代。随着中国企业数字化转型不断深入，云计算已经脱离简单的市场扩张、让企业上云用云的早期阶段，逐步进入到云原生重构IT架构、上云用云兼顾优化治理、原生安全加速应用的深水区。如今，云计算走到了哪个阶段？企业应该加强哪些方面的云计算能力？如何将自身业务与云计算更好地衔接融合？近日，在2021可信云大会上，中国信息通信研究院云计算与大数据研究所所长何宝宏、中国信通院云计算与大数据研究所副所长栗蔚共同就云计算十年来的发展脉络回顾总结，对云计算产业发展的变革趋势进行全面剖析，并就云计算未来趋势开展深入解读。中国信息通信研究院云计算与大数据研究所所长何宝宏数字化转型迎来分水岭云原生加速重构IT基础设施近两年，“云原生”堪称云计算领域最热的名词之一，其出现不仅将原有IT基础设施重构为云原生基础设施，提供更高效的资源，还为企业打造更敏捷的应用开发、交付运维能力，加速企业应用的敏捷创新。从简单迁移上云的“On Cloud”到在云上基于云原生而重构企业应用的“In Cloud”，云原生成为数字化转型的重要分水岭，其要求企业既要继承过去，又要连接未来；既要立而不破，又要持续进化。根据IDC预计，到2022年，90%的新应用将采用微服务架构，35%的生产环境应用是云原生。此外，在Gartner的报告中，云原生技术也正在向应用场景、技术、生态三个方面快速演进，并将扩展到更多应用场景，比如在混合云和多云管理领域，以及边缘层的应用等。在应用价值方面，云原生能够支撑业务应用的通用技术能力下沉到基础设施，在业务应用完整生命周期中提供持续稳定服务，最大化实现云的价值，让企业在资源配置、产品交付、系统架构等方面获得更高的效能，从而可以将更多精力放在业务视角的响应、分析和决策中，使企业在竞争激烈、需求多变的市场环境中具有更强的创新优势。对于这一趋势，何宝宏表示，企业对于竞争的核心诉求正在转到注重商业模式的改变、快速感知并响应用户的需求，这在很大程度上将倒逼技术架构变革，使架构的支撑焦点由资源转向应用。为此，云原生将在发挥云计算应用价值方面产生积极作用。未来，无论是ERP、CRM等系统应用还是底层IT基础设施，都会越来越趋向于云原生，这将是近些年云计算最大的趋势。不同企业实现应用现代化的路线各不一样，例如：有先进行容器化改造的，有先做微服务架构改造的，也有直接在上云迁移的过程中同步实现微服务改造的，另加之企业内部环境各不一样，所以企业在实现应用现代化进程中遇到的挑战也不尽相同。他们往往会面临很多挑战，包括：如何让运转着的旧系统和新应用之间做到无缝的衔接？如何快速敏捷地完成应用的集成，以提高可持续的交付能力？以及如何在混合多云环境下，最大程度地降低架构转型的技术风险等。在栗蔚看来，云计算融合新技术，带动云原生进入黄金发展期。云原生融合新型信息技术，改变数、智、算的应用方式。云原生带动技术架构、应用效能、云化效益的全方位提升，传统行业用户逐步对外围系统、次核心系统、核心系统进行不同程度的云原生化改造。云原生进一步降低技术门槛，深化云数融合、云智融合、高性能计算的发展，推动云数智高质量融合发展。中国信通院云计算与大数据研究所副所长栗蔚注重云计算应用效能优化治理成为企业上云后突出诉求中国信通院最新发布的《云计算白皮书》显示，2020年云计算市场整体规模达到2091亿元，增速56.6%。对于很多企业，应用云计算为企业提升了管理效能，但也带来了相当大的复杂性。如果没有适当地策略，可能会妨碍业务的正常运行。所以随着企业用云程度的加深，企业关注点从开始上云的咨询、迁移，逐步地转到上云后的优化。企业需要仔细考虑如何管理、优化和使用云计算服务，从而可以通过降低云管理成本，进一步提升业务的数字化转型效果。对此，云优化治理成为很多企业上云后改善性能、降低成本、提升效率的主要选择，其能够给企业上云策略制定、线路规划、采用实施、云上优化进行全生命周期的优化提升，为企业数字化转型提供新的动力。在谈及云优化治理将如何发挥作用时，何宝宏认为，企业在上云过程中对价格、安全、服务能力等尤为关注，对云品牌的关注度反而降低，这也反映出企业在云计算应用方面的理念日趋成熟。优化治理是云计算永恒的主题，相比以前关注重心只停留在基础设施层面，现在更多地落到应用层面，优化治理不仅能够改善企业上云后在性能、应用、架构等方面的能力，还将充分发挥云计算的效能和价值，让企业更懂云、更好用云。混合云管理模式演变进行时是当前企业上云的最佳路径云计算最终的发展趋势将可能是朝私有云和公有云的结合——混合云发展。因为没有绝对的私有云，也没有绝对的公有云，纯粹的公有云和纯粹的私有云都有其局限性，而混合云将能够同时避免他们的劣势而发挥他们的优势，已成为企业上云的主流模式。根据中国信通院报告，相比全球市场混合云高达82%的部署比例来说，国内混合云市场由于起步较晚，这一数字则刚刚超过50%。从混合云的特性来看，要实现统一纳管、高效运维，混合云解决方案必须具备在多云管理、云网协同、安全管理、云原生等四个维度中的强大能力。这些关键能力将决定用户应用的部署位置、交互模式和协同效率，进而对业务产生巨大的影响。同时，混合云的管理模式也在不断演进，过去私有云和公有云的协作很多是利用公有云做灾备，或者对计算需求峰值的性能补充，这是合作互补的模式，但现在本地和公有云的协作越来越密切和同步。现在用户开始把不同的应用负载部署到更合适的位置，而不是把所有的应用部署在一个地方。不同的应用根据其特点分别部署到本地、边缘和公有云，混合云的协作管理正在成为趋势。推动新型信任体系构建零信任与云原生安全持续融合从业界今年的发展来看，无论是Gartner认为信任和弹性是自适应安全的两个原则，还是“零信任”理念成为业界热议的流行词，都说明整个行业已经意识到，简单堆砌安全机制已经无法抵御日渐复杂的应用场景和攻击团伙，所以回归安全的本源，思考如何构建信任体系，成为当前一种独特的现象。随着零信任的理念西风东渐，越来越多的国内机构和企业在考虑通过零信任重新构建新的业务访问模型和体系。早期以边界为核心的传统安全思维方式需要被打破，考虑到系统、资源之间的交互越来越频繁，如今的安全需要转向以用户身份为核心的安全，要持续性验证用户身份的真实性。面对零信任与云原生的融合，何宝宏将其看作是发展到一定阶段的必然趋势。零信任从私有化部署向SaaS服务演进，SD-WAN通过集成零信任实现安全防护边缘上零信任实现弹性扩展，能够应对海量访问的请求，同时微隔离作为零信任的关键技术，对云类东西向流量进行访问控制，弥补传统安全防护机制在云环境应用的不足。如今，中国数字化建设的大幕已经开启。为了让行业更好应用创新的云计算技术，中国信通院积极联合各行业龙头企业探索企业高效用云的有效路径，围绕混合云、云原生、零信任、云优化治理等热点技术领域发布一系列标准和认证，成功构建起国内权威的新型云计算安全标准体系。通过对数字时代下云计算发展的深刻洞察，中国信通院不仅实现了相关标准规范的前瞻性布局，还为体系技术的落地应用提供参考和指引，进一步夯实云计算新基建的底座，为中国数字经济发展和企业数字化转型升级打下坚实基础。站在未来十年的新起点，云计算还将裂变出无限的机会和可能，带着人们在探索的路上发现更多未知的精彩。【科技云报道原创】转载请注明“科技云报道”并附本文链接https://new.qq.com/rain/a/20210802A04ODI00

＞＞点击跳转至活动首页＜＜活动已开奖，中奖名单如下所示。请获奖的用户填写华为云2021星云闪耀1024程序员节获奖信息收集表（点击填写），12月12日前填写有效，奖品将于15个工作日内发出哦！活动奖励以及获取线索说明：a. 线索说明：完成领取免费产品+体验任意任务（必须在本帖回帖）将获取星耀宝盒谜题（破解后获取谜题11）b. 奖励说明：在所有完成任务的开发者中抽取10人，每人奖励酷睿冰尊A9 笔记本散热器1个活动时间：2021年10月20日~2021年11月21日 参与方式：＞＞点击获取PaaS空间站体验任务＜＜完成领取免费产品+体验任意任务可获取线索：＞＞点击获取PaaS空间站体验任务＜＜1.在PaaS空间站活动页试用专区开通任意一款免费或付费资源2.完成PaaS空间站任意一个体验任务特别说明：请务必按照以下格式要求进行回帖，否则无法计算奖励：1、华为云账号：xxx（即右上角的字母数字组合ID）2、实践感想：（产品体验建议、感想等）3、任务截图：1.成功领取任意一个免费资源截图2.完成任意一个实践任务截图4、完成任务后（完成回帖），小助手会在活动期间的工作日每天上午9点-下午4点，为符合活动要求的用户通过社区私信星耀宝盒谜题，码豆将在活动结束后统一发放。Tips：1、请务必使用个人账号参与活动（IAM、企业账号等账号参与无效）。2、所有获得华为电子产品奖项的获奖用户，请于获奖后3日内完成实名认证，否则视为放弃奖励。3、 本次活动抽奖将采用巨公摇号平台（https://www.jugong.wang/random-portal/）如您对评奖方式有异议，请勿参加本次活动。

上期《一文带你理解云原生|云原生全景指南（上）》带您看了云原生全景指南，说明了为什么要上云、上云的弊端、云原生概述、容器以及容器编排的问题，这次我们接着了解服务网格、云原生主流组件以及其常用网络技术，最后，对云原生做一个总结。     6. 服务网格 Istio    6.1 服务网格概述    6.2 Istio 控制面4.3 Istio 数据面     7 云原生-主流组件   7.1 Prometheus   7.2 Grafana   7.3 Elasticsearch + Fluentd + Kibana   7.4 Jaeger   7.5 Chaos Engineering    8 云原生-常用网络技术   8.1 主机网络iptables是运行在用户空间的应用软件，通过控制Linux 内核 netfilter，来管理网络数据包的处理和转发。存在“表（tables）”、“链（chain）”和“规则（rules）”三个层面：每个“表”指的是不同类型的数据包处理流程，例如 filter 表表示进行数据包过滤，而 NAT 表针对连接进行地址转换操作；每个表中又可以存在多个“链”，系统按照预订的规则将数据包通过某个内建链，例如将从本机发出的数据通过 OUTPUT 链；在“链”中可以存在若干“规则”，这些规则会被逐一进行匹配，如果匹配，可以执行相应的动作，例如修改数据包，或者跳转。   8.2 Underlay 网络技术VLAN 虚拟局域网：是将一个物理 LAN 在逻辑上划分成多个广播域的通信技术。每个 VLAN 是一个广播域，VLAN 内的主机间通信就和在一个 LAN 内一样。没有划分 VLAN：LAN 局域网：优势：简单，静态，IP 地址与交换机关联；劣势：迁移域受限，不能机房内随意迁移。交换机下 IP 需要提前规划好，约束虚拟比。划分 VLAN：虚拟局域网：优势：IP 地址与交换机无关，虚拟机可以在机房范围内迁移。VLAN 间则不能直接互通，这样广播报文就被限制在一个 VLAN 内。有人会问：交换如何区分不同 VLAN？交换机能够分辨不同 VLAN 的报文，需要在报文中添加标识 VLAN 信息的字段。数据帧中的VID（VLAN ID）字段标识了该数据帧所属的 VLAN，数据帧只能在其所属 VLAN 内进行传输。   8.3 Overlay 网络技术VXLAN 虚拟扩展局域网：是对传统 VLAN 协议的一种扩展；是一种网络虚拟化技术，试图改善云计算部署的可扩展性问题。解决哪些问题？vlan 的数量限制（12bit->24bit），VLAN 报文 Header 预留长度只有 12bit，只支持 4096 个终端；VNI（VXLAN Network Index）标识某条指定隧道；不改变 IP 实现服务器迁移。传统二三层网络架构限制了虚拟机的动态迁移范围。VXLAN 在两台 TOR 交换机之间建立一条隧道，将服务器发出的原始数据帧加以“包装”，好让原始报文可以在承载网络（比如 IP 网络）上传输。当到达目的服务器所连接的 TOR 交换机后，离开 VXLAN 隧道，并将原始数据帧恢复出来，继续转发给目的服务器。VXLAN 将整个数据中心基础网络虚拟成了一台巨大的“二层交换机”VXLAN 网络模型UDP 封装（L2 over L4）：将 L2 的以太帧封装到 UDP 报文即（L2overL4）中，并在 L3 网络中传输；VTEP，VXLAN 隧道端点，对 VXLAN 报文进行封装和解封装；VNI，VXLAN 隧道标识，用于区分不同 VXLAN 隧道。矢量性协议：使用基于路径、网络策略或规则集来决定路由；AS（自治域）：AS 是指在一个实体管辖下的拥有相同选路策略的 IP 网络；BGP 网络中的每个 AS 都被分配一个唯一的 AS 号，用于区分不同的 AS；eBGP（域外 BGP）：运行于不同 AS 之间的 BGP，为了防止 AS 间产生环路；为了防止 AS 间产生环路，当 BGP 设备接收 EBGP 对等体发送的路由时，会将带有本地 AS 号的路由丢弃；iBGP（域内 BGP）：运行于同一 AS 内部的 BGP，为了防止 AS 内产生环路；RR（路由反射器）：通过集中反射同步，解决全连通的网状网格结构路由同步问题。EBGP+IBGP 实现 AS 间的路由传递：一个常见的 IP 骨干网的拓扑结构，骨干层和汇聚层分别是两个自治系统，AS100 有两个出口设备 SwitchC 和 SwitchD，两个 AS 之间需要进行路由互通。    9 总结-云原生云原生应用：docker 应用打包、发布、运行，Kubernetes 服务部署和集群管理，Istio 构建服务治理能力。云计算以“资源”为中心，关键技术：虚拟化：SDX，NFV；资源池化：弹性快速扩缩容；多租化：提升云厂商的资源利用率；典型代表：计算、网络、存储三大基础设施的云化。云计算以“应用”为中心，关键导向：设计之初，关注更好适应云，充分发挥云优势；云原生已成为企业数字创新的最短路径；云原生一系列 IAAS、PAAS、SAAS 层技术，支撑产品高效交付、稳定运维、持续运营。【私人观点】以“资源”为中心的云，将成为“底层基础设施”，利用云原生以“应用”为中心赋能自身业务；云的时代，已经来临。作为云的使用者、从业者，更多思考如何利用云赋能业务产品；商业市场模式从“大鱼吃小鱼”靠信息不对称，向“快鱼吃慢鱼”转变。我们必须利用趋势，拥抱云原生。    10 鸣谢以下小伙伴给出宝贵建议，非常感谢。鸣谢 CDG-FiT 线：Hawkliu、Cafeeqiu鸣谢腾讯 OTeam：Kubernetes 开源协同技术讲师    11 学习资料《SRE Google 运维解密》《Kubernetes 权威指南》《Kubernetes in Action》《深入剖析 Kubernetes》《Docker 容器与容器云》-浙大《云原生服务网格 Istio》华为丛书《Kubernetes 开源协同技术课程》CNCF 官网：https：//www.cncf.io/Huawei-Cloud Native : https：//github.com/huawei-cloudnativeDocker 官方文档：https：//docs.docker.com/Kubernetes 官网：https：//kubernetes.io/Istio 官网：https：//istio.io/- END -*注：文章源自：https://blog.csdn.net/lianhunqianr1/article/details/118037321一文带你理解云原生|云原生全景指南（上）———————————————————————————————————————————————【   AOC社区  】AOC (Agile Open Container)集成了华为网络云化平台，以及从网络运维中抽象总结出的业务框架，以Yang模型为基础，提供了对网络的开放可编程能力。社区为大家提供了关于数通网络开放可编程一站式学习、体验、认证、交流的平台。以视频为载体构建了在线学习AOC的整个学习、认证体系。另外还提供了SDK、demo样例、以及API手册、开发指导等文档的下载，方便大家进行新项目的开发。

hi， 大家好，如今几乎所有大厂都将容器和K8s列入未来的战略重心，K8s可能将成为下一代分布式操作系统，今天分享一篇很经典云原生文章（万字雄文），希望可以帮大家彻底了解到底什么是云原生。本文是一篇云原生的关键知识科普，希望给大家提供一扇云原生的“窗户”，传达三个目标：1、透过窗户看到一棵大树代表：云原生的蓝图全貌；2、树上会有很多核心树干代表：云原生的关键技术；3、希望树干上能摘到果实代表：云原生对我的启发。开始阅读文章前，请角色切换：设想你作为一位中小型 IT 公司 CTO，面对云原生技术决策，你需要回答两个问题：    1、为什么需要上云？    2、上云有何弊端？作为一家公司的技术决策者，必须理解上云的利与弊，并结合公司各阶段发展目标给出最适合的技术方案。    3、 云原生-概述    3.1 云原生-定义云原生的定义，业界也是“百家争鸣”各持观点，从技术视角理解云原生会相对清晰。云原生的关键技术包括：• 微服务架构：服务与服务之间通过高内聚低耦合的方式交互；• 容器：作为微服务的最佳载体，提供了一个自包含的打包方式；• 容器编排：解决了微服务在生产环境的部署问题；• 服务网络：作为基础设施，解决了服务之间的通信；• 不可变基础：设施提升发布效率，方便快速扩展；• 声明式 API:让系统更加健壮；命令式 API：可以直接发出让服务器执行的命令，例如：“运行容器”、”停止容器”等；声明式 API：可以声明期望的状态，系统将不断地调整实际状态，直到与期望状态保持一致。• DevOps：缩短研发周期，增加部署频率，更安全地方便：Culture ：达成共识Automation：基础设施自动化Measurement：可度量Sharing：你中有我，我中有你【私人观点】云原生的定义：应用因云而生，即云原生。应用原生被设计为在云上以最佳方式运行，充分发挥云的优势，是上云的最短路径。   3.2 云原生-技术生态   3.3 云原生-关键技术云原生关键技术包括：微服务，容器，容器编排，服务网络，不可变基础，声明式 API。   3.3.1 微服务微服务是一种用于构建应用的架构方案。将一个复杂的应用拆分成多个独立自治的服务，服务与服务间通过“高内聚低耦合”的形式交互。微服务典型架构包括：服务重构：单体改造成符合业务的微服务架构；服务注册与发现：微服务模块间的服务生命周期管理；服务网关：身份认证、路由服务、限流防刷、日志统计；服务通信：通信技术方案如，RPC vs REST vs 异步消息；可靠性：服务优雅降级，容灾，熔断，多副本。  3.3.2 容器容器是一种打包应用的方式，可以打包应用中的所有软件和软件所依赖的环境，并可实现跨平台部署。容器关键技术：namespac 视图隔离，cgroups 资源隔离 ，Union File System 联合文件系统。容器优势：更高效的利用资源；更快速的启动时间；一致性的运行环境。  3.3.3 容器编排容器编排包括：自动化管理和协调容器的系统，专注于容器的生命周期管理和调度。核心功能：容器调度：依据策略完成容器与母机绑定；资源管理：CPU、MEM、GPU、Ports、Device；服务管理：负载均衡、健康检查。  3.3.4 服务网格服务网格（Service Mesh）是致力于解决服务间通讯的基础设施层。Service Mesh 应对云原生应用的复杂服务拓扑，提供可靠的通信传递；通过一组轻量级网络代理（Sidecar proxy），与应用程序代码部署在一起来实现，且对应用程序透明。Service Mesh 特点：应用程序间通讯的中间层；轻量级网络代理，应用程序无感知；解耦应用的重试、监控、追踪、服务发现。Service Mesh 主流组件：Istio、MOSN（Modular Open Smart Network）Linkerd。  3.3.5 不可变基础设施不可变基础设施（Immutable Infrastructure）（宠物 VS 牲畜）任何基础设施实例（服务器、容器等各种软硬件）一旦创建之后便成为一种只读状态，不可对其进行任何更改；如果需要修改或升级实例，唯一方式是创建一批新实例以替换。不可变基础设施的优势提升发布应用效率；没有雪花服务器；快速水平扩展。  3.3.6 声明式 API命令式 API：可直接发出让服务器执行的命令，例如：“运行容器”、“停止容器”等；声明式 API：可声明期望的状态，系统将不断地调整实际状态，直到与期望状态保持一致。为什么声明式使系统更加健壮？可以类比理解成自动化工程学的闭环自适应模型。  3.3.7 DevOpsDevOps 目标 ：缩短开发周期，增加部署频率，更可靠地发布。从历史上开发和运维相对孤立到开发和运维之间建立合作，可以增加信任，更快速地发布新版本。DevOps 是一组过程，方法和系统的统称包括：Culture：文化是 DevOps 中的第一成功要素。由于目标不同，开发和运维形成一堵墙，DevOps 通过建立开发和运维之间合作和沟通的文化来消除墙。Automation：自动化软件的开发和交付，通常包含持续集成，持续交付和持续部署，云原生时代还包括基础架构的自动化，即 IaC(Infrastructureas code)。Measurement：度量尤其重要，通过客观的测量来确定正在发生的事情的真实性，验证是否按预期进行改变。并为不同职能部门达成一致建立客观基础。Sharing：开发和运维团队之间长期存在摩擦的主要原因是缺乏共同的基础。开发参与运维值班，参与软件的部署和发布，运维参与架构设计。    4 容器-Docker   4.1 Docker 概述为什么学习容器技术?云时代从业者：Docker 已成云平台运行分布式、微服务化应用的行业标准。作为有技术追求的程序员，有必要理解云原生的关键技术：容器。Docker 核心概念：镜像、容器、仓库。镜像(Image)：一个只读模板；由一堆只读层（read-only layer）重叠；统一文件系统（UnionFileSystem）整合成统一视角。容器(Container)：通过镜像创建的相互隔离的运行实例；容器与镜像区别：最上面那一层可读可写层；运行态容器定义：一个可读写的统一文件系统，加上隔离的进程空间，以及包含在其中的应用进程。仓库（Repository）：集中存放镜像文件的地方；Docker Registry 可包含多个仓库（Repository），每个仓库可包含多个标签（Tag），每个标签对应一个镜像。   4.2 Docker 关键技术   4.2.1 Namespace 视图隔离Linux namespace 是一种内核级别的环境隔离机制，使得其中的进程好像拥有独立的系统环境。Network namespace 在 Linux 中创建相互隔离的网络视图，每个网络名字空间都有自己独立的网络配置，包括：网络设备、路由表、IPTables 规则，路由表、网络协议栈等。（默认操作是主机默认网络名字空间）  4.2.2 control groups（资源隔离）Linux Control Group 是内核用于限制进程组资源使用的功能。资源包括：CPU，内存，磁盘 IO 等。  4.2.3 Union File System（联合文件系统）Union File System， 联合文件系统：将多个不同位置的目录联合挂载(union mount)到同一个目录下。Docker 利用联合挂载能力，将容器镜像里的多层内容呈现为统一的 rootfs(根文件系统)；Rootfs 打包整个操作系统的文件和目录，是应用运行所需要的最完整的“依赖库”。   4.3 Docker-网络技术Bridge 模式：Docker0 充当网桥，在默认情况下，被限制在 Network Namespace 里的容器进程，是通过 Veth Pair 设备 +宿主机网桥的方式，实现跟同其他容器的数据交换。一旦一张虚拟网卡被“插”在网桥上，它就会变成该网桥的“从设备”。从设备会被“剥夺”调用网络协议栈处理数据包的资格，从而“降级”成为网桥上的一个端口。而这个端口唯一的作用，就是接收流入的数据包，然后把这些数据包全部交给对应的网桥，由网桥完成转发或者丢弃。Veth 提供一种连接两个 network namespace 的方法。Veth 是 Linux 中一种虚拟以太设备，总是成对出现常被称为 Veth pair。可以实现点对点的虚拟连接，可看成一条连接两张网卡的网线。一端网卡在容器的 Network Namespace 上，另一端网卡在宿主机 Network Namespace 上。任何一张网卡发送的数据包，都可以对端的网卡上收到。在物理网络中，如果需要连接多个主机，会用交换机。在 Linux 中，能够起到虚拟交换机作用的网络设备，是网桥（Bridge）。它是一个工作在数据链路层的设备，主要功能是根据 MAC 地址学习来将数据包转发到网桥的不同端口（Port）上。Bridge 网桥类似交换机，两个以上 namespace 接入同一个二层网络。veth pair 一端虚拟网卡加入到 namespace，另一端到网桥上。路由 routing是通过互联的网络把信息从源地址传输到目的地址的活动，发生在 OSI 模型的第三层（网络层）。Linux 内核提供 IPForwarding 功能，实现不同子网接口间转发 IP 数据包。路由器工作原理：路由器上有多个网络接口，每个网络接口处于不同的三层子网上。根据内部路由转发表将从一个网络接口中收到的数据包转发到另一个网络接口，实现不同三层子网间互通。    5 容器编排-Kubernetes   5.1 概述&架构&核心组件我认为 Kubernetes 最大成功：让容器应用进入大规模工业生产。Kubernetes 的提供特性，几乎覆盖一个分布式系统在生产环境运行的所有关键事项。包括：Automated rollouts and rollbacks(自动化上线和回滚)使用 Kubernetes 描述已部署容器的所需状态，受控的速率将实际状态更改为期望状态。Self-healing(自我修复)Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。Service discovery and load balancing(服务发现与负载均衡)Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果进入容器的流量很大，Kubernetes 可以负载均衡并分配网络流量，从而实现部署稳定。Storage orchestration(存储编排)Kubernetes 允许你自动挂载选择的存储系统，例如本地存储、公厂商等。Automatic bin packing(自动装箱)Kubernetes 允许指定每个容器所需 CPU 和内存（RAM）。当容器指定资源请求时，Kubernetes 可以做出更好的决策来管理容器的资源。Secret and configuration management(安全和配置管理)Kubernetes 允许存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。你可在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥。API Service: Kubernetes 各组件通信中枢。资源操作的唯一入口，并提供认证、授权、访问控制、API 注册和发现等机制；为 Pod， Deployment， Service 等各种对象提供 Restful 接口；与 etcd 交互的唯一组件。Scheduler：负责资源调度，按照预定调度策略将 Pod 调度到相应的机器。Predicates(断言)：淘汰制Priorities（优先级）：权重计算总分。Controller manager：负责维护集群的状态，比如故障检测、自动扩展、滚动更新等。etcd：分布式的 K-V 存储，独立于 Kubernetes 的开源组件。主要存储关键的原数据，支持水平扩容保障元数据的高可用性；基于Raft 算法实现强一致性，独特的watch 机制是 Kubernetes 设计的关键。kubelet ：负责维护 Pod 的生命周期，同时负责 Volume（CVI）和网络（CNI）的管理。kube-proxy：负责为 Service 提供 cluster 内部的服务发现和负载均衡kube-proxy 通过在节点上添加 iptables 规则以及从中移除这些规则来管理此端口重新映射过程。控制器模式的设计思想：容器类比集装箱，集装箱固然好用，但是如果它各面光秃秃的，吊车还怎么把它吊起来摆放好呢？Pod 对象其实就是容器的升级版，对容器进行组合，添加更多属性和字段。就好比在集装箱上安装了吊环，Kubernetes 这台“吊车”可以更轻松操作容器。然而Kubernetes 操作这些“集装箱”的逻辑都是由控制器完成的。Kubernetes 通过“控制器模式” 的设计思想，来统一编排各种对象和资源。   5.2 部署&资源控制&存储Kubernetes-集群部署架构所有组件通过 kubelet staticpod 的方式启动保证宿主机各组件的高可用，systemd 提供 kubelet 的高可用；每个 Master 的使用 hostNetwork 网络，controller-manager 和 scheduler 通过 localhost 连接到本节点 apiserver；controller-manager 和 scheduler 的高可用通过自身提供的 leader 选举功能（--leader-elect=true）；apiserver 高可用，可通过经典的 haporxy+keepalived 保证，集群对外暴露 VIP;外部访问通过 TLS 证书，在 LB 节点做 TLS Termination，LB 出来 http 请求到对应 apiserver 实例。apiserver 到 kubelet、kube-proxy 类似。    5.3 Kubernetes-网络技术     3.3.1 对外服务Service是一个逻辑概念，一组提供相同功能 Pods 的逻辑集合，并提供四层负载统一入口和定义访问策略。交互流程：Service 可通过标签选取后端服务。匹配标签的 Pod IP 和端口列表组成 endpoints，有 kube-proxy 负责均衡到对应 endpoint。为什么需要 service？对外提供入口（容器如何被外部访问）；克服 Pod 动态性（Pod IP 不一定可以稳定依赖）；服务发现和稳定的服务（ Pod 服务发现、负载、高可用）。Service Type 四种方式Cluster IP：配置 endpoint 列表；NodePort：默认端口范围：30000-32767，通过 nodeIP：nodePort 访问 ；LoadBalancer：适用于公有云，云厂商实现负载，配置 LoadBalance 到 podIP ；ExternalName：服务通过 DNS CNAME 记录方式转发到指定的域名。Service Type 为 Cluster IP：Kubernetes 的默认服务，配置 endpoint 列表，可以通过 proxy 模式来访问该对应服务；类似通过 Nginx 实现集群的 VIP。Service Type 为 Node Port：在集群所有节点上开放特定端口，任何发送到该端口流量借助 Service 的 Iptables 规则链发送到后端 Pod。注意事项：每个服务对应一个端口，端口范围只有 30000–32767；需要感知和发现节点变化，流量转发增加 SNAT 流程，Iptables 规则会成倍增长。适用场景：服务高可用性要求不高或成本不敏感，例如：样例服务或临时服务。Service Type 为 Load Balancer：对公网暴露服务建议采用此方式，Service 没有对其行为做任何规范，依赖云厂商 LB 具体实现（云厂商收费服务）如：腾讯公有云：CLB。Service Type 为 External Name ：DNS 作为服务发现机制，在集群内提供服务名到 Cluster IP 的解析。CoreDNS ：DNS 服务，CNCF 第 04 个毕业项目，KUBERNETES 的 1.11 版本已支持。CoreDNS 实现的高性能、插件式、易扩展的 DNS 服务端，支持自定义 DNS 记录及配置 upstream DNS Server，可以统一管理 Kubernetes 基于服务的内部 DNS。Ingress Controller：定义入流量规则，可做七层 HTTP 负载君合。Egress Controller：定义出流量规则。交互流程：通过与 Kubernetes API 交互，动态感知集群 Ingress 规则，按照自定义的规则生成（负载均衡器）配置文件，并通过 reload 来重新加载。   5.3.2 Underlay 与 Overlay 网络Underlay 网络模式: 底层承载网络，是网络通信的基础。优势：复用基建，网络扁平，性能优势；劣势：协作复杂，安全问题，管理成本。很多场景下业务方希望容器、物理机和虚拟机可以在同一个扁平面中直接通过 IP 进行通信，通过 Floating-IP 网络实现。Floating-IP 模式将宿主机网络同一网段的 IP 直接配置到容器中。这种模式为了保证容器与宿主机的交换机二层连通，需要在物理机上搭一个虚拟网桥。具体选择哪种网桥，主流有：Linux bridge、MacVlan、SRIOV 三种模式。BridgeBridge：设备内核最早实现的网桥，性能与 OVS 相当，可以使用到所有场景；MacVlan：一个简化版的 bridge 设备，为了隔离需要内核，实现时不允许 MacVlan 容器访问其宿主机 IP 和 ServiceCluster IP；SR-IOV 技术：一种基于硬件的虚拟化解决方案，可提高性能和可伸缩性；SR-IOV 标准允许在虚拟机之间高效共享 PCIe（快速外设组件互连）设备，并且它是在硬件中实现的，可以获得能够与本机性能媲美的 I/O 性能。Overlay 网络：是一种建立在另一网络之上的计算机网络。优势：独立自治，快速扩展，网络策略；劣势：复杂层级，性能损失，定制成本。Kubernetes 相当于云原生的操作系统。有人会问，凭什么云原生的操作系统这杆大旗？主要原因是：Kubernetes 解决了一个分布式操作系统最核心的计算、存储、网络三种资源。CNI 容器网络统一标准：CNCF 项目，为 Linux 容器提供配置网络接口的标准和以该标准扩展插件提供基础函数库；CNI 命令行调用规范，其插件在主机上直接切换进入容器网络命名空间，为容器创建网络设备，配置 IP，路由信息。CNI 规范内容：输入：ADD/DEL 控制指令，CNI 目录，容器 ID，网络命名空间，网卡名称。配置文件：标准部分：cniVersion，Name，Type，IPAM。输出：设备列表、IP 资源列表、DNS 信息。插件应用如：Bridge：Linux 网桥 CNI 实现，采用网卡对链接网桥和容器；Host-device：将主机设备直接移动到容器命名空间中；PTP：创建虚拟网卡对，采用路由方式实现对外互联；MacVlan：网卡多 Mac 地址虚拟技术完整支持 vlan；Vlan：Vlan 设备 CNI 实现，允许容器和主机分属不同 LAN；IPVlan：网卡上基于 IP 实现流量转发。   5.3.3 Overlay 网络-Flannel 方案CoreOS（被 Red Hat 收购）为 Kubernetes 专门定制设计的 overlay 网络方案。03 层网络方案实现：在每台主机部署 flanneld 进程实现网段分配，路由控制，采用多种转发机制实现流量跨机交互。Flannel 职责子网管理：每个主机分配唯一的子网；互联方式：为同 Overlay 平面容器分配唯一 IP。Etcd 存储：容器之间路由映射；SubNetManager：子网资源划分、IP 资源申请释放的接口定义；Backend：针对网络互联方式的接口定义。UDP，UDP 封包转发，建议仅调试使用；VxLAN(建议)，使用内核 vxlan 特性实现封包转发；Host-GW，主机 2 层互联情况下较高性能互联方式；IPIP，使用 IPIP 隧道完成封包和转发；IPSec，使用 IPSecurity 实现加密封包转发；AliVPC，对接阿里云 VPC 路由表实现网络互联；AWSVPC，对接 Amazon VPC 路由表实现网络互联。Flannel 的单机互联方案：子网分配：充当虚拟交换机/网关角色，连接所有本机容器，完成虚拟子网构建；Bridge：通过 NAT 借助主机网络实现外部服务访问；Veth pair：一端设置到容器网络 namespace，一端链接 bridge 实现容器接入网络；对外访问：为每个节点分配独立不冲突的 24 位子网。Overlay 解决方案：跨 Node 的 Pod 之间通信通过 Node 之间的 Overlay 隧道。职责：路由控制，数据转发。主要流程：本节点设置：设备创建、本地路由创建、回写本地信息；监听其他节点信息：更新 ARP 信息、更新 FDB、更新路由信息。   5.3.4 Overlay 网络-Calico 方案Calico 项目：是纯三层的虚拟网络解决方案，旨在简化、扩展和保护云网络的容器方案。Calico 优势：可扩展性：采用 IP 路由支持大规模网络。扩展便利，容错性高；网络安全：支持 Kubernetes 网络策略，支持自定义网络策略；广泛集成：集成 Kubernetes ，Mesos，支持 OpenStack，AWS，GCE，Azure。Calico 不足：BGP 支持问题：需要网路设备支持 BGP 协议，否则需要追加 IPIP 隧道；规划 2 层直连：需要节点做良好的规划实现 2 层网络直接互联；大规模配置复杂：网络规划，手动部署 Route Reflector，增加 API 代理。关键组件：BGP Client：和其他节点互联，发布当前节点路由并学习其他节点路由；Confd：同步节点配置信息启动 BGPClient；Felix：负责虚拟设备监控，ACL 控制、状态同步的 agent；Calico：CNI 插件，负责容器设备创建；Calico-IPAM：CNI 插件，负责容器网段管理与 IP 地址管理；RouteReflector：对接 BGPclient 实现路由中转；Etcd/Kube-apiserver：Calico 数据存储；typha：应对大规模节点接入时作为数据缓存 proxy；RouteReflector 安装：集群超过100 个节点时强烈建议启用，通过 RR 中转全局路由信息。Calico 单机互联方案：Veth-pair：一端设置到容器，一端放置在主机上，为容器提供网络出入口；路由策略：针对 IP 和设备设置路由条目，在主机上实现互联。Calico 跨机互联方案：同网段/BGP 支持：主机之间通过 2 层直连或者网络支持路由转发至目标主机；跨网段 IPIP 互联：网络设备不支持 BGP 协议情况下，采用 IPIP 隧道实现跨网段互联；跨网段 VxLAN 互联（Cannel）：集成 flannel，底层通过 VxLAN 实现跨机转发。*注：文章源自：https://blog.csdn.net/lianhunqianr1/article/details/118037321未完：一文带你理解云原生|云原生全景指南（下）———————————————————————————————————————————————【  AOC社区 】AOC (Agile Open Container)集成了华为网络云化平台，以及从网络运维中抽象总结出的业务框架，以Yang模型为基础，提供了对网络的开放可编程能力。社区为大家提供了关于数通网络开放可编程一站式学习、体验、认证、交流的平台。以视频为载体构建了在线学习AOC的整个学习、认证体系。另外还提供了SDK、demo样例、以及API手册、开发指导等文档的下载，方便大家进行新项目的开发。

在互联网技术公司里存在这样一个共识，那就是中国没有多少原创技术，基本都是美国原创之后，中国直接拿来用，无论是编程语言、操作系统、数据库、技术框架等等，那在云计算领域中国是否也会如此？云计算可以说是下一代工业革命的引擎，而云原生技术则是云计算的核心。通过了解一个国家或企业的程序员对云原生项目的贡献，就可以大致得出它在云计算领域的原创能力和贡献水平。云原生计算基金会CNCF提供的开源项目的数据算是很有力的参考。云原生开源贡献国家排名从表中可以看出，美国确实遥遥领先于其他国家，其次是德国、中国、印度、英国、法国、加拿大、澳大利亚、荷兰、日本、西班牙、俄罗斯等。德国能有如此强悍的表现让我十分意外，印度排在第四说明它确实如外界传闻一样在软件领域表现得很不错，但也并不比中国强。日本只排在第十，它的软件研发能力和它的国力、人口并不成比例，说明日本在软件开发方面确实落后了。中国在软件研发方面的原创能力是值得称道的，并没有很多人吐槽得那么不堪。这里所说的软件研发并不只是互联网技术，毕竟云原生可以算是国家基建了。云原生开源贡献企业排名如果是从公司的角度来说，整个云计算领域Google做出了莫大的贡献，无论是云计算还是云原生，抑或是大数据、AI、Go语言等，Google都是鼻祖，虽然它的市场份额比AWS、微软甚至阿里巴巴都要低。在中国，开源了多个重要项目的PingCAP排在世界第八、中国第一，其次是华为世界第十、中国第二，然后是阿里巴巴、中兴通讯、DaoCloud、网易、博云、腾讯、才云科技、百度、京东、字节、七牛等。这些云原生的开源项目至少九成以上是用Go语言写的，国内未来Go语言人才应该会比较紧缺。

科技云报道原创。在这充满变化的年代，数字技术在快速发展，数字化发展已成为全球重要的共识。今天，全球已经有超过170个国家发布了国家数字战略。各行各业的数字化转型需求从未像今天这么迫切。对于企业尤其是传统行业的企业而言，数字化转型已经不再是一道选择题，而是一道生存题。但是，对于如何踏上数字化转型之路，不同国家、不同企业、不同行业由于所处阶段不同，所面临的挑战不同，造成各有各的道，进而认识不同，采取的战略不同、节奏不同、方案不同。要真正实现数字化，还有相当长的路要走。数字化转型下的企业IT新需求当一个企业发生数字化转型，这个企业IT部门就会发生巨大的变革。原来企业IT和企业财务、法务、人力资源都是支持部门、成本中心，但是现在他们开始变成了企业运营和实现价值、实现增长的核心抓手。在这样一个大背景之下，传统IT必然会面临多方面的需求和挑战。首先，大量新增企业应用的运维。以往运维的应用主要是ERP、财务、OA系统，数字化转型时代，大量新兴数字化业务的数量可能带来几何级的增加。第二，不断增长的企业自研应用。以前企业更多通过采购获得新的IT能力，但是现在数字化业务和企业核心业务息息相关，是企业竞争力的来源，结合业务需求不断打磨、自研才是可行途径。像房地产、工业制造这类相对传统的企业也在向“软件企业”转型，Gartner指出2020年企业有75%的业务来自于自研而非采购。第三， 业务复杂度导致业务必须要解耦。传统业务系统，更多是基于信息的记录，但是在数字化的今天，系统更多是基于交互。因此业务系统越来越复杂，传统单体架构在功能开发、软件交付、测试更新等各方面都不能胜任。从单体式架构解耦变成小服务甚至微服务才是良策。这些也是“敏态IT”的需求，敏态IT对传统IT意味着强烈的“破坏性”、“颠覆性”。基于过去标准构建的IT运维和运营体系在敏态IT的面前变得疲于应对、捉襟见肘。这就需要一些新的思维方式、新的技术体系来解决敏捷IT问题，这个解决方法就是云原生。数字化转型，怎样才能不迷路？受新冠疫情影响的这两年，产品和服务的数字化进程进一步提速，据麦肯锡的调研数据显示，全球的数字化进程整体提前了7年，其中，亚太地区更是提前了10年。毋庸置疑，数字化是中国经济转型升级的一个重点，但也是痛点。中国数字经济的快速发展为中国经济巨轮劈波斩浪前行注入新动力，但中国数字经济依然大而不强，面临着高速增长和高质量发展的双重攻坚任务。虽然目前各行业的数字化转型进度并不统一，但很多企业的数字化转型已经取得了阶段性成果。随着各行业数字化转型的深入，它们完成“上云”之后，发现其数字应用更加丰富、也更加复杂。资源弹性与简化运维的价值依然是企业上云的基础，传统云服务已经远远不能适应企业的需要。资源极致弹性、应用敏捷开发迭代正在发展成为云服务的新常态。因此，“火爆”的云原生也成为互联网企业和传统政企的共同选择，云原生不仅掀起了云计算时代一股新浪潮，也开辟出一条企业数字化转型的最佳路径。随着云原生应用深入企业各个业务场景，跨云、跨地域统一协同治理，保证一致应用体验等新的需求日渐突出。对于传统政企应用，除了自身云原生改造获得资源和敏捷收益，更要充分与大数据、AI等新的云原生能力相结合，创造更大的价值。以政务云场景为例，首先，各局办委的OA应用重复建设，需要应用市场的统一管理。应用更新发布难，需要在各个局点部署安装，面临原生云应用分发的挑战。其次，资源独享，不支持共享池，ISV应用独立建设平台，平台厂商绑定导致重复建设，资源利用率低。再次，现有的平台缺乏应用的高可用和连续性保障、缺乏业务安全防护机制。最后，市民类业务越来越多，市民服务类业务往往都有弹性的需求，缺乏弹性，无法应对突发的流量。各省、地市、县不同级别的各类单位需要全局统一的业务分发与资源管理能力。以金融场景为例，很多金融企业进行了“多云”的部署。其中，金融监管较弱的业务(消金、互金、三方支付的核心系统和行情等)和面向互联网的敏态业务部署在公有云上，主要面临着无法极速扩容和支持大规模治理、难以有效应对流量冲击等算力方面的挑战;金融监管最强的数据敏感业务(证券/银行风控，银行核心)、时延敏感业务(资管，证券核心)和信创部署在IDC中，难以满足资管衍生品定价和风险定价等业务的高性能要求，例如每次请求有100TPS并发度，需要95%的时延能在5秒内返回。在营业厅、关键安防等节点，无法有效管理海量终端，实施有效监管和运营，缺乏统一体验(云边协同)。总体来说，金融场景缺乏统一的多云/多中心联邦治理能力，金融数字化新核心需要多地多中心架构，跨中心监控与治理，业务实例秒级跨云迁移成为新需求。以汽车制造的场景来看，传统制造行业数字化转型的痛点十分突出，财务、ERP、考勤等传统稳态业务资源利用率不高，基础资源无法有效整合、资源协同性差;车联网等创新业务部署在公有云上，面临着弹性能力无法满足海量并发接入需求，难以保障业务就近接入、访问时延高等挑战;智慧门店和数字工厂等业务存在分布式集群业务交互入口分散，面临运维困难，用户体验差等问题。那么，落地到具体的业务场景，企业要想切入云原生赛道，应该从何处入手？其实并没有统一答案。有公司是从开发部门开始，有公司是从运维开始，而有公司则从整个平台的架构设计端导入，不同企业要结合自己的业务状况，根据企业的发展阶段以及业务特点来选择。比如金融行业客户，有自己的开发团队，一般开启云原生的方式会从开发部门开始，从微服务、容器化和Serverless开始导入，然后逐渐推广。再比如制造业企业，一般没有自己的开发团队，更多是从第三方软件采购商那里获得云原生应用。并且，除了应用外，还有大数据、人工智能等很多数据处理平台，这些平台本身已经云原生化。就像在工业领域应用比较广泛的深度学习框架tensorflow，就有和kubernetes相结合的项目，叫做Kubeflow，很多客户通过这种方式来落地。另外，还有一些政府类的客户，在构建新的平台的时候，直接按照云原生的方式来实施和部署。总体来看，在传统应用架构下，网络流量大多是南北走向，但是到了云原生平台时代，会变成东西走向，这对整个数据的传输、存储和计算产生非常大的压力。为了让数据移动得更快，存储得更多，适应更广泛，帮助企业快速走向云原生时代。可以预测，在未来企业加快数字化转型过程中，云原生一定会变成现代业务的基础应用，其广度和深度会远远超过当年的虚拟化，最终变成企业应用现代化之旅的坚实底座。