2023 DynatraceDevOps 自动化脉动 2023 年版由 Dynatrace 提供的调查研究DevOps 自动化脉动|2前言 随着企业继续向云原生软件交付过渡，DevOps 自动化已从提高效率的驱动力发展成为一项战略.要务。Kubernetes 架构的盛行推动了对自动化生态系统协调的需求，因为技术环境已经完全超出.了 人类的管理能力。为了满足这一需求，各组织正在尝试使用越来越多的开源工具，并将其与日益复杂的 DIY 方法结合在一起。然而，这种各自为政的做法现在开始出现裂痕。各组织被数据孤岛、.孤立的单一事件驱动自动化和被动的运营所束缚。不断上升的成本压力使人们更加迫切需要一种更连贯、更智能的企业级自动化方法，以提高效率并减少支出浪费。为了支持这一工作，各组织正在寻求数据驱动的自动化，使其能够更好地响应业务需求。他们的目标是通过预测性操作、先发制人的补救和持续优化，从被动转变为主动。只有通过强大的分析能力，在多种数据模式和最适合特定 DevOps 自动化用例的 AI 方法的支持下，才能实现这一点。组织需要一种可以在 IT 环境实时变化时持续即时地了解环境现状的 AI，以提供基于事.实的准确洞察。传统的基于机器学习的方法将无法满足这一需求，因为它们需要时间进.行训练。不过，这些方法可以满足对 AI 的额外需求，因为 AI 可以根据历史数据预测未.来状态。此外，组织还需要一种可以利用这些洞察来创建有意义的建议和自动化工作流.程的 AI。为了最有效地实现 DevOps 自动化用例，需要以可扩展和隐私优化的方式将数据收集和分析整合到单一平台上。这种方法需要将安全作为可观测性的一部分进行集成，并在上下文中统一这些数据，涵盖开发、安全和操作实践，以消除孤岛，确保不同类型的 AI 能够提供更精确、更可信的答案。只有这样，团队才能获得所需的精确答案，从而满怀信心地自动执行 DevOps 工作流程，而不会陷入利用数据流分析来核实洞察内容的困境。本报告为了解各全球组织当前 DevOps 自动化实践的成熟度提供了一个窗口，并为组织迈向下一阶段的旅程提供指导。调查结果基于来自世界各地各行业组织的 450 名 DevOps 自动化从业人员的反馈。我们希望这些见解能为您提供信息和帮助，帮助您在自己的组织中提升 DevOps 自动化的成熟度。Bernd Greifeneder Dynatrace 创始人兼首席技术官目录 引言内容摘要.4第 1 章DevOps 自动化的现状.5第 2 章DevOps 自动化的影响.16第 3 章克服阻碍 DevOps 自动化成熟的障碍.22第 4 章DevOps 自动化的未来.31研究方法.41DevOps 自动化成熟度模型.43如何提升 DevOps 自动化成熟度.45DevOps Automation Pulse|3内容摘要 本报告基于对不同行业 450 名 IT 从业人员的调查，简要介绍各全球组织的 DevOps 自动化成熟度。本报告探讨了 DevOps 自动化如何发展，迄今已经取得的效益，.以及进一步采用的障碍。本报告还揭示了随着组织寻求提升其 DevOps 自动化实践的成熟度，未来的前景将会如何。我们将深入探讨的一些重要调查结果包括：DevOps 自动化的未来.平台工程和 GitOps 实践对 DevOps 自动化的成熟度越来越重要，超过一半(54%)的组织在.这一领域进行了投资。.59%的组织预计大型语言模型(LLM)，.如 ChatGPT 和 Bard，将对 DevOps 自动化产生重大影响。为了实现这一点，他们需要将这些生成式 AI 能力与其他类型的 AI 相结合，以提供精确性和预测性。DevOps 自动化的现状.各组织正在继续投资 DevOps 自动化，但还有很长的路要走，因为目前只有 56%的端到端 DevOps 流程实现自动化。.工具链的复杂性阻碍了各组织在整个企业中扩展 DevOps 自动化的能力，因为团队平均依赖 7 种以上不同的工具。自动化投资带来的效益.DevOps 自动化投资在多个关键领域带来了实实在在.的效益，包括提高软件质量(61%)、提高员工满意度(58%)、减少部署失败次数(57%)、降低 IT 成本(55%)。.各组织寻求从 DevOps 自动化中取得的其他预期效.益包括：改进分析和洞察(59%)、缩短上市时间(49%)以及改善开发、安全和运维之间的协作(44%)。自动化采用的障碍 .由于对安全(54%)和工具链复杂性(53%)的担忧，各组织在进一步实现 DevOps 自动化方面受到了阻碍。.对于 87%的组织来说，数据孤岛仍然是 DevOps 自动化的障碍，使他们无法经济.高效地查询数据来获得实时洞察。DevOps Automation Pulse|4DevOps Automation Pulse|5第 1 章 DevOps 自动化的现状在成本上升和消费者信心减弱的动荡经济环境中，IT 领导者承受着越来越大的压力，.他们需要以更少的成本提供更多的服务，以保持组织在竞争中领先。因此，随着各组织寻找在不增加支出、不牺牲质量或安全的情况下加快创新的.方法，DevOps 自动化变得比以往任何时候都更具战略必要性。各组织在 DevOps 自动化之旅中取得了重大进展，超过一半的端到端 DevOps 流程已经实现自动化。但是，仍有许多工作要做。与大型组织相比，小型组织往往处于更基础的阶段。.他们的端到端 DevOps 流程自动化程度较低.他们的团队必须更频繁地人工干预才能完成任务.他们的软件工程师修复生产应用程序问题所需的时间是原来的两倍多56%已实现端到端 DevOps 流程自动化的平均比例 9 端到端 DevOps 管道中人工干预（包括审批和安全）的次数 9 软件工程师修复生产应用程序问题所需的平均小时数DevOps Automation Pulse|6DevOps 自动化脉动|6DEVOPS 自动化的现状各组织中已实现端到端 DevOps 流程自动化的总百分比45QWWcgQ0 亿美元 1050 亿美元50100 亿美元100200 亿美元 200500 亿美元500 亿美元以上收入软件和技术制造 电信 金融服务 能源和公用事业 汽车 医疗保健 政府/公共部门 零售 教育 61YYWWTSSE%不同规模不同行业DevOps Automation Pulse|7DEVOPS 自动化的现状各组织中完整端到端 DevOps 管道中的人工干预次数77991012510 亿美元 1050 亿美元50100 亿美元100200 亿美元 200500 亿美元500 亿美元以上收入不同规模不同行业软件和技术制造 电信 金融服务 能源和公用事业 汽车 医疗保健 政府/公共部门零售 88教育DevOps Automation Pulse|8DEVOPS 自动化的现状75.5971214软件工程师修复组织中生产应用程序问题所需的平均时间长度（小时）510 亿美元 1050 亿美元50100 亿美元100200 亿美元 200500 亿美元500 亿美元以上收入不同规模不同行业9987软件和技术电信 能源和公用事业制造 教育 汽车 医疗保健 零售政府/公共部门 金融服务 DevOps Automation Pulse|9DEVOPS 自动化的现状“DevOps 自动化对于组织能否与客户和瞬息万变的市场保持同步至关重要。通过自动化.减少工作量并最大限度地降低工具链复杂性，使开发人员能够专注于他们最擅长的事情，即进行创新，为业务带来价值。”“DevOps 自动化是加强我们日常工作管理和提高可靠性的关键组成部分。我们正在.塑造卓越运营文化，使员工能够从事更有意义的工作，并为公司提供更深层次的价值。”Hilliary Lipsig，RedHat 首席现场可靠性工程师Trevor Pratt，首席 IT 架构师.Duke EnergyDevOps Automation Pulse|10DEVOPS 自动化的现状自动化脆性普遍存在。随着各组织继续推动其他 DevOps 流程的自动化，他们依赖于越来越多的工具集，.以及操作这些工具集所需的专业技能。不同的团队使用各自首选的工具为其用例创建自动化脚本，通常采用复制粘贴方法.在不同的工作流程中复制自动化。平均而言，各组织使用 7.5 个工具来支持 DevOps 自动化 随着团队在整个组织的孤岛中生成多个自动化脚本的副本，自动化会变得脆弱，技术.债务也会增加。当有人离开组织或有新团队成员加入时，这也增加了理解和修改自动.化脚本的难度，因为这些脚本通常由创建者拥有和管理。因此，在 DevOps 生命周期.中整合端到端自动化流程的工作会受到阻碍。为了最大限度地发挥投资影响，组织必须避免在孤岛中将流程自动化。他们应该寻找.机会，通过基于平台的方法来优化端到端流程，从而整合工具并规范自动化脚本的构.建实践。工具集数量日益增加需要专业技能.才能操作技术债务日益增加.操作复杂，.难以管理自动化脚本各组织面临的挑战DevOps Automation Pulse|11DevOps 自动化脉动|11DEVOPS 自动化的现状“.在我们的 DevOps 环境中浏览工具网就像试图解开一个结。.我们需要一种更精简的自动化方法，该方法应可简化我们的开发、.交付和运维流程，使其更高效。”Alex Hibbitt，SRE 和履行工程总监.Albeli-photobox GroupDevOps Automation Pulse|12DEVOPS 自动化的现状各组织使用的最热门 DevOps 自动化工具/平台包括：Kubernetes67432)(&%!fSRRIG888%Azure DevOpsGitHubGitLabAtlassianTerraformJenkinsAnsibleServiceNowDockerPuppetDIY/内部开发ChefHarnessCrossplaneJFrogArgo CDFluxSnykDevOps Automation Pulse|13DEVOPS 自动化的现状可观测性是 DevOps 自动化的先决条件 自动化的精确度取决于其所依据的数据。因此，在 DevOps 自动化的背景下，可观测性已成为基本条件。可观测性数据为深入了解应用程序及其基础架构的稳定性、性能和用户体验提供了丰富的见解来源。当与安全数据和业务事件（如购物车废弃率和用户满意度）相结合时，这些见解会因上下文而进一步丰富，从而在各种 DevOps 用例中实现更精确的 AI 驱动自动化。随着各组织继续投资于大规模捕获、保留和查询这些数据的能力，他们能够将 DevOps 实践提升到新的高度，带来更高的效率，增强服务的稳定性，并提高用户满意度。的组织表示，可观测性驱动型自动化带来了更迅速的事件响应和更快的解决时间 的组织表示，可观测性使他们能够自动进行发布验证，.在将软件投入生产之前提高软件的安全和质量的组织表示，可观测性工具帮助他们识别瓶颈并实现交付管道自动化的组织表示，他们积极利用可观测性数据和见解来.推动 DevOps 工作流程的自动化决策和改进78xtqvOps Automation Pulse|14DEVOPS 自动化的现状自动化投资的主要优先事项 随着业务需求的不断增加以及可用资源的有限，DevOps 团队必须专注于尽快有效地实现高质量、安全的创新。这促使在软件开发生命周期(SDLC)的所有领域，从安全管理到基础设施运维，从软件开发和交付到可观测性，加大对自动化和 EaC（一切皆代码）方法的投资。然而，各企业都处于 DevOps 自动化成熟度的不同阶段。这造成了 DevOps 团队工作重点的多样性，并且必须确定哪些流程是 DevOps 自动化投资的优先事项。各 DevOps 自动化组织计划在未来 12 个月内进行投资的领域55%安全和合规管理48%可靠性自动化 52%基础设施资源调配/管理 46%测试和发布验证 51%性能优化 41%自动化回滚 49%渐进式交付 DevOps Automation Pulse|15DEVOPS 自动化的现状DevOps Automation Pulse|16第 2 章 DevOps 自动化的影响成功的衡量标准 如果各组织不首先衡量 DevOps 自动化现有投资的影响，就不可能确定需要改进的领域。因此，DevOps 领导者正在采用一系列关键性能指标(KPI)和服务级别目标(SLO)来评估其自动化工作是否成功。然而，在衡量自动化的影响方面，大多数组织仍处于成熟度相对早期的阶段。随着组织规模的缩小，他们不太可能有一个稳健的投资回报率(ROI)模型，使他们能够高效地跟踪和报告 DevOps 自动化的影响。只有 35%的组织拥有 ROI 模型来跟踪其 DevOps 自动化投资的影响*因此，规模较小的组织更难确保将精力集中在 DevOps 自动化能带来最大价值的领域，这反过来又阻碍了他们与竞争对手保持同步，并以市场和客户要求的速度进行创新的能力。*数据基于全部受访者中较小的一部分。DevOps 自动化脉动|17DEVOPS 自动化的影响拥有 ROI 模型来衡量其 DevOps 自动化投资影响的组织*数据基于全部受访者中较小的一部分。57q&!Q0 亿美元 1050 亿美元50100 亿美元100200 亿美元 200500 亿美元500 亿美元以上收入不同规模软件和技术制造 电信 金融服务 能源和公用事业 汽车 医疗保健 零售 教育438821!%6%0%政府/公共部门不同行业70dvOps Automation Pulse|18DEVOPS 自动化的影响各组织用于评估自动化是否成功的常见 KPI/SLO在软件开发和交付方面 在安全流程方面 在业务层面53YaXUHGEXEBRPCBB5%严重 P1 警报的数量 严重应用程序安全事件的数量 用户采用率 自动化流程百分比 客户满意度(CSAT)评分 相对于竞争对手的市场份额 成本降低幅度 收入增长 误报率 MTTD（平均检测时间）覆盖范围变更故障率 测试覆盖范围.（自动化测试的百分比）开发人员工作效率 MTTD（平均检测时间）变更准备时间 从 SDLC 中消除的瓶颈数量 部署频率 DevOps Automation Pulse|19DEVOPS 自动化的影响DevOps 自动化的价值 各组织报告称，他们在 DevOps 自动化方面的投资正在以多种方式获得.回报，从提高软件质量、提高竞争优势到提高员工满意度、打造创新和协.作文化。此外，DevOps 自动化显著减少了部署失败次数，最大限度地减少了中断，.提高了可靠性，同时优化了 IT 成本，实现了持续的卓越运维。值得注意的是，59%的组织表示，DevOps 自动化提高了分析和洞察力，.使他们具备了有价值的数据驱动决策能力。然而，“垃圾进，垃圾出”这句谚语仍然适用。为了获得充分效益，各组织需要保持数据的准确性，并授权其团队以保留不同类型和数据源之间关系和依赖性的完整上下文的方式进行分析。59%的组织表示，DevOps 自动化提高了分析.和洞察力。DevOps 自动化在关键领域的改进程度如何？软件质量领域的平均改进幅度开发、运维和安全团队的员工满意度领域的平均改进幅度部署失败次数领域的平均减少幅度IT 成本的平均减少幅度 DevOps Automation Pulse|20DEVOPS 自动化的影响DevOps Automation Pulse|21DEVOPS 自动化的影响“DevOps 自动化的成功不应该仅仅以工程输出成果的增加和服务可靠性的增强来衡量。.它应该表现为一种卓越运营文化，使员工不会做无用功，并使组织成为一个良好的工作场所。”“采用 DevOps 自动化改变了我们的软件之旅。这不仅仅是为了提高质量；.还关乎我们创新的速度。通过自动化，我们的交付周期迅速加快，.客户满意度也随之显著提高。”Dan Healy，APM 监控和指标高级经理，TIAAMichael Cabrera，SRE 总监.VivintDevOps Automation Pulse|22第 3 章 克服阻碍 DevOps 自动化成熟的障碍安全性和复杂性阻碍了组织的发展 57%的 DevOps 从业人员表示，由于缺乏数据流分析或数据可观测性工具，很难.以合规的方式推动.自动化。阻碍组织启动 DevOps 自动化新用例的最大障碍安全问题/担心快速交付会增加风险迁移与 DevOps 自动化不兼容的遗留系统的复杂性各自为政的团队-每个团队都有自己的章程、预算、工具和工作方式文化阻力-很难说服团队采用新的工具和流程难以操作数据来支持自动化工具链复杂性/集成 1000 多个 CNCF 工具的资源有限希望增加 DevOps 自动化现有用途的组织面临的额外障碍缺乏实施和维护新自动化技术的专业知识缺乏从操作到开发的反馈回路，很难实现自动化缺乏资源（预算和时间）现有自动化计划的影响有限，很难获得额外预算DevOps Automation Pulse|23克服阻碍 DEVOPS 自动化成熟的障碍DevOps Automation Pulse|24“安全问题一直是全面实现 DevOps 自动化的一个重要障碍。尽管我们希望简化流程，.但我们不能牺牲数据完整性和隐私。我们的首要任务是找到将强大的安全措施纳入.自动化战略的方法。”Michael Glaess，首席产品架构师.Dynatrace克服阻碍 DEVOPS 自动化成熟的障碍许多组织缺乏 DevOps 自动化战略 为了支持这种更加可控的自动化构建方式，团队需要一种方法来确保通过标准化和可重复的流程，以负责任和安全的方式在整个组织内扩展这种能力，从而最大限度地降低人为错误的风险。然而，对于许多尚未实施明确 DevOps 自动化战略的组织来说，这将是一个重大挑战。因此，对于希望提高 DevOps 自动化计划成功率的组织来说，制定和推出这样的战略将是至关重要的第一步。只有 38%的组织有明确制定的完整 DevOps 自动化战略*各组织还应该设法简化其快速扩展的工具链的复杂性。云原生计算基金会(CNCF)领域目前有 1,000 多个解决方案。随着团队采用这些解决方案来支持 DevOps 自动化，组织需要确保它们无缝集成。这将减少端到端 DevOps 工作流程中人工移交和干预的需求，使团队能够充分利用自动化投资的好处。*数据基于全部受访者中较小的一部分。DevOps Automation Pulse|25克服阻碍 DEVOPS 自动化成熟的障碍拥有明确制定的完整战略来支持 DevOps 自动化的组织*软件和技术制造 电信 金融服务 能源和公用事业 汽车 医疗保健 零售 教育60WPPG0%0%政府/公共部门*数据基于全部受访者中较小的一部分。57b0P!Q0 亿美元 1050 亿美元50100 亿美元100200 亿美元 200500 亿美元500 亿美元以上收入不同规模不同行业DevOps Automation Pulse|26克服阻碍 DEVOPS 自动化成熟的障碍打破数据孤岛：利用上下文洞察发挥 DevOps 自动化的作用 许多组织都在努力最大程度发挥其 DevOps 自动化计划的影响，因为他们的数据被困在不同存储库和团队用于管理.其云生态系统的众多工具中。因此，这些数据必须经过系统间的多次跳转，才能构建可用于自动化工作流程的上下文。85%的组织表示，他们在使用可观测性和安全数据来推动 DevOps 自动化方面面临挑战没有上下文，就不可能精确地推动 DevOps 自动化，因为团队无法理解云技术堆栈之间的关系和依赖性。因此，.他们无法应用分析功能来区分问题的症状和原因，这会产生误报、重复警报和低优先级问题，从而破坏自动化流程。10-可观测性和安全数据在可用于 DevOps 自动化之前需要流经的不同跃点平均数DevOps Automation Pulse|27克服阻碍 DEVOPS 自动化成熟的障碍各组织在使用可观测性和安全数据来推动 DevOps 自动化方面面临的挑战数据无法访问 数据成为孤岛 数据需要流经许多系统/跃点才能进行分析 数据质量差 数据分析往往会导致过多误报 数据不一致 数据缺少上下文 重大挑战挑战51CA4442vOps Automation Pulse|28克服阻碍 DEVOPS 自动化成熟的障碍软件和技术制造 电信 金融服务 能源和公用事业 汽车 医疗保健 零售 教育可观测性和安全数据在可用于在组织中驱动 DevOps 自动化之前需要流经的平均跃点数010998政府/公共部门10 亿美元 1050 亿美元50100 亿美元100200 亿美元 200500 亿美元500 亿美元以上收入不同规模不同行业DevOps Automation Pulse|29克服阻碍 DEVOPS 自动化成熟的障碍获得技能仍然是一个重大障碍 除了操作数据的挑战外，各组织还面临着支持 DevOps 自动化所需技能的严重短缺。在经济不确定性持续存在的情况下，.获得额外预算以吸引和留住这些专业技能仍将是一项重大挑战，但这个问题对于 IT 领导者来说已是老生常谈。自动化 DevOps 工作流程所需的最重要技能，也是各组织正在努力解决其短缺的技能包括：56%熟练使用 Python、Ruby、PowerShell 等脚本语言 41%熟悉 GitOps/基础.设施即代码(IaC)52%云平台和架构知识.（例如微服务）41%熟练使用开源自.动化解决方案 49%精通自动化软件.测试工具和实践 40%对 CI/CD 管道的了解以及.有效实施这些管道的能力 40%敏捷交付知识 44%熟悉自动化部署和.渐进式交付实践 DevOps 自动化脉动|30克服阻碍 DEVOPS 自动化成熟的障碍DevOps Automation Pulse|31第 4 章 DevOps 自动化的未来自动化的发展 DevOps 自动化是一种不断发展的实践，在过去 15 年中取得了显著进展。现在，各组织正在投资于各种计划，.通过确保自动化从根本上融入其团队构建和交付软件的方式，将这一进展推向新的高度。各组织将在未来 12 个月内采取各种措施，确保将 DevOps 自动化整合到整个软件设计流程中 定期审查 DevOps 自动化实践和工具 进行流程、工具和协作工.作方式的定期团队培训 建立定期检查点，推动开发和.运维团队之间的协作 投资于数据可观测性和数据流分析工具，.以合规方式实现流程自动化 提高团队对现场可靠性工程(SRE)文化的遵守程度 66URH9vOps Automation Pulse|32DEVOPS 自动化的未来智能自动化之旅 DevOps 最初致力于通过实现可重复业务流程的自动化来提高效率，现在正在取得进展。DevOps 团队正在制定自动化工作流程，使他们能够在满足特定条件或发生事件时实时做出响应，例如表明存在安全风险的可疑用户活动，或放弃购物车等客户行为。这一发展的下一个前沿领域是向智能自动化的.转变，DevOps 团队可以使用出色的 AI 功能即时查.询数据，以便更准确地了解其生态系统中事件的来.龙去脉。这形成了一个反馈回路，可以触发自动工作.流程，为企业实现价值最大化和成果最优化。例如，DevOps 团队可以利用从可观测性数据中获取.的性能、稳定性和用户体验指标，来制定智能发布管理流程。AI 可以将这些数据转化为见解，使团队能够立即了解任何新软件发布的影响。这反过来又可以自动触发工作流程，如果影响是有害的，则将发布回滚到以前的.稳定版本；如果产生积极影响，则将其推广到更广泛的用户群。同样的方法也可以用于实现更智能的安全流程，从自动威胁检测和漏洞扫描到快速事件响应。随着各组织不断探索这些可能性，他们正朝着自主、.自我修复的系统发展，这种系统可以在无需人工干预的情况下自动检测和解决应用程序和基础设施中的问题。为了实现这一点，各组织正在投资于推进其自动化计划所需的技能集、框架和最佳实践。许多组织依赖于开源 DevOps 自动化项目，这些项目通常作为 DIY 工具链的一部分来实施。这增加了复杂性，并且需要大量的人工维护工作。拥有内部资源和能力，能够在不付出大量劳动的情况下建立工作流程，这是取得成功的另一个关键衡量因素。的组织在很大程度上依赖于 DevOps 自动化的开源项目软件工程和开发团队构建和维护 DevOps 自动化脚本所花费的平均时间的组织拥有专职自动化工程师来支持 DevOps 自动化413evOps Automation Pulse|33DEVOPS 自动化的未来平台工程和 GitOps 是 DevOps 自动化成熟度的关键 当各组织努力提高其 DevOps 自动化实践的成熟度时，他们需要将.重点放在通过协作团队文化提高运营效率和灵活性的计划上。新兴.的平台工程学科可以加快软件开发并优化开发人员体验，是这些工作的核心。54%的组织正在投资于平台，以实现自动化项目团队之间更轻松的工具集成和协作有了内部开发平台(IDP)，各组织可以为开发团队提供自助服务功能，使他们能够更有效地协作，利用现有工具，并减少工作量。各组织可以通过一个集中管理的安全平台，为其团队提供创建自己的解决方案所需的组件、工具和模板，而不是从头开始构建每一个新的自动化工作流程。更成熟的组织还将寻求 GitOps 和 EaC 方法来提供 DevOps 团队所依赖的关键能力，包括基础设施管理、软件部署和可观测性。这使开发人员能够更好地控制将这些功能嵌入到自动化工作流程的过程，因为流程是标准化和完全自动化，从而减少了采用的障碍。随着平台工程和 GitOps 的发展，各组织将发现更容易克服他们最.初在推动 DevOps 自动化采用方面所面临的许多障碍。创建统一.的 IDP 将打造一种更具协作性的文化，有助于消除团队之间的隔阂，.并在他们看到其他团队正在发挥效用时，缓解他们对变更的抵触。.通过 GitOps 构建自动化工作流程的标准化和可重复流程的普及，.也将减少支持这些计划的软件工程师和开发人员的时间消耗。DevOps Automation Pulse|34DEVOPS 自动化的未来DEVOPS 自动化的影响DevOps Automation Pulse|35“平台工程正日益成为寻求提高 DevOps 自动化实践成熟度的组织关注的焦点。这种转变将增加技术债务和团队间的协调工作。如果没有一个集中的集成平台，.扩展自动化以推动进一步的影响将成为一项难以克服的挑战。”“通过进行版本控制的基础设施和声明性配置，采用 GitOps 带来了极高的灵活性和稳定性。我们的团队无缝协作，轻松协调变更，为效率和创新的新时代奠定了基础。”Anita Schreiner，交付副总裁.DynatraceSimon Pilar，DevOps 和 DLC 工具链总监.Clario“自动化卓越中心”推动管理和提升成熟度 许多组织已经开始为 DevOps 自动化开发自己的内部卓越中心(CoE)，帮助整个组织的团队.成功实施计划。然而，随着组织向成熟的 DevOps 自动化迈进，这种新兴的实践需要得到更.广泛的推广。36%的组织拥有“卓越中心”来支持 DevOps 自动化*CoE 在提供团队在整个工作流程中构建和实施自动化所需的工具、框架和最佳实践方面至关.重要。例如，它可以建立低代码/无代码平台，推动 GitOps 实践的采用，使团队无需专业知识.和技能，就能以集中管理、安全和受控的方式构建和部署自动化脚本，并保持合规性。*数据基于全部受访者中较小的一部分。DevOps Automation Pulse|36DEVOPS 自动化的未来拥有卓越中心(CoE)来支持 DevOps 自动化的组织*14BGQR%能源和公用事业汽车医疗保健软件和技术电信政府/公共部门 教育 金融服务 零售 70aXPGC%0%0%制造 510 亿美元 1050 亿美元50100 亿美元100200 亿美元 200500 亿美元500 亿美元以上收入不同规模不同行业*数据基于全部受访者中较小的一部分。DevOps Automation Pulse|37DEVOPS 自动化的未来AI 必须与自动化共同成熟 DevOps 自动化的基础方法依赖于概率性机器学习模型，该模型可根据历史模式和行为关联数据并提出.见解。这些方法不够精确，因此 DevOps 团队必须先人工审核答案，然后才能用于触发自动化工作流程。59%的组织预计大型语言模型(LLM)，如 ChatGPT 和 Bard，将对 DevOps 自动化能力产生重大影响各组织现在正在探索 AI 技术的持续进步如何使他们的 DevOps 自动化战略达到一个新的成熟度水平。.毫无疑问，在整个 2023 年，大部分注意力都集中在团队如何利用生成式 AI 和大型语言模型(LLM)来推.动 DevOps 自动化进一步成熟。有相当多的组织已经在探索 DevOps 工作流程中生成式 AI 的一些早期.用例。“我们设想未来 DevOps 实践将被 AI 彻底改变。对于我们的行业来说，.这是一个激动人心的变革时刻。我们对其提升我们自动化工作的能力充.满希望并表示乐观。”Mark Tomlinson，性能架构师.FreedomPayDevOps Automation Pulse|38DEVOPS 自动化的未来各组织期望 LLM 影响 DevOps 自动化的方式包括：57FA9VH%通过分析大量数据、进行预测和建议优化自动化工作流程，提高工作效率，减少人工工作量通过更快的知识共享、自动化文档、持续学习和即时回答问题，.改进开发、安全和运维协作使 DevOps 和平台工程团队能够利用软件库中的信息.自动生成代码片段通过分析用户反馈和可观测性数据来确定模式、.发现问题并提供实时建议，从而改进交付管道通过生成测试案例、确定潜在的边缘用例和提供测试覆盖.范围的见解，改进测试和代码质量通过分析历史数据、用户反馈和行业最佳实践的能力，制定更智能的发布、部署和回滚策略DevOps Automation Pulse|39DEVOPS 自动化的未来然而，要满怀信心地实现 DevOps 流程自动化，团队需要相信 AI 提供的答案。因此，团队正在寻找超越机器学习的更先进、更精确、更可扩展的方法，使他们能够将生成式 AI 用于 DevOps 自动化。AI 理解问题根源的能力对于建立信任至关重要。因此，可观测性数据和因果关系 AI 对 DevOps 自动化的未来至关重要，因为它们可以用来揭示基于事实的答案，而不是基于数据中的相关性和模式的最佳猜测。86%的组织表示，可观测性数据将在其未来的 DevOps 自动化战略中发挥至关重要的作用预测性 AI 是另一个重要组成部分，通过预测未来情况并就如何在问题出现之前先发制人和主动解决问题提出建议，有助于改善 DevOps 自动化工作。随着各组织继续实施这些不同类型的 AI，以提高其 DevOps 自动化的成熟度，成功的关键在于能否将它们结合起来，使团队能够利用每种技术的优势。因果关系 AI 基于事实的准确性、预测性 AI 的前瞻性直觉以及生成式 AI 带来的工作效率提高，都将在不断迈向 DevOps 自动化成熟的过程中发挥核心作用。DevOps Automation Pulse|40DEVOPS 自动化的未来研究方法 本报告基于对 450 名负责大型组织 DevSecOps 自动化的 IT 从业人员的全球调查，其中包括美国 150 人、欧洲、.中东和非洲地区 150 人以及亚太地区 150 人。这项调查研究由 Dynatrace 委托 Coleman Parkes 进行。您主要居住在哪个国家/地区？美国33%英国6%爱尔兰3%荷兰3%瑞典3%挪威3%丹麦2%芬兰2%德国5%法国5%印度7%新加坡7%澳大利亚7%新西兰2%泰国6%马来西亚6%贵公司在哪个行业开展业务？软件和技术22%零售和批发19%金融服务（包括银行和保险）18%教育9%政府/公共部门-中央（联邦）、省（州）和当地8%制造6%电信5%医疗保健5%能源和公用事业5%汽车4%贵组织的年收入大概是多少？5-10 亿美元 13-50 亿美元 20P-100 亿美元 180-200 亿美元20 0-500 亿美元16P0 亿美元以上13vOps Automation Pulse|41以下哪一项最接近您的职务？副总裁/工程主管9%副总裁/DevOps 主管8%开发经理/主管8%高级架构师8%高级软件开发人员8vOps 工程师8%云架构师8%站点可靠性工程师7%副总裁/平台主管7%平台工程师/平台架构师7vOps 经理7%首席架构师5%SRE 经理5%其他5%贵组织已经实践 DevOps 多少年？12 年 35 年 超过 5 年 120WvOps Automation Pulse|42DevOps 自动化成熟度模型根据与参与 DevOps 自动化计划的众多组织的探讨，.DevOps 自动化成熟度出现了四个明确的阶段：基础、标准化、先进和智能。基础标准化先进智能说明自动化工作处于早期阶段，重点是建立基本.自动化实践自动化在各个流程中的整合程度越来越高，.减少了人工干预，提高了效率，并确保了结.果的一致性自动化实践变得成熟，并整合到整个 SDLC 中，成立了团队并制定了章程，以推动整个组织的自动化发展自动化先进、可靠、完全值得信赖自动化实践.具有较高的管理水平，并在整个 IT 组织中根.深蒂固自动化实践自动化实践没有正规化，在整个软件开发生.命周期中缺乏标准化和集成化为了实现更无缝、更连贯的自动化框架，需要.协同努力来整合自动化实践并加强团队之间的协作自动化实践利用先进的自动化技术和优化策略来提高工作效率、降低风险并推动持续改进自动化实践利用人工智能(AI)和机器学习(ML)等先进技术，实现自主、可靠和值得信赖的决策和预测能力DevOps 流程有些 DevOps 流程已实现自动化，而大多数.则依赖人工流程和干预许多 DevOps 流程已实现中等程度的自动化，而其他流程正在逐步实现自动化大多数 DevOps 流程均已实现自动化和简化，从而保留了宝贵的人力资源，实现了更大程度的创新几乎所有 DevOps 流程均已完全实现自动化，并采用数据驱动的洞察力来推动智能自动化、高级和预测性分析以及主动解决问题应用程序安全一些应用程序安全流程（例如，安全测试、.漏洞扫描）已在 DevOps 流程中实现自动化许多应用程序安全流程自动执行，而测试和.扫描结果则作为发布管理的一部分由人工进.行评估持续监控应用程序运行时的漏洞；当检测到新的关键漏洞时，会自动通知相应的团队持续监控应用程序运行时的漏洞；设置安全门以阻止具有新关键漏洞的部署DevOps Automation Pulse|43基础标准化先进智能数据挑战重大的数据挑战（数量、质量、不一致性、.孤岛和缺乏上下文）阻碍了 DevOps 自动.化取得进展数据挑战仍然存在，但已确定应对这些挑.战的措施许多数据挑战已被消除，利益相关者能够.利用数据推动跨团队和部门的自动化工作整个企业的数据质量、收集、可访问性和流.程均得到了高度优化，增强了持续自动化预算和投资自动化投资很少，没有专门的自动化预算分配制定了自动化预算，确定了投资，但很难跟.踪和报告投资回报率为自动化投资制定了专门的预算，并建立.了 ROI 模型或类似模型来实现高效报告为自动化投资制定了专门的预算，并建立了 ROI 模型或类似模型来实现高效报告人力资源为推动自动化计划和人员培训分配的资源极少一些关键的开发人员/工程师负责推进自动.化计划和发展，并接受了有限的培训为推动自动化计划的持续发展专门设立.了具体角色并分配了时间、预算和培训建立了完善的 DevOps 和平台工程团队，.对其进行了培训，并持续有效地加强自动.化实践目标目标是打造强大的自动化基础，制定自动化.原则，并为更加成熟的自动化框架奠定基础目标是在 DevOps 生命周期的不同阶段之.间实现更高级别的自动化集成和协同效应目标是通过自动化驱动型实践实现卓越运营目标是通过智能自动化实践实现高水平的.效率、灵活性和创新DevOps Automation Pulse|44DevOps Automation Pulse|45如何提升 DevOps 自动化成熟度 每个组织在其 DevOps 自动化之旅中都处于不同的阶段，这取决于多种因素，从高管的认可水平到可用的资源，以及团队内部存在的变革文化。目标应该是向智能自动化迈进，实现流程自动化，以在整个组织中提供最大的效率、灵活性和创新。为了制定有助于组织发展的路线图，领导者应该采取的第一步是进行 DevOps 自动化成熟度评估，以确定他们目前正朝着哪个阶段努力。有了这种理解，就更容易确定并专注于他们需要实施的关键举措，以推进到下一阶段。阶段：基础进入基础阶段评估和认知：首先对当前流程进行评估，确定可以自动化的人工和/或可重复的开发、安全和运维任务。.提高团队对自动化好处的认识。基本自动化：从简单重复的任务着手，使用现成的工具将其自动化。这将有助于熟悉自动化概念。绘制流程图：绘制软件开发生命周期图，确定自动化可带来附加值的领域，如代码编译、软件测试、.代码部署、监控、补救等。技能集：确定建立自动化文化和交付自动化项目所需的技能和资源。工具探索：开始探索可满足组织需求的自动化工具。其中可能包括基本脚本语言、开源自动化框架.或简单的 CI/CD 平台。安全：确定人工安全流程，如漏洞扫描、测试、警报优先级排序和补救工作。考虑这些流程中有多少.接触点可以实现自动化。阶段：标准化 从基础到标准化自动化管理：为整个 DevOps 流程的自动化标准化制定路线图，重点是创建一致的指导原则和最佳实践。确保自动化投资的专用预算。跨团队协作：发起跨团队协作，共享自动化脚本、工具和经验，打造知识交流和协作文化。自动化倡导者和培训：确定并培训一些开发人员和管理人员，让他们成为自动化倡导者，推动自动化实践的采用。这将确保每个人都可做出有效的贡献。工具整合：评估和整合自动化工具集，以最大限度地降低复杂性，并确保工具与您正在实施的标准化实践保持一致。DevOps 流程自动化：在开发、运维和安全流程的基础上实现 DevOps 流程自动化。自动化指标：获取监控和衡量自动化流程有效性的指标，使您能够跟踪进度并确定需要改进的领域。确定数据挑战：确定阻碍自动化工作的数据挑战（例如：访问受限、数据孤岛、数据质量差、缺乏上下文、.误报过多等）。集中警报：通过实施集中式工作流程和工具集，整合多个团队的警报、漏洞修复、测试和其他关键流程。DevOps Automation Pulse|46阶段：先进 从标准化到先进 自动化管理：建立“自动化卓越中心”(CoE)，以集中专业知识，促进最佳实践，并推动先进自动化方法.的采用。增强 ROI 跟踪：通过实施更复杂的模型来增强 ROI 跟踪，这些模型不仅应节省成本，还应利用自动.化提高工作效率和质量。减少数据障碍：通过提高数据质量，减少阻碍团队利用数据推动自动化的障碍（例如，在存储数据时保留数据上下文，实施数据访问控制和权限，投资数据仓库存储解决方案，设计高效的数据路径以最大限度.地减少跃点和延迟等）。持续优化：为自动化实践制定持续优化流程，定期审查和完善脚本、工具和流程，以实现最大效率。提高自动化实践：考虑实施 GitOps 等实践，并采用“一切皆代码”的方法来进一步提高自动化并简.化流程。DevOps 流程自动化：引入先进自动化流程，如动态资源调配、自动扩展、自我修复和漏洞扫描，.以提高软件的效率和可靠性。统一优先级排序：实现单一真相源，以持续、自动确定警报的优先级。AI 和 ML 集成：考虑将 AI 和 ML 技术集成到 DevOps 流程中，以获得数据驱动型洞察力。阶段：智能 从先进到智能AI 驱动型优化：利用洞察力推动整个 SDLC 的自动化（例如，动态调整资源分配、控制部署、微调测.试场景等）。主动问题预测：利用 AI 预测潜在的自动化瓶颈、安全漏洞或性能问题。在这些问题影响运营之前解.决这些问题。全自动补救：实施 AI 技术支持的自动补救，可以快速响应事件，并根据学习到的模式和预定义的运行.手册执行纠正措施。平台工程：成立专职平台工程团队，以推动一致性和自助服务自动化。高级培训：为团队提供 AI、ML 和数据分析方面的高级培训。探索 LLM 和 GPT 等新兴技术，并评估这.些技术如何增强智能自动化能力，从而提高效率和促进创新。智能安全：引入 AI/ML 来协助连续和自动的安全流程，如漏洞检测、调查、分配、补救验证和警报优先级。DevOps Automation Pulse|47附录2023 Dynatrace01.05.24 BAE9093_EBK_jvs关于 DynatraceDynatrace(NYSE:DT)旨在让全球的软件完美运作。我们的统一平台将广泛而深入的可观测性和持续的运行时间应用程序安全性与出色的 AIOps 相结合，提供基于大规模数据的答案和智能自动化。这使创新者能够实现云操作的现代化和自动化，更快、更安全地交付软件，并确保完美的数字体验。这正是全球大型组织信任 Dynatrace 平台可以加速数字化转型的原因。要了解更多，请访问 。

0人已浏览 2024-01-23 48页 5星级

I边缘云原生虚拟化研究报告2024 年 1 月可信边缘计算推进计划II目次前言.III1 技术与需求概述.11.1 虚拟机和容器.11.2 OpenStack 与 Kubernetes.11.3 融合管理的演进：K8s 环境下运行虚拟机.31.4 开源项目简介.42 技术实践.92.1 生命周期管理.92.2 镜像管理.102.3 存储管理.132.4 网络能力.15III前言参与单位（排名不分先后）：中国联合网络通信有限公司研究院，中国联合网络通信有限公司智网创新中心、可信边缘计算推进计划编写人：黄蓉 庞博 黄倩 陈丹 肖羽 蔡超 侯迎龙 隗英英 高沛 李晓旭 隋佳良 王蕴婷 李昂11技术与需求概述随着网络技术和云技术的发展，边缘计算得到了广泛的应用。边缘计算可以解决高可靠低延迟的设备接入和海量数据的实时计算问题，云技术有力的保障和推动了边缘计算的应用。1.1虚拟机和容器虚拟机和容器是云计算中最常用到的应用部署和运行方式。虚拟机是伴随着虚拟化的技术出现的，容器则云原生技术的典型特征之一，他们的架构对比如下图所示：图 1：虚拟机与容器架构对比图如上图所示，虚拟化技术一般通过虚拟化层（hypervisor）来实现，通过虚拟化技术，虚拟机可以共享物理机的 CPU、内存、IO 等硬件资源，并在逻辑上实现相互隔离。每一个虚拟机都拥有独立的操作系统（客户机操作系统），所以虚拟机不依赖于宿主机操作系统，其安全性和隔离性更强。但是虚拟机占用的资源较多，而且由于要模拟硬件，虚拟化层本身也会占用部分资源，对宿主机性能有一定的消耗。比较而言，容器则是使用宿主机的内核系统加上自身的文件系统。运行容器时是在使用宿主机的内核情况下加载文件系统，一般可以将容器看作是在内核上运行的独立进程。而精简的文件系统可以小到100MB 以内，因此容器比虚拟机占用资源的更少、启动速度更快。容器缺点是隔离性不如虚拟机，而且由于依赖宿主机内核，所以容器的操作系统选择一般会受到限制。两种技术的特点对比如下表：表 1：虚拟机与容器技术特点对比对比项虚拟机技术容器技术安全隔离性强，操作系统级别弱，进程级别对宿主机操作系统依赖无有，需要相同操作系统内核启动时间慢，分钟级快，秒级磁盘占用大（GB）小（MB）虚拟化性能损耗大1小1.2OpenStack 与 Kubernetes从运行和管理平台来看，OpenStack2与 Kubernetes（K8s）3分别是对虚拟机和容器进行运行和管理的典型开源项目。OpenStack 是开源的云计算平台，利用虚拟化技术和底层存储服务，提供了可扩展、灵活、适应性2强的云计算服务。OpenStack 的服务分为核心功能和非核心功能。核心功能是指运行 OpenStack 系统必须的功能的组件，包括：Keystone（身份识别服务）、Glance（镜像服务）、Nova（计算机服务）、Neutron（网络服务）、Cinder（块存储服务）、Swift（对象存储服务）、Horizon（控制面板服务）。非核心功能指的是实现附加功能的组件，如 Ceilometer（测量功能）、Heat（部署编排）、Trove（数据库服务）等。OpenStack 的各个组件（服务）之间使用标准的 API 接口调用，减少了服务之间的依赖。下图是 OpenStack 的逻辑架构图。图 2：OpenStack 逻辑架构图Kubernetes 是容器管理编排引擎，可以自动完成容器的部署、管理和扩展等操作，部署 Kubernetes的设备环境通常被成为 Kubernetes 集群。Kubernetes 集群逻辑上可以分为两个部分：控制平面与计算设备（或称为节点）。控制平面的包含：kube-apiserver（接口程序，用于处理内部和外部请求）、kube-scheduler（调度程序）、kube-controller-manager（集群控制管理程序）、etcd（数据库）。计算设备包含容器运行时引擎、kubelet（节点代理程序）、kube-proxy（网络代理程序）。Kubernetes 的设计原则包括：安全、易于使用和可扩展。Kubernetes 同样遵循标准化 API 接口，而且 Kubernetes 实现了 CNI（容器网络接口）、CRI（容器运行时接口）、CSI（容器存储接口）等接口和 CRD（用户自定义资源）等，便于实现功能的扩展。下图是 Kubernetes 的逻辑架构图。3图 3：Kubernetes 逻辑架构图OpenStack 的设计比较全面，组件众多，部署相对复杂，难于运维，使用成本较高，更适合作为大规模云的管理系统。相对而言，Kubernetes 的设计更加简洁，其核心组件少，便于运维，同时 K8s 的生态很庞大，可以很方便地对其进行扩展或者定制，更适用于资源受限的边缘环境。1.3融合管理的演进：K8s 环境下运行虚拟机当前，通过容器部署的应用越来越广泛。但是，通过虚拟机部署的应用也会存在相当长的时间。首先，有不少现存的应用程序是运行在虚拟机上的，其中一些程序无法轻松地进行容器化重构。其次，即便对程序进行容器化改造，之后的系统调试和问题定位又会带来很大的挑战，尤其是对于通信行业来说，多代通信设备并存，对设备和应用程序的稳定性要求又非常高，对原有的应用程序进行容器化改造的成本和风险都是较大的。最后，一些应用或者场景更加适合使用虚拟机来进行部署。比如下面这些场景更适合使用虚拟机来运行而不是容器：*NFV（network function virtualization）网络功能虚拟化的场景：将传统的网元虚拟化，使用虚拟机会比使用容器更方便，因为容器在接入多网卡方面比起虚拟机的能力来说还有一定的差距；*大模型的研发测试：大模型在研发测试阶段进场需要使用多张GPU协同配合，同时要安装很多多软件依赖包来进行调试和使用，这时直接将多张GPU挂载到一个虚拟机里，然后在虚拟机里来实验开发要比在容器里方便很多；*数据库：不是所有的数据库都适合放在容器里运行，比如部分数据库的特定算法需要限制IP的变化，在虚拟机里部署可以有一个固定的IP，会更加方便；4*很多进程的应用：在容器使用上，有个核心概念就是部署任务单一的进程，比如一个简单的api服务进程加一个日志收集的进程组合成为了一个容器，有些多进程的应用就不适合放在容器中运行了。于是，随着时间推移，企业会遇到这样的情况，有些应用还是只能运行在虚拟机上，有些应用已经完成了容器化，企业管理员不得不同时运维管理多套平台，这大大增加了运维的难度：*计算资源：从管理角度来说计算资源的管理不同的平台的管理方法也是截然不同的，比如OpenStack是通过project quota来管理，而K8s则通过request/limit来管理，管理人员必须完全了解2套机制才能完全很好的管理起来；*网络资源：同样，对于网络管理来说，不同的平台也是完全不同的，K8s使用CNI来管理网络，同时OpenStack通过neutron来管理网络，他们的使用理念上也是截然不同的，这样很大程度上增加了学习成本；*监控/日志：各种平台都有自己的完整的监控/日志收集系统，它们会占用大量的计算、存储和网络资源，同时部署这样2套平台，从资源使用的角度上来说也是一种很大的浪费；*存储资源：相同的存储资源对接K8s和OpenStack方式都是截然不同的，出现问题后找根因的思路和角度也都是不一样的，这样也大大加大了运维的成本和难度。*安全风险：软件是由不同工程师编写的代码，运行在不同的操作系统上，每个环境都会遇到安全漏洞，越多组件则面临更多的安全漏洞，同时运维2套平台就意味着面临安全漏洞也会更多，企业面临的安全风险也就更大。从各个方面来看，企业内部的虚拟机平台和容器平台合并成为同一套平台来进行管理是一个趋势。那么是将K8s合并到OpenStack呢？还是反过来呢？业内也在研究虚拟机和容器的共平台的部署和管理，从OpenStack和K8s各自的发展来看，两个平台也在进行虚拟机和容器共同管理的探索，比如OpenStack的zun服务将容器作为一种OpenStack资源来进行管理，并通过集成OpenStack的其他服务，为用户呈现统一的、简化的API接口，用户可以通过这些接口来创建、管理容器；K8s也有多个相关的开源项目在研究如何实现对虚拟机的管理（见下文）。从云技术的现状和发展来看，容器的应用越来越广泛，而且K8s在容器编排领域成为了业内事实上的标准。在边缘环境下，K8s的适用范围也更加广泛，因此，本文将进一步探讨在K8s环境下运行虚拟机的技术和实践范例。1.4开源项目简介本节介绍在K8s环境下运行虚拟机的相关开源项目。当前这些项目还在发展之中，功能还在不断地迭代和完善。1.4.1KubeVirtKubeVirt4是一个K8s插件，由Redhat开源，云原生计算基金会（CNCF）赞助的开源项目。KubeVirt插件可以在K8s平台上调度传统的虚拟机。KubeVirt使用自定义资源（CRD）将VM管理接口接入到K8s中，通过一个Pod去使用libvirtd管理VM的方式，实现Pod与VM的一一对应，做到如同容器一般去管理虚拟机，并且做到与容器一样的资源管理、调度规划。KubeVirt的架构图如下。5图4：KubeVirt架构图KubeVirt主要由下列五个部分组成：virt-api：kubevirt是以CRD形式去管理VM Pod，virt-api就是所有虚拟化操作的入口，这里面包括常规的CDR更新验证、以及console、vm start、stop等操作。virt-controller：virt-controller会根据VMI CRD，生成对应的virt-launcher Pod，并且维护CRD的状态。与K8s的api-server通讯监控VMI资源的创建删除等状态。virt-handler：virt-handler会以deamonset形式部署在每一个节点上，负责监控节点上的每个虚拟机实例状态变化，一旦检测到状态的变化，会进行响应并且确保相应的操作能够达到所需（理想）的状态。virt-handler还会保持集群级别VMI Spec与相应libvirt域之间的同步；报告libvirt域状态和集群Spec的变化；调用以节点为中心的插件以满足VMI Spec定义的网络和存储要求。virt-launcher：每个virt-launcher Pod对应着一个VMI，kubelet只负责virt-launcher Pod运行状态，不会去关心VMI创建情况。virt-handler会根据CRD参数配置去通知virt-launcher去使用本地的libvirtd实例来启动VMI，随着Pod的生命周期结束，virt-lanuncher也会去通知VMI去执行终止操作；其次在每个virt-launcher Pod中还对应着一个libvirtd，virt-launcher通过libvirtd去管理VM的生命周期，不再是以前的虚拟机架构那样一个libvirtd去管理多个VM。virtctl：virtctl是kubevirt自带类似kubectl的命令行工具，它是越过virt-launcher Pod这一层去直接管理VM虚拟机，可以控制VM的start、stop、restart。KubeVirt利用CRD的功能定义了若干种资源对象。VirtualMachineInstance（VMI）：类似于 Kubernetes Pod，是管理虚拟机的最小资源。一个VirtualMachineInstance 对象即表示一台正在运行的虚拟机实例，包含一个虚拟机所需要的各种配置。VirtualMachine（VM）：为群集内的 VirtualMachineInstance 提供管理功能，例如开机/关机/重启虚拟机，确保虚拟机实例的启动状态，与虚拟机实例是 1:1 的关系，类似与 spec.replica 为 1 的StatefulSet。VirtualMachineInstanceMigrations：提供虚拟机迁移的能力，虽然并不会指定具体迁移的目的节点，但要求提供的存储支持 RWX 读写模式。VirtualMachineInstanceReplicaSet：类似ReplicaSet，可以启动指定数量的 VirtualMachineInstance，并且保证指定数量的 VirtualMachineInstance 运行，可以配置 HPA。KubeVirt虚拟机生命周期管理主要分为以下几种状态：61.虚拟机创建：创建VM对象，并同步创建DataVolume/PVC，从Harbor镜像仓库中拉取系统模板镜像拷贝至目标调度主机，通过调度、IP分配后生成VMI以及管理VM的Launcher Pod从而启动供业务使用的VM。2.虚拟机运行：运行状态下的VM可以进行控制台管理、快照备份/恢复、热迁移、磁盘热挂载/热删除等操作，此外还可以进行重启、下电操作，提高VM安全的同时解决业务存储空间需求和主机异常Hung等问题。3.虚拟机关机：关机状态下的VM可以进行快照备份/恢复、冷迁移、CPU/MEM规格变更、重命名以及磁盘挂载等操作，同时可通过重新启动进入运行状态，也可删除进行资源回收。4.虚拟机删除：对虚机资源进行回收，但VM所属的磁盘数据仍将保留、具备恢复条件。1.4.2Kata ContainerKata Container5社区由 OpenStack Foundation（OSF）领导，Kata Container 是一个开放源代码的容器，运行时可以构建无缝插入容器生态系统的轻量级虚拟机，通过轻量级虚拟机来构建安全的容器，这些虚拟机的运行方式和性能类似于容器，但是使用硬件虚拟化技术作为第二程防御层，可以提供更强的工作负载隔离。相较于普通的容器技术，Kata Container 的优点如下：安全：在专用的内核中运行，提供网络，I/O 和内存的隔离，并可以通过虚拟化扩展利用硬件强制隔离。兼容性：支持行业标准，包括开放容器格式、Kubernetes CRI 等。性能：提供与标准 Liunx 容器一致的性能。简单：易于集成和使用。图5：Kata Container架构图Kata Container主要由由如下几部分组成：kata-agent：在虚拟机内kata-agent作为一个daemon进程运行，并拉起一个或多个容器的进程。kata-agent使用VIRTIO或VSOCK接口（QEMU在主机上暴露的socket文件）在guest虚拟机中运行gRPC服务器。kata-runtime通过grpc协议与kata-agent通信，向kata-agent发送管理容器的命令。该协议还用于容器和管理引擎（例如Docker Engine）之间传送I/O流（stdout，stderr，stdin）。容器内所有的执行命令和相关的IO流都需要通过QEMU在宿主机暴露的virtio-serial或vsock接口，当使用VIRTIO的情况下，每个虚拟机会创建一个Kata Containers proxy(kata-proxy)来处理命令和IO流。7kata-runtime：Kata Containers runtime(kata-runtime)通过QEMU/KVM技术创建了一种轻量型的虚拟机，兼容 OCI runtime specification 标准，支持Kubernetes的Container Runtime Interface(CRI)接口，可替换CRIshim runtime(runc)通过K8s来创建Pod或容器。kata-proxy：kata-proxy提供了 kata-shim 和 kata-runtime 与VM中的kata-agent通信的方式，其中通信方式是使用virtio-serial或vsock，默认是使用virtio-serial。Shim：kata-shim类似Docker的 containerd-shim 或CRI-O的 conmon，主要用来监控和回收容器的进程，kata-shim需要处理所有的容器的IO流（stdout,stdin and stderr）和转发相关信号。当前Kata Container发展到了Kata Shim V2（containerd-shim-kata-v2）版本，实现了Containerd Runtime V2(Shim API)，集成了kata-runtime、kata-shim、kata-proxy的功能，所以架构图中不再包含这几部分。其演进方式如下图所示。图6：Kata Shim V2演进图Hypervisor：kata-container通过QEMU/KVM来创建虚拟机给容器运行，可以支持多种hypervisors。1.4.3Kube-OVNKube-OVN6是一款CNCF旗下的企业级云原生网络编排系统，将SDN的能力和云原生结合，提供丰富的功能，极致的性能以及良好的可运维性。Kube-OVN可提供跨云网络管理、传统网络架构与基础设施的互联互通、边缘集群落地等复杂应用场景的能力支持，解除Kubernetes网络面临的性能和安全监控的掣肘，为基于Kubernetes架构原生设计的系统提供成熟的网络底座，提升用户对Kubernetes生态Runtime的稳定性和易用性。Kube-OVN的设计原则和思路是，平移OpenStack网络的概念和功能到Kubernetes。OpenStack的网络已经发展了很多年，很多设计和概念也基本成了SDN的标准。Kube-OVN通过引入高级功能和成熟的网络概念，从整体上增强Kubernetes网络的能力，并通过OVN实现网络的数据平面，简化维护工作。Kube-OVN 的组件可以大致分为三类：上游OVN/OVS组件。核心控制器和Agent。监控，运维工具和扩展组件。8图7：Kube-OVN架构图上游上游OVN/OVSOVN/OVS组件组件该类型组件来自OVN/OVS社区，并针对Kube-OVN的使用场景做了特定修改。OVN/OVS本身是一套成熟的管理虚机和容器的SDN系统。Kube-OVN使用OVN的北向接口创建和调整虚拟网络，并将其中的网络概念映射到Kubernetes之内。ovn-central：Deployment运行OVN的管理平面组件，包括ovn-nb、ovn-sb和ovn-northd。多个ovn-central实例通过Raft协议同步数据保证高可用。ovn-nb：保存虚拟网络配置，并提供 API 进行虚拟网络管理。kube-ovn-controller 将会主要和ovn-nb 进行交互配置虚拟网络。ovn-sb：保存从 ovn-nb 的逻辑网络生成的逻辑流表，以及各个节点的实际物理网络状态。ovn-northd：将 ovn-nb 的虚拟网络翻译成 ovn-sb 中的逻辑流表。ovs-ovn：ovs-ovn以DaemonSet形式运行在每个节点，在Pod内运行了openvswitch、ovsdb和ovn-controller。这些组件作为ovn-central的Agent将逻辑流表翻译成真实的网络配置。核心控制器和核心控制器和 AgentAgent该部分为Kube-OVN的核心组件，作为OVN和Kubernetes之间的一个桥梁，将两个系统打通并将网络概念进行相互转换。kube-ovn-controller：该组件为一个Deployment执行所有Kubernetes内资源到OVN资源的翻译工作，其作用相当于整个Kube-OVN系统的控制平面。kube-ovn-controller监听了所有和网络功能相关资源的事件，并根据资源变化情况更新OVN内的逻辑网络。主要监听的资源包括：Pod、Service、Endpoint、Node、NetworkPolicy、VPC、Subnet、Vlan、ProviderNetwork。kube-ovn-cni：该组件为一个DaemonSet运行在每个节点上，实现CNI接口，并操作本地的OVS配置单机网络。kube-ovn-cni会配置具体的网络来执行相应流量操作。监控，运维工具和扩展组件监控，运维工具和扩展组件该部分组件主要提供监控，诊断，运维操作以及和外部进行对接，对Kube-OVN的核心网络能力进行扩展，并简化日常运维操作。kube-ovn-speaker：该组件为一个DaemonSet运行在特定标签的节点上，对外发布容器网络的路由，使得外部可以直接通过Pod IP访问容器。9kube-ovn-pinger：该组件为一个DaemonSet运行在每个节点上收集OVS运行信息，节点网络质量，网络延迟等信息，收集的监控指标可参考Kube-OVN监控指标。kube-ovn-monitor：该组件为一个Deployment收集OVN的运行信息，收集的监控指标可参考Kube-OVN监控指标。kubectl-ko：该组件为kubectl插件，可以快速运行常见运维操作。2技术实践本章通过一些典型地范例介绍对于在K8s环境下运行虚拟机的功能增强的技术实践。2.1生命周期管理2.1.1在 K8s 环境下实现虚拟机热调整资源在K8s中启动的虚拟机都是在一个Pod里面运行着libvirtd和qemu等依赖组件，这样kube-scheduler不需要感知Pod里是一个虚拟机还是一个容器，都按照统一的方式进行管理。既然虚拟机运行在了K8s平台上，那么我们管理虚拟有可以通过kubectl进行管理。创建虚拟机创建虚拟机通过kubectl create-f vm1.yaml直接通过一个yaml文件来创建一个虚拟机。更新虚拟机更新虚拟机通过kubectl edit vm-n namespace1即会打开一个vim编辑器，让用户直接可以修改虚拟机的yaml文件。删除虚拟机删除虚拟机通过kubectl delete vmvm1-n namespace1来删除在namespace1下的一个虚拟机vm1。虚拟机热调整资源虚拟机热调整资源由于K8s最近的版本已经支持Pod原地扩容了，可以利用了这个功能，实现kubevirt的虚拟机的cpu和memory热添加的功能，社区目前只支持cpu的热插。*社区的热扩容的实现：社区目前之实现了通过了live migration（热迁移）功能来实现的，这样的实现依赖虚拟机是否可以进行热迁移，比如虚拟机如果有gpu挂载的话，就不能实现热迁移，也就不能热扩容。10图8：社区版热扩容*改进的实现：首先使用了1.27.x版本的特性Pod原地扩容的特性(Pod in-place VPA)先将外部的virt-launcher Pod的limit调整到期望的大小，然后再调用libvirt api去扩容虚拟机到期望的大小。图9：改进版虚拟机热扩容2.2镜像管理2.2.1从 Harbor 镜像仓库拉取镜像在容器云平台启动虚拟机，那么虚拟机镜像最好是能和容器镜像一起管理，避免增加不必要的管理成本，所以可以将制作好的虚拟机镜像伪装成为了一个容器镜像存放在Harbor中，这样就不用单独管理虚拟机的镜像了。Harbor7是由VMware公司开源的企业级的Docker Registry管理项目，它包括权限管理(RBAC)、LDAP、日志审核、管理界面、自我注册、镜像复制和中文支持等功能。Harbor镜像仓库地址为：harbor.mec.local，首先通过kubectl命令进行配置：#kubectl get cm-n mec-images hci-controller-config-o yaml#kubectl edit cm-n mec-images hci-controller-config-o yamlapiVersion:v1data:config.yaml:|healthzPort:8080resyncPeriod:10mleaderElection:leaderElect:trueleaseDuration:30srenewDeadline:15sresyncPeriod:5s11resourceName:hci-controllerresourceLock:endpointsleasesresourceNamespace:mec-imagescontrollerConfig:baseImageNamespace:mec-imagessnapshotClass:csi-rbdplugin-snapclass#name of VolumeSnapshotClassglanceBaseURL:https:/172.18.22.100:9292registryAddr:registryAddr:harbor.mec.localharbor.mec.localkind:ConfigMapmetadata:annotations:kubectl.kubernetes.io/last-applied-configuration:|apiVersion:v1,data:config.yaml:healthzPort:8080nresyncPeriod:creationTimestamp:2022-07-06T14:44:34Zname:hci-controller-confignamespace:mec-imagesresourceVersion:18229389uid:3de8bcfc-f87d-4be5-9c85-d84198866133在Harbor仓库中的镜像有 kubevirt/fedora36，创建EVM时采用该镜像：#kubectl create-f evm-registry-fedora.yaml#cat evm-registry-fedora.yamlapiVersion:mececs.io/v1beta1kind:EnhancedVirtualMachinemetadata:name:ecs-registry-fedoranamespace:wq-testspec:template:spec:running:truetemplate:metadata:labels:kubevirt.io/vm:ecs-registry-fedoraannotations:ovn.kubernetes.io/allow_live_migration:trueKcf.io/networks:mec-nets/attachnet1attachnet1.mec-nets.ovn.kubernetes.io/logical_switch:subnet-ipv4attachnet1.mec-nets.ovn.kubernetes.io/default_route:trueattachnet1.mec-nets.ovn.kubernetes.io/allow_live_migration:truespec:domain:cpu:sockets:4cores:1threads:112memory:guest:8192Miclock:timezone:Asia/Shanghaitimer:rtc:present:truedevices:disks:-disk:bus:virtioname:cloudinitdiskinterfaces:-bridge:name:attachnet1resources:requests:cpu:2memory:2048MidnsPolicy:NonednsConfig:nameservers:-114.114.114.114options:-name:ndotsvalue:5hostname:ecs-registry-fedoranetworks:-name:attachnet1multus:networkName:mec-nets/attachnet1volumes:-name:cloudinitdiskcloudInitNoCloud:userData:|-#cloud-configpassword:fedorassh_pwauth:Truechpasswd:expire:False source:registryImageURL:registryImageURL:kubevirt/fedora36:latestkubevirt/fedora36:latestbootVolume:resources:requests:storage:10Gi创建成功，EVM可正常访问。#kubectl get evm ecs-registry-fedora-n wq-test13NAMEAGEecs-registry-fedora 3h1m#kubectl get vm ecs-registry-fedora-n wq-testNAMEAGESTATUSREADYecs-registry-fedora 3h1m Running True#kubectl get vmi ecs-registry-fedora-n wq-testNAMEAGEPHASEIPNODENAME READYecs-registry-fedora 3h1m Running 192.168.100.26 ecs8True2.3存储管理2.3.1Kata Container 使用卷的存储直通模式本项优化是为了提高使用Kata作为容器运行时提高Ceph rbd作为磁盘时的IO性能。原有挂载是储存卷（RBD image）挂载到宿主机的目录中，然后通过virtio-fs协议，将存储卷的内容共享到Kata Container中。如下图所示：可以添加卷直通功能，分为半直通（块直通）和全直通（rbd 直通）两个模式。其中半直通如下图所示，去掉了中间的协议virtio-fs，将映射到宿主机上面的块设备通过qmp命令直接添加到了Kata Container中，Kata Container再通过mount块设备进内容的读写。全直通如下图所示，进步的去掉了挂载到宿主机上面的动作，将rbd image直接通过qmp指令作为块设备添加到了Kata Container中，Kata Container再通过mount块设备进内容的读写。14卷 直 通 功 能 是 否 开 启 通 过 PVC 的 annotations 进 控 制。在 PVC 的 annotations 中 添 加 了volume.katacontainers.io/direct-mode字段。1.当volume.katacontainers.io/direct-mode值为“block”时，为半直通模式；2.当volume.katacontainers.io/direct-mode值为“rbd”时，为全直通模式；3.在字段的值不为上述两个或者不添加该字段时为原有模式。直通模式，通过kubectl exec-it centos-blk-test-bash进到对应容器后可以看到对应的块设备且对应的Filesystem不为 none：rootdeployer simple-test#kubectl exec-it centos-blk-test-bashrootcentos-blk-test/#df-hFilesystem Size Used Avail Use%Mounted on/dev/sdb 4.9G 265M 4.4G 6%/tmpfs 64M 0 64M 0%/devtmpfs 998M 0 998M 0%/sys/fs/cgroup/dev/sdc/dev/sdc 2.0G2.0G 6.0M6.0M 1.9G1.9G 1%1%/data-rbd/data-rbd/dev/sdd/dev/sdd 2.0G2.0G 6.0M6.0M 1.9G1.9G 1%1%/data-block/data-blockshm 998M 0 998M 0%/dev/shmrootcentos-blk-test/#lsblkNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTsda 8:0 0 5G 0 disksdb 8:16 0 5G 0 disk/sdcsdc 8:328:32 0 0 2G2G 0 0 diskdisk/data-rbd/data-rbdsddsdd 8:488:48 0 0 2G2G 0 0 diskdisk/data-block/data-blockpmem0 259:0 0 382M 1 disk-pmem0p1 259:1 0 380M 1 part半直通模式，创建Pod之前通过lsblk查看host的块设备信息，如果为半直通则创建完Pod之后host会多出来个rbd的块设备roothost1#lsblkNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTsr0 11:0 1 486K 0 romrbd1rbd1 251:16251:16 0 0 2G2G 0 0 diskdiskvda 252:0 0 50G 0 diskvda1 252:1 0 50G 0 part/152.3.2Kata Container 和 OpenEBS 适配优化本项优化是为了提高使用Kata作为容器运行时提高OpenEBS作为磁盘时的IO性能。OpenEBS8是一种开源云原生存储解决方案，托管于CNCF基金会。OpenEBS是K8s本地超融合存储解决方案，它管理节点可用的本地存储，并为有状态工作负载提供本地或高可用的分布式持久卷。OpenEBS支持两大类卷，本地卷和复制卷。管理员和开发人员可以使用kubectl、Helm、Prometheus、Grafana、Weave Scope等K8s可用的工具来交互和管理OpenEBS。为了实现Kata Container使用OpenEBS的本地卷直通方式，修改OpenEBS的lvm-localpv直通的实现。OpenEBS的CSI nodeDriver主要功能包括挂载、卸载、扩容和状态获取四项：1.NodePublishVolume：格式化块设备并将块设备挂载到targetPath。2.NodeUnPublishVolume：将块设备从targetPath卸载。3.NodeExpandVolume：对volume进行扩容。4.NodeGetVolumeStats：获取卷的使用情况。修改方案依赖PVC annotations实现是否为直通卷的判断，在CSI中针对上述四项功能分别对 kata进适配：1.NodePublishVolume：a.通过annotations判断是否为直通卷；b.通过targetPath目录下的文件判断该直通卷是否已经挂载，已经挂载则直接重新调用kata-runtime direct-volume add 即可（重启后kata-runtime add创建的文件会消失）；c.如果未挂载则先对块设备进格式化（OpenEBS通过调用K8s的库实现格式化并挂载）；d.格式化完成后调用kata-runtime direct-volume add命令；e.在targetPath创建个文件用于判断是否为直通卷（因为annotations只会在stageVolume、publishVolume阶段可以获取到，其他阶段无法获取），并在文件中写挂载状态；2.NodeUnPublishVolume：a.通过targetPath目录下的文件判断是否为直通卷；b.如果为直通卷则调用kata-runtime direct-volume delete命令进删除；3.NodeExpandVolume：a.通过targetPath目录下的文件判断是否为直通卷；b.如果为直通卷则在使用lvextend对文件系统进扩容；c.待块设备扩容完成后调用kata-runtime direct-volume resize命令调整大小；4.NodeGetVolumeStats：a.通过targetPath目录下的文件判断是否为直通卷；b.如果为直通卷则调用kata-runtime direct-volume stats命令获取volume状态。2.4网络能力2.4.1DPDK 加速的 OVSDPDK是X86平台报文快速处理的库和驱动的集合，不是网络协议栈，不提供二层，三层转发功能，不具备防墙ACL功能，但通过DPDK可以轻松的开发出上述功能。DPDK的优势在于，可以将用户态的数据，不经过内核直接转发到网卡，实现加速目的。DPDK加速的OVS与原始OVS的区别在于，从OVS连接的某个网络端口接收到的报文不需要openvswitch.ko内核态的处理，报文通过DPDK PMD驱动直接到达用户态ovs-vswitchd里。社区方案里，虚拟机/容器不能利用DPDK技术来提高网络的流量，本节描述的解决方案中加入使用DPDK技术来让虚拟机网络包可以直接通过user space来交互通讯，大大提高的了可以处理的网络流量。16图10：DPDK加速的OVSDPDK加速的OVS数据流转发的大致流程如下：1.OVS的ovs-vswitchd接收到从OVS连接的某个网络端口发来的数据包，从数据包中提取源/目的IP、源/目的MAC、端口等信息。2.OVS在用户态查看精确流表和模糊流表，如果命中，则直接转发。3.如果不命中，在SDN控制器接的情况下，经过OpenFlow协议，通告给控制器，由控制器处理。4.控制器下发新的流表，该数据包重新发起选路、匹配和报文转发。总结：主要区别在于流表的处理，普通OVS流表转发在内核态，而OVS-DPDK流表转发在用户态。查看Pod,vmi可正常启动：#kubectl get PodNAME READY STATUS RESTARTS AGEvirt-launcher-vm-dpdk-6nrqt 2/2 Running 0 3m13s#kubectl get vmi-ANAMEAGEPHASEIPNODENAME READYvm-dpdk3m9s Running 172.18.22.173node173True查看OVS-DPDK创建了vmi对应的vhostuserclient port（ede503e0_net2_h）：#kubectl ko vsctl node173 show340aee64-1e86-486a-a99e-a62481e9d67aBridge br-intfail_mode:securedatapath_type:netdevPort 1e9da8d5d0d7_hInterface 1e9da8d5d0d7_hPort ovn0Interface ovn0type:internalPort 43d5339cda9a_hInterface 43d5339cda9a_h17Port 99e85593750e_hInterface 99e85593750e_hPort d6653a5bbdc2_hInterface d6653a5bbdc2_hPort ede503e0_net2_hInterfaceInterface ede503e0_net2_hede503e0_net2_htype:type:dpdkvhostuserclientdpdkvhostuserclientoptions:vhost-serverpath=/var/run/openvswitch/vhost_sockets/578dd327-f9ba-4a1b-8bd3-1a55351e07ab/vhostuser-sockets/net22.4.2Kata Container 使用 SR-IOV 设备并运行 DPDK 应用Kata Container默认采用QEMU作为hypervisor，而QEMU不支持veth，所以一般默认方案是采用TAP来为VM内外打通网络。本节展示在K8s环境下Kata Container使用Mellanox的设备并运行DPDK应用的能力。本项优化同样是为了提高网络流量，同DPDK技术一样，SRIOV（single root IO virtualization)技术同样也为了提高虚拟机/容器的网络性能，SRIOV技术可以将一张物理网卡变为若干个虚拟的物理网卡，并直接接入虚拟机/容器从而提高网络性能。内核编译内核编译通常linux启动时先加载kernel，再加载initrd.img，initrd.img通常被用来加载驱动模块。但是在KataContainer中，不能通过启动时加载驱动模块，所以需要在编译kernel时将需要的驱动模块通过配置编译到内核文件中。Kata提供编译脚本和内核配置模板，可以修改配置文件或者通过make menuconfig命令启动图形界面进修改。因为模块间的依赖和互斥关系相当复杂，建议通过make menuconfig启动图形界面来开启下列模块：CONFIG_DCB networking options-Data Center Bridging support CONFIG_INFINIBAND device Drivers-InfiniBand support CONFIG_DYNAMIC_MEMORY_LAYOUT Processor type and featres-Randomize the kernelmemory sections CONFIG_COMPAT Binary Emulations-IA32 Emulation CONFIG_NUMA Processor type and features-NUMA Memory Allocation and SchedulerSupport CONFIG_PAGE_POOL General setup-Page allocator randomization CONFIG_MODULES enable_loadable module support CONFIG_PCI device driver-Userspace I/O drivers CONFIG_MLX5 device driver-network device support-Ethernet driver support-Mellanox devicesKernel-headerKernel-header包制作包制作Mellanox驱动安装需要依赖kernel-header模块，所以需要提前准备和镜像制作系统相同内核的Kernel-header安装包。在第一步的内核文件夹使用下列命令可以生成.deb的包。$make deb-pkg编译编译MellanoxMellanox驱动驱动以Dockerfile为例，编辑镜像步骤如下：FROM*WORKDIR/18#加入Kernel-header模块包ADD*.deb./#安装Kernel-header模块包RUN dpkg-i*.deb#安装编译需要的软件和库RUN apt-get update&apt-get install-y gcc.#下载Mellanox驱动编译包ADD MLNX_OFED_LINUX-5.7-1.0.2.0-ubuntu20.04-x86_64./MLNX_OFED_LINUX-5.7-1.0.2.0-ubuntu20.04-x86_64#编译安装Mellanox驱动RUN./mlnxofedinstall-upstream-libs-dpdk#运行DPDK相关应用.之后就可以在Kata Container中使用SR-IOV设备和DPDK的应用了。2.4.3开启 IPv4v6 双栈功能开启双栈可以让K8s平台上的虚拟机/容器能够同时支持ipv4/ipv6（可选）双协议栈。虚拟机开启IPv4v6双栈需要K8s和Kube-ovn都开启双栈。K8sK8s启用双栈启用双栈要启用IPv4v6双协议栈，需要为集群的相关组件启用IPv6DualStack特性，并且设置双协议栈的集群网络分配。K8s采用kubeadm方式部署，需要修改相关组件的yaml文件。kube-apiserver：启用IPv4v6双栈特性。#vim/etc/kubernetes/manifests/kube-apiserver.yaml-feature-gates=IPv6DualStack=true-feature-gates=IPv6DualStack=true-service-cluster-ip-range=10.233.0.0/18,fd00:10:96:/112kube-controller-manager：启用IPv4v6双栈特性,并增加Pod/service IPv6 CIDR。#vim/etc/kubernetes/manifests/kube-controller-manager.yaml-feature-gates=IPv6DualStack=true-feature-gates=IPv6DualStack=true-service-cluster-ip-range=10.233.0.0/18,fd00:10:96:/112-cluster-cidr=10.244.0.0/16,fc00:/48-node-cidr-mask-size-ipv4=24-node-cidr-mask-size-ipv6=64Kubelet：启用IPv4v6双栈特性。#vim/etc/sysconfig/kubelet#vim/var/lib/kubelet/config.yamlKUBELET_EXTRA_ARGS=-feature-gates=IPv6DualStack=trueKUBELET_EXTRA_ARGS=-feature-gates=IPv6DualStack=truekube-proxy：启用IPv4v6双栈特性,并增加Pod IPv6 CIDR。#kubectl-n kube-system edit cm kube-proxydata:config.conf:|-.featureGates:IPv6DualStack:IPv6DualStack:truetrueclusterCIDR:10.244.0.0/16,fc00:/4819Kube-ovnKube-ovn启用双栈启用双栈在Kube-ovn的安装脚本中打开对IPv4v6双栈的支持。#vim install.shDUAL_STACK=$DUAL_STACK:-trueDUAL_STACK=$DUAL_STACK:-true开启双栈部署好Koube-ovn后，在配置网双栈时，需要设置网CIDR格式为cidr=,，CIDR顺序要求IPv4在前，IPv6在后。apiVersion:kubeovn.io/v1kind:Subnetmetadata:name:subnet1-bj1namespace:sgbjspec:vpc:vpc-bj1-sgprotocol:IPv4default:falsecidrBlock:cidrBlock:192.168.100.0/24,fd00:10:18:/64192.168.100.0/24,fd00:10:18:/64excludeIps:-192.168.100.1-fd00:10:18:1gateway:192.168.100.1,fd00:10:18:1gatewayNode:disableGatewayCheck:truegatewayType:distributednatOutgoing:trueprivate:false正常指定网启动Pod。#cat Pod.yamlapiVersion:v1kind:Podmetadata:name:Podnamespace:defaultannotations:ovn.kubernetes.io/logical_switch:ovn-defaultKcf.io/networks:mec-nets/attachnetsg,mec-nets/attachnet1sgattachnetsg.mec-nets.ovn.kubernetes.io/logical_switch:subnet1-bj1attachnet1sg.mec-nets.ovn.kubernetes.io/logical_switch:subnet2-bj1spec:containers:-name:spec-subnet4command:/bin/ash,-c,trap:TERM INT;sleep 36000&waitimage:rancher/curl.Pod可以正常获取IPv4和IPv6 地址，并且路由正常。#kubectl exec-it Pod-ip a.52:eth0if53:mtu 1400 qdisc noqueue state20UPlink/ether 00:00:00:5d:bd:30 brd ff:ff:ff:ff:ff:ffinet 10.16.0.28/16 brd 10.16.255.255 scope global eth0valid_lft forever preferred_lft foreverinet6 fd00:10:16:1c/64 scope globalvalid_lft forever preferred_lft foreverinet6 fe80:200:ff:fe5d:bd30/64 scope linkvalid_lft forever preferred_lft forever54:net1if55:mtu 1400 qdisc noqueue stateUPlink/ether 00:00:00:2f:af:e4 brd ff:ff:ff:ff:ff:ffinet 192.168.100.5/24 brd 192.168.100.255 scope global net1valid_lft forever preferred_lft foreverinet6 fd00:10:18:5/64 scope globalvalid_lft forever preferred_lft foreverinet6 fe80:200:ff:fe2f:afe4/64 scope linkvalid_lft forever preferred_lft forever56:net2if57:mtu 1400 qdisc noqueue stateUPlink/ether 00:00:00:09:8a:5d brd ff:ff:ff:ff:ff:ffinet 192.168.200.10/24 brd 192.168.200.255 scope global net2valid_lft forever preferred_lft foreverinet6 fd00:10:17:a/64 scope globalvalid_lft forever preferred_lft foreverinet6 fe80:200:ff:fe09:8a5d/64 scope linkvalid_lft forever preferred_lft forever.#kubectl exec-it Pod-ip-6 route showfd00:10:16:/64 dev eth0 metric 256fd00:10:17:/64 dev net2 metric 256fd00:10:18:/64 dev net1 metric 256.OVN逻辑网关和逻辑路由配置正常。#kubectl ko nbctl showswitch.port.addresses:00:00:00:E6:21:AE 192.168.100.3 fd00:10:18:3port.addresses:00:00:00:2F:AF:E4 192.168.100.5 fd00:10:18:5port.type:routerrouter-port:.#kubectl ko nbctl lr-route-list ovn-clusterIPv4 Routes10.16.0.4100.64.0.3 src-ip.21IPv6 Routesfd00:10:16:4fd00:100:64:3 src-ip.在宿主机上查看ovn0网络正常。#ip a.8:ovn0:mtu 1400 qdisc noqueue state UNKNOWN groupdefault qlen 1000link/ether 00:00:00:f0:ac:c6 brd ff:ff:ff:ff:ff:ffinet 100.64.0.2/16 brd 100.64.255.255 scope global ovn0valid_lft forever preferred_lft foreverinet6 fd00:100:64:2/64 scope globalvalid_lft forever preferred_lft foreverinet6 fe80:200:ff:fef0:acc6/64 scope linkvalid_lft forever preferred_lft forever.KataKata ContainerContainer使用使用IPv4v6IPv4v6双栈双栈ECI指定网启动Kata Container，可以正常获取双栈地址。#cat Pod10.yamlapiVersion:v1kind:Podmetadata:name:Pod10namespace:sgbjannotations:ovn.kubernetes.io/logical_switch:ovn-defaultKcf.io/networks:mec-nets/attachnetsg,mec-nets/attachnet1sgattachnetsg.mec-nets.ovn.kubernetes.io/logical_switch:subnet1-bj1attachnet1sg.mec-nets.ovn.kubernetes.io/logical_switch:subnet2-bj1spec:runtimeClassName:kata-qemunodeName:mastercontainers:-name:Pod7command:/bin/ash,-c,trap:TERM INT;sleep 36000&waitimage:rancher/curldnsPolicy:NonednsConfig:nameservers:.在Kata Container中查看本地网卡，可以正常获取IPv4和IPv6地址。#ip a.2:eth0:mtu 1400 qdisc fq state UP qlen 1000link/ether 00:00:00:75:b3:f2 brd ff:ff:ff:ff:ff:ffinet 10.16.0.4/16 brd 10.16.255.255 scope global eth0valid_lft forever preferred_lft forever22inet6 fd00:10:16:4/64 scope globalvalid_lft forever preferred_lft foreverinet6 fe80:200:ff:fe75:b3f2/64 scope linkvalid_lft forever preferred_lft forever3:net1:mtu 1400 qdisc fq state UP qlen 1000link/ether 00:00:00:a8:1a:bb brd ff:ff:ff:ff:ff:ffinet 192.168.100.2/24 brd 192.168.100.255 scope global net1valid_lft forever preferred_lft foreverinet6 fd00:10:18:2/64 scope globalvalid_lft forever preferred_lft foreverinet6 fe80:200:ff:fea8:1abb/64 scope linkvalid_lft forever preferred_lft forever4:net2:mtu 1400 qdisc fq state UP qlen 1000link/ether 00:00:00:c7:37:2e brd ff:ff:ff:ff:ff:ffinet 192.168.200.2/24 brd 192.168.200.255 scope global net2valid_lft forever preferred_lft foreverinet6 fd00:10:17:2/64 scope globalvalid_lft forever preferred_lft foreverinet6 fe80:200:ff:fec7:372e/64 scope linkvalid_lft forever preferred_lft forever.VMVM使用使用IPv4v6IPv4v6双栈双栈需要修改Kubevirt支持bridge类型IPv4v6双栈。#kubectl exec-it Pod10-n sgbj-shfedoravm1$ip a.2:eth0:mtu 1400 qdisc fq_codel state UP group defaultqlen 1000link/ether 00:00:00:72:cc:56 brd ff:ff:ff:ff:ff:ffaltname enp1s0inet 192.168.100.9/24 brd 192.168.100.255 scope global dynamic noprefixroute eth0valid_lft 86313494sec preferred_lft 86313494secinet6 fd00:10:18:9/128 scope global dynamic noprefixroutevalid_lft 86313495sec preferred_lft 86313495secinet6 fe80:200:ff:fe72:cc56/64 scope link noprefixroutevalid_lft forever preferred_lft forever3:eth1:mtu 1400 qdisc fq_codel state UP group defaultqlen 1000link/ether 00:00:00:86:e6:ba brd ff:ff:ff:ff:ff:ffaltname enp2s0inet 192.168.200.9/24 brd 192.168.200.255 scope global dynamic noprefixroute eth1valid_lft 86313494sec preferred_lft 86313494secinet6 fd00:10:17:9/128 scope global dynamic noprefixroutevalid_lft 86313495sec preferred_lft 86313495secinet6 fe80:200:ff:fe86:e6ba/64 scope link noprefixroutevalid_lft forever preferred_lft forever.23fedoravm1$ip-6 r:1 dev lo proto kernel metric 256 pref mediumfd00:10:17:9 dev eth1 proto kernel metric 101 pref mediumfd00:10:17:/64 dev eth1 proto ra metric 101 pref mediumfd00:10:17:/64 dev eth1 proto ra metric 101 pref mediumfd00:10:18:9 dev eth0 proto kernel metric 100 pref mediumfd00:10:18:/64 dev eth0 proto ra metric 100 pref mediumfe80:/64 dev eth0 proto kernel metric 100 pref mediumfe80:/64 dev eth1 proto kernel metric 101 pref mediumdefault via fe80:200:ff:fed6:6258 dev eth0 proto ra metric 100 pref mediumdefault via fe80:200:ff:fe2b:192d dev eth1 proto ra metric 101 pref medium2.4.4NicPort 网卡热插拔使用社区实现的虚拟机网卡热插拔的方式不符合用户的使用习惯，本节描述的方法可以给用户更好的界面体验。本节新开发了一个CRD叫做NicPort，该CRD的每个实列即代表了一个IP地址，可以将这个实列单独创建，然后由管理员决定将创建好的实列分配给需要的虚拟机，从而达到良好的用户体验。创建NicPort分为两种情况：创建NicPort时选择vm，则直接创建绑定；创建NicPort时不选择vm，只创建网卡。创建创建NicPortNicPort创建NicPort需要选择，可以通过kubectl get subnet查看信息和CIDR。创建时可以选择是否指定IP，指定IP时要满IP在所选的CIDR范围内，且不冲突。如果不指定IP，创建时会根据动分配。当前CNI类型只支持kube-ovn，network_type类型只支持bridge。查看子网：#kubectl get subnetNAMEPROVIDER VPCPROTOCOL CIDRPRIVATE NATDEFAULT GATEWAYTYPE V4USED V4AVAILABLE V6USED V6AVAILABLEEXCLUDEIPS.subnet1-bj1ovnvpc-bj1-sgIPv4192.168.100.0/24falsetrue falsedistributed 225100192.168.100.1式：使API登录到ecs1节点，例如创建NicPort时不绑定vm，选择subnet subnet1-bj1，IP为192.168.100.200，MAC为9e:13:e7:31:56:1d，示例如下：curl-v-XPOST-H Accept:application/json-H Content-Type:application/json https:/ecsvip.lab.ecs.io:6443/apis/ GET NicPort 中的法查看。如果创建NicPort时绑定vm，需要将curl data中的vmi字段选择指定的vmi。式：使 kubectl创建 nicport1.yaml，示例如下：apiVersion: apply-f nicport.yaml命令创建网卡。获取获取NicPortNicPort式：使API登录到ecs1节点，url的最后要指定NicPort的名字，可以返回NicPort的信息。curl-v-XGET-H Accept:application/json-H Content-Type:application/json https:/ecsvip.lab.ecs.io:6443/apis/ kubectl通过kubectl describe nicport 或者kubectl get nicport -oyaml查看NicPort信息。NicPort有多个状态。状态为 phase0.1表示创建了NicPort，正确分配 IP MAC，但未绑定虚拟机；状态为phase1表示绑定了虚拟机，示例如下：Spec:Cni:kube-ovnIp:192.168.100.200Mac:9e:13:e7:31:56:1dnetwork_type:bridgeSubnet:subnet1-bj1Vmi:Status:dhcp_advertising_ip:Stat:phase0.1/NicPort状态Events:列出列出NicPortNicPort25式：使 API登录到ecs1节点，使用下列命令，可以看到NicPort列表：curl-v-XGET-H Accept:application/json-H Content-Type:application/json https:/ecsvip.lab.ecs.io:6443/apis/ kubectl使用kubectl get nicports命令可以看到NicPort列表。更新更新NicPortNicPort可以更新NicPort的vmi字段，实现将网卡挂载到虚拟机上和从虚拟机卸载网卡：绑定到虚拟机时，设置vmi-target字段为非空；解绑时设置vmi-target字段为空（）。式：使 API挂载NicPort的示例如下：curl-v-XPATCH-H Accept:application/json-H Content-Type:application/merge-patch json https:/ecsvip.lab.ecs.io:6443/apis/ metadata:labels:vmi-target:testvmi-target:test,spec:vmi:test绑定后通过查看可以看到NicPort的状态变为phase1，且有networks字段。还可以查看vm的 annotations可以看到基于该networks字段的信息。需要注意，vm有关联的Pod存在，所以查看vm时需要查看该Pod，如通过kubectl describe Pod virt-launcher-testvm-lltgc可以看到如下信息：Annotations:attachnet10.mec-nets.ovn.kubernetes.io/allocated:trueattachnet10.mec-nets.ovn.kubernetes.io/cidr:192.168.100.0/24attachnet10.mec-nets.ovn.kubernetes.io/gateway:192.168.100.1attachnet10.mec-nets.ovn.kubernetes.io/ip_address:192.168.100.200attachnet10.mec-nets.ovn.kubernetes.io/logical_router:vpc-bj1-sgattachnet10.mec-nets.ovn.kubernetes.io/logical_switch:subnet1-bj1attachnet10.mec-nets.ovn.kubernetes.io/mac_address:9e:13:e7:31:56:1dattachnet10.mec-nets.ovn.kubernetes.io/Pod_nic_type:veth-pairattachnet10.mec-nets.ovn.kubernetes.io/routed:trueKcf.io/networks:interface:net1,name:attachnet1,namespace:mecnets,interface:,name:attachnet10,namespace:mec-nets卸载后NicPort的状态将改回phase0.1。卸载NicPort的示例如下：curl-v-XPATCH-H Accept:application/json-H Content-Type:application/merge-patch json https:/ecsvip.lab.ecs.io:6443/apis/ 26-data metadata:labels:vmi-target:vmi-target:,spec:vmi:test式：使 kubectl绑定和解绑NicPort可以使用Kubectl edit nicport 命令。绑定时，修改specvmi-target字段，添加虚拟机名称，为NicPort增加label，保存后即可。解绑时，修改specvmi-target字段，删除虚拟机名称，删除NicPort的label，保存后即可。检查点和式相同。删除删除NicPortNicPort删除前需要先从虚拟机卸载。卸载法更新NicPort。式：使 API挂载NicPort的示例如下：curl-v-XDELETE-H Accept:application/json-H Content-Type:application/json https:/ecsvip.lab.ecs.io:6443/apis/ kubectl通过创建NicPort时使用的yaml文件删除，使用Kubectl delete-f nicport1.yaml命令即可。2.4.5Macvtap 对接的实现本节描述的的 macvtap 网卡直通方案比社区原生 bridge 方案，网络吞吐性能可以提升约 50%。Kubevirt kube-OVN bridge方案网络连接如下图所示：图11：Kubevirt kube-OVN bridge方案网络连接1、Libvirt运行在virt-launcher Pod computer容器中；272、kube-OVN CNI创建veth pair对，一个veth设备挂接到OVS网桥上，另一个veth设备绑定到virt-launcher网络命名空间中；3、在computer容器中会创建linux网桥 k6t-net0，VM的tap设备挂接到网桥上，同时也将veth挂接到linux 网桥上，从而打通了VM到OVS网桥的数据通路。从架构图上可以清晰的看出，VM的流量到容器网络的链路较长，中间需要通过多次内核协议栈，性能有很大的不必要的损耗。为优化网络性能，可以使用macvtap网卡直通方案，即通过VM使用macvtap网卡，直接缩短VM到容器网络的数据链路，实现架构如下图所示：1、Libvirt运行在virt-launcher Pod computer容器中；2、kube-ovn CNI创建OVS internal-port，并以该internal-port创建macvtap网卡，将该macvtap绑定到virt-launcher网络命名空间中；3、在computer容器中直接只用该macvtap网卡启动VM，从而打通了VM到OVS网桥的数据通路。图11：macvtap网卡直通方案网络连接_281 AnupdatedperformancecomparisonofvirtualmachinesandLinuxcontainershttps:/ OpenStack:https:/www.OpenStack.org3 Kubernetes:https:/kubernetes.io4 Kubevirt:https:/kubevirt.io5 Kata Container:https:/katacontainers.io6 Kube-OVN:https:/www.kube-ovn.io7 Harbor:https:/goharbor.io8 OpenEbs:https:/openebs.io参参 考考 文文 献献

0人已浏览 2024-01-15 31页 5星级

大数据云原生技术发展研究报告大数据云原生技术发展研究报告（2023 年）年）先进计算产业发展联盟先进计算产业发展联盟2023 年年 12 月月I研 究 报 告 要 点研 究 报 告 要 点随着行业的快速发展，数据量也呈爆炸式增长，大数据已成为决策的基本工具，企业面临着数据管理和处理的巨大挑战。围绕 Hadoop的传统大数据架构在交付运维，资源利用率，系统迭代与兼容性，安全等方面存在诸多不足。随着以 Kubernetes 为代表的云原生概念的兴起，越来越多的企业投身于云原生转型的浪潮，以解决传统应用面临的弹性能力不足、资源利用率较低、迭代周期较长等问题。当前云原生的发展已比较成熟，成为数字化转型的重要支撑技术。大数据和云原生技术的融合，逐渐成为企业数字化转型的重要演进方向，目前还处于高速发展，百家争鸣的阶段，一些企业已经在大数据云原生之路上砥砺前行，而国内大部分企业依然处于观望状态。同时可以看到，业界在大数据与云原生结合的定义和方向上，有一些不同的声音，不同企业融合的方式也有所不同。大数据和云计算要不要融合？如何融合？都是人们所关心的话题。带着这个问题，我们希望基于之前积累的经验，结合工作中的痛点，调研并产出一份尽量中立、客观、完整的尽量中立、客观、完整的大数据云原生技术发展报告，希望能为相关企业、研发团队和需要大数据的客户提供参考。也希望能抛砖引玉，吸引更多企业专家的参与，引发后面更专业，更大范围有关大数据云原生技术的讨论，最终能促进一些共识，提升大II数据云原生的技术普惠，“旧时王谢堂前燕，飞入寻常百姓家”，为国家数字化转型，做一点贡献。本报告将从以下几个方向来阐述：1.大数据与云原生技术的发展与演进：大数据与云原生技术的发展与演进：介绍大数据技术的演进，云原生技术的发展，以及它们融合的情况。2.传统大数据平台的痛点：传统大数据平台的痛点：探讨传统大数据平台交付运维成本高、资源利用低效、迭代兼容性及安全性问题等关键痛点。3.云原生技术解决思路：云原生技术解决思路：详细说明云原生技术解决这些关键痛点的思路，以及云原生技术带来的其它好处和引入的新挑战。4.大数据云原生技术架构简述：大数据云原生技术架构简述：简述大数据云原生技术的设计思路和参考架构，包括弹性伸缩、资源隔离、容器化、统一资源调度、多计算引擎管理、统一数据湖管理以及智能化运维等方面。5.大数据云原生的未来发展和建议：大数据云原生的未来发展和建议：最后简单提出对大数据云原生技术未来发展和建议，以提升大数据云原生的技术普惠。由于时间仓促，水平所限，错误和不足之处在所难免，欢迎各位读者批评指正，意见及建议请发送至 。III研究单位：天翼云科技有限公司课题负责人：王小刚课题参加人：侯圣文，张桐，李冰，金喆，李启蒙，黄俊慧，李庆森完成日期：研究单位：天翼云科技有限公司课题负责人：王小刚课题参加人：侯圣文，张桐，李冰，金喆，李启蒙，黄俊慧，李庆森完成日期：2023 年年 12 月月IV目录目录一、大数据平台与云原生技术的发展与演进.1（一）数据平台的发展与演进.1（二）云原生技术简述.9（三）大数据与云原生结合分析.12二、传统大数据平台的需求与痛点.15（一）交付运维成本高.16（二）资源利用率低.17（三）系统迭代与兼容性挑战.18（四）安全相关挑战.19三、云原生技术解决大数据问题的思路.20（一）云原生技术提升运维交付质量与效率.20（二）云原生技术提升集群资源使用率和弹性.22（三）云原生技术提升大数据平台迭代效率.26（四）云原生技术提升大数据安全和隐私保护.27（五）云原生技术带来的其它好处.31（六）大数据云原生引入的新挑战.35四、大数据云原生技术的架构简述.40V（一）云原生大数据平台的架构原则.40（二）云原生大数据平台的参考架构.41五、大数据云原生的未来发展和战略建议.44（一）技术发展方向.44（二）针对行业的建议.44（三）针对企业和用户的建议.45六、参考文献.461一、大数据平台与云原生技术的发展与演进一、大数据平台与云原生技术的发展与演进（一）数据平台的发展与演进（一）数据平台的发展与演进需求催生技术革新，在海量数据需求的推动下，数据平台架构持续演进，经过数十年的发展，历经了数据库、数据仓库、数据湖、湖仓一体等概念。这里按出现顺序简述：（其中关于数据湖和湖仓一体目前业界有多种不同的定义，这里我们采用其中一种定义说明）来源：CCSA TC601 大数据技术标准推进委员会图 1：数据分析技术演进图数据库（数据库（Data Base）：）：自 1980 年代初至中期起，数据管理工具主要呈现为数据库形式，以面向事务交易的 OLTP 场景为主，数据分析功能则作为辅助。这些数据库主要用于向管理层提供固定报表，支持宏观管理决策。它们通过标准SQL提供数据分析能力，主要代表产品包括Oracle、Sql Server、Mysql 等。2图 2 早期数据库阶段系统架构数据仓库（数据仓库（Data Warehouse）：）：随着互联网的快速普及，门户、搜索引擎、百科等应用快速增长，数据量呈爆发式增长，原有的单个关系型数据库架构无法支撑庞大的数据量。20 世纪 90 年代数据仓库理论被提出，核心是基于 OLTP 系统的数据源，根据联机分析处理 OLAP 场景诉求，将数据经过数仓建模形成 ODS、DWD、DWS、DM 等不同数据层，每层都需要进行清洗、加工、整合等数据开发（ETL）工作，并最终加载到关系型数据库中。来源：云原生产业联盟3图 3：OLAP 系统建设数据仓库架构是为了解决单个关系型数据库架构无法支撑庞大数据量的数据存储分析问题。传统数据仓库多为 MPP(MassivelyParallel Processor)架构，代表产品有 Teradata、Greenplum 等，当前MPP 架构依然为新型数仓的重要选择，比如 ClickHouse，Doris，StarRocks 等。随着 Hadoop 技术的成熟与普及，基于 Hadoop 自建离线数据仓库(Hive)是常见的大数据平台之上数据仓库方案，在目前依然发挥着重要的作用。数据湖（数据湖（Data Lake）：）：随着移动互联网的飞速发展，半结构化、非结构化数据的存储、计算需求日益突出，对数据平台提出了新的要求。以开源 Hadoop 体系为代表的开放式 HDFS 存储(或 S3)、开放的文件格式、开放的元数据服务（Hive Metastore 等）以及多种引擎（Hive、Spark、Flink、Presto 等）协同工作的模式，形成了数据湖的雏形。4来源：云原生产业联盟图 4：Hadoop 生态系统重要组件2010 年，数据湖概念被提出，数据湖是一种支持结构化、半结构化、非结构化等数据类型大规模存储和计算的系统架构。数据湖与数据仓库的主要区别在于数据仓库中数据在进入仓库之前是需要实现归类，而数据湖是把大量原始数据通过廉价存储保存下来。数据湖架构的特点可总结为：低成本、原始数据、需灵活使用、面向任务数据绑定、不提前定义数据模型。5从解决场景的角度来看，数据仓库和数据湖各有其适合覆盖场景，基本上属于互补关系，前者更多是解决固定的、明确的数据问题；后者则为应对随机性、探索式的数据问题。下图是一个示意图。6来源：Gartner图 5：数据仓库和数据湖的场景湖仓一体（湖仓一体（LakeHouse）：）：为满足多种数据类型存储、多场景分析等业务诉求，企业的数据采用混合部署模式，其中数据湖和数据仓库通过 ETL 进行数据交换，数据湖和数据仓库是两套独立的体系。7来源：CCSA TC601图 6：湖 仓混合架构图“数据湖 数据仓库”混合架构满足了结构化、半结构化、非结构化数据高效处理需求，解决了传统数据仓库在海量数据下加载慢、数据查询效率低、难以融合多种异构数据源进行分析的问题，但混合架构是技术向业务妥协的一个产物，存在数据冗余，增加存储成本，两个系统间额外的 ETL 流程导致时效性差，数据一致性保障低，混合架构开发运维复杂等弊端。2020 年 Databricks 提出“湖仓一体”的概念，到目前技术和概念侧依然在持续演进。湖仓一体是指融合数据湖与数据仓库的优势，形成一体化、开放式数据处理平台的技术。通过湖仓一体技术，可使得数据处理平台底层支持多数据类型统一存储，实现数据在数据湖、数据仓库之间无缝调度和管理，并使得上层通过统一接口进行访问查询8和分析。总的来看，湖仓一体通过引入数据仓库治理能力，既可以很好解决数据湖建设带来的数据治理难问题，也能更好挖掘数据湖中的数据价值，将高效建仓和灵活建湖两大优势融合在一起，提升了数据管理效率和灵活性。湖仓一体目前没有统一的架构，在企业需求的驱动下，各开源技术和厂商基于原有架构演进，数据湖与数据仓库在原本的范式之上扩展。逐渐形成了“湖上建仓”与“仓外挂湖”两种湖仓一体实现路径。如图 7 和表 2 所示。湖上建仓和仓外挂湖虽然出发点不同，但最终湖仓一体的目标一致。9图 7：湖仓一体架构模块图（二）云原生技术简述（二）云原生技术简述云原生的发展简述：云原生的发展简述：云原生(Cloud Native)，最初由 Pivotal 公司的 Matt Stine 在 2013年提出，随后 Linux 基金会在 2015 年成立了云原生计算基金会(CNCF)。CNCF 不仅推广了云原生这一概念，还逐步构建了以云原生为核心的技术生态工具。到 2018 年，Kubernetes 成为 CNCF 的首个毕业项目。目前，Kubernetes 已经确立了在容器编排领域的领导地位，并推动了云原生技术的广泛应用。10来源：https:/cf.io/图 8：云原生 Landscape（景观）指南云原生的核心思想：云原生的核心思想：云原生普遍被认为包含四大核心要素：DevOps、微服务、持续交付和容器化。DevOps：DevOps 是开发(Development)和运维(Operations)的结合，它推动了开发和运维团队的紧密协作。在 DevOps 文化中，软件的开发、测试、部署和监控过程是连续的，不断循环，旨在加快软件交付速度并提高质量。11持续交付：持续交付：持续交付是一种软件工程方法，它允许软件在短时间内且持续地被交付到生产环境。它通过自动化开发、测试和部署流程来支持频繁的版本发布，旨在减少发布新功能和修复的时间。微服务：微服务：微服务架构是一种设计方法，将应用程序分解为一组较小、相互独立的服务，每个服务都围绕特定业务功能构建，并可独立部署。容器：容器：容器技术，如 Docker，提供了一种轻量级、可移植的方法来封装、部署和运行应用。Kubernetes(K8S)则发展为容器编排和管理的领导者，它提供了高级的部署、扩展和运行容器化应用的能力。CNCF 重新定义云原生：重新定义云原生：随着云原生生态的不断壮大，CNCF 基金会容纳的项目越来越多，到了 2018 年，原来的定义已经限制了云原生生态的发展，CNCF 为云原生进行了重新定义：“云原生技术有利于各组织在公有云公有云、私有云私有云和混合云混合云等新型动态环境中，构建和运行可弹性扩展可弹性扩展的应用。云原生的代表技术包括容器容器、服务网格服务网格、微服务微服务、不可变基础设施不可变基础设施和声明式声明式 API。这些技术能够构建容错性好容错性好、易于管理易于管理和便于观察便于观察的松耦合系统松耦合系统。结合可靠的自动化手段可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更频繁和可预测的重大变更。12云原生计算基金会(CNCF)致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。”新的定义继续保持原有的核心内容：容器和微服务，加入了服务网格、不可变基础设施和声明式 API 这三个重要设计指导理念，并且强调了公有云、私有云和混合云等新型动态环境。（三）大数据与云原生结合分析（三）大数据与云原生结合分析从 2018 年起，一些开源大数据引擎陆续开始了 on Kubernetes 的探索：2018 年 3 月，Spark v2.3.0 开始探索 on Kubernetes2018 年 6 月，KubernetesAirflow Operator 在正式发布2019 年 8 月，Starburst Presto 宣布持 K8S2020 年 2 月，Flink v1.10.0 发布 Native Kubernetes beta 版2020 年 2 月，Hive 探索 MR3 运在 Kubernetes 上而到了 2021 年 3 月，Apache Spark 3.1 正式支持了 kubernetes，越来越多的企业开始在生产环境使用大数据云原生融合的技术。根据 Pepperdata 关于“2022 BigData on Kubernetes Report”显示：13来源：Pepperdata 2022 BigData on Kubernetes Report图 9：大数据云原生融合情况与上云目的50% 的受访者正在将数据应用迁移至 Kubernetes 中，以降低整体成本。报告显示，迁移原因排名前四的是：1.超过 45%的受访者为了提高应用程序的性能和稳定性而选择将任务迁移至 Kubernetes。2.为任务负载具备更高的灵活性和可移植性。3.降低成本。4.多云解决方案避免被一个云厂商绑定。从任务分布上可以看出：占比最高的大数据作业依次是 Spark、Presto、Kafka、Trino、Flink，可以看到基本上涵盖了大数据领域的批处理、交互式分析和流处理场景。国内外云厂商也一直加大产品技术在云原生(Serverless)方向的投入和引导。亚马逊云科技在 2022 年 re:Invent 中宣布其大数据核心14产品已全面 Serverless 化，阿里云在 2023 年云栖大会上将 Serverless作为大会主题之一，包括大数据在内的多款云产品均发布了其Serverless 相关的产品能力。单纯从技术趋势的角度来看，无论是技术还是产品，大数据云原生化都是发展的必然趋势。与云原生融合的一些其它声音，也值得我们关注：与云原生融合的一些其它声音，也值得我们关注：值得一提的是，在数据库领域，对于“数据库是否应该放到 K8S”这个话题有一些讨论，虽然大数据有一些不同，但可以参考：反方认为：维持已经成熟和可靠的系统不需要维持已经成熟和可靠的系统不需要 K8S：认为将数据库放入 K8S 中会导致“双输”K8S 失去了无状态的简单性，不能像纯无状态使用方式那样灵活搬迁调度销毁重建；而数据库也牺牲了一系列重要的属性：可靠性，安全性，性能，以及复杂度成本，却只能换来有限的“弹性”与资源利用率，但虚拟机也可以做到这些。整体论点分为以下四点：1.增加复杂度和不可靠性增加复杂度和不可靠性：K8S 增加了额外的架构复杂度和潜在失效点。2.性能挑战性能挑战：在 K8S 上运行的数据库可能面临性能问题。3.安全和合规风险安全和合规风险：多租户环境和更多的组件依赖，增加数据库的安全威胁，使得审计和合规更加复杂。4.成本和维护问题成本和维护问题：尽管 K8S 在一定程度上简化了数据库管理，但可能无法抵消其自身引入的复杂度和维护成本。15正方认为，数据库数据库 on K8S，是专业能力的普及化：，是专业能力的普及化：这里的“专业能力”指的是高可用性、弹性伸缩、容错等能力，它们通常需要复杂的技术实现和专业知识。通过将数据库部署在K8S 上，这些能力可以通过 K8S 的自动化和标准化机制更容易地实现和普及，降低了对专业数据库管理技能的依赖。整体论点主要也是下面四点：1.资源弹性和伸缩性资源弹性和伸缩性：K8S 提供强大的资源弹性和伸缩性，适应业务需求的波动，在高峰期自动扩展资源，在低谷期收回，有效节约成本。2.容器技术的优势容器技术的优势：Docker 等容器技术提供了轻量级和标准化的部署方式。容器对数据库性能影响很小。3.K8S 的运维能力的运维能力：包括路由网关、水平扩展、监控、备份和灾难恢复等，这些能力有助于数据库的高可用性和持续运行。4.高可用性等解决方案高可用性等解决方案：固化高可用方案，提供主从秒级切换和数据一致性等特性。“它山之石，可以攻玉”，虽然数据库与数据平台在场景和技术架构上会有一些不同，但大数据云原生的融合在这个问题上依然值得借鉴思考。二、传统大数据平台的需求与痛点二、传统大数据平台的需求与痛点传统围绕 Hadoop 生态构建的大数据平台，存在着交付运维成本高、资源利用率低、系统迭代与兼容性挑战和安全相关挑战。用户期16望大数据云原生技术能够在这些方面为传统的大数据平台带来优化和改进。（一）交付运维成本高（一）交付运维成本高传统大数据平台的建设和维护目前是一个重要且复杂的任务。这些平台通常包括多种不同的组件，它们在技术栈、功能和架构上存在显著差异。这种多样性不仅使得平台的部署和配置变得极为复杂，也大幅增加了整体的运维成本。组件多样性导致较高的人力需求：组件多样性导致较高的人力需求：大数据平台包含多种组件，这些组件在技术栈（如 Java、C ）、功能（如流处理、批处理，OLAP）和架构（如 C/S、MPP）方面各不相同。部署，配置和维护如此多样的技术栈需要大量的专业人力，特别是在部署和交付新的大数据平台时，人力资源的需求和成本会显著增加。运维专业性与效率：运维专业性与效率：大数据组件的复杂性，具有较高的运维知识门槛。这不仅增加了运维团队的工作负担，还可能导致效率低下和更频繁的解决问题需求，从而增加成本。工具与管理挑战：工具与管理挑战：许多大数据组件缺乏开箱即用的日志、监控和告警功能，导致运维团队需要为每个组件单独开发和适配这些工具。17每个组件可能有各自的集群和管理界面，使得整个平台的统一管理和问题排查变得困难。这种分散性不仅降低了运维效率，还可能导致问题解决的延迟，增加了管理成本。云原生技术可以有效缓解传统大数据平台的运维挑战。容器化通过屏蔽不同组件间的技术栈和基础设施差异，简化了运维流程。工具如 Operator 实现了服务部署和运维的标准化与自动化，降低了复杂性和人力成本。在云原生架构下，应用和组件的更新仅需拉取新镜像并重启容器，确保环境一致性，加速应用发布。此外，云原生环境提供统一管理界面，集中处理不同服务的发布和运维，提高问题监测和定位的效率。集成在 Kubernetes Pods 和节点的监控与告警工具，使得运维团队可以通过统一界面清晰监控基础设施和服务状态，有效跟踪系统性能和健康状况。（二）资源利用率低（二）资源利用率低组件混部困难：组件混部困难：传统的大数据平台，为了避免组件间的相互影响，组件的集群往往是相互独立部署的。这样虽然对于整体的编排来说相对简单，但是会降低资源利用率。业务波动性：业务波动性：由于大数据业务的特点，大数据组件在高峰期的资源利用率可以很高，但是在业务低峰期则会有较多闲置，此时集群整体资源利用率可能只有 20%-30%，综合平均起来集群整体的资源利用率偏低。18弹性扩缩容难度高：弹性扩缩容难度高：在业务高峰期时，如果现有的资源已经无法支撑业务，这个时候可能需要通过较为繁琐的运维流程扩容节点。到了业务低谷期时，这部分机器又很难通过运维流程快速下线，扩缩容的效率不高。云原生领域在基础资源基础上抽象出了“资源池（计算、存储、网络等的组合）”的概念，资源池被所有的大数据组件公用，按需申请，可以避免重复规划造成的资源浪费。资源池可以承载不同类型的大数据集群，可以是批处理、也可以是流处理、MPP 等，得益于容器化较好的隔离性，不同的业务可以在一起混部，形成资源的分时复用；同时云原生领域有着丰富的工具来对资源池进行弹性扩缩容，甚至当业务不存在的时候降到零副本，做到随需启停，做到 Serverless化。（三）系统迭代与兼容性挑战（三）系统迭代与兼容性挑战传统的大数据平台，组件开发迭代不敏捷，周期长。组件版本往往比较固定，版本升级难度比较大。在部署新的大数据组件到现有的Hadoop 集群时。首先，必须确保这些新组件与现有的 HDFS 和 Yarn版本兼容。由于许多新的大数据组件不支持旧版本的 Hadoop，升级Hadoop 可能导致现有组件失效。其次，部署时还需考虑到不同 Linux操作系统间的兼容性问题，这增加了额外的复杂性。因此，整合一个新的计算和存储组件到现有架构中通常是一个耗时的过程，可能需要几天甚至几周的时间。19云原生的定义中先天具有 DevOps、CI/CD 的思想，可以比较容易地做到IaC(Infrastructure as Code)和CaaS(Configuration as a Service)。组件的配置或代码在 Git 中进行保管，一旦发生变化，就会经过 CI的环节进行质量验证，然后通过 CD 的管道打包成容器镜像发布到运行环境中。由于云原生中都是微服务架构，你可以只单独发布组件的一部分，不必整体组件一起发布；在组件的发布过程中，也可以更方便地实现 A/B Test、灰度发布、发布回滚等操作。同时云原生中都是容器，启停容器是轻量级动作，效率高。（四）安全相关挑战（四）安全相关挑战传统大数据平台，在安全方面面临着一系列挑战。包括数据隔离、综合访问控制、数据加密和保护、审计与合规性、网络安全、灾难恢复与数据备份等。针对这些挑战，大数据开源社区已经有一些解决方案，如使用 Kerberos 进行认证、Ranger 或 Sentry 进行访问控制等，但这些解决方案往往伴随着配置复杂、灵活性不足、自动化程度低等缺点。相比之下，云原生技术社区也提供了面对安全问题更全面、灵活且自动化的安全解决方案。可以做到更好的网络隔离，数据隔离，权限隔离，灾备等。20三、云原生技术解决大数据问题的思路三、云原生技术解决大数据问题的思路（一）云原生技术提升运维交付质量与效率（一）云原生技术提升运维交付质量与效率1、容器化、容器化云原生中部署的都是容器，容器的不可变基础设施属性，屏蔽了基础设施层对应用的影响：如应用的依赖包是否安装好，应用所在机器的 CPU 架构等，提高了应用程序的可移植性，大大降低了平台交付过程中环境标准化工作的成本。2、Operator 机制机制大数据组件种类繁多，每个大数据组件的安装和运维方式不尽相同，人力维护成本较高。Kubernetes 中提出了使用 Operator 的方式来管理复杂应用。通过 Operator 的方式标准化了大数据组件的安装和运维，将复杂的安装步骤、大数据组件升级、高可用配置等运维操作自动化，减少了人工成本，同时也提高了运维工作的及时性和效率。3、统一的日志收集与监控报警、统一的日志收集与监控报警在云原生技术栈中，日志收集展示和监控报警都有标准化的实现方式，如采用 sidecar 容器收集业务容器中的日志，采用 Prometheus技术体系收集监控指标与配置报警规则。这样就可以用统一的方式将所有组件的日志和监控汇总到统一页面来查看，方便了问题的跟踪与定位。21图 10：kubernetes 中常见日志收集方式4、声明式的、声明式的 API在云原生中，API 都是声明式的，声明式会为大数据组件带来两个好处:资源抽象程度高：资源抽象程度高：如果组件需要一个 1G 容量大小的块存储，不用运维人员感知然后手工去创建和配置，只要在 API 中声明你需要的配置即可，整个流程都是自动化的；图 11：kubernetes 声明式 API 样例-存储面向终态：面向终态：声明式 API 是不断向着终态逼近的，假如我们声明了一个服务包含 3 个副本，如果其中某几个副本意外退出了，声明式API 会及时发现并且迅速拉起一个同样副本，始终保证服务的副本数22的稳定，确保服务的整体可靠性。图 12：kubernetes 声明式 API 样例-计算资源副本数（二）云原生技术提升集群资源使用率和弹性（二）云原生技术提升集群资源使用率和弹性1、混部、混部云原生技术中，将整个基础资源层抽象成了一个大的资源池（计算、存储、网络等资源的组合），被所有大数据组件所共享。组件可以按需从这个大资源池中申请资源，这样避免了资源的重复建设，减少了资源浪费。同时这些资源池可以承载不同类型的大数据组件，如批处理、流处理、OLAP 等，加上云原生提供的多种调度技术，可以将不同大数据组件一起混部，结合算法模型，可以预测各个组件的流量峰谷，从而形成了资源的分时复用，整体上提高了总体资源利用率。云原生提供的单机隔离技术 Cgroup、KVM、Kata 等可以有效的防止混部进程间的相互干扰，使得混部更加安全。大数据混部主要指离在线业务的混部，有如下几种常见思路：（1）在线离线业务完全容器化混部）在线离线业务完全容器化混部在该种思路中，新业务完全使用 K8S 调度，同时兼容在线集群，离线和在线大数据业务根据分时调度的策略，选择不同集群/节点运行。整体架构如图所示：23来源：https:/ 13：在线离线业务混部示意图该思路的优点是管控集中，统一 K8S 调度管理，便于实现在线离线任务的灵活调配。缺点是目前社区大数据方案还不够成熟，旧的基于 Yarn 的大数据作业的兼容性无法保证，需要企业自身具备较强的大数据及云原生技术实力，且无需考虑历史作业的兼容。（2）Hadoop Yarn on Kubernetes 模式模式在该种思路中，作业提交入口依然为 YARN 保持不变，整个计算资源的调度还是由 YARN RM 来执行，计算任务还是运行在 YarnNode Manager 中。整体架构如图所示：24来源：https:/koordinator.sh/图 14：Hadoop Yarn on Kubernetes 集群模式混部示意图从上面架构图中，可以看到大数据集群和容器集群依旧是相对独立的，容器集群中会启动一个 Yarn Node Manager（以下简称为 YarnNM）的 Pod，这里的 Yarn NM 会自动连接到大数据集群的 ResourceManager 服务。这样的话，所有的业务代码和提交方式都不需要改变，等同于单独扩容了几台 Yarn Node Manager。该思路的优点是计算任25务层无感知，兼容性好。缺点如下：离线集群可扩展差，Yarn 镜像中需绑定大数据集群的 Host列表。会有额外的资源消耗，Node Manager 占用部分服务资源。需要高版本的 Yarn，低版本 Yarn 不支持 Liunx ContainerCgroup 设置，可能会对在线资源有影响，需要考虑好 Cgroup目录划分和驱逐策略。额外的节点 Yarn 标签管理工作。该种思路适用于大部分企业场景，改造成本更低、能够较好兼容现有大数据集群、效果明显。除此之外，会有企业在上述两类混部思路的基础上，实现更多组合优化方案。2、弹性伸缩、弹性伸缩云原生技术栈提供了 HPA、KEDA 等弹性扩缩容技术，结合统一监控收集到的组件业务指标和性能指标，可以实现大数据组件的资源弹性伸缩。在业务高峰期时，按需动态增加资源容量（CPU、内存、存储等），当业务低谷时，动态减少资源容量，甚至做到当业务无流量时，将资源容器缩容到 0，从而进一步提高整体资源的弹性和利用率。同时由于容器的轻量级，弹性伸缩的速率很高，通过镜像预热等技术，可以更快的提高弹性扩缩容的速率。26图 15：弹性伸缩示意图（三）云原生技术提升大数据平台迭代效率（三）云原生技术提升大数据平台迭代效率利用云原生 DevOps 和持续交付的特性，基于现在比较流行的GitOps 方法论，可以方便得做到 IaC(Infrastruce as code)和 CaaS(configuration as a service)：将代码和配置存储在 Git 中，Git 中的每一次提交会产生一个新的 CommitID，所以天然具有版本的概念。当Git 中的文件发生变化，会产生一个新的版本(CommitID)，同时通过CI/CD 机制可以触发对这个版本的测试，当测试通过，会进行打包和部署；部署时可以结合灰度发布和服务网格等技术实现 A/B test，金丝雀发布安全发布方案。整体上提高从研发、验证到决策的效率。27图 16：GitOps 流程示意图常见的云原生发布策略有滚动更新与回滚、蓝绿发布、金丝雀发布策略，这些策略可以使应用发布的过程中实现应用的平滑升级，以减少对业务的影响。滚动更新：确保应用程序在更新过程中保持可用。滚动回滚：允许回滚到之前的版本。蓝绿部署：一种在新旧版本之间进行切换的策略。金丝雀发布：一种渐进性更新策略。相较于传统的大数据和分布式系统发布，云原生的容器发布提供了一种更为灵活、轻量、可移植性和隔离性的发布形式，使得大数据和分布式系统的部署和管理更为方便。（四）云原生技术提升大数据安全和隐私保护（四）云原生技术提升大数据安全和隐私保护1、数据隔离与多租户安全：、数据隔离与多租户安全：云原生技术栈中，有健全的多租户隔离机制来隔离不同用户的资源，防止不同用户间的恶意干扰。通过虚拟集群技术可以实现云原生28API 使用层面上的隔离、通过 Kata 等安全容器技术，可以实现容器运行时的强隔离，防止普通容器的逃逸问题发生；通过 VPC 等虚拟网络技术实现网络层面的隔离，防止端口扫描等恶意探测行为；云存储可以实现存储介质和 IOPS 上的隔离。多租户隔离可以分为硬隔离和软隔离，硬隔离为每个租户底层单独分配一个集群，从而达到隔离不同租户的目的，适用于为企业外部客户服务的场景，软隔离是多个租户共享底层计算，存储，网络资源。云原生强大的生态能力在网络层面，数据层面，控制面提供了多种隔离解决方案，多租户软隔离=网络隔离 数据隔离 权限控制。网络隔离：网络隔离：VPC 网络（Kube-router），Network Policy（Calico，Cilium）。数据隔离：数据隔离：安全容器 Kata,运行时 Runc Cgroup,Resource Quotas,Limit Range,Request/limit,Namespace。权限隔离：权限隔离：基于 RBAC 的访问控制 鉴权 授权29图 17：云原生安全隔离技术图示2、网络通信安全：、网络通信安全：K8S 内部微服务和 K8S 的通信使用非对称加密方式，服务之间通信使用证书/SA，具有双向认证功能，K8S 内针对 K8S 对象的访问也基于 RBAC 准则，即访问控制 鉴权 授权，针对不同的用户限制了对集群资源的访问范围和权限，极大的减少了由于越权访问带来了安全问题。图 18：双向认证与权限控制3、数据加密与保护：、数据加密与保护：想要实现端到端的数据加密在传统大数据平台上实施起来较为复杂。开源的方案有 HDFS 加密，TLS/SSL 用于数据传输等，但加密配置可能复杂，且在某些场景下可能影响性能。而云原生解决方案可以提供内建的、透明的加密功能，能够在性能较小损耗的情况下实现端到端加密：数据完整性数据完整性:云原生存储中，会通过校验码等机制来验证数据在传输和存储过程中没有损坏和篡改，保证数据的完整性。同时云原生技术栈中可以使用 RAM/IAM 等鉴权系统对资源进行精确的访问控制，可以细粒度到 PV 级别。同时当数据不用时，云存储会自动擦除30云盘上的数据，防止残留。数据机密性数据机密性:云原生技术栈中，从数据传输、计算、到存储都有完整的全链路加密方案，数据在网络传输时可以采用 Https、SSL、VPN 等加密，使用 HSM(密钥托管)等组件来实现证书的获取和管理；在数据的处理和计算过程中，可以采用数据脱敏技术对隐私数据进行隐藏，同时可以采用隐私计算等软硬结合技术实现安全沙箱容器，在内存级别实现对隐私数据的加密和隔离。在数据存储时，可以选择不同算法对数据进行加密存储，算法可以在申请 PV(Persistent Volume,持久化存储)的时候进行指定。下图是全链路加密的示意图:图 19：全链路加密示意图4、审计与合规性：、审计与合规性：云原生解决方案通常可以提供更全面和集成的审计日志功能，以及与合规性标准（如 GDPR、HIPAA）的更紧密集成。这些平台能够自动记录更详细的操作日志，并提供更高级的数据保护和隐私控制功能，从而更有效地满足复杂的合规性要求。5、灾难恢复与数据备份、灾难恢复与数据备份在灾难恢复和数据备份方面，云原生解决方案可以提供自动化的、高效的备份和恢复解决方案：31云原生技术基于微服务架构，每一个微服务一般都是多活架构，微服务架构将整体组件的复杂性进行了解耦，避免了服务的单点故障，提高稳定性和容错性；云原生存储在技术实现上都是多副本机制，可以避免少量副本意外丢失造成的数据不可用情况，保证了数据的高可用性；云原生技术栈中自带的负载均衡、服务发现、共享存储等机制，可以更好的实现组件的同城双机房，两地三中心等容灾部署。6、丰富的安全工具提升网络安全、丰富的安全工具提升网络安全在网络层面的安全防护是传统大数据平台的薄弱环节。云原生解决方案有着丰富的安全类云产品或工具，如 WAF、安全组、网络 ACL等来对组件的安全进行防护，实现防止网络攻击、异常行为检测、异常代码扫描等。（五）云原生技术带来的其它好处（五）云原生技术带来的其它好处除了解决上述传统大数据平台的痛点，云原生技术与大数据平台融合，还带来了以下好处：1、对跨平台的支持更加简便、对跨平台的支持更加简便云原生架构的大数据平台对于适配不同的 CPU 架构和操作系统来说会更简便，得益于如下两个特点：首先，云原生技术栈及其配套工具普遍采用 Go 语言开发。作为一种编译型语言，Go 提供了优秀的交叉编译能力和对不同平台的原生支持，这降低了针对多操作系统的适配和部署难度。其次，大数据32组件在云原生环境中通常以容器形式运行。容器技术的不可变性和隔离性能有效地屏蔽了底层操作系统差异，加快了在不同环境中的适配速度。这两大特性共同增强了云原生大数据平台的跨平台能力，提升了其灵活性和可移植性。2、更便于实现混合云、多云架构、更便于实现混合云、多云架构随着公有云的更加普及，未来企业会有更多的混合云、多云的需求，遵循云原生规范的基于 Kubernetes 的大数据云原生架构，将极大地促进跨多云和混合云部署的便利性。这主要得益于以下几个方面：统一的管理和编排：统一的管理和编排：Kubernetes 提供了一个统一的平台来管理和编排容器化的大数据应用。无论是在公有云、私有云还是混合云环境中，Kubernetes 有希望提供一致的操作体验，简化跨环境部署和管理。灵活的资源调度：灵活的资源调度：Kubernetes 强大的资源调度能力使得在不同云环境中部署和扩展大数据应用变得更加灵活和高效。我们可以尝试根据应用的资源需求和可用性要求，智能地在多云或混合云环境中分配和优化资源。容器化的一致性：容器化的一致性：由于大数据组件在 Kubernetes 平台上以容器的形式运行，这保证了应用在不同云环境中的一致性和可移植性。容器化的应用更好地在多个云环境之间迁移，无需针对特定云环境进行重大修改。网络策略和安全：网络策略和安全：Kubernetes 提供了强大的网络策略和安全机33制，这有助于在多云和混合云环境中保护数据和应用。通过这些策略，可以有效地隔离和保护跨云环境中的网络流量，确保数据安全和合规性。图 20：多云/混合云部署示意图3、更便于与、更便于与 AI 平台融合平台融合传统的大数据平台和 AI 平台往往存在一定程度的割裂，往往是两个独立的团队，它们依赖于不同的技术栈。大数据平台通常基于Java 技术栈，而 AI 平台则更倾向于使用 Python 技术栈。这种技术栈的差异在一定程度上导致了两个领域之间的协作障碍。然而，随着云原生架构的普及和采纳，这种局面正在发生变化。技术栈的统一：技术栈的统一：云原生架构提供了一种更加统一的方法来构建和部署应用，无论它们是基于 Java 还是 Python。在云原生环境中，不同技术栈的应用可以容器化，并在统一的平台上进行管34理和调度。这极大地简化了不同技术栈之间的集成和协作。灵活的服务交互：灵活的服务交互：云原生架构通常采用微服务的方法，这允许不同的服务（无论是大数据处理还是 AI 模型）作为独立的组件被开发和部署。这种方法不仅提高了系统的灵活性和可维护性，还促进了不同技术栈之间的互操作性。统一的数据开发能力：统一的数据开发能力：大数据平台在处理和分析大规模数据方面的能力可以直接支持 AI 应用。通过在同一云原生平台上紧密集成，AI 模型可以更方便地访问和处理存储在大数据平台上的数据，从而提高数据处理的效率和效果。统一的管理运维：统一的管理运维：云原生平台如 Kubernetes 提供了高度灵活的资源管理和调度能力，可以同时纳管 CPU 和 GPU，更好的支撑大数据和 AI 作业。在云原生环境中，无论是大数据应用还是AI 应用，都可以利用相同的 CI/CD 流程、监控工具和运维实践。这种统一性减少了跨技术栈协作的复杂性，使得团队可以更专注于业务逻辑的实现，而不是环境的差异。通过采用云原生架构，大数据平台和 AI 平台之间的融合变得更加自然和高效。这种融合不仅打破了技术栈的障碍，还为企业提供了一个更加灵活、协同和创新的环境，以支持其数据驱动和智能化的业务需求。35图 21：大数据/AI 混合部署（六）大数据云原生引入的新挑战（六）大数据云原生引入的新挑战借助云原生技术对大数据平台带来好处的同时，也引入了一些新的挑战，需要业界共同去解决，简要列举如下：1、如何提升大数据作业调度的稳定性和性能？、如何提升大数据作业调度的稳定性和性能？由于大数据的离线计算跟传统云原生应用的场景相比，对调度的时效性和并发度要求都会比较高，传统的调度机制难以满足这种动态和大规模的资源管理需求，因此需要更符合大数据场景的调度方案，可以考虑以下措施：(1)更为智能和灵活的调度算法更为智能和灵活的调度算法最为关键的是开发更为智能和灵活的调度算法，例如基于Kubernetes 的自定义调度器，能够根据作业的特性和资源的可用性进行优化调度。同时，通过实现高级调度功能，如对于大数据批处理作业来说，针对 All-Or-Nothing 类型任务的 Gang Scheduling，确保相关36任务能够同步执行，减少资源的闲置和作业的等待时间。在实现 GangScheduling 方面，有一些开源项目比如 Volcano、YuniKorn 等提供了优秀的案例。Volcano 是一个为云原生环境设计的高性能批处理系统，专注于优化大数据和 AI 工作负载的调度，而 YuniKorn 则提供了轻量级且适应大规模和异构环境的调度解决方案，同时支持多租户和容量调度。这些系统将 Gang Scheduling 的概念与自身特有的调度策略相结合，为云原生环境中的大数据作业提供了更为稳定和高效的调度解决方案。(2)针对不同作业类型的精细化调度针对不同作业类型的精细化调度在 Kubernetes 环境中，根据作业的特性和需求，作业被分为不同的 Quality of Service(QoS)类型，如 Guaranteed,Burstable,和BestEffort。这种分类允许系统根据作业的重要性和资源需求进行更细致的资源分配。例如，对于关键任务，可以保证资源的稳定供应，而对于非关键任务，则可以在资源紧张时进行调整。这种策略有助于在保障关键作业稳定运行的同时，提高整体系统资源的使用效率和灵活性。(3)分布式调度支持大规模集群分布式调度支持大规模集群随着集群规模的扩大，单个调度器可能成为性能瓶颈。分布式调度系统，如 Kubernetes 中的多调度器架构，允许将集群资源分区分组，并进行并行调度。这种方法降低了单个调度器的压力，提高了调度的吞吐量，减少了作业的等待时间，从而提升了大数据作业的运行效率。(4)多集群联邦调度多集群联邦调度37多集群的联邦方式，整合不同部门不同组织的集群资源。根据不同集群中业务实际运行情况，跨集群进行资源共享（主要包括资源空闲时借出及资源紧张时回收等），既提升多集群资源使用效率，同时又保证高优先级大数据作业的及时响应。2、如何做好旧系统兼容性，降低旧作业迁移成本？、如何做好旧系统兼容性，降低旧作业迁移成本？传统的大数据应用大多是运行在 Hadoop 之上的，资源管理方面是 Yarn，存储对接的主要是 HDFS，而云原生的大数据平台，资源管理变成了 K8S，存储可能是对象存储，这导致将旧系统迁移到云原生平台时，需要进行大量的改造和适配工作，增加了成本和复杂性。为了降低迁移成本，可以考虑提供与旧系统兼容的接口和服务，如支持 Yarn API 的云原生调度器。同时，开发与传统存储系统（如HDFS）兼容的解决方案，确保无缝迁移，减少对现有工作流的影响。目前有一些开源的框架可以支持文件格式转换等工作，比如 Alluxio，JuiceFS 等。同时也需要针对各自具体的场景，开发一些辅助迁移工具；3、如何解决云原生场景下中间临时数据存取的问题？、如何解决云原生场景下中间临时数据存取的问题？大数据计算场景下有很多中间临时数据，也就 Shuffle 数据。传统的 Shuffle 机制可能因为跨节点动态资源调度的特性，在资源重新调度后无法读取前面 Shuffle 的数据，造成任务异常。解决这一问题的一种方法是指定 Shuffle 存储，防止数据随着 Pod的失效而丢失；业界比较流行的演进方案是采用新型的 Shuffle 处理技术，如 Remote Shuffle Service(RSS)，来优化在云原生环境中的数38据传输和处理流程。通过这种方式，可以有效提高数据处理的效率，降低延迟。4、如何缓解存算分离对大数据组件的影响？、如何缓解存算分离对大数据组件的影响？云原生环境中普遍采用的存算分离架构，数据普遍会考虑存在成本更低的对象存储中，对数据访问和处理模式提出了新的要求。在这种架构下，传统的大数据处理组件可能无法高效处理远程存储的数据，影响整体性能。针对这一挑战，需要优化大数据处理组件，比如改进 Spark 和Hive 等计算引擎的数据缓存机制，使用 Alluxio、JuiceFS 等中间缓存层，以及 Hudi、Iceberg 等表格式存储，实现更适合存算分离场景的统一元数据管理，以提高对远程数据的处理效率。5、Hadoop 需要进行云原生改造吗？需要进行云原生改造吗？Hadoop 的关键组件 HDFS 和 YARN，在云原生场景下，都有相应的平替，比如对象存储和 K8S，因此 HDFS 和 YARN 本身的容器化，相比 Spark、Flink 等计算引擎，一直是一个比较低调的话题，这是否意味着，我们不需要考虑 Hadoop 的云原生改造了？这个问题目前没有标准答案。然而，我们还需具体场景具体分析，在国内大量的私有化大数据场景下，Hadoop 本身的可靠性和兼容性在较大规模的场景下已经经过了大量的检验，对于很多用户来说，可靠性和兼容性大于一切，Hadoop 依然有其存在的价值，私有化场景下的对象存储也会失去公有云即开即用的优势，与 HDFS 在哪些场景下孰优孰劣也是一个值得39探讨的话题。在传统的 Hadoop 大数据平台到完全 Serverless 化的云原生大数据平台之间，我们也需要讨论是否需要过渡方案，以期望通过较少的投入，获得部分云原生技术的红利。目前开源社区有一些Hadoop On K8S 的方案，也有围绕 Hadoop 体系演进的开源对象存储方案，同时也有云厂商推出了兼容 HDFS 的 Serverless 云原生方案。6、传统大数据平台如何向云原生演进？、传统大数据平台如何向云原生演进？大量的企业未来都会面对如何从传统的大数据平台向云原生演进的问题，在从传统架构过渡到云原生架构的过程中，我们希望既能缓解大数据平台的问题，又尽量降低迁移过程中的改造成本，规避迁移风险，还需要考虑两种架构的共存问题。目前这一问题还没有标准的解法，业界一些常见的经验是，为解决这一问题，可以采用分布式迁移策略，研究相对平滑渐进的解决方案，目前也有一些厂商，在大数据云原生演进方面进行了一系列探索，也希望业界积累更多的经验和共识。7.引入引入 Kubernetes 的复杂度与不可靠性如何权衡？的复杂度与不可靠性如何权衡？Kubernetes 的引入虽然为云原生大数据环境带来了诸多优势，如资源的动态管理和服务的自动化部署，但同时也带来了更高的系统复杂度和潜在的不可靠性风险，排查大数据故障需要同时涉及大数据知识和云原生知识。在不同场景下，还需要用户根据实际需求进行权衡，为了有效利用 Kubernetes 的优势，同时控制风险，需要实施综合的系统监控、自动化运维和容错设计。40四、大数据云原生技术的架构简述四、大数据云原生技术的架构简述（一）云原生大数据平台的架构原则（一）云原生大数据平台的架构原则1、弹性伸缩与资源隔离、弹性伸缩与资源隔离针对不同的大数据组件以及同一组件的不同租户，要利用多租户技术与编排技术做到相互隔离，使它们可以安全地运行在各自的资源池内，并且不同组件要能实现弹性的扩缩容来应对业务的波峰波谷以提高资源利用率。2、容器化与统一资源调度、容器化与统一资源调度假设是完全的大数据云原生方案，所有大数据组件要容器化，接入云原生底座操作系统 Kubernetes。通过可插拔调度体系对底座资源池进行统一的、细粒度调度。实现在离线业务混部，提高资源利用率。根据业务优先级来分配对应的资源，确保资源不发生不合理竞争。通过不同的专业调度器实现 Gang Scheduling、CapacityScheduling 等不同的调度效果。3、多种计算引擎联合管理、多种计算引擎联合管理云原生大数据平台要有统一的页面和接口管理所有的云原生大数据组件，包括管理所有大数据组件的 Operator、统一为所有的大数据组件申请需要的云产品资源、为每个组件对接监控和日志等。4、统一元数据管理、统一元数据管理41无论从客户需求出发，还是从云原生数据架构的需求来看，需要具备在基于云计算分布式存储之上的独立统一元数据管理体系，统一管理结构化与非结构化的多种数据格式，以及对这些数据的访问权限控制，来支持多种计算引擎及上层需求。这里云原生技术和湖仓一体技术是相互融合的关系，共同构建云原生湖仓一体数据平台。5、智能化运维、智能化运维Serverless 极大了降低了大数据平台的运维难度，但平台智能化的边界还可以向外延伸，结合丰富的历史统计信息、作业运行信息、查询信息等，利用 AI 算法可以更好得做到提前预测流量高峰，智能作业调优和诊断，以及智能 Agent 等。6、可靠性与容灾、可靠性与容灾利用云资源做好数据和服务的备份和冗余，做到同城和异地容灾。（二）云原生大数据平台的参考架构（二）云原生大数据平台的参考架构各企业根据自己的场景，会有不同的架构，下图是结合了一种湖仓一体与云原生大数据平台的一个可能的架构设计，仅供参考：42图 22：云原生湖仓一体数据平台参考架构基础资源层：基础资源层：部署大数据平台时依赖的基础资源，主要包含主机、容器、网络、数据库、GPU 等基础资源。这里分为公有云、私有云和混合云等情况。公有云部署可以采用云厂商售卖的半托管或全托管的 Kubernetes 服务，私有云部署可以使用自己部署的开源Kubernetes 服务，而混合云客户可能同时拥有公有云和私有云的资源。数据存储层：数据存储层：主要包括 HDFS 存储与对象存储，以及基于之上构建的数据湖格式（Hudi、Iceberg、Delta Lake、Paimon 等），以及可能需要的数据缓存加速层（Alluxio、JuiceFS 等）。资源调度与管理层：资源调度与管理层：对大数据组件进行统一调度，这一层可利用Kubernetes 的抽象能力，将所有的基础资源抽象成统一的资源池，有些场景下依然需要依赖 Yarn，在此基础上为上层提供统一的资43源池管理，包括云原生 Operator、弹性伸缩控制器、分布式调度、多种专业调度器、多云调度等。统一元数据服务与管理层：统一元数据服务与管理层：存储引擎通常通过统一元数据服务，为上层的计算引擎提供统一的数据访问接口。元数据目录一般是Hive Metastore 或者兼容 Hive Metastore 的元数据服务，对于更大量，丰富的分析型元数据需求，可以考虑构建元数据仓库，通过湖仓管理服务来解决湖仓一体的自动化治理难题，通过统一数据安全权限模块来体系化地提供数据安全权限服务。计算引擎层：计算引擎层：包括大数据批处理引擎（Spark 等），流处理引擎（Flink 等），交互式分析引擎（Trino、Impala 等），远程混洗服务 Remote Shuffle Service，OLAP 数据库（Doris、StarRocks等），AI 引擎（Pytorch、TensorFlow 等）以及数据服务引擎（ElasticSearch、HBase 等），这些引擎都可以使用云原生 Operator 的方式进行部署和管理。数据开发与治理层：数据开发与治理层：为用户在大数据引擎基础上提供的各种上层服务，主要包括数据集成，数据开发，调度，数据治理，数据服务，数据科学等服务。运维管理平台：运维管理平台：负责整个大数据平台的部署和运维，包括集群部署，用户管理，集群管理，组件管理（部署、升级、下线），可观测性设施构建(Log/Metrics/Tracing)，安全管理，发布管理，容灾管理，基础资源管理等。44五、大数据云原生的未来发展和战略建议五、大数据云原生的未来发展和战略建议（一）技术发展方向（一）技术发展方向当前大数据云原生技术领域涌现出一系列发展趋势，简述如下：1.多云和混合云战略：多云和混合云战略：企业越来越倾向于采用多云和混合云战略，将工作负载分布在不同的云服务提供商和本地数据中心之间，以避免被单供应商锁定，提高弹性和可用性。2.自动化和智能化运维：自动化和智能化运维：云原生技术将更深入地实现自动化和智能化运维。通过整合自动化流程、自愈能力以及基于 AI 的运维策略，大数据云原生技术将帮助企业更有效地管理和维护其大规模的数据基础设施。3.数据治理架构变革：数据治理架构变革：随着数据规模的增加，以及多云环境的普及，数据的迁移成本，可观测性和有效的数据治理变得至关重要，Data Fabric 等数据治理架构和方法论正逐步被行业关注，企业需要更强大的工具来处理、监管和保护其数据资产。4.AI 与大数据的融合：与大数据的融合：人工智能和大数据技术的融合将推动更高级的数据分析和智能决策。（二）针对行业的建议（二）针对行业的建议随着大数据和云原生技术的快速发展，国内在这一领域的探索和实践仍处于早期阶段。为了促进大数据云原生的健康发展，以下是针对整个行业的一些建议：1.建立更广泛的探讨：建立更广泛的探讨：鼓励信通院这样的权威机构牵头，组织行45业内的专家学者、企业领袖和技术先锋，共同进行更广泛和深入的探讨。2.产出专业研究报告和技术白皮书：产出专业研究报告和技术白皮书：定期发布关于大数据云原生技术和产业的研究报告，以及相关技术的白皮书。这些文档应涵盖最新的行业趋势、技术进展、最佳实践和案例研究，为行业提供指导和参考。3.关注国内特殊需求：关注国内特殊需求：针对国内市场的特殊需求，如私有化部署场景，考虑更多私有云、混合云的方向，提供针对性的解决方案和实践建议。4.制定统一的测评标准：制定统一的测评标准：制定一套标准化、公正的测评体系，用于评估不同大数据云原生解决方案的性能、可靠性、安全性等关键指标。这将有助于提高市场的透明度，促进健康竞争。（三）针对企业和用户的建议（三）针对企业和用户的建议对于企业和用户而言，正确地选择和实施云原生技术是实现数字化转型和提升竞争力的关键。以下是一些具体的建议：1.实际评估业务需求实际评估业务需求：在跳入云原生的大潮之前，先停下来问一问：“我们真的需要这个吗？”评估你的业务场景是否真的会从云原生技术中受益，比如是否需要更便捷的部署运维、更强的扩展性或更高的资源利用率。2.选择合适的方案选择合适的方案：不同的需求会有不同的解决方案，是先不动，是完全升级，还是渐进升级，重要的是找到“对症下药”的解决方案。463.小步快跑，逐步迁移小步快跑，逐步迁移：不必急于一步到位。可以先从一个不太复杂的项目开始尝试，逐渐感受和学习云原生的运作方式，再逐步扩展到其他项目。4.分享实战经验分享实战经验：如果你在云原生转型中取得了成功，不妨写个案例分享出来，或者在行业会议上讲讲你的故事。这不仅能提升你的品牌影响力，也能帮助同行少走弯路。5.关注实际的安全和合规问题关注实际的安全和合规问题：安全不是摆设，合规不是噱头。确保你的云原生方案一开始就能满足行业安全标准，有时候后面改会有较高的成本。6.持续监控，关注成本和效益持续监控，关注成本和效益：定期检查你的云原生环境是否真的提高了效率，降低了成本。有时候，一些看似高效的技术实际上可能是金钱和时间的黑洞。六、参考文献六、参考文献在编撰本报告的过程中，我们深入研究了众多国内外大数据云原生领域的资料。在此基础上进行了综合性的分析和融合，加入了自己的理解。感谢所有原作者和专家的贡献，为我们提供了宝贵的信息和启发。最后感谢大数据云原生资深专家，开源 CloudEon 作者星河与KubeData 作者刘彬，利用业余时间帮助审稿。由于时间仓促，水平所限，错误和不足之处在所难免，欢迎各位读者批评指正，让我们一起努力，共同推动大数据云原生的技术普惠。471 信通院-湖仓一体技术与产业研究报告2 信通院-云原生湖仓一体白皮书（2022 年）3 CNCF-云原生技术官方定义：https:/ CNCF-云原生 Landscape：https:/cf.io/5 大数据云原生的探索与实践：https:/ 大数据云原生的现状与趋势：https:/ 云原生时代的大数据技术演进：https:/ 云原生大数据平台的构建思路：https:/ 云原生大数据架构实践与思考：https:/ 大数据系统云原生渐进式演进最佳实践:https:/ 湖仓一体 2.0：数据分析的终局之选：http:/ Pepperdata-2021 Big Data on Kubernetes Report：https:/ 传统大数据平台如何进行云原生化改造：https:/ Starburst-Presto 在 2019 年 8 月宣布支持 K8S：https:/www.starburst.io/blog/presto-on-kubernetes/15Apache Flink-Flink v1.10.0 发布 Native Kubernetes beta 版：https:/flink.apache.org/news/2020/02/11/release-1.10.0.html16 Datanami-Hive 探索 MR3 运行在 Kubernetes 上：https:/ Kubernetes Blog-Kubernetes Airflow Operator：https:/kubernetes.io/blog/2018/06/28/airflow-on-kubernetes-part-1-a-different-kind-of-operator/18 KubeData:大数据离在线混部场景资源调度的演进与选型https:/ Volcano https:/ yunikorn https:/ Koordinator https:/koordinator.sh/22 CloudEon https:/ 数据库应该放入 K8S 里吗？https:/ 没错，数据库确实应该放入 K8s 里！https:/ ChatGPT：https:/

0人已浏览 2024-01-12 53页 5星级

1分布式异构智能算力的管理和调度技术分布式异构智能算力的管理和调度技术研究研究报告报告研究单位：研究单位：中国移动研究院、浪潮电子信息产业股份有限公司中国移动研究院、浪潮电子信息产业股份有限公司、新华三技术有限公司新华三技术有限公司完成日期：完成日期：2023 年年 12 月月2目录目录一、研究背景.3二、异构算力的发展和应用场景需求.4（一）异构算力的发展情况.4（二）异构算力的主要应用场景.7三、分布式异构算力管理和调度的关键技术能力.9（一）异构算力的虚拟化和池化.10（二）分布式异构算力的调度能力.13（三）分布式异构算力的度量和标识.16四、当前业界技术实现情况.17（一）中国移动智算体系实现异构资源池化.18（二）浪潮 AIStation 平台实现异构资源管理调度.19（三）新华三傲飞平台实现异构资源管理调度.22五、总结与展望.24参考文档.263一、研究背景研究背景随着我国数字经济规模总量的不断攀升，实体经济、数字经济和信息服务的深度融合正加速产业数字化和数字产业化变革。算力作为承载信息数据的重要基础设施，已成为全社会数字化转型的重要基石。根据中国信息通信研究院最新发布的中国算力发展指数白皮书（2023 年）显示，至 2023 年我国智能算力规模达到 178.5EFlops，增速为 72%，在我国算力占比达 59%，成为算力快速增长的驱动力；据 IDC 等机构预测，至 2025 年，新增数据量 180ZB，其中 80%的增长来自于文本、图片、语音、视频等非结构化的数据。随着人工智能、元宇宙、高性能计算等领域的发展，激发了更多智能数据处理的需求和场景，对新型智能算力的需求激增。本研究围绕典型智能计算应用对异构算力的协同及调度需求，研究泛在异构算力参与训练或推理过程的协同需求、调度需求，研究泛在异构算力参与训练或推理过程的协同需求，包括异构算力类型、规模要求、性能要求、网络要求、数据传输要求等，分析异构算力协同4的应用场景等特点，考虑同数据中心、跨数据中心、跨云边端多级、池化和非池化异构算力并存等各种场景下，算力协同的需求及可行性。研究分析异构算力资源分类整合、池化重构和智能分配等技术方案。研究分布式异构算力资源管理技术方案，包括管理跨数据中心、边缘及端侧的 GPU、FPGA 等异构算力设备，已虚拟化或池化的异构硬件，研究对异构算力资源进行标识和监控的方案，对算力进行细力度切分供给的技术方案，研究对计算任务进行异构算力匹配和调度的技术方案。包括如何匹配差异化的计算任务到相应的异构算力节点，如何支持异构算力资源高效和细粒度分配，基于应用场景的负载差异性，建立面向多样化异构算力资源和上层多场景需求的多元异构算力统一调度架构，统一资源实时感知，抽象资源响应和应用调度。研究分布式 AI 框架支持分布式异构算力的管理和调度技术方案。二、异构算力的发展和应用场景需求（一）异构算力的发展情况二、异构算力的发展和应用场景需求（一）异构算力的发展情况异构算力通常是指 CPU、GPU、FPGA、ASIC 等多种不同的算力处理体系，能够满足不同场景中的应用需求，实现计算效力最大化。异构算力通常以 AI 芯片的形态被集成在计算机中，AI 芯片是 AI 算力的核心基础设施之一。近年来，面向特定领域体系结构的定制化芯片也不断涌现，已成为 AI 算力发展的主流趋势。目前异构算力主要有以下类型：GPU：5英伟达 GPU 的发展可以追溯到 1999 年，当时英伟达发布了第一代 GPU 架构 GeForce 256，标志着 GPU 时代的开始。随后，英伟达的 GPU 架构不断升级，从 TNT、Rage 到 Geforce 256，再到 Tesla、Fermi、Kepler、Maxwell 等。随着 GPU 技术的不断发展，英伟达的GPU 架构也不断升级，以适应日益增长的计算需求，GPU 架构也不断推动着图形渲染、人工智能和高性能计算等领域的发展。近年来，英伟达还发布了多款强大的 GPU 芯片，如 Turing、Ampere 等，这些芯片都具有高性能的计算能力，为各种应用提供了强大的计算支持。2022 年 3 月，英伟达推出了 HGX H100，拥有最高可达 18432 个 FP32（单精度）和 9216 个 FP64（双精度）的 CUDA核心，辅以 576 个第四代 Tensor 核心。2023 年 11 月，英伟达再次升级其 GPU 产品线，发布了 HGX H200。这款新的 AI 计算平台在原有H100 的基础上进行了全面升级，主要升级包括提供 141GB 的下一代HBM3e 内存，这使得 H200 成为了英伟达目前最强的人工智能芯片。APU：APU（Accelerated Processing Unit）中文名字叫加速处理器，AMD将中央处理器和独显核心做在一个晶片上，它同时具有高性能处理器和最新独立显卡的处理性能，支持 DX11 游戏和最新应用的“加速运算”，大幅提升了电脑运行效率。从 2010 年以来，AMD 相继推出 GCN 架构、RDNA 架构、RDNA2架构、RDNA3 架构、CDNA 架构和 CDNA2 架构。最新一代面向高性能计算和人工智能 CDNA2 架构于架构采用增强型 Matrix Core 技6术，支持更广泛的数据类型和应用，针对高性能计算工作负载带来全速率双精度和全新 FP64 矩阵运算。基于 CDNA2 架构的 AMD InstinctMI250X GPU FP64 双精度运算算力最高可达 95.7TFLOPs。TPU：TPU 是由 Google 推出的人工智能芯片 Tensor Processing Unit。之后又陆续推出了 TPUv4 等若干代 TPU 和 TPU Edge。TPU 是计算神经网络专用芯片，是 google 为了为优化自身的 TensorFlow 机器学习框架而打造。FPGA：FPGA 作为一种灵活可编程的硬件平台，具备较高的计算性能和可定制性，能够提供对 AI 算法的加速和优化；在 AI 应用中，可以用于实现神经网络加速器、高性能计算单元等，为计算密集型的 AI 任务提供高性能和低延迟的计算能力。例如，英特尔 Stratix 10 NX FPGA 就是专门为 AI 设计的，具有AI 张量块，包含密集的低精度乘法器阵列，针对矩阵和向量乘法进行了调整，可执行 INT4、INT8、Block FP12 或 Block FP16 操作。此外，这些张量块可以级联在一起，支持大型矩阵。ASIC：与更通用的芯片（如 CPU 和 GPU）相比，ASIC 芯片的定制化提供了更高的效率。ASIC 的兴起引起了 NVIDIA、AMD 和英特尔等科技巨头的关注。行业可能会采用混合技术来推动创新和进步。例如，NVIDIA 一直在开发自己的 AI 专用芯片，称为 Tensor Cores。随着亚7马逊、微软和百度等科技巨头探索定制 ASIC，这项新技术显然将在AI 处理中发挥重要作用。ASIC 领域还持续在可扩展性、可负担性和实施方面开展攻关。DPU：DPU 服务于云计算，主要作用是提升数据中心等算力基础设施的效率，减少能耗浪费，进而降低成本。随着数据中心建设、网络带宽和数据量急剧增长，由于 CPU 性能增长速度放缓，为了寻求效率更高的计算芯片，DPU 由此产生。例如，英伟达将 Mellanox 的ConnectX 系列高速网卡技术与自己的已有技术相结合，于 2020 年正式推出了两款 DPU 产品 BlueField-2 DPU 和 BlueField-2X DPU。（二）异构算力的主要应用场景（二）异构算力的主要应用场景异构计算利用不同类型处理器的独特优势，例如 GPU 的并行计算能力和 FPGA 的定制化硬件设计能力，从而提高计算性能和功率效率。它在许多领域都有广泛的应用，如人工智能领域的深度神经网络训练，科学计算领域的模拟和数据处理，物理仿真和计算机视觉等。此外，异构计算还可应用于移动设备和嵌入式系统等领域，在这些领域中，功率和性能都是非常重要的因素。异构计算可以让这些设备更加智能化，同时提高它们的性能和功率效率。总结来看，异构算力的主要应用场景包括：机器学习和深度学习：异构计算可以利用 AI 算力的并行处理能力，加速机器学习和深度学习的训练和推理过程。例如，使用 GPU进行大规模的矩阵运算，可以大幅提高训练速度和模型准确率。8 高性能计算（HPC）等科学计算场景：在科学研究、工程仿真等领域，需要处理的数据量巨大，传统的 CPU 计算已经无法满足需求。异构计算可以利用 CPU 和 GPU 联合的方式，实现更高的计算性能和效率。图形处理渲染和游戏开发：异构计算可以利用 AI 算力的并行处理能力，实现图像的实时渲染和处理。例如，在游戏开发中，利用GPU 卡加速可以实现更加真实的光影效果和更高的帧率。物联网（IoT）：物联网设备数量庞大，需要进行大量的数据处理和管理。通过异构计算，可以实现物联网设备的智能化管理和数据处理，提高物联网应用的效率和可靠性。异构计算可以利用CPU GPU 或者 CPU FPGA GPU 等异构算力联合的方式，实现更高的计算性能和效率。区块链：区块链技术需要保证交易的安全性和可靠性，同时需要处理大量的交易数据。异构计算可以利用 FPGA 进行加密计算，提高区块链的运算速度和安全性。除了上述典型的应用场景外，不同行业对异构智能算力的整体需求也呈现差异化分布的特点。9据信通院与 IDC 的最新统计，由于互联网行业对数据处理和模型训练的需求不断提升，是智能算力需求最大的行业，占智能算力 53%的份额；服务行业由于快速从传统模式向新兴模式发展，算力份额占比位列第二；政府、电信、制造、金融、教育等行业分列第三到八位。三、分布式异构算力管理和调度的关键技术能力三、分布式异构算力管理和调度的关键技术能力异构算力多元泛在，对算力的管理平台提出了新的挑战。异构算力管理平台实现多种异构算力的管理和调度，并为智算应用提供应用层的推理和训练技术栈的支持，主要实现以下主要核心能力：动态资源管理：管理 CPU、GPU、FPGA 等异构算力的注册和接入，算力拓扑信息，算力实时状态信息，实现对算力资源的虚拟化和池化的资源重构，提供细粒度的资管管理和隔离；资源调度编排：实现异构算力节点的灵活调度，实现任务与节点资源的灵活编排，多以容器技术基于 Kubernetes 定制化研发实现对任务和资源的灵活编排调度，为上层功能模块提供资源能力；异构算力适配：提供适配异构算力的从底层驱动到应用层框架整10体技术栈的适配支持，以保证应用在不同算力节点上能弹性迁移调度，例如支持不同异构硬件的算子库、编译器、开发工具等；支撑智算的平台能力：基于底层异构算力提供智算应用的数据处理、AI 训练推理框架、模型服务等功能支持。分布式异构算力的管理和调度是分布式异构算力平台的核心功能，其包括的关键技术主要包括：（一）异构算力的虚拟化和池化（一）异构算力的虚拟化和池化异构算力虚拟化和池化是指在计算环境中利用不同类型的计算资源（例如 CPU、GPU、FPGA 等）进行虚拟化和资源的池化管理。对于异构资源的虚拟化、池化等资源重构技术方案，将整合硬件资源，形成同类资源池，提高计算资源的利用率和灵活性，从而更好地满足不同应用的需求。异构算力虚拟化指的是将不同类型的计算资源进行虚拟化，使其能够被多个应用程序或用户共享和管理。这种虚拟化技术可以提高计算资源的利用率和灵活性，比如将 GPU 资源虚拟化供应用程序使用，以满足不同应用对算力的需求。而池化则指的是将异构计算资源汇聚到一个统一的资源池中，通过统一的管理和调度，按需分配给不同的应用程序或用户。这种池化的方式能够提高整体的资源利用率，降低资源浪费，同时也能够更灵活地满足不同应用对算力的需求。目前典型的 GPU 虚拟化的技术实现方案包括 MIG 和 vGPU。MIG（Multi-Instance GPU）作为 Ampere 以及之后的 Hopper 架11构推出的新特性，解决了像 Ampere、Hopper 这种大 GPU 在集群服务应用时一类需求 GPU 切分与虚拟化。MIG 分割的每个 GPU 实例都有完整的独立的内存系统 L2 缓存、内存控制器、DRAM 地址总线等，这样的切分方式也同时以利于容错和吞吐率以及延迟的预测。MIG 的基本方法就是能完成资源的分块 组合，即对物理卡上能用的物理资源进行切分，包括系统通道、控制总线、算力单元（TPC）、全局显存、L2 缓存、数据总线等；然后将分块后的资源重新组合，让每个切分后的子 GPU 能够做到数据保护、故障隔离独立、服务稳定。MIG 可以动态创建和销毁，但是对于没有被分配的 GPU 是无法被使用的。MIG 的资源创建存在两次划分过程，先划分 GI 资源，再划分 CI 资源，这样通过排列组合，增加了配置的多样性。但是这些组合并不是随意的，必须遵循一定的规则，按照 MIG 设定的（profile）进行配置。基于 vGPU 的虚拟化方案最初由 Nvdia 推出，vGPU 技术允许用户按照规范对 GPU 的计算资源进行切分，就是将一块 GPU 卡的计算能力进行切片，分成多个逻辑上虚拟的 GPU，以 vGPU 为单位分配GPU 的计算能力，并将单块 GPU 卡分配给多台虚拟机使用，其本质上是通过硬件支持和驱动软件配置的方案，将部分 GPU 暴露给用户。同时为了丰富 GPU 虚拟化的能力，vGPU 也可以支持多种不同的调度机制，使不同的容器可以安全的共享一张物理 GPU，提高 GPU 的利用，例如支持 Round-Robin 调度算法，Equal Share Scheduling 算法，Fixed Share Scheduling 机制等。12智能算力池化的目标是利用软件定义技术，对通过高速无损网络互连互通的 CPU、GPU、AI 芯片等算力资源进行池化整合，实现资源的集中调度、按需分配，使能资源可被充分利用，降低碎片概率，提高总体有效算力。池化技术下，资源分配方式发生了根本性的变革，软件介入了资源的算力供给，为开启更敏捷的资源管理模式，比如动态伸缩、资源超分等奠定了技术基础，为持续优化智算资源利用率创造了无限可能。池化技术主要通过以下两种实现了软件定义的资源分配：一是 API 劫持技术：API 劫持技术是目前比较普遍的、针对智能算力的池化技术，它通过劫持对 Runtime API（如 CUDAAPI）调用实现资源调度。当 AI 应用访问池化运行时的 API 时，则被池化运行时转递至池化服务代理执行，池化服务代理则具备敏捷化的资源管理功能，比如按 1%算力、1MB 缓存的精度细粒度分配资源，实现跨节点远程调用资源等。API 劫持技术的关键在于池化运行时仿真 GPU/AI芯片的原生运行时，由于 GPU/AI 芯片种类、型号繁多，其原生运行时又相对活跃、升级频繁，仿真工作较为复杂，开发量、维护难度较大。二是应用程序监视器技术：这是一种完全与 GPU/AI 芯片无关的设备虚拟化和远程处理方法，允许在没有显式软件支持的情况下启用新的硬件体系结构。该项技术通过应用程序监视器工作，该监视器与Hypervisor 管理虚拟机的方式类似，分为前端、后端，前端监视指定应用程序的活动，拦截至后端处理，后端可以按应用程序申请的数13量分配资源，或将应用程序拆分到多台机器上运行，在保持代码、数据和执行环境一致性的前提下使用这些机器上的智算资源，从而实现资源的细粒度管理、远程调用等资源敏捷化管理功能。（二）分布式异构算力的调度能力（二）分布式异构算力的调度能力分布式异构算力的调度将实现底层算力资源与上层应用的匹配，通过节点的动态调度，异构算力节点间的协同，实现分布式异构算力资源使能上层智算应用。对于跨异构计算节点支撑统一智算应用的调度，依然面临很多技术上的挑战。对于非同质节点的调度，还存在技术上的壁垒问题。由于不同 GPU 等异构硬件在支撑智算应用时，依赖不同的技术栈，包括底层的 CUDA、编译器、前端 AI 框架等，例如运行在英伟达的 GPU上的应用并不能调度到国产化的 GPU 上无缝运行，也更无法将一个运行在 GPU 上的程序不经过适配改动直接运行在 FPGA 上，技术栈的竖井问题导致一个智算应用目前仍然很难在不同的异构算力节点上无缝迁移，或者同步运行，往往需要对应用本身进行适配和改造才能具备在不同异构算力节点上进行任务调度的前提。产业界也在一致开展跨架构迁移的探索，中国移动提出的算力原生相关技术，能够支撑模型推理在跨异构节点的统一编译，实现不同异构节点的技术栈的拉通，为应用在跨异构节点之间的调度提供了一定的技术基础。异构算力资源的调度不仅需要考虑异构算力本身的特性，还需要考虑算力资源实时的状态、与算力任务的匹配等。由于当前智算算力集群和资源管理绝大多数以容器和 K8s 的管理体系为主，在异构算力14的背景下，K8s 通过对设备插件的拓展支持实现对不同异构算力的识别和管理，算力设备厂商按照 device plugin 的接口规范实现自己的device plugin，以 daemonset 形式部署到节点，通过和 kubelet 交互，从而实现设备资源的发现、健康检测、分配等操作。当 K8s 集群具备对异构算力的管理能力时，则可以基于 K8s 的系统调度能力，对异构算力按照一定的机制进行管理。例如在 Kubeflow 平台中，GPU 资源的管理和调度是通过 GPU插件实现的，当用户提交一个 GPU 任务时，Kubernetes 的 GPU 插件会首先检测系统中可用的 GPU 资源，并根据用户的要求为该任务分配一定数量的 GPU 资源。GPU 插件会根据任务的需求和系统中GPU 资源的可用情况，选择合适的 GPU 设备挂载给对应的 Pod。在集群初始化阶段，K8s 将通过设备管理将特定类型的硬件资源注册到Kubernetes 集群中，并提供 API 接口实现对资源的管理。当Kubernetes 调度器需要为任务分配 GPU 资源时，会通过 DevicePlugin接口来获取可用的 GPU 资源，并根据任务的需求选择最适合的 GPU设备为任务分配，如图所示：Kubeflow 的 API 可以查询 GPU 资源的可用性和使用情况。用户也可以使用 Jupyter Notebook 来创建、编辑和运行深度学习任务，在创建15用于训练的 Jypyter Notebook 时，系统会将整数块的 GPU 分配给对应的 Pod，如果要实现任务的细粒度管理，可以使用 GPU-Share 的方式实现多个 Pod 之间的 GPU 共享。目前分布式异构算力管理平台所支持的主流调度机制包括：-基于 Gang scheduling 的批量调度策略：支持在并发系统中将多个相关联的进程调度到不同异构算力上同时运行的策略；-网络拓扑调度：对集群网络进行标识和描述，根据异构算力所在的网络状态，以支撑策略对不同的集群网络进行调度和决策；-基于实时资源状态调度：根据异构节点实时资源状态，包括CPU、GPU 等实时可用资源情况进行调度；-基于任务优先级等状态调度：结合应用任务的状态和需求，以及与底层异构算力的状态和属性进行匹配调度；-指定异构算力节点或集群调度：明确资源需求的定向调度，根据异构算力的标识，进行定向的调度决策；-基于负载均衡策略进行节点间调度：在异构算力节点间通过应用轮询法、随机法、源地址哈希法、加权轮询法等负载均衡的算法，有效地提高计算资源的利用率，减少系统等待时间和响应时间，提高系统的整体性能和效率。在具体的应用场景中，根据应用的特定需求和优化目标以及当前算力基本情况，选择一种或多种不同的调度机制。另一方面，产业界当前的另一研究热点方向是节点内混合异构计算系统内异构算力的协同。目前 GPU 为应用最广泛的 AI 芯片，除此16之外 FPGA、NPU、ASIC 等形态的算力也被广泛应用于不同的使用场景。在混合异构系统的调度中，由于 CPU 负责对计算机的硬件资源进行控制调配，也要负责操作系统的运行，计算系统中仍是不可或缺的，GPU、FPGA 等芯片都是作为 CPU 的加速器而存在。主流的混合异构系统包括面向 CPU GPU 架构的混合异构系统，程序的串行部分在 CPU 上运行，而并行部分则在 GPU 上运行，是该种混合架构调度技术的核心思想。CPU 和 GPU 的结合刚好可以解决深度学习模型训练在 CPU 上耗时长的问题，提升深度学习模型的训练效率，同时共享内存空间，消除冗余内存副本来改善问题，处理器不再需要将数 据 复 制 到 自 己 的 专 用 内 存 池 来 访 问/更 改 该 数 据；面 向CPU GPU DPU 架构的混合异构系统，DPU 参与的混合架构的调度，其核心是将任务从 CPU“卸载”，释放了宝贵的 CPU 资源，使得更多 CPU 核心可用于处理应用程序，从而大大提高数据中心的效率，减少了能源浪费，降低成本，除此之外，还有面向 CPU TPU 架构的混合异构系统等。当前混合异构系统所涉及的异构算力资源间的调度多是在节点内或者是片间完成的，对于在跨节点间甚至广域分布式的范围实现这样的调度还有很多技术难点需要攻克。（三）分布式异构算力的度量和标识（三）分布式异构算力的度量和标识不同应用对算力的需求不同，异构算力支撑同一应用也具有较大的性能表现差异性，因此对分布式异构算力的度量和标识，也将进一步提高算力的细粒度管理能力，提升整体算力使用效率。在算力的度量方面，业界目前已经开始了对异构算力度量的研究17和标准化工作。在 CCSATC1 中立项了 算力网络异构算力资源度量指标、算力网络算力节点能力度量及评估方法的标准，从设备静态参数、动态度量指标和综合性能指标对算力指标进行不同维度的评估。设备静态参数反映了从设备硬件自身设计和生产的标称能力，动态度量指标反映了异构算力在动态情况下瞬时的处理能力，而综合性能指标则是从浮点运算能力等角度出发对算力进行综合评估。也有相关研究从逻辑运算能力、并行运算能力和神经网络计算能力的评估三方面对异构算力进行评估和度量。其中，逻辑运算能力是一种通用的基础运算能力，以 CPU 为代表。由于 CPU 芯片需要大量的空间去放置存储单元和控制单元，相比之下计算单元只占据了很小的一部分，所以它在大规模并行计算能力上极受限制，而更擅长于逻辑控制。度量单位一般的可以用 TOPS 来衡量其运算能力；并行计算能力是指专门为了处理如图形图像等数据类型统一的一种高效计算能力，典型的硬件芯片代表如 GPU，从架构来看，GPU 有数量众多的计算单元和超长的流水线，常用浮点运算能力来衡量；神经网络计算能力主要针对近年来 AI 神经网络、机器学习类密集计算型业务进行加速的能力，例如 TPU、NPU 等。在算力的标识方面，异构算力标识为算力调度、算力溯源、算力交易的基础，产业界也已经开始对算力标识的整体架构开展相关研究，对异构算力形成统一的能力抽象，并提供相应的接口服务，供算力调度或者算力交易等模块或平台调用。四、当前业界技术实现情况四、当前业界技术实现情况18异构 AI 算力的管理和调度平台，能够兼容适配多种形态智能 AI硬件，实现硬件与计算要求有效对接、异构算力在节点间灵活调度、同时协同提供智算相关处理流程，将各类异构算力协同处理来发挥最大的计算效力，为多样化 AI 应用场景提供高性能、高可靠的算力支撑。当前产业界的各种智算平台已经对异构算力的管理和调度开展了不同技术方向的探索。（一）中国移动智算体系实现异构资源池化中国移动智算体系实现异构资源池化中国移动智算中心基于移动云底座的 IaaS 能力，管理算力基础设施层的各类硬件资源，向上提供智算类业务所需任务式服务，构建一体化的 AI 新型智算体系。在整体方案上，智算中心划分为大模型训练池、小模型训练池及推理池。中国移动将在小模型训练池中，采用自研的容器基础设施EKI 叠加相关池化模块，通过基于 API 劫持的池化技术，实现 CPU、GPU/AI 芯片、块存储/文件存储资源等基于高速无损网络的统一管理与调度，实现对智能算力的几大关键能力。包括算力的精细化分配，根据 AI 任务的资源需求进行按需供给，契合多样化业务的差异需求，19基于高速无损网络，跨节点调取 GPU、AI 芯片等智能算力资源，使能 CPU 传统算力及 GPU、AI 芯片智能算力高度解耦，进一步降低碎片化比例，同时支持资源根据负载变化的动态分配、回收，支持全局资源可以适度超分，促进资源效率提升。该技术方案持实现资源跨节点远程调用、零散资源整合等，从而达到算力资源充分利用、碎片最小化效果，可有效提升资源效率，降低智算中心整体建设成本。（二）浪潮 AIStation 平台实现异构资源管理调度（二）浪潮 AIStation 平台实现异构资源管理调度浪潮人工智能平台提供统一的主流深度学习框架（Tensorflow、Pytorch、Caffe、Mxnet、PaddlePaddle）开发训练平台以及计算资源(CPU、GPU、内存、存储)管理的平台，简称 AIStation。通过 AIStation，可以实现物理计算资源（CPU、GPU、内存、存储）的统一管理与监控，实现基础资源服务管理,快速开展人工智能相关业务的开发和部署。关于异构算力的接入和管理关于异构算力的接入和管理，AIStation 人工智能开发平台实现对基础设施的统一管控、形成资源池，由 Kubernetes 系统统一调度。20AIStation 人工智能开发平台可为用户分配使用配额。AIStation 提供了插件化设计，能够实现包括 GPU、寒武纪、昇腾 Ascend、天垓等异构加速卡的配置化接入。平台默认接入 GPU 资源，接入其他加速卡资源时，平台 UI 会自动适配展示。AIStation 接入加速卡后，能够通过平台发起训练任务、开发环境、模型测试等计算任务，并能够对加速卡进行监控报警、也对加速卡的使用情况自动进行适配统计展示。关于异构算力的调度关于异构算力的调度，AIStation 人工智能开发平台调度系统提供资源分配能力，在提高集群资源利用率的同时，尽可能的提高任务的性能，目前支持的可调度资源包括 CPU、内存、GPU、IB 卡。架构图如下所示：21目前 AIStation 调度器支持的主要策略包括：Gang scheduling：提交 Job 后，只有当满足 Job 中全部 Task 的需求时，才会调度成功，否则全部 Task 会处于 pending 状态，等到资源充足时，全部 Task 才会完成调度。网络拓扑调度：支持集群管理两种网络类型：IB 网络和以太网网络，同时支持按照接入交换机进行调度，尽量将任务调度在一个交换机内，避免跨交换机的通信损耗。GPU 共享调度：提供 GPU 细粒度调度，允许多个任务指定 GPU显存，调度到同一张 GPU 卡，从而实现 GPU 卡的复用，提高 GPU卡的使用率。提交任务时指定需要几个 GPU 卡，每个 GPU 卡需要占用多少显存量。指定主机调度：创建任务时，允许指定一组主机，任务只能允许被调度到这组主机内。紧急任务调度：内置紧急任务队列，用户提交的训练任务带有紧急任务队列属性时，会将该紧急任务放到该紧急队列，在紧急任务队列的任务有最高的调度优先级，调度器在处理完全部的紧急任务后，才会处理其他任务。用户组公平调度：提供基于用户组公平的调度机制，业务层创建不同的用户组，调度器会为每个用户组创建对应的调度队列，相同用户组的用户提交的训练任务会进入同一队列，调度器循环选择每一个用户组的任务进行调度。GPU 细粒度调度：GPU 卡整块显存按预置显存粒度大小分割为多22个粒度切片，即对 GPU 卡显存进行切片隔离。提交任务时指定需要切片的显存粒度大小（如：4G 或 8G 等），和显存粒度分片数量。作业就会调度到合适显存粒度切片的 GPU 卡上。GPU 负载调度：调度器采集并统计集群节点的 GPU 卡负载数据，数据包括 GPU 利用率和 GPU 显存利用率。调度器根据节点 GPU卡负载信息执行作业调度，为作业计算性能考虑，优先选择 GPU负载较低的节点和 GPU 卡。数据集亲和性调度：调度器处理更新集群节点已缓存的数据集信息，根据节点缓存数据集和作业所需数据集信息执行作业调度，优先选择作业所需数据集匹配命中缓存数据集的节点。超时任务优先调度：若一个任务因资源不足而继续等待调度，就开始对同一资源组中“比它优先级低并调度成功的任务”计数。如果计数达到阈值后该等待任务仍然未得到足够资源，则在同一资源组中，优先调度这个等待任务。该特性保证在资源紧张的情况下请求资源较多的任务也能及时调度成功。（三）新华三傲飞平台实现异构资源管理调度（三）新华三傲飞平台实现异构资源管理调度H3C 傲飞高性能计算管理平台（Advanced Management Platformfor HPC andAI 简称 AMPHA）基于 Kubernetes 和 Slurm 自主开发的AI和HPC资源一体化管理的集群管理平台，支持在不改变AI和HPC用户习惯的前提下，实现 AI 和 HPC 资源的灵活调配管理。实现了AI 和 HPC 两个业务模块的统一调度、统一用户用户组管理、统一文件文件夹管理、统一计费、统一监控告警，实现了 AI 和 HPC 业务23的融合。傲飞平台支持精细化的 GPU 管理，支持 GPU MIG 切分，支持vGPU 和显存分割。支持多种调度策略，包括 FIFO、Gang、抢占、回填、QoS 优先级、Best Fit、Spread 等，充分挖掘集群的算力。傲飞平台基于兼容 Kubernetes 的基础自研容器服务平台为底座，向下封装对各类异构资源的统一管理，向上提供标准 Kubernetes集群环境和 API，以运行各核心组件，实现资源运维管理、AI 任务调度和弹性伸缩、工作流编排、AI 作业生命周期管理、各种 AI 制品管理、统一运维等服务。再向上针对 AI 生产流程（MLOps）中的主要环节，支持 AI 数据集管理，AI 模型开发、训练、评测，以及模型推理服务。而且通过同样的组件和工具，也可以支持云上 AI 服务、开源 AI 框架和第三方 AI 能力的集成。AI 模块支持异构计算资源（CPU、GPU、AISC 卡）管理、容器管理。支持对于不同形态的算力资源进行约束限制，对用户使用的CPU、GPU、内存、显存以及存储空间支持配额约束，防止个别用户长24期过度占用系统资源，平台也实现了对各异构算力节点资源的状态监控、统计分析和告警。五、总结与展望五、总结与展望随着以算力和网络为核心的新型基础设施体系的加快构建，算力多样化、泛在化已成为必然的趋势，实现分布式异构算力的管理和高效灵活调度，将进一步释放硬件资源优势，增强算力的整体利用率。在异构算力的管理调度方面，依然有待持续攻关，例如对异构算力的度量和评测，跨异构算力的应用适配等问题，逐步构成异构算力从硬件到软件的开放生态，增强行业应用能力，持续、有效的赋能智算产业的发展。25术语与缩略词表术语与缩略词表英文缩写英文全称中文全称GPUgraphics processing unit图形处理器FPGAFieldProgrammableGateArray现场可编辑门阵列ASICApplicationSpecificIntegrated Circuit用于供专门应用的集成电路芯片技术CUDAComputeUnifiedDeviceArchitecture由NVIDIA推出的通用并行计算架构AIArtificial Intelligence人工智能MLOpsModel Learning Operations 用于创建机器学习和人工智能解决方案并提高其质量的有用方法FIFOFirst In First Out先入先出26参考文档：参考文档：1 中国算力发展指数白皮书（2023 年），http:/ 中国综合算力评价白皮书（2023 年），http:/ 浪潮 AIStation 人工智能开发平台，https:/ 新华三傲飞算力平台，https:/ 中国移动 NICC 新型智算中心算力池化技术白皮书，https:/ 中国移动算力网络白皮书，https:/ 中国移动算力网络技术白皮书，https:/ 阳王东，王昊天，张宇峰，林圣乐，蔡沁耘 异构混合并行计算综述 计算机科学9 异构算力统一标识与服务白皮书，中国联通算力网络产业技术联盟

0人已浏览 2024-01-11 26页 5星级

2023年12月?03?04?05?06?07?08?09?10?11?12?13?14?15?16?17?18?19?20?21?22?23?24?25?26?27?28?29?30?31?32?,1其中，表示时间的变量，表示在 时刻下最终产品的产出量，表示在时刻下的外生技术创新水平；为封闭经济体中的算力资本平均存量，表示时刻下生产最终品所使用的物资资本量，用以表示经济体中的算力资本对非算力资本所产生的协同效应；表示 时刻下生产最终品所使用的算力资本量，表示 时刻下生产最终品所使用的算力服务；参数,1?0,1 分别表示非算力资本、算力资本、算力服务的产出弹性。生产函数中同时体现了算力资本的协同效应和互补替代效应，对算力资本求偏导数可以得出算力资本的边际生产率为：33?41其中，表示时间的变量，表示在 时刻下最终产品的产出量，表示在时刻下的外生技术创新水平；为封闭经济体中的算力资本平均存量，表示时刻下生产最终品所使用的物资资本量，用以表示经济体中的算力资本对非算力资本所产生的协同效应；表示 时刻下生产最终品所使用的算力资本量，表示 时刻下生产最终品所使用的算力服务；参数,1?0,1 分别表示非算力资本、算力资本、算力服务的产出弹性。生产函数中同时体现了算力资本的协同效应和互补替代效应，对算力资本求偏导数可以得出算力资本的边际生产率为：?11,?0,1从上式中可知，伴随算力资本的不断积累，经济体中的算力资本平均存量不断增加，所产生的协同效应不断增加；由于?0,1，即10，算力资本的边际生产率递减，满足稻田条件（Inada Conditions），因此可知算力资本与非算力资本对经济增长的影响机制类似，即当算力资本投资总量较少时，算力资本的边际生产率较高，而算力资本的不断积累，其边际生产率也不断降低，最终算力资本的边际生产率收敛至零，经济实现稳态增长。同样，对算力服务求偏导数可以得出算力服务的边际生产率为：1?,?0,1从上式中可知，算力服务的边际生产率递减，同样满足稻田条件（InadaConditions），因此可知当算力服务投入生产较少时，算力服务的边际生产率较高，而伴随算力服务在生产过程中的不断深化，其边际生产率也不断降低，最终算力服务的边际生产率收敛至零，经济实现稳态增长。稻田条件（Inada Conditions）：是指当生产要素投入趋于 0 时，其边际生产率趋于无穷；当生产要素投入趋于正无穷时，其边际生产率趋于 0，且生产函数满足：00 的初始条件。41时刻下生产最终品所使用的物资资本量，用以表示经济体中的算力资本对非算力资本所产生的协同效应；表示 时刻下生产最终品所使用的算力资本量，表示 时刻下生产最终品所使用的算力服务；参数,1?0,1 分别表示非算力资本、算力资本、算力服务的产出弹性。生产函数中同时体现了算力资本的协同效应和互补替代效应，对算力资本求偏导数可以得出算力资本的边际生产率为：?11,?0,1从上式中可知，伴随算力资本的不断积累，经济体中的算力资本平均存量不断增加，所产生的协同效应不断增加；由于?0,1，即10，算力资本的边际生产率递减，满足稻田条件（Inada Conditions），因此可知算力资本与非算力资本对经济增长的影响机制类似，即当算力资本投资总量较少时，算力资本的边际生产率较高，而算力资本的不断积累，其边际生产率也不断降低，最终算力资本的边际生产率收敛至零，经济实现稳态增长。同样，对算力服务求偏导数可以得出算力服务的边际生产率为：1?,?0,1从上式中可知，算力服务的边际生产率递减，同样满足稻田条件（InadaConditions），因此可知当算力服务投入生产较少时，算力服务的边际生产率较高，而伴随算力服务在生产过程中的不断深化，其边际生产率也不断降低，最终算力服务的边际生产率收敛至零，经济实现稳态增长。稻田条件（Inada Conditions）：是指当生产要素投入趋于 0 时，其边际生产率趋于无穷；当生产要素投入趋于正无穷时，其边际生产率趋于 0，且生产函数满足：00 的初始条件。34?42间品厂商处于垄断市场，其根据最终品厂商对算力服务的需求来租赁算力资本用以生产满足最终品生产的算力服务。假设算力资本产出算力服务的产出系数为1/，设定其生产函数形式为：1其中，为 时刻下最终品厂商对算力服务的需求，为 时刻下为满足算力服务需求所需要投入的算力资本。对中间品厂商而言，租赁算力资本的价格与最终品厂商租赁算力资本的价格相等，否则对于家庭部门的居民而言存在资本套利机会。根据垄断市场的厂商定价准则（边际利润等于边际成本），可以求得算力服务的单位租赁成本为：1其中，为算力资本的单位租赁价格。（二）家庭部门对于本模型中，家庭部门的居民属于消费和储蓄部门。最终产品的一部分用于居民的消费（），未被消费的部分用于储蓄转化为投资（），即。在总投资中，假设用于算力资本的投资比重为（01），用于非算力资本421/1其中，为 时刻下最终品厂商对算力服务的需求，为 时刻下为满足算力服务需求所需要投入的算力资本。对中间品厂商而言，租赁算力资本的价格与最终品厂商租赁算力资本的价格相等，否则对于家庭部门的居民而言存在资本套利机会。根据垄断市场的厂商定价准则（边际利润等于边际成本），可以求得算力服务的单位租赁成本为：1其中，为算力资本的单位租赁价格。（二）家庭部门对于本模型中，家庭部门的居民属于消费和储蓄部门。最终产品的一部分用于居民的消费（），未被消费的部分用于储蓄转化为投资（），即。在总投资中，假设用于算力资本的投资比重为（01），用于非算力资本112135?111max0?d6?37

0人已浏览 2024-01-08 38页 5星级

段晓东中国移动算网一体定义算力网络未来算网一体定义算力网络未来2通信网络正加速向新型信息通信网络演变通信网络正加速向新型信息通信网络演变技术范式技术范式产业范式产业范式资源范式资源范式通信网络通信网络新型信息通信网络新型信息通信网络架构范式架构范式算力算力为核心的信息数据处理为核心的信息数据处理提供计算、感知、智能、安全等一体化的提供计算、感知、智能、安全等一体化的新一代信息通信服务新一代信息通信服务网络网络为核心的信息交换为核心的信息交换提供语音、短信、提供语音、短信、移动移动宽带等宽带等通信服务通信服务23中国移动算力网络发展历程中国移动算力网络发展历程中国移动算力网络白皮书中国移动算力网络白皮书算力网络是以算为中心、算力网络是以算为中心、网为根基网为根基 ，网、云、数、，网、云、数、智、安、边、端、链智、安、边、端、链（ABCDNETSABCDNETS）等深度融合、）等深度融合、提供一体化服务的新型信提供一体化服务的新型信息基础设施。息基础设施。杨杰董事长提出“算力网络”概念与愿景成为“5G 算力网络 能力中台”新型信息基础设施的关键一环发布算力网络技术白皮书，提出十大技术方向提出新概念提出新概念发布中国移动算力网络白皮书和发展倡议发布新理念发布新理念融入新战略融入新战略开创新方向开创新方向算力网络子链组建14支攻关战队联合攻关产业问题组建新战队组建新战队5G5G智慧智慧中台中台算力算力网络网络发布算力网络科技创新成果，CFITI试验网与中国算力网、中科院信息高铁联合打造科学装置构建新装置构建新装置中国移动深刻把握算力时代发展脉搏中国移动深刻把握算力时代发展脉搏，发挥运营商网络领先优势，发挥运营商网络领先优势，以网强算以网强算提出提出“算力网络算力网络”全新理念。全新理念。两年来，继往开来、开拓创新，全力推进算力网络发展两年来，继往开来、开拓创新，全力推进算力网络发展启动算力网络试验网CFITI 1.0，发布 算 网 服 务 体 系1.0打造新平台打造新平台34算力与网络跨学科交叉融合创新算力与网络跨学科交叉融合创新网络演进需求网络演进需求算力发展需求算力发展需求 从通信服务向新型信息通信服务新型信息通信服务转变 性能性能代际提升对算力提出更高要求 单一速率范式制约网络规模网络规模发展 摩尔定律下单点算力单点算力面临性能瓶颈 多样性算力多样性算力需要异构融通、互补协同 泛在算力泛在算力闲散分布，需要高效集约利用研判：算和网已经呈现双向驱动趋势，为了进一步呈现整体的能效、性能和利用率优势研判：算和网已经呈现双向驱动趋势，为了进一步呈现整体的能效、性能和利用率优势，需要算网一体化的系统思维和多学科交叉创新需要算网一体化的系统思维和多学科交叉创新算网一体=F(Computing,Network)必要条件：Network,Computing 互相影响充分条件：F(Computing,Network)=F(Computing) F(Network)限制条件:有限的Computing资源，和有限的Network资源优化目标:=G(=G(能效、性能、利用率)算为核心，网为根基，算力与网络的融合体现在算为核心，网为根基，算力与网络的融合体现在“以算促网以算促网”和和“以网强算以网强算”两个方面，两个方面，二者二者“双向驱动双向驱动”，算网交叉融合创新成为发展新范式，算网交叉融合创新成为发展新范式4算力网络能效能效性能性能利用率利用率5算网一体是算力网络的发展目标算网一体是算力网络的发展目标走过算力网络走过算力网络“泛在协同泛在协同”的重要阶段，迈入的重要阶段，迈入 “融合统一融合统一”的发展新阶段的发展新阶段5起步：起步：泛在协同泛在协同发展：发展：融合统一融合统一一站一站服务、协同运营服务、协同运营协同编排协同编排网随算动网随算动融合融合服务、统一运营服务、统一运营算网融合算网融合智能编排智能编排跨越：跨越：一体内生一体内生一体服务，模式创新一体服务，模式创新智慧内生智慧内生算网算网一体一体6算网一体主要特征算网一体主要特征设备一体设备一体以外挂或内嵌/内生的方式，形成“算力感知”、“网络感知”或“转发即计算转发即计算”的计算形态的计算形态，构建异构融合的设备硬件支持算力、网络、应用等多维资多维资源感知和调度的新协议源感知和调度的新协议，可通过网络协议扩展并携带计算信息，或者定义新型协议协议一体协议一体架构一体架构一体构建统一编程范式和异构算力抽象机制，形成一体编译链接、跨架构动态运行的基础软件架构，实现应用跨架构无感迁移应用跨架构无感迁移网络和计算服务统一入口，通过能力的相互补充和调用，面向用户提供无感知的网络无感知的网络和计算服务和计算服务服务一体服务一体算网一体原创技术深度赋能算网基础设施、编排管理、运营服务多层次一体化发展算网一体原创技术深度赋能算网基础设施、编排管理、运营服务多层次一体化发展67算网一体发展需要原创技术创新算网一体发展需要原创技术创新算力网络是算网交叉学科创新的重大契机。为构筑算力网络发展源动力，开创算力网络是算网交叉学科创新的重大契机。为构筑算力网络发展源动力，开创算网一体算网一体原创技术体原创技术体系，已形成一批系，已形成一批标志性标志性的原创技术的原创技术数据快递数据快递突破广域传输性能瓶颈空芯光纤空芯光纤新型光纤介质与系统在网计算在网计算打破算网边界全调度以太全调度以太突破无损以太性能瓶颈算力度量算力度量打破单维算力指标移动算力移动算力5G、6G新增计算面算力路由算力路由突破互联网架构协议存算一体存算一体突破冯氏架构算力原生算力原生实现应用跨架构迁移400G/800G400G/800G超高速大容量全光网络G-SRv6G-SRv6统一IP承载协议算力卸载算力卸载多算力形态统一底座算力并网算力并网实现算力供给侧改革新一代新一代SD-WANSD-WANUnder与Overlay协同算力解构算力解构应用模块化解构部署算力智能内生算力智能内生计算要素创智能服务空天地一体空天地一体突破异构算网融合隐私计算隐私计算安全数据分析计算应用感知应用感知应用类型识别OTNOTN光电联动光电联动新型全光网架构全光接入全光接入新型接入网架构云原生云原生敏捷高效体系总线互联总线互联卡间高速通信50G PON FTTR50G PON FTTR新型接入网架构算网一体算网一体“5 5颗珍珠颗珍珠”：算力原生、全调度以太、算力路由、在网计算、数据快递：算力原生、全调度以太、算力路由、在网计算、数据快递78算网一体需要解决的核心技术问题算网一体需要解决的核心技术问题81构筑新型智算中心的问题构筑新型智算中心的问题传统无损以太存在性能天花板，网络技术成为AI算力瓶颈，通过创新以太网转发机制，以网强算构建无阻塞、高带宽、低时延的新型智算中心网络。23大规模数据广域高效传输大规模数据广域高效传输的问题的问题针对传统协议吞吐随着传输距离、丢包率增加而急剧下降问题，设计新型可靠传输协议，实现长肥网络下超高吞吐数据传输。面向网络和计算的联合优化问题面向网络和计算的联合优化问题基于互联网协议体系，在路由中引入算力因子，开创算力路由协议，实现距离向量和计算向量在路由技术的叠加，满足新型业务网络和计算的时延需求。算力路由算力路由CATSCATS突破互联网架构协议全调度以太全调度以太GSEGSE突破无损以太性能瓶颈数据快递数据快递GSNGSN突破广域传输性能瓶颈91 1、算力路由、算力路由CATSCATS（1/1/3 3）AR/VR AR/VR 时延需要低于时延需要低于20ms20ms保障用户体验，包括：保障用户体验，包括：传感器采样延迟：1.5ms（客户端）显示刷新延迟：7.9ms（客户端）GPU的帧渲染计算延迟5.5ms5.5ms（服务器）网络延迟（预算）=20-1.5-7.9-5.5=5.1ms5.1ms（网络）结论：结论：需要同时考虑网络和计算资源状态，进行路由协议层面的联合优化需要同时考虑网络和计算资源状态，进行路由协议层面的联合优化典型场景典型场景1 1：Computing-Aware AR/VRComputing-Aware AR/VR典型场景典型场景2 2：Computing-Aware V2XComputing-Aware V2X 通过算力路由在本地优先优先处理低时延业务（如辅助驾驶业务），保证其用户体验和可用性 将时延不敏感时延不敏感业务（如车载娱乐业务）从本地调度到远端算力路由将算力路由将算力因子算力因子引入路由域，实现引入路由域，实现网络和计算的联合优化网络和计算的联合优化，克服面向边缘计算的，克服面向边缘计算的“性能反转性能反转”问题，问题，满足时延和计算敏感新型业务需求满足时延和计算敏感新型业务需求9 观察观察1 1：计算延迟和网络时延在同量级：计算延迟和网络时延在同量级 观察观察2 2：仅根据网络或计算负载选择服务节点，总：仅根据网络或计算负载选择服务节点，总 时延时延无法满足无法满足 观察观察3 3：根据两者选择边缘站点：根据两者选择边缘站点3 3，总延迟，总延迟19.4ms19.4ms101 1、算力路由、算力路由CATSCATS（2 2/3 3）在距离矢量上叠加算力向量，改变选路方法，影响路由决策。简单叠加将导致路由不收敛算力信息维度较多，需要定义面向路由调度的高可用性计算信息，兼顾报文封装成本以及可用性构建算力路由信息表（CA-RIB），考虑距离因子、算力因子以及权重，生成算网cost=w1*网络cost w2*算力cost技术方向：技术方向：新型算网多因子算路算法新型算网多因子算路算法提出分域通告、分类通告，约束算力信息更新的范围，减少算力信息的无效通告。通过仿真建模量化分析算力信息通告信令开销的影响技术方向：简单高效的算力信息封装技术方向：简单高效的算力信息封装通告频率越高，算力信息越实时，但开销越大，如何找到通告信令开销与信息实时性的平衡点技术方向：自适应技术方向：自适应的算力通告的算力通告问题问题3 3：路由求解，多维因子路由优化问题：路由求解，多维因子路由优化问题问题问题2 2：合理的算力信息通告问题：合理的算力信息通告问题问题问题1 1：算力度量问题：算力度量问题统一量纲，使用与网络和业务相同的度量维度信息，应用于路由调度，例如通过BGP Path Attribution扩展封装计算时延信息ABCE网络节点ABCE连接算力的网络节点网络拓扑算力网络节点拓扑算力网络状态拓扑网络节点ABCE连接算力的网络节点算力节点算力节点能力通告能力通告算力节点算力节点状态通告状态通告网络节点算力路由需要解决算力扩展、算力信息通告、多因子路由求解等多方面的问题，实现基于网络因子算力路由需要解决算力扩展、算力信息通告、多因子路由求解等多方面的问题，实现基于网络因子和计算因子的联合路由和计算因子的联合路由10111 1、算力路由、算力路由CATSCATS（3 3/3 3）20022年年5 5次研讨会次研讨会20232023年年3 3月月 CATS CATS WGWG成立暨首次会议，成立暨首次会议，是路由域最受欢迎的工作组之一是路由域最受欢迎的工作组之一完成场景和需求立项完成场景和需求立项推动面向推动面向AIAI大模型大模型的算力路由场景写入的算力路由场景写入CATS WGCATS WG标准标准 基于CATSCATS的分布式推理 基于CATS AICATS AI的内容获取AI-based Media Distribution and Traffic Steering完成实验系统，验证完成实验系统，验证全局时延优化上约全局时延优化上约300%的性能提升的性能提升合力合力攻关算力路由技术，围绕攻关算力路由技术，围绕IETF CATSIETF CATS构建标准体系，推动产业构建标准体系，推动产业生态生态加速构筑领先优势加速构筑领先优势历经历经4 4年，中国移动在年，中国移动在IETFIETF发起成立算力路由工作组发起成立算力路由工作组(CATS,Computing-Aware Traffic Steering)(CATS,Computing-Aware Traffic Steering)，中国移动担任主席，是中国移动担任主席，是IETFIETF路由域路由域近近2020年年由中国高校由中国高校/公司牵头成立的公司牵头成立的两个两个工作组之一工作组之一11122 2、全调度以太、全调度以太GSEGSE（1/1/3 3）集群有效算力集群有效算力GPUGPU单卡算力单卡算力*总卡数总卡数*线性加速比线性加速比*有效运行时有效运行时网络可用性决定网络可用性决定GPUGPU集群稳定性集群稳定性2%2%的丢包就会使的丢包就会使RDMARDMA吞吐率下降为吞吐率下降为0 0网络设备能力决定网络设备能力决定GPUGPU集群组网规模集群组网规模芯片容量提升芯片容量提升2 2倍，组网规模提高倍，组网规模提高4 4倍倍随着随着GPUGPU单卡算力受限，获得同等算力的难度持续增加，以网强算成为提升大模型训练效率的关键单卡算力受限，获得同等算力的难度持续增加，以网强算成为提升大模型训练效率的关键网络性能决定网络性能决定GPUGPU集群算力加速比集群算力加速比GPUGPU集群性能集群性能 单单GPUGPU性能性能*N NAIAI大模型以大模型以GPUGPU集群分布式训练为基础，带来大量节点间通信消耗，集群分布式训练为基础，带来大量节点间通信消耗，网络成为网络成为AIAI算力算力“瓶颈瓶颈”智算中心建设进入快车道，网络技术发展已滞后于智算中心建设进入快车道，网络技术发展已滞后于AIAI模型演进，模型演进，新型新型AIAI网络方案成为业界创新焦点网络方案成为业界创新焦点12132 2、全调度以太、全调度以太GSEGSE（2 2/3 3）从从“局部局部”决策决策到到“全局全局”调度调度从从“流流”分发到分发到“报文报文”分发分发从从盲发盲发 被动控制被动控制到到感知感知 主动控制主动控制将业务流拆分到不同“报文容器”转发，提供逐“报文容器”负载均衡机制，提升带宽利用率从被动拥塞控制，到基于“授权请求和响应机制”的主动流控，最大限度避免网络拥塞产生全局视野的转发调度机制，实现集中式管理运维、分布式控制转发，提高网络可用性当前：逐流负载，链路利用率低、发生拥塞被动降速当前：逐流负载，链路利用率低、发生拥塞被动降速未来：逐报文容器转发，链路负载均衡，全局调度，避免拥塞未来：逐报文容器转发，链路负载均衡，全局调度，避免拥塞创新以太网转发机制，实现创新以太网转发机制，实现三大核心机制转变三大核心机制转变源leafSpineSpineSpine目的leaf2213213拥塞21321321丢包中国移动提出全调度以太网（中国移动提出全调度以太网（GSEGSE）技术架构，最大限度兼容以太网生态，创新基于报文容器（）技术架构，最大限度兼容以太网生态，创新基于报文容器（PKTCPKTC）的转发及）的转发及调度机制，构建无阻塞、高带宽、低时延的新型智算中心网络，形成标准开放的技术体系，助力调度机制，构建无阻塞、高带宽、低时延的新型智算中心网络，形成标准开放的技术体系，助力AIAI产业发展产业发展 13142 2、全调度以太、全调度以太GSEGSE（3 3/3 3）全调度以太网（全调度以太网（GSEGSE）特设组研究）特设组研究范畴范畴2023.2023.1111云网智联大会发布云网智联大会发布全调度以太网技术架构白皮书全调度以太网技术架构白皮书中国算力大会正式启动中国算力大会正式启动全调度以太网（全调度以太网（GSEGSE）推进计划）推进计划中国网络大会发布中国网络大会发布业界首款业界首款GSEGSE原型系统原型系统CCSACCSA成功立项成功立项全调度以太网总体技术要求全调度以太网总体技术要求2023.2023.6 62023.2023.8 82023.2023.9 92023.52023.5ODCCODCC冬季全会冬季全会GSEGSE工作组成立工作组成立及第一次工作组会议及第一次工作组会议低延迟FEC、光交换、故障快速检测、400G/800G以及更高速率接口物理层扩展等改进的PFC、GSE高级调度技术、链路级安全、链路级容错等新型网络拓扑、新型路由协议、新型组播协议等改进的RDMA、新型拥塞控制协议、网络多路径能力、乱序重排、选择性重传等运维和管理体系端到端网络可视化、可调试能力、部署/运维/变更/故障恢复等多维自动化能力物理层数据链路层网络层传输协议层中国移动，中国信息通信研究院，中国广电、华为、盛科、中兴、锐捷、新华三、浪潮信息、Intel、Broadcom、清华大学、上海交通大学、鹏城实验室、紫金山实验室、北京邮电大学、中科院计算机网络信息中心、中信科、Spirent、是德科技、云合智网、楠菲微电子、燧原科技、昆仑芯、迈普，星云智联、云脉芯联、中科驭数、云豹智能、大禹智芯、中盈优创等四十余家产学研机构及厂商全调度以太网（全调度以太网（GSEGSE）合作伙伴）合作伙伴中国移动携手中国信通院，联合国内外三十余家主流互联网，设备商、芯片商、高校院所联合发起中国移动携手中国信通院，联合国内外三十余家主流互联网，设备商、芯片商、高校院所联合发起GSEGSE推进计划，推进计划，推动智算中心网络推动智算中心网络技术创新、标准完善和产业应用技术创新、标准完善和产业应用，打造高速无损、开放兼容的新型智算中心网络技术体系，打造高速无损、开放兼容的新型智算中心网络技术体系 14153 3、数据快递、数据快递GSN(1/2)GSN(1/2)数据量大数据量大单次传输在单次传输在TBTB级别级别天文观测：几十TB/次基因测序：TB100TB/次影视渲染：10TB100TB/节目传输距离远传输距离远属于长肥网络（属于长肥网络（LFNLFN）带宽时延积（BDP）大网络传输带宽：10Gbps传输时延：20ms50ms网络复杂多样网络复杂多样设备异构、拓扑复杂，难以无损设备异构、拓扑复杂，难以无损链路层误码率不可避免大象流负载不均，存在拥塞丢包多流竞争，存在微突发丢包传统传统TCPTCP协议在数据快递中吞吐受限，有效吞吐与链路时延、丢包率成反比协议在数据快递中吞吐受限，有效吞吐与链路时延、丢包率成反比TCPTCP网络吞吐网络吞吐=1.221.22*MSSMSSRTT RTT*Sqrt(L)Sqrt(L)单流传输时，时延由单流传输时，时延由1ms1ms增加到增加到10ms10ms时，时，吞吐下降吞吐下降约约1010倍倍使用多流传输会使单流使用多流传输会使单流吞吐下降吞吐下降，且受主机，且受主机CPUCPU性能限制，同样存性能限制，同样存在吞吐瓶颈在吞吐瓶颈RFC 3649:HighSpeed TCP for Large Congestion Windows8条流并发传输，单流吞吐下降7%算力分布的不均衡以及智算、超算业务的蓬勃发展对广域数据传输提出更高要求，中国移动提出算力分布的不均衡以及智算、超算业务的蓬勃发展对广域数据传输提出更高要求，中国移动提出“数据快递数据快递”技术体系，充分利用技术体系，充分利用高带宽高带宽网网络络实现实现高吞吐高吞吐数据传输数据传输15163 3、数据快递、数据快递GSN(GSN(2 2/2)/2)基于基于UDPUDP协议设计新型可靠传输协议协议设计新型可靠传输协议贵州到北京贵州到北京“数据快递数据快递”测试测试贵州FAST北京国家天文台传输距离远传输距离远2200km广域长肥网络测试结果：新型传输测试结果：新型传输协议是传统协议是传统TCPTCP协议吞吐的协议吞吐的1 18 8倍倍（单流吞吐：7.94Gbps vs 424Mbps）新型传输协议设计，消除端侧吞吐瓶颈新型拥塞控制算法，提升网络有效利用率丢包快速恢复算法，降低数据传输尾时延丢包精确重传机制，降低丢包对吞吐影响端到端多路径传输，实现带宽聚合与均衡5 5大大核核心心技技术术基于新型传输协议，构建基于新型传输协议，构建“数据快递数据快递”技术体系，实现超长距广域网环境下的超高吞吐数据传输技术体系，实现超长距广域网环境下的超高吞吐数据传输物理层物理层互联网协议层（互联网协议层（IPIP）应用层应用层新型可靠新型可靠传输协议传输协议广域拥塞控制机制广域拥塞控制机制丢包精确重传丢包精确重传用户数据报协议用户数据报协议层层（UDPUDP）API API 编程接口编程接口丢包快速恢复丢包快速恢复多路径传输多路径传输联合产、学、研共同推动联合产、学、研共同推动“数据快递数据快递”产业成熟产业成熟第二届中国算力大会发布技术白皮书CCSA TC3推动关键技术行标立项链路时延长链路时延长RTT45ms链路带宽大链路带宽大10Gbps网络类型复杂网络类型复杂云专网/传输网/DC1617多举措推动算网一体技术和产业发展多举措推动算网一体技术和产业发展17打造打造算力网络试验示范网（算力网络试验示范网（CFITICFITI）构建算力网络构建算力网络产业链合作产业链合作机制机制“1 9 9”“1 9 9”节节点点布局布局“A-B”“A-B”双平面双平面协同互促协同互促“三大装置互联三大装置互联”科学装置科学装置打造打造多节点互联、双平面互促的算力网络试验示范网多节点互联、双平面互促的算力网络试验示范网（CFITICFITI），并与），并与“中国算力网中国算力网”、“信息高铁信息高铁”等互联，等互联，面向基础学科和前沿技术创新形成面向基础学科和前沿技术创新形成技术支撑平台技术支撑平台以以“补强建延补强建延”为指导思想，构建为指导思想，构建产业支撑平台产业支撑平台，成立多种，成立多种攻关战队开展协同攻关，提升产业链韧性和竞争力，推动算攻关战队开展协同攻关，提升产业链韧性和竞争力，推动算力网络产业繁荣发展力网络产业繁荣发展四维一体、链式牵引四维一体、链式牵引编队作战，协同创新编队作战，协同创新四大工作组算网应用算力基础设施网络基础设施算网服务和协同省专协同联合研发研采协同五大协同创新机制 协同创新基地以网强算，算网一体，以网强算，算网一体，以学科交叉融合范式创新，以学科交叉融合范式创新，领航智算产业未来新发展领航智算产业未来新发展

0人已浏览 2024-01-08 18页 5星级

2023 云安全联盟大中华区版权所有1 2023 云安全联盟大中华区版权所有22023 云安全联盟大中华区保留所有权利。你可以在你的电脑上下载.储存.展示.查看及打印，或者访问云安全联盟大中华区官网（https:/www.c-）。须遵守以下：（a）本文只可作个人.信息获取.非商业用途；（b）本文内容不得篡改；（c）本文不得转发；（d）该商标.版权或其他声明不得删除。在遵循 中华人民共和国著作权法相关条款情况下合理使用本文内容，使用时请注明引用于云安全联盟大中华区。2023 云安全联盟大中华区版权所有3 2023 云安全联盟大中华区版权所有4致谢致谢云原生可观测性技术研究与应用由CSA大中华区云原生安全工作组内企业云原生可观测性白皮书项目组专家撰写，感谢以下专家的贡献：项目组组长：王亮主要贡献者：高巍陈磊浦明郑伟申屠鹏会杨文宏刘刚李卓嘉谢奕智研究协调员：罗智杰闭俊林贡献单位：北京沃东天骏信息技术有限公司安易科技(北京)有限公司北京神州绿盟科技有限公司中国工商银行股份有限公司天翼云科技有限公司(以上排名不分先后)关于研究工作组的更多介绍，请在 CSA 大中华区官网（https:/c- CSA GCR 秘书处给与雅正!联系邮箱 researchc-；国际云安全联盟 CSA 公众号 2023 云安全联盟大中华区版权所有5序言序言2018 年，可观测性（Observability）被引入 IT 领域，CNCF-Landscape 率先出现了 Observability 的分组。自此以后，“可观测性”逐渐取代“监控”，成为云原生技术领域最热门的话题之一。Gartner 发布的2023 年十大战略技术趋势中，提到了可观测性的发展趋势解读。文中谈到：“可观测性应用使企业机构能够利用他们的数据特征来获得竞争优势。它能够在正确的时间提高正确数据的战略重要性，以便根据明确的数据分析结果采取快速行动。可观测性是一种强大的工具。如果能够在战略中予以规划并成功执行。可观测性应用将成为数据驱动型决策能力建设的最强支撑。”本白皮书介绍了可观测性在云原生场景的架构设计，阐述在云原生场景使用 eBPF技术完成可观测性数据采集的技术实现及优势。云原生可观测性的应用场景涵盖了事件根因分析、安全溯源分析等主要内容，旨在阐述云原生可观测性的生产实践。云原生场景业务弹性变化节奏加快、工作负载生命周期缩短、工作负载直接的访问关系更加复杂。在轻量、多变、短生命周期的云原生环境获得足够多的数据，得以对事件根因进行分析，对入侵行为进行溯源，对未知威胁进行预测，是将可观测性能力运用至云原生安全领域后带来的安全能力提升。这也是可观测性对云原生场景安全的价值体现。希望通过本白皮书为读者深入浅出的介绍云原生可观测性及云原生可观测性对安全能力的赋能。使得广大云原生基础设施运维者、云原生业务使用者能够借鉴本文的评估自身系统云原生可观测性的成熟度及发展战略。李雨航 Yale LiCSA 大中华区主席兼研究院院长 2023 云安全联盟大中华区版权所有6目录致谢.4序言.51.可观测性概述.81.1 云原生可观测性发展.81.2 可观测性定义.92.云原生可观测性成熟度.102.1 监控.112.2 基础可观测性.112.3 因果可观测性.142.4 主动可观测性.183.云原生观测体系能力构建.213.1 云原生可观测性信号.213.2 云原生可观测能力构建.283.3 核心能力-基于 eBPF 构建云原生数据采集技术.334.云原生可观测性应用场景.404.1 故障分析.404.2 事件预测.404.3 日志审计.414.3 监控.474.4 微服务追踪.50 2023 云安全联盟大中华区版权所有74.5 安全检测分析.535.优秀云原生可观测项目介绍.565.1 Prometheus 项目.565.2 OpenTelemetry 项目.595.3 SkyWalking 项目.63附件.引用文献.67 2023 云安全联盟大中华区版权所有81.可观测性概述可观测性概述1.1 云原生可观测性发展云原生可观测性发展CNCF 云原生定义对云生技术描述为：在现代动态环境（如公有云、私有云和混合云）中构建和运行可扩展的应用程序的能力。容器、服务网格、微服务、不可变基础设施和声明性 API 均是基于云原生技术的特征。采用云原生技术使松散耦合的系统具有弹性、可管理和可观察性。结合强大的自动化功能，能够以最少的工作量频繁且可预测地进行高影响力的更改。Pivotal 公司 Matt Stine 在 2013 年首次提出云原生概念。2017 年 Matt Stine将原生特征归纳为六大点，分别是：模块化 Modularity可观测性 Observability可部署性 Deployability可测试性 Testability可处理性 Disposability可替换性 Replaceability 2023 云安全联盟大中华区版权所有9作为六大特征之一的可观测性是保证云原生应用稳定性的基础。在云原生时代，应用规模不断扩大，复杂度愈来愈高，而其中潜藏的问题和风险也随之增多。这对支撑平台及业务自身的稳定性提出更高要求。能够支撑业务的快速迭代、故障快速响应能力、适应复杂的微服务拓扑、保证高效运维。在数字化大趋势下，云计算成为企业数字化转型的关键。以云上开发为核心的云原生技术得到了广泛的使用。云原生在企业上云和基础实施架构上的大量应用，也对企业的运维监控安全提出了新的挑战。分布式、解耦合的新型系统架构，服务调用链长、系统行为复杂、软件系统稳定性保障困难，解决以上问题需要采用新的方式对系统进行观测。1.2 可观测性定义可观测性定义在控制理论中，“可观测性是从系统外部输出的数据衡量系统内部状态的程度”。可观测性是人类对机器可以观察、理解和处理所述系统状态的功能。可观测性是在没有考虑目标的情况下决定系统在实现时应该具有哪些输出。在 IT 领域，可观测性是在日志与监控指标组成的传统监控基础上，依据由日志、指标、链路追踪三种核心数据来洞悉系统运行状态。通过统一的链路追踪洞察系统服务调用链，并与日志、指标数据联动分析，可实现对云原生系统的高效故障定位与故障解决，保障云原生系统稳定性。2023 云安全联盟大中华区版权所有10可观测性具有三个方面的特征，首先是度量能力，可观测性的度量能力能够帮助使用者在系统处于非常极端复杂的场景时，也能理解和解释系统当前的状态。其次是探索分析，可观测性不应该预定调试/排查模式和路径，而应该能够自由地对所有采集到的各类状态数据在各种维度和组合之间进行关联分析，不断探索分析出新的关联性。最后是按需改变，可观测性最好是在不改变原有代码的情况下，按需进行埋点。2.云原生可观测性成熟度云原生可观测性成熟度研究可观测性成熟度模型的目标是提供一种可衡量、可复制的理论基础用以评估、改进可观测性体系能力。遵循 PDCA 模型通过对可观测性能力持续改进，提高对云原生系统的感知能力，缩短运维过程中寻找根因、排除故障的时间。衡量和评估云原生系统可观测性的成熟度模型，可定义为如下四个级别：Level 1 监控（Monitoring）Level 2 基 础 可 观 测 性（Basic Observability）Level 3 因 果 可 观 测 性（Causal Observability）Level 4 主动可观测性（Proactive Observability）可观测性成熟度模型的每个级别，建立在前一级别已实现的基础上。2023 云安全联盟大中华区版权所有112.1 监控监控2.1.1 目标：确定系统组件是否按预期正常工作目标：确定系统组件是否按预期正常工作可观测性成熟度模型中，监控是第一个阶段。此阶段对资产、进程、资源使用等数据持续采样、度量和记录，获取实时或定期的信息和数据。跟踪单个系统组件的特定参数，度量系统组件状态。系统组件运行状态如超出预设范围，触发警报、状态更改、通知。监控级的目标之一是设置实时警报，在系统出现问题或达到预定阈值时能够及时报警。2.1.2 能力能力在 Level1 阶段，被监控的系统各组件之间无相关性，此级别主要目标是了解系统组件是否正常工作。监控级会开始对基本的性能数据进行采集，以确保系统在负载情况下不会受到显著影响。监控级的主要目标是建立起最基本的监控能力，以确保系统的基本稳定性和可用性。关键功能：系统输入：事件和组件级指标系统输出：报警、日志价值：获得基本信息，系统组件的健康状态出现问题时的警报和通知2.2 基础可观测性基础可观测性 2023 云安全联盟大中华区版权所有122.2.1 目标：确定系统故障目标：确定系统故障可观测性通常指基于对复杂系统外部输出的了解，能够了解其内部状态或状况的程度。系统越可观测，定位问题根本原因的过程就越快速越准确，而无需进行额外的测试或编码。为保证复杂动态的系统可靠运行，需要知道系统组件是否正常运行，还需要了解它为什么不运行。当出现问题时，希望遵循“5W1H”的原则了解问题详情：who、when、where、what、why、how。Level1 监控措施基于预置规则实现告警、通知。预置规则依赖于一个关键性的假设，即能够在问题发生之前预测将会遇到的问题类型。这种方法不能覆盖足够多的场景，无法回答 5W1H 的问题。云原生环境是动态的、复杂的、多变的，无法事先预知可能会出现什么样的问题。因此云原生应用下的可观测性方案，应可以根据更完整、更深入的可观测性数据，实时感知事件，并提供定位可能无法预料的问题根因的能力。可观测性成熟度 Level 2 相较于 Level 1 的数据具有更大的广度和深度。可观测性系统主要关注三种关键类型的数据来提供系统洞察力：指标、日志和跟踪。可观测性的这三大支柱是从微服务、应用程序、数据库、云原生基础设施中收集的，旨在提供对系统行为的更为完整的视图。每种数据提供不同类型的信息：2023 云安全联盟大中华区版权所有13指标：指标：了解服务性能和状态的数值测量-四个黄金信号：延迟、流量、错误率和饱和度。日志：日志：了解系统在给定时间点的行为-统中发生的相关事件（例如事务、警告、错误）的时间戳记记录追踪：追踪：解决性能问题-显示数据如何从端到端流经应用程序的详细快照（例如，用户请求）可观测性强调数据的统一性，通过构建统一的平台来实现指标、日志和跟踪数据的汇聚与处理，突破单点工具的能力限制。建设统一数据平台可将各种可观测性工具整合在一个集中的界面，提高管理和维护系统的效率。通过手工关联数据来推断事件的可疑原因，需要跨系统手动查询。在 Level 2中，尚未涉及自动化方法来统一和关联来自各种工具汇聚的孤立数据，准确定位问题的根本原需要大量的人力投入。2.2.2 能力能力Level2 阶段，理解可观测性数据之间的关系，将上下文数据结合。关键功能：系统输入：Level1 链路、指标、日志系统输出：Level1 图标、日志可视化综合仪表盘 2023 云安全联盟大中华区版权所有14价值：通过从更多来源收集数据，更深入、广泛、全面地了解整个系统健康状况，更好地支持问题诊断除已知故障类型外，还能够发现未知故障模式从各种类型的数据中获得有益的洞察力-例如，跟踪有助于识别性能瓶颈，指标可提供出色的 KPI，日志可用于查找软件缺陷。2.3 因果可观测性因果可观测性2.3.1 目标：确定问题根本原因影响面及规避方法目标：确定问题根本原因影响面及规避方法可观测性的核心价值在于提高排查问题的效率。可观测性工具通过分析数据，定位问题，进一步确认问题的根本性原因（Root Cause）。可观测性体系用于因果判断，可以更深入全面地理解系统的运行和行为，得出系统中事件之间的因果关系。通过对因果关系分析理解，找出引发问题的根本性原因。具备因果分析能力的可观测性体系可定义为“因果可观测性（CausalObservability）”。具备因果分析能力的可观测性体系，通过收集、分析和解析足够多维度的数据，达到理解系统内事件、状态变化之间的关系，从而更深入地洞察系统运行状态。因果可观测性强调在数据分析中寻找因果关系，并将这些关系转化为对系统事件之间关系的可视化呈现。2023 云安全联盟大中华区版权所有15因果可观测性与基础观测性有所不同，Level2 强调数据，Level3 强调关系。Level2 基础可观测性关注收集、分析数据以理解系统的状态和行为，Level3 因果可观测性强调数据与数据、实体与实体、事件与事件或更多维度数据之间的联系。构建因果可观测性，涉及数据收集、关系收集、数据处理、关系处理、因果推断等步骤，以揭示事件发生的因果过程。面对复杂性、不确定性和变化性的云原生应用场景，对事件因果的理解有助于更好地预测、解释、优化和管理系统。调查故障根因时，需收集事件发生的时间、空间、参数变化等数据，从而了解导致问题出现、传播，以及随着时间的推移而变化的事件状态。解决这些问题，需要引入新的能力：网络数据、拓扑数据、时间、空间地图、自动化关联技术。这些能力可以更全面地理解系统运行状态，定位问题的根本原因。为了建立因果可观测性，需要补充两种类型的数据要素：拓扑、时间。拓扑系统中各实体对象相互之间的连接关系（例如根据链路相关数据绘制的服务拓扑）时间持续抓取观测数据的时间维度表 1 两种类型数据要素拓扑是因果可观测性的第一个必要维度。拓扑是因果可观测性的第一个必要维度。拓扑是 IT 环境中所有组件的映射，它跨越所有层，从网络到应用程序再到存储，显示一切是如何相关的。拓扑结合了组件之间的逻辑依赖性、物理接近性和其他关系，以提供人类可读的可视化和可操作的关系数据。2023 云安全联盟大中华区版权所有16拓扑信息（Topology）指的是系统中各主机、进程、容器、API、Service 之间的关系和连接方式。拓扑的价值在于提供系统的高级视图，帮助运维者理解不同实体之间的依赖关系、通信路径和层次结构。通过拓扑信息，能够更全面清晰地了解系统结构。拓扑信息在可观测性数据中扮演着一种定位和上下文的角色，辅助理解数据所涉及的组件、服务、资源以及它们之间的关系。拓扑信息是一个系统的结构图，展示了系统内部各个元素之间的连接和依赖关系。这种结构图可以是物理上的（如网络拓扑、主机之间的连接），也可以是逻辑上的（如服务之间的依赖关系、数据流动路径）。将信息点连接至系统元素，使得每个维度的数据不是孤立的点。时间是因果可观测性的第二个必要维度。时间是因果可观测性的第二个必要维度。在充满微服务、云资源和容器不断变化的动态环境中，拓扑信息的变化是非常迅速的。系统状态可能在问题多次出现的过程中发生变化。为了确立因果可观测性，需要引入一个至关重要的维度：时间。为了深入了解现代 IT 环境的动态行为并获取实现因果可观测性所需的上下文。随着时间的推移，捕获拓扑信息的变化，并将其与可观测性数据进行关联，以跟踪整个堆栈的变化。当出现问题时，可以回溯到问题开始的确切时间点，并查看是什么变化导致了这个问题。通过这种时间维度的关联，能够更准确地定位问题的根本原因，实现对问题的全面分析和解决。2023 云安全联盟大中华区版权所有17空间地图是拓扑的升维，提供 IT 环境中所有元素的关系映射，空间地图是一张三维的元素连接拓扑，涵盖水平的实体关系拓扑，垂直的依赖关系拓扑。空间地图结合了组件之间的逻辑依赖性、物理邻近性和其他关系，以提供可读的可视化和可操作的关系数据。水平拓扑：在相同类型的元素之间建立的连接关系地图，如进程到进程、服务到服务、主机到主机垂直拓扑：在不同类型的元素之间建立的连接关系地图，如数据中心到主机、主机到进程、进程到服务、服务到应用程序通过技术实现水平层、垂直层的空间地图，自动化、实时性的绘制，将可观测性数据与空间地图的实体关联，拉动时间轴，展示随时间变化的空间拓扑、关联数据，能够比较变化前后的系统状态，是可观测性能力的集中式成果体现。2.3.2 能力能力拓扑可以极大地提高因果判定的准确性和有效性，Level 3 对空间地图的引入是重大的进步。关键功能：通过拓扑为指标、链路、流量、日志提供上下文，随事件推移关联相关数据，追踪变化；系统输入：Level1 Level2 网络 拓扑 时间 2023 云安全联盟大中华区版权所有18系统输出：Level1 Level2 空间拓扑 数据关联 时序变化价值：通过统一时间序列拓扑中的孤立数据，获得统一、清晰、相关的环境状态上下文视图通过拓扑可视化和分析了解因果关系，显着加快根本原因识别和解决时间基本自动化调查的基础，例如根本原因分析、业务影响分析和警报关联自动将与同一根本原因相关的警报集中在一起，从而减少噪音和干扰所需的上下文2.4 主动可观测性主动可观测性2.4.1 目标：自动输出问题根因、自动化响应，智能预测、主动预防目标：自动输出问题根因、自动化响应，智能预测、主动预防Level 4 主动可观测性，典型特征是引入“AIOps”技术，通过自动化和智能化的方法实现更深入更准确的洞察力，将传统的被动式运维转变为主动式运维。将人工智能（AI）和机器学习（ML）技术融入到可观测性体系中。在这一阶段中，更加强调分析结果和答案，而不仅仅关注原始数据和分析过程。主动可观测性将分析结果呈现给用户，并辅助决策和采取行动。2023 云安全联盟大中华区版权所有19Level4 主动可观测性建立在该成熟度模型中因果可观测级别的核心功能之上。Level4 阶段添加了模式识别、异常检测和更准确的问题修复建议。对于主动可观测性而言，因果可观测性是一个必要的基础：时间序列拓扑提供了一个必要的框架。数据是原材料，原材料经过分析之后得出的答案。快速的把高质量结果和答案传达出来，快速做出决策、采取行动，是主动可观测性需要重点考虑的问题。任何一套可观测性解决方案或建设可观测性体系之前，都应解决三个最本质的问题：通知：通知：在问题出现并造成影响前后，能够在多快的时间内得到通知？诊断：诊断：能迅速地对问题进行分类，了解影响？理解：理解：如何找到潜在的原因以快速解决问题？AIOps 利用因果关系，使用基于拓扑驱动的渐进式故障树分析算法。AIOps具备强大的拓扑绘制能力，实时获得基础架构、流程和服务依赖关系的可视化关系，更好地理解系统的运行情况和交互关系。AIOps 依托拓扑地图、云原生系统产生的数据进行分析，能显示一个事件在垂直和水平方向的拓扑依赖关系，能够自动确定异常问题的根源。2023 云安全联盟大中华区版权所有20在 Level 4 阶段，目标是关注更高效且无事故的 IT 运维。可观测系统基于AI/ML 算法模型，感知服务或组件偏离正常行为的趋势，并在出现故障之前采取措施规避问题。对未发生事件的预测能力是 Level4 阶段可观测系统的典型特征。2.4.2 能力能力Level 4，目前是 IT 技术领域中最高的可观测性成熟度级别。需要拓扑和时间提供的额外上下文，准确评估根本原因、确定业务影响、检测异常并主动确定何时提醒 SRE 和 DevOps 团队。关键功能：系统输入：Level1 Level2 Level3 大数据分析/ML 模型系统输出：Level1 Level2 Level3 空间拓扑 自动化 RCA 预测价值：自动根因定位、自动化 RCA、告警降噪、预测异常；借用 Gartner 2022 年 3 月“Innovation Insight for Observability”文章中的一段话作为本章总结：“发现异常很容易，因为它们一直都在发生。当每天收集十亿个事件时，每两分钟就会发生一百万分之一的事件。可观测性工具的关键是发现与手头问题相关的异常，然后从可能相关的日志文件/指标中链接其他信息。通过在上下文中显示相关信息，操作员可以更快地找出问题的潜在根本原因。”Gartner“Innovation Insight for Observability”，2022Mar，PadraigByrne&Josh Chessman.2023 云安全联盟大中华区版权所有213.云原生观测体系能力构建云原生观测体系能力构建3.1 云原生可观测性信号云原生可观测性信号云原生可观测性的实现依赖于监控指标/监控度量（Metrics）、事件日志（Logs）和链路追踪（Traces）三种数据类型。这三种数据各有侧重，不是完全独立，三种数据之间有重合或者可以结合之处。图 1 三种数据类型3.1.1 指标指标 2023 云安全联盟大中华区版权所有22指标是数据的数字表示形式。它们分为两大类：已经是数字数据和提炼（聚合）成数字的数据。前者的一个例子是温度，后者例如在 Web 服务器上观察到的 HTTP 请求计数器。数字是存储数据的最有效方式，随着时间的推移，所有成熟的行业都趋向于指标优先。指标的典型示例用例-衡量主机（例如虚拟机）堆内存使用情况的仪表。我们称之为“堆内存字节”。指标由一个名称、一组标签（有时称为属性或标签）和每个时间点的数值（例如每秒一个值）组成。每个具有特定名称和标签的指标实例通常称为“时间序列”或“流”。3.1.2 日志日志事件日志（Logging）：日志的职责是记录离散事件，应用运行过程会持续输出日志数据，这些日志数据是业务系统运行状态的各种事件及业务处理逻辑时输出的，通过这些记录事后分析出程序的行为，基本上可以还原业务流程处理的全过程。事件日志可以详细解释系统的运行状态，但是存储和查询需要消耗大量的资源。日志是描述操作系统、应用程序、服务器或其他设备中的使用模式、活动和操作的一个或多个文本条目。日志可以分为不同的类别，例如：应用程序日志-应用程序内部事件创建的记录。日志可帮助开发人员了解和评估应用程序在运行过程中的行为模式。2023 云安全联盟大中华区版权所有23安全日志 事件与系统中检测规则匹配后创建对该事件的记录。包括登录失败、密码更改、资源访问、资源更改、策略更改、发生时间。安全管理员通过安全日志可回溯与检测规则匹配的事件。系统日志-系统日志记录操作系统中的事件，包括处理物理和逻辑设备的内核级消息、引导顺序、用户或应用程序身份验证以及其他活动、故障、资源状态消息。审核日志-事件和更改的记录。记录执行活动人员、执行活动内容以及系统如何响应。系统管理员根据业务需求确定审核日志收集内容。安全管理员可根据审核日志回溯人员对系统的使用。基础架构日志-涉及管理影响组织 IT 基础的物理和逻辑设备。在本地或云中通过 API、Syslog、主机代理收集获取。日志记录应用程序或系统在发生故障时的状态,在执行根本原因分析时，这些记录特别有价值。存储在日志中的信息是自由格式的文本，因此很难得出含义。在过去的 30 年中，已经进行了许多尝试将架构应用于日志，但它们尚未特别成功。使用统一架构的原因使提取相关信息更易于访问。通常是通过解析、分段和分析日志文件中的文本来完成的。日志数据还可以转换为其他可观测性信号，指标和跟踪。一旦数据成为指标，它就可以用于了解随时间的变化。日志数据还可以通过日志分析技术进行可视化和分析。基于对数据获取不同颗粒度，日志可设置不同级别:“错误”、“警告”、“信息”和“调试”。错误是最不详细的日志级别，调试是最详细的日志级别。2023 云安全联盟大中华区版权所有24错误：错误：传达发生情况并详细说明发生故障的原因警告：警告：需要注意的高级消息，不一定是失败信息消息：消息：系统的工作状态调试：调试：存储每个操作的详细信息。通常，仅在故障排除期间或具备充足得存储或性能而短期使用。3.1.3 追踪追踪链路追踪（Tracing）：链路追踪大都是依据谷歌在 2010 年发表的论文Dapper:a Large-Scale Distributed Systems Tracing Infrastructure Dapper 理论来实现的，调用链记录的是串联单个事务内全过程的日志数据，通过对请求打标、透传、串联，最终可以还原出一次完整的请求，可以帮助工程师轻松分析出请求中异常点。但是链路追踪和事件日志一样有着相同的问题就是资源消耗较大，通常也需要通过采样的方式减少数据量。为了有效地进行分布式追踪，Dapper 提出了追踪（Trace）与跨度（Span）两个概念：追踪（Trace）：从客户端发起请求抵达系统的边界开始，记录请求流经的每一个服务，直到到向客户端返回响应为止，这整个过程就称为一次追踪。2023 云安全联盟大中华区版权所有25跨度（Span）：由于每次 Trace 都可能会调用数量不定、坐标不定的多个服务，为了能够记录具体调用了哪些服务，以及调用的顺序、开始时点、执行时长等信息，每次开始调用服务前都要先埋入一个调用记录，这个记录称为一个跨度。Dapper 使用以跨度为基本树节点的跟踪树构建跟踪模型，并为每个跨度记录了一个可读的 span name,span id,parent id，这样就能重建出一次分布式跟踪过程中不同跨度之间的关系。没有 parent id 的跨度被称为根跨度。一次特定跟踪的所有相关跨度会共享同一个通用的 trace id。换句话说每一个追踪实际上都是由若干个有顺序、有层级关系的跨度所组成一颗追踪树（Trace Tree），如下图 2 所示：图 2 追踪树11图片引用自 Google Dapper:a Large-Scale Distributed Systems Tracing Infrastructure 2023 云安全联盟大中华区版权所有26追踪（Tracing）通常表示一个具体的事务实例，即计算机通过特定程序的路径，使它们成为可观察性中的详细且昂贵的信号。跨度（Spans）高度情境化，需要进行上下文关联。除此之外，跨度（Spans）还记录有关启动它的“父”跨度（Spans）的信息。这使得在分布式系统的不同参与者（如服务、队列、数据库等）之间建立因果关系成为可能。3.1.3.1 基于日志的追踪数据收集基于日志的追踪数据收集基于日志的追踪的思路是将 Trace、Span 等信息直接输出到应用日志中，然后根据收集到的日志数据，从全局日志信息中反推出完整的调用链拓扑关系。基于日志的追踪数据收集的优点在于其对网络消息完全没有侵入性，对应用程序只有很少量的侵入性，对性能影响也非常低。但其缺点是直接依赖于日志归集过程，日志本身不追求绝对的连续与一致，这也使得基于日志的追踪往往不甚精准。另外，业务服务的调用与日志的归集并不是同时完成的，也通常不由同一个进程完成，有可能发生业务调用已经顺利结束了，但由于日志归集不及时或者精度丢失，导致日志出现延迟或缺失记录，进而产生追踪失真。Dapper 的跟踪记录和收集管道实现如下图所示，共分为三个阶段：1.把 Span 数据写入到本地日志文件2.Dapper 守护进程和采集器从主机中将日志他们拉取出来3.将拉取出的日志写入 Dapper 的 Bigtable 仓库中，其中 Bigtable 中的行表示一次跟踪，列表示一个 span。2023 云安全联盟大中华区版权所有27图 3 Dapper 工作流程23.1.3.2 基于服务的追踪数据收集基于服务的追踪数据收集基于服务追踪的实现思路是通过某些手段给目标应用注入追踪探针（Probe），通过探针获取服务调用信息并发送给链路追踪系统。探针在结构上可视为一个寄生在目标服务身上的小型微服务系统，它一般会有自己专用的服务注册、心跳检测等功能，有专门的数据收集协议，把从目标系统中监控得到的服务调用信息，通过另一次独立的 HTTP 或者 RPC 请求发送给追踪系统。基于服务的链路追踪劣势在于比基于日志的追踪消耗更多的资源，也有更强的侵入性。基于服务的链路追踪优势为这些资源消耗换来收益的直接结果是精确性与稳定性均有所保证，从而不必再依赖日志归集作为追踪数据的来源。基于服务的追踪被 Zipkin、SkyWalking、Pinpoint 等追踪系统广泛采用。2图片引用自 Google Dapper:a Large-Scale Distributed Systems Tracing Infrastructure 2023 云安全联盟大中华区版权所有283.2 云原生可观测能力构建云原生可观测能力构建3.2.1 信号关联信号关联有两种基本方法可以关联数据：运维人员建立或者利用现有数据建立相关性。应该对所有的信号使用相同的元数据结构。尽可能对日志使用相同的标签。如有必要，运维人员可自建标签，附加到所有类型信号的数据。连续收集所有可观测性信号，每条数据的范围都标记为某个时间戳。在不同的维度上，每个可观测性信号都需要绑定到某个“目标”，能够查看目标的指标、跟踪和日志三个维度可观测性数据。通过一致的元数据来切换来自同一目标（例如，同一应用程序）的可观测性信号。利用基于拉取的系统，如 Prometheus 或 OpenTelemetry Prometheus 接收指标，利用日志收集器（OpenTelemetry、Fluentd、Fluentbit）收集日志。确保收集器附加一组一致的目标标签或属性，例如“集群”、“namespace”、”label“、“Pod”。在处理 OTLP（指标、日志和跟踪）等多维度集合数据时，应用附加目标标签信息，确保数据一致性。运维人员可以基于相同的标签，在不同的可观测性信号之间切换。允许从每个信号中选择与特定过程、组件、时间相关的信息，从而快速浏览具有相同标签信号的细节内容。2023 云安全联盟大中华区版权所有29日志中共享与请求相关的相同信息（请求 ID、操作 ID）。确保日志记录和跟踪的这些 ID 是相关联的，从而确保数据可基于事件请求 ID 紧密地相互关联。运维人员能够通过跟踪绑定到单条日志的请求 ID 标签，快速定位日志。3.2.2 典型业务架构典型业务架构可观测性业务架构可分为以下五层（数据源、数据采集层、数据存储层、应用展示层、智能化层）。五层架构可作为可观测性建设的内容，也是当前大多数企业正在实践的部分。典型可观测性业务架构如下图 4 所示：2023 云安全联盟大中华区版权所有30图 4 典型可观测性业务架构3.2.2.1 数据源数据源可观测的数据源大致可分为几大类，硬件、操作系统与网络以及软件。硬件如服务器的硬盘、电源、风扇和主板等；网络设备如交换机、路由器和网关等设备；安全设备如防火墙；机房设施如空调、电力等；这些硬件在运行时都会产生状态数据。操作系统其实也是一种软件，由于其特殊性这里将其单独归类，操作系统内会有 CPU、内存、存储相关的使用和状态数据，操作系统间会有通信的网络数据。软件包含集群编排系统、Docker 运行时、DB、中间件、业务软件。3.2.2.2 数据采集数据采集对数据进行分析总结出三种独立的数据类型，分别从三个不同的维度来展示应用的状态，这三种数据类型分别是日志数据（Logging）、链路数据（Tracing）和指标数据（Metric）日志是记录了发生在运行中的操作系统或其他软件中的事件。常见于事件日志、事物日志、消息日志等，而与可观测性相关主要就是事件日志。事件日志（Event logs）记录了在系统运行期间发生的事件，以便于了解系统活动和诊断问题。它对于了解复杂系统的活动轨迹至关重要，尤其是只有很少用户交互的应用程序（例如服务器应用程序）。目前，许多企业使用 CNCF 推荐的 Fluentd 作为主要的日志数据采集工具。此外还有一些企业采用 Filebeat 和 Logstash。2023 云安全联盟大中华区版权所有31链路追踪即调用链监控，特点是通过记录多个在请求间跨服务完成的逻辑请求信息，帮助开发人员优化性能和进行问题追踪。链路追踪可以捕获每个请求遇到的异常和错误，即时信息和有价值的数据。链路追踪的技术选型目前在 CNCF中主要有的 Jaeger，SkyWalking 或 Zipkin 几种工具供选择。指标数据是应用程序运行时产生的内部指标，以 API 接口的方式提供查询。指标数据具有时间点的特性，不同的时间点对应的指标是不同的，因此用以存储指标数据的数据库一般称为时序列数据库。3.2.2.3 数据存储数据存储采集到的数据需要进行处理并进行存储，为下一步的数据应用和展示提供数据基础。一般场景日志数据和链路追踪数据存储可使用 ElasticSearch、ClickHouse等非关系数据库。在大规模日志采集场景下可以添加 Kafka 作为缓冲。对需要进行大数据分析等场景时，也可以选择 HDFS/HBase 存储。对于指标数据推荐使用 Prometheus 存储（Prometheus 本身也实现了 TSDB数据库），但是原生的 TSDB 对于大数据量的保存及查询支持不太友好，该数据库不能保证可靠性，且无法支持 Prometheus 集群架构。而 Thanos 和 Cortex都是在数据可靠性和集群高可用方面进行了优化和增强，目前都是 CNCF 孵化中的项目，也是不错的选择。在大规模场景下还可以选择 openTSDB 或Clickhouse 来进行指标数据存储。3.2.2.4 数据展示数据展示 2023 云安全联盟大中华区版权所有32展示层是对采集数据的基础应用，也是当前企业主要的应用场景。图表展示是可观测性面向用户最为直观的呈现，将复杂的数据以图或表形式展示出来，便于运维人员快速了解应用状态，基于经验做出判断或预测。对于日志数据和链路追踪数据的查看可以通过 Kibana 查看，对于指标数据可使用 Grafana 进行展示，也可以使用原生的 Prometheus、Thanos 或 Cortex 查看。服务拓扑是通过数据流向和调用关系，以 UI 的方式将服务依赖关系拓扑呈现出来。实际业务中，应用之间的关联与依赖非常复杂，需要通过全局视角检查具体的局部异常。可以在服务拓扑查看应用在指定时间内的调用及其性能状况。监控告警是最常用的场景，也是目前建设可观测系统的核心目标。监控告警通过事前配置好阈值，数据采集上来后通过计算与阈值比对，对于不符合规则要求的数据生成告警事件，通过告警渠道发送到目标设备。对于可观测性数据的应用除以上几项外，还可尝试将三者的数据进行关联，使同一个应用不同维度的事件立体化的展示出来。如请求发生异常时，应用一般会将请求以日志的方式输出，调用链路也会上报调用异常，这两类数据可以通过RequestID 或 TraceID 进行关联。3.2.2.5 智能化智能化将人工智能和大数据应用于可观测性，辅助运维实现自动化、智能化，以达到业务服务高效稳定运行的目的。2023 云安全联盟大中华区版权所有33智能分析依托大数据和人工智能技术对采集的日志、指标和链路数据进行分析，按需产生有价值的结果。智能分析的主要应用有趋势预测、根因分析和智能决策三类不同场景。趋势预测：预测可能会发生的事件；根因分析：确定事件发生的根本原因；智能决策：基于根本原因后提供智能决策的解决方案。3.3 核心能力核心能力-基于基于 eBPF 构建云原生数据采集技术构建云原生数据采集技术随着大量应用基于云原生技术进行开发、适配和迁移，应用出现微服务激增、多语言开发、多通信协议特征，系统架构复杂度越来越高，传统可观测方法存在采集数据粒度不够细致、资源消耗量大、外部代码侵入等问题。近年来，业界开始关注 linux 内核 eBPF 技术，独有特性能更有效地解决发展中问题。3.3.1 Linux 内核内核 eBPF 技术原理技术原理eBPF 起源于 Linux 内核，可以运行沙箱程序，安全有效地扩展内核功能，无需更改内核源代码或加载内核模块。eBPF 全称“扩展的伯克利数据包过滤器(Extended Berkeley Packet Filter)”，是一种数据包过滤技术，从 BPF(Berkeley PacketFilter)技术扩展而来。BPF 提供了一种在内核事件和用户程序事件发生时安全注入代码的机制，这就让非内核开发人员也可以对内核进行控制。随着 Linux 内核的发展，BPF 逐步从最初的数据包过滤扩展到网络、内核、安全、跟踪等，而且它的功能特性还在快速发展之中，这种扩展后的 BPF 被简称为 eBPF。2023 云安全联盟大中华区版权所有34eBPF 是基于寄存器的虚拟机，使用自定义的 64 位 RISC 指令集，在 Linux内核运行即时本地编译的 eBPF 程序。eBPF 程序并不像常规的线程那样，启动后就一直保持运行，它需要由事件触发后才会执行。这些事件包括系统调用、内核跟踪点、内核函数和用户态函数的调用退出、网络事件，等等。借助于强大的内核态插桩（kprobe）和用户态插桩（uprobe），eBPF 程序几乎可以在内核和应用的任意位置进行插桩。eBPF 程序通常包括 4 部分：后端代码：在内核中加载和运行的 eBPF 字节码，它将数据写入内核 map和环形缓冲区的数据结构中；加载器：它将字节码后端加载到内核中，当加载器进程中止时，字节码会被内核自动卸载;前端代码：从数据结构中读取数据，并将其显示给用户数据结构：后端和前端的通信手段。它们是由内核管理的 map 和环形缓冲区，可以通过文件描述符访问。需要在后端被加载之前创建，数据会持续存在，直到没有更多的后端或前端进行读写操作eBPF 程序的运行流程，如下图 5 所示：2023 云安全联盟大中华区版权所有35图 5 eBPF 程序的运行流程1.用户态编写 eBPF 程序2.使用 LLVM 编译成 bytecode 的 ELF 文件3.使用 bpf 系统调用，把程序加载进入内核4.内核的 verifier 会验证 eBPF 程序的合法性，确保其能够安全、合规地在内核中运行5.内核会使用 JIT compiler 把 eBPF 字节码编译成本地机器码6.eBPF 程序在内核中以 VM 方式安全运行3.3.2 基于基于 eBPF 云原生可观测性技术架构云原生可观测性技术架构 2023 云安全联盟大中华区版权所有36云原生环境中每台机器(或虚拟机)只有一个内核，所有运行在该机器上的容器都共享同一个内核，内核了解主机上运行的所有应用代码。通过对内核的检测，基于 eBPF 可以同时检测在该机器上运行的所有应用程序代码。当将 eBPF 程序加载到内核并将其附加到事件上时，它就会被触发，而不考虑哪个进程与该事件有关。eBPF 能够对基于广泛的可能来源的可视化事件的定制指标进行收集和核内聚合。基于 eBPF 在操作系统内核特性优势，与 OpenTelemetry 结合实现云原生观测数据收集处理的架构，极大增强云原生环境可观测性能力。基于 eBPF 的可观测性架构如下图 6：图 6 基于 eBPF 的可观测性架构 2023 云安全联盟大中华区版权所有37关键点在 eBPF 采集数据导入 OpenTelemetry Collector，步骤如下：1.数据接收：在 kubernetes 集群节点上基于 eBPF 的 tracepoint 和kprobe/kretprobe，将内核采集到的应用请求、系统调用、网络传输性能等数据放到内存中，在用户态 eBPF 程序读取数据，进行预处理；基于OpenTelemetry 规范实现 Receiver，以事件订阅方式接收采集数据；2.数据处理：基于 OpenTelemetry 规范实现 Processor，对采集数据进行协议解析和指标处理评估，然后填充 kubernetes metadata（元信息），实现 eBPF 采集的内核数据与 kubernetes 调度请求、上下文信息关联；3.数据导出：基于 OpenTelemetry 规范实现 Exporter 数据导出到可观测平台进行分析。基于 eBPF 实现云原生可观测性数据采集具有以下优势：1.能够采集更加全面的数据，数据指标覆盖从程序调用、网络传输性能、网络协议栈性能、服务黄金指标等各个层面；2.资源消耗占比小，eBPF 程序以本机机器指令运行，性能很高，基于内核进行数据采集，对应用零侵入、零改造；3.更加灵活具备可伸缩性，eBPF 程序可以在运行时动态附加到系统中，无需重新启动目标系统；2023 云安全联盟大中华区版权所有384.能够轻松应对容器启动、停止等动态特点，不需要任何的边车（Sidecar）侵入，直接通过内核来观测任意的容器行为。3.3.3 基于的基于的 eBPF 云原生可观测性增强示例云原生可观测性增强示例3.3.3.1 动态网络性能监控动态网络性能监控通过在每个 kubernetes节点上部署个探针eBPF程序。这个探针通过 hook内核的 accept,connect,send,recv 等 L4(TCP、UDP)相关的系统调，可以获取进程与绑定地址的关系、通信双的地址、各连接收发的流量统计。探针会去获取当前 kubernetes 集群的 metadata 数据(pid,container,pod,service,node 等)并把它们保存在内存中，丰富原始 eBPF 数据。服务端在收集到通信双的 eBPF数据后做进步数据填充，并存数据库。查询时，根据指定的时间范围、主机/服务/pod 等筛选条件查询数据库，从构造出该时段的各级别的动态拓扑图。并且基于eBPF 能进一步采集内核级底层网络可观测性黄金信号数据,如TCP网络流量、网络延迟、堵塞等数据，并建立与 kubernetes 对象关联。3.3.3.2 HTTP 黄金指标监控黄金指标监控云原生环境中有运行状况的三个关键 HTTP 黄金指标：请求速率、请求延迟、请求响应代码/错误。基于 eBPF 能够在不对应用程序进行任何更改的情况下提取这些数据，并且聚合相应的指标不是基于 IP，探针在获得络报文之后，进步解析 L7 内容，包括 HTTP、HTTPS、gRPC 等将微服务的各个会话（次请求和响应）的 URL、latency、错误码关联到服务标识。探针定期将会话聚合信息推送到服务端进步丰富数据，构建微服务链路、监控仪表盘等。2023 云安全联盟大中华区版权所有393.3.3.3 性能剖析（性能剖析（Profiling）传统工具对系统中 CPU 进行定时采样，以特定的时间间隔或速率采集正在运行的函数或堆栈跟踪的计数，估计 CPU 的时间消耗分布，这种方式需要与应用强绑定，受开发语言局限，并且在跟踪多线程、多请求应用时存在困难。基于eBPF 可以轻松地对堆栈跟踪和时间进行内核内摘要,获得系统级别特定进程的On-CPU 和 Off-CPU 事件。基于 On-CPU 事件可以绘制焰图，直观地展示各个调栈所占时间例。通过分析线程堆栈能够定位分析服务 CPU 使用率高的问题，如果堆栈被转储的次数更多，则意味着线程堆栈占用了更多的 CPU 资源，如下图 7：图 7 CPU 资源 2023 云安全联盟大中华区版权所有404.云原生可观测性应用场景云原生可观测性应用场景4.1 故障分析故障分析故障分析是云原生可观测性的最基本的应用场景，也是可观测性技术的持续发展的重要驱动力。谷歌给出可观测性的核心价值快速排障（troubleshooting）。可观测性犹如整个 IT 系统的眼睛，它是运维人员发现问题、定位问题、解决问题的第一步，同时，也是运维监控的实现“先知、先觉、先行”的重要条件。随着云原生持续发展，业务对可靠性、稳定性的要求越来越高。提前发现故障、快速发现故障、快速定位故障原因是做好稳定性的核心要素，良好的可观测性能够帮助用户在故障分析上事半功倍，有效提高业务上线运行地稳定性。在故障分析领域，云原生可观测技术协助运维人员发现故障事件，分析故障发生原因，快速定位故障根因，可极大提升云原生领域运维效率。4.2 事件预测事件预测在安全运维领域，自动化成为技术发展的趋势。系统能够完成人类根本无法完成的任务，例如通过机器学习方法，在错误或事件发生之前进行预测。实现预测能力，需要通过在可观测性系统添加人工智能层。将人工智能的大数据分析能力及结果赋能于可观测性系统，使可观测性系统在问题发生之前提供预测能力。人工智能赋能的可观测性系统，除了提供预测能力，并且可对预测发生的问题提供解决方案。在安全运维领域提升对未发生事件、未知威胁的感知能力。2023 云安全联盟大中华区版权所有41为使得可观测性系统具备更强的预测能力，需要更多的数据和更强大的算力支持，建立精确的模型和预测系统，提供更深刻的事件洞察能力。4.3 日志审计日志审计日志与审计对系统和应用行为的记录，对云原生可观测性的实现起到了重要的作用。通过日志系统获取系统以及应用的详细操作数据，是云原生可观测性重要的数据来源。针对 Docker 和 Kubernetes，分别具有对应的日志采集机制，从安全审计的角度出发，可对日志数据进行存储、归类、查询等操作处理。4.3.1 Docker 日志审计日志审计Docker 支持多种日志记录机制，用以帮助用户从正在运行的容器和服务中获取信息，这种机制被称为日志驱动程序。Docker 从 1.6 版本开始支持日志驱动，用户可以将日志直接从容器输出到如 syslogd 这样的日志系统中。每个 Docker 守护进程都有一个默认的日志驱动程序，通常这个默认的日志驱动是 json-file，也就是以 JSON 文件的形式保存日志信息。同时 Docker 还支持其他的日志驱动，比如 none、json-file、syslog 和 fluentd 等。下表 2 展示了当前Docker 支持的日志驱动格式。驱动描述none不启用 log 功能，该容器 docker logs 没有可用的日志，并且不返 2023 云安全联盟大中华区版权所有42回任何输出。local日志以自定义格式存储，旨在最大程度地减少开销。json-file日志格式为 JSON。这是 Docker 的默认日志驱动程序。syslogLinux 的系统 log 服务，将日志消息写入 syslog，确保 syslog 守护程序必须在 Docker 主机上已经运行。journaldsystemd 的 log 服务，可以代替 syslog 服务，将日志消息写入journald，journald 守护进程必须在主机上运行。gelf将 log 写入 graylog 或 Logstash 等端点。fluentd将 log 写入 fluentd，确保 fluentd 在主机上已运行。awslogs将 log 写入 Amazon CloudWatch Logs。splunk使用 HTTP Event Collector 将 log 写入 splunketwlogs将 log 写为 Event Tracing for Windows(ETW)事件，仅适用于Windows 平台gcplogs将 log 写入 Google Cloud Platform(GCP)logentries将 log 写入 Rapid7 Logentries表 2 Docker 支持的日志驱动格式 2023 云安全联盟大中华区版权所有43CIS Benchmark 对 Docker 的日志审计也提出了安全建议和要求，例如，在 CISDocker Benchmark v1.6.0 版本中，2.13 小节要求需要配置集中和远程的日志记录，以确保所有的日志记录都是安全的，进而满足容灾的需要，而具体的日志驱动程序，则可以根据自身情况进行选择。除了对容器的日志审计外，CIS Benchmark还针对 Docker 主机，提出了相关的安全审计建议。对 Docker 主机的安全审计，一方面包括了常规的对 Linux 文件系统以及系统调用等进行审计。另一方面，也包括针对 Docker 守护进程等相关内容的安全审计。例如 CIS Docker Benchmarkv1.12.0 版本中，1.1.3 小节要求，需要审计所有活动的 Docker 守护进程，可以通过 auditctl-l|grep/usr/bin/docker 命令，列出当前的审计规则，默认情况下，没有针对 Docker 守护进程的审计规则。CIS Benchmark 中除了对 Docker 守护进程提出了安全审计的建议外，还对Docker 相关的文件和目录提出了安全审计建议，例如：需要审计 Docker 文件和/var/lib/docker 目录、需要审计 Docker 文件和/etc/docker 目录、需要审计 Docker文件和 docker.socket 目录等。更多针对 Docker 详细的安全审计建议，可参考 CISDocker Benchmark 标准。4.3.2 Kubernetes 日志审计日志审计4.3.2.1 应用程序日志应用程序日志应用程序的日志记录可以更好的了解应用内部的运行状况，同时对调试问题、监控集群活动以及对应用程序运行过程的安全性分析有着非常大的作用。2023 云安全联盟大中华区版权所有44当前，大部分应用程序都有某种日志记录机制，前文已经介绍过，以 Docker为代表的容器引擎也被设计成支持日志记录的方式。针对容器化应用，最简单且最广泛采用的日志记录方式就是写入标准输出（stdout）和标准错误流（stderr）。但是，由容器引擎或运行时提供的原生日志功能，通常不足以构成完整的日志审计方案。例如，当发生容器崩溃或者节点宕机等情况时，我们通常会想访问应用的日志，这时可能就会出现问题。在集群中，日志应该具有独立的存储和生命周期，与节点、Pod 或容器的生命周期相独立。这里通常会称为集群级的日志。集群级的日志架构需要一个独立的后端用来存储、分析和查询日志。Kubernetes 当前并不为日志数据提供原生的存储解决方案，有很多现成的日志方案可以集成到 Kubernetes 中,具体可参考下 4.3.2.3 日志工具小节。4.3.2.2 系统组件日志系统组件日志在 Kubernetes 中，除了 Pod 中应用程序的日志外，Kubernetes 系统组件的日志同样需要有一定的方案来记录和存储。系统组件的日志主要记录了集群中发生的事件，这对于调试以及安全审计有着重要的作用。系统组件日志可以根据需要配置日志的粒度，灵活调整日志记录的细节程度。日志可以是只显示组件内错误这种粗粒度的，也可以是更加细粒度的，例如记录事件的每一个追踪步骤（HTTP 访问日志、Pod 状态更新、控制器操作、调度器决策等）。2023 云安全联盟大中华区版权所有45在 Kubernetes 中，系统组件根据部署运行方式的不同，可以分为两种类型：其中一种是运行在容器中的，比如，kube-scheduler、kube-proxy 等；另一种是不在容器中运行的，比如 kubelet、以及容器运行时等。在使用 systemd 机制的服务器上，kubelet 和容器运行时将日志写入到 journald 中。如果没有 systemd，它们会将日志写入到/var/log 目录下的.log 文件中。容器中的系统组件通常将日志写到/var/log 目录，绕过默认的日志机制。Kubernetes 默认使用的日志库是 klog，专门用来做日志初始化的相关操作，klog 是 glog 的 fork 版本，由于 glog 不再开发、在容器中运行有不易测试等一系列问题，所以 Kubenetes 自己维护了一个 klog,由于 Kubernetes 近期版本一直持续不断在精简系统日志组件的，因此在 Kubernetes v1.23.0 开始，klog 的一些命令行参数已经被废弃。CIS Benchmark 对 Kubernetes 的日志审计也提出了安全建议和要求，例如，在 CIS Kubernetes Benchmark v1.6.0 版本中，1.2.22 小结要求需要配置audit-log-path 路径，启动 Kubernetes API Server 的审计功能，设置合适的日志路径，进而可以获取 API Server 一系列按时间排序的与安全相关的记录。更多针对Kubernetes 详细的安全审计建议，可参考 CIS kubernetes Benchmark 标准。虽然 Kubernetes 没有为集群级日志记录提供原生的解决方案，但是Kubernetes 官方给出了几种常见的参考设计方法（Logging Architecture）4.3.2.3 日志工具日志工具 2023 云安全联盟大中华区版权所有46目前支持 Kubernetes 的日志管理工具种类也比较多，例如 Zebrium、ElasticStack、CloudWatch、Fluentd 等，这些日志管理工具都有着一个共同的目标，那就是可以尽可能高效、快速的进行日志监控、记录以及分析处理。这里我们以CNCF 项目 Fluentd 为例简单进行介绍。Fluentd 由 Sadayuki“Sada”Furuhashi 于 2011 年提出，是一个跨平台的开源数据收集器，提供了统一的日志记录层，以便更好的使用和理解数据，不过它并不是一个独立的日志管理器。这是一个非常流行的工具，有着数十个贡献者、数百个社区贡献的插件、有超过 5000 多名用户以及数以万计的事件被收集、过滤和存储，其用户包括Atlassian、Microsoft 和 Amazon 等。从架构上来看，Fluentd 创建了一个统一的日志记录层，可以更有效的使用数据，并在软件上对数据进行快速的迭代，可以每秒处理 12 万条记录。可扩展性方面，当前最大的用户集群可以从 5 万多个服务器中收集日志。因此，有着高可靠性、高可扩展性和良好的性能。2023 云安全联盟大中华区版权所有47图 8 Fluentd 日志记录层4.3 监控监控监控（Metrics）在生产系统中，是必不可少的一部分，是系统稳定运行的重要基础，尤其是在云原生环境下，良好的监控系统，对于云原生应用的高效平稳运行，起到了重要的作用。监控与日志有所不同，日志是对应用程序行为操作的一种记录，提供的是显式的数据。而监控更多的是通过数据的聚合，来对一个程序在特定时间内的行为进行衡量。监控数据是可累加的，他们具有原子性，每个都是一个逻辑计量单元，或者一个时间段内的综合数据。监控的结果可以很好的观察系统的状态和趋势，但相比较于日志和追踪，监控结果对于问题的定位缺乏细节展示。作为云原生架构的重要支撑技术平台，我们以 Kubernetes 的监控为例，来介绍云原生环境下的主要监控指标。Kubernetes 的监控一方面需要包括对整个基础架构平台的监控，另一方面包括对正在运行的工作负载的监控。具体的监控指标，根据集群的特性不同而有所差异。4.3.1 集群状态指标集群状态指标集群状态可以说是一个基本的，也是关键的监控指标，我们需要知道集群中所有的聚合资源当前的状态以及使用情况，比如节点的状态、可用的 Pod、不可用 Pod 等。2023 云安全联盟大中华区版权所有48通过对集群状态进行监控，进而对监控数据进行评估，以及由此产生的监控指标，可以让我们看到集群总体运行状况的概要视图。还可以了解到节点、Pod、Service 等相关联的问题。根据状态指标，可以判断集群的运行是否正常，是否存在相应的风险。通过监控集群状态指标，我们还可以对节点正在使用的资源数量进行评估，包括共有多少节点、有多少节点可用等信息，从而可以根据需要调整所使用节点的数量和大小。4.3.2 资源状态指标资源状态指标CPU 利用率。利用率。清晰准确地知道节点 CPU 资源的使用情况，对于保障系统以及应用的平稳、安全运行有着至关重要的作用。如果微服务应用或主机节点已分配的 CPU 资源被耗尽，那么就需要考虑增加 CPU 配额或者增加处理节点，以满足业务的正常运行。同时，针对 CPU 资源使用情况的监控，还可以通过分析资源使用行为，发现挖矿、拒绝服务攻击等针对计算资源的恶意攻击行为。内存压力。内存压力。这个监控指标展示了一个节点正在使用的内存量，通过监控数据，我们可以实时的了解整个节点内存的使用状态，防止节点因内存耗尽而对应用运行产生影响。同时，还可以通过对每个组件、应用的内存分配情况进行分析，发现内存分配异常问题，比如，哪些应用的内存分配过度、不必要地增加了节点的开销，同时高内存压力还可以初步的判断应用程序是否存在内存泄露等问题 2023 云安全联盟大中华区版权所有49磁盘压力。磁盘压力。磁盘在使用过程中，通常会设置相应的使用阈值，通过对磁盘使用情况的监控，结合既定的使用阈值，来判断节点磁盘空间的使用情况，进而确定是否需要增加额外的磁盘空间、当前应用程序的磁盘使用是否正常、是否需要对应用程序的磁盘使用进行调整等。4.3.3 网络状态指标网络状态指标对网络状态相关指标的监控，无论对于应用程序的通信还是安全，都有着重要的指示意义。基于微服务架构的云原生应用，服务间的网络通信异常频繁，只有确保通信的正常，才能保证业务系统的顺畅运行。通过监控网络状态指标（比如，带宽、速率、连接状态等），及时的发现网络出现的问题，进而对问题进行定位、处置。另外，对网络状态的监控，除了能够发现并解决网络故障问题，还可以通过对网络状态数据进行分析，判断是否存在网络层的攻击发生，比如拒绝服务攻击的检测，再比如异常网络行为的检测等。4.3.4 作业运行指标作业运行指标 2023 云安全联盟大中华区版权所有50除了对基本的基础设施资源进行监控外，我们还需要对正在运行的作业任务进行监控，保证任务的准确运行。Kubernetes 中，使用了 Job 和 CronJob 两个资源，来提供一次性任务和定时任务的特性，这两种资源使用控制器模型来实现资源的管理。Kubernetes 的 Job 可以创建并且保证一定数量 Pod 的成功停止，当Job 持有的一个 Pod 对象成功完成任务之后，Job 就会记录这一次 Pod 的成功运行。当一定数量的 Pod 任务执行结束之后，当前的 Job 就会将它自己的状态标记成结束。基于这种机制，可以有效地对 Pod 进行管理和控制，同时对这些内容进行监控，也可以发现相关的问题，比如作业失败、崩溃循环、资源耗尽等。作业失败并不一定意味着应用程序变得不可访问，但是忽略作业失败可能会导致后续部署出现更严重的问题。密切监控作业失败可以帮助及时恢复，并在未来避免这些问题。崩溃循环通常指，应用程序在 Pod 启动时崩溃，并在不断的崩溃和重新启动中循环。出现崩溃循环可能会有很多原因，通常很难确定根本原因。因此，实时对其进行监控，在发生崩溃循环时，可以快速告警，快速缩小原因列表，并采取紧急措施使应用程序处于正常状态。4.4 微服务追踪微服务追踪 2023 云安全联盟大中华区版权所有51在基于微服务的云原生架构中，客户端的一次服务调用，会产生大量的包括服务和中间件在内的众多调用关系。针对这些复杂的调用过程进行追踪，对于微服务的安全性分析、故障定位、以及性能提升等，有着重要的作用。因此，分布式追踪系统是微服务架构下不可或缺的重要组成部分。分布式追踪是实现应用链路追踪的一种重要技术手段，同时也是实现云原生可观测性的重要组成部分，其主要用于应用程序的性能分析（APM，ApplicationPerformance Management）和故障定位等。Google 在 2010 年公开其生产环境下的分布式跟踪系统 Dapper，奠定了整个分布式追踪以及 APM 模型的基础。自 Google Dapper 首先提出分布式链路追踪的设计理念以来，许多分布式追踪工具不断涌现。当前，常见的分布式追踪工具包括 Dapper，Zipkin，Jaeger，SkyWalking，Canopy，鹰眼，Hydra，Pinpoint 等，其中常用的开源分布式追踪工具为 Zipkin，Jaeger，SkyWalking 和 Pinpoint。这些分布式追踪工具大致可分为：基于 SDK、基于探针以及使用 Sidecar。基于基于 SDK 的分布式追踪工具的分布式追踪工具。以 Jaeger 为例，Jaeger 提供了大量可供追踪使用的 API，通过侵入微服务业务的软件系统，在系统源代码中添加追踪模块实现分布式追踪。此类工具可以最大限度地抓取业务系统中的有效数据，提供了足够的可参考指标；但其通用性较差，需要针对每个服务进行重新实现，部署成本较高，工作量较大。2023 云安全联盟大中华区版权所有52基于探针的分布式追踪工具基于探针的分布式追踪工具。以 SkyWalking Java 探针为例，在使用SkyWalking Java 探针时，需将探针文件打包到容器镜像中，并在镜像启动程序中添加-javaagent agent.jar 命令实现探针的启动，以完成 SkyWalking 在微服务业务上的部署。SkyWalking 的 Java 探针实现原理为字节码注入，将需要注入的类文件转换成 byte 数组，通过设置好的拦截器注入到正在运行的程序中。这种探针通过控制 JVM 中类加载器的行为，侵入运行时环境实现分布式追踪。此类工具无需修改业务系统的源代码，相对 SDK 有更好的通用性，但其可获取的有效数据相对 SDK 类工具较少。基于代理实现基于代理实现。Sidecar 作为服务代理，为其所管理的容器实现服务发现，流量管理，负载均衡和路由等功能。在流量管理过程中，Sidecar 可以抓取进出容器的网络请求与响应数据，这些数据可以记录该服务所完成的一次单个操作，可与追踪中的跨度信息对应，因此可将 sidecar 视为一种基于数据收集的分布式追踪工具。Sidecar 无需修改业务系统代码，也不会引入额外的系统的开销。但由于 sidecar 所抓取的跨度不包含追踪链路上下文，要将 sidecar 所抓取的跨度数据串联成追踪链路是很困难的。基于基于 eBPF 实现实现。eBPF 通过一种软件定义的方式,提供并支持了丰富的内核探针，同时提供了强大的动态追踪能力。开发者通过编写 eBPF 程序即可实现相应的追踪脚本，我们可以使用 eBPF 自身的实现机制，以保证在内核执行动态追踪时的效率及安全性。eBPF 结合 Opentelemetry 规范可实现微服务链路追踪，详细内容可参考前文 3.3.2 小节。2023 云安全联盟大中华区版权所有534.5 安全检测分析安全检测分析4.5.1 容器运行时检测容器运行时检测使用 eBPF 追踪技术可实时捕获云原生环境中活动容器内关键事件。包括：容器对文件的可疑访问，容器对系统的可疑调用，容器之间的可疑互访，检测容器的异常进程等，结合安全主控引擎和安全策略集可进一步对活动容器的异常行为进行取证。例如：检测容器中用户操作及可疑的 shell 脚本的执行检测容器运行时是否打开了新的监听端口或者建立意外连接的异常网络活动检测容器运行时是否存在文件系统读取和写入的异常行为，例如在运行的容器中安装了新软件包或者更新配置检测容器运行时是否创建其他进程检测容器中是否运行了黑客工具，是否存在反弹 shell 行为检测容器中是否执行了挂载系统目录操作 2023 云安全联盟大中华区版权所有54图 9 架构设计eBPF 程序：捕获系统调用、网络数据包、文件系统等业务操作的 eBPF 程序，并加载至宿主机内核中执行。数据收集模块：接收 eBPF 收集的容器内部系统调用和其他关键事件，例如创建文件、执行命令、网络通信等。这些事件可以包括正常的操作，也可能包括恶意行为或异常操作。安全主控引擎：用于接收数据收集模块的数据，并根据预定义的安全策略集检测容器内部异常行为，若命中策略则实时触发警报并进行响应。具体可包括发送通知、记录审计日志、触发自动化的安全措施等。安全策略集：定义一系列安全规则和策略，用于识别潜在的安全威胁和异常行为。这些规则可以基于特定的系统调用、文件访问、网络通信等事件，定义容器行为规范。4.5.2 微服务业务异常检测微服务业务异常检测 2023 云安全联盟大中华区版权所有55云原生环境中，可通过分布式追踪技术，实现获取 API 上下文信息及调用拓扑，这些信息可以做为检测引擎的输入源，通过业务异常检测引擎对正在运行的业务系统进行异常检测。图 10 业务异常检测引擎检测引擎具体功能介绍：分布式追踪工具分布式追踪工具。相比 Skywalking、Sidecar，Jaeger 可获取的数据字段最多，能够检测的异常场景最丰富，然而，Jaeger 需要在业务系统的源代码中进行插桩，对开发团队而言有较强的侵入性。相反，Sidecar 模式没有代码和镜像的侵入性，但通过反向代理截取流量的模式也决定了它不能获得丰富的上下文，如云原生应用的 API 调用关系树（TraceID）是无法获得的。采用 eBPF 可解决上述的侵入性问题，且更轻量级，对系统性能的影响更小。从而实现更高效的性能跟踪和监控，同时提供更多细粒度的数据收集和分析能力。2023 云安全联盟大中华区版权所有56数据筛选与整合模块数据筛选与整合模块。此模块主要功能为过滤掉数据集中的脏数据，以及提取出可以表示业务系统行为的数据。在云原生应用中，可以表示业务系统行为的数据为 API 调用关系树、服务名、操作名、HTTP POST 参数等。数据训练模块数据训练模块。将预处理后的历史数据利用机器学习或统计学的方法，训练出业务系统中的正常行为，并生成与业务系统正常行为匹配的特征数据。这里进行训练的先验知识为，我们认为业务系统中大量存在的行为是正常行为，而数量很少的行为是异常行为。在训练过程中，需要根据专家知识对训练结果的检验不断调整训练模型的参数。检测引擎检测引擎。将业务系统当前数据与特征数据库中数据进行检索匹配，并利用序列相似性计算等方法找出特征数据库中与当前行为最为匹配的特征数据。检测引擎需要将特征数据与当前数据的相似性与基线进行比较，若比较结果显示当前行为与正常行为的差异在基线限制范围内，则为正常行为，若超出基线限制范围，则判定为异常行为。对于基线，首先需要根据专家知识设置合理的初始基线，并根据不同场景，或利用无监督模型自行调整基线，或由运维人员手动维护基线。5.优秀云原生可观测项目介绍优秀云原生可观测项目介绍5.1 Prometheus 项目项目5.1.1 项目概述项目概述 2023 云安全联盟大中华区版权所有57Prometheus 是一个开源的云原生监控解决方案，用于收集、存储和处理各种指标和事件数据。它旨在解决现代应用程序架构中与传统监控系统相关的一系列挑战，如复杂性、可扩展性和平衡成本效益。Prometheus 成为了许多现代应用程序和基础设施中首选的监控解决方案，包括 Kubernetes、Docker 和 CloudNative Computing Foundation（CNCF）中的许多项目。项目于 2012 年开源，截止本文撰写日（23 年 11 月），Stars 数量高达 50K，参与的贡献者/组织达到了 838 个。Prometheus 于 2016 年加入云原生计算基金会 作为继 Kubernetes 之后的第二个托管项目。5.1.2 整体架构整体架构图 11 Prometheus 项目整体架构 2023 云安全联盟大中华区版权所有58Prometheus 的整体架构可以分为以下几个核心组件：1.Prometheus Server：Prometheus 服务端负责拉取和存储各种监控指标。它使用一种可扩展的HTTP 协议来远程访问目标设备或服务，并支持多种数据导出格式，如 JSON、CSV、Graphite 等。2.Client Libraries：客户端库用于将应用程序内部指标转换为 Prometheus 可以理解的格式。这允许开发者轻松加入 Prometheus 的数据采集功能。几乎所有的编程语言都有对应的客户端库，如 Go、Python、Java 等。3.Exporters：导出器用于将第三方服务的指标转换为 Prometheus 可以理解的格式。这使得 Prometheus 可以轻松集成和监控各种第三方服务和设备，如数据库、消息队列、文件服务器等。4.Remote WriteAgents 远程写入代理用于将采集到的指标数据发送到 Prometheus Server。它们在本地存储指标，并在接收到请求后将其发送到 Prometheus Server。5.Service Discovery：服务发现组件（如 Consul）负责在应用程序中注册和发现 Prometheus 实例。这允许将 Prometheus 部署在分布式环境中，以便收集各个服务实例的指标。2023 云安全联盟大中华区版权所有595.1.3 功能特点功能特点Prometheus 具有以下功能特点：采用多维数据模型，其时序数据由指标名称和键/值对标识；采用 PromQL，一种灵活的查询语言，可利用此语音进行数据搜索；不依赖分布式存储;单服务器节点是自治；时序收集通过 HTTP 上的拉取模型进行；支持通过中间网关推送时序数据；通过服务发现或静态配置发现目标；支持多种绘图和仪表板模式；5.1.4 定位定位Prometheus 是一个功能强大、灵活且易于扩展的云原生监控解决方案。Prometheus 作为云原生应用的监控基石，为复杂的云原生基础设施提供了稳定、高效的监控和报警能力，是云原生架构中不可或缺的组件之一。在未来几年的发展中，该项目也会是未来云原生监控发展的中坚力量。5.2 OpenTelemetry 项目项目5.2.1 项目概述项目概述 2023 云安全联盟大中华区版权所有60OpenTelemetry 项目最早于 2019 年由两个独立的项目 OpenCensus 和OpenTracing 合并而成。OpenCensus 主要关注收集和传输观测数据，OpenTracing主要关注定义和追踪分布式系统中的请求元数据信息，开源可观测性项目如Jaeger、Zipkin 均使用了其标准，然而，由于两个项目的目标和方法略有不同，缺乏统一的标准和工具，不同的应用程序和服务使用不同的观测数据格式和传输方式，导致观测数据收集变得复杂和困难。为了解决这一问题，OpenCensus 和OpenTracing 的维护者决定将两个项目整合在一起，形成一个统一的解决方案。在合并之后便形成了 OpenTelemetry 项目。OpenTelemetry 项目是一个开源的可观测性框架，用于收集、检测、分析、导出可观测数据（追踪、度量、日志）。OpenTelemetry 与其他开源云原生可观测项目无关，因而可与其联合使用，如 Jaeger、Prometheus、Fluentd 等开源工具，此外 OpenTelemetry 也作为孵化类项目入选了了云原生计算基金会(CloudNative Computing Foundation CNCF，通过使用 OpenTelemetry，用户可以使用统一的 API 和数据模型来收集和传输观测数据，而不需要关心底层的实现细节，从而可以降低观测数据收集的复杂性，并提高系统的可观测性。5.2.2 整体架构整体架构OpenTelemetry 的核心组件包括以下几部分：2023 云安全联盟大中华区版权所有61图 12 OpenTelemetry 核心组件组件规范：定义了所有组件的规范和标准。标准协议(OTLP)：定义了遥测数据的格式和结构的标准协议。语义约定：定义了常见遥测数据类型的标准命名方案。API：定义了如何生成遥测数据的接口。开发语言 SDK：实现了定义各类开发语言的遥测数据的开发工具包。自动化生成组件(Auto Instrumentation)：无需代码更改即可生成遥测数据的自动化组件。OpenTelemetry Collector：一个代理，用于接收、处理和导出遥测数据。其他工具：如 OpenTelemetry Operator 用于 Kubernetes、OpenTelemetryHelm Charts 等场景。2023 云安全联盟大中华区版权所有625.2.3 功能特点功能特点OpenTelemetry 的功能特点体现在其工作流程，以下为工作流程不同阶段所覆盖的功能特点：生成（生成（Instrumentation）：在微服务中使用 OpenTelemetry 提供的 SDK 或自动化组件进行埋点，以生成跟踪和指标数据。这类数据可包括微服务的函数调用、数据库查询、网络请求等。处理（处理（Processing）：生成的跟踪和指标数据可通过 OpenTelemetry 的 SDK或自动化组件导出至 OpenTelemetry Collector 或其他支持的 Collector(第三方)。导出可以是实时的或批量的，具体取决于配置和需求，Collector 接收到 SDK 收集的指标数据后，将通过 Processor 组件进行一系列的处理操作，包括针对指标的过滤、采样、聚合、转换及添加自有的业务等，定制化能力较强。导出（导出（Exporting）：通过 Proccessor 处理后的指标数据将根据需求通过Exporter 导出至可观测性平台，如 Jaeger、Promethues 等。分析（分析（Analysis）：导出的数据可通过可观测型平台进行进一步的分析和可视化。这些平台可提供追踪，指标查询、告警、仪表盘等功能，从而帮助开发人员及运维人员监控、优化应用程序的性能。5.2.4 定位定位 2023 云安全联盟大中华区版权所有63OpenTelemetry 目前在市场上的应用情况正在逐步增加，尤其在容器化和微服务架构中。现今许多云服务提供商和容器平台，如 AWS、Google Cloud、Azure、Huawei Cloud 等均已经开始支持和推广 OpenTelemetry。值得注意的是Opentelemetry SDK 现已支持多种开发语言，包括但不限于 C 、.NET、Go、Java、Javascript、Python、Rust、Swift 等。OpenTelemetry 仍处于发展和演进过程中，在频繁更新版本给用户带来新的体验的同时，可能会导致不同版本间的兼容性问题。OpenTelemetry 会持续聚焦于云原生生态系统支持，致力于将统一的数据格式和数据传输协议集成至更多主流的监控分析平台。5.3 SkyWalking 项目项目5.3.1 项目概述项目概述Skywalking 是一个国产的开源框架，2015 年有吴晟个人开源，2017 年加入Apache 孵化器，主要开发人员来自于华为，2019 年 4 月 17 日 Apache 董事会批准 SkyWalking 成为顶级项目，支持 Java、.Net、NodeJs 等探针，数据存储支持Mysql、Elasticsearch 等，跟 Pinpoint 一样采用字节码注入的方式实现代码的无侵入，探针采集数据粒度粗，但性能表现优秀，且对云原生支持，目前增长势头强劲，社区活跃。5.3.2 整体架构整体架构 2023 云安全联盟大中华区版权所有64SkyWalking 在逻辑上分为四个部分：探针，平台后端，存储和用户界面，其总体架构如下图 13 所示：图 13 SkyWalking 总体架构探针探针收集监测数据，包括各种格式（SkyWalking、Zipkin、OpenTelemetry、Prometheus、Zabbix 等）的指标、追踪、日志和事件。平台后端平台后端支持数据聚合、分析和流处理，涵盖追踪、指标、日志和事件。可以作为聚合器角色、接收器角色或两者兼备。存储存储通过开放/可插拔的接口存放 SkyWalking 数据。可以选择现有的实现，如 ElasticSearch、H2、MySQL、TiDB、BanyanDB，或自己实现。UI 是一个高度可定制的基于 web 的界面，允许 SkyWalking 的最终用户可视化和管理 SkyWalking 数据。5.3.3 功能特点功能特点分布式追踪：端到端的分布式追踪能力。服务拓扑分析、以服务为中心的可观测性和 API 仪表盘。2023 云安全联盟大中华区版权所有65多语言自动探针：Java、.NetCore、PHP、NodeJS、Golang、LUA、Rust、C 、客户端 JavaScript 和 Python代理，处于积极开发和维护状态。采用 eBPF 技术：Rover 代理作为由 eBPF 提供支持的指标收集器和分析器，用于诊断 CPU 和网络性能。原生 APM 数据库：BanyanDB 是在 2022 年创建的一款可观测性数据库，旨在摄取、分析和存储遥测/可观测性数据。一致的指标聚合：通过同一脚本管道进行处理 SkyWalking 原生的度量格式以及广为人知的指标格式（例如 OpenCensus、OTLP、Telegraf、Zabbix等）。日志管理管道：通过脚本管道支持日志格式化、提取指标、各种采样策略，性能高效。警报和监测管道：支持以服务为中心、部署为中心、API 为中心的报警规则设置。支持将报警和所有监测数据转发到第三方。扩展性：单个 SkyWalking 集群可以收集和分析超过 1000 亿条遥测数据。兼容性：支持来自成熟生态系统的指标、追踪和日志，例如 Zipkin、OpenTelemetry、Prometheus、Zabbix、Fluentd。5.3.4 定位定位 2023 云安全联盟大中华区版权所有66Skywalking 项目定位为分布式系统的应用程序性能监视工具，专为微服务，云原生架构和基于容器（Docker，K8S,Mesos）架构而设计，它是一款优秀的 APM（Application Performance Management）工具，包括了分布式追踪，性能指标分析和服务依赖分析等。2023 云安全联盟大中华区版权所有67附件附件.引用文献引用文献【1】B.Sigelman,L.Barroso,M.Burrows,Patrick Stephenson,Manoj Plakal,DonaldBeaver,Saul Jaspan,C.Shanbhag.Dapper,a Large-Scale Distributed SystemsTracing Infrastructure 2010【2】CNCF Observability Whitepaper 1.02023【3】Dan Wendlandt.Grafana and Cilium:Deep eBPF-powered observability forKubernetes and cloud native infrastructure,2022.【4】高巍.基于操作系统 eBPF 在云原生环境下的技术研究.电子技术与软件工程，2022【5】高巍.可观测性技术研究与探索.电子技术与软件工程，2022.【6】Han Liu,Sheng Wu.Pinpoint Service Mesh Critical Performance Impact by usingeBPF，2022【7】刘文懋 江国龙 浦明 阮博男 叶晓虎云原生安全：攻防实践与体系构建，2021.【8】Gartner Top Strategic Technology2023 年度十大重要战略技术趋势【9】Gartner Market Guide for AIOps Platforms,May 2022【10】The Forrester Wave:Artificial Intelligence for IT Operation,Q4 2020【11】中国信通院稳定性保障实验室可观测性成熟度模型白皮书2023 2023 云安全联盟大中华区版权所有68

0人已浏览 2024-01-04 68页 5星级

版权声明版权声明 本报告版权属于中国信息通信研究院，并受法律保护。本报告版权属于中国信息通信研究院，并受法律保护。转载、摘编或利用其它方式使用本报告文字或者观点的，转载、摘编或利用其它方式使用本报告文字或者观点的，应注明应注明“来源：中国信息通信研究院来源：中国信息通信研究院”。违反上述声明者，。违反上述声明者，本院将追究其相关法律责任。本院将追究其相关法律责任。中国信息通信研究院技术与标准研究所中国信息通信研究院技术与标准研究所 2022023 3 年年 1212 月月 量子计算发展态势量子计算发展态势 研究报告研究报告 （2022023 3 年）年）量子计算发展态势研究报告量子计算发展态势研究报告 (20232023 年年)中国信息通信研究院技术与标准研究所 2023年12月 版权声明版权声明 本报告本报告版权属于版权属于中国信息通信研究院中国信息通信研究院，并受法律保护，并受法律保护。转载、摘编或利用其它方式使用转载、摘编或利用其它方式使用本报告文字或者观点的，本报告文字或者观点的，应应注明注明“来源：来源：中国信息通信研究院”中国信息通信研究院”。违反上述声明者，。违反上述声明者，本本院院将追究其相关法律责任。将追究其相关法律责任。前前 言言 量子计算以量子比特为基本单元，利用量子叠加和干涉等原理实现并行计算，能在某些计算复杂问题上提供指数级加速，是未来计算能力跨越式发展的重要方向。量子计算的发展和应用具有重大战略意义和科学价值，已成为全球主要国家在前沿科技和未来产业领域的政策布局和投资推动的重点方向之一。当前，量子计算处于理论研究、工程研发、应用探索和产业化培育并行发展的关键阶段。超导、离子阱、中性原子、光量子、硅半导体等主要技术路线的基础科研和工程研发亮点成果不断涌现，应用场景探索在化学模拟、量化金融、医疗健康、航空交通等领域广泛开展，科技巨头和初创企业布局以量子计算云平台、软件开源社区、产业联盟等为重点的产业生态建设发展迅速。量子计算云平台是推动应用探索和产业化发展的生态汇聚点和支撑驱动力，国内外不同类型量子计算云平台开放发展竞争激烈，三大服务模式日趋成熟，标准体系建设和基准测评研究逐步成为业界各方的关注热点。中国信息通信研究院在量子计算发展态势研究报告（2022年）的基础上，持续跟踪分析 2023 年国内外量子计算技术研究、应用场景探索和产业生态培育等方面的进展成果和发展演进趋势，并进一步聚焦量子计算云平台，初步提出量子计算云平台功能框架和标准体系建议，分析总结基准测评的研究与实践结果，最后结合量子计算领域发展现状、趋势和问题提出发展建议，为凝聚业界各方共识合力提供参考。目目 录录 一、量子计算已成为前沿科技和未来产业关注热点.1 二、量子计算科研攻关与软硬件研发保持高度活跃.2（一）多种硬件技术路线并行发展，亮点成果频出.2（二）量子计算软件持续开放探索，功能各有侧重.7（三）量子纠错突破盈亏平衡点，未来需持续攻关.11（四）环境测控系统取得新进展，性能指标待提升.13 三、应用探索多领域广泛开展，产业生态初步形成.16（一）应用探索成业界热点，行业领域趋向多元化.16（二）实用化落地尚未突破，硬件性能提升是基础.19（三）产业联盟与开源社区成为生态发展重要助力.21（四）欧美量子计算企业活跃，产业生态初具雏形.23 四、量子计算云平台是构建应用产业生态重要支点.28（一）国内外企业机构加速布局，抢占产业生态位.28（二）量子计算云平台功能架构可借鉴经典云计算.30（三）量子计算云平台的服务和业务模式逐步完善.32（四）云平台成为开展科研与应用探索的重要支撑.34 五、量子计算云平台标准和基准测评研究持续开展.37（一）国内外积极布局推动量子计算基准测评研究.37（二）构建量子计算云平台基准测评体系参考模型.39（三）开展测评实践验证，验证平台硬件实际能力.41（四）量子计算云平台标准体系建设需进一步推动.46 六、机遇与挑战并存，多策并举加快量子计算发展.49 图图 目目 录录 图 1 量子计算主要技术路线代表性研究成果.3 图 2 量子计算主要硬件技术路线关键指标对比概况.7 图 3 量子计算软件体系架构图.8 图 4 2023年 Gartner 量子计算技术成熟度预测.20 图 5 全球代表性量子信息产业联盟概况.21 图 6 国内外量子计算软件 GitHub开源社区活跃度.22 图 7 量子计算产业生态与国内外代表性企业概况.25 图 8 中美量子计算产业基础能力对比.27 图 9 国内外代表性量子计算云平台概况.28 图 10 量子计算云平台功能架构参考模型.30 图 11 量子计算云平台三大服务模式.32 图 12 量子计算云平台脉冲级实验套件功能.36 图 13 量子计算云平台基准测评体系参考模型.40 图 14 单比特 RB 测试结果.42 图 15 双比特 RB 测试结果.42 图 16 量子体积（QV）测试结果.43 图 17 DJ 算法测试结果.44 图 18 QFT 算法测试结果.44 图 19 哈密顿量模拟算法测试结果.45 图 20 量子计算云平台标准体系架构.48 表表 目目 录录 表 1 国内外代表性量子计算应用开发软件.9 表 2 国内外代表性量子计算编译软件.9 表 3 国内外代表性量子计算 EDA软件.11 表 4 代表性量子计算测控系统.15 表 5 量子计算应用场景分析.16 表 6 量子计算云平台基准测评初步测试结果汇总.41 量子计算发展态势研究报告（2023 年）1 一、量子计算已成为前沿科技和未来产业关注热点 量子计算以量子比特为基本单元，利用量子叠加和干涉等原理实现并行计算，能在某些计算复杂问题上提供指数级加速，是未来计算能力跨越式发展的重要方向，将对传统技术体系产生冲击、进行重构，成为引领新一轮科技革命和产业变革方向的颠覆性创新。量子计算的发展和应用具有重大战略意义和科学价值，已成为全球主要国家在前沿科技和未来产业领域的关注焦点之一。近年来，全球 30 个国家和地区制定发布了以量子计算为重点的量子信息发展战略或法案，不完全统计投资总额超过 280 亿美元。量子计算领域基础科研和技术创新持续保持活跃，科研论文和专利申请数量近年来屡创新高，初创企业数量和投融资金融也经历一轮爆发式增长。近一年来，全球科技巨头、初创企业和研究机构在量子计算领域的关键技术攻关、软硬件工程研发、应用场景探索和产业生态培育等方面取得了诸多重要进展和亮点成果。量子计算云平台作为集成量子计算软硬件能力，面向用户提供服务，支撑算法研究、应用探索和产业培育的生态汇聚点，是展现量子计算技术能力和产业化发展水平的重要视角。近年来，国内外各类量子计算云平台持续推出，多方开放竞争，功能框架和服务模式不断丰富和完善，已成为推动量子计算技术产业演进和产学研用合作的关键助推器。基于量子计算云平台开展量子计算软硬件系统的功能和性能测评验证，也是业界关注的热点方向之一，近年来在基准测评指标和测试方法等方面发展演进迅速。量子计算发展态势研究报告（2023 年）2 本报告对近一年来量子计算领域基础科研与工程研发的重要进展进行梳理总结，包括量子计算硬件主要技术路线研究成果，软件系统研发动态，量子纠错编码实验，环境测控系统进展。对各领域量子计算应用场景探索进展进行分析，分析杀手级应用落地面临的挑战，探讨量子计算企业、产业生态和开源社区等方面发展动态。对比国内外量子计算云平台发展情况，提出量子计算云平台的参考功能架构、主要功能需求和三大服务模式。此外，报告还提出量子计算云平台基准测评体系框架，开发电路级、系统级和应用级测试用例，对代表性云平台进行了测试验证。最后，报告总结量子计算演进趋势，提出未来发展关注重点。二、量子计算科研攻关与软硬件研发保持高度活跃（一）（一）多种硬件技术路线并行发展，亮点成果频出多种硬件技术路线并行发展，亮点成果频出 量子计算硬件有多种技术路线并行发展，主要可分为两大类：一是以超导和硅半导体等为代表的人造粒子路线，二是以离子阱、光量子和中性原子为代表的天然粒子路线。人造粒子路线可重用半导体集成电路制造工艺，在比特数量扩展方面具有一定优势，但在提升逻辑门精度等指标方面受到基础材料和加工工艺等限制。天然粒子具有长相干时间和高逻辑门精度等优势，但在比特数量扩展等方面面临挑战。近年来，各种主要技术路线均有研究成果不断涌现，呈现开放竞争态势，尚无某种技术路线体现出明显综合优势。2023年量子计算硬件主要技术路线的代表性研究成果如图 1所示。量子计算发展态势研究报告（2023 年）3 来源：中国信息通信研究院（截至 2023 年 11月）图 1 量子计算主要技术路线代表性研究成果 超导技术路线基于超导约瑟夫森结构造扩展二能级系统，具有可扩展、易操控和集成电路工艺兼容等优势，受到众多科研机构、科技巨头和初创企业重视，科研进展成果丰富。2023年，QuantWare推出 64 位超导量子比特处理器 Tenor1。中科大扩展超导量子处理器“祖冲之二号”可操纵量子比特至 176 位2。苏黎世联邦理工基于超导量子电路完成无漏洞贝尔实验3。谷歌使用超导量子处理器模拟操控非阿贝尔任意子，并通过非阿贝尔编制实现任意子纠缠态4。中科大联合团队实现 51 位超导量子比特簇态制备5。Rigetti 推出 84 位超导量子处理器 Ankaa-16。中科院物理所利用 41 位超导量子芯片“庄子”1 https:/tech.eu/2023/02/23/quantware-debuts-64-qubit/2 https:/ 3 https:/ 4 https:/ 5 https:/ 6 https:/ 量子计算发展态势研究报告（2023 年）4 模拟“侯世达蝴蝶”拓扑物态7。日本富士通和 RIKEN 发布 64 比特超导量子计算机8。总体来看，超导量子计算处理器比特规模和保真度等指标逐年稳步提升，在纠缠态制备、拓扑物态模拟等科研实验方面取得诸多进展，是量子计算领域业界关注度最高的发展方向。离子阱路线利用电荷与磁场间所产生的交互作用力约束带电离子，通过激光或微波进行相干操控，具有比特天然全同、操控精度高和相干时间长等优点。2023 年，Quantinuum 发布9其全连接量子比特离子阱原型机 Model H2 的单比特和双比特量子逻辑门保真度达到99.997%和 99.8%，量子体积指标达到 524288，成为业界最新纪录10。华翊量子发布1137 位离子阱量子计算原型机 HYQ-A37，成为国内代表性成果。需要指出，离子阱路线未来发展需要突破比特规模扩展、高集成度测控和模块化互联等技术瓶颈，未来能否在量子计算技术路线竞争中占据优势仍有待进一步观察。光量子路线利用可利用光子的偏振、相位等自由度进行量子比特编码，具有相干时间长、室温运行和测控相对简单等优点，可分为逻辑门型光量子计算和专用光量子计算两类，以玻色采样和相干伊辛等为代表的专用光量子计算近年来的研发成果较多。2023 年，中科大联合团队发布12 255 光子的“九章三号”光量子计算原型机，进一步提升了高斯玻色采样速度和量子优越性，基于光量子计算原型 7 https:/journals.aps.org/prl/abstract/10.1103/PhysRevLett.131.080401 8 https:/ 9 https:/ 10 https:/ 11 https:/ 12 https:/journals.aps.org/prl/issues/131/15 量子计算发展态势研究报告（2023 年）5 机完成稠密子图和 Max-Haf 两类图论问题求解13，验证计算加速潜在优势。玻色量子发布14100量子比特相干光量子相干伊辛机“天工量子大脑”，与中国移动合作开展算力调度优化等任务可行性验证15。硅半导体路线利用量子点中囚禁单电子或空穴构造量子比特，通过电脉冲实现对量子比特的驱动和耦合，具有制造和测控与集成电路工艺兼容等优势。2023 年，新南威尔士大学实现16新型触发器（flip-flop）硅量子比特。美国休斯研究中心提出17硅编码自旋量子比特的通用控制方案。中科大实现18硅基锗量子点超快调控，自旋翻转速率超过 1.2 GHz。Intel 发布1912 位硅基自旋量子芯片 Tunnel Falls。浙江大学20在半导体纳米结构中创造了一种新型量子比特。硅半导体路线得到 Intel 等传统半导体制造商支持，由于同位素材料加工和介电层噪声影响等瓶颈限制，比特数量和操控精度等指标提升缓慢。中性原子路线利用光镊或光晶格囚禁原子，激光激发原子里德堡态进行逻辑门操作或量子模拟演化，相干时间和操控精度等特性与离子阱路线相似，在规模化扩展方面更具优势，未来有望在量子模拟等方面率先突破应用。2023年，加州理工展示21量子橡皮擦纠错新方法，使激光照射下的错误原子发出荧光实现错误定位以便进一步纠错处理，系统纠缠率提升 10 倍。普林斯顿大学22基于相似擦除 13 https:/physics.aps.org/articles/v16/s64 14 https:/ 15 https:/doi.org/10.1007/s11433-023-2147-3 16 https:/www.science.org/doi/10.1126/sciadv.add9408 17 https:/ 18 https:/pubs.acs.org/doi/10.1021/acs.nanolett.3c00213 19 https:/ 20 https:/ 21 https:/ 22 https:/ 量子计算发展态势研究报告（2023 年）6 原理将门操作错误转化为擦除错误，有效提升逻辑门保真度。哈佛大学23基于里德堡阻塞机制控制方案，在60个铷原子阵列实现99.5%双比特纠缠门保真度，超过表面码纠错阈值。Atom Computing 公司发布241225原子阵列中性原子量子计算原型机，成为首个突破千位量子比特的系统。中性原子路线近年来在比特数目扩展和量子纠错等方面进展迅速，有望成为技术路线竞争中的后起之秀。量子计算多种技术路线研究成果不断涌现，如何分析发展趋势和进行横向对比是业界关注点。图 2 展示了五种主流技术路线关键指标的代表性成果对比情况，超导路线在量子比特数量、逻辑门保真度等指标方面表现较为均衡；离子阱路线在逻辑门保真度和相干时间方面优势明显，但比特数量和门操作速度方面瓶颈也同样突出；光量子和硅半导体路线目前在比特数量、逻辑门保真度和相干时间等指标方面均未展现出明显优势；中性原子近年来在比特数量规模、门保真度和相干时间等指标方面提升迅速。需要指出，当前量子计算各技术路线的性能指标发展水平参差不齐，但距离实现大规模可容错通用量子计算的目标都还有很大差距。23 https:/ 24 https:/atom- 年）7 来源：中国信息通信研究院 图 2 量子计算主要硬件技术路线关键指标对比概况25（二）量子计算软件（二）量子计算软件持续开放探索持续开放探索，功能各有侧重功能各有侧重 量子计算软件是连接用户与硬件的关键纽带，在编译运行和应用开发等方面需要根据量子计算原理特性进行全新设计，提供面向不同技术路线的底层编译工具，具备逻辑抽象工程的量子中间表示和指令集，以及支撑不同计算问题的应用软件。目前量子计算软件处于开放研发和生态建设早期阶段，业界在量子计算应用开发软件、编译软件、EDA软件等方向开展布局，如图 3 所示。25各技术路线指标统计是不同团队和系统报道的最优值，并非在同一系统中同时实现各项最优指标。量子计算发展态势研究报告（2023 年）8 来源：中国信息通信研究院 图 3 量子计算软件体系架构图 应用开发软件为开发者提供创建和操作量子程序的工具集、开发组件以及算法库，业界代表性应用开发软件如表 1 所示。2023 年，QC Ware推出量子化学软件SaaS Promethium26。Quantum Brilliance发布量子计算开发工具 Qristal SDK27，用例包括经典量子混合应用、化学模拟以及自动驾驶等。瑞典查尔姆斯理工大学开发量子计算开源软件SuperConga28，协助用户开展量子物理等领域的研究。未来，量子计算应用开发软件发展需要进一步增加应用场景、计算问题和算法开发的支持能力，以及与不同硬件系统软硬件协同适配性。26 https:/ https:/ 28 https:/www.chalmers.se/en/current/news/mc2-open-source-software-to-speed-up-quantum-research/量子计算发展态势研究报告（2023 年）9 表 1 国内外代表性量子计算应用开发软件 类别类别 名称名称 领域领域 发布机构发布机构 量子计算应用开发软件 OpenFermion 化学 Google TensorFlow Quantum 人工智能 PennyLane 机器学习 Xanadu InQuanto 化学 Quantinuum Qristal SDK 化学、经典量子混合应用、自动驾驶 Quantum Brilliance SuperConga 量子物理 Chalmers University of Technology ChemiQ 化学 本源量子 VQNet 人工智能 HiQ Fermion 化学 华为 Paddle Quantum 人工智能 百度 QuOmics、QuChem、QuDocking、QuSynthesis 化学、生物制药 图灵量子 QuFraudDetection、QuPortfolio 金融 来源：中国信息通信研究院 编译软件用于明确量子编程边界并确保程序编译正确执行，并提供完善且体系化的语法规则用于协调和约束量子操作与经典操作，表 2 梳理了业界代表性量子计算编译软件。2023 年，Pasqal 发布中性原子量子计算软件 Pulser Studio29，使用户能够以图形方式构建量子寄存器并设计脉冲序列。微软发布 Azure 量子开发套件（QDK）预览版30。Pasqal 推出用于数字模拟量子计算软件 Qadence31。量子计算编译软件未来需要持续提升软硬件协同编译、调度和优化能力。表 2 国内外代表性量子计算编译软件 类别类别 名称名称 特性特性 发布机构发布机构 29 https:/ 30 https:/ 31 https:/ 量子计算发展态势研究报告（2023 年）10 量子计算编译软件 Qiskit 具有 Terra、Aqua、Ignis、Aer 等四个功能模块，可用于编写、模拟和运行量子程序 IBM Cirq 针对量子电路精确控制、优化数据结构 Google QDK Q#量子编程语言、编译器、资源估计器等 微软 Forest 全栈编程和执行环境，Quil、pyQuil 等组件 Rigetti qbsolv 协助开发者为 D-Wave 机器开发程序 D-Wave Strawberry Fields 支持 python 库原型设计和量子电路优化 Xanadu Pulser Studio 以图形方式构建量子寄存器并设计脉冲序列 Pasqal Qadence 简化在相互作用的量子比特系统上构建和执行数字模拟量子程序的过程 Super.tech 根据硬件的脉冲级原生门自动优化量子程序 SuperstaQ ProjectQ 基于 python 编译并对量子电路编译优化执行 ETH Zurich Qulacs 基于 Python/C 编译，可模拟噪声量子门、参数化量子门等 Kyoto University HiQ Pulse 包含量子最优控制算法和脉冲库，提供快速优化设计的调控解决方案 华为 QCompute 支持 Python/QASM 混合编译和量子电路本地运行 百度 TensorCircuit 支持自动微分、即时编译、向量并行化和 GPU 加速 腾讯 QPanda 支持 Python、QASM、OriginIR、Quil等语言，可用于构建、运行和优化量子算法 本源量子 isQ-Core 支持经典量子混合编程，提供量子电路分解、优化和映射等功能 中国科学院 QuTrunk 具有 QCircuit、Qubit、Qureg等模块，支持代码的抽象封装和操作执行 启科量子 SpinQit 支持 Python/OpenQASM 2.0 编译以及经典量子混合编程，兼容 Qiskit 语法 量旋科技 来源：中国信息通信研究院 芯片设计 EDA 软件主要用于实现量子芯片的自动化设计、参数标定与优化、封装设计等功能，表 3 梳理了业界代表性的 EDA 软件。量子计算发展态势研究报告（2023 年）11 2023 年，亚马逊推出开源软件平台 Palace32，可执行复杂电磁模型的3D模拟并支持量子计算硬件设计。量旋科技发布超导芯片EDA软件天乙33。未来，量子计算芯片 EDA 软件需要在芯片性能验证、设计自主程度、设计效率等方面持续研究和完善。表 3 国内外代表性量子计算 EDA软件 类别类别 名称名称 特性特性 发布机构发布机构 量子计算 EDA软件 Qiskit Metal 用于超导量子处理器，构建芯片设计图，产生定制组件 IBM KQCircuits 用于超导量子处理器，可用于生成芯片设计，并在制造器件之前检查信号路由 IQM FeynmanPAQS 光量子芯片设计辅助系统与光学模拟系统 图灵量子 本源坤元 支持超导和半导体量子芯片版图自动化设计 本源量子 天乙 用于超导量子处理器，通过参数化生成量子器件，可自动布线算法 量旋科技 来源：中国信息通信研究院 总体而言，量子计算软件目前处于开放式探索阶段，不同软件功能各有侧重，但由于硬件技术路线未收敛、应用探索尚未落地使用等原因，软件技术水平基本处于研究工具级，与经典软件成熟度相距尚远。量子编程语言和框架、量子编译器和优化器、量子误差校正模块等关键功能特性仍需要持续研发，构建完善的软硬件技术栈和应用生态还有待业界进一步协同推动。（三）量子纠错突破盈亏平衡点，未来需持续攻关（三）量子纠错突破盈亏平衡点，未来需持续攻关 量子纠错可保护量子态免受噪声或退相干影响，是可容错量子信息处理中必不可少的环节。由于量子态的不可克隆、相干性以及 32 https:/ https:/ 量子计算发展态势研究报告（2023 年）12 差错连续性等特性，导致量子纠错与经典纠错存在本质差异。量子纠错概念提出34以来，已有多类不同原理和构造的量子纠错编码方案，其中表面码是当前研究和实验验证的热点，其优势在于高容错阈值，仅需近邻比特间作用，在超导等技术路线中易实现等。量子纠错需要执行状态编码、辅助比特制备、错误探测和纠正等多种操作，每个步骤都可能引入额外的错误。为了避免量子纠错陷入“越纠越错”的窘境，需要在各环节均完成高精度的操控。假设在纠错精度高于某个阈值时可以很好地完成量子纠错，即可通过多重级联编码等方式使错误率大幅度降低，从而实现高精度逻辑量子比特。因此突破量子纠错编码的盈亏平衡点，实现纠错编码规模与相干时间、错误率等性能指标的正增益，具有重要意义。2023 年，谷歌首次突破量子计算纠错编码规模与收益的平衡点35，在纠错编码规模增长的同时降低错误率，验证了量子纠错方案的可行性。南方科大以离散变量编码逻辑量子位突破量子纠错平衡点36，超过盈亏平衡点约 16%。耶鲁大学利用实时量子纠错方案实现盈亏平衡点超越37，利用实时纠错实现稳定的逻辑量子比特。芝加哥大学报通过观察量子比特持续监测量子系统外部噪声38，并实时调制数据量子比特以最小化误差。IBM 报道39在 127 位 Eagle 量子处理器上基于误差缓解技术和量子伊辛模型，在无需量子纠错条件下实现对磁性材料简化系 34 https:/doi.org/10.1103/PhysRevA.54.1098 35 https:/ 36 https:/ 37 https:/ 38 https:/www.science.org/doi/10.1126/science.ade5337 39 https:/ 量子计算发展态势研究报告（2023 年）13 统模型的自旋动态和磁化特性的模拟，并验证其准确性。量子纠错跨过盈亏平衡点，是实现通用量子计算的重要里程碑之一。但当前量子逻辑门保真度水平距离可容错实用化要求仍有约十个数量级的巨大差距，基于量子纠错实现逻辑量子比特仍是需要长期研究攻关的目标。量子纠错未来发展的主要方向包括：提升逻辑量子比特的可操控性，优化利用高维度量子资源实现逻辑量子比特的纠错编码方案；实现对特定噪声免疫的量子态调控方案，研究分布式量子纠错架构；在考虑计算资源的同时探究切合实际的纠错性能评价指标，实现带量子纠错的量子计算优越性等。在突破量子纠错盈亏平衡点后，业界将持续研究量子纠错理论与实验验证，未来数年将有更多量子纠错研究重要进展和成果出现。（四）（四）环境测控系统取得新进展，性能指标待提升环境测控系统取得新进展，性能指标待提升 量子计算中的叠加和纠缠等状态极易受到外界影响而退相干，需要极低温、高真空等环境系统支持，同时对大规模量子比特的微波或光学调控与测量，也需要高精度和高集成度的测控系统支持。环境与测控系统是各种技术路线的量子计算原型机必不可少的使能组件，也是当前提升样机工程化水平面临的重要技术瓶颈。稀释制冷机可为超导、硅半导体等路线的量子计算处理器运行提供 mK 级别的极低温环境，利用氦-3 和氦-4 混合液的浓缩相和稀释相分离和循环转换产生制冷效应，具有可连续工作、操作简单、无振动与电磁干扰、性能稳定等优势。稀释制冷机的技术难点主要在于脉冲管和冷头等预制冷设备研制、制冷量提升、低温设备焊接量子计算发展态势研究报告（2023 年）14 和检漏工艺等方面。稀释制冷机是量子计算系统的重要装备之一，提升国产化自给能力对于保障科学研究和应用产业发展意义重大。近期国内相关单位持续研发攻关并取得重要进展。2022 年下旬，IBM 发布40“黄金眼”超大稀释制冷机。2023 年，中船重工鹏力发布41稀释制冷机产品，中科院物理所研制的无液氦稀释制冷机样机42，本源量子发布稀释制冷机产品43。未来，稀释制冷机将向更高制冷量、更大样品空间和集成化系统等方面发展。超高真空腔是离子阱和中性原子量子计算必需环境，用于避免真空腔内气体分子与离子或原子的碰撞导致囚禁脱离，保证束缚时间和操控精度。超高真空腔技术挑战在于高性能吸气剂泵等关键组件的研制、提升气体抽速以及腔内真空度等方面。2022 年底，启科量子发布离子阱低温真空系统44，将低温、真空、电气、光学四大核心要素进行有机整合，为样机系统研制提供环境保障。未来真空腔需要持续提升真空度指标和集成化水平。量子计算测控系统主要用于操控和测量量子比特，根据技术路线的需求区分大致可分为两类：一是离子阱、中性原子和光量子等技术路线所需的光学测控系统；二是超导、硅半导体等技术路线使用的微波测控系统。主要挑战在于提升同时被测控量子比特的数量、减小测控信息反馈延迟、提升系统内多模块同步性、减小噪声干扰等方面。当前业界代表性量子计算测控系统如表 4 所示。2023 年，40 https:/ 41 http:/ 42 http:/ 43 https:/ 44 http:/ 量子计算发展态势研究报告（2023 年）15 苏黎世仪器发布量子计算控制系统 QCCS，启科量子发布离子阱环境控制系统，玻色量子推出光量子测控一体机量枢，量旋科技发布超导量子测控系统织女星 Vega。未来量子计算测控系统需要提升测控芯片集成度、进行测控系统机箱内扩展、机箱间扩展以及提升系统的通道密度等。表 4 代表性量子计算测控系统 类别类别 名称名称 发布机构发布机构 技术路线技术路线 量子计算测控系统 量子计算控制系统（QCCS）Zurich Instruments 超导 量子测控一体机 SHFQC 量子控制系统 QCS Keysight 超导 Cluster Qblox 超导 量子计算测控系统 QCS1000 中微达信 超导 本源天机 3.0 本源量子 超导 ez-Q Engine 国盾量子 超导 启科量子 离子阱 量枢 玻色量子 光量子 织女星 Vega 量旋科技 超导 来源：中国信息通信研究院根据公开信息整理 需要指出，当前量子计算环境与测控系统研发也面临一些挑战。一是由于硬件技术路线并行发展导致环境系统、测控装备、关键组件等需求过于分散和碎片化，上游供应商难以聚焦某条技术路线开展集中攻关，制约工程化水平提升。二是未来量子比特规模提升对环境测控系统技术要求提出更严苛要求，例如稀释制冷机需支持数千乃至更大规模比特量级的布线和制冷，真空腔系统实现极高真空环境仍有存在工程挑战，测控系统进一步提高集成度。总体而言，量子计算环境与测控系统发展仍处于工程化研发和性能提升的攻关阶段，未来仍需进一步加强核心组件和系统集成等方面研发投入。量子计算发展态势研究报告（2023 年）16 三、应用探索多领域广泛开展，产业生态初步形成（一）（一）应用探索成业界热点，行业领域趋向多元化应用探索成业界热点，行业领域趋向多元化 近年来，基于中等规模含噪量子处理器（NISQ）和专用量子计算机的应用案例探索在国内外广泛开展，代表性应用领域和典型场景如表 5 所示，涵盖了化学、金融、人工智能、交运航空、气象等众多行业领域，产业规模估值达到千亿美元级别。量子计算公司普遍期待未来数年，在NISQ系统中完成具有社会经济价值的计算问题加速求解，实现杀手级应用突破。表 5 量子计算应用场景分析 行业行业 领域领域 关键环节关键环节 问题原型问题原型 应用时间（应用时间（ 代表影响力）代表影响力）产业估值产业估值(亿美元亿美元)35年年 510 年年 10 年以年以上上 保守估值保守估值 乐观估值乐观估值 金融 金融服务 组合优化 人工智能 3940 7000 能源与材料 传统能源 量子模拟 组合优化 人工智能 100 200 可持续能源 100 300 化工 1230 3240 生命 科学 制药 量子模拟 组合优化 人工智能 740 1830 先进 工业 汽车 人工智能 量子模拟 组合优化 290 630 航空航天与国防 因式分解 量子模拟 组合优化 300 700 电子产品 因式分解 量子模拟 组合优化 100 200 半导体 100 200 电信 传媒 电信 量子模拟 组合优化 100 200 传媒 100 200 出行、运输和物流 物流 组合优化 量子模拟 人工智能 因式分解 500 1000 来源：麦肯锡量子技术监测、波士顿量子计算为商业化做好准备等 量子计算发展态势研究报告（2023 年）17 化学领域量子计算应用探索主要通过模拟化学反应，达到提高效率、降低资源消耗等目的。2023 年，德国尤利希中心利用量子计算提升寻找蛋白质最低能量结构的成功率45。牛津大学实现基于网格的量子计算化学模拟46，探索基态准备、能量估计到散射和电离动力学等方面能力。QC Ware 展示量子计算帮助检测糖尿病视网膜病变47。IBM 和克利夫兰诊所建立量子计算应用联合研究中心，加速生物医学方面研究48。美国艾姆斯研究中心报道了量子计算在材料模拟应用中的自适应算法，减少计算资源的同时提升模拟稀土材料准确性49。金融领域量子计算应用有望在优化预测分析、精准定价和资产配置等问题中产生优势。2023 年，法国 CIB、Pasqal和 Multiverse 联合发布量子计算金融应用解决方案的验证结果50，减少金融衍生品估值计算所耗算力资源，提升评估速度与准确性。摩根大通和 QC Ware 使用量子深度学习分析风险模型提升训练有效性51。汇丰银行和 Quantinuum 合作探索在欺诈检测和自然语言处理等方面的量子计算应用优势52，推出用于金融数学问题建模应用的量子蒙特卡罗积分引擎量子算法工具53。45 https:/www.eurekalert.org/news-releases/977133 46 https:/www.science.org/doi/10.1126/sciadv.abo7484 47 https:/ https:/ 49 https:/ https:/ 51 https:/ https:/ 53 https:/ 量子计算发展态势研究报告（2023 年）18 人工智能领域与量子计算结合可能在于机器学习、化学分析、神经网络等领域产生应用。2023 年，Zapata 联合研究表明混合量子人工智能有望生成更理想特性的药物小分子54。慕尼黑大学使用量子神经网络训练小型含噪数据集为化学制药提供解决方案55。清华大学演示反向传播算法训练六层深度量子神经网络56，提升平均保真度达94.8%。Rigetti 联合 ADIA 实验室开发概率分布分类的量子机器学习解决方案57，探索量化金融领域中的投资策略制定新方法。交通物流领域量子计算应用主要聚焦组合优化问题，以更优方案实现路线规划和物流装配，提升效率降低成本。2023 年，Terra Quantum 和泰雷兹公司使用混合量子计算验证加强卫星任务规划过程并改善卫星运行效率58。英伟达、罗尔斯-罗伊斯和 Classiq 将量子计算用于提升喷气发动机的工作效率59。Amerijet International 和Quantum-South 报道利用量子计算，可以实现飞机货物装载效率优化从而提高航班收入60。气象预测领域量子计算应用主要体现在求解大数量、多维度的气象数据，协助建模仿真与预测。2023 年，德勤举办 2023 年量子气候挑战赛61，使用量子计算机模拟从大气中过滤二氧化碳的材料从而 54 https:/ 55 https:/ https:/ 57 https:/ 58 https:/www.newswire.ca/news-releases/xanadu-and-rolls-royce-to-build-quantum-computing-tools-with-pennylane-881322368.html 59 https:/ https:/quantum- https:/deloitte.zoom.us/webinar/register/45/WN_-ga8oLPKQCyGgx97qZ5c2A 量子计算发展态势研究报告（2023 年）19 减少全球变暖的影响。美国能源部国家能源技术实验室使用量子计算研究胺化学反应62，找寻用于碳捕获的胺化合物。需要注意的是，近年涌现出众多关于量子计算应用案例报道，基本属于原理验证性质的可行性实验报道，部分应用案例可以取得一定加速优势，但距离业界期待的指数级加速和算力飞跃仍有较大差距。量子计算在应用实际落地和产生商业价值方面仍面临挑战，目前基本处于可行性和实用性探索阶段。（二）（二）实用化实用化落地落地尚未突破尚未突破，硬件性能提升是基础硬件性能提升是基础 2023 年 7 月，美国 Gartner发布计算技术成熟度曲线如图 4 所示，数年前量子计算技术向着“过高期望”顶点逐渐靠近，现阶段已跨越了“过高期望”顶点，但整体距离“生产力高原”仍需超过十年的时间。NISQ 样机时代能否实现“杀手级”应用突破，是量子计算行业发展的分水岭，如果未来数年内一直无法实现应用落地突破，则量子计算技术产业发展恐将面临“幻灭之谷”的低潮期。62 https:/avs.scitation.org/doi/10.1116/5.0137750 量子计算发展态势研究报告（2023 年）20 来源：Gartner:Hyper Cycle of Compute（2023年 7 月）图 4 2023 年 Gartner量子计算技术成熟度预测 量子计算系统是十分脆弱的，易受到外部环境噪声、系统中粒子间的相互作用等复杂因素的交互影响而引发退相干效应，导致量子态失真，使算法运行结果的保真度和准确性受到影响。目前量子计算应用难以实用落地的主要原因在于样机的相干操控比特规模、逻辑门保真度和线路深度等关键性能指标仍极为有限，量子算法、量子纠错编码方案等未完全成熟，难以支撑具有明确加速优势的算法实施。未来需要提升 NISQ 样机性能，在解决实际问题时发挥出相较于经典算法的显著算力优势，才能体现出量子计算价值。量子计算技术发展演进可大致分为三个阶段，阶段一是实现量子计算优越性验证（已完成）；阶段二是实现可在若干具有实用价值的计算难题中展现量子计算优越性并带来社会经济价值的专用量子计算机（下一步重点攻关目标）；三是大规模可容错通用量子计算机（远期目标）。阶段二的专用量子计算机“杀手级”应用，以超导量子路线为例，也可大致分为三步：一是实现数百比特规模的相干操控，逻辑门保真度达 99.9%以上时，能够在运算复杂度和精度要求不高的部分量子组合优化场景中率先实现落地，有望未来3-5年实现；二是实现数千比特规模的相干操控，逻辑门保真度达 99.99%以上时，能够使用量子模拟在多个行业领域实现落地应用，有望未来 5-10 年实现；三是实现数万比特规模的相干操控，逻辑门保真度满足量子纠错阈值要求时，能够在密码分析等计算问题更为复杂的行业领域量子计算发展态势研究报告（2023 年）21 产生重要影响，预计至少仍需 10年以上。（三）（三）产业产业联盟与开源社区联盟与开源社区成为生态发展重要助力成为生态发展重要助力 随着量子计算技术研发和应用探索不断推进，产业生态培育成为热点，业界通过成立产业联盟，建设开源社区等方式，促进量子计算产业生态系统发展。近年来全球多国相继成立量子信息领域产业联盟，成员涵盖量子企业、研究机构以及行业用户，持续推动产学研用多方合作。全球代表性量子信息产业联盟如图 5所示。来源：中国信息通信研究院根据公开信息整理（截至 2023年 11 月）图 5 全球代表性量子信息产业联盟概况 2023 年，加拿大量子工业联盟（QIC）、美国量子经济发展联盟（QED-C）、日本量子技术与应用联盟（Q-STAR）和欧洲量子产业联盟（QuIC）签署了谅解备忘录，成立国际量子产业协会理事会，旨在加强成员之间在量子技术发展目标、战略规划、国际规则制定以及知识产权管理等方面的沟通和协作，并将致力于推动全球供应链的可视化。量子信息网络产业联盟（QIIA）目前已有 68 家成员单位，自成立以来组织开展技术交流研讨，已相继启动技术研究、标量子计算发展态势研究报告（2023 年）22 准预研、测评验证、应用案例征集等方向的二十余个研究项目，并于 2023 年举办了第一届量子信息技术与应用创新大赛。本源量子计算产业联盟（OQIA）已有四十余个成员，共同开展研发制造、应用探索和科普教育等方面合作。量子科技产学研创新联盟由合肥国家实验室牵头成立，旨在全面增强量子科技创新策源能力，推动量子产业集聚发展，引导和拓展量子科技在政务、通信、金融等领域应用示范。此外，电子学会、通信学会、计算机学会、信息协会等行业平台，也成立了量子计算、量子通信等方向委员会，组织开展年度学术交流和产业研讨会议论坛等多学科领域的交流与研讨。开源软件社区是高效协作打造软件生态的重要模式，有助于促进独立开发者和大型企业积极参与，推动量子计算软件生态发展。国际科技巨头依托 GitHub 等开源软件社区，吸引更多用户学习和使用量子计算产品，积极构建产业生态圈，拓展用户培育途径，在开源社区贡献度、软件工具用户吸引力和生态影响力方面更具优势。来源：中国信息通信研究院（截至 2023 年 11月）图 6 国内外量子计算软件 GitHub开源社区活跃度 量子计算发展态势研究报告（2023 年）23 国内外典型量子计算软件开源项目在 GitHub 网站的活跃度对比情况如图 6 所示。我国在量子计算软件项目关注数（Star）、项目分支拷贝数（Fork）、项目问题数（Issue）等方面与国际先进水平存在数量级差距，普遍活跃度较低，生态影响力有限，处于培育期。活跃度差距主要原因是欧美企业在经典计算领域已建立了较为雄厚的开源软件先发优势，用户和企业在量子软件操作和使用习惯受到先入为主的惯性引导，多种软件并发也稀释了开源社区研发力量。总体而言，全球量子计算生态体系处于早期构建阶段。国内外业界各方通过成立产业联盟，构建开源社区，汇集行业伙伴、探索应用场景、促进创新协同已成为重要趋势。未来我国需要依托产业联盟与开源社区等平台，进一步整合业界各方力量，加快量子计算软硬件协同开发迭代和应用场景探索等产业生态建设工作。（四）（四）欧美量子计算企业活跃，产业生态初具雏形欧美量子计算企业活跃，产业生态初具雏形 近年来全球主要国家量子计算企业数量和投融资经历了一轮爆发式增长，科技巨头和初创企业成为促进量子计算产业化发展的重要推动力量，欧美成为量子计算企业聚集度和活跃度最高地区。美国代表性量子计算企业包括 IBM、Google、Intel、微软、亚马逊等科技巨头成立的研发部门，IonQ、Rigetti、QCI、QuEra 等多类型初创企业在硬件、软件、算法等领域开展创新，通过资本市场不断获取资金支持，积极研发量子计算原型机及软件算法，加速技术水平提升与成果转化，推动全球量子计算产业发展。欧洲量子计算企业大多为初创企业，如 Quantinuum、IQM、Pasqal、OQC、Qu&Co、量子计算发展态势研究报告（2023 年）24 Planqc 等。欧美企业间合作紧密，在技术推进、应用探索和产业培育等方面取得诸多进展。此外，加拿大、澳大利亚、新加坡等国也涌现出一批量子计算企业，典型如 D-Wave（加）、Xanadu（加）、Horizon Quantum Computing（新）、Q-CTRL（澳）等，在硬件系统研发和软件产品开发等方面表现活跃。我国华为、百度、腾讯等企业近年来相继成立量子实验室，在软硬件研发、算法研究、应用探索、量子计算云平台等方面积极布局，但相对美国科技企业而言投入推动力度仍较为有限。11 月，阿里达摩院裁撤量子计算研究团队，也成为业界热点事件。本源量子、启科量子、国盾量子、玻色量子、图灵量子、量旋科技、弧光量子、中科酷源、幺正量子等量子计算初创企业布局推进量子计算技术研究与应用探索，力争在全球量子计算产业生态中占得一席之地。量子计算产业生态上中下游各环节已初具雏形，如图 7 所示，目前全球已涌现出百余家量子计算企业，欧美企业聚集度较高，产业生态各环节的参与者逐步增多，产业培育正在稳步推进。量子计算发展态势研究报告（2023 年）25 来源：中国信息通信研究院 图 7量子计算产业生态与国内外代表性企业概况 产业生态上游主要包含环境支撑系统、测控系统、各类关键设备组件以及元器件等，是研制量子计算原型机的必要保障。目前由于技术路线未收敛、硬件研制个性化需求多等原因，上游供应链存在碎片化问题，逐一突破攻关存在难度，一定程度上限制了上游企业的发展。国内外情况对比而言，上游企业以欧美居多，部分龙头企业占据较大市场份额，我国部分关键设备和元器件对外依赖程度较高。产业生态中游主要涉及量子计算原型机和软件，其中原型机是产业生态的核心部分，目前超导、离子阱、光量子、硅半导体和中性原子等技术路线发展较快，其中超导路线备受青睐，离子阱、光量子和中性原子路线获得较多初创企业关注。美国原型机研制与软件研发占据一定优势，我国量子计算硬件企业数量有限且技术路线量子计算发展态势研究报告（2023 年）26 布局较为单一，集中在超导和离子阱路线，量子计算软件企业存在数量规模较少、创新成果有限、应用探索推动力弱等问题。产业生态下游主要涵盖量子计算云平台以及行业应用，处在早期发展阶段。近年来全球已有数十家公司和研究机构推出了不同类型的量子计算云平台积极争夺产业生态地位。目前量子计算领域应用探索已在金融、化工、人工智能、医药、汽车、能源等领域广泛开展。国外量子计算云平台的优势体现在后端硬件性能、软硬件协同程度、商业服务模式等方面。大量欧美行业龙头企业成立量子计算研究团队，与量子企业联合开展应用研究，我国下游行业用户对量子计算重视程度有限，开展应用探索动力仍需提升。产业基础能力是观察和分析各国量子计算技术产业发展态势的重要视角之一，本报告从科研基础、政府活动、私营企业、技术成果等四个维度构建产业基础能力分析框架，对比分析中美量子计算领域的产业基础能力情况，具体结果如图 8 所示。量子计算发展态势研究报告（2023 年）27 来源：中国信息通信研究院 图 8 中美量子计算产业基础能力对比 科研基础方面，我国具有较多的发文机构，但高被引论文数、国际合作机构以及合著出版物数量等相对较少，在高水平科研成果和国际合作仍需加强。政府活动方面，中美研发投入资金量级差距不大，我国量子计算重要研究中心的数量有待增加。私营企业方面，美国企业发展较为活跃，在企业数量、资金分布和供应链能力方面全面领先。技术成果方面，我国专利增长率较高，但专利数量、代表性技术成就、产品技术路线图等方面仍存差距，需要加强样机软硬件研发创新性成果输出和样机产品发展路线图规划。综合来看，我国在量子计算领域具有一定的科研基础，但在技术成就、企业发展和产业推动等方面仍有较大提升空间。量子计算发展态势研究报告（2023 年）28 四、量子计算云平台是构建应用产业生态重要支点（一）国内外（一）国内外企业机构企业机构加速布局，抢占加速布局，抢占产业生态位产业生态位 量子计算云平台将量子计算机硬件、模拟器、软件编译和开发工具，与经典云计算软硬件和通信网络设备相结合，可为用户提供直观和实例化的量子计算接入访问与应用服务。作为集成量子计算软硬件能力，面向用户提供服务，支撑算法研究、应用探索和产业培育的生态汇聚点，量子计算云平台已成为推动应用探索和产业化发展的生态汇聚点和重要驱动力。近年来，科技巨头、初创企业与研究机构为抢占应用产业生态核心地位，加大量子计算云平台建设投入和推广力度。全球已有数十家公司和研究机构推出了不同类型量子计算云平台，其中代表性云平台如图 9 所示。来源：中国信息通信研究院（截至 2023 年 11月）图 9 国内外代表性量子计算云平台概况 美国以 IBM、亚马逊、谷歌、微软等为代表的科技巨头和以Rigetti、Strangeworks 等为代表的初创企业先后推出了各自的量子计算云平台，对外提供量子计算硬件或量子线路模拟器的接入使用和应用开发等服务。加拿大、欧洲各国也相继推出各自的量子计算云量子计算发展态势研究报告（2023 年）29 平台。我国在量子计算云平台方面起步晚于欧美，但近年来多家科技公司、初创企业和研究院所陆续推出量子计算云平台，并在编程语言、编译框架、应用服务、接入体验等方面积极推出相关服务，支撑量子计算领域科学研究、科普推广和应用探索。我国云平台提供商既包括华为、百度等传统互联网科技企业，也包括本源量子、量旋科技、弧光量子等量子计算初创企业，还包括北京量子院、中科院等研究机构。相比国外科技巨头，国内量子计算云平台在后端硬件能力，开发运维水平和服务推广能力等方面还有一定差距。从云平台后端量子计算硬件路线来看，云平台后端的量子计算处理器主要可分为逻辑门型和专用型两类。目前超导路线仍是逻辑门型量子计算处理器的主流方向，此外国内外也上线了部分离子阱、光量子、中性原子、核磁共振等路线的量子处理器。专用型量子计算处理器不具备量子逻辑门操控和量子纠错编码等能力，但可用于求解组合优化、量子退火和玻色采样等专用问题，主要包括量子退火机、玻色采样机和相干伊辛机等类型。D-Wave 是最早进行量子退火机研发的企业，2018 年推出了基于量子退火机的量子计算云平台Leap，近年来基于云平台在运输物流、生命科学、投资金融等领域开展应用探索。2023年，D-Wave基于量子退火机在“自旋玻璃”问题上证明了量子优越性63。玻色量子于发布 100 比特相干光量子计算机，与中国移动共建“五岳”量子云平台。总的来说，国内外诸多研究机构和企业布局推出了量子计算云 63 https:/ 量子计算发展态势研究报告（2023 年）30 平台产品和服务，依托云平台加快推动量子计算算法研究、应用探索和产业生态建设已逐渐成为业界共识。（二）（二）量子计算云平台功能架构可借鉴经典云计算量子计算云平台功能架构可借鉴经典云计算 量子计算云平台将量子计算与经典云服务融合，通过云端提供量子计算资源，有望成为服务量子计算用户的主要形式。根据量子计算云平台技术特性和发展现状，本报告研究提出量子计算云平台的功能架构参考模型，如图 10 所示，可划分为基础设施层、平台层、服务层，以及云服务所需的运维管理与安全服务等主要部分。来源：中国信息通信研究院 图 10 量子计算云平台功能架构参考模型 量子计算云平台的应用层主要由接入门户和应用服务等功能模块组成。接入门户层提供用户接口（UI）。用户可以通过 UI 界面访问量子云服务，输入必要的参数和数据，并获取返回结果。目前，用户使用量子计算云平台的方式可分为两类，一类是本地编译、通量子计算发展态势研究报告（2023 年）31 过应用程序编程接口（API）访问云平台，另一类是直接在云平台上进行开发实践。接入门户功能又可以细分为服务门户和管理门户。应用服务层既可提供拥有图形用户接口（GUI）的量子应用，也可提供算法 API 以及软件开发工具包（SDK）允许用户根据自身需求或特殊应用场景自行开发量子应用。平台层主要由平台服务功能模块组成。平台服务功能主要包括图形化/代码编程开发、程序编译、程序调试、任务调度、量子比特校准等功能，同时也提供数据库、中间件等必要的经典云平台功能。目前量子计算云平台提供的编程开发方式主要有两种，一种是通过IDE、低代码或无代码等提供可视化、图形化、可拖拽等配置方式进行量子线路创建和运行，运行结果展示。另一种是通过编程语言实现量子线路创建和运行，支持运行结果返回和查询。由于目前量子计算硬件性能尚不稳定，需要定期进行校准，平台层可提供在线或离线方式的比特校准功能，可通过手动或自动形式完成。基础设施层向云服务用户提供量子计算基础资源，云服务用户在其上部署和运行任意的应用程序。基础设施服务子层可独立为用户提供基于量子计算硬件的服务，如硬件调用、租赁等，也可实现平台层与底层硬件的桥接。资源管理子层为管理员提供资源的新增、统一纳管、信息修改、虚拟化/容器化、删除等全生命周期管理功能。物理资源功能子层是量子计算云平台的核心，提供量子算力和经典算力，此外还需提供必要的经典物理资源，如服务器、存储器、网络设备等。虚拟资源子层将云平台上分布式的物理资源进行虚拟化量子计算发展态势研究报告（2023 年）32 或容器化，形成资源池，按需动态分配给用户，并保证虚拟机或容器之间的隔离。由于量子计算机硬件尚不成熟，分布式和虚拟化等解决方案尚不具备。外围设施子层为量子计算硬件正常运行提供支撑保障，不同硬件路线对环境保障系统要求有较大差异。运营管理功能主要由用户管理、服务管理、计费管理、运营管理、报表管理和监测管理等功能模块组成。安全保障功能主要实现通用安全、主机安全和 Web 安全等功能。其中，用户认证、授权管理、安全审计、经典服务器防护与加固、网络安全等功能可以借鉴经典云计算平台相关能力。（三三）量子计算云平台的量子计算云平台的服务服务和业务和业务模式模式逐步完善逐步完善 量子计算云平台具有网络连接、资源共享、弹性且按需服务、服务可测量等特点。按照云平台服务提供资源所在的层次，可分为量子基础设施即服务（Q-IaaS）、量子平台即服务（Q-PaaS）和量子软件即服务（Q-SaaS）三类，如图 11所示。来源：中国信息通信研究院 图 11 量子计算云平台三大服务模式 Q-IaaS量子计算发展态势研究报告（2023 年）33 Q-IaaS 将量子计算机硬件及配套设施作为服务在量子计算云平台上提供给用户。用户可调用云平台上的硬件（量子计算机、量子计算模拟器、经典服务器、存储器等）而无需对其进行维护，实现低成本的开发应用。Q-PaaS 将量子计算相关基础设施和中间件组成的开发平台作为服务在云平台上提供给用户。用户可基于量子计算软件开发平台开发量子编程框架和量子算法库，并通过云服务器连接至不同公司量子计算硬件进行计算。Q-SaaS 根据特定行业应用场景和应用需求将打包好的应用服务方案作为服务在量子计算云平台上提供给用户。用户可以直接调用量子算力来解决特定领域的实际计算问题，无需全面掌握量子软硬件知识和量子算法等编程能力。近年来，亚马逊、微软、Strangeworks等欧美量子计算云服务商逐步探索 Q-PaaS 服务模式，提供统一的接入方式和开发平台，调用多公司的量子计算硬件后端。国内大部分云平台介于 Q-IaaS 和 Q-PaaS 之间，可提供基本的量子硬件接入和初级的量子线路编辑、运行等功能，部分平台可提供相对完整的开发环境和算法库。此外，以 IBM、百度、本源量子为代表的量子计算云提供商建立全栈式量子计算云服务，从上层应用软件，到中间开发平台，再到底层硬件后端，用户可根据自身需求完成量子计算研究与开发。量子计算云平台后端硬件接入和提供方式也有不同合作模式。一类是云平台供应商自身具备量子计算硬件研发能力，将自研的量量子计算发展态势研究报告（2023 年）34 子计算机或基于经典算力的量子线路模拟器置于云端，典型企业包括 IonQ、Xanadu、Rigetti、本源量子等。另一类是云平台企业凭借其云计算技术与资源，使其云平台可接入其他公司的硬件或软件，典型企业包括微软、亚马逊、Strangeworks等。此外，部分云平台在接入自研硬件的同时，也支持其他公司硬件资源的调用，如 IBM 量子计算云平台除自研超导量子计算芯片，还可调用 AQT、IonQ 等公司硬件资源。国内百度量易伏平台连接自研的超导量子计算处理器，同时也为中科院物理所的超导量子计算处理器以及中科院精测院的离子阱量子计算处理器提供了云接入服务。量子计算云平台业务已开始进入商业化探索阶段。计费模式包含即用即付型和按操作付费型两类。即用即付型也称为计时付费，用户按照接入云平台或量子硬件的时长进行计费。按操作付费型是根据基于某一确定后端计算任务的操作次数进行计费的收费模式。某些云平台也提供部分免费服务，即提供一定的免费次数或时长，或云平台中部分资源免费，但对高级功能和应用进行收费。当前以IBM、亚马逊为代表的科技巨头率先推出量子计算云平台的付费型服务模式，付费用户可以获得更高的接入权限和更好的服务体验。未来有望形成商业循环，进一步加强量子计算云平台的技术能力和生态影响力。相比而言，我国量子计算云平台目前尚未形成商业化运营和服务能力，在未来应用和产业生态竞争中可能落后。（四四）云平台成为开展科研与应用探索的重要支撑云平台成为开展科研与应用探索的重要支撑 随着量子计算技术的不断发展，基于量子计算云平台开展算法量子计算发展态势研究报告（2023 年）35 研究和应用探索已经成为业界热点。全球多个研究机构和企业积极探索量子计算云平台的应用并取得初步成果。目前，基于量子计算云平台的应用探索主要面向基础科研和行业应用两个主要方向。量子计算云平台辅助开展量子信息领域基础科研的有力工具。量子计算云平台提供了方便使用的量子计算资源，使得用户可在其上运行量子算法和量子模拟，有助于深入探究量子现象与性质，更高效地开展量子计算实验，探索量子计算的应用和潜力，为未来更广泛地应用量子计算奠定基础。2023 年，中科院物理所等团队基于Quafu 量子计算云平台实现了 10 比特的 Greenberger-Horne-Zeilinger纠缠态64。河北师范大学、中科院物理所等联合团队提出一种多测量环境下的广义状态依赖熵不确定关系65，并在 Quafu 量子计算云平台进行了实验验证。此外，部分云平台支持基于量子硬件指令集的实验工具套件，用于产生、编辑、校准和调度任意脉冲波形的测控信号，可实现量子系统动力学、量子门误差分析、表征和缓释、芯片参数标定、门脉冲校准、基准测评等领域的理论和实验研究，逐渐成为量子硬件研究与开发的辅助工具之一。目前 IBM的 Qiskit、百度的 Quanlse等平台支持开放脉冲级别的接口。脉冲级实验套件主要功能模块如图 12 所示。用户通过可视化客户端、SDK 或云平台自带的基准测试、错误缓释等工具生成业务实例，标定、校准工具对业务实例进行转译、校准并发送给脉冲发生工具，最终转化为微波或光学脉冲信号 64 https:/ 65 https:/journals.aps.org/pra/abstract/10.1103/PhysRevA.107.052617 量子计算发展态势研究报告（2023 年）36 序列作用于量子计算机，或将脉冲模型发送给量子线路模拟器，硬件层再将实验结果返回给用户。脉冲级实验套件是量子计算云平台一项特色服务，在硬件成熟之前具有重要应用价值。来源：中国信息通信研究院 图 12 量子计算云平台脉冲级实验套件功能 量子计算云平台在助力量子人工智能、量化金融、生物医药等领域应用探索方面也有重要价值。目前国内外众多量子计算云平台上均已提供大量的应用软件和接口，方便用户使用无代码或低代码的方式开展应用探索。在人工智能领域，量子计算云平台允许用户进行机器学习、神经网络等算法的应用探索。IBM Quantum 平台上提供了量子人工智能、量子机器学习、量子卷积神经网络的封装函数和代码示例，可用于数据分类、手写识别以及数据回归等。华为 HiQ 云平台上则提供了量子神经网络分类器、自然语言处理等方面的代码示例。在量化金融领域，量子计算云平台可提供金融数据分析、投资组合优化等实验。本源量子云平台上提供量子期权定价、期权策略收益期望应用、VaR 值应用、投资组合优化等模块，并与建信金科、量子计算发展态势研究报告（2023 年）37 中国民生银行等金融机构开展合作。百度量易伏云平台中的QFinance 可基于量子蒙特卡洛方法实现期权定价的计算。在生物医药领域，量子计算云平台可提供分子模拟等服务，有望应用于基因组学、蛋白质组学等领域，为生物医药领域提供更高效准确的工具。日本 QunaSys 的 Qamuy 平台提供分子结构优化、分子动力学模拟、吸收/振动光谱计算等服务，并与 JSR、三菱化学等机构联合开展光化学反应等研究。华为 HiQ 云平台提供面向量子化学的量子变分求解器。本源量子ChemiQ平台提供计算分子能量和结构、计算化学反应、模拟势能曲线、模拟动力学轨迹等功能。五、量子计算云平台标准和基准测评研究持续开展（一）（一）国内外积极国内外积极布局布局推动推动量子计算量子计算基准基准测评测评研究研究 基准测评通过设计科学的测试方法、工具和系统，对测试对象的性能指标进行定量和可对比。这种客观中立的评价方式已在计算机、人工智能、云计算等领域发挥了重要作用，量子计算基准测评对于表征硬件关键性能指标和评价系统能力有重要意义，也是分析量子计算技术产业发展水平的重要参考。国内外研究机构和科技企业纷纷布局开展量子计算基准测评研究。美国能源部启动量子科学计算开放用户测试床（QSCOUT）并推出Testbed 1.0，建立了面向离子阱量子计算机的测试床。国防高级研究计划局宣布推出量子基准（Quantum Benchmarking）项目，研究开发量子计算测评指标用于多维度客观评估当前硬件研发与未来实用需求的差距。欧洲 12 家机构联合发起量子计算应用项目，旨在量子计算发展态势研究报告（2023 年）38 为NISQ应用程序提供一个完整的通用工具集。德国慕尼黑量子谷启动 Bench QC 项目66，重点研究应用驱动的量子计算性能基准。2023年，中国移动成立量子计算应用与评测实验室67，旨在研究设计新型量子算法并形成量子算法库，将为不同技术路线的量子计算机能力与不同量子算法性能提供基准评测。随着量子计算原型机研制、软件研发、应用探索和云平台服务的快速发展，基准测评工作已逐步成为业界各方的关注热点话题。针对各类量子计算样机和量子计算云平台，开展基准测评技术研究与测试验证，是引导和促进样机工程化研发和应用推广的重要推动力量。量子计算云平台测评是对量子计算技术从硬件层到软件层再到应用层的全栈式检验。首先，通过测评可发现量子计算技术在实际应用中存在的能力差距问题，引导和推动量子计算硬件研发。测试评估结果也为量子计算技术攻关和改进优化提供了重要参考。其次，通过测评可以对云平台服务能力进行全面检测，从而获得其可靠性、可用性和稳定性等性能指标，为云平台改进和提升服务能力提供有力支持，助力提升用户对云平台的信任度，促进用户推广和发展。最后，开展测评可促进云平台标准化发展，通过制定统一的测评标准规范可确保不同平台间的兼容性和可扩展性，降低用户使用门槛，提高云平台易用性，推动行业健康发展。66 https:/www.iks.fraunhofer.de/en/projects/bench-qc-application-driven-benchmarking-of-quantum-computers.html 67 https:/ 量子计算发展态势研究报告（2023 年）39（二）（二）构建量子计算云平台基准测评体系参考模型构建量子计算云平台基准测评体系参考模型 构建量子计算云平台评价体系和测评基准，需要满足开放性、易用性、客观性、可复现性、科学性、系统性和可追溯性等原则，以确保测评结果的准确性和可靠性。开放性是指测试的方法和指标是通用的，并可通过公开方式获取。用户还可根据自身需求在源代码的基础上进行修改或增强，适用于特定场景的测试评估。易用性是指测试套件对于非量子计算专业人士，无需过多的调试与操作，同时测试结果尽可能直观，易于理解，例如采用通过率、正确率、评分等指标对量子计算机的性能进行评价。客观性是指每一项测评指标和用例具有明确且公认的定义，且测试结果不依赖于测试人员的主观判断，或将主观因素降到最低。可复现性，亦称为可靠性，即测试结果不随时间、地点以及人员等因素的变化而变化。重复测试多次，结果误差在一定范围内。科学性是指测评方法具有理论依据和可操作性，禁得起反复推敲，测试结果具有明确的现实意义。通过对结果的量化分析可定位问题或性能瓶颈。系统性是指测评性能的指标尽可能完备，能够综合、全面地评估量子计算机的性能；同时边界清晰，每个测试例具有明确的测试目的和适用范围。系统性还包括基准测评方法的可扩展性。可追溯性是指测试过程中全程留痕，数据归档，方便专业人员从中间数据结果中溯源问题。量子计算发展态势研究报告（2023 年）40 来源：中国信息通信研究院 图 13 量子计算云平台基准测评体系参考模型 量子计算云平台基准测评处于开放探索阶段，近年来业界提出多种表征指标与测试方法。本报告梳理总结提出了量子计算云平台的基准测评体系的参考模型如图 13 所示。纵向维度关注云平台的硬件、软件、应用和云平台等不同层面。越靠近硬件层测评越反映量子计算机技术能力，测评指标有较好通用性，适合硬件开发者使用。越靠近应用层测评越能够对量子计算机执行特定任务能力进行综合评估，屏蔽底层硬件细节，适合行业用户或应用开发者使用。云平台层面的测评则是根据量子计算云平台的服务模式从应用服务能力、平台服务能力、基础设施服务能力以及提供云服务必需的用户接入功能、管理运维功能、安全保障功能等维度开展。横向维度从规模、质量、速度三方面划分。其中，规模反映了量子计算机的极限能力，规模质量速度电路电路运行时间量子比特通信时间数据传输时间随机基准（RB）镜像电路线路宽度线路深度算法/应用App-Oriented Benchmark suite混合量子经典计算qBAS基准测试Q-Score云平台用户接入能力应用服务能力运营管理能力平台服务能力基础设施服务能力系统量子体积（QV）每秒电路层操作数(CLOPS)体积基准（VB）量子比特量子比特数目连通性串扰量子比特寿命T1量子比特相干时间T2逻辑门单/双量子比特门错误状态制备和测量错误门速度测量速度量子逻辑门集重置速度门集层析成像（GST）算法比特（#AQ）SupermarQ安全保障能力开放性易用性客观性可复现性科学性系统性可追溯性量子计算发展态势研究报告（2023 年）41 质量反映了执行量子计算任务的准确性和可信度，速度反映了量子计算机单位时间可完成工作量，三者共同支撑量子计算能力评估。（三）（三）开展测评实践验证，验证平台硬件实际能力开展测评实践验证，验证平台硬件实际能力 为有效评估量子计算云平台硬件发展水平，推动引导量子计算云平台技术、产业、服务良性发展，本报告基于基准测评体系框架开展了量子计算云平台的测评实践探索工作，对业界有代表性的量子计算云平台及其后端硬件开展初步测试验证。根据当前量子计算硬件发展现状、测评指标行业认可程度、可操作性等因素，本报告基于云接入的量子计算云平台硬件测试方法，开展了包括电路级、系统级和应用级等级别的测试实践，测试均基于统一的 QASM 测试电路集合，满足开放性、科学性、通用性和可复现性。表 6 展示了在量子计算云平台 1 和 2 上运行 6 个不同测试例的测评结果。表 6 量子计算云平台基准测评初步测试结果汇总 测试项测试项 量子计算云平台量子计算云平台 1 量子计算云平台量子计算云平台 2 超导量子计算机超导量子计算机 1 超导量子计算机超导量子计算机 2 测试结果测试结果 测试结果测试结果 电路电路级级 单比特 RB 0.9948（q1 比特结果）见图 14(a)0.9884（q0 比特结果）见图 14(b)双比特 RB 测试失败68（q1 比特结果）见图 15（a）0.9542（q0 比特结果）见图 15（b）系统系统级级 QV 8(23)见图 16(a)8(23)见图 16(b)应用应用级级 DJ 算法 见图 17（a）见图 17（b）QFT 算法 见图 18（a）见图 18（b）哈密顿量模拟算法 见图 19（a）见图 19（b）来源：中国信息通信研究院 68 量子计算云平台 1 对可运行的线路深度上限进行了限制，导致能测试 Clifford 深度有限，数据过少无法拟合函数。量子计算发展态势研究报告（2023 年）42 来源：中国信息通信研究院 图 14 单比特 RB 测试结果 来源：中国信息通信研究院 图 15 双比特 RB 测试结果 电路级测试结果如图 14 和图 15 所示，单/双比特门保真度等参数实测值和标称值约有 0.3%3%的相对偏差，主要是由于目前量子芯片性能不稳定，参数随时间产生一定的波动。另外云平台上通常标称的是整机所有比特平均值或中位值，而同一芯片不同比特之间性能也可能存在一定差异，本报告仅对部分比特进行测试，实测值与标称值存在微小差异属于正常现象。系统级测试的量子体积（QV）结果如图 16 所示，虽然两个云平台标称的量子比特数目均大于 3 个，但是执行量子体积电路后只能获得QV=8的结果，相当于仅能运行宽度和深度为3的方形电路。Clifford LengthClifford LengthP(0)P(0)(a)量子计算云平台1结果（Q1）(b)量子计算云平台2结果（Q0）(a)量子计算云平台1结果（Q1）(b)量子计算云平台2结果（Q0）(a)量子计算云平台1结果（Q1）Clifford LengthClifford LengthP(00)P(00)量子计算发展态势研究报告（2023 年）43 可能有两方面原因：一是由于量子比特本身的保真度不高，当逻辑门序列长度增大时，结果保真度会呈现指数下降的趋势，当序列长度过大时其结果与理想输出结果的差异较大，无法满足重输出判定规则。二是QV基准对于比特连通性要求较高，运算过程中量子比特无法保证全连接时，可通过添加 SWAP 门等方式连接不相邻的比特，但增加逻辑门序列长度导致测试结果劣化。由于超导量子计算处理器中的量子比特只能与周边有限个量子比特连接（比如相邻的 2 个或 4 个），因此比特连通性会严重限制 QV测试最终结果。来源：中国信息通信研究院 图 16 量子体积（QV）测试结果 应用级测试结果如图 17至图 19所示，本报告选择了几种典型应用算法作为测试基准，包括演示级算法、子程序级算法和功能级算法。演示级算法是指利用浅深度的量子线路实现简单功能，仅可解决部分抽象出来的特殊问题，一般不具有实用价值，如 DJ 算法等。子程序级算法是指大型功能性应用程序算法中的子程序或功能模块，如 QFT 算法等。功能级算法是指具有完成应用功能的复杂算法，如哈密顿量模拟算法等。Shor 算法、Grover 算法等均具有重要应用价值，但对于量子比特数目和保真度要求较高，现有硬件无法满足，量子计算发展态势研究报告（2023 年）44 因此本报告中暂不涉及，仅以哈密顿量模拟算法为代表的测试量子计算处理器运行功能级算法的能力。来源：中国信息通信研究院 图 17 DJ 算法测试结果 演示级 DJ 算法测试结果如图 17 所示，由于线路深度较浅，运行结果可保持较高保真度，但随着量子线路宽度和深度的增加，结果保真度略有下降。当线路宽度达到 8 时，保真度小于 70%，由于DJ 算法的执行结果是选取概率最大的量子态，此保真度尚能满足算法需求。但是当线路宽度进一步增大，线路输出保真度低于 50%后，则有一定概率输出错误结果。来源：中国信息通信研究院 图 18 QFT 算法测试结果 子程序级 QFT算法结果如图 18所示，量子线路更为复杂，因此(b)量子计算云平台2结果(a)量子计算云平台1结果(b)量子计算云平台2结果(a)量子计算云平台1结果量子计算发展态势研究报告（2023 年）45 随着比特数的增加，结果保真度迅速下降，当量子比特数较大时已无法满足应用的需求。以 Shor算法为例，演示整数 15的分解就需要运行至少 8 比特的逆量子傅里叶变换（IQFT）电路，从测评结果来看此时结果保真度已经低于 10%，无法获得有价值的结果。随着待分解整数的增大，需要的量子比特数目和量子线路深度会进一步增加，对量子计算处理器硬件规模和质量提出更高要求。来源：中国信息通信研究院 图 19 哈密顿量模拟算法测试结果 功能级哈密顿模拟算法测试结果如图 19 所示，由于哈密顿量模拟算法原理特殊性，量子线路复杂性随比特数目的增加变化不大，因此结果保真度的下降趋势相对缓和，这也是哈密顿量模拟算法被视为当前硬件条件下比较有应用前景的算法的原因。但可以看出当量子比特数增加到 8 个时，结果保真度已下降至 40%左右。然而以化学模拟为例，对于真实的多电子体系的计算化学求解问题，其哈密顿量的参数空间为=()() 1/2，计算复杂度约为(2)，其中 m 为基函数数目，n 为电子数目。可见如要解决计算实际化学问题，当前量子计算云平台提供的硬件在规模和质量上尚难以满足要求。(b)量子计算云平台2结果(a)量子计算云平台1结果量子计算发展态势研究报告（2023 年）46 此外，测试发现部分量子计算云平台对可运行的量子线路深度严格限制，超过门限深度的线路运行会报错。一方面，由于当前硬件性能有限，执行过深的量子线路的返回结果保真度很低，从应用角度看意义不大，限制线路深度可保证用户获得有效的运行结果。但另一方面，对于研究性质的任务（例如研究量子比特保真度对特定应用算法的影响），用户希望获得极限情况下的真实运行结果，人为设定量子线路深度上限将限制用户使用。根据上述测试结果可以看出，现阶段我国量子计算云平台处于发展起步阶段，所提供的量子计算硬件能力较为初级，在执行较为复杂的电路时，输出结果保真度下降较快，难以满足算法可靠性的要求。量子计算处理器是量子计算云平台的核心组件，硬件水平是制约着量子计算云平台应用推广的关键瓶颈，未来需要持续研发攻关，提升量子计算硬件的关键性能指标。（四）（四）量子计算云平台标准体系建设需进一步推动量子计算云平台标准体系建设需进一步推动 量子计算技术研究、样机研制和应用探索正在加速发展，相关技术标准研究和讨论在国内外广泛开展。ISO/IEC、ITU-T、IEEE 等国际性标准组织，以及全国量子计算和测量标准化委员会（TC578）等国内标准化组织，均积极开展量子计算标准化工作布局和标准预研等工作。目前主要关注和研究量子计算相关概念术语和定义，提出量子计算的性能评价的准则和方法等方面。国际标准化组织（ISO）和国际电工委员会（IEC）第一联合技术委员会（ISO/IEC JTC 1）成立 WG14 量子计算工作组，开展量子量子计算发展态势研究报告（2023 年）47 计算领域标准研究工作，由我国牵头提出的信息技术 量子计算 术语和词汇国际标准提案在 ISO/IEC JTC 1 成功立项，编制量子计算简介技术报告，并在量子计算服务平台框架、量子机器学习数据集、量子模拟器等方面提出预研项目。国际电子电气工程师协会（IEEE）有 10 个工作项目在进行量子计算领域的标准化研究。重点关注澄清概念、定义术语、识别标准化需求并提供性能指标和基准，以及量子计算机和量子模拟器的功能架构、算法开发设计和计算能效测试等方面内容。全国量子计算与测量标准化技术委员会（TC578）于 2023 年 5月发布量子计算领域首个国家标准量子计算 术语和定义，规范量子计算通用基础、硬件、软件及应用方面相关术语和定义，为量子计算发展提供指导。近期，进一步推动了量子计算基准测评、云平台功能框架和性能指标测试方法等相关标准立项和研究工作。01基础标准术语定义参考功能框架标准集成应用指南02 软硬件标准虚拟化量子计算处理器经典服务器经典存储设备经典网络设备平台与软件03 管理与运维标准数据资源管理网络资源管理量子/经典计算资源管理平台资源管理终端资源管理资源管理存储资源管理资源调度资源监控故障管理运维模型运营维护04 服务标准服务采购服务水平协议服务目录设计与部署数据和服务迁移计量和计费内容和原则交付质量管理治理与审计能力要求运营05安全标准安全管理服务安全安全技术与产品安全基础量子计算发展态势研究报告（2023 年）48 来源：中国信息通信研究院 图 20 量子计算云平台标准体系架构 量子计算云平台目前处于发展起步阶段，相关标准化研究工作相对空白，量子云服务的多样性以及量子计算硬件平台的异构性为不同软硬件之间以及云平台之间的互操作带来了巨大的挑战。根据量子计算云平台体系架构和国内外技术产业生态发展现状，并参考经典云计算的标准体系架构，本报告提出量子计算云平台标准体系架构的初步建议，如图 20 所示。其中，基础标准统一量子计算云平台及相关概念，为其他各部分的标准制定提供支撑。软硬件标准是标准体系架构中的核心部分，规范和引导量子计算云平台中的关键软硬件产品研发，硬件主要包括量子计算处理器、经典服务器、经典存储器、经典网络以及提供和使用云服务的终端设备等，软件主要包括云平台软件和应用服务软件等。为实现软硬件的一致性和互操作性，需要对软硬件的性能、功能、接口及测评等方面进行规范。管理运维标准规范量子/经典计算、存储、网络等资源管理与使用，主要涉及各类资源的管理、调度、监控，以及故障管理等。服务标准规范量子计算计算云平台在提供云服务过程中的各个环节，涉及各类云服务和面向量子计算云平台建设运营的云支撑服务。安全标准是实现量子计算云平台安全的重要保障，主要涉及接入安全、数据安全、用户隐私保护、物理机/虚拟机安全、恶意攻击防范等方面，也是影响量子计算云平台发展的关键因素之一。鉴于量子计算硬件及云平台尚处于发展初期，建议优先开展量量子计算发展态势研究报告（2023 年）49 子计算云平台术语定义、功能框架、软硬件基准测评指标和方法、软硬件接口，以及基础的管理运维和安全类标准研究，服务类的标准可待云平台服务和商用模式明确后再开展。开展量子计算云平台标准体系建设，将有助于屏蔽技术差异，实现互联互通，推动量子计算云平台技术、产业和应用的健康发展。六、机遇与挑战并存，多策并举加快量子计算发展 量子计算对未来数字经济产业升级，信息社会发展演进等领域将产生重要变革和驱动，成为全球科技竞争关注焦点之一。当前，量子计算优越性已得到验证，超导、离子阱、中性原子、光量子、硅半导体等技术体系并行发展，基础科研与工程实验成果不断涌现，各领域应用场景加速探索，产业生态逐步构建。国内外量子计算云平台加速发展，成为助力基础科研与应用探索，促进样机研发和应用推广的重要推动力量。量子计算已进入技术攻关、工程研发、应用探索和产业培育一体化推进的关键阶段，未来发展前景可期。也应看到，量子计算仍有诸多技术工程和应用产业问题需突破。硬件研发方面，需要在研制更高性能量子计算原型机的同时，提升量子态制备、逻辑门操作和量子态测量等关键技术，开发量子纠错编码算法和硬件实现方案。应用探索方面，进一步开发解决实际应用问题的计算模型和量子算法，积极探索重点行业领域的应用场景。产业推进方面，发挥产业联盟、开源社区等平台的生态培育作用，加强企业和产业化培育，进一步推动供应链和生态建设。量子计算云平台方面，需要提升后端硬件性能，持续完善云平台功能和服务量子计算发展态势研究报告（2023 年）50 模式。基准测评方面，需要进一步完善性能指标体系与测评方法，构建量子计算基准测试验证平台能力。同时，相比欧美而言，我国量子计算原型机工程化研发水平，供应链自主保障能力，企业界研发投入和创新驱动力，顶层规划设计与发展体制机制，产学研协同合作方式，重点行业领域应用探索和推广等方面，仍有一定差距，未来发展也面临不进则退、慢进亦退的风险。未来，加快推动我国量子计算领域发展，需要产学研用各方多措并举，形成协同创新合力。一是持续稳定支持科研探索与研发攻关，加强顶层规划设计，掌握和突破量子计算核心技术，加强供应链安全保障能力建设，补齐支撑能力短板。二是加快重点行业领域应用探索，促进量子计算企业与行业企业开展合作研发，提升应用转化能力，建设国家级量子计算云平台，促进应用探索。三是加强产学研协同合作，依托产业联盟等平台加强各方合作，积极开展量子计算系统测试校准、基准测评等验证工作，助力硬件研发与云平台服务能力完善，支撑技术产业发展。中国信息通信研究院中国信息通信研究院 技术与标准研究所技术与标准研究所 地址：北京市海淀区花园北路地址：北京市海淀区花园北路 52 号号 邮编：邮编：100191 电话：电话： 传真：传真： 网址：网址：

0人已浏览 2023-12-29 57页 5星级

点击查看更多中国科学院：2023机密计算：现状与展望报告（22页）.pdf精彩内容。

0人已浏览 2023-12-29 22页 5星级

点击查看更多边缘计算产业联盟：算力时代的边缘计算（2023）（15页）.pdf精彩内容。

0人已浏览 2023-12-28 15页 5星级

20232023年中国年中国云原生数据库十大厂商推荐云原生数据库十大厂商推荐头豹研究院弗若斯特沙利文咨询（中国）数据库理念变革、AI4DB、DB4AI、可观测性2023年12月沙利文市场研读沙利文市场研读400-072-55882u中国云原生数据库行业综述中国云原生数据库行业综述 云原生数据库定义 云原生数据库发展阶段 云原生数据库必要性分析u中国云原生数据库技术发展趋势中国云原生数据库技术发展趋势 与大数据深度结合 与人工智能深度结合 资源使用持续优化 优化可观测性能力u中国云原生数据库市场分析中国云原生数据库市场分析 云原生数据库市场发展现状与环境分析 云原生数据库需求场景与基本要求 需求端：云原生与本地部署选择思路 供应端：云原生数据库布局分析u中国云原生数据库行业竞争分析中国云原生数据库行业竞争分析 中国云原生数据库竞争力评分维度 中国云原生数据库综合竞争表现 中国云原生数据库标杆企业u名词解释名词解释u方法论方法论u法律声明法律声明研究框架研究框架400-072-5588沙利文市场研读沙利文市场研读3章节一章节一行业综述行业综述1.1云原生数据库定义云原生数据库定义q云原生云原生数据库的核心是云原生理念带来的数据库架构变革与服务效能提升数据库的核心是云原生理念带来的数据库架构变革与服务效能提升本报告所定义的云原生数据库：基于云计算基础设施特点进行架构设计，充分利用云上计算、存储、网络等资源，从而实现性能增强与功能范围扩大的数据库，具有高可扩展性、高弹性、高安全、可观测性、可高度自动化的特性。云原生数据库主要代表了数据库部署模式及架构向云环境的适应与演进，与数据模型无关，SQL与NoSQL数据库均可发展成为云原生数据库。沙利文认为，云原生数据库的核心为云原生理念带来的数据库架构变革与服务效能提升，具体而言：数据库架构变革：云原生数据库采用存算分离架构，设计紧贴云计算基础设施特点。在这设计理念下，云上计算与存储资源调用的效率与利用率得到提高，并能降低网络损耗，从而优化数据传输性能与存储能力，实现数据库的性能增强。同时，通过打破传统数据库架构在云环境下的限制，云原生数据库对云上资源的把控度更高，能够实现资源的按需使用、弹性伸缩，显著提高用户业务流量变化的敏捷度，并降低数据库服务的使用成本。服务效能提升：云原生数据库与云计算环境下的技术与工具深度整合，包括AI、可观测性工具等。通过应用这些技术与工具，数据库厂商能够为用户提供弹性负载均衡、智能监控、智能运维等服务，从而拓宽数据库服务的功能边界。同时，数据库厂商借助这些工具，可以构建数据库DevOps团队，实现数据库能力快速迭代与功能演进。基于这些变化，云原生数据库能够更为全面地满足用户降本增效的需求。云原生数据库的两大核心云原生数据库的两大核心来源：云原生数据库：原理与实战，沙利文关键关键发现发现云原生数据库的本质是云原生理念带来的数据库架构变革与云服务水平进化，通过紧密贴合云计算基础设施进行数据库架构设计，能够更充分地发挥出云计算的优势，使数据库性能与功能范围扩大Text here云原生云原生数据库数据库数据库架构变革数据库架构变革服务效能提升服务效能提升用户数据库厂商丰富工具助力提高数据库运维效率与性能优化构建数据库DevOps，快速应对用户需求变化进行迭代资源解耦与池化弹性伸缩资源按需使用动态容灾（高可用）计算节点无状态（基于更灵巧的存储方式，利用多副本与共识算法提供高可用能力。同时还能提供全球数据库、故障自愈等功能）（提高弹性灵活度与速度）400-072-5588沙利文市场研读沙利文市场研读41.2云原生数据库发展阶段云原生数据库发展阶段q云上部署数据库经历了云托管云上部署数据库经历了云托管、云服务云服务、云原生三大阶段云原生三大阶段数据库在云上部署的演进经过了三大阶段：云托管、云服务、云原生，需求变化、技术革新、架构创新为三大阶段发展的核心影响因素。最初，云托管主要解决的问题是IDC机房部署带来的物理设备维护压力，用户将传统数据库软件部署到云主机上，数据库管理工作仍由用户负责。随着云服务供应商技术能力提升、团队更为完善，供应商兼顾起数据库运维的工作，对数据库性能与功能进行优化，用户仅需通过接口访问的方式便能使用上性能较高的数据库，减轻用户数据库运维的成本与压力，使用户更好地从云计算服务中受惠。在前两个阶段，厂商主要完成了减轻用户对于资源运维以及数据库运维压力与利用共享资源池降低使用成本的任务，并一定程度上优化数据库性能与功能，但由于传统架构的限制，数据库仍未能充分发挥出结合云计算所能产生的高可扩展性、高弹性、高可用的优势。在数据要素地位显著提升的趋势下，企业数据容量持续增长，高并发的业务需求提升，同时云计算也成为了承载工作流的主要环境。面对这些场景时，云服务阶段的云数据库能力存在着扩展效率低、资源利用率低等问题，难以满足需求变化。因此，数据库通过技术革新、架构创新完全与云计算系统融合，以步入云原生阶段成为了在云上部署发展的必然。云上部署数据库的演进实际上是云上部署数据库的演进实际上是“以资源为中心以资源为中心”转变为转变为“以应用为中心以应用为中心”来源：51CTO，沙利文关键关键发现发现云上部署数据库由云托管演进至云原生，实际上是“以资源为中心”转变为“以应用为中心”。随着技术与工具不断完善，用户将能更容易的实施数据库迁移与理解迁移效益，从而提高对云原生数据库的了解与接受度，将有效推动云原生数据库市场发展变，云原让数据库实现真正意义上的横向扩展！算解耦、章节一章节一行业综述行业综述以资源为中心（传统部署模式）以资源为中心（传统部署模式）以应用为中心（以应用为中心（Serverless部署模式）部署模式）规划应用容量评估数据库资源购买匹配规格调整规格评估应用访问压力，得出性能评估模型根据性能评估模型测试出数据库资源需求根据数据库资源需求购买相应规格的数据库资源根据应用现网运行情况重新调整规格匹配资源最高规格最低规格负载上升负载下降升级规格n升级规格400-072-5588沙利文市场研读沙利文市场研读5q云原生数据库进入快速发展阶段云原生数据库进入快速发展阶段，Serveless部署模式是核心方向部署模式是核心方向从第一款云原生数据库问世至今的十年间，云计算与云原生技术得到了不断的完善，支撑着云原生数据库迭代更新与功能完善，性能显著提高，同时业内云原生数据库产品矩阵也变得更为丰富，如多种数据模型的数据库、深度集成的智能运维工具，能够以更灵活与全面地满足不同场景的需求。云原生数据库已完成技术沉淀与商用验证，开始步入快速发展阶段。在快速发展阶段，云原生数据库发展的关键在于能够更为充分地发挥出云原生带来的弹性资源按需分配与精准计费、数据库易于管理的价值，更高效与灵活地应对企业应用需求，因此能够进行更细粒度的资源部署、免于用户对数据库底层设施运维的Serverless 部署模式成为当前阶段发展的核心方向。来源：中国信息通信研究院，沙利文，头豹研究院q用户对云原生数据库认知逐步提高用户对云原生数据库认知逐步提高，进一步增强用户需求进一步增强用户需求据中国信息通信研究院统计，考虑应用云原生数据库的企业占调查样本的91%，反映出云原生数据库的价值已得到用户的感知。据头豹研究院访谈调研，当前企业对于云原生理念接受度已得到显著提高，但由于传统架构的数据库的部署和应用方式已使用多年，且更贴合用户认知与使用习惯，部分企业在是否改为使用云原生数据库时存在犹豫。实际上，转换至云原生数据库对现有应用的改变并不大，这部分企业的犹豫主要源于对云原生数据库的了解程度不足。随着Serverless数据库技术越来越成熟，数据库厂商的生态工具能力（如FinOps、数据库迁移工具）越来越完善，将有利于促进企业以更灵活便捷地进行测试使用，有效感知云原生数据库，并逐步积累案例形成宣传作用，进而提高市场整体对云原生数据库认知。企业应用云原生数据库意愿高企业应用云原生数据库意愿高，要实现快速发展需提高企业认知要实现快速发展需提高企业认知章节一章节一行业综述行业综述57.93.1%9.0%应用在主要业务系统中应用在一般业务系统中不会应用企业应用云原生数据库意愿调查企业应用云原生数据库意愿调查当前影响选择云原生数据库的主要因素当前影响选择云原生数据库的主要因素认知不足认知不足/习惯冲突习惯冲突架构复杂或架构复杂或耦合度高耦合度高问题问题：传统DBA对于云计算技术理解与掌握程度有限。云原生数据库服务水平升级，运维方式转变与现有习惯存在冲突。解决方案：解决方案：数据库厂商提供技术分享、案例展示等方式提高认知。通过扩展与适配工具，提供Serverless部署帮助用户更容易上手，转变习惯数据安全数据安全问题问题：云原生数据库部署环境主要为公有云环境，数据受到的潜在威胁增多解决方案：解决方案：数据库厂商需持续完善数据库安全功能，如多层访问控制、审计和数据加密、数据备份和恢复、服务安全等技术问题问题：现有数据库与应用耦合度高，应用业务逻辑复杂。转换工作量过大、效益不明确解决方案：解决方案：领先的数据库厂商拥有方法论沉淀，提供迁移评估、迁移策略支持、数据库迁移工具等生态工具，能够帮助用户平滑迁移数据库。同时通过提供FinOps与Serverless等能力，有助于用户对效益有效感知400-072-5588沙利文市场研读沙利文市场研读61.3云原生数据库的必要性云原生数据库的必要性q云原生数据库服务将数据库的使用理念转变至云原生数据库服务将数据库的使用理念转变至“以数据为中心以数据为中心”传统数据库的使用理念为“以数据库为中心”，主要集中在对数据库的管理和维护，如硬件资源的配置、数据存储的优化和查询性能的调整。在面对不同业务负载时，用户需要管理维护多个相同或不相同数据模型的数据库，并处理数据库间的数据交互工作。云原生数据库以云计算服务的形式交付，其核心理念转变为“以数据为中心”。在运维管理层面，凭借云原生数据库与云资源的充分结合，以及与配套工具的深度集成，数据可实现无缝访问、高效处理和智能分析。在这种模式下，云原生数据库能够提供动态资源管理、可扩展性和故障快速恢复能力。同时，数据库厂商可打通不同数据模型的数据库服务间的数据链路，根据不同业务负载可匹配数据库服务，数据库间数据自动同步。因此，企业可以更加专注于数据价值的提炼和业务逻辑的实现。此外，云原生数据库可以提供全球跨地域数据同步，应用可以低时延就近访问数据库。这能够帮助企业实现全国乃至全球的业务拓展，并为企业提供全球跨地域的数据库容灾能力。q云原生数据库将是支撑企业数据驱动业务战略发展的核心基础云原生数据库将是支撑企业数据驱动业务战略发展的核心基础随着精细化运营的深入发展，企业内多业务间的数据互联互通与复杂性日益加深。面对多样化和不同量级的数据时，企业需要能够保持性能稳定和低时延的数据库解决方案。同时，在各国持续推进云计算战略的趋势下，企业业务上云将不断深化。目前，中国已推出一系列政策推动云计算技术推广与深度应用，为云上服务需求建立基础。在这环境下，云原生数据库通过提供完善的服务，减轻单一或多个数据库使用的复杂性，并能利用资源弹性帮助企业应对业务的快速变化，为企业推动数据驱动业务战略发展提供核心基础。云原生数据库云原生数据库“以数据为中心以数据为中心”理念下可实现的功能理念下可实现的功能来源：沙利文关键关键发现发现云原生数据库引领数据库使用理念向“以数据为中心”转变。数据库厂商通过提供更全面的数据库服务，降低企业对数据库运维管理的关注，更专注于数据价值的提炼和业务逻辑的实现。这种方式更符合数据驱动业务、企业上云趋势下的企业对于数据库使用需求章节一章节一行业综述行业综述SQLNoSQL关系型数据库非关系型数据库数据仓库（数据管理解决方案）数据库服务深度集成数据库服务深度集成全球数据库全球数据库主节点（上海）同步节点（北京）同步节点（新加坡）提供就近读取、基于物理复制，低时延跨地域同步能力。在不同区域一样感受地使用数据库资源，并提高容灾能力 通过深度集成，提高数据处理效率 减轻用户对多类型数据库运维管理压力，专注数据分析与应用本身可观测性能力优化可观测性能力优化 云原生数据库与云上资源充分结合，能够更好地收集到数据库内部与外部数据，从而进行问题分析、系统诊断 凭借与生态工具深度集成，能够显著减轻用户发现与理解问题的压力，并可提供智能化工具，协助性能调优日志链路追踪指标400-072-5588沙利文市场研读沙利文市场研读7关键关键发现发现AI与数据库的深度结合包括AI4DB与DB4AI两个方向。AI4DB能够显著提高数据库运维管理、性能优化的效能，具有巨大的应用潜力。同时，DB4AI能够应对AI落地的挑战，实现AI效率提高与成本降低。这两种方式相辅相成，共同推动AI与数据库技术的进步与创新章节一章节一技术跟踪技术跟踪2.3与人工智能深度结合与人工智能深度结合q AI4DB的应用具有巨大潜力的应用具有巨大潜力，数据库厂商应及早开始布局实现技术沉淀与能力提升数据库厂商应及早开始布局实现技术沉淀与能力提升AI4DB即利用AI优化数据库，以更精准、更高效、更敏捷的能力进行数据库的运维与管理，提高处理复杂工作的效率，减少日常工作负担，释放人脑带宽处理更重要的事情。AI4DB的实现可以分为以下四个发展阶段：建议建议阶段：阶段：这个阶段主要通过插件式的智能工具，聚焦减少消耗人脑带宽的工作，如负载管理优化、数据库性能监控预警、数据库审计、SQL优化。目前，大部分数据库厂商已经落地了智能运维工具实现这些功能。同时基于AIGC，部分工具已支持NPL2SQL功能，简化SQL编写与优化的工作难度。辅助辅助阶段：阶段：AI的辅助可以进一步集成到数据库的组件中，如AI调优模型与查询优化器结合，通过查询调优用户级参数，自动适应不同的查询特性。这个阶段专注于增强数据库各项特定能力。部分厂商已开始利用AIGC与模型交流，不断演进判断逻辑，启发出新的根因分析定位思路。增强阶段：在上一阶段的基础上，降低人工对于AI模型优化的干预需求，利用深度强化学习能力，适应不同环境提供动态调优、动态最优索引方案推荐等能力。这一阶段的能力相当于数据库内置AI服务，利用AI算法进行自我增强，可以进一步降低对于DBA经验的依赖，并能得出经验难以推断出的优化方式。自建阶段：基于深厚的数据与算法积累，AI形成自主设计、组装、评估、监控、运维数据库的能力。数据库是一个复杂的系统，同时也是承载着众多业务运行的关键数据底座。在这背景下，AI4DB的应用具有巨大潜力，但是在实用性与可靠性等方面面临着许多挑战。不过，AI能力的增强依赖于持续的数据积累，数据库厂商应开始布局构建和应用相关能力，以实现AI4DB技术沉淀与能力提升。AI4DB演进路径演进路径来源：轩辕:AI原生数据库系统，沙利文AI4DB路径路径建议阶段（主要基于AI工具插件）辅助阶段（AI与数据库组件结合）增强阶段（数据库内置AI服务）自建阶段（AI建设数据库）功能例子功能例子负载管理SQL优化数据库监视器数据库审计自配置自优化自监测自诊断自愈自安全学习型查询重写器学习型代价估算器学习型优化器学习型执行器学习型存储引擎学习型索引自设计、组装、评估、监控、运维数据库自调配硬件资源400-072-5588沙利文市场研读沙利文市场研读8章节一章节一技术跟踪技术跟踪q建立建立DB4AI的能力能够应对的能力能够应对AI落地的挑战落地的挑战，实现效率提高与成本降低实现效率提高与成本降低沙利文认为，当前AI落地其中两大挑战是硬件要求提高与效率问题。一方面，随着模型参数越来越多，硬件要求与成本随之提升。另一方面，数据与模型的交互较为复杂，在业务需求持续变化、算法效果要求持续提升、数据量持续膨胀的趋势下，这个复杂度只会越来越高。基于传统的研发流程会导致模型落地效率低，其中包括数据流动效率以及工作流程效率。DB4AI指根据AI模型训练的需求，优化数据库对数据存储、管理、操作的效能，从而使训练过程更为高效。具体可实现的能力包括：简化建模：简化建模：通过数据库内部对数据、特征、AI模型进行统一管理，并提供统一SQL接口，用户可以利用SQL完成模型的开发、训练、推理，无需使用多种语言（如Python、R语言）进行AI的开发；辅助计算：辅助计算：在数据库内部增加AI算子和支持向量计算功能，利用数据库计算能力完成模型的训练及推测任务，减轻AI训练的算力负担；模型重用：模型重用：通过物化视图、查询表等方式将AI模型持久化，方便用户管理与复用模型利用上述功能，数据与AI深度结合可以避免各模型数据管理割裂，降低数据管理复杂度与数据延迟。数据流动效率能够得到提高，工作流程也得以简化。同时，通过对数据、特征、模型统一管理，以及AI训练及推测任务功能支撑，AI相关硬件的需求也能够有所降低，进而降低硬件成本。AI模型涉及的流程与元素以及模型涉及的流程与元素以及DB4AI对算法研发流程优化的展示对算法研发流程优化的展示来源：轩辕:AI原生数据库系统，沙利文DBA/数据科学家算法工程师AI模型后端工程师数据库业务系统传统算法研发流程传统算法研发流程DB4AI的算法研发流程的算法研发流程 AI模型管理后段工程师具DB4AI能力的数据库业务系统效率提升成本下降传统算法研发流程演进至使用DB4AI的算法研发流程对比特征管理数据管理AI模型训练涉及的流程与元素在线部署、离线推理数据清洗、特征计算AI业务算法数据模型部署数据加工模型训练模型评估模型选择、参数选择优化效能、保持稳定AI部署需要综合考虑业务、算法、数据三大元素。随着时间的推移，这些元素也正在不断的迭代、演进，如业务需求持续变化；算法需持续更新并保持质量；数据体量持续扩大，对AI落地带来日益的挑战在AI模型训练过程包含多个工序，其中模型与数据的交互涉及多个系统，在迭代过程当中复杂度持续提高400-072-5588沙利文市场研读沙利文市场研读9关键关键发现发现为最大程度地发挥出云原生数据库提升资源利用率以降低成本的价值，用户面临着资源配置优化与成本管理困难两大挑战。数据库厂商应提供完善的资源部署策略、持续优化Serverless性能，并提供FinOps工具，帮助用户优化资源使用的效能章节一章节一技术跟踪技术跟踪2.4资源使用持续优化资源使用持续优化q提供高效部署策略与提供高效部署策略与FinOps工具将是帮助用户优化资源使用效能的关键工具将是帮助用户优化资源使用效能的关键提升资源利用率以节约成本是云原生数据库核心价值，但要充分发挥出这一价值仍面临着两大挑战：资源配置优化与成本管理困难。资源配置的挑战主要源于配置手段存在一定复杂性，以及业务负载不断变化。依赖于人力对这些手段精心搭配，难以充分地在复杂且动态变化的环境中将资源配置价值最大化，同时大部分用户仍然以传统资源配置思维管理资源，导致浪费严重。成本管理的困难是因为云原生技术的导入使传统集中式财务预算和IT管理模式带来变化。传统数据库的财务预算模式是预先评估硬件、软件资源购买量，预算明确。在云原生的环境下，由于资源弹性伸缩，导致成本存在不确定性和变动性。此外，云原生数据库可能在多个业务部门部署，服务追踪与成本分配复杂度也有所提升。应对这些挑战的关键在于解决资源浪费的问题，其主要原因通常是业务资源需求设定过高。为此，云原生数据库需要能够提供单一集群中读写节点预置模式与Serverless结合的策略，实现资源保底，并具能应对波峰的弹性。Serverless数据库技术也正不断演进当中，性能持续优化，使资源消耗最小化。此外，这些部署应提供根据负载变化自动调整的能力，从而降低人力配置的需求，实现资源配置能力优化。同时，提供FinOps工具对于引导用户从传统财务预算和IT管理模式向适应云原生环境的管理方式转变至关重要。FinOps工具应提供规格推荐、预算与配额管理的可视化指引，并检查出不合理配置、负载感知调度与拓扑感知调度等能力，为持续的费率、弹性优化提供支持。通过对业务算力使用情况建模和量化，并建立水位线、冗余度等配套指标体系，企业可以得到建议并通过各种策略，如削峰填谷、资源在离线整合，以及自动化扩缩容，有效地优化资源配置，从而真正地实现降本增效。可考虑提供的云原生数据库部署可考虑提供的云原生数据库部署模式模式与完善企业与完善企业FinOps实施的关键点实施的关键点来源：51CTO，沙利文共享存储共享存储RO预置预置RW预置预置RWServerless单一集群预置与单一集群预置与Serverless混合部署与切换混合部署与切换单一数据库实例弹性化部署单一数据库实例弹性化部署基础基础付费付费租用租用付费付费（闲置即释放）（闲置即释放）预预定义资源最定义资源最小最大范围，小最大范围，随时扩展随时扩展MaxMin资源可资源可分配分配数据可数据可视化视化文化文化建设建设自动化自动化流程与流程与机制机制参与角色：参与角色：决策部门、业务部门、财务部门、运维与技术部门FinOps的实施需要企的实施需要企业有意识地内部文化业有意识地内部文化与流程机制与流程机制数据库厂商应提供资数据库厂商应提供资源分配功能，丰富数源分配功能，丰富数据覆盖度以便问题洞据覆盖度以便问题洞察。同时可提供一站察。同时可提供一站式式FinOps平台打通平台打通数数据链路，促进部门间据链路，促进部门间协同协同400-072-5588沙利文市场研读沙利文市场研读10本报告设立云原生及创新功能与技术、基础功能与技术、运维与管理、安全保障、服务与市场、生态建设六大维度对竞争主体表现分别进行评价。根据得分情况对竞争主体的各项能力进行梯队划分，并基于各项能力的总得分展示竞争主体的综合能力云原生云原生数据库厂商数据库厂商评估指标体系评估指标体系评分维度评分维度评分指标评分指标要点要点云原生及创新功能与技术产品分类数据模型、负载场景、分布式架构、部署场景云计算服务能力资源隔离、资源利用率优化、混合多云云原生能力扩缩容性能、大规模性能与稳定性、Serverless、HTAP分布式架构创新能力事务吞吐优化、存算分离、HTAP性能可观测性能力性能指标、日志、链路追踪DB4AI技术储备SQL调用机器学习、库内训练和推理、自动特征工程基础功能与技术数据库事务类场景能力事务架构、一致性、并发控制、事务吞吐优化数据库分析类场景能力分片规则、平滑扩展、性能扩展损耗、跨域分区分布式架构基础能力物理资源层、可扩展性、跨地域部署能力运维与管理运维优化能力智能运维工具、负载均衡、查询优化、SQL优化AI4DB运维技术储备数据库配置、性能优化、数据库监测、AIGC应用数据库管理能力资源隔离级别、网络拓扑检测、主机负载下移安全保障数据备份管理能力备份恢复、备份管理、节点管理、高可用功能数据库灾备建设机房故障切换方案、异地容灾切换时长、各类故障RTO数据库访问安全权限管理、身份鉴别、防恶意入侵、访问控制数据安全分级分类、数据脱敏、数据加密、数据遮掩审计能力审计记录范围与保护安全防护能力漏洞扫描、防SQL注入、防勒索、DDoS防护生态建设开发开放兼容性开发接口、SQL标准、语法兼容、开放引擎、新型硬件迁移适配改造高可移植性工具和服务、迁移方案、不停机升级技术可持续发展性研发路径、标准编写、学研、人才、布道、合作伙伴国产化适配建设服务器、芯片、中间件、操作系统、最优组合服务与市场服务支持实施服务、增值服务、专家团队、产品文档商业落地成熟度行业领域应用广度 产品覆盖行业领域广度行业领域应用深度 产品落地颗粒度及深度优势服务模式 面向需求持续优化服务能力章节四章节四竞争分析竞争分析400-072-5588沙利文市场研读沙利文市场研读11q报告基于评估结果为读者推荐入选本篇报告的十大厂商报告基于评估结果为读者推荐入选本篇报告的十大厂商本报告采用弗若斯特记分板模型对中国云原生数据库厂商进行全面评估。评估体系涵盖了六大维度：云原生及创新功能与技术、基础功能与技术、运维与管理、安全保障、服务与市场、生态建设。基于评估结果，沙利文筛选出中国云原生数据库厂商中的10家竞争主体。这一筛选过程不仅仅基于单一维度的表现，而是综合考虑各厂商六大维度的能力。从这几个维度的分析中，报告总结出了各个厂商在面向产品、面向用户、面向市场发展的三大核心能力，为读者产品调研与选型决策提供参考。本报告对竞争主体云原生数据库产品和服务综合竞争力的分析结论仅适用于该阶段云原生数据库市场发展情况。沙利文将持续关注云原生数据库市场，捕捉竞争动向。2023年中国云原生数据库市场综合竞争表现年中国云原生数据库市场综合竞争表现Frost Vendor ScoreCask(弗若斯特弗若斯特记分板)注：记分板按由下而上递增的逻辑对应由低至高的综合评分，最高分为5分,共分六个维度评价,形成总得分满分30分为最高分。-领导者-得分=5-卓越者-得分 4,5)-满足-得分 3,4)-中等-得分 2,3)-偏弱-得分 2安全保障服务与市场生态建设云原生及创新功能与技术基础功能与技术运维与管理LeaderProminentSatisfactoryModerateWeakq2023年中国云原生数据库解决方案市场综合竞争表现年中国云原生数据库解决方案市场综合竞争表现Frost Vendor ScoreCask(弗若斯特记分板弗若斯特记分板)本报告设立云原生及创新功能与技术、基础功能与技术、运维与管理、安全保障、服务与市场、生态建设六大维度对竞争主体表现分别进行评价。根据得分情况对竞争主体的各项能力进行梯队划分，并基于总得分展示竞争主体的综合能力章节四章节四竞争分析竞争分析400-072-5588沙利文市场研读沙利文市场研读122023 Frost Vendor ScoreCask for Tencent Cloud2023年中国云原生数据库市场综合竞争表现年中国云原生数据库市场综合竞争表现Frost Vendor ScoreCask(沙利文沙利文CASK)腾讯云腾讯云4.69安全保障4.81服务与市场4.81生态建设云原生及创新功能与技术4.8基础功能与技术4.9运维与管理4.95总得分28.96（满分30）腾讯云腾讯云Tencent Cloud面向产品的能力面向产品的能力：通过对云计算技术与数据库技术进行深度结合，腾讯云打造出TDSQL-C。该云原生数据库在资源弹性伸缩、资源性能优化、可观测性等能力上皆形成较强能力，如Serverless可设置最大资源限制，预留资源进行弹缩，提高弹性能力、自研组件完善冷启动性能。同时在可靠性、高可用性以及分布式技术等数据库能力方面具有较好表现。面向用户的能力面向用户的能力：腾讯云在AI4DB中具有较为深厚的技术积累，为用户提供全链路分析、智能运维、数据安全相关工具，提供优质的运维体验，减轻用户工作负担，提高问题处理效率及精准度。面向市场发展的能力：面向市场发展的能力：腾讯云在可持续发展的布局上，已具备较为完善的服务体系与实现较优的市场覆盖的广度与深度。在促进行业整体发展方面，腾讯云积极拥抱开源，并在市场教育（标准、专利）、人才培育等方面形成积极的影响力。评估综合评价腾讯云六项指标皆处于领先地位，综合分数排名第二关键关键发现发现TDSQL-C在Serverless能力上具有显著优势，其首创可释放存储架构可进一步极致压缩用户使用成本，同时在弹性稳定性、秒级冷启动上具有显著优势；其在AI for DB中具有较为深厚的技术积累，可为用户提供全链路分析、智能运维，减少用户工作负担来源：沙利文章节四章节四竞争分析竞争分析领导者卓越者满足中等偏弱400-072-5588沙利文市场研读沙利文市场研读13关键关键发现发现TDSQL-C在Serverless能力上具有显著优势，其首创可释放存储架构可进一步极致压缩用户使用成本，同时在弹性稳定性、秒级冷启动上具有显著优势；其在AI for DB中具有较为深厚的技术积累，可为用户提供全链路分析、智能运维，减少用户工作负担腾讯云腾讯云TDSQL-C Serverless 2.0 架构与架构与三大核心特性三大核心特性q持续推动端到端的数据战略持续推动端到端的数据战略，聚焦提升用户使用体验聚焦提升用户使用体验TDSQL-C融合了传统数据库、云计算与新硬件技术的优势，100%兼容MySQL，为用户提供极致弹性、高性能、高可用、高可靠、安全的数据库服务。实现超百万QPS的高吞吐、PB级海量分布式智能存储、Serverless秒级伸缩，助力企业加速完成数字化转型。其特点包括：超高性能与快速弹性扩展：拥有单节点百万QPS 的超高性能，可以满足高并发高性能的业务需求，保证关键业务的连续性，并支持秒级扩展，实现极致弹性。最高 PB 级海量储存：最高支持 PB 级的海量存储，为客户免去面对海量的数据时频繁分库分表的繁琐操作，同时支持数据压缩，在海量数据检索和写入性能上进行了大量优化。高可用性/高可靠性：基于数据多版本的秒级快照备份对用户的数据进行连续备份保护，免去主从架构备份回档数据的同步和搬迁，最高以 GB/秒的速度极速并行回档，保证业务数据迅速恢复。可靠性达99.9999999%。Serverless架构：业内首创可释放存储Serverless架构，自动扩缩容，仅按照实际使用量计费，不用不计费，轻松应对业务数据量动态变化和持续增长。来源：腾讯云，沙利文章节四章节四竞争分析竞争分析RW VPCRO VPCRWServerless/normalROServerlessROServerless共享分布式存储横向弹性纵向弹性归档存储Proxy(Serverless)纵向弹性极致稳定性保驾护航自适应负载快速弹性扩展集群版Serverless支持一主多从的集群架构、自动弹性扩缩容，不到1秒即可从数百个事务扩展到数十万个事务，快速应对业务峰值和变化场景。按实际业务压计费的超低成本集群版Serverless最高支持一主多从的集群架构、自动弹性扩缩容，不到1秒即可从数百个事务扩展到数十万个事务，快速应对业务峰值和变化场景。秒级冷启动，秒级弹性，预分配缓冲池等多项能力保证弹性过程中对业务无损，可保障业务核心系统持久平稳运行。TDSQL-C Serverless：企业级全链路Serverless数据库服务TDSQL-C Serverless 2.0 三大核心特性快照备份归档快速释放存储触发式回档,优先恢复命中page业内首创，可释放存储 集群无访问时段数据可落冷归档，启动时无需等待数据全量恢复，可瞬时恢复服务 归档存储价格同比分布式存储最高可降低80%Serverless混合集群版 一主多从集群版Serverless正式发布，支持横向、纵向多纬度弹性伸缩 Serverless只读节点可灵活绑定不同类型数据库主节点Proxy(Serverless)横向弹性VIPVIPROServerlessROServerlessRWServerless/normal共享存储HiStore垂直弹性垂直弹性垂直弹性横向弹性绝对平滑弹性扩缩 Buffer Pool resize优化，按地址遍历需要被回收的chunk 预 分 配 内 存、延 迟 释 放chunks、动态Resize Hash等弹性过程中无毛刺现象，整体稳定性提升1000-072-5588沙利文市场研读沙利文市场研读14方法论方法论u 头豹研究院布局中国市场，深入研究19大行业，持续跟踪532个垂直行业的市场变化，已沉淀超过100万行业研究价值数据元素，完成超过1万个独立的研究咨询项目。u 头豹研究院依托中国活跃的经济环境，研究内容覆盖整个行业发展周期，伴随着行业内企业的创立，发展，扩张，到企业上市及上市后的成熟期，头豹各行业研究员积极探索和评估行业中多变的产业模式，企业的商业模式和运营模式，以专业视野解读行业的沿革。u 头豹研究院融合传统与新型的研究方法论，采用自主研发算法，结合行业交叉大数据，通过多元化调研方法，挖掘定量数据背后根因，剖析定性内容背后的逻辑，客观真实地阐述行业现状，前瞻性地预测行业未来发展趋势，在研究院的每一份研究报告中，完整地呈现行业的过去，现在和未来。u 头豹研究院密切关注行业发展最新动向，报告内容及数据会随着行业发展、技术革新、竞争格局变化、政策法规颁布、市场调研深入，保持不断更新与优化。u 头豹研究院秉承匠心研究，砥砺前行的宗旨，以战略发展的视角分析行业，从执行落地的层面阐述观点，为每一位读者提供有深度有价值的研究报告。400-072-5588沙利文市场研读沙利文市场研读15法律声明法律声明u 本报告著作权归头豹所有，未经书面许可，任何机构或个人不得以任何形式翻版、复刻、发表或引用。若征得头豹同意进行引用、刊发的，需在允许的范围内使用，并注明出处为“头豹研究院”，且不得对本报告进行任何有悖原意的引用、删节或修改。u 本报告分析师具有专业研究能力，保证报告数据均来自合法合规渠道，观点产出及数据分析基于分析师对行业的客观理解，本报告不受任何第三方授意或影响。u 本报告所涉及的观点或信息仅供参考，不构成任何证券或基金投资建议。本报告仅在相关法律许可的情况下发放，并仅为提供信息而发放，概不构成任何广告或证券研究报告。在法律许可的情况下，头豹可能会为报告中提及的企业提供或争取提供投融资或咨询等相关服务。u 本报告的部分信息来源于公开资料，头豹对该等信息的准确性、完整性或可靠性不做任何保证。本报告所载的资料、意见及推测仅反映头豹于发布本报告当日的判断，过往报告中的描述不应作为日后的表现依据。在不同时期，头豹可发出与本报告所载资料、意见及推测不一致的报告或文章。头豹均不保证本报告所含信息保持在最新状态。同时，头豹对本报告所含信息可在不发出通知的情形下做出修改，读者应当自行关注相应的更新或修改。任何机构或个人应对其利用本报告的数据、分析、研究、部分或者全部内容所进行的一切活动负责并承担该等活动所导致的任何损失或伤害。弗若斯特沙利文咨询（中国）头豹研究院https:/ 主笔分析师霍翰松胡竣杰深度研究小组负责人李庆

0人已浏览 2023-12-28 16页 5星级

II 目 次 目 次.II 前 言.IV 1 范围.1 2 规范性引用文件.1 3 术语和定义、缩略语.1 3.1 术语和定义.1 3.2 略缩语.1 4 通信架构和要求.2 4.1 通讯架构.2 4.2 通讯安全要求.2 4.3 传输质量要求.2 5 地图.3 5.1 坐标系定义.3 5.2 地图切换.3 5.3 导航切换.4 6 任务及流程.4 6.1 云端控制平台基础.4 6.2 AGV 状态迁移流程.8 6.3 自主空间申请.10 7 消息格式要求.12 7.1 协议基础.12 7.2 通信通道建立.15 7.3 AGV 注册.16 7.4 AGV 基础参数查询.16 7.5 AGV 基础参数配置.17 7.6 AGV 运动控制.18 7.7 AGV 充电控制.21 7.8 AGV 导航切换.21 III 7.9 地图切换.22 7.10 设备自主调整空间申请.22 7.11 状态上报.24 7.12 AGV 运维数据上报.25 8 总结.27 附录A .28 执行机构状态.28 状态上报中的 AGV状态.30 运动参数类型.31 目标点属性.31 移动类型.32 顶升机构调整类型.32 大任务类型.32 轨迹类型.33 空间锁定类型.33 特殊区域值定义.33 AGV 类型.33 执行机构类型.33 执行机构控制参数.34 IV 前 言 当今社会正处在一个技术飞速发展、机器人与人工智能深入应用于工业领域的时代。在物流、制造和零售等领域，自动导引车（AGV）已经成为高效生产的关键工具，正在全球范围内迅速发展并得到广泛应用。2022年，我国AGV销量为93000台，同比增长29.2%；销售规模为185亿元，同比增长46.8%；海外销售规模为36亿，同比增长44%。AGV系统中的无人驾驶技术，不仅可以提高生产效率，减少人工操作失误的概率，还可以在复杂和危险的环境下保障操作人员的安全。然而，随着行业的高速发展，AGV在生产环境中的安全性与使用效率却显得日趋重要。适时地制定出一份行业标准协议，对于规范AGV行业、提升产品的安全性、保障使用者的权益、提升使用效率等方面具有十分重要的意义。尽管AGV技术被广泛应用，却缺乏统一的调度系统与AGV设备的通用协议。由于AGV的操作环境各异，使用场景广泛，乃至应用行业差异大，使得不同厂家，用户和行业针对AGV的使用标准各不相同。这种混乱的现状，无疑会给AGV技术的推广应用带来难题，无法在同个场地使用一套调度系统管理多个厂家AGV设备；当多个系统共同调度的情况下，AGV的交通管制、工作效率都受到极大的影响，甚至可能诱发安全事故。因此，制定一套全面、深入、适用各种环境和物流领域的调度系统与AGV的协议，对于统一系统与设备之间对接，提升AGV的效率、稳定性和安全性至关重要。统一的协议标准不仅明确AGV供应方的责任，同时也为AGV需求方提供保障。AGV行业标准协议，为相关厂商用户和行业提供一套统一、全面、实用高效的协议标准。本协议内容包括但不限于AGV注册、参数配置、运动控制、管理控制、状态上报等各个环节的行业级规范，并且充分考虑了云端控制系统与AGV通讯的效率和安全性。它以现有最优的质量和安全标准为基础，借鉴相关行业的先进经验，集结各方专家智慧，试图在统一规则的同时，充分考虑各类AGV的特殊需求和特性。一个统一、高效且安全的AGV标准协议，不仅关乎每一个使用者的生产效率和质量，更意味着每一位使用员工的健康和生命安全。相信在大家共同努力下，AGV技术可以更好地为生活和事业服务，同时保障工作效率和安全。本文件对于协议使用范围，使用基本要求，信令通信结构，具体的协议细节均做了详细的说明和阐述；对于AGV实际使用中的问题尽最大能力在协议层面解决，针对系统安全性专门提出协议加密方案，对于基本安全攻击也提出更明确的协议方案。本文件中有丰富的协议指令和详细的信令解析，针对业务应用场景也画出相关的业务流程图，可以让使用者更方便的上手使用。协议编写过程中不断重视并考虑AGV设备控制使用过程中出现的问题，力求把每一个细节都考虑周到，制定出公开、公平、公正的相关规定，既保障了生产者的权益，也保障了使用者的权益。本协议试图通过兼容性和灵活性，解决这些问题，同时设定出最优质和稳健的标准。任何一份标准协议都不可能完全无懈可击，技术的发展和人的需求是持续变化的，不能预见所有可能的问题和挑战。因此，我们将以谦虚的态度对待标准协议的完善，对于尚未发现或未能及时解决的问题，坦诚地承认并积极寻求改进。同时，也热诚欢迎各个行业的同仁，无论是生产者还是使用者，都能参与到标准协议的完善和修改中来，让这份协议更加完善。这份标准协议的实施将弘扬AGV与各行各业的合作精神，促进AGV技术的推广应用，推动AGV行业的进步发展。持续倡导技术的开放和分享，是推动科技进步的重要动力。同时，也对AGV行业的未来充满信心。随着行业标准的完善，AGV行业的团结性将得到根本改善，整个行业的健康发展也将成为可能。期待着AGV技术在全球各个角落发挥出它应有的作用，为世界带来改变。V 本文件按照GB/T 1.12020标准化工作导则 第1部分：标准化文件的结构和起草规则的规定起草。本文件可能涉及专利，本文件的发布机构不承担识别专利的责任。本文件主要定义了中央调度系统与AGV之间的通信协议。本文件由边缘计算产业联盟、中国物流采购联合会提出。本文件由边缘计算产业联盟、中国物流采购联合会归口。本文起草单位：华为技术有限公司、中国外运股份有限公司、顺丰科技技术有限公司、龙岩烟草工业有限责任公司、杭州海康机器人股份有限公司、杭州蓝芯科技有限公司、斯坦德机器人（深圳）有限公司、深圳市海柔创新科技有限公司、深圳市镭神智能系统有限公司、杭州迦智科技有限公司、北京灵动速度科技有限公司、广东嘉腾机器人自动化有限公司、上海仙工智能科技有限公司、浙江杭叉智能科技有限公司、浙江华睿科技股份有限公司、广东塔斯克机器人有限公司、浙江中力机械股份有限公司、凯乐士科技有限公司、神州数码信息服务股份有限公司、深圳稳石机器人有限公司、深圳市今天国际物流技术股份有限公司、浙江大学、上海交通大学、香港中文大学(深圳)、长安大学、中国科学院沈阳自动化研究所、中国信息通信研究院。本文件主要起草人：王诗荣、王厚金、王烽、朱可平、张恒、符鹏、林昱廷、查小平、廖建科、郭剑华、乔冰、张靖、周顺波、邹锋、谢骏、宋翔、李波、魏世奇、阮一凡、刘冬、苏汉武、曾锴、代晓君、郑超、刘胜平、王吉祥、雷祖芳、吴兴盛、李连杰、胡政、张腾宇、王瀚森、李翔、陈利峰、武俊华、白红星、郄胜强、李航、曾巍巍、李琳骁、朱炳炎、吴剑进、熊蓉、王挺、陈卫东、付樟华、高涛、明洋、王哲。本文文件历史版本发布情况如下：-2023年12月首次发布 1 云端控制平台与物流自动导引车通用接口指南 1 范围 本文件规定了物流自动导引车与云端控制平台的接口模型、客户端通信安全认证、通信协议结构，以及控制、传输流程接口的技术要求和检验规则。本文件适用于物流、仓储、制造业等领域的物流自动导引车实现云端控制的系统接口设计、开发、检验等。2 规范性引用文件 下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T 7408-2005 数据元和交换格式 信息交换 日期和时间表示法 GB/T 16977 机器人与机器人装备 坐标系和运动命名原则 GB/T 20720-2019 企业控制系统集成 GB/T 39466-2020 ERP、MES与控制系统之前软件互联互通接口 GB/T 32918 信息安全技术 SM2椭圆曲线公钥密码算法 第2部分：数字签名算法 第3部分：密钥交换协议 GB/T 32907 信息安全技术 SM4分组密码算法 3 术语和定义、缩略语 GB/T 30030-2023界定的以及下列术语和定义适用于本文件。3.1 术语和定义 3.1.1 云端控制平台 Cloud Control Platform 基于云厂商提供的计算基础设施及其上的AGV管理控制平台。3.1.2 切换地图 Change Map AGV运行在云端控制平台的不同地图时，实现不同地图的变更。3.1.3 切换导航 Change Navigation AGV在跨区域运行时，通过云端控制平台实现不同导航方式的变更，如SLAM切换成二维码导航。3.1.4 平台路径规划 Platform Path Planning AGV在运行区域内，由云端控制平台控制轨迹行驶的方法。3.1.5 自主路径规划 Autonomous Path Planning AGV在运行区域内，对于临时性避障，由AGV自主规划且平台授权的轨迹行驶方法。3.2 略缩语 下列缩略语适用于本文件。SSL 安全套接层协议(Secure Sockets Layer)TLS 传输层安全协议(Transport Layer Security)API 应用程序接口(Application Programming Interface)2 HTTP 超文本传输协议(Hyper Text Transfer Protocol)IP 互联网协议地址(Internet Protocol Address)UDP 传输控制协议(User Datagram Protocol)TCP 传输控制协议(Transmission Control Protocol)TLS 传输层安全协议(Transport Layer Security)定位地图：AGV本体用来在环境中定位的地图，如二维码和SLAM地图 逻辑地图：云端控制平台用来规划机器人路径并处理业务逻辑的地图 4 通信架构和要求 4.1 通讯架构 云端控制平台与AGV的通讯架构如图1 所示，其中云端控制平台可以根据需求部署在中心云或边缘云。AGV与云端控制平台通过UDP/TCP socket来实现边端或云端通讯。因此，网络层应支持IP协议，传输层应支持TCP和UDP协议。云端控制平台与 AGV 通讯架构图 4.2 通讯安全要求 云端平台与AGV之间的通信需要满足以下安全需求：1)认证性：为了防止敌手冒充云端平台或AGV发送错误指令，云端平台和AGV进行交互时首先需要对双方的身份进行认证确保真实性。2)机密性：AGV和云端控制平台通过公开信道通信，然而位于公开信道上的窃听者可能会获得通信中的机密信息，因此应保证传输数据的机密性。3)完整性：由于公开信道的敌手可以对云端控制平台发送的指令请求发动篡改或伪造攻击，因此应保证传输数据的完整性。4)抵抗重放攻击：由于敌手可能会窃取到传输的数据，因此需要考虑验证数据的即时性以抵抗重放攻击。4.2.1 传输带宽要求 1)单台AGV运行时需要的带宽不小于125Kbps；2)单台AGV维护时需要的带宽不小于500Kbps；4.3 传输质量要求 1）网络时延不大于200ms；2）时延抖动不大于100ms；3）丢包率不大于110-3；4）包误差率不大于110-4；5)无线漫游切换时间不大于200ms；3 5 地图 5.1 坐标系定义 为了能够对AGV进行统一的管理，需要规定地图坐标系及AGV在地图上的坐标表示。如图2 所示，世界坐标系和AGV坐标系为右手坐标系，其中世界坐标系原点位于地图左下角。x y z的单位为毫米，AGV的朝向单位为度，且位于(180,180。当AGV头部朝向世界坐标系的x轴正方向时，车体角度为0；当AGV头部朝向世界坐标系的y轴正方向时，车体角度为90；当AGV头部朝向世界坐标系的x轴负方向时，车体角度为180；当AGV头部朝向世界坐标系的y轴负方向时，车体角度为90。位姿定义 5.2 地图切换 在实际业务中，经常有AGV跨楼或跨楼栋的搬运场景。在不同的区域中，AGV本体的定位地图和云端控制平台的逻辑地图会发生变化。因此，AGV在跨区域运动时，需要切换相关的地图。图3 定义了一种地图切换的流程，适用于AGV在SLAM/二维码导航方式之间切换。由于AGV在切换点执行地图切换时，本身并未运动，但是AGV的定位地图和关联的逻辑地图已经发生了变化。在切换点时，AGV需要能够同时获得在新旧地图上的位姿，所以切换点需要放置二维码或其他标记物进行辅助定位。切换地图流程 地图切换流程如上图所示，具体描述如下：4 1)控制平台下发切换地图请求；2)AGV 在收到地图切换请求后，首先回复收到切换请求；3)AGV 开始执行地图切换；4)AGV 地图切换完成且定位成功后，向云端控制平台上报地图切换成功请求；5)控制平台收到请求后，首先回复该请求，然后将 AGV 在新地图生效；6)AGV 开始在新地图作业；其中具体报文格式定义参考第7.9 节地图切换。5.3 导航切换 同一场地中，可能存在不同导航方式的区域，如SLAM和二维码导航。因此，当AGV跨区域运行时，需要进行导航方式切换，如SLAM导航切换到二维码导航。AGV在导航切换点时，依靠周围环境进行精确定位，因此切换点需要设置在定位环境较好的位置。导航切换 导航切换流程如上图所示，具体描述如下：1)云端控制平台下发移动任务经过导航切换点；2)当 AGV 即将到达导航切换点时，平台下发慢速移动任务，并下发导航切换请求；3)在 SLAM 切换二维码导航的场景中，当 AGV 下视镜头看到二维码时，开始通过二维码对自身位置进行标定；4)在二维码切换 SLAM 导航的场景中，当 AGV 收到导航切换请求后，开始用 SLAM 进行定位；其中具体报文格式定义参考第 7.8 节导航切换。6 任务及流程 6.1 云端控制平台基础 6.1.1 任务的生成和路径的生成 在云端控制平台中，保存了一份的由拓扑点和拓扑边组成的逻辑地图，定义了AGV的工作环境，如道路是否可通行、载具下是否可穿行、是否可旋转等约束信息。AGV的任务信息中通常包含起点、终点以及载具/容器等信息，云端控制平台会根据任务的起点、终点、AGV所需刚体空间和逻辑地图中的约束信息生成一条AGV需要行走的轨迹。图5 描述了一个典型的AGV逻辑地图。其中起点为P1，终点为P11，云端控制平台生成的AGV全局路径为P1-E1-P2-E2-P3-E3-P4-E4-P5-E7-P8-E11。同时云端控制平台也会根据任务的信息以及AGV的类型生成对应的控制动作。以潜伏AGV为例，在搬运载具过程中生成的任务为：1)移动到P1点；2)在P1点举升载具；3)AGV背负载具沿着路径P1-E1-P2-E2-P3-E3-P4-E4-P5-E7-P8-E12-P11运动；5 4)在P11点放下载具；逻辑地图和全局路径信息 6.1.2 路径信息基础 直线路径更新示意图 为了能够实现多个 AGV 的交通管制，运动控制报文需要包含 AGV 当前的目标点。在 AGV 移动的过程中，目标点不断更新，直至到达最终的目标点。在无避让且路网状态良好情况下，AGV 将沿着预规划的全局路径运动到终点。上图展示了 AGV 在直线路径上的目标点更新流程。1)在 T=k 时刻，任务生成；2)在 T=k 1 时刻，规划目标点到（10000，26000）；3)在 T=k 2 时刻，AGV 移动到（10000,28000），此时规划目标点到（10000，24000）；4)在 T=k 3 时刻，AGV 移动到(10000,26000)，此时规划目标点到（10000，22000）；5)在 T=k 4 时刻，AGV 移动到（10000，22000），此时规划目标点到（10000，20000）；6 因此，AGV 开始运动后，在无避让的情况下，目标点也随着 AGV 移动而均匀的向前移动。曲线路径更新示意图 上图展示了 AGV 在曲线路径上的目标点更新流程。当 AGV 即将进入曲线时，云端控制平台将更新多段路径到 AGV 控制报文中，目标点将会更新到曲线的终点。进入曲线后，目标点将会更新为曲线终点后方位置。曲线路径更新示例如下：1)2)在 T=k 时刻，AGV 在点位（100000，22000），此时将更新多段路径到 AGV。路径段 1 为直线，起点为当前位置，终点为（10000，20000）。路径段 2 为曲线，起点为（10000，20000），终点为（20000，10000），曲线的信息包含在控制点中。AGV 的当前目标点为曲线终点（20000，10000）；在 T=k 1 时刻，AGV 进入曲线，此时将更新 AGV 目标点为曲线后方位置，如（25000，10000）。此时路径段 1 为曲线，起点为（10000，20000），终点为（20000，10000），曲线的信息包含在控制点中。路径段 2 为直线起点（20000，10000），终点为（25000，10000）；旋转路径更新示意图 7 上图展示了 AGV 在旋转路径上的目标点更新流程。在 AGV 即将到达旋转点时，目标点将不再更新，此时只会更新 AGV 的旋转动作。旋转路径更新示例如下：1)在 T=k 时刻，AGV 在点位（36000,10000），此时更新 AGV 目标点为旋转点(40000,10000)；2)在 T=k 1 时刻,AGV 在点位（37000,10000），此时 AGV 的目标点仍然为旋转点（40000，10000），即目标点不更新；3)在 T=k 2 时刻，AGV 在点位（39000,10000），此时追加旋转90到 AGV；4)在 T=k 3 时刻，AGV 在旋转点（40000,10000）且已经完成转向，此时更新 AGV 目标点到（40000，14000），随后沿着直线继续运动；终点路径更新示意图 上图展示了 AGV 在即将到达终点时的目标点更新流程。在无避让情况下，目标点将不再更新。终点路径更新示例如下：1)在 T=k 时刻，AGV 在点位（40000，26000）此时 AGV 目标点更新到终点（40000，30000）；2)在 T=k 1 时刻，AGV 在点位（40000，27000），此时 AGV 目标点仍为终点（40000，30000）；6.1.3 路径重规划流程 路网状态变换重规划示意图 在逻辑地图状态更新时，如预规划路径上出现故障 AGV 或预规划路径指定区域被封锁，如果AGV 存在其他路径可以到达终点，云端控制平台将会更新全局路径。以上图为例，路径更新流程描述如下：1)在 T=k 时刻，AGV 在点位（23000，10000），AGV 仍然沿着预规划路径运动；2)在 T=k 1 时刻，AGV 在点位（25000，10000），此时在点位（33000，10000）出现故障 AGV。该情形将触发重规划，AGV 全局路径将会由红色路径更新为亮蓝色路径。控制报文的目标点也会相应变化；8 6.2 AGV 状态迁移流程 6.2.1 AGV 状态定义 AGV的状态定义图表1 所示。图11 描述了AGV在不同状态之间的切换流程。表1 AGV 状态定义 AGV状态状态 状态定义状态定义 空闲 AGV当前没有收到新任务或没有任务，上报【空闲】完成 AGV运动和充电任务执行结束后，上报【完成】运动中 AGV开始执行移动或机构动作，上报【运动中】，运动失败 用于表示AGV移动或机构动作执行失败 充电中 AGV在充电桩对接结束后，上报【充电中】充电失败 AGV执行充电动作过程中出现异常，上报【充电失败】暂停 AGV在【运动中】、【充电中】、【空闲】时，由于人工点击暂停，AGV进入【暂停】状态 AGV 状态迁移图 6.2.2 任务流程举例 表2 潜伏 AGV 搬运货架任务流程举例 动作动作 状态上报状态上报 空车移动 1)AGV 没有收到任务时，上报【完成】或【空闲】2)AGV 开始移动后，上报【运动中】3)AGV 运动到举升点后，上报【完成】。连续 3s 没有收到新任务，上报【空闲】举升动作 1)AGV 没有收到任务时，上报【完成】或者【空闲】2)AGV 收到举升动作后，上报【运动中】载货移动任务 1)AGV 没有收到任务时，上报【完成】或者【空闲】2)AGV 收到载货任务后，上报【运动中】3)AGV 载货移动到目标点后，上报【完成】。连续 3s 未收到新任务，上报【空闲】下放动作 1)AGV 没有收到任务时，上报【完成】或者【空闲】2)AGV 收到下放动作后，上报【运动中】3)AGV 下放完成后，上报【完成】9 6.2.3 任务更新 下图描述了AGV的任务更新流程，其中 1)节点【是否为新任务】需要根据当前执行的任务和收到的报文进行比较；2)节点【是否需要更新】需要根据 AGV 当前的执行参数和任务类型来判断；3)节点【AGV 能否执行该任务】需要判断当前 AGV 载货状态和收到的指令是否一致，如载货收到了空车指令，空车状态收到了载货指令等；任务更新流程 6.2.4 任务取消 任务取消 10 如果AGV收到了取消指令，需要根据当前执行状态或动作来判断动作能否取消。如果可以取消，则进入清理任务状态流程，如果动作无法取消，则需先等待当前动作执行结束。6.3 自主空间申请 在特殊场景中，AGV需要自主运动以完成搬运任务。然而，AGV在规划自主路径时，一般不会考虑是否与其他AGV碰撞。因此，AGV在执行自主运动之前，需要向云端控制平台申请安全空间，随后再进行自主运动。典型场景举例如下：1)在举升货架场景中，AGV需要调整位姿或执行机构以搬运货物，此时AGV的刚体空间会出现变化。如果相邻位置有作业的AGV，则可能出现干涉。为避免干涉导致AGV碰撞，需要AGV向云端控制平台申请安全运动空间，随后再进行自主运动；2)在栈板识别叉取任务中，AGV需要自主完成相关动作。该过程的路径由AGV自主规划。为避免由于AGV自主动作与其他AGV出现干涉或者碰撞等问题，需要AGV封锁路径；3)在搬运过程中，当AGV遇障时，可能会导致AGV长时间停留在障碍物前，为保证现场运行效率，AGV可以自主绕障。然而，在运动开始之前，仍然需要向云端控制平台申请安全空间；6.3.1 自主调整空间申请 自主调整空间申请流程 在相邻 AGV 同时作业时，如果某个 AGV 需要进行自主动作，上图提供了一种空间封锁方案，避免 AGV 在执行非云端控制平台规划的路径时和其他 AGV 产生干涉。流程描述如下：1)云端控制平台下发机构执行动作指令；2)由于机构动作过程中，AGV 会自主旋转或者刚体形态发生形变，AGV 开始申请安全空间；3)安全空间申请失败时将会重新申请；4)空间封锁成功时，AGV 开始执行动作并上报运动中。动作完成之后，上报完成，随后释放锁定的安全空间；相邻货位干涉 11 如上图所示，AGV1和AGV2为潜伏AGV，在相邻货位执行举升货架动作。由于AGV2识别货架货码时需要进行旋转，而AGV1此时也在旋转。为了避免AGV1和AGV2同时旋转导致碰撞，需要AGV2在旋转前进行空间申请。6.3.2 路径封锁 路径封锁请求流程 AGV 在识别标记物时需要自主规划路径以完成对接。此时的路径非云端控制平台规划产生，为避免和其他作业 AGV 发生干涉，上图提供了路径封锁的请求流程，描述如下：1)云端控制平台下发对接动作；2)由于 AGV 需要进行自主路径规划，开始申请路径封锁；3)如果路径封锁失败，则需要 AGV 重新申请；4)如果路径封锁成功，则 AGV 开始移动。当移动完成时，上报【完成】并释放锁定的空间；栈板识别叉取 如上图所示，AGV1和AGV2需要先后执行栈板叉取任务。由于现场环境恶劣，需要叉取的栈板均出现偏角。AGV1收到栈板叉取任务后，检测到栈板出现偏角，AGV1需要自主调整自身位姿与栈板对齐。在对齐过程中，AGV1的路径非云端控制平台规划结果，因此AGV1需要申请路径封锁。假设AGV2也收到了栈板叉取任务，由于AGV1已经封锁了路径，AGV2申请路径将失败。12 6.3.3 自主绕障申请 自主绕障申请 在AGV遇障之后，需要自主绕开障碍物继续执行任务，此时AGV需要将自主规划出来的路径上报到云端控制平台。如果云端控制平台判断路径安全，则AGV开始执行绕障。如果云端控制平台判断不可执行，则AGV继续上报遇障。自主绕障 如上图所示，AGV在执行移动任务中，由于前方出现障碍物导致遇障，此时AGV判断障碍物可绕过，AGV向云端控制平台申请路径，在申请通过后，执行绕障。7 消息格式要求 7.1 协议基础 7.1.1 通信交互机制 云端控制平台与AGV之间通过上下行报文进行交互，且每一条报文都有其对应的回复确认报文，用于告知对端已经接收到该报文。如果一端发送了消息，超过一定时间未收到对端的响应，则应重新发送该消息。消息在发送之后有一定的存活周期，发送端仅在该存活周期内进行重发，超过存活周期则应释放该消息，不再继续发送。存活周期和超时间隔等参数可通过第7.5 节报文进行设置。针对7.6 节的任务控制报文，AGV在没有上报任务完成前，云端控制平台将间隔性的下发相同的任务控制报文。AGV需要响应云端控制平台最新的控制报文。双方通过实时交换的状态包和回复包作为彼此的心跳包。云控制平台和AGV之间的报文交互，使用网络字节序也即大端模式。13 7.1.2 交互流程概述 云端控制平台与AGV交互流程如图20 所示。整体流程分成以下几步：1)AGV在初始化完成后，向云端控制平台发起接入申请，可选普通模式接入和安全模式接入。在普通模式中，后续报文将直接发送至对端。在安全模式中，AGV与云端控制平台将协商会话密钥，且后续报文以密文的形式发送；2)AGV向云端控制平台发起注册请求。注册成功后，将会周期性的上报自身状态；3)云端控制平台配置AGV的全局信息，如状态上报周期、告警参数等；4)AGV周期性地向云端控制平台上报自身状态，并与云端控制平台保持心跳；5)云端控制平台根据上层业务系统输入，下发每个AGV的控制报文，驱动AGV运动；6)AGV可以根据需求向云端控制平台申请安全空间，以完成自主运动，如动态绕障；云端控制平台与 AGV 报文交互示意图 7.1.3 基础报文格式 如图21 所示，云端控制平台与AGV交互的报文由消息头和消息体构成。其中消息头长度为32字节，具体内容如表3 所示。消息体的长度根据传输内容变化，具体细节将在后续章节解释。云端控制平台与 AGV 交互报文结构 14 表3 报文消息头 消息头字段消息头字段 长度长度(字节字节)类型类型 含义含义 消息标识 4 uint8_t 固定消息标识，默认“GBP$”消息长度 2 int16_t 包括消息头和消息体，且结构体4字节对齐 消息类型 2 int16_t 交互报文的信号令，不同场景的消息类型见表4 消息序号 4 uint32_t 云端控制平台和AGV分别维护自身主动发起的报文序列号,若是对端消息的回复确认包，此报文的消息序号维持对端消息中的消息序号不变 消息版本号 1 uint8_t 描述当前通信协议的版本号 设备接入模式 1 uint8_t 0 x0：普通模式；0 x1：安全模式 保留字节 18-字节对齐及预留为后续功能扩展 表4 报文消息头中的消息类型 类型类型 含义含义（发起端）（发起端）类型类型 含义含义（对端）（对端）0 x1 AGV注册报文 0 x2 AGV注册回复报文 0 x100 AGV状态上报参数配置报文 0 x101 AGV状态上报参数回复报文 0 x102 AGV全局精度参数配置报文 0 x103 AGV全局精度参数配置回复报文 0 x104 AGV告警参数配置报文 0 x105 AGV告警参数配置回复报文 0 x108 AGV运动参数配置报文 0 x109 AGV运动参数配置回复报文 0 x200 AGV基础参数查询报文 0 x201 AGV基础参数查询回复报文 0 x202 AGV上报基础参数报文 0 x203 AGV上报基础参数回复报文 0 x300 AGV状态上报报文 0 x301 AGV状态上报回复报文 0 x324 AGV运动控制报文 0 x325 AGV运动控制回复报文 0 x328 AGV取货控制报文 0 x329 AGV取货控制回复报文 0 x32A AGV放货控制报文 0 x32B AGV放货控制回复报文 0 x32C AGV充电控制报文 0 x32D AGV充电控制回复报文 0 x31E 导航切换请求报文 0 x31F 导航切换请求回复报文 0 x318 地图切换请求报文 0 x319 地图切换请求回复报文 0 x31A 地图切换成功报文 0 x31B 地图切换成功回复报文 0 x800 锁格申请报文 0 x801 锁格申请回复报文 0 x802 锁格释放请求报文 0 x803 锁格释放请求回复报文 0 x80A 路径封锁申请报文 0 x80B 路径封锁申请回复报文 0 x80C 路径解锁申请报文 0 x80D 路径解锁申请回复报文 0 x5001 AGV故障上报报文 0 x5002 AGV故障上报回复报文 0 x5003 AGV里程上报报文 0 x5004 AGV里程上报回复报文 15 7.2 通信通道建立 7.2.1 建立通信通道 考虑到扩展性和兼容性，协议提供普通模式接入和安全模式接入。普通模式即无加密模式，见图22。安全模式见图 23，其中 AGV 与云端控制平台通过 SM2 密钥交换协议协商会话密钥，然后使用该密钥对传输的报文进行 SM4 分组密码算法进行加密后，利用 SM2 数字签名算法生成签名，再对密文和签名进行传输，从而保证整个通信过程的安全。普通模式进行协议交互 安全模式进行协议交互 16 从图 23 可以看出整个过程分两个阶段，第一阶段进行密钥交换，第二阶段使用协商的会话密钥对传输数据进行加密并传输。具体步骤如下：1)设备发起接入申请，确认接入模式，可以选择普通模式(图 22)和安全模式(图 23)。设备端生成公私钥对，将公钥发送给平台端；平台端确认收到后将自己的的公钥也发送给设备端；2)会话密钥协商:设备端使用自身私钥和随机数，平台端的公钥和随机数承诺，通过 SM2 密钥交换协议生成 Key1。通过密钥导出函数，基于本地先验口令密码，Key1 和盐值生成最终密钥 KEY。平台端也用类似的过程生成平台端的 KEY；3)设备端通过 SM4 分组密码算法，使用协商得到的密钥 KEY 对报文加密得到密文，并使用 SM2 数字签名算法生成对应签名，将密文和签名同时发送给平台端；4)平台端收到密文和签名后，先对签名进行校验，如果校验成功，平台端将对密文使用密钥 KEY 进行解密得到数据。否则，平台端将直接丢弃该消息，并将消息异常次数记录入日志；7.3 AGV 注册 在通信通道建立之后，AGV向云端控制平台发起注册。当没有收到回复报文且超时后，将再次发起注册，直至接收到云端控制平台的注册回复报文。AGV注册完成后，开始以一定周期向云端控制平台上报状态报文，报文消息体如表5 所示。表5 AGV 注册报文消息体(AGV-云端控制平台)消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 AGV编号 4 uint32_t AGV在地图中的唯一标识符 AGV厂商 4 uint32_t AGV的生产厂商，便于云端控制平台进行区分 AGV序列号 48 uint8_t AGV的出厂序列号 AGV类型 1 uint8_t 用于区分AGV的类型，类型见附录 A.11 AGV状态 1 uint8_t 注册时AGV的状态，见附录A.2 AGV长度 2 uint16_t AGV的外轮廓长度(mm)AGV宽度 2 uint16_t AGV的外轮廓宽度(mm)AGV高度 2 uint16_t AGV的外轮廓高度(mm)AGV旋转直径 2 uint16_t AGV的最小安全旋转直径(mm)AGV重量 2 uint16_t AGV的出厂重量(kg)根据7.1 节所述的通信交互机制，对端在收到一条报文后都需要发送一条回复确认报文，以告知发送方消息已经收到。云端控制平台在收到AGV发送的注册请求报文后，将对其进行回复，并反馈是否注册成功，报文消息体如所示。表6 AGV 注册回复报文消息体(云端控制平台-AGV)消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 AGV编号 4 uint32_t AGV在地图中的唯一标识符 回复结果 4 uint32_t 消息回复结果，200表示成功，201表示失败 异常码 1 uint8_t 暂未启用 地码类型 2 uint8_t 地码上字符串上的字母 保留字节 1-字节对齐及预留为后续功能扩展 7.4 AGV 基础参数查询 云端控制平台向AGV发送基础参数查询报文。AGV在收到请求后，首先发送给平台一个简短的回复报文，随后会将AGV的基础参数发送给对方，最后云端控制平台会向AGV发送回复报文。7.4.1 云端控制平台查询 AGV 基础参数消息体 表7 AGV 基础参数查询报文消息体(云端控制平台-AGV)消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 AGV编号 4 uint32_t AGV在地图中的唯一标识符 17 表8 AGV 基础参数查询回复报文消息体(AGV-云端控制平台)消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 AGV编号 4 uint32_t AGV在地图中的唯一标识符 回复结果 4 uint32_t 消息回复结果，200表示成功，201表示失败 7.4.2 AGV 上报云端控制平台基础参数消息体 表9 AGV 上报基础参数报文消息体(AGV-云端控制平台)消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 AGV编号 4 uint32_t AGV在地图中的唯一标识符 负载能力 2 uint16_t AGV的额定负载(kg)续航能力 1 uint8_t AGV的额定续航时间(h)是否支持称重 1 uint8_t 是否带称重传感器 精度 空载精度 1 uint8_t 空载时，AGV的控制精度(mm)载货精度 1 uint8_t 载货时，AGV的控制精度(mm)保留字节 2-字节对齐及预留为后续功能扩展 空车运行性能 36 struct 空载时，AGV的运动性能，见表10 载货运动性能 36 struct 载货时，AGV的运动性能，见表10 表10 AGV 运动性能结构体 消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 最大直线加速度 4 uint32_t AGV的最大加速度(mm/s2)最大直线减速度 4 uint32_t AGV的最大减速度(mm/s2)最大线速度 4 uint32_t AGV的最大直线速度(mm/s)最大角加速度 4 uint32_t AGV的最大角加速度(1/1000deg/s2)最大角减速度 4 uint32_t AGV的最大角减速度(1/1000deg/s2)最大角速度 4 uint32_t AGV的最大角速度(1/1000deg/s)最大曲线加速度 4 uint32_t AGV的最大曲线加速度(mm/s2)最大曲线减速度 4 uint32_t AGV的最大曲线减速度(mm/s2)最大曲线速度 4 uint32_t AGV的最大曲线速度(mm/s)回复报文：同表 8。7.5 AGV 基础参数配置 基础参数可配置，即云端控制平台可选择性的配置某些参数。如果不配置，则AGV使用默认参数。7.5.1 云端控制平台配置 AGV 状态上报参数消息体 AGV 在满足以下任意一种条件时，需要上报自身状态：1)超过指定的上报周期；2)超过指定的距离；3)超过指定的角度；表11 AGV 状态上报参数配置报文消息体(云端控制平台-AGV)消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 AGV编号 4 uint32_t AGV在地图中的唯一标识符 上报周期 4 uint32_t 状态上报周期(ms)最大距离 4 uint32_t AGV移动超过该距离上报状态(mm)最大角度 4 uint32_t AGV旋转超过该角度上报状态(1/1000 deg)18 回复报文：同表 8。7.5.2 云端控制平台配置 AGV 告警参数消息体 表12 AGV 告警参数配置报文消息体(云端控制平台-AGV)消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 AGV编号 4 uint32_t AGV在地图中的唯一标识符 告警服务器IP IPV4 4 uint32_t 告警服务器的IPV4地址 IPV6 16 uint8_t 告警服务器的IPV6地址，当前保留 告警服务器端口 2 uint16_t 告警服务器的端口 保留字节 2-字节对齐及预留为后续功能扩展 回复报文:同表 8。7.5.3 云端控制平台配置 AGV 全局精度参数消息体 表13 AGV 全局精度参数配置报文消息体(云端控制平台-AGV)消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 AGV编号 4 uint32_t AGV在地图中的唯一标识符 空载移动精度 1 uint8_t AGV空载运行时，要求的移动精度(mm)负载移动精度 1 uint8_t AGV载货运行时，要求的移动精度(mm)保留字节 2-字节对齐及预留为后续功能扩展 回复报文:同表 8。7.5.4 云端控制平台配置 AGV 运动参数消息体 表14 AGV 运动参数配置报文消息体(云端控制平台-AGV)消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 AGV编号 4 uint32_t AGV在地图中的唯一标识符 参数类型 1 uint8_t 运动参数用于什么场景，见附录A.3 保留字节 3-字节对齐及预留为后续功能扩展 运动参数 36 struct 见表10 回复报文:同表 8。7.6 AGV 运动控制 用于云端控制平台控制 AGV 由当前点沿着直线、贝塞尔或 B 样条曲线的应用。表15 AGV 运动控制报文消息体(云端控制平台-AGV)消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 AGV编号 4 uint32_t AGV在地图中的唯一标识符 任务信息 24 struct 云端控制平台分配任务信息，见表16 目标信息 52 struct AGV的当前目标信息，见表17 最终目标 8 struct AGV 的最终目标信息，见表 18 避障参数 72 struct AGV的避障参数信息，见表19 路径信息 484 struct 云端控制平台给AGV下发路径的详细信息，见表21 执行机构信息-struct AGV上执行机构的信息，见表24 19 表16 任务信息结构体 字段名字段名 长度长度(字节字节)类型类型 含义含义 任务ID 2 uint16_t 云端控制平台分配任务的ID 任务子ID 1 uint8_t 云端控制平台分配任务的子ID 移动类型 1 uint8_t 移动类型，见附录A.3 大任务类型 2 uint16_t 此次任务所属的大任务的类型，见附录A.7 移动与执行机构是否同步执行 1 uint8_t 0：不同步，执行机构动作在移动之前；1：同步，即可以在移动过程中，同时进行执行机构的动作；保留字节 17-字节对齐及预留为后续功能扩展 表17 目标信息结构体 字段名字段名 长度长度(字节字节)类型类型 含义含义 x坐标 4 int32_t 目标点的x轴方向的坐标(mm)y坐标 4 int32_t 目标点的y轴方向的坐标(mm)方向 4 int32_t 目标点方向(1/1000 deg)节点类型 1 int16_t 该目标点的类型，见附录A.4 保留字节 1-字节对齐及预留为后续功能扩展 距离精度 2 uint16_t 该目标点的距离精度的要求(mm)小车角度精度 4 int32_t 该目标点的小车角度精度要求(1/1000 deg)保留字节 4-字节对齐及预留为后续功能扩展 最大速度 4 int32_t 此任务移动过程中的最大速度限制(mm/s)全向车移动方向 4 int32_t 针对全向车型，表示到目标点的移动方向(1/1000 deg)保留字节 16-字节对齐及预留为后续功能扩展 表18 最终目标结构体 字段名字段名 长度长度(字节字节)类型类型 含义含义 目标角度 4 int32_t 最终目标点角度(1/1000deg),取值范围(-180,180 x坐标 4 int32_t 最终目标点信息，x轴方向的坐标(mm)y坐标 4 int32_t 最终目标点信息，y轴方向的坐标(mm)表19 避障参数结构体 字段名字段名 长度长度(字节字节)类型类型 含义含义 距离阈值 2 uint16_t 值为 0 时，由 AGV 自行切换避障方案 值不为 0 时，使用平台配置的避障距离 特殊区域类型 1 uint8_t 特殊区域类型，具体值见附录A.10 避障控制类型 1 uint8_t 安全功能索引参数，当为0时，使用云端控制平台下发的距离参数控制避障；当为1时，使用激光轮廓模板进行避障，在部分AGV无法判断轮廓模板时，使用平台下发的激光轮廓模板类型值 安全控制参数 56 struct 表示AGV前、后、左、右四周的安全距离，每个方向的距离占用两个字节，单位mm。AGV距目标点的距离小于距离阈值时，根据安全距离与AGV配置的各个避障方案的近区距离做比较，最终取差值最小的避障方案，见表20 保留字节 12-字节对齐及预留为后续功能扩展 表20 安全控制参数结构体 字段名字段名 长度长度(字节字节)类型类型 含义含义 20 四周 停止距离 前 2 uint16_t AGV前方停止距离(mm)后 2 uint16_t AGV后方停止距离(mm)左 2 uint16_t AGV左方停止距离(mm)右 2 uint16_t AGV右方停止距离(mm)四周 一级减 速区 前 2 uint16_t AGV前方一级减速距离(mm)后 2 uint16_t AGV后方一级减速距离(mm)左 2 uint16_t AGV左方一级减速距离(mm)右 2 uint16_t AGV右方一级减速距离(mm)目标速度 4 uint32_t AGV在一级减速区的速度(mm/s)目标减速度 4 uint32_t AGV进入一级减速度区的减速度(mm/s2)保留字节 8-字节对齐及预留为后续功能扩展 四周 二级减 速区 前 2 uint16_t AGV前方二级减速距离(mm)后 2 uint16_t AGV后方二级减速距离(mm)左 2 uint16_t AGV左方二级减速距离(mm)右 2 uint16_t AGV右方二级减速距离(mm)目标速度 4 uint32_t AGV在二级减速区的速度(mm/s)目标减速度 4 uint32_t AGV进入二级减速度区的减速度(mm/s2)保留字节 8-字节对齐及预留为后续功能扩展 表21 路径信息结构体 字段名字段名 长度长度(字节字节)类型类型 含义含义 路径段数量 1 uint8_t 指令中下发的路径段数量。支持最大路径段数量为5 保留字节 1-字节对齐及预留为后续功能扩展 路径信息长度 2 uint16_t 包含路径段的所有字节长度，按照实际情况填写路径段个数和每个路径段的控制点。路径段0n-struct 路径段中数据，其中单个路径段数据见表22 表22 路径段结构体 字段名字段名 长度长度(字节字节)类型类型 含义含义 最大速度 2 uint16_t AGV运行于该路径段时最大速度(mm/s)目标路径比例 2 uint16_t AGV目标点在占该路径段的千分比，取值范围 0 1000。轨迹类型 1 uint8_t 当前路径段轨迹类型，详细定义见附录A.8 控制点数量 1 uint8_t 该路径段控制点数量，取值范围210 保持车身姿态 1 uint8_t 全向车移动时使用，用于判断是否是侧移 保留字节 9-字节对齐及预留为后续功能扩展 控制点-struct 路径段中包含最多10个控制点，单个控制点见表23 表23 控制点结构体 字段名字段名 长度长度(字节字节)类型类型 含义含义 x坐标 4 int32_t x轴方向的坐标(mm)y坐标 4 int32_t y轴方向的坐标(mm)表24 执行机构参数结构体 字段名字段名 长度长度(字节字节)类型类型 含义含义 执行机构类型 2 int16_t 执行机构类型，定义见附录A.12 保留字节 2-字节对齐及预留为后续功能扩展 执行机构参数定义-union 执行机构动作参数，定义见附录A.13 回复报文：见同表 8。21 7.7 AGV 充电控制 表25 AGV 充电控制报文消息体(云端控制平台-AGV)消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 设备编号 4 uint32_t AGV 在地图中的唯一标识符 任务信息 24 struct 云端控制平台分配任务信息，见表 16 目标信息 52 struct AGV 的当前目标信息，见表 17 最终目标 8 struct AGV 的最终目标信息，见表 18 避障参数 72 struct AGV 的避障参数信息，见表 19 路径信息 484 struct 云端控制平台给 AGV 下发路径的详细信息，见表 21 控制类型 2 uint16_t 1：开始充电 2：停止充电 3：定时重启,4:充电到目标水平 时间 2 uint16_t 控制类型为 1 时，表示充电时长(min)控制类型为 3 时，表示定时重启时间 充电桩 ID 2 uint16_t 若开启平台管理充电桩功能，此字段为充电桩 ID 目标充电比 1 uint8_t 当控制类型为 4 时，该值生效，值范围为0,100 保留字节 1-字节对齐及预留为后续功能扩展 充电桩 IP 4 uint32_t 若开启平台管理充电桩功能，此字段为充电桩 IPV4 地址 回复报文：见同表 8。7.8 AGV 导航切换 导航方式切换，主要用在二维码和SLAM之间切换。表26 导航切换请求报文消息体(云端控制平台-AGV)消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 设备编号 4 uint32_t AGV 在地图中的唯一标识符 切换类型 1 uint8_t 0:SLAM 切换二维码 1:二维码切换 SLAM 保留字节 3-字节对齐及预留为后续功能扩展 目标导航方式相关信息 144 union 目标导航方式所需信息，为联合类型，根据切换类型决定内容，见表 27 和表 28 表27 SLAM 导航目标信息结构体 消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 SLAM 初始 x 坐标 4 uint32_t SLAM 地图中，切换点的 x 坐标(mm)SLAM 初始 y 坐标 4 uint32_t SLAM 地图中，切换点的 y 坐标(mm)SLAM 初始角度 4 uint32_t SLAM 地图中，切换点的方向(1/1000 deg)目标地图空车精度 1 uint8_t 切换动作的目标导航方式所使用的地图中，空车运动的精度(mm)目标地图载货精度 1 uint8_t 切换动作的目标导航方式所使用的地图中，载货运动的精度(mm)SLAM 地码类型 2 uint8_t SLAM 地码类型，用于指定 SLAM 地图 URL 128 uint8_t 从二维码切换到 SLAM 时，需要下载的 SLAM 地图所在的地址 表28 二维码导航目标信息结构体 消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 22 目标地图空车精度 1 uint8_t 切换动作的目标导航方式所使用的地图中，空车运动的精度(mm)目标地图载货精度 1 uint8_t 切换动作的目标导航方式所使用的地图中，载货运动的精度(mm)地码类型 2 uint8_t 二维码导航方式的地码类型 x 方向信标转换系数 4 uint32_t x 方向信标转换系数 y 方向信标转换系数 4 uint32_t y 方向信标转换系数 回复报文：见同表 8。7.9 地图切换 表29 地图切换请求报文消息体(云端控制平台-AGV)消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 设备编号 4 uint32_t AGV 在地图中的唯一标识符 控制平台 IP IPV4 地址 4 uint32_t 云端控制平台的 IPV4 地址 IPV6 地址 16 uint8_t 云端控制平台的 IPV6 地址 控制平台端口 2 uint16_t 控制平台端口 目标地码类型 2 uint8_t 新地图中地码的类型 目标 x 坐标 4 int32_t 切换点在新地图中的 x 坐标(mm)目标 y 坐标 4 int32_t 切换点在新地图中的 y 坐标(mm)目标 x 信标转换系数 4 int32_t 目标 x 信标转换系数 目标 y 信标转换系数 4 int32_t 目标 y 信标转换系数 相对偏角 4 int32_t 新地图的 x 轴相对于老地图的 x 轴的逆时针方向偏角(1/1000 deg)回复报文：见同表 8。以下报文是发给设备连接的控制平台，向其通知地图切换成功。表30 地图切换成功报文消息体(AGV-云端控制平台)消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 设备编号 4 uint32_t 设备编号 表31 地图切换成功回复报文消息体(云端控制平台-AGV)消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 设备编号 4 uint32_t AGV 在地图中的唯一标识符 回复结果 4 uint32_t 消息回复结果：200 表示成功；201 表示失败 异常码 1-暂未启用 保留字节 3-字节对齐及预留为后续功能扩展 7.10 设备自主调整空间申请 7.10.1 申请锁格空间 表32 锁格申请报文消息体(AGV-云端控制平台)消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 设备编号 4 uint32_t AGV 在地图中的唯一标识符 保留字节 1-字节对齐及预留为后续功能扩展 23 锁格类型 1 uint8_t 空间锁格类型，见附录 A.9 保留字节 2-字节对齐及预留为后续功能扩展 当前位置 x 4 uint32_t 当前点坐标 x 值(mm)y 4 uint32_t 当前点坐标 y 值(mm)锁格区域 16 struct 见表 33 表33 锁格区域结构体 消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 锁格中心x坐标 4 int32_t 锁格中心在地图中的x轴坐标(mm)锁格中心y坐标 4 int32_t 锁格中心在地图中的y轴坐标(mm)锁格宽度 4 int32_t 锁格区域的宽度(mm)锁格深度 4 int32_t 锁格区域的深度(mm)回复报文：见同表8。7.10.2 释放锁格空间 设备向平台申请了空间封锁，且已经完成相应的动作时，需向平台申请释放已锁定的空间。发送申请空间锁格请求后，存活时间（如2min）内，超时（如100ms）未收到云端控制平台响应，则需重发该消息。表34 锁格释放请求报文消息体(AGV-云端控制平台)消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 设备编号 4 int32_t AGV 在地图中的唯一标识符 当前位置 x 4 int32_t 当前点坐标 x 值(mm)y 4 int32_t 当前点坐标 y 值(mm)锁格区域 16 struct 见表 33 回复报文：见同表8。7.10.3 路径封锁申请 表35 路径封锁申请报文消息体(AGV-云端控制平台)消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 设备编号 4 uint32_t AGV 在地图中的唯一标识符 保留字节 1-字节对齐及预留为后续功能扩展 封锁类型 1 uint8_t 空间锁格类型，见附录 A.9 保留字节 2-字节对齐及预留为后续功能扩展 目标信息 x 4 int32_t 规划目标点的 x 坐标(mm)y 4 int32_t 规划目标点的 y 坐标(mm)theta 4 int32_t 规划目标点的 theta 坐标(1/1000 deg)封锁路径-struct 需要封锁的路径，见表 21 回复报文：见同表8。7.10.4 路径解锁申请 设备向平台申请了路径封锁，且已经完成相应的动作时，需向平台申请释放已锁定的空间。发送申请路径解锁请求后，存活时间（如2min）内，超时（如100ms）未收到云端控制平台响应，则需重发该消息。表36 路径解锁申请报文消息体(AGV-云端控制平台)24 消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 设备编号 4 uint32_t AGV 在地图中的唯一标识符 回复报文：见同表8。7.11 状态上报 设备和货物等位置信息及其设备状态信息的上报。状态信息上报要实时上报最新的数据给平台，延迟的历史数据没有意义，所以状态上报的回应ack只作为心跳使用，如果持续没有ack，可以认为跟平台失去连接，状态报不需要重传发包，因为重传包不够实时无意义，直接发最新状态。AGV 实时状态报文对整体系统运行调度非常重要，它能够反馈当前 AGV 执行任务的 ID、AGV编号、位置、角度、速度、状态、业务执行机构状态，从中能够确定 AGV 在执行平台任务时的完成情况，详细状态消息格式如表 37。表37 AGV 状态上报消息体(AGV-云端控制平台)消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 设备 ID 4 uint32_t AGV 在地图中的唯一标识符 任务 ID 2 uint16_t 平台任务 ID 任务子 ID 1 uint8_t 平台任务子 ID 保留字节 1-字节对齐及预留为后续功能扩展 设备状态 4 uint32_t 设备当前状态，见附录 A.2 x 坐标 4 int32_t 设备位置 x 方向坐标值(mm)y 坐标 4 int32_t 设备位置 y 方向坐标值(mm)角度 4 int32_t 设备角度信息(1/1000 deg)速度 4 int32_t 设备实时线速度(mm/s)线加速度 4 int32_t 设备线加速度(mm/s2)线减速度 4 int32_t 设备线减速度(mm/s2)角速度 4 int32_t 设备实时旋转角速度(deg/s)角加速度 4 int32_t 设备旋转角加速度(deg/s2)地码类型 2 uint8_t 地图二维码类型 升级状态 1 uint8_t 平台发了升级请求后，此字段表示升级状态：bit0：是否在升级，0-未处于升级状态，1-升级中 bit1bit7：升级百分比 下载资源状态 1 uint8_t 平台发了下载资源的请求后，此字段表示下载状态：bit0：是否在下载，0-未处于下载状态，1-下载中 bit1bit7：下载百分比 主告警号 2 uint16_t 设备告警主类型 子告警号 2 uint16_t 设备告警子类型 电池温度 2 uint16_t 电池温度值，精确到小数点后两位 1/100(摄氏度)，最大 65 摄氏度 电池电流 2 uint16_t 电池电流，充电时为充电电流，工作时为电池输出电流，精确到小数点后两位，1/100(A)，最大 65A 电池电压 2 uint16_t 电池电压，充电时为充电电压，工作时为电池输出电压，精确到小数点后两位，1/100（V）电池电量 1 uint8_t 电池电量，按照0,100数字上报 保留字节 48-字节对齐及预留为后续功能扩展 执行机构索引 1 uint8_t 执行机构状态信息索引(确定执行机构字段信息格式)执行机构索引参考附录 A.1 25 执行机构状态信息 union 设备执行机构状态，是个联合类型参数，由执行机构索引确定具体内容，具体内容见相关定义。执行机构状态信息索引，见附录 A.1。任务执行状态解读：设备通过实时状态报文向平台反馈实时信息，平台同时可以校验确定任务完成情况，通过任务 ID，任务子 ID，设备状态字段确定，如下表所述。表38 任务执行状态结构体 任务任务 ID，任务子，任务子 ID 设备状态设备状态 代表任务完成情况代表任务完成情况 任务 ID=0，任务子 ID=0 完成/空闲 表示设备初始化完成或从异常中恢复，等待调度 任务 ID=n，任务子 ID=m 完成/空闲 表示任务 ID=n，任务子 ID=m 的平台任务，设备已经执行完成，等待平台新任务 任务 ID=n，任务子 ID=m 任务执行中 表示设备正在执行任务 ID=n，任务子 ID=m 的平台任务-异常/其他状态 表示设备处于某种特殊状态 回复报文：见表31。7.12 AGV 运维数据上报 7.12.1 AGV 故障事件上报 AGV运行过程中故障事件上报对于AGV运营非常重要，以确定AGV故障原因以及故障后的故障分析回溯。表39 AGV 故障上报消息体(AGV-云端控制平台)消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 设备 ID 2 uint16_t AGV 在地图中的唯一标识符 保留字节 2-字节对齐及预留为后续功能扩展 故障主类型 4 int32_t 故障主类型 保留字节 4-字节对齐及预留为后续功能扩展 故障状态 1 uint8_t 0:故障解除，1:故障等待解决中(只上报告警开始一次，告警结束一次),2:脉冲告警(持续上报直到告警结束)故障等级 1 uint8_t 1:低，2:中，3:严重 保留字节 2-字节对齐及预留为后续功能扩展 故障子类型 4 uint32_t 故障子类型 x 坐标 4 int32_t 故障发生时，AGV 所在 x 坐标(mm)y 坐标 4 int32_t 故障发生时，AGV 所在 y 坐标(mm)保留字节 16-字节对齐及预留为后续功能扩展 x 码值 4 int32_t 故障发生时，AGV 所在地码的 x 码值 y 码值 4 int32_t 故障发生时，AGV 所在地码的 y 码值 回复报文：见表31 7.12.2 AGV 里程上报 里程上报数据，用于 AGV 日常保养和备件备货以及异常分析中使用。对应请求目标为 7.5.2。其中消息头参考表 3。表40 AGV 里程上报消息体(AGV-云端控制平台)消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 设备 ID 4 int32_t AGV 在地图中的唯一标识符 总运行时间 4 uint32_t AGV 运行总时间(h)26 总里程 4 uint32_t AGV 运行总里程(km)数量 2 int16_t AGV 底盘舵轮和驱动轮的数量 信息-struct 舵轮或者驱动轮的监控信息，具体定义见表 41 表41 轮子信息结构体 消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 类型 1 uint8_t 0:舵轮，1：驱动轮 保留字节 3-字节对齐及预留为后续功能扩展 运行里程 4 uint32_t 轮子运行里程(km)保留字节 12-字节对齐及预留为后续功能扩展 回复报文：见表31。27 8 总结 期望自实施云端控制平台与物流自动导引车通用接口指南后，在此协议基础上进行的研究与应用取得丰础成果，持续积累与沉淀行业经验，为整个 AGV 行业添砖加瓦。本通用接口协议促进了 AGV 与云端系统间的顺畅通讯。通用接口协议明确了双方信令数据传输和交互的规定，使得 AGV 与云端系统能够高效无误地进行信息交换。此外，对于即时性和连续性要求高的物流环境而言，通用接口协议提供的更稳定通信手段，提高了系统效率。对于安全性而言，依托通用接口协议，采取了多种安全保障措施。这既包括了数据加密、身份认证等信息安全策略，也在协议层面通过防止恶意接入、防止数据泄露等手段提升了云边系统的安全性。这些做法有效降低了由于网络攻击、非法入侵等相对应的风险，保证了云边系统的稳健运行。期望通用接口协议提高各使用单位物流自动化和智能化水平，降低了开发成本和运营风险，同时也提升了业务效率及系统稳定性。期望在企业物流业务应用上，灵活按需配备云端系统与 AGV 设备；在庞大复杂的应用系统中依然保持顺畅高效、安全可靠的 AGV 控制调度云边系统；在企业未来激增的业务体量时，也能稳定应对新增的业务需求。对于通用接口协议的运用，我们将会持续探索，希望在后续工作中，不断优化和完善，不断提升系统的运行效能和安全性，为物流自动导引车的智能化发展贡献力量。28 附录A 执行机构状态 执行机构索引为1，执行机构状态信息表示的滚筒状态 消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 滚筒状态 4 uint8_t 即滚筒上的货物数量：0:编号 0 的滚筒上的货物状态 1:编号 1 的滚筒上的货物状态 2:编号 2 的滚筒上的货物状态 3:编号 3 的滚筒上的货物状态 执行机构索引为2，执行机构状态信息表示为CTU机构信息 消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 状态类型 1 uint8_t CTU 机构上报状态，0：动作机构上报状态，1：检视动作时上报的状态 保留字节 3-字节对齐及预留为后续功能扩展 机构状态-union 动作机构上报状态见附录 A.1.2.1，检视状态上报见附录 A.1.2.2 执行机构索引为 2，执行机构状态信息表示 CTU 机构状态 消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 旋转机构当前位置 4 int32_t 旋转机构位置(1/1000deg)，角度值范围(-180,180 旋转速度 4 uint32_t 旋转速度(1/1000deg/s)伸出机构位置 4 int32_t 当前伸出位置(mm)伸缩速度 4 int32_t 伸缩速度，外部动作为正,内部动作为负(mm/s)升降机构 4 uint32_t 升降机构离地面高度(mm)升降速度 4 int32_t 升降速度，上升为正，下降为负(mm/s)手指个数 2 uint16_t 手指个数，具体定义见附录 A.1.2.1.1 手指状态-struct 手指状态 托盘个数 2 uint16_t 托盘个数 托盘状态-struct 托盘状态，具体定义见附录 A.1.2.1.2 A.1.2.1.1 手指状态 消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 手指 ID 2 uint16_t 手指 ID，0 为左，1 为右 手指状态 2 int16_t 手指状态，-1:打开，1:关闭 A.1.2.1.2 托盘状态 消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 货叉背篓 ID 1 uint8_t 货叉背篓 ID 类型 1 uint8_t 0：货叉，1：背篓 状态 1 uint8_t 料箱状态，0：有料箱，已放置正确，1：没有料箱，2：错误，有料箱，但放置错误 保留字节 1-字节对齐及预留为后续功能扩展 料箱 ID 32 uint8_t 料箱一维码 CTU 检视动作状态上报 消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 29 料箱 ID 32 uint8_t 当检视类型为 0 为时，为扫描到的料箱 ID 料箱状态 1 uint8_t 当检视类型为 1 时，是否存在料箱，0:不存在，1：存在 保留字节 31-字节对齐及预留为后续功能扩展 执行机构索引为3，执行机构状态信息表示的探测到的货架信息 消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 货物字整型 ID 4 uint32_t 货物 ID 货物角度 4 int32_t 探测到的货物角度，即货码的 x 正方向在地码坐标系的角度，范围(-180,180(1/1000deg)货物字符串 ID 32 uint8_t 表示探测到的货架的字符串 ID，即货码上的字符串 执行机构索引为4，执行机构状态信息表示的货物信息 消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 货物字符串 ID 32 uint8_t 表示探测到的货架的字符串 ID，即货码上的字符串 货物 x 坐标 4 int32_t 货物位置的 x 方向坐标(mm)货物 y 坐标 4 int32_t 货物位置的 y 方向坐标(mm)货物角度 4 int32_t 探测到的货物角度，即货码的 x 正方向在地码坐标系的角度，范围(-180,180(1/1000deg)举升状态 1 uint8_t 设备举升执行机构的状态：0：未知状态 1：上升完成，在最顶部 2：下降完成，在最底部 3：中间状态强制停止 4：处理过程中中 5：异常，顶部脱离 6：异常，底部脱离 7：异常，举升时上传感器超时未检测到 8：异常，下放时下传感器超时未检测到:9：异常，上下传感器都检测到 10：转盘归零过程 11：转盘归零过程出错 保留 3-字节对齐及预留为后续功能扩展 执行机构索引为5，执行机构状态信息表示的隐叉机构信息 消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 伸叉长度 4 int32_t 当前隐叉伸出机构的伸出长度(mm)载货状态 1 uint8_t 当前隐叉是否载货，0：隐叉空车，1：隐叉载货 保留字段 3-字节对齐及预留为后续功能扩展 执行机构索引为6，执行机构状态信息表示的机械臂信息 字段名字段名 长度长度(字节字节)类型类型 含义含义 抓取状态 1 uint8_t 表示AGV机械臂是否有抓取物料，0:未抓取，1：已抓取物料 关节数量 1 uint8_t 机械臂的关节数量 物料状态 10 uint8_t AGV本体物料盒，表示物料是否在位 保留字节 18-字节对齐及预留为后续功能扩展 末端位姿 24 struct 末端r-p-y，绕轴z-y-x的顺序旋转角度(1/1000deg)，见A.1.6.1 关节位置-int32 机械臂关节所处位置(1/1000deg)末端位姿 30 字段名字段名 长度长度(字节字节)类型类型 含义含义 x 4 int32_t 机械臂末端相对AGV运动中心的x坐标(mm)y 4 int32_t 机械臂末端相对AGV运动中心的y坐标(mm)z 4 int32_t 机械臂末端相对AGV运动中心的z坐标(mm)翻滚角 4 int32_t 机械臂末端相对AGV运动中心的翻滚角，绕z轴顺时针为正，反之为负(1/1000deg)俯仰角 4 int32_t 机械臂末端相对AGV运动中心的翻滚角，绕y轴顺时针为正，反之为负(1/1000deg)侧航角 4 int32_t 机械臂末端相对AGV运动中心的翻滚角，绕x轴顺时针为正，反之为负(1/1000deg)执行机构索引为7，执行机构状态信息表示的叉车信息 消息体字段消息体字段 长度长度(字节字节)类型类型 含义含义 举升高度 4 uint32_t 当前叉车货叉举升高度(mm)载货状态 1 uint8_t 当前叉车是否载货：0:叉车空车 1:叉车正常载货 2:叉车载货异常 保留 1-字节对齐及预留为后续功能扩展 载货重量 2 uint16_t 实际货物重量(kg)预留 16-便于后续扩展 货架 ID 32 uint_8 载货状态非空时，上报货架的字符串 ID，即货码上的字符串 状态上报中的 AGV 状态 分类分类 具体状态具体状态 枚举值枚举值 运动状态 设备空闲，设备处于 ready 状态，即可以执行指令的状态 0 x1 设备已完成收到的任务 0 x2 控制指令执行中，设备正在执行平台发的控制指令 0 x3 曲线行走中，设备收到平台发的曲线控制指令，且处于曲线段的路径上运动 0 x4 设备的举升机构正在执行动作，举升或下放 0 x5 设备正在进行自主调整 0 x6 设备正在充电 0 x7 设备正在进行电池充满维护 0 x8 设备正在进行动态绕障 0 x9 预留 0 xA0 x40 前方遇障 0 x41 后方遇障 0 x42 左侧遇障 0 x43 右侧遇障 0 x44 曲线移动时前方遇障 0 x45 曲线移动时后方遇障 0 x46 曲线移动时左侧遇障 0 x47 曲线移动时右侧遇障 0 x48 遇障状态预留 0 x490 x80 设备收到暂停指令，并处于暂停状态 0 x81 设备处于异常中，如拍急停，或硬件出错等 0 x82 31 异常偏航 0 x83 货架偏角过大 0 x84 异常状态预留 0 x850 xC0 平台指令错误 0 xC1 平台指令错误预留 0 xC20 xFF 运动失败状态 背货未识别（背货架移动过程中，扫不到货码）0 x100 货码无法识别（举升前扫不到货码）0 x101 货码不匹配 0 x102 举升异常 0 x103 货架位置偏移过大 0 x104 货架堵转 0 x105 矩形托盘，零位检测失败 0 x106 举升状态预留 0 x1070 x13F 充电桩异常 0 x140 电量无增加 0 x141 充电站充电过程中失联 0 x142 充电站未连接 0 x143 能源状态预留 0 x1440 x17F SLAM 定位失败 0 x180 SLAM 预留 0 x1810 x1BF 设备处于显示屏操作中 0 x2C0 滚筒控制中 0 x2C1 对接滚筒失败 0 x2C2 传动指令错误(有料箱发”接”，无料箱发”送“)0 x2C3 传动超时 0 x2C4 料箱个数不匹配 0 x2C5 对接微调中 0 x2C6 对接微调失败 0 x2C7 AGV 作业中 0 x2C8 等待复位按钮确认 0 x2C9 动作执行失败 0 x2CA 货架二维码标定失败 0 x2CB 伸缩动作执行失败 0 x2CC 滚筒 PIO 通信对接失败 0 x2CD 区域锁定失败 0 x300 旋转申请空间锁定暂时失败 0 x301 旋转申请空间锁定永久失败 0 x302 地图切换点地码或标记物未识别 0 x303 运动参数类型 参数类型参数类型 枚举值枚举值 空车运动参数 0 x0 额定负载运动参数 0 x1 非额定负载运动参数 0 x2 充电运动参数 0 x3 目标点属性 目标点属性目标点属性 枚举值枚举值 32 目标点为非储位或充电位 0 x0 目标点为储位点 0 x1 目标点为充电位 0 x2 目标点为电梯 0 x3 移动类型 移动类型移动类型 枚举值枚举值 前进（复杂路径使用）0 x0 后退（复杂路径使用）0 x1 轴向直线前进（直线运动控制使用）0 x2 轴向直线后退（直线运动控制使用）0 x3 斜线前进（直线运动控制使用）0 x4 斜线后退（直线运动控制使用）0 x5 旋转（设备自行计算旋转方向）（复杂路径使用）0 x6 顺时针旋转（复杂路径使用）0 x7 逆时针旋转（复杂路径使用）0 x8 顶升机构调整类型 调整类型调整类型 枚举值枚举值 不限制（设备与货架可以相对旋转，举升前，转盘可以转）0 设备与货架可以有小角度相对旋转，举升前，转盘不能转 1 设备与货架不可以相对旋转，举升前，转盘不可以转 2 设备与货架可以相对旋转，举升前，转盘不能转 3 设备与货架不可以相对旋转，举升前，转盘可以转 4 设备与货架可以小角度相对旋转，举升前，转盘可以转 5 大任务类型 大任务类型大任务类型 枚举值枚举值 通用任务类型 0 x0 充电任务 0 x1 切换地图任务 0 x2 预留 0 x030 x38 动态进货架任务 0 x39 转盘需垂直于车体动作 0 x40 动态对接机台动作 0 x41 动态出货架任务 0 x42 动态出机台任务 0 x43 对接进充电桩任务 0 x44 对接出充电桩任务 0 x45 进出电梯任务 0 x51 滚筒车 V 形板对接 0 x52 隐叉栈板识别任务 0 x61 预留 0 x620 xFF 仓储业务类型 0 x100 移动到储位取货任务 0 x101 搬货到工作台任务 0 x102 搬货回储位任务 0 x103 预留 0 x1040 x1FF 33 轨迹类型 轨迹类型轨迹类型 枚举值枚举值 直线 0 x0 贝塞尔曲线 0 x1 圆弧曲线 0 x2 矩形 0 x3 B 样条曲线 0 x4 参数曲线 0 x5 常规 y=f(x)曲线 0 x6 仅原地旋转 0 x7 空间锁定类型 空间锁定类型空间锁定类型 枚举值枚举值 货架旋转申请 1 设备向前调整，空间锁定申请 2 设备向后调整，空间锁定申请 3 空车旋转，空间锁定申请 4 长方形货架和方形转盘，小车货架下面旋转调整或者旋转托盘 5 动态绕障封锁路径申请 10 特殊区域值定义 对应区域定义对应区域定义 枚举值枚举值 特殊区域起始标志 0 充电区 1 横主通道 1.25 米人工叉车混跑区域 10 横主通道 2.35 米人工叉车混跑区域 11 横主通道无人库区区域 12 纵主通道 1.25 米人工叉车混跑区域 13 纵主通道 2.35 米人工叉车混跑区域 14 纵主通道无人库区区域 15 巷道区域 16 库区区域 17 对接工位区域 18 曲线区域 19 主通道向左侧移 20 主通道向右侧移 21 库位侧移 22 高架区域 31 AGV 类型 类型定义类型定义 枚举值枚举值 顶升 AGV 0 x01 辊筒 AGV 0 x02 叉车 AGV 0 x03 潜伏叉车 0 x04 料箱 AGV 0 x05 机械臂 AGV 0 x06 执行机构类型 34 类型定义类型定义 枚举值枚举值 辊筒机构 0 x01 CTU 机构 0 x02 货架识别 0 x03 顶升机构 0 x04 潜伏叉车伸叉机构 0 x05 机械臂 0 x06 叉车机构 0 x07 执行机构控制参数 辊筒机构 辊筒控制参数 字段名字段名 长度长度(字节字节)类型类型 含义含义 辊筒控制 4 struct 辊筒控制参数由单个辊筒控制参数数组组成，定义见附录A.13.1.2 预留字节 16-预留字节用于后续功能扩展 单个辊筒控制参数 字段名字段名 长度长度(字节字节)类型类型 含义含义 辊筒动作 1 uint8_t 辊筒动作类型，0:辊筒停止，1:从AGV上料到机台，2:从机台接料到AGV 预留字节 1 uint8_t 预留字节,用于后续功能扩展 料箱数量 1 uint8_t 执行上下料动作时，AGV需要接料或者送料的料箱数量 预留字节 1 uint8_t 预留字节,用于后续功能扩展 CTU机构 字段名字段名 长度长度(字节字节)类型类型 含义含义 CTU动作类型 1 uint8_t CTU动作类型，0：移动，1:放箱，2:取箱，3:内部移箱，4:料箱识别 预留字节 7-预留字节,用于后续功能扩展 CTU动作参数-union 当动作类型 为0时，使用CTU移动参数 为1,2时，使用CTU外部取货参数 为3时，使用CTU内部取货参数 为4时，使用料箱识别参数 CTU 移动动作参数 字段名字段名 长度长度(字节字节)类型类型 含义含义 路径执行机构限制参数-struct 在到达目标点前，AGV在地图上的执行机构限制参数，定义见附录A.13.2.1.1 目标点执行机构限制参数-struct 路径终点为最终目标点，AGV在地图上的执行机构限制参数，定义见附录A.13.2.1.1 执行机构高度 2 uint16_t 执行机构动作高度，用于到达前的预处理动作 执行机构目标角度 2 int16_t 执行机构动作目标角度 预留字节 36-预留字节,用于后续功能扩展 35 货叉参数-struct 货叉参数，见附录A.13.2.1.2 预留字节 32-预留字节,用于后续功能扩展 A.13.2.1.1 限制参数定义 字段名字段名 长度长度(字节字节)类型类型 含义含义 是否携带料箱 1 uint8_t 是否携带料箱，0：不带料箱，1：带料箱 预留字节 5-预留字节,用于后续功能扩展 货叉角度最小值 1 int8_t 货叉角度最小值(1/1000deg)货叉角度最大值 1 int8_t 货叉角度最大值(1/1000deg)举升机构下限 2 uint16_t 举升机构运动下限(mm)举升机构上限 2 uint16_t 举升机构运动上限(mm)前进方向下限 2 uint16_t 前进方向下限(mm)前进方向上限 2 uint16_t 前进方向上限(mm)垂直方向下限 2 uint16_t 垂直方向下限(mm)垂直方向上限 2 uint16_t 垂直方向上限(mm)预留字节 16-预留字节,用于后续功能扩展 A.13.2.1.2 货叉/背篓参数 字段名字段名 长度长度(字节字节)类型类型 含义含义 背篓/货叉ID 1 uint8_t 背篓/货叉ID 类型 1 uint8_t 0：货叉，1：背篓 CTU 外部取货动作参数 字段名字段名 长度长度(字节字节)类型类型 含义含义 料箱ID 32 uint8_t 料箱ID 动作高度 2 uint16_t 动作高度(mm)动作目标角度 2 int16_t 动作目标角度(1/1000deg)预留字节 36-预留字节,用于后续功能扩展 背篓/货叉参数-struct 见附录A.13.2.1.2 保留字节 32-字节对齐及预留为后续功能扩展 CTU 内部移箱动作参数 字段名字段名 长度长度(字节字节)类型类型 含义含义 料箱ID 32 uint8_t 料箱ID 动作高度 2 uint16_t 动作高度(mm)动作目标角度 2 int16_t 动作目标角度(1/1000deg)预留字节 36-预留字节,用于后续功能扩展 源背篓/货叉参数-struct 源背篓/货叉参数,见附录A.13.2.1.2 目标背篓/货叉参数-struct 目标背篓/货叉参数,见附录A.13.2.1.2 保留字节 32-字节对齐及预留为后续功能扩展 CTU 料箱检视参数 字段名字段名 长度长度(字节字节)类型类型 含义含义 巡检类型 1 uint8_t 巡检类型,0:扫描货箱ID,1:检查库位是否有货箱 36 保留字节 3 uint8_t 字节对齐及预留为后续功能扩展 动作高度 2 uint16_t 动作高度(mm)动作目标角度 2 int16_t 动作目标角度(1/1000deg)动作货叉参数-struct 动作货叉参数，见附录A.13.2.1.2 保留字节 32-字节对齐及预留为后续功能扩展 货物识别 字段名字段名 长度长度(字节字节)类型类型 含义含义 识别类型 2 uint 识别类型，根据场景使用不同的识别类型 0:打开货码灯扫码，超时扫不到，报【完成】1：开货码灯扫码，超时扫不到报告警 超时时间 4 uint 用于识别货码时判断动作是否完成 预留字节 16-预留字节,用于后续功能扩展 顶升机构 字段名字段名 长度长度(字节字节)类型类型 含义含义 保留字节 26-字节对齐及预留为后续功能扩展 货架ID字符串 32 uint8_t 货架的字符串形式的ID 货架类型 1 uint8_t 货架的类型：0 正方形货架,1 长方形货架,其他：用户自定义 举货架精度 1 uint8_t 举货架前，货架与小车之间距离需满足的精度(mm)调整类型 1 uint8_t 货架的调整类型（包括举之前和举着货架移动过程中），见附录A.6 保留字节 1 uint8_t 字节对齐及预留为后续功能扩展 举升高度 2 uint16_t 单位mm 保留字节 2 uint16_t 字节对齐及预留为后续功能扩展 货架移动角度 4 int32_t 运行过程中保持货架与小车角度平行还是垂直(1/1000deg)999000：表示不关注 777000：表示货架与 AGV 垂直 666000：表示货架与AGV平行 货架目标角度 4 int32_t 到此任务目标点时，货架的方向(1/1000 度)，(若该值为999000，表示不关注目标角度)货架长度 4 uint32_t 货架长度(mm)货架宽度 4 uint32_t 货架宽度(mm)货物重量 2 uint16_t 货物重量(kg)放货架精度 1 uint8_t 下放货架的精度(mm)保留字节 1 uint8_t 字节对齐及预留为后续功能扩展 货码x偏移 4 int32_t 货架码x偏差(mm),没有标定发0 货码y偏移 4 int32_t 货架码y偏差(mm),没有标定发0 货码角度偏移 4 int32_t 货架码theta偏差(1/1000deg),没有标定发0 潜伏叉臂 字段名字段名 长度长度(字节字节)类型类型 含义含义 举升高度 2 uint16_t 取、放货动作前需要举升的高度(mm)x 4 int32_t 仅移动与执行机构同步时，此字段生效，表示 AGV 移动过程中，执行机构开始执行动作的位姿：y 4 int32_t 37 同步动作的位姿 theta 4 int32_t 保留字节 12-字节对齐及预留为后续功能扩展 货物类型 1 uint8_t 叉取栈板类型 保留字节 83-字节对齐及预留为后续功能扩展 机械臂 字段名字段名 长度长度(字节字节)类型类型 含义含义 抓取点ID 4 uint32_t 起始点ID 保留字节 16-字节对齐及预留为后续功能扩展 放料点ID 4 uint32_t 放料点ID 保留字节 16-字节对齐及预留为后续功能扩展 动作ID 4 uint32_t 机械臂执行动作ID 保留字节 16-字节对齐及预留为后续功能扩展 叉车 定义同附录A.13.5。

0人已浏览 2023-12-19 42页 5星级

I中国算力调度发展研究蓝皮书ODCC-2023-05003编号 ODCC-2023-05003中国算力调度发展研究蓝皮书开放数据中心委员会2023-08 发布中国算力调度发展研究蓝皮书ODCC-2023-05003I版权声明版权声明ODCC（开放数据中心委员会）发布的各项成果，受著作权法保护，编制单位共同享有著作权。转载、摘编或利用其它方式使用 ODCC 成果中的文字或者观点的，应注明来源：“开放数据中心委员会 ODCC”。对于未经著作权人书面同意而实施的剽窃、复制、修改、销售、改编、汇编和翻译出版等侵权行为，ODCC 及有关单位将追究其法律责任，感谢各单位的配合与支持。中国算力调度发展研究蓝皮书ODCC-2023-05003II编写组编写组项目经理：项目经理：吴美希中国信息通信研究院工作组长：工作组长：郭亮中国信息通信研究院贡献专家：贡献专家：阮迪中国信息通信研究院温小振中国信息通信研究院常金凤中国信息通信研究院张慷中国电信股份有限公司上海分公司桑洁丽中国电信股份有限公司上海分公司储伟伟中国电信股份有限公司上海分公司中国算力调度发展研究蓝皮书ODCC-2023-05003III前前 言言2023 年 2 月，中共中央、国务院印发了数字中国建设整体布局规划（以下简称规划），明确了“2522”的整体框架。其中，特别提到：“系统优化算力基础设施布局，促进东西部算力高效互补和协同联动，引导通用数据中心、超算中心、智能计算中心、边缘数据中心等合理梯次布局。”东西部算力高效互补和协同联动的实现离不开算力调度。近年来，关于加快构建全国一体化大数据中心协同创新体系的指导意见、全国一体化大数据中心协同创新体系算力枢纽实施方案、新型数据中心发展三年行动计划（2021-2023 年）等文件明确了算力调度的重要意义，国家东数西算工程的推进和实施更是离不开算力调度。为梳理当前算力调度的概念、技术和应用现状，中国信通院云大所数据中心团队联合上海电信基于前期研究成果编制了中国算力调度发展研究蓝皮书（2023 年）。本蓝皮书聚焦了算力调度技术的最新研究进展，分析了目前现有的算力调度技术，对比国内各厂商算力调度平台应用情况，从而更好地指导和建议业界判断行业发展趋势，为未来算力调度发展提供思路。如对蓝皮书有建议或意见，请联系：。中国算力调度发展研究蓝皮书ODCC-2023-05003IV目目 录录版权声明.I编写组.II前言.III一、算力调度概述.1（一）算力与异构算力.1（二）算力网络与算网融合.1（三）算力调度.2二、算力调度技术研究.3（一）跨区域算力调度技术.3（二）闲置算力调度技术.41.闲置算力的调度方法.42.集群调度器的分类.5（三）超算算力调度技术.81.算力调度平台架构.82.超算中心主流 HPC 调度器.9（四）边缘算力调度技术.101.调度技术与算法现状.102.边缘算力调度技术架构.113.典型应用场景.12三、现有算力调度平台分析.13（一）中国联通算力调度平台.131.算网一体化编排调度平台.13中国算力调度发展研究蓝皮书ODCC-2023-05003V2.天穹算力运营调度平台.143.中国联通边缘计算平台.15（二）中国电信算力调度平台.161.甘肃省算力调度平台.162.“息壤”算力分发网络平台.18（三）中国移动混合算力感知调度 AI 平台.20（四）中科曙光一体化算力交易调度平台.21（五）华为公共多样性算力服务平台.22（六）浪潮 AI 计算系统及推理平台.24（七）北鲲云一站式云超算平台.25（八）趋动云 AI 平台.26四、异构计算调度系统分析.27（一）典型异构计算平台.271.阿里云震旦异构计算平台.272.百度百舸 AI 异构计算平台.283.FPGA 异构计算平台.29（二）异构 AI 算力操作平台.301.操作平台定义.302.技术架构.31（三）异构计算调度技术.321.分布式异构计算调度技术.322.面向 FaaS 的算网异构算力调度技术.33五、总结.34中国算力调度发展研究蓝皮书ODCC-中国算力调度发展研究蓝皮书中国算力调度发展研究蓝皮书一、一、算力调度算力调度概述概述（一一）算力与算力与异构异构算力算力算力是服务算力是服务器器通过对数据通过对数据进进行处理行处理后后实现实现结果输结果输出的一出的一种种能力，能力，最最常常用的计量单位是每用的计量单位是每秒执秒执行的行的浮浮点运算次数点运算次数（FLOPS）。算力主要包括通用算力、智能算力、超算算力、边缘算力四类。其中通用算力以 CPU 芯片输出的计算能力为主；智能算力以 GPU、FPGA、AI 芯片等输出的人工智能计算能力为主；超算算力主要以超级计算机输出的计算能力为主；而边缘算力主要以就近为用户提供的实时计算能力为主，是以上三种算力形式的组合。异构异构算力是指算力是指 CPU、GPU、FPGA、ASIC 等多种等多种算力算力协协同的同的处理体系处理体系,能能够满够满足不同场足不同场景景中的应用需求中的应用需求,实现计算效力的最大化。实现计算效力的最大化。在市场需求的驱动下，算力的发展一方面呈现多样性，打破传统的单一架构的算力形态，实现了异构算力以应对不同场景下的数据处理应用；另一方面又呈现出异构算力下的能力开放和统一管理，不论是芯片厂商还是平台厂商目前都围绕自身的产品系统，将底层的异构算力能力进行融合，从而吸引更多的产业链上下游企业共同打造生态环境。（二二）算力算力网络网络与算与算网网融合融合算力算力网络网络是一是一种种根据业务需求，在根据业务需求，在云云、网网、边边、端之间、端之间按按需分需分配配和和灵活灵活调度计算调度计算资源资源、存储、存储资源资源以以及网络资源及网络资源的新型信息基础设施。的新型信息基础设施。中国算力调度发展研究蓝皮书ODCC-它的本质是一种算力资源服务，为企业客户或个人用户提供网络和云资源以及灵活的计算任务调度。算算网网融合是以通信融合是以通信网络网络设施和计算设施的融合发展为基础，通过设施和计算设施的融合发展为基础，通过计算、存储计算、存储及网络资源及网络资源统一编统一编排管控排管控，满满足业务对足业务对网络网络和算力和算力灵活灵活泛泛在、在、弹弹性性敏捷敏捷、智能、智能随随需应用需求的一需应用需求的一种种新型业务模式。新型业务模式。算网融合能够解决现有 TCP/IP 网络体系结构存在的技术瓶颈，增强泛在算力一体化管理能力，满足业务场景对于低时延、高可靠网络的需求。随着网络云化、云网融合趋势的不断加强，算网融合成为云网融合发展重要阶段，其技术创新主要体现在新架构、新协议和新度量三方面。在架构方面，由算、存、网分离，向算、存、网深度融合演进。在协议方面，由网络调度，向网络和计算联合调度优化演进。在度量方面，由网络性能度量，向算力度量体系演进。（三三）算力调度算力调度算力调度是通过对不同业务的算力算力调度是通过对不同业务的算力资源资源和算力需求和算力需求进进行行匹配匹配，使使合理的算力合理的算力去去处理处理相相应数据的一应数据的一种种方式。方式。算力调度是高效利用算力资源的关键。算力调度更多是指调用合理的算力去处理相应的数据。目前算力调度存在许多问题，例如算跨 AI 框架的应用无法直接调度，需要应用代码迁移；算法适配具有高度的专有性，不同的加速芯片适配技术复杂多样；跨厂商的作业调度生态支持能力弱，异构芯片适配标准不统一等。中国算力调度发展研究蓝皮书ODCC-二、二、算力调度技术算力调度技术研究研究（一一）跨跨区区域算力调度技术域算力调度技术跨跨区区域算力调度是以算域算力调度是以算网网大大脑脑作为算力作为算力网络网络的的核核心系统，重点在心系统，重点在构构建分建分层层分域分域管管理的算理的算网架构网架构。通过专通过专网构网构建跨建跨区区域分布式算域分布式算网网大大脑脑。分层算网大脑架构在总部部署总部中心算网大脑,分布式控制调配全网算力资源。同时,在省内部署区域中心算网大脑，实现区域的集中控制、本地优先。总部中心与各省的算网大脑通过专用网络实现算力协同,共同构成覆盖全国的超级分布式算网大脑。算力分层分级调度如图 1 所示图 1 算力分层分级调度算算网网大大脑脑基于基于开放资源矩阵进开放资源矩阵进行算行算网网地地图图建模。建模。基于算网请求的多维约束条件和权重短阵动态并行计算 Top N 候选结果，然后以资源利用率、成本、能耗等多目标进行求解后得到最终优选的算和网，并建立网络路径和流量引流，最终实现算网资源双均衡效果。算网地图建模如图 2 所示。中国算力调度发展研究蓝皮书ODCC-图 2 算网地图建模全国全国范围范围集中集中管控管控算力算力资源带资源带来来巨巨大的计算量需求，需要从算力大的计算量需求，需要从算力资源资源和和管管理方面集中评理方面集中评估估算力算力资源资源的调的调配配。在跨省调度效益方面，跨省资源选择“东数西算”枢纽资源，而社会泛在算力资源只在省内调度，可确保跨省调度效益最大化。在管理方面，将路径计算分成用户所在省、全国骨干网、云资源所在省三段，算力评估时各自计算路径,使计算分布式,提高效率、优化管理流程。不同不同厂商厂商的的网络网络设备实现设备实现互互通可有效助力算力通可有效助力算力网络网络需求需求匹配匹配。其中一种有效方法是，复用现有的通用网络协议。主要实现两大大目标：一是有效降低对路由器软件和性能的要求；二是实现了尽可能少的对路由器进行改造，从而充分利用现有资源，降低迭代、运维成本，加快算力网络落地进度。（二二）闲闲置算力调度技术置算力调度技术海量海量闲闲置算力的调度技术，重点置算力的调度技术，重点聚焦聚焦方方法研究法研究，重点，重点聚焦聚焦于算力于算力调度的各调度的各种种方方法法和集和集群群调度调度器研究两器研究两大分大分类类。1.1.闲闲置算力的调度方置算力的调度方法法中国算力调度发展研究蓝皮书ODCC-空空闲闲算力调度模型分为算力调度模型分为 Monolithic 统一调度、统一调度、Two-Level 两级两级调调度、度、Shared State 共享状态共享状态调度。调度。Monolithic 统一调度：通过集群状态信息，负责统一的资源和任务的调度。统一调度也被称为云计算中的调度，属于静态资源分区调度方式。资源集合的全面控制。部署在专门的，静态划分的集群的一个子集上。或把集群划分为不同的部分，分别支持不同的行为。Two-Level 两级调度：通过资源动态划分，使用中央协调器来确定每个子集群可以分配的资源，每个子调度器不具备全局资源视图，只是被动的接收资源，中央协调器仅将可用的资源推送给各个框架，各框架自主选择使用或拒绝这些资源。一旦框架接收到新资源后，再进一步将资源分配给其内部的各个应用程序，即调度策略下放到各个应用程序调度器，进而实现双层调度。Shared State 共享状态调度：系统同时存在多个调度器，每一个调度器都可以访问整个集群状态，共享全局资源视图，当多个调度器同时更新集群状态时使用乐观锁并发控制。2.2.集集群群调度调度器器的分的分类类(1)统一调度架构典型系统Kuberneteernetes：Kubernetes 是一个容器集群的编排管理系统，主要面向跨 Docker 主机场景之下容器集群的统一管理，用于自动部署、扩缩和管理容器化应用程序，提供资源调度、部署管理、服务发现、扩容缩容、监控、维护等一整套功能。中国算力调度发展研究蓝皮书ODCC-BorBorg：Borg 是 Google 内部自研的一套资源管理系统，用于集群资源管控、分配和调度等。通过准入控制，高效的任务打包，超额的资源分配和进程级隔离的机器共享，来实现超高的资源利用率。能够支持高可用应用，并通过调度策略减少出现故障的概率。S Swararm：Swarm 是 Docker 公司的一套管理 Docker 集群的工具。架构包含 Manager 和 Node，Manager 是 Swarm Daemon 工作的节点，包含了调度器、路由、服务发现等功能，负责接收客户端的集群管理请求，然后调度 Node 进行具体的容器工作，如容器的创建、扩容与销毁等。TorcaTorca：Torca 是腾讯 Typhoon 云平台的关键系统。一个 Torca集 群 由 一 个 Central Manager 和 若 干 Execute Server 组 成。Central Manager 是集群任务调度中心，Execute Server 接收任务并负责相应执行。伏羲：伏羲：伏羲是阿里巴巴“飞天”云计算平台的分布式调度系统，有资源调度和任务调度分离的两层架构。主要负责集群资源管理和任务调度，支持超大规模，水平扩展，提供优先级、抢占、Quota等灵活的资源调度功能。(2)两级调度架构典型系统MeMeso os：Mesos 是 Apache 的开源分布式资源管理框架，通过在多种不同框架之间共享可用资源来提高资源使用率，包括 Mesos 资源管理集群和框架两部分。资源管理集群是由一个 Master 节点和多个 Slave 节点组成的集中式系统，框架负责任务的管理与调度。主中国算力调度发展研究蓝皮书ODCC-要的资源分配算法是最大最小公平算法（MMF）和主导资源公平算法（DDRF）。Yarnarn：Yarn 是一种新的 Hadoop 资源管理器，也是一个通用资源管理系统和调度平台，主要面向大数据计算，可为上层应用提供资源管理和调度，为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。Yarn 由 Resource Manager、Node Manager、Container 和 Application Master 组成，是一个典型的多级调度。(3)共享状态调度架构典型系统O Ome ega a：Omega 是 Google 下一代资源管理系统。基于共享状态的策略，每个调度器拥有全局资源视图，具有整个集群全部负载信息的完全访问权限。Omega 中的“元调度器”（Cell State）维护着一个全局共享的集群状态，而每个调度器具有一个私有集群状态副本。A Apolloollo：Apollo 是微软已经部署在微软实际生产环境中的集群调度系统，负责上万台机器百万计的高并发计算任务的调度和管理。每个调度器拥有全局资源视图，具有整个集群的完全访问权限。No omadad：Nomad 是 Hashicorp 开源公司推出的一款分布式、高可用的开源集群管理工具，通过“Plan Queue”来维持一个全局共享的集群状态。专为微服务和批量处理工作流设计，支持所有主流操作系统以及虚拟化、容器化或独立应用，现已在生产环境使用。Nomad 支持跨数据中心跨区域数千节点的高扩展和任务调度。中国算力调度发展研究蓝皮书ODCC-（三三）超算算力调度技术超算算力调度技术超算算力调度技术主要用于超算算力调度技术主要用于解决多资源匹配问题解决多资源匹配问题，通过调度超算，通过调度超算的的带宽带宽、CPU/GPU、软件资源软件资源，满满足用足用户户对于计算对于计算功功能、能、延迟延迟、带带宽宽的各的各类类需求。需求。1.1.算力调度平算力调度平台架构台架构超算算力调度平超算算力调度平台架构台架构主要主要采采用用上下层两级架构上下层两级架构。上层部署总部中心算力调度系统，用于管理各省的子系统，包括运营系统和边缘云管控力系统；下层部署各省内区域算力调度子系统，同样包括两层，上层为运营系统和边缘云管控力系统，下层包括边缘云基础设施资源层、硬件资源层、虚拟层、软件资源层、云平台管理等部分。平台架构如图 3 所示。图 3 算力平台架构超算平超算平台管台管理理架构包括架构包括服务服务管管理理层层、调度分发、调度分发层层、算力服务、算力服务层层三三个部分。个部分。服务管理层为统一运营支撑系统；调度分发层包括运营管理子系统和全局调度控制中心，运营管理子系统可以接入厂商的订中国算力调度发展研究蓝皮书ODCC-单管理系统，接收来自全国各省各地节点的资源；算力服务层按照省市区形成省会算力节点、地市算力节点、区县算力节点。2.2.超算中心主流超算中心主流 HPCPC 调度调度器器基于基于 HPC 场场景景的集的集群任群任务调度的主流调度务调度的主流调度器器有四有四类类:LSF、SGE、Slurm、PBS。不同行业。不同行业采采用不同的调度用不同的调度器器。如高校和超算中心常用Slurm，半导体公司最常用 LSF 和 SGE，工业和制造业多采用 PBS。在在使使用用范围上范围上，LSF 用于用于科学科学计算和计算和企企业的业的事事务处理。务处理。功能上，LSF 除了一般的作业管理特性外，还在负载平衡、系统容错、检查点操作、进程迁移等方面力图实用化。LSF 系统主要包括用于商用的 Spectrum LSF 和 Platform LSF、开源免费的 OpenLava 三款调度器。其中，仅有 Spectrum LSF 支持 Auto-Scale 集群自动伸缩功能，同时还可通过 LSF resource connector 实现溢出到云，支持云厂商包括 AWSQ、Azure、Google Cloud 四家。SGE 能用于能用于查找并利查找并利用用资源池内资源池内的的闲闲置置资源资源。用于通常的一些事务中，例如管理和调度作业到可用资源中。SGE 则包括 UGE 和SGE，目前不再开源。对于 UGE 调度器，用户可通过 Univa 产品Navops Launch 把工作负载移到云端，同时支持 UGE 和 Slurm 集群。同时，Navops Launch 支持 AWS、Azure、Google Cloud 等云厂商，并能进行云端费用监控以及 Auto-Scale 集群自动伸缩。PBS 多多用于用于便携便携式批处理系统式批处理系统接受接受批处理作业。批处理作业。PBS 只能在作业执行后，将作业结果返回给提交者。目前，PBS 包含开源免费的OpenPBS、商业付费的 PBS Pro、Torque 三种分支。PBS Pro 支持可中国算力调度发展研究蓝皮书ODCC-视化界面，支持的云厂商包括 AWS、Azure 和 Google Cloud。Moab/TORQUE 则可通过 NODUSCloud OS 产品实现本地扩展到云，支持 TORQUE 或 Slurm 集群和自动伸缩，可支持的云厂商包括AWS、Azure、GoogleCloud 和华为云，并通过 Account Manager产品实现云端费用监控。Slurm 是一是一种种可用于大型计算节点集可用于大型计算节点集群群的高度可的高度可伸缩伸缩和和容容错的集错的集群管群管理理器器和作业调度系统。和作业调度系统。被世界范围内的超级计算机和计算集群广泛采用。Slurm 以一种共享或非共享的方式管理可用的计算节点（取决于资源的需求），以供用户执行工作。Slurm 会为任务队列合理地分配资源，并监视作业至其完成。Slurm 拥有容错率高、支持异构资源、高度可扩展等优点。此外，Slurm 开放框架可配置度高，适用性相当强。（四四）边缘边缘算力调度技术算力调度技术边缘边缘计算调度是基于计算调度是基于云原云原生的生的资源资源调度调度机机制，主要制，主要采采用用轻轻量化、量化、多多集集群群的分的分级边缘资源级边缘资源调度方调度方案进案进行算力行算力资源资源的调度。的调度。1.1.调度技术与算调度技术与算法法现现状状在技术方面，在技术方面，对于算力网络架构，现有调度方案主要采用基于云原生的资源调度机制来实现轻量化、多集群的分级。其中资源调度和管理平台是以 Kubernetes 为主的容器云来实现资源调度编排和统一管理。在算力网络资源调度方面，一方面采用轻量级的容器调中国算力调度发展研究蓝皮书ODCC-度平台适配于开放式嵌入式边缘计算集群；另一方面，实现统一的多集群的边缘计算集群的统一管控和动态扩缩容的资源弹性调度。在算在算法法方面，方面，一类算法是基于业务模型和用户规模双因子估算，另一类算法是把终端设备和边缘计算设备绑定。这两类现有调度算法的技术缺点包括：如存储、加密解密、图像识别和 VR 视频渲染等，操作起来繁琐；无法满足短周期算力需求的估算要求；算力得不到灵活分配和调度，导致高级别的业务算力需求得不到充分满足，同时低级别的业务算力需求不足造成算力浪费。2.2.边缘边缘算力调度技术算力调度技术架构架构在系统在系统架构架构方面，方面，基于“Kubernetes K3S”两级联动实现统一的边缘侧资源调度管理，即边缘计算节点侧采用传统 Kubernetes云原生实现资源纳管，同时负责底层嵌入式终端集群的注册和管理等统一多集群调度管理，而前端嵌入式终端集群则采用更加轻量级的 K3S 云原生平台实现资源管理，技术架构如图 4 所示。图 4 边缘调度系统技术架构中国算力调度发展研究蓝皮书ODCC-在在容器容器部署方面，部署方面，各厂商结合自家的专用芯片推出了相应的解决方案，通常的技术架构是基于 MCU 的嵌入式操作系统提供驱动层或者系统适配层，用于专用芯片的资源访问接口和提升资源调度能力，并通过插件方式实现 Kubernetes 对于专用芯片资源的调度和适配。主要采用“MCU 专用芯片”芯片架构。在边缘计算场景下，专用芯片在算法训练、推理和硬件编解码等方面更具优势，用来执行算力。3.3.典典型应用场型应用场景景在时在时延延、带宽带宽和和安安全三个方面对全三个方面对边缘边缘算力调度的需求在算力调度的需求在众多垂直众多垂直行业的新业务中行业的新业务中显显现明现明显显。目前智能制造、智慧城市、直播游戏和车联网 4 个垂直领域对边缘计算的需求最为明确。智能智能驾驶驾驶业务场业务场景下景下应用。应用。车载系统在保证低时延的数据处理需求的情况下，需要将数据和控制尽可能的保证在本地进行处理，同时需要通过 MEC 等，实现云端资源和策略调度的协同，例如：智能路灯等信号的处理和反馈；另一方面，由于车载系统本身的计算和存储能力有限，因此需要基于 K3S 等轻量级的资源调度系统来实现车载系统的资源管理和应用运行。具体如图 5 所示。通过环境感知来实现环境数据采集和智能训练，实现无人驾驶车辆自主识别避障。中国算力调度发展研究蓝皮书ODCC-图 5 智能驾驶业务场景下应用三、三、现有算力调度平现有算力调度平台台分析分析（一一）中国联通算力调度平中国联通算力调度平台台1.1.算算网网一体化编一体化编排排调度平调度平台台平平台概述：台概述：目前平台正在建设，能够实现对公有云、私有云、算力及网络资源的统一调度，在云、网、边之间按需分配和端到端智能调度算网资源，满足不同行业应用场景对算网的需求。调度调度机机制制：基于边缘云进一步下沉算力，引入智能算力网关，通过 SDWAN 网络链接边缘云和智能算力，并基于 SRv6 技术实现应用、网络统一编排和可编程调度执行功能，构建面向云网算业一体的算力网络管理编排架构和算力网络可编程调度体系，并制定南北向接口规范、测试标准等，支撑集团相关系统开发及部署，实现算网统一管控、协同编排和灵活调度，支持对中心云、边缘云以及在网算力、端算力等的端到端一体化编排调度能力。中国算力调度发展研究蓝皮书ODCC-应用应用情况：情况：中国联通算网一体化编排调度平台及基于该平台开发的云网边一体产品提供方便快捷的一站式算网融合服务。目前，该产品已在江苏、河北、上海、福建、重庆等多个省分公司进行试点，覆盖工业互联网、智慧交通、教育、能源等多个行业、多个领域。2.2.天穹天穹算力运算力运营营调度平调度平台台平平台概述：台概述：目前天穹算力运营调度平台已完成建设，并正式投入运营，为业内首个三算一体统一调度平台。通过平台向用户提供基础、智能、超级算力订购模式，满足不同类用户算力使用需求；平台同时向用户提供算力调度、运营等内部管理手段。天穹算力运营平台以多云纳管和异构算力资源分配调度机制为核心，聚合运营商高速专网优势，集成整合存储服务、监控运维、安全防护、迁移灾备等生态能力，提供一站式算力智能调度运营服务。平台架构如图6 所示。图 6 天穹算力运营平台架构中国算力调度发展研究蓝皮书ODCC-平平台特征：台特征：该平台为业内首个实现异构算力资源抽象建模、统一调度分配功能的调度平台。云算网储能力：多云纳管数量业界第一，具备云网专线、高性价比存储，云算网储统一纳管能力。拥有强大的算力调度编排框架适配性：能够适配多种算力调度编排框架，包括容器（Kuebernets）、人工智能（Kubeflow）、超算（Slurm、OpenPBS）等，解决应用对算力资源的编排作业需求。拥有高效智能的运营运维体系，对运营与运维人员提供针对性的自定义统计分析报表、自定义监控告警、自动化作业等运营运维场景服务。应用应用情况：情况：平台已应用于工业、政务、医疗多个行业。在医疗、工业、政务等关键民生领域输出算力资源，该平台产品已在多个大型国企、事业单位落地应用。平台支撑项目涵盖医疗、工业、政务等民生关键领域，赋能大湾区千行百业数字化转型。典型应用案例为：粤康码、疫苗预约、核酸检测等。3.3.中国联通中国联通边缘边缘计算平计算平台台平平台概述：台概述：中国联通 5G 边缘计算目前已经遍布 31 个省市、近200 个地市，具备近百万核 CPU 计算能力，全网基本完成 SDN 升级。5G 边缘计算平台，提供“边缘能力供给”和“集约支撑服务”，支持全网业务开展。面向“算网一体”演进，完成 3.0 版本迭代。边缘计算平台 3.0 构建了集“固移融合通信、网络大数据、网络增强能力”于一体的边缘计算多接入体系，拓展了 MEC 的内涵和外延。平平台特征：台特征：一是异构算力底座兼容，通过平台进行统一编排和调度管理，解决目前不同边缘业务对 CPU、GPU、DPU 等计算资源不同中国算力调度发展研究蓝皮书ODCC-的需求。二是能够实现边缘网络云化升级、支持下一代网络（IPV6）。边缘云化网络平面构建解决了当前物理路由器、交换机、负载均衡等网络设备型号繁多，需人为去逐项适配的问题，SDN 云化网关则实现了边缘业务的敏捷开通和交付。三是边缘通信增强能力规模开放。通过专网探针 专网网关能力，有效阻挡网络攻击，为工业等应用提供更加安全可靠的边缘服务保障。应用应用情况：情况：在车联网、视频、工业领域，推出了系列场景化边缘计算产品服务。在视频领域提供了边缘视频一站式服务，对视频进行预分析，并精准定位多样化场景，已广泛应用于新媒体、智慧教育、智慧交通、智慧城市等行业。在车联网领域实现车辆位置自动感知、边缘节点就近接入、边缘应用跨域切换、云边端一体协同功能，产品已在高潜市场实现标志性突破，满足车路协同多种业务场景需求；在工业领域实现产线数采、工业 AI、云化集控、智能调度等工业应用。（二二）中国中国电电信算力调度平信算力调度平台台1.1.甘肃省甘肃省算力调度平算力调度平台台平平台概述：台概述：目标是打造高速泛在、天地一体、云网融合、智能敏捷、绿色低碳、安全可控的智能化综合性信息基础设施，面向全国用户实现云网业务的统一受理、统一交付、统一呈现，实现云网深度融合供给，满足用户一体化服务需求。平台基于“能力与应用分离、应用与数据分离”的云化解耦思路，遵循“中心化、服务化”中国算力调度发展研究蓝皮书ODCC-架构原则，具备业务运营、服务、管理全流程的中台能力，面向政府、企业、个人灵活构建上层算力应用，提供丰富的业务应用场景。平平台特征：台特征：甘肃将整合省内的闲置算力资源，面向省外算力需求提供算力清单，建立全省统一的算力资源池；制定全省统一的算力接入标准，引导新建算力资源按统一标准建设及接入；建设算力调度平台，形成覆盖全省、互联互通的算力调度服务体系和平台基础框架，实现对全网算力资源统一编排、统一输入输出；构建算力交易平台，建立算力交易和结算体制，实现算力资源线上交易。平平台架构：台架构：包括算力运营要素、算力调度网络、天翼云技术底座、业务中台、安全中台等部分。算力运营核心要素包括云、网、物资及其他资源。算力调度网络是实现云网融合、算网一体调度的基础，通过算力网关、算力路由、算网融合及算网控制等网络关键技术，为上层云网一体化调度提供服务能力。天翼云技术底座，全面提升了算力、存储、网络的能力，重点覆盖产业上云场景。业务中台是调度平台的内核，主要包含算网管理、算网计量、算网大脑等组件。安全中台采用先进安全理论，对系统进行全方位监测预警，认清风险、找出漏洞、通报结果。算力调度平台架构如图 7 所示。中国算力调度发展研究蓝皮书ODCC-图 7 算力调度平台架构平平台特征：台特征：平台核心服务能力主要包括，提供集云、网、数、智、安等多要素于一体的融合性服务能力，实现包括算力注册、算力纳管、算力交易、算力编排、算力调度及算力监管等环节的全流程闭环服务体系的商业化应用，为用户提供一键入云、跨域部署等便捷服务。算力算力网络网络实实践：践：中国电信在西部甘肃节点积极推进算力网络的试点工作，目前已完成“东数西渲”和域内跨资源池存储等场景的落地与验证和“东数西渲”场景聚焦三维重建业务。“东数西渲”目前实践的场景可覆盖六百多个商业综合体、多个景区，域内跨资源池存储场景目前已经纳管甘肃省内存储资源近 3000PB，提供用户直接订购存储服务并使用的能力，同时也提供统一对外接口，方便用户嵌入第三方平台业务使用。2.2.“息息壤壤”算力分发算力分发网络网络平平台台平平台概述：台概述：中国电信推出天翼云 4.0 算力分发网络平台“息壤”，实现 3.1 EFLOPS 全国算力的调度。平台构建的“算网大脑”中国算力调度发展研究蓝皮书ODCC-是把多个数据中心和网络统一调度起来，根据应用的特征和实际的业务量，自动分配最合适的数据中心，自动调配算力资源和网络资源，实现业务体验和资源成本最优化。平台可对边缘云、中心云、第三方资源等全网算力进行统一管理和调度，具备算力感知、算力注册、算力映射、算力建模等能力，通过 AI 模型从实时业务预测未来的业务分布情况，基于网络编排、算力编排优化资源分布，最终将业务牵引到最适合的节点，满足不同业务算力需求。平平台架构：台架构：平台提供多样化、差异化的算力产品形态，满足从中心到边缘的多样化算力场景，产品形态包括 ECK 专用算力集群、ECK 托管算力集群、Serverless 边缘分布式容器、边缘容器实例、边缘函数、批量计算等。通过结合自研的算力调度引擎，实现了对算力资源的统一管理、统一编排、智能调度和全局算力资源优化效果。应用应用情况：情况：在全国范围内实现每分钟数万次、每天上千万次的算力统筹和调度，满足各种领域对算力的极致需求。把东部需要进行的机器学习、数据推理、智能计算等 AI 训练和大数据推理的工作放到西部，自动配置和调度相应算力；把东部对时延不敏感的、不活跃的、需存档的海量数据，放在西部存储。通过“息壤”，实现“东数西算”、“东数西训”“东数西备”“东算西也算”“东部企业西部上云”云渲染、跨云调度、性能压测、混合云 AI 计算等多种应用场景。中国算力调度发展研究蓝皮书ODCC-（三三）中国中国移移动动混混合算力合算力感知感知调度调度 AIAI 平平台台平平台概述：台概述：平台整体由 1 个中心节点，N 个边缘节点构成，可实现异地多活的集群协同管理架构，提供高性能 AI 能力推理服务。引入国产化 AI 芯片，同时研发国产化 NPU 芯片模型迁移工具和混合调度框架，形成 GPU CPU NPU MLU 内存的混合资源调度。统一AI 平台构建以云原生为基础、兼容异构算力和多种管理模式的“云-边-端”协同架构。实时感知云边端算力资源使用情况，根据任务需求动态调度算力资源。平平台特征：台特征：支持 GPU 虚拟化和碎片优化技术，大幅提升模型训练过程中的 GPU 使用效率。通过对全域算力和服务的智能感知，实现 AI 模型在西部节点集中训练、AI 能力在全域动态部署的模式。通过 AI 算力感知调度，实现异构设备的管理和用量监控、异构资源池的划分、异构设备的调度。基于云原生技术自主研发 AI 任务资源调度器，提供国产芯片算力调度、多机多卡协同调度、显卡碎片调度优化、细粒度显存调度等多种调度方案。基于国产化全栈软硬件平台，通过半自动化模型迁移工具和图形界面开发工具，可迁移不同框架模型。应用应用情况：情况：在 AI 算力感知调度层面，深度应用于训练和推理两大类人工智能主流任务当中，实时监控任务使用情况，在出现任务所需算力不足时，动态调度可用算力以满足任务的计算需求。广东移动打造的自动化稽核应用，目前已推广至全国三十多个省，其中中国算力调度发展研究蓝皮书ODCC-八十多项能力分别部署至哈尔滨和汕头节点，实现跨云算力编排调度，赋能中西部省份就近使用 AI 能力。（四四）中中科曙光科曙光一体化算力交一体化算力交易易调度平调度平台台平平台概述：台概述：全国首个“算力可用、可控、可计量”的一体化算力交易调度平台、算力服务交易解决方案平台。目前已经完成黑龙江、京津冀、河南、山西、陕西、四川、甘肃、安徽、江苏、浙江、上海、广州等地自有智算中心的互联，实现一体化调度。平台建设目标是整合算力提供方的零散算力，利用一体化协同调度系统智慧匹配算力资源，为大规模任务提供无损智算算力，解决算力输出、转化、匹配、应用、交易等问题。算力服务体系算力服务体系：面向用户的弹性计算服务，为用户和企业提供专属的云上高性能物理服务器，实现高性能、高安全性、灵活性和弹性等特点。先进计算服务体系如图 8 所示，其为企业提供更多算力获取途径，实现公有云、私有云混合调度，充分挖掘企业算力边界。同时，可帮助企业实现计算服务能力的对外输出，增强生态合作，拓展多元化业务，提供完整的专有计算行业解决方案，包括人工智能、大数据和云计算服务，满足企业业务升级和技术创新需求。中国算力调度发展研究蓝皮书ODCC-图 8 先进计算服务体系应用场应用场景：景：包括弹性计算服务、混合调度、专有计算服务三大类。应用领域为：生命科学（基因测序、新药研制、基因拼接、蛋白结构、生物起源）、气象环境海洋（天气预报、环境监测、海洋监测、生态监测、减灾防灾）、物理化学材料（新材料、新能源、新产品、新装备、新方法、材料基因组）、工业仿真（航空、航天、汽车、船舶、精密仪器、制造业、能源装备）、其他（人工智能、卫星遥感、石油勘探、天文研究、地震模拟）。（五五）华华为为公共多样公共多样性算力服务平性算力服务平台台平平台概述：台概述：业界首个公共多样性算力服务平台，适用于人工智能计算中心、高性能计算中心和一体化大数据中心等多种场景，通过系统工程与架构创新，实现从能源效率 PUE 最佳到有效算力 CUE 最佳的跨越。华为集群计算解决方案具有算力场景多样、算力利用高效、算力使用便捷等特点。通过多样性计算框架，支持 AI、HPC、大数据等多种场景；通过创新的多样性算力融合调度，算力利用率中国算力调度发展研究蓝皮书ODCC-可以提升 50%；通过算力服务平台使算力获取速度从几周缩短到几分钟。北冥多样北冥多样性计算融合性计算融合架构：架构：是为多样性计算硬件及集群打造的完整软件栈，简化多样性计算环境下的开发和部署，充分释放算力性能，可帮助开发者在多样算力环境下，实现与单机相同的应用开发和部署体验，并获得远超单一算力的应用性能。算力网络调度的整体架构为跨地域、跨管理域的多层复杂调度。地城架构包括八大枢纽节点，组织内/区城内包括据组节点、一级集群、二级集群；组织间/区域间包括 HPC、AI、云上集群；组织间包括云厂商、运营商、科研组织。表 1 架构包含的调度器调度调度器器负负载载资源资源粒粒度度华华为为使使用用情况情况多集群调度器计算作业、数据传输多集群资源小时元调度器集群调度器作业集群内资源分钟小时多瑙调度器OS 调度器进程/线程节点内资源毫秒openEuler任务调度器任务分配给进程的资源微秒/秒OpenMP,JRE硬件调度器计算核心/算子任务加速器资源纳秒/微秒Ascend多瑙多瑙调度调度器器是是华华为自主为自主研研发的面向重算力场发的面向重算力场景景的的多多算力统一集算力统一集群群调度调度器器。基于前沿的架构设计理念进行设计开发，横向支持 HPC、AI、大数据多场景统一调度；纵向支持应用、算力、存储、网络、能耗深度感知和多维度智能调度，结合专家系统、实现跨域联动、提高系统效率；支持数据中心间资源协同，全局调度。当前，多瑙应用业务不仅包含半导体、制造、气象气候、高能物理、材料化学等行业应用，也包含超算等公共算力平台。中国算力调度发展研究蓝皮书ODCC-元元调度调度器器用于用于纳管纳管东部和西部东部和西部 AI 及及 HPC 集集群群，实现全，实现全局局调度。调度。原型功能是实现算力网络接入，将异构集群动态加入算力网络。同时实现资源管理、租户管理、数据管理和作业调度。元调度器开放集群适配器接口，与合作伙伴共同定义标准；开放调度策略，提供调度框架和标准调度算法，二次开发调度策略。元戎元戎是是华华为面向为面向多样多样性计算集性计算集群打造群打造的分布式的分布式并并行行开开发发框架框架。当前元戎已经实现了对数据并行和算法并行两类关键应用开发场景的支持，大幅提升了分布式应用开发的效率。未来，元戎将支持多种计算模式的组合，帮助开发者更加灵活地在多样性计算集群中开发分布式应用。（六）（六）浪潮浪潮 AIAI 计算系统计算系统及推及推理平理平台台平平台概述：台概述：AIStation 人工智能推理服务平台是业界首个智能计算中心计算力调度软件，AI 推理服务平台专为企业 AI 生产环境打造，可实现推理服务资源的敏捷分配，支持多源模型的统一调度，将模型部署从几天缩短为几分钟，将有效帮助企业轻松部署 AI 推理服务，这将极大地提高人工智能的交付和生产力。平台主要面向企业 AI 应用部署及在线服务管理场景，通过统一应用接口、算力弹性伸缩、A/B 测试、滚动发布、多模型加权评估等全栈 AI 能力，为企业提供可靠、易用、灵活的推理服务部署及计算资源管理，帮助用户 AI 业务快速上线，提高 AI 计算资源的利用效率，实现 AI 产业的快速落地。中国算力调度发展研究蓝皮书ODCC-算算网网融合平融合平台台技术技术：包括全栈网络、云网融合、超大规模、跨地域互联。网间互联方式包括云内租户网络互通、云外/云间租户业务互通、跨地域互通。平平台特征：台特征：一站式模型开发训练，缩短模型迭代周期。样本数据本地缓存，提升计算吞吐效率，可以大幅缩短数据缓存周期，提升模型开发和训练效率。多维 GPU 细粒度调度，充分利用计算资源。面向企业多租户多任务的场景，提供了优先级、紧急任务、轮询作业、空载监控等资源调度管理策略，保证计算资源被合理充分利用，有效的提高投资回报率。具有智能容错机制，保障平台服务与模型开发业务的平稳运行。具有丰富的功能，包括多框架模型统一管理、应用服务全周期管理、应用请求快速响应、资源性能监控。（七）（七）北鲲云北鲲云一一站站式式云云超算平超算平台台平平台概述：台概述：可以整合企业线下及云上计算资源，提供安全、弹性、自主的企业级 Cloud-HPC 方案。可支持多个地域，线上多个用户、线下多个地区；支持纯线下集群、云上集群、混合集群多种模式；统一接入：2 个 API 调用接入云上高性能计算服务。在全球拥有 25个地域节点，单集群最大可支持 100000 核心算力，上传下载 200M带宽。平平台特征：台特征：通过公有云大规模并行和数据处理的技术架构，并以图形芯片为算力底座，为运行不同类型软件的任务提供新型算力基础设施，构建高算力科研环境。为企业免去搭建私有集群的巨大开支和运维成本。采用按需计费的模式，根据硬件资源（GPU/CPU 类中国算力调度发展研究蓝皮书ODCC-型、节点卡数、内存容量）、使用时长计费。支持多种 HPC 集群模式。私有模式最大化提高本地资源利用率；云上模式快速利用云上无限资源启动 Cloud-HPC 集群，灵活、经济的高性能计算方案；混合模式在本地算力资源不能满足自身需求时，自动溢出到云上，提高企业研发效率。应用应用情况：情况：在生命科学领域，提供生物信息及计算化学领域整体解决方案，搭建从基因测序、靶标发现、虚拟筛选到分子动力等全流程的研发环境；在人工智能领域，搭建一体化的数据、算法、算力服务平台，提供从数据集创建，预处理和标注，模型训练，模型超参调优，模型部署等全流程的开发环境；在科研领域，搭建高性能计算中心，管理线下计算资源、线上弹性溢出上云；在 CAE/CFD领域，集成工业制造企业所需的设计与仿真工具，可按需提供工程机械、汽车工业、能源化工、建筑土木等领域的解决方案。（八）（八）趋动趋动云云 AIAI 平平台台平平台概述：台概述：一款一站式全流程人工智能平台。基于领先的 GPU虚拟化技术，连接全球算力，提供高质量的 AI 应用开发体验，大幅降低模型训练成本，提供更灵活的算力选择，通过内置数十种算力规格，更准确的匹配客户的算力需求，采用按需使用模型，使成本最低，获得高性能的计算服务。具有 AI 模型在线开发、模型训练、AI 资产管理、排队管理等功能。功功能能架构：架构：在功能上平台共分为 3 层。基础层包括基础的软硬件资源，这些资源能够为平台本身及其业务提供存在的场所及运行的中国算力调度发展研究蓝皮书ODCC-基础。比如物理机、GPU 卡、存储、网卡等硬件资源和 K8s、Docker、OrionX 等软件资源。管理层指平台的运维控制台，运维控制台可整体管理平台所有资源、业务，以及用户空间等。用户层指AI 工作台，算法工程师可在该工作台上进行 AI 应用的研发。应用应用情况：情况：在教育领域，主要包括教学需求、教研需求和信息中心需求。在教学中优化教学成本，提供智能环境，少数 GPU 卡即可支持大量学生的 AI 实训课程。在教研中针对大规模科研场景，实现GPU 跨机聚合，调度更多算力支持科研加速。在信息中心方面高效利用 GPU，管理集群任务，同时满足教学、教研场景。虚拟 GPU 资源按需分配高效利用与管理。在金融和自动驾驶领域，引入软件定义 GPU 概念，将 OrionX 软件部署在多台不同类型的 GPU 服务器上，通过网络互联，构建了一个统一的 GPU 资源池化层，实现了 GPU 资源的统一调度、灵活分配、弹性伸缩等云化能力，为上层应用提供GPU 算力资源。四、四、异构异构计算调度系统分析计算调度系统分析（一一）典典型型异构异构计算平计算平台台1.1.阿里云震旦异构阿里云震旦异构计算平计算平台台平平台概述：台概述：阿里云震旦异构计算平台是基于异构计算硬件的编译优化平台，是一个统一的、云-边-端一体的异构计算加速平台，包含了 HALO、SinianML 框架、自动反馈优化系统、异构计算资源池系统等。提出业界首个面向深度学习的异构硬件统一接口规范中国算力调度发展研究蓝皮书ODCC-ODLA(Open Deep Learning API)，通过归一化的硬件架构抽象，实现上层应用在异构计算资源上的平滑迁移。平平台功台功能能：通过软硬一体的异构编译技术、架构感知和优化技术、全栈式自动调优等自主创新技术，实现云、边、端全场景的异构计算加速和优化。通过构建异构资源池和深度学习模型，提升软硬协同和资源适配能力，形成资源优化机制，保证异构算力重组优化，同时以模型部署为核心，通过自研的高性能流式业务执行引擎，实现 AI 业务高效的开发和部署。通过资源池化实现异构资源利用率的最大化和各种异构资源的灵活配比，此外，平台还适配 GPU、ASIC等多种异构 AI 芯片。应用应用情况：情况：震旦异构计算平台已经在阿里巴巴自研 AliFPGA 硬件加速器、阿里巴巴搜索 RTP 系统应用。边缘计算（天猫音箱、菜鸟驿站、盒马门店和大润发门店智能 POS 机）等业务场景中达到百万规模应用。震旦软硬协同编译优化成功应用、并支撑了“蚂蚁链一体机”软硬件一体机。2.2.百百度度百舸百舸 AIAI 异构异构计算平计算平台台平平台概述：台概述：包含 AI 计算、AI 存储、AI 加速、AI 容器四大核心套件，具有高性能、高弹性、高速互联等特性。为 AI 场景提供软硬一体解决方案，深度融合推荐、无人驾驶、生命科学、NLP 等场景。平平台架构：台架构：包括了 AI 计算、AI 存储、AI 加速、AI 容器、业务场景几个部分。AI 计算部分百度太行提供了基于自研 GPU 硬件架构X-MAN 的高性能实例，充分满足 AI 单机训练、分布式集群训练、AI中国算力调度发展研究蓝皮书ODCC-推理部署等对算、存、传的性能诉求。百度沧海是百度智能云的存储产品体系，基于 AI 存储架构，从数据上云、数据存储、数据处理和数据加速为计算提供全链条的支撑。存训推一体化加速，通过对存储访问、模型训练和推理的加速进一步提速 AI 任务。AI 容器提供 GPU 显 存 和 算 力 的 共 享 与 隔 离，集 成 PaddlePaddle、TensorFlow、Pytorch 等主流深度学习框架，支持 AI 任务编排、管理等。平台架构如图 9。图 9 百舸平台架构3.3.FPGAFPGA 异构异构计算平计算平台台平平台概述：台概述：FPGA 异构计算平台是面向大数据处理、包含多个计算节点的分布式系统。该平台功能包括了软硬件的划分和协同、多机系统管理和 FPGA 板卡的故障管理与容错。FPGA 板卡采用自动化的平台映射技术，实现了板卡设计硬件计算逻辑与 OpenCL 程序的协同开发。通过设置全局资源管理器来负责整个系统的资源管理与分中国算力调度发展研究蓝皮书ODCC-配。FPGA 板卡让系统能够实时检测和纠正单比特错误，并检测多比特错误，防止系统使用破损数据，从而提高了内存访问的可靠性。平平台架构：台架构：采用 CPU FPGA 的异构模式，在提高 CPU 计算能力的同时，降低了服务器功耗。按照 CPU 模块和 FPGA 加速模块耦合程度的不同可将其分为 4 类：作为外部独立的计算模块、作为共享内存的计算模块、作为协处理器、FPGA 集成处理器架构。图 10 FPGA 平台架构应用应用情况：情况：浪潮与第三方合作，利用 FPGA 异构计算平台开展了深度学习 DNN 语音识别算法加速研究。（二二）异构异构 AIAI 算力算力操操作平作平台台1.1.操操作平作平台定义台定义异构异构 AI 算力算力操操作平作平台台是一个面向是一个面向多元多元人工智能算力的人工智能算力的异构异构融融合合适配适配平平台台。能够实现硬件性能与计算要求有效对接、异构算力与用户需求有效适配、异构算力在节点间灵活调度、多元算力智能运营与开放共享,将各类异构算力协同处理来发挥最大的计算效力,为多中国算力调度发展研究蓝皮书ODCC-样化 AI 应用场景提供算力支撑。由硬件支撑平台、异构 AI 算力适配平台、异构 AI 算力调度平台、智能运营开放平台四个部分组成。图 11 异构 AI 算力操作平台2.2.技术技术架构架构资源资源重重构构技术方技术方案：案：按照计算、存储、网络等资源类别的差异，整合硬件资源，形成同类资源池，实现不同设备间资源按需重组。通过硬件重构实现资源池化，CPU 与 GPU、FPGA、xPU 等各种加速器将更加紧密结合，利用全互联的新型超高速内外部互连技术，实现异构计算芯片的融合；与此同时，计算资源可以根据业务场景实现灵活调度；NVMe，SSD、HDD 等异构存储介质则通过高速互连形成存储资源。在软件层面，推进硬件资源自适应重构，实现资源动态调整、灵活组合和智能分配，响应多应用、多场景需求。软硬件软硬件融合融合架构：架构：软硬件融合架构支持海量资源处理要求。平台能够满足 AI 训练中 GPU 或 CPU 计算集群的高带宽、低延时的并发访问要求，适应巨量数据增长，缩短 AI 模型生成时间。另一方面，软硬件融合架构基于软件定义计算、软件定义存储、软件定义网络，发挥资源管理和调度系统的应用感知能力，建立起智能化融合架构，在分离控制与计算的同时，融合计算与存储，满足多种应用场景。中国算力调度发展研究蓝皮书ODCC-硬件支撑硬件支撑平平台：台：基于融合架构，实现 CPU、GPU、NPU、FPGA、ASIC 等多种硬件资源的虚拟化和池化。建立“CPU GPU”、“CPU FPGA”、“CPU ASIC(TPU、NPU、VPU、BPU)”等 多 种“CPU AI 加速芯片”架构，释放 CPU 与 AI 加速芯片优势，应对交互响应和高并行计算。异构异构 AI 算力算力适配适配平平台：台：连接上层算法应用与底层异构算力设备、驱动异构软硬件算力工作的核心平台，提供覆盖 AI 算力全流程的适配服务，使用户能够将应用从原平台迁移到异构 AI 算力适配平台。平台包括应用框架、开发套件、驱动、固件 4 个部分。异构异构 AI 算力调度平算力调度平台：台：实现异构算力在计算节点间的灵活调度，形成标准化和系统化设计方案，提供 AI 模型开发部署和运行推理。对 AI 算力进行细粒度切分和调度，赋能 AI 训练，增强各类 AI 模型兼容适配能力。平台包括全栈训练、资源管理、监控告警。智能运智能运营开放营开放平平台：台：智能运营开放平台提供软硬一体的融合解决方案，面向全行业，建立开放、共享、智能的异构 AI 算力支撑体系和开发环境，实现对异构 AI 算力智能运营、安全可靠和开放共享。（三三）异构异构计算调度技术计算调度技术1.1.分布式分布式异构异构计算调度技术计算调度技术技术现技术现状：状：目前，大数据处理模型大致可分为三类，分别为批处理系统、流处理系统和针对机器学习的任务并行系统。批处理系统最具代表性的是 MapReduce、Spark 等,流处理系统则有 Flink、中国算力调度发展研究蓝皮书ODCC-Storm 等,而针对机器学习的大数据处理系统还处于发展阶段。分布式的处理有 Ray 系统。Ray 系统系统概述：概述：Ray 是针对机器学习的分布式计算引擎，Ray 框架专门为机器学习与强化学习设计的高性能分布式执行框架，使用了分布式计算的抽象方式的架构，具有比 Spark 更优异的计算性能。Ray 系统系统架构：架构：Ray 集群有且仅有一个头节点(head node)和若干个工作节点(worker nodes)。全局控制存储位于头节点,包含各种表数据来存储全局状态。Ray 采用分布式调度,在集群中的任意节点都存在本地调度器(scheduler)，Ray 依赖于每个节点的本地调度器。更贴合当下机器学习对低延迟、高吞吐的要求。在整个 Ray 集群中，任意两个节点都可进行通信。Ray 调度过程调度过程：任务调度和扩容的资源共分为 3 类：整体资源、可用资源和负载资源。Ray 的任务调度过程中，用户在本节点提交任务后,由调度器优先本地调度执行，若不满足资源要求，则提交到其他远程节点调度,称为溢出调度(spillover)。溢出调度是迭代的，直到任务找到资源满足的节点为止。2.2.面向面向 FaaSFaaS 的算的算网异构网异构算力调度技术算力调度技术技术现技术现状：状：Serverless 是未来云原生技术发展的演进方向，而FaaS（函数即服务）和 BaaS（后端即服务）是两个主流方向，其中FaaS 意在无须自行管理服务器系统或自身的服务器应用程序，即可直接运行后端代码。随着云计算服务能力开放和函数能力开放，通中国算力调度发展研究蓝皮书ODCC-过函数服务的形式对外提供中台能力逐渐成为主流，在现有的云原生能力开放架构中 FaaS 得到广泛应用。技术技术介绍：介绍：Serverless 和异构算力进行结合。通过 Serverless进一步屏蔽异构算力的差异性，从而更好的为不同算力之间的调度提供无差别的服务函数接口来实现不同算力的协同。通过 FaaS 平台来实现云计算、边缘计算、异构设备、高性能计算和公/私有云等能力开放，并且通过 FDN（面向异构算力的函数协同架构）网络来实现函数声明和调度。开发者和用户直接在 FDN 进行应用开发和资源请求，降低使用者门槛。技术技术架构架构:面向 FaaS 的算网异构资源调度技术结合了最新的云原生 Serverless 模式，提出了整体的技术架构和异构算力调度机制，并且在此基础上进一步提出了整体平台功能架构，以期解决在目前算力网络异构算网融合条件下通过 FaaS 对上层应用进一步实现算力网络能力开放的问题。五、五、总总结结算力调度通过算力调度通过连接连接算力基础设施的各算力基础设施的各种异构种异构算力算力资源资源，采采用高效用高效的算力调度算的算力调度算法法，建设算力，建设算力资源资源调度与服务平调度与服务平台台，向不同领域用，向不同领域用户户提供所需的算力服务。提供所需的算力服务。其中算力调度平台作为算力资源供给和需求的中枢，在算力调度的过程中扮演重要的角色。在算力资源接入、算力平台架构、集群调度器、算力调度算法等方面，平台技术发展路线和应用场景呈现多样性。中国算力调度发展研究蓝皮书ODCC-算力调度形式涵盖了跨区域算力调度、闲置算力调度、智算调度、超算调度、边缘计算调度等多种类型。三大运营商基于强大的骨干网络和广大的政企研客户，构建算力调度平台时具有显著优势，在算网融合、三算一体，统一调度、智算调度等方面取得实质进展。各厂商基于自身的业务优势，也纷纷布局发展算力调度平台，重点在企业 AI 算力需求、企业级 Cloud-HPC、低成本算力使用等方面部署应用。同时异构算力调度技术受到越来越高的重视，并取得重点突破，如分布式异构计算调度和面向 FaaS 的算网异构算力调度。中国信通院在异构 AI 算力操作平台方面展开持续深入的研究，并取得了丰硕成果。未来，需要算力调度技术在未来，需要算力调度技术在异构异构算力算力纳管纳管、算力、算力感知感知和度量、和度量、跨跨层层跨域智能调度、一体化跨域智能调度、一体化协协同服务、数据同服务、数据安安全全等等方面方面进进一一步步创新创新和和突破突破。随着CPU、GPU、FPGA、ASIC等芯片的融合应用，算力呈现出异构多样化，需要进行统一纳管。通过量化异构算力资源和多样化业务需求，建立统一的描述语言，建立算力资源度量和计费标准。通过不同的调度引擎和调度算法，保证算力使用的便捷性，支持资源自动化和智能化分配，实现跨层跨域的智能调度。同时在算力调度和使用过程中，会产生海量数据，需要关注数据安全。根据业务的需求，对网络和算力进行管理和监测，满足绿色、共享、智能、可信的算力服务，更好地支撑算力的应用。

0人已浏览 2023-12-19 41页 5星级

点击查看更多字节跳动：2023年CloudWeGo 技术白皮书- 字节跳动云原生微服务架构原理与开源实践（70页）.pdf精彩内容。

0人已浏览 2023-12-09 70页 5星级

B400G以太网助力智算中心光互联程伟强中国移动研究院-基础网络技术研究所2算力成为数字经济时代的核心竞争力AI大模型带动算力成为数字经济时代的核心竞争力。到2025年，我国算力规模将超过300 EFLOPS，智能算力占比达到35%；算力基础设施将成为推动我国经济转型升级和培育新动能的重要力量2022年中国移动全球合作伙伴大会发布新一代智算中心网络技术白皮书2023年5月2022年12月2023年8月2023年中国算力（基础设施）大会发布中国移动NICC新型智算中心技术体系白皮书2023云网智联大会发布面向AI大模型的智算中心网络演进白皮书智算中心将成为支撑和引领数字经济发展的关键信息基础设施，将有效促进AI产业化、产业AI化的进程国家发改委：全国一体化大数据中心协同创新体系算力枢纽实施方案2021年5月2022年7月工信部：加速推进高端芯片、新型数据中心等领域研发突破2022年1月国家发改委：我国将布局八大算力网络国家枢纽节点 加快数字经济发展2023年5月中央网信办：以算力、赋能、产业发展互动 走出数字经济特色化发展道路2023年10月工信部等六部门联合印发算力基础设施高质量发展行动计划3单个流量：数量多、带宽小、异步累积流量：抖动幅度较小，具有随机性单个流量：数量少、带宽大、同步累积流量：波峰、波谷效应明显，具有周期性单个流量累积流量单个流量累积流量传统DC流量模型智算中心大模型（All-to-all）流量模型GPU停工等待其他GPU完成工作传统DC与智算中心流量模型区别4面向大模型训练，网络成为AI算力瓶颈AI大模型以GPU集群分布式训练为基础，带来大量节点间通信消耗，网络成为AI算力“瓶颈”当前业界主流智算中心网络技术被国外厂商垄断，网络芯片存在代际差距，网络可能成为我国AI发展的“新卡点”集群有效算力GPU单卡算力*总卡数*线性加速比*有效运行时网络可用性决定GPU集群稳定性2%的丢包就会使RDMA吞吐率下降为0网络设备能力决定GPU集群组网规模芯片容量提升2倍，组网规模提高4倍网络性能决定GPU集群算力加速比GPU集群性能 单GPU性能*N随着GPU单卡算力受限，以网强算成为提升大模型训练效率的关键，探索以太网的新调度机制、新接口速率和新安全方案，提升智算中心网络性能和整体算力水平5目录以太网新调度机制GSE以太网新接口速率B400GE以太网新安全方案PHYSec6GSE技术体系-核心理念中国移动提出全调度以太网（GSE）技术架构，最大限度兼容以太网生态，创新基于报文容器（PKTC）的转发及调度机制，构建无阻塞、高带宽、低时延的新型智算中心网络，形成标准开放的技术体系，助力AI产业发展从“局部”决策到“全局”调度从“流”分发到“报文”分发从盲发 被动控制到感知 主动控制将业务流拆分到不同“报文容器”转发，提供逐“报文容器”负载均衡机制，提升带宽利用率从被动拥塞控制，到基于“授权请求和响应机制”的主动流控，最大限度避免网络拥塞产生全局视野的转发调度机制，实现集中式管理运维、分布式控制转发，提高网络可用性当前：逐流负载，链路利用率低、发生拥塞被动降速未来：逐报文容器转发，链路负载均衡，全局调度，避免拥塞创新以太网转发机制，实现三大核心机制转变源leafSpineSpineSpine目的leaf2213213拥塞拥塞21321321丢包丢包7报文容器以太报文报文容器1以太报文报文1报文2报文1长度报文2长度GSE HeaderGSE Header报文容器是区别于CELL转发的一种核心转发机制，该机制下以太网报文根据最终设备或者设备出端口被逻辑分配并组装成”逻辑等长”的虚拟报文容器，并以该”容器”为最小单元在交换网络中传输源节点根据报文容器长度以及已经占用的字节数为到达该节点的报文分配相应的容器ID，并记录其归属的报文容器编号及在该容器占用的字节数Packet基于确定长度的容器转发提升多链路均衡性早期 链路速率低 长短包转发差异性大切CellCell1Cell2Cell3报文容器将来链路速率高 总转发带宽增大 Cell相应增大组容器Packet1Packet28DGSQ 调度在输入端口将发送到不同端口（或者优先级）的数据包虚拟成不同的队列，并且彼此互不影响，解决HOL从Send-based到Receive-based，避免网络入向流量大于网络容量，从源头避免网络拥塞GSE报文信令请求获取信道资源INOUT无阻塞低时延 无损高带宽vs逐流负载均衡 高时延 甚至 丢包容器负载均衡 长尾时延低，网络利用率高低时延1000流量负载（%）报文时延非均匀到达模型下时延vs负载9负载均衡和重排序负载均衡方式 轮询 随机 基于拥塞感知每个转发节点根据自身负载情况对PKTC进行负载均衡，且同PKTC内的报文转发路径相同，高精度负载均衡方式，消除网络微突发，获得转发低延迟目的节点依照PKTC为单位进行容器间解乱序，同PKTC内报文严格保序容器间排序 大大降低排序压力.GSFGSFGSPGSPGSP.容器1容器210目录以太网新调度机制GSE以太网新接口速率B400GE以太网新安全方案PHYSec11IEEE802.3 B400GE标准目标演进IEEE P802.3df&dj 800GE和1.6TE规范目标 以太速率 信号速率电通道50m MMF100m MMF 500m SMF2km SMF10km SMF40km SMFAUIBPCu800Gb/s100Gb/s800GAUI-8800GBASE-KR8800GBASE-CR88 pairs800GE-VR88 pairs800GE-SR88 pairs800GE-DR88 pairs800GE-DR8-2200Gb/s800GAUI-4800GBASE-KR4800GBASE-CR44 pairs800GE-DR44 pairs 800GE-DR4-2 4 800GE-FR44 800GBASE-LR4800Gb/s1 pair800GE-LR11 pair800GE-ER11.6Tb/s100Gb/s1.6TAUI-16200Gb/s1.6TAUI-81.6TBASE-KR81.6TBASE-CR81.6TBASE-DR81.6TBASE-DR8-2802.3df802.3dj802.3dj智算中心内光互联智算中心间光互联潜在继续分化出子项目200G/lane 光 电BaselineD1.0D2.0D3.0800GE(4200G)1.6TbE(8x200G)802.3dj2022202420232026 20252021D1.0D2.0D3.0100G/lane光 电800GE(8x100G)802.3df200G/lane电800G单波相干D1.0?/D2.0?800GE(1800G)1.6TE(2800G)?800GE(4200G)1.6TbE(8x200G)B400GE标准演进时间线12B400G以太网技术标准化进展 802.3df：单通道100Gb/s的800G以太网标准，目前已完成Task Force Review形成D3.1版本草案“IEEE P802.3df/D3.1,14 Nov.2023”，正在进行标准协会(SA)范围审查 802.3dj：单通道200Gb/s FEC采用低复杂度Hamming(128,120)内码级联RS(544,514)外码；PMA逻辑层方案已确定，光层Baseline目前还未确定，仍处于技术讨论阶段，需要更长的时间完成方案收敛 802.3dj：面向10km和40km场景的单波800Gbps相干标准进展缓慢，800GE LR1已确定采用KP4 BCH的FEC方案，但O波动和C波段之争逐渐白热化；800G ER1采用相干已获得业界共识，FEC和光层PMD方案尚未明确800Gbps以太网标准1.6Tbps以太网标准 802.3dj：1.6TE PCS/FEC方案已确定，电接口形态包括16通道100Gbps(16AUI-16)和8通道200Gbps(1.6TAUI-8)；1.6T 500m/2km PMD子层方案尚未明确，2km采用相干技术可行性更高 1.6Tbps LPO和CPO等技术已出现商用产品形态，在智算中心场景也将具有广泛的应用潜力13推动800G 10km目标立项，确立相干技术路线中国移动积极参与并推动IEEE802.3df&dj工作组完成800G 10km目标立项，完成800G 10km相干技术路线确立，提交10余篇标准文稿需求文稿Application Requirement for Beyond 400GE from Telecom Operators Perspective 分析文稿提出B400GE需求，引领技术方向Towards consensus on a coherent based 800G 10/40 km specification800G 10km方案对比分析，凸显相干方案优势Consideration on 800Gb/s coherent solutions for 10km800G-LR1/ER1的GMP bypass方案分析标准文稿提出800G 10/40km发射和接收标准规范建议提出基于oFEC的800G 10km/40km规范建议提出800G-LR1/ER1与800ZR一致性规范建议标准文稿分析文稿Considerations on GMP bypass for 800G-LR1/ER1Update to oFEC-based single lambda baseline for 10km and 40km objectives标准文稿Alignment of 800GBASE-LR1 and 800GBASE-ER1with OIF800ZR Implementations-a baseline proposal14800GE(8100G)500m/2km高速接口测试本次测试800GE短距光模块性能整体较为稳定，模块功耗在15w左右和工作温度在5060范围仍有待优化空间；800GE光模块与路由器设备和测试仪适配性能良好，业界支持800GE设备厂家还较为单一测试拓扑：可插拔光模块插入测试仪表进行环回测试测试内容：非成帧误码率、FEC功能、发射机频率偏移、收发传输时延、通道时延偏差、固件功能等光模块性能测试800GE光模块性能测试800GE光模块与路由器设备适配测试模块类型A厂商B厂商500m500m2km500m500m非成帧误码率通道11.0e-096.5e-103.3e-091.1e-073.3e-06通道23.9e-101.6e-103.8e-082.3e-074.9e-06通道31.4e-109.6e-101.7e-084.3e-081.6e-06通道46.9e-118.4e-112.5e-084.9e-083.8e-06通道52.7e-092.4e-092.3e-084.8e-082.3e-06通道66.5e-106.0e-103.4e-086.1e-081.7e-06通道72.0e-084.5e-093.6e-084.6e-093.0e-07通道81.1e-101.0e-093.4e-086.9e-081.8e-06模块时延传输时延 51ns52ns43ns92ns90ns时延抖动3ns 3ns 4ns 4ns3ns测试拓扑：路由器设备800G接口对接测试仪表进行互通测试测试内容：包括流量转发功能、业务功能等设备能力测试注：802.3df规定的非成帧误码率BER 2.4e415目录以太网新调度机制GSE以太网新接口速率B400GE以太网新安全方案PHYSec16PHYSec：物理层加密，更低时延、更低开销、协议透明6NowL2物理层L3L4L5TimeTLS/DTLSMACSecPHYSecsoftwareSoftware hardwareHardwareHardwareMACIPTCPMACIPMACMACCipher textCipher textCipher textCipher textRDMASecHardware2022MACUDPCipher textIPIPSec？智算中心基础设施承载大量数据传输处理，安全诉求极高；RDMASec、MACSec等安全方案在加解密带宽开销、时延、硬件支持等方面存在性能瓶颈，暴露的帧头部信息仍存在安全漏洞PacketMACPCSPMAPMAPMDxAUIPHYSec光模块加密接口芯片加密PacketMACPCSPMAPMAPMDxAUIPHYSecor探索新层次：将传统密码学思想应用到以太网物理层PHYSec，解决现有技术方案的安全漏洞与性能瓶颈，具有极低开销、时延以及低功耗和成本等优势17L1.5层PHYSec：基于“64B/66B码块”的PHY芯片实现MAC(Preamble Padding FCS)RSAMDeskewAM LockPHY芯片RS-FECSymboldistributionReorderPMAEn/Decode(64B/66B)256B/257B(De)ScrambleDistribution/InterleaveMAC(Preamble Padding FCS)RSAMDeskewAM LockPHY芯片RS-FECSymboldistributionReorderPMAEn/Decode(64B/66B)256B/257B(De)ScrambleDistribution/InterleavePMDPMA光模块SerdesPMDPMADencryptionSerdes光模块Encryption技术优势：安全功能硬化，高吞量 安全加密能力不占用设备CPU资源，安全能力卸载 实现底层光通道不感知(OTN/SPN)的端到端数据加密加密后的64B/66B400GE400GE400GE400G OTN64B/66BGMPOTUOTUGMP64B/66BL1.5-PHYSec400GEL1.5-PHYSec18L1层PHYSec：基于“比特流”的光模块实现MAC(Preamble Padding FCS)RSAMDeskewAM LockPHY芯片RS-FECSymboldistributionReorderPMAEn/Decode(64B/66B)256B/257B(De)ScrambleDistribution/InterleaveMAC(Preamble Padding FCS)RSAMDeskewAM LockPHY芯片RS-FECSymboldistributionReorderPMAEn/Decode(64B/66B)256B/257B(De)ScrambleDistribution/InterleavePMDPMAAM LockEncryption光模块SerdesPMDPMAAM LockDencryptionSerdes光模块技术优势：安全功能可插拔、硬化，高吞量 无需升级设备硬件，即可具备安全加密能力 安全加密能力不占用主设备资源，安全能力卸载 实现端口-端口的链路级数据加解密AMAMAMAMVLane1VLane2VLane3VLane4400GEL1-PHYSecL1-PHYSec400GE19总结与展望 AI/ML带来海量算力需求持续增长，新型智算中心网络涉及技术领域多，国内外尚处在技术研究阶段，创新机遇大，不确定性也大 GSE最大限度兼容以太网生态，凝聚产业力量，形成自主可控、标准开放的技术体系，成为产业共识 B400G高速接口标准和商用化进程相对稳定，须重点关注B400G相干技术实现复杂度，谨慎评估功耗成本等因素 以太网物理层高安全能力有待进一步增强，PHYSec将成为新的安全解决方案 业界共同推动B400G以太网技术成熟和商用，助力智算中心快速发展

0人已浏览 2023-12-08 19页 5星级

y 计算机行业计算机行业 报告日期：报告日期：20232023 年年 1212 月月 0 04 4 日日 摘要：摘要：国产大模型发展方兴未艾。大模型规模、数据量和数量的全面国产大模型发展方兴未艾。大.

0人已浏览 2023-12-07 24页 5星级

OpenCOCA 白皮书白皮书(2023)主编单位主编单位中国移动云能力中心参编单位参编单位（排名不分先后排名不分先后）云计算开源产业联盟、深圳云豹智能有限公司、上海燧原科技有限公司、上海云脉芯联科技有限公司、昆仑芯（北京）科技有限公司、锐捷网络股份有限公司、中科驭数（北京）科技有限公司、上海壁仞科技股份有限公司、中兴通讯股份有限公司、华为技术有限公司、新华三技术有限公司、珠海星云智联科技有限公司、瀚博半导体（上海）有限公司目录1.算力基础设施发展现状与挑战.11.1 发展现状与趋势.11.2 应对机遇与挑战.32.COCA 软硬一体片上计算架构打造国家级自主可控算力基础设施.52.1 COCA-DPU 重构计算架构.62.2 COCA-GPU 融通算力生态.122.3 COCA-HPN 提供海量 AI 算力.153.从 COCA 走向 OpenCOCA，业内首个开放式的软硬一体片上计算平台.213.1 能力共享，激发行业活力.213.2 行业共治，规范行业标准.223.3 协作共赢，创造行业价值.234.展望与倡议.234.1 布局开放式智算生态，带动国内智算产业成熟发展.234.2 共建产业联盟，自主掌握云计算技术标准.234.3 联创高精尖技术，引领云计算市场下一个黄金十年.24缩略语列表.25参考文献.28OpenCOCA 白皮书(2023)11.算力基础设施发展现状与挑战算力基础设施发展现状与挑战1.1 发展现状与趋势发展现状与趋势当前，以云计算、人工智能、大数据为代表的新一代信息技术蓬勃发展，传统产业与新兴技术加速融合，推动数字经济的快速增长。算力基础设施作为各行业信息系统运行所依赖的核心能力，在经济社会运行中不可或缺。近年来，我国对算力基础设施的重视程度不断提升，国家发展和改革委员会在 2020 年 4 月明确定义新基建，即基于新一代信息技术演化而成的基础设施，其中包括以数据中心和智能计算中心为代表的算力基础设施。在狭义上算力基础设施指以算力资源为主体的基础设施，自下而上包括底层设施、算力资源、管理平台和应用服务等，覆盖超算中心、智算中心等多样化算力体系。在广义上算力基础设施指一体化 ICT 服务，包含融算力生产、算力传输和 IT 能力服务。作为新基建的核心组成部分，算力基础设施在我国数字经济发展过程中扮演着重大支撑角色。一方面，通过互联网、大数据、人工智能等新兴技术的深度应用，传统基础设施转型升级形成融合基础设施；另一方面，通过对科学研究、技术开发和产品研制的持续支持，算力基础设施驱动技术革新和产业应用创新。超算智算成为算力规模增长主驱动超算智算成为算力规模增长主驱动算力作为一种新型生产力，主要包含信息计算力、数据存储力等要素，通过算力基础设施向社会提供服务。在数据存储力方面，根据 IDC 数据统计，最近 5 年全球数据每年以两位数速度持续快速增长。同时，国家互联网信息办公室发布的数据显示，我国数据资源规模快速增长，2022 年我国数据产量达 8.1ZB，同比增长 22.7%，全球占比达10.5%，位居世界第二，预计到 2025 年数据总量将跃居世界首位，占比达到全球总量的三分之一。在信息计算力方面，随着云计算服务的日趋成熟，算力发展呈现单要素向多要素融合转变。随着“十四五”规划持续推进，截止到 2022 年底，我国算力总规模达到 180 EFLOPS，排名全球第二，其中，通用算力规模为 137 EFLOPS，智能算力规模为 41 EFLOPS，超算算力规模为 2 EFLOPS，近五年来，我国整体算OpenCOCA 白皮书(2023)2力规模保持近 30%的增长速度。随着算力规模持续扩大，智算和超算逐渐成为新的算力增长引擎。智算方面，根据 ICPA 智算联盟统计，截至 2022 年底，全国已投运的人工智能计算中心有20 余家，在建的也超过 20 家。地市企业依托智能计算中心的算力服务，结合本地产业特色，加快人工智能应用创新，聚合人工智能新业态。例如武汉人工智能计算中心陆续孵化出紫东太初、武汉 LuoJia 等大模型1。超算方面，2023 年 6月发布的最新全球超级计算机 TOP500 榜单中，中国以 134 套上榜数量位居全球第二，占 26.8%。应用创新促进数据中心融合升级应用创新促进数据中心融合升级近年来随着HPC(High Performance Computing)、人工智能和大数据等应用的蓬勃发展，原来的传统数据中心已无法满足新型应用的承载需要，新型应用以集群式服务为载体，具有超大规模并行计算的特征，往往依赖数十TB的高质量数据集、数十万CPU核和上万块GPU，以及节点间高效率的集合通讯，需要算力、算法、数据多要素的融通协同，迫使传统数据中心向新型数据中心演变。新型数据中心不仅是某些设备的集合，而且是包含计算、存储、通信能力以及环境、安全等配套能力，可通过内部设备传递、处理、展示数据信息，最终服务于客户的数据服务系统，具备高技术、高算力、高能效、高安全的特点，具体表现在算力规模与密度的逐步提高、“绿色低碳”新技术应用逐步扩大、本地或跨域智慧化运维管理逐步升级、信息技术与运营技术的一体化安全得到保障。从我国总体算力供需格局来看，东西部算力供需失衡，东部地区算力应用需求大且资源紧张，而西部地区算力资源相对宽裕，通过国家“东数西算”战略构建布局合理的新型数据中心将成为推动未来社会数字化发展、促进社会产业化变革乃至重构全球竞争格局的关键举措。随着人工智能和物联网技术的发展，新型数据中心算力整体需求结构逐渐发生变化，基础算力所占比重逐步降低，智能算力与超算算力比重正快步攀升。（1）智能计算中心智能计算中心是指基于最新人工智能理论，采用领先的人工智能计算架构，提供人工智能应用所需算力服务、数据服务和算法服务的公共算力新型基础设施。智能算力主要是基于GPU(Graphics Processing Unit)、FPGA(Field ProgrammableGate Array)、ASIC(Application Specific Integrated Circuit)或其他加速器支撑的高OpenCOCA 白皮书(2023)3并行、高密集计算能力的异构算力。近年新推出的大语言模型(LLM，LargeLanguage Module)所使用的数据量和参数规模呈现“指数级”增长，带来智能算力需求的爆炸式增加。智能计算中心主要应用于多模态数据挖掘、智能化业务高性能计算、海量数据分布式存储调度、人工智能模型开发、模型训练和推理服务等场景，所产生的大规模生产算力将为智慧医疗、智慧城市、智慧交通等领域的应用提供基础支撑。（2）超级计算中心超级计算中心是指配备高性能计算设备和软件，拥有超级数据存储和处理能力，且能够提供超级计算服务的综合产业化基地。超级计算指利用超级计算机的集中式计算资源来处理极端复杂和数据密集型的问题。超算芯片以CPU为主，可含部分GPU加速器，主要提供双精度浮点数(64 位)计算能力，其中每秒千万亿次的运算被称为“P级”超算，每秒百亿亿次的运算被称为“E级”超算。近年来，我国超算中心发展迅猛，目前已拥有 14 所国家级超级计算中心。超算中心主要运用于尖端科研、国防军工、产业升级和重大社会问题等大科学、大工程、大系统中，是国家科研实力的体现，也是国家科技发展水平和综合国力的重要标志。超算中心所提供的算力将广泛应用于石油气勘探、生物医药、海洋工程、气象预测和智慧城市等众多领域，深刻影响着国家产业和人民生活。新算力和新技术相互促进协同发展新算力和新技术相互促进协同发展一方面，基础设施计算技术加速演进，异构计算成为智算/超算中心的主流架构。在摩尔定律放缓、颠覆技术尚未成熟的背景下，以AI大模型为代表的多元应用创新驱动算力技术加速进入智能计算新周期，进一步带动计算产业的发展。智能计算时代，搭载各类计算加速芯片的AI服务器将成为智能算力的主要来源。另一方面，先进计算体系化创新活跃，创新模式和重点发生了转变，呈现出软硬融合、系统架构创新的特征。技术创新持续覆盖基础工艺、硬件、软件、整机不同层次，互联持续高速化、跨平台化演进，异构融合加速超级计算和智能计算协同发展。1.2 应对机遇与挑战应对机遇与挑战2023 年 10 月 8 日，六部委重磅发布 算力基础设施高质量发展行动计划，从计算力等四个方面提出了到 2025 年发展量化指标，提出到 2025 年算力规模超OpenCOCA 白皮书(2023)4过 300 EFLOPS，智能算力占比达到 35%2，算力基础设施的高质量发展面临如下挑战。随着摩尔定律的放缓，传统以 CPU 为中心的数据中心体系存在性能瓶颈、成本压力等问题，一方面，带宽性能增速比失调，通用 CPU 的性能增长已无法满足新型算力基础设施的数据增长需求；另一方面，云服务商的 TCO(Total Costof Ownership)急剧增加，百 Gbps 的高性能网络就需要 12 颗以上 Xeon CPU 的核。因此，数据中心的体系架构需要从“以计算为中心”转向“以数据为中心”，即将“CPU 处理效率低下、GPU 处理不了”的虚拟化计算、网络、存储等负载卸载到专用 DPU(Data Processing Unit)，提升整个计算系统的性能、降低系统的 TCO。AI(Artificial Intelligence)场景各厂家 GPU 芯片技术碎片化3、大模型需要激发 AI 芯片性能，AI 推理场景下 GPU 资源的利用率较低。多样化的 GPU 生态导致用户使用不同 GPU 芯片时增加了迁移成本；其次，模型的参数及数据量的倍增要求智算中心具备高效的训推套件来提升效率；最后，整卡或固定比例的 GPU算力资源的分配方式，使得在推理场景下资源的利用率较低且算力资源调度不灵活。大模型运算中，通信是一个重要组成部分，部分 GPU 进行运算，运算完成后还需要与其他 GPU 之间交互数据。一方面，通讯带宽越大，数据同步越快，GPU 的使用率就越高。另一方面，大模型对时延和丢包要求也很高。因为，多个 GPU 运算同一个任务，花费时间最长的 GPU 运算完，才算完成一个运算任务。丢包对 GPU 训练的影响明显，在极端情况下，丢包甚至会导致 GPU 训练失败。XPU(eXtreme Processing Unit)算力资源从体系结构设计到指令集架构再到接口设计，都是相对封闭的，相互之间不兼容，且难以修改或进行普适性扩展。整合多种异构算力资源并采用统一编程框架对现有计算平台来说复杂度高，需要一套标准化且能高效管理异构算力资源的开放平台。为了应对上述挑战，中国移动提出 COCA(Compute on Chip Architecture)软硬一体计算架构。其中，COCA-DPU 模块，针对数据中心场景，通过计算、存储、网络、安全和管控五大引擎实现云化加速；COCA-GPU 模块，用于提高 GPU 训练推理效率和提升 GPU 资源利用率；COCA-HPN(High Performance Network)模块，用于提供大带宽、低延时及零丢包的高性能网络服务能力，释放 AI 集群性能。OpenCOCA 白皮书(2023)5既是挑战也是机遇，为了实现构建更宏大的算力、更高效的连接和更可靠的算力体系愿景，秉承“开放 共赢”理念，中国移动同步孵化 OpenCOCA(OpenCompute on Chip Architecture)开源项目，包含 DPU、GPU 和 HPN 三个模块，用于共建 XPU 产业联盟，联创高性能技术，破解算力体系生态封闭难题，同时布局国产化智算生态，带动国产化智算产业成熟发展。2.COCA 软硬一体片上计算架构打造国家级软硬一体片上计算架构打造国家级自主可控算力基础设施自主可控算力基础设施COCA 以构建普惠的高性能算力为核心目标，以打造自主可控的高性能算力基础设施为宏伟愿景，助力数字中国建设。遵循“软件定义，硬件加速”的理念，COCA 主要由 COCA-GPU 模块、COCA-DPU 模块、COCA-HPN 模块组成。其中，COCA-DPU 模块，围绕计算、存储、网络、安全、管控形成“五大卸载引擎”，基于软硬一体重构算力基础设施的数据中心；COCA-GPU 模块围绕 AI 抽象、AI 加速、AI 池化技术，拉通 GPU产业上下游，共同化解不同 GPU 平台“碎片化”的问题；COCA-HPN 模块，针对大规模集群一方面需要海量的 GPU 算力，另一方面也将面临更为严重的网络拥塞问题的特点，提升算效突破算力互联瓶颈。COCA 以 DPU 为基础，通过 HPN 与国产 GPU 生态的深度融合，重构算力基础设施，联创高性能网络技术，共建自主 DPU GPU 产业联盟，带动国产化智算产业成熟发展。图 2-1 COCA 软硬一体片上计算架构OpenCOCA 白皮书(2023)62.1 COCA-DPU 重构计算架构重构计算架构DPU 是一种提供数据中心基础设施服务的处理器，可以卸载及加速网络、存储、安全和管控等基础功能，释放更多的 CPU 算力供客户使用4。DPU 通常由通用处理单元和专用加速引擎组成，通用处理单元处理控制平面业务，专用加速引擎保证数据平面的处理性能，在保证通用性的同时，突破通用基础设施虚拟化的数据处理性能瓶颈。将虚拟化软件框架由单 CPU 平台支撑扩展至由CPU DPU 双平台支撑，可大幅增强云基础设施的数据处理能力。COCA-DPU 模块通过对算力基础设施的数据中心进行软硬一体重构，能对计算、存储、网络、安全和管控等功能进行加速和卸载。COCA-DPU 模块通过抽象的驱动适配层实现对 DPU 的标准接入，可分为计算、存储、网络、安全、管控五大引擎，其中计算引擎提供标准化的 virtio-net(Virtual I/O Network)、virtio-blk(Virtiual I/O block)后端接口，实现虚拟化 I/O 的数据面和控制面的加速和卸载；存储引擎在 DPU 上实现存储接口后端，通过加载标准 virtio-blk 或NVMe(Non-Volatile Memory Express)驱动实现块存储的读写，无需额外的厂商专用驱动；网络引擎采用标准的卸载接口和流表实现网络流量的卸载与加速；安全引擎通过通过信任根机制以及标准的 IPsec 等加密通讯协议对系统和多租户网络进行安全防护，并基于 DPU 提供有效的卸载方案；管控引擎屏蔽了裸金属、虚拟机和容器的产品形态差异，从而实现 DPU 资源统一管理和全链路管控运维。图 2-2 COCA-DPU 系统架构OpenCOCA 白皮书(2023)72.1.1 计算引擎计算引擎计算引擎聚焦在 I/O 虚拟化卸载和热迁移。计算引擎通过 DPU 提供的标准化的 virtio-net、virtio-blk 后端接口，实现虚拟化 I/O 的数据面和控制面的加速和卸载。基于 Linux 内核层面和用户层面(例如DPDK、SPDK)的 virtio-net、virtio-blk 前端驱动，DPU 能够和 host 侧的 VM 或者裸金属实现无缝对接，提升网络 I/O 的性能，完全卸载 host 侧 CPU 对 virtio接口处理的资源开销。图 2-3 COCA-DPU virtio-net/blk 卸载为了实现现代算力基础设施资源灵活快速管理，计算引擎需要支持热迁移功能。vDPA(Virtual Data Path Acceleration)技术是其中一种有效的途径。vDPA 技术的核心是 vDPA Framework，能够实现 virtio 控制面和数据面的分离。通过在virtio 控制面和厂商私有控制面之间设置中间适配层，既避免了全直通下控制面过于暴露存在的安全隐患，又能屏蔽硬件差异，使不同硬件卸载厂商之间的热迁移成为可能。vDPA 框架可在用户态也可在内核态实现，计算引擎适配和支撑vDPA 的不同技术演进路径，提供针对算力基础设施的热迁移功能。OpenCOCA 白皮书(2023)8图 2-4 vDPA 框架5672.1.2 存储引擎存储引擎在云计算中，DPU 可以为云主机或裸金属提供存储加速功能，通过软硬件结合方式实现存储协议卸载，灵活实现存储 IOPS(Input/Output Operations PerSecond)高性能和 guest CPU 低占用率的要求。数据中心通过 DPU 弹性存储实现了数据中心存储资源的池化，使数据中心计算实例可以按需分配存储资源，并实现弹性伸缩，提高资源利用率，从而降低数据中心运营成本。在弹性存储中的云盘挂载与云盘启动过程中，COCA-DPU 可以实现裸金属实例的快速部署，通过将裸金属实例和虚拟机实例的部署流程、镜像资源和网络配置归一化，简化了部署过程，提升了用户体验，降低了运营成本。DPU 实现 guest 侧存储接口的卸载，主要方式为在 DPU 上实现存储后端接口，并提供 virtio-blk 或 NVMe(Non-Volatile Memory Express)的块设备接口，guest中加载标准 virtio-blk 或 NVMe 驱动实现块存储和文件存储的读写，无需额外的厂商专用驱动。DPU 网络侧接口则将业界常用的远端存储协议，包括iSCSI(Internet Small Computer System Interface)、Ceph RBD(Ceph Rados BlockDevice)、NVMe-oF(NVMe over Fabrics)910前端卸载到 DPU，其中基于 DPU 提供的 RDMA(Remote Direct Memory Access)网络功能实现的 NVMe-over-RDMA网络存储协议可以完成数据中心对各种存储设备的资源池化，大幅度提升了块存储性能，满足了租户对存储性能的需求。OpenCOCA 白皮书(2023)9图 2-5 COCA-DPU 存储卸载2.1.3 网络引擎网络引擎随着 CPU 与网卡性能“剪刀差”的产生，传统的、围绕 CPU 的网络加速方案逐渐难以应对不断增长的 I/O 需求，而投入更多 CPU 来换取 I/O 性能的做法则相对低效。COCA-DPU 通过网络引擎将虚拟交换机的功能卸载到 DPU，降低主机 CPU 在网络转发业务功能上的开销，提高主机可售卖计算资源，同时提升虚拟机的网络性能。图 2-6 COCA-DPU 网络卸载DPU 作为数据处理的核心，在以 DPU 为中心的数据中心架构下，网络 I/O请求由 DPU 处理和加速，可以将网络消耗的 I/O 资源全部卸载到 DPU 上，完全释放服务器的 CPU 资源。一方面因为 DPU 低功耗的特点，数据中心 I/O 的能耗可以大幅降低。另一方面，CPU 资源可 100%用于计算，这提升了单台服务器的计算密度，与同等规模的数据中心相比，该架构可以提供更多的计算资源。OpenCOCA 白皮书(2023)102.1.4 安全引擎安全引擎COCA-DPU 采用基于数字签名的可信根方式确保固件启动的安全性和完整性。DPU 中的一次性非易失存储区中存放公钥，该区域一次烧结后，不能再被更改，该公钥作为 DPU 安全启动的可信根计算基础。在 DPU 固件发布时，将采用数字签名系统的私钥进行加密。私钥为签名系统保留，不被外泄。当 DPU 启动时，将采用逐级验签的方式，确保系统固件的安全性和可靠性。公有云多租户场景，数据流量以明文形式进行传输存在风险，为保证数据的安全可靠，可以通过 COCA-DPU 以租户为粒度对客户的原始报文进行加解密，防止数据在传输过程中被非法窃取。首先，DPU 对主机侧发来的业务 VM 虚机流量进行分析，触发本端和对端的 DPU 引擎进行 IKE(Internet Key Exchange)协商，建立 IPsec(Internet Protocol Security)加密隧道。其次，当 IPsec 加解密隧道建立后，本地 VM 的感兴趣流经过本端 DPU 引擎时，本端 DPU 安全引擎会将此流量进行加密并添加新的报文头，然后发送到目的端 DPU。目的端 DPU 引擎收到密文后，对密文解密，并上送目的 VM，从而完成了数据加密传输流程。上述过程，除 IKE 协商外，均可以通过网络引擎和安全引擎对业务进行加速。图 2-7 COCA-DPU 安全卸载82.1.5 管控引擎管控引擎管控引擎可以为云平台提供裸金属、云主机和容器的资源管理和监控功能，通过将此部分下沉至 COCA-DPU，屏蔽了裸金属、虚拟机和容器的产品形态差异从而实现 DPU 资源统一管理，同时提供 DPU 全链路管控运维能力。基于管控引擎将云平台管理组件从主机 CPU 卸载到 DPU，不仅解决了主机 CPU 资源占OpenCOCA 白皮书(2023)11用的问题，增强了计算实例的性能和稳定性，也提高了计算实例的安全性。此外，除云主机管理组件外，VNC(Virtual Network Console)、监控脚本、系统日志等相关运维组件同样卸载到 DPU 上，可以降低虚拟化场景下主机 CPU 资源开销，为裸金属提供和虚拟机一致的交付和运维体验。图 2-8 COCA-DPU 管控系统架构与此同时，将管控组件部署在 DPU 中具有如下优势：DPU 可直接接入管控系统，实现上线、拉起和运维自动化，将管控系统与主机解耦，提高运维效率；对主机 CPU 系统零侵入，实现管控与主机系统解耦，提高管控开发和部署效率；实现裸金属和虚拟化场景 VM 和 BM 的并池，提高计算资源利用率；OpenCOCA 白皮书(2023)12图 2-9 COCA-DPU 管控部署架构另外，管理组件本身对 CPU 的计算性能要求不高，DPU 中的通用 CPU 性能完全可以满足需求，而且管理组件卸载到 DPU 之后能够将全部主机 CPU 资源提供给上层业务使用，同时也减小了管理软件对上层业务应用程序的干扰，进一步提升整体算力基础设施的算力密度和安全性。2.2 COCA-GPU 融通算力生态融通算力生态COCA-GPU 模块包括 AI 抽象、AI 加速以及 AI 池化三大技术，分别解决AI 生态割裂、大模型训练/推理性能加速以及算力资源调度不灵活的问题。AI 抽象屏蔽底层硬件差异构筑统一的 AI 生态；AI 加速为大模型分布式训练及生产部署提供了一套加速套件全面提升 AI 性能；AI 池化通过软件定义算力，在细粒度切分算力的同时打破物理边界实现算力资源的灵活取用。通过上述三大模块，COCA-GPU 可以有效帮助客户降低迁移成本，提高 GPU 训练推理效率及 GPU资源利用率。OpenCOCA 白皮书(2023)13图 2-10 COCA-GPU 系统架构通过在框架和 GPU 计算库之间新增 AI 抽象层定义了统一的算子标准，使得上(框架)下(GPU)两层有效解耦。不同厂商基于这一套标准里抽象的函数声明列表，根据自己的硬件封装算法及内存拷贝、流创建销毁等设备操作功能，标准化地接入 COCA-GPU。2.2.1AI 抽象抽象AI 抽象旨在屏蔽不同架构 GPU 芯片的软硬件差异，联合国内外 GPU 行业联盟共同构筑一套统一标准，实现 AI 应用跨芯片的无感迁移，解决当前 AI 生态的多样化、碎片化的问题，带动国产 GPU 统一生态的发展。图 2-11 COCA-GPU AI 抽象一是面向用户提供主流框架适配器，针对不同 GPU 芯片及软件栈为用户提供了统一抽象层，实现无感知的跨 GPU 迁移部署 AI 应用。二是面向 GPU 厂商联合制定了一套统一的算子标准支撑 AI 模型的开发应用，各硬件厂商基于自家OpenCOCA 白皮书(2023)14硬件特性主动适配接入，构建标准化的硬件接口，推动国产生态繁荣发展。三是面向 AI 应用提供了统一的算力 API，简化了各类 GPU 厂商软硬件栈，建立统一纳管及映射机制。算子标准制定了一套抽象的接口规范，并衍生出一系列的统一算力 API 接口。对下由各厂商根据该接口及参数列表实现具体的功能，对上供COCA-GPU AI 抽象提供的框架适配器调用。由于上层框架直接调用统一算力API，屏蔽底层硬件差异，因此可以实现一次编码在不同 GPU 执行，大大降低用户的研发和迁移成本。2.2.2AI 加速加速AI 加速是面向 AI 任务提供的加速引擎包括训练和推理加速套件，针对底层硬件、网络、通信及算子库对训练/推理过程进行优化，充分发挥硬件能力，进一步提升 AI 应用性能表现及效率，降低客户及企业的成本。图 2-12 COCA-GPU AI 加速分布式训练过程中，卡间及机间的通信往往成为制约大模型训练过程的主要性能瓶颈点。CTK(Compute on Chip Architecture Training Kit)为用户提供了开箱即用的训练加速套件。分布式通信策略一方面通过在梯度传递过程中同步进行计算操作，来提高整体的训练效率；另一方面通过降低通信频次及数据量来优化分布式训练的通信过程。高性能通信库根据网络拓扑并结合 RDMA 网络最大程度地优化分布式训练中的通信拓扑与时长，提升整个训练过程的效率。训练完的模型直接投入生产部署，其推理性能通常较差并且算力资源的使用效率很低。CIK(Compute on Chip Architecture Inference Kit)推理加速套件提供计OpenCOCA 白皮书(2023)15算图优化以及高性能算子库助力用户的业务模型可以针对不同硬件特性进行优化加速。图优化在模型真正执行推理前，通过图精简以及算子融合等技术对模型的计算量进行压缩，从而提升推理速度；高性能算子库则针对显存访问及算法优化等实现了一系列高性能场景化算子，帮助用户编译最优的部署方案，提升推理性能、降低生产成本。2.2.3AI 池化池化AI 池化通过软件定义 GPU 算力，打破原有的 AI 应用直接调用物理硬件的方式，增加软件层对 GPU 算力进行统一的抽象，实现算力的细粒度切分以及 AI应用与物理 GPU 的解耦。图 2-13 COCA-GPU AI 池化管理调度组件是 AI 池化单元的核心组件，负责管理集群所有服务器上物理GPU 设备、软件定义的虚拟 GPU 算力、服务器网络信息。提供虚拟 GPU 算力的统一调度、GPU 计算节点上其他功能组件的服务注册与发现功能。算力服务插件部署于每台 GPU 服务器之上，用于发现节点上的物理 GPU 资源，通过软件定义的方式将 GPU 算力进行细粒度切分与抽象，并上报到管理调度组件。同时通过配合客户端运行时组件实现虚拟算力的远程挂载。客户端运行时组件部署在用户云主机、容器或者裸金属之上，当使用 GPU算力执行 AI 应用时，相关算力请求会被客户端运行时组件接管并分发到对应的算力服务插件，对用户实现无感知地本地调用远端算力。2.3 COCA-HPN 提供海量提供海量 AI 算力算力OpenCOCA 白皮书(2023)16随着 ChatGPT(Chat Generative Pre-trained Transformer)的出现，AI 大模型相关应用百花齐放，纷纷进入到亿级参数网络时代，彻底引爆了智算中心领域对算力规模的需求。当前智算中心规模化算力部署扩展趋势上主要分为节点内算力连接和节点间算力连接两个主要方向。其中，节点内芯片间高性能互联网络以NV-LINK(NVIDIA-LINK)和 CXL(Compute Express Link)1112技术为代表，其主要特点是高带宽、低延迟、低功耗和高密度；另外，节点间高性能互联网络以IB(InfiniBand)13和 ROCE(RDMA over Converged Ethernet)v2 技术为代表，其主要特点是高带宽、低延迟、机房内传输和规模化互联。用于分布式训练框架通信的高性能集合通信库通过发现拓扑并选择最优通信路径进行集群通信，进而实现可以线性扩展的规模化异构算力集群。在 HPN 智能管理运维方面，智能管控系统不仅能够对节点内和节点间高速互联网络进行管理监控，还能够根据监控数据智能化调整网络配置参数以及故障诊断和排除。综上，通过软硬一体、端网协同等方式共同实现智能化管理运维的异构算力互联网络。图 2-14 COCA-HPN 异构算力互联架构2.3.1 高性能高性能集合通信集合通信库库高性能集合通信库在 AI 大模型训练过程中主要负责管理异构算力芯片间的数据通信，业界主流应用于异构算力通信的开源 GPU 集合通信库，如NCCL(NVIDIA Collective Communications Library)，无法做到在任何网络结构中都发挥出极致的通信性能，大规模训练任务的集群效率存在极大的改善空间。基于移动云能力中心自定义的异构计算互联网络拓扑结构的特点，COCA-HPN 正OpenCOCA 白皮书(2023)17自研定制化的高性能集合通信库，在 AllReduce 和 All-to-All 等常用通信模式下，能够有效利用内外部互联带宽能力，预计数据通信效率能提升 20%以上。同时，在设备管理、拓扑感知、通信选路等方面 COCA-HPN 也将进行定制化设计。（1）多轨网络的流量路径规划：异构算力 GPU 之间通信路径存在多种异构拓扑，如节点内部互联网络 NVLINK 和 PCIe Switch 等，节点间互联网络 RDMA。集合通信库在路径规划过程中应充分考虑物理拓扑结构，充分利用节点内和节点间网络。在多轨网络中，异构算力节点分配需结合算力连接智能管理系统，将算力资源分配在具有亲和性的网络位置，尽可能实现节点间互联网络在一跳交换机上实现互通。同时，充分利用异构算力节点内网络通信高吞吐的特点，优先将数据在节点内同步，再利用多轨网络进行节点间数据通信。（2）异构网络数据传输优化：异构网络将节点间数据传输的会话数量大幅减少，流量规模按节点内传输、机架内一跳交换机传输和三跳交换机传输依次递减，同时，将短数据流在节点内汇聚为长数据流的方式来减少会话数量，降低对RDMA 智能网卡上 RDMA QP 数量规模的要求，从而提升整网的传输性能。（3）通信原语拓扑自适应：异构算力集合通信库通过对异构网络拓扑的感知，在集合通信过程中使用不同通信原语时，充分利用网络拓扑特点，选择数据通信方式。如节点内互联方式是点对点时，做 Ring AllReduce 需要建立多个 Ring，充分利用节点内互联网络带宽；如节点内互联方式是 Switch 时，做 RingAllReduce 则无需建立多个 Ring。2.3.2 内部互联网络系统内部互联网络系统大模型的训练和推理场景中，需要使用到多张 GPU 卡联合进行计算，计算过程中需要多张卡对计算结果进行分发、收集和规约计算等数据交互操作。执行这些数据交互操作所需要的时间，通常占到整个训练或推理过程耗时的 30%-40%左右。因此，节点内通信的性能，直接影响了模型训练或推理的整体性能。当前算力基础设施的节点内通信，主要分为如下两种互联方案。（1）PCIe(Peripheral Component Interconnect express)Switch 互联随着 PCIe 技术的发展，以 PCIe x16 双向传输为例，总的双向传输带宽从Gen3 的 32GB/s 发展到 Gen4 64GB/s，再到 Gen5 128GB/s。PCIe/PCIe Switch 作为异构算力互联的基础拓扑得到了广泛应用，进一步依托 GPUDirect P2P 技术实现节点内 GPU-GPU、GPU-DPU 芯片间互联通信。在提供通信带宽扩展方面，OpenCOCA 白皮书(2023)18PCIe/PCIe Switch 的通信带宽限制了点对点间的线性扩展能力，进而限制了高性能异构算力在节点内互联互通的应用规模。（2）芯片间高速总线互联受限于 PCIe Switch 的通信性能，英伟达提出了自定义的高速总线互联技术NV-LINK，作为 PCIe 的替代技术，实现 GPU-GPU 以及 GPU-CPU 之间高速大带宽总线互联和内存共享能力。NVLINK 核心技术体现在增加连接密度的同时还能有效控制数据传输功耗，同时实现内存地址空间共享和互访。如下图，经过 4代 NVLINK 技术的迭代，在 NVLINK4 中单个 GPU 已经支持 18 个 NVLINK 连接，共 900GB/s 的双向总带宽能力。图 2-15 英伟达 NVLINK 演进过程14此外，CXL 也是目前业内重点关注的标准化协议。CXL 联盟于 2019 年由英特尔发起，联合了众多 CPU 厂商、服务器厂商和云厂商，共同推进 CXL 标准发展，目前标准已经更新到第三代，能够有效提升异构算力芯片缓存级和内存级通信效率。紧跟行业技术发展的路径，移动云提出 COCA-HPN X-LINK，通过卡间直连以及设备内存统一管理，提升卡间数据交互的效率。（1）加大卡间互联的数据传输带宽GPU 通过 PCIe 接口与主机相连，一般的卡间通信需要经过 GPU1 显存-主机内存-GPU2 显存的冗长链路，经历多次设备侧和主机之间的数据传输。为了解决这个问题，X-LINK 提供额外的数据传输通路，从而提供了更高的卡间带宽，且避免了数据多次搬运。（2）减少卡间数据传输的额外开销由于 PCIe 设备内存和主机内存处于不同的物理空间，难以做到统一的管理OpenCOCA 白皮书(2023)19和协作，并导致不同设备和主机间进行数据交互时，产生大量额外开销，降低了数据传输效率，且增加了数据传输过程中的不稳定性。支持 CXL 设备，可以将设备内存与主机内存作为一个逻辑整体来统一管理，从而减少设备和主机间的数据传输开销，提升整机协作效率。类似的，在同一台服务器内的多个 CXL 设备，也可以减少彼此之间的数据传输开销，从而提升数据传输的效率和稳定性。2.3.3 外部互联网络系统外部互联网络系统除了提升和解决节点内物理连接层面的带宽时延问题之外，COCA-HPN 也聚焦节点间的互联能力，旨在提供一套统一、可扩展、高可靠的网络连接。主流的被应用于 HPC、智算中心的节点间计算通信的网络协议包括：IB、ROCEv1、ROCEv2、iWARP、SRD(Scalable Raliable Datagram)15以 及Solar-RDMA16等。目前 IB 和 ROCEv2 得到了更多的发展机会，IB 是一种原生RDMA 协议，在物理层和传输层上都进行了优化，提供了非常高的数据传输带宽和低延迟，但是与特定的硬件耦合较强，部署成本高昂。ROCEv2 突破 ROCEv1只能运行于 L2 子网的限制扩展到 L2、L3 层网络，从而有了更大的应用空间，同时配合多种的拥塞控制算法，例如 DCQCN(Data Center Quantized CongestionNotification)、HPCC(High Performance Congestion Control)17、Timely、Swift 等，提升了网络性能，从而使得 ROCEv2 在 HPC 和分布式大模型训练逐步得到应用和推广。当前大模型训练数据量和参数数量仍在成倍增长，AI 模型的规模在过去 4年维持了每年 10 倍的增长，除了 GPU 本身的算力仍需提升外，超大的规模集群还将面临更为严重的网络拥塞问题。COCA-HPN 能解决这一问题，移动云推出面向 RoCE 的“乌蒙”高性能网络，其原创的“乌蒙”拥塞控制协议，实现了高精度的拥塞信号检测能力，可降低拥塞时延，提升集群算效。在智算中心的典型“中长流”场景下，集群网络性能可以提升 48%，可支持万卡级智算集群组网能力。OpenCOCA 白皮书(2023)20图 2-16 COCA-HPN 自研“乌蒙”拥塞控制协议2.3.4 HPN 智能管控系统智能管控系统当前新型智算数据中心场景，运维手段在应对高性能参数网络的高稳定性需求时存在着挑战，主要表现在：一是无法及时发现故障及网络性能波动，部分故障从发生到发现通常到小时级别，而且一些微突发的故障因为监控粒度不够导致监控遗漏。二是故障响应及解决速度慢，主要在于发现故障之后的排障分析耗时长，无法快速解决故障从而造成 GPU 运算资源的浪费。针对以上问题，移动云推出 COCA-HPN 智能管控系统，在自研的智能管控分析平台上通过链路状态监测、RoCE 网络性能实时监控分析以及快速故障根因分析来解决如上问题。（1）网络链路状态检测对全网链路进行主动的连通性探测(可通过 IPIP 标准协议，不绑定网络设备)，秒级快速探测全网所有网络路径，及时发现端口、线卡、设备、协议等异常引起的链路连通性故障。（2）RoCE 网络性能实时监控分析RoCE Telemetry 关键指标监控：通过 gRPC 遥测手段，秒级(部分指标毫秒级)收 集 端 口、芯 片 队 列、PFC(Priority-basedFlowControl)、ECN(Explicit Congestion Notification)等关键指标信息进行负载情况监控、拥塞情况监控、丢包统计、端口队列缓存监控，并针对超限事件及时告警，及时发现微突发、负载不均衡问题。RDMA 流级可视：通过 ERSPAN 镜像 RDMA 控制面报文，通过控制面报文OpenCOCA 白皮书(2023)21进行 RDMA 流统计和流参数的性能监控，及时发现网络性能波动，辅助调优。（3）故障根因分析根据告警信息、链路状态监控信息、Telemetry 监控指标等，结合专家经验和知识图谱进行故障的多维关联分析，分钟级自动定界定位，帮忙快速进行根因分析、解决故障。3.从从 COCA 走向走向 OpenCOCA，业内首个开放业内首个开放式的软硬一体片上计算平台式的软硬一体片上计算平台当前算力基础设施相关产业面临严峻的竖井化技术生态挑战，各厂商围绕自身硬件特性构建相对独立且排他的工具链系统。构建 COCA 技术架构的初衷是为了突破这种困境，而不是再造一个新的“竖井”，因此，中国移动决定突破创新，以世界一流信息服务科技创新公司的胸怀，开源 COCA 软硬一体片上技术架构，从 COCA 走向 OpenCOCA，打造业内首个开放式的软硬一体片上计算平台。3.1 能力共享，激发行业活力能力共享，激发行业活力COCA 以 DPU、GPU、HPN 三大单元为主体方向，当前已在 DPU 计算、存储、网络、安全、管控等关键技术实现突破，具备成熟的商用能力。秉承“开放 共赢”的理念，移动云将 COCA 基础核心能力提取出来创建OpenCOCA 开源项目，当前，OpenCOCA 项目已受到多家合作伙伴的关注与支持。图 3-1 OpenCOCA 开源理念OpenCOCA 拟筹 OpenCOCA 委员会、项目(群)办公室、技术运营委员会、OpenCOCA 白皮书(2023)22综 合 运 营 委 员 会，技 术 运 营 委 员 会 下 设 OpenCOCA-DPU 工 作 组、OpenCOCA-GPU 工作组和 OpenCOCA-HPN 工作组。其中项目(群)办公室负责架构、版本规划等项目管理工作，处理项目需求、跟踪问题反馈，并协调各工作组联合运营；OpenCOCA-DPU 工作组负责 DPU 五大引擎的架构设计、开源开发及维护；OpenCOCA-GPU 工作组负责 AI 抽象、AI 加速以及 AI 池化相关内容，设计统一的 GPU 接入标准，开发提供针对异构 GPU 池化管理的统一 SDK 或插件；OpenCOCA-HPN 工作组负责端网协同等融合技术，开发打造高性能，包容开放的高性能网络单元。图 3-2 OpenCOCA 委员会通过 OpenCOCA 开源项目，希望可以为行业内各芯片厂商提供开源应用实践平台，深化算力赋能行业应用，激活行业活力。3.2 行业共治，规范行业标准行业共治，规范行业标准以 OpenCOCA 开源项目为媒介，中国移动希望与产、学、研各界合作伙伴精诚合作，携手制定算力基础设施标准和规范，注重行业顶层技术规划，坚持技术协同，避免碎片化研究和低质量的重复工作，与各方一道，在以“软件定义、硬件加速”为核心理念的基础上，凝聚共识，共同推进算力基础设施标准化、规范化。OpenCOCA 开源项目拟将各家 DPU、GPU、FPGA 等算力芯片的能力集合分类梳理，制定异构算力能力标准规范，制定异构算力芯片接入标准规范；同时面向云平台提供标准化 API 接口。基于 OpenCOCA 软硬一体片上计算平台，云平台可以忽略底层设备差异，而专注于异构算力的编排调度，更加快速完成高性OpenCOCA 白皮书(2023)23能算力基础设施建设，通过基础设施并池的方式实现统一化运维与管理。基于OpenCOCA 相关标准，各芯片厂商可有效保障自身算力芯片的通配性，降低芯片产品接入云平台的适配成本，以便快速融入市场。3.3 协作共赢，创造行业价值协作共赢，创造行业价值为实现“打造自主可控的高性能算力基础设施”的宏伟愿景，OpenCOCA 将继续发挥“开放 共赢”优势，实现算力基础设施行业相关的需求感知传递与能力聚集呈现。将客户所提出的行业市场需求及时通过 OpenCOCA 向下传递至社区，引导芯片厂商和研究机构关注到更被迫切需要的技术能力；将各厂商具备的最新技术特性通过 OpenCOCA 向上暴露给云上租户，实现行业赋能的同时为各厂商提供实践应用平台及相应的市场份额。通过 OpenCOCA 开源事项推动算力基础设施行业内的良性循环，落地实施算力应用创新案例，创造行业价值。4.展望与倡议展望与倡议本白皮书基于算力基础设施的现状，围绕目前面临的挑战和技术革新，大胆畅想了高性能算力基础设施的未来发展。中国移动认为18，新型智算中心当前处在“集群时期”，已经按照集群的思想构建算力基础设施。面向中远期，我们将重点攻关“超级池化时期”的关键技术，尽快形成行业共识，加速相关核心技术和产业成熟。4.1 布局开放式智算生态，带动国内智算产业成熟发展布局开放式智算生态，带动国内智算产业成熟发展OpenCOCA 致力于构建以 GPU、DPU、HPN 为核心的异构超算力一体化开放式架构，有助于充分调动算力，满足高效、敏捷、弹性、安全等需求，是面向新一代基础设施建设的重要布局。OpenCOCA 将继续聚焦“算力 连接 能力”，以高效、开放可控、可信的计算架构为基石，持续构建“云为核心，网为基础”的算力网络，带动国内智算产业成熟发展，全力支撑国家算力互联互通、算网生态聚合，为数字中国建设贡献更大的力量。4.2 共建产业联盟，自主掌握云计算技术标准共建产业联盟，自主掌握云计算技术标准中国移动多措并举构建 OpenCOCA 框架开源生态，营造创新良好的算力基础设施发展环境。我们倡议遵循开源开放原则，联合建设开源社区，鼓励我国高OpenCOCA 白皮书(2023)24校、企业、行业组织等产业各方融入开源社区生态，孵化更多像 OpenCOCA 这样的开源项目，共建产业联盟，自主掌握云计算技术定义权。配套建设开源风险监测、开源生态监测等平台，强化开源生态治理意识。我们从标准工作切入，推进算力基础设施框架统一的标准化，加速 COCA 框架形成支持跨平台迁移部署的能力，为算力基础设施筑起协同生态。4.3 联创高精尖技术，引领云计算市场下一个黄金十年联创高精尖技术，引领云计算市场下一个黄金十年注重顶层技术规划，坚持自主可控，中国移动依托 COCA 计算架构完成算力基础设施升级，依托 OpenCOCA 解决算力体系生态封闭问题。鼓励企业增加技术创新投资，与合作伙伴联创高精尖技术，强化对 DPU、GPU、xPU、RNIC(RDMA Network Interface Controller)等单芯片的设计和创新能力，逐步实现关键核心领域自主可控，推动算力基础设施全面国产化稳步落地，引领云计算市场下一个黄金十年。OpenCOCA 白皮书(2023)25缩略语列表缩略语列表缩略语缩略语英文全称英文全称中文释义中文释义AIArtificial Intelligence人工智能ASICApplication Specific Integrated Circuit应用特定集成电路Ceph RBDCeph Rados Block DeviceCeph 提供的块存储能力ChatGPTChatGenerativePre-trainedTransformer生成型预训练变换模型CIKComputeonChipArchitectureInference Kit软硬一体片上计算架构推理套件COCACompute on ChipArchitecture软硬一体片上计算架构CPUCentral Processing Unit中央处理器CTKCompute on Chip Architecture TrainingKit软硬一体片上计算架构训练套件CXLCompute Express LinkINTEL 推出的开放性互联协议DCQCNData Center Quantized CongestionNotification一种广泛采用的拥塞控制算法DPUData Processing Unit数据处理器ECNExplicit Congestion Notification显性拥塞通知FPGAField Programmable GateArray可编程阵列逻辑GDRGPU Direct RDMAGPU 之 间 直 接 通 过RDMA 通信GDSGPU Direct StorageGPU 直接访问存储设备GPUGraphics Processing Unit图形处理器HPCHigh Performance Computing超级计算HPCCHigh Performance Congestion Control高精度拥塞控制HPNHigh Performance Network高性能网络IBInfiniBand无限带宽技术OpenCOCA 白皮书(2023)26IKEInternet Key Exchange因特网密钥交换协议IOPSInput/Output Operations Per Second每秒读写(I/O)操作次数IPSECInternet Protocol Security互联网安全协议iSCSIInternet Small Computer SystemInterface计算机系统接口LLMLarge Language Module大语言模型NCCLNVIDIA Collective CommunicationsLibraryNVIDIA 集合通信库NV-LINKNVIDIA-LINK英伟达开发并推出的总线及其通信协议NVMeNon-Volatile Memory Express非易失性内存标准NVMe-oFNVMe over Fabrics一种传输层协议规范，旨在使用NVMe通过网络将主机连接到存储OpenCOCAOpen-source Compute on ChipArchitecture开源软硬一体片上计算架构PCIePeripheral Component Interconnectexpress高速串行计算机扩展总线标准PFCPriority-based Flow Control基于优先级的流量控制RDMARemote Direct Memory Access远程直接内存访问RISCReduced Instruction Set Computer精简指令集计算机RNICRDMANetwork Interface ControllerRDMA 网络接口控制器ROCERDMAover Converged Ethernet基于融合以太网的RDMASRDScalable Reliable Datagram可扩展的可靠数据报TCOTotal Cost of Ownership总体拥有成本virtio-blkVirtiual I/O block虚拟块设备virtio-netVirtual I/O Network虚拟化网络设备驱动程序VNCVirtual Network Console虚拟网络控制台OpenCOCA 白皮书(2023)27vDPAVirtual Data Path Acceleration虚拟数据路径加速XPUeXtreme Processing Unit异构处理器单元OpenCOCA 白皮书(2023)28参考文献参考文献1 中国算力发展指数白皮书R，中国信通院，20232 算力基础设施高质量发展行动计划R，工业和信息化部、中央网信办、教育部、国家卫生健康委、中国人民银行、国务院国资委,20233 面向智算的算力原生白皮书R，中国移动，20224 云计算通用可编程 DPU 发展白皮书R，中国移动，20235 Ariel Adam,Amnon Ilan.Achieving network wirespeed in an open standardmanner:introducing vDPA.6 Jason Wang,Ariel Adam.vDPAkernel framework part 1:vDPAbus for abstractinghardware.7 Jason Wang,Ariel Adam.Introduction to vDPAkernel framework.8 https:/ NVMe Overview,https:/www.nvmexpress.org/wp-content/uploads/NVMe_Overview.pdf10 NVMe over Fabric Overview,https:/nvmexpress.org/wp-content/uploads/NVMe_Over_Fabrics.pdf11 Compute Express Link Specification,June 2019,Revision:1.112 Compute Express Link CXL:ACoherent Interface for Ultra High SpeedTransfers,Kurt Lender,Intel,Flash Memory Summit 201913 Introduction to InfiniBand,Mellanox White Paper,https:/ https:/ ACloud-Optimized Transport Protocol for Elastic and Scalable HPC16 SIGCOMM22 From Luna to Solar:The Evolutions of the Compute-to-StorageNetworks inAlibaba Cloud17 HPCC:High Precision Congestion Control,Yuliang Li,Rui Miao,HongqiangHarry Liu,etc.,SIGCOMM 19,2019 Conference of theACM Special Interest Groupon Data Communication18 中国移动 NICC 新型智算中心技术体系白皮书R，中国移动，2023

0人已浏览 2023-12-04 31页 5星级

点击查看更多IDC&浪潮信息：2023-2024中国人工智能计算力发展评估报告（47页）.pdf精彩内容。

0人已浏览 2023-12-04 47页 5星级

引言背景介绍随着云计算和云原生技术的广泛应用，越来越多的应用程序在诞生初期就成为云的原著民。在云原生的浪潮下，Kubernetes 集群在规模和数量上快速增长，进而使得在大规模集群中，节点管理的重要性日益突出。在这样的环境下，高效的节点管理成为确保集群稳定性、性能优化和资源利用率最大化的关键因素。计算节点作为云原生架构的关键组成部分，节点的管理直接影响着整个云原生应用的成本和稳定性。然而，现有的基础架构管理方法更偏向于传统的虚拟机管理理念，缺乏对工作负载的深度感知，无法适应大规模集群的节点管理要求。面对大规模的节点管理的场景，越来越多的人愿意尝试云原生式的节点管理模式。云原生节点管理是基于云原生理念，使用专为此目的设计的操作系统底座ContainerOS 和配套基础设施，提供的一种有效的节点管理方案。这种新的管理方案旨在优化云上环境的大规模节点的管理成本，并同时提供更佳的弹性、灵活性、稳定性和安全性。节点管理现状和面临的挑战计算节点是云原生架构的基石，承载着工作负载和集群核心组件，对整个系统的可用性和性能至关重要。有效的节点管理能够确保节点的稳定性、弹性和安全性。在云原生环境下，传统的节点管理方式面临着以下挑战。挑战 1：大规模节点的自动化部署和扩容Kubernetes 提供了弹性的部署环境，可以迅速扩展 Pod 副本以适应业务压力的迅速增长。为此，在 Kubernetes 集群中需要预留一定的计算资源来支持Pod 的横向扩展，这预留的标准就是集群预警水位。预警水位的高低直接影响了集群使用成本，如果水位过低，就会因为机器的闲置而导致资源的浪费。在云上环境中，依托于云厂商云主机（如阿里云 ECS 等）的弹性，使得 Kubernetes 集群可以采用较高的预警水位，在业务高峰期提前扩容 Kubernetes 节点以支持更多的工作负载。但是，Kubernetes 节点的扩容过程往往需要花费数分钟的时间，大规模的节点扩容甚至可能需要十几分钟，时间敏感的业务可能会因瞬时容量不足导致业务损失。挑战 2：节点状态的实时监控和故障恢复当集群的规模足够庞大时，集群中节点在运行过程中出现故障会成为常态，例如网络抖动、异常重启、底层硬件故障等。而且，对于分布式系统来说，由于爆炸半径各有大小，如何实时监控节点状态，快速响应故障情况以避免故障扩大，成为新的挑战。同时，节点监控本身也需要消耗资源，例如 cgroup 的采集、proc 系统的采集等。在密集部署工作负载的情况下，这种资源消耗会更加严重。如何以更低的成本监控节点的健康状况成为高密度容器部署所需要考虑的首要因素之一。挑战 3：大规模节点的运维自动化在大规模集群中，即使是常规的运维操作也会变得充满变数，包括操作系统的升级、安全补丁的应用、软件包的管理、kubelet 或 containerd 的自定义配置等。为了保证将集群内的所有节点安全、平稳地更新到一致的状态，不仅需要具备大规模节点变更的能力，还需要具备变更操作的审计和回滚能力。在运维操作中，若由于错误而导致节点状态不一致，即部分节点的配置与预期不符，甚至同时存在多个版本的节点，不仅会大幅增加下次运维操作失败的风险，还可能使得相同的业务副本在部分节点上出现非预期行为，进而引入业务的稳定性风险。本白皮书的目的和范围本白皮书的目的是探索和总结云原生节点管理的新范式，重点介绍面向云原生场景设计和优化的 ContainerOS 及其在云原生节点管理中的关键角色。我们将深入了解 ContainerOS 及其配套基础设施的能力和特点，阐述为大规模集群管理场景进行的优化和云原生节点管理方案。本白皮书的范围将涵盖云原生节点管理的核心概念和关键技术，并结合行业最佳实践，提供降低节点管理成本，提高稳定性和安全性的可行方案和具体建议。我们希望通过本白皮书，引起读者对云原生节点管理的关注，并为他们提供全面的理解和应用指南。目录页一、云原生节点管理概述.71.云原生节点管理的定义.72.理解 Kubernetes 节点管理成本.83.降低节点管理成本的重要性.10二、ContainerOS 概述.121.传统操作系统在云原生场景面临的问题.122.ContainerOS 的设计原则.133.ContainerOS 在云原生节点管理中的角色.14三、ContainerOS 特性介绍.171.专注于容器化应用.172.安全提升.183.原子升级与镜像版本化.19四、节点的生命周期.221.千节点扩容的弹性.222.节点运维监控工具.233.节点声明式配置.254.节点故障自愈.28五、阿里云最佳实践和客户案例.311.在阿里云容器服务中使用 ContainerOS 实现极速扩容.312.ContainerOS 助力阿里云 ECI 极致弹性.343.蚂蚁安全科技镜像加速实践.35六、尾声.391.云原生节点管理的基本逻辑.392.未来节点管理的发展趋势.39云原生节点管理概述Overview Of The Cloud Native NodeManagement一、云原生节点管理概述7一、云原生节点管理概述Kubernetes 是开源的容器编排平台，用于自动化部署、扩展和管理容器化应用程序。Kubernetes 的基本架构由几个核心组件组成。首先是控制平面，它是集群的控制中心，负责管理整个集群的状态和配置。控制平面包括三个组件：API Server 提供集群的 API 接口，Scheduler 负责调度工作负载到合适的节点上运行，Controller Manager 处理集群中的各种控制器任务。其次是 Worker 节点，它是集群中的工作节点，负责运行和管理容器化应用程序。Worker节点核心包括两个组件：Kubelet 是节点上的代理服务，与 Master 节点通信并管理容器的生命周期，Container Runtime 负责运行容器。1.云原生节点管理的定义Worker 节点（简称节点）是构建云原生应用平台的基础，承载着管理容器生命周期和物理资源的重要任务。通常情况下，节点有以下具体的职责：一、云原生节点管理概述8提供容器运行环境：节点使用容器运行时来处理容器的创建、启动、停止和销毁。通过全生命周期管理，使容器能够始终保持在期望状态。合理分配资源：节点负责为工作负载分配所需的运行资源。包括计算资源（如 CPU 和内存）、持久化存储和网络资源等。通过合理的资源分配，节点不仅能够满足容器的运行需求，更能保证不同容器间的资源隔离。提供高可用和故障恢复：节点应具备基本的高可用和故障恢复能力，在可预料的异常发生时，主动干预使工作负载向期望状态靠拢，以提供基础的稳定性和可靠性。但同时，节点也存在局限性，一方面单节点无法解决非预期的错误，比如容器运行时的异常，节点的恢复手段十分有限。并且由于缺乏全局视角，在集群容量不足时，因单节点的故障导致整个集群的雪崩也时有发生。另一方面，由于宿主节点自身的管理并没有被Kubernetes 集群标准化，随着集群规模变得庞大时，千奇百怪的手动运维操作，极易使得集群中节点的配置存在差异，加剧环境腐化。云原生节点管理是指在云上环境中，利用云的弹性、可用性和计量计费等特点，最大化发挥节点的自管理能力，并通过集群化手段弥补单一节点的局限性，构建成本可控、易于管理、敏捷、安全和高可用的集群基础设施。通过云原生节点管理实践，可以有效的进行大规模集群的管理，满足不同工作负载的需求，并确保整个集群的稳定运行。这种管理实践对于构建可靠、可扩展的云原生应用平台至关重要。2.理解 Kubernetes 节点管理成本Kubernetes 是业界云原生应用平台的事实标准，同时也是一个复杂的分布式系统。Kubernetes 的创建者之一，Heptio（VMware）的 Joe Beda 曾表示：Kubernetes 是一个复杂的系统，它带来了很多新的抽象，但这并不适合所有问题。我确定，很多人通过更简单的工具实现 Kubernetes 的功能。和其他所有的具备生命周期的软件系统一样，集群并不是一成不变的，而是根据业务实际需求动态的调整。无论是在集群内增减部署集，还是根据实际情况对集群节点进行扩缩容。day2 运维操作使得集群的整体状态一直处于变化中。一、云原生节点管理概述9作为分布式系统，Kubernetes 也天然具备了分布式系统的复杂性和风险，而环境动态变化引入的不一致问题，加剧了故障的可能性和排查难度。所以，随着集群规模的增加，集群的可用性反而会下降，节点管理成本也会不可避免的上升。所幸 Kubernetes 的使用和运维可以利用系统化和工程化的手段降低复杂度，并提高整体可用性和降低管理成本。但首先我们需要理解什么是节点管理成本，节点管理成本主要涉及硬件成本和运维成本两部分。硬件成本是指集群所管理的资源成本。在提高部署集规模的同时，对计算资源的需求也会相应增加，为了满足负载需求，需要考虑节点的计算能力、存储空间和网络带宽是否足够，这给容量规划带来了较大的挑战。合理的容量规划可以避免因硬件资源不足而导致的性能问题和系统崩溃，而不合理的容量规划会导致大量资源闲置，产生资源浪费。运维成本是指在日常的部署和节点运维中，需要投入的资源和人力。一方面，需要确保工作负载符合预期，另一方面，也需要保持节点配置和状态一致，以避免环境腐化。无论是操作系统和集群版本的升级操作，还是系统或容器运行时的配置和调优，大规模的节点管理是一个复杂的任务。需要时刻保持正确且最终一致的部署形态和环境配置，否则很容易造成应用行为异常或引入稳定性风险。一、云原生节点管理概述10更多的节点数量，也意味着更大的节点故障可能性。当节点发生故障时，需要及时发现并采取相应的措施来恢复服务。这包括诊断故障原因、迁移工作负载以及修复或替换故障节点等。故障处理的复杂性随着节点数目的增加而增高，需要投入更多的时间和人力来保证集群的稳定性。3.降低节点管理成本的重要性降低节点管理成本在构建可持续发展的云原生应用平台中十分重要。在云上环境中，我们可以利用云的标准化和弹性等特点，以通过系统化手段降低集群整体复杂度的方式，获得更可控的管理成本和更稳健的应用平台。采用云原生节点管理实践，可以获得以下益处。节约计算资源成本：充分利用云上环境的极致弹性特点，对集群内的资源使用状况动态感知，可以根据实际需求进行峰时扩容，低谷时缩容，避免资源浪费。这种灵活的资源调配方式可以有效降低计算资源的开销，降低硬件成本。提高运维效率：通过大规模自动化和面向终态的配置能力，减少部署和配置的复杂性。自动化的节点管理流程可以减少人工操作的错误和时间消耗，提高运维效率，降低节点运维成本和故障风险，使运维人员能够更专注于核心业务，提高整体运维人效。提高可用性和安全性：一致的执行环境可以大大降低应用程序出现异常的可能性。通过节点实时监控和节点自愈能力，可以及时发现并解决节点故障，确保应用程序的稳定运行，减少业务中断和损失。一、云原生节点管理概述11ContainerOS 概述Overview Of ContainerOS二、ContainerOS 概述12二、ContainerOS 概述云原生节点管理是以云原生理念为基础的实践方法论，主要目标是在满足日常运维需求的同时，有效应地应对大规模集群节点管理的挑战。而操作系统作为节点底座，是云原生节点管理的重要组成部分。1.传统操作系统在云原生场景面临的问题Linux 内核诞生至今已三十余年，催生出众多的 Linux 发行版与繁荣的生态。为了适应各种使用场景和各式各样的软硬件环境，传统的 Linux 发行版提供了复杂而完备的功能，包括硬件驱动、软件包、系统库和系统服务等。然而随着容器技术的出现，业务逐渐容器化，业务的运行依赖已经通过容器镜像实现了自包含。这意味着底层操作系统只需要支持容器运行时即可，不再需要提供大量的额外功能。在云环境中，云厂商的虚拟化技术使得硬件资源的管理变得简单，不再需要操作系统内核提供过多的硬件支持。因此，传统的 Linux 发行版在云原生场景下存在如下问题。问题一：体积臃肿面向通用场景的传统操作系统发行版内置了过多容器场景不会使用的软件包和系统库，提供的多余功能不仅导致镜像体积增大，还会占用多余的 CPU 和内存资源。此外，这些多余的系统服务和软件包还可能引入额外的安全风险，因为它们可能存在未修复的 CVE 漏洞。问题二：版本零散传统操作系统以软件包为粒度进行系统的管理，一个操作系统镜像的版本等同于里面所有软件包版本的合集。管理员对操作系统的管理需要细化到每一个软件包的版本，管理复杂度高，随着集群规模的增加，运维工作量往往成倍增加。二、ContainerOS 概述13问题三：运维方式落后集群内网络、存储、常规系统资源（如 CPU、内存）都可以通过 Kubernetes 进行管理，唯独操作系统自身是独立于集群的控制平面的，对操作系统的运维大多通过 ssh 直接登录系统进行操作，即我们常说的黑屏运维。运维粒度为单机，运维效率低、难以追溯且容易出错，大规模集群环境下极易导致集群内各个节点状态不一致的情况。而且操作系统自身的状态很难被 Kubernetes 感知并进行协同。2.ContainerOS 的设计原则为了应对上述一系列问题，同时给云原生用户带来更好的体验，专为容器负载而设计的容器优化操作系统应运而生，也就是我们通称的 ContainerOS。顾名思义，ContainerOS 聚焦在云上容器场景的功能与业务需求，这样得以摒弃传统操作系统大而全的设计理念和历史包袱。基于如下一些原则，我们设计了一款 ContainerOS。原则一：小型化与极速弹性因为 ContainerOS 并不存在通用操作系统的负担，可以专门为容器场景优化，包括容器网络性能优化，资源监控和控制能力优化等，配合更精简的系统设计，用以满足大规模集群中业务 Pod 极速伸缩的诉求。原则二：安全增强容器化技术使得应用的运行依赖通过容器镜像实现自包含，这样对底层操作系统的依赖减少。基于此前提，我们可以通过一些相对“激进”的手段来确保操作系统自身的状态处于预期的状态。比如，将根文件系统设计为只读以防非法程序或逃逸容器篡改底层操作系统、受控的运维通道、默认启用 SELinux 强制访问控制等手段，尽可能避免相对开放的云计算平台带来的安全风险。原则三：镜像原子更新与版本化管理二、ContainerOS 概述14像管理 GIT 代码仓一样管理整个操作系统，任何文件的变更可被记录成为一个新的版本，版本变更过程可记录、可追溯、可回滚。原则四：云原生场景开箱即用默认提供云原生场景必备组件，整个系统无需过多配置，用户仅需要关注自身的业务部署情况。3.ContainerOS 在云原生节点管理中的角色云原生节点管理提供了集群侧管理和节点侧管理两个维度的理论实践和工具集。这些工具和 ContainerOS 一起构成了可开箱即用的基础设施，帮助用户更好地理解和掌握云原生节点管理的最佳实践。1）节点侧管理节点侧管理的实现主要基于 ContainerOS 以及其内置组件。ContainerOS 为容器化业务进行了内核级的优化，促进容器化业务更快更平稳地运行。同时操作系统层面提供 API 支持以整个镜像为粒度的原子升级能力和类似于容器镜像的分层更新能力。分层变更是一种基于声明式规则的动态变更机制，它可以动态地变更操作二、ContainerOS 概述15系统、Kubelet 和容器运行时的版本和配置。这种变更方式采用叠加层的方式进行，可以支持变更回滚和历史版本回溯。操作系统原子升级能力提供了内核版本和系统软件包的升级能力。ContainerOS 支持新旧两个系统版本同时存在，这意味着节点可以在运行期间准备新版本的操作系统，只需一次重启操作，就能完成系统和软件包的升级，大大减少停机时间。同时支持版本快速回退，符合云原生场景下常用的 RollUp&RollBack 的灰度发布、回滚运维动作。2）集群侧管理在集群侧，多个控制器通过声明式配置的方式相互协作，完成集群内节点的全生命周期管理。Autoscaler 提供了基于规则的集群扩缩容能力。它根据预设的规则灵活地控制集群的节点数量，以满足不同的业务需求。无论是在业务高峰期还是低谷期，Autoscaler 都可以自动增加或减少节点，提高资源利用率，减少运维工作量，并保持集群的稳定运行。Machine Operator 支持统筹编排节点任务，基于 ContainerOS 的原子 API 和云平台的能力，对集群内节点统一管理，包括操作系统变更、核心组件升级等。Machine Operator使用声明式管理，通过定义节点期望版本和状态，支持全自动的分批操作。从而保证集群的一致性和稳定性。Configuration Operator 实现了对操作系统、Kubelet 和容器运行时配置的统一管理。不仅可以基于声明式配置对节点分批修改，也支持配置的版本管理，使得配置变更可追溯、可回滚。声明式和自动化的批量节点操作，减少了中间状态，提高了集群的运维效率，保证了集群节点的一致性、安全性和稳定性。二、ContainerOS 概述16ContainerOS 特性介绍Introduction to ContainerOS Features三、ContainerOS 特性介绍17三、ContainerOS 特性介绍操作系统作为软件与硬件之间的桥梁，一直扮演着重要的作用。尽管随着云原生相关基础设施、应用服务的蓬勃发展，操作系统的概念逐渐被弱化，但它仍然就像空气和水，在整个云原生架构中处于不可或缺的位置。ContainerOS 从一开始的设计上，便是聚焦在容器场景，旨在给容器提供稳定、安全、高效的运行环境。我们不仅从操作节点侧提供各种优化措施和流程，来简化和规范应用操作与部署的方式，更是结合 Kubernetes 控制平面，提供大规模集群下节点管理的最佳实践。1.专注于容器化应用ContainerOS 默认集成 Docker、containerd、Kubernetes 等常规云原生组件，同时最小化运行环境。内核层面，云厂商的虚拟化技术使得云主机内的硬件变得非常简单，我们不需要支持过多的硬件驱动，必备的内核模块构建为 build-in 模式，大幅简化 udev 规则，云主机系统盘基本固定为 virtio-blk 或 NVME 设备，主流根文件系统也相对固定，这样便不需要 initrd 来加载 rootfs，简化内核启动流程。BaseOS 层面，仅保留容器运行所需的软件包与系统服务，剔除不必要的语言包，简化 systemd 服务，软件包数量缩减至 200 以下，相比传统操作系统减少 60%，镜像大小减少 70%。轻量的操作系统在制作、部署和使用上会带来以下好处：较小的镜像大小：一方面，减少操作系统镜像的存储空间需求，节省存储成本，另一方面，可减少镜像的下载时间，这意味着更快的部署和迁移时间。更快的启动时间：精简的操作系统只加载必需的组件，以阿里云上的 ecs.g7.large（2vCPU，8G 内存规格云主机）为例，ContainerOS 的首次启动时间保持在 3s 以内。更少的资源消耗：更少的系统服务就意味着更低的 CPU 和内存占用，将更多的资源释放给用户。提高安全性：更少的软件包数量与系统服务意味着较少的潜在漏洞和需要修补的安全问题。三、ContainerOS 特性介绍18使用 ContainerOS 作为节点，在集群化管理时将会拥有更多的可用资源，相同的节点配置下，ContainerOS 可以部署更高密度的 Pod。Kubernetes 还提供了强大的自动化和扩展能力。管理员可以定义自动伸缩策略，根据负载情况自动调整 Pod 的副本数量。ContainerOS 的极速启动可以支持更激进的扩容策略，这意味着即使集群水位不足，在面对高负载业务压力时，Kubernetes 快速的自动扩展的 Pod 副本能够和节点同步横向扩容，而在负载下降时，它又能够自动缩减资源以节省成本。2.安全提升许多行业都有特定的安全标准和法规要求，如 GDPR 和 HIPAA，云计算行业也不例外，因为安全问题导致的业务数据泄漏问题可能招致法律诉讼、罚款和声誉损失。与相对封闭的传统 IT 系统相比，开放的云计算平台其实面临更大的安全风险，操作系统作为基础设施的基石，其安全性就变得尤为重要。为此，我们对 ContainerOS 应用以下设计原则与流程来提升其安全性：快速迭代发布 Pipeline传统操作系统发行版通常具备固定的发布周期，发布流程冗长，周期短则几个月，长则半年或者一年，这导致用户获取到的操作系统版本在部署之时，可能已经有不少软件包版本落后，甚至包含一些安全漏洞。对于 ContainerOS，我们将云原生 Devops 理念引入镜像的制作发布流程中，为了适应云原生场景快速的演进节奏，最快可按天发布新的镜像，尽最大可能确保用户始终可以获取到包含最新漏洞修复的镜像。同时，针对每一个发布的镜像，使用自动化工具和流程来进行持续的安全测试，并确保及时修复发现的问题。不可变基础设施原则容器化技术的出现使得应用与其运行依赖被一同打包发布，业务运行所需依赖与配置均由容器镜像提供，这给不可变基础设施的实现提供了技术前提。ContainerOS 的根文件系统在此前提下被设计为只读，恶意软件或攻击者无法对其进行修改或操纵。进一步地，可选择使用 EROFS 这样的只读文件系统，将安全性再提升一个台阶。强化访问控制与安全审计三、ContainerOS 特性介绍19默认启用 SELinux，实施严格的访问控制策略，限制容器对敏感资源的访问权限。使用强密码和密钥管理来保护容器的访问凭证。除此之外，根据行业内的安全测评机构要求，对操作系统进行安全加固配置。这包括关闭不必要的服务、限制特权访问、启用防火墙等。传统 IT 运维人员习惯于通过 ssh 服务登录系统进行一系列难以追溯的黑屏操作，在ContainerOS 中，ssh 服务被默认关闭，我们推荐用户通过 API 或运维容器进行操作系统相关的操作，这样一方面可以进行操作过程的记录和审计，另一方面降低误操作带来的安全风险。启用内核 Audit 功能，记录系统中的各种动作和事件，比如系统调用，文件修改，执行程序和系统登入登出等众多与安全相关的事件，并根据记录的信息，给用户推荐相应的安全改进建议。3.原子升级与镜像版本化一个拥有众多节点的集群经过长时间的运行和多次的运维操作之后，集群内各个节点的状态将很难保持一致，每一台服务器就像一片独特的雪花一样独一无二，难以复制，这便是非常知名的雪花服务器问题。如果集群内的节点状态、配置等存在差异，即使是部署相同的应用程序，或批量下发同样的命令，也很有可能产生不同的结果，甚至，同样的命令只能在部分节点上执行成功，在其余节点上则各自产生不同的错误，当集群规模越大，问题越凸显。大规模集群环境下的节点一致性问题一直是困扰集群运维人员的关键问题之一。传统操作系统以 rpm 为粒度进行升级，一个操作系统镜像的版本等同于众多软件包与配置的版本合集，这无疑给系统的运维带来极大的困难。相比之下，我们给 ContainerOS 提出镜像版本的概念，借助 OSTree 技术，用户可以像管理 GIT 仓库一样管理操作系统的版本，结合 Machine Operator，节点以整个镜像为粒度进行版本的轮转升级。每个镜像经过内部严格的测试之后才会上线，相较于传统操作系统基于单个 rpm 包的升级带来的不确定性，以镜像为粒度的测试发布更能保证升级后系统的稳定性。运维人员也不必再关注操作系统内部组件的变更，可将更多的精力放在业务连续性保障上。三、ContainerOS 特性介绍20然而，在实际的业务交付过程中，我们时常发现，部分业务场景可能会对操作系统镜像有一些特殊要求，这些要求包括但不限于修改系统配置、修改启动参数等。同一个ContainerOS 标准镜像不一定能完全覆盖所有的业务场景。此外，不可变基础设施（只读根文件系统）的设计一定程度上使得运行时修改操作系统变得更加困难。于是，提供一种灵活易用、且能够版本化记录变更的操作系统镜像定制工具就变得尤为重要。受到容器镜像分层技术（overlayfs）的启发，我们为 ContainerOS 提供分层变更的能力。通过 lifseacli 组件，用户可以采用类似于 Dockerfile 的方式，选择一个官方发布的基础镜像，按照 Dockerfile 的语法，进行一定程度的修改，再构建成为自己的镜像并推送到远端仓库。然后，在已经运行起来的系统中，拉取自定义的镜像层，并应用到当前的 Rootfs中。三、ContainerOS 特性介绍21节点的生命周期The Lifecycle Of A Node四、节点的生命周期22四、节点的生命周期如果说 Pod 是 Kubernetes 最小的调度单元，那么节点就是集群最小的组成单位。随着工作负载和节点不停的变化，集群始终在变化中动态平衡。从集群的层面看来，节点和节点上的工作负载并没有本质差异，只不过是被控制平面统筹管理的、具备不同能力的资源：同样具备创建、运行、销毁的生命周期，同样可能会因状态异常需要外部控制器介入协调。有太多对 Kubernetes 的介绍只强调了 day1 的节点初始化，但事实上节点加入集群后还有漫长的变配、升级、日常运维等 day2 操作。节点的日常运维和节点的创建销毁同样重要，就像保持 Pod 的正常运行和成功创建 Pod 同样重要一样。1.千节点扩容的弹性Kubernetes 集群支持以弹性伸缩的方式管理集群节点，当面临突发流量急需工作负载水平扩容时，弹性伸缩可以迅速增加节点数量，确保集群能够快速响应并保持高可用性。通过节点的弹性伸缩，集群可以在短时间内适应不断变化的需求，保证工作负载的正常运行。这种弹性能力使得业务能够轻松应对高峰期的流量，并在需要时自动缩容以降低成本。快速的弹性伸缩能力还可以提高集群的可靠性和容错能力。当集群中的节点出现故障或不可用时，节点扩容可以快速替换故障节点，确保集群水位足以支撑工作负载的持续运行。新扩容的节点迅速填补故障节点留下的空缺，减少服务中断的风险，减少业务感知，对于关键业务和可用性要求较高的应用场景至关重要。节点扩容重要的指标是扩容速度，一般情况下，使用通用性操作系统的单节点扩容耗时 1-5分钟不等。但在大量的节点扩容时，扩容速度除了单节点的启动时间，更依赖集群基础服务的性能，比如 API Server、容器镜像服务等，使用传统操作系统的大规模节点扩容时间可能会飙升至十几分钟。因此我们将千节点扩容作为重要的指标，以衡量集群的横向拓展能力。众所周知，容器的秒级启动使得大规模部署十分的便利，而当集群的千节点扩容具备 1 分钟内完成的能力时，集群的弹性也将具备极大的纵深。使得集群可以采取更激进的容量管理策略，更大密度的部署形态，更高的预警水位线。四、节点的生命周期232.节点运维监控工具和传统操作系统不同，只读根文件系统的设计使得 ContainerOS 仅需很少的运维干预，而面向大规模集群的设计理念，使得 ContainerOS 提供了更为简单的原子运维 API，以供外部控制器批量运维使用。常规配置变更，包括 sysctl、kubelet、容器运行时的配置，Configuration Operator 根据声明式配置中定义的期望节点配置，自动分批下发，确保目标节点配置一致。系统软件包的增减、升级操作，ContainerOS 提供了系统分层构建和更新的能力以应对增量和存量节点的更新。Machine Operator 通过统一管理，当包含新版本操作系统镜像就绪时，修改声明式配置的镜像信息。新的分层数据会自动下载到节点中，等待集群进入运维窗口后，对集群中的节点版本分批推平，仅需一次重启，便可使得节点升级到期望的操作系统版本。1）运维容器单节点的登录不应该成为常规的运维手段，为了提高系统的安全性，ContainerOS 原则上不支持直接登录实例进行操作，也不提供 ssh 登录功能。但为了满足用户的非常规的运维需求，ContainerOS 提供了一种新的解决方案：运维容器。通过启动并登录运维容器，用户可以进行系统的黑屏运维操作。相比主机，运维容器拥有更多的软件包，并且支持使用包管理软件 Yum 安装所需的软件包，以满足用户的调试需求。在运维容器中，用户可以轻松查看系统进程信息、网络信息、系统配置等关键信息，以便进行系统的监控和管理。将用户的操作隔离在运维容器中，一定程度上得以降低误操作带来的破坏性。四、节点的生命周期242）节点监控节点监控也是 day2 运维中不可缺失的一环。对节点进行实时的监控和管理，有助于及时发现节点的故障或异常情况，并触发相应的预警机制。除此之外，节点监控可以提供节点的性能指标和资源利用情况，帮助管理员了解节点的负载情况、瓶颈和优化空间。ContainerOS 除了支持常规监控组件如 Prometheus、kube-state-metrics、cAdvisor的部署之外，还提供 ECOS（Economical Cloud Native Operating System）工具集用于内核特性的友好配置、系统异常分析报告与常规内核监控指标的透出。ECOS 工具集主要分为以下几个部分：ECOS Configurator：ECOS Configurator 以更偏向于用户的视角，封装 ContainerOS内核提供的特性。通过提供一系列稳定的 API，屏蔽不同版本内核之间的配置差异，简化运维人员对内核特性的学习和使用成本。ECOS Analyzer：ECOS Analyzer 用于整机运行状态的分析，包括但不限于对磁盘用量、网络状态、内存压力、整机负载状态、kubelet和容器运行时健康状态等常规指标的检查，并提供异常分析诊断结果。ECOS Monitor：目前行业内大多数监控组件通过频繁多次调用不同的内核接口来获取四、节点的生命周期25监控指标，在高密度 Pod 部署或压力负载环境下，监控组件本身将会消耗让人难以忽视的系统资源，严重时甚至影响业务 Pod 的运行。ECOS Monitor 旨在以更轻量的形式透出内核的监控指标，技术上通过 eBPF 的形式聚合内核指标。上层应用、管控链路或运维人员仅需调用 ECOS Monitor 提供的少量聚合接口就可以获得常规的监控指标数据。3.节点声明式配置声明式配置是一种以声明方式描述期望状态的配置方法，它可以简化节点配置的过程和维护的复杂性。通过定义系统的期望状态，系统可以自动向期望靠拢，保持实现与之一致的状态。声明式配置也是 Kubernetes 的核心理念之一，它强调通过描述系统所需状态来定义所需的目标状态，而不是编写一系列命令来实现状态转换。在声明式配置中，用户通过 Yaml 文件定义期望的系统状态，然后将这些配置文件提交给 Kubernetes 控制平面。CRD（Custom Resource Definition）是 Kubernetes 中的一种常见的自定义资源扩展机制，CRD 允许用户定义自己的 API 资源类型，将自定义资源纳入 Kubernetes 控制平面的管理范围内。我们通过引入节点池自定义资源用于描述一组节点的期望状态，节点池是一个描述一组节点的逻辑概念，在同一个节点池中，节点具备相同的规格和架构，使用相同的基础软件版本和配置。通过定义有限个数的节点池，便可以轻松管理集群中所有的节点。四、节点的生命周期261）Configuration Operator节点池最重要的两个期望配置项是节点基础软件配置和机器配置。对于云原生场景来说，基础软件配置包含 sysctl、kubelet 和容器运行时的配置。在大规模集群中，软件配置的难度和复杂度在于配置一致和版本控制。在少数几个节点上执行没有问题的命令，在大规模集群却总会存在非预期的返回。而这种非预期的失败会加剧集群的不一致，导致后续的变配操作更容易因环境脏数据而失败。对存量节点修改完成后，往往还需要注意新增节点的配置，而常规运维中增量和存量的逻辑是分开管理的，不仅容易导致误配、错配、漏配，更导致配置的版本管理失效，在不同时间创建的节点拥有不同长度的版本树。Configuration Operator 通过简单的声明式配置，仅需要配置节点池的当前期望，一方面，Operator 会自动对当前的存量节点进行配置轮转，并对新创建的节点使用最新的期望配置。另一方面，配置管理可以直接复用节点池声明式配置的版本管理，从整个集群和节点池维度进行配置变更和版本回滚，使节点的管理不再受节点的生命周期影响。四、节点的生命周期272）Machine Operator节点机器配置主要包含节点规格、存储、网络、操作系统版本等。当需要对节点配置和系统软件栈变更时，仅需要修改对应的期望配置即可。当需要更改节点规格、存储、网络时，Machine Operator 会立刻修改新增节点模板，保证增量节点使用新的期望。同时，发起旧节点轮转任务，通过分批轮转操作，将节点池中的节点更新为期望状态。当需要对集群内的节点增删软件包，升级内核版本时，可以通过构建新的 ContainerOS 镜像并推送到 registry 中来实现。一旦推送完成，可以修改节点池的操作系统配置，不仅使得新的节点可以从 registry 中获取最新版本的镜像信息，同时，存量节点也会感知声明式配置的变化，根据 registry 中记录的分层元数据信息，将需要变更的分层更新到节点中。四、节点的生命周期28声明式配置管理带来了多个优势，不仅简化节点配置的过程和维护的复杂性。还可以避免黑屏运维带来的风险和错误。同时，声明式配置结合 ContainerOS 分层更新的能力，使得无论是存量节点还是新增节点，集群内的节点始终保持相同的配置，避免因为节点版本差异引发的非预期行为。另外，声明式配置还提供了可追溯性和版本控制的好处，可以更好的实践 IaC 理念，简化了问题排查和回滚操作。通过声明式配置和 git ops 相结合，追溯每个节点的配置历史和变更变得十分简单，这为系统维护和故障处理提供了便利。4.节点故障自愈节点故障自愈是指在集群节点池中，当节点发生异常时，自动进行节点恢复操作，以保持节点的正常运行状态。节点自愈功能包括问题诊断、恢复决策和恢复任务。节点故障自愈是通过将专家经验自动化，并根据故障特异性指标进行自动排查和故障恢复。自动化的前提是节点处于统一、可预期的状态。对于容器场景，业务应用通过 Pod 部署在节点中，通过存储卷持久化业务数据，通过 Lifecycle Hook 完成对 Pod 的生命周期管四、节点的生命周期29理，大部分节点上的配置并不会影响工作负载的行为。同时，ContainerOS 不可变的设计理念使得集群内的节点始终在可预期的状态。因此对于 ContainerOS 的节点，可以高度自动化的解决绝大部分的节点异常。当节点发生故障时，基于事件的控制器会快速感知异常，并根据故障原因，自动执行相应恢复任务。例如，如果 Kubelet 意外停止工作、PLEG 健康检查失败或 PodSandbox 残留，通过执行相应的恢复操作，使得节点恢复正常状态，如重启 Kubelet、清理PodSandbox、重启 ECS 实例等。节点自愈的好处不仅可以提高集群的稳定性和可靠性。系统自动的诊断和恢复节点异常状态，还可以减少手动排查和修复故障的时间和精力成本。更及时的发现节点异常情况，并在故障放大前采取相应的恢复操作。减少故障对用户的影响，提高了系统整体的容错能力。四、节点的生命周期30阿里云最佳实践和客户案例Alibaba Cloud Best Practices And CustomerCase Studies五、阿里云最佳实践和客户案例31五、阿里云最佳实践和客户案例1.在阿里云容器服务中使用 ContainerOS 实现极速扩容在阿里云容器服务 ACK 集群中实现弹性扩容，是一项基础、关键且被很多弹性场景的用户所十分看重的能力，尤其是在应对业务突发流量时，如何快速扩容节点、恢复资源水位对业务连续性至关重要。在节点自动伸缩场景，ACK 通过组件轮询判断集群内资源是否充足，一旦出现不足则自动触发扩容节点。如果在这种情况下，节点扩容速度慢，则会严重影响自动伸缩效果，甚至因为资源水位长期不足而影响用户业务。目前的节点扩容速度在 ACK 节点自动伸缩端到端耗时中占比超过 90%，可以说节点扩容速度的优化的程度决定了自动伸缩的体验。以某量化公司的扩容场景为例，在其长期提供服务的过程中，经过了上千次百节点级别的扩容活动，平均每次扩容 P90 节点就绪耗时（即单次扩容活动开始至 90%的节点处于就绪状态）超过 2min，耗时较长，且受网络抖动干扰大，时常出现部分节点就绪时间超长。若能将节点就绪时间稳定收缩在一个范围内，将大幅提高用户在节点扩容场景中的体验。为了达到上述效果，ContainerOS 基于 ACK 弹性扩容场景进行了端到端优化。通过预置集群管控必备组件的容器镜像以减少节点启动过程中因镜像拉取而带来的耗时，并结合ACK 管控链路优化（例如调节关键逻辑的检测频率、调整高负载下系统瓶颈中的限流值等），成功将节点扩容时间稳定控制在 1min 以内。五、阿里云最佳实践和客户案例32接下来介绍如何在 ACK 中配置使用 ContainerOS 实现节点极速扩容。1）前置条件已在 ACK Pro 创建 Kubernetes 集群，容器运行时为 Containerd，且 Kubernetes版本为 1.24.6 及以上，节点池类型为托管节点池。集群使用默认的网络插件（Terway）与存储插件（CSI）。2）操作步骤创建 ContainerOS 的节点池登录容器服务管理控制台，在左侧导航栏选择集群。在集群列表页面，单击目标集群名称，然后在左侧导航栏，选择节点管理 节点池。在节点池页面右上角，单击创建托管节点池。在创建托管节点池对话框，配置操作系统为 ContainerOS 类型，例如 ContainerOS1.26.3，并按需配置其他选项，然后单击确认配置。五、阿里云最佳实践和客户案例33关键组件限流调整如果您有同时启动大量节点（超过 100 个节点）的业务场景，建议进一步手动配置以下几个优化项以达到更好的弹性效果。部分 API 默认支持的最大连接数为 100，因此同时启动少于 100 个 ECS 节点时无需额外配置。KCM（Kube Controller Manager）限流调整登录容器服务管理控制台，在左侧导航栏选择集群。在集群列表页面，单击目标集群名称，然后在左侧导航栏，选择运维管理 组件管理。在组件管理页面的核心组件页签，定位到 Kube Controller Manager，然后单击卡片右下方的配置。在参数配置对话框，配置 kubeAPIQPS 为 800、kubeAPIBurst 为 1000，其余选项按需配置，然后单击确定。说明：基于测试数据，推荐您按照上方数值进行配置。如有其他需求，您也可以按照自身业务场景灵活配置。Kube Scheduler 限流调整登录容器服务管理控制台，在左侧导航栏选择集群。在集群列表页面，单击目标集群名称，然后在左侧导航栏，选择运维管理 组件管理。在组件管理页面的核心组件页签，定位到 Kube Scheduler，然后单击卡片右下方的配置。在参数配置对话框，配置 connectionQPS 为 800、connectionBurst 为 1000，其余选项按需配置，然后单击确定。五、阿里云最佳实践和客户案例34说明：基于测试数据，推荐您按照上方数值进行配置。如有其他需求，您也可以按照自身业务场景灵活配置。APIServer 数量调整集群内 APIServer 的副本数量根据负载进行弹性伸缩。如果同一时间弹出节点较多，APIServer 会自动进行扩容，一定程度上增加点就绪的耗时。若追求极致扩容时间，您可以提交工单，提前调整 APIServer 的副本数量，优化扩容效果。2.ContainerOS 助力阿里云 ECI 极致弹性阿里云弹性容器实例 ECI（Elastic Container Instance）是一款基于轻量级安全沙箱，面向 Serverless 场景的云产品。用户无需管理底层服务器，也无需关心运行过程中的容量规划，只需要提供打包好的容器镜像，即可在云上快速、安全地部署自己的应用，并仅为容器实际运行消耗的资源付费。随着云原生进入下半场，业界对容器启动速度、资源消耗、稳定性的要求越来越高，而这些也是 ECI 相对普通容器会面临的挑战。在 ECI 中，每个 Pod 之间都是 VM 级别的虚拟化安全隔离（安全沙箱），从安全沙箱创建、调度，到计算、存储、网络资源的初始化，再到应用启动，流程非常长。倘若安全沙箱使用传统操作系统，则单纯安全沙箱自身启动时间就可达分钟级，根本无法适应 ECI 所面临的大规模、突发流量的场景。除此之外，由于安全沙箱间内核隔离，过大的操作系统本身也会占用额外系统资源，无法达到机器高密度部署要求。因此，轻量、秒级启动的 ContainerOS 成为 ECI 安全沙箱 OS（GuestOS）的不二之选。五、阿里云最佳实践和客户案例35使用 ContaienrOS 作为 GuestOS 的 ECI 可以在 6 秒之内弹出 3000 个容器实例，成功支撑了弹性容器实例 ECI 业务每日最高超百万的创建量，通过极致的高密和弹性表现大幅增加业务的核心竞争力。不仅如此，ContaienrOS 除了提供轻量、极速的运行环境，还提供了快速迭代发布Pipeline，通过灵活和标准化的制作每个安全沙箱镜像，极大程度上降低 ECI 管控人员在镜像制作维护上的成本。镜像的制作、测试、发布周期可缩短至数小时，足以应对瞬息万变的云原生用户需求。3.蚂蚁安全科技镜像加速实践ZOLOZ 是蚂蚁集团旗下的全球安全风控平台，通过业内领先的生物识别、大数据分析和人工智能技术，为用户和机构提供安全又便捷的安全风控解决方案。ZOLOZ 已为中国、印尼、五、阿里云最佳实践和客户案例36马来西亚、菲律宾等 14 个国家和地区的 70 余家合作伙伴提供数字化转型过程中的安全风控技术支持。目前，已经覆盖金融、保险、证券、信贷、电信、公众服务等领域，累计服务用户超 12 亿。随着 Kubernetes 和云原生的大爆发，ZOLOZ 应用开始在公有云上进行大规模容器化部署。在公有云上容器化持续推进的当下，ZOLOZ 应用主要遇到如下挑战：集群机器拉起时间长，难以满足流量突增时，弹性自动扩缩容。拉取算法镜像耗时长，在集群扩容大量机器拉取镜像文件会容易导致集群网卡被打满，影响业务正常运行。针对 ZOLOZ 遇到的实际问题，ContainerOS 结合行业内多种相关解决方案，通过整合Nydus RAFS（Registry Acceleration File System）能力，支持用户构建 Nydus 格式的镜像。一方面，ContainerOS 通过简化 OS 启动流程，预置集群管控必备组件的容器镜像以减少节点启动过程中因镜像拉取而带来的耗时，极大地提高了 OS 启动速度，降低了节点扩容时间。另一方面，依托于 Nydus 与内核 EROFS 的优势，用户容器镜像得以进行块级别数据去重，大大降低了镜像的上传和下载数据量，Nydus 镜像提供按需加载能力，容器启动时仅需拉取少部分启动必需的数据，后续容器内业务 IO 请求哪些文件的数据，再从远端 Registry 拉取这些数据，这样避免镜像大量数据拉取阻塞容器的启动，大幅提升容器内业务就绪的时间。五、阿里云最佳实践和客户案例37ContainerOS 通过提供标准化、全流程的解决方案，以及更高的安全性和免运维的特点，给 ZOLOZ 整体的业务部署、研发效率、线上稳定性带来了质的飞跃。五、阿里云最佳实践和客户案例38尾声Conclusion六、尾声39六、尾声1.云原生节点管理的基本逻辑由于云原生技术的指数级增长，越来越多的业务和应用会运行在 Kubernetes 中，Gartner曾预测，2027 全球范围内将有 90%的应用以容器形态部署。而大规模的集群运维使得传统的集中式节点管理方式已经无法满足高效、灵活且可自动化的要求。云原生节点管理的核心目标，是基于云原生的理念，利用针对容器场景进行优化的操作系统和配套基础设施，实现自动化运维，以降低节点管理成本并提升生产效率。从节点维度上，ContainerOS 作为容器场景优化的操作系统，通过针对性剪裁，不仅减少系统资源的占用，提高节点利用率和安全性。也通过提供系统运维 API 和分层构建、更新的能力，使得节点运维和变更变得更加高效。从集群维度上，实现自动化运维是降低节点管理成本的关键。自动化运维能够减少运维人员的工作量，依托于操作系统提供的原子 API 和声明式配置，可以快速、准确地配置和部署节点，避免了手动操作可能引发的错误和延误。而节点的一致性和自动化使得自动诊断、节点故障自愈成为可能，这些优化措施共同提高了管理效率、降低人力成本，较少的人力投入足以维护规模庞大集群的正常运行。2.未来节点管理的发展趋势节点管理领域仍然具有广阔的发展前景。随着人工智能、大数据和边缘计算等新技术的发展和应用，节点管理将面临更多的挑战和机遇。一方面。这些新的技术和业务场景会对 Kubernetes 的使用和运维提出更高的要求，另一方面，这些新技术的发展也会反哺 Kubernetes 等基础设施，为节点管理带来更多的智能化和自动化的可能性。六、尾声40同时，随着 DevSecOps 的兴起，越来越多的人意识到容器和节点安全的割裂局面，节点管理还将面临更多的安全威胁和风险。未来也将更加注重节点安全和容器安全的统筹管理，包括容器安全加固、自动化安全性测试、审计和合规加固等措施。云原生节点管理作为一种全新的节点管理范式，是根据当前 Kubernetes 集群的使用局限性提出的系统化和工程化的解决方案。随着技术的不断前进和创新，云原生节点管理始终以云原生理念为指导，以具体的场景和痛点为抓手，面向未来的发展，迎接更广阔的机遇和挑战。六、尾声41白皮书作者（以下排名不分先后）彭媛洪陈海波

0人已浏览 2023-11-24 42页 5星级

云原生标准体系白皮书（2023）编委会名单编制单位：编制单位：中国电子技术标准化研究院、华为技术有限公司、蚂蚁科技集团股份有限公司、阿里云计算有限公司、腾讯云计算（北京）有限责任公司、浪潮云信息技术股份公司、北京百度网讯科技有限公司、中移（杭州）信息技术有限公司、浪潮电子信息产业股份有限公司、京东科技信息技术有限公司、北京凌云雀科技有限公司、中移系统集成有限公司、杭州谐云科技有限公司、中移（苏州）软件技术有限公司、安超云软件有限公司、中兴通讯股份有限公司编委成员：编委成员：杨丽蕴、陈行、汪维敏、李峰风、赵华、彭晋、郭智慧、吴涛、王永霞、何世友、李萌、颜秉泰、郑佳佳、崔凯、查丽、孙正君、喻涵、亓开元、张百林、韩冬、曹锐、田睿、王郁文、朱宇昕、边鹏旭、方佳伟、郭旸、隋成龙、李响、梁力晨云原生标准体系白皮书（2023）前言云原生正成为推动数字化转型和云计算跨越式发展的关键路径。从时代发展看，云原生是顺应数字中国与数字经济建设的重要模式；从产业升级看，云原生加速了全局创新效率与云上生态应用；从技术演进看，云原生代表着先进系统理念和软件生产力。2022 年，全国信标委云计算标准工作组（TC28/WG20）研判国内外云原生标准化重要趋势，在工作组下成立云原生专题组，系统性组织推进云原生标准化工作。2023 年，工作组报批国内首个云原生国家标准计划，启动了一系列云原生标准预研，并进一步组织产业界开展云原生标准体系研究，编制形成本白皮书。本白皮书主要围绕云原生标准化，研究分析国内外标准化历程和关键内涵，给出云原生标准体系的顶层设计、实施路径和建设内容，结合典型场景实践案例，为云原生服务提供商、技术开发者以及标准化从业人员等，系统性提供体系化的云原生标准化指导。版权声明：本白皮书版权受法律保护，凡转载、引用、摘编或以其它任何形式使用本白皮书内容，请务必注明来源出处，对违反者将追究法律责任。版权声明：本白皮书版权受法律保护，凡转载、引用、摘编或以其它任何形式使用本白皮书内容，请务必注明来源出处，对违反者将追究法律责任。云原生标准体系白皮书（2023）I目录一、云原生的标准化背景.1（一）云原生的定义史：从概念化到标准化.1（二）云原生的技术线：从体系化到标准化.4（三）云原生的应用面：从原生化到标准化.8二、云原生标准及组织.11（一）国际标准及组织.11（二）国内标准及组织.16（三）云原生开源项目及社区.20三、云原生标准体系.23（一）体系框架.23（二）建设内容.24附件：云原生标准化应用实践案例.29（一）商务服务.29（二）自动驾驶.31（三）电子政务.33（四）网络电商.35（五）能源化工.37（六）金融科技.39（七）银行货币.41（八）智慧家庭.42（九）医院医疗.44云原生标准体系白皮书（2023）II（十）互动娱乐.46云原生标准体系白皮书（2023）1一、云原生的标准化背景（一）云原生的定义史：从概念化到标准化（一）云原生的定义史：从概念化到标准化2023 年 6 月，由全国信标委云计算标准工作组（SACTC28/WG20，以下简称工作组）组织，华为技术有限公司、中国电子技术标准化研究院等近三十家企事业单位，完成编制报批了我国首个云原生领域国家标准信息技术 云计算 面向云原生的应用支撑平台功能要求。该文件给出了基于云原生支撑应用生存周期过程的平台功能框架，规范了支撑能力的功能要求，明确了“云原生”的标准术语定义，即：基于云计算架构设计和构建应用程序的技术集合与方法明确了“云原生”的标准术语定义，即：基于云计算架构设计和构建应用程序的技术集合与方法。利用云原生构建的应用具备弹性、敏捷、松耦合、易交付、易观测等特征。标志着“云原生”概念定义的首次国家标准化落地。标志着“云原生”概念定义的首次国家标准化落地。回顾云原生概念和技术演进过程，产业界对其内涵定义不断更新丰富，云原生的概念演进史传承着云计算发展史回顾云原生概念和技术演进过程，产业界对其内涵定义不断更新丰富，云原生的概念演进史传承着云计算发展史。2010 年 5 月，Paul Fremantle 在博客中首次提出 Cloud云原生标准体系白皮书（2023）2Native 架构概念，意在描述应用程序和中间件在云环境中的良好运行状态，并初步定义云原生架构应具备分布式、松散、多租户、自服务、按需计量计费、持续部署与测试等主要特征。2011 年，PaaS 提供商 Heroku 提出 12 因素(12-factor)，旨在引导促进更好地利用云计算 PaaS 能力构建 SaaS 或云原生应用程序。该 12 因素为：一个代码库，一个应用程序；依赖管理；设计、构建、发布和运行；配置、证书和代码；日志；易处理；后端服务；环境等价；管理进程；端口绑定；无状态进程；并发性。而后，Kevin Hoffman 修订增加了三个额外因素，即：API 优先、遥测；认证和授权。上述 15 因素后发展为著名的云原生架构设计经典方法论。2015 年，Pivotal 公司 Matt Stine 提出云原生应用具备的主要特征：符合 12 因素、微服务架构、自服务敏捷、基于 API 的协作以及抗脆弱性。后进一步将云原生凝练概括为：六大特质（模块化、可观察、可部署、可测试、可替换、可处理），及四大要点（DevOps、持续交付、微服务以及容器化）。云原生标准体系白皮书（2023）3同年，Google 联合 Linux 基金会成立 CNCF 组织，标志着云原生从概念理念加速步入开源产业化。CNCF 定义云原生为：云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。同时，CNCF 进一步建议云原生应用程序应采用6 大基础支柱：云及其基础服务模型；现代设计原则；微服务；容器化和容器业务流程；基于云的后备服务，例如数据库和消息代理；自动化，例如基础结构即代码和代码部署。总而言之，云原生的概念、定义、特性、理论和方法，随着产业发展与广泛应用而更加清晰。从概念定义看，云原生是一种更优利用云计算资源、服务和能力的架构理念，是一套更好构建和运行云上现代化应用程序的实践方法，是一个更加符合敏捷特征的先进技术体系。总而言之，云原生的概念、定义、特性、理论和方法，随着产业发展与广泛应用而更加清晰。从概念定义看，云原生是一种更优利用云计算资源、服务和能力的架构理念，是一套更好构建和运行云上现代化应用程序的实践方法，是一个更加符合敏捷特征的先进技术体系。云原生标准体系白皮书（2023）4（二）云原生的技术线：从体系化到标准化（二）云原生的技术线：从体系化到标准化发展至今，在云原生概念定义的指引下，目前形成了以容器、微服务、Serverless、Devops 等为典型代表的技术体系。其中，各个云原生关键技术点成为产业化提质增效的最佳实践，这些以点串线的云原生典型技术，通过标准化更加有效促进了技术体系的建设应用。标准化的容器单元开创了云原生应用部署的事实标准标准化的容器单元开创了云原生应用部署的事实标准。容器技术将应用及其所有依赖项打包，使应用不再受环境限制，在不同计算环境间快速、可靠地运行。Docker 容器引擎的开源，在很大程度上降低了容器技术的使用复杂性，加速了容器技术普及，极大提升了系统的应用部署密度和弹性。Docker 镜像的创新应用打包规范，解耦了应用与运行环境，使应用可以在不同计算环境间一致、可靠地运行。借助容器技术，让开发所需要的灵活性、开放性，以及运维所关注的标准化、自动化达成相对平衡。微服务架构标准化开创了云原生应用模块化设计标准微服务架构标准化开创了云原生应用模块化设计标准。微服务架构作为一种分解复杂应用的方法，被纳入到软件开发的体系中。通过应用内部的解耦和拆分，以实现更好的可扩展性和故障隔离性。容器技术的出现是使微服务架构走向标准化的关键因素之一，特别是 Docker 的普及，为微服务提供了一种统一的、轻量级的部署和运行环境。这种环境隔云原生标准体系白皮书（2023）5离技术解决了微服务架构中的许多挑战，为微服务的开发、部署和管理提供了一种一致性的解决方案。面向服务模式的标准化设计帮助应用架构全面升级面向服务模式的标准化设计帮助应用架构全面升级。服务化架构是符合企业发展需求和应用趋势的新型软件设计方法，通过微服务、服务器无感知（Serverless）、服务化网格等技术，帮助企业实现从单体应用到服务化架构的升级，让企业开发者更关注业务本身，无需关注基础设施，实现应用环境标准化，有效简化应用迁移与托管，提高编排和运维效率。此外，FaaS、BaaS 等为用户屏蔽云端复杂度，简化云应用开发，提高应用开发上线效率。更灵活的管理闲置资源，进一步提升了系统资源利用率。此外，组装式交付通过低代码、应用集成等技术，快速复用基础组件，通过简单的托拉拽实现快速交付新应用。标准化的统一管控调度实现异构资源的高效协同标准化的统一管控调度实现异构资源的高效协同。智能调度、微服务、动态编排等技术为应用提供了统一的资源池，让多种应用可以混合部署。通过这种面向应用的调度，可在同一集群内支持多种不同的应用类型，借助业务资源请求互补性大幅提升资源使用率、减少应用运维成本。同时，随着应用资源的急剧增加，多维资源调度统一计算节点技术将在调度方面实现资源分层、协同调度，通过屏蔽多元化算力资源差异，以精细化调度进一步实现资源利用率的有效提升。云原生标准体系白皮书（2023）6可观测能力与应用交付管理能力的标准化进一步完善IT 成 本 优 化可观测能力与应用交付管理能力的标准化进一步完善IT 成 本 优 化。随 着 云 原 生 技 术 社 区 Prometheus、OpenTelemetry、OpenMetrics 等项目发展，应用可观测性领域在日志、监控、链路追踪等领域进一步标准化和融合，使得多指标、根因分析的数据集更加丰富。此外，Kubernetes声明式 API、面向终态的应用交付方式，提供了更加一致的管理运维体验。Service Mesh 非侵入的数据遥测能力以及服务流量管理能力，可以在不修改现有应用的前提下获取更加丰富的业务指标，提高 AIOPS 的 AI 层面准确率和覆盖率，并实现以透明的方式对应用进行管理和自动化运维。分布式云原生技术帮助客户统一规划、调度、运维多个云提供商的容器云平台以及不同物理位置的集群资源分布式云原生技术帮助客户统一规划、调度、运维多个云提供商的容器云平台以及不同物理位置的集群资源。关键技术包括分布式云治理、全域应用调度、全域流量调度、流量跨云协同、数据跨云协同等，其中如分布式云治理技术支持多地域基础设施的统一注册、认证、访问、配置、分区管理以及合规治理，提供统一入口和管理工具，降低客户学习成本和操作复杂度。全域应用调度技术帮助用户掌控全域资源动态信息，包括接入位置、网络 QoS、可用资源等，根据业务 QoS、亲和性、时长等要求提供不同的全域调度算法和推荐实例资源，协助客户优化成本。多活高可用、全局负载均衡等韧性技术，实现多活应用部署、自动诊断、MTTR 恢复的分钟级效率多活高可用、全局负载均衡等韧性技术，实现多活应用部署、自动诊断、MTTR 恢复的分钟级效率。多活高可用可以云原生标准体系白皮书（2023）7保证应用在不同的地域或可用区同时运行，提高应用的可靠性和稳定性。全局负载均衡可以根据应用的流量和性能情况，动态地分配和调整请求到最优的服务节点，从而实现负载均衡和故障转移，提高应用的响应速度和用户体验。自动诊断、恢复（MTTR）可以利用智能的监控和分析技术，快速地发现和定位应用的故障和异常，从而实现自动化的修复和恢复，提高应用的恢复时间和效率。在未来支撑企业深度用云的趋势下，驱动计算、存储、网络等基础实施围绕应用将进一步优化，催生构建云原生2.0 技术体系，涵盖软硬协同、服务网格、云原生存储等。深度软硬协同能力为客户提供近裸机体验的性能，同时降低通过软件实现网络、存储等功能的 CPU 开销。服务网格则以更加解耦的方式将服务治理能力变成独立进程，对应用访问进行非侵入管理，全面提升应用治理能力。基于独立存储网络通道、Operator 机制等技术，容器存储的共享存储网络吞吐受限，以及虚拟化性能折损、跨级全迁移等难点问题将有效解决。云原生标准体系白皮书（2023）8（三）云原生的应用面：从原生化到标准化（三）云原生的应用面：从原生化到标准化云原生“为云应用而生”，为完善云应用的生命周期管理保障，标准化的技术和管理理念，加速推动了以“应用原生化”为核心的持续开发交付、稳定性保障、运维自动化、系统可观测等管理模式变革加速推动了以“应用原生化”为核心的持续开发交付、稳定性保障、运维自动化、系统可观测等管理模式变革。云原生应用开发与交付的标准化，有效革新了应用开发模式、提升了软件交付效率云原生应用开发与交付的标准化，有效革新了应用开发模式、提升了软件交付效率。传统开发方法存在过多重复性、烟囱式工作，技术和人力投入成本高，导致软件应用交付周期长、定制能力弱，进一步积压业务需求，难以敏捷响应快速变化的市场需求。DevOps 开发运维一体化通过标准化和自动化方法，显著加快应用开发、测试和部署。通过对 DevOps全流程的标准化管理与实施，有效提高“开发-测试-发布-运维”各环节研发工具的支撑能力和一站式服务水平。实现随时随地在云端享受代码托管、代码扫描、流水线管理、代码编译、镜像构建、应用部署发布等功能和服务。此外，DevSecOps 主张将安全性嵌入 DevOps 各环节，以便在开发过程早期识别安全问题，作为敏捷、DevOps 的延续和趋势，是打通管理与协同、设计与开发、CI/CD、应用管理、运维、安全可信等全链条各环节的一体化理念、技术和方法。同时，低代码无代码相关产品标准化，进一步统一产品功能要求、应用范围和服务能力，满足企业对于数字化业务需求快速响应、快速开发的目标。低代码无代码技术降低应云原生标准体系白皮书（2023）9用开发准入门槛，使非开发人员利用图形化界面，以拖拉拽方式快速搭建软件应用，以搭积木方式组成满足各类需求的应用产品，减轻对专业工程师的依赖，降低人力和时间成本。此外，应用程序的构建和部署极易出错，在繁杂的代码中识别错误会拖慢开发进度。通过标准化的 CI/CD 工具自动将新引入代码进行测试和集成，保证生成可部署的应用，并将其推送至生产环境，极大提升开发效率。可观测性技术和工具的标准化，保障业务系统稳定运行。可观测性技术和工具的标准化，保障业务系统稳定运行。云原生体系下的应用由单体架构转换为微服务架构，同时给运维管理带来全新挑战。一方面，数量众多的微服务之间互相调用的关系极为复杂，使用传统运维方式难以掌握业务系统整体的运行状态;另一方面，微服务架构下系统环境动态性增强，每个服务实例存在周期极短，系统复杂度提升而导致日志数据大规模增加，给系统根因定位带来极大挑战。由此，云原生的运维管理也从传统的被动监控系统数据转向主动观测应用关联的各类数据。通过对可观测性相关管理和实施，使得业务系统发生故障时能够迅速进行根因定位，提高故障修复效率。云原生应用运维标准化，有效保障信息系统的可靠性、安全性和业务连续性云原生应用运维标准化，有效保障信息系统的可靠性、安全性和业务连续性。随着企业核心业务系统由云化演变为云原生化，为客户提供更好的安全可靠容灾备份、流量治理等解决方案成为云原生标准体系考量的关键因素。由于云原云原生标准体系白皮书（2023）10生稳定性保障工具与传统方式不同，为了更主动的探测系统潜在故障，云原生技术体系衍生出以混沌工程为代表的新型管理工具，充分保障复杂的分布式系统稳定运行。通过标准化的监控、日志和指标收集，帮助开发和运维团队全面了解应用程序的运行状况，及时发现和解决问题，提高应用的稳定性和性能。在未来，软件业务模块规模化、部署环境多样化、系统架构复杂化等程度进一步加剧，对于软件研发迭代、运维运营保障、企业组织管理等多方面提出了极大挑战。在云原生场景下，软件应用服务围绕需求诉求对应构建，云原生架构将非功能性特性从业务代码中剥离到云计算基础设施中，使得业务开发人员专注于业务逻辑开发，有效降低企业上云用云的门槛和心智负担。随着云原生技术的不断发展，全面云原生时代将为企业数字化和智能化转型，谱写体系化改革新篇章。云原生标准体系白皮书（2023）11二、云原生标准及组织（一）国际标准及组织（1）ISO/IEC（一）国际标准及组织（1）ISO/IEC国际标准化组织（ISO，International Organizationfor Standardization）是目前世界上最大、最有权威性的国际标准化专业机构。其目的和宗旨是“在全世界范围内促进标准化工作的发展，以便于国际物资交流和服务，并扩大在知识、科学、技术和经济方面的合作”。其主要活动是制定国际标准，协调世界范围的标准化工作，组织各成员国和技术委员会进行情报交流，以及与其他国际组织进行合作，共同研究有关标准化问题。国 际 电 工 委 员 会（IEC，InternationalElectrotechnical Commission）负责有关电气工程和电子工程领域中的国际标准化工作，其宗旨是促进电气、电子工程领域中标准化及有关问题的国际合作，增进国际间的相互了解。目前，IEC 的工作领域已由单纯研究电气设备、电机的名词术语和功率等问题扩展到电子、电力、微电子及其应用、通讯、视听、机器人、信息技术、新型医疗器械和核仪表等电工技术的各个方面。目前，自联合开发基金会（JDF）被批准为 JTC1 PAS 提交人后，ISO/IEC JTC 1/SC 38 已开展研究合作可能性。由于云计算的创新动力源于众多 OSS 项目（如 Docker、云原生标准体系白皮书（2023）12Kubernetes 等），SC 38 正与 JTC 1 密切合作，研究云计算开放源码项目涉及的接口规范等标准化工作。（2）ITU（2）ITU国际电信联盟（ITU，International TelecommunicationUnion）是由法、德、俄等 20 个国家在巴黎会议上为了顺利实现国际电报通信而成立的国际组织，其实质性工作由国际电信联盟标准化部门、国际电信联盟无线电通信部门和国际电信联盟电信发展部门等三大部门承担。其中电信标准化部门由原来的国际电报电话咨询委员会（CCIR）和标准化工作部门合并而成，主要职责是完成国际电信联盟有关电信标准化的目标，推进世界范围内的电信标准化。2022 年 7 月，ITU-T（国际电信联盟电信标准化部门）SG13 立项Requirements of next generation networkevolution to support container-based network entities项目，是 ITU-T 在电信网络中首次引入云原生技术应用的标准，是我国运营商在推动网络云原生国际标准工作的里程碑。该项目提出在下一代网络演进中，引入容器化网元来解决虚拟化网元的启动慢、交付时间长、资源利用率低等问题，项目范围包括对容器基础设施、网元以及对容器化网元管理系统等方面要求。2023 年 4 月，ITU-TSG13 完 成 报 批 Cloudcomputing Functional requirements of Platform as a云原生标准体系白皮书（2023）13Service for cloud native application（云原生应用 PaaS功能要求）标准。该标准定义了 PaaS 服务场景、PaaS 能力类型、云原生概念、云原生应用基本设计原则、典型云原生技术等，面向云原生应用的开发、测试、部署、运维等环节共提出 43 条 PaaS 功能要求，覆盖容器资源、DevOps、可观测性能力、微服务管理、数据服务、流量控制、PaaS 服务管理等。该标准填补了 ITU 云计算标准体系中 PaaS 领域标准的空缺，为业界提供了云原生 PaaS 基本能力参考。2023 年 7 月，在 ITU SG13 WP2 会议上立项云间容器管理 功 能 架 构 标 准（CloudcomputingFunctionalarchitecture of container management in inter-cloud），持续推进算力网络泛在算力调度领域标准布局。此次中国移动在 ITU 主导的云间容器管理功能架构标准立项，针对跨多云的容器算力管理架构、关键功能设计、业务流程与参考接口等内容进行研究和标准制定，加速推动多云容器管理架构与关键方案的成熟发展。该标准填补了该技术领域在 ITU 组织的架构标准空缺，为算力网络多方云原生算力互联互通技术方案实现提供重要技术参考。（3）ETSI（3）ETSI欧洲 电信 标准学 会（European TelecommunicationStandards Institute，ETSI），是制定和发布欧洲电信标准的非营利性区域组织，总部设在法国尼斯。1987 年，欧共云原生标准体系白皮书（2023）14体委员会在其发表的关于发展欧洲电信政策绿皮书中，建议成立一个欧洲电信标准化机构，以加速制定和协调电信标准，推动欧洲统一电信市场的建立。ETSI 是第三代合作伙伴计划（3GPPTM）的国际合作伙伴，参与研究和制定 4G 和 5G移动通信标准，也是物联网国际标准化伙伴组织（OneM2M）发起者之一，共同制定机器对机器通信标准。2023 年 6 月，ETSI 多接入边缘计算行业规范小组（ISGMEC）发布白皮书，详细阐述了“边缘原生”的概念和愿景，指导开发人员了解边缘计算的原则和特定要求，以及如何将它们与云原生引入的现代架构方法相结合。多接入边缘计算通过采用基于云的技术，如虚拟化、基于服务的管理和异构硬件管理，为部署和管理边缘应用程序提供了灵活的环境。自 2014 年成立以来，ISG MEC 一直致力于通过标准提供互操作性足迹、确保普遍采用 API 设计原则，进一步充分利用边缘功能并采用应用程序开发的边缘原生设计原则，则需要开源和标准的共同努力。2023 年 5 月，ETSI 发布 Evolving NFV towards the nextdecade白皮书，该白皮书旨在探讨 NFV 未来十年的发展方向与关键驱动力，为未来的 NFV 技术和市场趋势的探索提供指 导。NFV 即 网 络 功 能 虚 拟 化（Network FunctionsVirtualization），是指利用虚拟化技术在标准化的通用 IT设备（如 X86 服务器、存储、交换设备等）上实现网络功能。云原生标准体系白皮书（2023）15NFV 的目标是取代通信网络中私有、专用和封闭的网元，实现统一通用硬件平台和业务逻辑软件的开放架构，将对未来通信网络发展产生重大影响。此外，ETSI GS Cloud Native Architecture提供了云原生应用程序设计和架构指南，包括最佳实践、技术要求和设计原则，旨在帮助开发人员在构建云原生应用程序时提高弹性、可伸缩性和可靠性。ETSI GS Cloud Automation提供了自动化云原生基础架构和应用程序的指南，包括自动化部署、配置和管理等方面，旨在帮助提供商和服务提供商实现高效、可靠和可扩展的自动化云原生系统。ETSI GSCloud Data Management提供了云原生数据平台的设计和管理指南，包括数据存储、数据处理和分析等方面，旨在帮助开发人员和提供商构建高效、可扩展和可靠的云原生数据平台。ETSI GS Cloud Container和ETSI GS CloudMicroservices Architecture等有关容器技术和微服务架构的标准，提供了容器技术和微服务架构的通用框架和指导，支撑构建高效、可伸缩和可靠的云原生应用程序。（4）3GPP（4）3GPP第三代合作伙伴计划（3rd Generation PartnershipProject，3GPP）成立于 1998 年 12 月，由中美日欧等七个国家和地区的电信标准组织联合成立，是全球范围内最具影响力、最重要的移动通信标准化组织。云原生标准体系白皮书（2023）162023 年 7 月，3GPP SA(业务与系统)全体会议通过了 Study on Management of Cloud Native VirtualizedNetwork Functions（云原生化 VNF 管理研究）项目结项和相关新标准项目立项。其中，已结项的 FS_MCVNF 研究项目输出的 TR 28.834 是 3GPP 在云原生化 VNF 领域的首个研究项目文件，围绕云原生化的 VNF 的创建、配置、性能、故障等管理方面展开需求、用例和解决方案研究，填补了 3GPP网络云原生标准领域的空缺，为电信行业促进网元的云原生化发展起到重要推动作用。同时，通过立项标准项目后续将遵循云原生设计原则的虚拟化网络功能，提出相关的标准化管理需求及解决方案，该立项进一步推进了中国在 3GPP 网络云原生领域的标准布局。此外，如 3GPP TR 24.802 标准提供了关于移动网络中云原生应用的要求和架构，包括云原生应用的定义、云原生平台的要求和云原生平台的架构等。旨在为移动网络和服务提供商构建云原生应用架构提供指导。（二）国内标准及组织（1）全国信标委云计算标准工作组及云原生专题组（二）国内标准及组织（1）全国信标委云计算标准工作组及云原生专题组2012 年，经全国信标委第一次主任委员办公会审议，决定成立全国信息技术标准化技术委员会云计算标准工作组，负责云计算领域的标准化工作，包括云计算领域的基础、技术、产品、测评、服务、安全、系统和装备等国家和行业标云原生标准体系白皮书（2023）17准的制修订工作，对口 ISO/IEC JTC1 SC38。2022 年，立足新发展时期我国云计算技术与产业应用生态建设诉求，为更好地响应与时俱进的产业标准化需求，推进建设我国云计算高质量标准体系，在第十一届中国云计算标准和应用大会上，工作组正式宣布下设成立首批专题组，统筹加速推进云计算国家标准化。云原生专题组作为首批成立的重点专题组之一，承担着完善新一代云计算标准体系建设的关键任务。2023 年 6 月，云原生专题组完成报批了信息技术 云计算 面向云原生的应用支撑平台功能要求国家标准计划。该标准历时两年时间完成，近三十家重点单位、超过百余位行业专家参与过程研制，是我国云原生领域首个批准立项并完成编制的国家标准。该标准围绕应用开发交付、运行、运维、管理等生存周期过程，规范了云原生支撑平台的功能性要求。为用户理解采用云平台 PaaS 服务提供指导，同时将有力配合工信部政策导向，指导和规范各厂商的应用支撑平台服务，推动实现应用深度上云，支撑行业数字化发展。此外，全国信息技术标准化技术委员会云计算标准工作组自 2016 年以来，已面向云原生容器、存储、DevOps 等典型技术领域，研究形成了一系列重要成果，包括基于开源技术的云计算系统实现指南 2.0企业级容器云平台技术要求信息技术 云计算 云开发通用技术要求等团体标云原生标准体系白皮书（2023）18准，以及容器技术及其应用白皮书开发运维一体化两岸共通标准研究报告云开发技术实践白皮书云原生内存数据库技术及标准化白皮书（2020）等。在 2023 年，依托云原生专题组进一步启动了 Serverless 服务能力、可观测性体系等标准化研究。（2）开放原子云原生工作委员会（2）开放原子云原生工作委员会2023 年 6 月，开放原子开源基金会联合 29 家单位倡议，号召国内云产业相关企业、机构，共同发起开放原子云原生工作委员会，共建、共治、共享，推动云原生技术的创新发展。云原生工作委员会旨在通过构建开源、开放的云原生技术生态，探索云原生技术创新，推进云原生技术在中国发展，赋能千行百业数字化转型。目前，委员会在云原生和容器领域已发布相关标准和研究 成 果。如 OpenContainerInitiative(OCI)Specifications标准是由开放容器倡议（OCI）制定的容器镜像和运行时规范，定义了容器镜像的格式、创建、验证和分发的标准，以及容器运行时的行为和接口的标准，规范了容器的可移植性和互操作性。CNCF Cloud NativeInteroperability Initiative(CNSI)旨在促进云原生技术互操作性，定义了云原生系统关键组件和接口的标准，包括容器平台、服务网格、存储和数据库等，促进不同解决方案的相互集成和协同协作。CNCF Serverless White Paper云原生标准体系白皮书（2023）19给出了无服务器计算的概念、优势、应用场景和最佳实践等，为开发人员和架构工程师提供具体指导。（3）中国电子工业标准化技术协会（3）中国电子工业标准化技术协会中国电子工业标准化技术协会（China ElectronicsStandardization Association，CESA）是全国电子信息产业标准化组织和标准化工作者自愿组成的社会团体。协会宗旨是团结和组织全国电子信息产业标准化组织和标准化工作者，加强电子信息产业各有关部门、地区、企事业单位之间的联系、协调与合作，开展电子信息产业各技术领域标准化活动，加强国际交流，提高电子信息产业标准化的科学技术水平，推动电子信息产业标准化工作，促进电子信息产业高质量发展。2023 年 4 月，CESA 公示云原生数据库技术要求团体标准，该标准明确了云原生数据库定义，确定了云原生数据库的基础功能、技术特性、安全能力和运维管理能力。该标准顺应云计算发展趋势，指导各行业数据库实现云原生化，为数据库上云起到良好的引导和规范作用，促进数据库与云计算技术更好的融合利用。此外，如 2020 年 7 月发布云计算原生平台技术要求和测试方法标准，规定了云计算原生平台的技术要求和测试方法，包括平台架构、功能要求、性能指标、安全保障等方面要求。云原生应用容器技术要求和测试方法标准规云原生标准体系白皮书（2023）20定了云原生应用容器的技术要求和测试方法，包括容器镜像、容器运行时、容器编排等方面要求。（三）云原生开源项目及社区（三）云原生开源项目及社区云 原 生 计 算 基 金 会（CloudNativeComputingFoundation，CNCF）成立于 2015 年 12 月，致力于云原生技术的普及和可持续发展。CNCF Landscape 给出了云原生路线图和全景图。其中，路线图（Trail Map）是 CNCF 指导云原生用户使用开源项目以及推荐相关云原生技术，其包括十个步骤，各步骤是用户或平台开发者将云原生技术在实际环境中落地时，需要循序渐进思考和处理的问题，指导用户基于路线图选择供应商产品或开源项目。云原生全景图从云原生的层次结构和不同功能组成上，让用户了解云原生体系的全貌，帮助用户面向不同组件层次选择适用的软件和工具。目前，“Docker Kubernetes”是云原生最关键的开源项目之一，成为资源调度和容器编排领域的事实标准目前，“Docker Kubernetes”是云原生最关键的开源项目之一，成为资源调度和容器编排领域的事实标准。2013年，Docker 容器技术正式发布，容器技术开始普及。大量容器的共同参与催生了进一步容器统筹工具的需求，在此背景下，2014 年 Google 发布容器编排工具 Kubernetes，凭借较高的社区活跃度及丰富的组件，于 2017 年脱颖而出，成为了容器编排的事实标准，市场份额远超其他厂商。目前在容器底层技术领域，“Docker Kubernetes”已成为主流。KubeSphere 是在 Kubernetes 之上构建的开源容器平KubeSphere 是在 Kubernetes 之上构建的开源容器平云原生标准体系白皮书（2023）21台，提供全栈的 IT 自动化运维能力，极大简化企业 DevOps工作流台，提供全栈的 IT 自动化运维能力，极大简化企业 DevOps工作流。KubeSphere 将前端与后端分开，实现面向云原生的设计，后端各功能组件可通过 REST API 对接外部系统。KubeSphere 无 底 层 的 基 础 设 施 依 赖，可 运 行 在 任 何Kubernetes、私有云、公有云、VM 或物理环境（BM）之上。此外，能够支持部署在任何 Kubernetes 发行版上。Kube-OVN 是全球首个被 CNCF 纳入托管的开源容器网络项目，是容器网络领域最具代表性和影响力的开源项目之一Kube-OVN 是全球首个被 CNCF 纳入托管的开源容器网络项目，是容器网络领域最具代表性和影响力的开源项目之一。支持跨云网络管理、传统网络架构与基础设施的互联互通、边缘集群落地等复杂应用场景，增强了 Kubernetes 容器网络的安全性、可运维性、管理性和性能。目前，Kube-OVN已成为开源社区最受欢迎的 Kubernetes 网络解决方案之一，在 Github 镜像下载量超 230 万，社区成员突破 3 千人，已实现上千集群级别的大规模企业级项目、海外项目落地和商业化探索，成为国内容器网络领域主流方案。此外，一系列云原生关键开源项目以标准化的理念，不断完善着云原生生态建设此外，一系列云原生关键开源项目以标准化的理念，不断完善着云原生生态建设。如开源监控软件 Prometheus 为云原生应用程序提供实时监控、警报和时间序列数据库功能，集成许多流行的开源数据导入、导出工具,已成为监控基于容器的基础设施的标准。Containerd 是工业级标准容器运行时组件，注重简单性、健壮性和可移植性，可在宿主机中实现便捷的容器镜像传输、存储、容器运行时等全生命周云原生标准体系白皮书（2023）22期管理。gRPC 是高性能 RPC（远程过程调用）框架，面向移动应用开发并基于 HTTP/2 协议标准设计，支持插件灵活扩展、双向流传输、负载均衡、运行状况检查和身份验证等。云原生标准体系白皮书（2023）23三、云原生标准体系（一）体系框架（一）体系框架结合国内外云原生技术演进趋势和产业化应用需求，为系统性、全局性推进云原生标准化工作，明确云原生标准化建设路径与规划，指导具体标准的立项与制修订，基于产业界云原生领域主要代表和实践方，研究形成云原生标准体系见图 3-1。包括“A 基础”、“B 技术与服务”、“C 管理”、“D 评估评价”四个部分。图 3-1 云原生标准体系其中，“A 基础”主要规范统一云原生相关概念和架构，为制修订其他各部分标准提供支撑，包括术语、架构、安全等方向的基础类标准。“B 技术与服务”主要规范云原生关键技术、服务/产品等方面的研发、设计与使用，包括容器、微服务、中间件等方向的标准。“C 管理”主要规范云原生涉及的应用开发交付、运行保障和服务运营等方面的生命周期管理，包括开发与交付、可观测性、稳定性保障、计量与计费等方向的标准。云原生标准体系白皮书（2023）24“D 评估评价”主要规范指导云原生化改造和能力建设，包括能力成熟度、评价指标等方向的标准。（二）建设内容（1）A 基础（二）建设内容（1）A 基础包括“AA 术语”、“AB 架构”、“AC 安全”等 3 个研制方向。其中：1）AA 术语规定容器、Serverless、FaaS、BaaS、Service Mesh 等云原生相关的角色、技术、概念、模式等术语定义，统一云原生认识与理解，为制修订其它标准提供指导。2）AB 架构规定微服务架构、Serverless 架构、存算分离架构等云原生相关架构或参考框架，为设计、开发和使用云原生系统及其能力提供指导。3）AC 安全规定云原生的应用安全、研发运营安全、数据安全、运行环境安全等方面的安全能力、安全框架或安全指南，为云原生生态和系统建设提供安全保障。（2）B 技术与服务（2）B 技术与服务包括“BA 容器”、“BB 存储”、“BC 网络”、“BD 中间件”、“BE 微服务”、“BF 服务网格”、“BG 调度”、“BH Serverless”、“BI 其它”等 9 个研制方向。其中：云原生标准体系白皮书（2023）251）BA 容器规定云原生容器集群、容器服务、容器接口、容器平台、容器管理等方面的技术要求、能力规范或产品功能，指导云原生容器的技术研发、产品选型及服务应用。2）BB 存储规定云原生分布式存储、对象存储、块存储、文件存储、云原生数据库等方面的技术要求、能力规范或产品功能，指导云原生存储的技术研发、产品选型及服务应用。3）BC 网络规定云原生网络功能、通信协议、网关服务、设备系统等方面的相关要求，指导云原生网络的建设与应用。4）BD 中间件规定云原生消息中间件、事务处理中间件、数据集成中间件、工作流中间件、安全中间件等方面的技术要求、能力规范或产品功能，指导云原生中间件的技术研发、产品选型及服务应用。5）BE 微服务规定云原生微服务方面的技术要求、能力规范或产品功能，指导云原生微服务的技术研发、产品选型及服务应用。6）BF 服务网格规定云原生服务网格相关的服务能力、交互协议、资源接口、服务质量等，指导云原生服务网格的技术研发、产品云原生标准体系白皮书（2023）26选型及服务应用。7）BG 调度规定云原生资源调度、分布式任务调度、服务编排调度等方面的技术要求、能力规范或产品功能，指导相关技术研发、产品选型及服务应用。8）BH Serverless规定云原生 Serverless 弹性伸缩、托管服务、BaaS API等方面的技术要求、能力规范或产品功能，指导 Serverless技术研发、产品选型及服务应用。9）BI 其它规定云原生与 AI、大数据等跨技术或跨场景融合应用方面的技术要求、能力规范或产品功能，指导云原生的生态建设与示范应用。（3）C 管理（3）C 管理包括“CA 开发与交付”、“CB 可观测性”、“CC 稳定性保障”、“CD 计量与计费”、“CE 资源管理”等 5 个研制方向。其中：1）CA 开发与交付规定云原生 DevOps、低代码/无代码、敏捷研发、持续集成交付、自动化工具等方面的技术要求、能力规范或产品功能，指导云原生开发与交付相关的技术研发、产品选型及服务应用。云原生标准体系白皮书（2023）272）CB 可观测性规定云原生日志事件、链路追踪、指标监控、关联分析等方面的技术要求、能力规范或产品功能，指导云原生可观测性相关的技术研发、产品选型及服务应用。3）CC 稳定性保障规定云原生容灾灾备、应用韧性、风险预测、故障自愈等方面的技术要求、能力规范或产品功能，指导云原生稳定性保障相关的技术研发、产品选型及服务应用。4）CD 计量与计费规定云原生计量模型、计费规范等相关要求，规范云原生服务按需计费、成本优化。5）CE 资源管理规定对云原生基础资源、平台资源、应用资源等方面的管理要求，指导构建、管理、调用统一资源池。（4）D 评估评价（4）D 评估评价包括“DA 评价指标”、“DB 能力成熟度”等 2 个研制方向。其中：1）DA 评价指标规范云原生弹性、韧性、性能、高可用、自动化、软硬结合、绿色低碳等非功能性评价指标，指导云原生系统的研发、设计、建设与应用。2）DB 能力成熟度云原生标准体系白皮书（2023）28规范利用云原生进行改造、优化、迁移、管理等方面的实现程度，指导云原生行业生态建设。云原生标准体系白皮书（2023）29附件：云原生标准化应用实践案例（一）商务服务（1）案例背景及难点（一）商务服务（1）案例背景及难点某商务服务企业致力于用科技构建开放数据平台，让公众更远、更透、更公平地看清世界，减少商业交易中的“信息不对称”，助力诚信社会建设。目前，已收录 3 亿社会实体信息，服务近 5 亿用户，但也面临着存量业务运营的新挑战和新需求。从内部视角看，亟需优化运营成本，提升业务质量及运转效率；从外部视角看，更需为业务发展提速、支撑快速创新。当下，原业务架构已掣肘提质、降本、增效、创新的整体战略。具体而言：一是一是数据架构与业务强耦合，业务代码直接进行库表操作，不仅安全性低，还影响迭代效率和开发难度。二是二是缺失大量数据冗余和数据模型，使得数据可扩展性差，另由于缺乏统一的数据开发框架和规范，导致新增业务模型的开发周期漫长、影响业务创新。三是三是应用架构复杂,导致服务间强耦合，单一特性修改往往牵涉成批服务改动，系统设计、编码、测试效率低下。同时，服务间复杂依赖导致业务弹性伸缩不灵活、问题定位定界困难,加剧产生因单个服务故障导致整体系统瘫痪的可能性。四是四是部署模式传统老旧，现有 IDC 架构和虚机管理资源利用率低，业务高峰期扩容效率低，已极大影响业务规模化增量。同时，传统的资云原生标准体系白皮书（2023）30产运维模式，导致资源与应用割裂，很难在故障发生时对问题快速定位恢复，增加了日常运维难度和压力。（2）案例实施成效（2）案例实施成效通过实施数据服务化、应用现代化、基础设施容器化，全面优化业务架构及相关的研发流程，不仅优化了CAPEX/OPEX，而且全面提升了业务创新能力。具体而言：一是一是实现数据服务化。将实时分析和离线分析业务分离，建立统一标准的 ETL 数据开发框架与开发规范，将数据开发效率提升 30%。将算法服务与 ETL 解耦，提升了算法处理效率 20%。精简业务数据模型，重构优化 300 数据表，减少数据冗余量 70%。统一数据访问模式，实现数据和业务解耦，提升了数据访问的安全性和便捷性。二是二是实现应用现代化。结合 Spring Cloud 框架对业务进行微服务化重构，实现模块间的分层和充分解耦，建立起包括业务能力、领域服务、基础工具等在内的六层微服务架构，将新特性开发效率提升 43%。微服务间通过统一网关互访，减少了业务流转的复杂度，各服务支持独立、灵活伸缩，单服务故障不再影响系统整体运行，问题定位定界更加清晰，提升了业务系统可靠性和运维效率。三是三是基础设施容器化。基于云原生基础设施构建的全新基础平台，极大提升了资产管理灵活性，将资源整体利用率提升 30%，实现业务秒级快速扩容，轻松应对突发业务量。云原生标准体系白皮书（2023）31基于标准化、开放、以应用为中心的容器平台，实现应用分钟级测试上线、故障秒级自动恢复；进行容器化改造后，面向企业的算法服务效率提升 20%。（二）自动驾驶（1）案例背景及难点（二）自动驾驶（1）案例背景及难点某科技出行企业在快速发展过程中面临关键难点：一是一是数据处理链路复杂。自动驾驶车联网数据链路长且数据增长快，因此数据时效性要求高。二是二是自动驾驶 AI 服务资源利用率低。缺乏有效的 AI 模型 GPU 训练和推理优化。三是三是可观测系统不完善。前端 Web 和后端服务缺乏有效的监控和分析，同时自建 Prometheus 稳定性不佳。四是四是支撑平台技术栈复杂。技术平台需要支持多种业务，并且需要建设如Workflflow CI 工作流、SRE 等工具平台，技术栈较为复杂。（2）标准化实践方案（2）标准化实践方案通过云原生产品支持出行业务的技术平台建设，数据处理、AI 训练与推理服务、工作流、SRE 运维设施均通过统一容器技术栈进行承载。云原生标准体系白皮书（2023）32（3）案例实施成效一是（3）案例实施成效一是弹性算力支持复杂数据处理。通过容器服务运行数据处理和数据脱敏任务，容器为实时任务提供了弹性算力。二是二是提升训练和仿真资源利用率。云原生 AI 套件支持自动驾驶大规模训练和仿真任务的调度和管理，提高了训练和仿真资源的利用率。同时，AI 套件还支持互联网技术中台和出行业务的 NLP、ASR 等推理业务。GPU 共享调度和隔离能力，成倍地提高了 GPU 资源的利用率。三是三是全链路可观测保障业务稳定。采用 ARMS Prometheus 服务、前端监控和 APM 等工具实现全链路监控系统，有效洞察业务稳定性风险，保障业务稳定性。四是四是统一云原生技术栈简化运维。除通过容器服务支持仿真、音视频转码、视频截图、图片处理、数据处理等相关业务外，还支持 Airflflow/Argo workflflow、Kubeflflow/Arena 等工作流平台。采用统一的技术栈运行各业务及其支撑系统，极大简化了运维复杂度。云原生标准体系白皮书（2023）33（三）电子政务（1）案例背景及难点（三）电子政务（1）案例背景及难点2022 年 4 月，国务院发布国务院关于加强数字政府建设的指导意见，提出“持续优化全国一体化政务服务平台功能，全面提升公共服务数字化、智能化水平，不断满足企业和群众多层次多样化服务需求，打造泛在可及的服务体系”。为持续优化利企便民数字化服务，提升公共服务能力，某主管部门积极推进基本公共服务数字化应用，打造“统筹共建、应用稳定、科学有序”的一体化建设管理体系，提升民生服务智能化水平。建设难点及要求包括：一是一是对系统稳定性及并发要求高，至少支撑 3 万 TPS，面对突发情况能够快速扩容；二是二是对接入层、网络层、应用层、数据层、基础设施均要求高 SLA，故障影响面小、运维成本本；三是三是具备可替代性及兼容性，有效降低迁移成本。（2）标准化实践方案（2）标准化实践方案基于分布式云平台为省平台提供技术成熟、安全运行、易于部署的基础设施，基于云平台的云原生支撑能力搭建平台支撑层，为该平台研发建设以及应用场景对接提供中台能力，保障平台安全、平稳、高效运行。云原生标准体系白皮书（2023）34该平台具有以下特点：一是一是具备微服务 容器保障的高可用能力。将前后端应用拆分成不同的微服务应用，部署在两个容器集群中，同时基于负载需求为微服务应用设置初始的副本数，并配置弹性扩容策略，保障高可用能力。二是二是DNS CDN 双活 SLB 提高负载能力。对外出口使用双活负载均衡，每组负载均衡配置对外提供服务，通过互联网 DNS 进行域名解析，CDN 提升传输速度与稳定性，对外提供统一域名访问能力。三是三是双轨并行降低迁移成本。基于 X86 测试环境系统进行双轨测试，通过流量分发实现应用的验证迁移，降低迁移成本。四是四是混沌测试提升系统整体可用性。通过覆盖容器集群、PaaS 产品、负载均衡等全链路的故障场景混沌验证，全面证明该平台在故障场景下的整体可用能力。（3）案例实施成效（3）案例实施成效目前，省平台已提供 200 工作节点，运行近 500 个 pod,云原生标准体系白皮书（2023）35日最大并发达 5 万 TPS，支持突发情况快速扩容能力，实现并发承载能力线性增长。该平台提供的微服务编排、治理、故障自愈、容器安全等云原生能力，提升系统整体可用性，保障 30%节点异常场景下业务稳定运行，实现应用上云成本降低 80%以上。（四）网络电商（1）案例背景及难点（四）网络电商（1）案例背景及难点当下，用户在网上商城一次次丝滑般秒杀、抢购、支付的背后，是巨大的 IT 资源成本投入。而在平时，这些资源大部分处于闲置状态。据统计，数据中心利用率平均约 10%，容灾、峰值、机器数冗余大，成本奇高。在此背景下，对于电商场景而言，主要面临三大技术难题。一是一是资源隔离。需对相关任务毫秒级自适性调度或限制，避免离线任务运行对在线任务造成影响，以保证高优先级的任务不受影响。二是二是存算分离。在面临多业务场景时，服务器集群量级会迎来爆发式增长，造成 I/O 读写不均，存储量受限制，故障无法恢复及数据易丢失等风险。三是三是资源的智能预测。支持能够对应用的未来资源使用情况预测，实现在线与离线应用的混合调度部署。（2）标准化实践方案（2）标准化实践方案通过构建云原生敏捷技术中台，以应用为中心在混合多云多芯场景下，兼具跨平台管理和运行环境供应的中台化运云原生标准体系白皮书（2023）36营模式。统一的云原生技术栈屏蔽了底层技术的复杂性，提供了丰富的云原生 PaaS 服务和支撑企业应用开发运行服务。此外，构建场景 PaaS 服务和行业 SaaS 应用市场，为企业数字化能力建设提供更多选择。该案例平台支持在多云形态下统一部署云原生运行环境，完成多云、多地域、多形态、多芯的基础设施整合。跨平台的融合编排帮助使用者在异构平台间快速部署业务应用，支持统一高效的运营运维，整体提升业务应用的迭代速度，保障系统稳定可靠、安全灵活。开放架构使平台能够构建良好生态，汇聚多方优秀的数智化能力，同时平台本身提供的高可用、高性能、稳定安全的架构降低了生态组件的管理复杂度，帮助使用者快速上手。（3）案例实施成效（3）案例实施成效案例实施后，通过容器网络组件和存储组件等扩展方式，极大优化了资源池的性能。支持云端边多技术栈业务场景，使用者可以按需灵活组合方案。敏捷技术中台有效提升云原生标准体系白皮书（2023）37整体协同能力和工作效率，丰富的 PaaS 服务减轻了运维人员自行搭建数据库、中间件带来的运维压力，通过场景 PaaS服务和应用市场，研发和运维工作效能大大提升。（五）能源化工（1）案例背景及难点（五）能源化工（1）案例背景及难点某油气公司启动信息化建设工作以来，一直以业务数据为核心，围绕着业务板块建立了核心应用系统，并形成以点到面进行扩散的全业务覆盖模式的信息化建设局面。目前，该公司应用架构主要以垂直的单体应用架构为主，应用系统架构处于原始的初级阶段。一是在开发模式方面，无法实现需求多变时业务的敏捷交付。二是在应用部署方面，形成了“一应用一虚机”或“一应用多虚机”的应用系统部署常态，现有运行模式造成的资源浪费和应用系统运维部署的压力巨大。三是应用系统面临零监控问题的被动式运维局面。（2）标准化实践方案（2）标准化实践方案平台底层兼顾新旧架构模式应用的高可用集群架构设计，应用自动化部署部分涉及高可用集群方案设计。应用监控平台建设针对该公司应用特点采用合适的监控方案。云原生标准体系白皮书（2023）38（3）案例实施成效（3）案例实施成效案例实施后，为该用户企业在多方面实现改进提升。一是一是应用系统性能优化提升。实现新老应用架构下应用系统的响应性能、持续服务能力、容量自动伸缩等能力的提升。二是二是应用系统部署运维效率提升。利用容器平台流水线的功能，自动化编译打包，自动化部署，实现开发测试运维流水线生产，提升应用系统部署运维效率。三是三是应用系统架构统一。实现公司所有应用系统的运行部署平台统一、开发的架构设计统计。四是四是业务组件复用集成。实现基础业务组件的快速集成，减少重复开发工作量，提供公司业务组件快速复用、应用敏捷集成管理的能力，为应用系统商品化改造提供底层支撑。五是五是公共服务支撑能力。实现统一用户、认证、授权、流程、日志等功能，通过应用集成管理云平台，打造公司应用公共服务支撑能力。六是六是业务门户的统一。云平台云原生标准体系白皮书（2023）39门户通过结合容器云平台、DevOps 平台、APM 监控平台，实现单点登录、统一管理。（六）金融科技（1）案例背景及难点（六）金融科技（1）案例背景及难点某金融科技公司秉持业务需求和技术创新相互驱动的发展理念，于 2018 年演进为云单元架构，但在业务应用过程中逐渐暴露出新旧系统难以互联互通和统一管理、研发和运维效率难以提升、机器资源使用率不高导致成本难以降低等关键问题。（2）标准化实践方案（2）标准化实践方案通过不断开展技术创新实践，围绕微服务治理、在离线混部、大规模调度、业务安全等方面，实现了从云单元架构到云原生架构的技术优化升级。该云原生架构体系包括自动化运维平台、应用服务框架、弹性资源调度、安全隔离的容器运行、可信服务运行环云原生标准体系白皮书（2023）40境五层。自动化运维是研发和运维的一体化平台，提供高效、稳定、安全的自动化及智能化服务能力；应用服务层采用Service Mesh 技术架构实现业务系统和基础设施的解耦，使得基础设施和业务的迭代速度大大加快，实现无侵入的分布式服务治理；在弹性调度层，结合智能调度画像数据，利用在离线混部，资源分时错峰，容量弹性伸缩等调度技术大幅提升了资源使用效率；在安全隔离层，采用自研内核级隔离安全容器技术，结合操作系统层和硬件层隔离技术，有效隔离在线和离线的资源，极大保障了大规模混部场景的安全稳定；在可信服务层，对异构服务器算力进行标准化，提供标准计算能力供上层调度系统调度，同时构建了基于安全沙箱技术、全站加密、以及全栈可信的三层防御纵深能力。（3）案例实施成效（3）案例实施成效该案例通过云原生架构体系升级，取得诸多关键成效。一是一是 ServiceMesh 全面落地，基础设施升级效率提升 10 倍。实现了数千应用的服务网格化，覆盖了大促核心系统全链路，基础设施升级能力从 1-2 次/年提升到 1-2 次/月。二是二是通过大规模混部，集群机器资源提升 2.5 倍。实现生产系统具备全天候资源弹性调度能力和资源分时复用，全站服务器计算利用率从 12%提升到 30%，资源分配率 90%以上。经测算，2021 年度，该案例项目合计节电超过 4600 万度，减排近 3万吨二氧化碳当量。其中，国产集群 CPU 利用率从 9%提升到云原生标准体系白皮书（2023）4126.4%，每年节省约 590.9 万度电，减排 1605 吨碳。三是三是全业务、全链路安全水位整体提升。为应用与数据提供了隔离性、机密性、与完整性保护，实现了身份认证、服务鉴权和通信加密。（七）银行货币（1）案例背景及难点（七）银行货币（1）案例背景及难点某银行从传统 IT 架构转变为新型云平台架构，规划引入容器技术，提高资源利用率、提高业务系统部署速度，建设高度自动化、深度集成的容器平台，提升运维自动化水平。在业务层面在业务层面，银行的互联网业务应用拥有庞大用户规模，随着手机银行类应用的普及和大规模推广，其业务系统时刻面临着突发性、并发性的业务应用访问挑战。其次，传统业务应用模式存在环节多、流程长、耗时久、创新容错不足等不足，难以适应市场快速变化。在技术层面在技术层面，业务飞速增长给承载业务系统的底层基础设施平台带来巨大资源压力。如何对资源使用量进行精确统计监控，并提升资源利用率成为银行数字换转型的最大难题之一。此外，现行运维模式缺乏自动化管理能力，亟需提升运维自动化水平、解放运维生产力。（2）标准化实践方案（2）标准化实践方案该银行通过采用容器云平台，能够支撑容器应用大规模部署，具备更高的安全管控能力，以及满足敏捷开发和智能化运维等需求。采用基于 Docker 和 Kubernetes 技术的容器云原生标准体系白皮书（2023）42编排解决方案，在开发测试、准生产、生产环境大规模落地容器化应用，从而实现应用的快速部署、实例的自动化弹性伸缩及高可用，保障应用的可靠性与稳定性。容器云平台进一步提高了资源利用率，将容器平台与云管平台进行深度对接，完成业务开发、上线等业务流程，实现开发与运维集成。同时在建设过程中，形成了容器部署、运维等方面标准规范。（3）案例实施成效（3）案例实施成效本案例建成开发、测试、准生产、生产等四套环境，支撑 300 多套系统实现容器化，覆盖手机银行超过 45%业务。从技术层面看从技术层面看，投产实现无人值守的灰度发布，从数小时提升至分钟级，版本更新和启停实现秒级，有效满足了实际业务快速增长的需求，实现秒级资源扩缩容。多数核心业务直接运行在物理点节上，提升业务应用性能约 34%。从业务层面看从业务层面看，包括机构客户交易平台、资产管理信用评级系统、信息安全门户、客户服务团队、行情中心、精准营销、质量和运维中心、服务治理等在内的迁移业务，均实现稳定运行和高效业务迭代。（八）智慧家庭（1）案例背景及难点（八）智慧家庭（1）案例背景及难点云原生技术以弹性可扩展、高可用、高灵活、强兼容和低成本的方式将云的价值最大化，使能智慧家庭业务场景实现敏捷、海量和简单的优势，满足经济社会数智化转型“线云原生标准体系白皮书（2023）43上化”、“智能化”和“云化”等新要求。本案例难点在于：一是一是市场快速发展和同质化竞争加剧，对新功能的上线要求越来越高，需要化解高速的业务发展和系统稳定之间的矛盾。二是二是如何支撑更多的视联新场景、新形态、新终端，构建支撑海量、高并发和高性能的业务系统架构能力，支撑线上转型。三是三是目标要通过自动化、智能化手段，提高运维效率和集群发布变更的敏捷性。（2）标准化实践方案（2）标准化实践方案智慧家庭平台以统一 K8S 技术栈为基础，完善以应用为核心的云原生技术标准，重视多样化算力体系和标准化体系构建，构建 X86/ARM 双平面算力资源，优化 CPU/GPU 算力支持，满足在不同业务场景下的应用需求。引入 Operator 模式，提升技术服务组件和平台内部组件的供给效率。在容器编排和应用管理之间，增加 OAM 应用管理平面，促进应用构建和部署的标准化。平台提供操作简便的一键式服务自动化部署、统一配置管理、应用的弹性扩缩容、微服务管控、DevOps 工具链、资源/服务/容器等多维度综合监控和安全管控等功能，并在此基础上持续集成 Serverless 和 AI 等创新能力。（3）案例实施成效（3）案例实施成效智慧家庭平台已在全网构建超过 100 个集群，纳管超过1.3 万台主机、超 30 万容器，提供云原生中间件、云原生数云原生标准体系白皮书（2023）44据库等 40 余种技术服务组件。基于该平台构建的智慧家庭合作生态，已有 800 硬件合作伙伴、200 应用服务伙伴和1000 款生态创新产品。支撑国家加速建设千兆光网政策，实现千兆 5G、千兆宽带与千兆 Wi-Fi 组网环境下 IOT 长连接能力的管控。支撑国家乡村振兴战略，集成自研云原生AIoTel、云原生视频传输等能力，打造农村信息化产品“平安乡村工程”。支撑国家数字家庭建设政策，打造全场景能力及服务平台，贯通 HDICT 全链路实现云边端的智能互通。支撑国家智慧社区建设政策，通过分布式云边端系统建设运营，完善了国家社会基层治理体系。（九）医院医疗（1）案例背景及难点（九）医院医疗（1）案例背景及难点某医院业务在运营中面临的主要问题：一是一是业务可用性要求高，需保证云平台等多层面的高可用；二是二是资产管理复杂，混合云、微服务架构等提升了基础设施与应用的复杂性,亟需构建对重大事故的及时预警、对关键业务运行过程的可观测性能力；三是三是技术门槛高，为有效应用容器、动态编排、服务治理等技术，需要高效易用的云平台产品；四是四是资源开销，业务的快速发展导致 IT 资源紧缺,如何能更高效的按时按需提供云资源。（2）标准化实践方案（2）标准化实践方案针对关键难点问题，为用户企业实施了云原生引擎方云原生标准体系白皮书（2023）45案。具体包括：一是一是双中心容器集群。支持跨同城两个数据中心部署单个大规模 Kubernetes 集群，并支持有状态和无状态应用。二是二是 ETCD 热备。Kubernetes 集群的 etcd 采用双机房热备方案，即在两个机房各部署一套etcd集群，并通过make-mirror做热备。三是三是均衡策略。通过预置策略将各机房网段的流量优先路由到该机房的 Kubernetes 节点进行处理，从而有效缩减跨机房数据流量。四是四是镜像管理。各机房分别部署定时相互同步的镜像服务，并对外提供高可用镜像服务。五是五是网络服务。使用高级网络组件提供容器网络服务，支持大规模场景下 EndpointSlice，以及通过网络拓扑感知实现多机房场景下的服务就近访问能力。六是六是业务弹性伸缩。支持业务应用按需进行水平、垂直弹性伸缩,同时提供基于负载压力的容器集群水平伸缩；七是七是资产管理。统一运维多数据中心的基础设施层、虚拟化层、容器化层和业务应用层,提供贯穿所有层的可观察性工具链。云原生标准体系白皮书（2023）46（3）案例实施成效（3）案例实施成效该案例实施后，一是一是提高了可用性，提供基础架构层面和控制层面的高可用性,通过构建跨机房容器集群，降低业务系统高可用架构的设计难度。二是二是提升了资产管理便捷性，提供多地域/多集群、资源、业务应用的统一管理能力。三是三是提升研发效率，为开发人员提供一致的开发体验，在任何地方都能快速构建和部署应用。四是四是降低运维成本，提供弹性伸缩、故障自愈和全局可观测性能力，提升运维质量并降低相关成本。（十）互动娱乐（1）案例背景及标准化实践方案（十）互动娱乐（1）案例背景及标准化实践方案某企业互动娱乐业务随着国际化市场服务加速发展，对于系统开发运维效率和成本控制等方面的要求不断提高。通过进行云原生和 Serverless 化改造后，更好助力业务快速上云。案例方案支持底层运算，单个虚拟服务器（VirtualServer）对应一个或多个云函数，便于用户创建并编写业务逻辑。通过 Serverless 提供完善的监控、日志能力，进一步对接后端服务和封装 DevOps 工具，为用户提供全托管、自动构建部署等功能。同时支持多种驱动方式，底层可对应不同函数触发器以触发 Virtual Server 实现业务运行。云原生标准体系白皮书（2023）47（2）案例实施成效（2）案例实施成效该案例实施后，一是一是实现开箱即用。用户无需额外购买、搭建和配置服务器，该架构加快软件发行和迭代速度，极大降低运维成本，保障了业务的稳定、安全和资源可用。二是二是支持动态扩缩容。Serverless 支持在访问量突增时，自动扩容保障业务正常运行。同时在流量低谷期，自动缩容以节约成本。三是三是支持实时监控。Serverless 提供的实时日志、监控面板，支持研发和管理人员实时监控业务运行状态，提供运行时间、状态异常等多维度告警能力，为用户实现问题快速定位。四是四是具备扩展性和灵活性。FaaS 特性支持业务灵活扩展，实现函数代码在线编辑功能，以及业务开发、部署、监控等一站式解决方案。五是五是满足用户多触发场景需求。案例实现十余种事件触发方式，包括定时触发器、API 网关触发器、对象存储触发器等。

0人已浏览 2023-11-21 52页 5星级