课程总览

华为ICT大赛省赛（复赛）

一、概述

二、比重

三、比赛范围（大纲）

**比赛内容概述：**云涵盖云服务、云原生、AI三个技术方向的相关知识，包括但不限于云计算基础知识、华为云产品与服务、华为云解决方案、上云迁移、容器与K8S、AI技术与应用、机器学习、深度学习、计算机视觉、自然语言处理、大语言模型、华为云ModelArts、盘古大模型等。

考点：（考点大纲为通用指南，比赛中可能会出现本大纲中未提及的其他相关内容）

技术大类：云

1、云计算基础知识及云服务基本操作：

​ ①云计算基础知识：

​ IT发展变迁概念：物理概念->虚拟化环境->私有云/公有云，以及云计算发展背景、云计算定义、云计算价值、云计算分类、基础 设施即服务IaaS、平台即服务PaaS、软件即服务SaaS等。

​ ②华为云：

​ 华为云简介、华为云使用场景、华为云生态、区域Region介绍、可用区AZ介绍、统一身份认证IAM介绍、华为云计费模式等。

​ ③计算服务：

​ 计算服务概述、弹性云主机ECS、裸金属BMS、镜像服务IMS、弹性伸缩服务AS等

​ ④云网络服务：

​ 传统网络和云网络异同、虚拟私有云VPC技术、安全组、ACL、弹性公网IP服务、负载均衡ELB、虚拟专用网络VPN、NAT网关 等。

​ ⑤云存储服务：

​ 数据存储概念及发展、云存储概念、分类、使用场景、OBS、EVS、SFS等产品的概念、技术原理及使用等。

​ ⑥云数据库服务：

​ 数据库发展概述、关系数据库概念、云数据库概念、关系型数据库RDS、非关系型数据库GeminiDB产品的功能特点及使用等。

2、业务迁移上云：

​ ①云迁移方法论：

​ 迁移的战略制定与顶层规划、迁移调研分析和评估规划、迁移上云方案设计和试点规划、迁移上云实施和运维。

​ ②Landing Zone企业最佳实践：

​ Landing Zone设计与实施方法、Landing Zone需求调研、Landing Zone方案设计、Landing Zone方案实施。

​ ③云迁移实施：

​ 使用迁移工具如SMS、OMS、DRS、DCS、MGC实现计算服务、存储服务和数据库服务的迁移。

3、云原生应用构建：

​ ①云原生架构总览：

​ 云原生相关概念、出现背景、技术版图、架构演进原则、使用场景及未来发展趋势。

​ ②云原生基础设施：

​ 容器概念、容器引擎、容器镜像、容器仓库、Kubernetes概念及架构、Kubernetes编排、Istio的概念、华为云容器服务、华为 云容器引擎CCE、云容器实例CCI、容器仓库SWR、应用服务网格ASM技术原理及操作使用。

技术大类：AI

1、AI基础知识：

​ ①AI基础概念：AI相关概念、发展历程及应用等。

​ **②AI技术领域：**AI研究领域包括计算机视觉、NLP、ASR等。

​ **③AI前沿技术场景：**AI当前前沿技术趋势及场景，包含智能驾驶、强化学习、AI Agent等。

​ **④大模型基础知识：**大模型相关定义、发展历程，关键技术原理，分层原理，检索增强生成在大模型中的应用。

2、AI算法：

​ **①机器学习：**传统机器学习算法、超参数调整、模型评估、模型有效性（过拟合、欠拟合）等。

​ ②深度学习：

​ 深度学习算法（全连接神经网络、CNN、RNN、LSTM等）、损失函数、梯度下降、神经网络计算过程、优化器和激活函数、正 则化等常见问题及处理，包括梯度消失、数据样本不平衡等。

3、华为AI开发平台：

​ **①华为AI全栈全场景整体应用：**昇腾云服务ModelArts整体方案、ModelArts核心模块、ModelArts实践案例。

​ **②华为云AI开发平台使用：**华为云AI开发平台使用，包括开发环境、数据管理、训练平台、推理平台、AIGallery

4、大模型：

​ ①Transformer与大模型：

​ Transformer结构、GPT架构、多模态大模型架构、强化学习与大模型训练、大模型应用开发工具ollama、LlamaIndex、 LangChain、Dify等工具。

​ ②华为盘古大模型典型应用：

​ 华为盘古CV大模型、华为盘古NLP大模型、华为盘古多模态大模型、华为盘古科学计算大模型、华为盘古GNN大模型。

四、知识点学习

HCCDA-Cloud Native 云原生入门级开发者认证课程笔记

1、云原生架构总览

1.1、云计算技术发展

云计算技术发展历程：

1. 核心构建单元：服务器→虚拟机→容器

这是云计算 “计算资源形态” 的演进：

• 早期用物理服务器：一台机器跑一个应用，资源利用率低、部署慢；
• 后来用虚拟机（如 VMware）：通过虚拟化技术把一台物理机拆成多个独立的虚拟系统，资源利用率提升，但虚拟机体积大、启动慢；
• 现在主流用容器（如 Docker）：更轻量的虚拟化，直接共享宿主机操作系统，体积小（MB 级）、启动快（秒级），是云原生的核心技术。

2. 不可变基础设施：从宠物到牛群

这是云计算 “运维模式” 的转变：

• 传统 “宠物式运维”：服务器是 “宠物”（专人维护、频繁修改配置），容易出现 “配置漂移”（每台机器环境不一致）；
• 现在 “牛群式运维”（不可变基础设施）：服务器是 “牛群”（部署后不再修改，要更新就直接替换新机器），通过镜像统一环境，避免配置混乱，是云原生的核心理念之一。

3. 隔离单元：更轻的体量，更快的启动速度

这是云计算 “资源隔离能力” 的升级：

• 物理机 / 虚拟机的隔离是 “重量级” 的（需要独立操作系统）；
• 容器的隔离是 “轻量级” 的（通过内核技术实现进程级隔离），既保证了应用间的独立运行，又做到了资源占用少、启动速度快。

4. 供应商：从闭源单一供应商到开源跨供应商

这是云计算 “生态模式” 的变化：

• 早期云计算依赖闭源单一供应商（如 VMware 的虚拟化、AWS 的早期服务），用户被绑定在特定厂商的技术栈里；
• 现在转向开源跨供应商（如 Kubernetes、OpenStack 等开源项目），用户可以在不同云厂商（阿里云、AWS、腾讯云）之间无缝迁移应用，避免 “厂商锁定”。

1.2、云原生定义

**云原生出现的背景：**移动互联网爆发，业务转向 “亿级规模 + 高频迭代”，传统架构（单体、物理机）无法支撑弹性与速度；云计算技术成熟，但传统软件 “搬上云” 难用足云价值；以互联网场景为标杆，催生适配云的技术体系，解决 “大规模 + 快变化” 与传统架构的矛盾。

云原生定义（Pivotal论述）：

• 云原生是一种构建和运行应用程序的方法，它利用了云计算交付模型的优势；
• 云原生关注如何创建和部署应用程序，而不是在何处；
• 虽然现在公有云影响了几乎每个行业的基础设施投资思想，但类似云的交付模式并不仅限于公有云环境，它适用于公有云和私有云；
• 云原生结合了DevOps、持续交付、微服务和容器的概念；
• 当公司以云原生方式构建和运行应用程序时，它们可以更快的将新想法推向市场并更快地响应客户需求；

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

云原生核心理念：

• 解耦软件开发，提高灵活性和可维护性
  • 基于容器镜像的软件分层，清晰的依赖管理
  • 剥离程序、配置和微服务，让开发者聚焦业务开发
  • 拆分应用程序为微服务并明确依赖表述
• 多云支持，避免厂商锁定
  • 厂商基于标准接口提供服务，互操作性强
  • 开源为主，丰富的标准软件生态（用户选择多）
  • 支持在所有公有云、私有云或混合云部署
• 避免侵入式定制
  • 基于Kubernetes的松耦合平台架构，易扩展
  • Kubernetes已被公认是platform for platform
• 提高工作效率和资源利用率
  • 通过中心编排过程动态管理和调度应用/微服务

云原生的技术版图：

容器技术（提高应用可移植性，提升业务敏捷）：

• 容器可以将应用本身及其依赖打包，使得应用可以实现“一次封装，到处运行”。
• 容器也可以理解成一种沙盒技术，沙盒在计算机安全领域中是一种安全机制，为运行中的程序提供的隔离环境。

容器核心价值：

• 可移植性：环境标准化，应用随处运行
• 敏捷：创建速度快，秒级资源弹性
• 提高生产力：消除跨服务依赖性和冲突

服务网格（剥离业务代码和分布式框架）

微服务（加速企业应用架构升级）：微服务作为一种构建应用的架构方案，可将应用拆分成多个核心功能，每个功能都被称为一项服务，可以单独构建和部署，各项服务在工作（和出现故障）时不会相互影响。微服务设计的三大原则是：单一职责、高内聚、低耦合。

DevOps（促进开发运维一体化）：DevOps做到在软件产品交付过程中IT工具链的打通，使得各个团队减少时间损耗，更加高效地协同工作。DevOps涵盖了代码、构建、发布、运营、监控和反馈等环节，形成良性循环。

1.3、云原生应用

一、云原生应用的定义（Pivotal+RedHat）

1. Pivotal 定义：专为云模式构建的应用，由小型团队快速开发部署，具备横向扩展、硬件解耦能力，适配公有 / 私有云，整合 DevOps、微服务等技术，核心是提升业务响应速度。
2. RedHat 定义：独立小规模松耦合服务的集合，通过快速迭代用户反馈持续改进，目标是加速应用构建与组合，满足企业级需求响应速度。

二、云原生应用的综合特征

基于云原生技术设计，充分发挥云优势：

• 采用容器打包分发，以微服务为架构；
• 结合DevOps 组织模式与CI/CD 工具链，实现持续交付；
• 依赖云平台组件，核心是 “弹性、敏捷、可移植”。

三、适用场景

适用于需高频迭代交付的组织，包括：互联网企业、ISV 提供商、智能设备厂商、云服务商等。

四、与传统应用的核心区别

维度	云原生应用	传统应用
发布与弹性	可预测、弹性扩展	不可预测、扩展能力弱
环境依赖	操作系统抽象化	强依赖操作系统
团队协作	DevOps 协同	部门孤立
开发模式	敏捷开发	瀑布式开发
架构	微服务（高内聚、低耦合）	单体（耦合严重）
运维	自动化运维、快速恢复	手动运维、恢复缓慢

五、12-Factors 核心方法论

由 Heroku 提出的云原生应用开发标准，目标是提升可靠性、扩展性与可维护性，核心价值包括：

• 标准化配置、降低环境差异；
• 适配云平台、节省资源；
• 支持持续交付与敏捷开发。

具体 12 要素覆盖代码管理、依赖、配置、构建发布、进程、日志等维度，每个要素对应明确的实践方法（如配置转环境变量、端口绑定、日志结构化等），适用于任意语言与后端服务。

1.4、云原生架构原则及常用模式

一、云原生架构演进的 5 大核心原则

1. 弹性：微服务无状态设计，支持自动水平伸缩、实例快速启停。
2. 分布式：业务逻辑与数据 / 会话解耦，数据去中心化、最终一致，跨可用区部署。
3. 高可用：基于 “不可靠资源” 设计，实例故障自动隔离恢复，基础设施单点故障不影响整体可用。
4. 自动化：实现自动化部署、监控、故障自愈。
5. 自服务：服务可被自助发现、获取、计量与管理。

二、云原生架构的核心模式（从单体到 Serverless）

1. 单体架构（云原生的优化起点）

• 局限性：团队协作难、上线周期长、资源扩容粗粒度（整体扩容）、功能重复开发。

2. 微服务架构（云原生核心模式）

• 架构特征：按功能拆分为独立服务，各服务有专属数据库，通过服务网关 / 注册中心管理。
• 优势：小团队高效协作、功能快速交付、组件可复用、仅针对瓶颈服务细粒度扩容。

3. Serverless 架构（云原生进阶模式）

• 定义：服务端逻辑以 “无状态函数” 运行，由事件触发、云平台托管，开发者仅关注业务逻辑。
• 优势：轻量（无需管基础设施）、毫秒级弹性伸缩、按调用计费成本低。

4. 微服务与 Serverless 的关系

微服务向 Serverless 演进，二者长期共存：Serverless 在弹性（毫秒级）、发布（分钟级）、运维（No Ops）等维度更极致，是微服务的轻量化升级。

1.5、华为云云原生解决方案

华为云云原生解决方案围绕 “技术贡献、全栈服务、场景化方案” 构建。具体为如下四点：

一、云原生领域的领导地位

1. 技术贡献：CNCF 亚洲唯一初创 + 白金会员，主导 KubeEdge（边缘计算）、Volcano（批量计算）等核心项目，Kubernetes 代码贡献量亚洲第一；
2. 行业落地：内部业务（流程 IT、华为云）容器数超 3000 万，外部覆盖 10 + 行业、千余家企业，中国容器软件市场份额第一；
3. 产业推动：联合发布《云原生 2.0 白皮书》等行业标准，成立云原生交流平台。

二、全栈云原生服务体系

以 “云原生应用 + 云原生基础设施” 为核心，覆盖全生命周期：

• 应用层：以 DevSecOps 为开发模式，通过 DevCloud（开发部署）、ServiceStage（运行治理）、AOM/APM（运维）实现安全可信的全流程管理；
• 基础设施层：以容器为核心，提供容器引擎（iSula）、网络（Yangtse）、存储（Everest）等底座能力，实现极致轻量、性能提升 40%。

三、场景化解决方案

1. 多云管理：通过 MCP（多云容器平台）+ASM（应用服务网络），实现跨区域、跨云的 K8s 集群与应用统一管理；
2. 高性能计算：基于 Volcano 调度引擎，支持 AI 训练、大数据等批量任务，集群利用率提升 30%，30 秒可发放 1000 容器；
3. 边云协同：以 KubeEdge 为底座，实现中心云与边缘设备的应用一致交付，支持 128MB 轻量边缘设备，性价比提升 30%。

四、配套能力

1. 微服务管理：通过 CSE 微服务引擎，支持 SpringCloud/Dubbo 等框架，实现服务注册、配置管理、熔断限流等能力，保障高可用；
2. 全栈运维：以 AOM（监控）、LTS（日志）、APM（调用链）构建非侵入式运维体系，实现 360° 监控与问题定位。

1.6、云原生未来发展趋势

1. Kubernetes 编排统一化

​ Kubernetes 在容器编排领域的采纳率达 63%，成为绝对主流；其编排对象从容器扩展至虚拟机、函数等各类资源，同时生态向大数据（如 Spark）、机器学习场景渗透，成为云原生技术的核心底座。

2. 服务治理 Mesh 化

​ 服务网格（Service Mesh）快速增长：38% 的单位已在生产中使用，42% 处于评估阶段；以 Istio 为代表的方案，通过将服务治理能力下沉到基础设施层，实现业务逻辑与治理解耦，成为传统应用向云原生转型的关键路径。

3. 应用服务 Serverless 化

​ Serverless 作为下一代云计算范式，正从观望走向落地：用户可聚焦核心业务逻辑，无需关注底层资源；其高可用、高弹性的特性，将大幅提升应用开发效率，成为云原生技术的重要演进方向。

4. 部署形态多元化，多云成主流

​ 74% 的用户已使用或计划采用多云 / 混合云架构，出于数据主权、安全合规、成本优化等需求，企业会同时使用 IDC、多家公有云；未来多云、多集群部署将成常态，可编程式多云管理将成为核心需求。

2、云原生基础设施之容器技术

2.1、容器定义及发展背景

企业 IT 业务云化的两类路径：

一、传统业务云化（基础迁移）

1. 方式 1：物理机部署 + 统一管理
   • 特征：业务无法云化，仅将物理资源搬迁 / 纳管到云平台资源池
   • 资源管理：按峰值静态分配，资源占用率高、缺乏统一管理
2. 方式 2：云化后虚拟化部署
   • 特征：通过 P2V/V2V 迁移应用到 IaaS 平台
   • 资源管理：按应用组件分类打标签，集群化管理

二、业务云化创新（进阶优化）

1. 方式 1：云化后容器部署
   • 特征：应用容器化，实现快速发布、弹性伸缩（应用少改 / 不改）
   • 资源管理：混合编排虚机进程与容器应用
2. 方式 2：云原生
   • 特征：应用微服务化，采用 Cloud-Native 架构（需改造应用），业务更敏捷
   • 资源管理：应用层集中、动态管理与调度

容器是什么？

• 容器是一种轻量级、可移植、自包含的软件打包技术，使应用程序可以在几乎任何地方以相同的方式运行。
• 开发人员在自己开发环境创建并测试好的容器，无需任何修改就能够在生产系统的虚拟机、物理服务器或公有云主机上运行。

**容器（以 Docker 为例）的核心思想：**通过 “打包应用 + 依赖环境”，实现 “多样应用” 在 “多样底层平台” 的跨环境一致运行。

**容器与虚拟机：**容器和虚拟机之间的主要区别在于虚拟化层的位置和操作系统资源的使用方式。

对比项	容器	虚拟机
启动速度	秒甚至毫秒启动。	数秒至数十秒。
系统内核	共享内核。	不共享内核。
实现技术	利用 Linux 内核技术 namespace/cgroup 等实现。	依赖虚拟化技术实现，由 Hypervisor 层实现对资源的隔离。
隔离效果	进程级别的隔离。	系统资源级别的隔离。
资源消耗（性能）	容器中的应用只是宿主机上的一个普通进程。	使用虚拟化技术，就会有额外的资源消耗和占用。
资源调用（敏捷性）	应用进程直接由宿主机 OS 管理。	应用进程需经过 Hypervisor 的拦截和处理，才能调用系统资源。
运行数量	一台服务器上能启动 1000 + 容器。	一台服务器上一般不超过 100 台虚拟机。
应用	DevOps、微服务等。	用于硬件资源划分。
镜像	分层镜像。	非分层镜像。

Docker项目介绍：

• Docker是最受大众关注的容器技术，并且现在"几乎"成为事实上的容器标准。2013年，dotCloud公司将Docker项目开源。
• Doeker项目：
  • GitHub上开发的Moby开源项目的一部分；
  • 遵循Apache License 2.0许可证协议；
  • Go语言编写。
  • Docker是一个开源的引擎，可以轻松的为任何应用创建一个轻量级的、可移植的、自给自足的容器。
• Docker公司目前推出两个版本：Docker CE（社区版）、Docker EE（企业版）。

2.2、容器基础技术介绍

容器技术基础：容器规范

​ 容器不光是Docker，还有其他容器，比如CoreOS的rkt。为了保证容器生态的健康发展，保证不同容器之间能够兼容，包含Docker、CoreOS、Google在内的若干公司共同成立了一个叫Open Container Initiative的组织，其目的是制定开放的容器规范。

容器技术基础：runtime

​ runtime与操作系统Kernel紧密协作，为容器提供运行环境。

• 常见的容器runtime：
  • runC（runC由Libcontainer演变而来）是Docker公司2015年发布的容器runtime工具，其管理工具为Docker Engine。
  • rkt，是CoreOS公司开发的Docker/runc的一个流行替代方案。
  • Kata，2017年整合Clear Container和runV项目，基于虚拟化技术的容器实现。
  • gVisor，2018年Google公司发布gVisor的项目，基于虚拟化技术的容器实现。

容器技术基础：容器管理工具

• 容器管理工具对内与runtime交互，对外为用户提供interface，如CLI。
• 如同Java程序的运行需要JVM提供运行环境，Java命令能够启停应用一样，runtime为容器运行提供环境，也需要有相应的容器管理工具对容器进行管理。

容器技术基础：容器定义工具

容器定义工具，也就是镜像，允许用户定义容器的内容和属性，通过该工具，容器就能够被保存、共享和重建。

• Docker image是docker容器的模板，runtime根据docker image创建容器。
• Dockerfile是包含若干命令的文本文件，可以通过这些命令创建出docker image。
• ACI（App Container Image）与docker Image类似，它是由CoreOS开发的rkt容器的Image格式。

容器技术基础：Registry

• Registry是存放容器镜像的仓库，用户可进行镜像下载和访问，分为公有和私有两类Registry。
• 公有镜像仓库：
  • Docker Hub是Docker公司为公众提供的托管Registry。
  • Quay.io现为Red Hat下的公共托管Registry。
• 私有镜像仓库：
  • 企业可以用Docker Registry构建私有的Registry（Registry本身是一个开源项目，可以用于搭建私有Registry）。

2.3、Docker介绍

一、Docker 架构与核心组件

Docker 采用客户端 - 服务器（C/S）架构，包含 3 大核心部分：

1. Client（客户端）：通过docker build/pull/run等命令向服务端发送请求；
2. Docker Host（主机）：运行Docker daemon（守护进程），管理容器、镜像等资源；
3. Registry（仓库）：存储 Docker 镜像（如 Docker Hub），支持镜像的上传 / 下载。

二、Docker 核心概念

1. 镜像（Image）：只读的应用模板，可用于创建容器，支持自定义构建或从仓库下载；
2. 容器（Container）：从镜像创建的运行实例，是相互隔离的轻量运行环境，支持启停、删除；
3. 仓库（Repository）：集中存储镜像的场所，Registry 是仓库的管理服务，每个仓库可包含多个版本的镜像（通过 Tag 区分）。

三、Docker 实现原理（基于 Linux 内核技术）

Docker 容器的核心是资源隔离 + 资源限制，依赖 2 项 Linux 技术：

1. Namespace（命名空间）：
   • 作用：实现进程、网络、文件系统等资源的隔离；
   • 类型：包括 PID（进程 ID）、Network（网络）、Mount（文件挂载）等 6 种类型，使容器内进程 “看不到” 宿主机资源（如容器内/bin/bash是 PID=1，宿主机中实际是其他 PID）。
2. Cgroups（控制组）：
   • 作用：限制容器的 CPU、内存、I/O 等资源使用上限；
   • 实现：以文件目录形式组织在/sys/fs/cgroup路径下，通过给进程组分配资源配额实现管控。

四、Docker 与虚拟机的区别

• 虚拟机：需运行独立 Guest OS，资源占用高、启动慢；
• Docker 容器：共享宿主机 OS 内核，仅隔离进程级资源，轻量（MB 级）、启动快（秒级）。

2.4、容器镜像介绍

一、容器镜像：

• 容器镜像是容器的模板，容器是镜像的运行实例，runtime根据容器镜像创建容器。
• 容器镜像挂载在容器根目录下，为容器中的应用提供执行环境的文件系统。
  • 容器镜像打包了整个操作系统的文件和目录（rootfs），也包括应用本身。即应用及其运行所需的所有依赖都在被封装在容器镜像中。
• 容器镜像采用分层结构：所有容器共享宿主机Kernel，并且不能修改宿主机Kernel。即容器运行过程中使用容器镜像中的文件，使用宿主机os上的Kernel。

容器镜像是一个分层的、只读的模板，包含了应用及其所有依赖；容器是镜像的运行实例，在镜像之上添加一个可写层来运行应用；容器共享宿主机内核，不修改宿主机内核。

二、Base 镜像是从空镜像 scratch 构建、不依赖其他镜像的基础模板，可基于它扩展新镜像，实际常用的是 Ubuntu、CentOS 等 Linux 发行版的 Docker 镜像。

三、Docker 镜像分层结构

Docker 镜像采用分层设计：

1. 结构：由若干只读镜像层（Image layers）和容器运行时的可写容器层（Container layer）组成；
2. 实现：基于 UnionFS 联合文件系统，将多镜像层挂载为统一目录，表现为一个完整的Linux操作系统供容器使用；
3. 优势：分层可复用（多个容器共享镜像层），提升镜像分发、容器创建的效率。

四、Docker 镜像构建（Dockerfile）

1. Dockerfile 定义：包含指令的文本文件，每条指令对应一个镜像层，用于自动化构建镜像；
2. 组成部分：基础镜像信息、维护者信息、镜像操作指令、容器启动指令；
3. 构建流程：通过docker build命令，基于 Dockerfile 和构建上下文（build context）生成镜像，再通过docker run启动容器。

五、Dockerfile 常用指令

核心指令及作用：

指令	作用
FROM	指定基础镜像
RUN	执行命令（构建镜像层）
COPY/ADD	复制文件到镜像
EXPOSE	声明容器暴露端口
CMD/ENTRYPOINT	定义容器启动命令

六、镜像命名

镜像名称格式为repository:tag，tag用于标识版本（默认latest），可通过docker tag为镜像添加标签。

七、搭建私有Registry示例

2.5、容器常用命令介绍

一、Docker 服务与容器运行

1. 查看 Docker 状态：systemctl status docker.service查看服务运行状态；
2. 运行容器：docker run -d -p 宿主机端口:容器端口 镜像（-d后台运行，-p端口映射），本地无镜像会自动拉取；
3. 验证容器：docker images看镜像、docker ps看运行容器，通过 “宿主机 IP: 端口” 访问验证。

二、容器生命周期管理

Docker容器有七种不同的状态，每种状态代表容器在其生命周期中的不同阶段。了解这些状态有助于更好地管理和操作容器。

容器状态

1. created（已创建）: 容器已经被创建，但尚未启动。
2. restarting（重启中）: 容器正在重启。
3. running（运行中）: 容器正在运行。
4. removing（迁移中）: 容器正在被删除。
5. paused（暂停）: 容器中的所有进程已被暂停。
6. exited（停止）: 容器已停止运行。
7. dead（死亡）: 容器已死亡，无法恢复。

这些状态可以通过运行命令 docker ps -a 来查看。容器的生命周期通常包括以下几个关键状态：

• created（已创建）: 使用 docker create 命令创建容器。
• running（运行中）: 使用 docker start 命令启动容器。
• paused（暂停）: 使用 docker pause 命令暂停容器。
• exited（停止）: 使用 docker stop 命令停止容器。
• dead（死亡）: 容器进入不可恢复的状态。

操作	命令	说明
停止容器	docker stop 容器ID/名称	状态变为 Exited
启动容器	docker start 容器ID/名称	恢复运行（状态 Up）
暂停容器	docker pause 容器ID/名称	状态变为 Pause
恢复容器	docker unpause 容器ID/名称	恢复运行
删除容器	docker rm 容器ID/名称	删除已停止容器
批量删退出容器	docker rm -v $(docker ps -aq -f status=exited)	清理所有退出状态的容器

三、进入容器

• docker attach 容器ID：进入容器（退出会终止容器）；
• docker exec -it 容器ID bash：交互式进入容器（退出不影响容器运行）。

四、其他常用命令

• docker inspect 容器/镜像：查看元数据；
• docker top 容器ID：查看容器内进程；
• docker events：获取 Docker 实时事件；
• docker port 容器ID：查看端口映射；
• docker cp 容器路径 宿主机路径：容器与主机间拷贝数据。

3、云原生基础设施之Kubernetes

​ 容器技术的诞生虽然解决了应用打包和发布的难题，但单一的容器技术工具并无法支持起生产级大规模容器部署的场景。针对这一场景，容器管理与编排成为了容器技术发展的关键。Kubernetes便是在这样的大背景下诞生的。

3.1、容器集群管理概述

容器编排技术：

​ 容器（如Docker）以及周边生态系统提供了很多工具来实现容器生命周期管理，能够满足在单台宿主机管理容器的需求。但越来越多企业开始使用容器，对容器技术的进一步发展提出了以下新的诉求：

• 高效的容器管理及编排
• 容器的跨主机部署及调度
• 容器的存储、网络、运维、安全等能力的拓展。

​ 容器编排是指自动化容器的部署、管理、扩展和联网，可为企业带来灵活的资源管理及调度、自动化部署及服务发现、高效的监控及运维和弹性扩展及高可用等价值。

​ 大规模容器集群管理工具，从Borg到Kubernetes：

• Kubernetes起源于Google内部的Borg项目，它对计算资源进行了更高层次的抽象，通过将容器进行细致的组合，将最终的应用服务交给用户。它的目标是管理大规模的容器，提供最基本的部署、维护以及应用伸缩等功能，其主要实现语言为Go语言。
• Kubernetes作为容器集群管理工具，于2015年7月22日迭代到v1.0并正式对外公布。与此同时，谷歌联合Linux基金会及其他合作伙伴共同成立了CNCF基金会（Cloud Native Computing Foundation），并将Kubernetes作为首个编入CNCF管理体系的开源项目，助力容器技术生态的发展进步。

容器集群管理的竞争最终以 Kubernetes 统一生态告终：

• 前期（Before）：容器编排领域呈 “多国混战”，存在 Kubernetes、Marathon（基于 MESOS）、Docker Swarm 等多个方案；
• 2017 年 10 月：Docker 宣布其企业版 / 社区版支持 Kubernetes，标志着 Kubernetes 的优势扩大；
• 当前（Now）：Kubernetes 已成为容器编排和资源管理框架的事实标准，一统容器集群管理生态。

3.2、Kubernetes架构与核心概念

Kubernetes架构

• 一个基础的Kubernetes集群（Cluster）通常包含一个Master节点和多个Node节点。每个节点可以是一台物理机，也可以是一台虚拟机。

Master节点

• Kube-apiserver：Kube-apiserver对外暴露了Kubernetes API。它是Kubernetes的前端控制层。被设计为水平扩展架构，即通过部署更多实例来承载业务。
• etcd：etcd用于Kubernetes的后端存储，存储集群数据，提供数据备份。
• Kube-controller-manager：控制器，负责策略控制，针对不同的工作负载执行不同的策略，如无状态应用，有状态应用等。
• Kube-scheduler：负责任务调度工作，监控没有分配节点的新创建的Pod，选择一个结点供Pods运行。

Node节点

• Kubelet：在集群内每个节点中运行的一个代理，用于保证Pod的运行，接收Master的指令，负责管理容器（Pod）。
• Kube-proxy：负责做负载均衡工作，在多个Pod/Service之间做负载均衡。用于管理Service的访问入口，包括集群内Pod到Service的访问和集群外访问Service。
• Add-ons：插件，用于扩展Kubernetes的功能。
• Container runtime：通常使用Docker来运行容器，也可以使用rkt等作为替代方案。

开放接口CRI、CNI、CSI

​ Kubernetes作为云原生应用的基础调度平台，相当于云原生的操作系统，为了便于系统的扩展，Kubernetes中开放的一下接口，可以分别对接不同的后端，来实现自己的业务逻辑：

• CRI（Container Runtime Interface）：容器运行时接口，提供计算能力，是定义了容器和镜像的服务的接口，常见的CRI后端有Docker、rkt、kata-containers等。
• CNI（Container Network Interface）：容器网络接口，提供网络能力，由一组用于配置Linux容器的网络接口的规范和库组成，同时还包含了一些插件，它仅关心容器创建时的网络分配，和当容器被删除时释放网络资源。
• CSI（Container Storage Interface）：容器存储接口，提供存储能力，通过它，Kubernetes可以将任意存储系统暴露给自己的容器工作负载。

Kubernetes核心概念

**1、Pod：**Pod是Kubernetes中最重要最基本的概念，Pod是Kubernetes最小工作单元。每一个Pod包含一个或多个相关容器，Kubernetes将Pod看做一个整体进行调度。

引入Pod的目的：

• 将联系紧密的容器封装在一个Pod单元内，以Pod整体进行调度、扩展和实现生命周期管理。
• Pod内所有容器使用相同的网络Namespace和共享存储。即Pod内的容器拥有相同的IP地址和Port空间，容器间直接使用localhost通信。当挂载volume到Pod，即可实现将volume挂载到Pod中的每个容器。

**2、Label：**当资源变得非常多的时候，如何分类管理就非常重要了，Kubernetes提供了一种机制来为资源分类，那就是Labell（标签）。Labe非常简单，但是却很强大，Kubernetes中几乎所有资源都可以用Label来组织。Label的具体形式是key-value的标记对，可以在创建资源的时候设置，也可以在后期添加和修改。

3、Namespace：

​ 命名空间（Namespace）是对一组资源和对象的抽象整合。在同一个集群内可创建不同的命名空间，不同命名空间中的数据彼此隔离。使得它们既可以共享同一个集群的服务，也能够互不干扰。

在默认情况下，新建的集群存在以下四个 Namespace：

• default: 所有未指定 Namespace 的对象都会被分配在 default 命名空间。
• kube-public: 此命名空间下的资源可以被所有人访问（包括未认证用户），用来部署公共插件、容器模板等。
• kube-system: 所有由 Kubernetes 系统创建的资源都处于这个命名空间。
• kube-node-lease: 每个节点在该命名空间中都有一个关联的 “Lease” 对象，该对象由节点定期更新，被用来记录节点的心跳信号（“心跳信号” 本质是节点向集群发送的 “存活证明”，核心作用是让控制平面（kube-apiserver、kube-controller-manager 等）确认节点仍处于正常运行状态，而非失联或故障。）。

4、Controller：

​ 工作负载是在Pod之上的一层抽象，我们可以通过**控制器（controller）**实现一系列基于Pod的高级特性，比如节点故障时Pod的自动迁移，Pod多副本横向扩展，应用滚动升级等。我们通常使用controller来做应用的真正的管理，而Pod是组成工作负载最小的单元。

​ 工作负载按不同业务类型，在Kubernetes中分为四类：Deployment和ReplicaSet；StatefulSet；DaemonSet；Job和CronJob。

5、Service：在Kubernetes中，Pod副本发生迁移或者伸缩的时候会发生变化，IP也是变化的。Kubernetes中的Service是一种抽象概念，它定义了一个Pod逻辑集合以及访问它们的策略。Service定义了外界访问一组特定Pod的方式。Service有自己的IP和端口，Service为Pod提供了负载均衡。

**6、Volume：**Volume用来管理Kubernetes存储，是用来声明在Pod中的容器可以访问的文件目录，含义如下：

• 声明在Pod中的容器可以访问的文件目录。
• 可以被挂载在Pod中一个或多个容器的指定路径下。
• 支持多种后端存储（本地存储、分布式存储、云存储等）。

3.3、Kubernetes应用编排与管理

对象类型总览：

Kubernetes管理

**1、Kubectl：**Kubectl是Kubernetes的命令行工具。通过kubectl，用户能对集群进行管理，并在集群上进行容器化应用的安装部署。

Kubectl支持以下对象管理方式：

• 指令式：通过kubectl内置的驱动命令，如：kubectl+create/scale/delete/…+参数的形式，直接快速创建、更新和删除Kubernetes对象。
• 声明式：使用kubectl apply创建指定目录中配置文件所定义的所有对象。通常，此配置文件采用yaml进行描述。

2、命令行语法：

• 在Kubernetes中的很多操作都是用kubectl来完成，通过其命令可以管理Deployment、Replicaset、ReplicationController、Pod等，进行操作、扩容、删除等全生命周期操作，同时可以对管理对象进行查看或者监控资源使用情况。

• kubectl的语法：

  kubectl [command] [TYPE] [NAME] [flags]
  

  • Command:指定你希望进行的操作，如create，get，describe，delete等。
  • TYPE：指定操作对象的类型，如deployment，pod，service等。
  • NAME：指定对象的名字。
  • flags：可选的标志位。

3、yaml示例：

• 创建 Kubernetes 对象时，必须提供对象的规约，用来描述该对象的期望状态，以及关于对象的一些基本信息（例如名称）。
• 在编辑 Kubernetes 对象对应的.yaml 文件时，至少需要配置如下的字段：
  • apiVersion：建该对象所使用的 Kubernetes API 的版本。
  • kind：创建的对象的类别，如 Pod/Deploymen/Service 等。
  • Metadata：描述对象的唯一性标识，可以是一个 name 字符串，可选的 namespace，label 项指定标签等。
  • Spec：该对象的期望状态，其中 replicas 指定 Pod 副本数量。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Kubernetes应用编排——工作负载类型：

• **无状态工作负载：**管理的Pod集合是相互等价的，需要的时候可以被替换。（Deployment；ReplicaSet）
• **有状态工作负载：**为每个Pod维护了一个唯一的ID，能够保证Pod的顺序性和唯一性，每个Pod是不可替代的。可使用持久存储来保存服务产生的状态。（StatefulSet）
• **守护进程工作负载：**保证每个节点上运行着这样一个守护进程。（DaemonSet）
• **批处理工作负载：**一次性的任务。（Job；CronJob）

Deployment概述

• Deployment是一组不具有唯一标识的多个Pod的集合，具备以下功能：
  • 确保集群中有期望数量的Pod运行。
  • 提供多种升级策略以及一键回滚能力。
  • 提供暂停/恢复能力。
• 典型使用场景：Web Server等无状态应用。

Deployment管理

1、使用命令行创建Deployment：

2、使用yaml创建Deployment：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

3、滚动更新：

• 用户希望应用程序始终可用，而开发人员则需要每天多次部署它们的新版本。在 Kubernetes 中，这些是通过滚动更新（Rolling Updates）完成的。滚动更新允许通过使用新的实例逐步更新 Pod 实例，零停机进行工作负载的更新。新的 Pod 将在具有可用资源的节点上进行调度。
• 滚动更新允许以下操作：
  • 将应用程序从一个环境提升到另一个环境（通过容器镜像更新）。
  • 回滚到以前的版本。
  • 持续集成和持续交付应用程序，无需停机。

StatefulSet概述

• 在某些分布式的场景，比如分布式数据库，要求每个Pod都有自己单独的状态时，这时Deployment就不能满足需求了。
• 此类应用依靠StatefulSet进行部署。StatefulSet具备以下特征：
  • Pod有稳定的网络标识符，Pod重新调度后PodName和HostName不变。
  • 每个Pod有单独存储，保证Pod重新调度后还是能访问到相同的数据。

创建有状态应用：

StatefulSet管理

DaemonSet概述

DaemonSet（守护进程集）部署的副本Pod会分布在各个Node上。它具备以下特点：

• 确保每一个节点或者期望的节点（通过nodeSelector实现）上运行一个Pod。
• 新增节点时自动部署一个Pod。
• 移除节点时自动删除Pod。

DaemonSet典型场景：

• 在集群的每个节点上运行存储Daemon，如glusterd，ceph。
• 在每个节点上运行日志收集Daemon，如fluentd或logstash。
• 在每个节点上运行监控Daemon，如Prometheus Node Exporter。

Jobs概述

Jobs主要处理一些短暂性的一次性任务，并具备以下特点：

• 保证指定数量Pod成功运行结束。
• 支持并发执行。
• 支持错误自动重试。
• 支持暂停/恢复Jobs。

典型使用场景：计算以及训练任务，如批量计算，AI训练任务等。

CronJob概述

CronJob主要处理周期性或者重复性的任务：基于Crontab格式的时间调度；可以暂停/恢复CronJob。

典型的使用场景：周期性的数据分析服务；周期性的资源回收服务。

3.4、Kubernetes服务发布

**Pod的特征：**Pod有自己独立的IP；Pod可以被创建，销毁；当扩缩容时，Pod的数量会发生变更；当Pod故障时，ReplicaSet会创建新的Pod。

那如何保证在pod进行如此多变化时，业务都能被访问？

**Service概述：**Kubernetes Service定义了这样一种抽象：逻辑上的一组Pod，一种可以访问它们的策略，通常称为微服务。这一组Pod能够被Service访问到，通常是通过Label Selector实现的。

Kubernetes支持以下Service类型：

• ClusterIP：提供一个集群内部的虚拟IP地址以供Pod访问（默认模式）。
• NodePort：在Node上打开一个端口以供外部访问。
• LoadBalancer：通过外部的负载均衡器来访问。

Service管理

NodePort模型

​ 节点访问（NodePort）是指在每个节点的IP上开放一个静态端口，通过静态端口对外暴露服务，后将外部请求路由至集群内部的ClusterIP。

LoadBalancer模型

• 负载均衡（LoadBalancer）可以通过弹性负载均衡从公网访问到工作负载，与NodePort加公网IP的方式相比提高了高可靠的保障。
• LoadBalancer此功能由集群外部负载均衡器提供商提供。

Ingress 概述

• Service 是基于四层 TCP 和 UDP 协议转发的，而在实际使用场景中，四层 Service 无法满足应用层存在的大量 HTTP/HTTPS 访问需求，因此需要使用七层负载均衡（Ingress）来暴露服务。
• Ingress 可基于七层的 HTTP 和 HTTPS 协议进行转发，它是 Kubernetes 集群中一种独立的资源，制定了集群外部访问流量的转发规则。这些转发规则可根据域名和路径进行自定义，Ingress Controller 根据这些规则将流量分配到一个或多个 Service，完成对访问流量的细粒度划分。

3.5、Kubernetes存储管理

Volume概述

• Volume 的核心是一个目录，其中可能存有数据，Pod 中的容器可以访问该目录中的数据。用户创建 Volume 时选择的卷类型将决定该目录如何形成，使用何种介质保存数据，以及规定目录中存放的内容。
• Volume 的生命周期与挂载它的 Pod 相同，但是 Volume 里面的文件可能在 Volume 消失后仍然存在，这取决于卷的类型。如当 Pod 不再存在时，Kubernetes 也会销毁临时卷，但并不会销毁持久卷。

Volume类型

• Kubernetes 支持多种卷类型，常用的类型有：
  • emptyDir：一种简单的空目录，主要用于临时存储。
  • hostPath：将主机（节点）某个目录挂载到容器中，适用于读取主机上的数据。
  • ConfigMap：特殊类型，将 Kubernetes 特定的对象类型挂载到容器。
  • Secret：特殊类型，将 Kubernetes 特定的对象类型挂载到容器。
  • PVC：PersistentVolumeClaim，用来挂载 PersistentVolume（持久化卷），提供可靠的存储来保存应用的持久化数据。

EmptyDir简介

• 特征：
  • 当 Pod 指定到某个节点上时，首先创建的是一个emptyDir卷，并且只要Pod在该节点上运行，卷就一直存在，卷最初是空的。
  • 尽管 Pod 中的容器挂载emptyDir卷的路径可能相同也可能不同，但这些容器都可以读写 emptyDir 卷中相同的文件。
  • 当 Pod 因为某些原因被从节点上删除时，emptyDir 卷中的数据也会永久删除。
• 使用场景：
  • 不同容器之间共享文件（例如日志采集等）。

HostPath简介

• 特征：hostPath 卷能将主机节点文件系统上的文件或目录挂载到 Pod 中。
• 使用场景：
  • 运行需要访问 Docker 内部文件的容器：使用/var/lib/docker的 hostPath。
  • 在容器中运行 cAdvisor：使用/sys/fs/cgroup的 hostPath。
  • 其他使用到宿主机文件的场景。

ConfigMap简介

• 特征：ConfigMap 用于容器的配置文件管理，在被 Pod 引用前需单独定义。它作为多个 properties 文件的应用，类似一个专门存储配置文件的目录，里面存放着各种配置文件。
• 应用场景：ConfigMap 最为常见的使用方式就是在环境变量和 Volume 中引用，能够实现 image 和应用程序的配置文件、命令行参数和环境变量等信息解耦。

Secret简介

• Secret 是一种包含少量敏感信息例如密码、token 或 key 的对象。
• 特征：
  • 在创建、查看和编辑 Pod 的流程中 Secret 暴露风险较小。
  • 系统会对 Secret 对象采取额外的预防措施，例如避免将其写入磁盘。
  • 只有 Pod 请求的 Secret 在其容器中才是可见的，一个 Pod 不能访问另一个 Pod 的 Secret。
• 应用场景：Secret 与 ConfigMap 非常像，都是 key-value 键值对形式，使用方式也相同，不同的是 Secret 会加密存储，所以适用于存储敏感信息。

PV/PVC/SC概念介绍

• PersistentVolume：持久化存储，简称 PV，是 Kubernetes 对存储资源的抽象，属于集群资源，可以由管理员事先创建，或者使用存储类（Storage Class）实现动态供应。
• PersistentVolumeClaim：持久化存储声明，简称 PVC，是用户对存储卷（PV）的申请，属于 Namespace 中的资源。
• StorageClass：存储类，简称 SC，为管理员提供了描述存储 “类” 的方法，通过相应的存储插件（CSI）实现，可根据用户提出的 PVC 动态提供不同性质的 PV。

4、华为云容器服务介绍

​ 在先前的课程当中，我们已经对以Docker及Kubernetes为代表的开源容器技术有了一定的认识。现在就让我们一同学习华为云提供了哪些容器相关的能力。

4.1、华为云容器全栈服务

4.2、华为云容器基础设施服务

如何搭建Kubernetes集群？——使用CCE云容器引擎

CCE云容器引擎

• 云容器引擎（Cloud Container Engine，简称 CCE），是一种托管的 Kubernetes 产品 / 服务，可进一步简化基于容器的应用程序部署和管理，您可以在 CCE 中方便的创建 Kubernetes 集群、部署您的容器化应用，以及方便的管理和维护。
• CCE 提供的集群相关功能包括：购买集群、Kubectl 访问集群、集群弹性扩容、升级集群、删除集群、集群休眠与唤醒、集群监控、集群权限控制等。借助云容器引擎，用户可以在华为云上轻松部署、管理和扩展容器化应用程序。

自建 Kubernetes VS. CCE

对比项	自建 Kubernetes	CCE 容器引擎
易用性	1. 需自行开发和维护与底层基础设施的对接，如计算、存储、网络。2. 需自行适配操作系统，工作量大且稳定性无法保障。3. 需管理多个独立集群。	1. 一键创建 k8s 集群，方便实现弹性伸缩；无中断一键升级，满足生产要求。2. 支持业界主流操作系统。3. 统一管理多集群资源。
可扩展性	需根据业务流量和健康情况，人工确定容器服务的部署，可扩展性差。	灵活集群托管，轻松实现集群节点和工作负载的自动扩缩容，自由组合多种弹性策略，以应对突发流量。
网络	1. 使用开源插件，性能损耗高。2. 新纳管节点时，需要手工配置 VPC 路由。3. 需自行实现与负载均衡等网络服务的对接。4. 外部转发时，通过节点 port，再转发到 pod，流量链路长，并且无法实现会话保持、加权轮询等转发策略。	1. 使用直通网卡，数据面网络零损耗，时延更小，提供商业支持。2. Pod 支持使用安全组隔离，与 ECS 保持一致。3. 对接商用负载均衡服务。4. 外部访问直通容器，零损耗，时延小。
存储	1. 使用开源插件，性能损耗高，读写稳定性差。2. 需要自学容器存储插件机制及使用方法，学习成本高。	专业的容器存储插件，支持 EVS、SFS、OBS 多种类型存储，与 ECS 保持一致。
维护	1. 自行开发基于监控的弹性伸缩能力。2. 自行完成集群升级、版本差异对比等。3. 需要团队中保持容器技术各个领域的专家长期维护。	1. 业界标准的应用运维组件，自动完成日志、监控、告警等信息采集展示。2. 原生支持基于监控的各类弹性伸缩机制。3. 华为容器技术专家持续提供技术支持。
安全	1. 无用户管理体系，无法满足企业安全可靠的诉求，未经授权的用户或攻击者均可访问。2. secret 等敏感数据明文保存，存在安全隐患。3. 应用层实现网络安全控制，存在安全隐患。	1. 提供企业应用的多租户管理和细粒度授权，支持审计日志、证书、秘钥管理等安全保障措施，为用户提供安全的容器集群。2. 使用 AES-256 算法保护 secret 敏感数据，保障 Secret 存储安全。3. 结合 VPC 安全组提供容器网络访问控制能力，可靠性更高。
成本	需要投入人力，构建、运维 K8s 集群，成本开销大。	提供商用支持，但只需支付管理节点资源费用，无额外投入。

**CCE使用方式：**可以通过CCE控制台、Kubectl命令行、Kubernetes API使用云容器引擎服务。

**CCE使用流程：**①创建集群②创建节点或节点池③部署工作负载

一、集群配置（步骤 1）

核心目标：完成集群基础参数与网络架构定义，为后续部署奠定基础。

1. 基础配置
   • 选择 Kubernetes 集群版本（建议选用最新稳定版，如 v1.23+）；
   • 设定集群规模（支持 50/200/1000 节点规格，创建后仅支持扩容）；
   • 开启高可用模式（推荐生产环境启用，多控制节点分布于不同可用区，保障集群稳定性）。
2. 网络配置
   • 选择网络模型（如 VPC 网络 / 容器隧道网络，创建后不可修改）；
   • 配置虚拟私有云（VPC）及子网（集群节点所属网段，创建后不可修改）；
   • 设定容器网段（容器 IP 地址池，需避免与其他资源网段冲突，创建后不可修改）；
   • 配置服务网段（Service 资源 IP 池，不可与节点 / 容器网段重叠，创建后不可修改）。

二、节点 / 节点池创建（步骤 2）

核心目标：配置集群运行节点的计算、存储、网络资源，生成可用节点资源池。

1. 节点基础配置
   • 计算配置：选择节点类型（弹性云服务器 / 裸金属服务器）、实例规格（如通用计算型）、容器引擎（Docker/Containerd）、操作系统（如 EulerOS）及登录方式（密码 / 密钥认证）；
   • 存储配置：配置系统盘（40-1024GB）、数据盘（至少 1 块，支持 HostPath/PVC 等存储场景），可选择磁盘加密或自定义空间分配；
   • 网络配置：关联集群对应的 VPC 及子网，指定节点 IP（默认随机分配），可选配弹性公网 IP（自定义线路与带宽）。
2. 确认与创建
   • 在节点管理控制台核对配置参数，确认无误后执行创建操作，完成后可实时查看节点运行状态（就绪 / 未就绪）。

补充：

1. 节点池定义是 CCE 集群中配置相同的一组节点，由 “节点模板 + 节点池配置” 管理，包含计费模式、节点规格、存储 / 网络配置、Kubernetes 高级参数等信息，可批量管理多个节点。
2. 节点池核心价值：实现节点动态扩缩容

• 自动扩容：当集群资源不足（Pod 无法调度）时，自动新增节点，降低人力成本；
• 自动缩容：当节点空闲满足条件时，自动减少节点，节约资源成本。

三、工作负载部署（步骤 3）

核心目标：将容器化业务应用部署至集群节点，实现业务上线运行。

1. 选择工作负载类型
   • 支持 Kubernetes 标准负载类型：无状态应用（Deployment）、有状态应用（StatefulSet）、守护进程（DaemonSet）等。
2. 选择部署方式
   • 镜像部署：从镜像仓库（华为云 SWR / 第三方仓库）拉取容器镜像（如 nginx:latest）；
   • 模板部署：使用预置应用模板快速部署；
   • YAML 配置部署：通过自定义 Kubernetes YAML 文件精准配置部署参数。
3. 核心部署配置（以无状态应用为例）
   • 基本信息：填写负载名称、指定运行命名空间、设置实例数量；
   • 容器配置：选择目标镜像、配置镜像版本、分配 CPU / 内存资源配额、设置健康检查（存活探针 / 就绪探针）；
   • 服务配置：创建 Service 关联负载，选择访问类型（节点访问 / 负载均衡访问）、配置端口映射（容器端口→服务端口）；
   • 高级配置（可选）：设置升级策略（滚动更新 / 重建）、调度策略（节点亲和性 / 污点容忍）、数据持久化（对接 EVS/SFS/OBS 等存储）。
4. 部署验证
   • 提交部署配置后，在 CCE 控制台查看工作负载运行状态、实例启动进度，通过 Service 访问地址验证应用可访问性。

补充说明

• 全程支持可视化控制台操作，关键参数（如网络模型、网段）创建后不可修改，需提前规划；
• 生产环境建议开启高可用、数据加密、安全组隔离等配置，保障集群与业务稳定性；
• 部署完成后可通过 CCE 控制台进行集群监控、弹性伸缩、日志管理等运维操作。

如何对Kubernetes集群扩容？在不搭建集群的情况下可以运行容器负载吗？——使用CCI云容器实例

CCI云容器实例

一、核心定义

CCI 是Serverless 容器引擎，用户无需管理集群 / 服务器，仅需聚焦容器化业务，实现容器应用 “零运维”。

二、与 CCE 的差异

维度	CCE（云容器引擎）	CCI（云容器实例）
计费方式	按年 / 月 / 小时计费，最小单位 24 小时	按秒计费，支持按需 / 套餐包
资源创建	需先创建集群、节点，再部署负载	直接创建负载，无集群 / 节点管理步骤
使用场景	长期稳定的大规模应用（电商、业务中台等）	批量计算、高性能计算、突发扩容、CI/CD 测试等

三、使用方式与流程

• 使用方式：通过控制台、kubectl、Kubernetes API 直接创建容器负载，仅为实际使用的资源付费。
• 使用流程：准备工作→创建命名空间→上传镜像→创建负载（配置基础 / 访问信息）→访问负载→清理资源。

四、关键特性

1. 智能调度：集成 Volcano 批处理平台，支持多业务混合调度，集群利用率提升 2 倍，每秒可调度 1 万容器。
2. 异构容器：提供 GPU/Ascend 芯片加速能力，适配大数据、AI 训练 / 推理等场景。
3. 安全容器：基于 Kata Containers，每个 Pod 运行在独立微型虚拟机中，实现虚拟化级安全隔离。
4. 秒级计费：按资源实际使用时长（秒级）计费，成本仅为 ECS 包月的 25%-33%。

五、典型应用场景

• AI 计算：支持 GPU/Ascend 加速，降低训练资源成本。
• 高性能批量计算：任务型计算随用随释，免运维。
• 突发流量处理：与 CCE 配合，高峰时快速弹性扩容，低成本适配流量波动。

如何搭建私有容器镜像仓库？——使用容器镜像仓库SWR

容器镜像服务SWR

一、SWR 的定义

是支持容器镜像全生命周期管理的服务，提供界面、Docker CLI、原生 API 等方式上传 / 下载 / 管理镜像，帮助快速部署容器化服务。

二、核心概念

1. 仓库：是存放镜像的空间（类似项目目录），需区分 “注册服务器”（存放仓库的服务器）；分公共仓库（如 Docker Hub）和私有仓库（用户在 SWR 自建的专属仓库）。
2. 容器镜像：是容器的运行基础（容器是镜像的实例），由多个只读二进制层组成，通过统一文件系统整合为单一视图。
3. 组织：用于隔离仓库（对应公司 / 部门），支持给不同用户分配读 / 写 / 管理权限，同一用户可归属多个组织。

三、使用流程

1. 创建组织：按架构构建资源管理结构；
2. 镜像获取：上传自有镜像或使用公共镜像；
3. 应用部署：通过云容器引擎部署镜像；
4. 更新镜像：配置规则自动更新应用镜像。

四、镜像管理操作

1. 上传镜像：
   • 客户端上传：用 Docker 命令（需 Docker 1.11.2+，单 layer 不超 10G）；
   • 页面上传：通过 SWR 控制台（单次最多传 10 个文件，单文件解压后不超 2G，支持 tar/tar.gz）。
2. 共享私有镜像：
   • 仅拥有管理权限的用户可共享，被共享者仅能下载；
   • 被共享者在 “我的镜像> 他人共享” 中查看。
3. 设置镜像加速器：
   • 修改 Docker 的/etc/docker/daemon.json配置文件，添加 SWR 提供的加速器地址（需 Docker 1.11.2+），提升镜像拉取速度。

4.3、容器化上云解决方案

①弹性伸缩：可根据用户的业务需求和预设策略，自动调整计算资源，使云服务器或容器数量自动随业务负载增长而增加，随业务负载降低而减少，保证业务平稳健康运行。

②流量治理：提供开箱即用的Istio服务流量治理能力，用户无需修改代码，即可实现灰度发布、流量治理和流量监控能力。

③混合云：云容器引擎利用容器环境无关的特性，将私有云和公有云容器服务实现网络互通和统一管理，应用和数据可在云上云下无缝迁移，并可统一运维多个云端资源，从而实现资源的灵活使用以及业务容灾等目的。

④DevOps：CCE搭配SWR提供DevOps持续交付能力，能够基于代码源自动完成代码编译、镜像构建、灰度发布、容器化部署，实现一站式容器化交付流程，并可对接已有CI/CD，完成传统应用的容器化改造和部署。

5、微服务架构介绍

​ 下面主要讲述了企业应用架构的演进过程，包括单体架构、SOA架构及微服务架构，然后介绍了典型的微服务框架，包括开源的Spring Cloud框架和华为云CSE微服务引擎，并介绍了通过Spring Cloud huawei接入CSE的过程，最后介绍了华为云应用管理与运维平台ServiceStage的相关功能。

5.1、企业应用架构演进

企业应用架构经历了单体架构→SOA 架构→微服务架构三代演进，每一代都是为了解决前一代的痛点：

一、第一代：单体架构

• 核心形态：所有功能模块打包在一个项目中，共享同一个数据库运行。
• 核心问题：
  • 功能耦合度高，修改一个模块需全量发布；
  • 扩展性差，无法针对高负载模块单独扩容；
  • 维护成本高，系统体积随功能增加越来越臃肿。

二、第二代：SOA 架构（面向服务架构）

• 核心形态：将系统拆分为多个子系统，通过ESB 企业服务总线实现子系统间的服务调用，各子系统有独立数据库。
• 核心问题：
  • 子系统仍较臃肿，升级需替换整个发布包；
  • ESB 总线是性能瓶颈，扩展性有限、成本高；
  • 通信依赖 SOAP 协议，传输效率低；
  • 技术栈单一，子系统需用相同语言开发。

三、第三代：微服务架构

• 核心形态：将功能拆分为独立的细粒度服务（如用户管理、订单服务等），通过服务网关通信，每个服务有独立数据库，同时配套服务监控、治理等工具。
• 核心优势：
  • 服务解耦，可独立开发、部署、扩容；
  • 技术栈灵活，不同服务可采用不同语言；
  • 配套工具完善，支持服务治理、监控等能力。

对比维度	单体架构	SOA 架构（面向服务）	微服务架构
核心形态	所有功能打包为单一应用，共享数据库	拆分为多个子系统（服务），通过 ESB 总线通信	拆分为独立细粒度服务，通过服务网关通信
模块耦合度	极高（代码、部署、数据库完全耦合）	中（子系统间通过 ESB 解耦，子系统内部仍耦合）	极低（服务独立部署、独立数据库，无直接依赖）
开发模式	统一技术栈，团队协作效率低	子系统技术栈需统一，跨团队协作有壁垒	技术栈灵活（各服务可选不同语言 / 框架），独立团队开发
部署方式	全量部署（修改任一模块需整体发布）	子系统级部署（升级需替换整个子系统）	独立部署（单个服务升级不影响其他服务）
扩展性	垂直扩展（仅能扩容整机，资源浪费）	子系统级水平扩展（需扩容整个子系统）	服务级精准扩展（针对高负载服务单独扩容）
通信方式	进程内调用（无跨模块网络开销）	SOAP 协议（基于 XML，传输效率低）	REST/HTTP/gRPC（轻量协议，传输高效）
核心依赖组件	无额外依赖（仅基础应用服务器）	ESB 企业服务总线（核心通信枢纽）	服务网关、服务注册发现、配置中心、监控工具等
维护成本	低（初期）→ 极高（后期系统臃肿，故障定位难）	中（子系统仍需整体维护，ESB 运维复杂）	中（服务独立维护，但需管理分布式生态）
适用场景	小型应用、创业初期、功能简单的系统	中大型企业、业务相对稳定、需跨系统集成的场景	大型复杂系统、业务迭代快、高并发场景（如互联网平台）
核心痛点	耦合高、扩展性差、迭代效率低	ESB 性能瓶颈、子系统臃肿、技术栈受限	分布式复杂度高（服务治理、分布式事务等）

5.2、典型微服务框架介绍

一、常见微服务框架

• Spring Cloud 是一系列框架的有序集合，具有丰富的生态。它利用 Spring Boot 的开发便利性巧妙地简化了分布式系统基础设施的开发，主要功能包括服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。
• ServiceComb 作为功能完善的微服务框架，包括应用框架代码生成、服务注册发现、服务配置管理、服务监控、服务调用追踪等功能，为开发者提供端到端的应用 DevOps 体验。
• Apache Dubbo 是一款高性能、轻量级的开源服务框架，提供了六大核心能力：面向接口代理的高性能 RPC 调用，智能容错和负载均衡，服务自动注册和发现，高度可扩展能力，运行期流量调度，可视化的服务治理与运维。

二、微服务架构模式

微服务需具备的核心能力：RPC 通信、服务发现、配置管理、服务治理（熔断 / 限流）、分布式事务、调用链追踪。

三、Spring Cloud 的核心信息

1. 为什么需要 Spring Cloud？

• 微服务架构的综合性解决方案；
• 整合成熟框架，兼容性 / 稳定性强；
• 社区活跃度高，问题易解决。

2. 优势与缺点

• 优点：Spring 生态背书、基于 Spring Boot 简化开发、功能全面、社区资源丰富、代码简洁实现服务治理。
• 缺点：仅支持 Java 开发，不适合小型独立项目。

3. 核心概念

• 服务注册 / 发现：服务将信息注册到注册中心，消费者从注册中心获取服务实例。
• API 网关：外部请求的统一入口，屏蔽后端服务细节。
• 配置中心：集中管理配置，支持动态更新。
• 负载均衡：将请求分发到多服务实例，提升性能 / 可靠性。
• 容错 / 熔断：服务异常时重试 / 切换实例（容错）；下游压力过大时暂时切断调用（熔断），保障系统可用。
• 链路追踪：记录跨服务请求的调用流程，便于监控 / 排障。

4. 技术实现与部署

• 技术栈：包含网关（Gateway/Zuul）、服务治理（Ribbon/Hystrix）等组件，注册中心可用 Eureka/Consul，配置中心用 Spring Cloud Config。
• 典型部署：前端（桌面 / 小程序）→ Spring Cloud 网关 → 应用服务，支持多网关 / 应用的集群部署。

四、华为微服务生态（Spring Cloud Huawei + CSE）

1. Spring Cloud Huawei

• 简化 Spring Cloud 开发：仅需掌握 Spring/Spring Boot 即可开发。
• 支持 ServiceComb/Nacos 作为注册 / 配置中心，生产可对接华为云服务。
• 核心模块：提供服务发现、配置管理、服务治理、路由、Swagger 等能力。

2. 微服务引擎 CSE

• 企业级云中间件，提供注册发现、服务治理等能力；
• 兼容 Spring Cloud/ServiceComb/Dubbo 等开源生态；
• 支持多语言服务治理、跨框架统一治理，解决架构升级 / 多框架管理问题。

五、微服务代码框架

以producer项目为例，代码结构包含：

• java目录：业务代码；
• resources：配置文件（bootstrap.yml启动配置、application.yml系统配置）；
• pom.xml：依赖管理。

六、CSE 与 Spring Cloud 的关系

CSE 兼容 Spring Cloud 的组件（如服务注册用 CSE 服务中心替代 Eureka），业务代码无需修改，仅需调整依赖 / 配置格式。

七、Spring Cloud Huawei 接入流程

分 3 步完成接入：

1. 引入依赖包：在项目中添加 Spring Cloud Huawei 的依赖；
2. 接入服务注册发现中心：配置 CSE 注册中心地址；
3. 接入配置中心：配置 CSE 配置中心地址。

八、Spring Cloud Huawei 开发操作

1. 引入依赖

• 普通微服务：引入spring-cloud-huawei-dependencies依赖（pom 方式导入）；
• 微服务网关：额外引入spring-cloud-starter-huawei-service-engine-gateway依赖。

2. 配置微服务与 CSE 引擎信息

在配置文件中设置：

• 应用名称、服务版本等基本信息；
• CSE 注册中心地址（servicecomb.discovery.address）；
• CSE 配置中心地址（servicecomb.config.serverAddr）。

3. AK/SK 配置（专业版需配置）

• 在bootstrap.yml中开启 AK/SK 验证，配置华为云账号的accessKey和secretKey；
• 独享版可跳过此步骤。

九、核心能力流程

1. 微服务注册发现

• 流程：
  1. 微服务启动后，将实例信息注册到 CSE；
  2. 微服务调用其他服务时，从 CSE 查询实例信息并缓存；
  3. 运维可通过 CSE 查看实例列表、调用关系等信息。

2. 配置管理

• 流程：
  1. 运维在 CSE 创建配置（按作用域、标签分类）；
  2. CSE 将配置下发到对应的微服务；
  3. 微服务使用统一配置运行。

3. 服务治理

• 开启方式：开发态配置 / 运行态动态修改；
• 流程：
  1. 运维在 CSE 创建业务场景、治理策略；
  2. CSE 将策略下发到微服务；
  3. 微服务应用治理策略（如熔断、限流等）；
• 动态治理：部署后可根据服务运行情况，实时调整治理策略。

5.3、华为云应用管理与运维服务

1. 核心架构

• 功能框架：以微服务框架（ServiceComb/Go Chassis 等）为基础，覆盖生命周期管理、微服务治理、运维监控、环境管理等能力，同时对接开发者 / 商业生态工具 / 组件市场。
• 生态联动：与华为云基础设施（CCE/ECS 等）、存储（OBS 等）、中间件（RDS 等）、运维工具（AOM/APM 等）深度集成。

2. 核心流程

​ 从应用开发（基于 spring_cloud_huawei 等模板）→ 持续交付（流水线绑定源码 / 自动构建部署）→ 应用托管（多基础设施部署）→ 生命周期管理→ 微服务治理，实现全流程自动化。

3. 核心能力

• 多场景部署：支持 CCE（容器集群）、ECS（虚机）、CCI（Serverless 容器）等基础设施，适配微服务 / Web / 移动等应用类型，支持 WAR/JAR/ 镜像等包格式一键部署。
• 环境管理：可将 VPC 下的资源组合为开发 / 测试 / 生产等环境，按环境维度管理资源。
• 全生命周期管理：覆盖应用创建、部署、启动、升级、回退、扩容、停止、删除全流程，结合 CSE 微服务引擎实现注册发现、配置管理、服务治理等能力。
• 运维监控：提供主机 / 集群 / 实例 / 基础设施的多维度监控、告警、统计分析，支撑可视化运维。

**4. 核心价值：**帮助企业简化应用部署、监控、运维、治理流程，加速数字化转型。

6、Istio技术介绍

​ 云平台能使企业受益匪浅，但业务上云同样会给DevOps团队带来压力。开发人员会使用微服务来构建应用以解决可移植性，运维人员也需要管理着越发庞大的混合云和多云的部署环境。在高层次上，Istio有助于降低这些部署的复杂性，并减轻开发团队的压力。

6.1、服务网格概念

服务网格（Service Mesh）是云原生阶段承载微服务理念的技术形态，核心是服务间通信的基础设施层，通过 Sidecar（轻量级代理）与应用部署在一起，对业务无侵入。

1. 技术演进逻辑

微服务的服务治理能力经历了 3 个阶段：

• 早期：治理逻辑内嵌业务代码→代码耦合、运维复杂；
• 中期：抽象到统一 SDK→减少重复，但语言绑定、改造成本高；
• 现在：归一到服务网格→独立进程（Sidecar），实现业务无侵入、语言无关。

2. 核心定义

服务网格是处理服务间通信的专用基础设施层，负责在复杂服务拓扑中可靠传递请求；通过一组 Sidecar 代理实现，对应用透明（无需业务感知）。

3. 关键特点

• 应用通信中间层
• 轻量级网络代理（Sidecar）
• 业务无侵入
• 解耦重试 / 超时、监控、服务发现等治理能力

4. 代表项目

主流包括 Istio（谷歌 / IBM/Lyft 联合开发，功能丰富）、Linkerd（最早项目）、Envoy（数据平面代理）、Consul Connect（服务加密 / 授权）。

5. 对比微服务框架

维度	微服务框架	服务网格
业务侵入性	SDK 侵入式	Sidecar 无侵入
开发语言	语言强相关（如 Java）	语言无关
灵活性	静态配置，需重启更新	动态配置，灵活
升级	业务需处理，难度高	优雅升级简单

6.2、Istio初识

​ Istio 是主流的服务网格项目，由 Google、IBM 等厂商主导，已成为服务网格的事实标准，核心是通过 “数据平面 + 控制平面” 架构实现无侵入的服务治理。

1. 发展历程

• 2017 年由 Google/IBM/Lyft 联合发布，迭代快（每 3 个月一个大版本），1.1 版后达到企业级可用，现已商业成熟；
• 定位是 Kubernetes 之后的另一 “杀手级技术”，目标成为服务网格标准。

2. 整体架构

分为数据平面和控制平面：

• 数据平面：以 Sidecar（基于 Envoy 代理）实现服务间数据通信；
• 控制平面：由 Istiod（集成 Pilot、Citadel、Galley）统一管理，负责配置下发、安全、配置校验等。

3. 核心组件功能

• Pilot：抽象不同平台的服务发现机制，通过 xDS 协议向 Sidecar 下发流量管理配置（负载均衡、路由等）；
• Citadel：服务网格安全组件，通过证书管理实现 mTLS 流量加密、身份认证 / 授权；
• Galley：负责配置校验（Admission Webhook）和配置摄取，向控制平面同步配置。

4. 典型应用场景

• 灰度发布：支持蓝绿发布、金丝雀发布（按权重 / 请求内容分流量）；
• 流量治理：负载均衡、熔断、故障注入等；
• 可视化：监控、调用链追踪、服务拓扑展示；
• 适配电商、政企、视频等业务场景。

6.3、Istio流量治理

Gateway 概述

• Gateway 为 HTTP/TCP 流量配置了一个负载均衡，用于启用一个服务的入口流量。和 Kubernetes Ingress 不同，Istio Gateway 只配置四层到六层的功能（例如开放端口或者 TLS 配置）。绑定一个 VirtualService 到 Gateway 上，用户就可以使用标准的 Istio 规则来控制进入的 HTTP 和 TCP 流量。
• L7 层的路由能力需要与 VirtualService 绑定。

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - bookinfo.com
    tls:
      mode: SIMPLE
      serverCertificate: /tmp/tls.crt
      privateKey: /tmp/tls.key

VirtualService 概述

• VirtualService（VS）：虚拟服务是 Istio 重要的资源对象之一。能够将流量路由到网格中的服务。支持基于权重、http header 条件等优先级的路由，比 Kubernetes service 对于流量的管控更加的丰富，颗粒度更加精细。

apiVersion:networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route: # 75%流量到v3，25%流量到v4
    - destination:
        host: reviews
        subset: v3
      weight: 75%
    - destination:
        host: reviews
        subset: v4
      weight: 25%

DestinationRule 概述

• 常常与 VS（VirtualService）配合使用，VS 定义一些策略将流量路由到某些目标服务，而 DestinationRule 允许用户针对目标服务配置一些负载均衡，异常检测，连接池以及证书。
• DestinationRule 还定义了对应目标主机的可路由 subset。VirtualService 在向特定服务版本发送请求时会用到这些子集。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews # 定义virtualservice名称
spec:
  host: reviews # kubernetes下对应的service
  trafficPolicy:
    loadBalancer:
      simple: RANDOM
  subsets: # 关联pod中version标签
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
      trafficPolicy: # 流量传输策略
        loadBalancer:
          simple: ROUND_ROBIN # 负载均衡策略
  - name: v3
    labels:
      version: v3

下面内容围绕 Istio 的流量治理策略和可观测性能力展开，是服务网格实现服务管控的核心手段：

一、核心流量治理策略

Istio 通过 7 类策略实现精细化流量管控：

1. 服务注册 & 发现

• 逻辑：服务注册到 Kubernetes/Consul/Eureka/ZooKeeper 等平台，Pilot 统一抽象这些服务发现机制，通过 xDS 协议将服务信息下发给 Envoy 代理。

2. 负载均衡

• 配置载体：DestinationRule的trafficPolicy。
• 支持算法：
  • 基础策略：加权轮询、最少请求、随机等（通过simple字段配置）；
  • 高级策略：一致性 Hash（按 Header/Cookie/IP 等）、跨可用域负载（localityLbSetting，支持区域权重分配、故障转移）。

3. 路由（流量切分 / 灰度发布）

• 配置载体：VirtualService的http.route。
• 能力：通过match（匹配 URI/Header/Query 等）规则，结合route的权重设置，实现流量按比例（如 80% 到 v1、20% 到 v2）路由，支撑灰度 / 蓝绿发布。

4. 熔断机制

• 配置载体：DestinationRule的trafficPolicy。
• 能力：
  • 连接管控：设置最大连接数、超时时间（TCP/HTTP 层面）；
  • 异常实例剔除（OutlierDetection）：当实例连续出现 5xx / 网关错误时，自动隔离该实例（可配置隔离间隔、比例）。

5. 故障注入

• 能力：模拟系统故障（识别薄弱环节），支持两种类型：
  • 延迟注入：指定比例请求添加延迟（如 20% 请求延迟 5 秒）；
  • 错误码注入：指定比例请求返回错误码（如 10% 请求返回 500）。

6. 限流

• 支持两种方式：
  • 中心集中式：依赖限流服务（Rls）统一管控流量；
  • 本地限流：由 Envoy 代理在本地直接限制流量。

7. 失败重试

• 配置载体：VirtualService的retries。
• 能力：设置重试次数、每次重试超时、重试触发条件（如 5xx / 连接失败），还支持跨地域实例重试。

二、可观测性（监控）

Istio 以非侵入方式提供三类遥测能力：

• Metrics：应用流量粒度的监控统计（如 QPS、延迟）；
• Distributed Traces：分布式调用链追踪，可视化服务拓扑；
• Access Logs：记录请求的详细访问日志（如请求方法、状态码、客户端信息）。

6.4、应用服务网格ASM介绍

华为云 ASM 是基于开源 Istio 的服务网格平台，深度对接华为云容器引擎（CCE），提供非侵入式微服务治理能力，核心信息如下：

一、核心定位与基础能力

• 是基于 Istio 的企业级服务网格，支持容器 / 虚拟机 / 裸金属等多集群环境；
• 提供全生命周期治理：负载均衡、熔断、限流等流量管控，内置金丝雀 / 蓝绿 / 灰度发布流程，同时支持无侵入的监控（流量拓扑、调用链）。

二、关键特性

覆盖 7 大核心能力：灰度发布、流量治理、安全、可观察性、多集群服务治理、兼容性拓展、网络数据面服务框架。

三、典型应用场景

1. 服务灰度发布：
   • 全流程自动化：版本一键部署、流量一键切换，支持按比例 / 请求内容（Cookie/OS）/ 源 IP 配置灰度策略；
   • 支持金丝雀、蓝绿发布，结合监控实现发布过程可视化、可回滚。
2. 服务流量管理：
   • 非侵入式管控：动态配置负载均衡（如一致性 Hash）、版本流量切分、服务保护（限流 / 熔断）、故障注入等，用户无需关注治理逻辑。
3. 端到端透明安全：
   • 提供多集群 / 多云 / 多基础设施的透明认证，支持双向 TLS 和细粒度访问授权，业务无感知。
4. 服务运行监控：
   • 结合 APM 服务，实现微服务级流量监控、调用链追踪、异常定位，支持流量 / 治理策略可视化。
5. 传统微服务 SDK 结合：
   • 支持遗留微服务框架迁移：无需修改业务代码，通过配置逐步剥离 SDK 治理能力到 ASM 的 Envoy 代理，统一用 ASM 控制面管理服务发现与治理规则。

7、云原生DevSecOps介绍

​ 下面内容主要介绍敏捷软件开发、DevOps思想及华为云HE2E DevOps框架，并对CodeArts IDE Online、低代码开发等开发模式进行阐述。

7.1、敏捷开发及DevOps思想

一、企业研发的核心挑战

新形势下企业面临 3 类压力：

1. 交付效率：小特性 1 天交付、版本 2 周交付，需快速迭代；
2. 协作复杂度：跨地域协作多、环境不一致，部署发布复杂；
3. 可靠性与安全：7×24 运行、公有云服务需高安全，核心数据有风险。

二、敏捷开发：应对挑战的研发模式

1. 核心逻辑

软件研发模式从传统（主机 / 客户端）演进到敏捷 / DevOps，核心是：

• 价值驱动：优先高价值工作；
• 持续研发：小步快跑、快速闭环；
• 拥抱变化：按需发布；
• 客户参与：运营驱动开发。

2. 敏捷价值观（敏捷宣言）

4 大核心价值（重视前者）：

• 个体和互动 > 流程和工具；
• 工作的软件 > 详尽的文档；
• 客户合作 > 合同谈判；
• 响应变化 > 遵循计划。

3. 敏捷 vs 传统瀑布模式

维度	瀑布模式（计划驱动）	敏捷模式（价值驱动）
核心逻辑	固定需求、估算资源 / 时间	聚焦价值、灵活调整特性
优势	流程规范	高可视性、高适应性，早出价值、早控风险

4. 敏捷管理方法：Scrum

• 发展历程：源于 1986 年生产管理理念，1993 年应用于软件研发，2001 年成为敏捷方法之一。
• 三大特点：关注当下（可能性的艺术）、团队自组织 / 自管理（放权）、面对面沟通（提效）。
• 团队角色：
  • Product Owner（PO）：1 人负责产品待办清单、优先级排序、ROI；
  • Scrum Master：保障 Scrum 规范落地、消除障碍、赋能团队；
  • 团队：5-9 人多功能小组，自我管理、全职参与。

三、DevOps：打通研发与运维的协同模式

1. 核心定义

是文化 + 流程 + 工具的集合，打破 Dev（开发）与 Ops（运维）的孤岛，通过自动化实现软件交付 “更快、更频、更可靠”。

2. 生命周期

覆盖 “计划→编码→构建→验证→发布→部署→运维” 全流程，核心是：

• 打破壁垒：Dev 与 Ops 协作分享；
• 关键支撑：持续集成、持续交付、自动化、监控；
• 理念融合：结合敏捷（快速迭代）、精益（优化价值）。

3. 与敏捷的关系

DevOps 是敏捷的延伸，其知识体系包含敏捷管理、持续交付、IT 服务管理、精益管理，覆盖从计划到运营的全生命周期。

7.2、华为云HE2E DevOps框架与CodeArts介绍

HE2E DevOps框架——集合业界先进理念，华为30年研发经验，可操作可落地的端到端一站式开发方法论和工具链。

华为云CodeArts（一站式DevOps平台）

**DevSecOps概念：**DevSecOps是在DevOps实践基础上，在持续构建的各阶段引入针对产品的安全保障活动，强调开发、运维/运营、安全团队的融合运作，是DevOps的增强和完善。

**DevSecOps的价值和实践：**权衡DevOps速度与现有安全要求的需求催生了一个名为DevSecOps的模型。DevSecOps基于”安全问题，人人有责“的原则。它强调应用程序开发人员可以怎样把安全检查与他们的集成和部署流水线构建到一起。

软件交付的挑战：一个系统的修改带来涟漪效应，受影响系统随着系统复杂度增加而呈级数增长。同时，被影响的系统可能还会造成二次涟漪效应，给需求规划，架构设计，开发过程，测试过程等整个软件开发过程造成极大的困扰（业务响应慢、系统复杂度增加、错误不能隔离、应用扩展能力差）。

通过自动化实现软件快速部署和发布：开源的自动化工具；”一切即代码“；统一的平台、流水线部署与发布；实现一定功能的子系统，解耦，拼接。

**持续集成：**持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译、发布、自动化测试）来验证，从而尽快地发现集成错误（Martin Fowler）。

**持续交付：**持续交付（英语：Continuous Delivery，缩写为CD），是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以发布的状态。它的目标在于让软件的建置、测试与释出变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。同时持续交付以持续集成为基础。

持续部署

• 持续部署（continuous deployment）是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。
• 持续部署是一种软件工程方法，意指在软件开发流程中，以自动化方式，频繁而且持续性的，将软件部署到生产环境中，使软件产品能够快速的发展。持续部署可以与持续集成与持续交付的流程整合在一起，为演进到 DevOps 做准备。

持续集成与持续交付

• 持续集成强调开发人员提交了新代码之后，立刻进行构建、单元测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。
• 持续交付是持续集成的延伸，将集成后的代码部署到类生产环境，确保可以以可持续的方式快速向客户发布新的更改。如果代码没有问题，可以继续手动部署到生产环境中。

持续部署与持续交付

• 持续部署与持续交付
  • 持续部署意味着所有的变更都会被自动部署到生产环境中。持续交付意味着所有的变更都可以被部署到生产环境中，但是出于业务考虑，可以选择不部署。如果要实施持续部署，必须先实施持续交付
• “持续交付并不意味着每一次变化都要尽快部署到生产环境中，而是意味着每一次变化都是随时可以部署的。”——Carl Caum

持续集成与部署（CI/CD）

1. 核心概念：
   • 持续交付：变更 “可随时部署”（业务可选不部署）；持续部署：变更 “自动部署到生产”（需先做持续交付）。
2. CodeArts 的 CI/CD 能力：
   • 编译构建：解决传统构建 “环境耗时、硬件差、资源闲置” 等问题，支持 10 + 语言 / 20 + 框架，通过缓存、增量构建提速，且可扩展 / 可追溯。
   • 部署服务：替代传统 “手动部署”（易出错、低效），实现自动化部署，支持物理机 / 虚机 / 容器 / 函数等多形态，适配 Tomcat/SpringBoot 等多技术栈，且支持回滚、并行执行、权限管控。
   • 自动化流水线：可视化编排任务（代码检查、构建、部署等），支持代码提交 / 定时 / 人工触发，带质量门禁、阻塞点识别等能力。

二、DevOps 运维体系

1. 运维特点：以 “高可用、高成功率、高效率” 为目标，实现可回滚、自动化运维、应用管理。
2. 华为云运维方案：
   • 覆盖 “基础设施→应用层→应用性能→业务分析” 全层级，采集资源 / 应用 / 用户体验数据，通过拓扑、调用链、监控等功能实现全面运维。
3. CodeArts+AOM 工具：
   • CodeArts 运维：提供组件、节点等监控仪表盘；
   • AOM（应用运维管理）：一站式平台，实时监控应用 / 云资源，通过可视化功能识别故障，统一管理资源、APP、服务等。

7.3、云端编程与华为云CodeArts IDE Online

1. 传统开发场景的常见问题

本地开发存在三类典型痛点：

• IDE：需手动下载、安装；
• 文件：需下载资源、配置 Git；
• Runtime（运行环境）：需手动配置，且难保证团队环境一致性。

2. 华为云 CodeArts IDE Online 的核心优势

作为云端开发环境，它解决了本地开发的痛点，具备四大特点：

• 全云化：轻量化移动开发能力，云端资源一键获取 / 配置；
• 更快速：基于云容器分秒级获取环境，无需复杂配置即可标准化；
• 重实用：支持 40 + 语言、覆盖编码 - 构建 - 调试 - 预览全流程；
• 可扩展：企业级权限 / 资源管控，通用插件机制支持业务扩展。

同时提供按需获取的开发环境（资源可选、技术栈支持、代码自动导入）、全面的开发体验（多语言高亮、云端构建调试）、开放的解决方案平台（多场景支持、华为云能力集成）。

3. 在 DevOps 工具链中的定位

CodeArts IDE Online 是 DevOps “编码” 环节的核心工具，嵌入完整 DevOps 流程：

• 覆盖Dev 侧全流程：从项目管理（看板 / Scrum）→配置管理（代码托管 + WebIDE）→编译构建→代码检查→测试→发布；
• 衔接Ops 侧流程：支持后续部署（环境管理 / 自动化部署）、运维（监控 / 反馈）、运营（数据分析）；
• 配套工具链：含流水线（可视化 / 自定义）、测试（自动化 / 压力测试）等能力，实现研发全链路闭环。

7.4、低代码/无代码开发与华为云AstroZero

1. AstroZero 的核心定位

它是云化 Low code 开发平台，提供 “无码化 + 低码化 + 多码化” 的开发模式：

• 通过 “拖、拉、拽” 可视化工具（页面编排、逻辑编排、数据对象配置），屏蔽技术复杂度；
• 支持从设计态（AstroZero Designer）生成元数据 APP，再通过运行态（AstroZero Engine）部署到华为公有云 / 私有云；
• 覆盖 5 大场景入口：轻应用构建、应用配置、行业应用构建、DMAX 构建、移动小程序。

2. 开发流程：全在线、所见即所得

支持 “Anywhere、Anytime” 的全在线开发交付，流程覆盖：

• 开发环境：在线完成数据模型定义、API 封装、页面编排等；
• 测试环境（SandBox）：在线打包、调测、修改；
• 预生产环境：在线升级、UAT 测试；
• 生产环境：支持云上 / 云下 / 容灾部署，提供调用链诊断、一键部署等运维能力；
• 核心优势：环境在线分配，沙箱环境可一键复制，真实环境实时模拟。

3. 能力覆盖：适配不同角色，降低开发门槛

围绕 “业务理解 + 技术掌控”，适配 4 类角色，提供 3 种开发模式：

• 零代码（No-Code）：面向业务管理员，通过友好配置快速开发简单应用；
• 低代码（Low Code）：面向业务开发者，结合资产 / 模板 + 线上配置 / 编码，全栈开发降门槛；
• 全代码（Full-Code）：面向知识开发者，支持资产分层开发、原生微服务接入，沉淀模板供其他角色复用；
• 最终价值：降低业务创新门槛，实现快速应用开发交付，同时支持个性化扩展。

7.5、无服务器编程与华为云FuntionGraph

计算架构演进

什么是 Serverless

• Serverless 是一种新型的云计算代码开发及执行模式。在这种模式中，云平台负责管理微服务函数的启动、执行、及删除，并自动配置调度函数执行所需的计算资源，网络资源，安全资源，HA 等。函数开发者只需专注于函数本身的逻辑开发，而不需考虑如何调度函数运行时所需的虚机或容器，如何建立函数所需的网络通讯等。云平台会监控函数执行的触发事件源。当事件发生时实时启动函数的执行。
• 函数开发者也不需要考虑或管理扩容。云平台会在并发事件情况下自动扩容、调度多个计算资源做并行函数执行，在并发事件结束时自动缩容。
• Serverless 以计量方式收费。只收取函数运行时计算资源的使用费。

Serverless 分类

• Serverless 两种形态
  • Backend-as-a-Service (BaaS)，它是基于 API 的第三方服务，可替代应用程序中的核心功能子集。因为这些 API 是作为可以自动扩展和透明操作的服务而提供的，所以对于开发人员表现为是 Serverless。
  • Functions-as-a-Service (FaaS)，通常提供事件驱动计算。开发人员使用由事件或 HTTP 请求触发的 function 来运行和管理应用程序代码。开发人员将代码的小型单元部署到 FaaS，这些代码根据需要作为离散动作执行，无需管理服务器或任何其他底层基础设施即可进行扩展。

Serverless 应用场景特征分析

• Serverless 主要用户场景有以下几个特点：
  • 短时间任务为主
  • 大部分时间请求平缓，偶然有突发流量
  • 基于事件驱动
  • 无状态，无会话保持
  • …
• 如下是一些典型的 Serverless 应用场景：
  • 电商
  • IoT 数据分析处理
  • 多媒体数据存储时的实时处理
  • 移动后端
  • ……

**Serverless价值：**秒级快速上线；毫秒级弹性伸缩，天然高可用；免运维；函数代码即服务；按实际使用100毫秒计费。

华为云 Serverless 方案 ——FunctionGraph

一、核心定位

FunctionGraph 是华为云的 Serverless 函数计算产品，以 “函数工作流” 为核心，通过关联各类云服务实现事件驱动的无服务器开发。

二、关联服务生态

可对接华为云多类服务，覆盖功能、存储、消息、监控等场景：

• 功能类：OCR 单据服务、IRS 图片识别、MLS 机器学习等；
• 存储 / 数据类：对象存储 OBS、DDS 文档数据库、DIS 数据接入等；
• 消息 / 调度类：SMN 短消息、Timer 定时器、DMS 分布式消息等；
• 管控类：CTS 云审计、CES 云监控、API 网关等。

三、核心能力

1. 多语言支持：兼容 Java、Python、Node.js、Go 等；
2. 毫秒级弹性伸缩：应对突发流量自动扩缩容；
3. 丰富触发器：支持 SMN、OBS、DIS 等多种事件触发；
4. 多函数多事件编排：实现复杂工作流；
5. 长时运行函数：支持长时间执行的任务；
6. 有状态函数：可保持状态的函数能力。

HCCDA-AI 人工智能入门级开发者认证课程笔记

1、人工智能概览

模块一：人工智能基础

下面主要讲述人工智能的定义、发展历史、产业生态、落地挑战和发展趋势。

1.1、人工智能定义

​ 什么是人工智能？——**人工智能（Artificial Intelligence）**是研究、延伸和扩展人的智能的理论、方法、技术及应用系统的一门新的技术科学。

强人工智能 vs 弱人工智能

• 强人工智能：强人工智能观点认为有可能制造出真正能推理（Reasoning）和解决问题（Problem_solving）的智能机器，并且，这样的机器将被认为是有知觉的，有自我意识的。可以独立思考问题并制定解决问题的最优方案，有自己的价值观和世界观体系。有和生物一样的各种本能，比如生存和安全需求。在某种意义上可以看作一种新的文明。
• 弱人工智能：弱人工智能是指不能制造出真正地推理（Reasoning）和解决问题（Problem_solving）的智能机器，这些机器只不过看起来像是智能的，但是并不真正拥有智能，也不会有自主意识。

人工智能三阶段

AI、机器学习、深度学习的关系：

1.2、人工智能发展历史

1. 人工智能发展主线：从 “感知理解” 到 “生成创造”

• 发展历程（三叠浪）：从 1956 年达特茅斯会议起步，经历符号 / 联结 / 行为主义等理论阶段，后续通过专家系统、深度学习等技术演进，2022 年 ChatGPT 等生成式 AI 推动其进入 “生成创造世界” 阶段。
• 关键里程碑：1997 年深蓝胜人类、2007 年视觉识别超人类、2020 年 AlphaFold、2022 年 ChatGPT/Stable Diffusion 等。

2. 第三次热潮：生成式 AI

• 定义：通过机器学习从数据中学习要素，生成全新原创内容（Gartner 定义）。
• 趋势：2023 年 20% 内容将由生成式 AI 创建，2025 年其产生数据占比将达 10%；当前处于萌芽期，预计 2-5 年内规模化应用。
• 典型应用：覆盖文本 / 代码 / 图像 / 语音 / 视频 / 3D 生成等（如 ChatGPT、DALL・E2）。

3. 从分析式 AI 到生成式 AI 的升级

• 分析式 AI：从数据中学习，做分类 / 预测等任务（代表技术：经典机器学习、CNN 等；应用：推荐系统、人脸识别）。
• 生成式 AI：在学习数据分布基础上，创造新样本（代表技术：Transformer、Diffusion；应用：文字创作、代码生成、跨模态生成），核心是 AIGC（AI 生成内容）。

4. AIGC 的发展：内容生产方式的迭代

• 演进：从 PGC（专业生产）、UGC（用户生产）升级到 AIGC（AI 生产）。
• 技术路径：图像生成（GAN→VAE→Diffusion）、语言对话（GPT-3→ChatGPT），未来将向 “能说会道” 的多技术融合方向发展。
• 前景：量子智库预测 2030 年 AIGC 市场规模超万亿，文字生成图像 / 视频是核心场景。

1.3、人工智能产业生态

一、市场规模：高速增长

• 全球 AI 市场 2024 年预计达 30610 亿美元；
• 中国 AI 核心产业规模将从 2020 年的 1500 亿元，快速增长至 2030 年的 10000 亿元，处于加速发展阶段。

二、产业图谱：分层覆盖全链条

分为基础层、技术层、应用层：

• 基础层：含 AI 模型生产（开发框架 / 平台）、算力基础（芯片 / GPU）、资源管理（数据 / 云服务）；
• 技术层：覆盖关键技术（机器学习 / 深度学习）、通用技术（计算机视觉 / NLP 等）；
• 应用层：落地到城市 / 企业 / 消费者场景（如 AI + 安防 / 医疗 / 工业等）。

三、技术架构：从底层到应用的完整链路

从下到上分为：

1. 基础架构层：含大数据（从原始数据到智慧的加工）、计算机硬件（CPU→GPU→Ascend AI 芯片，专攻 AI 算力）；
2. 算法层：机器学习、神经网络 / 深度学习（如前馈 / 反馈 / 图网络）；
3. 技术方向：计算机视觉（内容审核 / 检测 / 分类）、语音处理（唤醒→识别→理解→生成）、自然语言处理（翻译 / 分析 / 交互）等；
4. 行业应用：覆盖金融、医疗、工业、农业等多领域。

四、核心应用领域：多行业落地

• 智慧城市：实现全城感知、预警、协同（如交通 / 应急监控）；
• 金融：智能风控、支付、投顾等全流程 AI 赋能；
• 零售：覆盖设计、生产、供应链、线下零售全环节；
• 医疗：语音病历、影像分析、虚拟医生等提效降本；
• 农业：通过数据分析、无人机、机器人实现智慧种植、降本增效。

1.4、人工智能落地挑战

**数据的挑战：**①数据获取：数据积累不足、数据质量差、数据安全合规、数据归属权。②数据治理：多源异构数据、非结构化数据、海量数据存储与应用。③数据标注：小场景数据采集、复杂业务场景理解、数据安全。

**缺乏解释性：**①AI已经在大量关键系统中运行，并且开始进入到很多业务的核心数据处理体系。但是，对于AI的核心运行机制，依然没有彻底研究清楚。②深度学习系统的弱解释性给现有的AI系统带来了安全性、稳定性的挑战，如何确保AI不会失控，避免恶性事件发生，是目前AI研究领域重要的课题。

**算法的偏见：**算法的偏见主要源于数据的偏见。

​ 我们在用人工智能算法做决策时，算法可能是根据已有的数据，学会歧视某一个体。如根据种族，性别或其他因素，作出有歧视倾向的决策。即使种族或性别等因素被排除在数据之外，算法也能够利用人的姓名或地址中的信息做出有歧视倾向的决定。

​ 比如：①用一个听起来像非洲裔美国人的名字进行搜索可能会产生一个用于查询犯罪记录的工具的广告，而其他名字搜索这种情况不太可能发生。②在线广告商倾向于向女性用户展示商品价格更低的广告。③谷歌的图片软件曾错将黑人的图片标记为 “大猩猩”。

**隐私问题：**现有的人工智能算法都是数据驱动，我们需要大量的数据来训练模型。我们每天在享受人工智能带来的便捷的同时，例如 Facebook，谷歌，亚马逊，阿里巴巴等科技公司在获取大量的用户数据。而这些数据会揭露我们生活的方方面面（如政治、宗教和性等）。

1.5、人工智能发展趋势

当前人工智能的发展趋势围绕数据、算力、算法、场景四大核心要素，呈现出 “基础能力升级 + 技术融合深化 + 产业应用落地” 的整体方向，具体包括：

1. 数据层面：服务成熟化 + 安全共享化

• 基础数据服务产业已成熟，形成 “上游数据生产 - 中游标注工具 - 下游 AI 研发” 的完整产业链，覆盖科技公司、行业企业等多类需求；
• 采用联邦学习等技术实现 “数据可用不可见”，在保障隐私的前提下打破数据孤岛，解决模型训练的数据瓶颈。

2. 算力层面：端边云协同 + 硬件专用化

• 算力布局向 “云端（大模型训练）+ 边缘（低延迟场景）+ 终端（移动设备）” 全场景延伸，通过专用 AI 芯片（如昇腾系列）提升不同场景的算力效率，降低部署门槛。

3. 算法层面：大模型主导 + 技术轻量化

• 大模型成为核心方向：以千亿级参数的大型语言模型（LLM）为代表，通过 “预训练 + 精调” 模式实现多任务通用能力，且向行业定制（如煤矿、电力大模型）和多模态融合（文本 + 视觉 + 音频）演进；
• 轻量化适配落地：通过模型压缩（剪枝、量化等）技术，让大模型能部署到边缘 / 终端设备，平衡性能与资源消耗。

4. 产业应用层面：渗透加速 + 场景深化

• 大模型将快速重塑产业格局，未来 2 年预计覆盖 50% 以上行业核心场景，从 2C 的现象级应用（智能对话、内容生成），逐步向 2B 的行业场景（金融风控、医疗诊断、城市大脑）深入；
• 开发门槛降低，主流框架（MindSpore、PyTorch 等）向 “易用化” 演进，推动 AI 技术在更多垂直领域落地（如心理陪伴、车险定损、办公自动化）。

整体来看，AI 正从 “单点技术突破” 转向 “全链路生态构建”，通过基础能力的协同升级，实现从 “实验室模型” 到 “行业规模化应用” 的跨越。

模块二：华为AI解决方案

下面主要讲述华为全栈全场景AI解决方案以及华为云企业智能AI开放能力。

★华为全栈全场景AI解决方案，全栈包括IP和芯片、芯片使能、框架、应用使能，全场景包括消费终端、云、边缘计算、IoT行业终端。

1.1、华为全栈全场景AI解决方案介绍

1.2、华为云企业智能AI开放能力介绍

一、技术底座：全栈自主可控的 AI 开发能力

1. 算力与芯片层：基于昇腾系列芯片构建 AI 计算集群，通过 CANN（算子库） 沉淀 1400 + 算子、支持 900 + 主流算法，实现极致性能（如 BERT 训练速度提升 80%）。
2. 框架与开发平台：
   • MindSpore：原生支持大模型开发，千亿参数模型调优时间缩短 60%，支持端 - 边 - 云统一训练 / 推理；
   • ModelArts：一站式 AI 开发平台，支持模型迁移 / 开发 / 调优，提供全流程 MLOps，数据标注效率提升 2-5 倍，资源利用率超 90%。
3. 工具链：通过MindX SDK沉淀行业知识，将开发周期从 “2 人月” 压缩至 “2 人天”，降低行业 AI 开发门槛。

二、生态与资源：开放兼容的 AI 市场与大模型能力

1. AI Gallery 生态：汇聚 8700 + 贡献者、5500 + 企业、2000 + 行业资产，提供模型 / 数据 / 应用的共享与交易，实现 “开发者生产 - 使用者订阅” 的生态闭环。
2. 盘古大模型：采用 “L0 基础大模型 + L1 行业大模型 + L2 细分场景” 三层架构，适配各行业 Know-how，助力开发效率提升 10 倍、场景覆盖率提升 10 倍。
3. 通用 AI 能力：基于大模型开放 OCR、NLP、图像搜索等丰富 API，全面适配昇腾算力，提供高性能的通用 AI 服务。

三、行业落地：场景化智能体与商业闭环

1. 行业智能体：针对城市、交通、工业、医疗等场景，打造专属智能体：
   • 城市智能体：实现 “一网统管”，提升业务协同效率；
   • 工业智能体：在焦化、炼钢等场景降低成本（如板材切割年省 4000 万）；
   • 医疗智能体：支持靶基因预测、药物设计等 AI 辅助研发。
2. 商业闭环：通过 “开发飞轮（数据→大模型）+ 应用飞轮（大模型→场景）” 双轮驱动，实现数据、模型、场景的循环迭代，持续创造价值。
3. AI 求解器（天筹）：国际领先的运筹优化工具，在供应链、港口计划等场景提升资源利用率（如库存周转率提升 39%）。

四、核心优势

• 自主可控：从芯片到应用全栈自研，保障技术安全与供应链稳定；
• 高效易用：通过工具链、大模型、SDK 降低开发门槛，加速企业 AI 落地；
• 场景深化：结合行业 Know-how，提供 “开箱即用” 的场景化方案，直接创造业务价值。

1.3、昇腾云服务实践案例

核心逻辑：以 “全栈 AI 技术底座 + 行业定制方案”，助力 AI 规模化落地，核心价值体现为全栈自主可控、高效规模化、行业定制化三大优势。

典型案例：

1. 某城实验室：依托 4096 颗昇腾 AI 处理器 + 2048 颗鲲鹏 CPU 构建的 1024P 国产全栈 AI 算力，结合 MindSpore 框架与 ModelArts 平台，研发 “鹏程” 系列大模型矩阵，加速科研创新并带动数字经济生态。
2. 某能源集团：基于昇腾全栈国产化方案，构建分层 AI 能力，模型准确率、泛化能力分别提升 15%、30%，矿山主运皮带异物识别率达 98%，检测效率提升 10-100 倍，实现 AI 工业化落地。
3. 华为智能汽车 BU：通过昇腾云训练平台解决数据量大、性能衰减等问题，分布式训练效率提升 20%，任务故障率低于 0.5%。

2、人工智能应用集成需求分析

2.1、AI技术发展现状及技术挑战

2.1.1、计算机视觉发展现状及技术挑战

什么是计算机视觉？——计算机视觉是使计算机能理解采集设备的图像视频的一门学科。形象地说，就是给计算机安装上眼睛（照相机）和大脑（算法），让计算机能够感知环境。

计算机视觉可解决的问题：识别人、物、场景；以图搜图；障碍物的躲避和检测；制高点监控应用。

计算机视觉任务划分：

• 初级视觉：超分辨率重建、图像修复。
• 中级视觉：物体检测、图像分割。
• 高级视觉：图像文本描述、图像问答技术、图像检索、视觉追踪、动作识别。

计算机视觉的三个层次，对应从 “图像处理” 到 “图像理解” 的递进过程：

1. 底层（图像处理）：基于像素层面处理，比如获取原始图像的像素信息（如老虎照片的像素数据）。
2. 中层（图像分析）：提取图像的特征信息，比如识别出图像中的边缘、朝向、纹理（如老虎的轮廓、条纹纹理）。
3. 高层（图像理解）：实现对内容的语义认知，比如识别出老虎、水、草地、沙滩等物体和场景。

中级计算机视觉的任务：

• 分类（Classification）：解决”是什么？“的问题，即给定一张图片或一段视频判断里面包含什么类别的目标。
• 检测（Detection）：解决“是什么？在哪里？”的问题，即定位出这个目标的位置并且知道目标物是什么。
• 分割（Segment）：分为实例分割（Instance Segment）和语义分割（Semantic Segmentation），解决“每一个像素属于哪个目标物或场景”的问题。

计算机视觉面临的挑战：

难点	举例说明
光照变化	拍照曝光和拍照过暗
尺度变化	一辆车在一幅图像中占比可能超过 80%，也有可能小于 10%
遮挡	部分被遮挡的行人、车辆、自行车等
形变	人有站立、弯腰、下蹲、平躺等多种姿势
运动模糊	当目标在视频中运动过快时，画面会模糊
平面内旋转	正放、倒放、侧放的一本书
超平面旋转	左右转头、上下点头的人脸检测
背景干扰	水面下，鹅卵石上方的一条鱼
低分辨率	1024×1024 分辨率原图中一辆 10×10 的汽车，resize 到 256×256 之后，车的像素只有 2×2

2.1.2、自然语言处理发展现状及技术挑战

什么是自然语言处理（Natural Language Processing，NLP）？——自然语言处理就是利用计算机为工具对人类特有的书面形式和口头形式的自然语言的信息，进行各种类型处理和加工的技术。

用机器处理人类语言的理论和技术，让计算机能够理解和生成人类语言。

**自然语言处理应用场景：**智能问答、舆情分析、文本分类、实体抽取、摘要生成、AI写诗、机器翻译、内容审核、文本互译……。

中文自然语言处理面临的挑战：

难点	举例说明
句法问题	苹果，我吃了；我吃了苹果；≠ 苹果吃了我
语义问题	苹果不吃了 这个人真牛 这个人眼下没些什么
歧义问题	自动化研究所取得的成就 自动化／研究所／取得／的／成就 自动化／研究／所／取得／的／成就 门把弄弄坏了 门／把／手／弄／坏／了 门把手／弄／坏／了
结构歧义	今天中午吃馒头 今天中午吃食堂
上下文语境	这幅画很有意思 你这个人太不够意思，我都不知道你是什么意思，如果你明白他的意思，就该意思意思

2.1.3、语音处理发展现状及技术挑战

​ 语音交互是通过 “语音识别→语言理解→对话管理→语言生成→语音合成” 的流程，让机器把用户语音转化为文本理解后，再生成语音回复的人机交流方式。

**语音交互应用场景：**实时字幕、会议记录、电话回访、语音搜索、语音导航、有声阅读……。

语音交互面临的挑战：

难点	说明
输入不统一	不同说话人：发音器官，口音，说话风格；同一说话人：不同情绪状态，不同时间，身体状况变化
噪声影响	背景噪声；传输信道，麦克风收音设备质量
模型有效性	训练数据少，脏数据多；输出维度高，搜索空间大；难以融合心理学、语言学等外部知识

2.2、AI应用需求分析

传统软件应用开发与AI应用开发对比：

对比项	传统软件应用开发	AI 应用开发
需求分析	①明确问题和用户需求②可行性分析	① 明确问题和用户需求② 可行性分析，决策是否引入和引入哪些人工智能
产品设计	设计软件产品原型	设计业务方案原型
架构设计	① 生成和分解产品需求② 确定技术方案③ 完成系统架构设计④ 完成模块设计	① 生成和分解产品需求（包括评估人工智能需求）② 确定人工智能技术方案和系统技术方案③ 完成系统架构设计④ 完成模块设计
开发	① 编写 / 审核代码② 单元测试③ 审核和发布版本	算法、模型和应用开发：① 准备数据② 选择或开发 AI 算法③ 训练和调优 AI 模型④ 重复以上步骤，获得所有可用模型⑤ 编排模型，生成人工智能应用。 系统开发：① 编写 / 审核代码② 单元测试③ 审核和发布版本
测试	集成测试、系统测试、验收测试	集成测试、系统测试、验收测试（系统维度和模型维度）
发布	① 软件应用发布② 资料发布	① AI 应用发布② 资料发布
运维	① 软件应用维护② 资料维护	① AI 应用维护（尤其要关注数据和模型的维护）② 资料维护

AI 应用开发需求分析步骤

• 需求背景：在什么场景下遇到了什么问题？为什么要用 AI 来解决该问题？
• 需求价值：为什么要解决该问题？解决该问题可以带来什么价值？
• 需求描述：期望怎样解决该问题？业务要求的关键指标是怎样的？
• 问题抽象：将现实场景的业务问题进行建模、抽象，转化为 AI 技术领域的问题
• 可行性分析：是否有数据？业界是否有对应的 AI 算法？精度 / 性能指标能否达到？成本能否接受？

3、华为云EI—API服务介绍

图像搜索API服务介绍：

下面主要讲述华为云EI的图像搜索API服务的功能特点、应用场景以及对应的实践案例。

3.1、图像搜索概述

什么是图像搜索？——图像搜索是基于深度学习与图像识别技术，结合不同应用业务和行业场景，利用特征向量化与搜索能力，从而实现从指定图库中搜索相同或相似的图片。

3.2、图像搜索应用场景

1. 商品图片搜索

• 功能：用户上传商品图片，在商品库中匹配同款 / 相似商品，支持秒级响应亿级图像搜索、实时更新数据。
• 价值：省去文字描述，简化搜索流程，提升购物体验。

2. 商品推荐 & 侵权图片定位

• 商品推荐：基于图片搜索结果，进行同款 / 相似商品的销售或推荐。
• 版权图片搜索：从海量图库中快速定位侵权盗用的版权图片，帮助摄影 / 设计类网站维护权益。

3. 实践案例（盗图查询）

• 华为云与某大型图片库合作，通过图像搜索实现：
  • 5000 万版权图片库与数亿网图精准比对，定位盗图；
  • 客户收入增长超 10 倍，支持每天百万级防盗处理、亿级别搜索能力。

3.3、图像搜索服务调用流程

1. 账号登录：访问华为云官网，选择 “个人华为账号登录” 或 “IAM / 其他登录方式” 完成登录。
2. 服务开通：官网搜索 “图像搜索”，进入 “图像搜索 ImageSearch” 详情页，点击 “立即使用”；在控制台找到 “对象存储服务 OBS”，点击 “开通服务”。
3. 服务调用：进入 “实例管理” 创建图像搜索实例；通过 “API Explorer” 在线调试（如调用 “RunAddData” 接口添加数据），调试完成后发起请求获取搜索结果响应数据。

文字识别API服务介绍：

下面主要讲述华为云EI的文字识别API服务的功能特点、应用场景以及对应的实践案例。

3.1、文字识别概述

什么是文字识别？——文字识别是指将图片或扫描件中的文字转换成可编辑的文本。

华为云文字识别服务通过 “图片输入→多技术处理” 流程，以结构化 Key-Value 形式提取并输出图片中的信息，而结构化信息提取（通过Key-Value的字典形式返回，帮助用户直接获取准确信息）正是实现这一功能的核心技术。

3.2、文字识别场景应用

华为云 OCR（Optical Character Recognition 光学字符识别） 文字识别在多场景的应用：

1. 证件类 OCR：用于身份 / 资质认证、证件信息录入等场景，实现身份核验、节省人工录入；
2. 发票类 OCR：支持多种发票的批量 / 拍照识别，通过自动化流程提升财务处理效率、增强合规性；
3. 智慧物流 OCR：覆盖身份证识别、电子面单提取等环节，实现物流单据的快速识别与自动化处理；
4. 实践案例：在医疗保险理赔中实现单据自动识别与理赔流程自动化，在财务报销中支持 “一图多票” 的智能分类识别。

3.3、文字识别服务调用流程

华为云文字识别服务的调用流程，分为三步：

1. 登录账号：访问华为云官网，选择 “个人华为账号登录” 或 “IAM / 其他登录方式” 完成登录；
2. 开通服务：在官网搜索 “文字识别 OCR”，进入服务详情页后点击 “立即使用”，再在控制台选择对应服务（如票据类）完成开通；
3. 调用服务：先获取 AK/SK 密钥，再在本地 IDE 中填写该密钥构建客户端，最终发起调用并查看结果。

语音交互API服务介绍：

下面主要讲述华为云EI的语音交互API服务的功能特点、应用场景以及对应的实践案例。

3.1、语音交互概述

• 语音交互服务（Speech Interaction Service，简称 SIS）是一种人机交互方式，用户通过实时访问和调用 API 获取语音交互结果。例如用户通过语音识别功能，将口述音频或者语音文件识别成可编辑的文本，同时也支持通过语音合成功能将文本转换成语音等提升用户体验。

智能算法语音交互引擎采用创新算法，融合传统算法和深度学习模型，识别准确率高。

自助调优提供热词功能，用户可自助传入热词，优化特定领域识别效果。

语音交互服务介绍

功能模块	能力描述	应用场景	方言
实时语音转写	多种模式：连续、流式一句话、单句；支持打断、静默检测、智能断句、热词定制	智能外呼，实时质检，会议转写	四川话、粤语、上海话
一句话识别	热词定制、支持垂域模型定制	语音搜索，语音指令，语音短消息	四川话、粤语、上海话
录音文件识别	情绪识别、语速识别、热词定制、静默检测、话者分离	离线质检，录音录入	四川话、粤语、上海话
语音合成	多种音色，自定义语速，音量	智能外呼，有声阅读、人机交互，语音导航	四川话、台湾腔、闽南语

3.2、语音交互场景应用

华为云语音交互服务（SIS）的多场景应用及实践案例：

核心应用场景

1. 外呼 / 呼入：通过语音识别（ASR）、语音合成（TTS）实现智能外呼 / 呼入机器人，支持语义理解、回答生成，优势是识别率高、高并发低延迟，可降低成本、提升效率。
2. 客服质检：基于录音文件识别能力，实现话者分离、情绪检测等，替代传统人工抽检，实现全量质检，降低成本并避免主观影响。
3. 人机交互：通过一句话识别、实时语音识别等能力，支持语音搜索 / 指令 / 短消息，具备易接入、多音频格式兼容等优势，解放用户双手。
4. 有声阅读：利用语音合成能力，提供专属音色，云端合成一次即可多次使用，缩短有声作品制作时间。

实践案例

• 华为云 Welink 人机交互：通过实时语音转写接口，实现语音对话直达沟通协作、工作辅助等业务。
• 某税务局语音助手：结合实时语音转写、语音合成，支持语音唤醒、多轮追问，辅助税务数据查询。
• 某有声阅读：通过 Restful API 将小说文本转换为音频文件，云端存储、一次合成多次使用，音色自然流畅。

这些应用均依托语音交互的核心能力，实现各领域的智能化、高效化升级。

3.3、语音交互服务调用流程

华为云语音交互服务的调用流程分为三步：

1. 登录账号：访问华为云官网，选择 “个人华为账号登录” 或 “IAM / 其他登录方式” 完成账号登录；
2. 开通服务：在官网搜索 “语音交互”，进入服务详情页后选择并购买对应服务；
3. 调用服务：先获取 AK/SK 密钥，再在本地 IDE 中填写该密钥构建客户端，发起调用后查看结果。

4、华为云ModelArts服务介绍

昇腾云服务ModelArts介绍：

• ModelArts 是面向开发者的一站式 AI 开发平台，为机器学习与深度学习提供海量数据预处理及半自动化标注、大规模分布式训练、自动化模型生成，及端 - 边 - 云模型按需部署能力，帮助用户快速创建和部署模型，管理全周期 AI 工作流。

下面主要讲述华为 ModelArts 一站式开发平台的主要功能，帮助用户更好地理解和使用 ModelArts。

4.1、ModelArts概览

华为 ModelArts（基于昇腾云服务的一站式 AI 开发平台）的核心信息：

1. 背景与定位

• AI 技术已广泛应用于智能供暖、科研探索等多行业，而未来 AI 算力需求激增，需构建安全算力底座；
• ModelArts 是昇腾云服务下的全栈自主可控 AI 开发平台，从算力、根技术、生态三方面支撑中国 AI 国产化，提供数据处理、模型训练、部署等全周期 AI 工作流能力。

2. 核心模块及能力

• ModelArts Standard：端到端模型生产工具链，覆盖数据管理、模型开发、训练任务、推理服务等环节，具备国产 E 级算力、高容错等优势；
• ModelArts Lite：实现 K8s 兼容的零成本迁移，通过三层算力加速（推理 / 训练 / 数据缓存）提升 NPU 性能；
• ModelArts Edge：支持边云协同推理，可高效管理边缘资源、实现边云部署与运维，适配多类边缘设备。

3. 优势与案例

• 平台拥有丰富生态（100+AI 模型）、分布式优化（全球首个 E 级算力集群）、软硬件协同（高性能 AI）等优势；
• 案例：助力 RFCx 保护热带雨林（具体内容未展示）。

简言之，ModelArts 是全栈自主可控的一站式 AI 开发平台，通过多模块能力支撑 AI 全流程开发，适配多场景并助力行业智能化。

4.2、ModelArts功能介绍

下面讲述了华为ModelArts一站式开发平台的主要功能，包括数据管理、开发环境、训练平台、推理平台以及AI Gallery。

4.2.1、ModelArts功能概述

ModelArts为开发者提供从数据准备到算法开发、模型训练以及模型部署一站式开发平台。

4.2.2、开发环境

ModelArts 的两类开发环境：

1. ModelArts Notebook：实现云上云下无缝协同，支持云化 JupyterLab 使用，也可通过本地 IDE+ModelArts 插件远程开发；训练前从云存储（OBS 桶）下载数据 / 配置，训练后将模型等上传至 OBS，支持 Web 或 OBS Browser + 等方式交互。
2. ModelArts CodeLab：是云原生 Notebook，具备案例秒级接入与分享、Serverless 实例管理（资源自动回收）、免费算力（规格按需切换）等特点，便于 AI 探索与教学，可快速从 MindSpore 案例云上学习。

4.2.3、数据管理

​ ModelArts 的数据管理功能可百倍提升数据处理效率：通过 Web Console 完成数据 “导入 - 筛选 - 标注 - 处理 - 分析” 全流程，依托 50 + 算法支持数据校验、智能标注等 20 + 能力；同时借助无监督学习预筛选（人工标注前自动过滤 40% 数据）、半监督 / 主动学习混合智能标注（标注效率提 5 倍、精度超 99%），还能自动提取 20 + 特征，大幅降低数据准备成本（数据准备占 AI 落地成本超 70%）。

4.2.4、训练平台

4.3.5、推理平台

ModelArts 推理平台的模型部署与模型仓库能力：

1. 模型部署：端、边、云全场景覆盖

• 支持云、边、端多场景部署：
  • 云侧：在线服务（高吞吐、低时延、自动收缩）、批量服务（大数量推理、分布式计算）；
  • 边 / 端侧：通过网络蒸馏、模型压缩（裁剪 / 量化）等优化适配设备限制，边缘服务对接 IEF 与 Ascend 芯片，端侧服务支持 SDC 等设备。

2. 模型仓库：多来源模型统一管理

• 支持客户模型、华为建模、三方厂商的模型 / 镜像统一纳管，提供 3 种导入方式：
  • 训练模型导入：直接接入 ModelArts 训练作业的输出结果；
  • 模型模板导入：将 AI 引擎与推理模式模板化，快速导入；
  • 自定义镜像导入：支持 Docker 镜像或 OBS 模型规范包形式导入。

4.2.6、AI Gallery

华为云 AI Gallery（华为云在 ModelArts 基础上构建的 AI 开发者社区）的定位、功能与资产：

1. 核心定位：是连接 AI 供需的生态社区，同时也是华为云 AI 知识与实训社区，底层依托 ModelArts 等技术底座及昇腾算力。
2. 生态角色：
   • 供给侧：AI 企业 / 开发者、机构等提供 AI 案例、资产、内容，获取收益与荣誉；
   • 需求侧：行业客户、开发者、AI 学徒等通过使用案例、资产、内容，解决业务问题、提升效率、进阶能力。
3. 优质资产：支持 “百模千态”，涵盖盘古、讯飞星火、LLAMA 等主流开源大模型（适配昇腾 AI 云服务），提供丰富的 AI 资产、服务与解决方案，加速大模型业务上线。
4. 社区价值：提供体系化 AI 教学、多样化 AI 资产、场景化 AI 案例，实现 AI 学习有指导、开发更高效、应用落地零门槛。

4.3、ModelArts助力大模型开发

1. 大模型的一键推理部署流程（基于 AI Gallery）

ModelArts 依托华为云的AI Gallery（大模型资产共享平台），实现开源大模型的快速部署：

• 第一步：订阅模型：在 AI Gallery 中找到开源大模型，免费申请订阅；
• 第二步：部署推理：订阅成功后，通过 ModelArts 将模型部署为在线服务，直接进行预测；
• 第三步：资源清理：体验后可暂停 / 删除服务，避免资源浪费。

2. 大模型研发的技术支撑能力

ModelArts 作为 AI 开发平台，结合 MindSpore 框架、云底座及国产算力（1024P ops、昇腾 / 鲲鹏处理器），为大模型研发提供核心能力：

• 支持分布式训练加速（DataTurbo 缓存、自动容错）；
• 优化分布式通信（3D 并行、高效参数同步）；
• 实现分布式路由规划（拓扑感知调度，256 卡以上性能提升 30%）；
• 支撑 “鹏程” 系列多领域大模型（如盘古中文大模型、神农基因制药大模型等）的研发。

3. 产业级大模型的工业化落地

ModelArts 助力企业（如能源集团）实现 AI 工业化：

• 技术底座：以全栈国产化（MindSpore 框架、昇腾算力、云底座）为基础，提供数据 / 开发 / 训练 / 模型 / 部署全流程管理；
• 场景赋能：结合矿山大模型开发套件（基于盘古 CV/NLP 等大模型），落地主运监测、掘进识别等 L2 级工业场景；
• 落地价值：模型准确率提升超 15%、数据需求降 30%，主运皮带异物识别精度 > 98%、检测效率提升 10-100 倍等。

5、大模型概述

​ 在当今信息技术飞速发展的时代，大模型在处理复杂数据和执行高级任务方面展现出了巨大的潜力。本章主要讲述大模型的相关概念、发展历史，简要介绍大模型的关键技术原理和分层原理。

5.1、大模型概览

一、大模型的核心定义与定位

​ 大模型是指具有庞大的参数规模（数十亿以上）和复杂程度的人工智能模型，使用上亿级文本语料在大规模算力机器上并行训练而成。这些模型通常在各种领域，例如自然语言处理、图像识别和语音识别等，表现出高度的理解及生成能力，和极强的泛化能力。

大模型特点：大参数、大数据、大算力。

二、人工智能发展历程（到大模型时代）

分为三个阶段：

1. 萌芽期（1950s-1980s）：1956 年达特茅斯会议提出 “人工智能”，以符号逻辑、专家系统（如 MYCIN）为主；
2. 技术积累期（1990s-2010s）：机器学习成为主流，2012 年 AlexNet 推动深度学习突破；
3. 大模型时代（2018 年 -）：2017 年 Transformer 架构奠基，2022 年 ChatGPT 展现通用能力；中国自研模型（如 DeepSeek R1）实现全球影响力。

三、大模型的 “从专用到通用” 演进

• 早期（专用）：以 CNN/RNN 架构为主，聚焦感知理解（如物体识别），替代低端重复劳动；
• 当前（通用）：以 GPT 架构为主，具备生成创造能力（如内容生成、知识传递），替代高端脑力劳动；
• 代表进展：GPT-4 已在多模态场景达到人类 80% 的能力水平。

四、大模型核心技术（以 GPT 为例）

GPT 是 “生成式（Generative）+ 预训练（Pre-trained）+Transformer 架构” 的结合：

1. 生成式：可输出文字、图像等内容；
2. 预训练：通过海量数据让模型学习通用知识；
3. Transformer：以自注意力机制实现对输入信息的高效理解与生成。

五、AI 模型开发范式的转变

• 传统 AI 时代：“专模专用”—— 一个场景对应一个小模型，参数少、泛化差，开发需 “从 0 开始→独立调优→艰难迭代”；
• 大模型时代：“一模通用”—— 大模型吸收海量知识，通过预训练 + 微调适配多业务场景，以多模态基础大模型 + AI 集群算力，支撑全业务流创新。

5.2、大模型关键技术原理

5.2.1、大模型训练关键技术

一、大模型核心结构：Transformer

Transformer 是大语言模型的核心结构，核心优势是self-Attention 机制：

• 传统模型仅能基于有限上下文理解内容，而 self-Attention 可同时处理句子中所有词的关联信息（如理解 “学习” 时，结合 “我”“在”“大模型” 等全部单词），让模型捕捉更丰富的上下文，提升语言处理能力。

二、AI 算力支撑：GPU 与 NPU

大模型训练依赖专用 AI 芯片，两类核心芯片特点：

• GPU：成百上千个小核心，擅长并行处理大量相似任务，契合 AI 训练的密集运算需求，代表厂商为 NVIDIA/AMD；
• NPU：电路层模拟神经元，一条指令处理一组神经元，处理神经网络任务更节能，但灵活性低、生态待完善，代表如昇腾芯片。

三、分布式训练：大模型训练的必然选择

大模型参数 / 数据规模极大，传统训练（单设备）资源有限、效率低，** 分布式训练（多设备并行）** 成为刚需：

• 核心价值：通过并行计算大幅缩短训练时间（如原本需 10 天的任务，1 天完成），支撑超大规模模型训练；

• 传统训练 VS 分布式训练：

  维度	传统训练（单设备）	分布式训练（多设备）
  硬件资源	资源有限	资源丰富
  训练速度	慢（受单设备算力限制）	快（并行计算）
  数据处理	单设备完成，传输开销小	多设备传输同步，开销较大
  模型复杂度	仅支持中小型模型	支持 Transformer 等超大型模型

四、训练并行模式：数据并行、模型并行

大模型分布式训练的两类基础并行模式：

1. 数据并行
   • 逻辑：每个 AI 芯片拷贝一份完整模型，分别训练不同数据的梯度，最后同步汇总；
   • 特点：总体 batch size 随芯片数量放大，适合中小型模型；
   • 类比：多个学生分章节复习同一本书，最后分享笔记。
2. 模型并行
   • 逻辑：将大模型拆分到多个芯片，共同维护一个模型（解决单卡存不下的问题）；
   • 细分类型：
     • 纵向并行（Pipeline）：按模型层拆分，不同芯片存不同层；
     • 横向并行（Tensor）：按模型层内部拆分，不同芯片存同一层的不同部分；
   • 类比：多个工人分工组装汽车不同零件，最后拼成整车。

五、进阶并行模式：混合并行与自动并行

为适配超大规模模型，衍生出更高效的并行方式：

• 混合并行：融合数据并行 + 模型并行（含纵向 / 横向），需手动切分参数（如 PyTorch）；
• 自动并行：无需手动切分，框架（如 MindSpore）自动建模计算 / 通信开销，优化数据、模型的切分方式，最小化训练时间。

六、主流分布式并行框架

两类常用框架：

• DeepSpeed（微软）：提升大模型训练效率，支持数据并行（Zero 系列）、模型并行（PP）、梯度累积等加速手段，提供分布式管理、内存优化等工具；
• Megatron-LM（NVIDIA）：支持数据并行 + 张量并行 + 流水线并行，可复现 GPT-3，配套强大的数据处理、Tokenizer 工具，适配 Transformer 类模型。

5.2.2、大模型使用关键技术

一、Prompt 与提示工程

1. Prompt（提示词）：是与大模型交互的输入指令，形式可以是问题、描述、带参数的文字；
2. 提示工程（PE）：在不修改模型的前提下，通过设计 / 优化 Prompt，引导大模型生成更准确、符合预期的内容（同一模型 + 同一任务，不同 Prompt 会产生不同结果）；
3. 优质 Prompt 的 CRISP 原则：
   • Context（情境设定）：明确任务背景（如 “假设你是资深营养师，面向亚健康上班族…”）；
   • Role（角色定义）：指定模型身份（如 “作为区块链专家，用类比解释”）；
   • Instruction（明确指令）：结构化要求输出内容、格式；
   • Specificity（细节约束）：补充细节（如 “列举 5 个 2024 年 SaaS 模式，包含目标客户 / 核心价值”）；
   • Prevention（预防偏差）：规避问题（如 “避免专业术语，用案例说明”）。

二、思维链（CoT）

• 定义：将复杂推理拆分为一系列中间步骤，用短句逐步描述逻辑，引导模型链式解决问题；
• 魔法咒语：“你可以逐步思考…”；
• 特点：
  • 优点：增强模型推理能力、答案的可解释性；
  • 缺点：存在事实幻觉（一步错步步错）、约束模型思维；
• 适用场景：工单审核、数据质量管控、论文分析等需多步骤推理的复杂任务。

三、检索增强生成（RAG）

• 核心价值：解决大模型 “知识边界” 问题（如实时信息、企业私密数据），防瞎编、补知识、降成本；
• 原理：用户提问→检索知识库 / 数据库中的相关资料→将资料作为参考喂给大模型→结合资料生成回答；
• 优势：提高答案可靠性 / 事实一致性、动态补充新知识、适配知识密集型任务；
• 适用场景：问答系统、阅读理解、领域知识问答等。

四、AI Agent（智能体）

1. 定义：能感知环境、自主决策并执行行动的 AI 系统，核心特征是自主性、工具使用能力、持续学习适应性；
2. 基础架构：由规划（Planning）、记忆（Memory）、工具（Tools）、行动（Action）组成，精简逻辑为 “感知→规划→行动”；
3. 核心技术：工具使用（MCP 协议）：
   • MCP（模型上下文协议）：2024 年 Anthropic 提出的标准化协议，让大模型与外部工具 / 数据源 “即插即用”（类比 “AI 界的 HTTP/USB-C 接口”）；
   • MCP 优势：统一工具交互语言、降低开发难度、提升扩展性与协作效率（无需单独适配工具）。

5.3、大模型分层原理

一、大模型的三层分层逻辑（L0-L2）

大模型按 “通用→领域→场景” 的递进关系，分为三层：

1. L0 通用大模型
   • 训练基础：基于海量通用数据训练；
   • 能力特点：具备广泛通识知识，但缺乏行业 / 场景的专业 know-how。
2. L1 领域大模型
   • 训练基础：以 L0 通用模型为底座，用垂直行业的领域数据做增量训练；
   • 核心作用：将通用大模型的能力迁移到特定行业（如矿山、金融、电力等）。
3. L2 场景大模型
   • 训练基础：针对具体应用场景，用人工标准数据微调 L1 领域模型；
   • 能力强化：结合提示工程、思维链、RAG、AI Agent 等技术，适配场景的专业 know-how（如传送带异物检测、财务异常识别等）。

二、大模型分层的外部视角（三层架构）

从产业落地的角度，大模型分为 “基础层 - 中间层 - 应用层”，对应不同类型的模型：

层级	对应模型类型	核心特点
基础层	通用大模型	大数据、大算力、高投入 / 高能耗，提供通用能力底座
中间层	行业大模型	小数据（追求深度）、中算力、低投入 / 低能耗，向应用层输出垂直领域能力
应用层	场景微模型	微数据（追求个性化）、小算力、低投入，实现多样化、场景化的落地需求

三、盘古大模型的分层实践案例

以华为盘古大模型为例，分层落地逻辑清晰：

• L0 基础大模型：覆盖视觉、NLP、多模态等通用能力，训练周期 2-3 个月，需千卡算力；
• L1 行业大模型：基于 L0 适配矿山、气象、医药等行业，训练周期 1-2 周，需百卡算力；
• L2 场景模型：基于 L1 微调，适配传送带检测、财务审核等具体场景，训练周期 1-2 天；
• 价值体现：落地智慧金融、智慧电力等场景，实现效率 / 精度的显著提升（如单据审核成本降 50%）。

四、大模型分层落地的行业挑战

通用大模型直接落地行业存在三大问题：

1. 专业性弱：通用模型缺乏行业知识与工作流程认知，难以输出专业准确的结果；
2. 技能不足：通用语言大模型难以适配企业复杂场景的 “多任务、多技能” 需求；
3. 数据安全：企业数据是核心资产，大模型训练 / 使用过程中需保障数据合规与安全。

6、检索增强生成介绍

• 本章主要讲述检索增强生成在大模型中的应用，实践表明，大模型在知识幻觉、信息过时、参数化知识效率低、缺乏专业领域的深入知识等方面的不足开始凸显了出来。
• 将大模型 + 知识库结合起来，形成 RAG (Retrieval-augmented generation) 模式，是提高模型输出能力的一种落地方式。

6.1、RAG技术背景

1. 提出背景

大模型存在 “知识局限性”：要么涉及具体知识资料（如《飘》的细节），要么涉及实时信息（如上海当日民生事件），而大模型训练成本高、无法短期升级，因此需要 “外部力量”（即 RAG）。

2. RAG 的定义

RAG 是 “检索增强生成”，结合检索功能（从知识库搜相关信息）和生成功能（基于检索内容生成准确回答），像 “知识助手” 一样协同工作。

3. RAG 的优势

• 提高准确性：能实时检索最新信息、直接引用知识库原文，避免模型 “编造”。
• 增强可解释性：回答可标注信息来源，便于验证和调试。
• 减少幻觉：仅基于检索内容生成，无信息时会明确回复 “未找到”。

4. RAG 的工作方式

通过标准化 Prompt 引导大模型：将 “任务 + 问题 + 检索到的资料” 传给大模型，要求其结合资料回答（无信息则回复 “不知道”）。

5. RAG 的案例

以 “评价 OpenAI CEO Sam Altman 的人事变动” 为例：

• 无 RAG 时，大模型会表示 “无相关信息”；
• 有 RAG 时，会检索相关文档片段，结合后生成关于 OpenAI 内部权力博弈的分析。

6. RAG 与 SFT（监督微调）的对比

特性	RAG	SFT
知识更新	动态（更新知识库即可）	静态（需重新训练）
外部知识	擅长利用外部资源	不适合频繁变化的数据源
模型定制	无法定制风格 / 行为	可调整模型风格 / 领域知识
可解释性	可追溯来源，幻觉少	特定领域幻觉少，但未训练内容易出错

7. RAG 与 SFT 的选择原则

• RAG 侧重 “知识扩展”：适合需要实时 / 外部知识、标注来源的场景（如企业政策解读、文献综述）。
• SFT 侧重 “行为对齐”：适合需要固定格式、定制风格 / 功能的场景（如诊断书输出、英语陪练机器人）。

6.2、关键技术概览

一、RAG 基础技术流程（3 大模块）

RAG 的工作分为知识库构建、知识检索、智能问答三个环节，共 8 个步骤：

1. 知识库构建：
   • 文件预处理（清理文档冗余内容）→ 文件切分（拆分成长短合适的段落）→ 知识向量化（将文字转成计算机可识别的 “数字密码”）→ 构建索引（把向量存入 “智能书架” 方便检索）。
2. 知识检索：
   • 问题向量化（把用户问题也转成 “数字密码”）→ 知识库检索（用问题向量匹配知识库中最相关的段落）。
3. 智能问答：
   • 调用提示工程模板（把问题 + 检索内容拼接成提示词）→ 调用大模型（生成自然语言回答）。

二、核心环节细节

1. 文件切分

• 方法：包括递归式、HTML/Markdown/ 代码分割器、Token 分割器、语义分块器等（适配不同类型文档）。
• 技巧：自然语言推荐用 Token 分割器，通过Chunk Size（块大小）控制单段长度、Overlap Size（重叠大小）保留上下文信息。

2. 向量化

将不同类型数据转成高维 “数字特征”：

• 文本向量：通过词嵌入技术生成，承载语义信息；
• 图像向量：提取颜色 / 形状等特征；
• 语音向量：提取音调 / 音色等特征。

3. 知识检索：文本多路召回策略

通过**多个检索路径（如向量索引 + 关键词索引）**获取候选文档，再合并排序，提升检索的全面性与准确性。

三、RAG 技术的拓展与现状

• 应用场景：从问答扩展到推荐系统、信息抽取、报告生成等。
• 技术生态：工具（如 Langchain、LlamaIndex）持续丰富，范式从 “朴素 RAG” 演进到 “进阶 RAG”“模块化 RAG”。
• 评估维度：从 “检索质量”（答案相关性、上下文相关性）和 “生成质量”（噪声鲁棒性、事实准确性）等维度评估效果。

6.3、私域知识问答案例流程

一、案例目标

创建能针对任意网站 / 文档做问答的私域知识问答机器人（以 “儿童骑车年龄风险” 为例）。

二、RAG 落地流程（以 “儿童骑车风险” 为例）

整个流程分知识库准备、检索、生成三步，核心依赖 “嵌入模型 + 向量数据库”：

1. 知识库准备（前置工作）

• 拆分知识库：将交通政策等文档用 “知识分解器” 拆成知识片段；
• 知识向量化：通过嵌入模型把每个知识片段转成 “嵌入向量”，存入向量数据库（专门存储 / 管理向量的数据库）。

2. 知识检索（用户提问后）

• 问题向量化：用户问题（“几岁儿童骑车有风险”）也通过嵌入模型转成向量；
• 匹配知识片段：向量数据库根据 “向量相似度”，找到与问题最匹配的知识片段（如 “12 周岁以下儿童骑车风险” 的政策内容）。

3. 答案生成

• 构造 Prompt：给大模型发系统提示（如 “你是交通领域知识机器人，用知识库信息回答”），并附上检索到的知识片段；
• 生成回答：大模型结合问题 + 知识片段，输出准确回复（“12 周岁以下儿童骑车存在风险”）。

三、RAG 实践中的挑战

落地时会遇到多环节问题：

难点分类	具体挑战	说明示例
文件解析	复杂文件 / 多模态内容处理	PDF 扫描件需 OCR 识别，图表 + 文字混合内容难提取
数据质量	知识库错误、敏感信息泄露	文档错误会被 AI 传播，合同隐私信息可能泄露
检索环节	语义歧义、效率质量难平衡	“小米” 既指谷物又指公司；大规模向量库检索慢
生成控制	内容拼接生硬、事实性错误	检索片段与问题逻辑断裂；数据年份表述错误
系统维护	知识库更新成本高、长文档低效	金融领域需小时级更新，但重索引成本高

7、人工智能应用测试

​ 本章介绍了AI应用测试的主要流程，包括场景分析、特征因子分析、数据构建、评测指标、自动化方案，其中数据集的构建是整个流程中非常关键的一步，需要考虑不同场景不同特征因子下的样本以及AI应用上线后的难例样本和新样本。

一、AI 测试的分层体系

AI 测试从底层到应用层分为 6 层，每层有不同的测试重点：

层级	测试重点	示例技术 / 模块
芯片层	算力、功能、能效安全	CPU/GPU/NPU
调度层	可靠性、效率、性能安全	driver/Scheduler（调度器）
算子层	精度、性能、兼容性	Conv/pooling（卷积 / 池化）
框架层	易用性、兼容性、完整性	Caffe/TensorFlow
算法层	精度、性能、功能安全	Yolo/SSD（目标检测算法）
应用层	功能、精准性、业务安全	AI 应用（如数据管理）

二、AI 应用测试框架与角色

测试是跨团队协作的迭代流程，核心角色及职责：

• 开发团队：负责设计、开发、数据验收、自调优；
• 数据团队：负责数据采集、清洗、标注、质量检测；
• 测试团队：负责测试方案、数据、自动化、评估与发布。

三、AI 测试核心流程（5 步）

1. 场景分析：梳理应用场景、使用主体与特点，细化场景；
2. 特征因子分析：识别影响 AI 模型效果的输入数据因素（如拍摄、环境、对象），建立因子库；
3. 数据构建：基于场景 / 因子构建测试数据集，覆盖真实环境的各类情况；
4. 评测指标：根据业务需求确定指标（精度 / 性能 / 效率等）；
5. 自动化方案：实现批量测试与指标统计。

四、关键环节：特征因子分析

1. 核心逻辑：“有好数据才有好模型 / 输出”，需分析影响 AI 识别效果的输入数据因素，比如：

• 人脸场景：分为拍摄因子（角度 / 亮度 / 模糊度）、环境因子（时间 / 光照 / 背景）、对象因子（年龄 / 肤色 / 穿戴）；
• 身份证识别场景：包含图像曝光 / 模糊 / 倾斜 / 背景干扰等因子。

2. 价值：可通过约束因子（如引导用户规范拍摄）提升 AI 识别率。

五、关键环节：数据构建

包含 3 步：

1. 数据采集：冷启动（历史数据 / 网络数据 / 采购）+ 线上回流（真实场景数据）；
2. 数据清洗：去除冗余、修正格式（如处理文本中的特殊符号）；
3. 数据分析理解：样本分布分析（覆盖多样性）+ 负向样本分析（难例 / 新类别样本，指引模型优化）。

六、评测指标分类

测评指标分为两大类：精度指标和性能指标。精度指标在不同的AI技术领域有不同的常用指标，如下表所示：

技术领域	学术界公认的常用精度指标
图像分类	准确率、召回率、精确率、F1 值、ROC 曲线、P-R 曲线、混淆矩阵
目标检测	mAP(mean average precision)
图像分割	MIoU(Mean Intersection over Union)
文字识别	CPR(Character Precision Rate)、CRR(Character Recall Rate)
机器翻译	BLEU(Bilingual Evaluation understudy)、ROUGE(Recall-Oriented Understudy for Gisting Evaluation)
语音识别	WER(Word Error Rate)、SER(Sentence Error Rate)

常用的性能指标有：

• FPS（Frames Per Second），每秒能处理的图片数；
• FLOPs（Floating-point Operations Per Second），模型所需的浮点数处理次数；
• GPU显存占用；
• QPS（Query Per Second），衡量AI应用API每秒能响应的请求数；

HCCDP-Cloud Migration 云迁移工作级开发者认证课程笔记

1、云采用框架简介

• 云计算从根本上改变了 IT 基础设施和应用系统的建设、运维和管理方式。传统模式下，组织通常需要购买、安装和运维自己的硬件和软件。云计算模式下，IT 基础设施的建设和运维由云服务商负责，组织只需关注应用系统的开发和部署，可以从云服务商按需获取上述各种资源，资源可以快速部署、调整和扩展，运维负担轻，并大幅降低了初始投资。
• 云计算提供了巨大的灵活性、可靠性和扩展性，但同时，整个组织的云化转型是一项系统性工程，涉及组织、流程和技术的方方面面，需要一个成熟且一致的方法确保云化转型的成功，最大化业务收益。

1.1、迁移背景介绍

一、上云迁移的背景：系统性工程，需多方协同

从客户视角看，上云涉及不同角色的诉求，是跨部门协同的复杂工程：

• 决策者（CEO/CTO/CFO）：关注降本增效、支撑业务发展；
• 决策支持者（运维 / 采购主管）：关注业务连续性、平台稳定运行、业务改造量最小；
• 技术评估者（网络 / 开发 / 运维人员）：关注数据一致、系统稳定性提升、补齐能力短板。

因此上云需要 “铁三角协同”，明确路径、做好风险规划，同时保障 “上得快、上得稳”。

二、上云的核心前提：“三个转变”

企业上云需先完成 3 个层面的转变：

1. 转意识：从 “技术搬运工” 转变为 “架构师”（从简单迁移到主动设计架构）；
2. 转能力：从 “单一技术能力” 升级为 “综合能力”（覆盖规划、迁移、运维全流程）；
3. 转方法：从 “零散流程” 转向 “标准化方法论”（用体系化方法指导迁移）。

1.2、云采用框架整体介绍

一、云采用框架（CAF）的定义

华为云 CAF 是云化转型的端到端生命周期框架，覆盖 “制定战略→顶层规划→调研评估→方案设计→采用实施→运维治理” 全阶段，提供方法论、最佳实践、工具模板，帮助各角色（业务 / IT / 财务 / 运维等）做决策，对齐业务与技术战略，保障云化转型成功。

二、CAF 的核心流程（云化全旅程）

分 6 个阶段，每个阶段有对应的核心任务：

1. 制定战略：识别云化动力、制定 KPI、收益分析、成熟度评估；
2. 顶层规划：组建云能力中心（CoE）、设计架构 / Landing Zone / 安全框架、规划运营模式；
3. 调研评估：调研基础设施 / 应用 / 大数据、云服务选型、风险评估；
4. 方案设计：设计基础 / 应用 / 数据架构、制定 6R 上云策略、试点计划；
5. 采用实施：基础设施部署、应用 / 大数据迁移上云、云上创新；
6. 运维治理：精益化治理、确定性运维、安全运营、成本优化（FinOps）。

三、CAF 的云化全视角

从业务、技术两大维度，覆盖多视角的关注点与干系人：

1. 业务视角（5 类）

视角	关注点（示例）	干系人
战略视角	支撑业务 / 数字化战略	CXO、高级管理人员
业务视角	业务连续性、新业务上市速度	业务主管、CIO
财务视角	降低 TCO、成本效益	CFO、财务专家
组织视角	云化组织架构、人才管理	CIO、HR 专家
流程视角	优化 IT 服务 / 运维流程	CIO、IT 主管

2. 技术视角（5 类）

视角	关注点（示例）	干系人
平台视角	构建高安全 / 可靠的 IT 基础设施	CIO、IT 运维专家
架构视角	设计高可用的技术 / 应用架构	CTO、云架构师
运维视角	云上 IT 运维体系、故障处理	CTO、运维专家
安全视角	全方面安全防护体系	CISO、安全专家
治理视角	云上 “人财物权” 集中治理	CIO、IT 治理专家

2、迁移的战略制定与顶层规划

• 云化转型（也叫云转型）是指将组织的 IT 基础设施、应用系统、业务流程等迁移到云计算平台，或者利用云计算技术对其业务模式和运营流程进行重构和优化的过程。它不仅仅是简单地将数据和应用程序迁移到云端，更是一个涉及战略、技术、组织和流程的全面转型。
• 云化转型的第一步是制定云化转型战略，这需要全面的规划和周密的准备。制定云化转型战略不仅涉及技术层面的考虑，还需要与组织的业务战略和数字化战略紧密对齐，并在公司范围内与高层领导和所有干系人对齐战略目标。通常在制定云化转型战略时需要分析干系人利益、识别云化驱动力、评估云化成熟度、制定云化目标、分析云化收益等。

2.1、识别云化驱动力

一、云化驱动力的核心分类

云化转型的驱动力分为业务、技术、财务三类，对应不同角色的诉求：

1. 业务驱动力（CEO 视角）：提升业务敏捷性、加速创新、保障连续性、市场扩张、合规遵从、提升可持续性；
2. 技术驱动力（CIO 视角）：提升资源弹性、系统韧性、扩展性、安全性、运维效率、性能效率；
3. 财务驱动力（CFO 视角）：降低成本、新增收入、将资本支出（Capex）转为运营支出（Opex）。

二、驱动力的落地支撑

1. 干系人（干系人是指企业内部或项目相关的角色**，如业务、财务、IT、管理层等）对齐**：需明确各角色（CEO/CIO/CFO/ 业务主管等）的利益诉求与参与方式，确保战略共识；
2. 成本验证（TCO 对比）：云模式通过 “弹性提供资源”，相比传统模式（按峰值准备资源）大幅减少成本浪费；
3. 量化目标（云化 KPI）：将驱动力转化为可衡量的指标（如业务系统可用性 SLO、新产品 TTM、TCO 降低比例等）。

三、延伸：多云战略的驱动力

选择多云的核心原因包括：避免单云故障、规避厂商锁定、降本增效、利用不同厂商优势、满足合规要求。

四、驱动力的识别方法

通过关键业务事件匹配对应驱动力（例如：数字化转型对应 “提升业务敏捷性”；数据中心退役对应 “提升运维效率”），且需根据企业战略对驱动力做优先级排序。

2.2、评估云化成熟度和制定云化转型战略

一、云化成熟度评估（CMM）

1. 评估原则与维度

• 5 大原则：业务驱动、全要素（人 / 技术 / 流程）、全堆栈、全旅程、一体化；

• 10 个维度：覆盖云化收益、战略和业务、组织和流程、数智赋能等（共 70 个评估问题）；

• 5 个成熟度等级

  （从低到高）：

  • 起步（1 分）：初步探索，无整体规划；
  • 局部突破（2 分）：局部应用云技术，缺乏系统性；
  • 全面开展（3 分）：云化见效，技术能力建立；
  • 竞争优势（4 分）：云化驱动业务创新，实现显著收益；
  • 领先（5 分）：行业标杆，高度自动化 / 智能化运营。

2. 评估路径

分 5 步：定义范围→识别干系人→执行评估→分析报告→输出优化建议。

二、云化转型战略制定

1. 顶层规划（3 大层面）

• 组织转型：组建云卓越中心（CCoE），统筹云化全流程；
• 技术升级：基于卓越架构设计云基础设施，构建安全合规的云上环境；
• 流程变革：设计云运营模式，优化应用生命周期管理流程。

2. 制定云化目标

​ 云化目标一定要与组织的业务战略和业务目标对齐，而且云化目标要符合SMART原则，即目标应是具体的（specific）、可衡量的（Measurable）、可实现的（Achievable）、相关的（Relevant）和有时限的（Time-bound）。

量化指标	云化目标示例
业务系统的可用性 SLO	业务系统全年可用性 SLO 从 99% 提升到 99.95%。
新产品或新版本的 TTM	将新产品的 TTM 从 6 个月缩短至 3 个月，已有产品的迭代周期从 3 个月缩短至 1 个月。
不合规及安全事件造成的经济损失	将不合规及安全事件数量减少 75%，经济损失减少 75%。
IT 基础设施的 TCO	将 IT 基础设施的 TCO 降低 15%。
业务创新和市场扩张带来的新增收入	基于云进行业务创新和全球市场扩展，在未来三年带来 x 万活跃用户，实现新增收入 y 亿元。
碳排放减少量	上云后减少碳排放量 50%。
每个运维工程师可运维的资源数量	将每个运维工程师可管理的服务器数量提升 2 倍，从 100 台提升至 200 台。

3. 云化收益分析

聚焦 “降低 TCO”，云模式成本为运营支出（Opex），包含计算 / 存储 / 网络 / 安全等资源成本、迁移成本、人力成本等（需综合设备折旧、地域差异等因素对比传统模式）。

4. 战略制定全流程

设计愿景→明确目标→对齐干系人→高层发布战略。

5. 战略制定的反模式与优化

反模式	优化建议
与业务战略未对齐	战略绑定业务、获取高层支持
只关注技术收益	以业务为中心定目标、量化业务收益
缺乏干系人对齐	分析干系人利益、建立沟通反馈机制

2.3、云卓越中心简介

一、CCoE 的定位

云卓越中心是企业云化转型中组织和流程层面的核心统筹机构，负责协调跨部门资源、推动云化全流程落地，是云化转型顶层规划的关键组成部分。

二、CCoE 的组织架构

CCoE 是跨角色的联合团队，核心架构包括：

• 顶层管理：由 CIO 牵头，设 PM（项目经理）+ 指导委员会（业务 / IT / 财务 / 人力主管）；
• 执行团队：涵盖应用团队、云架构团队、云实施团队、云运维团队、云安全团队、云治理团队、FinOps 团队等，每个团队配备对应专业角色（如应用架构师、云架构师、调研评估工程师等）。

三、核心团队职责（以云实施团队为例）

角色	职责（示例）	技能要求（示例）
调研评估工程师	现状调研、需求提升、可行性评估、成本估算	熟悉主流云平台、具备 IT 基础设施知识、掌握迁移策略
迁移实施工程师	迁移方案落地、系统测试验证、故障排障	精通云服务与迁移工具、具备脚本编写能力

四、CCoE 的发展节奏

• 初期：从小规模团队起步，配备核心角色（支撑第一批业务系统云化）；
• 后期：随云化规模扩大，逐步扩充团队，增加运维治理阶段所需角色。

2.4、卓越架构设计

**华为云卓越架构框架（WAF）**的核心是通过五大维度构建高质量云上架构，并实现成本与业务目标的平衡，具体内容如下：

一、WAF 的核心定位

WAF 是基于华为云转型经验提炼的架构设计原则与最佳实践，目标是帮助企业构建 “高韧性、高安全、高性能、低成本、易运营” 的云上业务系统，覆盖五大核心维度：

维度	核心方向（示例）
韧性	高可用设计、故障全面检测、故障快速恢复、过载控制、变更防差错
安全性	云安全治理、基础设施安全、应用安全、数据安全与隐私保护、安全运营
性能效率	流程与规范、性能规划、性能建模、性能分析、性能优化、性能看护
成本优化	组织与流程、预算规划、成本分配、成本治理、成本优化
卓越运营	文化和运维体系、频繁可逆的变更、测试验证、自动化构建和部署、变更管理、可观测性、故障分析和管理

二、WAF 的核心逻辑：平衡业务需求与成本

企业需在 “成本” 与 “性能 / 韧性 / 安全性” 之间找到平衡：

• 避免追求 “极致性能 / 安全” 导致成本过高；
• 也避免 “极低成本” 影响业务稳定性与安全性，需根据实际需求做到 “恰到好处”。

三、WAF 的落地实践

WAF 通过匹配业务等级设计成本最优方案：

1. 韧性方案：根据业务的灾难恢复等级（RTO/RPO），选择对应容灾架构（如同城容灾、同城双活 + 异地容灾、单元化异地多活），等级越高可用性越强，但成本也越高；
2. 安全方案：根据业务的等保要求（保护等级 1-5 级），设计对应的安全技术 + 安全运营方案（覆盖物理、身份、网络、应用等多层面），满足合规的同时控制成本。

四、WAF 的支撑工具

• 架构调研和评估：通过问卷 / 评估检查设计方案，识别问题并持续改进；
• 风险检查及优化：运行阶段持续评估，识别风险并优化；
• 卓越架构资产库：沉淀各行业 / 场景的最佳实践（待发布）。

2.5、Landing Zone架构设计

华为云 Landing Zone 架构核心是解决全面云化后的 IT 治理挑战，构建安全合规、易扩展的云上多账号运行环境，内容如下：

一、Landing Zone 的定位

Landing Zone 是应对 “全面云化 IT 治理挑战”（如业务单元隔离、资源共享、权限管控等）的解决方案，目标是搭建安全合规、易扩展的云上多账号运行环境，实现资源、安全、成本的统一管控。

二、Landing Zone 的核心架构与能力

1. 整体架构（8 大核心能力）

覆盖组织与账号管理、身份权限、数据边界、网络管理、安全管理、合规审计、运维管理、财务管理，通过自动化部署（如 Terraform）落地，并配套 8 项核心动作（集中身份管理、网络运营、安全防护等）。

2. 核心价值场景

• 多账号管控：适配不同规模组织的账号规划（大型 / 中型 / 小型组织的账号分层方案），实现业务单元间的资源隔离与公共资源共享；
• 集中网络管理：构建骨干网络架构，统一互联网 / IDC 入口、多账号网络互通，简化管理并降低成本；
• 统一安全管控：通过安全运营账号 + 安全云脑等工具，实现跨账号的网络安全、数据安全、运维安全的集中防护。

三、Landing Zone 的落地效果

• 解决业务单元隔离、故障范围控制、资源灵活适配等治理难题；
• 实现 “安全合规 + 易扩展” 的云上环境，支撑多业务单元的高效协同。

2.6、安全架构设计

一、安全哲学：成体系的安全框架

以 “安全、可信、合规” 为核心，覆盖 5 大维度：

• 安全运营：安全感知分析、安全事件响应；
• 应用安全：安全编码、安全配置、开源安全、渗透测试；
• 数据安全与隐私保护：数据安全、隐私保护；
• 基础设施安全：身份认证与访问控制、运行环境安全、网络安全；
• 云安全治理策略：安全团队、安全基线、威胁建模等全流程管控。

核心逻辑：安全是 “木桶系统”，系统性防护才能避免短板风险。

二、责任共担模型：华为云与租户分工

• 华为云责任：基础设施安全（物理设施、计算 / 存储 / 网络）、平台服务安全、应用服务安全；
• 租户责任：数据安全（租户数据加密）、应用服务安全、平台服务配置（虚拟网络、身份管理等）。

三、十大安全设计原则

设计安全架构需遵循的核心准则：

1. 零信任原则（永不信任，始终验证）；
2. 最小授权（仅授予必要权限）；
3. 纵深防御（多重防护机制）；
4. 安全与成本平衡（匹配业务合规需求）；
5. 云原生安全防护（优先选云原生安全服务）；
6. 攻击者视角（从攻击侧评估风险）；
7. 持续安全运营（技术 + 运营结合）；
8. 木桶原则（避免安全短板）；
9. 人和数据分离（减少人员直接操作数据）；
10. DevSecOps（安全融入全开发周期）。

四、落地实践：七层纵深防线 + 统一安全运营中心

通过 “七层防线” 构建全链路防护，搭配 “统一安全运营中心” 管控：

• 七层防线：物理安全→身份认证→网络防线→应用防线→主机防线→数据防线→运维防线；
• 统一运营中心：实现云上资产管理、安全态势监控、事件响应等集中管控。

2.7、平台工程与云运营模式

一、平台工程工具：提升开发与交付效率

华为云提供一系列工具支撑应用全生命周期管理：

• AppStage（应用平台）：基于平台工程，管理传统 / AI 原生应用全生命周期，提供自助服务；
• CodeArts（软件生产线）：一站式云端开发平台，覆盖需求、代码、编译、部署全流程；
• ServiceStage（应用管理与运维平台）：支持多技术栈 / 微服务的应用发布、监控；
• CSE（微服务引擎）：微服务中间件，支持注册配置中心、应用网关；
• CAE（云应用引擎）：Serverless 托管服务，实现极速部署、极简运维。

二、3 种云运营模式（适配不同业务场景）

华为云总结了 3 类运营模式，各有优缺与适用场景：

1. 去中心化运营模式（适配快速创新业务）

• 核心逻辑：应用团队全权控制云资源，中心 IT 仅制定标准；
• 优点：敏捷性高、贴近业务、责任明确；
• 缺点：标准不统一、成本高、缺乏全局视图；
• 适用场景：创新业务系统（需快速迭代）+ 业务单元有独立 IT 团队。

2. 集中化运营模式（适配稳态业务）

• 核心逻辑：CCoE 团队集中管控云资源，应用团队仅负责业务开发；
• 优点：管理统一、成本优化、全局视图；
• 缺点：敏捷性低、CCoE 易成瓶颈、难匹配业务需求；
• 适用场景：稳态业务（如成熟商业软件）+ 需 IT 统一管控的系统。

3. 赋能 & 协同运营模式（适配敏态业务）

• 核心逻辑：CCoE 提供标准 + 赋能，应用团队自主运维，双方协同；
• 优点：平衡集中管控与敏捷性、协同高效、成本优化；
• 缺点：实施复杂、对 CCoE 能力要求高；
• 适用场景：敏态业务（如数字化营销系统）+ 稳态业务有强 IT 团队。

三、顶层规划的反模式（需规避）

• CCoE 团队配置不全（缺云架构师 / 治理专家、应用团队参与不足）；
• 未搭建 Landing Zone 就迁移（缺统一架构，导致延期、成本高、不安全）；
• 选错运营模式（如集中化用于快变业务、去中心化用于高合规业务）。

总结

• 识别干系人是制定云化转型战略的起点
• 识别云化转型驱动力是制定战略的前提
• 云化目标一定要与组织的业务战略和业务目标对齐
• 云化转型战略要有愿景、具体的目标，并同干系人充分沟通一致
• 云化转型是系统工程，需要 CCoE 来领导和推进
• 卓越架构技术框架，提供最佳实践

3、迁移调研分析和评估规划

• 本章主要介绍调研分析的思路和方法，在上云的每个阶段都可以参考此方法进行调研。
• 本章内容重点介绍迁移调研评估的方法论、工作要点、相关工具等，并阐述了计算、存储、网络等基础IaaS云服务选型原则，旨在指导迁移前期的准备工作。

3.1、组建调研评估团队

按 “先易后难、先粗后细、持续迭代” 的原则，分"六步"执行调研工作：

1. 确定调研目的：基于任务目标，确定所需的必要信息或数据，即为调研的目的。
2. 回溯整理已知信息：内部同步对齐已有信息，明确已知边界的范围；避免反复向客户索取重复信息。
3. 明确信息缺口：界定所需额外调研信息的边界，明确需要进一步调研的缺口、理由以及希望的获取方式。
4. 定义正确的干系人：根据所需信息的属性，判断能提供该信息的客户干系人，是客户的领导层、架构师、部门负责人还是具体工程师。
5. 制定沟通、调研策略：针对所定义的干系人，制定有针对性的沟通策略，以期用最小代价取得干系人对提供信息的认可。
6. 实行调研获取信息：依照客户干系人认可的授权方式获得需要的信息，完成调研。

组建调研评估团队：

角色	工作职责	来自部门
调研评估工程师	对企业现有的 IT 基础设施、业务系统、应用架构、数据存储、安全策略等进行全面调研和评估，包括硬件配置、网络架构、软件版本、依赖关系等；分析这些设施与云服务的兼容性和迁移难度，评估将现有系统迁移到云平台的可行性。	IT 部门或云实施专业服务提供商
业务专家	收集和分析业务需求，与利益相关者访谈，了解不同部门的需求和期望，提供业务价值分析，为团队提供业务层面的指导和建议，帮助量化上云收益。	业务部门
应用架构师	支撑云实施团队提供业务系统的现状进行调研，为其提供资源现状、应用架构、部署架构、依赖关系等信息。	业务部门应用团队
财务专家	对上云项目的成本进行核算和分析，包括云服务费用、迁移费用、运维费用等；评估上云项目的经济效益和 ROI（投资回报率）。为上云决策提供财务支持和建议。	财务部门
云安全专家	评估云服务的安全性、合规性以及数据保护能力，识别和应对潜在的安全风险，确保上云过程符合相关法律法规和行业标准。	IT 部门安全团队
项目经理	管理调研项目进度，确保各项任务按时完成，协调各部门之间的沟通与协作，促进信息流通，及时解决项目中的问题。	项目管理办公室（PMO）
云架构师	作为云技术的专家，为团队提供上云技术支持和指导，包括上云方法论，调研的最佳实践等。	IT 部门或云厂商

3.2、基础设施调研

​ 基础环境调研的主要是企业当前的IT基础架构的现状和上云需求，包括资源信息、组网信息、安全架构、运维架构、访问权限管控、资源计量计费等。

​ 调研的方式：①企业内部的IT系统导出信息（例如配置管理数据库CMDB；云管理平台CMP；虚拟化管理软件等）②问卷调查和访谈

​ 调研过程注意事项：①调研人员应与运维团队充分沟通，确保准确获取和理解企业的IT基础环境信息。②需要考虑敏感性和机密性的问题，并遵循企业的安全和保密要求。

​

3.3、应用系统调研

一、应用系统调研分析概览

调研是 “由粗到细、持续迭代” 的过程，覆盖基本情况、技术架构、部署架构、数据库信息、特殊依赖信息等维度，最终输出：基础信息汇总、上云可行性评估、上云方案与策略。

二、核心调研模块

1. 应用全景调研

• 阶段：前期评估规划阶段；
• 目的：了解企业应用概况，辅助制定上云策略；
• 逻辑：按 “业务域→业务系统→应用模块” 逐层拆解，覆盖应用名称、功能、供应商等信息。

2. 应用部署架构调研

• 阶段：试点 / 大规模迁移阶段；
• 对象：单个应用；
• 核心：调研 “接入层、应用层、中间件层、数据层” 四层架构，及各层技术组件的规格、版本、容量等信息（如主机、存储、数据库、网络等细节）。

3. 技术组件详细信息调研

通过表格记录具体组件的信息，例如：

• 源主机：系统平台、部署方式、CPU / 内存、操作系统等；
• 中间件（如 MessageQueue）：产品类别、版本、资源要求、性能数据等。

4. 应用关联关系调研

需同时覆盖内部 + 外部关联：

• 内部关联：用于迁移批次规划、切换方案制定（如共享服务、共享数据依赖）；
• 外部关联：用于评估业务影响、选择停机窗口（如第三方应用依赖、数据源 API 依赖）；
• 分析方法：CMDB 法、关联分析工具、配置分析、WorkShop 讨论等。

5. 外部关联关系调研

• 常见类型：第三方应用依赖、数据源 / API 依赖、授权安全关系、供应商关系等；
• 调研方式：结合文档资料、团队沟通、代码分析、系统扫描等多方式。

三、调研准备经验

需明确已知输入（交底材料、开工会纪要等）、调研目标（判断迁移定位、支撑评估 / 规划），同时覆盖客户角色、客户需求、各业务系统信息三类核心对象。

3.4、大数据调研

平台调研

数据调研

调研内容	调研目的	举例
数据类型	根据数据类型选择合适的迁移工具。	HDFS、HBase、MySQL 等
数据量	历史数据量，用于评估历史数据迁移周期；日增量数据，用于评估每日增量数据同步周期。	历史数据 X PB / 日增量 Y TB
数据分层	调研数据分层主要用于迁移优先级和数据校验标准。	数据接入层、中间层、结果层
数据权限	根据源端数据权限控制组件的不同，选择不同的权限数据迁移方式	Sentry、Ranger 等
数据重要性	调研数据重要性的目的是区分核心数据和非核心数据，用于迁移优先级和数据校验标准。	交易类是核心数据，日志类是非核心数据
数据更新频率	针对不同的刷新周期，制定数据的迁移计划和校验计划。	日刷新 / 周刷新 / 月刷新 / 实时更新
任务执行区间	让数据迁移、数据校验和业务高峰期错开。	离线任务上班前和下班后执行

任务调研

调研内容	描述
任务调度	如 Azkaban、DolphinScheduler，Hera、Crontab 等。
任务类型	基于编程语言分类：Jar 类：常用于 MRS、Flink、Spark 等；SQL 类：常用于 Hive、Spark、UDF 等；Python 类：常用于 Spark、算法场景等；其他类：如 Shell、Scala 等，多用于脚本调用
任务数量	调研各类任务的总数量，用于评估任务迁移周期及改造工作量。如：xx 调度平台下，Jar 任务 XX 个。
任务更新周期	识别出不同调度平台，不同任务类型的任务更新周期。如：xx 调度平台 xx 类任务月度更新；xx 平台 xx 类型任务每日 XX 点更新。
任务详细信息	识别出所有任务的详细信息，包括任务 ID、名称、责任部门、责任人、执行时间、更新周期等。用于后续任务改造和迁移时，和关键人员及时沟通。
任务依赖关系	识别关键任务，识别任务间依赖关系。

3.5、调研方式与云服务选型

一、调研方式总结

1. 不同调研方式的适用场景（按操作难度从易到难）

方式	适用场景	优势	不足
CMDB 平台	客户有含应用调用模块的 CMDB	依赖少、能直接获取资源 / 数据关联信息	信息可能老旧，不支持批量导出
现网云管平台	客户有 CMP / 虚拟化管理平台	资源详情准确	拿不到应用架构、关联关系
现有文档	客户有完整设备档案 / 方案	快速获取信息	文档时效性、完整性无保证
安装工具（RDA 等）	客户同意装 agent	快速拿到资源清单	敏感、难获取数据库 / 中间件 / 调用关系
调研访谈	客户人力充足	业务团队负责资源 / 调用关系	周期、信息准确性不可控

2. 调研方式的综合对比

调研渠道	效率	完整度	真实度	核心覆盖场景
现网 CMDB	高	高	中	应用架构、技术架构（需整理）
现网云管平台	高	低	高	技术架构（组件详情）
现有文档	高	不确定	不确定	应用 + 技术架构（内容可能不全）
RDA 工具收集	中	低	高	技术架构（组件详情）
调研 & 访谈	低	高	高	全场景（应用 + 技术架构）

二、云服务选型总结

1. 计算云服务（ECS/CCE）

• 选型原则：业务适配优先、兼顾性价比、可靠性（选新系列、跨可用区）、规格一致、选主力型号；
• 典型场景选型：
  • 接入层（Nginx / 跳板机）：c/m/t 系列；
  • 应用层（Web / 转码）：ac/am/c/m 系列；
  • 中间件 / 数据层（自建 Redis/MySQL）：c/m 系列。

2. 存储云服务（EVS/SFS/OBS）

服务	特点	适用场景	核心选型原则（业务 + 成本 + 可靠）
EVS	高 IO、类硬盘	核心业务 / 开发测试	业务适配（访问方式 / 共享）、成本优化（容量预测）、可靠（跨可用区）
SFS	高带宽、共享	媒体处理 / 文件共享	同上，支持跨可用区共享
OBS	海量、低成本	大数据 / 静态资源	需业务改造 API 访问，适合大容量 / 长周期存储

3. 网络服务

核心选型建议：

• VPC 互通：同域用对等连接、跨域用云连接 CC、云上云下用云专线；
• 负载均衡：低并发用共享 ELB、高并发用独享 ELB；
• 公网访问：ECS 通过 NAT 网关走公网，服务通过 ELB/NAT 暴露公网；
• 高可用：ECS 跨可用区部署，配虚拟 IP+keep-alive。

3.6、上云评估

一、上云可行性评估

围绕 “迁移源（A）→迁移方案（C）→迁移目标（B）” 的流程，从 3 个维度评估：

1. 迁移业务影响评估：针对迁移源（A），评估迁移过程对业务、周边关联关系的影响；
2. 迁移风险评估：针对迁移方案（C），评估工具、方案、环境、停机时长、人力等风险；
3. 云服务满足度评估：针对迁移目标（B），评估云服务在功能、性能、可用、成本等方面是否匹配目标架构。

最终输出整体上云迁移风险及应对策略。

二、云服务满足度评估

• 评估对象：计算、网络、存储、数据库等云服务模块；
• 评估维度：功能（如 MySQL 读写分离）、性能（如 TPS/QPS）、可用性（如跨可用区部署）、资源（如 ECS / 数据库数量）；
• 流程：基于技术架构 / 上云需求调研结果，对比云服务指标（必要时做 POC 测试），输出《云服务满足度评估报告》。

三、上云迁移风险评估

• 评估对象：计算、网络、存储等迁移模块；
• 评估维度：迁移工具（是否有工具支撑）、迁移方案（是否成熟）、实施环境（是否满足）、切换时间窗（停机时长是否可接受）、人力（客户 / 团队能力是否足够）；
• 流程：结合系统现状 / 上云需求，用《迁移风险 checklist》+ 专家经验评估，输出《迁移风险评估报告》。

四、典型风险及应对策略

风险维度	常见场景	应对策略
迁移工具	缺少自动化工具	用开源 / 伙伴工具，或研发自动化迁移脚本
迁移方案	方案无成熟案例	研发验证方案，或在测试环境验证
实施环境	网络不稳、不支持回退	建专用网络；离线迁移；建反向同步链路应对回退
切换时间窗	要求 “0” 停机	分析业务是否真无窗口，沟通改造工作量
人力满足度	缺开发 / 运维 / 验证人员	必须协调对应人员配合，否则风险不可控

五、调研评估的反模式（避坑点）

反模式	优化建议
调研方法错误	用 “先易后难、持续迭代” 法：先从 CMDB / 文档梳理缺口，再精准调研
业务调研不足	深入业务场景，确保上云匹配业务需求
评估不全面	建立覆盖成本、性能、安全等维度的评估体系
低估迁移复杂性	分析内外部关联关系，识别强弱依赖，降低迁移风险

4、迁移上云方案设计和试点规划

• 云上架构设计包括基础环境设计、应用部署架构设计、大数据架构设计三部分，架构设计的工作对于上云迁移起到重要的支撑作用。
• 上云迁移试点是企业在进行大规模上云迁移之前的重要步骤，它能够帮助企业在大规模迁移之前充分了解和评估各种因素，通过试点上云迁移流程与相关配置，企业可以提前识别出相关风险，为后续大规模上云迁移提供经验。

4.1、组件方案设计团队

4.2、基础环境设计

​ 企业在云上的基础环境主要就是Landing Zone，企业在将任何业务系统云化之前，都需要提前规划和设计一个架构卓越、稳定可靠、易扩展和安全合规的云上运行环境。请参考章节——Landing Zone设计。

4.3、应用架构设计

一、应用部署架构的核心框架

应用部署架构分为四层，每层对应云服务组件：

• 接入层：虚拟专有网络（VPN）、弹性公网 IP（EIP）、云专线；
• 应用层：弹性云服务器（ECS）、云容器引擎（CCE）、云容器实例（CCI）；
• 中间件层：分布式缓存（Redis/DCS）、分布式消息服务（Kafka）；
• 数据层：云数据库（NoSQL）、关系型数据库（RDS）、弹性文件服务（SFS）、对象存储（OBS）。

二、架构设计的 “六要素”

设计需兼顾 6 个维度，其中可用性、可扩展性、性能是重点，安全、成本、可运维性为全局设计：

1. 可用性：保障系统异常时稳定运行，业务连续；
2. 可扩展性：随负载灵活伸缩，避免崩溃 / 性能下降；
3. 性能：满足响应时间、吞吐量、并发数等需求；
4. 安全性：保护应用 / 数据，防攻击 / 泄露；
5. 成本：在保障性能 / 可用的前提下降本；
6. 可运维性：实现自动化部署、监控、故障快速恢复。

三、可用性设计的关键落地方式

1. 可用性 SLA（服务级别）

不同 SLA 对应故障时长上限（如 99.99% 对应年故障仅 52.56 分钟）。

2. 高可用部署方案

• 跨 AZ（可用区）部署：组件分散到多个 AZ，单个 AZ 故障不影响整体；
• 负载均衡：流量分发到不同 AZ 实例，避免单 AZ 过载；
• 数据冗余 / 备份：多 AZ 存数据，故障时从冗余副本恢复；
• 自动故障恢复：AZ 故障时自动切换到可用 AZ；
• 监控告警：实时监测状态，故障时及时通知。

3. 典型高可用方案

• 双 AZ 方案：四层架构全链路双 AZ 部署，通过负载均衡（ELB）、数据同步（RDS 主备）、容灾切换（SDRS）实现高可用；
• 两地三中心方案：生产 / 容灾中心分属不同 Region，跨 Region 数据同步（OBS），故障时通过 DNS 切换流量，保障极端灾难下业务连续。

四、可扩展性设计要点

各层通过 “纵向（升级规格）+ 横向（增加实例）” 伸缩：

• 应用层：微服务用 CCE 弹性伸缩 POD；ECS 用弹性伸缩服务（AS）；
• 中间件层：消息中间件（DMS）、缓存（DCS）随负载平滑扩规格；
• 数据层：数据库用读写分离（RDS）、分库分表（DDM）、存算分离（GaussDB）实现水平扩容。

五、性能设计

1. 影响性能的核心因素

计算 / 网络 / 存储 / 数据库资源，对应时延、吞吐量、IOPS、并发能力四个指标。

2. 性能设计原则

• 按需定指标，避免 “无底线” 堆资源；
• 合理选用新技术，平衡收益与风险；
• 针对数据热点设计缓存，缓解系统压力；
• 结合云弹性，通过集群实现快速伸缩。

4.4、大数据架构设计

云上大数据集群部署架构设计参考原则：

1. 优先用大数据云服务：综合考虑功能、性能、兼容性的满足度，结合改造工作量评估，选择“云上”或自建。
2. 最小改造原则：无特别的业务驱动，尽量避免大规模改造。集群组件要1:1对标设计，版本尽量一致。
3. 弹性扩展和自动伸缩：设计云上大数据集群时，应考虑弹性扩展和自动伸缩能力。根据负载情况增减资源，提高性能、效率并节约成本。
4. 容错和高可用性：云上集群应具备容错和高可用性，通过多副本、冗余节点和故障转移机制来实现。
5. 数据安全和合规性：云上集群需要有严格的数据安全和合规性保障，通过数据加密、身份验证、数据隔离等措施来保证。

大数据参考架构：

4.5、制定6R策略和标签方案设计

一、应用上云迁移的 6R 策略

6R 是应用上云的核心迁移策略，需结合业务驱动选择，流程为 “调研→评估→规划策略→业务 / 数据验证→切换→生产上线”：

策略	定义 & 操作	举例（场景）
Rehost	直接迁移（无改动）：手动安装配置 / 用迁移工具自动迁	IDC 自建 MySQL 迁到 ECS 自建 MySQL
Replatform	平台迁移（少量适配）：迁到云端平台并修改基础架构	IDC 自建 MySQL 迁到云端 RDS
Repurchase	重新采购：直接用云端 SaaS 服务替代原有应用	本地 CRM 迁到云端 Salesforce
Rearchitect（Refactor）	重构迁移：云原生改造后再上云	本地 Oracle 改造成云端 GaussDB；单体应用拆分为微服务
Retain	保留：应用继续留在原环境（如旧版应用）	保留旧版系统直到生命周期结束
Retire	下线：删除原环境中无用的应用	下线低利用率服务，回收 IT 资源

6R 策略的选择逻辑（以业务驱动为核心）

• 加速创新：选 Rearchitect，虽成本高、周期长，但业务收益（创新速度）高；
• 降低成本：选 Rehost/Retire，迁移风险低、成本低；
• 提升可用性：选 Replatform，迁到云端托管服务，搭建高可用架构。

二、标签方案设计（云资源管理）

标签是云端资源的 “分类标识”，用于高效管理大量云资源：

1. 标签的作用

• 快速筛选 / 管理资源：通过标签批量操作（检视、修改、删除）；
• 规范资源场景：标识环境、归属、超期时间，定期清理非法资源。

2. 标签管理服务（TMS）

提供跨区域 / 跨服务的标签集中管理能力，功能包括：

• 资源标签搜索（多服务 / 多 Region）；
• 资源标签可视化管理；
• 预定义标签规划、导入 / 导出标签库。

3. 标签设计的要点

• 需跨团队（财务、运维、安全等）做需求分析，明确标签场景；
• 遵循规范：不存敏感信息、格式统一、长度简洁；
• 按场景定义标签：

应用场景	标签键	允许的标签值
成本管理	Department	Marketing, Engineering, Sales，Service，Research 等
成本管理	Application	CRM，ERP，HRM，财务管理系统等
成本管理	CostCenter	123, 456, 789 等
权限控制	Environment	Development, Test, Stage, Product 等
权限控制	Layer	DB, App, Web 等
数据分类	DataClass	Public, Private, Confidential 等
安全运营	Compliance	PCI-DSS, HIPPA 等
运维和自动化	Status	Active, Inactive, Deprecated 等

4.6、选择上云试点应用

一、为什么要做上云试点？

试点是大规模上云前的 “小范围验证”，核心价值包括：

• 风险控制：验证迁移流程、识别潜在风险（小范围暴露问题）；
• 验证可行性：评估业务在云环境的适应性；
• 掌握经验：技术 / 业务团队积累云平台实操技能；
• 确定优先级：评估不同业务的迁移优先级；
• 性能优化：提前发现性能瓶颈并调整；
• 成本控制：摸清云服务的费用结构与隐藏成本；
• 团队磨合：识别协作问题，制定改进措施。

二、如何选择试点应用？

需从 7 个维度筛选，优先选 “价值高、难度低、风险小” 的应用：

1. 上云意愿：选团队投入积极、人力充足的业务；
2. 上云价值：选能量化价值（降本、提可用、快部署）的应用；
3. 业务重要性：选重要但不影响日常运营的应用；
4. 实施难度：选团队能力可覆盖、难度低的应用；
5. 业务影响：选上云后对其他业务流程影响小的应用；
6. 安全性：避开有安全风险、违规风险的应用；
7. 可测试性：选能充分验证方案、可测试性强的应用。

三、上云试点的执行流程

按 “选→做→总结” 的逻辑推进：

1. 试点应用选择：按上述 7 个维度选定应用；
2. 应用迁移小循环：按 “调研→设计→部署→迁移→验证→切换→保障” 的流程执行；
3. 试点总结：沉淀经验、优化方案，为大规模上云做准备。

4.7、迁移批次规划

一、迁移规划相关概念

中文	英文	说明
迁移批次	Migration Wave	迁移批次是指一组具有相同的预期开始和结束日期的一个或多个迁移分组的组合，一个 Wave 可能含有多个 Migration group
迁移批次规划	Migration Wave Plan	迁移批次规划包括 wave 的规划和迁移优先级 migration prioritization 的规划
迁移优先级	Migration Priority	迁移应用程序的顺序
迁移分组	Migration Group	迁移分组是一组具有依赖关系（含环境依赖）的应用程序和基础架构的集合，包括 APP、主机、存储、数据库、中间件等
关联关系分析	Dependency Analysis	关联关系分析主要是识别应用程序和基础架构依赖关系，包括技术依赖和非技术依赖
关联关系分组	Dependency Group	关联关系组是具有无法解决的技术和非技术依赖关系的应用程序和基础架构的集合
应用切换	Cut Over	应用切换的对象是迁移分组，将业务流量从一个环境切换到另一个环境运行
应用迁移方案	App Migration Solution	以应用为单位的迁移方案，包含所有技术组件的迁移方案和应用的切换方案
迁移原子方案	Technical Solution	以技术组件为单位的迁移方案，包括迁移各类技术组件所用的工具和迁移方法，如主机迁移采用 SMS，数据库迁移采用 DRS 等
着落区	Landing Zone	Landing Zone 是一个航空术语，是飞机可以着陆的区域，云上的 Landing Zone 是云上安全、合规、可扩展的多账户环境，实现多账号的资源共享和 “人财物权法” 的统一管控，设计好 Landing Zone 企业上好云的第一步，Landing Zone 可以类比为 “写字楼的公共装修部分”
应用上云目标技术架构	App to-be Technology Architecture	应用上云目标架构包括接入层、应用层、中间件层、数据层、采集层的云上网络架构、资源选型、业务连续性架构、运维架构等

二、迁移批次规划的核心逻辑

规划是 “数据 + 经验” 结合的过程，需完成 3 件事：分迁移分组、定迁移批次、排迁移优先级。

1. 迁移分组：按依赖关系打包

分组原则：把有共享数据、共享服务、应用通信依赖的组件放到同一组（避免拆分后业务断连）。例：App A、B 和数据库 db01 是紧耦合（高频读写），需放同一组；App C 和 db01 是松耦合（夜间批处理），可单独分组。

2. 迁移分批：控制规模 + 风险

分批参考原则：

• 强关联的应用放同一批次，避免云上云下互访延迟；
• 一个批次跨度 4~8 周（含部署 / 迁移 / 切换），规模不宜过大（建议≤20 个应用、150 台服务器）；
• 同一供应商的系统放同批次，方便协同；
• 测试环境和生产环境分批次（先迁测试，降低生产风险）。

3. 迁移优先级：按规则排序

优先级的核心依据：

• 客户意愿是第一优先级；
• 无明确意愿时，按 “业务环境（测试先）、业务重要性（一般先）、关联度（简单先）、架构复杂度（简单先）、停服时长（长的先）、迁移策略（平迁先）” 等维度打分，分数高的优先迁。

三、迁移批次规划的流程

输入 “应用关联性、优先级影响因子”→ 输出 “迁移分组、应用优先级”→ 结合 “分批原则”→ 最终输出 “迁移批次规划”。

四、方案设计的避坑点（5 个 “反对”）

• 反对资源配置不合理（没匹配业务负载）；
• 反对设计单点故障（没考虑高可用）；
• 反对直接迁移旧架构（没做云适配优化）；
• 反对忽略业务地理分布（导致用户访问延迟高）；
• 反对忽略合规 / 法律要求（引发数据风险）。

5、迁移上云实施和运维

企业上云通常先进行试点，试点以后进入大规模的上云迁移阶段。

5.1、实施团队组建和基础实施部署

上云实施团队组建：

1. 项目经理：整个上云实施的项目管理。
2. 迁移实施工程师：负责具体实施工作。
3. 云基础设施管理员：负责管理云基础设施，支持云环境的管理和优化。
4. 应用开发工程师：负责业务上云的适配改造。
5. 云架构师：负责云上架构部署和优化。
6. 云安全专家：专注云安全和合规。
7. 应用测试工程师：负责业务的功能、性能等测试，配合切换演练和正式上云操作。

基础设施部署：

基础设施部署主要是部署 Landing Zone，有三种部署 Landing Zone 的方式。

• 第一，由实施人员手动在华为云上部署 Landing Zone，这种方式非常灵活，不受自动化工具的功能限制，但部署周期比较长。
• 第二，基于资源治理中心完成自动化部署 Landing Zone。但资源治理中心部署的是最小化 Landing Zone，不一定符合企业的实际需求，还需要在此基础上通过手工或自动化的方式进一步设置 Landing Zone。
• 第三，使用华为云提供的资源编排服务 RFS 或第三方自动化工具（如 Terraform 等）实现 Landing Zone 的自动化部署和管理。华为云资源编排服务（Resource Formation Service，简称 RFS）是完全支持业界事实标准 Terraform（HCL + Provider）的新一代云服务资源终态编排引擎。基于业界开放生态 HCL 语法模板，实现云服务资源的自动化批量构建，帮助用户高效、安全、一致创建、管理和升级云服务资源，能有效提升资源管理效率，并降低资源管理变更带来的安全风险。

5.2、应用迁移上云

一、核心定义与迁移范围

应用上云迁移是将应用的接入层、应用层、中间件层和数据层迁移到云端的过程，迁移策略采用 Rehost（直接迁移）或 Replatform（平台迁移），不含 Refactor（应用改造）。数据层涵盖对象存储、块存储、文件存储、关系型数据库、非关系型数据库等类型。

二、迁移核心流程（应用迁移小循环）

迁移以 “迁移分组” 为执行对象，通过七阶段小循环保障迁移有序推进：

1. 调研：详细摸排应用技术架构，明确具体技术组件及版本信息；
2. 设计：基于调研结果，规划云上技术架构与规格选型，输出迁移方案和切换方案；
3. 部署：创建云上资源，完成上云适配改造（如涉及），并开展目标环境测试；
4. 迁移：将源端应用和数据迁移至云上目标环境；
5. 验证：进行数据一致性与业务功能验证；
6. 切换：开展切换演练，完善 Runbook（操作手册），执行正式切换；
7. 保障：切换后进行一段时间的实时监控与专项运维保障。

三、基于四层架构的迁移方案

（一）接入层

• 核心组件：负载均衡（硬件 / 软件）、Nginx/Openresty、微服务网关（Kong/Zuul）、DNS 域名解析等；
• 迁移方式：以重新配置为主，部分场景可通过 SMS 工具迁移服务器或在华为云 ECS 重新部署后拷贝配置文件并修改转发策略。

（二）应用层

1. 部署在主机 / 虚拟机的应用：优先使用华为云 SMS 主机迁移工具（全量 + 增量迁移，停机时间短）；无法使用 SMS 时可重新部署；停机窗口较长（≥4 小时）时可采用镜像导出导入；
2. 部署在容器的应用（云原生 / 微服务架构）：推荐通过企业 CI/CD 系统重新发布（操作简单、配置可控），也可采用容器镜像迁移或 Velero/E-Backup 等迁移工具。

（三）中间件层

1. Redis（缓存 / 持久化数据库）：缓存场景可选择数据预热或迁移工具迁移；持久化场景推荐华为云 DCS 迁移工具（全量 + 增量，停机时间短），也可采用 RDB/AOF 文件备份恢复；
2. 消息中间件（RabbitMQ/Kafka/RocketMQ 等）：切换时间充足时，待消息消费完成后直接切换；时间有限时，使用 MirrorMaker2.0（开源）或华为云 SmartConnect 工具（界面化、操作简单）迁移，支持消费队列 offset 偏移量同步。

（四）数据层

1. 结构化数据（MySQL/SQLServer/PostgreSQL 等）

• 推荐方案：华为云 DRS 数据复制服务（全量 + 增量，配置简单、支持实时同步）；
• 备选方案：mysqldump/pg_dump 导出导入（全量，适用于停服时间长场景）、主从复制（仅适用于自建数据库且 DRS 不兼容场景）。

2. 非结构化数据（NAS / 对象存储等）

• NAS 迁移：推荐华为云 CDM 服务（全量 + 增量，支持海量数据，操作简单），备选开源工具 rclone/rsync；
• 对象存储迁移：推荐华为云 OMS 服务（全量 + 增量，高并发、支持数据校验与可视化报告），备选开源工具 rclone/rsync。

四、切换方案设计

（一）切换类型及特点

切换类型	核心说明	优点	缺点	适用场景
停服切换	停止服务后切换，保障数据一致性	投入少、风险小	业务中断	停机窗口较长、业务关联复杂的场景
停写不停读切换	拦截写请求或停止写服务，保留读服务，保障数据一致性	业务不中断	需业务整改、潜在功能风险较大	有统一网关、读写分离或可轻微改造的场景
不停服切换	通过双写 / 双向同步实现零中断	业务零中断	客户 / 华为投入大、数据一致性风险高	对业务中断敏感、停机窗口极小的场景

（二）停服切换优化方式

1. 缩短停服时长的方法：分批切换（减小批次规模）、操作自动化（配置修改 / 测试自动化）、多次演练（提前识别问题）、业务改造（双跑模式）；
2. 常见切换策略：一把切（全业务一次切换，适用于关联复杂场景）、应用灰度切流 + 数据层整体切换（中停机时长）、应用灰度切流 + 数据层分批切换（短停机时长）、按业务域分批切换（适用于业务独立场景）。

五、测试与验证

（一）数据验证

• 一致性要求：核心业务（交易 / 支付数据）100% 一致，非核心业务 99.9% 一致，边缘业务（用户画像 / 推荐数据）90% 一致；
• 验证方法：数据库数据用 DRS 工具 /python 脚本对比，中间件数据用 redis-cli/Redis-Full-Check 工具对比，文件数据用 OMS/rclone 等工具对比。

（二）业务验证

• 阶段：部署完成后切换前、切换后均需验证；
• 内容：功能验证（冒烟测试、全业务测试、日志分析等）、性能验证（操作系统 / 数据库 / 接口 / 中间件性能，含 TPS/QPS、响应时间、并发量等指标）。

六、关键保障文档与动作

（一）Runbook（操作手册）

• 核心内容：明确切换步骤、操作人 / 确认人、时间计划、串并行顺序、脚本化操作、失败回退策略；
• 角色分工：操作人（执行操作）、确认人（验证结果）、引导人（统筹执行）、记录人（记录状态）、决策组（决策关键节点）、会务组（保障现场）。

（二）切换演练与正式切换

• 演练要求：至少 2 次，模拟生产环境，与正式切换人员、步骤一致，复盘优化 Runbook；
• 正式切换：完成停机窗口确认、公告发布、人员通知等前置准备后，按 Runbook 执行流量转发、服务停止、数据迁移、切换验证等操作。

（三）切换后保障

• 组建保障团队（覆盖 PM、SRE、TAM 等角色）；
• 持续监控与深度巡检，控制现网变更，建立定期沟通机制，针对关键场景强化应急处理。

5.3、应用现代化

一、核心定位

“上云” 是完成迁移与架构搭建，“云上” 需通过应用现代化优化业务体验、支撑业务创新。

二、什么是应用现代化

传统应用向现代化应用的升级，核心是通过新的理念、技术、方法对传统应用改造，实现用户体验提升、降风险、缩上市时间、提研发效能，最终释放企业数字生产力。

传统应用 vs 现代化应用的差异：

维度	传统应用	现代化应用
架构	单体、高耦合	微服务、解耦易组合
用户体验	多入口、体验割裂	以用户为中心、一站式个性化
业务响应	难适配新业务	快速组合、按需定制
交付周期	年 / 月级（绑定大版本）	周 / 天级（快速迭代）
团队模式	大规模、传统开发	小团队、DevSecOps 敏捷运作
部署方式	物理服务器	容器化、全面上云

三、华为云对应用现代化的定义

通过体验重塑、云原生技术、组件标准化、效能工具四大支撑，实现四大目标：

• 用户体验提升：设计精美、用户友好、简洁易用；
• 降低现网风险：无损更新、高效流畅、安全稳定等；
• 缩短上市时间：快速装配、业务配置快速组装；
• 研发效能提升：自动化、高效协同、安全可信。

四、应用现代化的关键实践

（一）基础设施现代化：应用容器化

通过 8 个步骤实现：

1. 评估规划：分析服务特性、依赖关系，筛选适合容器化的应用；
2. 平台选择：采用 Docker+Kubernetes；
3. 应用容器化：编写 Dockerfile、拆分微服务；
4. 容器编排：实现自动扩展、负载均衡（声明式 API）；
5. 网络存储配置：容器网络互通、数据持久化；
6. 安全与监控：镜像漏洞扫描、权限控制、状态 / 性能监控；
7. 测试部署：单元 / 集成 / 性能测试、自动化部署；
8. 持续集成交付：落地 CI/CD、DevOps。

（二）架构设计现代化：服务化架构

通过两种模式提升灵活性与资源利用率：

• 微服务：全托管端到端生命周期，基于微服务引擎 CSE，配套注册发现、配置、服务治理等能力，结合 CCE/ServiceStage 等实现托管运维；
• Serverless：业务与资源解耦，通过 FaaS（开发门槛低、极致弹性）+ BaaS（集成 10 + 后端服务），依托华为元戎内核实现高效资源利用。

（三）开发与运维现代化：DevOps 全流程

落地云上全流程 DevOps（覆盖 Web / 移动 / 微服务等应用类型），核心价值：

• 更快交付：周 / 天级 TTM、在线协同；

• 内建质量：工具预置规范 + 最佳实践；

• 智能化开发：AI 赋能代码生成、测试、运维等环节；

  通过华为 CodeArts 工具链实现一站式流程，支撑高并发研发（如华为自研日流水线 20 万次、部署 15 万次等）。

（四）治理与运营现代化：资产全生命周期管理

实现资产 “可视、可管、可用、可溯”，核心是通过 Roma Exchange 做异构资源服务化治理，覆盖：

• 统一用户接入、API 规范、资产打包规范、资源纳管、运维监控；
• 落地数字资产中心（资产共享 / 变现）、差异化场景体验（业务 / 开发 / 运营按需用）、数字化运营阵地（资产分析、知识中心等）。

五、云采用实施的避坑点

需避免四类 “反模式”：

1. 未采用自动化部署模式；
2. 未进行切换演练；
3. 测试不充分；
4. 资源未打标签。

5.4、云上运维与治理

应用系统迁移 / 部署上云后，云化转型进入运维治理阶段，核心包含四大方向：精益化治理、确定性运维、安全运营、FinOps。

一、精益化治理：构建精益 IT 治理体系

通过华为云 Landing Zone 解决方案，围绕 “业务单元、人员、资源、数据、安全合规、财务” 六大治理要素，实现收益与风险的平衡：

• 治理目标：业务单元分级分域隔离、人员权限精细化管控、资源共享可控、数据边界安全、全链路安全防护、成本持续优化；
• 治理方案：配套成员账号管理、RBAC/ABAC 权限控制、资源共享管理、数据边界控制等能力，依托 IAM、身份中心等核心服务落地。

二、确定性运维体系：实现高可靠、智能化运维

分阶段构建运维能力，核心是保障 “质量、可用、风险、智能”：

• 阶段演进：2017-2019 年启动变革 / 构建组织→2020-2022 年建运维质量工程 / 初步形成体系→未来持续智能化；
• 能力成果：年变更 400 万次（自动变更率 92%）、高危命令自动拦截率 99.9%、月 API 调用超 21 亿次；
• 核心支柱：以质量文化为基础（开发与 SRE 共担 SLO）、高可用架构为前提（失效 / 恢复 / 影响范围可控）、动态风险治理为保障（全生命周期主动运维）、智能运维为未来（自动恢复、智慧故障定位）。

三、安全运营：持续安全保障体系

贯彻 “安全经验即服务”，助力企业构建安全运营中心，核心能力包括：

• 安全治理：合规检测 IT 化，一键生成等保 / PCI DSS 等合规报告；
• 安全编排：20 + 内置处理剧本，99% 事件分钟级自动化响应，支持自定义 / 第三方剧本；
• 态势感知：采集多类安全告警并关联分析，通过大屏 / 报告全景展示安全态势；
• 威胁管理：200+AI 检测算法 + 华为云每日数亿威胁情报，实现高级威胁识别；
• 日志 & 资产管理：预置接入 60 + 类安全数据，云上资产 100% 自动盘点、云外资产统一纳管。

四、FinOps：成本可视化与持续优化

通过 “成本可视（Inform）→成本优化（Optimize）→成本运营（Operate）” 三阶段闭环管理：

• 可视：理清成本趋势、构成，预测未来成本；
• 优化：提供智能化成本优化建议；
• 运营：从组织、文化、流程等维度建设成本运营体系，实现上云成本的端到端管控。

5.5、迁移中心MGC介绍

迁移中心（Migration Center，MgC）是华为云一站式上云迁移与现代化平台，基于华为云迁移交付方法论 CMF 设计，覆盖上云全流程能力，助力用户高效完成应用资源迁移。

一、核心定位与能力

• 定位：租户侧云服务，提供向导式迁移流程，覆盖调研、资源采集、应用关联分析、评估、资源发放、迁移原子能力编排等全阶段；
• 核心价值：简化上云操作，提升迁移效率与可控性。

二、应用场景

支持四类核心场景：

1. 应用现状调研：提供丰富调研能力，覆盖友商 / IDC 中的应用现状；
2. 存储迁移：通过专属迁移集群 + 专线，实现对象存储、文件存储一站式上云；
3. 批量迁移：灵活定制迁移工作流，基于源端性能数据推荐华为云主机规格，一站式批量发起任务；
4. AZ 间迁移：提供迁移流程模板，高效完成可用区之间的资源迁移与业务切换。

三、关键功能

（一）资源发现与采集

支持多场景的资源采集方式：

• 云平台采集：公网在线发现并采集源端云平台资源，梳理资源与应用关联；
• VMware 采集：内网部署 MgC Agent，扫描采集 vCenter 主机 / 磁盘信息；
• IDC 采集：内网部署 Agent，通过网段扫描采集线下 IDC 主机资源；
• 手工导入：支持 RVTools 表格、云资源文件等手工导入信息。

（二）迁移风险评估

迁移前提前检查风险项（兼容问题、固件兼容、规格差异等，目前仅支持主机），支持两种评估策略：

• 按资源评估：勾选资源列表中的主机；
• 按应用评估：创建应用并加入待评估主机，勾选应用进行评估。

（三）迁移校验中心

提供统一数据校验模型，覆盖大数据、对象存储、数据库等场景：

• 核心能力：数据采集（源端 / 目的端数据采集与格式化）、校验策略管理（Sum/Avg/ 误差等策略）、对数分析（任务进度 / 结果）、对数报告（风险 / 误差 / 建议）；
• 价值：解决数据验证难、手工校验成本高的问题。

四、实践案例

案例 1：IDC 批量应用上云

• 痛点：微服务多（600+）、应用调用关系复杂、IDC 资源量大（3000+VM）、搬迁周期长；
• 方案：通过 MgC 做应用关联分析（自动采集资源）、批量迁移（规划迁移批次）；
• 效果：采集效率提升 260%-460%，应用关系分析周期缩至 7 天，迁移效率提升 60%、成本降低 30%。

案例 2：大数据迁移及对数

• 痛点：数据日增 200TB（总量 PB 级）、表数量 6k+、手工验证成本高（700 + 人天）、数据不准确；
• 方案：通过 MgC 完成 CDH 到 MRS 的元数据迁移，结合大数据对数能力（全量 / 增量 / 指定日期校验）+ 血缘分析；
• 效果：数据问题定位效率提升 9 倍，迁移数据 0 误差，成本降低 20%。

6、迁移实施案例

了解不同行业场景的上云迁移过程。

6.1、金融行业上云迁移案例

该案例是某保险公司的全业务架构上云迁移方案，覆盖环境准备、架构设计、迁移执行、切换与回滚全流程。

一、业务架构基础

保险公司业务架构分为多模块，涵盖渠道（OnePartner）、客户管理（OneCounter）、核心业务（OneLife/OneFinance 等）、数据中台（OneData）、办公系统（OneOffice）、开发运维（OneCloud&OneService）等，是典型的金融多系统协同架构。

二、上云环境准备

1. 组织账号设计（Landing Zone）

• 以 ROOT 为根节点，分拆为 IT_Function（IT 职能）和Business（业务） 两大组织单元；
• IT_Function 下分 Security（安全审计）、Infra（网络管理）；
• Business 下分 Prod（生产）、Staging（预发）、Non-Prod（非生产），每个业务线单独规划账号，实现资源隔离与权限管控。

2. 网络架构设计

• 保留原有 DC 的 DMZ 区域作为公网出入口，专属云与原有 DC 通过专线连通；
• 专属云内部通过 VPC Peering 打通不同 VPC 网络，划分业务应用部署区（生产 / 预发 / 测试 VPC）、公共服务区等；
• VPC 内按子网划分组件（应用 / 中间件 / 数据库），通过安全策略隔离，仅开放固定 IP / 端口访问。

三、上云部署架构（首批 3 个应用）

采用双可用区（AZ）高可用架构：

• 接入层：以原有 DC 为入口，通过 Nginx 做负载均衡；
• 应用层：无状态组件双 AZ 集群部署，有状态组件跨 AZ 主备部署；
• 中间件层：自建 Redis / 消息队列先迁移上云，后续替换为云上中间件（DCS/DMS）；
• 数据层：数据库双 AZ 主备部署，后续替换为云上数据库（RDS）；
• 配套仲裁组件保障 AZ 故障时自动切换。

四、迁移方案

分组件制定迁移策略：

组件类型	源端（IDC）	迁移方式	目标端（华为云）
配置	安全组策略	重新配置	安全策略
虚拟机	主机	RDA + 重新部署	ECS
中间件	自建 Redis/MQ	重新部署 + 数据同步	自建 Redis/MQ
数据库	自建 SQLServer/Oracle 等	备份还原 / XTTS/Binlog 同步等	自建对应数据库
存储	FTP/MinIO	rclone 工具迁移	对应存储服务

迁移流程分为 4 阶段：准备目标端资源→目标端部署验证→增量迁移与业务切换→持续监控与资源清理。

五、切换与回滚方案

1. 正式切换（停服切换）

• 耗时约 12 小时，前置阶段完成数据实时同步、配置修改；
• 切换步骤：数据备份→停止定时任务→应用断网→增量数据同步与验证→修改配置 / 重启服务→启动定时任务→业务验证。

2. 回滚方案

• 回退标准：未达切换成功标准则执行回退；
• 回退步骤：恢复配置→应用联网→启动原有定时任务；
• 切换期间新增数据：在原有生产环境手工录入。

6.2、互联网行业上云迁移案例

该案例是某互联网电台从 A 云迁移至华为云的全流程方案，涵盖业务架构、架构优化、迁移执行及切换策略。

一、业务架构基础

电台业务架构分层清晰，覆盖用户端（多终端）、业务系统（营销 / 会员 / 音频等）、中台（用户 / 内容 / 支付）、后台（主播 / 版权管理），并配套数据平台、算法、安全及基础架构，特点是云原生架构、业务并发高、数据流量大。

二、架构优化（关键发现与改进）

针对现有架构问题，从降本、性能、架构等维度提出优化建议：

类别	问题点	优化建议
降本增效	待下线 ECS 资源闲置	关机释放资源，降低成本
性能调优	用户系统 MySQL 无分库分表，性能瓶颈	使用华为云 DDM 分库分表服务
架构升级	生产 / 测试环境互访、共用数据库	VPC 隔离环境，拆分共用数据库
架构升级	多配置中心、CI/CD 工具不统一	归一配置中心，接入 AMS 统一管理 CI/CD
容器化改造	容器化不彻底、老业务无人维护	完成老业务云原生架构升级

三、整体迁移方案

采用分批迁移策略，按应用层（电台 / 内容中心等）、数据层（MySQL/MongoDB 等）分类制定迁移方式：

• 应用层：通过 AMS 重新发布；
• 数据层：MySQL/MongoDB 用 DRS 全量 + 增量同步，Redis 用 DTS，HBase 用 BDS 迁移；
• 关键注意点：提前识别增量迁移主机、Redis 迁移需开权限、MySQL 迁移避免拉跨源端业务等。

四、切换策略

1. 停服切换（版权 / 媒资等系统）

通过 “停服务→停任务→消费中间件→数据库只读→增量同步→华为云开放权限→切流量→改 DNS” 的步骤完成切换，同时配套回退流程（反向同步数据、切回 DNS）。

2. 停写不停读切换（4 种实现方式）

针对不同业务场景，采用差异化方案实现 “读业务不中断、写业务暂停”：

场景	适用业务	实现方式	优点
读写分离应用	电台	停写服务，保留读 API	业务改造后支持弹性伸缩
网关禁写（非读写分离）	音频系统	Kong 网关拦截写接口 + 数据层禁写	无需改代码，业务改动小
代码改造禁写	主播后台	发布禁写临时版本 + 数据层禁写	开发熟悉，适合局部写屏蔽
数据层禁写	用户系统	回收数据库写权限	分析工作量小，业务改动小

6.3、零售行业上云迁移案例

该案例是某全渠道零售企业的上云迁移方案，覆盖业务架构、迁移挑战、技术方案及切换保障全流程。

一、业务架构基础

企业采用多层级全渠道架构，涵盖：

• 触达端：线下（POS / 手持终端）+ 线上（APP/H5）+ 门店端（B 端 APP / 小程序）；
• 业务应用：支付网关、联华到家、云店等；
• 共享中台：业态共享（O2O / 云店等）+ 集团共享（商品 / 价格 / 库存等中台）；
• 基础服务：分布式框架、数据库、缓存等，同时对接第三方系统（物流 / 支付 / 分销等）。

二、上云核心挑战

迁移面临 “业务、技术、管理” 三重复杂场景：

类别	挑战要点
业务复杂	全渠道业务 + 4000 + 线下门店 + 几十家三方平台，涉及商超 / 百货等多业态
技术复杂	4000 + 操作系统、600 + 微服务、1300+JOB 任务，服务间网状调用
管理复杂	涉及 9 个二级公司、近 300 家三方合作商，项目任务超 1000 项，切换需近 200 人协同

三、云产品选型与迁移方案

按层级制定迁移策略，匹配华为云服务：

层级	源端（IDC）	迁移方式	华为云服务
接入层	自建 DNS/Nginx/BLB	重新配置 / 部署	自建 DNS/Nginx + 华为 ELB
应用层	ECS（Docker）	重新部署	ECS（Docker）
中间件	自建 Redis/ES/Kafka	RedisShake / 快照 / 先迁生产再迁消费	自建 Redis/ES/Kafka
数据库	MySQL/MongoDB/Oracle	DRS 全量 + 增量 / DG 实时同步	RDS/DDS/ 自建 Oracle

四、架构与切换设计

1. 高可用部署

将 IDC 单环境架构升级为华为云跨 AZ 高可用架构：接入层、应用层、中间件 / 数据库层均在 AZ1、AZ2 双节点部署，实现容灾冗余。

2. 切换方案选型

最终采用 “先应用层灰度切流，再数据层一把切” 方案：

1. 应用层分阶段切流（1%→10%→30%），数据层跨云访问；
2. 全量应用 + 数据层 “一把切”：关停所有应用 / JOB，数据层切换至华为云，重启服务并修改 DNS。

五、测试与演练保障

通过 “功能测试 + 性能压测 + 切换演练” 降低风险：

• 功能测试：在华为云生产 VPC 搭建接入 / 应用层，跨云访问 IDC 数据层验证功能；
• 性能测试：1:1 模拟生产环境压测；
• 切换演练：开展 4 次正向 + 1 次回退演练，识别解决 100 + 问题，优化 Runbook 任务 148 项，最终将业务停机时长压缩至 8 小时。

​

异同点：

1. 迁移核心流程一致：均遵循 “环境准备 - 资源部署 - 数据迁移 - 业务切换 - 监控回滚” 的标准化流程。先完成目标端网络（VPC、子网）、账号组织架构设计，再通过全量 + 增量同步迁移数据，最后实施业务切换并配套回滚方案，确保迁移安全性。
2. 高可用架构设计：均采用跨可用区（AZ）部署策略，应用层、中间件层、数据层通过主备集群或仲裁机制实现故障自动切换；网络层面通过 VPC 隔离、安全组策略、专线 / 内网互联保障数据传输安全与网络稳定性。
3. 数据一致性保障：均重视数据迁移的完整性与一致性，采用全量备份 + 增量同步（如 Binlog、DRS）方案，切换前进行数据比对验证；部分场景使用读写分离、数据库只读锁定等方式避免数据脏写。
4. 配套安全与监控：迁移过程中均配置防火墙、权限管控、备份策略，迁移后部署监控告警系统（如 Prometheus、日志 SLS），同时清理临时资源，优化资源利用率。

维度	金融行业（保险公司）	互联网行业（互联网电台）	零售行业（多业态集团）
业务核心诉求	安全性优先，合规性要求高（如财务、信托业务合规），业务连续性要求极强	高并发、高流量支撑，降本增效，架构云原生升级	全渠道协同（线上 + 线下），多业态、多三方系统兼容，短停机窗口
业务复杂度	核心系统集中（如 OneLife 核保系统），业务流程规范，第三方接口少（主要对接银行）	业务场景分散（直播、电台、主播管理等），用户交互频繁，数据流量大	业态复杂（商超、百货、医药等 9 + 二级公司），线下门店 4000+，三方平台数十家，微服务 600+
技术架构特点	传统架构与云架构并存，部分组件自建（如数据库、中间件），后续计划替换为云上服务（RDS、DCS）	基于开源云原生架构（K8s、Kong 网关），容器化需求强烈，依赖大数据分析（用户行为分析）	混合架构（物理机、虚拟机、容器），服务网状调用复杂，内部域名、JOB 任务数量庞大（域名 2000+）
迁移策略	分批迁移（首批 3 个核心应用），停服切换（预估 12h），严格的权限隔离（按产品线划分账号）	分批次按业务模块迁移（电台、直播→用户中心→支付等），支持 “停写不停读” 四种灰度切换方案	先应用层灰度引流（1%→10%→30%），再数据层一把切，5 次演练优化，切换当晚近 200 人协同
核心挑战	安全合规风险（如财务数据保密），核心业务无中断要求，专线资源规划与回收	高并发场景下性能稳定（如直播流量峰值），海量小文件迁移效率，老业务容器化改造	跨部门、跨供应商协同难度大，线下门店设备适配，多系统兼容性验证（Runbook 任务 236 项）
云上服务选型	以自建组件迁移为主，逐步替换为华为云专属云服务，强调安全审计（Security OU）	深度使用华为云原生服务（CCE、DDM、DDS），网关拆分（内网 / 生产 /portal 三套 Kong）	混合使用自建与云上服务（ELB、RDS），注重分布式服务框架、消息队列适配多系统

7、Landing Zone设计和实施

• 大型企业的组织结构复杂，往往拥有数十上百个业务单元（如子公司、事业部、产品线、部门或项目组等），这些应用系统的全面云化转型将导致在云上同时存在数百个业务系统和海量云资源，复杂的操作场景可能会导致资源闲置、误操作、恶意操作、数据泄露和权限错配等风险。大型企业必须构建精益化、集中化和结构化的 IT 治理体系才能有效控制这些风险，最大化业务收益。
• 华为云通过 Landing Zone 解决方案来全面应对云上 IT 治理的挑战。Landing Zone 本身是一个航空术语，指直升飞机等飞行器可以安全着陆的区域，将企业业务系统安全平稳迁移到公有云的解决方案命名为 Landing Zone，目的是系统性解决企业大规模上云所带来的 IT 治理和安全合规的挑战。

7.1、Landing Zone整体介绍

华为云 Landing Zone 是针对大企业大规模上云挑战的解决方案，核心是通过体系化架构解决 IT 治理与安全合规问题：

1. 解决的背景挑战

大企业上云已进入全面深度云化阶段，需应对三大核心需求：

• 业务隔离：实现事业部、产品线等业务单元间的安全、故障、管理及财务隔离，缩小风险影响范围；
• 安全合规：确保云资源、数据、应用符合国家、行业及企业自身的安全合规标准；
• 云上 IT 治理：构建 “人财物权” 集中管控体系，覆盖用户 / 账号、成本 / 预算、云资源运维、权限管理等维度。

2. 解决方案整体架构

Landing Zone 以 “自动化部署 + 多维度统一管理” 为核心，包含：

• 基础支撑：提供参考架构、最佳实践、咨询与实施服务；
• 核心能力模块：覆盖组织与账号管理、身份权限管理、数据边界、网络管理、安全管理、合规审计、运维管理、财务管理等 8 大维度；
• 关键行动：通过 SOD 一键部署、集中身份 / 网络 / 安全管理、合规审计、成本优化等 8 项动作落地。

7.2、Landing Zone需求调研

调研目的：

• 了解客户当前的IT治理现状，包括安全规范、网络规范、账号管理规范、计费分账规范等。
• 分析客户当前的IT治理架构，收集客户对于云上IT治理的需求。
• 明确客户对于云上IT治理的需求，为构建云上高效治理架构提供依据。

调研方式：

• 深度访谈：与企业IT负责人、业务部门代表、安全合规团队等进行访谈。
• 问卷调查：面向广泛的用户群体，收集对现有云环境的使用体验、功能需求等反馈。
• 文档审查：分析企业现有的IT架构文档、安全策略、合规要求等，为Landing Zone设计提供依据。
• 对标分析：参考行业最佳实践与华为云Landing Zone的成功案例，提取可借鉴的经验与方案。

调研领域：

领域	调研目标（示例）	问题示例
组织账号	账号规划	企业在 AWS/GCP/AZURE/ALI 上当前有多少个账号包含职能账号和业务账号？对每一个应用，是否需要针对开发、测试、试运行、生产环境分别创建账号来进行资源隔离？客户有多少涉及云的团队（如 DevOps 团队、安全团队）？每个团队的职责分别是什么？
身份权限	权限规划	企业希望如何管理团队成员的权限？团队的成员当前如何登录云平台？
身份权限	登录安全	是否允许非联邦用户（例如 IAM/RAM 用户）访问控制台？是否有设置控制台访问 IP 白名单等机制？
网络规划	逻辑网络分区调研	逻辑网络分区是怎么设计的，是否按照接入互联区、公共和管理服务部署区、业务应用部署区来设计？
网络规划	VPC/IP 网段 / 子网划分调研	IT 职能子账号下的 VPC 数量是如何规划的，是否可以按照 1 个 VPC 进行规划？业务子账号下的 VPC 数量是如何规划的？
安全防护	边界网络 / 内网安全需求调研	调研企业针对边界网络 / 内网安全防护的需求是什么？
安全防护	安全管理需求调研	调研企业针对安全运维管理类产品需求是什么？
合规审计	组织、人员和责任分工调研	明确 IT 运维组织团队组成，并将 Landing Zone 安全实施过程中各阶段的任务以 RACI 矩阵的形式呈现
合规审计	安全合规遵从调研	是否有所遵循的安全合规的规范要求，如等保三级，或者企业内部自行定义颁发的规范要求。
运维监控	运维监控工具	是否存在没有源码的第三方商业软件？这些软件如何做监控和运维？是否使用了工单系统，是否需要和华为云告警对接？
运维监控	统一日志管理	使用了什么日志管理平台？是否需要把多个账号的日志接入到统一运维账号下集中存储和检索？
财务治理	了解客户的财务管理基本信息设计主子账号之间财务管理模式	账号：多个账号的实名信息是否为同一法人？当前的主子账号之间是哪种财务管理模式？统一结算还是独立结算？
数据边界	服务控制策略	是否有对资源操作的控制策略需求？是否有个别 Region 对资源操作有限制策略需求？
自动化需求	自动化脚本	企业是否有自动化实施需求，如 Terraform？当前已经实现了哪些自动化场景？是否使用过 RGC？

7.3、Landing Zone方案设计与实施

华为云 Landing Zone 方案设计与实施围绕 “构建精益化、集中化、结构化云上 IT 治理体系” 核心目标，以 8 大关键模块为核心展开，覆盖从组织架构到自动化落地的全流程，确保企业大规模上云的安全合规、高效管理与风险可控。

一、方案设计核心框架

方案设计遵循 “先顶层规划、后分层落地” 逻辑，核心包含 8 大设计模块，各模块环环相扣，形成完整的云上治理闭环：

1. 组织单元和账号设计（基础架构）
2. 身份权限设计（访问控制）
3. 网络规划设计（连接与隔离）
4. 安全防护方案（风险防御）
5. 合规审计方案（合规管控）
6. 运维监控方案（运维效率）
7. 云财务治理方案（成本管控）
8. 数据边界设计（数据安全）

二、关键模块设计与实施细节

1. 组织单元和账号设计：构建多账号分层架构

（1）核心能力：基于 Organization 服务的层级管理

• 组织组成元素：包含根 OU（顶层节点）、OU（嵌套式分组，映射部门 / 子公司 / 项目）、管理账号（1 个，总控账号）、成员账号（承载具体业务 / 职能）。
• 核心策略：通过服务控制策略（SCP） 划定权限边界（拒绝优先、交集有效），关联到 OU 或账号，限制成员账号操作范围；通过可信服务（如 CTS 审计、HSS 安全）实现跨账号管控；通过标签策略标准化资源分类。

（2）组织架构设计模式

根据企业业务管理需求，提供 2 种核心架构，适配不同管控场景：

架构模式	设计逻辑	适用场景
架构 1	先按业务架构（业务线 / 子公司）划分 OU，再按运行环境（生产 / 非生产）划分下层 OU	需按业务单元（BU）独立管理，设置差异化 SCP 策略的企业（如集团型企业）
架构 2	先按运行环境（生产 / 非生产）划分 OU，再按业务架构（业务线 / 项目）划分下层 OU	需按环境严格隔离（如金融、运营商），统一管控环境安全基线的企业

（3）账号规划：职能与业务分离

• IT 职能账号：按 IT 职责划分，适配不同组织规模，确保权限与职责匹配：

  规划类型	适配组织规模	核心账号示例	职责说明
  最小规划	小型组织	公共服务和管理账号、沙箱账号	可复用管理账号承担公共服务职责，减少账号数量
  标准规划	中大型组织	安全运营账号、网络运营账号、公共服务账号	按核心 IT 职能拆分，覆盖安全、网络、运维基础需求
  全量规划	超大型组织	日志账号、数据平台账号、DevOps 账号	细化职能分工，新增日志审计、数据管理、研发流水线专属账号

• 业务账号：按业务单元划分，提供 3 种模式：

  • 模式 1（外资 / 金融）：按业务系统（如 ERP、电商）划分，每个系统独立账号，区分生产 / 非生产环境；
  • 模式 2（民营集团）：按子公司划分账号，账号内通过 VPC 隔离环境；
  • 模式 3（互联网 / 软件）：按产品线（如游戏、SaaS 软件）划分账号，账号内通过 VPC 隔离环境。

（4）实施步骤

1. 开通 Organization 服务，创建根 OU 及分层 OU（如 IT 管理 OU、业务线 OU、生产 / 非生产 OU）；
2. 邀请现有账号加入组织，或创建新的 IT 职能账号 / 业务账号，分配至对应 OU；
3. 创建 SCP 策略（如禁止非生产环境访问公网）、标签策略，绑定至对应 OU / 账号；
4. 开启可信服务（如 CTS、HSS），指定委托管理员账号（如安全运营账号负责全组织安全管控）。

2. 身份权限设计：统一身份与最小授权

（1）核心能力：基于 IAM 身份中心的集中管控

• 统一身份管理：支持对接企业现有 IdP（如 AD、Azure AD），实现单点登录（SSO）；集中创建用户 / 用户组，配置多因素认证（MFA）强化登录安全。
• 权限控制逻辑：SCP 划定账号权限边界，IAM 权限集实现具体授权，二者为 “边界 + 授权” 关系（IAM 权限需在 SCP 边界内生效）。

（2）用户组与权限规划

按 “职能分组、权限匹配” 原则设计用户组，明确跨账号访问权限：

用户组	核心职责	多账号权限设置建议
组织管理组	管理 OU、成员账号、SCP 策略	管理账号的 Organizations FullAccess 权限
身份权限管理组	配置用户 / 用户组、SSO、权限集	管理账号的 IdentityCenter FullAccess + 所有账号的 Security Administrator 权限
安全管理组	统一管控安全策略、安全资源	所有账号的安全资源（HSS、DSC、安全云脑）管理权限
网络资源管理组	管理 VPC、ER、VPN 等网络资源	网络运营账号的 Tenant Administrator + 所有账号的网络资源管理权限
合规审计组	查看全组织审计日志	日志账号的 Tenant Administrator + 所有账号的 Tenant Guest 权限

（3）实施步骤

1. 开通 IAM 身份中心服务，创建用户组（如安全管理组、网络管理组）及用户；
2. 创建权限集（如 Security Admin、Network Admin），映射具体 IAM 权限；
3. 授权绑定：将权限集关联至用户 / 用户组，并指定可访问的成员账号（如安全管理组关联安全运营账号、所有业务账号）；
4. 配置 SSO 对接企业 IdP，启用 MFA 登录，禁止非联邦用户（如 IAM/RAM 用户）访问控制台（按需设置 IP 白名单）。

3. 网络规划设计：分区隔离与统一互联

（1）整体网络架构：四大逻辑分区

以网络运营账号为网络枢纽，规划 4 个逻辑分区，实现 “边界可控、内部互通、环境隔离”：

分区名称	核心功能	关键资源部署	安全管控重点
公网接入区	提供公网接入能力，终结公网连接	公网 NAT 网关、EIP、Proxy、ELB；WAF、Anti-DDoS、南北向 CFW	暴露明确 IP / 端口，屏蔽冗余端口；通过 WAF 防御 Web 攻击，CFW 拦截非法访问
骨干互联区	实现云上云下、跨 Region、跨云互联	企业路由器（ER）、VPN 网关、云专线网关、云连接	采用 “专线 + VPN” 冗余链路；通过 ER 路由控制跨账号 / VPC 通信
业务部署区	部署业务系统资源	业务 VPC（按生产 / 开发 / 测试隔离）、Web / 应用 / 数据子网	子网按应用分层（Web→应用→数据），通过 ACL / 安全组控制访问；生产与非生产 VPC 路由隔离
公共服务和管理区	部署公共服务与管理系统	公共服务 VPC（AD、DNS、OBS）、运维监控 VPC（AOM、LTS）	仅允许内部账号访问，禁止公网直接连接；通过 ER 与业务部署区互通

（2）核心网络设计要点

• VPC 规划：
  • 共享 VPC（严管控）：网络运营账号创建共享 VPC，业务账号复用，适合需统一管控网络的企业；
  • 独享 VPC（松管控）：业务账号独立创建 VPC，通过 ER 与其他 VPC 互通，适合业务灵活扩展的企业；
• 路由设计：通过 ER 路由表隔离环境，如 “生产路由表” 仅允许生产 VPC 互通，“非生产路由表” 仅允许开发 / 测试 VPC 互通，阻断跨环境流量；
• DNS 管理：公共服务账号集中创建 Private Zone（内网域名），共享给所有业务账号，实现内网域名统一解析，减少管理成本。

（3）实施步骤

1. 网络运营账号创建核心 VPC（如 Access VPC、DMZ VPC），规划 IP 网段（避免与本地 IDC 冲突）；
2. 部署 ER、VPN 网关、云专线网关，配置跨账号 / VPC 路由规则，搭建骨干互联网络；
3. 业务账号创建生产 / 开发 / 测试 VPC，划分 Web / 应用 / 数据子网，配置 ACL 与安全组；
4. 公共服务账号创建 Private Zone，共享给业务账号并关联其 VPC，实现内网域名解析。

4. 安全防护方案：分层防御与统一管控

（1）整体安全架构

覆盖 “物理 - 平台 - 资源 - 数据 - 操作” 全层级，构建 “事前预防、事中防御、事后审计” 体系：

• 物理 / 平台安全：依赖华为云基础设施安全（如硬件加密、云平台合规认证）；
• 网络安全：公网接入区部署 WAF、Anti-DDoS、CFW；内网通过 ACL / 安全组、东西向 CFW 控制流量；
• 主机与应用安全：HSS（主机安全）防护 ECS 漏洞，DBSS（数据库安全）防护 RDS，WAF 防护 Web 应用；
• 数据安全：DEW（数据加密服务）管理密钥，DSC（数据安全中心）识别敏感数据，OBS 桶策略控制访问；
• 操作安全：IAM 身份中心管控权限，云堡垒机（CBH）管控运维操作，CTS 审计操作日志。

（2）统一安全管控模式

以安全运营账号为核心，集中管控全组织安全策略，具体能力包括：

• 统一安全基线：为所有业务账号配置安全基线（如 ECS 补丁更新、RDS 加密）；
• 统一安全监控：通过安全云脑（SecMaster）聚合全组织安全告警，识别威胁（如暴力破解、恶意程序）；
• 统一漏洞管理：HSS 跨账号扫描主机漏洞，生成修复报告并推送给业务团队。

（3）实施步骤

1. 需求调研：明确客户安全合规要求（如等保三级、CIS benchmark）、现有安全产品部署情况；
2. 方案设计：按场景配置安全服务（如公网业务部署 WAF+DDoS 高防，内网业务部署东西向 CFW）；
3. 资源部署：安全运营账号部署安全云脑、HSS、DSC 等服务，授权跨账号访问权限；
4. 策略配置：配置 CFW 规则（默认阻断，按需放通）、HSS 防护策略（漏洞扫描频率、病毒查杀）、OBS 桶加密策略。

5. 合规审计方案：全链路合规管控

（1）核心能力：基于 Config 与 CTS 的自动化审计

• 统一资源合规审计：通过 Config 服务跨账号聚合资源配置（如 ECS、VPC、RDS），对比合规基线（如等保三级、PCI DSS），生成不合规报告并自动修复（如未加密 EVS 自动启用加密）；
• 统一操作审计：通过 CTS 服务收集全组织操作日志（如账号创建、资源删除），投递至日志账号的 LTS/OBS，实现日志持久化存储（满足审计留存要求）；
• 合规报告生成：自动生成合规遵从证据链，支持导出审计报表，适配内外部审计（如公司内审、监管检查）。

（2）合规包覆盖场景

提供多维度合规包，满足不同行业 / 标准需求：

合规包分类	具体示例
行业标准	等保三级 2.0、PCI DSS、NIST、SWIFT CSP
云服务最佳实践	IAM 权限最小化、ECS 公网访问控制、RDS 加密
运维运营最佳实践	资源标签合规、空闲资源清理、日志存储留存
地区法规	香港金管局规范、德国云计算合规目录

（3）实施步骤

1. 开通 Config、CTS、LTS 服务，指定日志账号为可信服务委托管理员；
2. 配置 Config 跨账号资源聚合，选择合规包（如等保三级），设置扫描频率（如每小时）；
3. 配置 CTS 日志投递规则，将全组织操作日志投递至日志账号的 LTS（实时分析）和 OBS（长期归档）；
4. 设置 SMN 告警主题，不合规资源触发告警时通过短信 / 邮件通知合规团队。

6. 运维监控方案：统一可视与高效运维

（1）整体运维架构

以运维监控账号为核心，实现 “跨账号资源统一监控、统一运维、统一日志管理”：

• 统一监控：通过 AOM（应用运维管理）、CES（云监控）跨账号聚合资源指标（如 ECS CPU 利用率、RDS 连接数），自定义监控大屏（按应用 / 业务线分组）；
• 统一运维：通过云堡垒机（CBH）跨账号管控 ECS 登录，支持身份认证集成（如 AD），记录运维操作日志；
• 统一日志：日志账号集中存储全组织日志（CTS 操作日志、LTS 应用日志、VPC 流日志），支持对接第三方 SIEM 系统（如 Splunk）进行分析。

（2）关键场景：跨账号运维

运维人员通过 “权限集授权 + 角色切换” 管理多账号资源，流程如下：

1. 运维人员通过企业 IdP 认证，获取 IAM 身份中心临时 Token；
2. 访问运维监控账号，通过 “权限集” 获取业务账号的 IaaS/PaaS 资源管理权限；
3. 切换角色，直接在运维监控账号控制台管理业务账号的 ECS、RDS、CCE 等资源，无需登录多个账号。

（3）实施步骤

1. 运维监控账号部署 AOM、CES、CBH、LTS 服务，授权跨账号访问权限；
2. 配置 CES 指标聚合（如按业务线分组监控 ECS 指标），设置告警规则（如 CPU 利用率 > 80% 触发告警）；
3. 配置 CBH 运维策略（如禁止 root 直接登录、操作日志留存 6 个月）；
4. 配置 LTS 日志收集规则，聚合业务账号的应用日志，设置日志检索模板。

7. 云财务治理方案：分级管控与成本优化

（1）财务管理模式

提供 2 种核心模式，适配不同财务管控需求：

模式	管控逻辑	适用场景
主子账号财务托管	主账号统一管理子账号 “钱账票券”，子账号账单自动结算至主账号；主账号统一激活成本标签，子账号复用	需集中管控财务（如集团型企业），减少子账号财务操作的场景
主子账号财务独立	主账号统一充值、划拨资金 / 代金券，子账号独立核算成本；子账号按企业项目 / 标签分账	需业务单元独立承担成本（如事业部制企业），细化成本归属的场景

（2）成本优化能力

• 统一配额管理：主账号为子账号分配资金配额（如子账号 A 每月 10 万）、资源配额（如 ECS 最大创建数 5000 个），开启余额预警；
• 标签分账：通过标签（如 “成本中心 = 市场部”“项目 = XX 产品”）实现成本归属精准划分，生成标签成本报表；
• 空闲资源优化：识别闲置资源（如 30 天未使用 ECS、未绑定 EIP），推送优化建议，降低资源浪费。

（3）实施步骤

1. 主账号配置财务管理模式（托管 / 独立），开通成本管理、费用管理服务；
2. 配置成本标签（如 “成本中心”“环境”“项目”），激活标签同步至所有子账号；
3. 为主账号 / 企业项目设置资金配额、资源配额，开启余额预警（如余额低于 10% 触发告警）；
4. 定期生成成本报表（按账号 / 标签 / 企业项目），分析成本趋势并优化（如关闭闲置 ECS）。

8. 数据边界设计：三重护栏阻断非预期访问

通过 “身份 - 网络 - 资源” 三重护栏，确保数据仅被 “授权身份 + 授权网络” 访问，消除数据泄露风险：

护栏类型	实现方式	核心场景
身份护栏	基于 SCP 策略，限制身份可访问的云服务 / 操作（如禁止成员账号共享 SFS/IMS 资源给组织外）	防止特权账号越权操作、资源外泄
网络护栏	基于 VPC 终端节点（EP）策略，限制 VPC 内资源可访问的服务（如仅允许 VPC1 访问 OBS 桶 A）	防止非授权 VPC 访问敏感数据（如核心业务 VPC）
资源护栏	基于资源策略（如 OBS 桶策略、RDS 访问策略），限制资源可被访问的 IP/VPC（如 OBS 桶仅允许 VPC1 访问）	防止公网 / 非授权网络访问敏感资源（如客户数据桶）

典型应用场景：

• 互联网边界限制：禁止业务账号直接访问公网，仅允许通过网络安全账号的 DMZ 区访问（如补丁更新通过 DMZ 的 NAT 网关）；
• 关键数据保护：限制敏感数据（如用户隐私数据）仅允许安全运营账号的合规审计组，从生产 VPC 访问；
• 数据驻留控制：通过 SCP 策略禁止在指定 Region 外创建资源（如仅允许北京 / 上海 Region 部署业务，满足数据本地化要求）。

实施步骤：

1. 配置身份护栏：创建 SCP 策略（如禁止在非授权 Region 创建资源、禁止共享资源给组织外）；
2. 配置网络护栏：创建 VPC EP 策略（如仅允许生产 VPC 访问 OBS），关联至对应 VPC；
3. 配置资源护栏：创建 OBS 桶策略（如仅允许 VPC1 的 IP 段访问）、RDS 白名单（仅允许应用子网 IP）；
4. 验证策略有效性：通过模拟非授权访问（如从测试 VPC 访问生产 OBS 桶），确认护栏生效。

三、自动化实施支撑：基于 IaC 的高效落地

为减少手动操作误差、提升部署效率，方案提供 3 大自动化工具，支持 “基础设施即代码（IaC）” 管理：

工具	核心功能	应用场景
Terraform	开源 IaC 工具，通过.tf 配置文件描述云资源（如 VPC、IAM 用户、SCP），支持版本控制、自动化部署	自定义资源部署场景（如复杂网络架构、个性化权限策略）
RFS（资源编排服务）	华为云原生编排引擎，兼容 Terraform 语法，提供模板化部署（如一键部署业务 VPC + 安全组）	标准化资源栈部署（如新建业务账号时自动创建基础 VPC）
RGC（资源治理中心）	快速搭建 Landing Zone 基础环境，提供预制策略包（如安全基线、合规审计规则），支持账号自动创建	快速落地 Landing Zone（如半小时完成基础架构部署，5 分钟创建新业务账号）

自动化实施优势：

• 效率提升：避免手动配置（如创建 10 个业务账号需手动操作 200 + 步，自动化仅需 1 个模板）；
• 一致性保障：所有环境基于同一模板部署，避免 “环境差异” 导致的故障；
• 可追溯性：配置文件纳入版本控制（如 Git），可回溯历史变更，便于问题定位。

四、方案核心价值

1. 风险可控：通过 SCP、三重数据护栏、合规审计，解决资源闲置、误操作、数据泄露等风险；
2. 效率提升：自动化部署减少 80% 手动操作，多账号统一运维降低管理复杂度；
3. 合规适配：覆盖等保、PCI DSS 等多维度合规要求，自动生成审计证据链；
4. 灵活扩展：分层架构与模块化设计，支持业务规模扩大时快速新增账号 / OU，无需重构架构。

7.4、基于IaC的自动化方案

​ 华为云基于 IaC（基础设施即代码）的自动化编排除方案，核心由 3 个组件（Terraform、RFS、RGC）构成，实现云资源的自动化部署、管理与治理，具体总结如下：

一、核心组件及功能

1. Terraform：基础 IaC 工具
   • 是开源的基础设施编排除工具，通过xxx.tf配置文件（含 provider、resource 等）描述华为云资源（如 ECS、VPC 等），实现资源的创建、管理、删除 + 版本控制。
   • 代码最佳实践：采用模块化目录结构（main.tf定义版本 / Provider、variable.tf管理变量、modules拆分不同资源模块），提升可维护性。
2. RFS（资源编排服务）：华为云原生编排除引擎
   • 兼容 Terraform 标准，通过 HCL 模板实现云服务资源的自动化部署；
   • 提供 “资源强管控” 能力：业务账号无模板修改 / 直接创建资源的权限，需基于管理员定义的模板申请资源，降低人为操作风险。
3. RGC（资源治理中心）：多账号环境治理工具
   • 快速搭建 Landing Zone（云上基础环境），支持多账号自动创建、集中配置（网络、日志等）；
   • 场景覆盖：加速多账号部署、云上合规治理（如权限 / 网络管控）、新业务快速上线。

二、方案价值

• 效率提升：Landing Zone 半小时自动化部署、业务账号 5 分钟内完成创建配置；
• 风险降低：通过模板 / 权限管控，减少人工操作失误、避免资源变更的安全风险；
• 一致性保障：新业务账号的配置（日志、网络等）统一标准化，满足合规要求。

8、计算服务的使用和迁移

下面内容重点介绍计算类云服务的使用和典型主机应用平迁的方法。

• 总结：传统架构的应用，通常部署在物理机或虚拟机，建议优先通过华为云SMS主机迁移工具进行迁移；如果无法使用华为云SMS进行迁移的，可以采用应用重新部署的方式；对于可停机迁移的应用，也可以考虑采用镜像导出导入的方式进行迁移。

8.1、ECS介绍

华为云计算服务总览

**ECS的定位理解：**弹性云服务器（Elastic Cloud Server，ECS）是一种可随时自动获取、可弹性伸缩的云服务器，帮助用户打造可靠、安全、灵活、高效的应用环境，确保服务持久稳定运行，提升运营效率。

• 聚焦运算：把服务器理解为是计算资源
• 用户拥有完整的服务器控制权
• 用户只需关注操作系统以上的部分
• 弹性：可以理解为是一次性资源

实例类型的选择

• 实例的系列：c表示通用计算增强型、m表示内存优化型……
• 实例的版本代号：c6中的6表示通用计算增强型6代。通常更大的数字代表新一代实例规格，拥有更高的性价比。
• 实例的规格：当前规格的vCPU核数，例如：small、medium、large、xlarge、2xlarge、4xlarge、8xlarge等。
• 内存、vCPU比：以具体数字表示，例如4表示内存和vCPU的比值为4。

**实例系列的分类：**通用计算增强型、通用计算型、内存优化型、超大内存型、磁盘增强型、超高I/O型、GPU加速型、AI加速型、通用入门型、鲲鹏内存优化型、鲲鹏超高I/O型……

选择实例类型的思路：

1. 根据模块特性，选择适合模块的实例类型：评估资源的消耗，选择合适的规格。
2. 实例类型选错不用慌张：更换一台服务器的实例类型非常方便，不想换生成一台新的服务器也行。
3. 实例类型的优化不是一次性工作：优化的基础是看监控，看看所有关注的重点资源是不是都用足了，若有浪费就相应更换实例类型，更换后继续保持监控，寻找更多调整优化机会。

ECS 服务器规格的成本与风险考量：

服务器 “大小” 需结合业务规模：

• 多台小规格服务器的灾害半径更小（单台故障影响范围有限）、弹性成本更低（资源伸缩更灵活）；
• 大规格服务器虽能减少 OS / 存储数量，但故障影响范围大。

ECS 服务器的初始化流程

分为 4 个步骤，核心配置项包括：

• 基础配置：付费方式、区域 / 可用区、实例类型、启动镜像、硬盘存储；
• 网络配置：VPC / 子网、安全组、弹性 IP / 流量；
• 高级配置：服务器命名、备份、服务器组、高级选项；
• 确认配置：最终核对并完成部署。

8.2、SMS介绍+操作指导

一、SMS 的定义与作用

主机迁移服务（SMS）是一种P2V/V2V 迁移服务，支持将 x86 物理服务器、私有云 / 公有云虚拟机，迁移到华为云 ECS 上，实现应用与数据的云端迁移。

二、迁移流程

1. 后台流程：

2. 准备目的端 ECS，创建迁移任务；

3. 生成临时 EVS 卷并挂载到目的端；

4. 格式化、分区目的端 ECS；

5. 迁移源端磁盘数据，修改配置、设置启动卷；

6. 删除临时 EVS 卷，重启目的端 ECS。

7. 操作流程（用户 + 服务自动执行）：

8. 用户操作：在源端安装迁移 Agent；

9. 服务自动：Agent 注册并上报源端信息，完成迁移可行性校验；

10. 用户操作：在控制台设置目的端并启动迁移；

11. 服务自动：Agent 获取指令，依次迁移系统盘、数据盘；

12. 用户操作：启动目的端完成迁移。

三、核心能力

1. 迁移可行性校验：安装 Agent 并校验 AK/SK 后，自动检测源端的 OS 版本、CPU、内存、磁盘等信息，确认是否可迁移；
2. 全量迁移与同步：
   • Windows：识别源端分区有效块并传输，全量迁移后自动持续同步；
   • Linux：传输目录及文件，全量迁移后支持新增数据同步；
3. 动态安全传输通道：通过 “生成 SSH 密钥对→建立 SSH 通道→传输 SSL 证书→建立 SSL 通道” 的流程，保障迁移数据的安全传输。

四、SMS 的优势

• 兼容性好：支持国内外主流云平台虚拟机、x86 物理机迁移；
• 简单易用：迁移任务仅需 “选源端→配目的端→确认信息” 三步；
• 业务平滑：迁移过程无需中断业务；
• 传输高效：识别有效数据迁移，网络利用率超 90%；
• 安全性高：AK/SK 校验 Agent 身份，传输通道 SSL 加密。

五、使用须知与约束

1. 注意事项

• 迁移前：评估老系统（如 Windows 2008）兼容性，关闭可能冲突的软件（如杀毒软件）并备份数据；
• 迁移中：禁止操作目的端系统 / 磁盘，禁止重启 SMS-Agent；
• 迁移后：仅保证数据一致性，业务能否运行需用户自行验证调整。

2. 主机迁移的约束与限制：

源端服务器类型	说明
操作系统	仅支持迁移包含在兼容列表的操作系统；不支持迁移多操作系统
磁盘可用空间大小	Windows：当分区大于 600 MB，该分区的可用空间小于 320 MB 时不能迁移；当分区小于 600 MB，该分区的空间小于 40 MB 时不能迁移。Linux：根分区可用空间小于 200 MB 时不能迁移
文件系统	Windows：只支持 NTFS 类型文件系统。Linux：只支持 ext2、ext3、ext4、vfat、xfs、btrfs 的文件系统
共享文件系统	只支持迁移本地磁盘上的文件，不支持迁移共享文件系统（例如 Network File System、Common Internet File System 等）中的文件
加密文件	不支持含有受保护文件、加密卷的系统
系统卷不在第一块磁盘的服务器	不支持迁移系统卷不在第一块磁盘上的服务器
应用与硬件绑定	不支持含有与硬件绑定的应用的系统
动态磁盘	在 Windows 系统中，动态磁盘会当做基本磁盘来迁移，迁移完成后，目的端服务器不会有动态磁盘
加入域的主机	迁移加入域主机时，在迁移完成后，目的端服务器需要重新加入域

3. 迁移时间估算

时间与 “源端实际数据量” 成正比，与 “带宽 × 网络利用率” 成反比（公式：T=B×U**V）。

**操作指导：**略

8.3、IMS介绍+操作指导

一、IMS（镜像服务）的基础介绍

• 本质：是包含操作系统、预装软件 / 配置的 “磁盘模板”，可用于快速初始化云服务器（购买服务器本质是镜像恢复）；
• 镜像类型及特性：
  1. 华为云公共镜像：安全纯净、官方维护，是自定义的基础模板；
  2. 私有镜像：从自有主机创建，包含自定义软件 / 配置，需自行负责内容安全；
  3. 华为云市场镜像：由合作伙伴提供，含特定软件，可能需额外付费；
  4. 共享镜像：用户间共享，需提前配置权限，由共享者负责内容安全。

二、基于 IMS 的跨云迁移方案（友商云→华为云）

1. 迁移流程（共 7 步）:

2. 登录友商云控制台，为源主机创建自定义镜像；

3. 将友商云镜像导出至其对象存储服务；

4. 从友商对象存储下载镜像文件到本地 PC；

5. 将镜像文件上传至华为云 OBS（文件 > 5G 需用 OBS Browser + 工具）；

6. 通过华为云 IMS，将 OBS 中的镜像文件制作成私有镜像；

7. 使用该私有镜像申请华为云 ECS（主机配置需≥源端）；

8. 验证迁移结果。

9. “制作私有镜像” 的操作细节：

• 选择 “系统盘镜像> 镜像文件”，关联 OBS 中的镜像文件；
• 填写源主机的配置信息（如操作系统类型、系统盘大小等）；
• 完成私有镜像的创建。

3. “申请云主机” 的注意事项：

• 使用自制私有镜像申请 ECS；
• 主机配置需与源端一致或更高；
• 迁移后主机名、密码与源端相同。

三、镜像相关扩展能力

1. 镜像格式支持：华为云支持 vhd、vmdk、qcow2 等格式，非兼容格式需用qemu-img工具转换（超大镜像建议转成 qcow2）；
2. 云内跨区域迁移方案：通过 “IMS 制作私有镜像→导出至 OBS→OBS 跨区域复制→目的区域导入 IMS→申请 ECS” 实现跨区域迁移。

9、存储服务的使用和迁移

本章主要讲述块存储、对象存储和文件存储的迁移方法。

9.1、存储服务介绍

​ **对象存储服务OBS：**全托管对象存储服务、可以互联网直接访问、没有限制的存储空间（单对象48T）、99.9999999999%可靠性、事件触发能力、多样性的低成本方案。

​ **弹性文件服务SFS：**全托管的共享存储服务、可以理解为是一台NAS服务器、没有限制的存储空间、99.99999999%可靠性、有容量版和Turbo版（支持海量到性能的不同场景需求）。

​ **云硬盘EVS：**块存储，给ECS使用的硬盘、单可用区三副本存储，9个9可靠性、单盘最大32T、多种配置选择，平衡成本和性能、备份快照进入OBS存放。

​

9.2、对象存储迁移OMS

一、对象存储迁移方式（按数据规模划分）

华为云提供多类迁移方式，匹配不同数据量级场景：

迁移方式	适用场景	说明
OBS 客户端拷贝	GB 级小数据量	直接通过客户端工具完成数据迁移
OMS 工具迁移 + 回源	TB/PB 级、有增量数据的场景	先全量迁移，再通过 “回源” 同步增量数据，保障业务连续性
线下 DES 磁盘拷贝	TB 级、增量少的场景	通过物理磁盘 / 专用设备（Teleport）离线迁移，降低大带宽成本
定制迁移服务	EB 级超大规模数据	华为云专业团队提供定制化迁移方案

二、核心迁移工具：OMS（对象存储迁移服务）

1. 定义与能力：OMS 是线上数据迁移服务，支持将其他云厂商的对象存储数据平滑迁移至华为云OBS，迁移速度约10-20TB/天。

2. 迁移流程：①拉取源端对象列表与元数据；②比对目的端是否已存在该对象；③迁移对象至目的端；④校验迁移后对象与源端的一致性。

3. 网络模型：

   • 跨 Region / 跨云迁移：通过公网读取源端数据，写入华为云 OBS；
   • Region 内迁移：通过华为云内部网络传输，效率更高。

4. 功能特性：

   • 支持按文件 / 目录 / 前缀选择对象、按时间过滤；
   • 支持并行迁移、断点续传、流量控制；
   • 提供迁移前评估、多任务管理、迁移结果通知（短信 / 邮件）；
   • 安全能力：AK/SK 鉴权、HTTPS 传输加密、存储加密。

三、OMS 迁移操作步骤

1. 为源端、目的端创建访问密钥（AK/SK）；
2. 在 OBS 创建用于存放迁移数据的桶；
3. 在 OMS 中创建迁移任务并启动；
4. 检查 OMS 中迁移任务的结果。

四、离线迁移工具：DES（数据快递服务）

适用于超大规模数据（30TB~PB 级），通过物理设备（磁盘 / Teleport）完成迁移：

• 优势：成本低于互联网传输、内建加密保护；
• 流程：创建桶→下单服务→拷贝数据→设备回寄→数据导入 OBS。

五、迁移实施全流程（规范步骤）

1. 迁移前准备：收集源端信息、评估时间、确认增量策略；
2. 方案设计：迁移任务划分、增量实施策略；
3. 演练与预案：迁移方案测试、制定业务应急方案；
4. 迁移保障：实时监控进度、迁移后一致性比对。

9.3、文件存储迁移

华为云文件存储（以 NFS→SFS 为例）的迁移方案，涵盖工具、方案、流程等核心内容，总结如下：

一、文件存储迁移的核心方案（基于工具分类）

针对 “自建 NFS→华为云 ECS/SFS” 的场景，提供 4 类迁移方案，核心信息如下：

方案类型	工具	数据源→目的端	迁移网络	优势	约束限制
rehost	mgc 主机迁移	NFS→华为云 ECS	公网 / 专线	简单高效、可视化管理、数据安全	源端 OS 兼容性限制、服务器规格要求
replatform	mgc 存储迁移	NFS→华为云 SFS	公网 / 专线	数据安全（HTTPS/KMS 加密）、传输可靠	仅支持部分 Region、单对象≤5TB
replatform	rclone	NFS→华为云 SFS	公网 / 专线	支持增量迁移、跨存储类型同步	仅支持 Linux、文件 UID/GID 不保持一致
replatform	rsync	NFS→华为云 SFS	专线	支持断点续传、保留元数据、增量迁移	小文件多目录场景效率低、需开放 22 端口

二、核心迁移工具介绍

1. rclone

• 是 Go 语言开发的开源跨平台同步工具，支持文件系统 / 对象存储间的数据同步（具备对象存储数据迁移的能力，但厂商专门针对对象存储场景的迁移服务是使用OMS）；
• 核心命令：
  • rclone config：配置同步信息；
  • rclone copy：跳过已复制文件的增量拷贝；
  • rclone sync：将源数据同步到目的端（仅更新目的端）。

2. rsync

• 是基于 “rsync 算法” 的远程同步工具，仅传输文件差异部分，速度快；
• 支持多种工作模式（本地拷贝、本地→远程、远程→本地等），需依赖 SSH 协议。

三、典型迁移方案流程

以 “NFS→华为云 SFS” 为例，核心流程（以 rclone/rsync 为例）：

1. 准备：申请带 EIP 的 ECS，挂载 SFS 共享目录；
2. 配置：在 ECS 上安装 rclone/rsync，挂载源端 NFS 目录；
3. 迁移：先全量拷贝数据，再多次增量同步；
4. 切换：确认增量窗口可接受后，停止源端业务，执行最后一次增量迁移，启动目的端业务。

四、扩展方案：共享存储→OBS

通过CSG 云存储网关实现：

• CSG 是本地存储与云端存储的桥梁，支持 NFS 协议（兼容现有 NAS 应用）；
• 流程：本地共享存储→CSG→华为云 OBS，可结合 DES 实现离线迁移，也可从 OBS 恢复数据到 EVS/SFS。

五、工具对比

对比项	rclone	rsync
主要作用	跨存储服务同步 / 管理	本地 / 远程文件系统同步（依赖 SSH）
复制方式	不支持文件增量复制	仅传输文件差异部分
直接传输	支持两个远程服务间直接传输	必须有一侧是本地文件系统
场景适配	云存储服务间同步	本地 / 远程文件系统增量同步

10、数据库服务的使用和迁移

• 在数字化转型的浪潮中，数据库迁移是企业实现业务升级、架构优化或云化部署的关键环节。随着数据规模的增长和业务需求的多样化，传统单体数据库在应对高并发、海量数据及分布式场景时逐渐显现瓶颈，而分布式数据库凭借其弹性扩展、高可用及高性能等优势，成为企业技术演进的重要方向，因此如何进行分布式数据库的迁移也成为一个重要问题。
• 本章将围绕迁移流程，介绍华为云数据库服务，数据库迁移的源端调查与目的端评估，迁移工具与不同架构数据库的迁移方案，帮助读者掌握数据库迁移落地的关键要点，为业务系统的平滑过渡与持续优化打下坚实基础。

10.1、华为云数据库服务

★关系型数据库服务RDS（Relational Database Service）

• RDS是一种基于云计算平台的在线关系型数据库服务。
• 提供基于MySQL/PostgreSQL/SQL Server/MariaDB的数据库实例，支持单机或主备部署模式。数据库实例的安装和部署，完全由RDS在几分钟内自动完成，让用户可以即开即用。
• RDS还提供了数据库运维的高可用/容灾、数据库备份与恢复、弹性伸缩、性能监控等，显著地减少数据运维的复杂性和成本，从而能够让用户专注于应用开发和业务发展。

★云数据库TaurusDB

• TaurusDB是华为自研的最新一代企业级高扩展海量存储云原生数据库，完全兼容MySQL。
• 基于华为最新一代DFV存储，采用计算存储分离架构，128TB海量存储，故障秒级切换，既拥有商业数据库的高可用和性能，又具备开源低成本效益。
• 用户无需修改代码即可迁移现有MySQL应用。

★云数据库GaussDB

• GaussDB是华为自主创新研发的分布式关系型数据库。
• 支持分布式事务，同城跨AZ部署，数据0丢失，支持1000+的扩展能力，PB级海量存储。同时拥有云上高可用、高可靠、高安全、弹性伸缩、一键部署、快速备份恢复、监控告警等关键能力。
• 为企业提供功能全面、稳定可靠、扩展性强、性能优越的企业级数据库服务。

10.2、数据库从单体到分布式的架构详解

一、MySQL 架构演进路径

1. 单机架构：

• 特点：应用直接读写单节点，架构简单、运维量小。
• 痛点：单点故障 + 性能瓶颈（存储容量、CPU / 内存、读写 OPS 不足）。
• 扩展方案：
  • 垂直扩容（Scale Up）：升级硬件（高性能 CPU / 内存、高 IO 存储）。
  • 水平扩容（Scale Out）：读写分离、分库分表（解决存储 / 读写瓶颈）。

2. 主从架构 + 读写分离：

• 核心逻辑：主节点负责写操作，从节点同步主节点数据并负责读操作。
• 优势：扩展单机的读能力。
• 延伸形态：节点数量（一主一从 / 多从、多级复制）、读写分离方式（应用层 / 代理层）、高可用方案（MMM、MHA 等）。

3. 分布式架构 + 分库分表

• 核心逻辑：将表数据水平拆分为多个分片，所有分片组成全量数据；基于 Share-Nothing 架构，不同分片由不同节点存储，突破单机写能力瓶颈。
• 延伸形态：分片支持单节点 / 主备 / 读写分离；计算层（分片路由）可通过应用层、中间件（如 ShardingSphere）或商用分布式数据库实现。

二、数据库拆分方式

1. 垂直拆分：

   • 垂直分表：按 “列” 拆分（如将大表的 “冗余列” 拆分到扩展表），提升单表读写效率。

   • 垂直分库：按业务模块拆分数据库（如将业务中台库拆分为用户中心库、支付中心库等），降低业务耦合。

2. 水平拆分：

   • 水平分表：同库内按规则（如哈希、取模）拆分表数据，降低单表数据量。

   • 水平分库：将分表分散到不同数据库，解决单库 IO 瓶颈；支持 “只分库不分表”（一级拆分）或 “分库 + 分表”（二级拆分）。

三、分布式数据库核心概念

1. 分库 / 分片 / 分表：分片 = 分库（database），一个分片可包含多张分表；是物理概念。
2. 表的类型：
   • 拆分表：全量数据拆分到多分片，适合大表高频读写（如订单表）。
   • 全量表：每个分片存全量相同数据，适合小表低频写（如省份表）。
3. 分片字段 / 算法：
   • 分片字段：用于路由数据的字段（需均匀分布，避免热点）。
   • 分片算法：如取模（mod）、哈希，决定数据路由到哪个分片 / 分表。
4. 与 MySQL 实例的关系：一个 MySQL 实例可存多个分片，但需避免 OPS 过载，需分散到多实例。

四、分布式数据库逻辑架构

由计算层、元数据层、存储层组成：

• 计算层（SQL 层）：对应单机数据库的 SQL 层，负责权限检查、分布式事务、结果汇总；可通过应用层、中间件（如 ShardingSphere）、第三方 / 厂商中间件（如 DDM）实现。
• 元数据层：记录存储节点、路由规则等信息。
• 存储层：存储实际业务数据（MySQL 实例）。

五、逻辑结构（逻辑库 / 表 vs 物理库 / 表）

• 逻辑库 / 表：对应用提供统一访问入口，屏蔽底层物理存储细节，不存实际数据。
• 物理库 / 表：实际存储数据的库 / 表；一个逻辑库对应多个物理库，一个逻辑表对应多个物理表，映射关系存在元数据层。

六、华为云分布式数据库中间件DDM

• 分布式数据库中间件（Distributed Database Middleware，简称DDM），兼容MySQL协议，专注于解决数据库分布式扩展问题。
• DDM使用华为关系型数据库（RDS）作为存储引擎，具备自动部署、分库分表、弹性伸缩、高可用等全生命周期运维管控能力。

10.3、数据库迁移的源端调查

数据库迁移前源端调研的 8 大核心维度，聚焦明确迁移条件、适配目标端方案，总结如下：

**1. 源端建设方式：**明确源端部署形态（IDC 自建 / 云上自建 / 云数据库服务），判断迁移前置限制（如不同云厂商参数差异）。

2. 迁移范围：确定迁移的环境（开发 / 测试 / 生产） 和级别（实例 / 库 / 表），作为后续迁移任务的范围输入。

3. 源端分库分表方案：

• 分布式中间件：确认分库分表的实现方式（应用代码 / ShardingSphere / 第三方中间件），适配目标端（如华为云 DDM）的改造需求；
• 拆分规则：明确逻辑库表、拆分形式（分库分表 / 分库不分表等）、命名规则、分片与 MySQL 实例的对应关系；
• 拆分字段 / 算法、业务查询条件、是否有全局表：为目标端逻辑表配置提供参考。

4. 源端数据量：统计数据条数（最大表） 和数据大小（总表），用于目标端数据库资源评估（如分片数）。

5. 源端数据库资源现状

• 基础信息：MySQL 版本、存储引擎、组网形态（单机 / 主从）；
• 硬件 / 高可用：服务器性能规格、高可用方案；
• 配置 / 网络：IP / 端口、关键参数（编码、binlog 格式等）；
• 监控 / 业务波动：CPU / 内存 / IOPs 等监控数据、业务高峰时段，用于目标端资源 / 限流方案设计。

**6. 未来业务增量：**评估未来 N 年数据增量、业务下线计划，支撑目标端资源预留与迁移方案设计。

**7. 关键性能指标：**收集 TPS（Transactions per Second 每秒处理的交易数）/QPS（Query per Second 每秒查询率）、IOPs，用于目标端资源评估与性能调优。

8. 其他：

• 备份恢复：源端备份策略，指导目标端备份配置；
• 周边对接：与数仓 / 其他系统的交互情况，判断是否需目标端（如 DDM）的只读组能力。

10.4、数据库迁移的目的端评估

数据库迁移中目的端（华为云 RDS+DDM）的资源评估方案，核心围绕性能、分片、存储、高可用展开，总结如下：

一、RDS 资源评估（存储层）

需综合TPS/QPS、分片设计、存储空间、高可用4 个维度：

1. TPS/QPS 评估

• 依据业务实际 TPS/QPS，结合 MySQL 版本 + 实例类型（通用型 / 独享型）的性能基线（基于 Sysbench 压测），计算所需 RDS 实例数。
• 示例：若应用 QPS 为 50000，选择 8C16G 规格 RDS，需 2 个实例。

2. 分片设计评估

• 分库分表建议：单表记录 < 5000W 用单表；≥5000W 则分库分表，单表≤1000W（如 10 亿数据需 100 张分表）。
• RDS 实例分片数：中性能规格（8C16G/8C32G）单实例建议 16 分片；高性能规格（16C32G/16C64G）单实例建议 32 分片。
• 原则：优先保证 RDS 实例数量（小规格实例垂直扩容更灵活，避免大规格水平扩容的风险）。
• 示例：10 亿数据需 100 分片，选 8C32G RDS（单实例 16 分片），需 8 个 RDS 实例。

3. 存储空间评估

• 考虑因素：现有数据量 + 未来增量 + 保存时长；磁盘使用率建议 60%-70%；单 RDS 存储上限 4T。
• 公式：建议存储总量 = 业务数据量 ÷(60% 或 70%)。
• 示例：5T 业务数据，需 7.2T-8.4T 存储，需 3 个 RDS 实例。

4. 高可用评估

• 生产环境至少选择主备实例；
• 若业务需对外提供读服务（如大数据抽数），建议增加只读实例。

二、DDM 资源评估（分布式中间件层）

需综合TPS/QPS、高可用2 个维度：

1. TPS/QPS 评估

• 依据业务 TPS/QPS，结合 DDM 规格的性能基线（基于 Sysbench 压测），选择节点规格。

2. 高可用评估

• DDM 总 CPU 核数需为 RDS 总 CPU 核数的 1/2；
• 至少选择 2 节点部署，避免单点故障。
• 示例 1：QPS=40000，选 18C16G DDM，需扩容为 28C16G；
• 示例 2：8 个 8C32G RDS（总核数 64C），DDM 需 32C，可选 48C16G 或 216C32G。

**最终结论：**结合 RDS 的性能/分片/存储/高可用，以及 DDM 的性能 / 高可用，综合确定目的端的资源规格与数量。

10.5、数据库迁移工具与迁移方案

一、迁移工具：数据复制服务DRS（Data Replication Service）

• 数据复制服务（Data Replication Service，简称DRS）是一种易用、稳定、高效、用于数据库实时迁移和数据库实时同步的云服务。

• 数据复制服务围绕云数据库，降低了数据库之间数据流通的复杂性，有效地减少数据传输的成本。

• 技术原理：

  • 全量同步：一次性迁移源库全量数据（含表结构、索引），支持分片并行同步；
  • 增量同步：抓取源库日志→解析变更数据→落盘存储→在目标库回放 SQL，实现数据实时同步；
  • （迁移至 DDM 场景）：源端对接存储层（获取全量数据 / 日志），目标端对接 DDM 计算层（保证路由元数据）。

• 核心功能：

  • 实时迁移：通过 “全量 + 增量” 同步实现业务最小中断的平滑迁移，迁移后源库下线；
  • 实时同步：维持多系统间数据持续流动（非迁移），支持多对一 / 一对多等灵活映射。

二、典型迁移方案

1. MySQL 平迁（无分布式改造）

• 场景：源端为单实例 MySQL，无需分布式改造。
• 流程：
  1. 建 DRS 任务（源库→华为云 RDS，全量 + 增量）；
  2. 建反向 DRS 任务（RDS→源库备库，用于回退）；
  3. 验证华为云应用→切流量→数据比对后结束任务；
• 回退：流量切回源库→数据比对→结束反向任务→验证源库业务。

2. 分布式改造场景 1：分片平迁

• 场景：源端分库分表（应用层路由）、数据量小 / 增量少、需合并实例降本。
• 方案：建多个 DRS 任务，将源端多实例分片直接迁移到华为云单 RDS 实例（仅修改域名映射，不合并库表），迁移后切流量→验证→结束任务。

3. 分布式改造场景 2：数据汇聚 + 重分布

• 场景：源端分库分表、数据量大 / 增量高、需用 DDM 简化运维。
• 方案：
  1. 源端多分片→华为云 RDS 中间库（DRS 同步，多表汇聚为单表）；
  2. RDS 中间库→DDM（DRS 同步，按新规则重分布分库分表）；
  3. 支持分库分表、分库不分表、分表不分库等形态。

三、方案对比

方案	适配场景	核心优势	代码改造
平迁	独立应用单实例数据库	方案成熟、无改造	不涉及
分片平迁	源端分库分表、数据量小	成本低、代码无改造	少量配置修改
数据汇聚 + 重分布	源端分库分表、数据量大 / 增量高	减少运维、扩展性好	涉及

11、容器服务的使用和迁移

本章主要讲述华为云服务中的容器服务，并且介绍容器服务迁移流程、工具和方法。

11.1、华为云容器服务介绍

容器镜像服务SWR

• 华为云提供的容器镜像托管
• 支持多版本镜像的完整生命周期管理
• 目前是免费服务，包括免费存储和流量
• 兼容Docker Hub，直接用docker命令控制
• 和CCE，CCI等服务整合
• 支持事件触发器

云容器引擎CCE

• 华为云提供的容器编排调动服务
• 同时支持Kubernetes和Docker
• 在VPC内部自行管理容器区网络
• 创建是生成控制节点，支持高可用
• 会在节点安装采集探针，收集监控数据
• 需要另外增加、纳管或自动扩容（工作）节点
• 用Kubectl工具管理集群

云容器实例CCI

• 无服务器的容器资源。用户可以聚焦容器本身
• 按秒计费，颗粒度极小
• 秒级启动时间，弹性迅速
• 自带调度器
• 和SWR直接整合

11.2、容器迁移流程及关键事项

容器（k8s 集群）迁移的全流程及关键要点，核心总结如下：

一、容器迁移整体流程

分为 4 个核心阶段，按顺序推进：

1. 调研评估：调研现有业务 / 资源，评估技术可行性、风险、迁移时长，输出评估报告；
2. 规划设计：基于调研输出迁移详细方案，包含资源、网络、存储等规划；
3. 迁移实施：创建目标资源、部署工具、完成数据 / 应用迁移；
4. 测试验证：业务测试、流量切换、原资源下线、项目验收。

二、关键阶段细节

1. 调研评估

• 信息收集：覆盖 k8s 集群（版本、容器引擎、CRD/Operator 等）、网络、存储、应用、安全、系统对接等维度（通过调研表落地）；
• 风险评估：
  • 低风险：无状态应用 / 有状态应用（仅存配置 / 日志），可平滑迁移；
  • 风险可控：有状态应用（存业务数据），需申请停机窗口保障数据一致。

2. 规划设计

从高可用、可扩展等维度，聚焦 5 大方向：

• 云上实例类型：匹配业务性能 + 成本；
• 网络规划：IP 网段、容器网络类型、访问控制；
• 存储规划：适配原存储类型（文件 / 对象 / 本地盘）选择云上存储；
• 环境变量：管理 / 配置 / 注入方式；
• 运维规划：监控、告警、日志持久化方案。

3. 迁移实施

• 迁移资源：
  • 集群内资源：Pod/Deployment 等对象（跳过velero/kube-system系统资源）、持久存储（需将 HostPath 转为 Local 类型）；
  • 集群外资源：镜像库（迁到 SWR）、数据库（迁到 RDS）、对象存储（迁到 OBS）；
• 迁移工具：
  • 集群外资源：数据库用 DRS、对象存储用 OMS、镜像用 image-syncer；
  • 集群内资源：应用 / 配置用 velero；
• 实施步骤：创建目标 CCE 集群→数据迁移→应用迁移→业务验证→流量切换→原集群下线。

4. 测试验证

• 应急预案：流量切换后若出现问题，通过调整 DNS 快速切回原集群，保障业务连续性。

三、核心注意事项

1. 系统资源（kube-system）按需迁移，迁移工具资源（velero）无需迁移；
2. 持久存储迁移前需将 HostPath 转为 Local 类型（适配 velero 工具）；
3. 目标集群配置尽量与原集群一致，降低适配成本；
4. 有状态业务需提前申请停机窗口，保障数据一致性。

11.3、容器迁移实施

一、容器迁移核心场景

主要分为两类：

1. 容器镜像迁移：将镜像迁移至新主机或华为云 SWR；
2. k8s 集群迁移上云：自建 / 友商 k8s 集群迁移至华为云 CCE。

二、容器镜像迁移的实现方式

1. 迁移至新主机（Docker 命令）：适用于镜像数量少的场景，有两组核心命令：

命令组合	作用对象	能否保留存储层数据	应用场景
save + load	容器（container）	不可以	制作基础镜像
export + import	镜像（image）	可以	打包多个镜像

• 操作步骤：
  • save+load：容器提交为镜像→save打包→scp传输→load导入；
  • export+import：export打包容器→scp传输→import为镜像。

2. 迁移至华为云 SWR

• 方式 1：Docker 命令（镜像少）：给镜像打 SWR 仓库标签（docker tag）→docker push上传至 SWR；
• 方式 2：image-migrator 工具（镜像仓库迁移）：适用于开源 / 自建镜像仓库迁移，步骤为：创建 SWR→安装工具→配置权限→编写镜像列表→执行迁移。

三、k8s 集群迁移上云（至 CCE）的实施

1. 核心工具：Velero

• 定位：开源 k8s 备份 / 迁移工具，支持集群资源（yaml 文件）和持久化数据（PV）的迁移；
• 架构：客户端 + 服务端，依赖对象存储（OBS/MinIO）存储备份数据；
• 备份 / 还原流程：
  • 备份：创建 Backup 任务→获取集群资源→备份至对象存储；
  • 还原：创建 Restore 任务→下载备份数据→重建集群资源。

2. 迁移步骤：

3. 目标集群资源规划；

4. 迁移集群外资源（镜像→SWR、数据库→RDS 等）；

5. 安装 Velero 工具；

6. 迁移集群内资源（Velero 备份原集群→还原至 CCE）；

7. 资源更新适配；

8. 业务验证与流量切换。

四、主流迁移工具对比

工具	特点
Velero	支持 k8s 资源 + PV 数据迁移，需两端部署服务端，迁移 PV 时需辅助容器解析数据
k8clone	轻量命令行工具，备份 k8s 数据到本地文件，恢复时自动替换镜像地址
image-migrator	镜像迁移专用工具，支持多厂商仓库，操作简单

12、缓存、队列服务的使用和迁移

• 在现代化应用架构中，中间件作为连接系统组件、保障数据流动的 “中枢神经”，直接影响着业务的稳定性与扩展性。随着云原生技术的普及，如何将传统中间件平滑迁移至云平台，并充分利用云服务的弹性、高可用特性，成为开发者与架构师面临的核心挑战之一。

• 本章系统讲解华为云中间件迁移技术，涵盖华为云中间件服务概览，缓存迁移原理与方案与消息队列迁移方案。

12.1、华为云中间件服务介绍

分布式缓存服务Redis版DCS

• 是开源服务Redis的华为云上实现
• 缺省支持数据持久化
• 支持高性能集群模式，可配置自动跨可用区高可用
• 本质上是键/值数据库

GeminiDB Redis

• 是华为的数据库引擎
• 基于计算存储分离架构
• 兼容Redis，高QPS能力
• 支持高性能集群模式，可配置自动跨可用区高可用
• 本质上也是键/值数据库

Redis 的两种典型使用方式：

​ 第一种是作为缓存使用，应用会优先从 Redis 读取数据，命中则直接完成请求，未命中时从 RDS 数据库读取并写入缓存，写操作则直接落库；这种方式的优势是对缓存可靠性要求低、仅缓存必要数据，但存在缓存未命中的性能损耗，也可能出现脏数据问题。

​ 第二种是作为键值（K/V）数据库使用，应用直接通过键值对形式向 Redis（可集群部署）读写数据；它的优势是性能高、数据结构灵活且数据规模几乎无限制，但缺点是缺乏事务能力，也不支持复杂查询操作。

分布式消息服务DMS

• 是开源Kafka、RabbitMQ、RocketMQ引擎的华为云上实现
• 亿级消息洪水蓄积
• 消费者-生产者松耦合架构的粘结器
• 可配置自动跨可用区高可用

消息队列的使用：

12.2、缓存迁移原理及迁移方案

一、Redis 迁移原理

分为离线迁移和在线迁移两类：

1. 离线迁移：基于 Redis 持久化文件（AOF/RDB）实现
   • AOF：记录所有写操作命令（类似操作日志），迁移时需修复 AOF 文件后恢复，优点是数据丢失少、可读性强，缺点是文件大、恢复慢；
   • RDB：生成某一时刻的内存快照（二进制文件），迁移时直接拷贝文件重启即可，优点是文件小、恢复快，缺点是可能丢失快照后的新数据。
2. 在线迁移：基于主从同步原理（PSYNC）PSYNC 是 Redis 主从增量同步的核心机制，通过runid（服务标识）、offset（复制偏移量）和复制积压缓冲区，仅传输断开期间的增量数据，避免全量同步的低效与带宽消耗。

二、自建 Redis 迁移到华为云 DCS 的方案

共 5 种主流方案，各有优劣势与适用场景：

方案	核心逻辑	优势	约束 / 缺点
1. DCS 在线迁移服务	基于主从同步（PSYNC）迁移	迁移快、业务中断少	仅支持 Redis3.0+、不支持公网迁移
2. 备份导入服务	导出 AOF/RDB 到 OBS，再导入 DCS	适配多数迁移场景	业务中断时间长
3. Redis-Shake 工具	基于主从复制原理迁移	迁移快、中断少	无可视化界面、操作不便
4. 双写方案	应用同时写源 Redis 和 DCS，再全量迁移	业务完全不中断	需自行改造代码、数据一致性难保障
5. EventGrid 在线迁移	基于事件流同步 + 立体监控	数据一致性高、有监控能力	不支持集群迁移、版本限制多

12.3、消息队列迁移方案

自建消息队列 Kafka 迁移到华为云的 5 种方案：

针对自建 Kafka 迁云，提供了 5 类方案，覆盖 “不迁移数据” 和 “迁移全量数据” 两类场景，各方案的核心逻辑、优劣势如下：

方案 1：不迁移数据，先切生产再切消费

• 逻辑：在华为云创建同 topic 的 Kafka，先将生产者切到云 Kafka，待源端消息消费完毕后，再将消费者切到云 Kafka，最后停源端服务。
• 优势：简单快捷、业务自主控制、保障消费顺序；
• 约束：切换有延迟、新 Kafka 可能消息积压。

方案 2：不迁移数据，双端同时消费后切生产

• 逻辑：云侧创建同 topic 的 Kafka，消费者同时消费源端和云 Kafka 的消息，再将生产者切到云 Kafka，待源端消息消费完后关闭源端连接。
• 优势：简单快捷、无数据积压；
• 约束：不保障消息顺序。

方案 3：MirrorMaker 迁移全量数据后切生产消费

• 逻辑：通过 MirrorMaker 工具（作为消费者读源端、生产者写云端）同步全量历史 + 增量数据，同步完成后切生产者 / 消费者到云 Kafka。
• 优势：同步全量数据；
• 约束：消费者切换后会重复消费历史消息。

方案 4：SmartConnect 迁移全量数据后切生产消费

• 逻辑：云侧开启 SmartConnect + 自动创 topic，创建任务拉取源端全量 + 增量数据，同步完成后切生产者 / 消费者到云 Kafka。
• 优势：同步全量数据；
• 约束：消费者切换后会重复消费历史消息。

方案 5：事件网格迁移全量数据后切生产消费（优先推荐）

• 逻辑：云侧创建 Kafka + 事件流作业，通过事件网格同步源端全量 + 增量数据，同步完成后切生产者 / 消费者到云 Kafka。
• 优势：支持海量并发、全量 + 增量同步、可观测 / 流控、SSL 加密；
• 约束：仅支持 Kafka 2.X+、作业配置后不可修改源 / 目标信息。

方案选型参考：

• 若无需保留历史数据：选方案 1/2；
• 若需保留全量数据：优先选方案 5（功能强、安全），或选方案 3/4（轻量工具）。