《华为云:云原生2.0架构白皮书-以云原生的思维践行云原生(2022)(172页).pdf》由会员分享,可在线阅读,更多相关《华为云:云原生2.0架构白皮书-以云原生的思维践行云原生(2022)(172页).pdf(172页珍藏版)》请在三个皮匠报告上搜索。
1、云原生2.0架构白皮书以云原生的思维践行云原生构建万物互联的智能世界从业界首次提出云计算迄今为止的十多年历程中,全球正在从面向个人消费者的开放式移动互联以及面向企业、行业、政府的封闭 IT 的两极化时代,稳步迈向万物互联、数字化、智能化,各领域应用和业务统一走向云端的新时代,在这几乎影响到全社会、全行业、国民经济乃至日常生产生活方方面面的数字化转型过程中,多样化的云部署形态:无论公有云、私有云,以及行业云、政务云等,无不通过云服务为载体,将云计算、大数据、人工智能、物联网等技术有机整合在一起,为企业提供一站式的“云原生”数字化底座引擎,从而使得企业 IT 信息系统的开发者和运维者可以从繁重的非
2、业务平台开发与维护的技术细节中解放出来,以更低的学习成本接入并使用云服务的能力,真正聚焦于业务本身,进而将企业业务的创新能力、经营优化与决策能力,乃至生产力水平带上一个新的台阶。就云原生而言,其初衷更多是将弹性按需、水平扩展、高可靠高冗余、状态与应用分离等关键云架构属性特征以架构设计模式以规范参考架构及方法论的形式总结提炼出来,从而为企业应用的云化架构重构改造提供指引。后来 CNCF 云原生开源社区的诞生,通过 K8S 容器使得计算资源的轻量化、小型化,以及应用服务的集成打包封装等,逐步成为标准化、模块化的技术选择,与此同时云原生的方法论、工具集,以及全栈云原生参考架构等方面,也在 CNCF
3、云原生社区中得到了进一步的定义与分解。虽然 CNCF 等开源社区的系列云原生开源技术,比之前的“抽象设计模式”更进了一步,为企业 IT 业务架构在无修改整体搬迁上云的基础上,进一步展开更深度的云原生架构重构与改造,从而为最大限度地释放云的技术与商业红利提供了“技术组件与平台”,序言然而要真正支撑完整的企业全栈 IT 的重构,仅仅依赖容器化平台来承载企业自己开发的业务逻辑,以解决云原生应用的部署态及运行态弹性可靠性,及无单点高可靠、高可用问题,仍然是远远不够的,为进一步提升企业核心业务处理及 AI 创新应用的端到端开发态效率,突破传统垂直 IT 架构的数据层的扩展性瓶颈能力,解决大集中云资源池难
4、以支撑时延敏感应用及数据主权隐私保护,DevOps 开发流水线工具集、去中心化架构的分布式中间件、分布式数据库、云边端及多云协同架构、乃至普惠 AI 开发平台,无一不是未来全栈云原生重构所必须依赖的“基本要素”。由此,华为云通过自身在云原生开源社区的贡献与引领,云原生架构、全栈云原生服务产品的持续创新开发,以及支撑千行百业客户上云的实践经验,在业界已有的云原生系列概念与开源技术基础上,首倡提出了“云原生 2.0”的理念与框架体系,旨在通过这本白皮书向华为云的生态伙伴及企业行业客户阐述自己对企业云化、数字化转型的系统化思考、建议与展望。云原生 2.0,代表了云计算下个十年的发展趋势,即是云原生
5、1.0 的平滑延续,更为即将到来得全行业数字化经济时代定义了标准化、开放式、可高效批量复制的“智能世界云底座”参考架构与事实标准,各位开发者、架构师、以及技术管理决策者们,让我们一起迎接并尽情拥抱云原生 2.0 时代的到来,共同引领云原生 2.0 产业走向更加美好和生机勃勃的未来!编写说明编写单位:华为云编写组成员华为云顾炯炯 雷晓松 黄 毽 张 琦 吴清辉 张 煜 伍华涛 李 昆 文 震龙 江 郭奉民 朱冠宇 彭立勋 傅 飞 俞 岳 曾正阳 刘丙真 曹宗南怀宝兴 顾震宇 胡红山 胡 巍 王显雷 李善航 唐金根 兰修文 禹英轲第一章 云原生概念与技术的历史 /0011.1 云原生的定义,什么是
6、云原生(Cloud Native)?/0021.2 云原生 1.0 的技术特征 /0061.3 云原生 1.0 的典型架构模式 /0081.4 云原生 1.0 面临的挑战&云原生 2.0 /015第二章 云原生 2.0 的技术及架构特征 /0222.1 关键特征一:分布式云 /0232.1.1 趋势与需求 /0232.1.2 关键特征与架构原则 /0242.2 关键特征二:应用驱动基础设施 /0312.2.1 趋势与需求 /0312.2.2 关键特征与架构原则 /0322.3 关键特征三:混合部署,统一调度 /0372.3.1 趋势与需求 /0372.3.2 关键特征与架构原则 /0372.4
7、 关键特征四:无服务器化(Serverless)/0402.4.1 趋势与需求 /0402.4.2 关键特征与架构原则 /0412.5 关键特征五:存算分离 /0442.5.1 趋势与需求 /0442.5.2 关键特征与架构原则 /045目录目录2.6 关键特征六:数据治理自动化 /0462.6.1 趋势与需求 /0462.6.2 关键特征与架构原则 /0472.7 关键特征七:基于软总线的异构集成 /0482.7.1 趋势与需求 /0482.7.2 关键特征与架构原则 /0482.8 关键特征八:可信、平民化 DevOps /0522.8.1 趋势与需求 /0522.8.2 关键特征与架构原
8、则 /0522.9 关键特征九:多模态可迭代行业 AI /0552.9.1 趋势与需求 /0552.9.2 关键特征与架构原则 /0572.10 关键特征十:全方位立体化安全 /0612.10.1 趋势与需求 /0612.10.2 关键特征与架构原则 /062第三章 华为云云原生 2.0 架构设计模式 /0673.1 华为云原生架构设计方法(Huawei Cloud Native Architecting Methodology)/0683.1.1 企业数字化战略 云原生技术架构的根本驱动力 /0693.1.2 业务可持续发展 云原生技术架构的直接驱动力 /0703.1.3 架构设计视角 云原
9、生技术架构本身 /0703.1.4 组织变更视角 /0733.1.5 工程变革视角 /0743.1.6 架构持续演进闭环 /0753.2 企业云原生架构的可持续演进与迭代能力:基于服务开发服务 /075云原生 2.0 架构白皮书3.3 华为云云原生 2.0 的典型架构设计模式 /0763.3.1 分布式云设计模式 /0763.3.2 极致性价比驱动的软硬协同架构设计模式 /0823.3.3 多元算力统一资源池架构设计模式 /0843.3.4 无服务器化(Serverless)架构设计模式 /0853.3.5 存算分离架构设计模式 /0913.3.6 数据治理自动化架构设计模式 /0943.3.
10、7 基于软总线异构集成的架构设计模式 /0993.3.8 可信、平民化 DevOps 架构设计模式 /1013.3.9 多模态可迭代行业 AI 架构设计模式 /1053.3.10 全方位立体式安全防护架构设计模式 /113第四章 华为云云原生 2.0 典型案例实践 /1424.1 长沙政务云 /1434.2 梦饷集团 /1444.3 上海 12345 热线 /1464.4 顺丰科技 /1484.5 新潮传媒 /1504.6 一汽红旗 /1524.7 国网信通 /1544.8 江苏财政 /1554.9 深圳巴士 /1564.10 信义玻璃 /158第五章 未来趋势展望 /160目录001云原生
11、2.0 架构白皮书第一章云原生概念与技术的历史 002业界关于云原生的概念,最早出现在 2010 年,由应用集成中间件厂商 WSO2 提出,其关于云原生关键特征的提炼与描述包括:分布式、动态连接:云化应用与中间件需支持多个共享配置及共享会话状态,且并行运行的节点,另外不能假设云化应用是一种单一语言开发的,因此各云化应用之间要支持动态按需连接(与具体开发语言无关)。弹性:也即云化应用与中间件的分布式子节点应能根据系统的动态负载情况,进行按需的实例伸缩,包括调用云基础服务 API 启停虚机镜像。多租户:云化应用与中间件的多租方式有 2 类,1 类为物理多租,另 1 类为逻辑多租;前者靠将应用实例复
12、制多份 VM 或容器来实现,而后者则倡导“云化应用与中间件”内生的逻辑多租户隔离,一般建议云化应用和中间件在可能的情况尽量使用逻辑多租,因为其在满足多租能力需求的同时,占用相比物理多租更少的资源。自服务:自助式业务发放及管理对于最大化发挥云系统的效率至关重要,租户弹性账号内如果完全依赖管理员进行一切搭建、配置及管理活动,则不能称之为 IaaS/PaaS/SaaS 服务,分别对应在基础设施领域管理租户自己的 VM 或容器,在平台层领域管理并部署生产应用与中间件;在软件层领域则在特定应从用中直接创建和管理“自己的租户”。颗粒化的计量计费:按使用计费是云的基础特征之一,按年计费与按小时计费显然颗粒度
13、有很大区别,即使对于私有云场景,对资源消费的计量也很重要,在一个自服务、多租户、弹性的系统内资源和服务的使用情况就对应了系统的真实成本付出,因此深入理解、度量并监控资源的使用是至关重要的。增量的部署和测试;在一个高度可扩展、具备超大容量的云环境内,即便大型云客户的新版本已进行过充分的单元或者系统测试,他们仍然希望能在生产环境上展开新版本的试错性测试,并且可以在新旧共存版本之间控制流量分发的百分比。而采用云原生可以带来的价值则包括:更高的资源利用率,更快的发放效率,更好的应用治理;从上面的云原生特征总结来看,与 NIST 对云计算的关键要素定义看起来比较相似,但云计算的定义更多是从云平台的视角出
14、发,而云原生则更多是以云化应用为讨论出发点。2013 年,亚马逊 AWS 及其战略伙伴 Netflix 的最佳实践,进一步对云原生给出了自己的诠释:基于不可靠、易失效的基础设施,构建高度敏捷、高可用服务。云原生的定义,什么是云原生(Cloud Native)?1.1第一章|云原生概念与技术的历史 003云原生 2.0 架构白皮书 目标:伸缩性、可用性、敏捷、效率。原则:关注点分离,反脆弱性,高度信任的组织。特点:基于公有云(Public Cloud),微服务(Micro-services),反范式化数据(De-normalized data),混沌引擎(Chaos Engines),持续部署(
15、Continues Deployment),DevOps 等。2015 年,由 Heroku 提出,AWS Elastic BeansTalk,Cloud Foundry 等共同参与进一步对云原生的架构特征进行了系统化总结与补充,首次提出了云原生“十二因子”,微服务,以及DevOps 等云原生的关键要素与特征:十二因子应用(Twelve-Factor)因子 1:一份代码,多份部署每个可部署 app 在版本控制系统中仅有一个独立的代码库,可以在不同的环境中部署多个实例。因子 2:依赖App 应该使用适当的工具(如 Maven、Bundler、NPM)来对依赖进行显式的声明,而不该在部署环境中隐式
16、的实现依赖。因子 3:配置配置或其他随发布环境(如部署、类生产、生产)而变更的部分应当作为操作系统级的环境变量注入。因子 4:后端服务后端服务,例如数据库、消息代理应视为附加资源,并在所有环境中同等看待。因子 5:构建,发布,运行严格区分构建,发布,运行这三个步骤。直接修改处于运行状态的代码是非常不可取的做法,因为这些修改很难再同步回构建步骤。因子 6:进程以一个或多个无状态进程运行应用,任何需要持久化的数据存储在后端服务内,比如数据库。第一章|云原生概念与技术的历史 004因子 7:端口绑定应用完全自我加载而不依赖于任何网络服务器就可以创建一个面向网络的服务。互联网应用通过端口绑定来提供服务
17、,并监听发送至该端口的请求。因子 8:并发通过进程模型进行扩展,进程是一等公民。开发人员可以将不同的工作分配给不同的进程类型。例如,HTTP 请求交给前端 Web 进程来处理,而常驻的后台工作则交由后台任务处理进程负责。因子 9:易处理快速启动和优雅终止可最大化健壮性,进程应是易处理的也即可以瞬间开启或停止,从而有利于快速、弹性的伸缩应用,迅速部署变化的代码或配置,稳健的部署应用。进程应当追求最小启动时间,一旦接收终止信号就会优雅的终止,就网络进程而言,优雅终止是指停止监听服务的端口,即拒绝所有新的请求,并继续执行当前已接收的请求,然后退出。对于任务处理进程来说,优雅终止是指将当前任务退回队列
18、。进程还应当在面对突然死亡时保持健壮。因子 10:开发与验证环境等价通过保持开发、类生产和生产环境尽可能的相同来实现持续交付和部署。因子 11:日志不管理日志文件,将日志视为事件流,允许执行环境通过集中式服务收集、聚合、索引和分析事件。因子 12:管理进程日常管理类任务(如数据库迁移),应该在与 app 长期运行的相同的环境中一次性完成。这些特性很适合快速部署应用程序,因为它们不需要对将要部署的环境做任何假定。对环境假设能够允许底层云平台使用简单而一致的机制,轻松实现自动化,快速配置新环境,并部署应用,优化应用的部署速度。微服务(Microservices)微服务将单体业务系统分解为多个“仅做
19、好一件事”可独立部署的服务。这件事通常代表某项业务能力,或者最小可提供业务价值的“原子”服务单元。微服务架构通过以下几种方式为速度、安全、可扩展性赋能:005云原生 2.0 架构白皮书 将业务领域分解为可独立部署且有限能力的环境。同时,也将相关的变更周期解耦。通过扩展部署组织本身可以加快部署。由于学习业务领域和现有代码的认知负担减少,添加到每个沙箱的新开发人员可以更快速地提高并变得更高效。可以加快采用新技术的步伐,大型单体应用架构通常与对技术堆栈的长期保证有关。微服务提供独立、高效的服务扩展。自服务敏捷基础设施(Self-Service Agile Infrastructure)使用云原生应用
20、架构的团队通常负责其应用的部署和持续运营。云原生应用的成功采纳者已经为团队提供了自服务平台。应用程序代码简单地以预构建的工件(可能是作为持续交付管道的一部分生成的)或 Git 远程的原始源代码的形式“推送”。然后,平台构建应用程序工件,构建应用程序环境,部署应用程序,并启动必要的进程。团队不必考虑他们的代码在哪里运行或如何到达那里,这些对用户都是透明的,因为平台会关注这些。除此之外,自服务敏捷基础设施还具备如下能力:应用程序实例的自动化和按需扩展 应用健康管理 请求到或跨应用程序实例间的动态路由和负载均衡 日志和指标的聚合基于 API 的协作(API-Based Collaboration)在
21、云原生应用架构中,服务之间的唯一互动模式是通过已发布和版本化的 API。这些 API 通常是具有 JSON 序列化的 HTTP REST 风格,但也可以是其他协议和序列化格式。通过消费者驱动的协议,可以在服务间交互的双方验证协议的合规性。服务消费者不能访问其依赖关系的私有实现细节,或者直接访问其依赖关系的数据存储。反脆弱性(Anti-fragility)提升系统的韧性能力,即便在遭受压力时不会被破坏或变弱,例如通过“混沌猴”将随机故障注入到生产组件中,目的是识别和消除架构中的缺陷。第一章|云原生概念与技术的历史 006DevOps,持续交付,康威定律系统即便在遭受压力时不会被破坏或变弱,例如通
22、过“混沌猴”将随机故障注入到生产组件中。也是在 2015 年同年,CNCF 云原生计算基金会(Cloud Native Computing Foundation,成员包括 Google、华为、IBM/Redhat、Intel 等 19 家)正式成立,标志着云原生从技术理念转化为开源实现,并给出了目前被广泛接受的定义:云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。CNCF 致力于通过培养和维持一个开源、供应商中立的项目生态系统来推动云原生技术的广泛采用,进而实现让云原生无处不
23、在的愿景。CNCF对云原生的定义让云原生的概念进一步具体化,从而让云原生更容易被各行业理解,为云原生在全行业广泛应用奠定了基础。过去几年中,云原生关键技术正在被广泛采纳,CNCF 调查报告显示,超过 8 成的用户已经或计划使用微服务架构进行业务开发部署等,这使得用户对云原生技术的认知和使用进入新阶段,云原生技术生态也进入到快速更迭的阶段。回顾云原生技术自诞生以来的发展历程,站在企业应用软件上云的视角,特别是上云过程本身对应用软件本身迁移、重构、开发、部署乃至全生命周期管理的影响,及其对全栈云服务价值挖掘持续地由浅入深地地过程,不难将其归纳为如下 2 个特征:云原生特征 1:容器化,微服务化以
24、AWS 之上的 NetFlix 为代表,其传统单体软件架构被解耦拆分为微服务架构,每个微服务对应一个明确单一的业务功能单元,以及一个或多个运行态容器实例,所有微服务对外开放声明式的 REST 或 gRPC API,作为与其他微服务交互的“唯一契约”,微服务本身开发复杂度适合 10人左右小团队承担,所有微服务均有自己独立的数据库及持久化数层,而不与其他微服务有任何云原生1.0的技术特征1.2007云原生 2.0 架构白皮书共享数据库依赖,从而确保所有微服务可以完全运行态解耦,以独立的版本节奏迭代演进,并支持不同的开发语言,且每个微服务可依据业务量需求,以容器为最小扩缩容单元进行秒级按需弹性伸缩(
25、容器颗粒度一般远小于 VM,且更轻量化,易于秒级启停),每个容器的发布包,除应用镜像外,也包含其业务应用运行时所需的依赖库、环境变量等。此外,还将分布式微服务的管理与治理能力下沉到开源语言特定的微服务框架,例如 SpringCloud、ServiceComb、CSE 等,以及非侵入式通过边车(Sidecar)与业务逻辑绑定注入微服务治理能力,也即通过应用无感知的Istio 服务网格(ServiceMesh)机制为拆分后的微服务提供注入服务发现、灰度升级、熔断流控、流量治理等微服务公共基础框架。云原生特征 2:基于云化应用中间件、数据库,乃至可重用服务重构及开发企业应用或服务在解决了租户面业务逻
26、辑容器化的挑战之后,对其所依赖的中间件,数据库从应用空间到云服务商空间进行“下沉”。以 Salesforce 为代表,将企业应用中的共性业务逻辑下沉到应用平台,在相同应用逻辑上实现跨租户共享,并借助模型驱动架构(MDA:Model-Driven Architecture)进行跨租户应用逻辑的抽象,同时在平台层进一步实现跨租户的数据库共享,也即基于统一的数据库模板进行不同租户对应数据表的裁剪、重映射等操作;总之,通过在应用和数据服务层提供跨租户共享能力(也即逻辑多租),实现面向最终云租户屏蔽资源层多租隔离的复杂性。另一种上云模式是与底层资源耦合、应用无需感知弹性资源伸缩控制的 PaaS 平台,也
27、即 hcaPaaS(high-control application PaaS),AWS BeansTalk、Google 的 GAE 等 即 属 于hcaPaaS;或与底层资源解耦、面向开发者展开高效企业应用开发的 PaaS 平台,也即 hpaPaaS(high-productivity application PaaS),从而面向云租户实现对应用屏蔽下层资源的操作,依赖应用平台实现应用和 DB 级的伸缩操作。Salesforce 的 2 大平台 Heroku 和 F 分别对应hcaPaaS 及 hpaPaaS。hpaPaaS 的另一个内涵对应到 Low/No Code,将应用的生产环境部署
28、延展到开发环节,基于应用逻辑的理解,引入模板/DSL 进行敏捷开发,对行业数字化起到了巨大的推动作用。第一章|云原生概念与技术的历史 008所谓云原生(Cloud Native),是指构建、运行、管理基于云环境、利用云环境、适应云环境、受益云环境的软件而发展起来的一系列的软件系统实践范式。包括充分利用云基础设施与平台服务,具备微服务架构、弹性伸缩、分布式、高可用、多租户、自动化运维等关键特征的架构实践;建立与系统架构匹配的全功能团队、发展全栈工程师并高度协作的组织实践;采用 DevOps、自动化工具,实现微服务持续交付的工程实践。通过架构、组织、工程面向云环境的协同实践,实现 Cloud Na
29、tive 系统对外体现快速、可靠、规模、灵活、高效的价值收益。云原生 1.0 阶段的代表性技术架构模式包括:服务化架构模式服务化架构是现代云原生应用普遍适用的标准架构模式,与传统软件工程所强调的“高内聚、低耦合”架构模式在实现软件功能的“分而治之”,以及公共软件功能的“最大化重用”的目标方面是一致的,二者也均提倡通过 DDD(领域模型驱动)方法论指导将软件面临的业务应用问题分解为复杂度、交付质量、交付时间可控且更小颗粒度的应用单元,但在实现这些应用单元之间的隔离及复用手段方面,服务化架构与传统软件架构存在本质不同:传统软件架构更强调开发态静态代码的隔离与复用,而服务化架构则更强调进程级别的运行
30、态隔离,并以接口契约(IDL,Swagger,RAML 等)定义每个服务应用单元可以为外部提供功能支撑,以标准协议(HTTP/HTTPS、gRPC 等)作为接口契约 API 的最终传输协议承载。各服务/微服务进程之间只能严格通过服务 API 为界面进行业务流程与逻辑地交互与协同,不允许直接访问其他服务/微服务内部的数据信息。服务化架构采用运行态进程级软件(服务/微服务)代替静态开发态软件模块作为软件隔离与共享基本单元的关键优势:轻量级服务/微服务的开发、测试、部署、发布等全流程活动由独立全功能团队负责,不再需要多个有紧耦合关联的开发测试功能团队协作才能完成,因此有效地提高了软件研发迭代效率;业
31、务逻辑按照服务/微服务解耦,使得服务/微服务级别的故障,不会扩展至整个软件系统;不同服务/微服务的代码模块所对应的部署实例数可依据实际业务情况各不相同,并且可以云原生1.0的技术特征1.3009云原生 2.0 架构白皮书服务为单位进行更小颗粒度的水平伸缩,从而使得系统部署成本更优;每个服务/微服务可以根据具体的场景,独立演进最优的技术堆栈,利于实践新技术,享受额外的技术红利;单个服务/微服务职责单一、轻量化,利于实施持续交付,快速演进业务。当然,凡事必有其两面性,服务化架构所带来的也不仅仅是优势,同样也必然存在其约束和挑战:数据随同服务一起分布化后,需要妥善处理数据一致性问题,跨服务进程的远程
32、调用引发的性能问题导致系统部署运维复杂,涉及众多服务实例,需要完善的工具做支撑;服务之间基于接口契约化,隐式的运行态依赖,导致依赖管理复杂度提升。服务进行不兼容升级时,需妥善处对上游服务的影响;系统划分为多个服务,业务特性需要多个服务协作完成,增加了测试难度。因此,服务化架构下的软件进程拆分颗粒度也不是一味追求越小越好。一方面要考虑与业务应用边界的对齐,另一方面也要充分做好与服务化架构配套的工具自动化、治理流程方面地准备。对于软件进程间交互对性能(时延、吞吐)高度敏感的场景,比如底层数据报文转发、基于内存共享区的数据映射与交换等,不排除传统的软件进程解耦相比服务化/微服务化拆分是更好的选择。图
33、 1-1 传统单体架构与微服务化架构对比Web UIWeb UI移动App移动AppREST 接口API Gateway服务A接口开放业务逻辑数据访问层数据库接口开放业务逻辑数据访问层数据库接口开放业务逻辑数据访问层数据库服务C服务B模块CREST 接口模块A模块B数据访问层模块A数据表模块B数据表传统单体架构服务化/微服务化架构数据库公共数据表模块C数据表第一章|云原生概念与技术的历史 010服务网格化架构模式服务网格化架构,可以认为是服务化架构的进一步“延伸与发展”,其本质是将服务化架构下跨服务/微服务之间与具体服务应用的业务逻辑无关的公共交互处理与消息流量治理功能,与每个服务/微服务特有
34、的业务逻辑解耦,从而使得这些提供服务端点注册发现、服务间消息交互鉴权认证与加解密保护、服务间的消息流控、熔断、降级、重试、反压、隔仓等分布式架构模式及其用到的中间件框架(比如缓存、异步消息、远程过程调用等)从业务进程中彻底分离解耦,统一纳入到服务化网格(Service Mesh)的框架内,而业务进程中仅需要保留与服务化网格之间很薄的一层适配通信客户端,甚至完全无需感知服务化网格能力的存在,其架构示意如下:图 1-2 服务网格化架构实施服务网格化架构后,业务应用代码自身只需聚焦做好业务应用逻辑的处理,而与具体业务应用逻辑无关、可公共共享的服务/微服务治理方面的处理均可交由服务网格机制来统一处理:
35、包括服务能力发现、服务间交互韧性保护、服务弹性伸缩、零信任安全保护、按流量进行服务/微服务版本灰度上线与环境隔离、基于流量做自动化的冒烟/回归测试等。可观测的服务/微服务架构在服务化/微服务化架构模式下,由于传统单体应用被拆分为更多颗粒度更小的微服务/组件,导致需独立部署及升级变更的微服务/组件进程数有了数倍甚至数十倍增加,因此也必然对应用架构的“透明可观测”能力提出了更高的要求。为数量众多的微服务/组件进程之间点到点业务进程业务进程业务应用代码业务应用代码业务应用代码服务发现SDK流量治理SDK安全管控SDK消息跟踪SDK业务应用代码服务网格进程(服务发现、流量治理、安全管控、消息跟踪.)服
36、务发现SDK流量治理SDK安全管控SDK消息跟踪SDK011云原生 2.0 架构白皮书网状解耦消息交互端到端跟踪,从而确保系统运行一旦出现问题时,即可快速定位并寻找到问题产生源头所对应的微服务和组件。服务/微服务的可观测性主要通过日志、跟踪、统计指标 3 类渠道获得,其中日志提供多个级别(详细/调试/警告/错误/致命)的详细信息跟踪,可由应用开发者主动提供日志信息的收集与上报;跟踪则提供一个请求从前端接收到 API 请求到后端业务处理完成的端到端全调用链路跟踪,对于分布式场景尤其有用;统计指标则提供对系统量化的多维度度量。服务/微服务架构即可为自己选择合适的、支持可观测能力的开源框架(比如 O
37、penTracing、OpenTelemetry),或选择自研的与服务/微服务运维监控能力配套的监控运维系统(含被观测对象侧的运维代理,以及负责后端日志、跟踪与统计指标处理的运维服务端),并规范化定义各服务/微服务上报的日志、跟踪及统计指标等观测数据的具体类型与参数(比如用户信息、地理位置、请求参数等),明确这些可观测数据的产生端与消费端。利用日志和跟踪信息中的“跟踪实例/ID 信息”,可使得后台分布式链路分析时将来自不同服务/微服务实例的跟踪消息做快速关联分析,以实现快速排障与问题调试。除故障管理及业务连续性保障之外,构建服务/微服务可观测能力也有助于衡量各个服务/微服务组件是否达到了其面向
38、服务租户所承诺的SLA/SLO(Service Level Agreement/Objective),比如并发业务请求数、业务请求平均处理时长、持续提供不中断服务的市场、系统的总体容量、剩余可用容量等。分布式事务模式服务/微服务架构模式下每个服务拥有自己独立的数据源,不允许像单体应用那样直接跨服务共享数据源,因此导致高复杂度、大颗粒度的业务往往需要跨多个分布式服务/微服务的数据访问,由此也引发了分布式事务一致性问题,从而确保跨不同服务/微服务有关联域的数据保持一致(多个微服务的关联数据库/数据表,要么同时更新成功,或要同时失败)。架构师需要根据不同的场景选择合适的分布式事务模式。1)两阶段提交
39、模式服务/微服务应用中间件与数据库通过 XA 接口规范,使用两阶段提交来完成一个全局事务,XA 规范的基础是两阶段提交协议:一阶段:表决阶段,所有参与者都将本事务能否成功的信息反馈发给协调者;二阶段:执行阶段,协调者根据所有参与者的反馈,通知所有参与者,步调一致地在所有分支上提交或者回滚采用强一致性机制。该模式的缺点是能低下,可能因为 XA 协议自身原因,造成事务资源长时间得不到释放,锁定周期长,而且在应用层上面无法干预,数据并发冲突高的场景性能很差。第一章|云原生概念与技术的历史 012事务开始时,业务应用会向事务协调器注册启动事务。之后业务应用会调用所有服务的 try接口,完成一阶段准备。
40、之后事务协调器会根据 try 接口返回情况,决定调用 confirm 接口或者cancel 接口。如果接口调用失败,会进行重试。TCC 方案让应用可自定义数据库操作的粒度,使得降低锁冲突、提高吞吐量成为可能,不足之处体现在两方面:一是业务侵入性强:业务逻辑的每个分支都需要实现 try、confirm、cancel 三个操作;二是应用侵入性较强,改造成本高,实现难度较大。2)TCC 模式:本质是两阶段提交的一种改进,将整个业务逻辑的每个分支显式分为 Try、Confirm、Cancel三个操作。Try 部分完成业务的准备工作,confirm 部分完成业务的提交,cancel 部分完成事务的回滚,
41、如下图所示:图 1-3 两阶段提交模式图 1-4 TCC 模式第一阶段事务协调器事务协调器预备就绪本地资源管理器本地资源管理器本地资源管理器本地资源管理器预备就绪提交成功提交成功第二阶段2 调用Try接口1 启动事务3 提交或回滚事务业务应用事务协调性服务ATry接口Confirm接口Cancel接口服务ATry接口数据库数据库Confirm接口Cancel接口013云原生 2.0 架构白皮书3)基于消息的最终一致性方案通过消息中间件保证上下游应用数据操作的一致性。基本思路是将本地操作和发送消息放在一个本地事务中,保证本地操作和消息发送要么两者都成功或者都失败。下游应用向消息系统订阅该消息,收
42、到消息后执行相应操作。最终一致方案本质上是将分布式事务转换为两个本地事务,然后依靠下游业务的重试机制达到最终一致性,因此其对应用侵入性也很高,应用需要进行大量业务改造,成本也非常高。图 1-5 基于消息的最终一致性方案4)非入侵的高性能事务方案(DTM 分布式事务中间件)其基本思路将分布式事务也即一个全局事务,划分为若干个分支事务,每个分支事务均是一个满足 ACID 的本地事务。为实现对本地事务的非入侵修改,引入资源管理器来拦截业务 SQL,对其解析并做额外的一些数据处理,产生 undo log 并保存,一旦发生全局事务回滚,则通过各个分支事务对应的 undo log 完成所有分支事务回滚。为
43、防止两个全局事务并行修改数据导致回滚数据错误,引入分布式锁服务器对事务所修改数据加锁,全局事务提交后立即放锁,全局事务回滚则等待分支事务回滚完成放锁。5.事件驱动架构(EDA)随着万物互联时代的到来,用于高效关联集成事件监测与产生者,与对应的事件处理者的事件驱动架构 EDA 正在迅速兴起,用于促进事件的生产、检测、处理和响应。事件可以是多种多样的,比如某人拿起一件物品,某对象的测量指标达到一个阈值,或者一个特定的客户到达零售店。EDA 由三个属性定义。首先,它有选择地将相关事件从传入数据传输到数据库。其次,它处理来自多个源的复杂事件,这些事件可以实时地相互影响。第三,它通过推式操作简化了实时服
44、务。事件驱动架构的用例示例包括滴滴、Uber 等资产共享解决方案、分配维护人员和备件的规定维护系统或动态客户服务应用程序。订单数据库库存数据库消息队列.业务应用订单服务库存服务因此,TCC 方案虽多被研发实力强、有迫切需求的电商、金融公司采用,但由于事务处理逻辑多数需要在应用层完成,因此与微服务所倡导的服务轻量化思路不完全吻合。第一章|云原生概念与技术的历史 014EDA 是一种非常流行的分布式异步架构模式,经常被用与构建高可伸缩性的应用程序。当然它也适合小型应用,复杂应用和规模比较大的应用。这种架构模式由一系列高度解耦的、异步接收和处理事件的单一职责的组件所组成。事件驱动架构由两个主要的拓扑
45、组成:分别是调停者拓扑和代理者拓扑。调停者拓扑通过一个中央的调停者来编排各种处理步骤。然而代理者拓扑适用于那些想将事件链式的聚在一起但不使用中央调停者的情况。事件流通过客户端发送到消息队列,事件队列则传递消息到调停者。调停者接收到队列传递过来的原始消息,然后编排成异步的消息发送到事件通道,事件通道则通过事件处理器执行处理过程的每一步。事件处理器则监听事件通道,根据自身不同的业务逻辑来处理从调停者接受的事件。EDA 架构的 3 要素为:事件(event)响应(handler)事件与响应的“逻辑关系”其中的“事件”常常是固定的,而“逻辑关系”往往体现的是业务规则或者核心逻辑,也常常是固定不变的。只
46、有“响应”是可变的,或者说是可以配置或者需要改变的。响应事件而不是主动查询目标系统将会带来自主性,更好的容错能力和弹性,但也有一点其他影响,会影响自治事件驱动系统的是“延迟”。EDA+CQRS(Command and Query Responsibility Split)模式强调命令和查询的分离,也即各自独立的类封装:其中查询负责请求获取系统的状态,而命令则负责请求系统修改其状态。将 EDA 与 CQRS 模式相结合,是系统设计的一个自然增量,因为命令本身就是事件的生成器。结合图 1-6 事件驱动架构The Complementary Use of Event Stream Analytics
47、 and Event Brokers in Event-Driven ComputingEvent SourcesEvent BrokerComplexEventStreamStream Analytics(CEP)Event HandlersTransactional Event Stream015云原生 2.0 架构白皮书使用 CQRS 和命令,为从传统控制流架构向EDA架构的过渡时的迁移数据提供了一个衔接的桥梁,在迁移结束后,可以移除该衔接桥梁。EDA+事件溯源(ES)模式:事件溯源表示能追查一个事件的源头,甚至与之相关的其他事件的概念,通过将 ES 与 EDA 配合使用,ES 负责保存
48、 EDA 产生的事件信息,使得我们对系统中的实体究竟是如何一步一步变成现在这个样子能有一个清晰的了解,并且也为必要的 Redo 撤销重做机制提供了支撑。尽管云原生技术自诞生以来经历了蓬勃迅猛的发展,不断臻于完善,然而随着千行百业云化不断走向纵深,人们也发现云原生技术正在面临越来越多的不足与局限性亟待解决和突破,而对这些问题及其解决途径的思考与探索,引发了云原生新代际的出现。挑战 1:如何解决云资源池的大集中化,与实时应用上云要求低时延,及海量线下数据上云不满足数据隐私合规,或者带宽接入成本过高之间的矛盾?解决之道:分布式云众所周知,云计算相比传统计算模式最大的优势:“弹性伸缩&敏捷按需”,来源
49、于云数据中心中的超大规模计算与存储资源池,通过资源动态共享,一方面使得云租户视角永远感知到“取之不尽,用之不竭”的“弹性按需资源”,另一方面则通过不同租户及租户内不同虚拟化、容器负载之间的集约动态复用,获得相比传统独占硬件平台方式更高的有效资源利用率。然而云资源池的大集中化,必然面临着该集中资源池距离多数最终云租户/用户接入距离较远,甚至超过上云应用和业务可接受接入时延的上限(比如超过 50ms 时延),而对于一些特定行业用户侧产生的海量数据(如公安领域的视频监控数据、医疗领域基因数据、工业互联网制造领域的数字孪生建模数据等),要么由于国家区域或者行业的数据安全隐私保护规范的要求,希望相关核心
50、数据资产永远保留在自己得数据中心内,不得泄露到任何第三方(包括云服务商);或者虽然对线下数据上云没有隐私保护要求,但由于数据体量过大(单个企业租户每天数十甚至上百 TB 得数据上传量),使得数据上传的成本可能反而超过从云端获得弹性算力及算法服务可获得的收益。与大集中的云资源池相对应,当前云原生微服务治理框架,也仅考虑了大规模云资源池站点内的服云原生1.0面临的挑战&云原生2.01.4第一章|云原生概念与技术的历史 016务注册、自动发现、流量治理、灰度升级等功能。随着云、5G、物联网、AI 技术的不断成熟,云化、数字化从互联网及企业后端 IT 支撑系统迅速延伸进入到智慧城市、智慧政务的物联网终
51、端系统,智慧制造的前端实时生产线,促使上述实时应用及海量数据上云难与云资源池大规模集约化之间的矛盾变得更为紧迫和突出,云原生迫切需要回答在云基础设施及云原生框架两个层面,如何从“大集中云”走向“大集中云”与“分布式云”共存,从而实现灵活敏捷、可编程的云边端协同。挑战 2:如何解决云原生应用对跨物理机、虚拟机,跨云服务商,以及跨云端和边缘的云基础设施无关性需求,与性能敏感的关键重载应用对云原生基础设施的极致性能需求之间的矛盾?解决之道:应用驱动基础设施云原生强调应用与基础设施平台各自水平分层解耦,特别是面向云租户和开发的应用发布、部署以及全生命周期管理的“物理基础设施无关性”,也即相同的容器发布
52、方式,无论部署在物理服务器、KVM 虚拟化、乃至 VMware 虚拟化之上,均可保持其容器包发布与管理方式的一致性;然而随着云原生改造所覆盖的应用类型越来越广泛,对于性能敏感的应用,比如 AI 训练与推理、网络吞吐敏感的视频及大数据分析类业务、网络与存储时延敏感的数据库业务等,传统基于通用CPU 及 OS 内核态实现的虚拟化隔离及存储、网络协议栈功能,已越来越难以满足应用对底层基础设施的性能诉求,从而促使业界去思考如何在保持云服务管理面及数据面界面不变的前提下,通过软硬件深度垂直整合以及必要的软件重构,带来极致性价比的可能性。挑战 3:如何解决越来多样化的云原生应用需独占容器集群甚至资源池,且
53、在CPU、内存、存储 IO、网络 IO 等各资源维度利用率不均衡所导致主机计算资源浪费的问题?解决之道:混合部署,统一调度当前多数云服务商的虚拟机层与 Kubernetes 应用容器层的资源调度是相对独立的两层(往往将容器资源的调度叠加在虚拟机资源调度层之上),甚至缺省针对不同的租户应用,需为其申请相对独立的容器集群,从而导致无论底层不感知租户应用类型的弹性虚拟机层,还是上层具备一定应用感知能力的容器层,其资源调度逻辑完全各自独立,彼此互不相通,形成了过多的“云原生资源碎片与孤岛”。为整合这些“资源碎片与孤岛”,急需我们在云基础设施资源调度层水平统一打通应用感知的K8S容器集群,以及更底层物理
54、机、虚拟机资集群调度,基于统一的资源视图,实现多种类型云原生应用(CPU、内存、存储 IO,网络 IO 密集型,或其任意组合)在统一资源017云原生 2.0 架构白皮书池上的混合部署与统一并发调度,并进一步引入闭环的性能与 QoS 实时监控机制,从而驱动统一多维调度引擎在保障云原生应用性能的前提下,获得更高的动态超分比资源利用率。挑战 4:如何简化运维复杂度、降低运维负担的问题?解决之道:无服务器化(serverless)容器及微服务之后,云原生技术前沿已迈入 Serverless 无服务器时代。AWS 发布 FaaS(Function-as-a-Service)产品 Lambda 后,业界首
55、次提出了 Serverless。Serverless 是将应用程序(或其一部分)在远程托管的执行环境中按需运行的架构,其不需要用户维护自己的资源管理,甚至不需要构建与特定 OS 兼容的应用程序。FaaS 实质上是 Serverless 架构中以计算为中心的部分,可以构成其中的一部分,但不代表整个系统。Serverless 上的应用只需为实际运行代码的时间付费。FaaS 早期以无状态业务逻辑运行,对有状态应用无法支持,因此出现了 Serverless 2.0=FaaS+BaaS(Back-end as a Service),需要将应用和数据服务均 Serverless 化,并充当计算逻辑的 Se
56、rverless 特征后端服务。当前 Serverless 在推广中遇到一些问题,包括有限的编程语言支持、供应商锁定、SLA 难以保证(尤其是冷启动)、只涉及应用的部分而无法 cover 整个应用,因此长期会同传统应用模式共存。对编程语言受限问题,考虑采用统一的后端语言级 VM 来支持;供应商锁定可通过跨厂商的标准和模型互通来支持(参考 AWS SAM);SLA 则可通过简单的热点代码 Warm、以及 Serverless 平台与资源层垂直优化来部分解决。挑战 5:如何解决企业应用上云之后海量的结构化、半架构化及非结构化数据存储格式各异,同一份数据多次重复拷贝,数据存储与数据计算弹性需求不一致
57、所导致的资源浪费,可靠性保障水平参差不齐的问题?解决之道:存算分离,分层池化在云原生初期阶段,数据库、大数据普遍采用存算一体的部署方案,数据处理进程与数据存储是耦合部署的,例如开源数据库 MySQL 采用虚拟机加云盘的部署方式,数据库进程只能访问本地挂载云盘的数据,增加只读副本需要拷贝一份完整的数据,各节点之间无法共享数据和计算能力;同样,大数据开源软件 Hadoop Spark 系列采用了 NDP(近数据处理)架构,大数据分析处理进程与 Hadoop 数据分片是紧耦合的关系,导致了大数据集群无法与云主机及云容器集群共享计算资源池,计算与存储紧耦合的大数据集群始终无法与面向普通应用的云租户计算
58、和存储集群实现物理共享;此外,对于企业应用上云之后所产生的海量结构化 MySQL、PQ-SQL,半结构化 NoSQLCassandra MongoDB,以及搜索引擎 Elastic Search,图数据库 Noe4j,乃至非第一章|云原生概念与技术的历史 018结构化数据对象存储 OBS,分布式文件系统等,为解决其数据水平横向扩展的问题,均各自采用了特定于其数据组织结构及查询变更逻辑的数据冗余分片、分布式一致性处理,分布式 RAID/EC数据编码,乃至持久化数据容灾与恢复处理等逻辑,导致各类对海量容量及水平扩展能力,以及分布式可靠性容器保护能力的类型各异的持久化数据层采用了 N 套不同的技术机
59、制来实现,增加技术栈复杂度与维护成本的同时,导致数据处理逻辑与底层数据持久化逻辑紧耦合,难以胜任高并发高弹性高可用的在线事务处理需求(例如电商大促期间对计算资源的需求远大于对存储容量的需求,社交平台的历史数据访问频率极低其容量需求远大于计算资源需求)和相关海量数据分析对计算和存储资源集群的非均衡弹性诉求(比如基于原始顺联大数据素材的机器学习或深度学习分析,其计算资源消耗量远大于存储;而对于分析调用频度不高的日志汇总分析,则存储资源消耗远大于计算);基于上述问题挑战,业界开始积极尝试所谓“云原生数据”架构,也即以“存算分离”架构模式为特征,重构所有的大数据、数据库、NoSQL 乃至搜索引擎、图数
60、据库等,以统一的分布式高可用存储引擎支撑所有上述数据形态的数据分片、无限制水平按需扩展、秒级快照及恢复、数十倍的存储节点故障或扩容的并发数据重分布效率,乃至无锁化的并发 IO 读写等,使得所有云原生数据集群服务(含结构、半结构、非结构化)无论在水平扩展性、性能、容灾可靠性,以及业务不中断数据平滑扩容的能力均获得了高度一致的大幅提升。在计算层与存储层分离后,计算层也在进行进一步的解耦即 CPU 资源和内存资源解耦。以分布式内存池的方式,提供像分布式存储一样的全局内存,使得 CPU 资源和内存资源也可以单独的进行弹性扩展,对于数据库、大数据等有状态的云服务,可以将全局状态卸载到全局内存池上,可以更
61、方便的实现计算节点之间的状态转移。云原生的“弹性按需扩展”架构能力主要聚焦于基于容器的无状态应用业务逻辑,然而对于有状态的应用事务、数据库、大数据、消息与缓存中间件,互联网应用虽有分表分库等应用层与数据库层配合的设计模式来实现有状态应用的超大规模水平扩展,但随着云原生存算分离数据库、大数据,以及分布式事务技术的持续演进发展,使得企业应用系统的开发无需再关注任何与数据规模及其水平扩展能力问题,因为该层能力将完全卸载到持久化数据层。挑战 6:如何解决企业数据治理平台构建依然人工介入、效率低下的问题?解决之道:数据治理自动化企业将其应用事务处理及运营分析相关的数据通过数据库、NoSQL,以及大数据平
62、台汇聚到云上海量数据湖后,还需要经过一系列人工介入过程对各类数据资产进行标签分配,并对存在质量问题的数据进行识别并触发相应的清洗过滤,由此可见企业数据治理平台的构建在当前严重依赖于大量人力的投入,为解决这一条件,最好的途径仍然是用 AI 替代人力进行数据质量规则稽核、019云原生 2.0 架构白皮书查重、修复和数据丰富,自动生成数据资产之间的关联、发现与标签分类,以及自动识别个人隐私数据和数据安全保护等。从而将企业数据治理的效率及数据资产准确性与质量水平提升到一个新的台阶,满足企业业务的数据消费需求。挑战 7:如何解决云原生新开发应用,与各行业已有的非云原生应用,特别是非互联网领域的政企传统行
63、业 IT 应用的无缝互通及平滑演进的问题?解决之道:平滑演进,兼收并蓄千行百业的 IT 系统完成云原生的演进改造,显然不是一蹴而就的过程,必将在相当长一段时间内,处于云原生应用与非云原生应用兼容并存的状态,因此必须有机制确保云上与云下,云原生应用及其数据,非云原生应用及其数据,可以像原来在相同数据中心,相同软件架构下一样无障碍地彼此互联互通及互相集成。挑战 8:如何将诞生于互联网的 DevOps 敏捷开发流水线能力,推广引进到对产品研发质量及安全可信有更为严格要求的政府及传统行业,以及让行业的软件开发效率不断获得提升?解决之道:可信、平民化 DevOps云原生 DevOps 敏捷开发流水线,源
64、自于互联网在线业务的快速迭代开发,强调通过可定制的从需求管理、开发、编译链接、测试验证、上线发布、生产环境运维监控等所有软件生命周期阶段流程及流程活动自动化带来开发节奏的大幅加快,及客户需求响应敏捷度的大幅提升,然而其缺点和不足是在流水线上的安全及质量管控和加固的机制缺失,无法满足很多传统行业(如汽车制造、金融等)对其软件开发质量与安全合规的严格诉求,因此如何构建可信的 DevSecOps,成为大企业应用与软件生产现代化最关注的课题之一。另外,除 Full Code 的传统软件开发模式之外,各个行业也逐步积累沉淀了一些高于 PaaS 层、且行业特有的前端界面模板,及后端可重用业务逻辑/应用及数
65、据资产,这些资产能力通过高效的建模及编排,使得仅基于上述模板资产能力的编排及少量定制(低代码/零代码)即可实现行业应用的开发,从而使得行业应用效率得到大幅提升。挑战 9:如何让方兴未艾的人工智能技术助力全栈云服务更好地服务于云租户及云生态开发者,以及有效降低各行业开发者使用人工智能技术的门槛,更快捷地开发人工智能应用,并为行业生产力提升带来核心价值?解决之道:全栈 AI 加持,全行业 AI 普惠第一章|云原生概念与技术的历史 020云原生全栈能力的不断成熟,打破了人工智能(特别是深度学习)与云计算、大数据之间的技术与商业壁垒,使其融合成为有机整体:大数据、人工智能均转变可按需消费的云服务,云计
66、算为大数据分析和人工智能训练与推理提供“统一算力”,大数据、数据库则为人工智能提供“统一算据”,使得大数据、人工智能不再是成本高昂的“奢侈品”,加之人工智能技术近年来在计算机视觉识别、语音识别、自然语言 NLP、图文 OCR、线性规划最优次优求解、知识图谱等领域的日益成熟及广泛工程应用,使得 AI 技术无论面向全栈云自身的运维与优化效率提升,还是直接服务于各行业场景的运营优化与生产力提升,均蕴藏着巨大的潜能与无限的可能性。挑战10:如何让云安全不仅作为对外产品直接为租户和开发者提供立体式的数据、应用、网络及认证鉴权等安全服务保障,更能对内与全栈各云服务能力紧密协同,实现租户端到端应用架构的安全
67、可信?解决之道:全方位立体式的云安全防护云原生对云安全能力的考虑,主要聚焦在容器化平台及微服务治理框架范围内,服务访问合证鉴权,以及服务间互通的合法性、私密性保护相关的证书及安全凭证管理,缺少从网络边界、应用、数据、行业国家隐私、安全合规等全方位的云安全能力体系化设计,以及云服务及云上应用如何高效调用或适用这些云安全框架能力的设计模式与最佳实践指导。企业仍主要依赖相对独立和割裂的传统商业化IT安全软件及“基于防火墙硬盒子”来承担企业IT免遭安全攻击的屏障与保护层角色,但该安全防护模式显然也越来越难以匹配与企业业务快速增长同步的潜在安全攻击源和攻击方式的隐蔽多样化,以及多变性等特征,从而促使云安
68、全也走向安全多租化、软件化,以及智能化的趋势。总之,为突破上述千行百业 IT 云化发展历程中面临的一系列困难和挑战,云原生正在迎来一场更为深刻全面、全栈、全场景的云化架构变革,这就是云原生 2.0。云原生 2.0 时代序幕拉开的第一个重要标志,是 CNCF 云原生社区技术与开源版图的蓬勃演进发展,从最初的容器、微服务、DevOps 等技术领域,迅速扩展到如今的底层云原生基础设施技术、编排及管理技术、云安全技术、监测分析技术、大数据技术、人工智能技术、数据库技术以及场景化应用等众多分支,初步形成了支撑应用云原生化构建的全生命周期技术链。同时细分领域的技术也趋于多元化发展,CNCF的云原生开源版图
69、,由开始单一的容器编排项目 Kubernetes,发展到如今 5 大类 100 多个项目,Kubernetes 已成为云原生的操作系统,在其上发展出面向各行业、不同功能、不同应用场景的开源项目,Spark、Flink、Kafka、Redis 等开源项目也陆续加入 CNCF 的云原生技术图谱,进一步完善了云原生技术生态,也引领云原生再次迎来了前所未有的发展浪潮,极大加速了云原生在全球范围内的快速应用和发展。021云原生 2.0 架构白皮书而云原生2.0架构的商业价值与最终愿景,是面向千行百业(无论是孕育云原生的互联网企业,还是呼唤云原生重构改造实现数字化赋能的非互联网的政企客户)的业务与应用开发
70、与运维团队,提供涵盖云原生基础设施、数据使能、应用使能、AI 使能、视频使能、企业应用数据集成、万物互联、企业办公协同等在内的全栈数字化平台能力,从而将全栈云优势最大限度地发挥出来,将企业 IT 信息开发人员从云基础设施、各类应用、数据、AI 等平台中间件与使能组件的重复开发与日常运维管理等方面的繁重负担中解放出来,并帮助企业从基础平台使能层构筑弹性敏捷自动化、水平弹性按需扩展、安全可信、韧性高可用高可靠等非功能的关键企业架构属性能力,使得企业最终可将有限的精力和资金投入到核心业务竞争力上,从而实现数字化、智能化转型中的投入产出效率最大化。图 1-7 CNCF Cloud Native Int
71、eractive Landscape来源:https:/cf.io/第二章|云原生 2.0 的技术及架构特征022第二章云原生2.0的技术及架构特征023云原生 2.0 架构白皮书前文提到,伴随着以企业应用及数据云化为手段的千行百业数字化、智能化转型不断走向纵深,为确保各产业及行业领域的客户能更充分、全面地受益于云转型所带来的技术红利,进而带动相应产业及行业自身的升级换代及生产力变革,云原生技术迫切呼唤跨代际的突破和演进,云原生2.0 由此应运而生,以下就针对前文提到的云原生 2.0 关键特征,对云原生 2.0 的价值驱动及架构原则逐一进行解读和阐述。2.1.1 趋势与需求分布式云是将云服务分
72、布到不同物理位置,运营、治理和演进可由统一组织负责提供。当前业界的分布式云解决方案主要由公有云服务商提供,或由云服务供应商统一建设、交付、托管。使用分布式云,使组织能够让这些服务的物理位置更靠近本地,有助于支持低延迟场景、降低数据成本,并有助于遵守规定数据必须留在某个特定地区中的法律法规要求。随着近年来企业数字化转型不断深入,企业云基础设施的规模与复杂度快速提升,带来的结果是自身 IT 团队的大部分精力都投入到了基础设施的管理与运维中。因此,分布式云通过管理平台的集中部署和运维托管,可以使得组织不用管理自己的云基础设施,从而专注于自己的业务本身。从地域覆盖的角度看,分布式云应该充分覆盖核心区域
73、、热点区域、客户机房、业务现场四个不同的区域,在不同的层次为用户提供最适合的服务。从基础设施的角度看,承载分布式云上层业务的基础设施可以由单一厂商提供,实现单一云内的分布式架构;基础设施也可以由不同厂家提供,并由上层云原生管理平台在云原生服务层面形成统一的平台,从而形成跨云的云际计算。但不管是哪种形式,其上层的云原生平台都应该具备统一化、全局化的特点,形成统一的分布式云服务化平台。Gartner 预测到 2025 年超过 50%的组织将在其选择的地点使用分布式云。随着移动终端及物联网的技术发展和普及应用,以及企业业务的跨区域部署,从互联网到政企客户都产生了对分布式云的强烈需求。基于互联网互动视
74、频的创新业务,AR/VR/云游戏等,正在催生本地渲染的云基础设施发展;另外低时延(OT 应用)、数据本地驻留(合规),本地数据处理(视频监控)等政企应用,在催生本地计算的云基础设施发展。基础设施部署将从集中式向分布式演进,实现云的最后一公里覆盖。关键特征一:分布式云2.1第二章|云原生 2.0 的技术及架构特征024总结来说,分布式云发展的核心驱动力有如下几点:低时延:为满足低时延要求,需要在离业务现场最近的位置构建解决方案,减少业务处理时延,业务本地闭环。海量数据分析(带宽优化):5G/IoT 时代边缘数据爆炸性增长,难以直接回传至云端且成本高昂,数据在本地进行分析和过滤,仅回传结果,节省网
75、络带宽,如 AI 推理、流分析等。安全隐私:数据涉及企业生产和经营活动安全,在边缘处理企业保密信息、个人隐私。本地自治&交互:不依赖云端的离线处理能力、自我恢复能力;能够与本地系统进行交互。按需提供服务:公共云的服务可以按需灵活部署在其他区域,无需镜像公共云的所有服务,以节省资源开销。2.1.2 关键特征与架构原则分布式云的核心是跨地理位置以及用户可以将全部基础设施交由公共云服务提供商进行运营和运维管理。在实施上具有全域协同的特征:1)服务协同服务协同主要指分布在不同地理位置的业务,可以进行微服务之间的协同。具体包括微服务跨边云发现和通信,通信全链路进行路由、限流、熔断等治理能力,灰度发布、金
76、丝雀、蓝绿发布等典型发布流程。2)业务管理协同业务管理协同是指用户可以在云端对边缘侧的复杂业务模型进行管理,以集中式的管理方式降低管理运维成本,提升人效。3)数据协同支持分布式云的数据同步、共享,能够完成应用在不同位置分布式云之间的无缝衔接,满足应用在分布式云上使用数据的一致性。4)资源协同构建统一的分布式资源调度机制,能够根据分不同位置的分布式的能力、位置、业务运行状态、资源使用情况,以及用户的习惯和意图,选择合适的站点进行资源分配、容灾编排;另外,在物联网场景的边缘计算中,提供云-边-端的资源协同管理,在云端统一管理边-端的节点和设备。资源协同的核心就是对节点、设备进行功能抽象,在云-边-
77、端之间通过各种协议完成数据接入,在云端统一管理和运维。025云原生 2.0 架构白皮书1.分布式基础设施企业上云过程对云的诉求是由多维度的因素驱动而产生,用户的所在行业、经营的业务、产生的数据、处于的位置等因素不同会对分布式云基础设施提出不同的要求。所以,就要求分布式云基础设施在不同的地理位置,支持以不同的接入方式,提供不同的资源和服务以满足企业多样化的需求。基础设施架构从云位置的视角观察可以划分为核心区域、热点区域、本地机房、业务现场,这些区域内的基础设施定位不同,对外提供不同的资源、网络、SLA 等规格。图 2-1 分布式云原生图 2-2 处于不同位置的分布式基础设施分布式集群统一管理云原
78、生服务中心分布式管理调度全域流量控制分布式数据管理中心区域热点区域客户机房业务现场华为云基础设施(CCE)第三方设备(CCE Agile/IEF)核心区域热点区域本地机房中心Region边缘数据中心企业边缘站点企业专属RegionAloT边缘节点业务现场传感器|OT设备|机器人|摄像头|无人机|智能手机|VR.第二章|云原生 2.0 的技术及架构特征026敏捷和效率是分布式云原生为用户带来的核心价值之一,所以需要快速敏捷的响应用户需求,满足用户位置和网络多样性的诉求,例如,自建 DC、CDN 机房、PSTN 机房,甚至是场馆、办公环境、公网、专线、骨干网等等。满足基础设施高效敏捷诉求的关键技术
79、手段:高度模块化的交付设计中心,可以乐高式模块化搭建,快速批量的完成站点设计。可编排的超级自动化流水线,跨领域协同、跨工具协同、快速批量的完成站点部署。开箱即用、极简交付,软硬一体化的全栈软硬件预安装,降低交付复杂性。分布式基础设保持与公有云或公共云架构同源,提供分布式算力集中化管理的能力,例如,云硬件、云网络设备、云平台、运维管理平台、管理 API 等。海量分布式云站点通过中心云进行统一管理运维,边缘侧站点架构需要轻量化部署,管理能力由中心云提供并纳管,避免多头管理和管理复杂化。通过分布式网络技术例如(分布式PoP),用户可基于不同业务对网络质量的不同需求(时延、抖动、故障率、成本等)选择合
80、适的网络接入方式(BGP、单线、CDN 网络)以获取分布式云算力进而实现业务需求与网络质量的最佳匹配。图 2-3 分布式网络技术就近接入上云Region AAZAZAZ网络服务区分布式云站点A分布式云可用区ARAZRAZ分布式云站点ARAZRAZ边缘网络服务分布式云可用区BRAZRAZ边缘网络服务Region BAZAZAZ网络服务区互联网/专线互联网/专线EdgePOPEdgePOPEdgePOPEdgePOPEdgePOPCentralPOPCentralPOPCentralPOP骨干网络027云原生 2.0 架构白皮书图 2-4 云厂商统一运维托管,用户免运维2.分布式云原生如今越来越多
81、的企业为其业务发展采用了多个云提供商,更多的云平台意味着更多的复杂性。多云容器平台为客户提供集群资源集中管理的统一入口,帮助客户从这些复杂性中跳脱出来。因此,需要通过多云治理对客户本地数据中心以及各个云厂商的私有云、公有云的资源以及 Kubernetes集群进行统一纳管,实现对异构资源的统一规划、分配、调度、监控、运维等管理操作。分布式云原生包含如下技术:1)统一分布式云治理在分布式云中,业务分布式化以满足分散部署的业务需求,管理则需要集中以降低管理成本。因此将分散至各处的分布式云基础设施进行中心式的统一管理是非常重要的特性。对分布式云进行统一管理需要提供多基础设施注册、连接、统一认证、分区管
82、理、统一访问、统一配置,合规治理等能力。用户免运维,云厂商集中提供运维服务集中运维服务平台云服务运维数据分布式云云服务分布式云云服务第二章|云原生 2.0 的技术及架构特征028随着业务的发展,业务运行环境日益复杂,环境已经扩展到多数据中心,多云以及边缘。每个环境都有自己独立分散管理工具,客户学习成本和操作复杂度都比较高。通过提供一致的多云和本地管理平台来简化治理与管理。通过统一认证将不同的环境的访问控制进行统一。通过统一访问将零碎的访问入口进行统一,提升运维开发效率。通过统一配置确保应用程序和集群在大规模部署时保持一致性。通过合规治理满足数据治理和安全要求,并有效地管理资产。2)全局应用调度
83、在多云多集群中部署时,应用具备根据一定的调度规则在不同的云中进行调度和迁移的能力。支持按权重部署,根据不同集群的权重设置自动计算和分发实例;根据 label 进行条件部署,通过集群 label 进行组合条件的设置,并根据条件的满足情况进行实例分发;容器从故障集群中自动迁移,当集群发生故障时,位于该集群中的应用实例可自动迁移至正常集群中;跨集群弹性伸缩,当需要对应用进行整体伸缩时,可根据不同集群的权重进行实例分配,实现用户优先在指定云上创建新资源的目的。另外,资源调度器根据全局资源的状态和网络 QoS 统计信息为每个租户/域名决策资源分布。分布式云用户在使用云资源时,由于无法掌握全局的动态资源信
84、息,当前只能靠人工经验指定位置要求固定的资源容量。这样对于用户,没有办法获取到最优质的资源改进业务服务质量,同时也缺乏应对业务突发的弹性手段。全域资源调度器,可以帮助用户即时掌控全域资源状态信息,包括动态的边缘站点可用资源、临近公有云资源以及优质的5G MEC资源,满足用户对服务(例图 2-5 分布式云原生基础设施统一管理公有云注册连接合规治理统一访问分区管理统一认证统一配置分布式云原生基础设施统一管理边缘云边缘节点用户IDC029云原生 2.0 架构白皮书如网络时延)的要求,同时在保证整体 QoS 最优下,可以针对成本、服务质量、业务波动做针对性优化。资源调度的关键点是全局资源视图和资源调度
85、算法。资源视图包括用户的位置、资源的成本、网络的 QoS、接入的地理位置等。全域调度算法的设计会考虑任务的 QoS 要求、亲和性、等待时长等一系列要求。另外还会基于利用率的评估,给用户一些低价资源和突发性实例推荐,使租户可以更好的优化自己的成本。图 2-6 全局应用调度全域资源调度全域流量调度网络QoS测量分析(全局裸机、容器(Node级别)、VM)位置分布算法成本优先算法边缘节点/5G MECRegion(中心云)IOT/终端活跃IP探测QoS建模分析时延敏感算法地理就近接入时延优先接入负载感知切换云边全局流量协同控制器智能DNS/HTTP DNS故障就近转移多目标求解器3)全域流量调度据资
86、源的预留分布,流量调度器在流量级进行精细化调度。在给定资源分配的情况下,流量调度为用户的每一位客户决策流量的分配位置。流量调度具有与业务高度相关的特点,针对不同业务的类型,流量调度的方法各不相同。例如,CDN 业务中,流量调度要同时支持接入调度和回源调度,且调度算法的设计需要考虑到内容缓存策略的影响。云游戏业务中,流量调度只需要支持接入调度即可。流量调度的关键点是精准控制和调度执行器。全局优化器基于历史数据完成流量粗粒度的流量规划以保障基础水位均衡,并基于分钟级的流量特征学习,决策控制周期和分配策略,对流量进行全局性的优化。实时调度器负责针对每个区域租户请求的毫秒级响应,执行、切换调度策略,并
87、当发生故障时,及时完成故障转移。华为云当前的全域流量调度,支持多种策略的选择,并基于流量的数据特征,充分发挥全局优化和区域灵活控制的特点,实现精准调度。第二章|云原生 2.0 的技术及架构特征0304)流量跨云协同流量跨云分发包含北向用户访问流量和东西向微服务间交互流量两种。在北向流量的跨云分发中,通过 GSLB 技术,实现用户流量的就近接入,同时具备对后端服务健康检查的能力,自动屏蔽故障服务实例后端。另外,通过服务网关进行入云流量治理。服务网关部署于每个分布式云成员的流量入口处。接收网格控制面的配置,提供跨 Region、多云混合云、多种基础设施的服务后端实例上的流量管理。包括但不限于:基于
88、权重和内容的流量切分、灰度、故障倒换、熔断限流等。东西向微服务间流量交互,依赖于在多云多集群中建立安全可信的通信通道,VPN、wildguard 是这里的常用技术。另外可通过地址映射和转换等方式处理多云中子网冲突的问题。在跨云网络互通基础之上,可以叠加 Service Mesh 技术实现东西向流量的治理能力。5.)数据协同数据跨云协同是指以应用为中心构建应用的克隆、迁移和容灾能力。数据包含应用配置数据和应用业务数据。基于多集群管理(如 armada)平台或云原生备份插件实现跨集群的配置数据的跨集群、跨 AZ、跨 Region、跨云数据协同能力。业务数据面对的场景比较复杂,整体可分为三层,也即:
89、基于存储基础设施的跨云数据协同:是指基于相同基础设施的场景下,利用存储基础设施的数据同步复制/异步复制能力,构建同 Region RPO=0,跨云/跨 Region RPO 15 分钟的数据容灾能力。图 2-7 全域流量调度边,线,狐有费用,容量,时延等点、节点目的始发47204420135流找“可行”或“最优”路径,考虑到量、成本、QoS等约束,可能有多路径。031云原生 2.0 架构白皮书 基于云原生基础设施的跨云数据协同:是指在云原生应用管理平台(K8S)场景下,通过存储抽象(PV/PVC)屏蔽存储基础设施的差异性,实现统一架构的跨集群、跨 AZ、跨 Region、
90、跨云数据协同能力。基于应用中间件生态的跨云数据协同:是指通过中间件生态平台(如:OSC)提供通用的数据协同的接入定义,与中间件应用提供商一起构筑跨集群、跨AZ、跨Region、跨云数据协同能力。图 2-8 数据协同MM存储基础设施数据备份存储库数据恢复中间件生态平台数据协同存储基础设施存储基础设施1232.2.1 趋势与需求随着云计算的发展,越来越多的应用已经云化部署,从早期的微服务,到大数据/AI,再到中间件,这些应用也对云基础设施不断提出新的要求。微服务是云化部署的典型应用,根据用户的使用情况,微服务对资源的请求会有较大的波动,需要云服务提供足够的资源,并能够快速启动实例;同时,为了保障用
91、户体验,对时延及 SLA 也有较高要求。大数据与 AI 技术为企业提供智能化,帮忙企业应对复杂的商业环境;但大数据与 AI 业务不仅对资源性能有较高要求,而且资源需求增涨速度较快,因此需要云服务提供大量高性能资源。中件间对资源的稳定性和性能也提出了较高的要求。关键特征二:应用驱动基础设施2.2第二章|云原生 2.0 的技术及架构特征032大规模的网络资源供应、泛在的网络安全隔离、极致的网络弹性和细粒度的网络 QoS 是承载大规模云原生业务的基础网络要求。资源供应方面,单 VPC 内多集群的容器端点数可以达到甚至超过百万,灾备场景的集群迁移要求容器级的网络配置、隔离,例如 QoS,带宽限速大批量
92、容器快速发放(10 万/分钟);网络弹性方面,Serverless/Function 等轻量级云原生运行时的要求毫秒级创建,秒级冷启动(包含网络端到端打通);安全隔离方面,无边界、零信任、海量端点和高动态性的云原生网络安全,要求即时生效的容器粒度安全隔离与 ACL;资源力度方面,在/离线业务混部场景下,为了能够发挥出云原生极致资源利用率和性价比,要求容器网口粒度的QoS(包括带宽保障和优先级支持)。不断变化的云原生业务诉求正推动着云网络架构的不断演进。2.2.2 关键特征与架构原则在云计算早期,通过架构分层为应用提供了灵活的基础设施以满足应用的多样性;进入云原生时代以来,以容器、微服务以及动态
93、编排为代表的云原生技术蓬勃发展,面向应用形成了统一的行业标准,为软硬协同、统一调度等能力提供了基础。云原生 2.0 以后,企业云化从“ON Cloud”走向“IN Cloud”,网络、存储等基础设施都面向应用做进一步优化,并催生了服务网格等新技术。1.软硬协同:通过软件卸载、硬件直通等技术,借助硬件的高性能为应用进行加速,从而达到降本增效的目的随着越来越多的应用运行云化部署,各种应用对云基础设施提出了更高的性能、稳定性及时延要求。为了应对这些新诉求,面向应用的软硬协同技术应运而生;软硬协同系统包含从芯片、硬件到软件的全栈技术创新,例如共享存储、高带宽等。同时,随着 5G 建设加速,5G 的低时
94、延、大带宽等能力也在催化各行各业孵化创新应用,完成数字化转型。典型的,互联网行业,这是一个技术迭代特别快的行业,新的云游戏、云 VR 等互联网应用对时延性能、确定性保障的要求会更高。政企行业,客户则会更关注安全可信等合规保障,自身计算资源的利用率等效能优化情况。通过深度软硬协同能力,为客户提供了近裸机体验的强劲性能、虚机/容器/裸机等多级计算粒度,和云上最丰富的算力。技术上,硬件卡是实现软硬协同的关键。从图中可以看到,之前运行在服务器内部的存储、网络、管控等能力,全部卸载至硬件卡实现,并进行芯片加速。033云原生 2.0 架构白皮书图 2-9 虚拟化演进虚拟化1.0-2003发源于实验室:纯软
95、件虚拟化VMVMBT/PVServerVMIBM 360斯坦福-Binary Translation剑桥-Para Virtualization虚拟化3.02018-计算存储网络Server硬件卡VMVMVM软硬协同前后端硬隔离,简约不简单前端自研Hypervisor,打掉一横、保留一纵资源“0”预留,虚拟化“0”开销,业务“0”抖动,算力“0”损失后端硬件实现I/O卸载加速Virtio虚拟化语义硬件实现,前向无缝透传VMlibvirtV qemu卸载,后向无缝接入云管控、云存储、云网格存储、网格卸载加速,性能硬隔离虚拟化2.02004-2017计算存储网络ServerVMVMVMKVM/Xe
96、n:硬件辅助虚拟化CPU硬件辅助虚拟化CPU虚拟化:VT-x实现CPU虚拟化,开销较大Mem虚拟化:EPT实现内存隔离,开销极小I/O虚拟化:VT-d、SR-IOV技术引入生态和弹性问题I/O性能飙升,成本高昂Workload干扰,业务抖动算力损失虚拟逃逸软硬协同降低了之前通过软件实现网络、存储等功能产生的 CPU 开销,并通过芯片实现全IO 路径的性能加速;例如,基于擎天卡与华为全栈自研的 CurreNET 网络技术,实现 VF 直通与网络零拷贝,时延可低至 10us。计算虚拟化:在计算虚拟化方面,通过硬件卡实现了 IO 虚拟化等能力,主机侧仅保留了CPU 和内存的隔离和映射,最大限度将对虚
97、拟机的扰动降到最低;并通过动态调频技术,让每台主机可降低能耗,实现效能极优。通过安全芯片,可确保主板固件零篡改,实现主机的安全启动;最后,通过安全芯片与硬件卡构成的安全系统,将传统依靠软件来实现的身份证明,通过硬件实现密钥保护,真正做到硬件身份证明,进一步确保全流程零差错,做到安全可信。网络虚拟化:在网络虚拟化方面,为了避免大规模高速网络环境下存在的拥塞情况,基于硬件能力实现了新的算法稳定拥塞控制,支撑更大组网规模提升,大幅降低长尾时延。基于硬件卡将 RDMA 网络应用于虚拟机,为 HPC 高性能计算等场景带来更强性能,与更高性价比。更进一步,除了性能、安全、能效方面的创新,通过软硬协同也将实
98、现租户业务的稳定和确定性 QoS。网络通过虚拟机、网卡的两级硬件 QoS,保障了虚拟机带宽、PPS、会话连接数等多维度的确定性,更通过 Bucket 桶资源做到上限反压时不丢包。存储虚拟化:在存储方面,将 DIF 校验、EC 算法等过程也通过硬件卡来实现,在大幅降低时延的同时获得较高的带宽,可以大幅提升数据库、AI 训练等场景效率;除了性能外,安全芯片也帮助应用做到从主机启动到 IO 处理等全流程的安全可信。在数据加密方面,一般传统第二章|云原生 2.0 的技术及架构特征034软件方式加密存在 10%20%左右的性能损耗;将加密的流程卸载至硬件卡后,实现了加解密过程的硬件加速,让用户基本感知不
99、到因加密带来的性能损耗。2.云原生网络:云原生网络面向应用进行优化,将虚机网络加容器网络进行归一,由多层变一层,提供高性能网络;同时,通过服务网格(Service Mesh)解决应用的服务治理问题1)基础网络:以应用为中心,重构更加快速的,全新的云原生网络很多客户的业务对时延有较高的敏感性,尤其是短连接的 TCP 应用,因 TCP 建链需要多次报文交互,对首包时延非常敏感,比如游戏登陆平台,在玩家登陆的时候,需要和数据库进行数据交互获取玩家账号相关信息,首包时延大不仅影响玩家登陆体验,同样也会影响整个游戏登陆系统支持同时登陆玩家数量的能力。基于原生 openstack 架构的数据面存在慢路径问
100、题,通常情况下首包时延比后续建链后的报文时延高;下一代数据面在保证兼容原生openstack系统的基础上,需要进行转发路径优化,所有报文不再有快慢路径之分,从而降低首包时延。同时,客户业务系统部署上云时,为了提高业务系统可靠性,一般会采用集群模式部署,其中很多系统需要通过主备集群模式来部署,典型如 RDS 数据库、自建 NAT 服务器等,这就要求云上的平台能支持便捷、高效的主备倒换能力。一般情况下,通过 VIP 或从网卡提供主备倒换能力;但 VIP 因底层实现方式差异,整体转发能力比正常虚拟机网卡差;并且后续的 IPv6 VIP 也需要通过 API 切换,从网卡迁移会导致内网 IP 丢失等问题
101、。通过动态 IP 绑定弹性网卡(ENI/subENI)后,同时具备了私网及公网能力,弹性网卡在虚拟机间迁移,即可完成私有 IP 和公网 IP 的同时迁移。如下图所示,可以支持三种迁移方式:EIP+ENI 迁移 EIP+subENI,跟随 ENI 一起迁移 EIP+subENI 迁移 图 2-10 迁移方案IPIPIPIPIPIPIPIPIP安全组2主网卡(subnet1)从网卡(subnet2)安全组1ECSECS安全组2安全组1安全组2安全组3VIPsubnet1VIPsubnet1ENI(subnet3)subENIsubnet1subENIsubnet1ENI(subnet1)subEN
102、Isubnet1subENIsubnet1更独立的安全控制更多的IP地址规格035云原生 2.0 架构白皮书2)服务网络:全新的应用级网络,全面提升应用的治理能力随着越来越多的应用进行云化部署,对各个服务之间的治理以及灰度发布等能力提出了更高的要求;目前基于流量、LB 等组件已经无法满足大量微服务的诉求。为了应对服务治理及灰度发布的需求,业界引入了服务网格这一技术。服务网格以一种更加解耦的方式将服务治理能力变成独立进程,对应用的访问进行非侵入管理。在大部分容器场景下,通过容器部署形式再应用容器启动过程中,将服务治理进程作为独立容器注入到应用 Pod 中,并拦截出入应用的流量。从这里看出:网络上
103、额外增加了两跳,通信时延势必有所增加。同时每个数据面代理自身的七层数据代理能力也对端到端请求处理的时延有较大影响。数据面代理和客户应用部署在相同的主机空间内,一旦主机 CPU 使用率较高时,分配给数据面代理的时间片将会减少,这样导致路由选择和转发率下降,更多应用发出的请求将被堆积,导致整体时延显著增加。并且由于主流数据面代理为 Pod 内部署形式,无法进行绑核等操作,基于现有架构较难解决。每个 Pod 内都需要部署一个数据界面代理进程,实测每个代理将占用 70MB 以上的内存空间,因此实际分配给应用的内存将达不到需求获知导致主机内存利用率较低。数据面代理运行在主机空间,多租环境下拥有节点登录权
104、限的用户有机会查看其他应用代理的运行状态、拦截数据面通信网络流量或下发额外的配置给其他应用的数据面代理,对节点内数据安全保障造成一定的风险。引入节点共享数据面模式,将节点内每个 Pod 内的 Sidecar 移到节点上进行整合,消除每个 Pod 内 Sidecar 额外内存占用。节点上共享数据面形成高可用,自动识别网格流量类型并进行拦截,对不同业务进行 QOS 连接保障。另外分离数据面代理与业务应用的生命周期便于对数据面代理自身所使用的系统资源进行预先规划,同时可以利用节点内提供的其他硬件加速能力。优化应用到数据面代理之间、本节点数据面代理与其他节点数据面代理网络通信。采用sockmap、用户
105、态协议栈、RDMA 等技术进一步降低高并发连接情况下端到端网络时延TP90 及提升吞吐 QPS。优化数据面代理自身线程模型提升网络事件响应效率,优化连接调度减少工作线程对连接处理的不均衡问题降低端到端网络时延 TP90。基于七层网格数据面代理的硬件卸载,隔离用户空间对数据面代理的访问,保障节点内网格流量及网格运维的安全。进一步整合智能网卡内计算加速能力及协议栈硬件加速能力,同时就近集成大云环境下其他网络通信特性。第二章|云原生 2.0 的技术及架构特征036引入共享数据面模式后,对于规格较大的节点内存资源消耗有较大的降低;预先绑定数据面CPU/NUMA 等资源后,代理效率提升明显,减少端到端调
106、用时延;节点内流量采用 sockmap 端到端降低网络时延;优化数据面代理自身线程模型及连接调度。3.云原生存储:云原生存储面向应用进行优化,通过独立的存储网络通道解决网络通道上限、性能折损和资源开销等问题;并提供应用级的备份/恢复、迁移、数据监控等能力容器存储面临着共享存储网络让吞吐受限,虚拟化让性能折损和资源开销增加等问题。多个块存储共享节点上存储网络通道,让性能受限、时延增加。性能越高的块存储,虚拟化带来的性能折损越明显;文件存储通过 virtio 技术共享给容器使用,叠加的虚拟化层让存储性能折损和资源开销增加。云原生存储将为每个 pod 分配独立的存储网络通道,该 pod 中所有的容器
107、使用的块存储都挂载到该网络通道上,解决了共享网络通道上限、虚拟化/叠加虚拟化增加性能折损和资源开销问题。块存储直通到安全容器中,业务负载对块存储的 IO 请求直接通过该通道交给卸载卡组件处理,大大降低了时延,也避免共享网络通道上限的问题;文件存储直接挂载到安全容器中,略去 virtio 虚拟化层,提高请求效率,提升请求处理效率。另一方面,随着云原生技术的不断成熟,基于 K8S 容器平台的云原生应用快速增长。现有容器存储的解决方案面临着云原生应用的跨集群迁移、缓存加速、完善的数据驾驶舱能力。通过Operator 机制构建云原生数据管理、云原生缓存、云原生监控能力,为云原生应用提供 K8S 元数图
108、 2-11 Service Mesh来源:https:/ Mesh Control PlaneInstanceASidecarProxySidecarProxySidecarProxyInstanceBInstanceCControlPlaneData PlaneEast-WestTraffic037云原生 2.0 架构白皮书2.3.1 趋势与需求在云计算早期,当应用进行云化部署时会根据应用的需求选择不同的算力类型和粒度,并进行单独规划;烟囱式的部署极大的影响了资源的使用效率,同时也给应用的运维带来了极大的不便。进入云原生时代以来,以容器、微服务以及动态编排为代表的云原生技术形成了统一的行业标
109、准,将不同应用统一到云原生标准下;智能调度等技术为应用提供了统一的资源池,让多种应用可以混合部署,并与资源高效协同。2.3.2 关键特征与架构原则1.混合部署各种应用进行云化部署后,通过将所有应用混合部署在同一资源池中,并根据应用的不同属性及资源请求,最大限度的复用资源,提升资源使用效率。同时,当多业务混合部署后,为了保证各个应用的服务质量,需要操作系统提供较强的资源隔离能力。企业核心业务全面云原生化后,降本增效和运维成本是困扰企业的主要难题。以应用为中心的调度是解决这些难题主要的途径之一;通过面向应用的调度,可以在同一集群内支持多种不同的应用类型,借助业务资源请求的互补性可以大幅提升资源的使
110、用率;通过支持大规模集群,可以将大量的应用提交至同一的集群中,从而减少应用的运维成本。大规模场景下,基于共享视图的并行多调度器架构,大幅提升集群整体调度的吞吐率,实现万级任务并发。通过任务拓扑感知调度、网络 IO 感知调度、NUMA 感知调度等多种应用和硬件感知调度技术,满足不同类型应用模型对资源的诉求,为应用匹配最佳的资源。通过多业务类型的分时复用、混合调度、资源的超卖、隔离技术,减少集群资源的空闲比例,实现集群全时段资源最大化利用。关键特征三:混合部署,统一调度2.3据和 PV 数据卷的一键式备份/恢复、跨集群克隆/迁移、近算缓存加速和数据监控能力。松耦合、插件式、按需部署的备份/恢复、克
111、隆/迁移、监控/采集等插件集合:为云原生应用提供应用备份/恢复、应用克隆/迁移、应用数据监控能力。第二章|云原生 2.0 的技术及架构特征038不同的应用对性能有不同的需要,针对性能敏感型应用需要为其提供性能保证,而且对于普通型应用,仅需保证其有只足够的资源量。为保证性能敏感型应用,需要在操作系统层提供隔离抢占技术,该技术涉及的资源包括 CPU、内存、网络和 IO 等等,针对每一种资源,需要结合已有隔离技术来应对混合部署场景下的新需求。在离线混合部署对的资源的需求可归纳为两点:对于使用分配情况优先供应给在线任务,对于回收情况优先从离线任务回收资源。图 2-12 混合部署GPUDevicePlu
112、ginYangtseAgentedpfedpfedpf代码注入QoS(优先级,流控)路由、转发流观测服务加速vNICEVSNIC/ENIiGPUCPU 调度策略调度网络策略PodHost OS(openEuler/CentOS)Kubernetes 节点2.统一资源池越来越多的应用云化部署,希望云服务可以提供统一、无限的资源,从而减少资源申请及管理的复杂度,提升运维效率,快速应对业务峰值等需求。应用云化部署以后,统一的资源池将用户从服务器的管理中解放出来,用户只需要专注于自身业务。统一资源池为应用屏蔽了基础设施,提供了自动化的运行环境、随时按需使用、按实际用量计费的能力。目前大部分的云服务厂商
113、仍依据成本,用户量等因素在不同的地域(Region)建设资源,用户再根据业务、成本、性能等因素选择相应的 Region 提交作业,不同 Region 的网络时延、资源成本、数据就近访问成为跨 Region 作业管理的难点。全域调度是面向跨 Region 场景的下一代统一调度,不仅能够通过全局资源的调配来达到降本增效的目的,还能将用户从多039云原生 2.0 架构白皮书Region 的管理与运维中解放出来,让客户聚焦到业务本身,提供真正的统一资源池体验。全域调度维护的全局资源视图包含了各 Region 的资源分配和使用情况、数据位置、地理位置、网络时延、资源成本等信息,并通过资源、网络成本最优,
114、跨 Region 时延最优,就近接入、数据亲和等全域调度策略最大化资源使用率,为应用提供全网资源。在统一资源池以前,用户为了保证服务的稳定性和性能通常按照波峰申请资源,大量的资源会在波谷期闲置,据第三方机构统计,大多数在线服务集群的平均使用率低于15%;而另外一方面,对资源消耗量非常大的大数据、AI、HPC 作业,资源常常到不到满足;资源无法统一规划和使用。基于统一资源池,可以将用户提交的 Web 应用、大数据、AI、HPC 作业根据其对资源的诉求和负载情况,优化调度方式,提供资源抢占,分时复用等机制减少集群资源的空闲比例。通过作业混合部署和资源超卖的方式,实现集群资源利用率的提升。作业进行统
115、一调度,在资源真正发生竞争之前进行规划。同时提供诸如:节点资源监控,资源超卖,动态调度,离线业务重调度等功能。操作系统层面,支持在 cgroups 中进行物理资源隔离,资源发生竞争情况下,根据任务的优先级,保障高优先级任务不受影响,降低对低优先级任务伤害通过在离线作业混部,提升集群物理资源使用效率。当在线作业压力较低时,节点上物理资源的使用率较低,调度器进行资源超卖,将离线作业调度到相应的节点上运行。当在线作业压力变大时,调度器驱逐掉当前节点上的离线作业,保证在线作业能够正常运行。3.多维度调度随着应用的多样化,对调度也提出了新的挑战;要求云服务从应用、资源以及流量等多维度进行业务调度,在满足
116、服务质量的同时,最大限度的降低成本,提高资源使用率。随着应用以及计算资源的增多,云服务需要引入多维度的调度来提升资源的使用率,从而降低成本,提高应用稳定性及性能。因此,云计算规模发展和计算资源多元化趋势,在资源有效利用、资源成本控制等方面对云提供商的资源供应提出了更高的要求,打造算力池化、技术栈统一、数据自驱的多维度资源管控平台成为了技术发展的必然选择。多维度资源管控平台具有以下特点:资源调度:多维资源调度统一计算节点技术栈基础,并在调度方面实现资源分层、协同调度。资源池调度系统屏蔽多元化算力资源差异,在资源池化基础上完成在线资源调度、离线资源整理、资源自适应调整等功能,通过精细化调度实现资源
117、利用率的有效提升。问题建模、求解:使用统一的问题建模语言,应用统一的问题求解框架,解耦问题建模与算法求解过程,成为了一个趋势。数据自驱演进:超大规模资源的管理和高效利用,高度依赖实时、自动化、智能化的数字化管理能力,为系统架构、功能的长期演进提供数据支撑。第二章|云原生 2.0 的技术及架构特征0402.4.1 趋势与需求从 2006 年云计算初现端倪,到计算虚拟化、网络虚拟化、Openstack 等技术层出不穷,第一个阶段主要改变的是基础设施管理的工作方式,从繁重的机房建设和维护工作中解放出来。云厂商提供虚拟服务器和网络等资源的供给服务,让用户将应用从物理服务器迁移到虚拟服务器上,实现资源云
118、化,从而降低资源管理成本。随后,Docker 容器、Kubernetes 等技术逐步流行,并出现了如 Spring-Cloud、Dubbo 等基于云服务的云原生开发框架,云厂商通过提供容器、代码控制管理、编译流水线、自动化测试、中间件等工具,实现应用环境标准化、实践 DevOps、简化应用迁移与托管,提高编排和运维效率。2015 年,AWS 发布 Lambda 标志着 Serverless 理念的 FaaS(Function-as-a-Service)函数计算模式出现,旨在屏蔽服务端的复杂配置和运维,简化云开发以聚焦业务逻辑,改变开发人员的工作方式。Serverless 理念让应用构建与云服务
119、深度结合,以发挥云平台弹性伸缩、按需计费、免运维等能力,实现松耦合、快速上线、高性价比的现代化应用,从而降本增效。2019 年,各大云厂商开始积极拥抱 Serverless 理念,并推出多样化的产品,总体而言,Serverless 应该具备的三个基本要素:提供一个小颗粒或大颗粒的抽象,隐藏服务器以及编程和操作服务器的复杂性。提供现收现付成本模型,而不是基于预订的模型,因此闲置资源不收费。自动、快速和无限扩展资源,以紧密匹配需求,从零到几乎无限。一方面,Serverless 为用户屏蔽云端复杂度,简化云应用开发、托管和运维,提高应用开发上线效率,提供资源按需计费模型,降低应用部署和运维成本;另一
120、方面,云厂商通过 Serverless更灵活的管理闲置资源,提升系统资源利用率,实现用户和云厂商双赢。2019 年,加州大学伯克利分校在 Cloud Programming Simplified:A Berkerley View on Serverless Computing 的回顾中总结到,当前的云平台在简化运维和提升硬件利用率上仍然无法让人满意。因为开发者还需要管理虚拟机的可靠性、负载均衡、容灾、扩容和缩容、监控、日志及系统升级,挑战仍然较大。尤其规模较小的企业,很难雇佣到熟练的运维或 DevOps 人员,无法通过自动化工具、脚本、服务来解决这些问题。伯克利大学指出 Serverless
121、有望弥补这些不足。Serverless 弱化了存储和计算之间的关系,使计算变得无状态、调度及扩容/缩容更容易、数据更安全。开发者不再需要手动创建虚拟机或管理其他资源(网络带宽等),只需要专注在业务代码开发上。同时,函数根据调用次数和每次计算的资源开销来计费,更加合理。关键特征四:无服务器化(Serverless)2.4041云原生 2.0 架构白皮书2.4.2 关键特征与架构原则从开发者或商业的角度看来,Serverless 的价值在于全托管及创新的计费模式。但从技术的角度看,Serverless 从架构、开发模式、基础设施等层面都呈现出区别以往的特征:1.Serverless 是事件驱动架构
122、的延伸Serverless 更容易实现事件驱动的应用。在分布式系统中,请求/响应的方式和事件驱动的方式都存在。请求/响应是指客户端会发出一个请求并等待一个响应,该过程允许同步或异步方式。虽然请求者可以允许该响应异步到达,但对响应到达的预期本身就在一个响应和另一个响应之间建立了直接的依赖关系。事件驱动的架构是指在松耦合系统中通过生产和消费事件来互相交换信息。相比请求/响应的方式,事件的方式更解耦,并且更加自治。例如,在图片上传后进行转换处理的场景,以往需要一个长时运行的服务去轮询是否有新图片产生,而在 Serverless 下,用户不需要进行编码轮询,只需要通过配置将对象存储服务中的上传事件对接
123、到函数即可,文件上传后会自动触发函数进行图片转换。Serverless 架构的基本单元从微服务变为函数。微服务的每个 API 的非功能属性有差异,比如对性能、扩展性、部署频率的要求并不相同,进一步拆分的确有助于系统的持续演进,但相应会带来指数级的服务数量增长,导致微服务的基础设施和运维体系难以支撑。Serverless 架构可以将微服务的粒度进一步降低到函数级,同时不会对基础设施和运维产生新的负担,只是增加了少量的函数管理成本,相比其带来的收益是完全可以接受的。2.Serverless 简化了开发模式微服务提供了丰富的框架,方便开发者进行开发,但同时也增加了开发者的认知负担,同样是使用 Jav
124、a,基于 Serverless 开发服务,开发者只需掌握 Java 的基础特性、函数编程框架及BaaS 的 SDK 即可,如下图所示:图 2-13 serverless 开发分布式事务SpringCloudSpringDataSpringBootSpring框架(loC,AOP)Java并发编程Java基础语言特性/API分布式事务BaaS SDK函数编程框架Java基础语言特性/API分布式事务BaaS SDK函数编程框架Java基础语言特性/APICircuit Breaker ConfigOpenFeign Commons.第二章|云原生 2.0 的技术及架构特征042函数的编程框架相比
125、 Spring/SpringBoot 要简单很多,开发者只需了解输入输出处理(通常为JSON)及如何处理业务逻辑。基于函数的编程模型,可以继续对数据进行抽象操作。3.Serverless 是不可变基础设施的最佳实践Serverless 直接以代码方式部署,开发者不用再考虑容器镜像打包、镜像维护等问题。系统通常在部署时重新创建函数实例,在不使用时回收实例,每次处理用户请求的可能都是全新的实例,降低了因为环境变化出错的风险。而这些部署及变更的过程,对用户来说只是更新代码,其复杂度相比使用容器及 Kubernetes 大大降低。Serverless 在扩展性方面也具有优势。FaaS 和 BaaS 对
126、开发人员来说没有“预先计划容量”的概念,也不需要配置“自动扩展”触发器或规则。缩放由Serverless 平台自动发生,无须开发人员干预。请求处理完成后,Serverless 平台会自动压缩计算资源,当面对突发流量时,Serverless 可以做到毫秒级扩容,保证及时响应。基于 Serverless 的服务治理也更简单。例如,通过 API 网关服务可以对函数进行 SLA(服务水平协议)设置限流,函数请求出错后会自动重试,直至进入死信队列,开发者可以针对死信队列进行重放,最终保证请求得到处理。Serverless 平台默认对接了监控、日志、调用链系统,开发者无须再费力单独维护运维的基础设施。虽然
127、当前 Serverless 的监控指标并不如传统的监控指标丰富,但是其更关注的是应用的黄金指标,如延迟、流量、错误和饱和度。这样可以减少复杂的干扰信息,使开发者专注在用户体验相关的指标上。Serverless 的关键技术可以基于如下 Serverless系统架构进行描述:图 2-14 serverless 系统架构HTTP请求事件源函数编程模型FaaS平台BaaS平台API网关消息队列触发器事件事件异步/同步定时器loT.def handler(event,context)FaaS控制器云存储身份认证消息队列API网关NoSQL数据库.函数实例容器eventcontext043云原生 2.0
128、架构白皮书 事件源(Event Sources):事件的生产者,可能是 HTTP 请求、消息队列的事件等,通过同步或异步的方式去触发函数。触发器(Trigger):函数的 REST 呈现,通常是 RESTful URL。当事件源将事件推/拉到触发器时,FaaS 平台会查找触发器和函数的映射关系,从而启动该函数实例,以响应被推/拉到触发器的事件。FaaS控制器(FaaS Controller):FaaS平台的核心组件,管理函数的生命周期、扩容和缩容等。可以将函数实例缩容为 0,同时在收到对函数的请求时迅速启动新的函数实例。函数实例(Function Instance):执行函数的环境,包含函数代
129、码、函数运行环境(如 JRE、Node.js)、上下文信息(如函数运行的配置,通常以环境变量注入)。一个函数实例可以同时处理 1 个或 N 个事件(取决于平台的具体实现)。函数实例通常内置可观测性,将日志和监控信息上报到对应的日志和监控服务中。函数编程模型(Programming Model):通常表现为函数的编码规范,如签名、入口的方法名等。函数的编程模型一般会提供同步/异步/异常处理机制,开发者只需要处理输入(事件、上下文),并返回结果即可。BaaS 平台:函数通常是无状态的,其状态一般存储在 BaaS 服务中,如 NoSQL 数据库等。函数可以基于 REST API 或 BaaS 服务提
130、供的 SDK 来访问 BaaS 服务,而不用关心这些服务的扩容和缩容问题。结合上图中典型 Serverless 架构的架构元素,从 Serverless 系统的实现来看,其关键技术需求包括以下几点:函数编程模型:提供友好的编程模型,使开发者可以聚焦于业务逻辑,为开发者屏蔽编码中最困难的部分,如并发编程等。同时,需要原生支持函数的编排,尽量减少开发者的学习成本。快速扩容:传统的基础设施通常都是从1到n扩容的,而Serverless平台需要支持从0到n扩容,以更快的扩容速度应对流量的变化。同时,传统基础设施基于资源的扩容决策周期(监控周期)过长,而 Serverless 平台可达到秒级甚至毫秒级的
131、扩容速度。快速启动:函数被请求时才会创建实例,该准备过程会消耗较长的时间,影响函数的启动性能。同理,对于新到达的并发请求,会产生并发的冷启动问题。Serverless 平台需要降低冷启动时延,以满足应用对性能的诉求。高效连接:函数需要将状态或数据存放在后端 BaaS 服务中,而对接这些服务往往需要繁杂的 API,造成开发人员的学习负担。如果能提供统一的后端访问接口,则可以降低开发和迁移成本。另外,Serverless 平台的函数实例生命周期通常较短,对于如 RDS 数据库等后端服务无法保持长连接。然而,在并发冷启动场景下,大量函数实例会同时创建与数据库的连接,第二章|云原生 2.0 的技术及架
132、构特征044可能会导致数据库负载增加而访问失败。为此,Serverless 平台需要为函数提供完备、高效、可靠的 BaaS 服务连接/访问接口。安全隔离:Serverless 是逻辑多租的服务,租户的函数代码可能运行在同一台服务器上。基于容器的方式,一旦单个租户的函数遭受攻击,造成容器逃逸,会影响服务器上所有租户的函数安全。所以,通常 Serverless 平台会采用安全容器的方式,引入轻量级虚拟化技术来保证隔离性,但这同时会引入额外的性能(启动)和资源开销等问题。因此,Serverless 平台需要兼顾极致性能和安全隔离。虽然业界涌现的各种 Serverless 系统在实现上可能有所不同,但
133、基本的概念、原理和关键技术是相通的,各个系统在实现时都需要应对以上所述的技术挑战。4.Serverless 简化了资源规划高阶服务 Serverless 会根据应用程序的需求自动启动、关闭以及扩展或缩减容量,无需管理任何具体的实例,即可在云上运行。比如数据库的 Serverless,手动管理数据库容量需要提前规划,也可能因为规划不准确或负载经常变化导致数据库资源的使用效率低下。借助数据库 Serverless,只需创建数据库节点,指定所需的数据库容量范围,然后数据库处于工作状态期间按照每秒使用的数据库容量进行付费。2.5.1 趋势与需求对于企业来说,数据处理系统云端部署、存算分离,逐渐替换传统
134、线下存算合一的集群部署方式,成为企业构建数据处理平台的首选方案。企业通过将服务托管上云,云厂商对数据处理平台做全面优化,带来更优的存、算体验,企业只需要关注自身业务的开发和维护工作。但原有的存算合一的数据处理系统,存在如下问题:计算资源利用率低:随着数据量的增长,集群整体扩容,计算需求没有明显增长,且算力的消耗具有潮汐性特征,导致计算资源利用率低,CPU 平均利用率低于 50%,方案整体成本高。数据拷贝成本高:数据全生命周期 Pipeline 计算,涉及多集群计算。在多计算集群之间数据关键特征五:存算分离2.5045云原生 2.0 架构白皮书共享难,数据拷贝代价大,多份数据存储成本高等问题。数
135、据在线事务处理需要扩展读能力也需要拷贝完整的数据,拷贝的时间开销和存储成本都很高。可靠性风险大:大规模的存算合一集群,运维和可靠性的风险增大。如:组件版本升级会迫使全量业务配合,业务之间资源抢占严重,运维可靠性风险增大。跨 AZ 部署难度大:为了系统的高可用,往往会需要将应用和数据都部署在多个 AZ 内,存算合一的数据处理系统,AZ 之间的数据一致性需要靠计算层来保证,特别是在线事务处理的数据库中,跨 AZ 的部署还需要考虑事务的可见性,在计算层实现复杂度很高,对性能影响较大。另外,当前政企客户数据治理也面临如下主要挑战:数据体量巨大:数据时代,各类数据增量巨大。如某医疗中心,存量 100PB
136、,增量 40T/天,100GB/全基因测序/人,一个国家级精准医疗量将超 EB 级别。数据实时要求高:IOT 时序数据测点数量庞大,上报频率高。如某钢铁集团,20000+传感器测点,平均 100ms1S 上报,趋势分析,异常实时监测。业务如何实现端边云联动,进行时序数据压缩、分析、预测。数据类型繁杂:多模态数据关联分析处理成为常态。如在公安侦查工作中,涉及数据种类多,位置、社会关系、网络行为,以及大量非结构化数据如语音通信,视频人脸,案件存档等。运用 AI 技术可以对非结构化数据挖掘,自动建立非结构化数据与结构化记录关联。数据需要融合计算:业务创新需要跨领域数据融合,如互联网客户精准画像,精准
137、营销,涉及位置/消费行为/社交关系/舆情等多数据关系碰撞,以及跨源跨域数据协同分析。数据跨 AZ 部署:业务数据安全要求高,对数据的分布往往要求多 AZ 的方式提高可靠性。如某医保局点,要求至少两 AZ 部署数据节点。2.5.2 关键特征与架构原则1.存算分离存算分离方案的实施,计算和存储资源的解耦,可以实现如下关键特征:解耦弹性扩展:存储和计算各自按需弹性扩展,通过容器化技术实现计算弹性伸缩,彻底释放算力的流动,实现了资源价值的最大化。Pipeline 计算数据免拷贝:一份数据多协议共享访问(S3/HDFS/Posix 协议),数据免拷贝,提高了计算分析效率,节省了数据保存成本。第二章|云原
138、生 2.0 的技术及架构特征046 只读副本免拷贝:存算分离让多个节点可以共享访问同一份数据,通过增加只读节点扩展读性能时,只需要新建一个只读计算节点,从写节点同步元数据后即可读取共享存储上的同一份数据,节省了数据存储成本,提升了扩展效率。可靠性增强:分布式数据存储提供各种类型数据持久化,归一化解决底层数据的可靠性问题,性能问题,数据容灾问题。从实践的角度,可以使租户在数据服务受益。跨 AZ 部署:存算分离使得跨 AZ 可以在分布式存储层完成,计算节点只需要读取存储层的数据,跨 AZ 一致性由存储保证,大大简化了跨 AZ 部署的数据一致性的实现。2.统一元数据管理通过统一数据湖内外的元数据管理
139、,形成企业级数据资产目录。支持数据湖内外的技术元数据、业务元数据、ML 数据特征等企业级元数据统一管理,提供全文搜索体验,让用户快速找到他想找的数据。提供自动数据推荐、数据关系挖掘、data profile、data feature 等能力,帮助业务人员快速数据探索和数据洞察。主要关键特性:数据关系图谱:自动解析发现元数据之间的深度关系,包括血缘、主外键、logical-physical、parent-child、数据标准、分级、分类、主题目录等,以知识图谱的形式呈现;智能数据搜索:支持自然语言全文搜索,相关度机器学习排序,基于用户特征的资产推荐等。2.6.1 趋势与需求在数据驱动决策中有效利
140、用海量复杂数据是一个新趋势。到 2023 年,增强分析市场预计将达到 184 亿美元。然而,大数据智能领域没有端到端系统,帮助增强人类智能,企业数据治理面临以下痛点:相对于动态的业务,当前的数据治理产品过于死板,包括创建数据湖开发时间过长,需要过多的领域专业人员来改进和维护;缺乏智能化的可视化工具来帮助用户在大数据系统中轻松探索、发现和分析;全有或全无的访问控制迫使企业在协作和保护敏感数据免遭滥用之间难以做出权衡;数据集、用户知识和模型之间没有联系,数据无法直接用于 BI 分析和科学计算,数据价值无法业务变现。关键特征六:数据治理自动化 2.6047云原生 2.0 架构白皮书2.6.2 关键特
141、征与架构原则在数据高效治理方面,通过对海量复杂数据驱动问题的有效分析,帮助用户专注于现实世界的问题,在正确的时间将正确的数据提供给正确的人做正确的决策。主要包含以下特征:1.一键式数据入湖,提升数据湖构建效率数据自动化一键集成入湖,用户只需要指定入湖的数据源和所属业务主题域,系统自动化创建入湖任务,底层资源根据入湖数据量自动扩缩容,智能完成入湖数据的安全等级、分级分类、隐私等级等数据标签的自动识别打标。关键特征包括:实时增量数据入湖,元数据自动发现:支持自动爬取存储中的表 schema 等技术元数据信息,并写入 Data Catalog 统一管理。迁移资源动态扩展:基于迁移任务数据量大小、fl
142、avor,动态计算并推荐迁移资源配置。智能入湖管理:入湖过程中,自动进行隐私数据自动识别、动静态数据脱敏、数据质量六要素处理、数据关系图谱构建。2.可视化“No Code”的 Auto ETL 技术,提升数据准备效率为数据科学家、业务分析师提供 no code 的数据准备能力,在 AI 治理引擎帮助下,交互式、迭代式的做数据准备,不需要 SQL 开发技能,就可以做数据清洗、数据自动 ETL、数据关系挖掘、数据特征分析、数据准备 pipeline 任务。基于 AI 增强数据管理技术的数据预览、数据剖析、schema mapping、算子推荐等能力实现数据准备引导式交互界面。关键特性包括:自动数据
143、质量评估:基于 AI 智能增强数据管理技术,自动统计数据相似度,并给出数据重复度等数据质量评估结果。数据丰富:基于湖内外标准数据集,通过关系挖掘实现对数据内容的丰富以及数据schema的补充。AutoETL:提供托拉拽可视化交互界面,基于 AI 技术自动生成表关系、转换算子推荐,数据准备 pipeline 自动生成。图 2-15 智能数据治理流程(-UserMultiple source 数据集导入新数据集Data profiling annotation processing validation准备高质量的数据数据打标、安全、分享添加知识以供分析数据建模转换(Auto ETL)schema
144、 mapping将数据转换为以业务为中心的模型DaaS(Auto multi-pass SQLs)按需提供ML、BI分析的数据数据发现、探索、见解基于搜索的数据驱动的决策一键入湖数据准备数据目录/数据发现数据洞察第二章|云原生 2.0 的技术及架构特征0482.7.1 趋势与需求1.“信息共享、业务协同”已成为企业新老应用共存场景下的基本需求。随着云原生技术的普及,使用云原生技术或框架开发新应用成为了主流,但企业不可能完全抛弃“老”应用。政府、企业、园区等业务新老应用系统越来越多,底层基础平台能力逐渐丰富,各应用系统与基础平台之间的协同、互联互通,以及应用系统之间的互联互通高效协作尤为重要,但
145、是也面临着严峻的挑战:各平台系统独立建设,缺少统一的服务开放标准规划,平台之间无联动;新老应用间、应用与基础平台之间点对点集成,形成日益复杂的网状交错结构,应用与基础平台高耦合;随着应用系统的不断建设,应用集成越来越多,集成的复杂度将不断增加,后续维护难、扩展难等不可预知问题将逐渐凸显出来;当应用、平台分布式部署在不同的网络环境时,如跨云、跨隔离网络、跨企业、跨局点等情况下,传统的 ESB 缺乏多节点组网方案。可见,企业新老应用共存时,信息获取、互联互通成本高,业务很难协同,“信息共享、业务协同”已成为基本需求。2.传统集成模式应用新老应用对接面临的挑战 旧应用有很多私有协议,基于 Restf
146、ul 协议的新应用无法与之对接。很多旧应用已无法提供对接所需接口,就应用的改造性价比低。2.7.2 关键特征与架构原则应用融合集成:一站式的应用/数据/API/设备集成等能力,将API、数据、设备、消息灵活互转,高效完成应用间集成;此外,融合集成作为iPaaS领域技术,还包含元数据、低代码、事件驱动架构、多云管理、应用聚合、函数编排等技术。应用融合集成平台在新老应用共存场景下的主要表现:关键特征七:基于软总线的异构集成2.7049云原生 2.0 架构白皮书 新老应用均无需修改,非侵入式对接,大大减小云原生应用落地复杂度。多种集成方式配合使用,集成功能强大且灵活。通过协议转换联接新老业务,支持各
147、种协议适配插件。通过访问数据库或 Function 的方式生成标准云原生接口。满足新业务跟随新技术长期演进需求。解决了遗留数据、应用资产的利用问题。解决新系统短时间内难以替换老系统的现实。新老应用共存场景下,企业对应用融合集成的 API 集成、数据集成、消息集成、设备集成等技术也有不同的诉求。1.应用间 API 跨云集成集团与各地区子公司的 IT 系统集成,直接访问对方各类数据库方式过于复杂,且容易发生信息泄露风险,如果以 API 方式互相开放访问,同时加强 API 调用安全防护,就能实现跨网络跨地域协同办公。1)API 跨网、分布式集成 简单易用:只需简单配置 API 信息,即可完成 API
148、 注册与开放 跨网发布 API:支持 API 由内网到公网,云端到内网发布 大规模高性能:分布式部署,分区域运行,可自动扩展,低延时2)快速开放 DB 成 API 接口 API 接口:能快速开放 DB 为 Restful 接口 数据编排:支持 API 数据编排3)API 的安全与流控 流量控制:对 API 可设制调用量控制 安全可靠:提供 Appkey 认证、支持 SSL/TSL 加密,黑白名单设置2.异构数据间跨网集成同步很多企业部门间的数据源不一样,难以形成部门间有效的信息传输。应用集成平台需要提供多种数据源之间转换的方式,支持 MySQL、Kafka、API 等主流格式之间的转换。第二章
149、|云原生 2.0 的技术及架构特征050 支 持 多 种 异 构 数 据 源 间 同 步,如 API、ActiveMQ、ArtemisMQ、DB2、DIS、DWS、HL7、HANA、HIVE、IBM MQ、Kafka、MySQL、TaurusDB、MongoDB、MRS Hive、MRS HDFS、MRS HBase、OBS、Oracle、PostgreSQL、Redis、RabbitMQ、SAP、SNMP、SQL Server、WebSocket 等。支持复杂多样网络环境支持跨网络、跨云、跨数据中心、跨机房等网络环境数据同步。灵活调度按数据量(增量、全量)、时间(定时、实时)等任务触发规则来
150、调度任务。数据安全防护机制提供数据安全(敏感数据加密)、系统安全、网络安全(防火墙防入侵)、业务安全(租户隔离)等多层安全防护机制。3.分布式消息集成企业与合作伙伴使用的消息系统不一样,消息系统对接成本较高,而且难以保证对接之后消息传输的可靠性和安全性。支持公有云、集团、子公司自由组网,应用就近接入,消息本地发布本地消费,消费端决定路由策略。图 2-16 应用与数据集成平台大数据APISNMPRestful关系型数据库文件商业/专有协议HL7消息IBM MQJDBCMessageFileHTTPRFCStreamJDBCStreamMessageFileHTTPRFC大数据API关系型数据库文
151、件OBSHL7消息IBM MQ私有云公有云混合云私有云公有云混合云OBSSNMPRestful商业/专有协议应用与数据集成平台051云原生 2.0 架构白皮书1)需要支持分布式消息部署 主备模式多节点集群模式 跨数据中心的多集群模式 跨数据中心的消息平台通过统一路由连接2)消息统一路由,可实现应用就近接入 统一的服务发现与负载均衡模块,实现应用就近接入消息平台 自动发现消费端位置,统一路由模块处理,路由到消费端本地消费3)支持混合云各种应用场景 消息 Proxy 代理消息到消息平台 Proxy 负责认证、加密等安全措施 集团分子公司间全国 全球跨网集成 B2B 跨网间消息集成 公有云、私有云间
152、跨云消息集成4.设备数据快速集成工业场景中,设备的信息和生产过程中的参数比较分散。生产线出现故障时,如果靠人工采集每一台设备的信息与参数,定位问题的过程缓慢。应用集成平台需要能够连接设备和 IT 系统、大数据平台,将设备的运行状态等信息上传到 IT 系统或大数据平台中,实现所有设备的信息可视化,一旦生产线出现故障,企业能够快速定位问题。需要实现标准的 MQTT 协议:使用开源的标准 MQTT 设备端 SDK,轻松接入云端。设备多协议接入connector:持标准MQTT、MQTT Client SDK、设备集成Agent、软/硬网关、HTTP 各种协议与方式实现设备数据接入云端。水平拓展:支持
153、海量设备低延时接入,支持百万设备长连接。安全可靠:保障设备安全与唯一性,提供 TLS 标准的数据传输通道保障消息传输通道的安全。第二章|云原生 2.0 的技术及架构特征0522.8.1 趋势与需求1.云原生应用研发趋向一体化模式云原生时代的应用研发趋向于从需求、计划到上线、运维直至用户反馈的全过程均在云上完成的应用研发一体化的新模式,业界也称之为 DevOps。但一体化模式并非唯一选择,企业仍然可以采取传统研发模式来开发云原生应用,这样就无法发挥或无法全面发挥云原生技术的优势,应用研发效能只能处于较低水平。同时,要将一体化模式落到实处,提升应用研发效能,需要企业聚焦云原生应用研发转型的目标和价
154、值,以能力屋及实施框架为指引,涵盖人和组织、工程方法、最佳实践、工具平台、生态各方面,制定计划并推动落实。关键是要正识正视,云原生应用研发实质上是研发模式甚至业务模式的变革转型,需要通过有效的变革管理来保障转型成功。2.从敏捷到 DevOps,是一体化趋势的延续应用研发一体化模式并非从天而降,实则是从 20 世纪 90 年代起研发模式演变的趋势延续。2001 年,敏捷运动兴起,强调打破业务、开发与测试之间的壁垒。2009 年,DevOps 运动兴起,致力于促进软件开发、运维和质量保障部门之间的沟通、协作与整合。2012 年,Gartner 提出DevSecOps 概念,主张将安全性嵌入 Dev
155、Ops 链条每个环节,追求在开发过程早期而不是产品发布后识别安全问题,目标是让每个人对信息安全负责。敏捷、DevOps 以及 DevSecOps,它们是一种延续,所代表的是打通管理与协同、设计与开发、CI/CD、应用管理、运维、安全可信等各个环节的一体化趋势。关键特征八:可信、平民化DevOps2.82.8.2 关键特征与架构原则1.DevSecOps伴随着 DevOps 在公司内的快速发展,研发安全保障的思维和技术也需要不断演化发展,其中一个重要的思想就是 DevSecOps,它完全遵循 DevOps 的思想,将安全无缝集成到其中,使之升级成为 DevSecOps,相较于 DevOps,De
156、vSecOps 需要在以下原则加强:053云原生 2.0 架构白皮书1)安全左移(Shift Security Left)持续的发布不停地进行,靠以往把所有的检查在发布之前进行根本跟不上这个速度。所以需要更多的关注研发流程的“左”边,在更早的环节中(设计、编码、自动测试)也要进行安全介入和管控。但安全工作必须从工程师的角度出发,制定更加轻量级可迭代的措施,并以有效、可重复和易于使用的方式实现自动化。这个想法虽好,但并不是那么容易落地,主要的原因是安全人员数量并不足够,所以需要让开发和运维人员承担更多的安全责任,这里需要安全人员对他们进行更多的安全培训(意识和能力),还有就是提供有效的工具来帮助
157、构建更安全的系统。2)默认安全(Secure by Default)拿编码环节来说,持续的快速构建也意味着需要快速的产生代码,而如何快速的产生安全的代码变的越发重要。在开发人员能力短期无法质变(或不停的有人力交接或新人加入等)时,通过提供默认安全的开发框架或者默认安全的组件可能很好的防止犯低级错误,默认安全的原则并不仅仅限于代码,Web 接入层上默认覆盖的 WAF、默认安全配置的云/容器/数据库/缓存等基础系统和服务、统一的登录鉴权认证服务、KMS(密钥管理系统)、保护关键数据的票据系统、零信任(Zero Trust)架构等等,都是默认安全的很好实践。这也要求安全团队要参与到整个系统架构、基础
158、设施等的建设中。反过来也会要求更多的组织架构保障以及安全与研发团队之间的沟通协作能力。3)运行时安全(Runtime Security)在越来越快的发布之下,倒逼着安全的考量除了上述提到的左移和默认安全以外,更加需要特别关注和加强上线后运行时的异常监控和攻击阻断能力提升。需要有更加及时快速自动化的风险监控、发现、阻断、恢复等的手段和机制。类似于致力于提升系统整体可用性的各种Monkey(混沌工程),安全机制也需要有类似的机制和能力,重点在识别内外部的安全风险上。再比如与应用运行时环境嵌入更紧密的运行时应用自我保护(RASP,Runtime Application Self-Protection
159、)技术,以前如果还犹犹豫豫,那以后可能会更多纳入大家的视野中。虽然也有一些问题如部署比较麻烦、兼容性问题、性能问题等,但是借助于云、容器等成熟的大规模基础设施和技术之上通过优化完全有可能提供更优雅更易于接受和使用的方案,能够带来更快更精准更细致入微的安全检查及防护能力。此外,对于很多安全风险来说,情报来源管理和自动化分级分析是第一步,然后如何更快的检测?又如何快速地对问题进行响应,特别是为了提升安全响应效能,不能仅仅从单点来考虑,要从全网及整个系统架构层面来考虑,将分散的检测和响应机制整合起来,这也导致了 Gartner 在 2015 年提出了安全编排自动化和响应(SOAR,SecurityO
160、rchestration,Automation and Response)的概念,更好的完成运行时的风险响应问题。第二章|云原生 2.0 的技术及架构特征0544)安全服务自动化/自助化(Security as Code/Pipeline)在 DevSecOps 中,安全并不是特殊或者拥有某种高权限的存在,跟其他所有研发环节和工具一样,不能因为安全而中断 DevOps 的流程。如果你的安全服务没有实现自动化,那么就无法称之为 DevSecOps。整个研发流程都在围绕流水线运转,你不可能突然在其中把开发人员支走,很莫名其妙并且无法被接受。应该向他们提供可使用且易于理解的安全工具,让这些工具自己进
161、行配置和运行,保证这些工具能以合适的方式融入到流水线中,融入到各个流程中,成为DevSecOps 工具链中的一环,使用角度跟其他工具没有大的区别。总而言之,需确保安全测试和检查服务能够自动化和自助化并且提供快速且清晰的反馈。业界有一些研究和尝试比如漏洞代码自动修复(MIT的CodePhage,GitHub发布的针对开源漏洞组件自动修复的Dependabot)等技术,虽然目前看有些成熟度可能还不高,这些方向虽然困难但绝对是正确的,是一种贯彻 DevSecOps思想的尝试。但是这里也要小心陷入另一个误区,需要清晰的认识到,安全领域是没有“银弹”的。如同所有风险类管控一样,信息安全的管控本身一定是层
162、层防御的机制,对于很多营销目的的所谓新技术一定要全面了解多方对比才能做出判断,不太可能指望搞一个方案就一劳永逸的解决所有安全问题,就要达到 100%安全,这是不切实际的空想!就如同软件研发领域“没有银弹”,系统可用性没有 100%(一般我们说要做到 4 个或 5 个 9),安全也没有 100%。5)利用基础设施即代码(IaC)基础设施即代码(Infrastructure as Code)思想和工具是以前成功构建实施 DevOps 的关键,安全管控也要积极的利用这些能力。利用他们确保大规模场景下配置、环境和系统行为等的一致性,通过版本控制、代码审计、重构、动静态分析、自动测试等手段持续交付流水线
163、来验证和部署 IaC 设施,确保标准化、可审核并且使之更安全,减少攻击者发现和利用运维漏洞的机会。各种安全系统和安全机制也积极使用这些设施,另外在出现安全漏洞或应急事件时,直接使用 IaC的一些机制快速安全可靠的修复漏洞或部署缓解措施。另一方面,也特别要保护这些基础设施,保护持续集成和持续交付管道等研发流程中的关键系统,真的无法想象流水线系统被恶意控制之后会导致什么。所有的操作集中起来对于安全保护的要求会更高。2.BizOpsDevOps 从 IT 团队的角度补齐了能力,实现了 IT 团队内部从开发测试到运维的流程、组织、文化重构,通过实现 IT 从“稳态”到“敏态”的转型和“双态 IT”支持
164、,很大程度上能改善 IT应对市场及业务变化的能力;但是从整体上看,在数字化时代下,企业的商业价值需要更多由业务数据来驱动,业务和 IT 需要以商业价值的交付为目标,前端的业务决策、业务调整和执行,需要和 IT 实现以及 IT 运营数据形成更紧密的闭环。从 DevOps 向业务端进行扩展,实现业务、IT055云原生 2.0 架构白皮书开发运营的整合重构,就有了 BizDevOps 的概念。BizDevOps 需要实现业务和 IT 之间的连接,其中重要的一点就是通过低代码(Low-Code)或是无代码(No-Code)开发平台,为业务人员、开发人员提供统一的交互基础。核心 IT 团队更关注于提供自
165、动化工具及平台,以及支撑业务功能实现的服务化功能和组件,业务分析师/开发人员可通过自动化平台工具以及服务组合,从业务需求出发对 IT 实现进行定义。当技术被隐藏起来时,它就易于为更广泛的公众所使用,被称为平民化。低代码开发的核心能力包含以下几个方面:全栈可视化编程:可视化包含两层含义,一个是编辑时支持的点选、拖拽和配置操作,另一个是编辑完成后所及即所得(WYSIWYG)的预览效果。传统代码IDE也支持部分可视化能力(如早年 Visual Studio 的 MFC/WPF),但低代码更强调的是全栈、端到端的可视化编程,覆盖一个完整应用开发所涉及的各个技术层面(界面/数据/逻辑)。全生命周期管理:
166、作为一站式的应用开发平台,低代码支持应用的完整生命周期管理,即从设计阶段开始(有些平台还支持更前置的项目与需求管理),历经开发、构建、测试和部署,一直到上线后的各种运维(e.g.监控报警、应用上下线)和运营(e.g.数据报表、用户反馈)。低代码扩展能力:使用低代码开发时,大部分情况下仍离不开代码,因此平台必须能支持在必要时通过少量的代码对应用各层次进行灵活扩展,比如添加自定义组件、修改主题CSS样式、定制逻辑流动作等。一些可能的需求场景包括:UI 样式定制、遗留代码复用、专用的加密算法、非标系统集成。2.9.1 趋势与需求云的强大算力和海量存储使深度学习的普及成为可能。随着 AI 应用越来越广
167、泛,诸如BERT、GPT-x 等预训练模型的持续突破,AI 对算力和数据的需求越来越强烈。云提供了最佳算力和数据存储载体,也为 AI 模型的全生命周期治理以及端边云 AI 协同提供了统一控制点,可以大大促进全行业 AI 普惠。但是 AI 在行业的真正落地,面临各种挑战。众所周知,一个 AI 产品的开发&交付运维过程,是一个复杂系列的工程,所需要的人员及技能范围较广,在实际的机器学习系统中,只有一小部分是由机器学习代码组成的,所需的相关元素既庞大又复杂。系统的其余部分包括配置、自动化、数据收集、数据验证、测试和调试、资源管理、模型分析、过程和元数据关键特征九:多模态可迭代行业AI2.9第二章|云
168、原生 2.0 的技术及架构特征056图 2-17 As AI Matures,Inference will Dominate管理、服务基础架构和监控。而且 AI 一旦进入核心系统,发现了更深层次的问题,行业建模和求解成本非常高:行业专家与AI专家合作:如何让双方能够相互听得懂,围绕一个共同的目标相互促进是个难点;行业知识与 AI 模型结合:不同行业都有自己数十年甚至上百年的专业积累,形成了大量成熟的基于物理、化学、生物信息等知识表达的机理模型,这些模型能否提升数据驱动 AI 模型的求解效率与精度,及如何有效结合;行业数据与实验模型结合:如何让模型随着客户真实数据不断适应变换,不断自我迭代算法喻
169、模型是一个难题;行业应用与 AI 系统结合:行业自身多年积累的应用系统、控制系统和 AI 系统。如何让这些行业应用平滑有序地升级为智慧系统。这些 AI 软实力的背后,根本问题是知识表达(建模成本)和知识求解(求解成本):行业知识如何与 AI 结合?解决这个机理性问题后,专家配合及系统配合的问题就将随之清晰。AI 应用与传统软件不同,有分析机构统一发现,传统软件的毛利率比 AI 应用的毛利率高,原因还是开发成本和迭代成本高导致。另外传统软件的服务基本上一次性就可以完成,而 AI 应用软件则需要长期训练迭代,专人运维。并且可复制性上面,传统软件的可复制性更高(场景确定性高),而 AI 应用的可复制
170、性低(往往随着环境变化,导致可用性低)。这些 AI 软实力的背后,根本问题是落地管理(迭代成本):行业数据如何与 AI 迭代?解决这个工程化问题后,实验与真实系统配合的问题才将随之解决。下面的这个概念图显示了建模与推理花费的百分比。可以看到今天受到关注的一些应用程序随着推理变得越来越主流。AutosHealthcareFinancial ServicesRetailMediaGovemment/DefenseCyber SecurityEducationModelingInference2030202520200%of Spending100Level 3 autonomous driving
171、,trafficoptimization,AR/VR,power grid,new paymentsystems,on-shore manufacturing,machineintelligent robots,content production,inrelligent call centers.Smart phone,Alexa,facial recognition,NLP,low level autonomous drixing(e.g.lane warnings),Brave Browser(BAT),DeFi/Blockchain,GamungFraud detection,adte
172、ch,pricing,weather,categorization,recommendation engines,supply chains,drug provenance.057云原生 2.0 架构白皮书对于企业使用AI而言,更关心的往往是AI应用(Inference)价值。当前,如防诈骗、广告技术、预测天气、预判价格、推荐引擎等方面,建模成本占比小于推理,但是上面的概念图显示了随着时间推移,训练和推理的花费百分比会到一个过程趋于平衡,并且随着使用越多价值越大。该图还显示了,随着推理成为主流,当前受到关注的一些应用会逐步走向成熟。随着业界在算法/工程能力方向上面的持续创新,如 Built-i
173、n 大模型/MLOps 能力加持外,用户在 Modeling 生产 AI模型的单位消耗和时间会逐步减低下来。在 2017 年训练图像识别需要花费 2000 美金,到 2020年训练一个图像识别模型仅仅需要 7.43 美金。2.9.2 关键特征与架构原则在各大平台预测中到2025年,97%的大企业将采用AI,其中企业对AI的采用率 86%(Source:Huawei GIV)。在云原生 2.0 时代,已逐步出现如下特征:1.超大规模分布式算力提升建模效率(Modeling)对于Modeling而言,最核心的即模型的训练过程。模型训练通常需要大规模高质量训练数据,并基于 AI 模型的特性表达不同行
174、业中复杂而庞大的业务体系。这涉及到如何利用行业知识刻画行业特点。一方面,行业知识可以指导行业数据的获取、标注等工作,帮助识别无效数据、补全缺失数据,解决不同场景下数据收集难、数据误差大等问题,帮助构建符合行业特性的高质量数据;另一方面,行业知识可以帮助更高效地完成模型选择、模型参数化等工作。随着业界越来越多的 AI 落地,触发对 Built-in 的 Models 模型越来越强烈,则对于 Training的过程越来越细分出来。从原来的一个团队从算法开发+场景化开发,逐步走向了两类人员,一类人群专门从事算法开发,另外一类人群负责做场景化迭代。如下图,触生了一部分有能力的算资源消耗ALL-One-
175、teamOne-teamOther-teamFuturePast500500045550AlgorithmsAlgorithmsDev WorkflowDev WorkflowDev Workflow.WorkflowUse WorkflowUse WorkflowUse Workflow.图 2-18 AI 团队合作模式的转变第二章|云原生 2.0 的技术及架构特征058法团队,会专门负责生产 Built-in Models。而客户&ISV 则通过 Built-in Models 进行围绕场景的Workflow 开发,解决场景化方案。面向未来对于 Built-in Models,则需要大量的
176、算力,而单纯的几台机器算力已然无法满足其需求,超大规模分布式成了业界必然趋势。故在这个业界趋势下,对于第一阶段的训练而言,Centralization 成为趋势,去构建更大体量的算力。2.利用行业知识提升 AI 模型求解效率与精度(Solving)求解是确定模型参数值的过程,求解的效率限制了模型迭代的速度,求解的精度决定了模型在业务中的可靠性。为了提升 AI 模型的求解效率,通常会一次性喂给模型更多的数据,辅以先进的硬件计算资源,以加快模型求解速度。除此之外,科研人员也在不断更新求解算法,进一步提升模型的求解精度。然而,由于诸多行业业务的复杂性,单纯基于大数据的方式求解模型,往往难以得到令人满
177、意的结果。以石油勘探为例,勘探数据具有海量、多维、多尺度、多属性等复杂特点,需要基于大量的背景知识对数据进行分析推理,进而做出预测。基于过往的实践经验,由于缺乏相关的领域知识,单纯地基于大数据训练 AI 算法,AI 算法难以从海量数据中学习油气层的固定模式,往往精度较低,难以满足业务需求。利用行业知识帮助AI模型高效求解,可以弥补数据偏差造成的影响,帮助AI模型寻求更优解,同时知识中所包含的约束、规则等信息能够调整模型求解策略,得到更符合行业场景的 AI 解决方案,将成为 AI 模型求解的趋势之一。3.MLOps 提升迭代效率(Iteration)MLOps(Machine Learning
178、Operation)是“机器学习”(Machine Learning)和“DevOps”(Development and Operations)的组合实践。随着机器学习的发展,人们对它的期待不仅仅是学术研究方面的领先突破,更希望这些技术能够系统化地落地到各个场景中。但技术的真实落地和学术研究还是有比较大的差别的。在学术研究中,一个 AI 算法的开发是面向固定的数据集(公共数据集或者某个特定场景固定数据集),基于这单个数据集上,不断做算法的迭代与优化,面向场景的 AI 系统化开发的过程中,除了模型的开发,还有整套系统的开发与运维,于是软件系统开发中成功经验“DevOps”被自然地引入进来。但是,
179、在人工智能时代,传统的 DevOps 已经不能完全覆盖一个人工智能系统开发的全流程了。基于 Machine Learning 的 MLOps 就被提出来。059云原生 2.0 架构白皮书图 2-19 MLOps如上图,机器学习开发流程主要可以定义为四个步骤:项目设计、数据工程、模型构建、部署落地。AI 开发并不是一个单向的流水线作业,在开发的过程中,会根据数据和模型结果进行多轮的实验迭代(如上图箭头指向)。算法工程师会根据数据特征以及数据的标签做多样化的数据处理以及多种模型优化,以获得在已有的数据集上更好的模型效果。传统的 AI 应用交付会直接在实验迭代结束后以输出的模型为终点。当应用上线后,
180、随着时间的推移,会出现模型漂移的问题。新的数据和新的特征在已有的模型上表现会越来越差。在MLOps中,实验迭代的产物将会是一条固化下来的流水线,这条流水线将会包含数据工程,模型算法,训练配置等。用户将会使用这条流水线在持续产生的数据中持续迭代训练,确保这条流水线生产出来的模型的 AI 应用始终维持在一个较好的状态。以一系列工程化的思想和实践,帮助 AI 算法模型完善其在工程化及效能方面的短板。MLOps 是机器学习项目从实验室走出来,走向规模化应用的有效途径。通过持续训练、持续集成、持续部署、持续监控等多个自动化循环流程,大大减少迭代需要的开发周期,持续提高模型应用交付质量,降低对专业算法人员
181、依赖,整体提高研发效能,推动挖掘更多元化的业务价值。4.生态社区(Marketplace)有了一个好用的 AI 平台,意味着有了趁手的生产工具,但如果要达到更高的生产力,没有知识和经验是不行的,AI 的开发和落地也是如此。AI 是一种通用的目的性技术,AI 的落地是一个系统级的工程,涉及到的知识和经验体系具有很强的行业和技术纵深,开发者很难面面俱到。如何项目设计数据工程模型构建部署落地需求收集场景设计明确问题边界定义数据收集数据数据标注数据可用性检查数据工程算法开发模型训练模型评估迭代优化应用集成应用部署模型监控系统运维DESIGNML DEVOPS第二章|云原生 2.0 的技术及架构特征06
182、0将 AI 相关的知识和经验汇聚并沉淀,并为不同背景的开发者提供其所需的 AI 能力,成为了 AI 产业化落地、赋能千行百业征途中必须要解决的问题。而这个问题的一种解决思路,就是构建 AI 生态社区。生态社区并不是一个新鲜词,这里所指的 AI 生态社区有什么特别之处呢?这和生态社区的核心,也就是“AI 知识和经验的载体”密切相关。根据前文所述,我们知道 AI 开发和落地过程中,需要经过多次实验、反复迭代。在端到端的过程中,优质的成果物可作为 AI 知识和经验的载体,用来做后续的二次开发或同类场景复用,具备分享和交易价值。我们可为这些优质的成果物引入“AI资产”的概念。围绕 AI 开发和落地端到
183、端流程中使用的 AI 生产要素,可梳理如下典型的 AI 资产:AI镜像:用于AI训练、推理的镜像环境,其中包括了操作系统,GPU/NPU驱动,Python软件,基础 AI Frameworks 及高级的 Frameworks,一般都是以镜像包的方式去呈现;DataSets 数据集:用于 AI 开发与训练的样例数据集,如 Imagenet、coco 等;Packages 领域组件:开源算法库,如 pyod/egads/OctoML/shap/pysyft/interpret/OpenVINO;Algorithms 领域算法:参考算法代码,如回归、分类、评估、安全等;Pre-trained Mod
184、els 预训练模型:预训练算法模型,如 Backbone 大模型等;Models:模型应用包,可在云侧、边缘等环节部署运行进行推理预测;Experiment Pipeline:开发过程的工作流,面向训练迭代过程,例如智能标注也是一种workflow;Solution Pipeline:模型组合的封装工作流,面向应用过程;Project workspaces:项目工作空间,基于项目的端到端配置及工程等;EndPoints:API 服务;Tools:如第三方标注工具、模型评估工具等。AI 资产具有丰富的种类形态、多样的使用方式,并且在数量上随着开发者的共建共享会持续增长。为了让 AI 开发者能够更
185、加高效的开发、使用和管理 AI 资产,也让 AI 平台能够聚焦在通用能力建设并灵活迭代升级,可以将 AI 资产和 AI 工具平台解耦。开发者可使用工具平台生产出 AI资产,发布到生态社区进行分享或交易;也可以从生态社区中获得 AI 资产,快速的加载到工具平台上使用,类似于微软的 Office 工具软件以及模板资源。场景示例:某工业质检类业务场景下,数据科学家们收集原始数据,并运用 AI 平台进行数据处理和标注,获得可供训练使用的数据集 Dataset,再基于 AI 平台反复开发调测,获得相应的训061云原生 2.0 架构白皮书练算法 Algorithm,然后基于相应的自定义 AI 框架 Fra
186、meworks 进行训练,训练结束后得到模型Models,再通过 AI 平台将模型部署起来,以 API 服务形式提供给业务做集成。这个过程可通过工作流 workflow 固化下来,方便后续迭代。从这个端到端环节中,我们可以看出来有哪些 AI 资产:Datasets,Algorithms,Frameworks,Models,workflows。这些 AI 资产都是 Data Scientist 的知识产物,都具有分享和交易价值。2.10.1 趋势与需求云安全是什么?在最早期阶段,云的安全包含了基于虚拟化技术的网络安全(Virtualization-based Network Security),
187、基 于 资 源 池 化 的 网 络 安 全(Resource-pool-based Network Security),基于云的网络安全(Cloud-based Network Security)。传统安全厂商,为了适应云化潮流,也纷纷提出以安全硬件、软件形式而非服务形式提供 Offering,进一步衍生出来大量安全资源池的概念。在公有云的初期,由于公有云服务提供商提供的安全能力较少,用户仍然部署了不少非云服务商提供的安全产品,我们姑且称为用户部署的安全产品(Customer-deployed Security Product)。造成这一局面的原因可能是用户依然有大量专业安全产品的生命周期没有
188、终止,或者已经购买的产品产生了较强的依赖,或者经过评估云服务商安全产品后发觉无法达到专业安全厂商同等产品的水平。当前各个公有云服务提供商除了提供数量不少的云安全服务如保护工作服务的安全产品(CWPP,Cloud Workload Protection Platform),监控云安全态势的安全产品(CSPM,Cloud Security Posture Management),云 原 生 应 用 保 护(Cloud Native Application Protect Platform)等技术。上述这些阶段,这些阶段并不是替代关系,而是仍然并存。随着公有云厂商对云的理解逐步深入,对云安全的思考也
189、从狭义的安全概念引申到如何在云上帮助客户构建全方案的安全体系这个理论了,这些理念和技术可以解决传统安全过去很难、甚至是无法解决的安全风险,比如大型企业部署应用时如何进行安全架构设计、如何管理复杂组织和系统的权限和账号;如何进行现代化的安全运营以应对安全攻击、入侵风险等,这些都是云原生 2.0 展现给客户的。关键特征十:全方位立体化安全 2.10第二章|云原生 2.0 的技术及架构特征0622.10.2 关键特征与架构原则1.统一权限管理 随着安全合规的要求越来越严格,在访问控制方面需要严格遵守最小授权原则,这就要求云平台提供精细化的权限控制手段,企业利用这些细粒度授权方法可以精确设置访问控制的
190、 5 个要素:Who、What、How、Where、When。Who 表示谁可以访问云资源,What 表示可以访问哪些云资源,How 表示有权执行该资源的哪些操作,Where 表示允许用户从哪里访问,When 则表示允许访问的时间段。细粒度授权体现在以下几个方面:细粒度资源:授权时可以指定特定的资源组甚至单个资源,而不是把租户内所有的资源都授权出去,这个可以通过企业项目、标签等方式来限定授权的资源范围。如果需要授权特定资源,可以先把这些资源归集到一个企业项目或者打上一个标签,然后按照企业项目或标签来设置权限。细粒度操作:将云资源的读、写、列表等操作进一步细化,对其细化操作进行鉴权,并将这些细化
191、操作变成可供用户配置的权限操作。以云主机为例,将其读操作细化为读取规格、读取标签、读取服务器详情、读取挂载的磁盘、读取网卡等细粒度操作,这些细粒度操作在用户配置权限的时候是可以自由选择的,这样就可以将权限控制到用户所需的最小操作集合。ABAC(Attribute-Based Access Control):即基于属性的访问控制,相比 RBAC(Role-Based Access Control)更加灵活,可以在权限设置的时候附加各种基于属性的条件,在权限判定的时候检查当前的访问请求是否满足这些属性所对应的条件,满足条件时才允许访问。属性通常包含三类:一是访问主体的属性,比如用户姓名、创建时间、
192、是否启用 MFA 等;二是环境的属性,比如访问的IP地址、访问时间、访问的设备等;三是资源的属性,比如资源的标签、创建日期、资源名称等。通过 ABAC 可以更细粒度地设置访问控制的权限,例如运维人员只有启用了 MFA 认证后并且只能在晚上 12 点后、凌晨 4 点之前对云资源进行关机和重启操作。2.统一安全凭证管理账号密码、数据密钥、应用 AK/SK 凭证是业务安全最基本的要素,这些凭证的安全生成和保管对于任何企业都是非常重要的。但是我们不能忽视的问题是,凭证管理有如下风险:弱密码、特征密码 密码、密钥因为规范性的要求,设置很长,系统管理员记不住而明文存储在业务系统中 应用凭证通过编码的方式记
193、录在软件中 使用缺省口令或伪随机数生成密码、凭证,且长时间不更换 企业有大量的人机、机机账号,海量凭证管理困难063云原生 2.0 架构白皮书对于上云业务系统,可以充分利用云原生的技术来管理凭证,做到人机、机机账号凭证的有效管理,在安全和效率之间得到充分协同。使用密钥管理服务 KMS 来管理密钥,KMS 服务是云原生的密钥管理系统,其原理是对用户密钥进行托管,将用户的密钥存储在专业的加密机(HSM)中,只有正式的用户登录后才能通过KMS访问加密机来获取相关密钥。彻底解决密钥明文存储、硬编码在代码中等问题。同时,云原生的密钥管理服务天然与云数据类服务(如对象存储、块存储、数据库服务等)进行了对接
194、,用户在安全使用密钥时,还减免了和对应数据服务对接的开发工作量。使用证书管理服务来管理各类证书,通过云上的证书管理服务,将证书的申请、发放、配置、替换的生命周期流程管理起来,确保证书申请过程中不会泄露系统信息,证书下载过程不泄露证书公私钥。密钥、密码等凭据的轮转,对于业务系统中的密钥和凭据,需要定期进行更换以避免管理漏洞带来的数据丢失,云上凭证管理支持密钥的定期轮询和自动替换,替换后自动更新到上下游业务系统中。在业务效率不下降的情况下,最大化保证安全。随着云技术的发展,API、SDK 的广泛引用,凭证的安全管理显得越发重要,使用云原生的服务是被广泛认知的有效、安全、必要的方式。同时,类比传统
195、IDC 环境下动辄数十万甚至数百万一套的加密机、CA签发系统,云原生技术也极大的降低了相关服务的开通复杂度和使用成本,为租户安全管理密钥、密码、凭证提供的有利条件。3.安全可信多方计算在政策驱动和市场需求同时作用下,隐私计算技术、产业、应用迅速发展,成为保护数据拥有者的权益安全及个人隐私的前提下,实现数据的流通及数据价值深度挖掘的重要方法。一方面,多方数据融合需求强烈。然而受制于数据的分散性、高复制成本以及价值聚合性,数据仍呈高度分散状态;另一方面,隐私保护需求强烈。然而“野蛮掘金”诱惑下的数据盗用,滥用频发。同时法律监管日趋严格,公众个人信息保护意断提升。基于以上因素,以安全多方计算、联邦计
196、算为核心技术的隐私计算增强了数据流通过程中对用户隐私、商业秘密的保护,为数据的融合应用和价值释放提供了新思路。4.面向大企业客户的“单企业多租安全治理”对于规模较小的企业云客户,往往一个企业客户对应一个云服务租户账号,但对于大型的企业云客户而言,因其业务单元众多,组织层次架构复杂,为了实现企业内各业务单元的安全和故障隔离,往往选择将该企业不同业务单元的应用系统分别部署在不同的云服务租户账号中。从企第二章|云原生 2.0 的技术及架构特征064业安全治理管控的角度,云服务租户账号承担了如下 3 个关键作用:各业务单元或组织的资源容器,用户可以在其中部署任意云资源和上层业务应用系统,不同的账号相当
197、于不同的资源容器,账号之间是完全隔离的。因此在一个账号中的故障和安全风险不会影响和传播到其他账号。各业务单元或组织的安全管理边界,每个账号都有独立的身份和权限管理系统,一个账号内的用户只能访问和管理本账号的资源,未经允许,一个账号内的用户不能访问其他账号的资源、数据和应用。各业务单元或组织的独立的账单实体,每个账号可以单独在公有云上充值、购买云资源、结算和开票。因此对于大企业内部的多个业务单元和组织而言,设置多个云服务账号不仅有利于实现不同业务单元和组织之间的故障和安全隔离,还可用于将多个业务单元和组织的财务和资源配额进行独立管理。另外,从可靠性、可用性角度出发,为了避免单点故障带来雪崩效应、
198、减少单点故障的爆炸半径,核心办法就是不要把所用业务系统及其云资源部署在单一账号,也就是不要“把鸡蛋放在一个篮子里”。单一账号存在两个严重的问题:其一是单一账号的爆炸半径太大,如果该账号发生崩溃将导致企业所有业务系统不可用;其二是云平台上账号的资源配额是有上限的,不能在一个账号内无限扩容云资源。综合上述,针对大企业上云的场景,多账号架构往往是最佳的选择。按照康威定律,大企业的多账号架构通常会与其组织架构或业务架构保持一致。采用多账号架构后可以实现职责分离,不同的账号负责不同的事情、承载不同的业务,每个账号可以对本账号内的资源进行自治管理,但同时从 IT 治理角度肯定要求一定程度的统一管控,比如多
199、账号的统一运维管理、安全管控、资源管理、网络管理、财务管理等。针对大企业的上述核心诉求,需要为大企业客户在云上构建安全合规、可扩展的多账号运行环境,实现与同一大企业客户对应的多个云服务账号之间的资源共享,以及相应的“人财物权法”的统一管控。人的管理:多账号环境下对组织单元、账号、用户、用户组、角色等进行统一管理。财的管理:多账号环境下对资金、预算、成本、发票、折扣等进行统一管理。物的管理:多账号环境下对计算、存储、网络、数据、应用等云资源进行统一运维和管理。权的管理:多账号环境下对云资源的访问权限进行统一管理,确保访问权限符合最小授权原则。法的管理:多账号环境下对安全合规进行统一管理,确保符合
200、国家、行业和企业自身的安全合规要求。065云原生 2.0 架构白皮书企业成功实施了上述“单企业多账号”解决方案之后,可以有效规避大规模上云之后的管理失控、安全失控、成本失控的风险,全面应对各种 IT 治理挑战,帮助企业建立分统结合的 IT 治理体系和完善的安全合规体系。分统结合的 IT 治理体系:即在分权分域分级管理的基础上进行一定程度的统一管控,如统一运维、统一安全等;完善的安全合规体系:云上运行环境(包括云资源、数据、应用等)满足国家、行业和企业自身的安全合规标准,“单企业多账号”提供了以下主要安全措施:SOD(Separation of Duty):通过多账号架构实现 SOD,一个账号就
201、是一个 SOD 单元,企业可以按照业务单元、地理单元、功能单元等维度划分账号,任何单一账号的崩溃不会影响全局系统,减少爆炸半径。操作审计:为每个账号开启操作审计,记录任何主体对资源访问的日志,也就是确保所有的操作都留下痕迹,同时将所有账号的审计日志进行集中存储和分析。配置变化跟踪:为每个账号开启资源配置记录功能,记录资源配置的变更日志,确保资源的所有变化都有迹可循,同时将变更日志进行集中存储和分析。安全护栏:安全护栏有两类,一类是安全红线,设定成员账号不能做什么事情,相当于强制限定成员账号的权限,避免成员账号权限过大带来的安全风险,在设置安全红线时可以采用上文中的细粒度授权,安全红线也叫做预防
202、性安全护栏;另一类是安全基线,要求成员账号满足基本的安全合规要求,如根用户要启用 MFA、云硬盘要加密等,安全基线也叫做检测性安全护栏。统一身份权限管理:统一管理多账号环境下的用户、用户组和权限,使得一个用户即可访问多个账号下的资源,统一身份权限管理可以减少权限管理的工作量,也有利于在企业范围内制定和实施统一的权限标准,避免权限设置不当造成的安全风险。统一安全管控:统一检测、处理和分析多账号环境下的安全事件、安全风险,并统一进行事件处理和响应,统一安全管控可以减少安全管控的工作量,也有利于在企业范围内制定和实施统一的安全规范。5.全方位立体化的安全运营,端到端闭环风险1)安全运营目标:安全运营
203、的工作围绕两个大目标进行:防入侵,防攻击;防入侵的运营子目标有:消除自身脆弱性、消减安全入侵威胁、掌握更新更全的脆弱性及威胁的情报知识;第二章|云原生 2.0 的技术及架构特征066 防攻击的运营子目标有:快速消减 DDos 威胁、快速消减扫断威胁、持续发现并清理招来DDos 及扫断的灰黑产业务;2)安全运营流程:端到端可闭环风险的安全运营,主要分如下阶段:安全日志集成:基于分布式无码采集技术,对云原生的产品的安全日志、以及多云日志集成,集成过程中完成归并、富化等初始加工;建模分析:基于大数据分析引擎,自动化的关联分析,基于 AI 构建流式模型,自动冒泡预警安全风险;安全风险预警及呈现:可拖拽
204、的安全风险可呈现与大屏、报告中,可以被安全管理人员、安全值班人员感知到;告警响应及处置:对所有预警进行全生命周期的闭环管理,基于 SOAR 技术自动化源编排、排班值班、响应处置、转事件、调查、关单等;3)安全运营要素:为了可闭环风险的安全运营流程,安全运营需要具备如下要素:具备安全运营经验的专家团队;可沉淀安全运营经验的运营平台;安全防护套件及工具,提供安全数据以及执行安全策略;4)安全运营场景:安全运营的大型场景,主要分为如下几类:日常安全运营:日常过程中,基于各安全要素,对各个安全目标,执行各安全运营流程,发现、消减风险,并对流程进行持续改进,避免风险再次发生;重大保障:重大节日、假日、活
205、动、会议期间,进行高强度 7*24 的安全保障,侧重于防攻击,保障业务可用性不因安全攻击受影响;防护演练:国家机关单位、地方政府、企业组织的攻防演练中,进行高强度的安全防守保障,侧重于防入侵,保障不因入侵失分被问责:通报、批评等;安全评估:重大保障及防护演练前,信息全面的脆弱性盘点,包括白盒方式的基线评估、黑盒方式的攻击面、攻击路径探测。067云原生 2.0 架构白皮书第三章华为云云原生2.0架构设计模式 068华为持续为千行百业的企业及政府客户提供基于华为云服务的解决方案与最佳实践,特别是全栈云原生的技术与架构方案,完成其数字化、智能化战略转型,并积累了丰富的经验教训与方案样板。考虑到华为自
206、身也是一家以数字化产品与解决方案制造为核心的大型企业,在近 10 年以来以云技术为底座的流程与 IT 数字化转型过程中,也总结沉淀了一整套体系化的企业信息架构云化的方法论及最佳实践,华为通过将华为云服务的外部企业、行业客户,以及华为流程 IT 自身数字化、智能化转型的核心关注点、企业组织与文化、工程实施能力等方面,与云原生架构与技术等进行有机结合,形成了华为独有的云原生架构设计方法HCNAM(Huawei Cloud Native Architecting Methodology)。HCNAM 是一个2+3+1的云原生战略解码及架构设计的端到端闭环流程,2代表企业战略视角,以及业务发展视角,是
207、云原生架构重构及演进的商业及业务层面的驱动力及规划的源头,3代表架构视角、工程视角,以及组织视角,是云原生架构重构及演进的设计及落地实施过程,1表示贯穿上述2+3要素的云原生架构的架构持续演进闭环。2+3+1华为云原生架构设计闭环的整体构成如下图所示:华为云原生架构设计方法(Huawei Cloud Native Architecting Methodology)3.1上一章节系统化地阐述分析了为充分释放全栈云服务的潜力,作为云原生 1.0 升级版的云原生 2.0,应具备哪些新的关键技术与架构原则,以及相应的技术架构特征背后的商业驱动力。而本章节,我们将更进一步逐一分享华为云具体是如何将上述云
208、原生 2.0 的关键技术与架构原则应用到全栈云服务产品及其组合的开发、测试、上线再到运营运维的全生命周期过程,以及相关的典型业务应用场景中,并总结提炼了一系列与之对应的云原生 2.0 架构设计模式,从而为华为云生态千行百业客户的 IT 云化、智能化转型开发者、运营运维人员提供更具参考和指导意义的最佳实践与经验模板。第三章|华为云云原生 2.0 架构设计模式069云原生 2.0 架构白皮书3.1.1 企业数字化战略 云原生技术架构的根本驱动力任何技术架构首先必须服务于企业的数字化战略,而云原生架构作为企业数字化转型的核心引擎与黑土地平台,不仅仅是一个技术升级过程,更是一个通过不断迭代重构技术架构
209、,使其与企业的核心业务生产业务流程和数据流程不断对齐,从而更进一步推动企业核心业务更敏捷地响应客户的需求,并将创新能力持续提升的过程。换言之,云原生架构本身就是企业整体数字化战略转型实施过程中不可或缺的一个关键环节与使能器,这也完全符合“康威定律”的总结:仅当技术架构与企业组织与业务架构高度吻合时,才能达到最高效的运作效率。不仅仅是高科技互联网企业,随着企业数字化、智能化不断渗透到千行百业,特别是面向实体经济的制造业、服务业、政府惠民便民服务等场景,与实体世界一一对应的数字化孪生世界对云计算、大数据、AI、IOT以及音视频等技术与服务能力提出了更为广泛与深入的需求。事实上,越来越多的企业正在越
210、来越重视 IT 数字化与云转型战略在企业整体战略中的位置,而围绕企业 IT 与业务桥梁建立、企业信息安全可信、企业核心数据资产沉淀梳理的关键岗位角色如 CTO(Chief Technology Officer)、CIO(Chief Information Officer)、CTIO(Chief Technology&Information Officer)、CDO(Chief Data Officer)等也应运而生。图 3-1 华为云原生架构设计架构(微)服务架构自动化运维高可用自服务云基础设施与平台服务分布式弹性伸缩多租户组织全功能团队AM团队FSD全栈工程师工程微服务持续交付DevOps自
211、动化研发环境外在价值企业可持续发展企业数字化战略架构设计持续改进与闭环快速规模可靠灵活高效第三章|华为云云原生 2.0 架构设计模式0703.1.2 业务可持续发展 云原生技术架构的直接驱动力华为云基于为企业提供的云服务和咨询最佳实践,总结数字化业务对云架构的主要诉求是业务连续性、业务快速上线、成本以及科技赋能业务创新。业务连续性诉求主要包括了数字化业务必须能够持续为用户提供服务,不能因为软硬件故障或者 bug 导致业务不可用,也能够抵御黑客攻击、数据中心不可用、自然灾害等意外事故。此外,当业务规模快速增长时,不能因为软硬件资源来不及购买或者部署而导致不能拓展新用户。市场瞬息万变,数字化业务由
212、于比传统实体业务更灵活可变而被要求更快的推向市场能力,包括新业务快速构建的能力、现有业务快速更新的能力。这些能力诉求被云原生架构深刻理解并在产品、工具、流程等层面得到不同程度的处理,需要注意的是这个诉求同时对组织结构带来了新的要求,也可能要求应用进行彻底的重构(比如微服务化)。云计算作为新的技术必须为企业释放成本红利,帮助企业从原来的 CAPEX 模式转变为 OPEX 模式,不必事先购买大批软硬件资源,而是用多少付多少;同时大量采用云原生架构也会降低企业开发和运维成本,有数据展示通过采用容器平台技术就降低了 30%以上的运维支出。传统模式下如果要使用高科技技术赋能业务,有一个冗长的选型、POC
213、、试点和推广的过程,而大量使用云厂商和三方的云服务,由于这些云服务具备更快的连接和试错成本,且在不同技术的集成上具备统一平台和统一技术依赖的优势,从而可以让业务更快速的应用新技术进行创新。3.1.3 架构设计视角 云原生技术架构本身1.服务化能力以服务/微服务为最小运行态单元构建业务应用,参照业务功能及其迭代周期进行单体应用的解耦拆分,并将多个服务/微服务以标准化 API 形式进行集成与编排;服务间采用事件驱动的方式集成,尽量减小相互依赖;通过可度量建设不断提升服务/微服务的 SLA 能力。2.弹性能力服务/微服务需要能依据动态业务峰值的变化,进行相应的资源负载实例的扩充和收缩。3.可观测能力
214、为保障企业业务的不中断连续运作,企业 IT 基础设施及其业务应用中的任何软硬件发生错误后均需要能快速修复,由此要求相关的服务/微服务具有全面的可观测性,从传统的日志方、监控、告警/事件,到面向微服务的端到端链路跟踪,以及服务 QoS/SLA 度量。071云原生 2.0 架构白皮书4.韧性能力要求业务应用基于微服务框架能力,或基于自身业务直接构建常用的熔断、限流、降级、自动重试、反压等能力,同时进一步构建面向可靠性鲁棒性的高可用容灾、异步化的特性。5.安全可信能力关注企业业务的数字化安全,除充分利用云安全服务加固企业业务应用的全方位应用安全、数据安全、网络安全、平台安全的同时,将安全可信管控制引
215、入到 DevSecOps 软件生命周期开发的全流程各个关键里程碑点,确保企业应用符合 ISO27001、PCIDSS 等级保护等国家区域与行业的云安全合规要求。6.自动化水平随着企业大颗粒的单体业务应用被重构改造为小颗粒的服务/微服务解耦架构,相关服务/微服务的全生命周期管理,包括开发、构建、测试、部署、升级、扩容等过程与活动如不能实现敏捷自动化,则可能反而为企业业务应用 IT 系统的运维效率及复杂度带来巨大挑战,为应对这一挑战,服务/微服务软件的发布部署从基于物理机或虚拟机的软件包安装配置演进为基于容器技术的集装箱式封装,并通过引入 IaC(Infrastructure as Code,基础
216、设施即代码)自动化编排机制,以及 TOSCA/Terraform,及 CNCF OAM 等主流生态兼容的 DSL 云服务编排部署脚本;GitHub/Jerkins 等自动化 CI/CD 流水线及运维工具能力,从而打通各层云服务,以及自动化运维工具之间的信息断点与流程断点,实现从企业业务原始需求输入,到需求开发实现并上线验证部署,乃至后续修改变更的全流程自动化。7.云边协同能力随着互联网行业内上云业务流程从非实时移动互联网业务迅速向低时延互动视频直播、游戏AR/VR 验证发展渗透,同时随着全面云化、数字化进一步从互联网领域延伸到千行百业,也必然对上云业务与工业互联网生产现场设备、智慧城市物联终端
217、设备之间的接入时延提出了更高要求:通常工业互联控制边缘场景小于 5ms 时延,互动直播、AR/VR 游戏则要求小于 20ms。因此,唯有将云端应用靠近数据产生端的部署,才能可能解决上述这些日益苛刻的云业务接入时延诉求。除时延外,海量智能物联设备所产生的海量数据的上传云端的成本也不容忽视,随着物联网时代边缘数据爆炸性增长,全球数以百亿计物联终端接入到互联网的数据容量高达 50 万亿 GB。如此海量的数据全部回传至云端显然成本过高,需要数据在上传云端前即在本地就近的边缘节点侧展开分析和过滤,再向云端上传预处理后的数据,从而大幅节省网络带宽;而鉴于部分企业客第三章|华为云云原生 2.0 架构设计模式
218、072户对其核心或涉密业务数据场景的数据敏感隐私安全需求,可能要求数据处理变换在客户本端数据中心内完成,从而实现企业敏感数据及个人隐私信息的仅在本地处理,杜绝了不可控的数据外传风险。最后,云边协同的边缘节点虽然日常要求与云端保持长连接,从而使得云端保持对边缘节点运行健康状态的管理能力,但在本地网络与云端断连的情况下,要求边缘侧可在一段时间内不依赖云端连接控制及终端的离线处理能力、自我恢复能力。8.无服务器化程度在业务中尽量使用云服务而不是自己持有三方服务,特别是自己运维开源软件的情况;并让应用的设计尽量变成无状态的模式,把有状态部分保存到云服务中;尽量采用 FaaS、容器/应用无服务器的云服务
219、。指标维度HCNAM-L1(1 分)HCNAM-L2(2 分)HCNAM-L3(3 分)HCNAM-L4(4 分)HCNAM-L5(5 分)服务化能力无(单体应用)部分服务化 有跨服务数据共享全部服务化,无治理体系全部服务化,嵌入式微服务治理平台全部服务化,服务网格化弹性能力手工扩容(月/周级)资源监控+人工干预扩缩容(天级)资源监控+代码实 现 基 于 VM 的自动扩缩容(分钟级)资源&应用监控+代码实现基于VM 自 动 扩 缩 容(分钟级)资源&应用监控+代码实现基于容器的自动扩缩容(秒级)无服务器化程度应用逻辑及底层中间件、DB 均采用进程资源,物理多租事件驱动的无状态计算数据库、中间件
220、、文件系统提供逻辑多租服务数据库、大数据等有状态服务的Serverless 化端到端有状态中间件/数据库+无状态应用的Serverless 化可观测能力无有基础监控、告警、日志类监控在 L2 基础上,支持端到端跟踪,性能指标上报及故障根因定位在 L3 的运维监控日志大数据,支持多维度分析,监控数据事件精度分钟级监控数据事件精度秒级,基于实时监控流数据的洞察观测能力安全可信能力防火墙+传统安全 3 方件安全及网络功能软件化、分布式可 扩 展,IAM 多租身份标识与认证管理租户级数据安全加解密及隐私数据脱敏,租户内资 源 分 组 RBAC控制安全威胁与态势感知,自动化风险响应,租户内资源实例级细粒
221、度权限ABAC 控制基于零信任的安全多方计算,行业合规自动化评估,联邦学习,安全能力融入 DevOps 全生命周期流水线073云原生 2.0 架构白皮书根据对上述 8 个云原生架构维度分别展开评分并汇总,并最终基于汇总评分对企业业务应用进行云原生架构成熟度的定级:云原生架构成熟度1 级入门级2 级基础级3 级标准级4 级发展级5 级 成熟级级别与定义=34-1213-2829-3738-40表 3-1 企业云原生成熟度评估模型表 3-2 云原生架构成熟度级别与定义指标维度HCNAM-L1(1 分)HCNAM-L2(2 分)HCNAM-L3(3 分)HCNAM-L4(4 分)HCNAM-L5(5
222、 分)韧性能力无冗余,无流控及容灾机制本 地 主 备/负 载均衡 HA 冗余(RTO 10 分钟级)基本流控能力跨地主备或多活容 灾(50-100 公里)增强流控能力(峰值 10 倍于可处理流量)本地主备或多活容灾,跨地冷备容 灾(数 百 至1000 公里)先弹性扩展,再出发流控及反压;面向微服务的熔断、限流、反压控制机制全 球 化 Serverless业务分发,切流无感 知,容 灾、流控失效后,系统具备降级能力,确保最小功能集可连续提供,并提供逃生 机制自动化水平无单层平台或单个服务软件支持基于文件的半自动化安装 CI/CD单各云服务/微服务基于容器自动化的 CI/CD 流水线基于终态+过程
223、驱动相结合的 DSL自动化的全栈业务应用及其所赖的云服务、公共的自动化发放AI 使能的系统运行参数优化,以及无人干预自动化修复云边协同能力无云端资源池拉远到与分布式 CDN站点共站址,下沉云服务 10%云端资源池拉远到与客户的 On-Premise 数据中心站点,下沉云服务 40%云端 K8S 容器通过 KubeEdge 边缘将容器拉远部署在边缘节点上,并支持边缘证书发布及管理跨云边统一协同、事 件 EDA 驱 动 的Serverless 开 发 与编排支持云服务 Traffic全球性智能路由3.1.4 组织变更视角云原生架构涉及到的架构升级对企业中的开发、测试、运维等人员都带来了巨大的影响,
224、技术架构的升级和实现需要企业中相关的组织匹配,特别是架构持续演进需要有类似“架构治理委员会”这样的组织,不断评估、检查架构设计与执行之间的偏差从开发团队视角,必须实现从原有水平细化分工的瀑布式开发到 DevOps 敏捷式全功能开发的转变。第三章|华为云云原生 2.0 架构设计模式0743.1.5 工程变革视角DevOps 运维工具、数字化运维运营平台是企业云原生架构落地不可或缺的前提条件。构建Cloud Native 工具链,实现从开发人员提交代码,到构建、测试、发布、反馈的自动化和持续交付流水线;基于 IaaS 和 PaaS 建设软件开发云 2.0,给产品提供完整的 IaaS 和 PaaS
225、服务,实现服务共享、互通和版本配套;产品要基于开发云环境和 Cloud Native 工具链进行开发。3.1.6 架构持续演进闭环云原生架构演进是一个不断迭代的过程,每一次迭代都是从企业战略、业务诉求到架构设计与实施的一个完整闭环,整体关系如下图:图 3-2 架构持续演进闭环从上图不难看出,整个企业云原生架构持续演进闭环中初始关键输入为企业战略及业务发展策略,及其层层解码后映射到 IT 技术视角的一系列原始包需求与设计分解需求;而该云原生架构持续演进闭环中的关键过程则包括:参照持续更新的原始包需求及设计分解需求,不断识别业务痛点和架构债务、确定架构迭代目标、评估架构风险、选取云原生技术、制定迭
226、代计划、架构评审和设计评审、架构风险控制、迭代验收和复盘。企业战略视角业务发展视角架构持续演进闭环识别业务痛点和架构债务01.确定架构迭代目标02.评估架构风险03.选取云原生技术04.制定迭代计划05.架构评审和设计评审06.架构风险控制07.迭代验收和复盘08.075云原生 2.0 架构白皮书1.统一认证鉴权企业基于全栈云原生服务能力进行云化业务应用开发或重构,基于“零信任选择”,企业应用业务软件必须统一对接华为云的 IAM 认证系统,已获取访问全栈云服务能力的合法权限,如自身开发的服务希望以多租行业云服务形式进一步对外开放,则也需要完成与 IAM 对接,从而实现租户模型、认证和权限管理的
227、统一。2.统一运营计费若新开发的 SaaS/行业 aPaaS 也需提供面向企业 2B 多租用户的计量计费功能,则各云服务软件必须遵从统一的计量话单和计费规范,实现计量话单的标准化输出和计费模式的统一。图 3-3 华为云云原生架构企业云原生架构的可持续演进与迭代能力:基于服务开发服务3.2云原生应用网络云原生基础网络云原生硬件智能网卡OVS卸载(182x)通用计算CPU(X86/鲲鹏)异构计算NPU/GPU(昇腾/笛卡尔)容器引擎/虚拟化卸载云原生网络直通及服务网格加速云原生存储卸载(SDI)超融合机柜(FusionPod)云原生低时延网络UBUS云原生操作系统轻量级容器引擎 Container
228、d/iSulad/WASM安全容器 轻量级虚拟化Qemu/Stratovirt云原生负载均衡ELB云原生虚拟化网络VPC(CNOS)云原生网络高速软交换Gaea云原生L4负载均衡IPVS/CVS云原生应用L7负载均衡Nginx/Envoy云原生网格Terrace云原生超低时延链路协议CurreNET云原生网关xGW云原生容灾管理云原生存储网关(K-V/S3/HDFS/CIFS)云原生分布式K-V存储引擎(DFV)云原生对象存储OBS云原生块存储EVS云原生文件系统SFS云原生容器引擎 CCEServerless容器引擎 CCI云原生统一资源调度(瑶光+柔性计算)云边拉通、跨Region全域调度
229、云原生Serverless Runtime调度 元戎内核/KNative云原生统一应用调度 Volcano云原生批量计算BCE/EKS云原生消息中间件DMSAI开发套件云原生微服务框架云原生CloudIDE云原生软件调试云原生可信代码仓可信二进制仓云原生编译构建云原生测试工厂云原生服务网格 ASM(非侵入式,服务发现/流量治理/应用代理/RPC)云原生服务市场OSC(服务目录&管理)容器镜像仓库 SWR(容器Registry)多云容器编排MCP(Karmada)微服务治理ServiceStage(侵入式,Java/Go)云原生应用编排IAC/AOS(Terraform&TOSCA)无服务器应用
230、托管(WebHosting etc.)CleanCode监控告警全链路跟踪CMDB配置变更日志分析故障管理容器洞察CIE(Prometheus)云原生开源治理AI市场视频直播 LIVE视频点播 VOD媒体处理 MPCCloud XR实时音视频 RTC云会议 meetingIoT行业生态工作台IoTStageIoT边缘IoTEdgeIoT数据分析IoTA设备接入管理IoTDA认知计算AI(行业知识图谱)感知计算AI(视频,OCR,语音,NLP,时序预测.)ModelArts OS底座云原生缓存中间件DCS云原生应用集成Connect云原生资产运营Exchange云原生函数FunctionGrap
231、h云原生Serverless事件中心云原生HC Linux(含云原生容器OS/CNOS)云原生应用系统加速Runtime-CNSR云原生硬件云原生OS云原生弹性资源云原生应用平台云原生应用生命周期管理云原生生态使能云原生计算云原生中间件用户标识与认证授权IAM租户资源组隔离EPS云原生多租认证与权限管理客户管理订购与交易履行产商品管理计费/账单/成本管理服务信控计量话单SDR云原生运营与计费管理面APIGW(外部)管理面APIGW(内部)租户面APIGAPI治理云原生API开放Web前端框架Web后端NGINX云服务ConsoleConsole代理云原生Web Console云原生AI云原生视
232、频云原生物联网云原生服务开发流水线DevSecOps云原生服务治理与编排云原生物联网云原生数据库混合云 CCE敏捷版边缘容器服务 IEF(KubeEdge)边缘系统 IES边缘站点 IEC云原生边缘及混合云云原生安全可信云原生大数据云原生存储数据智能基础设施 DII数据治理中心 DGC数据湖目录 DLCatalogue物理多租 批处理MRS逻辑多租多引擎DLI数据仓库DWS搜索引擎CSS多方计算TICSNo SQL大数据 CloudTable流式数据集成DIS数据搬迁CDMAPI/SDK(JDBC/C/C+/Python/.NET)分布式DB Server&分布式锁(Share Everyth
233、ing&Share Nothing)Tool Kit DB管理(DAS)DB容灾(DRS)分布式SQL引擎分布式文档引擎分布式K-V/时序引擎分布式图引擎流量清洗 AntiDoS检测与响应类凭证类Web防火墙 WAF云堡垒机CBH态势感知 SA安全策略管理SPM主机安全HSS容器安全CGS数据库安全DBSS数据加密DEW证书管理CCM凭证管理CCMS审计类政企与互联网应用与开发生态入口第三章|华为云云原生 2.0 架构设计模式0763.统一服务 API 开放对于新开发产品必须开放 API,并遵从统一的 API 开发设计规范,实现开放 API 的标准。4.统一 API 网关统一各新开发的服务直接
234、对接到统一的 API 网关,为后续业务应用的开发者用户提供统一的入口调用各个服务的 API。5.运维管理统一新开发运营的日志、告警、监控等功能必须使用统一的租户运维管理工具服务。6.通过基于服务开发服务,实现公共组件的“云原生归一化”严格遵从“基于服务开发服务”的架构原则,实各服务尽量统一到优选的数据库、集群管理、负载均衡、消息队列等。7.统一安全可信管理服务各云服务遵守统一的云领域的可信架构方法,与相应的安全性、韧性、隐私等可信管理服务集成,实现相关可信能力的落地。3.3.1 分布式云设计模式分布式云设计的核心是基础设施的部署方式。其中中心云可以通过公有云承载,也可以通过云服务供应商交付全栈
235、云架构到企业的本地机房。分布节点根据其业务诉求也会有所差别。业务场景较为简单、清晰,但是又一定计算能力诉求的分布式节点可以通过边缘云承载;跨国、跨区域业务,可通过公有云跨 region 业务部署模式承载;分支节点业务量大、业务场景复杂的场景,也可以考虑本地专属 region 的交付方式。因此,分布式云的设计模式,按照云服务的交付模式可以大致分为三种:华为云云原生2.0的典型架构设计模式3.3077云原生 2.0 架构白皮书1.公有云+边缘云边缘云上部署 CDN、就近接入视频直播、AI 媒体转换处理,边缘云服务是华为云基础设施的一种延伸形态,部署在城域热点区域的位置,满足大流量和低延时的业务需求
236、。图 3-4 公有云+边缘云架构图 3-5 内容源站场景互动直播中心云边缘云视频RTCVR渲染资源调度覆盖热点区域沉浸式智真协作智真会议终端PC桌面智慧屏手机平板/电脑20ms流量调度站点部署管理运维云游戏引擎视频AI在线教育应用加速智能视频智能边缘云IEC管理面云游戏云VRIEC边缘站点高阶服务基础服务擎天架构多元算力网络转发IEC边缘站点高阶服务基础服务擎天架构多元算力网络转发IEC边缘站点高阶服务基础服务擎天架构多元算力网络转发1)内容源站场景多运营商线路同站点接入,快速获取资源降低客户内容源站压力。为客户提供弹性、安全、可灵活扩展和伸缩的边缘计算网络服务,为短视频、游戏、直播、教育等多
237、场景提供一站式内容分发解决方案。华为云IEC边缘站点CDN内容中心全局调度负载均衡内容缓存内容访问信令交互内容源站日志分析IEC边缘站点负载均衡内容缓存内容访问信令交互第三章|华为云云原生 2.0 架构设计模式0782)就近视频接入场景高性价比的海量视频接入能力,助力客户实现业务可持续经营。通过智能存储、视频 AI,多线网络接入等技术有效解决视频接入中心云流量成本高,以及热点区域覆盖问题。图 3-6 就近视频接入场景图 3-7 互动直播媒体转换场景3)互动直播媒体转换场景借助多元算力、AI 智能服务、就近接入网络技术,满足用户解决降低成本和时延、提升业务处理性能等诉求,助力用户更好的处理就近转
238、码、弹幕分发、实时渲染、内容审核等核心业务。华为云IEC边缘站点CDN内容中心智能手机OBS直通访问视频流视频存储视频智能摄像头OBS网关视频接入按需查看三线接入IEC边缘站点智能手机摄像头OBS网关视频接入按需查看三线接入IEC边缘站点直播转码内容渲染主播音视频流弹幕流CDN分发流主播观众观众弹幕分发内容审核IEC边缘站点直播转码内容渲染弹幕分发内容审核华为云CDN网络直播中心视频存储视频智能视频存储视频智能079云原生 2.0 架构白皮书 基于边缘 IEF 的视频 AI 及流处理,云端 ModelArts 训练,模型推送到 IEF,兼容非 AI 传统终端上图表示了一个用该模式实现的智慧工业
239、场景,根据对从产线上采集到的信息进行推理分析来不断优化产线参数,达到最优化生产的目的。在该系统中,部署于云上的 ModelArts 服务利用云上的资源完成海量数据预处理及半自动化标注、大规模分布式训练、自动化模型生成,而后通过 IEF(智能边缘平台)将模型部署到边缘。IEF 服务将云上训练好的 AI 应用以容器形式推送到指定的边缘节点,提供边云传输通道,联动边缘和云端的数据,支撑 AI 应用实现边云智能协同。同时提供升级、监控、日志等运维能力。边缘 AI 容器加载模型,实时从设备获取数据,通过推理进行瑕疵检测,根据结果调整生产设备的参数,提升良品率。边缘产生的数据和推理结果周期上传到云上的 M
240、odelArts 服务,用于持续模型训练和生产分析。通过华为云 IEF 服务管理基于开源云原生边缘计算项目 KubeEdge 定制的边缘一体化系统KubeEdge 是 CNCF 中的首个云原生边缘计算框架。该项目面向边缘计算场景,专为边云协同设计,旨在提供应用协同、资源协同、数据协同和设备协同的统一标准。IEF 是华为云中提供的KubeEdge 商用版服务,与 KubeEdge 生态完全兼容,可对用户使用 KubeEdge 为自己特殊的边缘形态深度定制化的系统提供统一的云上管理能力。数据集管理产线维护生产计划良品率分析EI服务模型部署数据集管理模型训练IEF接入服务应用管理边缘运维资源调度产线
241、通信容器管理EdgeAgent函数管理1.发放/更新边缘应用5.持续训练4.传递数据边云通道3.周期上传检测数据和结果2.启动边缘容器1.读取视频流2.调整参数工业平台-AI应用视频接入瑕疵检测任务管理边缘AI容器/函数产线调节数据管理图 3-8 IEF 用于智慧工业场景第三章|华为云云原生 2.0 架构设计模式080上图展示了该模式在云原生卫星场景中的使用。在该场景中,使用边云协同的模式从地面对卫星上的 AI 遥感模型进行管理,并且通过 KubeEdge-Sedna 的能力使卫星具备了与大云进行协同推理、增量训练的能力,让卫星越来越聪明。在卫星中,对设备功耗要求严苛,从星载设备到操作系统再到
242、上面运行的软件都有严格的要求。为了满足卫星上的使用,需要对 KubeEdge 进行兼容性、轻量化等方面的深度定制。只需保证定制后的系统满足社区的“平台一致性认证”,即可保证该边缘可以连接至华为公有云,利用公有云的海量算力支持业务运行。2.公有云跨 Region1)多云容器场景:互联网 App 的跨 Region/跨云统一弹性伸缩,跨 Region/跨云统一微服务治理图 3-10 多云容器场景系统管理员MCP集群联邦管理ASM网络数据面资源利用率低中心云专属Region全局容器网络边缘站点A边缘站点B推理中间件推荐数据库网站ASM网络数据面资源利用率高ASM网络数据面ASM网络数据面资源利用率高
243、弹性流量治理数据库广告用户LBLB视频转码视频资源利用率高LB视频视频视频数据广告网站数据数据数据ASM全局服务治理中心图 3-9 IEF 用于遥感卫星场景遥感卫星华为云星载边缘一体化遥感设备EdgeCloud遥感目标检测(小模型)卫星地面信号站KubeEdoe-Sedna遥感目标检测(大模型)IEF服务081云原生 2.0 架构白皮书上图是抽象了互联网客户的场景,用户的业务分别部署在中心云和专属 region 上以及多个边缘站点上,这样用户希望多地集群资源能够进行统一的管控,从而提升资源的利用率。在此基础上希望将多集群间服务就行统一治理,降低服务延迟和提升服务的流量分发效率。通过 MCP 集
244、群管理能力,可以把这些分布式集群统一就行管控,这样当流量高峰时候,单一便于站点的资源利用率持续升高,提高了业务由于资源不足的故障可能性,这时候就可以通过识别其他资源利用率低的站点,弹性扩容服务,将流量一部分导入到其他站点上来缓解业务高峰时故障发生,完成跨云跨地域的弹性扩容,保证业务可用性,提供资源利用率。而通过 ASM 的全局服务治理,可以使得用户的访问流量能够就近访问对应集群,降低访问的端到端时延,提升用户使用体验,同时服务在集群间的流量可以识别不同流量就行分发访问,例如实际访问流量可以导向边缘站点,而溢出流量等可以导向其他集群。2)跨国企业用户跨华为云、伙伴云开通账号,并使用消费云服务企业
245、在华为云(归属云)上完成开户,申请开通巴黎Reigon、莫斯科Region的“漫游”访问权限。归属云会自动在漫游 Region 所属的伙伴云创建“漫游”账号,赋予访问权限。然后,企业就如使用归属云自有 Region 一样,以统一的账号、统一 Console、统一 API 网关使用漫游 Region,费用统一结算、统一出账。图 3-11 跨国企业用户跨华为云、伙伴云开通账号租户统一入口伙伴云归属云归属账号租户Console华北Region华东Region新加坡Region莫斯科Region巴黎Region河姆斯特丹Region.RegionAPIConsoleAPIConsoleAPI漫游账号伙
246、伴云漫游账号3.公有云+本地专属 region该模式基于专属云技术,可提供对计算资源、存储资源、网络、数据库等资源的专属使用,第三章|华为云云原生 2.0 架构设计模式082华为云通过 HCSO 解决方案为政企客户提供专属云技术,该解决方案的技术优势包括:专享合规、安全隔离:用户独享隔离的物理资源,满足业务性能和安全合规要求;就近部署、极致体验:就近部署在用户机房,满足数据不出省或不出机房,高速本地接入,节省跨省链路成本,云服务使用时延小于 50ms;稳定可靠、精简敏捷:继承云大规模商用成熟架构,代码相同,体验一致,业务可用性高;云服务模块化解耦,可快速同步华为云服务,按需搭配云服务组合,精简
247、管理和网络占比,自动化部署快速上线,统一运维,业务平滑迁移和扩展;同构混合、开放生态:基于与华为云统一的擎天架构,构建云上云下无缝协同的混合云架构,共享华为云 MarketPlace 生态,方便直接复用云上丰富的第三方软件生态。图 3-12 公有云+本地专属 region3.3.2 极致性价比驱动的软硬协同架构设计模式 1.基于擎天/SDI 卡的无 IO 损耗虚拟化/容器化华为云的擎天/SDI 卡通过 SRIOV 获得 VF 形式的 SCSI Controller,这些 VF 通过 VFIO 直通到容器中。容器内的 IO 读写请求将直接发送到运行在擎天卡上的 SPDK 进程,SDPK 进程通过
248、 DMA直接访问需要读写的数据,并进行本地或远程的 IO 持久化操作,全过程都在 SDI 上运行,不会因HCS Online云服务华为云机房本地机房华为云统一运维华为云机房云服务共享资源池.资源专属HCS Online云服务全栈专属云服务同时提供高安全的网络隔离环境满足网络隔离要求,资源独享可以避免业务高发期资源被抢占造成的业务卡顿情况,从而满足性能、安全、可靠性、可扩展性等关键业务诉求。083云原生 2.0 架构白皮书此占用物理机上的 CPU 和 memory 资源。同时由于采用的是物理设备直通的方式,最大限度地消除了虚拟化带来的 IO 时延和带宽的影响。2.基于昇腾卡替代 GPU/CPU
249、的 AI 训练及推理服务面向 AI 场景,华为云提供昇腾系列云服务器。该服务支持 Mind Studio、自定义编排 AI 业务流,以及 Caffe/Tensorflow 等推理模型,非常适合人脸识别、内容审核等视觉计算类业务,性价比相比业界主流GPU系列推理型实例性价比提升75%。同时,基于华为自研的鲲鹏+昇腾处理器,华为云打造了两款鲲鹏系列 AI 实例,鲲鹏 AI 推理型实例 KAi1s 和鲲鹏 AI 训练型实例 KAt1。华为云昇腾 AI 计算解决方案基于昇腾全栈创新的能力,构建开放的开发和服务框架,提供快速被集成,共享标准化组件。昇腾 AI 计算解决方案由推理加速型云服务器 Ai1 提
250、供 AI 算力,其单实例性能半精度 FP16 计算高达 128 TeraFLOPS,整型 INT8 计算高达 256 TeraOPS;其中,单芯片可提供 8GB 显存,内存带宽 50GB/s,功耗低至 8w,构建高性价比算力。解决方案中Ascend Serving 层支持 RESTFul 和 gRPC 接口,兼容 FFmpeg 框架,与主流生态无缝对接,无需额外编码。解决方案的 AI 容器层借助容器的轻量灵活的优势,可实现 30 秒扩容 1000 容器,为海量的任务快速补充算力,再结合智能任务调度,实现任务与资源的最佳匹配。其以高性价比、高性能、生态兼容为互联网、智慧园城市、智慧零售、泛金融认
251、证等行业提供全栈赋能。3.应用感知智能自治的云原生 OS云原生下的操作系统变更应满足以下的特征要求:感知云上资源与负载:云化基础设施可以看做是一种新型的硬件形态,当前操作系统在沟通协调应用与底层资源匹配上仍存在一定的隔阂,尤其当云上硬件环境发生变化,如多种异构设备下的混合算力模式的时候。因此,云原生下的操作系统应能精确感知底层资源状况,观测并收集分析信息给平台层进行调度决策;对上需要感知具体应用运行负载,根据负载特征进行相关调整。协同全栈的敏捷:前文表述过当前基础设施与应用开发部署态复杂度进行了置换,在云原生进入深水区后,操作系统自身应和全技术栈一道进行敏捷化,其重要表现为系统的自治,实现系统
252、的自治依赖于对应用、负载、资源及自身运行状态的感知,可以说上文中特征要求是实现自治的基础。智能化 AI Native 可定义的操作系统:利用人工智能机器学习等智能化方式结合启发式经验化的自动化能力,实现将智能化融入操作系统本身,这里应该包括两个部分,一方面是利用智能化对整个系统的自治,另一方面是利用智能化手段对操作系统本身进行改造,更适配当前应用所需的运行环境,也是以应用为中心的体现之一。第三章|华为云云原生 2.0 架构设计模式084针对上述技术特征,云原生操作系统包括但不限于以下的技术能力:数据观测引擎:提供低负载的数据观测能力,包括对黑盒的观测与微架构层级的观测等,形成统一的结构化数据,
253、为数据分析提供基础能力。可以注意到的是,观测能力是基础能力,但资源消耗是当前观测能力局限的一个很大的制约。可行的技术手段包括利用 eBPF 轻量化的观测探针、与硬件结合的细粒度 PMU 观测手段等。在云原生环境下,数据观测应该内化为操作系统的基础能力之一。OS 数据服务:清洗处理数据观测引擎提供的数据,提供数据分析与数据关系处理。这里的数据服务指操作系统本身产生的数据。在实际的使用过程中,云平台、框架本身也会提供一定的数据服务,这部分能力应可以结合协同使用。如在华为云平台中,瑶光提供了一定的数据处理能力,此时这部分数据服务可以进行相应的结合。OS智能自治引擎:包括运行态的自治,即应用运行态性能
254、的自调节,保障应用运行最优环境;运维态的自治,即智能化自动进行操作系统运维操作,包括但不限于系统的升级、故障定位定界与排除等;安全自治,即自动化安全漏洞推送、修复等。当然,除了以上列出的可能的探索点,在云原生下操作系统本身还有诸多可探索的方面。华为云平台也针对云原生推出了 Huawei Cloud EulerOS 操作系统发行版,上述的这些技术能力也会逐步在该发行版内进行实践。3.3.3 多元算力统一资源池架构设计模式华为云瑶光云脑支持多异构资源统一调度。云计算规模发展和计算资源多元化趋势,在资源有效利用、资源成本控制等方面对云提供商的资源供应提出了更高的要求,华为云瑶光统一调度通过算力池化、
255、技术栈统一、数据自驱等技术打造了统一资源管控平台。瑶光统一资源管控平台具有以下特点:1.统一资源调度过去的资源调度中,常常针对不同的硬件资源、不同的器件代系、不同的产品形态独立建立多个资源池,资源池独立调度。这主要存在两方面问题,首先是资源池调度没有有效实现资源池化,精细程度不足,第二是调度局限在资源池内部,资源池间存在空气墙。统一资源调度需要统一的计算节点技术栈基础,并在调度方面实现资源分层、协同调度。资源池调度系统需要屏蔽多元化算力资源差异,在资源池化基础上完成在线资源调度、离线资源整理、资源自适应调整等功能,通过精细化调度实现资源利用率的有效提升。资源池间调度系统需要处理多资源池之间的联
256、系,协调多资源池有序供给,协同应用层进行削峰填谷,实现资源的极致复用。除此之外,统一资源调度还需要完善的配套基础设施,例如计算热点最终系统,调度仿真及算法迭代系统,资源供需画像及预测系统等。085云原生 2.0 架构白皮书2.统一问题建模、求解云计算资源管理领域中存在诸多复杂、多目标、大规模的博弈、优化问题,问题之间相互影响且多属于 NP 难。建模与求解此类工业级复杂约束的问题一直是学术界和工业界的共同挑战,针对独立问题逐个突破几乎注定无法成功。因此,使用统一的问题建模语言,应用统一的问题求解框架,解耦问题建模与算法求解过程,成为了一个趋势。3.数据自驱演进超大规模资源的管理和高效利用,高度依
257、赖实时、自动化、智能化的数字化管理能力,平台需要具有资源、服务、系统等多维度指标数据的实时采集能力,选用合适的存储系统累计数据资源,支持流、批等多种数据分析及可视化供给,同时与调度、运维等系统联动、协同,一方面实现资源交付使用全链路看护,另一方面为系统架构、功能的长期演进提供数据支撑。3.3.4 无服务器化(Serverless)架构设计模式华为云 Serverless 函数工作流 FunctionGraph2.0 是新一代函数计算与编排服务,联合华为2012 实验室倾力打造。图 3-13 华为云 Serverless 架构大数据&AI端侧应用物联网数据处理音视频函数开发工具监控调用链日志函数
258、可观测条件分支并行分支循环处理时间等待DDSAPIGLTSOBSSMNKafka触发器函数编排Fn 1Fn 2Fn n云基础设施(计算、存储、网络、容器)数据库消息认证存储BaaS元戎内核CLI CI/CDCloudIDE第三章|华为云云原生 2.0 架构设计模式0861.丰富的函数开发语言及触发方式让设计更灵活支持常见的编程语言 python、java、nodejs、go,也支持容器镜像和自定义运行时。函数调用支持同步和异步两种方式,最长支持 12 小时,可满足长时间任务的需求,大大突破传统serverless 的适用场景。图 3-14 华为云 Serverless 支持的函数开发语言和函数
259、触发方式图 3-15 华为云 Serverless 支持图形化拖拽方式进行函数编排2.可视化拖拽式函数流支持编排复杂业务场景支持通过图形化拖拽方式进行函数编排,支持并行分支、条件分支、子流程、循环、异常处理等,可以满足多函数场景下的快速编排需求。函数开发语言(6大类)函数触发方式(10+)自定义运行时Shell脚本 orLinux可执行文件容器镜像版本:6.10、8.10、12.13、14编程语言版本:2.7、3.6、3.9版本:8、11版本:1.xGaussDB(for Mongo)云数据库Kafka分布式消息服务DDS文档数据库服务APIGAPI网关同步 最大运行时长15分钟DBCTS云审
260、计服务LTS云日志服务DIS数据接入服务OBS对象存储服务DMS分布式消息服务SMN消息通知服务Timer定时器异步 最大运行时长12小时087云原生 2.0 架构白皮书3.统一插件支持云上和云下的开发与调试serverless 场景下如何对函数进行调试是个难点,我们针对云上云下两个场景都提供了解决方案,值得一提的是支持了多函数调试能力,目前业界首家。4.HTTP 函数让 WEB 服务近乎 0 成本改造,享受 Serverless 优势能力图 3-16 云上云下两个场景数支持多函数调试能力业界首个支持集群函数调测VSCode 本地开发测试(云上)CloudIDE 支持:1.通过模板创建函数2.
261、云端函数的查看,下载到云 IDE 在线调试3.函数推送到云端4.当前支持 Java,Node.js 语言(云下)VSCode 插件支持:1.通过模板创建函数2.云端函数的查看,下载到本地调试3.本地函数推送到云端4.当前支持 Node.js,Python 语言图 3-17 WEB 服务 serverless 化改造方案RDS云数据库ECS云服务器ECS云服务器ELB典型的WEB服务部署架构RDS云数据库Client客户端Client客户端FunctionGraphWeb ServerWeb ServerWeb ServerAPIServerless化改造方案Server代码0修改,仅需修改服务
262、端口等少量配置自动创建API网关服务,仅需创建函数第三章|华为云云原生 2.0 架构设计模式088微服务和函数在未来几年会是一个共存的形态,当前存在着大量微服务应用,如何高效的支撑其 Serverless 化,让现有微服务快速享用到 Serverless 的优势能力,是一个待解决的问题。针对 Web 服务,推出 API 网关加 FunctionGraph 的 HTTP 函数方案,用户只需把原有的 Web Server代码打包为一个HTTP函数,即可完成Serverless化改造。价值体现在多语言WEB框架支持,例如:Java-Spring Boot,Nodejs-Express 等框架开发的应
263、用极小修改就是能完成 Serverless 函数化改造。开发人员可以继续使用熟悉的开发框架和测试工具,API 网关服务随函数自动化创建,降低开发人员学习负担。改造后无需运维资源,简单配置即可实现 100ms 级自动弹性和灰度升级。5.函数支持在运行时动态指定资源,灵活调度节省成本图片压缩、水印处理、文档转换、视频转码是典型的事件触发,波峰波谷明显的场景,越来越多地使用 Serverless 函数来开发业务,以视频转码为例,典型的处理流程:图 3-18 Serverless 函数用于视频转码的处理流程视频文件的大小从 MB 到 GB,不同编码格式和分辨率对转码需要的计算资源要求差别很大,为保证转
264、码函数的性能,通常配置一个很大的资源规格,但是在低分辨率的(例如短视频)场景下,会造成资源浪费。FunctionGraph 提供了一种方案支持函数执行时可根据业务需要动态指定资源规格,最小化资源占用,可以给用户带来更精细的资源控制,更低的成本开销。用户OBS存储视频上传视频FunctionGraph获取元数据FunctionGraph转码VOD视频点播转码工作流089云原生 2.0 架构白皮书图 3-19 华为云方案在视频转码场景的优势图 3-20 有状态函数支持更多复杂应用6.有状态函数支持更多复杂应用 当前的 Serverless 方兴未艾,为了能够支撑更广泛应用的开发和运行,还需要解决一
265、系列挑战。函数生命周期有限,已加载的状态无法复用。当前主流的 Serverless 平台对于函数的生命周期都有时间限制,函数不能长时间运行,只能在有限的时间执行,如 900s(15min)。当函数没有新的请求时,函数所在的执行环境被销毁,函数执行的中间状态、缓存等会被删除。当新的函数调用发起时,不能直接利用上次计算的缓存状态。获取元数据转码8CPU分辨率:4K转码2CPU分辨率:480P转码2CPU6CPU分辨率:480P业界方案,默认配置满足极限转码性能低分辨率时产生资源浪费华为方案,用户可动态指定资源规格节点节点外部存储/缓存服务有状态应用无状态函数有状态函数节点Function代码Fun
266、ction代码状态远程读写序列化/通信开销状态本地读写应用代码堆/栈/寄存器Global数据系统Local数据系统状态内存状态本地读写第三章|华为云云原生 2.0 架构设计模式090 数据搬移成本高,影响运行效率。承载业务逻辑的函数在 FaaS 的容器上加载,独立于数据侧(BaaS)运行,函数执行时需要把数据运送到代码处,而不是把代码放在数据所在的计算节点运行。对于大数据、分布式机器学习等场景,数据的搬移开销会影响这些工作负载的运行效率,同时也会给数据中心网络造成负担,这大大限制了 Serverless 的应用范畴。借助于类似 OBS 的对象存储服务,要比点对点通信慢、成本高。为了解决这些挑战
267、,FunctionGraph 推出有状态函数,有状态函数编程模型提供了方便的函数定义方式,以及语言无关的状态定义方式。由于不需要频繁地和外部存储进行交互,减少了网络访问的次数,从而能够获得更低的时延。数据不需要分发到外部存储中,也不需要缓存到其它节点上,在可用性和一致性方面得到提升。由于用户请求与节点存在粘性连接,用户只需和一个函数实例发生交互,存取状态数据更为容易,通常只需要对函数中的一个简单结构体进行操作即可。另外,由于 FunctionGraph 服务接管了状态的管理,可以为用户提供多种数据一致性模型,以及处理并发场景下死锁的问题,从而使得编程模型更加容易理解、用户程序更加简洁。7.对应
268、用无感知的倒换支撑数据库 Serverless传统的数据库部署模式,用户需要先从应用视角规划数据库容量,再根据实际运行情况调整规格,而调整规格往往意味着数据库需要重启甚至倒换,引起应用连接的中断,影响用户体验。而 Serverless 的部署模式只需要用户给定资源的上限下限,让云平台自动根据运行的负载调整实例规格,利用华为云数据库的应用无损透明倒换技术(ALT),规格变更可以实现应用基本无感知。让开发者专注于应用开发,无需关注资源。图 3-21 从“以资源为中心”到“以应用为中心”的部署模式以资源为中心以应用为中心Serverless部署传统部署评估应用访问压力,得出性能评估模型最低规格规划应
269、用容量评估数据库资源购买匹配规格调整规格最高规格升级规格1升级规格n.负载下降负载上升根据性能评估模型检测出数据库资源需求根据数据库资源需求购买响应规格的数据库资源根据应用现网运行情况重新调整规格匹配资源091云原生 2.0 架构白皮书3.3.5 存算分离架构设计模式华为云基于云原生数据湖+云原生数据库底座提供存算分离的一站式数据处理方案。1.计算和存储资源解耦,各自弹性伸缩华为云存算分离方案的实施,计算和存储资源的解耦,可以实现:存储和计算各自按需弹性扩展,通过容器化技术实现计算弹性伸缩,彻底释放算力的流动,实现了资源价值的最大化,更为灵活和可靠的一站式数据处理整体方案,性能超过存算合一方案
270、 20%,整体成本降低 30%。2.云原生云存储能力升级,支撑大数据计算云原生数据湖云存储,基于对象语义能力升级,通过扩展 Posix 文件语义,实现了:高性能 Rename 原子操作,满足 MapReduce 过程中性能诉求。Append、hflush&hsync 支持,完善 HDFS 语义支持,满足流计算场景的接口语义兼容性。图 3-22 华为云存算分离架构HDFSPOSIX数据湖云存储Data Multi-Protocol云容器弹性云服务器裸金属服务器兼容S3第三方大数据AI训练平台华为云大数据MRSDLIModelArtsTensorFlow图 3-23 云原生数据湖云存储对象语义能力
271、升级新增API接口PUT(Modify)POST(Append)POST(Rename)并行文件桶(Posix文件语义)标准对象存储桶OBSFilesystem(HDFS FileSystem语义实现)云存储OBS API(兼容S3)COPYDeletePUTGETPOST第三章|华为云云原生 2.0 架构设计模式0923.数据全生命周期 PipeLine 计算,多协议数据共享采用数据湖底座云存储,支撑 Pipeline 多种计算场景。一份数据多协议共享访问(S3/HDFS/Posix 协议),数据免拷贝,提高了计算分析效率,节省了数据保存成本。图 3-24 PileLine 多集群计算,数据
272、多协议共享访问4.云原生近计算缓存,实现高性能数据计算 IO 加速存算分离后,计算集群从云存储拉取数据进行计算,针对高性能计算场景需要更高性能的存储介质,提升 IO 效率。大数据和 AI 计算场景,通过计算引擎内置分布式缓存,基于内存和 SSD存储介质提升 IO 效率。云原生的近计算缓存,定位于近计算、轻量化、任务感知的高性能智能缓存服务层,通过数据湖 IO 加速,实现大数据&AI 计算场景 1.5 倍的性能提升。关键特性包括:基于内存+SSD 池化,无 NameNode 分布式缓存;利用 RACE Hashing 索引,数据分片多节点并发预取;计算任务感知、文件格式感知等智能数据预取手段;数
273、据预取流量 Qos 控制能力等。图 3-25 云原生近计算缓存SparkSQLFlink流计算数据湖云存储数据入池离线分析计算即席查询计算数仓计算AI计算 KafkaMR任务SparkStreamingHivePrestoImpalaDWSTensorflowCDMOMS本地盘本地盘HDFS协议HDFS协议S3协议S3协议HDFS协议S3/Posix 协议 数据全生命周期3rdPartyMRS/DLIDWSModelArtsOne CatalogCompute Pod云原生近计算缓存数据湖云存储数据预取作业DAG感知File FormatMem/SSD 池化093云原生 2.0 架构白皮书5.
274、近数据计算存储卸载技术,实现数据计算加速存算分离后,计算集群到云存储之间,网络带宽需求膨胀,如:中等规模的计算集群(如:5万计算核)需要 Tbps 级网络带宽供给,网络成本增加。采用 OBSSelect 存储卸载技术,大数据服务和云存储通过云原生的垂直优化,实现网络带宽消减 30%,计算性能提升 20%。关键特性包括:文件 schema 感知(Json、CSV、Parquet)、Projection/Filter/Aggregation 的类 SQL 算子卸载云存储近数据计算。图 3-26 OBSSelect 存储卸载技术利用云原生数据库云存储 DFV 基于存储算子语义下推能力,支撑事务处理算
275、子的并行下推。计算层可以通过并行处理分片下推数据库要处理的语义到存储层,存储层也能够理解数据库语义,进而在存储层并行地预处理数据库的算子。比如范围查询,存储层可以在确保事务隔离性、数据一致性的前提下过滤掉不需要的数据,直接把命中的行返回到计算层,避免计算层和存储层无意义的数据交互。存储层支持日志回放能力,数据库写节点无需把数据页面写到存储层,只需要把日志写到存储层,存储层可以将日志回放为数据页面,并在多副本上提供一致性版本给其他节点访问,进而节省计算层和存储层的高速网络带宽。图 3-27 GaussDB 存算分离+数据库逻辑下推架构NetworkObjectSelect firstName,l
276、astNameFrom tablePeopleWhere country=“China”;BaselineNetworkObjectOBSSelectData movementData movementEntireObjectObjectSubsetSelect firstName,lastNameFrom tablePeopleWhere country=“China”;架构更优SQLNodesStorageNoder简单的计算存储分离ReplicaDataServerA b cDataServera B cDataServera b CMasterRDMA(Storage Network)
277、ReplicaStorageNoderGaussDB计算存储分离+数据库逻辑下推RDMA(Storage Network)SQLNodes内置深度整合DB插件ReplicaSALModuleSALModuleSALModuleMaster分布式存储池Replica第三章|华为云云原生 2.0 架构设计模式0946.云原生统一元数据,实现多计算引擎共用一份数据存算分离后,当大量业务访问一份数据使用时,常常遇到并发写入、并发查询、修改Schema 等并发需求。由于不同业务使用的计算引擎不同,也带来了跨引擎使用一份数据的需求。而基于传统存算合一的 Hadoop 生态组件,其创建之初并没有考虑众多引擎
278、的并发访问,所以为大数据和 AI 计算引擎统一元数据,并支持并发事务型操作,变得越来越急迫。采用云原生统一元数据方案,实现了多个计算引擎并发共用一份数据。其具备如下特点:兼容 Hive Meta Store,计算组件可无缝对接统一元数据,可按需将原有表格迁移新的元数据管理系统。对已有的 Hadoop 生态组件无侵入式修改,通过配置即可支持使用新的统一元数据。基于可扩展的 KV 存储实现大规模元数据存储和并发访问,访问性能与表格个数、分区个数、数据量大小无关。支持结构化表格、半结构化数据、非结构化数据、AI模型等多种数据实体的元数据存储和处理。所有元数据操作都支持事务和版本管理,对表格数据可实现
279、任意版本恢复、回退。支持插件式扩展元数据功能,例如通过插件可增加数据鉴权、数据共享、数据画像、数据脱敏等功能。3.3.6 数据治理自动化架构设计模式进入 AI 时代后,数据类型越来越多,业务要求越来越实时化,传统 Hadoop 生态组件做数据管理有较高的门槛,基于人工管理的成本越来越高,越来越难以适应业务的要求。企业迫切需要一种新的方式来管理海量数据,将数据从“资源”变为“资产”,真正帮助业务实现以实时数据驱动的智能决策。数据智能基础设施 Data Intelligence Infrastructure(DII)是华为云面向云原生 2.0 自动数据治理平台打造的全新平台,其基于华为云智能数据
280、AI for Data 引擎,构筑覆盖数据入湖、数据准备、数据目录管理和数据洞察的全流程自动化能力,极大提升企业数据治理效率,帮助企业快速洞察数据价值。095云原生 2.0 架构白皮书1.数据集成服务DII 全新构建的数据集成服务支持一键式数据入湖能力,无需过多的手工配置,自动完成数据的入湖存储,满足全量迁移,定时增量迁移,实时迁移等多个场景。基于华为云 AI for Data Engine 智能数据引擎,支持在数据迁移入湖过程中,自动进行隐私数据发现和标注,自动脱敏和水印。并且还具备数据爬虫功能,自动发现半结构化数据的元数据 schema 信息,并统一存入Data Catalog 中。入湖数
281、据统一存储在华为云 OBS 对象存储服务中,支持 parquet、hudi、ORC CarbonData 等多种开源格式,方便多种数据分析引擎使用。图 3-28 数据智能基础设施 Data Intelligence Infrastructure(DII)图 3-29 DII 数据集成服务一键入湖2.0数据目录2.0依赖的云服务Auto ML权限管理实时同步入湖爬虫数据图谱元数据存储搜索引擎AI引擎特征工程模型训练模型评估模型服务联邦认证数据权限资源权限全量增量入湖自动扩缩容数据准备2.0数据理解数据转换数据质量数据洞察2.0Daas engineML insight智能分析No code工作台
282、智能ETL推荐自动ETL流水线特征提取实体合并智能打标脱敏OBSMRS元数据存储DLIDAYU-DGCIAM.数据湖存储OBS业务数据库文档上传VPC增量迁移CC实时迁移公有网络VPCEP一键迁移Data CatalogAI for Data Engine消息第三章|华为云云原生 2.0 架构设计模式0962.数据准备服务 AutoETLDII 的 AutoETL 服务为数据科学家、业务分析师提供 no code 的可视化数据准备能力。AutoETL 提供数据流推荐交互界面、托拉拽可视化交互、运维管理页面、调度引导配置、资产发布与可视化呈现界面。类 Excel 的数据准备智能交互方式,基于 A
283、I for data module 的数据预览、数据剖析、schema mapping、算子推荐等能力实现数据准备引导式交互界面。数据质量评估:支持常规数据质量检测,支持基于质量异常检测算法,自动展示质量评分、修复建议。智能数据清洗:基于 AI for data module 的算子推荐实现转换与清洗。数据丰富:基于湖内外标准数据集,通过关系挖掘实现对数据内容的丰富以及数据schema的补充。数据发布:支持新建 Schema,自动实现 Schema 关联,字段信息推荐,比如业务名称、标准、密级、分类、标签等内容的推荐。AutoETL Studio:提供托拉拽可视化交互界面,支持表关系推荐,转换
284、算子推荐,数据准备pipeline 自动生成与运维管理,支持版本管理,数据血缘生成,支持数据流推荐。图 3-30 AutoETL Studio3.数据目录服务 Data Catalog基于华为云在线元数据管理引擎,为企业构建统一的元数据管理中心,统一管理数据湖元数据、业务元数据、dashboard 元数据、ML 数据特征、sample data 等各类数据资产。数据湖 Catalog:数据湖的元数据统一采集,支持 Schema 自动解析,支持注册 DWS、Mysql、ES 等外部数据源,提供兼容 Hivemetastore 的查询接口;数据湖元数据和计算引擎元数据支持秒级同步。数据理解迁移数据
285、洞察2.0Data samplingData previewData profilingFeature extractSchema buildingMetric building数据发布数据转换数据质量数据丰富AutoETLpipeline097云原生 2.0 架构白皮书 元模型管理:支持用户自定义元模型,自定义采集适配器,支持内置元模型扩展属性。数据关系图谱:自动解析发现元数据之间的深度关系,包括血缘、主外键、logical-physical、parent-child、数据标准、分级、分类、主题目录等,以知识图谱的形式呈现。数据湖库表统一权限管理:支持库级、表级、列级、行级权限管控,支持权限
286、有效期。数据目录权限管理:通过 access control 控制元数据和数据的访问权限。智能数据搜索:所有资产均可搜索,支持搜索+过滤,自然语言搜索,相关度机器学习排序,基于用户特征的资产推荐等。图3-31 数据目录服务Data Catalog4.智能数据洞察引擎服务 DaaS Query Engine基于华为云智能数据 AI for data 引擎而构建的 Data as a Service 能力,提供搜索体验的数据洞察能力,通过简单的搜索输入,系统即可提供可视化的数据洞察、根因分析、数据预测、图表推荐、自动数据故事生成等,帮助用户发现数据中隐藏的价值。自然语言交互式分析:用户通过自然语言
287、输入查询或所需报表内容,基于规则化或模型完成到 SQL 语义转化。通过转化后的语义查找 DII 数据目录元数据生成 Query SQL,并基于用户的语义理解从 Data Lake 中发现所需数据。报表智能分析、设计和应用发布:支持数据片段和数据点的智能根因分析,关联指标及图表推荐,多维下钻。支持不同粒度下手动托拉拽+提醒引导式的数据智能洞察和报表智能设计。提供全局(数据集)的报表内容洞察和单一图形的智能分析、图表推荐,设计完成的报表形成仪表盘发布。针对某些业务场景的工作区可以整体打包成应用发布。智能洞察(ML Insights):支持从单维到多维的数据洞察,提供时序智能异常检测、预测、告警能力
288、;支持数据根因探索,例如异常点贡献因素分析、预测值特征重要度分析等。元数据采集权限管理数据特征解析元模型管理数据图谱元数据目录HMS API搜索API图分析API权限APIConsole数据目录HMSElasticsearchGraphDB第三章|华为云云原生 2.0 架构设计模式098 智能图表设计:基于用户数据配置或者自然语言提问方式,自动推荐包括:最适合的图形组件,多视图下报表整体布局,配色一致性,基于见解的自动故事生成。图 3-31 智能数据洞察引擎服务 DaaS Query Engine5.智能数据增强管理技术辅助数据洞察,提升 BI 分析效率基于智能数据增强管理技术的 Data a
289、s a Service 能力,提供搜索体验的数据洞察能力,通过简单的搜索输入,系统即可提供可视化的数据洞察、根因分析、数据预测、图表推荐、自动数据故事生成等,帮助用户发现数据中隐藏的价值。关键特性包括:自然语言交互式分析:用户通过自然语言输入查询或所需报表内容,基于规则化或模型完成到 SQL 语义转化,并基于用户的语义理解从 Data Lake 中发现所需数据。智能洞察(ML Insights):基于智能增强管理技术,自动数据归类统计和洞察,支持数据根因探索和数据预测。6.数据生命周期管理自动化,自动入库、自动合并、自动清理云原生数据湖采用数据生命周期管理自动化技术,降低数据管理的门槛,无需编
290、程,使用纯SQL 方式使企业数据管理员轻松管理数据,实现如下能力:对如 App 埋点日志、IoT 数据等实时流数据,实现无间断的自动入湖。对于 JSON 数据,在入湖期间支持自动 Schema 推断和自动 Schema 变更。基于数据统计,可自动触发 Compaction 任务合并小文件。基于使用统计,可自动触发建索引任务,加速业务查询。根据用户配置的数据老化规则,可自动触发数据清理任务,节省存储空间。数据集报表智能分析&设计仪表盘(ML)InsightsLineage发布图表设计引导式拖拉拽1.通用分析模块2.智能见解模块TS,Geo3.根因探索模块4.关联指标联系模块1.智能图表推荐模块2
291、.智能布局配色模块3.见解自动故事生成参数设置自然语言输入语义转化Query SQL获得数据DaaS Query EngineApps数据资产发现工作区/应用业务099云原生 2.0 架构白皮书在统一元数据的基础上,根据用户配置的数据生命周期管理规则,云原生数据湖会自动触发一系列的数据管理任务,以Serverless的方式自动执行,将用户从繁重的数据管理任务中释放出来,用户只需聚焦自己的数据分析业务。3.3.7 基于软总线异构集成的架构设计模式1.融合集成平台 ROMA Connect 功能架构 FDI:支持多种异构数据源灵活转换,入湖,入库能力集成 DRS 和 CDM;APIC:实现 API
292、 全生命周期管理;MQS:支持消息中间件接入,前后端应用无感知;设备集成:支持标准 MQTT、MQTT Client SDK、软/硬网关、OPCUA、Modbus 等各种协议与设备数据接入;FDI、APIC、MQS 和设备集成之间也可以自由组合形成多种集成解决方案;ABM:构建业务元数据模型;Compose:基于业务模型,通过业务规则,构建业务过程,实现应用聚合;图形化业务流编排:代码可视化集成,快速完成端边云应用集成。图 3-32 华为云融合集成平台 ROMA Connect数仓/数据湖企业SaaS应用设备消息服务MDMDWIEFIESHCS 8.0公有云HCHCSO财务营销PLMERPME
293、S企业应用大屏应用视频应用移动应用GIS应用SaaS服务合作伙伴业务仓库物流供应商ROMA connect(混合云)ROMA Site(边缘)企业资产汇聚、沉淀集成应用 Cloud应用、Legacy系统连接器 协议对接插件API、MQ 各类标准化接口业务流 集成关系业务编排(Compose)集成流(Flow)业务对象模型构建模型映射模型管理应用业务对象(ABM)应用与数据联接数据集成(FDI)消息集成(MQS)服务集成(APIC)设备集成业务联接ROMA Connect(融合集成平台)任务监控数据转换任务管理读写插件任务调度多通道消息轨迹运维可视Topic管理消息延时发布订阅消息重发多语言SD
294、K多协议转换策略路由秒级流控环境管理服务编排协议转换设备状态报警信息规则引擎TLS加密传输多IoT对接模型联接函数计算编排引擎规则引擎第三章|华为云云原生 2.0 架构设计模式1002.基于 ROMA Connect 将传统非云原生应用封装为 REST 接口与云原生应用对接如图展示了融合集成平台的设备集成、消息集成、数据集成、API 集成等能力,将设备、传统非云原生应用、第三方应用的数据集成至数据库、EI 平台、数仓等系统,最终通过融合集成平台的统一接口服务层 APIC 进行开放,业务云原生应用通过标准接口即可获取老系统的信息。图 3-33 融合集成平台架构3.传统 Oracle/Sybase
295、 等数据接入上云传统数据一般在云下,与云上网络不互通,此时通过融合集成云边协同完成数据上云。云上云原生应用通过云上标准 API 调用、数据库访问、消息订阅等方式即可获取传统数据。(注:如果云下通过专线、VPN 等方式与云上网络互通,则融合集成平台边缘形态不是必选项。)图 3-34 传统 Oracle/Sybase 等数据接入上云应用层融合集成平台统一接口服务层APIC数据运营平台(DAYU)数据集成数据规范数据开发数据质量数据资产数据服务汇聚层明细层贴源层三维组态系统多维分析系统AI创新业务云原生应用传统非云原生应用数据仓库DWS第三方应用设备1工业网关EI平台ModelArts设备NEMQ(
296、MQTT 消息服务器)MQTTKAFKA(分布式消息队列)Jstorm(流处理引擎)OBS(数据归档3个月)RDS(mysql)内部外部API(服务接口层)数据归档Stream/Flink融合集成平台历史OT数据备份OBS(IT)OBS(OT)以外表关联查询OT归档OT查询消息集成MQSERP财务系统CRM资金系统eHROA数据集成FDIAPI集成Spark消息集成MQS融合集成平台-lOTOT实时OT实时工业网关(IIG500/1000/3000)设备1DCS/PLC/上位机设备NDCS/PLC/上位机数据集成与计算平台(MRS)云原生应用方式二:数据库访问方式三:订阅子消息云上数据库API
297、CAPI托管数据定时或实时集成数据集成FDI消息集成MQS传统数据APICOracleSAPMysqlRedisSQL Server消息集成MQS数据集成FDI路径1方式一:标准API调用云上内部数据ROMA Connect边缘形态ROMA Connect101云原生 2.0 架构白皮书4.企业多分支集成大型政府机构和企业的复杂网络环境,要求能够跨云、跨网的方案应用、数据和服务;政企需要一种安全、可靠、高效的连接方案,在不打破组织安全边界的前提下,进行跨组织的API、数据、消息协同;在跨网过程中,不同业务方无需进行定制化对接适配工作,全程无感知。即可实现协议的转换和数据的可控性交换。融合集成平
298、台通过公有云、混合云、边云多种部署形态协同,跨云跨域集成,构建应用一张网,全网级联,多种能力组合完成企业多地数据共享数据交换。图 3-35 企业多分支集成一级中心(集团)ROMA ExchangeROMA Connect应用资产(软件包/镜像)服务资产(App API)运营中心(IOC)定价管理集成资产(南向集成)数据资产(LiveData API)服务质量客户分析二级分支1(省网1)数据源 库表消息文件数据湖MRSDWS接入FDI+MQSROMA Factory应用开发应用开发应用托管应用运维应用APP微服务APIROMA Connect 数据FDI 消息MQS省级应用1省级应用2API(A
299、PIC)集团应用系统1系统N消息MQS管理面MGR数据FDI管理面MGRAPI(APIC)三级分支1(市/县/边缘)ROMA Site本地数据应用数据库容器IEF底座消息MQS数据FDI设备MQTTAPI(APIC)二级分支2(省网2)融合集成平台级联数据源 库表消息文件数据湖MRSDWS接入FDI+MQSROMA Factory应用开发应用开发应用托管应用运维应用APP微服务APIROMA Connect 数据FDI 消息MQS省级应用API(APIC)管理面MGR三级分支N(市/县/边缘)ROMA Site本地数据应用数据库容器IEF底座消息MQS数据FDI设备MQTTAPI(APIC)3
300、.3.8 可信、平民化 DevOps 架构设计模式 1.合开发能力、运维能力与安全能力的 DevSecOps 平台DevCloud:DevOps 工具链,包括 CloudIDE、项目管理服务、代码托管服务、流水线服务、代码检查服务、编译构建服务、云测服务、移动应用测试服务、部署服务、发布服务;第三章|华为云云原生 2.0 架构设计模式102图 3-36 华为云 DevCloud2.基于 AppCube 的界面定制1)多种页面类型支持标准页面:标准页面是一种将一个或多个组件拖进画布,进行低代码甚至无代码的配置,即可快速完成业务功能的前端页面。对于一般的业务应用系统,例如绩效管理、请假电子流、出差
301、报销、在线投票等企业常见业务场景,其功能主要是针对业务数据的增、删、改、查,且前端界面的样式相对简单的页面。标准页面提供了丰富的组件,组件包含了预置的样式,并封装了基础事件代码,实现了开箱即用,避免重复写样式和事件代码,陷入代码细节,使开发人员更好的专注于业务场景的挖掘。高级页面:对于一些样式比较复杂的页面,例如网站、电商、园区大屏等,您可以使用平台提供的“高级页面”。业务大屏页面:业务大屏页面即 DMAX 大屏页面,业务大屏页面可以帮助开发者快速构建和发布专业水准的实时可视化大屏页面。可广泛应用于政府、商业、金融、制造等行业的业务场景中。CICD流水线DevOps工具链(DevCloud/A
302、OM)安全工程能力服务化安全技术服务化(SecDev/AAD/SA)DevSecOps开发阶段安全度量/安全看板安全设计服务隐私合规服务代码安全服务安全测试服务安全运维服务运行阶段安全度量及生态感知安全标准、规范、最佳实践需求计划安全设计与合规协同编码构建部署发布托管治理编码安全检查日志监控攻击发现响应运维压测、接口测试安全测试漏洞扫描安全应用开发框架API安全开发框架安全开发组件IDE检查门禁检查源码已知漏洞检查.API安全测试Web漏洞扫描安卓应用扫描系统漏洞扫描.隐私分析隐私声明隐私设计方案库.威胁建模威胁库安全设计.态势感知DDoS高防主机安全安全响应.AOM:运维平台,包括 LTS
303、日志服务、AOM 监控告警服务、APM 应用性能服务;SecDev:安全开发服务,包括安全设计服务 SecDesign、隐私合规服务 SecPCP、代码安全服务 SecSolar 以及安全测试服务 SecScan;同时也集成了安全运维服务态势感知服务 SA、DDos 高防AAD 等。103云原生 2.0 架构白皮书2)丰富的组件能力AppCube 基础组件覆盖了全部的标准 W3C HTML5 表单组件,包含:文字组件:单行文本域、多行文本域、密码域、日期域、数字域、范围域、颜色域、搜索域。列表组件:Select 组件、DataList 组件。选择组件:Radio、Checkbox。按钮组件:提
304、交按钮(submit)、重置按钮(reset)、普通按钮(button)。AppCube 具备适配企业业务的高级组件,包含:高级控件:函数公式、自动编号、身份证件、手机号码、地理定位、手写签名、文本识别。关联控件:关联记录、子表、他表字段、级联选择、汇总。企业相关:部门选择、角色选择、人员选择、群聊选择、云盘附件。AppCube 提供自定义组件和组件属性的能力 平台内置常用的 JS 库,开发者可以基于 JS 库开发组件上传到平台。平台同事支持开发者通过引用第三方库的方式在降低组件开发的复杂度的同时丰富组件的功能。平台支持自定义组件的一些属性,可以在用到该组件的页面中根据具体的场景配置这些属性值
305、。3)强大的布局能力,支持常见的 Web 页面布局,适配多终端展示 支持静态布局,常用于 IOC 大屏页面开发。支持流式布局,流式布局为 12 列栅格布局,可拖动组件右侧边界按栅格进行组件宽度调整,组件高度将根据组件内容进行自适应,页面中组件将按照从左到右、从上到下的顺序依次排列。支持响应式布局,组件的响应式设计是页面适配多终端的重要前提。多种布局组件:包含栅格、分栏、容器、表格、弹层、IFrame、JSX 等多种组件。3.基于 AppCube 的服务能力编排的业务流程无代码定制1)灵活的流程触发方式 表单实例创建、修改、删除触发 API 调用触发 用户手动触发 定时触发 自定义事件触发第三章
306、|华为云云原生 2.0 架构设计模式1042)基于BPMN2.0规范的流程节点,可以设计出多分支、多规则、多权限、多处理的复杂业务流程,满足企业业务的全流程闭环 活动:用户任务、调用脚本、调用服务编排、规则决策表、邮件发送、数据映射、子流程/活动。事件:开始、抛出信号、捕获信号/时间、结束/终止。网关:排他网关、并行网关、事件网关。3)多种权限配置方式 支持部门、角色、人员、自定义分组等维度来划分权限。支持数据创建、修改、删除、查看、列表、打印、分享等多种操作权限赋予。支持数据集、数据行、数据列、自定义规则等途径对数据进行敏感保护。4)自定义的业务编排 托拉拽式编排流程:以往的传统编程,需要进
307、行变量的声明并编写相应逻辑代码进行服务的开发。使用服务编排进行服务开发,能够通过托拉拽的方式,将配置项创建的变量以及服务编排中提供的各种功能进行编排,并以流程的方式将服务所要实现的功能展现出来。整个开发过程中无需进行代码的编写,简单快捷,并能够图形化展示服务的逻辑。逻辑处理:服务编排中提供了逻辑处理的图形化元件,包括赋值、循环、跳出循环、决策和等待。通过这些图元能够实现基本的逻辑处理,并图形化展示,便于开发者理解。5)对象处理服务编排中提供了对象处理的图形化元件,包括记录创建、记录查询、记录更新和记录删除。通过这些图元能够对通过平台创建的自定义对象或标准对象进行相应的增、删、改、查操作,简化处
308、理对象数据的流程,提高开发效率。6)服务单元组合脚本、原生服务、BO、第三方服务服务编排中提供了服务单元组合的图形化元件,包括脚本、子服务编排、原生服务、BO 和连接器。通过这些图元能够将平台中已开发完成的服务集成到服务编排中,并重新进行组合,快速扩展出更丰富的业务功能。105云原生 2.0 架构白皮书3.3.9 多模态可迭代行业 AI 架构设计模式华为云面向 AI 主要提供底层的 AI 训练平台以及上层的面向各行各业的 AI 应用。底层 AI 平台是华为云 ModelArts 服务,上层 AI 应用是华为云知识计算服务。3.3.9.1 华为云普惠 AI 开发平台:ModelArts 1)面向
309、 AI 开发的 ModelArts IDE软件开发的历史,就是一部降低开发者成本,提升开发体验的历史。在 AI 开发过程中,ModelArts 也致力于提升 AI 开发体验,降低行业 AI 开发门槛。ModelArts IDE,为不同类型的AI 开发、探索、教学用户,提供更好的云化 AI 开发体验;更近一步接入优质 AI 开发内容,提供基于算法外壳+套件的算法开发方式和基于 ModelBox 的应用开发能力。将 On Cloud AI 开发演进为 In Cloud AI 开发。ModelArts IDE作为统一的AI开发解决方案,是由多个工具和服务组成,面向不同开发者场景,提供不同的解决方案。
310、1.ModelArts Studio 一站式 AI 开发线上(Web)入口针对于 AI 数据、算法探索、特征分析、模型训练评估等场景,提供一站式的 AI 实验开发与管理的能力。ModelArts Studio 基于 JupyterLab 底座,通过丰富功能扩展插件来打造,延续了类似 Notebook 的交互习惯,增加了额外的云上 AI 开发能力与管理功能。利用云上 AI 计算资源完成算法代码的交互式调测,迎合 Notebook 生态,便捷的运行和管理Notebook;云上开发主入口,方便的上传数据,模型训练、调优、评估、转化以及搜索等步骤的执行、管理与可视化;集成 ModelArts 基于算法
311、套件的算法开发能力,接入官方以及开源算法套件内容,高效的完成算法探索。2.ModelArts CodeLab 云原生 Notebook 服务针对 AI 探索、教学、快速实验场景,提供云上 serverless 化的云原生 Notebook 服务。免费算力:包含 CPU、GPU 和 Ascend。开发者可以使用免费规格,按需进行使用规格切换,端到端体验 ModelArts Notebook 能力。也可使用此免费算力,在线完成您的算法开发。即开即用:serverless 化资源管理,无需创建 Notebook 实例,打开即可编码,自用自动释放。高效分享与协作:ModelArts 官方提供的 Not
312、ebook 样例,一键即可打开 CodeLab 学习样例第三章|华为云云原生 2.0 架构设计模式106代码,也提供 Notebook 分享的功能,方便的讲自己的 notebook 分享给其他开发者完成实验内容复现。3.ModelArts Studio extension for PyCharm and VSCode 本地 IDE 远程开发能力针对 AI 算法或者 AI 应用中,需要进行深度代码开发与调测的场景,例如工程化代码开发与调测、算子开发与调测等,提供 PyCharm 和 VScode 插件,直接连接云上 AI 开发容器实例,完成远程代码开发与调测。高效代码调测:延续深度代码开发用户的
313、开发使用习惯,利用本地 IDE 代码开发、工程管理的能力,更高效的完成代码开发与调测。云上云下协同:本地 IDE 插件与云上资源进行联动,在 Web 入口无法高效完成工程化代码调测功能时,能够低成本的进行使用方式切换,开发内容一致。AI 算法开发能力:在 IDE 中集成 ModelArts 算法外壳,利用 ModelArts 提供的算法套件,以及接入定向适配的开源套件,完成工程化算法开发与探索。AI 应用开发能力:在 VScode 通过插件提供基于 ModelBox 的 AI 应用开发能力,包含 AI 应用开发工程,结合 ModelBox 提供的预置流单元完成 AI 应用开发与调测。图 3-3
314、7 ModelArts Studio extension for PyCharm and VSCode2)面向 AI 项目管理与迭代的 ModelArts Workflow在云原生 2.0 时代,如何实现普惠 AI,需要解决迭代效率的问题。AI 项目在落地过程中,端到端的流程包括项目设计、数据工程、模型构建、模型训练、模型评估和部署落地。传统交付一ModelArts插件ModelArts IDE插件管理底座ModelArts-SDK本地IDE底座(VSCode、PyCharm)本地IDE+插件开发环境管理面边侧设备、一体化大数据资源DLI、MRSMA资源池第三方资源纳管K8s operator
315、远程开发(ssh)httpsHilens.定制化插件2定制化插件n社区商业化插件工具ModelArts插件ModelArts Notebook插件管理底座ModelArts-SDK线上IDE底座(JupyterLab)ModelArts-StudioMLStudio.AIFlow定制化插件n社区商业化插件工具ModelArts-IDE(IDE底座+ModelArts插件)Integrated development environment(IDE)for MLModelArts-Fundamental107云原生 2.0 架构白皮书个 AI 项目,都是直接交付一个 AI 应用。当出现数据漂移的
316、情况时,需要相对应的算法人员、测试人员等重新介入迭代模型。这种流程非常消耗人力。MLOps 是一种机器学习工程文化和做法,其统一了机器学习系统开发和系统运营。参照DevOps 的概念,DevOps 使软件的维护工程化、例行化、专业化。AI 应用的维护也需要工程化、例行化和专业化。在迭代过程中,通过固化已有的流程构造工作流,针对场景中的数据样本增加数据量,提高数据标注的一致性,输入到工作流中迭代训练定期调整模型。ModelArts Workflow 是专为 MLOps 功能提供的工具。借助 Workflow 和账号管理体系,用户可以在 ModelArts 上开发基于实际场景的 MLOps 工作流
317、。workflow 就是针对某个 AI 项目的解决方案。在 AI 项目中会有不同角色的参与,基本角色有项目 PO、数据科学家、算法人员、集成&验证和运维人员等;相对应的 workflow 也有开发态和运行态。图 3-38 AI 项目的端到端流程项目设计数据工程模型构建部署落地需求收集场景设计明确问题边界定义数据收集数据数据标注数据可用性检查数据工程算法开发模型训练模型评估迭代优化应用集成应用部署模型监控系统运维图 3-39 ModelArts Workflow 数据AI 应用数据处理模型开发模型训练模型评估应用开发应用评估AI开发数据处理模型训练应用构建应用部署迭代优化第三章|华为云云原生 2
318、.0 架构设计模式108用户可以基于 ModelArts 提供的 Workflow SDK 和低代码的开发工具 Studio,开发相应的Workflow。基于不同的实际场景,开发者可以自己定义每一个步骤的实际业务属性和操作。实际业务属性包括步骤的输入输出、依赖的步骤、需要用户操作的参数等。通过 ModelArts Studio 的低代码可视化开发工具,让用户更轻松地进行模型和流程开发。在 Workflow 运行时提供可视化的操作界面,提供给使用者一个只需要关注迭代优化的工具。开发者完成工作流的定义后,发布到项目中,即可提供给使用者进行使用。使用者无须关注每个步骤是如何实现的,背后使用了什么算法
319、逻辑,只需要关注开发者定义的评估指标是否符合当前业务上线标准,当不符合标准的时候,更新数据进行应用模型迭代。针对整个开发的流程,通过定义步骤的属性来定义 AI 项目工程的流程。结合 ModelArts 账号体系,实现基于单/多项目场景多人开发&迭代,不同步骤多人开发&管理功能。3)面向 AI 生态社区培育与建设的 AI GalleryAI Gallery 是为 AI 初学者,算法工程师,数据科学家量身打造的 AI 开发生态社区。围绕着 AI学习、AI 开发、AI 落地三大环节,构建“学徒专家”“资产建模”“建模推理”的供需桥梁,通过体系化的 AI 内容、多样化的 AI 资产和场景化的 AI 方
320、案,实现 AI 学习有指导,AI 开发更高效,AI 落地零门槛。图 3-40 AI Gallery AI 学习:主要是面向 AI 学徒,AI 专家两类用户。AI 学徒能够在 AI Gallery 上获取围绕 AI 相关的课程、论文、文章等内容知识,并从中学习成长;AI 专家能够在 AI Gallery 上贡献各种优质内容,并得到相应的荣誉和收益。区别于其他的社区内容,AI Gallery 的课程、论文等内容体系,关联嵌入可基于实际环境动手实践的AI资产,例如数据集、Notebook代码样例等。AI企业,高阶开发者企业/个人开发者AI专家,AI教育培训机构行业客户企业/个人开发者AI学徒供需AI
321、 Gallery提供AI内容,获取收益、荣誉。使用AI内容,获取能力进阶提供AI资产,获取收益、荣誉。使用AI资产,提高AI开发效率提供AI案例,获取收益、荣誉。使用AI案例,解决业务问题AI学习AI开发AI落地AI方案(面向场景化交付的AI解决方案)AI内容(围绕AI相关的课程,论文,文章等)AI资产(AI开发到落地过程中的成果物,如数据集,算法,模型等)109云原生 2.0 架构白皮书 AI 开发:主要是面向具备一定 AI 开发能力,能够基于数据集,算法、模型、工具等 AI 资产完成 AI 建模的各类开发者。AI 开发者们可以分享和复用 AI 开发过程中的各类 AI 资产,例如数据集、算法
322、代码、预训练模型、镜像,工具等,来提升自身的 AI 开发能力和效率。各类AI 资产,可基于业务场景,通过组合、集成等方式构建覆盖端到端环节的 AI 解决方案。AI 落地:主要是为对 AI 应用落地有诉求,但自身 AI 开发能力相对薄弱的各类行业客户提供其所需的 AI 方案。具备 AI 能力的企业、高阶开发者等,可以作为 AI 能力的供应方,提供基于场景化交付的AI方案,帮助AI能力的需求方,实现AI应用的快速落地,解决实际业务问题。围绕场景化的方案,通过不同行业、不同领域的打磨,可以沉淀为丰富的案例库,实现 AI 经验和知识在不同业务场景下的复用。AI 资产是 AI Gallery 的核心。A
323、I 平台 ModelArts 的数据管理、训练管理、模型管理等模块类似于“生产线”,AI 开发者们在这里生产出数据集、算法、模型等各类 AI 资产;然后可以将自己生产出来的资产发布到 AI Gallery 的“资产集市”进行免费分享或者商业售卖。其他的开发者们可以来到资产集市搜索查找自己想用的 AI 资产,找到后,可以便捷获取并一键运行在 ModelArts等底座平台上。图 3-41 AI Gallery 与 ModelArts 协同当前 AI Gallery 已支持数据集、Notebook 代码样例,算法、模型、Workflow 工作流、套件等多种类型的 AI 资产,积累沉淀 6W+资产。通
324、过构建 AI 生态链上的供需桥梁,未来将吸引更多伙伴和开发者共建共享一个繁荣的 AI 生态社区。发布订阅数据准备代码调测实验管理模型评估模型注册部署管理ModelArts发布者订阅者AI资产数据算法模型Notebook工作流AI学习AI落地AI开发AI Gallery创建AI资产使用AI资产第三章|华为云云原生 2.0 架构设计模式1103.3.9.2 华为云知识计算与多模态 AI1)知识计算架构当前,AI 主要基于海量数据完成建模、求解与应用。然而现实中,人类在解决各类问题时,通常会基于对数据的观察,结合所学知识进行思考,进而做出决策。在此过程中,知识是人在解决复杂问题时,做出判断、推测的重
325、要依据。基于这一特点,很多学者提出 AI 系统需要结合知识来解决复杂的问题。在数字化转型过程中,企业积累了大量的知识,比如专家经验、生产系统中的机理模型、行业标准、技术文献等,这些知识以多种形态存在于各行各业,承载了诸如场景属性、业务流程、数据特征等信息,蕴含着宝贵的价值。将行业知识与 AI 有效的结合,可以解决 AI行业应用过程中的诸多问题,帮助 AI 以更高效的方式落地。当前人工智能正在向第三代迈进。相比数据驱动的人工智能,第三代人工智能试图将人类对世界的认知转换为知识这一要素,参与到人工智能模型的计算中,帮助模型提升鲁棒性和可解释性。知识与人工智能的结合,为 AI 行业落地提供了新的思路
326、,也为加速行业智能化指明了潜在的方向。知识和 AI 的结合主要体现在三个方面:行业知识赋能 AI 建模、行业知识帮助 AI 模型高效求解、行业知识保证 AI 应用持续可靠。图 3-42 华为云云原生知识计算框架111云原生 2.0 架构白皮书如上图所示,华为云知识计算框架主要包括知识层、模型层和算子层。知识是知识参与计算的底层基础,是人类在实践中认识客观世界(包括人类自身)的成果。参考哲学、心理学对知识的分类,通常以事实性知识、概念性知识、程序性知识以及元认知知识等形式呈现。行业生产活动所沉淀的知识可被归于其中,包括生产日志、手册、经验、流程等。例如,生产中的基本元素属于事实性知识、生产流程属
327、于程序性知识、机理模型属于概念性知识。模型是知识参与计算的载体,刻画行业知识并有效参与计算。由数学模型刻画的知识,可以通过数值计算、符号计算等方式来求解,是可以有效参与计算的知识。常用的数学模型包括代数方程模型、微分方程模型、统计模型、图模型等,例如知识图谱可以通过图模型来构建,石油勘探的测井环节中的伽马射线通量计算模型属于一种微分方程模型。算子是知识参与计算的手段,是一种机器对知识进行建模和求解的操作。让知识参与建模和求解的过程中,机器进行的操作即为知识计算算子。算子可以规范化为两类:建模算子和求解算子。建模算子聚焦在将数据转换成可计算的模型,求解算子聚焦在利用 AI 技术对模型进行高效、精
328、准求解。通过对知识计算框架中算子的使用,可形成搜索、推荐、预测、优化、正演、反演等行业应用。例如,知识可以提升预测准确率,实现更智能的行业应用:在政务“一网统管”中,构建工单多维度分析知识图谱,落地智能工单智能分拨、疑难工单识别、敏感事件预警应用;在交通调度场景中,落地实时路况分析、公交调度等应用。知识在正演、反演中同样起着重要作用,例如在能源行业,通过数据正演解决小样本问题,通过反演解决测井油气层识别、地震层位解释等问题,实现“提质增效”和“增储上产”。2)多模态 AI 架构传统的 AI 主要侧重某种特定信号的处理,比如计算机视觉领域的视觉信号、语音信号处理领域的语音信号、自然语言处理领域的
329、文本信息等。但是现实生活中人所接触的信号是各种各样的,不仅仅限于某一个种类的信号,如在城市治理工作中,涉及数据种类多:位置、社会关系、网络行为,以及大量非结构化数据如语音通信、视频人脸、案件存档等。运用 AI 技术可以对非结构化数据挖掘,自动建立非结构化数据与结构化记录关联。如在视频分析中会涉及语音、文本、图像信息。多模态分析设计多模态识别和多模态生成。多模态 AI 主要涉及的技术点包括表示、映射、对齐、融合以及协同学习。表示是指如何表示各个模态的特征,比如语言是符号表示,而音频和视频是连续的信号表示。这两类表示如何统一的有效表示为计算机可以理解的表示信息是一个关键技术。映射是指不同的模态之间
330、如何从一个模态映射到另外一个模态。不同模态之间的关系往往是开放的或主观的。比如针对一张图片,有很多种文字描述方法来描述这张图像。同一段文字描述,不同人联想到的图像也是不一样的。这种模态之间的映射可能是一个多对多的映射关系,不存在一个完美的映射。第三章|华为云云原生 2.0 架构设计模式112 对齐是指两种或三种模态之间的信息如何精准对齐,比如我们希望视频中语音、文本和视频画面信号之间进行对齐;人的说话内容和其表情、肢体动作对齐等。融合是指有了多种模态信息之后,如何综合有效利用这些模态的信息进行 AI 模型的训练,起到 1+1 大于 2 的作用。如在视听语音识别中,将唇动的视觉描述信息与语音信号
331、融合,预测语音对应的文本信息。不同模态之间的信息所具备的信息量、噪声、分布不相同,模态之间可以互补,甚至可能会出现模态缺失的问题。协同学习是指如何实现不同模态之间的知识迁移,比如在某一个模态 A 上训练的模型,如何有效的迁移到另外一个模态 B,实现在 B 模态上的零样本学习。这种在某个模态缺失数据的情况下非常关键。如语音情感分析领域,语音对应的情感标注数据非常少,而人脸的情感标注会容易很多,所以可以基于人脸的情感识别知识迁移到语音的情感语料标注中。华为云提供了基于知识计算引擎的云原生多模态分析工作流内置了多模态表示学习、映射、对齐、融合、迁移、补全等功能。结合知识计算引擎,为用户提供一站式的多
332、模态应用开发工作流。具体应用案例如 OCR 文字识别、视频分析、多模态内容审核等。图 3-43 多模态分析流程华为云提供了基于知识计算引擎的云原生多模态分析工作流内置了多模态表示学习、映射、对齐、融合、迁移、补全等功能。多模态输入多模态输出多模态表示多模态映射多模态对齐多模态融合多模态迁移113云原生 2.0 架构白皮书3.3.10 全方位立体式安全防护架构设计模式3.3.10.1 统一权限管理1)细粒度授权模式访问控制,是指对受保护的资源进行选择性的限制访问,防止未授权的操作。任何访问控制模型都离不开两个关键要素:主体(Subject)和对象(Object),主体指系统中发起访问操作的实体,
333、不仅指人,也包括应用程序和服务,对象指需要进行访问控制的资源。目前最流行的访问控制模型是 RBAC(Role-Based Access Control),也就是基于角色的访问控制。RBAC 模型在主体和对象之间抽象出角色的概念,将主体和权限的关联进行解耦。角色是一组权限的集合,主体只需要担任角色,即自动拥有该角色中包含的权限。图 3-44 RBAC 访问控制模型RBAC 的权限设置是基于组织内的职责划分来定义,容易理解和管理,且实现成本低,所以RBAC 得到了非常广泛的采用。例如 Kubernetes 主流的访问控制机制就是 RBAC。但 RBAC 的授权策略必须是基于授权这一时刻下主体和对象的静止状态来预先定义,对于主体和对象变化的响应是滞后的。RBAC 一般定义一套资源组,资源需要放到不同的资源组里,并根据组织内人员的职责设置角色及其权限,建立人员-资源组-角色的关联。如果资源的分组维