云计算研究报告-PDF版

点击查看更多中国信通院：《2022年中国云计算发展指数》解读（13页）.pdf精彩内容。

10人已浏览 2023-04-01 13页 5星级

腾讯云工具指南轻量级云开发与云应用01 代码传递思想技术创造回响前言腾讯云轻量化工具指南 企业上云，实现了众多企业在高速发展中的自动化、弹性化、精细化，这是数字化的第一步；今天，我们还需要将数字化工具融合到企业的实际业务场景中，帮助企业进一步降本增效提质，这对云应用与云开发工具提出了更高的要求：一方面，我们要支持企业开发者站在业务场景视角，搭建更高效敏捷的系统平台；另一方面也要支持非技术人员更快速简洁地使用云应用，并以此助力生产效率及质量的提升。于是，我们提出了“化繁为简，轻而易用”，希望用更轻量、更好用的工具来助力更多云端梦想的构筑，实现更大数字化价值的释放。轻量化，可以降低开发门槛，让企业上云更加容易。过去，在搭建 Web 应用、小程序、APP 等场景中，需要创建服务器、配置网络、安装应用软件、数据库、Web 服务器等，再进行各种环境配置。为提升开发效率，针对这类高频开发场景，我们推出了轻量应用服务器 Lighthouse，把 IaaS 资源、应用软件和各种配置都统一打包好，实现开箱即用。就算是刚入门的开发者，也只需要 1 分钟不到的时间，就能够完成一个网站的搭建。轻量化，可以提升研发效率，让企业用云更加敏捷。我们搭建了 Coding DevOps 平台，一站式实现研发和运维自动化，敏捷项目管理、测试管理、持续集成、制品库、持续部署、应用生命周期管理等功能，这让团队研发工具建设成本下降 82.7%，研发效能提升 75%，产品交付效率提升了 68%。产品发布时间从过去以“季度”、“年”为单位，缩短到以“天”或者“周”为单位。轻量化，是授之以渔而不只是授之以鱼，从而让更多人享受到云服务带来的价值。我们既要让开发者更好地实现其开发目标，更要让众多开发者可以以此去推动实现业务目标。我们将腾讯云音视频能力，封装为腾讯云视立方终端 SDK，我们的合作伙伴小鹅通只通过这样一个 SDK 一套接口就拥有全栈视频需求的能力，既降低其 70%的投入成本，更让其更好聚焦在品牌营销、知识产品交付、用户管理等业务场景中。在这一本 腾讯云轻量级产品工具指南 中，你会看到腾讯云对轻量化更深入的理解与实践：包括零门槛的全栈式AI开发平台、像自来水一样灵活使用的云原生数据库、聚焦设计细分市场的TDesign等等，希望这对您在未来开发的实践与创新有所帮助，谢谢！化繁为简 轻而易用 腾讯云高级副总裁、腾讯云 CTO腾讯云轻量化工具将能带来什么价值？价值 轻量化工具指南降低学习和开发门槛提升研发和用云的效率加速撰写、搭建、部署极速完成贴近场景解决推动目标实现加强交流与资源协同能力覆盖从规划、设计到开发部署、运维全生命周期目录 轻量化工具指南目 录云开发 共建前端基础设施解放设计开发生产力CODING DevOpsDevOps 探索与实践：如何系统化提升研发效能？Lighthouse 极简上云：使用 Lighthouse一键构建云上应用微搭提效 50%，快速构建企业级应用的开发秘诀音视频 破局音视频终端困境，快速实现多种音视频应用AI 低门槛开发 AI：全栈AI平台开发新体验Serverless 大数据任务处理最佳实践：如何用 Serverless 实现事件驱动？数据库有效降本：如何像用自来水一样使用数据库？微服务如何基于 Spring Cloud Tencent 快速构建高可用轻量级微服务应用？内容风控全方位保障业务生命线：如何极速开发直播音图风控？01050811141822273033区块链人人都是区块链工程师，一站式区块链平台新体验37轻量应用服务器Lighthouse 轻量应用服务器（TencentCloud Lighthouse）是新一代开箱即用、面向轻量应用场景的云服务器产品，助力中小企业和开发者便捷高效的在云端构建网站、Web 应用、小程序/小游戏、APP、电商应用、云盘/图床和各类开发测试环境，以套餐形式整体售卖基础云资源并提供高带宽流量包，将热门开源软件融合打包实现一键构建应用。01 轻量化工具指南轻体验产品优势应用场景一站式融合计算、存储、网络等常用基础云服务，简化云服务器和应用系统的创建、管理复杂度。轻投入计算、存储和网络资源套餐式售卖，并提供高带宽流量包，开支清晰直观且整体性价比更高。轻应用开箱即用的热门优质应用镜像，预置网站、博客、论坛等应用系统所需的软件栈最优组合，一键部署、秒级启动应用。轻运维从服务器到服务器内应用系统的运维管理，均可在统一、可视化的管理控制台中完成操作。网站搭建使用轻量应用服务器提供的精品应用镜像（例如 WordPress、Typecho、WooCommerce 等），可快速创建满足您业务诉求的网站，例如企业官网、个人展示网站、博客、论坛、电商独立站等。腾讯云将持续提供更多类型的应用镜像。开发测试环境提供多种预置 LAMP、Node.js、ASP.NET、K3s 等常用开发环境的应用镜像，帮助开发者随时随地在云端构建开箱即用的开发测试环境。Web 应用服务通过使用预置常用 Web 开发平台（如 LAMP 堆栈、Node.js、ASP.NET 等）的镜像，可快速部署 Web 应用程序，简单高效上线各类业务应用。云端学习环境提供触手可及的云端学习环境，例如 TencentOS、Ubuntu、CentOS、Debian 等 常 用 Linux 系 统 和 Windows Server 系统，您可以随时创建、随时销毁环境。极简上云：使用 Lighthouse 一键构建云上应用相信各位都会有一个疑问，就是我们为什么要做Lighthouse这款产品？我们做轻量应用服务器的初衷有2点：-第一点，我们希望降低云的使用门槛。有很多用云计算初学者，在使用云产品的过程中，都有过类似“云计算从入门到放弃”的经历，以云服务器CVM为例，因为要兼顾所有的用户，所以它涉及的概念和关联的产品非常多，入门相对比较复杂。因此我们希望专门打造一款面向中小微企业和个人开发者的云服务器产品。-第二点，我们希望这款云服务器产品能够更加贴近应用、贴近开发者，让各位开发者朋友都能享受云计算的便利、高效。打个比方，如果说CVM是毛坯房，那Lighthouse就是精装房，我们已经为用户配齐了所需要的功能，拎包入住就可以了。Lighthouse与传统云服务器CVM相比，Lighthouse服务的客户群体更聚焦，主要是个人开发者和中小企业。Lighthouse采用更简单的概念，比如套餐、流量包将底层的计算、网络、存储等云资源进行封装，化繁为简，降低用户理解成本。同时为用户提供优质的应用镜像，为用户在多种应用场景中提供开箱即用的产品体验。如果用一个公式进行总结的话:Lighthouse=云服务器 独立IP及流量包 开箱即用的应用镜像 CVM复杂繁琐的细节功能02轻量化工具指南了解产品更多详情二维码用Lighthouse来实现WordPress进行直播这个场景就非常简单，只需要三步即可。1.创建三台轻量应用服务器。2.在WordPress中插入云盘中图片的外链URL，就能显示图片了。3.在WordPress中使用简码，插入SRS服务器中HLS流的播放地址，就能显示直播流了。自行搭建需要安装10多个软件，耗时1-2天的应用场景，使用Lighthouse来搭建只需两行代码，5分钟就能完成。Lighthouse的核心设计原则是化繁为简，快速高效。在产品设计层面，Lighthouse通过多种渠道，比如用户微信群、轻友团、调研问卷、有奖吐槽平台等渠道，收集开发者核心共性的需求。在需求分析时，我们专注于核心需求，在功能边界上不断做减法，聚焦于应用场景和易用性，使得Lighthouse一直保持开箱即用的特性。在技术设计层面，Lighthouse的底座是腾讯云敖驰云原生操作系统、Vstation云服务器资源调度系统和KVM虚拟化技术。在集成了腾讯云核心技术基础上，构建了LightPower轻量调度系统。Lightpower调度系统采用无锁乐观并发机制、基于全局资源视图进行调度决策，显著提升了调度器的吞吐率。Lighthouse在技术实现上，专注于基础资源的融合，秒级构建应用，一键免密登录等上层服务。最终在产品使用复杂度上做减法，为用户提供简单的体验。03轻量化工具指南这是Lighthouse的架构图，也是Lighthouse这个“精装房的硬装”部分。套餐服务，封装了计算、网络和存储的概念和功能，屏蔽了底层的细节。KeyPair服务，提供了SSH一键登录的服务器的功能，用户无需设置密码和密钥即可登录服务器进行命令操作。Blueprint服务，提供了DiscuzQ论坛，Cloudreve云盘等优质应用，用户创建好服务器后，即可使用这些服务。Instance服务，则将CVM，VPC，安全组，云盘，密钥，镜像打包成一个整体即轻量应用服务器，提供给用户使用。Lighthouse服务在框架层面对资源进行统一调度，各个服务之间通过消息队列进行通信，做到了各个子服务之间的独立解耦，这样既有一个全局的视图又能保证系统的健壮性，不会因为某一服务出问题而影响其他服务。应用镜像是Lighthouse这个“精装房的软装”部分。在构建应用镜像过程中，最为繁琐的耗时的部分是，在服务器上手动安装各种应用软件，并进行验证是否安装成功。通常情况下会耗时1-2天，这完全是人工操作，流程无法复用。而Lighthouse有几十款应用镜像，完全靠人工来制作镜像显然是效率极低的做法。这里Lighthouse在技术实现上采用全流程自动化的做法，核心原理是利用腾讯云API Postman TAT自动化助手来完成制作镜像流水线。用腾讯云API来实现创建服务器，创建镜像和各个地域分发镜像等功能。利用Postman调用云API，并进行流程编排。而最复杂的安装软件和验证软件的操作，则通过腾讯云自动化助手TAT完成，在制作镜像的过程中无需登录云服务器，将命令通过TAT助手进行下发执行，同时将安装各种软件的命令保存为TAT公共命令，方便以后进行组合复用。最终制作镜像耗时从1-2天的人工操作缩短为1小时的自动化流程。04轻量化工具指南腾讯云微搭低代码 腾讯云微搭低代码以云开发作为底层支撑，通过行业化模板、拖拽式组件和可视化配置快速构建多端应用（小程序、H5、PC Web 应用等），免去了代码编写工作，让您能够完全专注于业务场景。轻量化工具指南在微搭，发现更大的应用开发想象空间提供丰富的 UI 组件，拖拉拽即可开发应用，摆脱繁琐的代码开发。小程序开发，用拖拉拽的方式让想法快速落地可视化编辑小程序注册、授权、开发、预览、发布等流程一步到位。流程全闭环云开发技术底座，服务器搭建、扩缩容、网络安全，微搭帮您搞定。云原生一体化在微搭，让业务系统定制变得游刃有余打通企业微信组织架构和用户角色，应用可发布到企业工作台。企业级应用开发，零代码实现业务工作流集成企业微信轻松调用腾讯会议、腾讯地图等腾讯国民级产品能力。连接腾讯SaaS生态通过搭建内部管理应用连接小程序，轻松实现外部用户触达、用户信息采集、移动设备作业等场景。连接外部用户来自各个行业的客户信赖与肯定2 周时间完成健康码小程序，安全可靠地支 撑 四 川 省 超 过8000 万 人 口 的 访问。四川天府健康通政务利用微搭服务商模式，一次开发，服务十万家医药门店小程序，交付时间缩短45%。存健康医疗利用微搭快速上线电商小程序，关联视频号直播，串联起微信生态渠道。永骏魔方电商7 天时间完成小程序搭建到上线，把幼儿园招生报名业务线上化。七色果幼儿园教育05“低代码”要追溯可追溯到1980年的可视化编程领域，而概念是在2014年正式被知名权威机构Forrester提出，基于编程效率提升的技术一直致力于提高企业的IT应用开发、落地效率，降低重复性开发成本的损耗。根据Gartner的数据显示，2023年，全球超过50%的大中型企业，将把低代码应用平台作为主要战略应用平台之一。传统开发模式下，需要企业配备前端、后台、运维等不同角色的人员手写代码完成一款应用的开发。而低代码开发，相比传统开发模式最大的优势在于可以少写代码或者不写代码完成一款应用，把业务架构抽象成为组件、流程编排等能力，把业务能力组件化、模块化，从而提高开发效率。而腾讯云微搭低代码的定位，是快速连接腾讯生态的低代码平台，能快速打通企业微信、腾讯会议、腾讯文档等企业级应用。提效50%，揭秘低代码如何高效构建企业级应用的开发轻量化工具指南06了解产品更多详情二维码轻量化工具指南07微搭低代码底层基于腾讯云的云原生底座，可以做到安全高效地支撑应用发布后的稳定运行，而在上层提供了一系列能力，例如丰富的组件库、可视化拖拉拽编辑器、数据模型等能力，供开发者进行低代码开发，在业务层可创建企业微信应用、微信小程序，以及在浏览器打开的PC WEB、移动端H5应用。目前，腾讯云微搭也提供了覆盖多个行业的通用模版，如企业门户模版、设备报修系统模版等。四川天府健康通是一个很好证明微搭低代码平台创建的应用能够应对高并发、高安全要求场景的标杆例子。这是四川省内统一健康码，基于腾讯云微搭技术底座，创新性地使用了低码开发技术，整个过程只耗费十余天，适时满足了疫情防控的需要，免去大部分重复性的代码编写工作，降低开发门槛并提升效，复用政务基础组件和复用已有业务逻辑抽象，交付效率至少提升了5倍。CODING DevOps CODING DevOps 包括代码托管、项目管理、测试管理、持续集成、制品库等多款产品和服务，涵盖软件开发从构想到交付的一切所需。轻量化工具指南08 完整的自研开发工具覆盖开发管理全过程工具服务，具备完整的自研工具能力，无需对接第三方工具，一站式进行 DevOps 实践。快速发布应用的能力依托腾讯云强大的 CDN 能力，通过全球连通极速网络进行上传下载，快速完成应用分发。产品特性多角色岗位高效协作适合团队内产品、设计、研发、测试、运营等不同的角色岗位同平台无缝协作，快速接收业务部门的反馈，帮助产品迭代优化。支持敏捷或瀑布工作流研发协作工具链深度结合敏捷研发理念，对产品进行迭代规划，让 Scrum 过程风险可控，同时可支持企业进行瀑布式开发模式。多维度数据报告支持对代码、项目进度、人员工作量等不同维度输出详尽的数据报告。开发过程自动化从代码在线管理到持续集成、自动化测试、自动部署过程，为项目的持续性交付提供高度自动化的能力。敏捷开发实践从用户故事开始，到需求池管理以及任务拆解、缺陷管理、测试管理，敏捷开发过程都有序建立。瀑布流开发实践涵盖了从需求规划、开发计划、需求评审、开发测试、持续部署整个研发生命周期的管理，满足不同规模团队的瀑布式研发模式，有效控制项目风险。DevOps 自动化实践提供持续集成到自动部署的全过程工具：自动构建、自动化测试、制品库、持续部署。支撑项目的快速迭代，保证软件稳定、持续构建发布。应用场景持续发布DevOps探索与实践：解决企业研发效能提升的痛点右边的图描述了缺陷密度与评审代码行数量之间的关系。缺陷密度就是每 1000 行代码之中所发现的错误（bug）数。当评审代码行数量超过 200 时缺陷密度就会急剧下降，当评审代码行数超过 400 以后，缺陷密度几乎为 0 了。因此一次最好只评审 200 400 行代码，这样才能获得最大的收益。在代码评审的过程中，我们应该给予建设性而不是情绪化的反馈意见。因为所有负面的情绪其实都会对我们的工作效率造成不好的影响。因此我们应该互相尊重，在处理问题时应该对事不对人。只有这样，我们才能营造一个团结和睦的团队氛围。写完代码以后，应该先自测，自测没有问题以后，我们应该通过自动化流水线来进行自动检测，当自动化检测也通过以后，我们再提交给同行进行评审。这么做是为了将一些明显的低级错误先排除掉，从而节省评审者的宝贵时间。总结一下 CODING 项目协同的敏捷模式。左边是 product backlog 也就是需求池，右边是迭代。里面的需求都是有顺序的，上面的重要，需要先做，下面的相对不重要，这就是敏捷的核心：价值排序。右边的红框里有个数字 26，它是下面数字的总和，叫做故事点，也就是说：一个团队一次迭代只做这么多事情，如果有紧急需求插队，没关系，放弃别的需求，让故事点总和保持不变即可。如果最后还是没做完，剩下的都是相对不重要的，丢回左边，重新参加排序，也许下次迭代也不会做它们，因为有更重要的事情做。每次迭代都要开反思会，找到没做完的原因，比如预估错误。经过几次迭代的磨合，找到良好的工作节奏，把故事点明确下来。轻量化工具指南09了解产品更多详情二维码Policy as Code 翻译过来就是 策略即代码。简单来说，策略即代码是通过代码的方式去定义，更新，分享和实施策略。传统模式下，我们想要检查某项配置是否符合安全规范时，往往需要参照一些已经写好的安全规范手册来进行人工检查。这种做法费时费力，在微服务时代，这种方式显然是不可取的。想要提高效率，我们必须借助一种自动化工具来快速检测这些潜在的安全问题。由 BridgeCrew 公司开发的 checkov 工具正好可以满足需求。如左边的流程图所示，我们可以通过结合 CODING 代码仓库、CODING 持续集成流水线 CI、Terraform 和 Checkov 来实现 Policy as Code。Git as the SINGLE source of truth of a system。Git as the SINGLE place where we operate(create,change and destroy)。All changes are observable/verifiable。GitOps 就是 基础设施即代码 合并请求 持续集成或者是持续部署。所有的操作都将围绕着代码仓库来进行。比如，当运维人员要修改某项配置时，他需要将更新后的配置文件提交到 CODING 代码仓库，当评审通过以后，相应的配置文件将会合并到主干分支。当 CODING 的持续部署模块监听到相关的配置文件有变更以后，机会触发相应的持续部署流水线，。由于所有的操作都是围绕着代码仓库进行的，因此所有的操作都会有相关的提交记录，方便我们快速追溯问题。轻量化工具指南10音视频终端 SDK 腾讯云视立方 腾讯云微搭低代码以云开发作为底层支撑，通过行业化模板、拖拽式组件和可视化配置快速构建多端应用（小程序、H5、PC Web 应用等），免去了代码编写工作，让您能够完全专注于业务场景。轻量化工具指南11 产品功能产品特性卓越能力腾讯云视立方支持超低延迟、超高画质、超大并发访问量的直播点播需求。灵活定制针对直播、点播、实时音视频等不同终端场景，提供不同版本 SDK。AI 赋能可对人脸进行识别定位，实现实时的美颜特效、动效贴纸等直播互动，灵活搭配丰富场景应用。功能强大集成终端 SDK，可快速拥有终端直播、点播、互动直播、短视频剪辑、美颜特效、视频会议等功能。一处接入，处处调用。简单易用灵活定制您需要的 SDK 版本，集成后配合各类场景化 Demo 快速实现终端应用。数据分析实时统计直播、点播、连麦等使用量具体消耗、请求、请发等等数据，把控上下行质量，定位播放问题。直播推流配合云直播使用，使用 RTMP Over QUIC 快速推流至腾讯云，更低卡顿，更低延迟。直播播放功能强大的直播播放器支持 RTMP、FLV、HLS 协议，让用户享受更加流畅清晰的直播画面。超级播放器提供极致流畅全面稳定的音视频播放服务，优质内核适配海量设备机型，集视频加密、数据洞察、精准 Seek 等强大功能于一身。AI 美颜特效特效滤镜、美颜美妆特效实时渲染、AI 识别定位五官、动态贴纸、手势识别、智能抠图等多样特效提升直播/短视频/音视频通话效果。短视频编辑为 App 开发者提供视频采集、剪辑、拼接、发布等最领先的短视频功能。音视频通话提供全平台互通的多人音视频通话和低延时互动解决方案。直播连麦支持实时的直播连麦，实现主播与观众之间的1 对多的视频连麦直播互动。多平台支持支持移动端、Web 端、小程序等全平台音视频通信终端能力。5000家300ms40 1次累计服务用户数超 5000 家通话场景国际链路端到端平均时延 1.不需要参与服务的运维 2.支持自动的扩缩容，丝滑的弹性能力，用户不需要提前规划容量 3.按实际用量付费，空闲时无费用CNCF 的定义中，Serverless 分为 FaaS（Function as a Service）和 BaaS（Backend as a Service）。FaaS 是函数计算，而 BaaS 则是各个后端服务，比如对象存储、云数据库其他使用后端接口形式提供服务的产品等，只要产品能满足用户以上三个好处，那么就可以认为是 Serverless。函数计算能满足 Serverless 所要求的 3 个特点，而对象存储作为 BaaS 中的一种，也能满足这 3 个特点。但目前主流的云数据库还没有完全支持这 3 个特点。传统云数据库，数据库实例内核进程直接写本地数据文件。当一台机器的存储使用已经接近 90%，即使整机的存量实例的计算资源负载再低，也无法再分配新实例了。在这种情况下，该机器上存量实例的用户，虽然没有使用计算资源，CPU 内存都是 0，也依然要承担机器计算资源的费用。反过来也一样，计算使用 90%，而存储使用量较少，也将导致剩余存储无法再售卖。按实际用量付费的问题本质是按实际用量分配资源。所以云数据库如果要迈向 Serverless 这个目标，要走的第一步就是计算存储分离，也就是 TDSQL-C 这款数据库产品最主要的特点。计算存储分离还有很多别的好处，比如存储空间和写带宽能突破单机上限，更强的容灾能力等等，但本文主要强调的是资源分配弹性灵活的特点。计算存储分离能使得计算和存储解耦，任意计算节点能访问任务的存储节点。计算和存储维护各自的资源池，分别各自最大化、最灵活地进行资源分配。存储层按存放的数据量收费，计算层按真正的负载收费。函数计算能实现按实际使用量计费，也是因为它只涉及计算，不涉及存储，将存储分离到数据库、对象存储中。另一方面，传统云数据库扩缩容需要搬迁数据到另一台物理设备，所以时间会很长。而计算存储分离架构，计算层扩缩容不需要搬迁存储层的数据，直接分配计算层资源即可，秒级即可以完成扩缩容。了解产品更多详情二维码20轻量化工具指南用户购买实例时需要指定最小到最大的规格，比如 1核2G 到 2核4G，我们会直接限制用户的规格到最大的 2核4G，然后根据用户的 CPU 使用负载对缓存数据(Buffer pool)进行扩缩容。这种资源限制方式可以让用户在 CPU 的使用上非常丝滑，没有扩缩容的时间，也不会因为刚开始规格很小，突发大量连接导致 oom。只是缓存的大小会随时间慢慢调整，进而引起性能的提升的延迟。TDSQL-C 定义算力单位 CCU（TDSQL-*C*C*ompute*U*nit）为 max(CPU,Mem/2，最小规格)，比如用户使用了 0 核 0.1G 内存的计算资源，则 CCU 为 0.25；使用了 3 核 1G 内存的计算资源，则 CCU 为 3；用户使用 0 核 1.6G 内存的计算资源，则 CCU 为 0.8。TDSQL-C 的计费模式是按照 CCU 使用量计费，每 5 秒采集一次，每小时求和结算。在没有暂停前，实例将在最小和最大 CCU 之间随负载而变化。最大 CCU 决定了实例承载突发负载的能力，同时也限制了异常的流量导致过多收费；最小 CCU 意味着低负载时进行的最小费用（如果实际使用算力小于选择的最小 CCU，则按最小 CCU 收费），也决定了空闲时缓存在内存的数据量，以应对之后突发请求的能力。21轻量化工具指南有的用户可能觉得刚刚 0 核 0.1G 内存的计算资源，CCU 为 0.25，还是多了，明明没有用 CPU 却还要收钱。那么我们带来了更进一步的无使用无费用的特性。与函数计算相同，在用户无负载时，TDSQL-C Serverless 会关闭计算进程并对计算资源不再不收费，这个过程称为自动暂停。在自动暂停后，用户对实例的访问会引起实例的重新部署然后重新提供访问，并开始计费，这个过程称为自动恢复。自动暂停的策略是用户一段时间（可以指定时长，最短 10 分钟）没有连接访问，则会触发进程关闭，不再对计算资源收费。所以用户应用程序的 SDK 如果有配置空闲的长连接个数，建议配置为 0 才能触发自动暂停，暂停后 CCU 为 0。因为涉及路由变更，自动恢复过程中需要客户端具有*重连机制*才能访问恢复后的实例。TDSQL-C Serverless 也提供手动暂停和手动恢复的功能。TDSQL-C Serverless 已经售卖了 1 年多，已经有非常多的用户在使用了。我们举例一些现在已经使用的典型用户：许多业务都有定时任务（左图），比如夜间清理过期数据、生成报表，每个月初计算上月的账单等等，通常这些类型的请求会伴随大查询，和高的 CPU 负载。如果用户购买一个大的规格，将在大部分时间花更多的成本；如果用户购买一个小规格，那么他的定时任务将没有足够 CPU 资源，而导致长时间运行，甚至产生 SQL 超时，或者影响其他在线业务请求。有许多的用户在开发测试环境使用了我们的 TDSQL-C Serverless（右图），这张图的周期是一周，在周一至周五的工作时间，我们按使用量计费；在周一至周五的夜间以及周末，我们将计算资源回收，不对计算资源收费。另外许多业务的数据库高峰期是在晚上和周末，包括社交网络、游戏、电商等等，我们通过把开发测试环境多余的计算资源回收的方式，来让出这部分 CPU 内存。通过混合部署节省不同场景业务的成本，这也正是云计算的初衷。应用场景Serverless-云函数 SCF是腾讯云为企业和开发者们提供的无服务器执行环境。只需使用平台支持的语言编写核心代码并设置代码运行的条件，即可在腾讯云基础设施上弹性、安全地运行代码。轻量化工具指南22 实时文件处理视频应用、社交应用等场景下，用户上传的图片、音视频的总量大、频率高，对处理系统的实时性和并发能力都有较高的要求。例如：对于用户上传的视频短片，我们可以使用多个云函数对其分别处理，对应不同的清晰度（1080p、720p 等），以满足不同场景下用户的需求，适应移动网络带宽较小且不稳定的特性。数据 ETL 处理一些数据处理系统中，常常需要周期性/计划性地处理庞大的数据量。例如：证券公司每 12 小时统计一次该时段的交易情况并整理出该时段交易量 top 5，每天处理一遍秒杀网站的交易流日志获取因售罄而导致的错误从而分析商品热度和趋势等。云函数近乎无限扩容的能力可以使您轻松地进行大容量数据的计算。我们利用云函数可以对源数据并发执行多个 mapper 和 reducer 函数，在短时间内完成工作；相比传统的工作方式，使用云函数更能避免资源的闲置浪费从而节省资金。全景录制方案所见即所的录制形式，以观众视角实现全景录制，高度还原音视频、白板、评论、特效等互动环节，免后期合成，即录即得。通过云函数计算实例快速启动，稳定支持超高并发业务需求，弹性扩缩容，以更低的成本加速业务上线迭代。移动及 Web 应用后端无服务器云函数和其他腾讯云云服务紧密结合，开发者能够构建可弹性扩展的移动或 Web 应用程序 轻松创建丰富的无服务器后端，而且这些程序可在多个数据中心高可用运行，无需在可扩展性、备份冗余方面执行任何管理工作。AI 推理预测在 AI 模型完成训练后，对外提供推理服务时，可以使用无服务器云函数，将数据模型包装在调用函数中，在实际用户请求到达时再运行代码。不仅能享受无需准备服务器或 GPU 服务器的费用节省、按实际调用量计费，还可以获得高并发请求下的自动扩容伸缩能力。产品特性Serverless-事件总线 EventBridge作为流数据和事件的自动收集、处理、分发管道，通过可视化的配置，实现事件源（例如：Kafka，审计，数据库等）和目标对象（例如：CLS，SCF 等）的快速连接。低代码提供完善的集成与被集成通路，帮助开发者快速实现的事件驱动的核心原子功能。高可用支持 Region 化、多可用区、分布式集群化部署，具备极强的容灾能力，利用不同云服务满足不同的业务场景和业务需求。数据处理集 成 数 据 处 理 能 力，上 游 对 接 Kafka、TDMQ、数据库等常见数据源，数据过滤、清洗、格式转换等可直接快速实现。快速构建提供高效便捷的事件管理方式，搭配所见即所得的事件目标，譬如函数，企业微信，短信等通路，帮助用户快速实现消息消费。丰富生态事件总线提供统一 Put Event 事件推送协议，兼容 CloudEvents 1.0 规范，全面拥抱开源社区生态，目前已完成 100 事件源，10 目标接入。配套能力提供事件查询，事件日志，事件审计及事件全链路查询能力。Serverless-消息队列 Pulsar 版消息队列 Pulsar 版是基于 Apache Pulsar 自研的消息中间件，具备极好的云原生和 Serverless 特性，兼容 Pulsar 的各个组件与概念。轻量化工具指南23 产品特性数据强一致TDMQ Pulsar 版采用 BookKeeper 一致性协议实现数据强一致性，将消息数据备份写到不同物理机上，并且同步刷盘。丰富的消息类型提供丰富的消息类型，涵盖普通消息、顺序消息（全局顺序/分区顺序）、分布式事务消息、定时消息。高性能低延迟能够高效支持百万级消息生产消费以及海量消息堆积，单集群 QPS 超过 10 万。消费者数量无限制消费者数量不受限于 Topic 的分区个数，并且会按照一定的算法均衡每个消费者的消息量。百万级 Topic计算与存储架构的分离设计，轻松支持百万级消息主题。整个集群不会因为 Topic 数量增加而导致性能急剧下降。隔离控制提供按租户对 Topic 进行隔离的机制，同时可精确管控各个租户的生产和消费速率。24轻量化工具指南大数据任务处理最佳实践，如何用Serverless实现事件驱动？架构选型上选云函数作为单个节点，由事件函数和触发器这两部分组成。事件函数是接收事件，处理返回结果，其入口函数形式是一个固定的Handler，然后给两个参数，一个是用户的event，一个是来自云函数系统的context。触发器是把特定事件进行加工，然后投递给设定函数，再去触发事件函数的运行，根据不同的触发器会有不同的功能。比如需要网络应用，常用API网关；数据来源于对象存储，就用COS触发器；去处理某一个函数的异常，需要读取日志，就用CLS触发器。在函数间传递消息主要通过事件总线或消息队列。事件总线能在云服务之间发标准格式事件，标准格式是CloudEvents 1.0。云服务之间还支持用事件规则去传递和过滤，并进行额外处理。事件总线的标准化，令在不同的云服务间传递消息非常方便，将来更复杂甚至还可以支持从数据库和其他一些渠道去订阅消息。消息队列重点在其维护了一个队列，有订阅上游的消息并发布给下游目标的功能。我们的消息队列，支持各种订阅版本，并会原生的支持重试和死信队列，这对复杂数据处理任务非常关键。云函数模型了解产品更多详情二维码25轻量化工具指南我们采取一个事件驱动的整体框架，最简单的模型就是云函数传递给事件总线，事件总线再把消息传递给云函数，云函数处理，再传递给事件总线。当我们面对一个很复杂的任务时，我们就能把这个任务拆分成若干个相对简单的部分。实例：这是一个音视频处理项目，要对总体积3TB的视频进行计算处理。云函数云函数云函数云函数26轻量化工具指南项目架构如图，其重点是几个云函数的使用，通过事件总线EB传递消息，通过文件存储CFS共享文件。这里需要在两个云函数之间传递大文件，因此将同一个CFS挂载在两个云函数上。源视频从对象存储COS中拉取出来，计算处理后最终将结果写入DB数据库，成为一系列结构化数据，这即是一个典型的将非结构化数据结构化的处理操作。项目结论：这样一个TB级数据项目，可做到以天为单位敏捷开发。弹性并发特性使得3TB的视频数据处理总共仅需一至两小时，且在极速运行的同时成本极低，项目成本仅需300元，且还有30%以上的进一步优化空间。全项目代码量非常低，该项目只有百行的代码，加上数十行配置与注释。项目开发历时仅22天，且其中有一大半时间在修复云SDK等基础设施的问题，预期后续项目还可以大幅度减少开发时长。高效的处理运行与简洁的计算模型带来快速敏捷的结果，整个项目工期之内可非常密集地发版本，便捷地使用全量数据的运行结果找出存在的问题，密集地进行修复，减少通过不断抽取小样本数据测试逐渐发现问题的过程。云函数微服务引擎 TSE 微服务引擎提供开源增强的注册配置中心（Zookeeper、Nacos、Etcd、Consul、Eureka 和 Apollo），服务治理中心（腾讯自研和开源的 PolarisMesh）和云原生网关（Kong）托管服务。微服务引擎完全兼容开源版本的使用方式，在功能、可用性和可运维性等多个方面进行增强，帮助用户快速构建微服务架构。轻量化工具指南27 产品特性一键部署您无需关注资源部署，微服务引擎提供一键式开箱即用的微服务注册、配置中心托管能力。无缝迁移托管引擎使用方式与开源框架完全一致，您可零代码改造实现无缝迁移。丰富的消息类型。免运维为您保证托管引擎后端的健康运行，您无需投入人力运维相关组件，让您专注于自身业务实现。灵活扩容提供一键扩容的能力，您可根据业务增长情况，轻易完成扩容与升级。隔离控制。高可用容灾提供多可用区部署、健康探测、自动恢复等能力，实现高可用容灾，保障您的服务持续、稳定、安全运行。低成本为您优化了托管服务的部署方式，让您在免运维使用微服务引擎时，能够获得更低的单位时间使用成本。应用场景微服务注册发现提供 consul、eureka、zookeeper 注册中心托管服务，并提供多指标的监控管理，帮助用户实现高效、稳定、高可用的服务注册发现能力。分布式配置提供配置热生效、记录配置变更操作的分布式应用配置集中管理能力，原生数据无缝迁移，支持主流的 apollo、spring cloud config 配置中心。分布式协调提供高效、稳定的分布式协调服务，为用户提供高可用的容错、数据备份机制，帮助提高灾备能力，保证数据的强一致性。28轻量化工具指南基于 Spring Cloud Tencent 快速构建高可用微服务应用一个公司在做微服务架构选型时，往往需要组装不同微服务中间件，例如把 Zookeeper 作为注册中心、Apollo 作为配置中心、Sentinel 作为限流中心等。每个公司、每个架构师可能都不一样。这会导致以下几个问题：1.运维同学需要熟悉运维很多的中间件 2.中间件组件多也会导致资源成本高 3.对于研发同学来说，需要记录很多中间件的服务地址，难以管理。同时不同组件的管控台体验上也不一致，使用成本高。北极星整体架构分为三层：1.API Server 层，提供 API 接口给管控台以及 SDK 2.核心领域层，是各个子模块的核心业务逻辑实现的地方。在实现层面，北极星的三个子模块都是独立实现，互相之间不耦合。3.存储层，Server 的内存缓存了服务列表、路由规则、配置数据等核心数据，绝大部分 SDK 请求都通过缓存直接响应请求。Redis 主要用于服务注册发现的心跳请求处理。Mysql 则用于数据的持久化。了解产品更多详情二维码微服务痛点北极星核心技术原理场景29轻量化工具指南Spring Cloud Tencent 是 Spring Cloud 的一套标准实现，并在 Spring Cloud 基础上拓展了更多的服务治理能力，例如服务路由能力、集群限流能力、元数据透传能力等。所有这些能力都以 Spring Cloud Starter 的标准形式提供给用户按需使用，并且使用成本非常低。通过 Spring Cloud Tencent 实现特性环境场景非常简单，只需要每个分组内部署的实例增加以下两个环境变量即可 SCT_METADATA_-CONTENT_ENV=dev1 以及 SCT_METADATA_CONTENT_TRANSITIVE=ENV。Spring Cloud Tencent 会自动读取这两个环境变量，并且在每次服务调用的时候，优先调用跟当前实例属于同分组的服务。场景：环境路由Spring Cloud Tencent 总览轻量化工具指南30 一站式服务与腾讯云的存储、计算能力无缝对接，一站式完成海量数据的存储和分析挖掘。全流程管理集数据处理、模型训练、预测、部署功能于一体，帮助不同业务场景的 AI 开发者完成全流程模型构建。框架全面支持 Tensorflow、Torch、PySpark 等主流训练框架，并支持一机多卡、多机多卡模式的 GPU 分布式计算。产品特性应用场景性能强大搭载万兆网卡的大量 CPU/G-PU 实体机，为 TB 级数据的模型训练提供坚实基础。计算加速内置自研 TI-ACC 加速服务，显著提高模型训练推理效率，降低成本。操作简便Notebook、SDK 操作模式符合高阶客户使用习惯，灵活敏捷；自动学习通过向导式方式构建模型，界面友好易用。泛互泛互的客户在很多对内或者对外业务里存在 AI 训练和推理场景，需要消耗大量的服务器成本，特别是在复杂场景的模型推理时，模型推理部分时延较高会带来机器成本较高。腾讯云 TI 平台 TI-ONE 提供从训练阶段的训练加速到推理阶段的推理加速能力，助力客户降本增效。金融金融行业的客户具备多样性，如何根据客户历史数据，对相关客户进行针对性理财产品推荐，是提高工作效率，提升金融机构效益，和提升用户体验的关键。腾讯云 TI 平台 TI-ONE 可以辅助金融机构建立用户购买行为预测模型，预测用户行为，从而对用户进行针对性理财产品推荐。DevOps 自动化实践随着行业的兴起，各类 AI 算法大赛不断，如何提供满足各参赛队伍的使用习惯的工具，同时又能支撑数千人的高并发一直是各举办单位的痛点。腾讯云 TI 机器学习平台内置的丰富算法与框架组件满足不同用户的使用习惯，高性能集群稳定性可以支持大批量的训练任务。AI-腾讯云TI平台腾讯云 TI 平台（TencentCloud TI Platform）是面向开发者、政企提供的全栈式人工智能开发服务平台，致力于打通包含从数据获取、数据处理、算法构建、模型训练、模型评估、模型部署、到 AI 应用开发的产业 AI 落地全流程链路。31轻量化工具指南低门槛开发AI：全栈AI平台开发新体验以高可靠，高性能，高扩展性为目标，公有云AI开发平台设计过程中，充分利用了腾讯云完善的云原生产品能力，平台底层围绕容器化底座TKE/EKS构建集群自动伸缩的能力，构建训练任务的调度管理机制，实现高扩展性。同时依托云原生的API网管和CLB负载均衡，横向扩容支撑海量推理服务请求，实现高可靠的生产环境支持。在系统构建策略上，采用vpc隔离策略，将应用系统组件部署在自研VPC网络中，用户算力集群部署在公有云vpc中，确保平台与行的稳定。AI开发领域，与传统软件开发不同的是，从0构建AI能力，特别是深度学习能力，开发人员仅仅写出代码往往不足以生产出可用的AI能力，满足实际业务要求的AI能力，意味着更高的精度，以及长期稳定的模型性能表现，随之而来的是更多的样本数据，更强的算力资源。即使是一个实验环境，从0开始搭建，往往也需要投入很高的成本。为此在建设AI开发平台的时候，我们着重考虑了围绕“低门槛”去构建一个高可靠，高性能，高扩展的AI开发平台。我们的平台工具都以低使用门槛为出发点进行构建，低使用门槛并不意味着功能简单，而是将算法开发人员最熟悉的开发习惯提供给用户，大到代码开发工具，小到函数的选型，我们都最大程度得为真实的用户减少学习成本。低资源投入门槛也是我们思考的一个方向，AI动辄几十卡的算力要求，已经成为算法开发人员最大的负担，在云上我们提供托管式的平台服务，实现即用即买，用完即释放的算力使用体验，最大程度降低用户算力资源的投入，同时有训练加速以及推理加速两大核心能力加持，进一步得缩减了算力资源的消耗。作为企业级的AI开发平台，低运营门槛也是建设时的核心考量，借助云上云原生监控体系，以及容器化底座的扩缩能力，实现让用户投入最少的人力获得最稳定的生产环境运行。了解产品更多详情二维码10轻量化工具指南TI-ACC训练加速在计算优化，通信优化，并行训练，显存优化等多个技术方向入手，对模型训练过程进行加速，最大限度得为算法工程师提供降本提速的基础能力。在计算优化方面，TI-ACC提供了灵活的策略，可以分阶段开启分配6 XLA计算图加速，并采用混合计算图机制，解决精度损失和负优化问题。在通信优化方面，TI-ACC通过优化通信次数，对梯度进行融合，减少梯度同步通信次数，通过优化通信拓扑，由原来的机外通信改为先机内同步，然后跨机同步，并通过进行Topk梯度压缩，减少通信量。在并行训练方面，采用混合并行，对conv层采用数据并行，对FC层采用模型并行，同时采用反向图显存优化，重构反向图，用计算时间换取现存消耗，以此支持亿级分类数大规模模型训练。针对超大batchsize训练，TI-ACC支持自动调节大batch学习绿，解决loss跳变问题，并通过AutoML 人功能精调分阶段搜索，提升调参效率和效果，找到了既增大batch size，又不降低精度的较优解。TI-ACC推理加速在通用模型转换，计算优化，以及一些深层性能的优化方面都进行了技术探索。TI-ACC基于PyTorch，TensorFlow等原生框架，通过子图切分替换，将加速能力嵌入原生框架，保证了接口与原生框架接口一致，以此确保了加速能力的通用性，降低了用户的使用门槛。在计算优化方面，采用常量折叠，对常量部分进行预计算，降低运行时计算，也采取了图优化，静态算子融合等优化方法，降低模型复杂度，进一步降低计算量。在架构设计中，通过细致的kernel设计，提高了GPU占用率，采用外积累加的方式实现指令级并行，加速推理计算。32轻量化工具指南全栈式内容安全解决方案机器智能高效检测与人工及时复审一体化，助力企业对于平台敏感内容实时管控，优化管理成本，提高管理效率。轻量化工具指南33 方案优势小程序生态审核能力审核标准对齐官方，保障小程序内容的合规安全。应用场景机器通用识别能力强智能引擎能力广泛应用于内部 App，如 QQ、空间、微信等；结合腾讯大数据舆情监控能力，紧跟内容趋势，模型自动迭代。底层能力集成方便快捷一体化方案已经与六大云产品（COS、点播、直播、TRTC、GME、IM）打通，腾讯云用户可在对应产品中一键开通审核服务。机器人工审核方案一体化智能引擎审核的同时，提供专业的人工审核服务，高效准确识别不良内容。直播、短视频、视频点播企业直播、娱乐直播、游戏直播等场景。头像、留言评论、即时通讯用户上传个人信息。公开场合的发言及评论。多人语音听书学堂线上连麦开黑、语音聊天房间场景。34轻量化工具指南全方位保障业务生命线：如何极速开发直播音图风控？腾讯云内容风控解决方案提供音频、视频、图片、文本四种数据类型的审核，提供涉黄、暴恐、广告、低俗等多种审核能力，并且支持让用户自己管理审核策略，针对不同行业场景配置专属拦截标签配置，并可以提供自定义词库和自定义图库快速覆盖新型的违规数据。内容风控总体技术架构可分为数据层、算法层、策略层、应用层和解决方案五层，其中数据层主要提供海量数据的存储和查询服务，算法层主要提供图像、音频和文本NLP的AI模型服务，以及包括规则检测和关键词匹配服务，为了更灵活地应用算法层能力，单独构建一套策略层服务，主要包括审核模型和标签管理配置服务，基于图片/文本/音频构建的专业知识库服务，同时具备对数据标准、模型训练、模型评测和模型发布的模型平台，结合算法层的原子能力模型和策略层的效果优化服务，实现对音频、视频、图片、文本的主动识别能力，并将主动识别能力集成到腾讯云产品，形成面向行业的综合解决方案。了解产品更多详情二维码35轻量化工具指南现阶段内容审核主要是利用机器学习技术，在图像、音频和文本的数据上训练出多种识别能力，包括人脸识别、OCR识别、图像识别、Logo识别、音频ASR和文本NLP能力，可以快速、低成本地从数据中提取违规元素信息，比如OCR识别可以从图片中识别文本，并通过文本NLP技术发现文字中是否有不合规的内容。在面向复杂的业务场景和快速变化的识别需求，基于单一模型提供识别能力的模型架构在效果调优效率方面会比较低，为了较好地解决这类问题，在底层识别能力上按原子化拆分到行为、场景、物品和人体部件等维度，通过模型组合和原子能力标签组合成模型策略，提供灵活集成，插拔可用的模型组合，满足不同行业和客户的差异化需求。示例，图片来自网络36轻量化工具指南在众多内容审核业务应用场景中，直播和点播业务应用会相对比较复杂，其中直播审核场景出现的内容需要具备比较高地实时发现和打击能力，并且为了确保产品体验，需要满足较多的时序规则，比如在考虑一下日常用语习惯，通过会在谩骂识别的基础上综合该行为的频次来决定是否需要处置。但在点播场景，由于内容载体主要为视频文件和音频文件，可采用先审后发的模型，在识别能力的基础上，增加一些队列服务，可灵活调配优先级，控制满足不同场景的审核时效。在腾讯云上，内容审核能力与多种云基础产品实现内置集成，可为客户提供一键开动，自助接入产品能力，在部分云产品中，还同时具备人工复审和自动化处置能力，进一步降低客户的接入成本。腾讯云区块链服务 TBaaS腾讯云区块链服务 TBaaS 提供高效、安全、开箱即用的区块链服务，1 站式管控、2min 极速部署、60%人力成本节省。轻量化工具指南37多引擎支持集 成 长 安 链 ChainMaker、Hyperledger Fabric、FISCO BCOS 等多种区块链底层引擎，为技术选型提供丰富多样的选择。轻松上手提供全生命周期完备的可视化操作能力，零门槛装配，用户只需聚焦应用的开发与创新，实现业务快速上链。安全隐私具备金融级隐私保护能力，提供多种可配置的软硬件加密技术，全方位保障数据传输安全可信。产品特性跨链服务（特色增值服务）自研跨链互操作服务，支持同构、异构链。基于跨链身份管理协议及组件实现不同参与方之间的高安全高可信的跨链协同治理。可信计算（特色增值服务）提供硬件级隐私数据安全防护，在保护数据不出域的前提下，实现多方数据可信共享、协同计算，保证数据可用而不可见。分布式身份（特色增值服务）为人、企、物等实体生成和验证全局唯一的身份标识符。为实体之间跨系统、跨边界的可信身份识别和数据交换提供基础设施。应用场景可信存证区块链价值：区块链分布式账本多方见证，不可篡改、不可抵赖典型案例场景：司法存证电子签章电子合同存证书信息追溯区块链价值：区块链链式结构，每个区块信息可追可查典型案例场景：版权保护冷链溯源农产品溯源高效协作共享区块链价值：区块链智能合约促进多方高效协作，分布式账本高效协作改变原有模式典型案例场景：电子证照管理医疗病例通认房产税费一体化征缴数字资产区块链价值：区块链分布式账本和可追溯性使得数字资产高效流转、减少对账流程典型案例场景：数字艺术品流转积分流通与通兑供应链金融38轻量化工具指南区块链服务TBaaS：轻松建链、用链、管链区块链技术优势：优化对账流程：基于分布式账本节省对账时间减少接口开发：基于分布式账本，各账本间时时数据互通，减少接口开发确保数据真实：基于链式结构和安全加密算法，保证数据安全可信，真实有效提速数据获取：基于P2P网络，各账本间数据时时同步，提升数据获取效率TBaaS的价值TBaaS核心优势1.降低业务落地门槛（屏蔽底层技术复杂度、降低建链用链管链技术成本、缩短区块链业务落地周期）2.区块链安全管控（统一纳管不同的业务链、多机构一键组网协作、实时运维能力保障安全稳定）3.助力链上业务动态扩展（连接底链与业务应用，动态可伸缩、跨域跨链服务突破多方协同瓶颈）了解产品更多详情39轻量化工具指南以云链结合、云为底座的腾讯云区块链服务平台TBaaS，是腾讯云打造的全球领先企业级区块链技术服务平台，为企业客户及开发者提供高效、安全、弹性、开箱即用的区块链服务。该平台率先完成与“长安链ChainMaker”自主可控区块链开源底链适配，腾讯云也因此成为国内首个支持长安链的云厂商。腾讯云TBaaS目前可支持开发者一站式、轻松构建基于长安链的区块链产业应用。1.建链组网：多引擎选配，多种组网模式，灵活满足不同业务场景诉求，区块链系统全方位安全加固2.合约开发：多语言合约引擎，全生命周期管控，一站式开发调试服务3.应用对接：多种上链工具，低门槛对接区块链网络4.查看交易：多种可视化组件，链上数据实时掌控了解产品福利活动观看课程完整视频

18人已浏览 2023-03-30 44页 5星级

碳中和下的云计算分析师：中桥调研咨询 分析师 马艳数据：中桥调研咨询，2022.08云计算成就绿水青山云计算成就绿水青山13全球碳排放现状全球碳排放现状20212021年，与能源相关的二氧化碳排放量创历史新高，再次给人类敲响警钟。年，与能源相关的二氧化碳排放量创历史新高，再次给人类敲响警钟。国际能源署（IEA）日前发布的全球能源回顾：2021年二氧化碳排放报告指出，2021年，全球能源领域二氧化碳排放量达到363亿吨，同比上涨6%，增长幅度创下了历史新高的同时，也抵消了新冠肺炎疫情以来因经济活动减弱带来的碳排放下降（下图）。与此同时，IEA的统计数据显示，2021年，全球可再生能源发电量超过了8000太瓦时，较2020年上涨了500太瓦时，也创下历史新高。整体上看，虽然低碳电力在电力供给中的占比已经超过了燃煤发电，但是，目前全球经济仍高度依赖化石燃料，且疫情期间全球经济显然并未实现“可持续复苏”。因此，加快能源转型的步伐并保障能源安全在当下更凸显其必要性。根据根据联合国政府间气候变化专门联合国政府间气候变化专门委员会（委员会（IPCCIPCC）全球升温）全球升温1.51.5特特别报告别报告，基于，基于巴黎协定巴黎协定提交提交的国家规定的减缓目标来估算全球的国家规定的减缓目标来估算全球排放结果，这些减缓的目标路径不排放结果，这些减缓的目标路径不会将全球变暖限制在会将全球变暖限制在1.51.5摄氏度。摄氏度。如果各国政府不能迅速将升温幅度稳定在1.5摄氏度及以下，气候变化的影响将持续恶化。届时许多自然系统将跨越危险临界点，造成永久性转变。气候变化的影响和对策与可持续发展紧密相关，涉及社会福祉，经济繁荣与环境保护等平衡发展与权衡取舍问题。人类活动产生的碳排放对全球环境人类活动产生的碳排放对全球环境的负面影响越发明显。的负面影响越发明显。工业革命带来了人类历史上前所未有的经济繁荣，到2021年全球人均GDP达到12517美元，比工业革命前翻了10番。然而200多年来，人类对化石能源和其他不可再生资源的需求成倍增长，当前地球每年自然资源被消耗的速度接近再生速度的两倍，现有的生产和生活方式已不可持绩。4全球多国通过政策驱动“碳中和”目标实现全球多国通过政策驱动“碳中和”目标实现为应对全球气候变化，世界主要经济体陆续作出碳中和目标的承诺：欧盟委员会公布2050年实现碳中和，并发布绿色新政；能源与气候智库统计，截至 2021 年 12 月，全球已有 136 个国家和地区承诺碳中和。在碳中和目标的驱动下，全球规划以风光水为代表的低碳化清洁能源，从2020年的能源占比26%，提升到2050年能源占比的60%，能源结构由化石能源加速向可再生能源转型。来源：英国能源与气候智库统计。国家国家中国中国印度印度美国美国日本日本韩国韩国南非南非德国德国俄罗斯俄罗斯印度尼西印度尼西亚亚澳大利亚澳大利亚占全球煤占全球煤炭总量炭总量50.2.0.6%3.1%2.5%2.2%1.9%1.8%1.8%1.6%碳中和承碳中和承诺时间诺时间20602050205020502050全球全球1010大煤电生产国关于碳中和的承诺大煤电生产国关于碳中和的承诺1990国际社会在联合国框架下开始关于应对气候变化国际制度安排的谈判1997达成京都议定书2020联合国一般性辩论时向全世界做出承诺2015达成巴黎协定1992达成联合国气候变化框架合约5中国双碳“中国双碳“1 N”1 N”政策体系政策体系中国降碳初显成效中国降碳初显成效。自“十二五”时期开始，中国持续将单位国内生产总值二氧化碳排放下降作为约束性指标，纳入国民经济和社会发展规划纲要，积极制定实施各项战略、政策与行动，取得了积极成效。2021年9月第76届联合国大会一般性辩论上，习近平主席再次强调中国将力争2030年前实现碳达峰、2060年前实现碳中和。目前目前，中国中国“碳达峰碳达峰、碳中和碳中和”采用采用“1 1 N” N”政策体系政策体系，聚焦聚焦20302030年前年前碳达峰目标碳达峰目标，对推进碳达峰工作做出总体部署对推进碳达峰工作做出总体部署。1中共中央、国务院：关于完整准确全面贯彻新发展理念做好碳达峰碳中和工作的意见 2030碳达峰行动方案降碳路径降碳路径优化能源结构推动产业和工业优化升级推进节能低碳建筑和低碳措施构建绿色低碳交通运输体系发展循环经济，提高资源利用效率保障措施保障措施推动绿色低碳技术创新发展绿色金融以扩大资金支持和投资出台配套经济政策和改革措施建立完善碳交易市场“十四五”时期（2021年-2025年）初步形成绿色低碳发展经济体系非化石能源消费比作达到20%左右单位国内生产总值能源消耗比2020年下降13.5%单位国内生产总值二氧化碳排放比2020年下降18%“十五五”时期（2026年-2030年）碳达峰阶段非化石能源消费比重达到25%左右单位国内生产总值二氧化碳排放比2005年下降65%以上“十六五”至“二十一五”时期（2031年-2060年）碳中和阶段非化石能源消费比重达到80%以上碳中和目标顺利实现开创人与自然和谐共生N6科技创新实现可持续发展科技创新实现可持续发展在全球科技竞争中在全球科技竞争中，科技创新成为关键科技创新成为关键。发力于科技端的“新基建”，包括大数据中心、人工智能、工业互联网、新能源汽车充电桩等，不仅有利于国家调整经济结构和能源结构，产生拉动中国经济的新动能，还能够使经济发展动力向科技创新、管理创新方面进行转变，从而实现可持续发展。科技创新给中国带来的不仅仅是生态环境的改善，也是发展质量的提升。比如，过去五年，风电、太阳能发电等新能源产业蓬勃发展，不断推动中国经济增长方式向绿色低碳转变。此外，在当前数字经济下，中国以科技创新提升产业发展质量的同时，还将有助于中国国际国内“双循环”发展格局，在“一带一路”走出去过程中，以数字化服务输出的方式，参与新形势下的国际合作和竞争。7云计算成就绿水青山云计算成就绿水青山到到20242024年，可助力减排超年，可助力减排超1010亿吨二氧化碳亿吨二氧化碳云计算与低碳化的协同发力，可以让人类社会的可持云计算与低碳化的协同发力，可以让人类社会的可持续发展变得有迹可循续发展变得有迹可循在交通领域在交通领域，依托云计算发展的智慧交通，可以缓解路面交通压力，从而降低碳排放量。在工业领域在工业领域，基于云计算的智慧厂房管理系统，对厂房系统及设备运行数据的自动获取和数据的互联互通，从而实现厂房系统安全可靠、高效节能、绿色低碳运行。在农业领域在农业领域，云计算能将传统农业靠天吃饭，转变为可控的智能生产模式，从而实现高效、低碳的效果。云计算既能应用于主粮生产监测，也能够为农作物的标准化生产及市场销售提供数据支撑，推动产业提质升级，同时为乡村低碳发展提供数据支撑。“绿色低碳“绿色低碳 资源云化”的数据中心改造势在必行资源云化”的数据中心改造势在必行碳达峰、碳中和要求数据中心将绿色化和硬件资源利用得更加充分。全国一体化大数据中心协同创新体系算力枢纽实施方案提出，打通跨行业、跨地区、跨层级的算力资源，构建算力服务资源池。为满足国家对数据中心建设的新要求和适应数字经济时代政企对算力资源灵活调度的新需求，一大批“老旧小散”的存量数据中心低碳化改造和云化升级势在必行。云计算碳减排总量云计算碳减排总量20242024年或超年或超1010亿吨亿吨据云计算领域的一项新预测表明，从2021年到2024年，继续采用云计算可以减少超过10亿吨的二氧化碳排放。相比于传统数据中心，云计算为企业带来了更低的成本、更短的上限周期和可伸缩性。云计算基于IT设备实时能耗监测则可以为用户数据中心实现精准节能管理。中桥中桥20222022云计算调研数据云计算调研数据2920232023年，云计算依旧持续火热年，云计算依旧持续火热57.4b.6Y.4%其他区块链虚拟现实（AR/VR/MR）云原生应用的部署边缘计算双模式IT(传统应用/传统架构 新应用/工业互联网或物联网人工智能云计算大数据贵公司未来12个月的IT战略三大重点是什么？所有受访者（N=399）企业级（1000人以上，N=155）中小企业（1000人以下，N=244）政策驱动企业深度上云用云：政策驱动企业深度上云用云：2021年的中华人民共和国国民经济和社会发展第十四个五年规划和2035年愿景目标纲要和“十四五”数字经济发展规划，2022年4月，工信部启动企业上云用云实施指南（2022）编制工作，持续深化企业上云行动，推动企业高质量上云用云。产业集聚效应明显，布局发展从东部向中西部逐步扩散：产业集聚效应明显，布局发展从东部向中西部逐步扩散：目前，我国云计算产业已形成京津冀、长三角、大湾区三大热点区域。2022年2月“东数西算”工程正式启动，云计算将成为“东数西算”中算力的关键载体与主要服务形式。中西部正在加大云计算领域的投入，云计算产业加速“下沉”，区域间的“数字鸿沟”预计将会进一步缩小。市场需求持续更迭，多种部署模式并存发展：市场需求持续更迭，多种部署模式并存发展：目前云计算部署模式仍以混合云、公有云和私有云为主，但随着用户在服务形态、平台性能、数据安全、建设成本等方面的需求层出不穷，市场又催生出分布式云、专有云、托管云等新型部署模式。行业应用水平参差不齐，阶梯状发展特点明显：行业应用水平参差不齐，阶梯状发展特点明显：位于第一梯级的互联网和信息服务业已基本实现云计算的深化应用。位于第二梯级的金融、政务、交通等行业云化改造能力持续加深。位于第三梯级的能源、医疗、工业等行业的核心系统云化改造程度有待提升。中桥调研的数据显示，云计算是中桥调研的数据显示，云计算是20232023年前三大年前三大IT IT战略重点之一。战略重点之一。近年来，越来越多的企业将业务迁移到云上，以降低经营风险、提高业务敏捷性等。特别是新冠肺炎疫情的到来，加速了企业上云的步伐，驱动着云市场快速增长。云计算作为信息技术发展和服务模式创新的集中体现，已成为企业及产业实施数字化转型的重要基础。10借助云计算推动业务创新成为主流借助云计算推动业务创新成为主流39.4%9.0.3).8%0%5 %05E%已经部署未来12个月内会部署未来12-24个月内会部署不会考虑云计算不确定贵公司处于云计算哪个阶段？*注：云计算1.0，主要用于中小企业、互联网公司或作为企业级用户补充资源（用于测试开发、审计、系统或应用升级等）。云计算2.0，企业级IT替代资源，支撑云原生应用创新（云原生应用、IoT、AI）的核心资源。云计算1.0云计算2.0目前，企业将越来越多的核心应用或负载向云端迁移，应用的迭代速度越来越快，加上越来越多的云原生应用的涌现，都加速了应用或负载的上云速度。企业需要将数据负担转化为数据资产，将应用交付转化为服务创新，这都推动了云计算升级，具体表现在：从资源平台向创新（应用交付）平台升级：从资源平台向创新（应用交付）平台升级：云计算、大数据、物联网、人工智能等新技术带来的全渠道应用数量增加和应用形态的快速改变，加速了云原生，刺激云计算向创新平台演进。企业基于AIOps构建跨传统数据中心和多云、边缘的创新平台，加速应用交付速度，加快应用价值转化。从补充资源，向作为核心资源转变：从补充资源，向作为核心资源转变：不同于早期的云计算作为企业的补充资源非核心资源，如今云计算逐渐成为企业级核心应用的重要支撑。不同于互联网企业，多数传统的企业级用户在云计算快速发展阶段，往往出现跨传统IT、公有云、多云跳跃式发展的需求。企业需要跨多云构建企业级创新平台，满足跨物理、虚拟和云之间海量查询处理的需求，加快业务响应速度，从而提高IT演进过程中企业的运营效率。从从IaaSIaaS向向PaaSPaaS升级：升级：中桥的调查数据显示，中国市场未来2年PaaS增长远高于IaaS增长。越来越多用户利用云平台、微服务和容器架构实现核心应用现代化，通过资源和开发平台深度整合，并提供基于人工智能的安全与合规管理。越来越多的企业正在通过云计算支撑新技术应用，以推动业务创新和企业发展。越来越多的企业正在通过云计算支撑新技术应用，以推动业务创新和企业发展。中桥调研咨询对中国企业级云计算市场的调查数据显示，中国企业级用户的云计算部署和应用正在从早期的云计算1.0（即云计算用于中小企业、互联网公司或作为企业级用户补充资源（用于测试开发、审计、系统或应用升级等）向企业级云计算2.0（即云计算作为企业级IT替代资源，支撑云原生应用创新（云原生应用、IoT、AI）的核心资源）演进。11混合云成为主流趋势混合云成为主流趋势近年来，各大云厂商纷纷加码布局，抢滩混合云。IBM并购红帽，AWS推出Outposts，微软推出了Azure Stack;阿里、华为、腾讯，以及联想集团等国内的主流云计算公司和科技公司相继推出自己的混合云的产品和解决方案，比如阿里推出了Apsara Stack，联想推出Lenovo xCloud，都是巨头的最新行动。企业应用混合云技术的优势不容小觑。混合云服务要求将公有、私有及本地数据库和系统有机结合起来，由此实现的灵活性能够让企业在不同平台上充分发挥各自优势、获取全面收益。第一，混合云能够更好地支持远程办公人员，帮助企业更灵活地支持远程及分布式员工，引导他们随时按需访问业务数据。第二，混合云还能降低企业运营成本。第三，混合云系统还有助于提升敏捷性与创新能力。第四，混合云能够支持有效的备份体系，更好地保障业务连续性。第五，混合云能够改进安全性与风险管理能力。信息安全已经成为企业技术应用中的重要考量因素。在中国，混合云的采用已成为主流趋势，成为企业价值创造的核心驱动力。在中国，混合云的采用已成为主流趋势，成为企业价值创造的核心驱动力。中桥调研的数据显示，未来的2023年和2024年，中国企业的IT形态都是以混合云为主，占比超过三分之一。受全球疫情和经济放缓的影响，中国企业正在加快上云步伐，以支持数字化业务转型。移动应用和物联网的日益普及，海量数据和快速变化的业务需求，都推动着云基础架构向更敏捷、更智能、更强的扩展性方向发展。在中国，许多企业正在采用混合云，来实现满足数据安全和行业合规的要求，以及扩展新兴IT技术的双重目标，混合云为企业提供两全其美优势。35.36.1%混合云：自有数据中心和公有云公有云私有云传统数据中心多云（不含混合云）跨任意IT资源即服务其他未来24个月，贵公司的IT形态以下面哪种为主？未来12个月未来12-24个月12部署部署/使用云计算时面临的三大问题使用云计算时面临的三大问题中桥调研的数据显示，2022年企业在部署或使用云计算时面临的三大问题分别是：“混合云或多云以及跨云边环境下的运维管理复杂”、“应用上云迁移复杂，周期长”、“混合云或多云，以及跨云-边环境下数据共享、数据分析”。具体而言体现在以下三个方面：跨云管理难统一：跨云管理难统一：混合云、多云正在迅速成为企业构建业务的创新平台。但是，由于各种云管理不兼容，增加企业在跨云管理难度，造成“云孤岛”。而通过API实现多云管理，往往能“看”不能“管”，无法保证工作负载跨不同云资源稳定安全。应用上云周期长：应用上云周期长：相对互联网公司、创新企业的云原生环境，企业级用户往往需要考虑如何在保证已有IT架构和应用安全稳定的前提下逐步演进升级。这个过程中，不论传统应用上云还是下云，整个迁移并不简单，应用“改造”比较复杂，这使得应用迁移周期长、成本高，并且还影响业务的稳定性。跨云边数据共享与分析难支撑：跨云边数据共享与分析难支撑：传统的批处理数据引擎已经完全无法满足现代企业对实时性的要求。而且，现有的流式数据系统大都基于消息模型，例如Kafka，Spark等。这些系统从本质上看，仅仅只是一些高速消息系统，缺乏一致性、可靠性、持久化等存储特性，因此很难适应当今物联网趋势下的各种复杂数据实时处理且计算准确的需求。近年来，企业在快速部署云计算过程中，普遍遇到管理多云、应用上云和云上云下数据安全等问题。近年来，企业在快速部署云计算过程中，普遍遇到管理多云、应用上云和云上云下数据安全等问题。混合云的优势相信大家已了然于心。企业可以将一些核心业务数据部署在本地的数据中心满足合规要求，而云原生和边缘应用或者是负载需求波动不可预测的业务应用，以及新业务开发，则部署在公有云，利用公有云的特点来快速实现触达用户的服务能力，保证2C查询交易激增业务稳定。但在部署和使用过程中，各种问题也都接踵而来。43.6F.9H.9%其他混合云或多云，以及跨云边环境下持续应用交付以及应用负载优化零信任安全混合云或多云，以及跨云-边环境下数据共享、数据分析应用上云迁移复杂，周期长混合云或多云以及跨云边环境下的运维管理复杂贵企业在部署或使用云计算时面临的问题？所有受访者（N=399）企业级（1000人以上，N=155）中小企业（1000人以下，N=244）13混合云实现方式混合云实现方式数据互联互通：数据互联互通：混合云作为云计算的一种形态，若无法实现公有云和私有云之间的数据流通，则极容易形成“云孤岛”。这反而会给企业业务应用带来阻碍。因此，混合云在应用普及过程中，首先要实现的就是在公有云和私有云之间间架起一条“数据通路”。这也是目前市面上各厂商提供的服务，即通过专线/VPN等多种方式去实现公有云和私有云之间“数据通路”。统一管理：统一管理：当然，数据层面的打通只是第一步。接下来则是要实现两种云之间的跨云管理与整合。根据中桥调查数据，48.9%的受访者表示跨云管理现在对企业业务发展至关重要。在混合云场景下，混合云管理应该是解决跨平台云管理的问题，为企业用户提供云资源和企业应用的配置、监控、自动化运维和管理服务，让企业能够轻松部署和管理跨公有云、私有云的重要商业应用和开源应用，降低企业云落地的门槛。工作负载双向迁移：工作负载双向迁移：在这之后，要解决的问题便是实现业务双向迁移。混合云并不是简单的把公有云和私有云堆砌在一起，而是通过将公有云、私有云打通，使两者无缝衔接，让数据在云中按需流动，产生新的业务价值。而如何实现工作负载跨云双向迁移是混合云应用时需要考虑的问题之一。因此，混合云的发展应为帮助用户去实现基于跨云的业务应用，从而真正将私有云的定制能力和公有云的共享及生态能力有机融合。创新驱动发展将推动混合云快速升级，企业不再满足基于创新驱动发展将推动混合云快速升级，企业不再满足基于VPNVPN的数据互联互通，或基于的数据互联互通，或基于APIAPI打通管理，而是需要企业级的一致性资源、一致性管理和一致打通管理，而是需要企业级的一致性资源、一致性管理和一致性服务，这将成为混合云的新趋势。性服务，这将成为混合云的新趋势。中桥调研的数据显示，未来两年，基于VPN通过混合云实现数据互联互通的用户占比，将从目前的42.1%下降到22.1%；基于混合云实现企业级一致性工作负载双向迁移的用户占比，将从目前的9.3%上升到31.8%。这种变化趋势显示了混合云的发展三阶段：42.1.3%9.3&.8%8.5.1.31.8.1%8.8%通过VPN实现公有云和私有云数据互联互通通过API实现公有云和私有云管理整合保证应用跨私有云和公有云实现工作负载不考虑混合云其他贵公司如何实现混合云？贵公司如何实现混合云？目前2年后14部署核心应用时，部署核心应用时，公有云的公有云的品牌选择品牌选择从市场格局来看，企业选择公有云部署核心应用时，会优先选择阿里云，其次为华为云和微软云。阿里云阿里云在不断提升产品优越性的同时在赋能传统企业数字化转型上持续发力，占比达27.57%。华为云华为云凭借技术设施即服务、技术即服务以及经验即服务的服务理念，在政企、互联网行业继续加速发展，占比达14.79%。微软云微软云业务收入快速增长，Azure平台提供200多种不同的产品和服务，可用于分析语音和图片、数据预测，甚至还面向诸如应用开发、安全以及物联网（IoT）等高需求服务，占比7.77%。AWSAWS持续加速“5 1 1”的全球优势在中国全面落地的同时，更在服务企业出海、汽车行业以及AI上加强投入，占比达4.51%。腾讯云腾讯云持续推动产业互联网数实结合，联合合作伙伴打造行业解决方案，赋能产业数字化转型，占比达3.51%。中国电信中国电信继续加强天翼云云网融合的差异化优势，打造“云-网-边-端-数-智-安-用”全栈云产品能力，占比达3.01%。中国云市场虽然起步较慢，但发展迅猛，其规模仅次于美国，是全球第二大云服务市场。中国云市场虽然起步较慢，但发展迅猛，其规模仅次于美国，是全球第二大云服务市场。展望未来，中国公有云市场规模有望从 2021 年的 320 亿美元增加到 2025 年的 900 亿美元。根据中桥调研的数据，到2024年，公共云的部署率将达到15.6%，仅次于混合云，成为中国企业第二大IT形态。27.57%3.51.79%3.01%4.51%7.774.09%阿里云腾讯云华为云天翼云（电信）AWS微软云（Azure）金山云浪潮云Ucloud百度云其他不会考虑公有云贵企业选择公有云部署核心应用时，首选哪家云服务商？中小企业（1000人以下，N=244）企业级（1000人以上，N=155）所有受访者（N=399）15基于上云的技术和业务需求，中国用户在选择公有云服务商时主要考量以下三大因素：“企业级功能以及得以验证的用户群，保证核心业务云层稳定安全性”、“提供满足企业级一致性的跨边缘、核心、云的工业互联网就绪架构”、“全球跨多云集中管理能力，实现企业云演进透明规划管理，以及国际化云计算服务能力”。简而言之，就是公有云服务商的服务积累、跨云-边-核心的平台化业务能力，以及出海服务能力，是中国企业在选择公有云时着重考量的因素。此外，Gartner也表示，超大规模边缘计算和安全接入服务边缘等新兴云技术正在为公有云提供商创造新的收入机会。未来，转向公有云作为推进其业务和技术战略的企业组织，将取得最大成功。0.3&.6D.6I.1S.6V.6i.2%其他完整的生态圈云计算开支中国本土技术，满足自主可控全球跨多云集中管理能力，实现企业云演进透明规划管理，以及国际化云计提供满足企业级一致性的跨边缘、核心、云的工业互联网就绪架构企业级功能以及得以验证的用户群，保证核心业务云层稳定安全性评估公有云服务商的三个重要考虑因素是什么？所有受访者（N=399）企业级（1000人以上，N=155）中小企业（1000人以下，N=244）评估公有云的三个考虑因素评估公有云的三个考虑因素关于中桥中桥调研咨询成立于2006年，是一家专注于IT基础设施、IT架构、新应用、新技术等相关领域的调研、咨询、Go To Market服务的公司。公司致力于从全球视角结合调查数据和市场技术，为IT厂商和IT专业人士提供前瞻性、可信赖的市场和技术趋势参考。联系我们微信公众号010-85655510contactsino-

40人已浏览 2023-03-27 16页 5星级

2023 云安全联盟大中华区版权所有1 2023 云安全联盟大中华区版权所有22023 云安全联盟大中华区-保留所有权利。你可以在你的电脑上下载、储存、展示、查看及打印，或 者访问云安全联盟大中华区官网（https:/www.c-）。须遵守以下：(a)本文只可作个人、信息获取、非商业用途；(b)本文内容不得篡改；(c)本文不得转发；(d)该商标、版权或其他声明不得删除。在遵循 中华人民共和国著作权法相关条款情况下合理使用本文内容，使用时请注明引用于云安全联盟大中华区。2023 云安全联盟大中华区版权所有3致 谢致 谢云安全联盟大中华区（简称：CSA GCR）区块链安全工作组在 2020 年 2 月份成立。由黄连金担任工作组组长，9 位领军人分别担任 9 个项目小组组长，分别有：知道创宇创始人&CEO 赵伟领衔数字钱包安全小组，北大信息科学技术学院区块链研究中心主任陈钟领衔共识算法安全小组，赛博英杰创始人&董事长谭晓生领衔交易所安全小组，安比实验室创始人郭宇领衔智能合约安全小组，世界银行首席信息安全架构师张志军领衔 Dapp 安全小组，中国移动集团信安中心高工于乐博士领衔去中心化数字身份安全小组，北理工教授祝烈煌领衔网络层安全小组，武汉大学教授陈晶领衔数据层安全小组，零时科技 CEO 邓永凯领衔 AML 技术与安全小组。区块链安全工作组现有 100 多位安全专家们，分别来自中国电子学会、耶鲁大学、北京大学、北京理工大学、世界银行、中国金融认证中心、华为、腾讯、知道创宇、慢雾科技、启明星辰、天融信、联想、OPPO、零时科技、普华永道、安永、阿斯利康等六十多家单位。本白皮书主要由共识算法安全小组专家撰写，感谢以下专家的贡献：原创作者：陈 钟关 志王 珂审核专家：黄连金 江 洪郭鹏程姚 凯关于研究工作组的更多介绍，请在 CSA 大中华区官网（https:/c- CSA GCR 秘书处给与雅正!联系邮箱：researchc-;国际云安全联盟 CSA公众号。2023 云安全联盟大中华区版权所有4序 言序 言从早期的分布式一致性算法的缓慢发展到现如今区块链共识的百花齐放，共识算法的发展已经走过了四十年左右的时光。随着区块链技术的快速发展，共识算法也在不断演进和提高，不同的共识算法的侧重点不同，因此它们所面临的问题、环境也不一样。共识算法，可以理解为是为了实现分布式一致性协议而产生的一系列流程与规则。当分布在不同地域的节点都按照这套规则进行协商交互之后，最终总能就某个问题得到一致的决策，从而实现分布式系统中不同节点的一致性。共识算法与共识安全白皮书深入介绍了 CFT 类共识算法、经典拜占庭共识和开放 BFT 类共识等三大类共识算法，并延伸到了共识算法安全性分析和测试方法。报告旨在提供一份系统的关于共识算法安全的知识，从共识算法理论和实现两方面展开安全测试和分析，理论分析主要从算法本身展开分析，实现分析从算法的具体参数、代码实现、应用部署等都方面进行安全分析和测试。基于测试方法和标准，对共识算法安全的典型安全进行分析，并给出分析过程和结论。报告以超级账本和以太坊共识算法为例，探索这些项目在共识算法安全领域的实践经验。报告旨在为区块链开发者、投资者、组织机构在共识算法安全领域提供指导，通过详细数据和案例进行论证，力求将理论与实践更好结合，希望能为您提供有关共识算法的有益信息，帮助您更好地理解和应用这项技术。李雨航 Yale LiCSA 大中华区主席兼研究院院长 2023 云安全联盟大中华区版权所有5目录1 共识算法介绍共识算法介绍.61.1介绍.61.2 CFT 类共识算法.61.3 经典拜占庭共识.91.4 开放 BFT类共识.172 共识算法安全性分析共识算法安全性分析.362.1安全建模.362.2 分析方法.392.3 攻击方法.413 共识算法安全测试方法和标准共识算法安全测试方法和标准.483.1 共识算法安全理论分析和模拟.483.1.1 共识算法安全理论分析.483.1.2 安全性与恶意攻击类型.493.1.3 应对策略.503.1.4 共识算法安全模拟.513.2 共识算法安全渗透测试和代码安全审查.553.2.1 安全指标.553.2.2 渗透测试.573.2.3 渗透测试工具和代码安全审计.583.3 共识算法安全 CheckList.594 共识算法安全案例分析共识算法安全案例分析.624.1 51%攻击.624.2 DDoS 攻击.634.3 BGP 劫持攻击.645 共识算法安全的最佳实践共识算法安全的最佳实践.645.1 超级账本的共识算法安全最佳实践.645.2 以太坊共识算法安全最佳实践.66参考文献参考文献.69 2023 云安全联盟大中华区版权所有61 共识算法介绍1.1介绍共识问题是社会科学和计算机科学等领域的经典问题，计算机科学领域的早期共识研究一般聚焦于分布式一致性，即如何保证集群中所有节点中的数据完全相同并且能够对某个提案（Proposal）达成一致，主要解决的问题是因节点失效、节点间网络故障及分布式系统的运行速度的差异而带来的系统不一致问题。Fischer等在 1985年提出了 FLP 不可能原理，即在网络可靠，但允许节点失效（即便只有一个）的最小化异步模型系统中，不存在一个可以解决一致性问题的确定性共识算法1。Eric Brewer在 1998年提出了 CAP 理论，指出在异步的网络模型中，所有的节点由于没有时钟，仅仅能根据接收到的消息作出判断，系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）这三项中的两项2。FLP 不可能性可以采用更弱的终止条件或者更强的网络假设解决，Ben-Or 在 1983年提出了完全异步模型下概率终止的共识算法3，Dwork等人在 1988年提出了部分异步模型下的共识算法，保证在网络同步的时侯算法能够确定性终止4，Leslie等在 1982年提出了同步模型下的共识问题5。早期的共识算法一般也称为分布式一致性算法，与目前主流的区块链共识算法相比，分布式一致性算法主要面向分布式数据库操作、且大多不考虑拜占庭容错问题，即假设系统节点只发生宕机和网络故障等非人为问题（CFT,Crash Fault Tolerance），而不考虑恶意节点篡改数据等问题（BFT,Byzantine Fault Tolerance,拜占庭容错）。拜占庭容错问题是Leslie 在 1982年提出的分布式领域容错问题，它是分布式领域中最复杂、最严格的容错模型5。在该模型下，系统不会对集群中的节点做任何的限制，节点可以向其他节点发送随机数据、错误数据，也可以选择不响应其他节点的请求.这些无法预测的行为使得容错这一问题变得更加复杂。1.2 CFT类共识算法CFT 类共识算法只保证分布式系统中节点发生宕机错误时整个分布式系统的可靠性，而当系统中节点违反共识协议的时候无法保障分布式系统的可靠性，因此 CFT共识算法目前主要应用在企业内部的封闭式分布式系统中。目前流行的 CFT共识算法主要有 Paxos算法及其衍生的 Raft共识算法。此外，获得较多研究关注的共识算法还有两阶段提交（Two-Phase Commit）算法、三阶段提交（Three-Phase Commit）算法、Zab、Kafka 等。2023 云安全联盟大中华区版权所有71.2.1 Paxos共识算法Paxos共识算法是基于消息传递的一致性算法，由 Leslie Lamport 在 1990年提出6，该算法基于同步性假设，通过引入超时（Timeout）概念规避了 FLP 不可能问题，如果在确认下个值的过程没有进展，Paxos会等到超时，然后重新进行共识的步骤。Paxos的算法步骤如下：阶段阶段 1：准备请求：准备请求1)提案者选择新的提案号（n），然后向接收者发送“准备请求”。2)当接收者收到准备请求(“prepare,”n)，且 n 比已经接收到的其他准备请求大，接收者会发出消息(“ack,”n,n,v)或(“ack,”n,)。3)接收者承诺不会再接纳任何提案号小于 n 的准备请求。4)如果有的话，接收者会发出具有最高提案号的提案值（v），反之则发出空消息 。阶段阶段 2：接收请求：接收请求1)如果提案者收到大多数接收者的响应，则可以发出带有提案号 n 和价值 v 的接收请求(“accept,”n,v)。2)n 是准备请求中出现的数字。3)v 是响应中具有最高提案号的提案值。4)当收到接收请求(“accept,”n,v)时，除非接收者已经采纳了大于 n 的提案号，否则接收者就会采纳这个请求。阶段阶段 3：学习阶段：学习阶段1)每当接收者采纳了一个提案，就会向所有学习者返回(“accept,”n,v)。2)学习者从多数接收者那儿得到(“accept,”n,v)，选定最终的值 v，然后向其他学习者发送(“decide,”v)。3)学习者收到(“decide,”v)和最终决定的值 v。2023 云安全联盟大中华区版权所有8图1Paxos算法示意为了提供部署的灵活性，Paxos 描述的许多主要特性都是开放式的，比如领导者选举、侦错、日志管理等内容。这种设计选择后来成为 Paxos 最大的缺点之一，使得 Paxos不仅难以理解，而且难以实施。1.2.2 RAFT 共识算法因为 Paxos晦涩难懂，2013 年 Ongaro 和 Ousterhout 为 Raft 复制状态机提出了一种新型共识算法7，其核心目标是可理解性，主要有两方面的改进：1）将整体算法的描述分解为子问题）将整体算法的描述分解为子问题Raft 算法将其整体划分成了几个子问题，每个子问题都可以独立解释，从而理解 Raft算法只需要相对独立地理解几个子问题即可。Raft 算法可分为以下几个子问题：Leader election：描述如何从集群节点中选举出 Leader；Log Replication：描述如何将日志同步到各个节点从而达成一致；Safety：定义了一组约束条件保证 Raft 算法的强一致性；Membership changes：描述如何变更集群关系（增加或者减少节点）。2）简化状态空间）简化状态空间Raft 算法尽可能地确定各个环节的状态。典型地，Raft 算法采用 strong leader 模型，每个日志的读写均由 Leader 从中主动协调，整体系统的数据流变得非常简单：从 Leader流向 Follower。而且每个节点的状态也只有 3 种：Leader，Candidate 和 Follower。如图 2所示：2023 云安全联盟大中华区版权所有9图2 RAFT数据流此外，Raft 使用两个超时机制控制领导人选举，分别是选举超时及心跳超时。在 Raft中，如果节点宕机并重启后，在试图声明成为领导者（Leader）之前，需要至少等待一个超时周期，并且一定会有所进展。1.3 经典拜占庭共识经典拜占庭共识算法能够保证当系统中不超过一点数量的节点发送拜占庭行为时，系统仍能够保持一致性。经典拜占庭容错系统普遍采用的假设条件包括：（1）拜占庭节点的行为可以是任意的，拜占庭节点之间可以共谋；（2）节点之间的错误是不相关的；（3）节点之间通过异步网络连接（如 Internet 网络），网络中的消息可能丢失、乱序到达、延时到达；（4）服务器之间传递的信息，第三方可以知晓但不能篡改或伪造信息的内容，可以通过签名技术实现这一点。目前主要有两种类型的经典拜占庭协议，一种是基于状态复制的，称为 Agreement-Based协议，通过节点间的相互通信达成对请求序列的共识；另一种是 Quorum-based协议，客户端直接与节点交互，乐观地执行请求。前者一般通信复杂度较高，后者处理争议的代价比较高。BFT 类算法效率一般较低，很难实用，学术界和业界对 BFT 协议进行了大量改进，其优化的主要思路是针对无拜占庭错误的场景，尽可能降低协议复杂度，提高效率。1.3.1 Agreement-based BFT 协议Agreement-based BFT 协议通常需要有一个主节点作为网络中的枢轴，与其他节点相比，主节点在共识过程中起最主要的作用，但通常也会成为系统性能的瓶颈。主节点需要将客户端发来的请求排序后发送给所有的备份节点，所有节点通过互相通信后达成一致，2023 云安全联盟大中华区版权所有10实现安全性（Safety），大多数协议中所有节点也会向客户端回复响应，实现活性（Liveness）。该类协议通常需要 3f 1个节点实现对 f个拜占庭节点的容错。1.3.1.1 PBFT协议PBFT是 Castro和 Liskov在 1999年提出的8，是第一个“实用”的拜占庭容错算法，解决了原始拜占庭容错算法效率不高的问题，将算法复杂度由指数级降低到多项式级（2），使得拜占庭容错算法在实际系统应用中变得可行。首次提出在异步网络环境下使用状态机副本复制协议，并且通过优化在早期算法的基础上把响应性能提升了一个数量级以上。PBFT中的很多机制都受到 Paxos的影响。PBFT在保证活性和安全性（Liveness&Safety）的前提下，提供了(n-1)/3的容错性，即如果系统内有 n个节点，那么系统最多能容忍的恶意/故障节点为(n-1)/3个。PBFT是一种状态机副本复制算法，所有的副本在一个视图（view）轮换的过程中操作，主节点通过视图编号以及节点数集合确定，即：主节点 p=v mod|R|。v：视图编号，|R|节点个数，p：主节点编号。算法主体流程如图 3所示，共分为 5个阶段：图3 PBFT算法流程1.REQUEST客户端 c向主节点 p发送请求并签名，其中 o为请求的具体操作，t 为时间戳，c为客户端标识，REQUEST 包含消息内容 m，以及消息摘要 d(m)。2.PRE-PREPARE主节点对收到的请求做校验，如果校验通过，则分配一个编号 n，编号 n主要用于对客户端的请求排序，然后主节点广播一条,m消息给其他副本节点并签名，其中 v为视图编号，d 为客户端消息摘要，m为消息内容。3.PREPARE 2023 云安全联盟大中华区版权所有11副本节点 i 收到主节点的 PRE-PREPARE 消息，进行校验，如果校验通过，则向其他节点包括主节点发送一条消息并签名，其中 v,n,d,m与上述 PRE-PREPARE消息内容相同，i 是当前副本节点编号。记录 PRE-PREPARE和 PREPARE 消息到 log中，用于 View Change过程中恢复未完成的请求操作。4.COMMIT主节点和副本节点收到 PREPARE消息，需要进行校验。如果副本节点 i 收到了 2f 1个验证通过的 PREPARE消息，则向其他节点包括主节点发送一条消息并签名，其中 v,n,d,i 与上述 PREPARE 消息内容相同。记录 COMMIT 消息到日志中，用于 View Change 过程中恢复未完成的请求操作。记录其他副本节点发送的 PREPARE 消息到 log中。5.REPLY主节点和副本节点收到 COMMIT 消息，需要进行校验。如果副本节点 i 收到了 2f 1个验证通过的 COMMIT 消息，说明当前网络中的大部分节点已经达成共识，运行客户端的请求操作 o，并返回给客户端，其中 r是请求操作结果，客户端如果收到 f 1个相同的 REPLY 消息，说明客户端发起的请求已经达成全网共识，否则客户端需要判断是否重新发送请求给主节点。记录其他副本节点发送的 COMMIT 消息到 log中。如果主节点作恶，它可能会给不同的请求编上相同的序号、或者不去分配序号、或者让相邻的序号不连续，副本节点应当有职责主动检查这些序号的合法性。客户端设置超时机制。如果主节点掉线或者由于作恶而不广播客户端的请求，一旦超时，则向所有副本节点广播请求消息。副本节点检测出主节点作恶或者下线，发起 View Change协议。为了确保在 View Change的过程中，能够恢复先前的请求，每一个副本节点都记录一些消息到本地的 log中，当执行请求后副本节点需要把之前该请求的记录消息清除掉。最简单的做法是在 Reply消息后，再执行一次当前状态的共识同步，但这样做的成本比较高，因此可以在执行完多条请求 K（如 100条）后执行一次状态同步。这个状态同步消息就是CheckPoint消息。PBFT算法由于每个副本节点都需要和其他节点进行 P2P的共识同步，因此随着节点的增多，性能下降得很快，但在较少节点的情况下可以有不错的性能。2023 云安全联盟大中华区版权所有121.3.1.2 Chain协议Chain协议是 Van Renesse等在 2004年提出的一个共识协议9，与 PBFT 不同的是其采用链式传播路径：从主节点开始，每一次传播时即加入该节点的摘要信息。当客户端较多时，Chain通常会比 PBFT、Zyzzyva 等有更高的吞吐量。1.3.1.3 Ring协议Ring协议是 Guerraoui等在 2010年提出的共识协议10。该协议使用环形拓扑方式传递消息，即每个节点都有消息的上一个发送者和下一个接收者，以此方式降低对部分节点分配更多工作而形成的性能瓶颈问题。对有无错误的不同场景，Ring分别采用两种运行模式：快速模式（Fast Mode）和弹性模式（Resilient Mode），并采用 ABSTRACT 框架进行切换。1.3.1.4 Honey Badger BFTHoney Badger BFT 是 Miller等人在 2016年提出的共识协议61。该协议基于异步网络假设，是第一个实用的异步 BFT共识算法。相比于 PBFT，Honey Badger BFT在现实的网络环境下具有更好的吞吐量及确认延迟。Honey Badger BFT 并不分主节点和从节点，每个节点都公平的接收交易，每个节点都各自维护交易池。每轮开始时，每个节点会从交易池里随机选择出交易组成交易集合 Ui，并利用 Reliable broadcast（RBC）协议广播给其它节点。RBC协议是为了降低广播带宽而设计的，其主要思路是发送节点将消息分割成 n份，分别发送给其它的 n个节点，n个节点直接通过相互广播即可恢复出消息，其中为了能够容纳 f个恶意节点，只需要其中 n-f个碎片即可恢复出消息。接着节点运行二元拜占庭协议（Binary Byzantine Agreement，BBA）剔除无效交易和重复交易，得到一个异步公共交易子集（Asynchronous CommonSubset）。受 FLP不可能定理所限，Honey Badger BFT 协议的在异步网络下为一个非确定性共识协议，可能无法终止。1.3.1.5 HotstuffHotstuff是 Yin等人在 2019年提出的共识协议62。HotStuff是一个三阶段投票的BFT类共识协议，通过引入门限签名及新型网络拓扑结构实现了 O(n)的通信复杂度，并通过流水线技术提高了共识效率。2023 云安全联盟大中华区版权所有13Hotstuff将视图切换流程和正常流程进行合并，不再有单独的视图切换流程，降低了视图切换的复杂度。为此，Hotstuff为正常流程引入了新的确认阶段，把 PBFT 的两阶段确认扩展成了三阶段确认：pre-commit 阶段、commit 阶段及 decide 阶段。为了减少通信量，HotStfuff引入了门限签名技术。在 HotStuff 的三阶段确认中，从节点会对消息进行门限签名并发送给主节点，当主节点收到足够多的签名时，将签名聚合导出完整签名，并在向从节点广播下一阶段消息时附上该签名，供从节点验证。Hotstuff 用门限签名和链式结构把节点轮换、区块链出块以及拜占庭共识结合了起来，使得无论是出块、拜占庭共识还是区块轮换都有了一个非常简洁并且完全一致的形式，并且将节点轮换和拜占庭共识的通信复杂度降到了 O(N)。但缺点是由于多了一轮共识，其交易确认延迟相比其它 BFT算法要高。1.3.1.6 LibraBFT作为 Facebook DIME项目（曾经命名为 Libra）的共识算法，LibraBFT 在 HotStuff 的基础上引 入显示活跃度的机制并提供了具体的延时分析。LibraBFT 在 3f 1 个验证节点之间收集投票，这些验证者可能是诚实的节点也可能是拜占庭节点。在网络中有 2f 1 个诚实节点的前提下，Libra 能够抵御 f 个验证节点的双花攻击和分叉攻击。LibraBFT 在一个有全局统一时间（GST），并且网络最大延时（T）可控的 PartialSynchrony 的网络中是有效的。并且，LibraBFT 在所有验证节点都重启的情况下，也能够保证网络的一致性。严格说来，LibraBFT 是基于 HotStuff 的一个变种，叫链式 HotStuff（ChainedHotStuff）。链式 HotStuff 是在基本 HotStuff（Basic HotStuff）上引入流水线概念，进一步提升效率的一个改进共识协议。libraBFT 最初会选择一些在不同地理上分布的创始成员做共识节点，以后逐渐的将共识节点对外开放，并基于 libra 稳定币的多少选择共识节点，也就是转变成 PoS 机制。libraBFT 的共识流程是分为不同轮次（Round），每一轮中一个 Leader 主节点被选 出。主节点会提议一个区块，里面包括多个交易。该区块将广播给其它共识节点。其它共识 节点会验证区块里的交易，并对其投票。主节点收到大多数（超过 2f 1，f 是系统中能容忍的拜占庭节点数）节点的投票后，主节点把确认消息发给所有共识节点确认。如果主节点没收到大多数投票，或者主节点出现故障，副本共识节点的定时将超时，副本节点会发起新一轮提议。2023 云安全联盟大中华区版权所有14libraBFT 在 HotStuff 基础上的改进主要在于提供一个详细的参与同步轮次的Pacemaker 设计和实现。并提供对实际交易确认的活性分析。LibraBFT 提供对共识节点投票权力的重配置机制。同时它给出了对提议节点和投票节点激励的机制。LibraBFT 的白皮书给出了如何检测投票节点破坏正确性的行为，为今后在协议中加入惩罚机制打下基础。同时白皮书也详细讨论如何同步，使得投票节点能同步它们的状态。libraBFT 白皮书采用Rust 语言描述协议。在 LibraBFT 中，为了更好地支持 Libra 生态系统的目标，LibraBFT以多种方式扩展 和调整了核心 HotStuff 协议和实现。重要的是，LibraBFT 重新定义了安全条件，并提供了 安全、活性和更高响应度的扩展证明。LibraBFT 还实现了一些附加功能。首先，通过让验证器对块的结果状态(而不仅仅是交易序列)进行集体签名，LibraBFT使协议更能抵抗非确 定性错误，还允许客户端使用法定人数证书来验证读取的数据库。其次，LibraBFT 设计了 一个发出明确超时的起搏器，验证器依靠法定人数进入下一轮而不需要同步时钟。第三，LibraBFT 打算设计一个不可预测的领导者选举机制，其中一轮的领导者由最新提交的块的提议者使用可验证的随机函数 VRF 确定。这种机制限制了攻击者可以针对领导者发起有效拒绝服务攻击的时间窗口。第四，LibraBFT 使用聚合签名保留签署仲裁证书的验证者的 身份。这使我们能够为有助于仲裁证书的验证人提供激励，聚合签名也不需要复杂的密钥阈值设置。具体实现细节如下：LibraBFT 共识组件最主要的是实现了 Actor 程序模型，使用消息传递在不同的子 组件之间进行通信，其中 tokio 框架用作任务运行时。Actor 模型的主要例外是(因为它是由几个子组件并行访问的)是共识数据结构 BlockStore。BlockStore管理块、执行、仲裁证书和其他共享数据结构。共识组件中的主要子组件是：TxnManager 是内存池组件的接口，支持拉取交易以及删除已提交的交易。提议者使用来自内存池中的按需拉取交易形成提议块。StateComputer 是访问执行组件的接口。它可以执行块，提交块，并可以同步状态。BlockStore 维护提议块树、块执行、投票、仲裁证书和持久存储。它负责维护这些数据结构组合的一致性，并且可以由其他子组件同时访问。EventProcessor 负责处理各个事件，如 process_new_round、process_proposal、process_vote。它公开每个事件类型的异步处理函数和驱动协议。2023 云安全联盟大中华区版权所有15Pacemaker 负责共识协议的活性。它由于超时证书或仲裁证书而改变轮次，并在它是当前轮次的提议者时提出阻止。SafetyRules 负责共识协议的安全性。它处理仲裁证书和分类信息以了解新的提交，并保证遵循两个投票规则 即使在重启的情况下（因为所有安全数据都持久保存到本地存储）。所有共识消息都由其创建者签名，并由其接收者验证。消息验证发生在离网络层最近的地方，以避免无效或不必要的数据进入协商一致协议。1.3.2 Quorum-based BFT 协议Quorum机制是一种分布式系统中常用的机制，用来保证数据冗余和最终一致性的投票算法。其主要思想来源于抽屉原理，常用于分布式系统的读写访问控制11。该类共识协议不需要节点间相互通讯，而是由节点直接执行并响应客户端发来的请求。当受到足够数量的响应后，客户端才会将结果最终提交。但是当出现拜占庭错误场景时，通常会花费较大的代价解决。另外，由于缺少对请求的排序机制，Quorum方法无法处理有竞争（Contention）的情况。1.3.2.1 Q/U协议Q/U协议（Query/Update）是 Abd-El-Malek在 2005年提出的一个基于 Quorum的协议12，该协议没有主节点为请求排序，而是由客户端直接向节点发送请求并由节点反馈结果，最多能容忍(n-1)/5个恶意/故障节点。1.3.2.2 HQ协议HQ 协议（Hybrid Quorum）Cowling等人在 2006年提出的共识协议13，该协议综合参考并优化了 Q/U协议和 PBFT协议，最多能容忍(n-1)/3个恶意/故障节点。对没有竞争的情况，该协议对 PBFT节点间通讯做了简化，将共识分为两个阶段：第一阶段是客户端发送请求并收集节点的状态信息；当收到结果表明 2f 1个节点状态相同且可以执行请求后，开始第二阶段信息发送并由节点执行请求。如果发现有竞争，则采用类似 PBFT的解决过程，性能退化为和 PBFT类似。1.3.2.3 Quorum协议Quorum协议是 Guerraoui等人在 2010年提出的基于 Quorum机制的一个共识协议14，主要为没有客户端竞争的非异步网络设计，只需要 3f 1个节点进行拜占庭容错。当没有错误产生时，Quorum协议的传播路径和 Q/U类似，节点独立执行请求并自己维护一个执 2023 云安全联盟大中华区版权所有16行历史记录。当客户端数量较少时，其吞吐量和延迟等性能指标均比其他 BFT类共识更好。但其缺点也和 Q/U类似，无法处理客户端有竞争的情况。1.3.2.4 Zyzzyva协议Zyzzyva 是 Kotla等人在 2007年提出的一个协议15，需要 3f 1个节点对 f个恶意节点进行拜占庭容错。Zyzzyva 同样需要主节点将客户端发来的请求排序后转发给副本节点，但采用了更加乐观的策略，节点不需要通过需要消耗大量系统代价的 3阶段提交过程即可响应客户端的请求，节点同意由主节点发出的排序请求即给客户端返回结果。由客户端而不是节点来负责考虑一致性问题，客户端会根据节点返回的一致性结果数量分别执行不同的动作。在乐观情况下，该协议具有线性的复杂度，但如果发生错误，主节点的更替仍然需要(3)的时间复杂度。Abraham等人在 2017年指出 Zyzzyva 协议存在安全漏洞16，并在 2018年给出了修正方案17。1.3.2.5 Zeno协议在 Zyzzyva 协议的基础上，Singh在 2009年提出的一个新的共识协议 Zeno18，该协议将 Zyzzyva 原有的强一致性替换为一个较弱的最终一致性保证，它允许客户端偶尔忽略其他更新，但是当网络不稳定时，所有节点的状态需要进行合并以达成一致。1.3.3 基于拜占庭锁的共识协议拜占庭锁是拜占庭协议的扩展，通过利用 IO 绝大多数时间里不会出现竞争的特性达到降低服务器响应时间、提高吞吐量与扩展性的效果。Hendricks等在 2010提出的 Zzyzx 协议最早引入的拜占庭锁的概念19，协议包括加锁和解锁两个部分。加解锁过程均基于现有拜占庭协议达成对客户端授权的一致。当授权完成，获得锁的客户端可直接进行操作，去掉了主节点排序、节点间通讯等操作，从大幅度提高了吞吐量。但当有多个客户端需要频繁切换时，其性能也会大幅下降，因此该协议较为适用于客户端不会频繁发生变化的情况下。2023 云安全联盟大中华区版权所有17针对无拜占庭错误的场景优化的共识协议，当遇到拜占庭错误时，其性能一般较低，甚至很难保证系统活性。为了解决这个问题，Aardvark协议20、Prime协议21、Spinning协议22、RBFT 协议23等针对发生特定的拜占庭行为的场景进行了优化，降低了系统在有无拜占庭错误这两种场景下的表现差异。1.3.4 其它共识协议此外，Pass等人将可验证随机数与中本聪共识相结合，提出了 Sleepy协议24，该协议大大降低了共识协议的复杂性，并将通信复杂度降低到线性，但是该协议的确认时间较长，且无最终确定性。Baird将 BFT 共识协议与 DAG 结合，提出了 Hashgraph协议25，将整个共识过程融入到 gossip通信中，降低了通信复杂度。1.4 开放 BFT 类共识传统的共识算法一般都假设网络是有准入机制的，因此无法应用于开放网络，2008年中本聪在发表的比特币白皮书引入了基于工作量证明（Proof of Work,PoW）的共识算法26，为解决开放网络中的分布式一致性问题提供了新的思路，使得协调复杂网络环境中的成千上万节点成为可能。此后，受比特币启发，诞生了一大批适用于开放网络的共识算法，如权益证明（Proof of Stake,PoS）、空间证明（Proof of Space,PoSpace）、混合共识（Hybrid Consensus）等。1.4.1 PoW类共识工作量证明的思想最早由 Dwork等人在 1993年提出，主要用来解决垃圾邮件的问题27。1999年 Jakobsson等人正式提出了“工作量证明”的概念，Adam Back 在 1997年提出并在 2002年正式发表了基于工作量证明机制的 HashCash，用以解决垃圾邮件问题28，与 Dwork的工作量证明所不同的是，HashCash的工作量证明机制更具随机性。Dwork的工作量证明需要解决一个难题，这意味着一台速度更快的电脑总能比一台速度慢的电脑更快解决问题，而 Hashcash允许速度较慢的计算机在某些时候更快地找到正确答案，仅在统计学上速度快的电脑能够更快的找到答案（这一点对 PoW共识非常重要）。HashCash为比特币的提出奠定了基石。1.4.1.1中本聪共识中本聪通过引入经济激励及工作量证明保证比特币网络分布式记账的一致性，其核心思想是通过分布式节点的算力竞争保证数据的一致性和共识的安全性。比特币系统的各节点基于各自的计算机算力相互竞争共同解决一个求解困难但是验证容易的数学难题（求 2023 云安全联盟大中华区版权所有18Hash的原象），最快解决该难题的节点将获得下一区块的记账权和挖块奖励。共识流程如下：1)客户端生成交易并向全网进行广播；2)比特币矿工节点将收到的交易放到交易池中，交易池中的交易会按照一定的优先级顺序打包进区块；3)矿工节点不断尝试为自己的区块找到一个具有足够难度的工作量证明；4)当矿工节点找到了一个工作量证明，就向全网进行广播该区块；5)其它节点对收到的块进行验证：打包的交易是否合法、工作量证明是否有效、引用的父块是否有效、时间戳是否有效等；6)若区块有效且以该区块结尾的链具有更大累积难道的工作量证明，则接受该区块并在该区块后继续出块。中本聪共识基于同步网络假设，比特币出块间隔维持在 10分钟左右，这就保证了区块能够在下一个区块产生前传播到几乎所有节点。当拜占庭节点的算力不超过 50%时中本聪共识能够保证系统的安全性。相比于传统共识算法，中本聪共识无法达成最终一致性，但由于每个区块都引用了上一个区块，因此每个区块都是对之前所有区块的确认，随着确认区块的增加，区块被修改的可能性也不断降低，从而实现统计意义上的最终一致性。Garay等人在 2015年对比特币共识协议进行了理论分析，提出了 Bitcoin BackboneProtocol44，从理论层面解决了在只有随机出块节点竞选而没有显式的 BFT委员会投票机制情况下，Bitcoin的“最长链法则（the longest-chain-rule）”的有效性。BitcoinBackbone Protocol最早给出了在半同步前提下，线性表结构区块链的三个基本的共识特征：1)Common Prefix：共有前缀，任意一对网络中诚实节点移除本地链（view）上最多k个最新块以后，得到的剩余区块相同，对应 BFT协议里面 Agreement 特性要求；2)Chain Quality：区块链质量，在链上任意 k个连续块里，由攻击者生成的块的比例有上界，对应 BFT协议里 validity特性要求；3)Chain Growth：区块链单向增长率，任意诚实节点在先后两个 time slot 之间观察到链上生成的区块数有下界，对应 BFT 的 liveness特性要求。1.4.1.2 GHOST为了保证安全性，比特币将出块间隔定为 10分钟，从而导致其低吞吐量（10Tps）和长确认时延，通过增加区块大小及减小出块间隔可以解决这个问题，但这将导致：（1）分叉率增高，导致安全性降低；（2）公平性被破坏，网络延迟低的节点更有可能获得奖 2023 云安全联盟大中华区版权所有19励；（3）攻击成本降低，由于诚实节点的算力有一部分浪费在分叉上，恶意节点可以使用低于 51%的算力完成攻击。图4 Gost协议示意为解决这个问题，Sompolinsky 提出了 GHOST协议30，与中本聪共识协议相比，GHOS 协议修改了最长链规则，在每次分叉的时候选取拥有最重子树的分叉节点，如图 4所示。以太坊的共识协议是 GHOST 协议的一个变体，其出块间隔做到了 15秒左右。1.4.1.3 Bitcoin-NGBitcoin-NG 是 Eyal 等人在 2016年提出的一个共识协议，其目的是提高比特币交易的吞吐量31。Bitcoin-NG 将比特币出块分为了两个阶段，分别是 leader选举及交易序列化，分别对应两种区块 Key区块及 Micro区块，如图 5所示。Key区块产生与比特币区块产生一样，平均间隔约 10分钟生成一个，需要工作量证明。一旦 Key区块被挖出，挖出该区块的矿工将负责生成后续的所有 Micro区块，直到下一个 Key区块被挖出。Micro区块的生成不需要工作量证明，但为了防止生成的 Mircro区块过多而阻塞网络造成 Key区块分叉率增高，协议规定了最大的 Micro区块出块速率。图5 Bitcoin-NG区块结构示意 2023 云安全联盟大中华区版权所有20所有的交易都被打包在 Micro区块中，Micro区块需要被下一个区块引用才有效，为了鼓励当前的 Key区块引用上一个 Key 区块产生的 micro区块，将 micro 区块的交易手续费的 60%发放给下一个区块，如图 6 所示。图6 Bitcoin-NG经济激励模型Micro区块的产生不需要工作量证明，因此节点能够快速廉价的产生微块，从而恶意节点可以通过产生微块分叉发起双花攻击。为解决这个问题，Bitcoin-NG 引入了“毒药交易（Poison Transaction）”，允许后面的出块者对恶意节点举报，举报成功恶意节点的酬金将被罚没，举报者获得恶意节点酬金的 5%作为奖励。1.4.1.4 FruitChains由于比特币挖矿难度较大，矿工为平衡收益易联合形成矿池，造成算力集中，并且利用自私挖矿，恶意节点可以通过创造分叉提高自己的挖矿收益，损害了系统的公平性。为了解决这个问题，Pass等人在 2017年提出了 FruitChains协议32。如图 7所示，FruitChains中将区块分成了两种，分别是正常区块及水果（Fruits），生成正常区块及水果都是通过寻找工作量证明完成，但是生成水果的难度要远低于生成正常区块的难度，由于水果与正常区块具有相似的区块结构及相同的工作量证明难题，因此水果与正常区块的挖矿可以同时进行。图7 Fruitchains结构示意 2023 云安全联盟大中华区版权所有21交易被打包在水果中，新挖出的水果只有被打包进正常区块才有效，如果攻击者通过藏匿区块进行自私挖矿或者扣块攻击，由于包含交易的水果总是会被其它诚实节点产生的区块打包，所有攻击会失败。隐私 FruitChains能够有效地防止自私挖矿。FruitsChain中挖矿奖励及交易手续费会平均分发给所有的 Fruits，由于产生 Fruits的难度要远低于产生区块的难度，矿工获得回报的频率将大大提高，从而不需要通过加入矿池来提高回报频率，避免了算力集中化。1.4.1.5 SpectreSpectre是 Sompolinsky等人在 2016年提出的基于有向无环图（DAG）的共识协议33，其本质是利用区块之间的引用关系对交易顺序进行投票。不同于比特币，Spectre没有主链的概念，区块可以同时引用多个之前的区块，所有的区块最终构成一个有向无环图（DAG）。与比特币最长链原则不同，当存在冲突区块时，Spectre选择拥有最多子区块（投票）的区块，如图 8所示。图8 Spectre结构示意因为 Spectre能够同时处理多个区块，其交易处理速度会明显提高，但是由于 Spectre无法提高交易的全局序，仅能提供相对排序，因此其很难支持像智能合约这种对时许要求较高的功能。1.4.1.6 ConfluxConflux是由 Chenxing Li 等人在 2018年提出的基于 DAG 的共识协议34，该协议解决了基于 DAG的共识算法无法提供全局序的问题。Conflux采用延迟排序交易的方式，先乐观地并行执行交易（不论是否有依赖或者冲突）和出块（不论是否会产生分叉），然后经过一段时间再全局地对所有的交易排序，并删除那些有冲突的交易。2023 云安全联盟大中华区版权所有22同 Spectre不同的是，Conflux采用了两种关系定义区块之间的关系：父边（ParentEdge）和引用边（Reference Edge），一个区块只能有一条指向父节点的父边，但可以有多条指向其它节点的引用边。其排序算法如下（如图 9所示）：1)按照 GHOST 规则排序只包含父边的块，形成一个枢轴链（Pivot Chain）；2)根据枢轴链将区块划分成纪元（Epoch），然后对每个纪元里面的区块进行拓扑排序。确定 epoch包含的区块的原则是：区块没有被之前的 epoch包含且能够通过枢轴链的父边或者引用边遍历到；3)根据 happens-before原则对不同 epoch之间的块进行排序图9 Conflux结构示意1.4.1.7 NC-MAXZhang Ren等人对 PoW共识中孤块的产生进行了分析35，将区块广播与新交易广播并行化，有效地缩短了区块广播时延，进而降低了孤块率。具体的，NC-Max 设计了一个交易两步确认机制，在致密区块中既包含新交易的哈希值（propose 交易），又包含老交易的哈希值（confirm 交易）。Propose交易的目的是通知其他矿工同步新交易，confirm交易是将交易打包上链，confirm 交易必须是前几个块中已经通知过的新交易，留给矿工足够的时间对新交易进行同步。该机制实现了交易确认与交易同步的解耦，在同样的出块间隔下，孤块率得到显著的改善。此外，区块链网络的状况并非一成不变，将出块间隔设置为固定时间并不能充分利用网络带宽。NC-Max指出孤块率是区块链要稳定的目标，于是 NC-Max 改变了难度调整的策略，以孤块率作为难度调整的依据。当孤块率大于预设的安全阈值时，难度上升，区块间隔上升，从而使得孤块率回落到安全阈值，反之亦然，从而使得 NC-Max 的吞吐量能够达到安全阈值下网络所能承载的最大吞吐量。1.4.2 PoS类共识PoW共识算法需要消耗大量的能源，为了解决这个问题，一位名为 Quantum Me-chanic 的数字货币爱好者在比特币论坛首次提出了基于权益证明（PoS）的共识算法36。2023 云安全联盟大中华区版权所有23权益是指节点或用户拥有的资产（如代币），并根据用户拥有资产比例决定其成为下一个区块生产者的概率。拥有资产比例越高，其成为生产者的概率就越大。PoS 一定程度上解决了 PoW 算力浪费的问题，并为共识优化带来了新思路：通过代理人制度缩小共识范围，从而缩短达成共识的时间，提供系统的吞吐量。1.4.2.1 PeercoinPeercoin是由 King等人在 2012年提出的，首次引入了权益证明（PoS）概念37。Peercoin将区块分成了两种，分别是 PoW区块与 PoS区块。PoW区块生成同比特币一样，需要工作量证明。PoS区块的生成则需要消耗币龄（币的持有时间），节点拥有的币数量越多，拥有币的时间越长，其被选为出块者的概率越大。具体的，Peercoin将随机散列运算的搜寻空间与币龄挂钩，限制了搜寻次数，避免了因大量计算而造成的能源消耗。但 Peercoin 的币龄机制存在被攻击的可能，该机制无法充分激励节点始终保持在线状态，节点可以先保持离线状态，在积累一定的币龄之后才参与共识网络，然后再次离线。1.4.2.2 Casper FFGCasper FFG 是由 Buterin 和 Griffith 在 2017年提出的基于 PoS的共识协议38，其目的是为以太坊的 PoW共识协议引入即时确定性（Instant Finality）。Casper FFG 许多设计受到 PBFT 的启发，并可以被视为改良后的 PBFT 它继承了 PBFT 的重要设计，同时添加了新的机制并简化了若干规则。在 Casper FFG 中，区块产生仍然依靠以太坊的 Ethash工作量证明算法，每隔一定高度（如 50）的区块被称为检查点（Checkpoints），检查点组成检查点树（CheckpointTree），验证者需要通过投票对检查点形成共识，投票的内容是由两个不同高度的检查点组成的连结（Link），其投票过程与 PBFT 类似。节点可以通过抵押以太币成为验证者，节点被选中成为检查者的概率与抵押以太币的数量成正比，被选中的节点需要经过网络中现有验证者的共识才能最终成为验证者。为了使 Casper FFG具有抵抗共谋的能力，系统会对验证者的违规行为做出惩罚，违规投票的验证者的押金会被罚没。由于验证节点集合会动态地随着时间变化，验证者的某些违规行为无法进行归责，为此 Casper FFG引入了缝合机制（Stitching Mechanism），确保每个错误都能够被归责。Casper FFG 更多的是作为一个过渡协议，使得以太坊能够从 PoW成功过渡到 PoS，目前在研究中的还有 Casper CBC 版本，可以视为以太坊切换到 PoS后的一个更好的版本。2023 云安全联盟大中华区版权所有241.4.2.3 Snow WhiteSnow White是由 Bentov 等人在 2016年提出的基于 PoS的共识协议39，同比特币类似，Snow White出块也是需要找到某个低于目标值（target）的 hash值的原象。不同的是，Snow White中节点只能每隔一段时间尝试一次寻找（通过将时间作为唯一随机源实现），此外 target 的大小与参与者抵押的押金成正比，从而实现参与者出块概率与抵押押金成正比。Snow White 采用与 Fruitchains32相同的区块结构机激励机制，挖矿收益交易放在水果中，水果放在区块中，将连续几个区块的奖励和其中包含的交易费平均分给水果的生产者，实现了公平性。Snow White基于弱同步假设，并采用睡眠模型（sleepy model）的网络模型，即假设节点不会保持永久在线，可能在某段时间内离线，又在某段时间内在线，间断的参与共识，该模型中节点的状态更加符合现实网络中节点的状态，因此适应性更广。1.4.2.4 OuroborosKiayias等人在 2017年提出的共识协议 Ouroboros 40并对其安全性给出了形式化的证明，Ouroboros是第一个可证明是安全和健壮的 POS算法。Ouroboros协议基于同步网络假设，其本质是通过多方运行 coin-tossing协议生成随机数种子，用以随机选取出块节点及下一轮的出块节点候选人集合。Ouroboros将时间划分为一个个的 epoch，每个 epoch又被划分为多个 slot，每个 slot产生一个区块，如果产生的区块非法或者出块者不在线，则该 slot会被跳过。Ouroboros假设每个 epoch内权益的分布是不变的，即权益是根据每个 epoch开始前的历史计算，当前 epoch权益分布的变化只能在以后的 epoch中体现。在每个 epoch的开始阶段会有一个该 epoch的创世区块，记录了该 epoch的出块节点候选人及随机种子，但该创世区块并不上链。随机种子是在上一个 epoch中通过多方的 coin-tossing协议生成的。Epoch中的每个 slot都会从该 epoch出块节点候选人中随机选择一个出块节点，候选人被选中的概率与其权益的占比成正比，即=,，其中 Se为候选人集合，为该 epoch的随机种子，j 代表第 j个 slot。为了确保激励出块节点始终遵循该协议，Ouroboros在每个 slot除会选出一个单一的出块节点外，还会选出多个称为“背书节点”（endorsers）的验证节点。背书节点会对交易的正确性进行检查并为其背书，区块中所包含的交易必须均已由背书人背书的情况下才有效。此外为了激励除出块节点外的其它节点在线，Ouroboros会按贡献度为权益持有者发放奖励。2023 云安全联盟大中华区版权所有25但原始的 Ouroboros协议存在问题：（1）由于伪随机函数是公开的，恶意节点可以在epoch开始时推测出整个 epoch中所有的出块节点，从而进行针对性的贿赂或 DDoS攻击；（2）用于计算随机种子的安全多方计算的计算协议性能会随参与节点的增多而降低；（3）其安全性论证基于同步网络模型假设。为了解决这些问题，David等人在 2018年提出了Ouroboros Praos协议41。Ouroboros Praos协议的主要改进是采用可验证随机函数（VRF）代替公开伪随机函数进行出块节点的选举。节点通过可验证随机函数 VRF 产生可验证随机数，如果其数值低于某个目标值，则可确定被选中为出块节点，出块节点在生成区块时会附带产生的随机数和证明，网络中其他节点可以据此确认其合法性。因为每个节点随机函数是独立的，所以Praos并不能像原始 Ouroboros那样保证每个 slot 都刚好有且只有一个出块节点，可能没有人选中，也可能选中多个。不过 praos已经证明，在半同步网络模型上其依然可以保证原来的安全属性。同时 praos的 slot 时长也比原始协议要低。Badertscher等人对 Ouroboros Praos协议进行了改进，并参考了 Snow White协议针对节点离线的情况的设计，提出了 Ouroboros Genesis协议42，解决了困扰 PoS的长链攻击问题（Long-range Attack），并基于 UC Framework证明了其安全性。Ouroboros Genesis 保留了 Praos协议里 VRF的部分，考虑到 Praos的 VRF会像 PoW一样可能在同一个 slot 里选出多于一个的合法出块节点而导致分叉，Ouroboros Genesis 修改了基本的最长链原则（Longest-chain-rule），新节点在加入网络时，需要从不同节点获得多个链，并进行对比，最终选定的区块链需要与其他链具有共同前缀且是最长链。这个新的设计保证新加入节点或者掉线节点能够在不引入需要附加信任机制的链上检查点（Checkpoint）的情况下正确自启（Bootstrap）。Kerber等人在 2019年提出了 Ouroboros Crypsinous43，首次对支持隐私保护的 PoS区块链协议进行了形式化分析，并引入 SNARKs 及 key-private forward secure encryption，使其能够更好的抵抗适应性攻击（Adaptive Attacks）。Ouroboros Crypsinous与 OuroborosGenesis协议基本一致，区别主要在于出块节点的选取及交易处理。1.4.3 PoSpace类共识空间证明（PoSpace）是为了解决 PoW算法能源浪费提出的，节点需证明其在一定的磁盘空间中存储了特定的数据，节点被选中成为出块节点的概率与其所能证明的磁盘空间大小成正比。Burst是首个基于空间证明的区块链项目。空间证明最大的问题是，因为挖 2023 云安全联盟大中华区版权所有26矿不需要付出代价，某个拥有大量磁盘资源的节点可以不费代价的覆盖整条链，从这条链最初的创世区块开始，把整个链重新挖一遍，独吞所有的区块奖励。1.4.3.1 PermacoinPermacoin 是 Miller 等人在 2014年提出的共识协议45，Permacion 本质上仍是一个 PoW共识协议，不过为了使挖矿变得有“价值”，Permacoin 会强制矿工存储一部分数据，并在出块时向其它节点证明一直存储着该数据，否则将无法出块。1.4.3.2 SpacemintSpacemint是由 Park等人在 2015年提出的基于空间证明的共识协议46，Spacemint详细分析了 PoSpace协议所存在的两个问题 Grinding和 mining multiple chains，并给出了解决方案。同 Permacoin不同的是，Spacemint 存储的是无用数据，但是避免了因不断“搜寻”而引起的能源浪费。Spacemint的空间证明本质上是求解单向函数的逆，逆的求解很难在短时间内通过纯计算完成，但通过将函数的象及原象预先存储在磁盘上，通过查找磁盘就可以在极短的时间内找到答案，而找到答案的数量（或质量）与所用的磁盘空间成正比，从而实现了容量证明。首先，Spacemint划分了一段段固定的时间，每一段固定时间内只能出一个块，其出块过程为：每一段固定时间都有对应的挑战（challenge），矿工根据挑战在磁盘上搜寻对应的答案，找到答案的矿工会广播自己的答案并与其它矿工的答案进行对比，拥有最高质量的答案的矿工获得出块权。由于 Spacemint 挖矿不需要代价，拥有大量磁盘空间的恶意节点可以私下构造一条具有更高质量（Chain Quality）的链而覆盖掉原有的链（Challenge-grinding Attack），为了解决这个问题，Spacemint 在计算 chain quality时加入了衰减因子，使新的块占有更大的比重，从而增加了攻击难度。此外对应同时在分叉上出块，Spacemint 引入了惩罚机制，促使矿工在单一分叉上出块以加快收敛速度。1.4.3.3 Chia尽管 Spacemint 在计算 chain quality时加入了衰减因子企图解决 challenge-grindingattacks，但仍然有被攻击的可能，为了解决这个问题，Bram Cohen利用可验证延迟函数，将空间证明与时间证明结合，在其设计的 Chia协议中，创造性地提出了时空证明机制（Proof of Space And Time）47。2023 云安全联盟大中华区版权所有27可验证延迟函数（VDF）使一类数学函数，在允许同时使用少量 CPU 进行并行计算的情况下，能够使得该函数的计算需要至少一段已知的时间，验证者能够对函数的输出结果进行验证，一般验证时间要远低于计算时间。同 Spacemint 一样，矿工仍需要对challenge在其磁盘空间中搜寻答案，拥有最高质量答案的节点获得出块权，不同的是出块节点会将块广播给 VDF服务器，VDF服务器需要提供一段时间流逝的证明，以证明两相邻块之间间隔了足够的时间，系统中会有多个 VDF服务器，最先完成 VDF计算的服务器进行最终出块。通过引入时间证明机制，Chia解决了 challenge-grinding attack，因为攻击者如果想覆盖整条链的话，其不但要付出存储空间资源，还需要 CPU 的时间资源，而后者将使攻击很难进行。1.4.3.4 FilecoinFilecoin是 Benet等人在 2018年提出基于容量证明的区块链协议48，其共识机制与Chia、Spacemint 等共识机制最大的不同是，其磁盘中存储的是有用数据，避免了磁盘资源的浪费。Filecoin的共识机制是预期共识（Expected Consensus，EC），Filecoin的矿工在每一轮里会独立的检查是否满足：如果满足则获得出块权，其中 H为 hash函数，L为函数值位数，为第 t 轮的全网统一随机数，为第 t 轮矿工 i 的存储空间，为啥出块节点的选取不可预测，定义为：矿工获得出块权力的概率与矿工已拥有的有效存储空间占全网存储空间的比重成正比。因为计算相互独立，因此 Filecoin会出现在 t轮没有节点或有多个节点获得出块权的情况。此外，Filecoin设有抵押机制，会强制矿工选择一条链，对同时挖多个链的矿工进行惩罚，有效促进矿工收敛。为计算矿工算力及存储的有效性，保证 EC共识机制的运行，Filecoin协议中采用了复制证明（Proof-of-Replication）和时空证明（Proof-of-Space-time）两种算法，其中复制证明用来验证矿工已经存储了某文件，时空证明用证明矿工一直存储了该文件。2023 云安全联盟大中华区版权所有28复制证明的目的是防范三种常见的攻击：女巫攻击，外源攻击和生成攻击，以保证矿工实际存储的数据大小与其声明存储的数据大小一致。时空证明可以理解为持续的复制证明，即矿工必须不断的生成证明，并在一个提交周期内提交存储证明。如果存储服务商没有在提交周期内连续及时提交证明，会被系统扣除部分代币。生成时空证明的过程跟复制证明非常相似，只是时空证明的输入是上一次生成的证明的输出，从而形成证明链，利用时间戳锚定这些证明链，这样即使验证者（Verifier）不在线，也能够在将来去验证矿工在该段时间内生成了证明链，PoSt会被提交到链上用来产生新的数据区块。1.4.4 proof of elapsed time消逝时间证明是基于硬件芯片执行某个命令的等待时间实现的，其实质是利用可信硬件（TEE）产生随机数决定下一个区块生产者。在 Hyperledger Sawtooth项目中，参与者使用英特尔可信芯片 Intel SGX 中的“飞地”模块，根据预定义的概率分布生成一个随机的等待时间，等待时间最短的节点被选为领导节点，SGX 可帮助节点创建区块、生成该等待时间的证明，而这种证明易于被其他 SGX 节点验证。Zhang 等人在 2017年提出了资源高效利用挖矿（Resource-Efficient Mining，REM）的共识协议 PoUW49。在 PoUW协议中，CPU 在承担原来的工作之外，还可以同时承担区块链的工作，该协议核心仍是采用可信硬件来计算 PoW，用时最短的节点将获得出块权。1.4.5 混合共识机制：单一委员会混合共识机制本质上是将共识范围缩小以提高共识效率。经典的分布式共识机制共识效率高、确认延时低，但由于存在女巫攻击，无法适用于开放的网络环境。混合共识机制将经典分布式共识机制与区块链共识机制相结合，即采用 PoW 或 PoS 的方式进行委员会选举解决女巫攻击，在委员会内部运行经典分布式共识机制，提高共识效率。混合共识机制可分为单一委员会制度或者多委员会制度，采用单一委员会的混合共识机制选举一个委员会负责全网所有交易的处理，而采用多委员会的混合共识机制选举多个并行运作的委员会，将全网划分为多个片区，分片处理网络中的交易（扁平），或者对系统进行分层，由不同的层处理不同的逻辑（垂直）。混合共识机制的一般过程如下：1)委员会成员选举。混合共识机制首先需要选举一个小型的委员会，为防止女巫攻击，委员会成员通过 PoW 或 PoS 的方式选举，节点被选中的概率与节点所拥有的算力或持有的权益成正比。2)委员会成员间共识。委员会成员间运行改进的 PBFT协议或类似算法，实现委员会内部的拜占庭容错，进而产生区块。2023 云安全联盟大中华区版权所有293)广播区块。委员会成员将生成的区块广播至全网，使得网络中非委员会的节点和客户端收到新产生的区块，更新交易和区块链。4)委员会重配置。为防止敌手腐化/DDos委员会成员，在工作一定时期后，委员会成员应当更新，可以一次更新一个或多个成员，也可以全部更新。如果更新过慢，则会给敌手 DoS 攻击提供稳定有效的目标，但如果更新过快，更新委员会的成本更高且需要激励新一轮被选中者持续在线。单一委员会的混合共识机制面临的安全问题主要是恶意节点干扰委员会选举和重配置过程。1.4.5.1 PeerCensus比特币共识机制较弱，只能提供最终一致性，导致其交易确认速度过慢。为了解决这个问题，Decker等人在 2016年提出了共识协议 PeerCensus 50，首次将经典分布式一致性算法 PBFT 与 PoW算法相结合，其主要想法是解耦区块创造过程和交易确认过程，以便共识速度可以显著提升。如图 10所示，PeerCensus底层仍然是一般的区块链（如比特币），矿工挖到区块后将区块提交到上层的 Chain Agreement（CA），Chain Agreement 运行 PBFT协议对区块确认，确认后的区块再返回给底层区块链。节点加入委员会需要提交工作量证明并经过委员会其它成员共识后才能加入。但 PeerCensus 委员会管理存在一定问题，它采用离开检测机制来判断节点是否离开。正常节点通过发送 ping 消息判断其它节点是否离线，如果离线则发起对该离线节点的“离开”提议，提议通过委员会共识后，委员会才完成重配置。这样的问题是，如果恶意用户不断制造“离开”提议，整个系统的运行效率将大大降低。图10 PeerCensus结构示意 2023 云安全联盟大中华区版权所有301.4.5.2 ByzCoinByzCoin是 Kogias等人在 2016年提出的51，是首个能够支持比特币中工作量证明的基于动态成员关系的拜占庭共识协议。Byzcoin将 PoW与 PBFT协议相结合实现了交易的即时确认并能够提供前向安全性。同时 Byzcoin通过引入联合签名方案减小 PBFT轮次的开销，使其能够支持更多的共识节点。ByzCoin借鉴了 Bitcoin-NG 的思想，将区块分为关键块（Keyblock）和微块（Microblock），关键块决定委员会成员和领导者。首先 ByzCoin定义了一个窗口大小（144个关键块或者 1008个关键块），窗口会随着关键块的产生不断往前移动，处于窗口内的关键块的生产者组成委员会，成员的投票权由其产生的关键块的比例决定。同Bitcoin-NG 一样，一旦一个节点生成了关键块，它将成为首领，被允许以固定速率生成微区块，微区块包含交易等信息。Byzcoin架构如图 11所示。图11 Byzcoin架构示意委员会成员采用改进的 PBFT算法对微块进行共识，为了提高效率，ByzCoin 利用联合签名（Scalable Collective Signing）将 PBFT的通信复杂度降到了 O(n)，使其能适用于规模较大的共识节点。此外为了激励委员会成员保持活跃，ByzCoin会将部分挖矿奖励分发给参与共识的委员会成员。1.4.5.3 SolidaSolida是由 Abraham等人在 2016年提出的基于 PoW和 BFT 共识的混合共识机制52。相比于 PeerCensus及 ByzCoin，Solida给出了更加详细的协议设计，尤其是委员会成员的重配置机制，解决了重配置时可能出现的问题。此外，Solida严格证明了当恶意节点算力不超过 1/3时，协议能够保证安全性及活性。2023 云安全联盟大中华区版权所有31矿工可以通过求解 PoW谜题加入委员会，一旦找到一个对应的 PoW，矿工可以向委员会成员广播该 PoW，委员会成员通过运行重配置协议，将该矿工加入到委员会中。Solida 的领导者选举方式借鉴了 Paxos 的思想，委员会每个成员都会被赋予一个等级元组(c,e,v)，并依次按 c、e、v进行排序，其中：c 代表委员会序号，每当新节点通过委员会重配置加入到委员会中后，委员会中节点的等级元组会由(c,e,v)变为(c 1,0,0)，新加入的节点成为委员会领导者；e 代表一个 PoW 对应的生存时期，如果有节点新找到 PoW，则其等级元组(c,e,v)变为(c,e 1,0)，新找到 PoW 的节点成为领导者。v 的含义是视图，当现任领导者停滞不前，利用函数 L(c,e,v)=H(c,e) v mod n在委员会内部选出新的领导者，领导者元组由(c,e,v)变为(c,e,v 1)。领导节点负责打包交易并创建区块，委员会成员通过运行改进的 PBFT协议对区块进行共识，除此之外，委员会成员还需对重配置事件进行共识，以顺利更新委员会成员及领导节点。1.4.5.4 Hybrid Consensus混合共识 Hybrid Consensus是由 Pass等人在 2017年提出的共识机制53，将经典共识与区块链共识结合，提高非授权网络下的交易确认速度。Hybrid Consensu证明了在异步或者半异步假设下（网络传播延迟上限不可知），非授权网络下的共识无法保证一致性及活性。Hybrid Consensus通过对系统进行更强的假设，通过混合共识机制实现了交易的快速响应，即交易的确认时间与网络真实时延有关，而与网络时延上限无关，协议的一致性及活性也被严格证明。在 Hybird Consensus中，底层链成为 snailchain，是一条 PoW链，委员会的成员由最近出块的矿工组成，委员会成员之间运行 DailyBFT 协议对交易进行确认。Hybrid Consensus解决了 ByzCoin中存在的因自私挖矿导致诚实节点维护的关键块链质量下降的问题，即在自私挖矿存在的情况下，要想诚实节点产生的关键块的比例超过2/3，以使委员会中有足够多的诚实节点，那么敌手所占的算力不能超过 1/4。1.4.5.5 ThunderellaThunderella是 Pass等人在 2018年提出的混合共识机制54，与其它混合机制不同的是，委员会成员之间并不运行完整的 BFT类共识协议，如果要发生视图切换（ViewChange）及状态恢复，则通过底层的 PoW协议实现。Thunderella提出了乐观响应的概念，2023 云安全联盟大中华区版权所有32即在乐观情况下，由上层的委员会快速处理交易，而一旦遭到攻击，则退回到底层 PoW协议进行安全处理。Thunderella的委员会选举可以通过 PoW进行也可以通过 PoS进行。如果通过 PoW进行，则最新找到 PoW的 n个节点成为委员会成员，并按顺序依此替换老节点。如果通过PoS的方式进行选举，节点需要现在底层链上抵押一部分保证金，系统随机从抵押保证金的节点中选择 n个节点作为委员会成员，选举方法与 snow white类似。如果领导节点诚实且委员会中诚实节点数量超过 3/4，则系统处于乐观期，此时客户端将交易提交给领导节点，领导节点对交易进行排序并广播给其他委员会成员，委员会成员对交易进行签名，如果超过 3/4个委员对交易进行了签名，则交易被最终确认。此外领导节点会定期的发送快速通道的哈希值给委员会成员确认，如果确认成功则该哈希值会作为心跳标记（Heartbeat）写入底层链，心跳机制保证了在回退时只会影响最后一个心跳标记后的交易。如果不满足乐观条件则系统进入宽限期（如 Yell Transaction 长时间未被确认，心跳标记长时间未出现），此时委员会成员停止对来自领导节点的消息进行签名，但允许节点发布经过公证但没有包含在最近心跳标记中的交易到慢速链上，宽限期包含 k个区块，宽限期结束后，节点输出所有已确认和未确认交易，进入底层区块链确认期。底层区块链确认期采用底层链共识机制，所有的交易处理和传统区块链没有区别。系统会等待足够的区块链数量后，重新进入乐观期，重启快速通道。Thunderella协议总体的安全性继承于底层链的安全性，底层链基于同步假设，实现了1/2的容错性，为部分同步假设下的上层 BFT共识提供了 1/2的容错能力。1.4.5.6 AlgorandAlgorand是 Gilad等人在 2017年提出的基于同步假设的混合共识机制，Algorand将PoS共识与经典分布式一致性算法相结合，并利用可验证随机数（VRF）进行委员会秘密选举，避免了被定向攻击的可能。同经典的 PoS共识一样，节点需要先抵押一定数量的代币才能参与到共识中。在每一轮共识开始时，每个符合条件的节点都可以通过 VRF独立验证自己是否是潜在的领导节点或委员会成员，即如果,1,1 1/则成为本轮的领导节点，如果满足,1,1/则成为本轮委员会成员，其中 H为哈希函数，_ 为签名函数，1是第 r-1轮的种子，为第 r-k轮符合条件的公钥 2023 云安全联盟大中华区版权所有33数，k为回溯系数。如果有多个候选 leader，最终上述哈希值最小的 leader 将在后续的共识中成为本轮最终的 leader。委员会成员通过运行改进的分布式一致算法 BA*对区块进行共识。BA*包括分级共识协议（Graded Consensus，GC）和二元拜占庭一致协议（Binary Byzantine Agreement，BBA），Algorand 利用 GC将对整个区块哈希值的共识转化为对二元数值的共识，并通过BBA 对二元数值达成一致从而确认本轮区块。BBA 可以在诚实节点超过 2/3的情况下快速达成共识，其具体过程是一个 3 步循环，循环中每一步都有 1/3的概率达成共识。尽管概率非常低，Algorand仍然有可能发生分叉。如果发生分叉，Algorand采用中本聪共识中的最长链法则进行恢复。1.4.6 混合共识机制：多委员会多委员会的混合共识机制是通过设立多个委员会，每个委员会负责不同的任务，以提高交易的处理能力，按委员会的拓扑结构不同，可分为分层结构（如 RSCoin，ELASTICO）和扁平结构（如 Chainspace，Omniledger）。相比于单委员会机制，多委员会机制在选举委员会成员后,需要将新选举的委员会成员分配到不同委员会中，按照委员会成员分配方式的不同可分为通过链上随机数分配（如 Omniledger）、通过投票分配（如 Chainspace）及通过 PoW分配（如 ELASTICO）。1.4.6.1 ELASTICOELASTICO 是 Luu等人在 2016年提出的混合共识机制。ELASTICO 的核心思想是把网络中的节点分成多个小的委员会，每个委员会处理互不相交的交易集合。这些不相交的交易集被成为分片（Shard）。委员会选举是通过 PoW进行的，完成 PoW的节点随机分到某个委员会中，由于每个委员会中的节点数量足够小，所以委员会内部可以运行经典的拜占庭共识协议。由于委员会之间交易处理是并行的，所以 ELASTICO 几乎完成了对吞吐量的线性扩展。为了降低委员会成员建立连接时的通信复杂度，ELASTICO 设有一个特殊的委员会，称作目录委员会。目录委员会为其它委员提供委员会分配委员会成员身份和委员会成员身份列表服务。同其它普通委员会一样，目录委员会也有 c个成员，前 c 个找到工作量证明的节点进入目录委员会。目录委员会满员之后，后续找到工作量证明的节点会将工作量证明及身份信息发送给所有目录委员会成员，目录委员会根据提交的哈希值将其分配进相应的委员会。当所有委员会成员到达 c 之后，目录委员成员会会把每一个普通委员会的成员列表广播给相应的委员会成员。2023 云安全联盟大中华区版权所有34目录委员会中拜占庭节点比例最多为 1/3，因此每个普通委员会成员将会收到最少2c/3个正确的成员列表，把收到的所有身份做了一个并集，就创建了一个至少拥有 c 个委员会成员的视图。每个委员会内部运行 PBFT 算法，就本轮自身委员会内部交易集合达成共识，并将交易集合和对其确认签名发送至最终委员会，最终委员会是从所有普通委员会中随机选出的一个委员会。最终委员会会收集所有普通委员会确认的交易集合，并组成本轮的总区块，其中交易是所有之前收到的有效交易集的并集，然后内部运行 PBFT协议，达成共识后将总区块广播到网络中。此外，最终委员会运行随机数生成协议，生成用于下一轮寻找 PoW的随机数集合，该过程仍需要运行 PBFT协议，以达成对随机数集合的共识。虽然 ELASTICO 极大的提高了区块链系统的吞吐量，但与其它的混合共识机制相比，其交易延迟过大。1.4.6.2 OmniledgerOmniledger是 Kokoris-Kogias等人在 2018年提出的混合共识机制57，其设计与ELASTICO 大致相同，但是解决了 ELASTICO 存在的几个问题：（1）分片较小，在抵御25%攻击时有较高的失败率；（2）选举不是强抗偏见的，矿工可以选择性的忽略 PoW来得到特定的结果；（3）交易确认延迟较高；（4）不能保证跨分片交易的原子性，易锁死。如图 12所示，Omniledger 有一条身份链和多条交易链组成。身份链用于记录协议每个时期参与的节点和其对应的分片信息，每个时期更新一次。交易链用于记录交易信息。Omniledger使用 RandHound协议，将所有的验证节点分成不同组，并随机的将这些组分配到不同的交易链，验证以及共识区块。图12 Omniledger结构示意Omniledger委员会选举方式与 ByzCoin 类似，即选取大小为 n的滑动窗口，区块处于滑动窗口内的出块者选为委员会成员。委员会通过可验证随机数（VRF）选出领导者，领 2023 云安全联盟大中华区版权所有35导者启动随机数生成算法 RandHound生成随机数 r并广播，其它委员根据随机数 r确定自己所在的分片，组成小委员会。小委员会之间运行 ByzCoinx协议对交易进行确认，ByzCoinx协议相比于 Byzcoin协议具有更好的健壮性但是牺牲了部分性能。Hydrand58 改进了 Omniledger 使用的随机数生成算法改进，采用公开可验证秘密，确保了随机数的不可预测性、抗偏置性和公开可验证性，并且确保了随机数的持续生成。1.4.6.3 ChainspaceChainspace是由 Al-Bassam等在 2017年提出的混合共识机制59，Chainspace 将智能合约的执行和验证步骤分离开来，并且提出了跨片交易处理的原子承诺协议（ShardedByzantine Atomic Commit，S-BAC），S-BAC 的实质是 BFT 和原子承诺（Atomic Commit）的结合。每个分片委员会内部运行 BFT协议，对客户端提交事务进行决策，以暂时决定是在本地接受还是中止事务，并将其本地决策预接受（pre-accept）或预中止（pre-abort）广播给其他相关分片。每个分片收集来自其他相关分片的响应，如果所有分片都使用预接受响应则提交事务，否则中止事务。这些分片通过向用户发送接受（accept）或中止消息（abort），将此决定传递给用户以及输出分片，如图 13所示。图13 Chainspace示意1.4.6.4 RapidChainRapidChain是 Zamani 等人在 2018年提出的混合共识协议60。RapidChain基于同步网络假设，最多能容纳 1/3拜占庭节点。Rapidchain主要包含三个阶段，分别是启动阶段（Bootstrapping Phase）、共识阶段（Consensus Phase）和重配置阶段（ReconfigurationPhase）。启动阶段只在 RapidChain开始时运行一次，这个阶段是为了创建一个初始随机源，并随机选出一个特殊的委员会，叫做参考委员会（Reference Committee），再由这个参考委 2023 云安全联盟大中华区版权所有36员会对节点进行随机分配，构成一个个分片委员会。该阶段使 RapidChain不需要任何可信第三方和可信启动的存在，便能够完成协议的初始化。RapidChain将时间划分成了一个个 epoch，每个 epoch由共识阶段和重配置阶段组成，共识阶段又分为了多个 round，即委员会在一个 epoch内可以进行多轮共识。在共识阶段开始时，委员会会利用当前 epoch的随机种子随机选择出领导节点，然后委员会成员运行实用同步拜占庭容错协议，对交易进行共识。重配置阶段会对委员会成员进行更新，网络中的其它节点可以通过寻找 PoW加入委员会，PoW须依赖于上一个 epoch的随机源，参考委员会验证收到的 PoW，如果验证通过则通过有界布谷鸟规则（Bounded Cuckoo Rule）将节点随机分配到各个委员会中。有界布谷鸟规则可以使新节点尽量替换掉原本委员会中不活跃的节点。此外，在重配置阶段，参考委员会的成员还会运行 DRG 协议（Distribute RandomGeneration Protocol）生成一个无偏差随机数并达成共识。RapidChain共识阶段采用同步网络模型，交易确认时延与网络真实时延无关，只与网络延迟上限有关，导致交易确认不能满足快速响应特性，但 RapidChain 协议其他部分采用部分同步网络模型，能够满足快速响应特性。1.4.7 其它除此之外，基于 Proof-of-X的共识机制还有 Proof-of-Burn(PoB)、Proof-of-Personhood、Proof-of-authority等共识机制，但应用都不广泛。恒星共识协议（Stellar ConsensusProtocol，SCP）提出了一种联邦拜占庭协商协议（Federated Byzantine Agreement，FBA），FBA 的健壮性来源于群体切片，即由单个节点的个体信任决策共同决定系统级别的仲裁63。2 共识算法安全性分析2.1安全建模2.1.1 安全属性一个安全的共识算法应满足：（1）一致性（一致性（Agreement/Consistency/Integrity），所有的诚实节点要么都接受某个值，要么都拒绝某个值；（2）终止性（终止性（Termination），所有的诚实节点最终都会对某个值达成共识；2023 云安全联盟大中华区版权所有37（3）合法性（合法性（Validity），所有诚实节点达成共识的值都是由诚实节点提议的。在区块链共识算法中，更多提及的是安全性（Safety）及活性（Liveness），这两者本质上是等价的，正确性和一致性决定了安全性，而终止性就是活性。另一个评价共识算法比较重要的特性是弹性（Resiliency），即最坏情况下最多能对多少恶意节点容错、最多需要几轮共识才能终止、最大通讯复杂度是多少等。对于一致性，又可分为强一致性（Strong Consistency）与弱一致性（WeakConsistency/Eventual Consistency），强一致性是指共识结果是确定的，具有强一致性的共识被称为确定性共识，大部分经典的共识算法都是强一致性的。弱一致性是指共识结果是不确定的，只是随着时间的推移其结果被推翻的概率会越来越小，大部分区块链共识算法都是弱一致性的。相比于弱一致性共识算法，强一致性共识算法能够保证前向安全性并实现更低的确认时延。此外，对于区块链共识算法，还有一些重要的性质64：（1）公共前缀（Common Prefix），即对任意两个诚实节点所提交的区块链，一定能找到某个正整数 k使得它们 0 到 k个区块是相同的；（2）链质量（Chain Quality），任意诚实节点的链除去最新的 k0后，任意 k 个连续的区块中，恶意区块的比例不超过安全参数 u；（3）链增长（Chain Growth），对于任意轮 r r0，假设诚实节点 P 在第 r 轮的输出的区块链为 C1，在第 r s 轮输出的区块链为链 C2，则满足 2 1 ，其中 t、r0、s 为安全参数；（4）公平性（Fairness），诚实节点产生的区块所占主链比例与其算力（或者权益）占比一致；（5）前向安全性（Forward Security），达成一致的共识结果不能在之后被推翻；（6）快速响应特性(Responsiveness)，是指交易确认时间与网络真实时延有关，与网络时延上限无关。（7）自一致性（Future-Self Consistency），在任意两个时刻 r、s，任意诚实节点在r、s时刻，除最后 t 个区块外剩余区块不相同的概率可以忽略不计。2.1.2 网络模型在共识网络中有主要有两种网络结构，分别是点对点通道（Point-to-Point Channels）及点到点扩散（Peer-to-Peer Diffusion）。在点对点通道传输模型中，节点分别与其它各节 2023 云安全联盟大中华区版权所有38点建立可靠的通道，直接进行消息传输，在传输过程中，消息的发送方与接收方均能识别对方的身份信息，该传输模型也叫做可靠信息传输（Reliable Message Transmission）。在点到点扩散传输模型中，节点只与网络中的部分节点建立连接，消息通过广播的方法发送给与其连接的节点，收到消息的节点再以同样方式进行广播，最终将消息传递至整个网络，消息接收者无法确认消息发送者的身份，消息发送者也无法确定接收者接收消息的顺序。对于共识协议分析及设计另一个重要的网络特征是同步性，目前对于网络主要有三种同步假设，分别是：（1）同步网络（同步网络（Synchronous Network），所有消息都必然在某个可以预先确定的时间内传达，并且网络中的所有参与者都知道消息需要传递多久。在同步网络中，协议可以以轮的形式进行，在每一轮中，诚实用户发出的消息能够在下一轮之前到达其他所有诚实用户。（2）半同步网络（半同步网络（Semi-Synchrony Network），参与者无法确切地知道网络延迟，但消息传递时间可以由随机变量建模，该随机变量的概率分布对于协议中的参与者来说是已知的。（3）部分同步网络（部分同步网络（Partially Synchronous Network），网络延迟存在上限，但网络中的参与者不知道该上限的确切值，时延上限不能作为协议的参数使用，部分同步网络是区块链协议分析中常用的网络模型。（4）异步网络（异步网络（Asynchronous Network），仅保证诚实用户的消息能够到达彼此，但消息传递的顺序可能被打乱，消息的时延可能无限长。2.1.3 启动模式（Setup Assumptions）根据协议开始时所依赖的信息不同，可以有三种不同的启动模式，分别是无状态启动（No Setup）、公共状态启动（Public-State Setup）、私有状态启动（Private-State Setup）65。无状态启动是指共识启动前不设置任何启动函数，没有初始状态，因此恶意节点可以在协议开始前进行预计算。公共状态启动是指协议依赖于一个特定的随机状态，该随机状态可以在协议开始时被随机取样，恶意节点可以通过某些手段干预随机状态的生成。私有状态启动是指协议启动依赖于一组状态 1,，n为参与成员个数，si由成员 i秘密随机生成的。2023 云安全联盟大中华区版权所有392.1.4 安全性假设同其他密码学协议一样，共识协议主要有两种安全性假设，分别是信息论安全性（Information-Theoretic Security）与计算安全性（Computational Security），前者假设敌手有无限的计算资源，后者假设敌手仅能对多项式复杂度的问题进行计算。对于信息论安全性又可分为完美安全性（Perfect Security）和统计安全性（StatisticalSecurity），前者指协议的安全性质在任何情况下都不会被破坏，后者指协议的安全性性质可能会被破坏，但被破坏的概率可以忽略不计。2.1.5 腐化模型腐化（Corruption）是指敌手通过向目标节点发动攻击，获取目标节点的秘密信息，进而控制目标节点的输入输出消息，使其完全受到自身的控制。共有三种腐化模型，分别是静态敌手（Static Corruption）、T-温和敌手（T-Mildly Corruption）及适应性敌手（Adaptive Corruption）64。静态敌手是指敌手只能在协议开始前选定其腐化的目标，协议运行期间，敌手不能够再去腐化其它诚实节点，其控制的节点数量也不会发生改变。T-温和敌手是指敌手需要一定的时间 t完成对一个节点的腐化，在敌手实施腐化的 t 时间内节点仍然属于诚实节点。t-温和敌手是区块链协议分析中经常采用的腐化模型。适应性敌手是指敌手能够根据协议运行过程中搜集的信息，动态且适应性地对目标节点实施腐化，适应性敌手是三种腐化模型中最强大的。2.2 分析方法2.2.1 经典分布式理论Fischer、Lynch和 Patterson在 1985年证明了：在网络可靠，但允许节点失效（即便只有一个）的最小化异步模型系统中，不存在一个可以解决一致性问题的确定性共识算法，被成为 FLP定理1。FLP定理从理论层面指出为异步网络设计在任何场景下都是安全的共识算法是不可能的。2000年 7月，加州大学伯克利分校的 Eric Brewer教授在 ACM PODC 会议上提出CAP 猜想。2年后，麻省理工学院的 Seth Gilbert和 Nancy Lynch从理论上证明了 CAP 猜想。之后，CAP 理论正式成为分布式计算领域的公认定理。简单来说，CAP 定理是指一个分布式系统，最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）这三项中的两项。2023 云安全联盟大中华区版权所有40一致性是指分布式系统中的所有节点在同一时刻具有相同的数据。可用性是指系统中部分节点发生故障后系统仍然能响应客户端的请求。系统如果不能在时限内达成数据一致性，就意味着发生了分区，分区容错性是指系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务。一般来说，网络分区是一个自然的事实，分区容错无法避免，因此可以认为 CAP 的 P 总是成立，即由 CAP 定理可知，共识协议一般无法同时做到可用性与一致性。实际上网络分区的情况极少出现，系统大多数时间能够同时满足一致性及可用性，Pritchett基于这个观察提出了 BASE理论66，其核心思想是当满足可用性时，即使无法做到强一致性，但每个节点可以采用适当的方式来使系统达到最终一致性（EventuallyConsistency）。最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。2.2.2 协议分析方法目前对于计算安全性的协议主要有两种证明方法，分别是 Simulation-Based Approach与 Game-Based Approach。Simulation-Based Approach的主要思路是用用理想模型模拟现实模型，证明敌手无法区分模拟模型与现实模型，从而证明现实模型是安全的。Game-BasedApproach的思路是通过证明没有敌手能够实现其目标从而证明协议是安全的，其主要过程为：描述协议、描述敌手目标、描述敌手能力、构造安全模型（利用困难问题构造）、归约证实（归约到困难问题不可解上）。Simulation-Based Approach的主要构造形式有 Trusted-party Paradigm、UniversalComposability及 black-box Simulatability。Trusted-party Paradigm 是由 Goldreich等人在1986年提出的67，该方法假设存在一个可信第三方去执行协议并且可信第三方能够看到协议的所有输入。如果现实敌手执行该协议，其输出与可信第三方输出完全一致，则可认为该协议是安全的。Universal Composability（UC）即通用可复合安全，是由 Canetti在 2001年提出的68，是解决协议组合问题的重要工具。作为一种可证安全的方法，UC框架中定义了一整套安全性模型来证明复杂环境下组合协议的安全性。UC安全采用模块化的思想，在 UC 框架中被证明是 UC 安全的协议，在复杂的网络环境中作为一个模块与其他协议进行组合时不破坏组合后协议的安全性，即几个分别在 UC框架中被证明是 UC 安全的协议，组合以后仍然是安全的69。2023 云安全联盟大中华区版权所有41目前在共识协议证明中使用比较多的是 Trusted-party Paradigm 及 universalComposability。2.2.3 区块链建模Garay等人在 2015提出了 Bitcoin Backbone Protocol44，最早提出了半同步假设下的线性表结构区块链的三个基本共识特征：公共前缀（Common Prefix）、链质量（ChainQuality）和链增长（Chain Growth）。Bitcoin Backbone Protocol从理论上解决了在只有随机出块节点竞选而没有显式的 BFT委员会投票机制情况下，比特币“最长链法则（TheLongest-Chain-Rule）”的有效性。同时作者证明了任何满足这些属性的区块链协议都可以被用来构造公共账本，公共账本满足：（1）持续性（Persistence），如果消息被添加到公共账本，它永远不会被删除；（2）活性（Liveness），如果所有诚实参与者想要向账本添加一些消息，那么最终消息应该出现在账本上面。目前已知的链式区块链共识协议分析大多基于 Bitcoin Backbone Protocol 提出的这三个基础特性。2017年 Garay对 Bitcoin Backbone Protocol协议进行了扩展70，对比特币的难度调整进行了理论分析，并对公共前缀（Common Prefix）和链质量（Chain Quality）的定义进行了适当的修改，证明了可以基于满足上述两个共识特征的区块链构建安全的公共账本。此外，Kiayias 和 Panagiotakos 证明了只要满足 Chain Quality与 chain Growth 就可以不依赖具体协议地证明协议的活性（Liveness）71。在 2017年，Rafael Pass 等人对异步网络环境下的区块链协议进行了系统性的分析以及抽象，给出了形式化的模型和主要定理72。根据这些模型和定理，可以准确地理解区块链协议各种安全属性的依赖条件以及边界。这篇论文为后续区块链协议的安全性证明打下了基础，包括 Ouroboros 和 DFINITY 在内的热门项目的论文均以该论文中提出的模型和部分结论为基础进行安全性证明。2.3 攻击方法本节对共识算法安全威胁进行全面的调研，并给出分类和进一步的分析。目前已知有多种针对不同共识算法的安全威胁，其中有理论上的安全风险，也存在实际部署中容易被利用的漏洞，下面初步例举如下：2.3.1 女巫攻击（Sybil Attack)女巫攻击是在对等网络中节点通过创建多个虚假身份标识进而提高系统中所控制节点的比例，从而对系统进行破坏。通过女巫攻击可以提高恶意节点在共识系统中的投票权，2023 云安全联盟大中华区版权所有42使其超过系统所能容忍的最大恶意节点数量，从而破坏共识。如果将传统的 BFT类共识协议直接应用于公开网络环境，由于失去了准入机制的保护，协议将会因为女巫攻击的存在而不可用。为了解决这个问题，就需要引入基于 PoW/PoS/PoSpace等的准入机制，提高节点复制身份的成本，从而避免女巫攻击的发送。2.3.2 自私挖矿（Selfish Mining）自私挖矿是 Eyal 等人在 2014年针对 PoW共识协议提出的一种攻击手段73。传统观点认为，比特币的挖矿协议是激励相容的，它可以抵御少数群体的合谋攻击，并激励矿工按照协议规定的方式进行挖矿。Eyal 等否定了这个观点，并给出了一种挖矿策略（自私挖矿），可以使恶意矿工获得比诚实挖矿更高的收益。自私挖矿会造成区块链网络分叉增加，影响网络的安全性。自私挖矿的基本策略是恶意矿工故意延迟公布其计算得到的新块，并创造一条私有分支，基于私有分支继续挖矿，而诚实矿工则继续基于公开的分支进行挖矿，当私有分支长于公开分支时，恶意节点将继续隐藏私有分支，但当公共分支接近私有分支的长度时，恶意节点将公布私有分支，从而使公开分支上的最近几个块无效。以上过程可以用一个马尔科夫链描述，通过自私挖矿期望收益如图 14所示，可见当算力超过 1/3时，恶意节点可以通过自私挖矿来提高收益。图14自私挖矿收益示意Nayak 等在 2016年提出了一种新的挖矿策略“Stubborn”，该策略对“自私挖矿”策略进行了扩展，相较于使用“自私挖矿”策略，使用该策略的恶意节点的收益将提高13.94%。作者还进一步对“Stubborn”策略进行了优化，并提出了两个新的策略，即“the 2023 云安全联盟大中华区版权所有43EqualFork Stubborn”和“Trail Stubborn”，这两个策略进一步提高了恶意节点的挖矿收益。Carlsten研究了交易手续费对于“自私挖矿”策略的影响75。Gbel等人进一步扩展了“自私挖矿”模型，将恶意节点与诚实节点之间的通信时延加入了模型76。基于此模型，作者提出了一种通过监测“孤立块”比例检测“自私挖矿”异常行为的方法。Houy则考虑了一个更加通用的假设，利用贝叶斯博弈公式对“自私挖矿”矿工在策略中的选择行为建模，进一步优化了挖矿策略77。PoW共识机制及以 PoW为基础的混合共识机制都会受到自私挖矿的影响，一些针对自私挖坑的解决方案被提出。Solat在 2016年提出了 Zeroblock78，要求一个块在块的时间戳之后的特定时间间隔内被其它节点接受，否则该块就会过期无效，这种机制在一定程度上可以防止恶意节点进行自私挖矿。Pass等人提出了 Fruitchain32，通过将出块奖励平坦到一个个小的水果区块解决了自私挖矿问题。Zhang等通过设计基于分叉率的难度调整算法，使节点无法通过自私挖矿提高收益35。2.3.3 长程攻击（Long range attack）长程攻击（Long Range Attack）则是权益证明协议中最大的威胁之一。由于权益证明协议有弱主观性并且能进行无代价模拟，这种攻击比在工作量证明协议中更为危险。长程攻击就是攻击者创建了一条从创世区块开始的长区块链分支，并试图替换掉当前的合法主链，该分支上可能存有和主链不同的交易和区块，所以这种攻击又被称 替换历史攻击或历史覆写攻击。弱主观性指的是区块链网络中的新节点或是长期离线的节点加入到网络中时无法分辨出哪些分支是从属于主链的。基于 PoW的共识协议可以通过最长链原则来选取主链，但是当遭遇 51%攻击时这个原则也会失效。但 51%攻击的代价非常高昂，因此弱主观性并不能对基于 PoW协议造成实质威胁。但是对于基于 PoS的共识协议，从头构建一条链几乎是零代价的，仅仅依靠最长链原则不足以判断哪一条是主链，从而就造成了攻击的可能。目前总共有三种不同类型的长程攻击，分别是简单攻击（Simple Attack）、变节攻击（Posterior Corruption）和权益流损（Stake Bleeding）。简单攻击是指通过伪造区块时间戳达到伪造的链具有更大链长度的目的，该攻击适用于不验证时间戳的权益证明协议区块链中。变节攻击是指对于已经退出区块链的节点，其私钥仍然可以用来产生历史区块，攻击者可以收买这些私钥伪造区块，增大其覆盖主链的概率。变节攻击可以使用密钥演进加密技术（Key-Evolving Cryptography）和移动检查点技术（Moving Checkpoint）应对。2023 云安全联盟大中华区版权所有44权益流损攻击是指为了增加攻击的成功率，攻击者可以拖延主链的正常运行，如果攻击者持有的权益占比足够多，这种行为可能会演变为一次活性冻结攻击（Liveness DenialAttack）。每当攻击者选为主链上的出块节点时，都会跳过出块，但这并不意味着别的节点可以替代其工作。相反，在该区块位置处不会有新的区块加入到主链中。而攻击者在自己的分支上积极出块。通过采用这样的策略，一方面拖延主链的出块速度，一方面在分支链上尽可能多的出块，攻击者最终可以在自己的分支链上获得绝大部分的权益，并且比主链更快地产生区块，最终覆盖主链。权益流损攻击一般需要的时间比较长。权益流损攻击可以通过采用移动检查点的策略应对。2.3.4 Difficulty Raising AttackDifficulty Raising Attack是由 Bahack在 2013年提出的一种攻击方法79，该方法允许任意算力的攻击者只要等待足够长的时间就可以以 100%的概率覆盖主链。该攻击方法的主要思路是攻击者私下构造一个区块，该区块难度是主链分支上所有区块难度的和。只要时间足够长，攻击者一定能找到一个这样的区块从而覆盖掉主链分支。由于攻击者需要根据主链的出块情况不断地调整目标难度，控制难度调整速度上限可以在一定程度上缓解该攻击，实际是目前大部分带难度调整的区块链共识协议都规定了一次调整所能调整的上限。此外由于该攻击所需要的时间非常长，在实际场景中并不太可能发生。2.3.5 无利益攻击（Nothing at Stake）除长程攻击外，无利益攻击是基于 PoS共识协议所面临的另一个主要威胁。无利益攻击问题的本质是“作恶无成本，好处无限多”。因为在基于 PoS共识的协议中出块是无成本的，当在系统出现分叉的情况时，出块节点可以在“不受任何损失”的前提下，同时为多条链出块，从而有可能获得“所有收益”，极大破坏共识的收敛性，甚至导致共识无法收敛。该攻击对基于 PoSpace的共识协议也有效。解决无利益攻击的一个主要手段是引入惩罚机制，对同时在多个分支上出块的节点进行经济惩罚（Slashing），从而迫使节点选择一个分支出块，加快收敛。2.3.6 权利压迫攻击（Grinding Attack）权利压迫攻击是指恶意节点通过影响出块节点的选举过程，加大自己被选为出块节点的概率。在基于 PoS、PoSpace的共识协议中，随机性来自于链本身的原始数据。恶意节点在出块时，可以通过尝试生成不同的区块以找到对自己有利的随机数，增大自己后续选为出块节点的可能性。2023 云安全联盟大中华区版权所有45可以通过减少采样频率的方法降低权利压迫攻击的影响，比如每隔 10个区块采样一次，10个随机数由采用值不断 Hash生成，这样恶意节点仅能影响其中一个随机数的生成。2.3.7 双花攻击（Double Spending Attacks）双花攻击是指攻击者通过某些方法将之前确认的交易推翻，双花攻击一般有三种方法：（1）Race Attack，对于同一笔钱攻击者发送两笔转账交易到区块链网络，其中一笔转向自己，由于转向自己的交易附有较高的手续，有更高概率被矿工打包；（2）Finney Attack，恶意节点通过预先挖到的区块推翻发出的转账交易；（3）51%Attack，当恶意节点的算力超过 51%时，可以通过创建更长链推翻之前区块上的交易。尽管不同的共识算法试图缓解此漏洞并采用不同的机制来解决该漏洞，但在区块链系统中无法完全避免重复支出，并且理论上可能一直在发生。2.3.7 交易拒绝攻击（Transaction denial attacks）交易拒绝攻击（Transaction Denial Attacks）是指攻击者阻止某笔交易成功完成，破坏了区块链系统的活性。交易拒绝攻击可以通过控制 P2P网络，进而使交易无法被正常广播，也可以通过通过控制矿工节点，使交易无法被打包。2.3.8 无法同步攻击（Desynchronization Attacks）无法同步攻击是指攻击者通过某些手段使系统中的节点无法与其它节点同步。该攻击通常是发生在基于 PoW、PoS、PoSpace 共识的开放网络中，由于 BFT类共识协议其节点不会直接暴露在开放网络中，且节点之间一般直接连接，因此共识节点很难产生无法同步的问题。2.3.9 日蚀攻击（Eclipse Attack）区块链网络的正常运行依赖于区块链节点间路由信息的共享。Eclipse攻击是指攻击者通过侵占节点的路由表，将足够多的虚假节点添加到某些节点的邻居节点集合中，从而将这些节点“隔离”于正常区块链网络之外。当节点受到 Eclipse攻击时，节点的大部分对外联系都会被恶意节点所控制，由此恶意节点得以进一步实施路由欺骗、存储污染、拒绝服务以及 ID 劫持等攻击行为。Eclipse攻击者通过不断地向区块链节点发送路由表更新消息影响区块链节点的路由表，试图使普通节点的路由表充满虚假节点。当区块链节点的路由表中虚假节点占据了较高的比例时，区块链网络的正常行为，包括路由查找或者资源搜索，都将被恶意节点隔绝。2023 云安全联盟大中华区版权所有46Eclipse攻击破坏了网络的拓扑结构，减少了节点数目，使得区块链网络资源共享的效率大大降低。在极端情况下，Eclipse攻击能完全控制整个区块链网络，把它分隔成若干个区块链网络区域。2.3.10 DDOS 攻击DDoS 攻击是一种对区块链网络安全威胁最大的攻击技术之一，它指借助于 C/S技术，将多个计算机联合起来作为攻击平台，对一个或多个目标发动攻击，从而成倍地提高拒绝服务攻击的威力。根据攻击方式的不同，基于区块链的 DDoS攻击可分为主动攻击和被动攻击两种。基于区块链的主动 DDoS 攻击是通过主动地向网络节点发送大量的虚假信息，使得针对这些信息的后续访问都指向受害者以达到攻击效果，具有可控性较强、放大倍数高等特点。这种攻击利用反射节点在短时间内发送大量通知信息，不易于分析和记录，并且可以通过假冒源地址避过 IP检查，使得追踪定位攻击源更加困难。此外，主动攻击在区块链网络中引入额外流量及虚假的索引信息，会降低区块链网络的查找和路由性能、影响文件下载速度。基于区块链的被动 DDoS攻击通过修改区块链客户端或者服务器软件，被动地等待来自其它节点的查询请求，再通过返回虚假响应达到攻击效果。通常情况下，需采取一些放大措施增强攻击效果，如：部署多个攻击节点、在一个响应消息中多次包含目标主机、结合其它协议或者漏洞等。被动攻击属于非侵扰式，对区块链网络流量影响不大，通常只能利用局部的区块链节点。如果共识协议中出块节点的选择可以被预测，则可以针对出块节点进行 DDoS攻击，从而达到拒绝打包某些交易或者禁止某些节点出块的目的，破坏区块的安全性及活性。2.3.11 51%攻击51%攻击即网络中恶意节点的算力或权益占到了 50%以上。对于 PoW机制，恶意节点掌握了全网络 51%的算力，那么该攻击者构造一个合法区块的平均时间会少于其他矿工，从而在相同的时间内可以构造出更多区块，并以最长合法链被网络接受，这样整个网络都可能在该恶意节点的控制下。在 PoS算法中，51%攻击转变为掌握网络中的大多数权益。在拜占庭类算法中，控制 33%的节点即可阻止达成共识，控制 2/3的节点就可操纵共识结果。2023 云安全联盟大中华区版权所有472.3.12 贿赂攻击贿赂攻击是指在区块链中存在一个拥有足够资源的贿赂者，通过额外的奖励激励其他节点采取特定行动的攻击行为，也就是“收买”现有节点对区块链进行攻击。该攻击可以不用花大成本去掌握 51%的算力，就可以对区块链造成分叉。可以引入保证金和惩罚措施防范此类攻击。2.3.13 历史多数攻击（Past Majority Attacks）历史多数攻击是指历史上对某区块链拥有控制权（出块权）的组织或个人，利用自己历史上存在的对该网络的控制权，从这个历史时间点开启新的分叉，甚至覆盖主链。该攻击对基于 PoS的共识协议影响较大，因为在历史上存在权益的节点，从历史时间点构造一条新的分叉几乎不费任何代价。2.3.14 BGP HijackingBGP 劫持攻击即利用 BGP操纵路由路径，如误导或拦截流量等，进而可以破坏区块链中共识机制、交易等信息。目前有数据统计大多数比特币节点都保管在少数特定的几个互联网服务提供商中，比特币网络的集中化更容易遭受 BGP 劫持攻击。2.3.15 P Epsilon 攻击P Epsilon攻击也是贿赂攻击。假设每个矿工都需要投票给 0，若达成共识则每个矿工都可以获得 P收益，若有人投票给 1则收益为 0。攻击者进入系统，告诉每个矿工若他投票给 1而其他人不投票，则他可以额外获得 Epsilon收益。每个矿工由于并不知道攻击者也告诉了其他矿工，因此有很大概率会选择投票给 1增加收益，最终所有矿工都投票给 1，达成了不利于区块链的共识。而此时攻击者甚至都不需要支付贿赂费用，对攻击者造成了双赢的局面，但对区块链影响重大。2.3.16 冷启动攻击PoS机制中，由于持币量会对挖矿难度产生影响，因此当一个基于 PoS的代币系统启动时，早期获得代币的持有者就会没有动力去花费或者转移代币。而且这些持有者会更容易挖矿，因此会出现初始代币流通性不好的问题。2.3.17 币龄累积攻击币龄攻击针对 PoS和 DPoS算法，节点获得记账权的可能性与账户中持币的数量和每个币的持币时间有关，当节点拥有的币越多，持币时间越长时，获得记账权的可能性就越 2023 云安全联盟大中华区版权所有48大。这样就会导致部分节点买入一定数量币后，持有足够长时间后达到 51%以上的算力，从而控制整个网络。2.3.18 预计算攻击预计算是指当 PoS中的某一节点有了一定量算力之后，就有能力控制挖矿参数使得挖矿难度在自己算力范围内。2.3.19 藏块攻击（Block withholding attack）藏块攻击是指攻击节点将一部分算力加入矿池挖矿，另一部分算力独自挖矿，加入矿池的那部分算力正常响应矿池发来的挑战，但是如果找到可以出块的答案，则不发送给矿池，由于找到可以出块的答案的概率比较小，不会影响矿池计算其在矿池中所占的份额，这样做会导致整个矿池的收益降低，但是会降低挖矿难度，提高攻击者独立挖矿算力的收益，从而使其整体收益提高，破坏了区块链共识协议的公平性。3共识算法安全测试方法和标准本节从共识算法理论和实现两方面展开安全测试和分析，理论分析主要从算法本身展开分析，不涉及算法的代码实现和具体应用部署环境。实现分析从算法的具体参数、代码实现、应用部署等都方面进行安全分析和测试。3.1 共识算法安全理论分析和模拟本节主要考虑算法本身和参数方面是否存在安全缺陷，通过模拟方式测试、验证共识算法在网络部署时的安全性。3.1.1 共识算法安全理论分析对于共识算法理论上是否满足安全性，主要考察共识算法是否满足一些属性，Bonneau对文献448182的工作进行了总结，提出了共识算法一般需要满足以下五个安全特性80：（1）最终一致性，即在任何时候，所有合法节点都对最终能成为有效区块链的前缀链达成共识。但是不能要求任何时候最长的链最终都能成为有效区块链的前缀，因为存在临时分叉，有些块会被丢弃。（2）指数收敛，即长度为的分叉出现的概率为(2)，这会给用户高度信心，区块被确认的规则将使用户的交易永远包含在有效区块中。2023 云安全联盟大中华区版权所有49（3）活性，即新的区块会持续添加到链上，并且拥有合理交易费的有效交易会包含在区块中。（4）正确性，即最长合法链只包含有效交易。（5）公平性，即拥有占总算力的矿工将挖出约比例的区块。有了以上标准，就按照此标准来从理论上初步判定一个共识算法是否具备安全性。共识算法中包含许多参数，这些参数一般都会影响共识算法的安全性，Bonneau在文章中列举几个重要参数：（1）出块间隔和难度调整窗口：出块间隔定义了矿工将区块写入区块链中需要等待的时间，出块间隔越短，确认交易就会越快，区块过期的可能性就越高，因此可以观察其出块时间判定共识算法的安全性。共识算法会自动调整对抗性难题的难度，以便在固定时间内出块，难度较低就会使网络中的块数量较多，出块速度较快，难度较高就会导致块数量较少。若出块速率过快，那么受到网络延迟的影响，矿工通常会在这些块被传播之前就找到冗余块，较容易出现分叉。若出块速率过慢，那么就增加了用户等待事物确认的时间。因此，难度调整窗口会影响攻击者对最长合法链的攻击能力，并且为了防止双花攻击，使得商家可以安全接受交易，还需要调整交易确认需要等待的块数。（2）块大小限制：通常情况下，区块有大小限制，比如比特币的块大小为 1MB。随着交易量稳步增长，这一限制可能很快就会达到。一旦达到该限制，交易者就需要支付更高的交易费用竞争资源。攻击者可能会利用块大小限制发起 DDoS 攻击和女巫攻击，通过发起数笔交易来使合法用户受到阻塞。通过观察块大小限制可以初步判定共识算法安全性。（3）货币政策：共识算法中通常会规定货币政策，比如比特币会规定新货币的铸造速度，还有一些 PoS算法会规定币龄上限。货币政策通常会影响初始代币的价格，若是通货紧缩的货币政策，那么最终可能会导致没有人愿意购买新的代币，囤积该币会更加有利可图，造成流通性不好的局面。而一些 PoS算法中，币龄与算力成正相关，最终可能会导致攻击者持有 51%的算力发起攻击。3.1.2 安全性与恶意攻击类型攻击行为一般发生在交易或者区块链前后的共识阶段。在共识过程中，为了保证区块链的稳定性，共识安全性的评估是非常有必要的。倘若区块链的安全性出现问题，那么即便区块链吞吐量（TPS）再高或者共识节点再多，区块链也无法保证其交易数据不可篡改和真实有效性。本小节将从理论的角度分析共识算法安全性和恶意攻击之间的关系。2023 云安全联盟大中华区版权所有50对共识的恶意攻击主要类型在 2.3 节已经介绍.3.1.3 应对策略对于共识的攻击，主要有以下几种应对策略：1）增加创建节点的成本。提高创建身份的成本可以有效减轻恶意攻击的风险。例如，在燃烧证明算法中，用户需要购买然后燃烧一定量的代币（通过将一些硬币发送到不可逆的地址）验证其身份。在堆栈证明中，用户需要在堆栈中放入一些代币。在工作量证明中，用户需要拥有并花费一些计算能力。该策略的主要挑战是如何找到理想的身份创建成本，以有效减轻恶意攻击的风险，并且不限制普通人加入网络。创建节点的成本也可能随时间变化，并且区块链共识应能根据网络需求修改其所使用的成本。2）引入某种类型的信任。抵御恶意攻击的第二种常见方法是在为节点加入区块链引入额外的信任机制。这种信任机制可以通过简单的两步验证/电子邮件/SMS或要求一组管理员进行验证的方式实现。基于用户的 IP 地址进行一些限制以及防御僵尸网络的其他常见方法也可用于提供这种信任。3）赋予身份不平等的权力。为用户和节点赋予不同的权限是防御恶意攻击的另一种方式。例如，在权重证明算法中，根据多个参数（如用户帐户的使用期限、与之进行交易的唯一身份用户的数量、用户拥有的代币数量）为每个帐户赋予权重以及交易数量。给定的权重赋予每个用户相关的投票或参与权。但是，这种不平等的权力分配使该系统成为精英制而不是纯粹的民主制，对于新用户而言可能并不友好。不同的共识机制使用不同的方法或它们的不同组合来防御恶意攻击。没有“最佳”策略，每个策略都有自己的优缺点。2023 云安全联盟大中华区版权所有514）根据业务场景切换共识算法评价共识算法的一般有四个维度：安全性、扩展性、性能效率和资源损耗。不同共识算法所侧重的方向也各不相同。因此，当面对不同的场景时，为了保证安全性，可以在全网同时采用多种共识算法，通过多级共识确认交易，以及根据业务场景选择合适的共识算法。3.1.4 共识算法安全模拟通过 3.1.1节对共识参数作理论分析，可以初步判定共识算法是否存在安全漏洞，为了更好的对共识算法进行分析，还可以用模拟的方式测试共识算法的安全性。3.1.4.1经典共识算法安全模拟一个直观的想法是运行实际的区块链应用程序分析区块链的性能，比如 Castro使用真实系统将 PBFT共识算法与其他算法进行了比较84。另一种思路是通过建立数学模型对PBFT算法进行模拟，以分析其更多的性质。Kai Zheng 等人提出使用连续时间马尔可夫链（CTMC）模型模拟 PBFT 的共识过程85，该 CTMC模型包括 5个部分：请求过程、预准备过程、准备过程、提交过程和答复过程。请求过程是客户端将请求发送给主节点；预准备过程是区块链中一个主节点被选中，其他节点变为副节点，主节点要向副节点广播消息；准备过程是副节点计算哈希摘要并且向所有节点广播；提交过程是如果主节点和副节点都收到了 2f的哈希摘要，并且摘要和自己的相同，就进行提交；答复过程是如果一个节点收到 2f 1的提交信息，就可提交新区块。CTMC模拟了此过程，整个模型中有 1 个客户端，1个主节点和 6 个副节点。作者主要考察了网络传播速度、客户端发送或接收消息的平均时间、主节点向其他节点发送消息的时间、副节点向其他节点发送消息的时间对于能否达成共识一致的影响。实验结果表明，这四者均是速度越快、发送或接收消息的平均时间越短，达成共识一致的可能性就越高。其中，网络传播速度对于达成一致的影响最大，其次是客户端、主节点，副节点对达成一致的影响最小。Sukhwani 等人使用随机奖励网络（SRN）对 PBFT 共识协议进行了建模86，主要对节点之间共识消息的传输时间、处理传入共识消息的时间和准备下一阶段共识消息的时间进行评估。作者假设：（1）在块事务开始之前每个领导节点就已经被选择好，并且在三阶段协议执行时不会改变；（2）每个验证节点处理消息的速度相同；2023 云安全联盟大中华区版权所有52（3）所有节点之间的消息传输率相同；（4）验证节点在执行三阶段协议时不会失效。作者之后对影响 PBFT共识算法的因素进行了分析。首先是敏感度分析，作者发现与为下一阶段准备共识消息相比，处理传入共识消息和提交消息的速度若较慢的话，对各节点达成共识会有较大影响。之后作者又考虑了节点数量对达成共识时间的影响。当节点数量增多时，基本上达成共识的时间也需要增加，这是因为节点增多会导致准备和提交阶段中消息的排队延迟增加。但是如果传输延迟比处理消息或排队的时间大一个数量级或者两倍，则随着节点数量的增多，达成共识的时间不会明显增加。因为 PBFT协议是基于消息传递的算法，因此共识消息传递的延迟对于能否达成共识较为重要。Halalai等人提出了一个基于模型检查和仿真技术的结合模型 HyPerf87，用于评估BFT协议的性能。模型主要包括客户端和副本，模拟了它们的状态以及客户端和副本之间消息通信过程。同时作者定义了 BFT共识协议的安全标准：（1）请求/响应对应，对于所有的客户端，接收到的响应都对应于之前发出的请求。（2）状态可达性，对于所有正确的副本，可以通过一系列客户端请求到达每个状态。（3）线性化，对于所有正确的副本，所有的请求都按照客户端看到的顺序执行。（4）状态一致，所有正确的客户端最终都会受到响应，所有的副本最终都能达到一致状态。但是上述模型只考虑了各节点最终的状态，并没有考虑时间消耗，因此作者为客户端和每个副节点的状态中都增加了时间消耗。增加时间消耗后，该模型就可以考虑对请求的响应时间，并把此增加到上文所述的安全性能中：（5）时效性。对于所有的客户端，每个请求都需要在一定时限内完成。之后作者用该模型对 PBFT算法进行了测试，主要测试了协议的时耗问题，并且考虑了有恶意行为的情况，即有一个副节点是拜占庭节点。结果表明这样的情况对于 PBFT没有很大影响，系统还是与正常情况一样达成了共识。3.1.4.2区块链共识算法安全模拟由于基于区块链的共识协议多应用于开放网络，环境复杂，难以通过实际运行协议来对协议进行安全分析，因此多通过建立数学模型进行模拟。Gervais使用马尔科夫决策过程（MDP）对挖矿行为进行了模拟，将其建模为一系列步骤83。MDP是离散时间随机控制过程，针对一些决策的输出结果部分随机而又部分可控的情况，给决策者提供一个决策制定的数学建模框架。与其他文献中的做法相似，要将区块链系统建模为 MDP，就要先 2023 云安全联盟大中华区版权所有53将区块链状态进行编码，并将参与者的可用决策编码为多个动作，并且用状态转移矩阵描述每个（状态，动作）的概率分布。MDP中描述的区块链状态包括可能影响诚实矿工和攻击者的所有信息，如竞争链的长度、攻击者挖出的未发布的区块数量等。诚实矿工会根据自己的算力，以概率分布开采新的区块，而攻击者会决定是否要发布新区块、发布多少区块以及要对哪条链进行挖掘，而这些事件都会触发 MDP状态转换。通过对该过程进行模拟，对攻击者的攻击过程进行建模，可以及时发现共识协议的弱点。在 MDP过程中观察以下参数：（1）孤块产生速率：孤块产生速率 会考虑不同的块大小、出块间隔、网络延迟、消息传播机制和网络配置（如节点数）。（2）挖矿算力：指攻击者算力占系统总算力的那部分，剩余部分的算力掌握在诚实节点中。（3）挖矿成本：对抗挖矿成本 0,对应于攻击者的预期挖矿成本（即总挖矿成本，包括硬件成本、电力、人力等），并以块奖励的形式表示。例如，如果=，则攻击者的挖矿成本等于其挖矿算力乘区块奖励，即挖矿成本完全由诚实矿工挖矿的区块奖励所覆盖。（4）区块确认数：区块确认数 对应需要确认交易以使商家接受交易的区块数。（5）传播能力：传播参数 表示攻击者在网络中的流通性，即当攻击者和诚实节点在网络中同时释放区块时，网络接收攻击者区块的概率。（6）日蚀攻击的影响：该模型考虑了日蚀攻击。在这里，我们假设诚实矿工会收到孤块产生速率的影响，但是攻击者及其同谋却不会在孤块上继续挖矿。这是因为攻击者可以对任意的区块进行攻击，并且当攻击者选择了一条诚实的链后，有很小的几率去开采孤块。因此在实际中，攻击者比诚实矿工挖到孤块的概率小得多。诚实的网络因为受到网络传播和延迟的影响，因此会有更高的孤块产生速率。为了定义最佳的双花攻击策略，作者定义了与最小交易值相对应的双花攻击金额，该双花攻击金额是使得双花攻击的收益大于诚实挖矿获得的收益的最小交易值。可以作为量化双花攻击下共识算法安全性的可靠指标，即如果诚实矿工挖矿获得的奖励大于不诚实行为的奖励，那么商家可以安全地接受价值的付款交易，因为这样的价值被认为是安全的。但是如果攻击者行为在经济上有更多回报，那么商家会意识到相关的双花攻击风险和矿工的相关激励措施。2023 云安全联盟大中华区版权所有54现在使用 MDP模型 模拟区块链系统，其中所有其他参与者都遵循共识协议，S表示空间状态，A 表示动作空间，P 表示随机转移矩阵，R表示奖励矩阵，M表示 MDP过程。在模型中，攻击者可以采取以下动作：（1）接受：攻击者接受诚实网络的链，此动作其实是攻击者重启发动攻击的开始，若攻击者发现赢取诚实链的可能性较小，那么此操作是适当的。（2）覆盖：攻击者比诚实节点发布的块多了一个块，因此可以覆盖有冲突的区块。当攻击者的秘密链比当前已知的公开链长（即），并且攻击者发布 1 个区块以用自己的秘密链替换公开的诚实链时，就会出现覆盖的情况。如果攻击者利用诚实节点的挖矿能力，则攻击者可能会使用诚实节点的个区块实现覆盖操作。（3）竞争：攻击者发布与诚实节点发布的一样的区块，触发两条链之间的竞争，而不是发布比诚实节点多的区块进行覆盖。（4）等待：攻击者继续在自己的秘密链上进行挖矿直到挖到一个区块为止。（5）退出：此操作仅在研究双花攻击时才有意义，因为它对应于具有个确认的成功双花攻击，并且仅在 并且 时才可行。状态空间定义为形式为,，其中表示对手链的长度，表示诚实链的长度，表示通过日蚀攻击挖到的区块，可以用三个值表示，分别是不相关、相关和活跃：（1）相关：相关表示诚实节点找到了最后一个区块，以及如果 则竞争操作可用，,1,的状态会变为,。（2）不相关：当攻击者找到最后一个块时，前一个块可能已经到达网络中的大多数节点，因此攻击者无法进行竞争操作，1,的状态会变为,。（3）活跃：当攻击者确定执行竞争操作时，该状态被标记为活跃，即当前网络正在分裂并且正在确定最长合法链。在该模型中，每一次状态的转变都对应着一个区块的创建，因此每次状态转变都意味着对诚实节点、攻击者或者日蚀攻击受害者的一次区块奖励。给定攻击者的挖矿算力，初始状态 0,0,0,会以概率转换为1,0,0,，即攻击者找到了一个区块。如果诚实节点发现了一个非孤块，则状态 2023 云安全联盟大中华区版权所有55会变为 0,1,0,。如果诚实节点发现了一个孤块，则状态会保持 0,0,0,，因为孤块不计入最长合法链中。此外 R.Zhang 等人对 MDP进行了改进35，将 MDP模型扩展到了拜占庭式攻击者，也就是不仅考虑经济利益方面的攻击，同时还考虑审查攻击或主链质量攻击，并且还引入了人工智能技术分析协议的安全性，给定攻击者的攻击目标，可以系统地找到共识协议中该方面的安全漏洞，从而有利于迭代地改进协议。3.2 共识算法安全渗透测试和代码安全审查3.2.1 安全指标除了对共识算法进行理论分析和模拟外，也需要测试算法实现中能否保证正确性和安全性。R.Zhang等人给出了四个指标，用以衡量在实现过程中算法的安全性35：（1）链质量：主要用于衡量替换诚实主链的难度，用区块链中诚实矿工挖出的区块数量除以诚实矿工和攻击者共同挖出的区块数量计算得出。假设攻击者控制了总挖矿能力的，则链质量定义为诚实矿工拥有的那部分挖矿算力 的下界。将和分别定义为诚实矿工和攻击者挖出的区块总数，是攻击者的攻击策略，那么我们有：=minlim ，理想情况下，=1 ，即攻击者获得的区块数最多与他们的挖矿能力成正比。越大，说明诚实矿工挖出的区块数量更多，该共识算法被攻击者替换主链的难度就越大。（2）激励兼容性：主要用于衡量共识算法对自私挖矿的抵抗力，用区块链中诚实矿工获得的奖励除以诚实矿工和攻击者总共获得的奖励计算得出，计算方式如下：=minlim? ?，其中?和?分别是诚实矿工和攻击者获得累积收益，激励兼容性与链质量有相同的理想值 1 。若该值越大，说明诚实矿工获得的奖励更多，矿工更愿意按照规定的共识协议进行挖矿，该共识算法对于自私挖矿的抵抗力就越强。（3）作恶收益：主要用于衡量双花攻击的成功率。该指标被量化为一定时间内区块链中双花收益的总金额，非法收益指的是攻击者无需消费就从商家那里获得的商品金额。我们假设每个诚实的区块都包含向商家的付款交易，当包含支付交易的区块达到确认后（比如比特币中=6）或者攻击者选择放弃攻击该区块时，商家就可以提供服务或者商 2023 云安全联盟大中华区版权所有56品。在前一种情况，如果之后付款交易无效，则对于在确认后孤立的每个区块，攻击者将以出块奖励为单位接受双花奖励，也就是说如果攻击者成功双花攻击使得个区块成为孤块，那么双花奖励将被定义为：,=0,( 1 ),，其中 1 是孤立的确认块的个数。此外，如果在到达确认之前，就使交易无效，则=0。攻击者并不会因为双花攻击失败而受到损失，因为商家还是会提供商品或服务，从而补偿了攻击者的损失。该指标能够从多个方面衡量共识协议是否能抵抗双花攻击，首先?会迫使攻击者去平衡失去出块奖励的风险和双花攻击成功得到的双花收益。第二，如果在确认之前广播冲突的交易，则允许商家延迟交货，以抵消攻击。第三，更长的分叉会在现实中带来更大的伤害，对攻击者来说回报也就更高。攻击者的作恶收益定义如下：,=maxlim? ?，其中，表示持续时间，是用出块间隔来衡量，是没有双花攻击的平均出块奖励。在理想情况下，攻击者应该诚实遵守协议以避免丢掉出块奖励，但是如果足够大，攻击者就能被该激励诱惑。（4）审查敏感性：主要用于衡量对审查攻击的抵抗性。该指标被量化为因为拒绝审查者的要求，导致诚实矿工的收益损失的最大百分比。我们选择不考虑攻击者的经济损失，因为如果审查威胁成功，则不会进行报复。只要其他诚实矿工能够坚定攻击者的决心，那么影响攻击者战略的唯一因素就是诚实矿工不进行合作的预期损失。与羽毛分叉攻击(Feather-forking attack,或惩罚性分叉来审查链上的交易。补充来说，这与生成分叉币种、空投或盈利无关，而与阻止网络参与者在区块链中执行交易操作有关。这样的攻击向量也要比 51%攻击更先进，因为它并不需要大多数的算力来将一个网络参与者列入黑名单当中)不同，在该评估标准中，攻击者在收到包含目标交易的区块后就会立刻开始报复，一旦合法矿工开始挖掘该区块，攻击者就会发起攻击。此设置很实用，因为攻击者可以通过一直监视网络中的交易立即进行挖矿。审查攻击和羽毛分叉的另一个区别是，允许攻击者放弃落后的链并能够在任何时间孤立下一个诚实的块。由于攻击者的目标是最大程度地增加诚实矿工的损失，因此攻击者并不会在落后的链上进行挖矿。因此在落后的链上进行挖掘并非总是最佳的。我们还考虑了多种攻击情形，例如在极端的攻击形式中，攻击者通过用空白区块替代诚实区块，从而延迟所有交易的确认时间，降低系统的可用性。审查敏感性定义如下：=maxlim? ?，2023 云安全联盟大中华区版权所有57其中?是诚实矿工因为审查攻击而遭受的累积奖励损失，以区块奖励为单位。在理想情况下，=0，即诚实矿工没有拒绝审查请求的风险。通过以上四个指标，可以对共识算法实现过程做安全审查，若无法同时满足以上指标，则该共识算法在实现过程较容易受到攻击。3.2.2 渗透测试“渗透测试”是完全模拟黑客可能使用的攻击技术和漏洞发现技术，对目标系统的安全做深入的探测，发现系统最脆弱的环节。渗透测试和黑客入侵最大区别在于渗透测试是经过客户授权，采用可控制、非破坏性质的方法和手段发现目标和网络设备中存在弱点，帮助管理者发现 IT 系统所面临的安全威胁。共识算法渗透测试的测试点主要有：（1）公共参数许多共识算法对如区块大小、出块间隔、奖励、主节点等都做了详细的规定，这些公共参数不应该被轻易修改，渗透测试应检查是否有违反公共参数的可能性。（2）一致性/有效性/可用性/公平性节点是否能在有限的时间内对共识的数据达成一致，所达成的数据是否合法，数据是否实时可用，节点是否能够公平的参与共识等。（3）数据传输共识通信多依赖 P2P网络，需测试节点间网络是否能够正常连通、是否存在被 DDoS攻击的可能、节点身份是否会被伪造、通信是否会被劫持等，如果通信有保密需求，则必须验证数据的加密和解密是否正常。（4）API测试API测试就是要检查应用程序与区块链生态系统之间的交互。这样做是为了验证 API发送的请求和响应，并确保它们已正确格式化和执行。（5）集成测试由于跨不同环境和并行系统部署了区块链测试，因此对集成测试的需求增加。完成测试是为了确保不同组件之间能够无缝通信。测试团队对 API进行测试，确保可以在验证阶段使用这些 API。（6）性能测试通过性能测试可确定潜在的瓶颈，并检查应用程序是否已准备好投入生产。确定性能的测试自动化是检查共识系统整体可扩展性的关键。（7）安全测试 2023 云安全联盟大中华区版权所有58目的是确保完全保护区块链应用程序免受病毒和恶意程序等攻击。区块链的安全测试需要非常彻底同时应迅速响应。由于正在进行的事务无法停止，因此测试过程应足够有效以发现所有潜在威胁。有效的安全测试还有助于改善公司在消费者面临风险之前撤销有缺陷的商品的流程，有助于实现数字质量保证。渗透测试通过有效利用编码错误，以潜在黑客的心态开展工作。用简单的话来说，测试人员本身就是黑客，并试图闯入网络以检测和报告安全漏洞。渗透测试人员花费的总时间取决于网络规模及其架构的复杂性。较小的测试只是时间问题，而较长的测试可能需要长达数周的时间。需要区块链渗透测试作为解决方案的一些挑战是：缺乏测试工具知识不足不称职的策略不可逆转的交易性能和负载测试有效的区块链测试可帮助组织通过连接的基础架构安全地构建和利用该技术。测试过程包括核心测试策略和服务，如云测试服务、功能测试、API测试、集成测试、安全测试和性能测试。它还包括特定于区块链的测试策略，如块测试、智能合约测试和对等/节点测试。3.2.3 渗透测试工具和代码安全审计测试人员选择最合适的区块链渗透测试工具以减轻漏洞并提供最佳质量的结果同样重要，以下几个框架是常用的测试框架：（1）Truffle框架Truffle是最受欢迎的开发环境之一，也是用于区块链测试的测试框架。Truffle为智能合约提供了简单的生命周期管理，包括对库链接、自定义部署和复杂的基于区块链的应用程序的支持。Truffle还提供自动合同测试，开发人员可以使用 JavaScript和 Solidity编写自己的自动测试代码。它的一些显着特征是：开发期间立即重建资产可配置的构建管道，完全支持自定义构建过程可编写脚本的部署和迁移框架通过交互式控制台进行直接合同通信（2）Embark 2023 云安全联盟大中华区版权所有59Embark提供了一种简单的声明性方法定义要部署的智能合约及其相关性。以太坊测试仪为各种区块链测试需求提供可管理的 API支持，旨在改善用户和开发人员的体验，并帮助他们轻松管理和执行所选工具。（3）Populus这里的测试由 python测试框架提供支持，并提供了用于测试智能合约的有用实用程序。代码审计是直接对程序的源代码进行检查，以确定程序源代码是否存在安全隐患，或者有编码不规范的地方，通过自动化工具或者人工审查的方式，对程序源代码逐条进行检查和分析，发现这些源代码缺陷引发的安全漏洞，并提供代码修订措施和建议。代码审计对于共识系统的发展具有重要意义：一方面，代码审计可以节约安全投入，降低修复成本。研究表明，当应用发布后再执行代码修复，修复成本大约是设计编码阶段的 30倍。所以，变被动防护为主动防御，从源头上控制安全隐患，可以最大程度节约成本；另一方面，代码审计可以降低系统安全风险。通过代码审计及时对代码层缺陷进行修复，从而大幅度提升系统整体安全性，避免巨额经济损失。越来越多的共识系统安全事件正在倒逼代码审计的发展。目前，智能化代码审计，即利用计算机进行稳健性检验是代码审计最重要的方式，但掌握该项技术标准的国内公司并不多。代码审计亟待进一步普及与发展。3.3 共识算法安全 CheckList包含 2.1和 2.2的安全检查列表。结合 2.1和 2.2内容，共识算法安全检查包含以下方面：（1）对算法参数进行检查，包含以下 3个指标：a.出块时间和难度调整窗口：检查出块间隔和难度调整窗口是否合适，若出块速率过快，那么受到网络延迟的影响，矿工通常会在这些块被传播之前就找到冗余块，较容易出现分叉。若出块速率过慢，那么就增加了用户等待事物确认的时间。b.块大小限制：区块大小和区块包含的交易数量紧密相关，通过检查区块大小防止交易量过大造成的合法用户阻塞问题。c.货币政策：检查货币政策是否过于紧缩，若紧缩会导致矿工挖矿积极性不高，初始代币不流通。（2）对算法进行模拟检查：通过 MDP建模模拟挖矿过程，包括区块链状态、攻击者动作、随机转移矩阵和奖励矩阵。诚实矿工会根据自己的算力，以概率分布开采新的区块，而攻击者会决定是否要发布新区块、发布多少区块以及要对哪条链进行挖掘，而这些事件 2023 云安全联盟大中华区版权所有60都会触发 MDP状态转换。并且对双花攻击和日蚀攻击建模，考虑这些攻击的最坏情况，模拟攻击者的攻击过程，可以及时发现共识协议的弱点。（3）对算法实现过程进行检查：包含以下 4个指标：a.链质量：主要观察算法能够替换诚实主链的难度，用区块链中诚实矿工挖出的区块数量除以诚实矿工和攻击者共同挖出的区块数量计算得出。若该值越大，则算法被攻击者替换诚实主链的难度就越大。b.激励兼容性：主要观察算法对自私挖矿的抵抗力，用网络中诚实矿工获得的奖励除以诚实矿工和攻击者总共获得的奖励计算得出。若该值越大，则诚实矿工获得的奖励更多，算法对于自私挖矿的抵抗力越大。c.作恶收益：主要观察算法对双花攻击的抵抗力，量化为一定时间内双花攻击获得的总收益。若该值越大，则算法对双花攻击的抵抗力更弱。d.审查敏感性：主要观察算法对审查攻击的抵抗力，量化为因为拒绝审查者的要求，导致诚实矿工的收益损失的最大百分比。若该值越大，则算法对审查攻击的抵抗力越弱。针对共识机制的安全风险有很多，下表列举了主要风险和攻击类型，通过逐条对照可以对所设计的共识算法进行安全性评定。下表可作为共识算法安全的 Checklist。2，3，8攻击类型攻击类型攻击对象攻击对象攻击手段攻击手段影响影响51%攻击PoWPoSDPoS当攻击者能够控制区块链中超过 50的能力（如挖掘能力或验证能力）时，他/她就能够进行恶意活动，例如双重支出或阻止其他节点接收其诚实交易。不同算法在攻击行为上有所不同，51的攻击也是不可避免的。分叉攻击PoWPoS一个或多个节点通过控制全网特定百分比以上算力/数字资产，利用这些算力/数字资产隐秘计算新区块（攻击区块），构造区块链分叉，并在攻击区块达到一定长度之后向所有节点释放，迫使节点放弃原区块篡改分叉后攻击者账户数据，实现双重支付，可导致链上记录回滚（可达数月）女巫攻击PoW攻击者生成大量攻击节点并尽可能多的将攻击实现攻击者对区 2023 云安全联盟大中华区版权所有61PoSDPoS节点植入网络中，在攻击期间，这些被称为女巫节点的攻击节点将只传播攻击者的块，导致攻击者算力无限接近于 1块链网络的高度控制权贿赂攻击PoS攻击者购买商品或者服务，商户开始等待区块链网络确认交易，此时攻击者开始在网络中首次宣称，对目前相对最长的不包含本次交易的主链进行奖励。当主链足够长时，攻击者开始放出更大的奖励，奖励那些在包含此次交易的链中挖矿的矿工。一旦确认达成后，放弃奖励。货物到手，同时放弃攻击者选中的链条。以小于货物或者服务费用的成本获利预计算攻击PoS将某一时间段内计算出的新区块扣留不公开，等到挖到第二块新区块后同时公布攻击者所在分叉成为最长链Sybil攻击PoWPoSDPoS攻击者尝试通过在区块链中创建许多欺诈性身份来控制对等网络。这些身份似乎是唯一的用户或节点，实际上是由攻击者控制的。这些身份用于获得投票权，阻止验证权，甚至在区块链的社交网络中传播假消息。使攻击者对网络有不成比例的控制权或包围诚实的节点，并试图影响到达该节点的信息，然后逐渐影响分类帐。双花攻击PoWPoSDPoS当一个人尝试两次在区块链上花费特定金额的钱时，就会发生双重支出攻击6。当攻击者试图创建一个正常交易以包含在一个区块中，然后在一段时间后，创建一个欺诈性冲突交易并将其推到一个新的分叉欺诈性区块中形成欺诈分支，影响交易3.4.1 共识算法的安全性测试步骤：针对共识算法的安全测试应遵循如下步骤：a)应保证来自于系统正常运行节点的请求能在规定时间内达成一致的、正确的共识最终 2023 云安全联盟大中华区版权所有62能够被系统接收并处理，需要测评是否能输出正确结果；b)应保证任意不超过理论值的节点数故障不会影响整个系统正常工作，需要测评诚实的节点是否会对相同的请求做出明确且一致的判断；c)应保证验证规则满足概然性与统一性，如共识机制中包含验证过程，需要测评每一参与节点是否具有独立判断能力；d)应保证共识方案的发布需伴随清晰的应用场景和规模参数，便于对机制的安全适配范围进行规范化的校验，主要测评该共识机制是否能够防止双重支付、女巫攻击等。e)应保证在理论值范围内的恶意节点对系统发出伪造、重复的恶意请求时，系统能够做出正确的响应，保证一致性。4 共识算法安全案例分析本节利用上一节的测试方法和标准，对共识算法安全的典型安全进行分析，并给出分析过程和结论。本节的案例包括现实中的案例和设计的案例两类，目标是涵盖前文介绍的全部安全威胁和测试方法。下面列举部分现实的共识算法安全案例：4.1 51%攻击2013年 6月，一种以莱特币为原型的创造的加密货币 Feathercoin遭遇 51%攻击，攻击者通过双花攻击卷走了价值 6.38万美元的代币，Feathercoin的创始人表示此次攻击的算力可能来自于莱特币矿池。2014年 7月，比特币矿池 GHash.IO在某天内获得了超过 51%的哈希率，引发了外界对比特币漏洞的担忧，尽管没有发生恶意攻击，但随后矿工逐渐离开矿池并且该矿池于 10月关闭。2016年 8月，一群被称为“51crew”的攻击者劫持了两个基于以太坊的区块链，Krypton和 Shift，通过发起双花攻击获取了价值 21465 Kryptons的数字货币。Krypton项目的代码复制于以太坊，拥有几乎一样的功能，这也被证实一些算力低的山寨币更容易受到 51%攻击。在 2018年 4月和 5 月，Verge经历了两次 51%攻击，遭受了 180万美元的价值损失。Verge为了避免算力的集中化采用 5种算法，项目在 5 种算法间切换，而攻击者正是利用 Verge算法的漏洞，修改了区块链的时间戳，从而成功攻击。2018年 5月，一群比特币矿工获得了超过 50%的算力，对比特黄金发动了攻击，盗取了价值 1800万美元的比特币。随后在 6月，还攻击了其他四种加密货币，分别是Monacoin，Zencash，Verge和 Litecoin Cash。这些攻击者甚至不需要购买硬件矿机，只需要在攻击期间从算力租赁市场租赁显卡算力，这种方式极大地降低了攻击者攻击的成本。2023 云安全联盟大中华区版权所有63同样的，在 2019年 1 月，ETC被发现受到了 51%攻击，攻击者总共获得了价值 110万美元的以太币，攻击者同样不需要投资任何硬件设备。从以上案例可见 51%攻击可分为以下几种情况：（1）与其它区块链公用相同的挖矿算法，导致攻击者可以从其它区块链抽调算力进行攻击，这多次发生在分叉币上；（2）矿池算力过于集中，矿池越大，矿工收益就越稳定，所以矿工倾向于选择大的矿池，导致矿池所拥有的算力越来越多，最终超过 51%，但该情况威胁一般不大，当矿池算力过大时，理性矿工会选择离开矿池，以使矿池算力恢复到一个合理的水平；（3）挖矿算法存在漏洞，导致矿工可以通过漏洞提高自己的算力；（4）攻击者可以通过算力租赁的方式使自己的算力超过 51%，这种情况一般对总算力较少的区块链有效；（5）专用硬件的出现导致拥有新硬件的攻击者可以以极低的成本拥有更高的算力；（6）出块间隔等参数设置不合理、发生自私挖矿攻击等，导致诚实矿工的算力大部分浪费在分叉上，攻击者可以以实际低于 51%的算力完成攻击；从攻击者目的来看，一般有三种情况：（1）通过制造双花来使自己收益；（2）通过拒绝其它矿工的出块来增加挖矿收益；（3）竞争币单纯的对对手进行破坏。4.2 DDoS攻击DDOS 的一种攻击形式是恶意节点通过发起大量尘埃交易以使得合法用户支付更高的交易费。2017年 6月，香港交易所 Bitfinex遭受了 DDoS 攻击，导致其临时暂停。同年的11月 11日，比特币交易池中被发现存在大小超过 11.5万笔的未经确认的交易，导致价值7亿美元的交易停滞。2018年 6 月，比特币的交易池再次遭到 4500笔未经确认的垃圾交易攻击，使得交易池大小增加了 45MB，规模增加导致交易费飙升，合法用户被迫支付更高的费用完成交易。在 2019年 11月，比特币交易池达到了 2018年 1月以来的最高水平，交易池大小超过 90MB，垃圾交易量大幅上涨。此外，攻击者还会对网站发动 DDoS攻击，使得系统卡顿、宕机，交易吞吐量减少。2018年 7月，一款运行在以太坊网络的游戏Fomo3D遭受黑客 DDoS攻击，使得 24小时内 Fomo3D 流量减少 38.32%，随后 Fomo3D使用的安全管理网站开启高防验证，用户需等待 5秒才能访问网站，这几乎是该网站的最高级 DDoS 防御策略。2020年 2月，加密货币交易所 Bitfinex和 OKEx均遭受多轮 DDOS攻击，该攻击通过轰炸信息使得平台过载而停止服务，平台的服务被迅速关闭并进行维护。2023 云安全联盟大中华区版权所有64从上述案例可见目前主要有以下几种攻击行为：（1）通过发送大量的垃圾交易使正常交易无法被及时处理，影响系统的活性；（2）通过对特定节点进行 DDoS 攻击，使节点无法正常同步及发送区块，造成网络分片，造成节点的不一致，影响共识的安全性；（3）针对运行于区块链网络上的特定应用进行 DDoS 攻击，导致应用不可用。防范 DDoS攻击可以从设置合理的交易费用、构建健壮的网络、使用更难预测的随机数进行出块节点选择等措施着手。4.3 BGP劫持攻击在过去的几年中，托管采矿池或加密货币交易所的自治系统都遭受了 BGP 劫持攻击。2014年，加拿大的一个恶意互联网服务提供商（ISP）公开了一些主要 ISP 的 BGP 前缀，这些 ISP 包括 Amazon、OVH、Digital Ocean、LeaseWeb和 Alibaba，并且拦截了到矿池的流量，攻击者因此获得了 83,000美元。2018年 4月，攻击者针对以太坊钱包MyEtherW发起了 BGP 攻击，这是一个用于在线交换以太坊令牌的开源 Web应用程序。攻击者控制了以太坊钱包的域名系统，使得用户被重定向到了一个钓鱼网站，当用户将私钥输入到钓鱼网站时，攻击者将设法窃取其私钥。此次攻击持续了几个小时，最终攻击者窃取了 152,000 美元。这类攻击的漏洞一般来自于底层网络服务提供商，选择可信的网络服务提供商是解决该类攻击的关键。5 共识算法安全的最佳实践对于实际部署的区块链系统，特别是基于开源区块链平台的区块链应用系统，共识算法通常是以一个可选模块的方式实现的，因此本节主要提供共识算法的具体实现的最佳实践，即区块链应用如何选择、评估、整合、使用共识算法实现，以及如何进行参数设置等等，从实际考虑，最佳实践围绕主流的区块链平台和典型的行业应用展开。5.1 超级账本的共识算法安全最佳实践超级账本（Hyperledger）是一个旨在推动区块链跨行业应用的开源项目，提供企业级的开源分布式账本框架和代码库。超级账本对传统区块链模型进行了革新，其中包括管理参与者的访问许可权，也就是超级账本是有权限的共享账本，为身份识别、审核及隐私提供了一个安全、健康的模型。2023 云安全联盟大中华区版权所有65Hyperledger Fabric是超级账本项目下正在孵化的一个项目，是分布式账本平台的实现。该平台利用熟悉和成熟的技术来运行智能合约，并且设计为模块化结构，允许组件如共识算法和成员服务模块插入即用。本节主要对 Hyperledger Fabric的共识算法实践进行说明。Hyperledger Fabric中使用了基于 Zookeeper的 Apache Kafka共识算法，该共识算法是Fabric1.0版本中提供的共识算法之一，之所以将 0.6版本中的 PBFT暂时取消，一是因为交易性能达不到要求，二是因为 Fabric面向的联盟链环境中，所有节点都有准入控制，拜占庭容错的需求不是很强烈，反而是并发性能更重要。Fabric中的共识算法被分解为三个阶段：（1）背书阶段：在可选择的节点上模拟交易并收集状态变化信息。客户端应用程序将构造一个交易提案来调用链码(chaincode)中的函数，该函数依次对账本状态进行读和/或写操作，然后根据背书策略将其发送给指定的背书节点。背书节点接收到交易提案后首先会验证提交者是否有权调用通道上的交易。之后背书节点执行链码，链码可以访问背书节点当前的账本状态，进行读取和写入，但是写入只是模拟写入，修改的是私有事务工作区，而不会记录到账本中。执行完成后背书节点调用 ESCC(Endorsement System Chaincode)对执行结果进行签名，然后响应给客户端应用程序。最后，客户端检查提案响应以验证其是否带有背书节点的签名。客户端会从不同的节点那里收集足够多的提案响应，以验证背书是否相同。由于每个节点可能在区块链的不同高度执行交易，因此提案响应可能会不同。在这种情况下，客户端必须将提案交给其他背书节点，以获得足够多相同的提案响应。（2）排序阶段：接受提交的被认可的交易并进行排序，确保交易顺序的一致性。排序阶段通过排序服务(Ordering Service)提供的接口接受已经背书的交易，然后根据共识算法中的配置（如指定的配置信息中定义的时间限制或指定允许的交易数量），确保交易顺序和数量，然后将交易打包到区块中进行广播。排序服务可以以不同的方式实现，开发和测试阶段可以使用集中式排序服务。为了保证交易的机密性，交易服务不能看到交易中的具体内容，也就是交易内容可以使用哈希散列或加密方式去处理。（3）验证阶段：获取有序块并验证其结果的正确性，包括检查背书策略和重复提交攻击。通道上的所有节点（包括背书节点和提交节点）都从网络中接收数据块。节点首先验证签名，之后每一个块中的所有交易都要通过 VSCC验证，再通过 MVCC 验证。VSCC（Validation System Chaincode）验证：验证系统链码（VSCC）会根据为链码指定的背书策略评估交易中的背书，如果不符合背书政策，则该交易被标记为无效。2023 云安全联盟大中华区版权所有66MVCC（Multi-Version Concurrency Control）验证：该验证用于确保交易在背书阶段读取的多版本密钥要与提交阶段中本地的当前状态相同，类似于为了进行并发控制而进行的读写冲突检查，并且块中的所有有效交易要按顺序执行。如果读取的版本不匹配，表示之前的交易修改了读取的数据，则该交易被标记为无效。潜在的验证失败主要分为两种：（1）语法错误：如无效输入、未验证的签名、重复交易等，此类交易要被丢弃；（2）逻辑错误：此类错误较为复杂，应该定义策略决定是继续执行还是终止。Fabric是用 Go语言编写的，并使用 gRPC 框架在客户端、节点之间通信。Fabric一般会配置如下模块：（1）背书政策：背书政策主要包括在交易请求提交给订购者前，需要执行多少次交易并且签名，以便交易通过 VSCC验证。交易背书的 VSCC 验证会根据收集到的背书评估背书政策，并检查可满足性，背书政策的复杂性将影响资源以及收集和评估它的时间。（2）通道：通道将交易彼此隔离，提交给不同渠道的交易彼此独立地进行排序、交付和处理。通道为系统中交易处理的各个方面带来了固有的并行性。Fabric中的每个通道都形成一个逻辑区块链，通道的配置在特殊块中的元数据中进行维护，每个配置块都包含完整的通道配置。（3）Gossip协议：由于大多数共识算法（如 CFT和 BFT 共识机制）都受带宽限制，因此排序阶段的吞吐量受其节点的网络容量的限制，共识协议将无法通过添加更多节点达成更广泛的共识，反而共识范围会缩小，吞吐量会下降。但是在 Kafka 协议中，排序阶段和验证阶段是分离的，因此可以在排序阶段之后将执行结果更为有效地广播给所有节点以进行验证，这是 Gossip协议解决的目标之一。除以之外，对新加入网络的节点以及长时间断开网络连接的节点进行状态转移，这也是 Gossip协议的目标。Gossip协议实现基于gRPC，并且使用具有相互认证的 TLS，这使得节点可以将 TLS 凭证绑定到远程节点上。Gossip协议维护网络中所有节点的实时信息，节点可以在网络中断后重新连接到该信息。（4）排序服务(ordering service)：排序服务用于管理多个通道，并提供如下服务：原子广播，用于建立交易顺序；当配置更新交易被广播时修改通道配置；访问控制，对某些交易广播和块接受进行限制。排序服务由链上的创世块完成。5.2 以太坊共识算法安全最佳实践比特币是最早的 PoW共识算法的实践，但随着比特币的发展，市场是逐渐出现了专业矿机专门针对哈希算法、散热、能耗进行优化，这脱离了比特币网络节点运行在普通计 2023 云安全联盟大中华区版权所有67算机中公平参与挖矿的初衷，并且会造成节点中心化，还可能带来 51%攻击。因此，以太坊中改进了 PoW算法。以太坊早期起草的共识算法中使用的是 Dagger-Hashimoto算法，但是 Dagger-Hashimoto算法容易受到共享内存硬件加速的影响，所以最后对 Dagger-Hashimoto算法进行改进得到了 Ethash算法，是 Ethereum1.0中使用的共识算法，在Ethereum2.0中计划使用 PoS 共识算法。Ethash算法增加了对内存的需求，即在进行挖矿时，需要占用大量的内存空间，这是 ASIC 矿机不具备的，因此将挖矿算法从 CPU密集型转为了 IO 密集型。传统的 PoW算法仅仅是不断尝试 nonce，将该 nonce与难度阈值进行比较，而以太坊的 Ethash算法中求解 nonce仅仅是第一步，还需要利用内存进行一些混合运算，然后将该值与阈值进行比较。算法首先需要一些数据集，数据集生成方式如下：（1）存在一个种子（Seed），该种子与区块高度有关；（2）根据种子计算出 16MB的伪随机缓存 cache，由种子计算出第一个数，之后的每个数都由前一个数取哈希得到，轻节点存储该 cache。（3）根据 cache生成 1GB 的 dataset（DAG），dataset 中每一项数据都由 cache中的数据参与生成，循环迭代 256次，全节点会存储 cache和 dataset。矿工在挖矿时，首先尝试随机数 nonce，在 DAG 中，利用区块头部和 nonce计算出一个 DAG中的初始位置 A，然后读取 A和 A相邻位置的元素 A，再通过 A 和 A计算出另外两个位置 B和 B，以此类推总共迭代 64次，总共取出 128 个数，将其计算得出的哈希与目标阈值比较，若满足条件则挖矿成功，否则重新尝试 nonce。Cache和 dataset中的数据并非不变，大概每隔 30000个区块就会重新计算一遍。而cache的大小 16MB和 dataset的大小 1GB每年也会增大一点。这里选择 16MB 的 cache大小是因为若选取较小的缓存，则太容易继续使用 ASIC 矿机进行挖矿，而 16MB需要比较高的缓存读取带宽。而更大的缓存会使得算法较难而轻节点客户端无法进行区块校验。选择 1GB的 dataset是为了要求内存级别超过大多数专用内存和缓存的大小，但是普通计算机还能使用。每隔 30000块重新计算一遍是因为间隔太大会使得内存不经常更新而仅仅是经常读取，而间隔太小又会使算力较小的机器要花大量时间在更新数据集的固定成本上。以太坊的共识算法是基于改进后的 GHOST 协议（Greedy Heaviest Observe Subtree），GHOST 协议是为了解决以太坊中出块时间过快所导致的安全性问题。以太坊中出块时间为 15秒，而比特币是 10分钟，出块时间过快会导致暂时性分叉过多，如果只用普通的PoW算法，那么假如有多个矿工同时挖出区块，算力大的矿池通常地理位置较优越，其网 2023 云安全联盟大中华区版权所有68络与更多的节点相连，它发布的区块能更快地在网络中传播，成为主链的可能性也越大。这对算力小的节点很不公平，并且不利于算力小的节点达成共识，因此以太坊中引入了GHOST 协议。GHOST协议就是在区块链中 7 代及其以内的叔父区块均可以得到奖励，而矿工若包含一个叔父区块也可以得到除了出块奖励额外的奖励。因此引入 GHOST 协议可以鼓励矿工挖矿，不会因为算力小而打消矿工积极性，并且解决了分叉过多难以达成共识的情况。以太坊中的每个节点都在以太坊虚拟机（EVM）上运行，EVM可以执行用以太坊编程语言 Solidity编写好的复杂代码，Solidity是一种类 JavaScript 的语言。使用 EVM跨以太网网络进行并行计算会很慢并且成本较高，因此让每个节点都自己运行 EVM可以在整个区块链中保持共识。以太坊共有 4个阶段，即前沿、家园、大都会和宁静，前三个阶段采用的都是 PoW共识机制，而在第四阶段采用的是 PoS共识机制，名为 Casper。PoS旨在解决 PoW的缺点：能源消耗过大；鼓励矿工投资专门的硬件，违背了去中心化的理念；存在自私挖矿等攻击。PoS可以被描述为“虚拟挖矿”，矿工购买的是 ETH 而不再是硬件和电力，共识机制根据矿工持有的代币数量成比例地分配投票权，而不是算力。因为不再用算力进行挖矿，因此可以说挖矿几乎“不用付出任何代价”，那么矿工很可能会朝着多个方向同时挖矿以增加其收益，这样会不利于达成共识。因此 Casper是要求矿工必须锁定他们的一些币作为保证金。当他们发现一个可以被加到链上的区块时，就会下赌注验证。如果区块成功上链，验证者可以得到相应比例的奖励。但是当验证者试图做一些恶意行为时，他们也会受到相应的惩罚。这样可以解决账本分叉的问题。2023 云安全联盟大中华区版权所有69参考文献1Fischer M J,Lynch N A,Paterson M S.Impossibility of distributed consensus with one faultyprocessJ.Journal of the ACM(JACM),1985,32(2):374-382.2Gilbert S,Lynch N.Brewers conjecture and the feasibility of consistent,available,partition-tolerant web servicesJ.Acm Sigact News,2002,33(2):51-59.3Ben-Or M.Another advantage of free choice(Extended Abstract)Completely asynchronousagreement protocolsC/Proceedings of the second annual ACM symposium on Principles ofdistributed computing.1983:27-30.4Dwork C,Lynch N,Stockmeyer L.Consensus in the presence of partial synchronyJ.Journal ofthe ACM(JACM),1988,35(2):288-323.5 Leslie Lamport,Robert E.Shostak,and Marshall C.Pease.The Byzantine Generals Problem.ACM Trans.Program.Lang.Syst.,4(3):382401,1982.6 Lamport L.The part-time parliamentM/Concurrency:the Works of Leslie Lamport.2019:277-317.7 Ongaro D,Ousterhout J.The raft consensus algorithmJ.2015.8 Castro M,Liskov B.Practical Byzantine fault toleranceC/OSDI.1999,99(1999):173-186.9 Van Renesse R,Schneider F B.Chain Replication for Supporting High Throughput andAvailabilityC/OSDI.2004,4(91104).10 Guerraoui R,Knezevic N,Quema V,et al.Stretching bftR.2010.11 zsu M T,Valduriez P.Principles of distributed database systemsM.Englewood Cliffs:Prentice Hall,1999.12 Abd-El-Malek M,Ganger G R,Goodson G R,et al.Fault-scalable Byzantine fault-tolerantservicesJ.ACM SIGOPS Operating Systems Review,2005,39(5):59-74.13 Cowling J,Myers D,Liskov B,et al.HQ replication:A hybrid quorum protocol for Byzantinefault toleranceC/Proceedings of the 7th symposium on Operating systems design andimplementation.2006:177-190.14 Guerraoui R,Kneevi N,Quma V,et al.The next 700 BFT protocolsC/Proceedings of the5th European conference on Computer systems.2010:363-376.15 Kotla R,Alvisi L,Dahlin M,et al.Zyzzyva:speculative byzantine faulttoleranceC/Proceedings of twenty-first ACM SIGOPS symposium on Operating systemsprinciples.2007:45-58.16 Abraham I,Gueta G,Malkhi D,et al.Revisiting fast practical byzantine fault toleranceJ.arXivpreprint arXiv:1712.01367,2017.17 Gueta G G,Abraham I,Grossman S,et al.SBFT:a scalable and decentralized trustinfrastructureC/2019 49th Annual IEEE/IFIP international conference on dependable systemsand networks(DSN).IEEE,2019:568-580.2023 云安全联盟大中华区版权所有7018 Singh A,Fonseca P,Kuznetsov P,et al.Zeno:Eventually Consistent Byzantine-FaultToleranceC/NSDI.2009,9:169-184.19 through Byzantine lockingC/2010 IEEE/IFIP International Conference on Dependable Systems&Networks(DSN).IEEE,2010:363-372.20 A.Clement,E.Wong,L.Alvisi,M.Dahlin,and M.Marchetti,“Making Byzantine Fault TolerantSystems Tolerate Byzantine Faults,”Symp.A Q.J.Mod.Foreign Lit.,2009.21 Y.Amir,B.Coan,J.Kirsch,and J.Lane,“Prime:Byzantine replication under attack,”IEEETrans.Dependable Secur.Comput.,2011.22 G.S.Veronese,M.Correia,A.N.Bessani,and L.C.Lung,“Spin ones wheels?Byzantine faulttolerance with a spinning primary,”in Proceedings of the IEEE Symposium on ReliableDistributed Systems,2009.23 P.L.Aublin,S.Ben Mokhtar,and V.Quema,“RBFT:Redundant byzantine fault tolerance,”inProceedings International Conference on Distributed Computing Systems,2013.24 Pass R,Shi E.The sleepy model of consensusC/International Conference on the Theory andApplication of Cryptology and Information Security.Springer,Cham,2017:380-409.25 Baird L.The swirlds hashgraph consensus algorithm:Fair,fast,byzantine fault toleranceJ.Swirlds,Inc.Technical Report SWIRLDS-TR-2016,2016,1.26 Satoshi,Nakamoto.Bitcoin:A peer-to-peer electronic cash system.Consulted 1.2012(2008):28.27Dwork C,Naor M.Pricing via processing or combatting junk mailC/Annual InternationalCryptology Conference.Springer,Berlin,Heidelberg,1992:139-147.28Jakobsson M,Juels A.Proofs of work and bread pudding protocolsM/Secure informationnetworks.Springer,Boston,MA,1999:258-272.29Back A.Hashcash-a denial of service counter-measureJ.2002.30Sompolinsky Y,Zohar A.Secure high-rate transaction processing in bitcoinC/InternationalConference on Financial Cryptography and Data Security.Springer,Berlin,Heidelberg,2015:507-527.31Eyal I,Gencer A E,Sirer E G,et al.Bitcoin-ng:A scalable blockchain protocolC/13thUSENIX symposium on networked systems design and implementation(NSDI 16).2016:45-59.32Pass R,Shi E.Fruitchains:A fair blockchainC/Proceedings of the ACM Symposium onPrinciples of Distributed Computing.2017:315-324.33Sompolinsky Y,Lewenberg Y,Zohar A.SPECTRE:A Fast and Scalable CryptocurrencyProtocolJ.IACR Cryptol.ePrint Arch.,2016,2016:1159.34Li C,Li P,Zhou D,et al.Scaling nakamoto consensus to thousands of transactions per secondJ.arXiv preprint arXiv:1805.03870,2018.2023 云安全联盟大中华区版权所有7135Zhang R,Preneel B.Lay down the common metrics:Evaluating proof-of-work consensusprotocols securityC/2019 IEEE Symposium on Security and Privacy(SP).IEEE,2019:175-192.36Proof of stake Online,available:https:/en.bitcoin.it/wiki/Proof of Stake,April 11,2018.37King S,Nadal S.Ppcoin:Peer-to-peer crypto-currency with proof-of-stakeJ.self-published paper,August,2012,19:1.38Buterin V,Griffith V.Casper the friendly finality gadgetJ.arXiv preprint arXiv:1710.09437,2017.39Bentov I,Pass R,Shi E.Snow White:Provably Secure Proofs of StakeJ.IACR Cryptol.ePrintArch.,2016,2016:919.40Kiayias A,Russell A,David B,et al.Ouroboros:A provably secure proof-of-stake blockchainprotocolC/Annual International Cryptology Conference.Springer,Cham,2017:357-388.41David B,Gai P,Kiayias A,et al.Ouroboros praos:An adaptively-secure,semi-synchronousproof-of-stake blockchainC/Annual International Conference on the Theory and Applications ofCryptographic Techniques.Springer,Cham,2018:66-98.42Badertscher C,Gai P,Kiayias A,et al.Ouroboros genesis:Composable proof-of-stakeblockchains with dynamic availabilityC/Proceedings of the 2018 ACM SIGSAC Conference onComputer and Communications Security.2018:913-930.43Kerber T,Kiayias A,Kohlweiss M,et al.Ouroboros crypsinous:Privacy-preserving proof-of-stakeC/2019 IEEE Symposium on Security and Privacy(SP).IEEE,2019:157-174.44Garay J,Kiayias A,Leonardos N.The bitcoin backbone protocol:Analysis andapplicationsC/Annual International Conference on the Theory and Applications ofCryptographic Techniques.Springer,Berlin,Heidelberg,2015:281-310.45Miller A,Juels A,Shi E,et al.Permacoin:Repurposing bitcoin work for datapreservationC/2014 IEEE Symposium on Security and Privacy.IEEE,2014:475-490.46Park S,Pietrzak K,Kwon A,et al.Spacemint:A Cryptocurrency Based on Proofs of SpaceJ.IACR Cryptol.ePrint Arch.,2015,2015:528.47Cohen B,Pietrzak K.The chia network blockchainJ.2019.48Benet J,Greco N.Filecoin:A decentralized storage networkJ.Protoc.Labs,2018:1-36.49Zhang F,Eyal I,Escriva R,et al.REM:Resource-efficient mining for blockchainsC/26thUSENIX Security Symposium(USENIX Security 17).2017:1427-1444.50Decker C,Seidel J,Wattenhofer R.Bitcoin meets strong consistencyC/Proceedings of the 17thInternational Conference on Distributed Computing and Networking.2016:1-10.51Kogias E K,Jovanovic P,Gailly N,et al.Enhancing bitcoin security and performance with strongconsistency via collective signingC/25th usenix security symposium(usenix security 16).2016:279-296.52Abraham I,Malkhi D,Nayak K,et al.Solida:A blockchain protocol based on reconfigurablebyzantine consensusJ.arXiv preprint arXiv:1612.02916,2016.2023 云安全联盟大中华区版权所有7253Pass R,Shi E.Hybrid consensus:Efficient consensus in the permissionless modelC/31stInternational Symposium on Distributed Computing(DISC 2017).Schloss Dagstuhl-Leibniz-Zentrum fuer Informatik,2017.54Pass R,Shi E.Thunderella:Blockchains with optimistic instant confirmationC/AnnualInternational Conference on the Theory and Applications of Cryptographic Techniques.Springer,Cham,2018:3-33.55Gilad Y,Hemo R,Micali S,et al.Algorand:Scaling byzantine agreements forcryptocurrenciesC/Proceedings of the 26th Symposium on Operating Systems Principles.2017:51-68.56Luu L,Narayanan V,Zheng C,et al.A secure sharding protocol for openblockchainsC/Proceedings of the 2016 ACM SIGSAC Conference on Computer andCommunications Security.2016:17-30.57Kokoris-Kogias E,Jovanovic P,Gasser L,et al.Omniledger:A secure,scale-out,decentralizedledger via shardingC/2018 IEEE Symposium on Security and Privacy(SP).IEEE,2018:583-598.58Schindler P,Judmayer A,Stifter N,et al.Hydrand:Practical continuous distributed randomnessJ.2020.59Al-Bassam M,Sonnino A,Bano S,et al.Chainspace:A sharded smart contracts platformJ.arXivpreprint arXiv:1708.03778,2017.60Zamani M,Movahedi M,Raykova M.Rapidchain:Scaling blockchain via fullshardingC/Proceedings of the 2018 ACM SIGSAC Conference on Computer andCommunications Security.2018:931-948.61Miller A,Xia Y,Croman K,et al.The honey badger of BFT protocolsC/Proceedings of the2016 ACM SIGSAC Conference on Computer and Communications Security.2016:31-42.62Yin M,Malkhi D,Reiter M K,et al.Hotstuff:Bft consensus with linearity andresponsivenessC/Proceedings of the 2019 ACM Symposium on Principles of DistributedComputing.2019:347-356.63Mazieres D.The stellar consensus protocol:A federated model for internet-level consensusJ.Stellar Development Foundation,2015,32.64刘懿中,刘建伟,张宗洋,等.区块链共识机制研究综述J.密码学报,2019,6(4):395-432.65Garay J,Kiayias A.Sok:A consensus taxonomy in the blockchain eraC/Cryptographers Trackat the RSA Conference.Springer,Cham,2020:284-318.66Pritchett D.Base:An acid alternativeJ.Queue,2008,6(3):48-55.67Goldreich O,Micali S,Wigderson A.How to play any mental game,or a completeness theoremfor protocols with honest majorityM/Providing Sound Foundations for Cryptography:On theWork of Shafi Goldwasser and Silvio Micali.2019:307-328.2023 云安全联盟大中华区版权所有7368Canetti R.Universally composable security:A new paradigm for cryptographicprotocolsC/Proceedings 42nd IEEE Symposium on Foundations of Computer Science.IEEE,2001:136-145.69苏婷.UC 安全理论及应用研究D.山东大学,2009.70Garay J,Kiayias A,Leonardos N.The bitcoin backbone protocol with chains of variabledifficultyC/Annual International Cryptology Conference.Springer,Cham,2017:291-323.71Kiayias A,Panagiotakos G.Speed-Security Tradeoffs in Blockchain ProtocolsJ.IACR Cryptol.ePrint Arch.,2015,2015:1019.72Pass R,Seeman L,Shelat A.Analysis of the blockchain protocol in asynchronousnetworksC/Annual International Conference on the Theory and Applications of CryptographicTechniques.Springer,Cham,2017:643-673.73Eyal I,Sirer E G.Majority is not enough:Bitcoin mining is vulnerableC/Internationalconference on financial cryptography and data security.Springer,Berlin,Heidelberg,2014:436-454.74Nayak K,Kumar S,Miller A,et al.Stubborn mining:Generalizing selfish mining and combiningwith an eclipse attackC/2016 IEEE European Symposium on Security and Privacy(EuroS&P).IEEE,2016:305-320.75Carlsten M.The impact of transaction fees on bitcoin mining strategiesD.Princeton University,2016.76Gbel J,Keeler H P,Krzesinski A E,et al.Bitcoin blockchain dynamics:The selfish-minestrategy in the presence of propagation delayJ.Performance Evaluation,2016,104:23-41.77Houy N.The Bitcoin mining gameJ.Available at SSRN 2407834,2014.78Solat S,Potop-Butucaru M.Zeroblock:Preventing selfish mining in bitcoinJ.arXiv preprintarXiv:1605.02435,2016.79Bahack L.Theoretical bitcoin attacks with less than half of the computational power(draft)J.arXiv preprint arXiv:1312.7013,2013.80Bonneau J,Miller A,Clark J,et al.Sok:Research perspectives and challenges for bitcoin andcryptocurrenciesC/2015 IEEE symposium on security and privacy.IEEE,2015:104-121.81Kroll J A,Davey I C,Felten E W.The economics of Bitcoin mining,or Bitcoin in the presence ofadversariesC/Proceedings of WEIS.2013,2013:11.82Miller A,LaViola Jr J J.Anonymous byzantine consensus from moderately-hard puzzles:Amodel for bitcoinJ.University of Central Florida Tech.Report CS-TR-14-01(accessed 5 June2019)https:/ A,Karame G O,Wst K,et al.On the security and performance of proof of workblockchainsC/Proceedings of the 2016 ACM SIGSAC conference on computer andcommunications security.2016:3-16.2023 云安全联盟大中华区版权所有7484Castro M,Liskov B.Practical Byzantine fault tolerance and proactive recoveryJ.ACMTransactions on Computer Systems(TOCS),2002,20(4):398-461.85K.Zheng,Y.Liu,C.Dai,Y.Duan and X.Huang,“Model Checking PBFT Consensus Mechanismin Healthcare Blockchain Network,”in the 9th International Conference on InformationTechnology in Medicine and Education(ITME),Hangzhou,2018,pp.877-881.86H.Sukhwani,J.M.Martnez,X.Chang,K.S.Trivedi and A.Rindos,“Performance Modeling ofPBFT Consensus Process for Permissioned Blockchain Network(Hyperledger Fabric),”in 2017IEEE 36th Symposium on Reliable Distributed Systems(SRDS),Hong Kong,2017,pp.253-255.87R.Halalai,T.A.Henzinger and V.Singh,“Quantitative Evaluation of BFT Protocols,”in the 8thInternational Conference on Quantitative Evaluation of SysTems,Aachen,2011,pp.255-264.

27人已浏览 2023-03-24 74页 5星级

大规模地实现混合云自动化连接云、团队和工作流目录1自动化将云环境连接起来2实现云环境的最大价值3利用红帽 Ansible 自动化平台实现云自动化5您准备好自动化了吗？4开始您的云自动化之旅编排云资源4.1实施云流程4.2管理云环境4.3创建完整的云自动化工作流4.41.02.03.04.05.0自动化将 云环境连接起来在如今的数字化世界，创新和适应能力是取得成功的关键。为提高敏捷性和响应速度，许多企业开始采用云技术。实际上，89%的企业现在实施的是多云策略，80%采用混合云策略1。尽管如此，云环境也会带来新的运维挑战。大多数企业使用各种工具来管理环境，通常会导致不一致和冗余。云环境的规模（即使用中的资源数量）可能接近无限，因此很难管理和了解企业的使用情况和成本。企业通常在他们的云环境中采用基于容器的和云原生技术，要求员工学习新的知识和技能。但是，由于云环境是分布式架构，所以在安全防护、合规和管理工作方面，必须采用全新的方法。IT 自动化可以帮助您实现云投资价值的最大化，为数字计划和创新提供支持。据调查，80%的企业高管表示采用 IT 自动化对所在企业未来的成功“极其重要”或“非常重要”2。云自动化即“将 IT 自动化应用于云技术”，可以帮助您克服因为迁移到云而引起的运维挑战，并大规模地管理这些环境。云自动化可覆盖到从资源置备和停用到完整生命周期工作流的方方面面，包括管理、发布工程以及网络和安全防护运维。1 Flexera。“Flexera 2022 年云状态报告”，2022 年 3 月。2 哈佛商业评论动向调查，红帽赞助。“引领 IT 自动化”，2022 年 1 月。IT 自动化越来越重要80%的企业高管表示采用 IT 自动化对所在企业未来的成功“极其重要”或“非常重要”2。68%的企业高管同意过去 12 个月，所在企业的 IT 自动化已经从“锦上添花”转变为“必不可少”2。68%的企业高管表示 IT 领导者应该制定和共享愿景，展示 IT 自动化如何使企业和 IT 职员受益2。11.02.03.04.05.0统一云域大多数企业采用的是混合的基础架构和环境，包括公共云、私有云和云原生环境。云自动化可以将这些域及其运维团队连接起来，促进协作，让团队在跨域工作时具备更高的自足能力。了解云环境和技术云是将网络中的可扩展资源抽象、汇集起来并予以共享的环境。私有云是专供单一终端用户组或企业使用的云环境。它们通常归该企业所有和管理，并在防火墙内运维。公共云是通过第三方公司拥有和管理的硬件所开发的虚拟资源池，如 Amazon Web Services（AWS）、Google Cloud、IBM 和微软。这些资源通过自助服务接口自动置备和分配到多个客户端。混合云是一种 IT 基础架构，能在两个或更多环境之间进行某种程度的工作负载移植、编排和管理，这些环境包括私有云、公共云、虚拟化和裸机环境。多云是一种云架构，由来自多个私有或公共云供应商的多个云服务组成。云环境通常与两种技术有关：云原生架构使用独立的小型松散耦合服务集合来交付专为云环境设计的应用。Linux 容器能够让您对应用及其整个运行时环境（包括全部所需文件）一起进行打包或隔离。公共云云自动化可以帮助您处理这些环境的庞大规模，以提高跨多个云的一致性、可见性和控制能力。私有云云自动化可以帮助您通过现场或自托管云基础架构，交付类似公共云的服务以及自助服务功能。云原生应用云自动化可以帮助您更高效地跨混合环境和多云环境，管理整个云原生应用生命周期。21.02.03.04.05.01.02.03.04.05.0实现云环境的 最大价值自动化是一股统一人员、流程和技术的力量IT 自动化融合平台、运维和企业文化来支持协作、创新和数字成功。技术和平台 将传统的、现有的和云原生 IT 环境连接起来。流程和策略 提高整个企业的运维速度、准确性和一致性。自动实施策略以确保合规性。人员和团队 利用统一的人类可读自动化语言和平台进行协作和共享。降低团队的运维负担，提高用户的自足能力，让员工能够专注于更有趣的任务。在整个企业内实现自动化自动化可以将人员、流程和技术结合起来，提高企业的敏捷性、创新能力和价值。阅读自动化企业电子书，以了解如何在整个企业内采用自动化。自动化可以通过简化的编排和工作流，帮助您实施整个混合和多云环境（从本地数据中心到公共云基础架构）。通过云自动化，您可以记录、评估和编写任务，使它们能够可靠且可重复地融入到工作流中，实现可预测的业务结果。云自动化还可以帮助您跨所有 IT 和云域创建一致的运维框架。将整个混合环境自动化可以帮助企业内的所有人取得成功：简化和加快运维。提升企业敏捷性和响应速度。提高生产力和效率。改善安全防护和合规性 提高一致性和可用性。减少错误和配置不当。专注于高价值的战略性计划。32.01.03.04.05.0需要什么才能实现云的自动化尽管自动化平台、自动化工具和基础架构即代码（IaC）非常相似，但它们的特性迥异，而这可能恰恰反映了在企业范围内有效采用自动化与无组织、分散化地使用自动化之间的差异。自动化平台自动化平台为大规模编排完整工作流提供统一的基础。您可以借助平台高效地管理和共享自动化内容，将整个企业内的资源、基础架构、环境和团队连接起来。自动化工具自动化工具仅对单个和点自动化有效。它们不提供企业级自动化或工作流编排所需的连接和管理功能。IaC 和置备工具IaC 和云置备工具可简化特定资源的置备和停用，但不能自动化完整的工作流或连接各种资源。任务自动化还是工作流自动化？有效的云管理要求您同时自动化单个任务和整个工作流。任务自动化可以简化一个人在一种基础架构资源上执行的一项功能。它会在员工操作层面上加快运维速度，并减少执行特定工作任务所需的时间。工作流自动化则是将多项任务整合到一个进程中。它会在流程层面上加快运维速度，并自动从一项任务转到下一项任务，从而减少了由于团队间交接而造成的等待时间。此外，工作流自动化还方便了自助服务的运维，同时又保留了 IT 对资源的控制。42.01.03.04.05.0有效的云自动化要求对工作流进行编排统一的自动化平台对于有效的云工作流编排至关重要。它提供整合的基础，让企业中的所有人都能参与其中，并按照一致的方式进行自动化。统一的自动化平台还提供在整个企业内，高效协作和共享自动化资产、最佳实践和经验的方法。尽管每个团队可以针对各自的领域创建自动化，但所有这些领域都可以接入更大的自动化工作流，遵循统一的策略。市面上有许多自动化解决方案，但并非所有方案都具备您的企业创建全面的编排云工作流所需的功能。寻找具备以下特征的自动化平台：完整的企业级支持。与行业领先的合作伙伴产品集成。所有角色均可轻松简单地采用。跨多个环境的大规模可扩展性。无代理部署。红帽 Ansible 自动化平台能助您实现上述所有目标，并具备其他众多优势，使您可以实施有效的云自动化和企业级自动化。云自动化的内容和位置关于云自动化，对什么进行自动化和在哪里运行自动化平台是两件不同的事。本电子书主要介绍您可以在云端自动化的内容：资源、应用、工具、流程和工作流。但同时，托管和运行自动化平台的位置同样重要。您可以根据企业需求，选择在云环境中或私有数据中心中运行平台。例如，如果您的许多 IT 运维和应用已在云中运行，您可能会选择在云中托管您的自动化平台，这样更接近目标，方便应用现有的云运维。如果您计划对大量物理位置较为分散的资源和应用进行自动化，您可能也会在云中托管平台，事实上，您的公共云区域可能比您的数据中心更接近这些端点。或者，如果您从私有数据中心管理您的 IT 基础架构，您可能会选择在本地部署自动化平台。对于大多数企业，如何选择最终取决于目前拥有的可用资源以及哪种选择最方便入手。5 51.02.03.04.05.0利用红帽 Ansible 自动化平台 实现云自动化红帽 Ansible 自动化平台为构建和运维大规模自动化奠定了基础，提供了各种工具和功能，让您能够创建完整的云自动化工作流来支持您的业务目标。将简单、易读的自动化语言与可信、可组合的执行环境相结合，同时融合了以安全为重的共享和协作功能。多个域团队可以使用 Ansible 自动化平台，从而在整个企业范围内创建、扩展和部署自动化。Ansible 自动化平台使您可以自动化和编排混合云环境的所有方面，从云资源和服务到操作系统、应用和安全等等。该平台用通用语言将您现有的自动化、配置和云工具以及流程连接起来。因此，您可以跨所有云域、流程和角色创建一致的运维框架，并使自动化更接近目标端点。Ansible 自动化平台还是一个无代理平台，您可以轻松地实现组件自动化，而无需在组件上安装自动化软件。最后，监控和日志记录功能可帮助您了解如何在整个企业内使用自动化并进行管理。简化自动化部署管理您可以直接从 Microsoft Azure 和 AWS 市场部署 Ansible 自动化平台。这些产品由红帽提供支持，集成原生云服务和认证的云内容，且计入您的云承诺支出协议。了解更多信息：Microsoft Azure 产品 AWS 产品迅速开始您的云自动化之旅Ansible 混合云自动化是一组经认证的内容集，可跨多个公共云和服务，简化和实施云运维。它为云管理员和应用开发人员提供运维框架和工具，供他们自动化云运维，以代码的形式管理云资源；同时，它还将 IT 部门内的团队连接起来，为数字化转型提供支持。1.02.03.04.05.063.01.02.04.05.07编排 自动化=业务成果Ansible 自动化平台将工作流编排与资源自动化相结合，交付真正的业务成果。通过编排完整的云工作流来交付可预测的业务结果。通过连接所有基础架构，改进一致性和可移植性。将所有工具与自动化编排集成起来，简化流程。以不同的方式评估、编写、组合任务，实施更大规模的云流程。通过增强协作和共享，跨团队和领域实现创新。通过自助服务自动化减少人工交接，提高生产力。自动化不仅局限于配置管理Ansible 自动化平台使您可以大规模构建和执行 IT 自动化。阅读以下电子书，进一步了解 IT 基础架构、网络、安全防护运维和云原生技术和环境：自动化基础架构工作流 惠及所有人的网络自动化 简化您的安全防护运维中心 将您的混合云环境与 IT 自动化连接起来3.01.02.04.05.0借助 Ansible 自动化平台连接和编排所有云、平台和工具Ansible 自动化平台可以跨云、平台和工具运行，因此您可以编排全面的工作流，融合您目前使用和未来计划采用的各类组件及技术。以下显示了一些常见组件的示例，单击徽标进一步了解与 Ansible 自动化平台的集成。Ansible 自动化平台 私有云 公共云 存储 网络 边缘 安全工具 操作平台 云原生平台 IT 服务管理（ITSM）81.02.03.04.05.0开始您的 云自动化之旅采用云自动化是一趟旅程，而不是孤注一掷的提议。您可以从一个用例入手，按照适合企业的节奏逐渐扩展。Ansible 自动化平台允许您编排、实施和管理完整的混合云工作流，从置备和部署，到 Day 2 运维和管理，再到灾难恢复和资源停用。本章概括介绍整个资源生命周期内的常见云自动化用例。我们将这些用例分解成多个生命周期阶段，即编排、实施和管理，以表明如何在整个生命周期中使用自动化。尽管如此，每个用例的自动化用时和投入的精力都各不相同。成功的自动化采用旅程通常都是循序渐进的：团队从小入手，展示价值，以迭代方式扩大范围，开展更加综合复杂的工作。这些工作可以分成三个阶段：评估自动化工作为展现本章讨论的每种自动化用例涉及的复杂程度，我们用一个符号来标记每种用例，代表自动化旅程中的相关阶段：机遇系统化融入 机遇。这个阶段侧重于简化任务，让云团队取得能快速实现成功、抓住机遇。这个阶段的用例可展示 Ansible 自动化平台的作用，并在企业内获得更多人对于自动化的支持。系统化。这个阶段侧重于集中流程，并系统地、有计划地应用自动化，从而高效地大规模管理云资源。融入。这个阶段需要创建和编排完整的工作流，通过决策自动化、集成基础架构和连接企业内的团队，为实现业务成果提供支持。94.01.02.03.05.0混合云自动化部署和停用云迁移基础架构编排基础架构优化云合规性业务连续性云运维基础架构可见性自动化故障诊断实施云流程编排云资源管理云环境资源生命周期内的常见自动化用例本章内容：4.1 编排云资源4.2 实施云流程4.3 管理云环境4.4 创建完整的云自动化工作流104.11.02.03.05.0编排云资源是许多云自动化工作流的第一步。这些用例包括设置您的企业需要运维的环境、系统、应用、网络和存储。3 IDC 白皮书，红帽赞助。“红帽 Ansible 自动化平台的商业价值”，2021 年 10 月。文档编号#US47989320。编排云资源云迁移将工作负载迁移到需要的地方，从本地迁移到公共云，在公共云之间迁移，或者从传统的计算架构迁移到云原生应用平台。简化企业内的云采用。简化工作负载向云原生应用平台的迁移。使用单一平台编排原有应用和云原生应用。Ansible 自动化平台可以配合可变和不可变基础架构使用，包括传统的、虚拟化、容器化和云原生基础架构，因此，您可以使用最合适贵企业的迁移策略，如经典的备份和恢复、扫描和重建或 IaC。同时，工作流可视化程序使您能高效地编排迁移。资源部署和停用置备、配置和停用云实例。快速创建可随时使用的云部署。构建服务目录，使用户 能快速访问预先批准的 资源。通过自动策略实施，管理实例的创建和停用。Ansible 自动化平台集成主流云置备、IaC 和带外置备工具，因此，您可以跨多个云提供商配置、部署和停用整个环境中的资源。74%部署新服务器资源的速度提升幅度3基础架构编排连接和协调整个企业的团队和基础架构。将云上和云外基础架构集成到一个统一的框架下。编排整个业务工作流和隔离的技术域。跨所有基础架构，应用一致的合规措施。Ansible 自动化平台与庞大的合作伙伴生态系统集成，因此您几乎可以编排云环境的所有方面。许多合作伙伴还通过自动化中心提供经认证和签名的内容，允许您更高效敏捷地将他们的产品实现自动化。30%IT 基础架构管理效率提升幅度3114.21.02.03.05.0Day 1 和 Day 2 运维对于长期实现业务成果至关重要。这些用例侧重于保持云环境流畅运行的日常流程。基础架构可见性收集关于基础架构和资源的信息，以了解您掌握的资源和最新动态。收集只读信息。通过动态清单和报告，获取对云资产的可见性，包括虚拟实例、容器、存储、网络、防火墙、身份管理等。用您选择的工具访问收集的数据。为进一步的自动化工作创建清单。Ansible 自动化平台包括基于 Web 的直观用户界面，可简化跨本地环境和云环境的运维。您可以创建自定义报告并计划自动化作业，以进一步了解环境的所有方面。云运维简化云环境中的 Day 1-2 活动。从头到尾管理完整的云资源和应用生命周期。修改云资源、主机操作系统和应用。以编程方式自动化地访问所有云提供商的功能。创建可重复使用的 GitOps 工作流和管道，持续维护所有云环境中的资源。Ansible 自动化平台允许您访问经认证的内容，以便实现基础架构、混合云、Windows、Linux、应用部署、安全防护等方面的自动化。因此，您可以做好更充分的准备来管理和自动化整个环境。自动化故障诊断快速响应事件和问题。及时识别发生问题的位置或域，缩短解决问题的平均时间。应用基于角色的访问权限控制（RBAC）来设置限制和策略 将自动化故障诊断流程 集成到您的 ITSM 解决 方案中。通过 ITSM 工单或监控工具，手动启动自动化故障诊断。Ansible 自动化平台包含与一些服务和资源管理系统的原生集成，包括 ServiceNow、Github 和 Gitlab，使您能够在这些工具之间编排响应操作。您还可以通过应用编程接口（API）来集成资源、工具和系统，以创建完整的响应工作流。实施云流程124.31.02.03.05.0管理是云运维中不可或缺的部分。云环境可以快速扩展，所实现的功能将远远超出手动控制功能；而自动化能够帮助您大规模地对各种资源应用和实施策略。这些用例侧重于确保云环境按照您的预期和业务要求运行。4 IDC 白皮书，红帽赞助。“红帽 Ansible 自动化平台的商业价值”，2021 年 10 月。文档编号#US47989320。业务连续性确保云环境始终可用于支持 您的业务。移动和复制云外资源以支持灾难恢复。创建、管理和实施备份 策略。通过按钮和事件驱动自动化，管理中断和故障。迅速为整个灾难恢复站点提供支持。执行日常快照和备份。Ansible 自动化平台的自动化网格组件让您能够大规模编排多样化环境，跨多个公共云提供商，支持业务连续性。基础架构优化自动优化云环境并节省时间和成本。根据策略关闭未使用的 资源。优化云资源规模，以平衡成本、性能和可用性。找回孤立的资源。更准确地了解云的使用情况，从而更合理地规划投资和预算。Ansible 自动化平台使您可以规划工作流，以持续追踪云的使用情况并了解您掌握的资源。掌握这些信息后，您可以创建自动化来优化基础架构。您还可以使用自定义工作流审批来了解变更会对云环境造成哪些影响，而后再将变更应用于生产环境。云端合规性确保您的云环境始终合规。自动实施身份和访问权限管理（IAM）策略以提高安全防护。验证安全防护组和访问控制列表（ACL）。与 IT 服务管理（ITSM）解决方案同步，以改进运维跟踪。Ansible 自动化平台能与可变和不可变基础架构配合使用，跨公共云提供一致的体验。因此，您可以跨多个地区和云更轻松地创建和实施策略。76%计划外停机时间减少418%合规团队生产力提升4管理云环境134.41.02.03.05.014该示例是一个完整的云自动化工作流，展示了如何使用 Ansible 自动化平台和 GitOps 方法来编排云资源和应用生命周期。工作流自动化1.云管理员修改资源定义或 playbook。2.云管理员将修改好的定义或 playbook 提交到中央存储库。3.Ansible 自动化平台中的 Webhook 集成会注意到所做的修改，并启动任何必要的自动化。4.Ansible 自动化平台将云资源重新部署到开发环境。5.云管理员批准自动化生产请求。6.Ansible 自动化平台将云资源部署到生产环境。7.Ansible 自动化平台设置和编排生产部署所需的任何其他云外资源。带外自动化 云运维：Ansible 自动化平台根据需要，执行 Day 1 和 Day 2 运维，包括修改和更新。基础架构优化：Ansible 自动化平台根据需要，优化基础架构和资源。云可见性：Ansible 自动化平台根据需要，保存基础架构快照以用于可见性和洞察目的。Ansible 自动化平台中央存储库部署到开发环境4部署到生产6编排基础架构7批准用于生产5拉取请求2Webhook3云可见性云管理员云基础架构（Dev）云基础架构（Prod）非云基础架构修改数据模型1基础架构优化云运维关键工作流自动化带外自动化云自动化工作流自动化可以帮助您将云环境连接起来，以简化运维和创建完整的工作流。通过将人员、流程和技术连接到一起，红帽 Ansible 自动化平台让您的入云之旅更加轻松。借助统一的自动化框架，您可以大规模编排、实施和管理混合云，创建完整的工作流，跨环境交付业务成果。版权所有 2022 Red Hat,Inc。红帽、红帽 Logo、Ansible 和 OpenShift 是 Red Hat,Inc.或其子公司在美国和其他国家/地区的商标或注册商标。Linux 是 Linus Torvalds 在美国和其他国家/地区的注册商标。F32113_1022_KVM您准备好自动化了吗？敬请访问 IDC 聚焦，了解云自动化如何交付业务价值。

8人已浏览 2023-03-22 17页 5星级

将您的混合云环境与 IT 自动化连接起来2目录1利用自动化实现转型2为混合云环境构建完整的自动化工作流4成功案例5您准备好自动化了吗？3自动化 云：相得益彰连接集群上和集群外的资源3.1创建完整的集群管理工作流3.2跨基础架构部署和管理应用3.3简化灾难恢复和业务连续性3.41.02.03.04.05.0利用自动化 实现转型各行各业的公司和机构都在进行数字化转型，以满足对新服务和创新不断增长的需求。而近些年全球发生的一些事件进一步加速了数字化转型的步伐。86%的企业目前正在实施数字化转型计划1。在全新的数字化世界中，速度和准确性将成为制胜的关键。为保持竞争力，企业必须以更快的速度开发、交付和管理安全至上的应用和 IT 基础架构。IT 运维团队将在支持创新方面发挥重要作用。通过简化服务交付流程，构建合适的平台和基础架构，以开发、测试和部署安全至上的应用，IT 团队可对数字化转型项目的速度和成功产生巨大影响。许多企业采用基于容器的环境来支持云原生应用的开发和部署。尽管如此，这些环境也要依赖外部元素才能运行，如计算硬件、网络、存储系统、外部安全与管理工具。IT 自动化可以帮助您将传统环境和云原生环境连接起来，同时提供您需要的运维速度和准确性。无论您处于数字化转型之旅的哪个阶段，IT 自动化都可以帮助您以更高的敏捷性、效率和信心向前迈进。本电子书探讨将云原生应用平台与 IT 自动化相结合来实现数字化转型的益处。80%的企业高管表示采用 IT 自动化对所在企业未来的成功“极其重要”或“非常重要”2。1 红帽报告。“2022 全球技术展望”，2021 年 11 月。2 哈佛商业评论动向调查，红帽赞助。“引领 IT 自动化”，2022 年 1 月。68%的企业高管同意过去 12 个月，所在企业的 IT 自动化已经从“锦上添花”转变为“必不可少”2。68%的企业高管表示 IT 领导者应该制定和共享愿景，展示 IT 自动化如何使企业和 IT 职员受益2。IT 自动化越来越重要1为混合云环境 构建完整的 自动化工作流自动化是一股统一人员、流程和技术的力量。IT 自动化融合平台、运维和企业文化来支持协作、创新和数字成功。技术和平台 将传统的、现有的和云原生 IT 环境连接起来。流程和策略 提高整个企业的运维速度、准确性和一致性。自动实施策略以确保合规性。人员和团队 利用统一的人类可读自动化语言和平台进行协作和共享。降低团队的总体运维负担，提高用户的自足能力，让员工能够专注于更有趣的任务。红帽为您提供集成平台和工具，通过灵活的自动化，缩小传统 IT 环境与云原生 IT 环境之间的差距。红帽 OpenShift、红帽 Ansible 自动化平台和红帽 Kubernetes 高级集群管理的组合可帮助您构建和自动化真正的混合环境。红帽 OpenShift 提供用于部署容器化应用和微服务的混合云平台。红帽 Ansible 自动化平台为您的整个 IT 环境和企业提供一致的用户友好型自动化。红帽 Kubernetes 高级集群管理为红帽 OpenShift 集群提供批量的生命周期管理、基于策略的治理和健康监测。1.02.03.04.05.0了解整个企业的自动化自动化可以将人员、流程和技术结合起来，提高企业的敏捷性、创新能力和价值。阅读自动化企业电子书，了解您可以如何在整个企业内采用自动化。22.01.03.04.05.0通过集成，这些平台使您能够自动化并高效地管理整个混合 IT 环境，包括传统的基础架构及云原生和容器化资源。如此一来，您就可以更轻松、更快速地采用云原生技术和方法。这种组合也可以使您按照自己的节奏行动，您可以迁移现有应用并进行现代化改造，交付注重安全的新型云原生应用，并循序渐进地调整基础架构和运维。从容起步您可以使用自己最熟悉的产品开始您的自动化之旅。如果您很熟悉红帽 OpenShift 和云原生运维，可以先从红帽高级集群管理的自动化入手；如果您更熟悉红帽 Ansible 自动化平台，可以从这里开始。红帽 Ansible 自动化平台和红帽高级集群管理的集成赋予您更大的灵活性，可以使用任一工具完成许多任务。您可以选择使用红帽 Ansible 自动化平台和/或红帽高级集群管理来管理您的红帽 OpenShift 部署。话虽如此，但它们各自有独特的功能和优势。红帽高级集群管理专为大规模管理多个红帽 OpenShift 集群而设计。红帽 Ansible 自动化平台提供的 IT 自动化覆盖基础架构、应用、网络以及安全防护和管理工具。您可以使用红帽 Ansible 自动化平台执行许多集群管理任务，但您必须自己经常编写自动化来访问 Kubernetes 应用编程接口（API）。如果您使用红帽 Ansible 自动化平台进行自动化，您在采用红帽 OpenShift 和云原生技术时，可以重复使用现有的自动化内容。红帽 Kubernetes 高级集群管理使用内置安全策略从单个控制台控制集群和应用。它通过部署应用、管理多个集群并大规模跨集群实施策略，使红帽 OpenShift 进一步发挥价值。红帽 OpenShift 平台 Plus 中包含红帽高级集群管理，这款组合产品是安全至上的应用交付和创新的不二之选。了解更多关于红帽 OpenShift 平台 Plus 的信息。红帽 Ansible 自动化平台是在整个企业范围内构建和运维自动化的基础。该平台包含了在混合云环境中实现企业级自动化所需的各种工具。红帽 OpenShift 是领先的企业就绪型 Kubernetes 容器平台，专为开放混合云策略构建。提供了一致的应用平台来管理混合云、多云和边缘部署。3详细了解集成。红帽 OpenShift、红帽 Ansible 自动化平台和红帽高级集群管理的组合可带来最大的价值和灵活性。红帽 OpenShift跨混合云基础架构构建、部署和管理基于容器的应用。红帽高级集群管理使用内置安全策略从单一控制台控制集群和应用。红帽 Ansible 自动化平台简化运维，将企业内的人员、流程和平台连接起来。自动化管理平台1.02.03.04.05.0连接自动化工作流红帽 Ansible 自动化平台和红帽高级集群管理的集成带来统一的端到端自动化工作流，使您可以将云原生和传统 IT 环境连接起来。红帽高级集群管理可以调用红帽 Ansible 自动化平台作业来自动化集群外的资源，而红帽 Ansible 自动化平台可以调用 Kubernetes API 和红帽 OpenShift 操作器来执行集群上的任务。您甚至可以使用现有的自动化技能和 Ansible 简单易读的语言创建自己的红帽 OpenShift 操作器。体验实现整个企业自动化的益处自动化整个混合环境可以帮助企业内的所有人取得成功。简化和加快运维。提升企业敏捷性和响应速度。提高生产力和效率。改善安全防护和合规性 提高一致性和可用性。减少错误和配置不当。专注于高价值的战略性计划。4自动化 云：相得益彰红帽 Ansible 自动化平台和红帽 OpenShift 可以帮助您实施完整的端到端自动化工作流，将现有的和云原生基础架构连接起来。阅读以下内容，了解如何结合使用这些产品来为您的云原生之旅保驾护航。本章内容：3.1 连接集群上和集群外资源3.2 创建完整的集群管理工作流3.3 跨基础架构部署和管理应用3.4 简化灾难恢复和业务连续性1.02.03.04.05.053.11.02.04.05.0连接集群上 和集群外的资源大多数企业已经有一些传统的基础架构、工具和资源，它们既不能立即停用，也不能马上清除。红帽 Ansible 自动化平台使您可以将传统的集群外和集群上资源一起自动化，充分利用现有投资，并按照您自己的节奏实现转型。传统的集群外资源包括：网络资源。设置和配置诸如交换机、无线接入点、域名系统（DNS）、负载均衡器和防火墙等资源。公共云和私有云服务。置备和配置您想要在应用中使用的服务，如托管数据库服务、虚拟机监控程序和无服务器功能。软件即服务。与软件即服务（SaaS）工具交互，如 IT 服务管理（ITSM）和票务系统、服务目录和其他托管应用。安全工具。集成和自动化安全防护和合规工具，以用于审计、事件响应和补救等应用。物理基础架构。设置和配置裸机服务器和存储阵列的带外管理和虚拟化设置、固件、基线和其他基本功能。3 IDC 白皮书，红帽赞助。“红帽 Ansible 自动化平台的商业价值”，2021 年 10 月。文档编号#US47989320。自动化不仅局限于配置管理红帽 Ansible 自动化平台使您可以大规模构建和执行 IT 自动化。阅读以下电子书，进一步了解 IT 基础架构、网络和安全运维自动化：自动化基础架构工作流 惠及所有人的网络自动化 简化您的安全防护运维中心使用红帽 Ansible 自动化 平台的企业实现了30%IT 基础架构管理效率提升3。63.11.02.04.05.0跨混合基础架构创建自助服务工作流通过自动化将现有的与云原生的工具和基础架构结合起来，为用户构建便捷的自助服务操作，使他们可以更加自给自足，并提高生产力。例如，您可以将 ServiceNow 等 ITSM 系统集成到工作流中，以部署使用云端数据库的容器化应用的新实例：1.用户向 ITSM 系统提交新实例请求。2.批准后，ITSM 系统将请求发送到红帽 Ansible 自动化平台来运行自动化作业。3.红帽 Ansible 自动化平台会执行所请求的任务，包括通过云提供商初始化数据库，在红帽 OpenShift 中部署和配置容器化应用，创建 DNS 条目，以及自动化作业中定义的其他任务。4.红帽 Ansible 自动化平台会更新 ITSM 系统中的工单，提醒用户应用实例已经就绪，并关闭工单。通过该自动化工作流，用户会收到根据 IT 策略配置的应用实例，并且全程不需要 IT 的人工干预。红帽 Ansible 自动化平台IT 服务管理系统请求的服务红帽 OpenShift73.21.02.04.05.0创建完整的集群 管理工作流部署或更新红帽 OpenShift 集群时，您必须先设置底层基础架构，然后才能运行红帽 OpenShift 安装程序。安装后，还必须完成集群配置来满足企业需求。红帽 Ansible 自动化平台允许您创建端到端集群设置和管理工作流，并且只需一条命令即可启动该工作流。123 4 轻量级目录访问协议准备系统以安装红帽 OpenShift。系统准备工作包括更新和验证固件版本，配置裸机设置，安装集成管理工具，设置电源管理，以及安装操作系统和其他基本软件。您可能还需要配置其他基础架构元素，如云原生存储、静态 IP 地址、存储卷和网络防火墙规则。启动红帽 OpenShift 安装程序。红帽 OpenShift 安装程序会创建集群。执行最终配置任务。安装后的任务包括挂载存储卷，添加证书，以及设置认证以使集群做好使用准备。其他最终配置目标包括：组和命名空间。LDAP4 组同步和 认证。镜像策略。密钥和证书。警报和监控。日志。红帽 OpenShift 数据基础存储。集群管理工具。工作节点时间同步。加密设置。订阅。您还可以更新网络组件、配置管理数据库（CMDB）和 ITSM 系统来反映集群部署状态并支持灵活的扩展。这些项目通常依赖于红帽 Ansible 自动化平台与红帽高级集群管理之间的集成。83.21.02.04.05.0您可以创建类似以上示例的自定义自动化集群管理工作流，也可以使用红帽 Ansible 自动化平台和红帽高级集群管理功能与安装实践的任意组合。借助自动化工作流，可以迅速地重复创建集群，由此，您就可以更加快速、轻松、一致地推出新集群以及向现有集群添加节点。通过完整的集群创建工作流，管理员无需登录集群和执行手动自定义，首次登录时，集群便已经可以使用了。集群和节点设置妥当并添加到管理池中后，您可以直接从红帽高级集群管理进行管理。您还可以使用红帽 Ansible Playbook 完成日常的管理任务，自动解决问题和不合规情况。自动升级集群您还可以使用红帽 Ansible 自动化平台创建集群升级工作流来执行一些前提任务，如备份 etcd 状态，融入红帽 OpenShift 操作器来加入和配置服务与应用，而所有这些任务只需一条命令即可实现。下一节将介绍有关加入应用的详细信息。9自动化提示由于红帽高级集群管理是在红帽 OpenShift 集群中运行，因此您可以使用红帽 Ansible 自动化平台来安装和配置您的“红帽高级集群管理”集群。3.31.02.04.05.0跨基础架构 部署和管理应用创建了红帽 OpenShift 集群后，您需要在集群上部署应用和服务。红帽 Ansible 自动化平台可以帮助您以一致的方式，跨红帽 OpenShift、其他 Kubernetes 分发版、非 Kubernetes 平台和边缘环境快速部署安全至上的应用。您还可以将使用红帽 OpenShift 开发的应用部署到其他平台，包括未连接的、间歇性连接的和休眠的环境，以及通过 Podman 运行红帽企业 Linux 的系统。在应用部署过程中，您可以使用红帽 Ansible 自动化平台来配置应用运维所需的集群外资源，例如，负载均衡器、数据库、防火墙和监控解决方案。您还可以触发 ITSM 系统更改请求，或在 ITSM 系统中更新部署状态。您甚至可以将红帽 OpenShift 操作器和 Helm 图表集成到更大的应用部署工作流中，以通过单一命令快速启动。通过 Kubernetes API 和 Helm 图表在 Ansible 内容集中的模块中自动执行操作器。自动化提示您可以使用红帽高级集群管理来查看、监控和更新通过红帽 Ansible 自动化平台部署到红帽 OpenShift 的所有应用资源。10红帽 Ansible 自动化平台使用红帽 OpenShift 开发的应用红帽企业 Linux 守护进程应用红帽 OpenShift Kubernetes 原生应用红帽企业 Linux 容器化应用3.41.02.04.05.0简化灾难恢复 和业务连续性虽然红帽 OpenShift 为应用开发和部署提供了一个弹性平台，但如果底层基础架构存在问题，则会导致集群故障。有效的自动化灾难恢复至关重要，可以确保生产应用和运维的业务连续性。红帽 Ansible 自动化平台和红帽高级集群管理可以帮助您自动执行部署、备份和恢复流程，在您需要时快速准确地重建环境：支持灾难恢复站点，包括硬件、软件、集群和应用。执行例行的集群快照和备份，包括有状态核心服务（如 etcd）和持久卷，以用于重建、克隆和灾难恢复工作流。重新分配故障集群的网络流量，确保业务连续性。利用端到端自动化工作流创建集群和部署应用，重建和恢复故障的集群和站点。创建与您的运行中节点和集群相同的热备用节点和集群。11 5 IDC 白皮书，红帽赞助。“红帽 Ansible 自动化平台的商业价值”，2021 年 10 月。文档编号#US47989320。使用红帽 Ansible 自动化平台的企业实现了76%计划外停机时间减少5。12成功案例了解红帽为各行各业带来的优势各行各业的企业正在利用红帽 Ansible 自动化平台和红帽 OpenShift 取得业务成功。阅读这些客户成功案例，了解详情。“阅读成功案例。1.02.03.04.05.0北卡罗来纳州的 Blue Cross and Blue Shield（Blue Cross NC）致力于实现更优质、更简单、更实惠的医疗服务。为实现这一愿景，该公司通过内部 IT，利用红帽技术创建了适应性强的自动化环境。该保险公司的新环境基于运行红帽企业 Linux 的红帽 OpenShift。Blue Cross NC 还部署了红帽 Ansible 自动化平台，用人类可读的 Playbook 增强红帽 OpenShift 的自动化功能。经过红帽技术专家的指导和培训后，Blue Cross NC 提高了效率，并降低了置备方面的成本。仅仅两年，该保险公司就节约了超过 850,000 美元的资金和 70,000 个工时。我们利用 Ansible 自动化平台将复杂的重复性任务自动化，展示了 IT 如何通过经济高效的一致性工作创造业务价值。仅前两年，我们就执行了 200,000 个 Ansible Playbook，节约了大概 70,000 个工时。”Petar BojovicBlue Cross NC 技术基础架构总监IT 自动化可以帮助您缩小传统环境与云原生环境在运维方面的差距。无论您处于数字化转型之旅的哪个阶段，红帽都可以帮助您构建和自动化真正的混合云环境。借助红帽 Ansible 自动化平台、红帽 OpenShift 和红帽 Kubernetes 高级集群管理，您可以简化运维，提升敏捷性，更快更轻松地采用云原生技术和方法。2022 Red Hat,Inc.版权所有。红帽、红帽 logo、红帽企业 Linux、Ansible 和 OpenShift 均为 Red Hat,Inc.在美国和其他国家/地区的商标或注册商标。Linux 是 Linus Torvalds 在美国和其他国家/地区的注册商标。F31453_0422_KVM您准备好自动化了吗？敬请访问

8人已浏览 2023-03-22 15页 5星级

孙滔中国移动2023.3运营商算力网络发展及技术探讨中国移动算力网络整体发展情况中国移动洞悉算力发展趋势，把握算力时代脉搏，积极响应国家东数西算战略，充分发挥运营商网络领先优势，以网强算提出“算力网络”全新理念，一年多来持续开拓创新，全力推进算力网络发展2中国移动算力网络核心理念算力网络是以算为中心、网为根基，网、云、数、智、安、边、端、链（ABCDNETS）等深度融合、提供一体化服务 的新型信息基础设施。算力网络的目标是实现“算力泛在、算网共生、智能编排、一体服务”，逐步推动算力成为与水电一样，可“一点接入、即取即用”的社会级服务，达成“网络无所不达，算力无所不在，智能无所不及”的愿景。算为中心以网强算多要素融合一体化服务算是业务与服务的原动力表达从通信网络向信息网络变革技术要素（存/算/网）能力要素（AI、安全等）资源要素（局址、能源等）资源式到任务式端到端质量保障算力交易、算力并网算力从有界变成无界网络从刚性变成柔性算网从分立变成一体3算力网络演进路径起步：泛在协同发展：融合统一跨越：一体内生协同编排网随算动智能编排算网融合智慧内生算网一体一站服务、协同运营融合服务、统一运营一体服务，模式创新 十四五阶段十五五阶段及更长期阶段一阶段三阶段二算力网络发展分为泛在协同、融合统一和一体内生三个阶段，最终推动算力成为与水电一样，可“一点接入、即取即用”的社会级服务，赋能数字经济高质量发展45中国移动体系化推动算力网络创新发展主线一面向算网基础设施构建主线二面向业务融合创新实现算力在物理空间、逻辑空间、异构空间的融通，打造领先算网基础设施实现算网高效协同，支持CHBN业务融合发展，打造算网全新生态实现创新技术引领，打造原创技术策源地主线三面向创新技术引领6主线一：面向算网基础设施构建完善算力基础设施布局物理融通推进数据中心覆盖和互联，实现不同地域泛在算力在物理空间的融通。对接东数西算国家算力枢纽规划完善“4 N X”数据中心布局，数据中心机架超120万架中国移动持续完善“4 N X”数据中心布局，推进边缘算力覆盖，加快泛在算力基础设施构建逻辑融通推进云、边、端协同，实现中心、边缘、端侧算力在逻辑空间的融通。从300余个区域和省级中心云逐步延展，建设超过1500个CDN边缘节点，推进超1000余个边缘云节点建设哈尔滨长三角区域贵阳呼和浩特京津冀区域粤港澳大湾区域成渝区域异构融通推进算力多样化，实现通用算力和专用算力在异构空间的融通。x86、ARM等多样化算力服务器规模超60万台，通过合营/转售、API对接、云原生等方式加快社会算力并网纳管中卫庆阳7主线一：面向算网基础设施构建打造以算为中心的基础网络以算力为中心打造骨干(20ms)、省域(5ms)、地市(1ms)三级时延圈，提升网络确定性能力端侧算力20ms骨干时延圈枢纽算力省级/区域算力城市边缘算力接入省域/区域骨干枢纽算力SD-WAN 5m省域时延圈1ms地市时延圈骨干DCI网络省内DCI网络CMNet城域/省网OTN国干OTN省干城域SPN OTN城市向算而生构建网络新架构技术创新打造网络新能力扩大网络覆盖，DCI云专网覆盖超320个地市提升网络Mesh度，减少流量绕转，降低时延提升网络带宽，向400G/800G演进通过SRv6/G-SRv6技术提升网络调度能力，实现多种业务的差异化保障网络切片提供确定性连接服务新一代SD-WAN高效分发算力服务8主线二：面向业务融合创新构建融数注智的算网大脑算网大脑是算网共生发展的关键系统，通过对算力和网络资源的统一编排调度和管理运维，融数注智，向下实现泛在算力的跨层跨区域融通和网的跨域跨专业拉通，向上实现多要素融合能力供给和算网一体化服务支撑算网跨域调度算网数据感知跨领域、跨专业统一调度算网全域感知，端到端服务质量保障算网智能化意图感知、网络自智算网融合编排多要素一体编排算网能力开放算网原子能力融合供给算网资源拉通、控制命令下发、状态交互、API原子能力开放算力网络基础设施层算力网络协同编排中心2算力网络智慧中心3算网大脑统一运营入口、融合类业务支撑 业务需求解析算力网络运营层一体化运营支撑能力统一资源呈现算网服务目录效能评估呈现 算网感知平台5数据共享数据存储策略管理业务设计中心业务生命周期管理算网能力仓库算网产品中心算网能力开放中心1业务能力开放业务指标监控业务需求解析算力使能网络使能安全使能.智能优化智能编排智能感知数据采集数据处理 算网跨域调度4API管理接入管理9主线二：面向业务融合创新开创算网服务1.0 中国移动算力网络云网一体产品云专网节点覆盖全国所有地市全网用户一跳入网、算力高速互联3AZ高品质资源池运营商首个自研3AZ架构，布局全网5大区8个节点提供L6级同城双活、异地容灾服务5G*云，双引擎持续赋能行业以算力驱动生产力，推动千行百业数智蝶变融合ABCDENETS能力，任务式服务，算力即取即用AZ1AZ3AZ2PTN云专线OTN云专线PON云专线5G云梯云互联云组网SPN切片云专线一站式入云服务10 方式一跳入云5G/SPN端到端切片上云租户百G带宽，百T容量超低时延，安全可靠 云上云下互联组网网元亿级并发百G吞吐3000万pps 转发性能 超大规模云内网络上云云间影像回传边缘渲染远程手术数字孪生工厂质检云游戏全息课堂AI算法行业切片建模仿真视频加速5G 云新型算网解决方案位置物联网AR远程辅助城市大脑以网强算让业务品质更可靠更安全算网融合让客户体验更高效更便捷算网赋能让服务模式更灵活更多元以产品算力化和算力产品化为主线，融合多要素，重塑产品能力，创新服务模式，打造更可靠、更高效、更智能、更便捷的算网服务体系10主线三：面向创新技术引领构建创新技术体系算力卸载算力原生存算一体算力度量云原生多样性算力全程可信算力路由在网计算PON高速全光接入算力交易数据流通安全编排隐私计算算网多要素融合编排芯片节能数据中心节能服务器节能绿色安全400G/800G全光高速互联OTN灵活光电联动算网SPN承载泛在调度应用感知确定性网络新一代SD-WANSRv6/G-SRv6低碳能源算网数据感知智算中心融合服务技术算力提升技术以网强算技术星云算力运营服务层编排管理层算网基础设施层算网智能化智能网络调度中国移动对算力网络的关键技术进行体系化的梳理和深度挖掘，重点布局算力提升技术、以网强算技术和融合服务技术，横向映射三层架构，纵向串联各技术栈，形成创新技术体系，推动技术簇的共同成熟创新技术1：广域吞吐敏感网络技术（1/5）p 东数西训、东数西渲、东数西存等场景通过广域网将温、冷数据（占全部数据95%）迁移至西部，实现数据高效利用，降低能耗和成本。为将源源不断的数据按时保质迁移，对网络吞吐有较高要求随着东数西算国家战略的实施，大容量数据在广域网传输的需求越来越多，同时多云数据备份、数据异地上云等场景对在线数据迁移的有效吞吐提出了更高要求，实现海量数据在广域网高吞吐传输成为迫切需求p 多云数据备份、多云协同计算、数据异地上云等场景通过广域网实现海量数据迁移，满足不同云业务需求。网络有效吞吐决定了数据迁移成本，同时有时延、安全、可靠等性能保障要求IP网络光底座东部温、冷数据西部通用、智算数据中心海量数据广域网传输智算、超算中心数据产生端广域网智算、超算中心智算、超算中心云间数据备份、同步数据异地上云11创新技术1：广域吞吐敏感网络技术（2/5）p 当前广域网大数据迁移存在的问题FTP类传输协议吞吐量不高，如果数据量几百TB或者PB级别，一般选用人工快递硬盘方式，耗时长，数据丢失、损坏风险高原因1：物理带宽不高，存在带宽上限。通过建设超宽骨干网，消除物理瓶颈原因2：现有广域网拥塞控制算法准确度不高，有效吞吐存在瓶颈广域网拥塞控制算法按照拥塞判断依据分为丢包类、时延类、带宽类等，随着广域网拓扑日益复杂、业务越来越多样，设备类型越来越异构，拥塞控制算法也在不断完善，期望达到物理带宽的吞吐量p 丢包类拥塞控制l典型算法：Reno、CUBIC等l缺陷：丢包=拥塞，发送速率过调整，吞吐受限p RTT类拥塞控制l典型算法：FAST、Vegas等l缺陷：RTT变大=拥塞，发送速率过调整，吞吐受限p 带宽类拥塞控制l典型算法：BBR、GCC等l缺陷：可用带宽变化调整发送速率，欠调整，丢包率高拥塞控制算法要综合考虑准确性、公平性、扩展性等，目标是充分利用物理带宽，提升用户体验12创新技术1：广域吞吐敏感网络技术（3/5）超高速率的数据传输驱使TCP/IP协议处理由内核卸载至网卡，RDMA成为数据高效传输首选技术RoCEv2协议易部署、性能高，但应用在丢包率较高的广域网中需要优化其原生实现“数据中心税”算力损耗居高不下 CPU TPS有限，吞吐存在瓶颈 零复制：在应用内存与内核之间复制数据 内核旁路：应用程序无需执行内核内存调用就可向网卡发送命令 无CPU参与：应用程序访问远程内存，而不占用远程机器CPU1.Infiniband：高性能、部署成本高2.RoCEv1/v2：高性能、部署成本低3.iWARP：低性能、部署成本低RDMA三大实现协议RoCEv2应用在广域网中的挑战 广域网丢包率较高，RDMA原生Go-back-N丢包重传机制，少量丢包即可导致吞吐大幅下降 IBTA没有针对RDMA定义数据加解密算法，缺乏数据安全机制高速数据传输带来的问题RDMA技术13创新技术1：广域吞吐敏感网络技术（4/5）基础设施层东数西算企业专线网络功能层应用服务层数据灾备数据上云云专线数据安全加密丢包精确重传广域拥塞控制丢包快速恢复功能集合性能计算时延测量实时吞吐检测丢包检测可用带宽检测IP协议RDMA协议基础协议UDP协议协同计算SDWAN应用服务层网络功能层基础设施层东数西算：东数西存、东数西渲等大数据迁移场景数据灾备：多数据中心间的备份数据迁移场景数据上云：数据产生端向异地智算、超算中心迁移场景分布式计算：异地多数据中心间的实时数据同步基础协议：基于传统IP/UDP协议，保持现网兼容性，同时基于RDMA扩展适应广域部署性能计算：对丢包、时延、带宽、吞吐等网络性能指标实时计算，为功能实现提供数据功能集合：插件式功能集，各功能间解耦，系统可根据不同应用需求调用不同功能云专线：实现多云之间广域互联SDWAN：实现多用户和云数据中心广域互联企业专线：实现企业与企业或数据中心广域互联提出广域吞吐敏感网络(WGSN)总体架构，实现高吞吐、高安全、低算力损耗的广域网络数据传输状态参数能力14创新技术1：广域吞吐敏感网络技术（5/5）网络高吞吐算力低损耗数据高可靠 新型拥塞控制技术：基于单向时延和可用带宽的高精度测量，设计扩展性强、准确性高的广域拥塞控制算法 精确丢包重传技术：基于高效、准确的丢包检测，设计精确丢包重传机制，消除RDMA原生 Go-Back-N丢包重传缺陷 快速丢包恢复技术：设计基于前向纠错码的丢包恢复算法，既可降低链路丢包概率，又不增加重传时延，大幅降低丢包对传输性能的影响 数据安全加密技术：基于传输层加密技术，路由协议无关，确保数据安全传输p 关键技术p 广域吞吐敏感网络目标在有限网络和算力资源下，实现网络高吞吐、数据高可靠、算力低损耗三者的动态平衡和综合最优云间数据迁移服务市场规模近百亿美元，并持续以25%的年增长率递增*。受限于网络吞吐不足，目前TB级别的数据迁移多采用人工快递硬盘方案，效率较低。广域吞吐敏感网络通过提升网络有效吞吐，期望TB甚至PB级别数据线上迁移时，效率更高，成本更低，用户体验更好。15*SNS Insider云迁移服务报告（2022年）16创新技术2：算力路由（1/3）2018年开始研究算网融合技术，面向云边协同和边边协同的“性能反转”等问题，提出在路由域引入计算信息进行联合调度通过仿真发现在路由中引入算力信息在低中重载情况下均有一定的优化效果。在负载达到60%时，整体系统的算力可用容量提升33.17%，端到端平均时延提升35.29%重载下CAN的QPS较好重载下CAN的时延比较低（1）感知：路由系统感知计算资源（2）路由：综合网络和计算信息寻址选路解决思路在路由中引入计算信息，进行联合调度提出算力感知网络CAN，发布系列白皮书2019 2021边缘节点边缘节点中心云问题本质计算和网络是独立系统，算的负载和网的拥塞信息没有产生关联算：降低负载、计算资源预留.网：增加带宽、配置专线.增加网络建设、运维成本 造成大量计算资源的闲置-计算负载高及网络队列深的条件下，边缘响应平均时延及尾时延远大于中心云-算的负载状态以及网的拥塞情况均是问题来源发现问题 云边以及边边调度之间出现“性能反转”（1）（2）形成算力感知网络CAN的核心方向-算力路由17基于BPG协议感知通告算力信息，在距离向量上叠加计算向量，需设计自适应算力通告机制和新型多因子算路算法，实现算力和网络的联合优化在BGP距离矢量上叠加算力向量，改变了BGP选路方法，影响BGP路由决策。简单叠加将导致路由不收敛算力信息更新频率快、信息类型多，以BGP增量更新网络信息的方式简单叠加算力信息，将导致信息泛洪，引起路由震荡ABCE网络节点ABCE连接算力的网络节点网络拓扑算力网络节点拓扑算力网络状态拓扑网络节点ABCE连接算力的网络节点算力节点能力通告算力节点状态通告网络节点构建算力路由信息表（CA-RIB），考虑距离因子、算力因子以及权重，生成算网cost=w1*网络cost w2*算力costCA-BGP：新型算网多因子算路算法通过仿真建模量化分析算力信息通告信令开销的影响，得到通告信令开销与路由调度成功率的最优解 CA-BGP：自适应算力通告通告频率越高，算力信息越实时，但开销越大，如何找到通告信令开销与信息实时性的平衡点CA-BGP：算力通告最优解提出分域通告、分类通告分域通告：约束算力信息更新的范围分类通告：减少算力信息的无效通告挑战3：路由求解挑战2：高效通告挑战1：算力扩展CAN协议簇包括CA-BGP、CA-BGP-LS、CA-OSPF、CA-Netconf/yang、CA-Restful/json等，实现算力感知、路由调度以及配置管理BGP是全球网际互联的域间路由控制协议的唯一事实标准，基于BGP的创新涉及到TCP/IP协议族核心协议的改动，创新难度大创新技术2：算力路由（2/3）2022 Mar IETF113Non-WG Forming CAN BoF2022 July IETF115WG Forming CAN BoF场景和需求达成共识220 人参会，包括半数AD讨论技术路线，工作组章程260人参会，投票支持度2/32023 March 2th IESG会议CATS工作组的成立中国移动担任工作组主席获取关注，凝聚初步共识3次 Side meeting20192021历经4年，中国移动在IETF推动成立算力路由CATS工作组并担任主席，是算力网络原创技术走向国际的里程碑 创新技术2：算力路由（3/3）18CATS首先面向单域，制定算力路由的场景、需求、架构标准Scope Groundwork of Problem statement,Use cases,Requirements Overall CATS framework&architecture Additional groundwork of computing metrics analysis,implementing the CATS control and data plane using existing mechanisms/potential new approaches MileStone Jul 2023:Adopt the CATS Problem Statement,Use Cases,Gap Analysis,and Requirements documents Jul 2024:Adopt the CATS Framework and Architecture document Nov 2025:Submit the CATS Framework and Architecture document to the IESG for publication as Informationalhttps:/datatracker.ietf.org/wg/cats/about/创新技术3：在网计算在网计算将应用相关功能卸载至网络设备，在数据转发同时实现高效数据处理，提升系统计算效率，算力网络体系中智算中心网络、高性能云网络等场景对于性能提出极致需求，在网计算可以大幅加速业务处理过程加速AI模型训练PS架构参数服务器聚合GPU节点1GPU节点2GPU节点3GPU节点NGPU节点1GPU节点2GPU节点NGPU节点3RAR架构循环参数聚合通信效率低带宽资源占用高GPU节点1GPU节点2GPU节点NGPU节点3可编程交换机聚合参数提升异构融合网元处理性能 在网计算优化分布式机器学习架构，实现通信性能和带宽占用的平衡 试验网初步完成性能评估，通信密集型模型训练任务最高可以上精准核间负载均衡系统架构异构融合网元负载方差相较传统网卡RSS机制下降数据面高速核负载感知和限速机制P4RSS:Load-Aware Intra-Server Load Balancing with Programmable Switching ASICs，ICC 202319总结与展望p 算力网络的终极目标是推进网络和计算两大方向的融合，实现算网一体共生发展，作为多学科交叉融合技术，需要体系化布局，解决系列科学性和工程性问题。p 中国移动以基础设施构建、业务融合、技术引领三条主线体系化推进算力网络创新发展，持续推动关键技术从概念原型进入产业实践p 实现算力网络的愿景和目标还存在诸多挑战，一些交叉领域的技术攻关还处于起步阶段，需要产学研各界共同努力，推进产业链跨域融通，促进生态繁荣。携手推动算力网络技术和生态成熟，助力新型基础设施建设，赋能新时代数字化转型升级！

33人已浏览 2023-03-21 20页 5星级

人工智能基础数据服务白皮书2023/03人工智能基础数据服务白皮书 2023。欲了解更多信息，请联系德勤中国。核心观点核心观点整体市场整体市场：人工智能产业的快速增长带动了人工智能基础数据服务市场的蓬勃发展人工智能基础数据服务市场的蓬勃发展，自动驾驶是未来五年最重要的应用领域自动驾驶是未来五年最重要的应用领域发展趋势：发展趋势：标注复杂化、自动化、全栈式服务需求以及愈加严格的数据合规需求是AI基础数据服务市场的四大趋势竞争格局：竞争格局：传统的专业型基础数据服务商仍是行业重要组成，但科技巨头企业依托其科技实力和强大资源，逐渐占据竞争优势科技巨头企业依托其科技实力和强大资源，逐渐占据竞争优势结构化数据是人工智能算法开发迭代的重要基础，人工智能基础数据服务市场受人工智能核心产业发展带动仍将保持高速增长，预计2027年市场规年市场规模有望达到模有望达到130-160亿元。亿元。自动驾驶自动驾驶是人工智能基础数据服务市场占比最大的下游应用，随着自动驾驶算法技术不断迭代与场景落地，未来占比有望进一步提升。未来占比有望进一步提升。标注复杂化：标注复杂化：随着算法迭代创新以及场景功能的持续扩展，数据标注元素和标注信息维度均将大幅增加，对于数据基础服务供应商提出了更高的要求；自动化标注：自动化标注：AI赋能的自动标注工具逐渐成为基础数据服务商和AI算法公司降本增效的利器，推高行业集中度；全栈式服务：全栈式服务：下游算法应用方自研人工智能算法的趋势逐渐显现，需求方对于“基础数据服务 云资源 工具链”的全栈式服务需求提升（包括算法公司，但主要由应用方驱动），特别是对于工具链产品的需求将随着商业化场景的成熟由自动驾驶领域向各行各业拓展，适应未来的迭代需求；从自动驾驶基础数据服务需求方的角度出发，整车厂及整车厂及Tier1自研需求不断提升，自研需求不断提升，同时技术迭代带来的更复杂、更专业的数据标注需求，这将推升整个自动驾驶行业的基础数据服务外包需求，并进一步释放对工具链及全栈式服务的需求。并进一步释放对工具链及全栈式服务的需求。数据合规性：数据合规性：数据安全法律法规体系不断完善，基础数据服务商在数据脱敏、数据采集的测绘资质要求等环节的专业性价值会为其带来竞争优势。科技巨头、专业型基础数据服务商以及科技初创企业是人工智能基础数据服务行业的主要参与者，其中专业型基础数据服务商布局早，服务经验积累深，在市场中仍占有较大份额，而科技巨头近两年发力明显，快速抢占市场；自动化标注、专业数据采标及全栈式服务是人工智能基础数据的三大核心能力，其中领先的科技巨头在三个维度均有持续的积累，综合能力最强。以百度为代表的科技巨头依托其研发能力、产业链协同资源和对AI算法的理解、稳定和专业的标注团队，竞争优势显著，市场份额有望持续提升。人工智能基础数据服务白皮书 2023。欲了解更多信息，请联系德勤中国。目录目录章节章节页码页码第一章：人工智能，数据先行：第一章：人工智能，数据先行：AI基础数据服务持续快速发展基础数据服务持续快速发展4第二章：第二章：AI基础数据服务趋势：复杂化、自动化、全栈化及合规化基础数据服务趋势：复杂化、自动化、全栈化及合规化12第三章：科技巨头已下场，强者优势愈发清晰第三章：科技巨头已下场，强者优势愈发清晰19人工智能基础数据服务白皮书 2022。欲了解更多信息，请联系德勤中国。人工智能基础数据服务白皮书 2023。欲了解更多信息，请联系德勤中国。存在大量针对黄恐暴、抄袭等方面的内容审核需求，但人工审核效率低、成本高传统客服也面临成本高昂的问题人力工序过程失误率高，且难以追溯部分工作环境存在高危性国内医疗水平参差不齐，基层卫生医疗水平低下，有经验的医生资源稀缺新药设计难度大、成本高且耗时传统安防无法准确识别人、物与场景犯罪、恐怖袭击等事件无法预知人口红利消失，驾驶员成本高且资源短缺超载及疲劳驾驶导致安全事故频发，造成生命财产损失采用语音识别、语义切割、图像识别等方式对内容数据进行识别分类，高效实现审核工作ChatGPT的诞生大大加快了人机交互的效率与应用利用计算机视觉技术高效准确发现瑕疵品机器人代替人在危险场所完成工作智能影像识别可以通过自动读片快速进行疾病筛查，弥补医疗资源差异AI制药能够以更低成本高效发现药物靶点、筛选化合物，大幅提升新药研发效率通过计算机视觉等技术实现人脸识别，从而发现嫌疑人行动轨迹进出楼宇与园区时采用指纹或人脸识别提高识别精确度自动驾驶通过传感器、计算机视觉等技术逐步解放驾驶员，实现车辆的自主驾驶中国人工智能产业处于高速增长期，正在加速向各行各业渗透，包括互联网娱乐、智能制造、智慧医疗、智能安防及自动驾驶等，而自动驾驶等应用场景的复杂性又反向推动了人工智能的迭代演进互联网娱乐互联网娱乐智能制造智能制造智慧医疗智慧医疗智能安防智能安防自动驾驶自动驾驶信息来源：德勤访谈、研究与分析人工智能主要应用场景人工智能主要应用场景场景痛点场景痛点AI解决方案解决方案AI应用场景复杂性应用场景复杂性高低AI精度要求精度要求人工智能正在加速渗透应用到各行各业人工智能正在加速渗透应用到各行各业人工智能基础数据服务白皮书 2023。欲了解更多信息，请联系德勤中国。开发流程开发流程数据价值数据价值数据需求量数据需求量结构化数据是人工智能算法模型开发和迭代算法模型开发和迭代的基础，从设计、训练、评测、仿真到整个算法更新迭代的全生命周期都需要持续不断的结构化数据的输入作为支撑信息来源：德勤访谈、研究与分析人工智能算法模型开发流程人工智能算法模型开发流程 从数据源采集包括图像、语音、文本、点云等形式在内的算法所需数据，通过标注，将非结构化数据转化为计算机语言下的结构化数据，通过标注，将非结构化数据转化为计算机语言下的结构化数据，结构化数据是人工智能算法开发的基石结构化数据是人工智能算法开发的基石 需要大量结构化大量结构化数据数据进行模型训练 需要根据场景挖掘构建场景库构建场景库，并进行仿真测试仿真测试 需要经过标注的测试数据集测试数据集进行对照验证结构化数据结构化数据训练训练仿真仿真评测评测设计设计 需要持续的一定持续的一定量数据输入量数据输入进行算法模型迭代 通过海量结构化数据训训练人工智能算法模型练人工智能算法模型，使人工智能算法得以落地实践 通过数据建模建立接近真实世界的测试场景并进行算法可行性测试验进行算法可行性测试验证，例如自动驾驶场景证，例如自动驾驶场景或智能制造场景或智能制造场景 通过人工数据标注结果与模型标注结果比对进行算法模型的评测，判判别算法模型识别准确性别算法模型识别准确性 通过感知训练评测平台根据实际场景和技术趋势对算法进行可持续性持续性的、针对性的更新迭代的、针对性的更新迭代和算法和算法bug修复修复 明确选择算法的核心目标，并从数据中提取有从数据中提取有效信息效信息以进行算法模型的选择和设计 分析小批量数据分析小批量数据特性特性以设计算法模型迭代迭代人工人工智能智能算法算法模型模型开发开发结构化数据是人工智能快速发展的基石结构化数据是人工智能快速发展的基石高低人工智能基础数据服务白皮书 2023。欲了解更多信息，请联系德勤中国。人工智能基础数据服务商处于产业链中游，通过提供数据采集和标注服务，连接上游数据来源方和下游人工智能算法研发方人工智能基础数据服务商处于产业链中游，通过提供数据采集和标注服务，连接上游数据来源方和下游人工智能算法研发方 市场上现存的大量数据均为非结构化数据，无法直接应用于人工智能算法的研发与训练，需要通过数据的采集与标注将其转化为结构化数据，以供下游人工智能算法研发商使用。这个采集与标注的过程逐渐形成了一项专项工作，主要由专业的基础数据服务商来提供，少量由算法研发企业的自有团队执行基于结构化数据的重要性，人工智能产业逐渐诞生了一批专业人工智能基础数据服务商通过数据采集与数据标注，有效衔接数据源与具有算法开发需求的企业人工智能基础数据服务产业链人工智能基础数据服务产业链1注释：1.产业链图谱中代表厂商为不完全列举，排名不分先后信息来源：德勤访谈、研究与分析数据产生源数据产生源产业链上游产业链上游产业链中游产业链中游产业链下游产业链下游人工智能基础数据采集与标注人工智能基础数据采集与标注人工智能算法研发人工智能算法研发AI基基础础数数据据服服务务商商语音语音图像图像视频视频文本文本点云点云数据数据采集采集数据数据标注标注非非结结构构化化数数据据结结构构化化数数据据声音人体事件道路物体车辆图片行为信号科技科技公司公司行业行业企业企业AI公司公司科研科研单位单位下下游游应应用用下游企业下游企业自有团队自有团队对结构化数据的需求催生基础数据服务产业对结构化数据的需求催生基础数据服务产业人工智能基础数据服务白皮书 2023。欲了解更多信息，请联系德勤中国。人工智能技术经历数十载的发展，近年来深度学习加速了人工智能技术的商业化落地，同时也带来了大量AI算法训练需求，推动基础数据服务市场的快速增长信息来源：公开资料整理、IDC；德勤访谈、研究与分析8.210.713.818.030.345.0130-160 41%-30%人工智能技术已经经历了较长时间的发展，近年来由深度学习带来的人工智能技术商业化应用落地极大的推动了人工智能技术已经经历了较长时间的发展，近年来由深度学习带来的人工智能技术商业化应用落地极大的推动了AI基础数据服务的需求基础数据服务的需求人工智能发展阶段及重要里程碑人工智能发展阶段及重要里程碑人工智能的人工智能的诞生诞生人工智能技术人工智能技术高速发展高速发展2006-20161950s-2005 1956年达特茅斯会议召开，标志着人工智能这人工智能这一技术的诞生一技术的诞生 1958年感知器：脑的组织和信息存储的概率模型发表，打开了神打开了神经网络研究的大门经网络研究的大门 2006年，深度学习神经深度学习神经网络网络概念被提出 2016年，谷歌Alpha Go运用深度学习算法运用深度学习算法战胜世界围棋冠军，拉开了人工智能深度学习商业化落地的大幕2027E20182019202020212022深度学习加速人工智能商业化落地深度学习加速人工智能商业化落地20172021年百度与小马获得首批自动驾驶车辆收费服务试点，标志着中国自动驾驶商业化运营的元年2017年，苹果iphoneX首次推出人脸识别解锁，2017-2018年，阿里巴巴、小米及百度先后推出AI智能音箱。AI智能终端商业化快速发展中国人工智能基础数据服务市场规模中国人工智能基础数据服务市场规模单位：亿元基础数据服务受基础数据服务受AI商业化落地驱动高速增长商业化落地驱动高速增长人工智能基础数据服务白皮书 2023。欲了解更多信息，请联系德勤中国。数据采集标注类型数据采集标注类型未来增长潜力未来增长潜力未来增速未来增速1自动驾驶自动驾驶采集大量真实、覆盖不同道路天气小概率事件的道路视频图像以及激光点云图像，标注视频图像以及点云数据中的道路可行驶区域、车辆、行人等各类元素自动驾驶行业对数据的需求处于起步阶段，未来技术与功能迭代、场景拓展将带动数据需求量几何级增长数据需求量几何级增长32-37%智慧工业智慧工业采集产品图像、生产环境画面、设备运行状态画面等数据，标注各类生产状况及产品图像及其状态，如钢铁表面瑕疵或裂纹工业视觉是行业增长主要驱动力，伴随国家对工业领域数字化智能化的重投入，未来行业需求量有望放量需求量有望放量提升提升24-29%智能安防智能安防采集各类公共场所、居民住宅楼及商用楼的监控摄像头数据，标注视频图像中的人脸骨骼点、车辆、动作行为等元素人脸识别精确度的可提升空间有限，但事件感知识别等新场景需求为智能安防基础数据服务需求带来一定需求带来一定增长空间增长空间17-22%AI 互联网互联网采集用户生成的文章、搜索、直播、视频、图像等内容素材，标注文本中的敏感字眼以及视频图像中人的行为、手势、嘴型等动作元素行业快速技术迭代驱动数据迭代需求增长，但由于技术路径正向无监督训练倾斜，未来长期看数据标注的未来长期看数据标注的需求量或将先增后减需求量或将先增后减15-20%智慧医疗智慧医疗采集医疗影像、手术工具、处方、设备控制、病例等数据，标注医疗影像中的人体拉框、骨骼点以及处方病例中的文本等我国老龄化明显，医疗行业AI应用发展旺盛，带动基础数据服务需求呈现一定增长需求呈现一定增长15-20%其他其他智能终端：各国人像、小语种、方言等数据智慧金融：票据单据、保险标的、人脸、对话语音等非结构化数据以及风控数据等结构化数据智能终端、智慧金融等场景已较为成熟固化，未来增增长潜力稍低，将趋于稳定长潜力稍低，将趋于稳定但其他潜在应用领域例如元宇宙板块随着发展成熟或存在市场增长爆发的机遇12-16%6%7%78R 222027E注释：1.2022-2027E CAGR信息来源：德勤访谈、研究与分析人工智能基础数据服务应用于众多下游场景，但不同下游场景对数据采集类型以及数据标注对象有着各自的差异化需求，自动驾驶当前是人工智能基础数据服务最重要的应用领域，并将在未来继续维系这一地位人工智能基础数据服务下游应用占比（人工智能基础数据服务下游应用占比（2022-2027E）基础数据服务在不同场景的需求各不相同基础数据服务在不同场景的需求各不相同45亿亿整体市场规模：130-160亿亿份额占比：增加持平降低人工智能基础数据服务白皮书 2023。欲了解更多信息，请联系德勤中国。自动驾驶AI算法的升级迭代及模型训练数据量的指数级增长，将持续拉动人工智能基础数据服务需求信息来源：德勤访谈、研究与分析17.124.638.251.662.474.92024E448 22E2023E50R 25E52 26E52 27E大量整车厂与Tier1开始自研自动驾驶人工智能算法带来新数据需求，同时搭载自动驾驶车型渗透率不断攀升，算法模型的跨车型搭载带来适配需求自动驾驶技术从目前低级别向高级别的迭代迭代将带来人工智能模型训练数据量指数级指数级的需求增长持续稳定的“小确幸”持续稳定的“小确幸”技术迭代带来的需求“大爆发”技术迭代带来的需求“大爆发”自动驾驶人工智能基础数据服务市场规模及整体占比自动驾驶人工智能基础数据服务市场规模及整体占比单位：亿元；%自动驾驶基础数据服务规模自动驾驶占整体基础数据服务占比预计2025年L3级别自动驾驶级别自动驾驶实现商业化应用，相应的算法达到一定的成熟度，基础数据服务需求开始相对收敛当前自动驾驶领域各参与厂商正持续研发并落地L2 级别自动驾驶级别自动驾驶L4级别自动驾驶级别自动驾驶2030后后或逐步落地，算法模型训练的数据需求2027年后或将逐步释放核心驱动因素核心驱动因素自动驾驶将在未来持续释放数据基础服务需求自动驾驶将在未来持续释放数据基础服务需求人工智能基础数据服务白皮书 2023。欲了解更多信息，请联系德勤中国。目前自动驾驶主要聚焦于L2 级别开发和应用，随着算法趋于成熟，算法开发对于数据的需求量呈周期性收敛趋势，而高级别L3和L4自动驾驶技术场景更为复杂，算法模型训练所需的数据量将逐步呈现指数级上升场景处理复杂程度：低高自动驾驶等级场景及发展规划自动驾驶等级场景及发展规划数据采标数据采标需求需求对应功能对应功能及场景处理及场景处理复杂程度复杂程度量产车量产车落地时间落地时间自动自动驾驶驾驶场景场景发展发展规划规划在限定道路和环境条件下，系统完成所有驾驶操作算法需要针对驾驶过程中的全部算法需要针对驾驶过程中的全部场景实现感知并自动实现驾驶过场景实现感知并自动实现驾驶过程中的全部操作程中的全部操作系统完成所有驾驶操作，根据系统需求，驾驶员适时接管算法需针对驾驶过程中的全部场算法需针对驾驶过程中的全部场景进行有效感知与控制景进行有效感知与控制Level 3L4级别的算法模型开放性较高，最终成熟可能需要百亿甚至千亿帧百亿甚至千亿帧级别级别标注需求一个L3级别算法模型打开了更多的应用场景，最终成熟需要约十亿约十亿帧级别帧级别标注需求一个L2 级别算法模型的最终成熟需要约千万至亿帧级别约千万至亿帧级别标注需求系统通过加速/制动和转向提供持续辅助算法可提供部分场景城市领航、算法可提供部分场景城市领航、记忆泊车等有限功能记忆泊车等有限功能Level 2 信息来源：智能网联汽车技术路线图2.0；德勤访谈、研究与分析预计各类网联式L4车辆将在车辆将在2030年实现商业化年实现商业化落地，落地，鉴于目前已经有部分领先算法公司处于L4算法研发阶段，对于数据的需求将持续释放L3级自动驾驶预计在2025年实现商业化应用，商业化应用，目前各大车企正在积极布局，预计2023年开始将爆发大量模型训练带来的数据需求将爆发大量模型训练带来的数据需求目前已经处于L2 级别自动驾驶规模化量产阶规模化量产阶段，段，除了新进入者及新车型带来的基础数据服务需求外，整体需求呈现收敛态势Level 4Level 4*随着自动驾驶技术迭代，功能和场景复杂度不断提高，每个场景下所需的标注点成倍增长，数据采标需求量呈指数级增长随着自动驾驶技术迭代，功能和场景复杂度不断提高，每个场景下所需的标注点成倍增长，数据采标需求量呈指数级增长数据采标需求：低高自动驾驶将在未来持续释放数据基础服务需求自动驾驶将在未来持续释放数据基础服务需求L2爆发期爆发期20302025202220232027L2收敛期收敛期L3爆发期爆发期L3收敛期收敛期L4爆发期爆发期2020L2爆发期爆发期L3爆发期爆发期L4爆发期爆发期L2收敛期收敛期L3收敛期收敛期人工智能基础数据服务白皮书 2022。欲了解更多信息，请联系德勤中国。人工智能基础数据服务白皮书 2023。欲了解更多信息，请联系德勤中国。信息来源：德勤访谈、研究与分析相似功能应用场景扩展相似功能应用场景扩展外语、方言识别外语、方言识别口罩、墨镜下人脸识别口罩、墨镜下人脸识别安防事件预测安防事件预测算算法法与与功功能能迭迭代代创创新新L3自动驾驶自动驾驶L4自动驾驶自动驾驶L5自动驾驶自动驾驶L2 自动驾驶自动驾驶智慧工业智慧工业智慧城市智慧城市元宇宙元宇宙L2自动驾驶自动驾驶人脸识别人脸识别语音识别语音识别语音合成语音合成人工智能算法仍处于快速动态演进阶段，随着算法与功能的迭代创新，场景功能的持续扩展，数据标注元素和标注信息维度均将大幅增加，对于数据基础服务供应商提出了更高要求成熟应用成熟应用中长期中长期长远未来长远未来短期短期人工智能发展趋势示意图人工智能发展趋势示意图算法迭代算法迭代创新需求创新需求场景功能场景功能扩展需求扩展需求随着不同场景下的功能不断拓展完善，算法存在迭代创新的需求。以自动驾驶领域为例，随着L2至L4自动驾驶技术的迭代发展需要，相应的算法对于功能性要求愈发提高，对于数据采集与标注的需求也将愈发庞大复杂，需要感知训练评测平台加持模型迭代的效率与精确度。利用AI算法，实现对于同一种或者相似度较高的功能（例如人脸识别）需求不断拓展，对算法进行挖掘需求提炼、规则定义、工具制作、数据处理等工作，深度挖掘高价值数据标签。数据基础服务复杂度不断提升数据基础服务复杂度不断提升人工智能基础数据服务白皮书 2023。欲了解更多信息，请联系德勤中国。AI自动标注能力推高行业竞争门槛自动标注能力推高行业竞争门槛随着标注量的增大，纯人工标注在成本上不再具有优势，AI赋能的自动标注能力与相关工具逐渐成为基础数据服务商和AI算法公司降本增效的利器，也推高了行业门槛，未来市场集中度有望提升AI自动标注基于通过大量数据训练的算法模型，能够实现对原始数据中需要标注的元素的自动识别、检测以及标注AI自动标注通过算法模型反哺，基于基础图像识别能力演化而来自动标注通过算法模型反哺，基于基础图像识别能力演化而来借助借助AI自动标注可大幅提升标注效率自动标注可大幅提升标注效率以人工标注为主，标注过程中利用AI能力形成辅助工具帮助实现自动贴边、自动分割等功能，从而提高人工标注效率AI自动标注的不同功能模块自动标注的不同功能模块信息来源：德勤访谈、研究与分析AI自动标注的主要作用自动标注的主要作用标注效率提升标注效率提升使标注更简单高效，帮助提升数据标注速度标注速度标注成本降低标注成本降低提高效率的同时实现人工的部分替代，节省人力成本基础数据服务训练算法的同时算法也能赋能自动标注基础数据服务训练算法的同时算法也能赋能自动标注训练基础数据服务基础数据服务算法模型算法模型赋能AI辅助工具辅助工具AI自动预标注自动预标注通过AI算法初步生成标注结果，AI标注完成后再通过人工进一步核对和验证AI自动标注无法完全替代人工标注自动标注无法完全替代人工标注AI自动标注仍需要人工审核，且复杂度和精细度较高的需求仍然依赖人工标标注注任任务务随着人工智能算法功能的不断迭代演进，自动标注需要随着人工智能算法功能的不断迭代演进，自动标注需要持续的训练以及更强的算法能力支撑，行业门槛提高，持续的训练以及更强的算法能力支撑，行业门槛提高，具备较强法能力和稳定训练资源的数据基础服务供应商具备较强法能力和稳定训练资源的数据基础服务供应商以及算法公司将更具优势以及算法公司将更具优势自动化程度：较低自动化程度：较低自动化程度：较高自动化程度：较高AI自动标注自动标注人工审核人工审核人工标注人工标注人工审核人工审核AI赋值标注赋值标注人工审核人工审核定制化需求自动化程度：高低人工智能基础数据服务白皮书 2023。欲了解更多信息，请联系德勤中国。基础型服务基础型服务随着人工智能技术应用深化，下游AI算法应用方自研人工智能算法的趋势逐渐显现，他们相对算法公司而言，更需要“基础数据服务 云资源 工具链”的全栈式服务信息来源：德勤访谈、研究与分析下游应用厂商向上游布局趋势显著下游应用厂商向上游布局趋势显著新格局下的全栈式服务需求新格局下的全栈式服务需求传统算法公司对于基础数据服务的需求聚焦于标注效率、标注标注效率、标注质量以及标注成本质量以及标注成本等基础型需求算法应用方对于数据存储以及算法开发和运行所依赖的云计算云计算算力资源算力资源提出了相应的新需求需借助数据管理中台、智能标注平台、感知训练平台、仿真平台等成熟的算法工具成熟的算法工具链产品链产品实现快速部署与持续的快速迭代目前工具链主要应用在自动驾驶领域，未来需求将随着人工智能商业化场景的成熟扩展至各行各业 随着下游应用方的下场参与，他们算法能力积累较少，而同时面临算法能力快速部署与迭代的需求，进而催生出了对包括云资源、算法工具链等全栈式工具服务的需求进而催生出了对包括云资源、算法工具链等全栈式工具服务的需求云计算资源云计算资源算法工具链算法工具链 人工智能技术应用的逐渐深化促使部分下游人工智能应用厂商在产业链上进行延伸，逐步开始向上游人工智能算法领域布局算法公司与应用方都有对全栈式服务的需求，云计算资源及算法工具链需求量不断扩大。但相比之下应用方的技术能力偏弱，在向上游延伸的过程中，对于工具链的需求更加强烈 2018年，上汽宣布建立人工智能实验室上汽ai lab，大举进入自动驾驶领域，加大算法研发投入 2015年海康威视成立人工智能研究院 2017年大华成立聚焦AI等技术的先进技术研究院 2016年，招商银行正式提出要加快推进金融科技战略，通过旗下招银网络科技加人工智能的创新应用智能安防智能安防自动驾驶自动驾驶智慧金融智慧金融全栈式服务需求逐渐显现全栈式服务需求逐渐显现主要需求方主要需求方：算法公司 算法应用方示例示例人工智能基础数据服务白皮书 2023。欲了解更多信息，请联系德勤中国。数据采集数据采集数据标注数据标注自动驾驶算法研发自动驾驶算法研发自动驾驶解决方案开发自动驾驶解决方案开发自动驾驶整车应用自动驾驶整车应用标注工具标注工具标注团队标注团队传统车企传统车企造车新势力造车新势力整整车车厂厂Tier 1企业企业（如博世、大陆等）（如博世、大陆等）自动驾驶算法公司自动驾驶算法公司信息来源：德勤访谈、研究与分析基础数据服务商基础数据服务商自动驾驶板块表现十分明显，算法研发过去由专业算法公司把控，近年来越来越多的整车厂与头部Tier1也开始构建自有算法，尝试掌握自动驾驶的核心环节，由此成为行业的“算法新兵”基础数据服务商专注于服务下游客户外包数据服务需求传统车企核心布局自动驾驶整车应用Tier1厂商主要通过整合自动驾驶软硬件集成解决方案领先公司的工具能力更强头部传统Tier1逐渐加入自研自动驾驶算法以把控算法为目的，头部整车厂陆续搭建算法自研团队多自建一定规模数据标注团队及标注供给满足自身部分需求传统车企与传统传统车企与传统Tier1近年近年来纷纷布局自研算法来纷纷布局自研算法核心布局环节延伸布局环节仅吉利亿咖通具备甲级测绘资质造车新势力自带互联网基因，且相较传统车企，技术路径更先进，技术投入更高，往往倾向采用自研算法路径，并亲自布局自动驾驶算法至整车应用的完整环节自动驾驶算法公司核心布局算法环节自动驾驶算法成为“兵家必争之地”自动驾驶算法成为“兵家必争之地”“算法新兵”主要采用“算法新兵”主要采用外部标注工具与外部标外部标注工具与外部标注团队进行算法自研注团队进行算法自研有部分内生核心团队，同时外包部分需求人工智能基础数据服务白皮书 2023。欲了解更多信息，请联系德勤中国。内生处理内生处理外包需求外包需求中小中小算法算法公司公司头部头部算法算法公司公司专专业业自自动动驾驾驶驶算算法法公公司司“算法新兵”将在未来释放出大量基础数据服务需求的外包需求，同时随着整车厂及Tier1供应商对于自动驾驶算法自主研发能力的深化，也将释放更多工具链使用需求信息来源：德勤访谈、研究与分析传统车企传统车企造车造车新势力新势力整整车车厂厂Tier1自动驾驶基础数据服务不同下游客户数据处理需求量占比示意图自动驾驶基础数据服务不同下游客户数据处理需求量占比示意图当前第三方基础数据服务商市场空间当前第三方基础数据服务商市场空间“算法新兵”释放全栈式需求“算法新兵”释放全栈式需求数据需求向整车厂及数据需求向整车厂及Tier1侧重侧重随着整车厂及Tier1供应商对于自动驾驶算法自主研发能力的深化，将产生更多的基础数据服务需求，占比逐步提升外包服务需求整体加强外包服务需求整体加强随着当前的L2 继续向L3和L4的技术迭代，更多复杂场景下的复杂标注需求将更多通过外包的形式得到满足，数据基础服务供应商的专业性将协助其进行市场开拓工具链需求逐渐显现工具链需求逐渐显现由于工具链对于算法开发在算力、协同性、易用性等方面不可替代的优势，未来随着传统车企与Tier1随着算法能力构建深入，工具链将成为未来企业的主要工具122100%数数据据需需求求量量占占比比基础数据服务外包占比基础数据服务外包占比未来变化趋势未来变化趋势30%3人工智能基础数据服务白皮书 2023。欲了解更多信息，请联系德勤中国。随着数据安全相关法律法规体系的完善，数据合规要求愈发严格，基础数据服务商在数据脱敏处理、数据采集的测绘资质要求等环节的专业性价值优势凸显信息来源：民法典、信息安全技术个人信息安全规范 、中华人民共和国数据安全法、自然资源部关于促进智能网联汽车发展维护测绘地理信息安全的通知；德勤访谈、研究与分析311920202021 2021年7月，国家有关主管部门对国内企业高精度地图测绘资质进行复核，具有甲级测资质的企业由原来的31家减少到现在的19家，资质获取难度较高，具有稀缺性202020212022数据合规相关法律法规及标准体系数据合规相关法律法规及标准体系自动驾驶领域响应政策，甲级测绘资质成为数据采集必须自动驾驶领域响应政策，甲级测绘资质成为数据采集必须数据脱敏合规性数据授权合规性 因涉及数据安全性与保密性，自然资源部规定仅已获得甲级测绘资质的企业可合法开展自动仅已获得甲级测绘资质的企业可合法开展自动驾驶高精度地图的数据采集、存储、传输与处驾驶高精度地图的数据采集、存储、传输与处理等相关测绘活动理等相关测绘活动，而无相关测绘资质的企业须与有资质企业合作以达成合规要求导航电子地图制作甲级测绘资质审核要求高，目前具备该资质的厂商共导航电子地图制作甲级测绘资质审核要求高，目前具备该资质的厂商共19个个规定个人信息控制者开展个人信息处理活动应向个人信息主体明示个人信息处理目的、方式、范围等规则，征征求其授权同意求其授权同意针对个人信息去标识化与匿名化提出更为严格的定义，明确经处理后的信息不仅不得识别到特定自然明确经处理后的信息不仅不得识别到特定自然人人，而且不得关联到相关个人信息主体规定任何以电子或者其他方式记录的信息的处理，包括数据的收集、存储、试用、加工、传输、提供、公开收集、存储、试用、加工、传输、提供、公开等，均应进行规范以保障数据安全，工业、电信、交通、金融、科技等行业主管部门承担本行业、本领域数据安全监管职责中华人民共和国数据安全法中华人民共和国数据安全法2021.6 信息安全技术个人信息安全规范信息安全技术个人信息安全规范 2020.3对于各行各业的数据安全与合规提出了更严格的顶层设计对于各行各业的数据安全与合规提出了更严格的顶层设计自然资源部关于促自然资源部关于促进智能网联汽车发展进智能网联汽车发展维护测绘地理信息安维护测绘地理信息安全的通知全的通知2022.8数据合规趋严，专业性价值凸显数据合规趋严，专业性价值凸显中超联赛2020年商业价值年度报告 2021。欲了解更多信息，请联系德勤中国。人工智能基础数据服务白皮书 2023。欲了解更多信息，请联系德勤中国。科技巨头下场，行业竞争格局正在重塑科技巨头下场，行业竞争格局正在重塑人工智能基础数据服务行业有三类参与企业：以百度为代表的科技巨头，核心优势在于资源整合和研发能力；以数据堂为代表的专业型服务商，众包或人力外包模式起家；以曼孚科技为代表的科创公司，基于算法研发能力，以自动标注等标注工具切入市场。从市场份额看，百度位居行业第一，市占率达到17-18%信息来源：德勤访谈、研究与分析类型类型代表企业代表企业核心能力核心能力未来份额趋势未来份额趋势科技巨头公司科技巨头公司强大的IT能力带来的算法工具链能力AI大模型算法基础带来一定的自动化标注能力云计算资源的部署与协同能力全平台业务带来的客户资源专业型基专业型基础数据服础数据服务商务商品牌化专业服务商以众包或重人力外包模式起步，依托多年服务经验形成了各环节专业化的基础数据服务能力；能够覆盖多行业多场景基础数据服务需求部分成熟应用场景下通过经验积累已经具备一定的标准化数据集产品能力以及较为成熟的工具链能力中小型人力外包企业缺乏技术能力，仅通过众包及人力外包模式，提供低成本的人力标注服务科技初创企业科技初创企业通过算法研发，以自动化标注及AI标注工具切入市场，从而降低标注人力成本，尝试以低成本获取竞争份额50%-550%-35%-20%基础数据服务整体格局（基础数据服务整体格局（2022）人工智能基础数据服务商市场份额占比及核心能力分析人工智能基础数据服务商市场份额占比及核心能力分析以山东、山西、河南、贵州等地为主，人力资源充沛，人力成本较低，具有大量数据基础服务人力外包企业百度智能云百度智能云数据众包数据众包阿里众包阿里众包京东众智京东众智腾讯数据厨房腾讯数据厨房数据堂数据堂海天瑞声海天瑞声澳鹏澳鹏龙猫龙猫数据数据MindFlowStardustBodenAISurfingTech人工智能基础数据服务白皮书 2023。欲了解更多信息，请联系德勤中国。顺应标注复杂化、标注自动化、全栈式服务化以及数据合规化的“四化”趋势，科技巨头依托长期的技术和资源积累，综合能力更强，竞争优势突出百度智能云数据众包百度智能云数据众包阿里众包阿里众包京东众智京东众智澳鹏澳鹏海天瑞声海天瑞声数据堂数据堂强大的AI算法能力支撑其自动标注以及场景筛选等辅助标注能力自动标注算法能力较强，主要部署在云端，一般通过打包云服务方式销售具备一定的AI预标注能力，但整体AI算法能力相对百度和阿里稍弱缺乏强AI大模型能力支撑，但基于海外市场20余年行业经验，具备一定的AI自动化标注能力缺乏强算法能力支撑，自动标注能力较弱，但基于自有标注平台的研发与迭代，在语音、基础图像领域针对相对成熟的应用、具备一定的AI辅助标注能力拥有自动驾驶甲级测绘资质集团内拥有自动驾驶甲级测绘资质不具备甲级测绘资质，但也都高度注重数据合规性及数据安全背靠百度，强大的产研团队定制标注工具，对算法行业理解深刻全面的法务合规团队与政府合作共建大规模、稳定的数据标注基地对互联网行业具备深刻的数据需求理解主要采取灵活的众包和人力外包模式，暂无自建标注团队对互联网行业具备深刻的数据需求理解千人规模的自建标注团队可保障交付质量具有多年专业化基础数据服务经验，具备较强的服务响应能力拥有无锡与大连两处自建标注中心团队，具备一定规模的内部交付团队语音领域具有深厚资源，能够提供标注数据集产品具备专业化标注基地，承接业务种类丰富基于百度AI基础数据服务能力、云资源、算法能力提供强大的全栈式服务能力拥有相对完善工具链产品，在自动驾驶行业积累丰富，帮助企业自建自研能够提供基于阿里云的包括云资源、工具链等功能集成的全栈式服务云资源相对稍弱，全栈式服务能力不及百度和阿里缺乏大型科技企业技术能力资源背书，主要专注于数据采集标注服务，全栈式服务能力弱，但具备一定的工具能力，可以协助客户进行数据标注工具的开发自动化自动化标注能力标注能力专业化基础数专业化基础数据服务能力据服务能力全栈式全栈式服务能力服务能力信息来源：德勤访谈、研究与分析顺应行业“四化”趋势，头部企业竞争优势愈加明显顺应行业“四化”趋势，头部企业竞争优势愈加明显专业资质及专业资质及合规性合规性人工智能基础数据服务白皮书 2023。欲了解更多信息，请联系德勤中国。百度数据众包拥有行业最大的自建标注团队，同时依托百度深耕人工智能多年的行业理解与经验，实现了数据标注能力与全流程业务能力的相互反哺，构建数据闭环信息来源：公司官网、公开资料整理；德勤访谈、研究与分析标杆案例：百度数据众包标杆案例：百度数据众包 2-3万稳定签约标注人员 百度数据众包在山东济南、山西临汾、重庆奉节、四川达州、甘肃酒泉、江西新余等10个地区有自建标注基地，可全力保障数据标注服务的全力保障数据标注服务的高质量交付高质量交付山东江西山西甘肃四川人员人员规模规模 图像框选100万框/天 图像分割8000帧/天 点云框选70万框/天标注标注能力能力 为基地标注人员提供综合标注技能培训 具有完善的人员考核机制和标注质检流程质量质量保障保障 AI数据处理具有高并发的需求特征，另外随着算法迭代升级和场景功能的拓展，稳定的自建标注基地带来的专业性将得以凸显稳定的自建标注基地带来的专业性将得以凸显，为高效、高质量处理客户需求提供保障庞大的自建标注团队为数据服务能力提供强力保障庞大的自建标注团队为数据服务能力提供强力保障百度强大的数据标注能力与全流程业务能力助力实现数据闭环百度强大的数据标注能力与全流程业务能力助力实现数据闭环数据标注数据标注能力能力全流程业务全流程业务能力能力基于领先的数据标注经验与平台技术积累，为AI研发与落地提供完善的基础数据提供完善的基础数据服务与私有化数据标注平台服务与私有化数据标注平台，通过科学的管理流程、自动化的标注工具、全面的数据安全与数据合规策略，帮客户在企业内部快速完成数据标注目标在人工智能商业化场景加速落地的当下，打通数据采集、传输/存储、处理挖掘、标注，以及基于数据的模型训练、仿真训练、模型优化和部署升级的数据基础服务全流数据基础服务全流程程，是数据基础服务行业高效推进业务流程的关键必备能力持续提升反哺强化不断强化的数据闭环正循环不断强化的数据闭环正循环数据闭环数据闭环人工智能基础数据服务白皮书 2023。欲了解更多信息，请联系德勤中国。百度数据众包依托自身较强的技术能力及规模化的专业标注团队，形成了强大的基础数据全栈式服务能力，提供数据管理、智能标注、感知训练评测、仿真测试服务的全面赋能，即可提供整套解决方案也可解耦使用信息来源：公司官网；德勤访谈、研究与分析百度强大的资源及能力支撑造就全栈式综合服务能力百度强大的资源及能力支撑造就全栈式综合服务能力标杆案例：百度数据众包标杆案例：百度数据众包 百度数据众包基于其丰富的数据处理与管理经验，将数据采标服务、AI算法开发者数据平台以及底层的云资源打通，通过数据管理、智能标注、感知训练评测、仿真测试服务的全面赋能，百度数据众包将帮助帮助AI开发者低开发者低成本高效构建人工智能算法技术研发成本高效构建人工智能算法技术研发、运营运营、商业化落地的全场景闭环商业化落地的全场景闭环，不仅能够基于自身平台交付高质量的数高质量的数据采集与标注助服务据采集与标注助服务，同时更能依托百度自身在AI算法开发方面的丰富经验为使用方的为使用方的AI算法快速落地算法快速落地提供支持百度云资源支撑百度云资源支撑数据标注平台数据标注平台（基于强大自建团队保障，辅以领先自动化标注能力，提供高效率高质量的数据标注服务）感知训练平台数据服务数据服务基础资源基础资源能力打通能力打通算法研发算法训练算法评测数据采集（包括脱敏及预处理）数据管理平台数据项目运营数据挖掘数据质量运营辅助数据有效管理与共享实现流水线式训练作业仿真云平台场景挖掘场景库建设仿真测试数据传输、数据存储工具链平台工具链平台为客户提供所需的部署方案在数据标注服务之上，基于深刻行业理解与强算法基因为AI开发者提供经验与工具支撑人工智能基础数据服务白皮书24 2023。欲了解更多信息，请联系德勤中国。濮清璐濮清璐德勤德勤中国中国科技科技、传媒和电信、传媒和电信行业华东区行业华东区主管主管合伙人合伙人电子邮件：廉勋晓廉勋晓德勤德勤中国中国科技科技行业主管合伙人行业主管合伙人电子邮件：林国恩林国恩德勤中国德勤中国科技科技、传媒和电信、传媒和电信行业行业主管主管合伙人合伙人电子邮件：联系我们联系我们王小璐王小璐德勤中国商业战略与研究德勤中国商业战略与研究总监总监胡佳男胡佳男德勤中国商业战略与研究德勤中国商业战略与研究经理经理李嘉程李嘉程德勤中国商业战略与研究德勤中国商业战略与研究高级咨询顾问高级咨询顾问潘乐晨潘乐晨德勤中国商业战略与研究德勤中国商业战略与研究咨询顾问咨询顾问黄鹭黄鹭德勤中国商业战略与研究德勤中国商业战略与研究咨询顾问咨询顾问濮清璐濮清璐德勤中国商业战略与研究德勤中国商业战略与研究合伙人合伙人白皮书编写团队白皮书编写团队关于德勤中国德勤中国是一家立足本土、连接全球的综合性专业服务机构，由德勤中国的合伙人共同拥有，始终服务于中国改革开放和经济建设的前沿。我们的办公室遍布中国30个城市，现有超过2万名专业人士，向客户提供审计及鉴证、管理咨询、财务咨询、风险咨询、税务与商务咨询等全球领先的一站式专业服务。我们诚信为本，坚守质量，勇于创新，以卓越的专业能力、丰富的行业洞察和智慧的技术解决方案，助力各行各业的客户与合作伙伴把握机遇，应对挑战，实现世界一流的高质量发展目标。德勤品牌始于1845年，其中文名称“德勤”于1978年起用，寓意“敬德修业，业精于勤”。德勤专业网络的成员机构遍布150多个国家或地区，以“因我不同，成就不凡”为宗旨，为资本市场增强公众信任，为客户转型升级赋能，为更繁荣的经济、更公平的社会和可持续的世界而开拓前行。关于德勤Deloitte（“德勤”）泛指一家或多家德勤有限公司，以及其全球成员所网络和它们的关联机构（统称为“德勤组织”）。德勤有限公司（又称“德勤全球”）及其每一家成员所和它们的关联机构均为具有独立法律地位的法律实体，相互之间不因第三方而承担任何责任或约束对方。德勤有限公司及其每一家成员所和它们的关联机构仅对自身行为承担责任，而对相互的行为不承担任何法律责任。德勤有限公司并不向客户提供服务。德勤亚太有限公司（即一家担保有限公司）是德勤有限公司的成员所。德勤亚太有限公司的每一家成员及其关联机构均为具有独立法律地位的法律实体，在亚太地区超过100座城市提供专业服务。请参阅 http:/ 了解更多信息。免责声明本通讯中所含内容乃一般性信息，任何德勤有限公司、其全球成员所网络或它们的关联机构（统称为“德勤组织”）并不因此构成提供任何专业建议或服务。在作出任何可能影响您的财务或业务的决策或采取任何相关行动前，您应咨询合资格的专业顾问。我们并未对本通讯所含信息的准确性或完整性作出任何（明示或暗示）陈述、保证或承诺。任何德勤有限公司、其成员所、关联机构、员工或代理方均不对任何方因使用本通讯而直接或间接导致的任何损失或损害承担责任。德勤有限公司及其每一家成员所和它们的关联机构均为具有独立法律地位的法律实体。2023。欲了解更多信息，请联系德勤中国。

46人已浏览 2023-03-21 25页 5星级

仅供机构投资者使用仅供机构投资者使用行业行业研究报告研究报告奇点将至，探他山之石从算力、算法、数据和应用看AIGC请仔细阅读在本报告尾部的重要法律声明请仔细阅读在本报告尾部的重要法律声明华西海外团队2023年3月19日朱芸执业证书编号：S1120522040001联系人：李佳妮/侯钧皓/吴嘉悦目录101 核心观点03 数据：大模型训练的基础资源02 生成式AI：ChatGPT引燃市场，数字经济未来已至05 算法：大模型算法助力AIGC突破04 算力：大模型发展带来高算力需求07 生成式AI海外受益标的08 风险提示06 产业应用：各领域应用加速落地，商业化前景广阔rRnM3ZfWbZeUpX9YyXaQdN7NoMqQsQoNkPqQmPjMsQrR7NqRmNMYtRqPxNrMvMAIGC未来已来，超预期持续出现从2018到2023年，四代GPT模型高速进步，从简单的问答、阅读理解、文本总结，到在众多测试中获得“人类级别表现”评级，AI迭代进化的速度越来越快。可以预期，AI达到人类智能水平、乃至超越人类智能水平的时代会以超预期的形态和速度出现。数据、算力、算法为AIGC核心要素，海内外厂商各占鳌头数据，通过算力，最后产生了算法或者应用。数据作为新兴生产要素，数据的拥有者、加工者是产业发展的基础。算力作为基础设施，是AIGC资本开支的主要受益者，核心参与者英伟达、AMD竞争优势显著。AIGC的技术壁垒主要体现在算法上，当前通用型AI由GPT领跑，而在细分领域上，行业内的主要参与者包括谷歌、Meta、Anthropic、Hugging Face和百度等公司。随着细分龙头竞相研发创新算法和优化现有技术、以及模型迭代下对数据、算力的需求高速膨胀，AIGC行业技术壁垒将不断提高，现有优秀参与者护城河极深。AIGC市场潜力巨大，应用领域迎来生产力解放根据Tractica的预测数据显示，全球AI软件市场规模将在2025年达到1260亿美元，2021年到2025年年复合增长率为41.02%。一级市场的火热也反映了AIGC发展的确定性趋势。在大模型的快速迭代推动下，搜索引擎、办公软件、汽车、媒体、AI绘画设计、AI广告营销、智能工作助理等应用率先落地的行业将具备较强商业化机会。报告亮点：作为海外团队，我们期待该篇报告能够尽可能呈现海外市场当前在生成式AI(AIGC)领域的布局和进展，从算力、算法、数据和应用入手，看清趋势，寻找差异。一是尽可能减少我们对海外认知的信息差，更重要的是，他山之石，可以攻玉，海外映射是国内可以持续关注的重点。核心观点核心要点：风险提示：技术落地商业化不及预期人工智能在部分领域应用的监管风险外部环境导致芯片、软件等供应限制投资建议：我们认为生成式AI模型不断加速迭代，将快速推动生成式AI技术的商业化推广应用的进程，带动产业三大要素数据、算力、算法和应用的高速发展。后续建议密切关注生成式AI产业链上四条投资主线：（1）数据是大模型训练的基础资源，随着大模型项目迭代发展，对训练用数据集需求将不断上升，受益标的为数据提供商龙头Appen（APX.AX）；（2）大模型发展带来高算力需求，人工智能芯片市场巨大，受益标的为英伟达（NVDA.O）、AMD（AMD.O）；（3）各大厂商布局大模型算法项目，龙头科技企业具有技术优势，受益标的为微软（MSFT.O）、谷歌（GOOG.O）、Meta（META.O）、百度（BIDU.O/9888.HK）；（4）生成式AI商业化应用落地领先领域，受益标的为自动驾驶技术公司Mobileye（MBLY.O)、数字媒体Buzzfeed（BZFD.O）、办公软件微软（MSFT.O）。核心观点目录401 核心观点03 数据：大模型训练的基础资源02 生成式AI：ChatGPT引燃市场，数字经济未来已至05 算法：大模型算法助力AIGC突破04 算力：大模型发展带来高算力需求07 生成式AI海外受益标的08 风险提示06 产业应用：各领域应用加速落地，商业化前景广阔AIGC(AI Generated Content)即生成式AI，多领域应用逐渐成熟。AIGC涉及无监督和半监督学习算法，截至目前其发展历程主要分为三个阶段：统计机器学习方法阶段（2010年前）：首先对数据进行手工标注，然后构建其重要特征，最后构建概率模型并进行参数优化，从而将概率最大的输出作为结果；基于深度学习的神经网络模型（2010年-2017年）：深度学习算法被引入，本质上是通过大量数据训练神经网络，主要表现形式为：CNN（卷积神经网络）、RNN(循环神经网络）等。相比统计学习方法，省去了复杂且手工的特征构建；基于Transformer结构的预训练模型（2017年至今）：利用大量无标注数据进行自监督学习，然后再使用少量的标注数据对下游任务进行微调（即迁移学习）。在应用方面，按场景分类AIGC已经较为成熟地应用于文本和代码撰写、图像识别和生成，以GPT为首的AIGC模型也正在探索消费级AI技术的变现方式。展望未来，AIGC不仅会在现有应用领域持续进步，也将逐步拓展到视频和游戏领域，AIGC将会在更多的领域得到广泛应用，为各个行业和领域的发展和进步提供更多可能性。表1：AI应用发展进程预测2020前20202022预计2025预计2030预计2050文本垃圾邮件检测翻译基础问答基础文案撰写生成草案撰写更长文章完善文稿对科学论文等进行垂直微调文章终稿超过人类平均水平文章终稿超过专业作者水平代码单行自动完成多行代码生产更长代码更高准确度更多语言深度提高文本到产品（草稿）文本到产品（终稿），超过大部分开发者图像艺术Logo摄影产品设计、建筑等模型产品设计、建筑等终稿终稿超过大部分专业艺术家、设计师、摄影师水平视频/3D/游戏视频和3D制作的初稿完善版本AI创作平台游戏和电影实现个性化定制开始尝试基本完成黄金时期 生成式AI：自然语言处理演变十余年，迎来变现阶段OpenAI创立于2015年12月，发布ChatGPT引燃AI行业热度。GPT系列是OpenAI打造的自然语言处理模型，采用以Transformer结构为核心的模型，其最大特点是使用了大量的未标注的语料进行无监督的预训练，然后在各种有监督的任务上进行微调。OpenAI于2022年11月先后推出了GPT-3.5和ChatGPT，GPT-3.5使用了更新的语料进行预训练，而ChatGPT是基于GPT-3.5的对话机器人，能够根据用户的输入生成流畅、有逻辑的回答，以及完成撰写论文报告、翻译文字、编写代码等文本生成任务，并且能根据聊天的上下文进行互动。ChatGPT发布后爆火，仅用5天时间用户量便破百万，推出2个月后用户量破亿，成为史上用户增长速度最快的消费级应用程序。3月14日，OpenAI进一步推出GPT-4.0，相比当前ChatGPT使用的GPT-3.5，增加了输入图像的功能；扩写能力增强，能处理超过25000个单词的文本；更具创造力，并且能够处理更细微的指令。GPT模型迭代的参数量及训练量均呈指数级增长，使得AI从实验技术成长为稳定生产力。图1：ChatGPT仅发布5天便达到百万用户资料来源：Statista，TRTWorld,华西证券研究所0200400600800100012001400NetflixAirbnbTwitterFoursquareFacebookSpotifyInstagramChatGPT用户量达到100万时间（天）生成式AI：GPT模型迭代四大版本，进化速度不断提升GPT模型稳定进步，AI已是成熟生产工具。从GPT-1到最新发布的GPT-4模型，其应用已经不仅局限于问答、阅读理解等文本处理，虽然目前GPT-4在现实场景中的能力可能不如人类，但在各种专业和学术考试上表现出明显超越人类水平的能力，GPT-4在模拟律师考试中，分数排在前10%；相比之下，GPT-3.5的得分则在倒数10%附近。随着算力、算法、数据量的演进，行业内不断出现高质量的AI产品，微软New Bing、AI绘画、智能驾驶等等，体现出AI未来在多个领域的应用潜力。ChatGPT版Office、百度“文心一言”两大产品正式推出，或将AI的生产力推向新的高度。图2：GPT 4.0 数学能力大幅提升 生成式AI：AI产品全面开花，生产力将达新高度AI行业星辰大海，数字经济未来已至。从2018到2023年，四代GPT模型高速进步，从简单的问答、阅读理解、文本总结，到在众多测试中获得“人类级别表现”评级，此外近期AI衍生产品的层出不穷，显现出背后AI行业的星辰大海。2020年，马斯克预言五年内人工智能将比人类更聪明，当前AI迭代进化的速度越来越快，虽然GPT还未通过图灵测试，距离真正的“智能”还有距离，但我们认为，AI达到人类水平、乃至超越人类的时代即将到来。表2：历代GPT学习目标及表现情况 模型发布时间参数量预训练数据量学习目标模型表现GPT-12018年6月1.17亿约5GB无监督语言模型（Pre-training）有监督fine-tune在9/12任务中获得“先进”表现：问答、阅读理解、文本总结GPT-22019年2月15亿40GB多任务零次学习Zero Short Task Transfer在7/8任务中超过“先进”表现随着模型参数变多，模型的表现呈现log-linear上升，没有到达瓶颈GPT-32020年5月1,750亿45TB语境学习小样本学习在小样本学习、单样本学习、零样本学习中表现突出GPT-42023年3月待公布基于规则的奖励模型(RBRM)在GLUE,SuperGLUE,SQuAD等测试中获得“人类级别表现”拥有图像处理能力生成式AI：AI进化加速，数字经济未来已至数据，通过算力，最后产生了算法或者应用。AIGC是人工智能、大数据、云计算、5G等多个技术领域的整合，是一种跨领域的合作发展模式。在AIGC行业中，算力、算法、数据是三个核心概念，它们共同构成了这个领域的基础设施。未来随着技术的进步和应用场景的不断拓展，这三个概念将继续发挥重要作用，推动整个行业的创新和发展。算力（Computing Power）：算力是指计算设备执行算法、处理数据的能力，包括CPU、GPU、FPGA、ASIC等。云计算技术和5G通信技术的发展使得算力的分布和调度更加灵活，有助于满足各种场景下对高性能计算的需求。算法（Algorithm）：算法是一系列解决问题、实现特定功能的有序指令和步骤。在AIGC行业中，算法是模型的基础，用于实现数据分析、人工智能模型训练等功能。数据（Data）：在AIGC行业中，数据是支撑决策和优化的基础，是算法发挥作用的前提。大数据技术可以对海量数据进行有效处理、分析和存储，而人工智能技术可以通过对数据进一步学习，实现各种智能化应用，如图像识别、自然语言处理等。表3：AIGC行业三大核心概念 核心概念描述应用及关联技术算力（Computing Power）衡量计算设备执行算法、处理数据的能力，关系到系统的运行效率和任务完成速度。数据中心、分布式计算、云计算、边缘计算、高性能计算（HPC）算法（Algorithm）解决问题、实现特定功能的有序指令和步骤，是计算机程序的基础，用于实现各种功能。机器学习（ML）、深度学习（DL）、自然语言处理（NLP）、计算机视觉（CV）、推荐系统等数据（Data）对现实世界的描述和反映，以数字、文字、图像等形式表现，是支撑决策和优化的基础。数据挖掘、数据分析、数据仓库、数据可视化、数据安全、隐私保护等生成式AI：算力、算法、数据三位一体目录1001 核心观点03 数据：大模型训练的基础资源02 生成式AI：ChatGPT引燃市场，数字经济未来已至05 算法：大模型算法助力AIGC突破04 算力：大模型发展带来高算力需求07 生成式AI海外受益标的08 风险提示06 产业应用：各领域应用加速落地，商业化前景广阔数据是训练大模型的基础资源，以GPT系列模型为例，对比三代模型间使用的数据集，训练所需的数据集在质量和数量方面均不断提升。随着人工智能模型迭代发展，高质量数据集的需求将进一步增长。模型数据集概要GPT-1BooksCorpus（7000不同的未发表的书籍，包括冒险、幻想、浪漫等题材，数据集中包含大量连续文本）GPT-2在Reddit上爬取的外链，构建了WebText数据集，包含了这4500万个链接的文字子集，移除了所有的Wikipedia文档，因为它是很多下游任务的数据源，这是为了避免数据集重叠而影响评估GPT-3使用Common Crawl数据集(几乎包含整个互联网的数据)，进行了3步过滤操作，增加了一些高质量数据集，最终采用混合数据集输入。数据集大小合计将近5千亿tokens表4：GPT系列模型训练使用数据集概要图3：GPT-3模型训练使用数据集概况 数据：大模型训练的基础资源，需求不断扩大 从自然数据源简单收集取得的原料数据并不能直接用于有监督的深度学习算法训练，必须经过专业化的采集、加工，形成相应的工程化训练数据集后才能供深度学习算法等训练使用。目前，带有监督学习的算法对于训练数据的需求远大于现有的标注效率和投入预算，基础数据服务将持续释放其对于算法模型的基础支撑价值。公司主营业务公司优势海天瑞声AI训练数据的研发设计、生产及销售业务1.拥有的成品训练数据集数量大，在产品领域覆盖方面比较完善2.已取得专利授权28项，计算机软件著作权159项，对比同业公司在专利技术储备方面具备一定优势3.公司的产品和服务已获得字节跳动、阿里巴巴、腾讯、百度、科大讯飞、海康威视、微软、亚马逊、三星、中国科学院、清华大学等国内外客户的认可，市场认可度较高澳鹏（Appen）数据采集和标注解决方案1.覆盖超过235个语种/方言，语言覆盖面具有优势2、成立于1996年，经营历史较长，规模较大，拥有人工智能辅助数据注释平台，在全球170多个国家与100多万名专业承包合作3.客户包括亚马逊、微软、谷歌等全球大型科技公司，产品质量得到认可标贝科技智能语音交互和AI数据服务1.拥有语音合成模型和算法，可覆盖音乐类训练数据。拥有TOBI标注体系，通过自主研发的TTS评测系统，提供高质量的数据服务。2.已与微软、百度、阿里、腾讯、京东、滴滴、字节跳动等国内外百余家企业客户建立合作，服务项目累计超过1000项表5：数据服务商部分公司概况 数据：大模型训练的基础资源，需求不断扩大目录1301 核心观点03 数据：大模型训练的基础资源02 生成式AI：ChatGPT引燃市场，数字经济未来已至05 算法：大模型算法助力AIGC突破04 算力：大模型发展带来高算力需求07 生成式AI海外受益标的08 风险提示06 产业应用：各领域应用加速落地，商业化前景广阔334.7 4,773.7 01,0002,0003,0004,0005,0006,00020212030E全球GPU市场规模（亿美元）AIGC模型硬件以GPGPU为主，GPU市场规模有望在2030年超过4000亿美元。GPU在并行计算方面具有性能优势，在AI领域分化成两条分支：一条是传统意义的GPU，专门用于图形图像处理用途；另一条是GPGPU，作为运算协处理器，增加了专用指令来满足不同领域的计算需求。使用GPGPU在云端进行模型训练算法能够显著缩短海量训练数据的训练时长，减少能源消耗，从而降低人工智能的应用成本，目前全球人工智能相关处理器解决方案仍以GPGPU为主。根据VerifiedMarketResearch报告，2021年全球GPU芯片市场规模已经达到了334.7亿美元，并预计到2030年将达到4,773.7亿美元，CAGR高达33.3%。GPU市场保持着高速增长态势，其在人工智能领域中仍然是不可或缺的计算资源之一。图4：全球GPU市场规模预测 CAGR：33.3%算力：算力需求不断攀升，GPU行业市场巨大英伟达：高算力芯片龙头，AI芯片市场地位领先。人工智能平台需要巨大的数据处理能力，英伟达的A100显卡适合于支持ChatGPT、Bard等工具的机器学习模型，这款芯片能够同时执行众多简单的计算，而这对于训练和使用神经网络模型很重要，使得A100显卡成为目前主流AI芯片。长期展望，AI芯片市场快速增长将带动英伟达营收快速增长，根据中商产业研究院数据显示，预计全球AI芯片市场规模有望从2020年的约175亿美元提升到2025年的726亿美元，年复合增长率32.9%。根据花旗集团预估，ChatGPT 的使用可能会在 12 个月内为英伟达带来 30 亿至 110 亿美元的销售额。算力：英伟达芯片龙头市场地位稳固图5：A100等显卡大模型训练速度 图6：A100等显卡机器学习性能 AMD：高算力芯片代表企业，即将推出世界首款集成数据中心CPU和GPU的APU产品。在2023年的CES上，AMD预览了AI推理加速器AMD Alveo V70，主打高能效，峰值AI算力可达到400TOPS，TDP仅75W。AMD称这是最强AI算力的75W TDP级产品。AMD还预览了其首款集成数据中心CPU和GPU的APU产品AMD Instinct MI300。该款产品采用了Chiplet封装理念。Chiplet策略是一项重要的硬件创新，摆脱了单芯片微缩的限制，同时能够优化设备的性能、功耗和性价比。MI300加速器专为领先的高性能计算（HPC）和AI性能而设计，借助3D封装技术将CPU和加速计算单元集成在一起，总共有1460亿个晶体管。图7：AMD在CES上介绍V70 图8：AMD在CES上介绍MI300 算力：AMD封装理念Chiplet领先，推出高性能APU全球GPU市场中英伟达和AMD占据96%份额，国内GPU主要研发企业为海光信息、寒武纪等。根据Wccftech，2022Q3独立GPU市场中英伟达和AMD分别占据88%、8%市场份额。根据海光信息招股书公布技术指标数据，当前国内高端GPU相比国际巨头在显存频率、带宽等参数上还有一定差距，但在典型应用场景下，深算一号已基本能够达到国际上同类型高端产品的水平。在国际市场上，英伟达和AMD在高性能计算和人工智能领域具有丰富的产品线和完善的生态系统，叠加长期积累的技术优势和市场地位，预计仍将长期维持AI算力芯片领域的龙头地位。算力：英伟达、AMD垄断全球，国产芯片奋起直追表6：深算一号与NVIDIA、AMD高端产品技术规格对比 核心概念海光NVIDIAAMD品牌深算一号Ampere 100MI100生产工艺7nm FinFET7nm FinFET7nm FinFET核心数量4096(64 Cus)2560 CUDA processors640 Tensor processors120 CUs内核频率Up to 1.5 GHz(FP64)Up to 1.7 GHz(FP32)Up to 1.53 GHzUp to 1.5 GHz(FP64)Up to 1.7 GHz(FP32)显存容量32 GB HBM280 GB HBM2e32 GB HBM2显存位宽4096 bit5120 bit4096 bit显存频率2.0 GHz3.2 GHz2.4 GHz显存带宽1024 GB/s2039 GB/s1228 GB/sTDP350 W400 W300 WCPU to GPU互联PCIe Gen4 x 16PCIe Gen4 x 16PCIe Gen4 x 16GPU to CPU互联xGMI x 2Up to 184 GB/sNVLinkUp to 600 GB/sInfinity Fabric x 3Up to 276 GB/s高端芯片进口受限，国产芯片需求加速扩大。在NVIDIA、AMD高端产品被限制向中国出售的情况下，国产大模型算力需求将快速推动国产芯片市场增长，当前国产GPGPU芯片的研发和生产已经取得了一定的进展，海光、炬芯、寒武纪等企业均拥有具备自主知识产权的GPU芯片，为国内高性能计算和人工智能领域的发展提供了重要支持。根据前瞻产业研究院，国产人工智能芯片自2020年来呈爆发式增长，2023年市场空间预计将超过1,300亿元，2020-2023年CAGR为95.86%。总体而言，在国际关系紧张、芯片进口受限的前提下国产人工智能芯片市场未来的发展前景广阔，随着国内厂商加大研发投入和技术创新力度，进一步提升产品性能，看好其在国内乃至国际市场中获得更多的份额和竞争优势。算力：国产芯片发展迅速，填补AI市场空缺图9：中国人工智能芯片行业规模（亿元）59.45 112.87 177.18 429.90 843.71 1,331.22 89.86V.982.63.26W.78%0 0000004006008001,0001,2001,4002018201920202021E2022E2023E目录1901 投资要点03 数据：大模型训练的基础资源02 生成式AI：ChatGPT引燃市场，数字经济未来已至05 算法：大模型算法助力AIGC突破04 算力：大模型发展带来高算力需求07 生成式AI海外受益标的08 风险提示06 产业应用：各领域应用加速落地，商业化前景广阔在算法领域，目前通用型AI的领军者是OpenAI，其发布的GPT-4模型是一种多模态语言模型，能接受图像和文本输入，再输出正确的文本回复。相较于ChatGPT基于的GPT-3.5模型，它拥有强大的识图能力，文字输入限制提升，准确性显著提高，风格上也有了变化，例如能够生成歌词和创意文本。在细分领域中，行业内的主要参与者包括以下公司：谷歌的PaLM-E模型是目前已知最大的视觉语言模型，并且将模型接入至机器人，实现可通过机器人执行命令，深耕将AI大模型应用到机器人领域。Meta的FAIR团队专注于研发用于辅助研究群体进行研究工作的大模型，其“LLaMA”模型参数量较少，但同样基准测试结果同样优秀。而较小的模型大小带来的是模型训练、运行成本的降低，实现以低成本使用大模型AI。Anthropic专注于人工智能的安全道德领域，其聊天机器人Claude在对有害性输入的应对上表现得更加优异，更擅长拒绝有害词。其提出的Constitutional AI（CAI）技术有望在未来对所有AI实施有效性安全监督。Hugging Face致力于构建开源模型库，集成了诸多人工智能模型，并在TensorFlow和Pytorch上做了一层抽象，屏蔽了机器学习框架的细节，并非常重视易用性。作为一个开源社区，其中立的第三方平台身份有助于聚集行业顶尖的社区贡献者，吸引社区贡献者将其模型集成到公司模型库中，或者是在公司模型库中构建模型。百度作为国内首个发布类ChatGPT聊天机器人产品的公司，是国产大模型的领导者。其产品“文心一言”尽管与ChatGPT有一定差距，但在中文领域展现出了独特的中文理解能力，并且出于数据安全、外部因素限制等角度考虑，国产大模型仍是必需，具备硬性市场需求。算法：OpenAI领跑通用型AI，各大厂商各有千秋Azure算力支持，数亿投入始现回报。GPT系列是OpenAI打造的自然语言处理模型，基于文本预训练的GPT-1，GPT-2，GPT-3三代模型都采用以Transformer结构为核心的模型。微软在2019年向OpenAI投资10亿美元，并为OpenAI建造了一台由数万个A100 GPU组成的大型AI超级计算机，成本或超过数亿美元。GPT模型正是由这台超级计算机提供支持，OpenAI试图训练更多需要学习海量数据、拥有超大参数规模的AI模型，需要长期访问强大的云计算服务，GPT-3的参数量达到了1,750亿，微软构建了一个可在非常大的范围内运行且可靠的系统架构，这使得ChatGPT成为可能。图10：微软发布NDm A100 v4 Public AI 超级计算机在ChatGPT的成功后，微软近日宣布了 NDm A100 v4 Public AI 超级计算机，并在21 世纪超级计算大会的TOP500 榜单中取得了前十的优异成绩。随着GPT模型的参数规模和数据量持续膨胀，Azure的强大算力支持是GPT持续完善的保障。算法：微软Azure超算为GPT提供保障OpenAI正式发布多模态预训练大模型 GPT-4，识图能力强大，实现多模态能力。相较前一代GPT-3.5，其主要在两方面实现飞跃式提升：（1）具备了强大的识图能力，可以接受图像和文本输入；（2）回答准确性显著提高。OpenAI目前已升级ChatGPT，ChatGPT Plus 订阅者可以获得具有使用上限的 GPT-4访问权限，开发者则可以通过注册等待以获取GPT-4的API访问权限。GPT-4 可以接受文本和图像形式的 prompt，新能力与纯文本设置并行，允许用户指定任何视觉或语言任务。具体来说，它能在用户给定由散布的文本和图像组成的输入的情况下生成相应的文本输出（自然语言、代码等）。图12：GPT-4识别论文图片生成概要 图11：GPT-4识图能力实例算法：ChatGPT引入最新模型GPT-4具备识图能力 相较GPT-3.5，回答准确性显著提高。根据OpenAI公布数据显示，GPT-4在专业和学术方面表现优异，在诸多标准化考试中均取得了优秀的分数。比如其能通过模拟律师考试，且分数在应试者的前10%左右，相比之下，GPT-3.5的得分在倒数 10%左右。GPT-4在GRE（Graduate Record Examination）数学考试中取得应试者前20%左右成绩，而GPT-3.5仅能排在应试者后25%。GPT-4在大部分语言上的准确性均超过了GPT-3.5在英语上的表现。OpenAI使用 Azure Translate将 MMLU 基准 一套涵盖 57 个主题的 14000 个多项选择题 翻译成多种语言。在测试的 26 种语言的 24 种中，GPT-4 优于 GPT-3.5 和其他大语言模型（Chinchilla、PaLM）的英语语言性能。图13：GPT-4标准化考试成绩图14：GPT-4在不同语言上的准确性算法：GPT-4模型回答准确性显著提高 谷歌：发布目前最大视觉语言模型PaLM-E，有望率先落地智能机器人相关产品。PaLM-E是一种多模态视觉语言模型（VLM），具有 5620 亿个参数，是全球已知的最大视觉语言模型。根据谷歌公布的演示视频显示，只需要给 PalM-E 下达一条高级命令，比如“把抽屉里的薯片拿给我”，它就可以给一个带机械臂的移动机器人平台（由谷歌机器人开发）生成行动计划，然后自行执行。PaLM-E 通过分析来自机器人摄像头的数据来实现这一点，整个过程不需要对场景表示进行预处理。并且，PaLM-E表现出了“正迁移”，又称助长式迁移，它能把一项任务中学到的知识和技能迁移至另一项任务，而且与单任务机器人模型相比具有“明显更高的性能水平”图15：PaLM-E具备能力一览资料来源：Google research，华西证券研究所算法：最大视觉语言模型PaLM-E，可操控机器人Meta：“LLaMA”致力于辅助学术研究人员完成研究工作。LLaMA（Large Language ModelMeta AI）模型参数相对少，意味着运行模型算力要求较低，但基准测试表现优秀。同ChatGPT、NewBing不同，LLaMA是一个开源的“研究工具”，旨在完成在文本生成、问题回答、书面材料总结，以及自动证明数学定理、预测蛋白质结构等工作帮助研究人员推进研究工作。根据Meta发布的信息，LLaMA包含4个基础模型，参数分别为70亿、130亿、330亿和650亿。其中，LLaMA 65B 和 LLaMA 33B在1.4万亿个tokens上训练，而最小的模型LLaMA 7B也经过了1万亿个tokens的训练。在大多数基准测试中，参数小的多的LLaMA-13B的性能优于GPT3.5的前身GPT3-175B，而LLaMA-65B更可与业内最佳的Chinchilla-70B和PaLM-540B竞争。图16：LLaMA的训练损失函数图图17：LLaMA在基础问题解决中的表现算法：针对研究群体的模型“LLaMA”，目标明确 Anthropic：聚焦“安全”的人工智能，或将成为AI安全领域专家。随着大语言模型的发展，AI在很多任务上的能力将会超过人类，这将让人类无法监督模型。为了确保 AI 在超过人类能力后仍保持安全性，需要开发一种可扩展的模型监督技术。CAI（Constitutional AI）技术即是这种模型监督技术，原理是人类可以指定一套行为规范或原则，而不需要手工为每个有害输出打标签，模型根据这套行为规范和准则选择最佳结果。Anthropic所开发的聊天机器人Claude，在对话安全领域上做得更为突出，更擅长拒绝有害词或有害的引导，与人类价值观更加相符。并且CAI技术有望对未来所有人工智能模型实施有效安全性监督。图18：Constitutional AI（CAI）技术流程示意图算法：对人工智能的安全性监督日益重要 Hugging Face：与亚马逊旗下云计算部门AWS扩大合作，将在AWS上构建下一个版本语言模型。近日，AWS宣布与美国明星AI创企Hugging Face扩大合作，以加速构建生成式AI应用的大型语言模型和大型视觉模型的训练、微调和部署。Hugging Face是OpenAI的主要竞争对手之一，其主要业务包括生产AI产品和托管其他公司开发的产品，已发展成AI开发者共享开源代码和模型的在线中心之一。据AWS数据库、分析和机器学习副总裁Swami Sivasubramanian透露，Hugging Face将在AWS上构建其语言模型的下一个版本BLOOM。该开源AI模型在规模和范围上将与OpenAI用于研发ChatGPT的大型语言模型竞争，将运行在AWS自研AI训练芯片Trainium上。图19：BLOOM模型结构算法：构建AI开发平台，加速AI模型迭代更新百度：国内首个类GPT产品，有望在外部压力驱动下快速推动国内应用结合落地。“文心一言”尽管模型能力水平上与ChatGPT等有一定差距，但在下游应用逐步对接后，有望依靠合作伙伴的高质量数据集快速提升模型能力。由于国内无法使用ChatGPT的API接口，且出于数据安全等角度考虑，势必需要国产大模型，百度“文心一言”作为国产大模型的先行者，在国内政策扶持和产业链协同发展的背景下，将进一步加速国内AI技术进步和产业化进程，填补市场空缺。根据百度文心大模型的布局全景，“文心一言”有望通过飞桨开源开放平台、百度智能云等赋能到工业、能源、金融、通信、媒体、教育等各行各业，通过接入合作伙伴的方式，进一步获取高质量数据集以强化模型训练调整，快速提升模型性能。图20：百度文心大模型布局全景算法：国产大模型奋力追赶，行业布局广泛尽管当前版本“文心一言”仍具备提升空间，但在中文理解能力上，相较ChatGPT等国外模型，其具备一定的“主场优势”，有望在国内中文环境下实现较好的应用效果。在关于东北烧烤店取名的提问中，ChatGPT的回答中夹杂了“周家烤鸭店”、“炸酱三绝串串香”等看似具有相似性，但实际不符合问题要求的答案；而文心一言则回答答案均符合要求，且呈现出了不同答案的取名逻辑。在创作藏头诗的任务中，ChatGPT没有能够正确理解“藏头诗”的含义，而文心一言的创作明显更胜一筹。由此可见，文心一言在中文理解领域上确实相较更有优势，或更加适合中国市场。图21：ChatGPT关于烧烤店取名回答图22：“文心一言”关于烧烤店取名回答图23：ChatGPT关于藏头诗创作图24：“文心一言”关于藏头诗创作算法：相比ChatGPT，“文心一言”在中文理解领域上具备优势 目录3001 投资要点03 数据：大模型训练的基础资源02 生成式AI：ChatGPT引燃市场，数字经济未来已至05 算法：大模型算法助力AIGC突破04 算力：大模型发展带来高算力需求07 生成式AI海外受益标的08 风险提示06 产业应用：各领域应用加速落地，商业化前景广阔AIGC市场潜力巨大，即将实现多领域应用。根据Tractica的预测数据显示，全球AI软件市场规模将在2025年达到1260亿美元，2021年到2025年年复合增长率为41.02%。在大模型的快速迭代推动下，AIGC市场预计将保持高速增长，市场潜力巨大。生成式AI领域在一级市场同样受到青睐，全球早期资金调研机构CB Insights最新报告显示，2022年有110笔创投交易和ChatGPT概念有关，投资资金超过26亿美元。我们预计搜索引擎、办公软件、汽车、媒体、AI绘画设计、AI广告营销等应用率先落地的行业将具备较强商业化机会，AI服务将极大解放生产力，带来行业新模式。图25：全球AI软件市场规模 870 1,198 1,650 2,275 3,139 4,335 5,990 8,290 11,480 15,910 37.707.737.858.008.108.188.408.488.597.27.47.67.88.08.28.48.68.8%-2,000 4,000 6,000 8,000 10,000 12,000 14,000 16,000 18,00020212022E2023E2024E2025E2026E2027E2028E2029E2030EAI产业全球市场规模（亿美元）YOY产业应用：AIGC市场潜力巨大，落地领域迎来生产力解放搜索引擎的主要代表为微软Bing。根据用户搜索内容，必应将生成相应问题答案的方案，比如当用户输入“计划一次为期五天的墨西哥之旅”的命令时，除了返回一些网址链接供你参考之外，跟使用ChatGPT 一样，必应对话框会直接给你写出一个方案，用户可以直接复制这个答案，不满意的话也可以要求它再生成一个另外的方案，而必应可能会在回复中给出与搜索内容相关的广告。由于生成式搜索下回复将对用户具有更高的匹配度，因此广告也将更符合用户需求。例如，当用户搜索精灵宝可梦：朱/紫时，聊天机器人在对其进行介绍后，询问用户“是否有兴趣购买朱与紫？”并附带了相应广告链接。在另一个关于罗尼-科尔曼的搜索中，Bing提供了关于这位退休的职业健美运动员的详细信息，并生成了带有图片、链接和价格的健美产品。图26：Bing搜索宝可梦朱/紫结果 图27：Bing搜索罗尼-科尔曼结果【搜索引擎】微软（MSFT.O）：高质量广告更加符合用户需求 微软于3月6日表示，其 Power Platform 平台上的一系列商业智能和应用程序开发工具，包括 Power虚拟代理（Power Virtual Agent）和 AI Builder，均已更新 ChatGPT 功能。Power 虚拟代理是一款供企业构建聊天机器人的工具，如今可以连接到公司内部资源，生成周报和客户查询的摘要。而用 AI Builder，则可以很容易地使用 GPT 模型创建文本。比如，研究人员可以从每周发布的报告中总结文本，发到自己的邮箱里，一遍快速提供信息，识别当前趋势。3月17日，微软宣布GPT-4全面接入Office，以插件助手Microsoft 365 Copilot形式辅助办公。PPT、Word、Excel均可使用该AI功能：Word，可以直接给一句简短的描述让它帮你生成文档初稿；Excel，根据输入需求自动分析、整理数据；PPT，可以通过其他文件内容生成精美PPT，并可以根据要求快速修改（简化内容、替换图片等）。预计随着Copilot的应用，将为办公模式带来全面变革，提升办公效率，解放生产力。图28：Power Virtual Agent使用界面图29：Copilot通过一句话分析excel数据趋势【办公软件】微软（MSFT.O）：AI助手解放生产力，办公模式迎来变革 自动驾驶：Mobileye自动驾驶技术领先，若能加入AIGC大模型将如虎添翼。根据GuidehouseInsights的报告，以技术成熟度、产品能力等因素评价，自动驾驶领域由Mobileye、Waymo、百度和Cruise 领先。基于Transformer架构设计的模型思路对自动驾驶领域有很强的借鉴作用，比如ViT（VisionTransformer）模型，它是一种基于Transformer的视觉模型，可以在不使用CNN卷积神经网络的情况下进行图像分类，在自动驾驶图像识别中应用；生成式AI技术有望进一步推动自动驾驶技术的快速发展，为未来的出行带来更加安全、便捷和智能的解决方案，实现更高等级的自动驾驶系统。图31：VIT模型结构【汽车】Mobileye（MBLY.O）：自动驾驶或达新高度 图30：全球自动驾驶系统排名资料来源：Guidehouse Insights，华西证券研究所智能语音助手：大模型下的语言训练，可以通过微调进入汽车领域用于汽车语音识别系统，帮助驾驶员实现语音控制，如语音导航，电话，音乐等。之后从汽车客户服务上来讲，帮助提供快速，准确和个性化的客户服务，从而提高客户满意度。通用汽车几乎是国外第一家正式宣布引入ChatGPT的车企，其正在与OpenAI合作开发一个基于支持ChatGPT的相同机器学习模型的车内数字助理，以帮助客户帮助车主获取车辆使用的相关信息，比如车主可以使用自然语言询问如何处理某种情况，例如如果用户轮胎被刺破了如何更换轮胎；仪表盘跳出某个指示灯建议驾驶员采取什么行动等等。图32：通用汽车或实现车载GPT数字助理【汽车】通用汽车（GM.N）：与OpenAI达成合作，提升车载助手智能程度资料来源：New York Post，华西证券研究所根据CBS消息，美国知名媒体BuzzFeed宣布与OpenAI合作，将从“Quizzes”栏目入手，引入生成式AI进行内容创作。该栏目主要由一系列有趣的问题测试组成，比如包括“测测你是迪士尼里的哪位公主”，“你最像复仇者联盟里的哪位超级英雄”之类等，根据用户回答生成个人报告。ChatGPT接入到Buzzfeed后，将被用于为每位客户生成个性报告的编写过程中，AI的自动化生产内容将为这一工作缩减不必要的人工劳动，从而降低内容生产的成本，有望迎来人力成本的解放。根据Buzzfeed同创办人兼执行长Jonah Peretti表示，AI将会被应用在建立测验、集思广益，并协助为阅听众提供客制化内容，帮助媒体作者提高效率。图33：BuzzFeed的Quizzes栏目【媒体】Buzzfeed（BZFD.O）：率先落地AI，互动更加个性化目前该行业领域暂无对应上市公司，主要公司之一为Stability AI。Stability AI是一家元宇宙及数字媒体工具开发商，构建了可制作数字艺术的AI绘画平台“Stable Diffusion”，该工具是一种根据描述生成图片的AI技术模型。只需输入简单的文字描述，其就能在几秒钟内自动生成一幅真实的画作。AI技术的发展让人们的想象逐渐成为现实。无论是需要一个角色立绘，还是设计场景背景，均可以通过AI绘图工具迅速完成。该类AI绘图应用有望为设计绘画行业带来效率的极大提升，释放大量人工劳动力，人类所扮演得角色将更倾向于提出意见，而不是亲自做图。目前AI绘画已能通过不断修改调整“提示词”生成高水平的艺术画作，名叫杰森艾伦（Jason Allen）的艺术家通过AI绘图工具生成的作品，在美国科罗拉多州博览会的艺术比赛中获得了第一名。图34：Stable Diffusion模仿毕加索生成的画作资料来源：Stability AI，公开资料整理、华西证券研究所图35：美国科罗拉多州博览会的美术比赛中获奖AI画作【设计绘画】Stability AI：AI高效绘图，改变行业工作模式资料来源：Stability AI，公开资料整理、华西证券研究所游戏资产生成：Scenario 允许创建由游戏开发人员或游戏艺术家训练的自定义生成器，以仅匹配他们自己图像的风格。在用户上传了一组定义给定游戏或项目的角色、物品、环境或其他资产的视觉效果后，Scenario平台可以根据用户上传数据快速生成相应游戏资产，大大降低了游戏开发成本。增强交互体验：近期网易旗下手游逆水寒官方宣布，实装国内首个游戏内类GPT技术，采用了大量来自网易伏羲人工智能实验室以及网易雷火事业群的 AI 技术。从官方公布演示视频来看，逆水寒手游已经能让智能 NPC 和玩家自由生成对话，同时也能基于对话内容做出合适的逻辑行为反馈，包括声音和形体动作。生成式AI在游戏中的应用可以大大增强玩家剧情代入感，大幅提高游戏交互体验，提升玩家对游戏的探索欲望。图36：在Scenario上生成游戏资产 图37：网易逆水寒手游实装游戏内类GPT技术【游戏】Scenario、网易（9999.HK）：生成游戏素材，增强交互体验 Jasper AI是一个AI文本生成工具，用户可以通过其自动创建博客文章、社交媒体文章、广告、电子书、登陆页面副本、故事、小说等等。一旦用户给出一些输入文本（关于需要生成的内、标题、相关关键词等的简介），它就会生成对应的原创内容。其深耕广告营销领域，有望成为垂直领域行业龙头，主要具备以下三个优势：精细的营销模板：用户可以根据想要生成的内容形式，选择更加符合需求的模板，平台提供50个简短的文案模板，可帮助用户为各种日常任务创建文案，其中包括用于为电子邮件、网站、博客、广告、电子商务、社交媒体、视频等编写内容的 AI 模板。产品交互体验优秀：该平台工具交互界面清晰易上手，产品符合用户使用逻辑，且会根据用户反馈频繁更新优化。优秀的配套培训体系：Jasper AI提供名为 Jasper BootCamp 的培训，帮助新用户快速了解该软件的工作原理，并且获得营销基本知识。图38：Jasper AI生成文本模板列表资料来源：Jasper AI，华西证券研究所图39：Jasper BootCamp帮助用户快速上手【广告营销】Jasper AI：快速创建各类广告内容，降低营销成本资料来源：Jasper AI，华西证券研究所目录4001 核心观点03 数据：大模型训练的基础资源02 生成式AI：ChatGPT引燃市场，数字经济未来已至05 算法：大模型算法助力AIGC突破04 算力：大模型发展带来高算力需求07 生成式AI海外受益标的08 风险提示06 产业应用：各领域应用加速落地，商业化前景广阔数据Appen（APX.AX）：（1）凭借专业的AI训练数据处理和高质量的数据标注服务，为AIGC模型提供可靠支持；（2）全球化众包劳动力网络确保了服务的可扩展性和灵活性。算力英伟达（NVDA.O）：（1）A100显卡在ChatGPT等模型中发挥关键作用，Trendforce预估其可能带来超过3亿美元的业务增量；（2）根据花旗集团预估，ChatGPT 的使用可能会在 12 个月内为英伟达带来30 亿至 110 亿美元的销售额。AMD（AMD.O）：（1）推出高能效AI推理加速器Alveo V70和首款集成CPU和GPU的APU产品Instinct MI300。算法微软（MSFT.O）：（1）全面将AI工具融合进办公软件，引领办公模式革新；（2）计划收购动视暴雪，布局AI融合游戏提升交互体验；（3）推出Azure OpenAI云服务，打造企业使用OpenAI服务入口。谷歌（GOOG.O）：（1）打造多领域AIGC产品，包括代码生成辅助工具AlphaCode、文本生成音乐模型MusicLM、文本生成图片模型Imagen等，全线布局生成式AI产业；（2）紧追OpenAI步伐，计划推出聊天机器人Sparrow，或将在基于强化学习的功能上更进一步。Meta（META.O）：（1）推出Make-A-Video，用AI驱动文本、图片生成短视频等；（2）将AI融合到其广告平台Advantage 中，通过自动化营销活动实现成本效益和更高的参与度。百度（BIBU.O）：（1）已有数百家企业成为其“文心一言”生态合作伙伴，有望快速形成商业化落地场景；（2）先后推出产业级搜索系统“文心百中”、AI绘图软件“文心一格”。生成式AI海外受益标的下游应用通用汽车（GM.N）：（1）几乎是国外第一家正式宣布引入ChatGPT的车企，正开发类GPT车内数字助理；（2）有别于ChatGPT，将专注于驾驶员相关任务，提升交互性和行驶安全。Buzzfeed（BZFD.O）：（1）在媒体领域率先引入AI，将与OpenAI合作，从用户互动栏目入手，引入生成式AI进行创作及内容个性化；（2）AI的自动化生产内容将为用户报告编写缩减人工劳动，从而降低内容生产的成本。网易（9999.HK）：（1）旗下手游逆水寒宣布实装国内首个游戏内类GPT，采用网易自研技术；（2）智能 NPC 可和玩家自由生成对话，增强玩家剧情代入感，大幅提高游戏交互体验，激发玩家的探索欲望。生成式AI海外受益标的，数据截至2023年3月19日表7：生成式AI海外受益标的生成式AI海外受益标的细分赛道代码简称市值（亿美元）彭博一致预测净利润（百万美元）彭博一致预测PE2023E2024E2023E2024E数据APX.AXAppen2.2-22.0-9.0-算力NVDA.O英伟达6,331.4010,817.0014,363.0057.543.7AMD.OAMD1,566.604,915.006,768.0032.222.6算法MSFT.O微软20,680.0069,818.0080,106.0029.926GOOG.O谷歌13,033.0069,907.0082,208.002016.7META.OMeta5,192.3028,028.0033,427.0019.816.2BIDU.O百度492.43,193.003,768.0015.513.3AMZN.O亚马逊10,195.5 27,751.5 40,670.5 74.0140.67下游应用MBLY.OMobileye348.25406926550.5GM.N通用汽车474.18,694.908,690.205.435.37BZFD.OBuzzfeed1.6-74-43-9999.HK网易-S558.5 3,396.1 3,791.1 17.2315.52目录4401 核心观点03 数据：大模型训练的基础资源02 生成式AI：ChatGPT引燃市场，数字经济未来已至05 算法：大模型算法助力AIGC突破04 算力：大模型发展带来高算力需求07 生成式AI海外受益标的08 风险提示06 产业应用：各领域应用加速落地，商业化前景广阔风险提示技术落地商业化不及预期人工智能在部分领域应用的监管风险外部环境导致芯片、软件等供应限制华西证券研究所：地址：北京市西城区太平桥大街丰汇园11号丰汇时代大厦南座5层网址：http:/

7人已浏览 2023-03-21 48页 5星级

数据中心服务器碳核算指南ODCC-2021-01007数据中心服务器碳核算指南i目录目录前言.iii版权说明.iv数据中心服务器碳核算指南.11.背景.12.服务器碳核算方法.32.1.产品描述.32.2.核算范围.32.3.数据收集与碳核算.32.4.数据质量要求.53.服务器产品低碳等级.53.1.服务器碳排放量.63.2.低碳技术与方案.63.2.低碳战略与管理.63.4.技术创新和突破.74.数据中心碳核算报告.75.评审流程及结果发布.7附录 A.81.基本信息.82.概述.8ODCC-2021-01007数据中心服务器碳核算指南ii3.数据收集.94.碳核算结果.105.碳排放评级.106.结论和不确定性说明.11附录 B.111.评估流程.112.评估结果证书样例.12ODCC-2021-01007数据中心服务器碳核算指南iii前言前言2020 年 3 月，在中共中央政治局常务委员会召开的会议上，明确提出要加快 5G 网络、数据中心等新型基础设施建设进度。在数据中心加快建设部署的大背景下，总耗能也呈增长趋势。据相关数据统计，2020 年我国数据中心耗电量占全社会总耗电量的比例超过 1%。数据中心中，服务器是最主要的耗能设备。在应对气候变化和践行“碳达峰”“碳中和”目标的大背景下，提升数据中心服务器能效、降低其能耗及碳排放对于数据中心实现绿色发展和落实双碳目标具有重大意义。数据中心服务器碳核算指南确定了数据中心服务器碳足迹的核算方法和评价体系，将加快推进数据中心行业确立具体的节能减碳目标，促进服务器产品节能减碳技术创新，并为数据中心服务器碳核算和数据中心绿色低碳水平评估提供参考依据。ODCC 始终关注数据中心及相关产品绿色低碳技术的发展，由中国信通院云大所牵头，联合相关单位共同编写了本指南。在此感谢以下起草单位（排名不分先后）：起草单位：中国信息通信研究院（云计算与大数据研究所）、中标院资环分院、华为、浪潮、联想、字节跳动、京东、美团、中国移动、中国电信、百度ODCC-2021-01007数据中心服务器碳核算指南iv版权说明版权说明ODCC（开放数据中心委员会）发布的各项成果，受著作权法保护，编制单位共同享有著作权。转载、摘编或利用其它方式使用 ODCC 成果中的文字或者观点的，应注明来源：“开放数据中心委员会”。对于未经著作权人书面同意而实施的剽窃、复制、修改、销售、改编、汇编和翻译出版等侵权行为，ODCC 及有关单位将追究其法律责任，感谢各单位的配合与支持。ODCC-2021-01007数据中心服务器碳核算指南1数据中心服务器碳核算指南数据中心服务器碳核算指南1.背景1.背景自 2015 年巴黎协定签署以来，全球主要国家已陆续对碳减排目标做出承诺并制定实现碳中和的具体时间表。对于 ICT 产业，数据中心总体耗电量较高，其能源消耗、绿色低碳发展进程正在不断引发社会各界的关注。目前多国政府制定了数据中心绿色低碳发展相关政策，美国发布了 DCOI 数据中心优化倡议，新加坡发布了绿色数据中心技术路线图。我国为落实双碳战略，也出台了相关政策，工信部、发改委、国管局等政策文件多次提出新建大型、超大型数据中心 PUE 达到 1.3 以下，绿色低碳等级达到 4A 级以上。2021 年 7 月，工信部发布 新型数据中心发展三年行动计划（2021-2023 年）（以下简称行动计划），引发业界高度关注。对于绿色低碳发展领域，提出要着重引导新型数据中心走高效、清洁、集约、循环的绿色低碳发展道路。绿色低碳发展行动作为重点任务，需提高绿色技术产品应用、提升能源高效清洁利用水平和优化数据中心绿色管理能力。行动计划对新建大型及以上数据中心提出了除达到绿色数据中心要求外，低碳等级也需要达到 4A 级以上的具体要求。2021 年 11 月，国管局联合发改委、财政部、生态环境部印发深入开展公共机构绿色低碳引领行动促进碳达峰实施方案，其中 5 大任务和 20 项工作中明确指出需要大力发展绿色建筑、加大既有建筑节能改造力度、提高建筑用能管理智能化水平、提升公共机构绿化水平并推动数据中心绿色化，新建大型、超大型数据中心全部达到绿色数据中心要求，绿色低碳等级达到 4A 级以上，PUE 达到 1.3 以下。2021 年 12 月，国家发改委、中央网信办、工信部、国家能源局四部门联合发布 贯彻落实碳达峰碳中和目标要求 推动数据中心和 5G 等新型基础设施绿色ODCC-2021-01007数据中心服务器碳核算指南2高质量发展实施方案。方案要求，到 2025 年，数据中心和 5G 基本形成绿色集约的一体化运行格局。数据中心运行电能利用效率和可再生能源利用率明显提升，全国新建大型、超大型数据中心平均电能利用效率降到 1.3 以下，国家枢纽节点进一步降到 1.25 以下，绿色低碳等级达到 4A 级以上。数据中心向绿色、节能、低碳的方向发展已成为该行业趋势。近年来，尽管数据中心的节能优化技术快速迭代发展，但由于行业的成长和市场规模的扩大，数据中心的总能耗仍呈增长趋势。对数据中心进行碳核算核查和低碳能力评估成为行业发展和行业碳排放管理的重要需求。2008 年 10 月英国标准协会发布的 PAS2050商品和服务在生命周期内的温室气体排放评价规范为评估产品生命周期内温室气体排放提供了方法参考。2010 年发布的 PAS2060碳中和证明规范以 ISO14000 系列和 PAS2050 等环境标准为基础，提出了通过温室气体排放的量化,还原和补偿来实现和实施碳中和的相关组织所必须符合的规定。两份文件为对数据中心进行碳排放核算核查提供了最基本的参考依据。国际上，互联网企业数据中心对于能源数据信息有较为全面的披露，相关信息包括：能源消耗总量、PUE、温室气体排放总量等。例如，谷歌可为其用户提供定制的碳足迹报告，详细说明用户在使用云服务过程中所产生的碳排放细节；微软发布了可持续发展计算器工具，可通过 Power BI 仪表盘分析用户使用 Azure服务所产生的碳排放预估量。随着相关政策及要求的出台，我国数据中心运营商也正在逐步完善能源数据信息的核算和统计，数据中心整体能耗披露正逐步开展和完善过程中。数据中心低碳等级评估基于数据中心整体碳排放表现，由于服务器能耗在数据中心总能耗中占据主要部分，因此对服务器碳排放的精确核算对数据中心整体碳排放是至关重要的。目前，我国尚缺乏针对数据中心服务器碳排放的具体核算标准。本指南文件将通过制定数据中心服务器全生命周期各阶段的碳核算方法和碳排放评级指标体系，为数据中心和服务器碳排放低碳等级评估提供相应参考和依据。ODCC-2021-01007数据中心服务器碳核算指南32.服务器碳核算方法2.1.产品描述2.服务器碳核算方法2.1.产品描述数据中心服务器产品描述应包括但不限于以下内容：产品名称（型号、规格、分类）；产品的主要技术参数和性能；产品所包括的部件（含包装、配件等）；产品的设计基准寿命。2.2.核算范围2.2.1.功能单位2.2.核算范围2.2.1.功能单位服务器的功能单位应定义为一台或一套服务器。2.2.2.系统边界2.2.2.系统边界服务器生命周期应包括以下阶段：原材料阶段：原材料开采、生产和运输等；生产制造阶段：服务器产品制造与包装。组装基准产品并进行包装，是产品形成的主要阶段；运输阶段：部件与产品的运输；使用阶段：服务器产品的使用，以及相关的产品维护；报废回收阶段：服务器产品报废与回收。2.3.数据收集与碳核算2.3.1.数据收集范围2.3.数据收集与碳核算2.3.1.数据收集范围应收集系统边界内所有单元过程的定性资料和定量数据。通过测量、计算或估算收集到的数据，可纳入产品碳核算过程和环节。ODCC-2021-01007数据中心服务器碳核算指南42.3.2.碳排放核算方法2.3.2.1.原材料阶段2.3.2.碳排放核算方法2.3.2.1.原材料阶段原材料阶段从自然界提取时开始，除了天然材料的提取，还包括再生材料的获取、原材料的预处理、成型和运输过程等。原材料的获取和预加工流程包括：采矿和提取（材料或化石燃料）；再生材料的加工（回收塑料等）；保证原材料满足客户要求的附加过程，例如金属加工、塑料定型加工和再生材料的转换。从服务器产品来看，主要原材料大类有金属、合成材料等。相应的材料经过前处理和附加过程转换，成为产品制造所需的输入。原材料消耗数据应来自于企业的实际统计记录和产品 BOM 里面的部件数据，相关数据的获得方式和来源均应列出和说明。2.3.2.2.产品制造阶段2.3.2.2.产品制造阶段产品制造阶段应收集以下数据：整机制造；制造场所内的元器件、零部件、组件的生产过程；最终产品装配与组装、测试、包装、检验过程；最终产品的存储过程；测试过程中配套设备设施的运行数据；上述环节所产生的废气、废水、废弃物处理相关的过程。2.3.2.3.运输阶段2.3.2.3.运输阶段运输阶段应收集以下数据：从制造商的物流中心至区域物流中心之间的产品及包装的运输过程；根据运输阶段的相关数据（运输重量、运输距离、运输类型），参考相关标准进行计算。2.3.2.4.使用阶段2.3.2.4.使用阶段使用阶段应收集以下数据：ODCC-2021-01007数据中心服务器碳核算指南5产品在通用基准测试场景的能效情况；产品使用的推荐寿命；产品使用能源相关的碳排放量情况。服务器使用阶段的功耗数据，需要考虑服务器通用基准测试场景，采用涵盖服务器 CPU、内存、存储 IO 等三大基础部件在指定负载压力情况下的功耗数据。本指南建议采用行业常用的能效测试基准工具，如 BenchSEE 等。2.3.2.5.报废回收阶段2.3.2.5.报废回收阶段报废回收阶段从废弃的服务器被送入处理处置点开始，到服务器回归到自然或分配到另一种产品的生命周期结束。该阶段主要考虑对服务器采取的不同处理处置方式产生的碳排放量差异。2.4.数据质量要求2.4.数据质量要求数据收集与处理过程中，相关数据应满足以下数据质量要求：技术代表性：数据反映实际生产技术情况，即体现出实际工艺流程、技术和设备类型、原料与能耗类型、生产规模等因素的影响；时间代表性：数据的年份和收集数据的时间期限，以及具体被评价产品的时间数据；地理代表性：排放因子等相关参数的选择需考虑相关环节所处的地理位置；数据完整性：按照数据取舍准则，判断是否已收集各生产过程的主要消耗和排放数据，尽可能避免数据缺失；数据准确性：零部件、辅料、能耗、包装、原料与服务器运输等数据需采用企业实际生产统计记录和 BOM 数据，所有数据均有相关的数据来源和数据处理算法；数据一致性：每个过程的消耗与排放数据需保持一致的统计标准，即相同数据来源、过程边界和处理规则等。3.服务器产品低碳等级3.服务器产品低碳等级从数据中心服务器碳排放量、服务器低碳技术与方案、低碳战略与管理等方面评估数据中心服务器碳排放水平，基于评估结果对数据中心服务器划分低碳等ODCC-2021-01007数据中心服务器碳核算指南6级，为数据中心行业生产、采购和使用服务器产品提供参考。3.1.服务器碳排放量3.1.服务器碳排放量将第2章所述核算方法得到的数据中心服务器生命周期的碳足迹作为评估指标。3.2.低碳技术与方案3.2.低碳技术与方案评估数据中心服务器生命周期各阶段的低碳技术与方案。3.2.1.技术方案3.2.1.技术方案考察数据中心服务器在生命周期各阶段采用的低碳技术方案及实施情况。原材料阶段；生产制造阶段；运输阶段；使用阶段；报废回收阶段；其他工艺流程。3.2.2.技术指标3.2.2.技术指标评估服务器绿色低碳水平的相关量化指标。回收利用率；单位能耗产生的生命周期总碳排放量；单位算力产生的生命周期总碳排放量；单位算力产生的使用阶段碳排放量；能效比。3.2.低碳战略与管理3.3.1.组织与战略3.2.低碳战略与管理3.3.1.组织与战略从低碳管理组织和战略规划方面评估数据中心服务器的碳减排能力。碳管理组织机构建设；ODCC-2021-01007数据中心服务器碳核算指南7碳管理战略制定；碳管理战略公开；开展节能减碳宣传。3.3.2.管理体系3.3.2.管理体系从低碳管理体系和能力方面评估数据中心服务器碳减排能力。温室气体和能耗监测与统计、能源管理体系建设情况；温室气体排放数据核查；碳信息披露；数字化管理平台应用；产品供应链管理；物流、回收和包装绿色低碳管理。3.4.技术创新和突破3.4.技术创新和突破服务器节能减排方面的创新性探索，比如：在国内率先进行某项节能减碳领域新技术、新工艺和新产品的实际应用，并在业内分享经验。4.数据中心碳核算报告4.数据中心碳核算报告报告模板可参考附录 A。5.评审流程及结果发布5.评审流程及结果发布评估流程及评估证书可参考附录 B。ODCC-2021-01007数据中心服务器碳核算指南8附录 A数据中心服务器碳核算报告模板1.基本信息附录 A数据中心服务器碳核算报告模板1.基本信息1.1.服务器基本信息名称：XX类型服务器型号：XX-XX-XX产品规格参数：如CPU4.7GHz，内存2.0GB，硬盘512G，显卡功能：运算、控制、存储等1.2.制造商基本信息制造商名称：XX有限公司社会信用代码：XXXXXX制造商简介：XXXXXX制造商地址：XX省XX市XX区XX路XX号制造商网址：1.3.联系人基本信息联系人：XXX电话：XXXX-XXXXXXXX传真：XXXX-XXXXXXXX电子邮箱：2.概述2.概述2.1.核算范围产品范围：核算对象为XX有限公司生产的型号为XX-XX的XX类型服务器。时间范围：本报告选取20XX年作为产品碳排放核算的核算期。温室气体范围：二氧化碳、甲烷、氧化亚氮、氢氟碳化物、全氟碳化物、六氟化硫。核算依据：依据数据中心服务器碳核算指南进行产品碳排放核算和核算ODCC-2021-01007数据中心服务器碳核算指南9报告编制。2.2.功能单位本报告以1台/1套型号为XX-XX-XX的XXX类型服务器产品为功能单位。2.3.系统边界本报告的系统边界包括：原材料阶段、生产制造阶段、运输阶段、使用阶段和报废回收阶段。主要考虑与产品生产相关的过程，其他和产品生产不直接相关的设备和人员的消耗和排放不纳入核算范围内。运输过程主要考虑部件与产品运输两部分。产品的使用寿命按照X年计算。3.数据收集3.数据收集3.1.数据收集时间产品数据的具体收集时间如下:研发（使用，运输，回收）：2021/XX/XX2022/XX/XX制造商（产品生产制成）：2021/XX/XX2022/XX/XX供应商（主要部件）：2021/XX/XX2022/XX/XX3.2.生命周期阶段数据应根据系统边界填写下列阶段的信息：原材料阶段原材料阶段该阶段从资源的获取和原材料的预处理开始，到部件生产完成为止。考虑原材料生产过程和部件生产过程两个主要部分。生产制造阶段生产制造阶段制造过程中的能源消耗、资源消耗、直接排放的温室气体和待处置的废弃物及工厂内运输过程。运输阶段运输阶段部件与产品的运输相关过程和信息。使用阶段使用阶段产品使用寿命、使用时间、产品能效相关信息。ODCC-2021-01007数据中心服务器碳核算指南10报废回收阶段报废回收阶段产品不同的报废和回收利用方式所占比例。3.3.数据质量评估填写技术代表性、时间代表性、地理代表性、数据完整性、数据准确性、数据一致性相关信息。4.碳核算结果4.碳核算结果4.1.原材料阶段原材料阶段的碳核算过程与结果。4.2.生产制造阶段生产制造阶段的碳核算过程与结果。4.3.运输阶段运输阶段的碳核算过程与结果。4.4.使用阶段使用阶段的碳核算过程与结果。4.5.报废回收阶段报废回收阶段的碳核算过程与结果。4.6.生命周期碳排放核算全生命周期的碳核算结果。5.碳排放评级5.碳排放评级5.1.服务器碳排放量服务器碳排放评分。5.2.低碳技术与方案低碳技术与方案评分。5.3.低碳战略与管理低碳战略与管理评分。5.4.技术创新和突破对技术、管理创新性等进行评分。ODCC-2021-01007数据中心服务器碳核算指南115.5.碳排放总体评级评分汇总并评级。6.结论和不确定性说明6.结论和不确定性说明本部分包括碳排放核算结果、对产品设计优化、供应链管理等方面的建议以及不确定性说明等，具体内容按照实际情况填写。附录 B评审流程及证书样例1.评估流程附录 B评审流程及证书样例1.评估流程本文件规定的流程包含提交申请、材料审核及评估计划制定、BenchSEE测试及各指标审核核查、专家评审评分、出具评估报告、联合相关机构颁发证书和结果发布与宣传推广。提交申请材料审核及评估计划制定BenchSEE 测试及各指标审核核查专家评审评分出具评估报告颁发证书与宣传推广ODCC-2021-01007数据中心服务器碳核算指南122.评估结果证书样例2.评估结果证书样例服务器低碳等级评估结果证书奖项样例，具体如下。

15人已浏览 2023-03-17 17页 5星级

I 中国信息通信研究院云计算与大数据研究所 人工智能关键技术和应用评测工业和信息化部重点实验室 2023年3月 人工智能研发运营体系人工智能研发运营体系（MLOpsMLOps）实践指南）实践指南 （20232023 年）年）版权声明版权声明 本指南版权属于本指南版权属于中国信息通信研究院、人工智能关键技中国信息通信研究院、人工智能关键技术和应用评测工业和信息化部重点实验室，并受法律保护。术和应用评测工业和信息化部重点实验室，并受法律保护。转载、摘编或利用其它方式使用本指南文字或者观点的，应转载、摘编或利用其它方式使用本指南文字或者观点的，应注明注明“来源：中国信息通信研究院、人工智能关键技术和应用来源：中国信息通信研究院、人工智能关键技术和应用评测工业和信息化部重点实验室评测工业和信息化部重点实验室”。违反上述声明者，本院将。违反上述声明者，本院将追究其相关法律责任。追究其相关法律责任。前前 言言 随着国家新型基础设施建设发展战略（2020）、国家“十四五规划和 2035 年远景目标纲要”等系列政策的出台，人工智能（AI）发展迎来新一轮红利，科技革命和产业升级处于进行时。近年来，AI 工程化的研究热度持续提升，其目的是帮助组织在数智化转型过程中，更高效、大规模地利用 AI 创造业务价值。人工智能研发运营体系（MLOps）作为 AI 工程化重要组成部分，其核心思想是解决 AI 生产过程中团队协作难、管理乱、交付周期长等问题，最终实现高质量、高效率、可持续的 AI 生产过程。MLOps 的发展呈现出逐渐成熟的态势，近几年国内外 MLOps 落地应用正持续快速推进，特别是在 IT、银行、电信等行业取得明显效果。与此同时，MLOps 行业应用成熟度不足，使得组织在制度规范的建立、流程的打通、工具链的建设等诸多环节面临困难。因此本指南旨在成为组织落地 MLOps 并赋能业务的“口袋书”，围绕机器学习全生命周期，为模型的持续构建、持续交付、持续运营等过程提供参考，推进组织的 MLOps 落地进程，提高组织 AI 生产质效。本指南由中国信通院云计算与大数据研究所、人工智能关键技术和应用评测工业和信息化部重点实验室联合发布。本指南站在组织如何布局和落地 MLOps 的视角，以模型的高质量、可持续交付作为核心逻辑，系统性梳理 MLOps 概念内涵、发展过程、落地挑战等现状，并基于 MLOps 的理论研究和实践案例分析组织如何构建 MLOps 框架体系和关键能力，最后总结和展望其发展趋势。由于 AI 产业的快速变革，MLOps 落地应用持续深入，工具市场不断迭代，我们对 MLOps 的认识还有待继续深化，本指南可能仍存在不足之处，欢迎大家批评指正。目目 录录 一、MLOps 概述.1（一）AI 生产过程管理问题凸显.1（二）MLOps 概念与意义.2（三）MLOps 实施原则.3 二、MLOps 发展现状与挑战.6（一）MLOps 发展过程.6（二）MLOps 落地挑战.11 三、MLOps 框架体系.13（一）机器学习项目生命周期.13（二）MLOps 流程架构.14（三）MLOps 相关角色.19 四、MLOps 关键能力与技术实践.22（一）数据处理.22（二）模型训练.25（三）构建集成.27（四）模型服务.30（五）运营监控.35（六）模型重训.38（七）实验管理.40（八）流水线管理.43（九）特征管理.45（十）模型管理.47（十一）仓库管理.50（十二）模型安全.53 五、MLOps 总结与展望.57（一）总结.57（二）展望.58 图图 目目 录录 图 1 MLOps 示意图.2 图 2 MLOps 实施原则.4 图 3 机器学习技术债示意图.6 图 4 Gartner 数据科学和机器学习技术成熟曲线.8 图 5 MLOps 工具分类一览.9 图 6 机器学习项目生命周期示意图.13 图 7 基于 MLOps 框架的机器学习项目生命周期示意图.14 图 8 MLOps 流程架构示意图.14 图 9 MLOps 相关角色分工示意图.19 图 10 MLOps 关键能力示意图.22 图 11 广东移动的数据处理能力示意图.23 图 12 格物钛的数据处理能力示意图.24 图 13 云测数据的数据处理能力架构图.25 图 14 百度的模型训练架构图.27 图 15 马上消费的构建集成流程图.29 图 16 腾讯的 MLOps 平台示意图.30 图 17 浦发银行模型服务示意图.32 图 18 建行模型服务架构图.33 图 19 中移在线中心 Polaris MLOps 平台模型部署流程.34 图 20 星环科技 MLOps 流程图.35 图 21 联通软件研究院模型成效闭环运营分析示意图.37 图 22 蚂蚁的持续训练能力示意图.39 图 23 蚂蚁的持续训练流程图.40 图 24 百度的实验管理流程图.41 图 25 华为终端云的实验管理界面.42 图 26 农行的流水线管理示意图.44 图 27 华为终端云的流水线编排可视化能力示意图.44 图 28 华为终端云的特征实验流程图.46 图 29 浦发银行的特征工程流程图.47 图 30 河南移动的模型管理示意图.48 图 31 百度的模型管理流程图.49 图 32 九章云极 DataCanvas 模型管理功能示意图.50 图 33 中信证券的机器学习生命周期示意图.52 图 34 绿盟的模型安全防御策略示意图.54 图 35 蚂蚁的 AntSecMLOps 架构图.55 图 36 蚂蚁的蚁鉴-AI 安全检测平台.56 表表 目目 录录 表 1 MLOps 相关角色职责要求.20 附表 1 MLOps 工具链清单.63人工智能研发运营体系（MLOps）实践指南（2023 年）1 一、MLOps 概述 MLOps 是通过构建和运行机器学习流水线（Pipeline），统一机器学习（ML）项目研发（Dev）和运营（Ops）过程的一种方法，目的是为了提高 AI 模型生产质效，推动 AI 从满足基本需求的“能用”变为满足高效率、高性能的“好用”。本章首先阐述组织在 AI 大规模生产过程中凸显的管理问题，然后梳理 MLOps 概念和意义，并分析落地MLOps 所遵循的原则。（一）（一）AI 生产过程管理问题凸显生产过程管理问题凸显 Gartner 调查发现，只有 53%的项目能够从 AI 原型转化为生产1。AI 生产转化率低的主要原因在于模型全链路生命周期管理存在问题，包括跨团队协作难度大、过程和资产管理欠缺、生产和交付周期长等。第一，跨团队协作难度大。机器学习项目生命周期中涉及业务、数据、算法、研发、运维等多团队，团队间缺乏相同的技术和业务背景知识作为协作基础，从而带来沟通屏障。同时每个团队的协作工具不尽相同，从数据和算法转化为推理服务的整个过程漫长而复杂，从而增大协作难度。第二，过程和资产管理欠缺。模型生产过程无标准化管理，导致AI 资产的价值无法有效发挥。原因在于以下几方面：一是生产过程冗长难管理，AI 模型生产过程涉及的环境、流程复杂，各部门习惯于小作坊的生产模式，重复造轮子现象普遍；二是 AI 资产无集中共享机制，组织内数据、特征、模型等碎片化 AI 资产无法共享使用，优秀实践经验难以沉淀。1 Gartner,Top Strategic Technology Trends for 2021.人工智能研发运营体系（MLOps）实践指南（2023 年）2 第三，生产和交付周期长。机器学习模型生产和交付是一个漫长、复杂又易出错的过程，且耗费的时间成本较高。据 Algorithmia 报告显示，38的企业花费超过 50的时间在模型部署上2。这一现象的主要原因有三：一是模型文件的生产需要经过不断重复的实验和评估；二是模型服务需要通过编写服务代码和配置参数，并达到业务需求后，方可部署上线；三是业务效果的保证需通过在线模型开展服务验证和结果对比。（二）（二）MLOps 概念与意义概念与意义 MLOps 通过连接模型构建团队、业务团队及运维团队，为机器学习模型全生命周期建设标准化、自动化、可持续改进的过程管理体系，使组织规模化、高质量、高效率、可持续地生产机器学习模型。MLOps 能有效缓解 AI 生产过程的各种管理问题，提升 AI 生产的转化效率。来源：中国信息通信研究院 图 1 MLOps 示意图 MLOps 理念源于面向软件工程的管理方法论 DevOps，起初希望可以参考传统软件生产过程的管理方法，以应对提质增效的挑战。然而 DevOps 并不完全适用，因为机器学习项目是以数据、算法、代码、2 Gartner,Gartner Top 10 Data and Analytics Trends for 2021.人工智能研发运营体系（MLOps）实践指南（2023 年）3 模型为核心的动态模式，整个过程充满探索性、实验性和不确定性。若要迎合动态模式的需求，需要一种融合了机器学习特性的 DevOps方法或体系，MLOps 应运而生。MLOps 意义和价值主要体现在以下几方面。第一，建立团队协作机制。通过在组织级明确各流程中各角色（例如业务人员、数据工程师、数据科学家、运维工程师等）和职责，并以流水线的方式连接各团队成员的工作，使团队协作机制得以建立，打破沟通屏障，让不同角色各司其职（例如，使数据科学家不用再沦陷于处理繁琐的模型更新和维护等工作），降低团队间整体合作成本。第二，实现敏捷交付过程。通过自动化流水线等方式实现敏捷交付，从而提高模型交付效率，加快模型迭代速度，提高模型效果，提供更丰富、更优质的产品体验。第三，构建全链路反馈闭环。通过贯通需求、开发、交付、部署、运营多环节的全链路，嵌入合规、监管、道德、安全等要求，形成完整的全链路流水线。同时，持续改进和简化原有运营和治理流程，高效率、低风险地实现持续集成、部署、训练和监控，形成有效的反馈闭环。第四，统一管理 AI 资产。机器学习项目中数据、算法、特征和模型等资产是一个有机整体，通过对 AI 资产的高效统一管理，并加以风险防控和安全管理等手段，实现有效治理。（三）（三）MLOps 实施原则实施原则 作为 AI 基础设施之一，MLOps 促进各团队高效协作，提升业务价值产出。一般来说，实施 MLOps 需要遵循的原则包括自动化、持续性、版本化、可监控、可测试、可追溯、可复现、可协作等。人工智能研发运营体系（MLOps）实践指南（2023 年）4 来源：中国信息通信研究院 图 2 MLOps 实施原则 自动化包括模型自动化构建、自动化集成、自动化测试、自动化部署等，减少人工操作，提高操作准确性，是 MLOps 的核心。持续性包括持续集成（CI）、持续部署（CD）、持续训练（CT）、持续监控（CM），是 MLOps 实现全流程闭环的基础。版本化包括数据、模型和代码等 AI 资产的版本控制能力，是达到可复现、可追溯的基础，是保证资产可在组织各层面共享使用的基本能力之一。可监控包括模型、模型服务及模型生产过程等维度的健康状态监控能力，以发现数据漂移和概念漂移，识别问题和改进方向，是维护高质量模型服务的基础。可测试从模型评估、集成测试、系统测试、业务测试、生产验证等过程维度，保障模型的功能、性能和可信能力（安全性、保密性、可解释性、公平性等）满足需求，是保证模型交付质量的重要手段。可追溯通过“效果模型实验数据”全流程追溯过程的实现，提供模型实验及数据的血缘回溯能力，是根因分析的基础，是事后审计的手段，也是过程可信的体现。人工智能研发运营体系（MLOps）实践指南（2023 年）5 可复现通过端到端记录模型构建过程相关数据、算法、参数等元数据信息，支持重现实验过程并获得高度相似的结果，是数据科学家开展模型工程的重要支撑。可协作确保不同团队角色在数据、代码和模型上进行协作，是全流程可持续闭环实施的协作基础，是提高团队整体效率的保障。人工智能研发运营体系（MLOps）实践指南（2023 年）6 二、MLOps 发展现状与挑战 MLOps 在国内外得到了广泛应用，并在多个行业取得了实质性效果。本章首先阶段性梳理 MLOps 发展历程，然后从落地应用和工具市场等角度分析当前发展现状，最后总结了 MLOps 落地面临的挑战。（一）（一）MLOps 发展过程发展过程 1.发展历程 2015 年至今，从业界意识到机器学习项目技术债给 AI 生产上线带来的潜在巨大影响伊始，MLOps 前后经历了斟酌发酵、概念明确、落地应用三大阶段。斟酌发酵阶段（2015 年至 2017 年前后）。2015 年 Google 在Conference and Workshop on Neural Information Processing Systems（NIPS）上发布的论文Hidden Technical Debt in Machine Learning Systems 首次提出机器学习项目技术债问题，一方面，机器学习项目具有传统软件工程的代码运维问题，这部分问题占比较小；另一方面，机器学习项目本身存在数据依赖关系不稳定、配置易出错、实验不可重现等问题，为模型的持续运维和迭代带来大量隐患。这篇论文标志着机器学习高效落地问题被明确提出和正视，也催生了产业界形成系统化的方法论和规范化的管理流程，解决技术债问题的强烈需求。来源：Hidden Technical Debt in Machine Learning Systems 图 3 机器学习技术债示意图 人工智能研发运营体系（MLOps）实践指南（2023 年）7 概念明确阶段（2018 年至 2019 年前后）。2018 年业内人士逐渐开始密集讨论大规模生产中机器学习生命周期集成化管理的重要性，MLOps 这一概念被提出并逐步接受。2019 年 Continuous Delivery for Machine Learning3提出的 CD4ML 理念，阐述了机器学习项目如何开展持续交付(CD)，并提出端到端的交付流程。CD4ML 将传统软件工程中的持续交付方法论扩展到机器学习中，使跨团队成员可基于数据、代码和模型，实现机器学习项目小步快跑、安全持续的增量式迭代。落地应用阶段（2020 年至今）。2020 年以来，产业焦点集中于 AI大规模快速落地，布局 MLOps 平台或工具的需求日益迫切，推动组织数智化转型成为产业界追逐的目标。2021年，Gartner将包括MLOps在内的 XOps 列为 2021 年十大数据和分析技术趋势之一4。此外，从2019 年到 2022 年，Gartner 连续 4 年将 MLOps 纳入数据科学与机器学习技术成熟度曲线5。2021 年，中国信息通信研究院牵头开展MLOps 系列标准编制，以引导产业有序发展，形成行业自律规范。来源：Gartner 3 Continuous Delivery for Machine Learning，https:/ Gartner,Gartner Top 10 Data andAnalytics Trends,2021.5 Gartner,Hype Cycle for Data Science and Machine Learning（2019,2020,2021,2022）.人工智能研发运营体系（MLOps）实践指南（2023 年）8 图 4 Gartner 数据科学和机器学习技术成熟曲线 2.发展现状 MLOps 产品提供方和应用方不同程度地受益于 MLOps 体系的蓬勃发展。随着工具市场和行业应用的发展不断推进，新工具不断涌现，在 IT、金融、电信等行业得到了广泛应用和落地。根据情报和市场研究平台 MarketsandMarkets 2022 年研究报告显示，MLOps 市场规模将从 2022 年的 11 亿美元增长到 2027 年的 59 亿美元6。（1）资本市场持续火爆，MLOps 工具不断创新 近年来，MLOps 相关工具链已成为 AI 投融资领域的明星赛道，涌现了诸多以 MLOps 工具为主打产品的初创公司。例如，聚焦于深度学习可视化工具的 Weights&Biases 获得 2 亿美元融资，且平台估值达 10 亿美元；聚焦于提供机器学习平台的 Tecton 获得 1.6 亿美元融资；聚焦于机器学习模型多硬件适配部署的 OctoML 获得 1.33 亿美元融资，且平台估值达 8.5 亿美元。在资本市场的驱动下，MLOps 工具持续创新。据不完全统计，目前全球约有 300 多款工具，大致可分为两类：一类是 MLOps 端到端工具平台，为机器学习项目全生命周期提供支持。端到端工具平台包括国外的 Amazon SageMaker、Microsoft Azure、Google Cloud Platform、DataRobot、Algorithmia、Kubeflow、MLflow 等，国内的百度智能云企业 AI 开发平台、阿里云机器学习平台 PAI、华为终端云 MLOps 平台、腾讯太极机器学习平台、九章云极 DataCanvas APS 机器学习平台等；另一类是 MLOps 专项工具，对特定步骤提供更为集中的支持，主要包括数据处理、模型构建、运营监控三大类。专项工具包括国外 6https:/ 年）9 Cloudera 提供的数据共享工具，DVC 和 DAGsHub 提供的数据和模型版本管理工具，Neptune.ai 提供的元数据管理工具等，国内的星环科技提供的运营监控工具，第四范式提供的特征实时处理工具，云测数据提供的标注工具等。来源：中国信息通信研究院 图 5 MLOps 工具分类一览（2）MLOps 行业应用稳步推进，落地实践成果颇丰 第一，国外 MLOps 落地广泛、效果显著。其主要应用于组织内部的服务运营、产品或服务开发、营销、风险预测及供应链管理等场景，应用行业涉及 IT、金融、电子商务、制造、化工和医疗行业等。IT 行业：应用 MLOps 后，美国某 IT 公司将开发和部署新 AI 服务的时间缩短到原来的 1/12 到 1/6，运营成本降低 50%；德国某 IT公司，通过自动化编排和实验跟踪，以相同的工作量运行 10 倍的实验数量；以色列某 IT 公司实验复现时间减少 50%；某美国出行科技公司三年内机器学习产品数量从零扩展到数百个。金融行业：应用 MLOps 后，新加坡某保险公司推理结果的生成时间从几天缩短至不到 1 小时；欧洲某大型保险公司节省了大量维护人工智能研发运营体系（MLOps）实践指南（2023 年）10 和调查时间，可实时跟踪和比较模型性能，并自动检测以前需要数月才能检测到的漂移；美国某支付公司可实时部署和运行其反欺诈预测模型，并实时分析新数据以适应新威胁。电子商务：应用 MLOps 后，荷兰某酒店预定网站通过打通机器学习模型生产流程，提高了生产规模，具备应用 150 个面向用户的机器学习模型的能力，逐步推进 AI 规模化落地。制造业：应用 MLOps 后，土耳其某水泥制造公司通过提升模型生产效率和质量，大大提升了 AI 赋能业务的能力，使得替代燃料的使用量增加 7 倍，减少 2%的二氧化碳排放总量，成本降低 3900 万美元。化工行业：应用 MLOps 后，美国某化工企业将模型部署周期从原来的 12 个月缩减至 30 到 90 天。医疗行业：应用 MLOps 后，美国某医疗企业通过快速构建和测试模型，为业务提供精准决策，使得每年从患者日支付的护士工时中节省 200 万美元，通过减少患者住院时间每年可节省 1000 万美元7。第二，国内 MLOps 处于规划和建设前期，落地探索成效初显。IDC2022 年预测，到 2024 年 60%的中国企业将通过 MLOps 来运作其机器学习工作流8。近 3 年来，国内各行业开始探索契合自身特点的 MLOps 落地解决方案。在数智化转型热潮中，IT、金融和电信等数字化程度较高的行业处于相对领先地位，其他行业进展稍缓。IT 行业：凭借在数据方面拥有的先天优势，IT 行业最早开始构建 MLOps 并驱动其业务智能化水平的提升。如百度、华为、阿里、京东等，关注机器学习项目全生命周期的优化和改进，并在原有 AI 7 https:/ IDC,IDC FutureScape:全球人工智能（AI）及自动化市场 2022 预测中国启示.人工智能研发运营体系（MLOps）实践指南（2023 年）11 中台或云服务平台上逐步扩展 MLOps 过程管理功能，实践效果明显。百度通过应用 MLOps 使得开发周期缩短 54%，测试周期缩短 67%，所投入的人天数缩减 57%9。金融行业：鉴于对风险的敏锐嗅觉，金融行业在使用 MLOps 驱动业务增长的同时，对模型风险的关注与日俱增。如工行、农行、浦发银行、中原银行、中信证券等，细分上千个应用场景，重点聚焦于模型生产、模型管理、模型安全、模型风险等方面，借助 MLOps 实现模型全流程管控。中原银行通过应用 MLOps 将模型上线周期从周缩短至天，将模型部署时间从小时级缩短至秒级9。电信行业：由于用户数量巨大，模型上线后的运营监控成为电信行业关注的重点之一。如联通、移动等，对模型运营监控的关注度较高，以保证模型的稳定性。某电信运营商应用 MLOps 建立模型运营监控体系，实现模型持续训练，节省人力 300 人天/年，成本降低 80%9。（二）（二）MLOps 落地挑战落地挑战 近年来，我国 MLOps 逐步在多行业中得到布局应用。将 MLOps引入模型开发阶段的实践较为成熟，而 MLOps 引入到模型交付和模型运营阶段的落地处于逐步规划建设中。在这个渐进式过程中，MLOps 落地面临着诸多挑战。一是组织落地驱动力不足。对于大多数组织而言，MLOps 落地驱动力不足。首先体现在 MLOps 建设成本较高，但短期内价值无法立即显现，导致必要性分析难度增大；其次是 MLOps 技术栈不清晰，且部分组织对已有 AI 能力和规模不确定，无法明确 MLOps 建设的目标成熟度，导致制定技术方案的难度加大；最后是业内缺乏成熟的 9 数据来源：中国信息通信研究院行业调研访谈.人工智能研发运营体系（MLOps）实践指南（2023 年）12 MLOps 实践指南作为指导，缺乏标杆组织和案例作为参考，导致诸多组织落地 MLOps 时“摸着石头过河”，进程缓慢。二是支撑工具选型难、集成难。虽然 MLOps 工具市场目前处于蓬勃发展阶段，为应用方提供了许多选择，但随之带来的问题也比较明显。一方面，由于工具种类繁多，功能复杂，解决某一环节问题的工具往往有许多个，缺乏统一的能力标准；另一方面，尽管 MLOps开源工具占多数，但如何将多个工具有效集成和打通，整合全生命周期各项关键能力，很大程度依赖于组织和人员的技术能力。这两个原因导致组织落地 MLOps 时，面临解决方案难决策、平台难选取、工具链难集成等难题，导致难以实现 MLOps 的快速落地。三是模型治理和可信道阻且长。机器学习模型的治理错综复杂，体现在两个方面：一方面，同一模型在不同业务场景面临的风险程度和所需更新频次不同，不同类别模型所需的生产过程和风险等级亦不同；另一方面，模型面临的事前、事中和事后风险包括生产过程不可追溯、线上模型效果下降、模型存在偏见、推理结果不可解释、无法审计等，导致 AI 可信落地难。四是环境间的交互难以平衡。企业内部的 MLOps 实践过程需要有效管理开发环境、测试环境、准生产环境、生产环境等之间的关系，外部需要有效打通与 DevOps、DataOps、FeatureOps 的连接，同时又要保证流程的简洁和安全。环境间的交互障碍，导致 MLOps 的自动化进程受限。人工智能研发运营体系（MLOps）实践指南（2023 年）13 三、MLOps 框架体系 机器学习项目生命周期伴随着 AI 的发展早已形成，而 MLOps 的出现驱动产业界对机器学习项目生命周期进行了完整梳理。本章由信通院和行业专家结合机器学习和 MLOps 相关理论研究和产业实践，围绕机器学习项目的全生命周期，对业界现有的 MLOps 框架体系做出总结归纳。（一）机器学习项目生命周期（一）机器学习项目生命周期 机器学习项目以需求、数据、代码、算法为输入，以模型、模型服务为输出，其生命周期主要包括定义问题、数据收集、数据处理、模型训练、模型评估、模型部署等过程。来源：中国信息通信研究院 图 6 机器学习项目生命周期示意图 MLOps 围绕持续集成、持续部署、持续监控和持续训练，构建和维护机器学习流水线，并通过流水线的衔接形成全生命周期闭环体系。基于 MLOps 框架的机器学习项目生命周期通常包括需求设计、开发、交付和运营四个阶段，细分为需求管理、数据工程、模型开发、模型交付、模型运营等过程。需求管理：根据商业目标与业务需求，开展可行性分析，编制技术需求和技术方案。数据工程：将源数据处理成可用数据，并存储至合适位置便于流转。模型开发：在实验环境中，对模型进行训练、参数调优、评估与选择等过程，得到最优模型。人工智能研发运营体系（MLOps）实践指南（2023 年）14 模型交付：将模型与配置、代码和脚本等进行封装，生成可交付物，并部署至目标环境。模型运营：在生产环境中为上线的模型服务提供监控和运营维护能力。来源：中国信息通信研究院 图 7 基于 MLOps 框架的机器学习项目生命周期示意图（二）（二）MLOps 流程架构流程架构 典型的 MLOps 流程架构包含需求分析与开发、数据工程流水线、模型实验工程流水线、持续集成流水线、模型训练流水线、模型服务流水线、持续监控流水线七个部分。来源：中国信息通信研究院 图 8 MLOps 流程架构示意图 人工智能研发运营体系（MLOps）实践指南（2023 年）15 1.需求分析与开发 需求分析与开发是指对业务方的需求进行分析和设计，对规则、代码、脚本等进行开发。目的是解决机器学习项目中需求管理流程混乱、不同角色对于需求的理解不一致及风险不可控等问题，从源头提升项目质量，降低需求变更带来的影响。主要输入：业务需求。主要步骤：1)将业务需求转为技术问题，确定使用机器学习模型解决潜在业务问题的可行性及必要性，评估模型潜在的风险。2)设计机器学习项目架构，确定要使用的技术。3)梳理项目过程需要的数据，以及数据处理过程和规则（例如，数据采集和标注规则，数据转换、清洗、特征选择和特征生成规则等），这些规则会根据后续的反馈持续迭代更新。4)开发对应的算法、训练代码、数据脚本、模型服务代码等。5)基于算法和脚本，触发数据工程和模型实验流程，得到最佳特征数据与模型参数等。主要输出：项目计划，设计文档，用于数据工程、特征工程、模型训练及模型服务的代码与配置。2.数据工程流水线 数据工程流水线是指以流水线方式，对数据进行接入、处理、存储、分析等工程化处理。目的是解决数据来源繁杂、数据及特征难以共享、数据管理不统一等问题，为模型开发及模型服务提供干净可用的数据原料。主要输入：原始数据、数据处理和特征工程的代码与配置。主要步骤：人工智能研发运营体系（MLOps）实践指南（2023 年）16 1)接入并提取原始数据，包括流数据、静态批处理数据或云存储数据。2)对原始数据进行初步分析探索，挖掘并分析数据内部结构、分布等规律，检查数据质量。3)数据处理从数据清洗与转换开始，以预定义的转换规则作为输入，处理数据异常、缺失、冗余等问题，生成可用格式的数据作为输出。4)最大限度地从原始数据或处理后的数据中提取、变换为新的或更高级的特征，预定义的特征工程规则作为输入，将生成的特征作为输出，并存储至特征库。主要输出：处理后的数据、特征。3.模型实验流水线 模型实验流水线是指以流水线方式，采用数据、算法和参数进行训练的实验过程。目的是解决过程难以回溯、实验难以复现、错误难以追查、参数难以配置和选择等问题，提高模型生产质量，并为持续训练提供基础。主要输入：原始数据、特征、模型实验所需代码与配置。主要步骤：1)利用特征库的能力，结合原始数据，开展数据分析，得到模型实验所需数据集。2)触发多轮模型训练，不断调整和选择性能最优算法和超参数。3)对不同模型参数进行交叉测试和验证，一旦性能指标达到预期，迭代训练将会停止。模型训练和模型评估任务可根据条件重复触发。4)导出模型并提交至仓库，包括训练算法、数据脚本、服务代码、模型等。人工智能研发运营体系（MLOps）实践指南（2023 年）17 主要输出：最佳算法、数据脚本、模型服务代码与配置、模型文件、实验指标。4.持续集成流水线 持续集成流水线是指以流水线方式，对模型和代码进行持续构建与集成的过程。目的是解决模型及代码构建、集成测试、安全扫描等过程繁琐、易出错、集成效率低下等问题，并以流水线的自动化提高交付质量。主要输入：最佳算法、数据脚本、模型服务代码与配置、模型文件。主要步骤：1)将代码、模型、配置等要素进行构建打包和集成测试，生产出可交付的部署包（例如镜像文件、JAR 包等）。2)将构建、测试、扫描等过程进行集成，以生成持续集成流水线。3)对集成过程出现的问题进行反馈和处理，提高集成成功率。主要输出：部署包。5.持续部署流水线 持续部署流水线是指以流水线方式，将模型服务部署至目标环境并开展相应评估的过程。目的是解决部署周期长、部署配置易出错、部署进程启动晚、流量接入配置复杂、模型运行状态不稳定等问题，做好模型为业务系统提供推理服务的充分准备。主要输入：部署包、特征、服务工作流配置（例如更新策略或 AB实验策略等）。主要步骤：1)将模型服务部署至目标环境，并通过更新策略将新版本模型服务进行持续部署。人工智能研发运营体系（MLOps）实践指南（2023 年）18 2)对已部署模型服务配置相应流量管理策略，使其按照策略有序接入流量并开展验证和评估工作。3)根据已分配流量在模型上的运行结果，评估模型效果优劣，驱动模型优化。主要输出：模型服务、评估报告。6.持续训练流水线 持续训练流水线是指以流水线方式，依据相关条件的触发持续对模型进行训练的过程。目的是解决数据漂移、模型服务不符合预期等业务问题，以及重新训练复杂耗时等效率问题，提高模型自生产能力。主要输入：流水线配置（包括节点、触发条件、参数等）、旧数据、新数据、特征。主要步骤：1)从特征库自动提取版本化特征。2)自动化开展数据准备和验证，并拆分数据集。3)根据模型实验阶段已选择的算法和超参数，对新数据进行自动训练。4)执行自动化的模型评估、超参数迭代。5)训练后的模型被导出并保存至模型仓库。6)根据需要触发模型测试及持续部署流水线。主要输出：新模型。7.持续监控流水线 持续监控流水线是指以流水线方式，贯穿 MLOps 端到端生命周期，持续对过程和结果开展监控，同时在特定场景特定条件下触发模型重新训练的过程。目的是解决模型效果下降的问题，通过监控发现问题并持续改进，提高过程流转效率，确保模型服务质量。人工智能研发运营体系（MLOps）实践指南（2023 年）19 主要输入：各类指标数据。主要步骤：1)收集各类指标值，并进行记录和保存。2)根据既定规则开展数据分析。3)根据分析结果生成报告，必要时为触发器提供数据。主要输出：分析结果、触发值。（三）（三）MLOps 相关角色相关角色 尽管机器学习模型的构建主要由数据科学家完成，但要最终为业务系统提供推理服务却需要多角色合作。组织应围绕 MLOps 流程的持续运转，明确角色与分工，可提高多角色间的协作效率，从而提升整体生产效率和质量。下图展示了 MLOps 相关角色分工示意图，但由于 MLOps 领域的飞速发展，将来可能出现的新角色暂未列出。同时，在许多组织中，各角色可能是专职或兼任，具体如何安排应视组织结构和业务场景等情况而定。来源：中国信息通信研究院 图 9 MLOps 相关角色分工示意图 典型 MLOps 相关角色分工包含业务人员、项目经理、机器学习架构师、数据工程师、数据科学家、软件工程师、测试工程师和运人工智能研发运营体系（MLOps）实践指南（2023 年）20 维工程师等。表 1 展示了在实际的机器学习项目全生命周期中，业务人员、数据科学家等各类角色所关注的不同重点及具体的工作职责。表 1 MLOps 相关角色职责要求 角色角色 关注点关注点 工作职责工作职责 业务人业务人员员 业务需求 1.识别和收集产品的新需求、缺陷和改进方向；2.提出明确的需求目标，在交付阶段进行需求验收。项目经项目经理理 项目全生命周期过程 1.带领团队进行业务需求的可行性分析；2.制定项目计划，统筹把控和管理项目全流程的进度、成本、质量、风险、资源等；3.推动项目持续优化改进，复盘问题并协调制定改进措施。机器学机器学习架构习架构师师 组织级机器学习体系架构 1.统筹设计硬件、底层技术、开发平台到上层应用的架构；2.规划设计 MLOps 流程架构，保障机器学习项目生产过程的一致性，从而确保生产质量的可控；3.管理和维护各条机器学习流水线，确保流水线的可扩展和灵活性。数据工数据工程师程师 数据 开展数据探索性分析，并对数据进行清洗、筛选、加工等处理，同时构建特征工程（可与数据科学家共同构建），完成数据准备工作。数据科数据科学家学家(建模建模 专家专家)机器学习 模型 1.将业务需求转化为技术需求；2.跟进数据准备过程，确保数据的高质量；3.模型开发过程中，选择性能最佳的算法和超参数，开展模型构建、模型训练、模型评估和模型选择，输出精准、高效的模型；4.模型交付、运营监控过程中，配合问题定位和决策。有的组织在模型构建阶段，亦开展模型优化和压缩等工作。软件软件 工程师工程师 模型工程化 1.将数据科学家提供的模型转化为模型服务，开发服务代码，便于模型服务与业务系统无缝协作；2.对模型进行优化或压缩、集成和部署模型服务。人工智能研发运营体系（MLOps）实践指南（2023 年）21 角色角色 关注点关注点 工作职责工作职责 测试测试 工程师工程师 模型 测试 开展模型效果验证、模型服务的功能与非功能测试。运维运维 工程师工程师 模型交付与运营 维护 开展模型服务的上线部署和运营监控工作，保障模型生产运行的可靠性和高可用。来源：中国信息通信研究院 值得关注的是，近年来行业开始出现 MLOps 工程师角色，职责主要包括 MLOps 平台部署与维护、流水线构建与管理、模型优化、度量改进等。MLOps工程师在Linkedln新兴职业排行榜中高居榜首，五年内增长了 9.8 倍10。国内绝大部分组织中的 MLOps 工程师职责由数据科学家、软件工程师或运维工程师兼任，相信随着 MLOps 的普及与发展，MLOps 工程师将成为专职岗位。实践案例：中原银行的模型风险分析师实践案例：中原银行的模型风险分析师 中原银行在风险合规要求较高的场景中，设置模型风险分析师的角色，对数据科学家开发的模型进行验证评估，确保模型设计方案、开发过程满足既定的业务诉求，并满足监管、合规等相关政策要求。1.模型需求设计，结合统计方法与专家经验，验证模型原理和方法的合理性、模型的可用场景和局限性，清晰理解模型的特征、影响及参数估计情况，确保满足业务需求。2.建模过程验证，检查建模过程的合理性，包括需求管理、数据工程、模型开发等过程的准确性、合规性、可控性。3.模型效果验证，将模型输出结果与真实结果进行比较，检验概率、模型参数的区分能力、准确性、稳定性等，确保模型稳定可靠。10 如何成为 MLOps 工程师，MLOps 工程实践.人工智能研发运营体系（MLOps）实践指南（2023 年）22 四、MLOps 关键能力与技术实践 当前，MLOps 概念逐渐明晰，应用落地持续开展。组织在落地时，以总体流程架构为主线，以计划解决的问题为目标，对关键能力各个击破，逐步形成 MLOps 落地效应。为顺利构建和实施 MLOps 流水线，组织需提前做好关键能力的建设予以支撑。本章围绕 MLOps 过程管理、制品管理和基础保障三个维度，以业界共识为基础，提出了 12 个关键能力，并对工程实践过程中应考虑的核心要点展开分析，同时提供优秀实践案例以供参考，梳理了部分 MLOps 工具链清单（见附表）。来源：中国信息通信研究院 图 10 MLOps 关键能力示意图（一）数据处理（一）数据处理 数据处理是将源数据加工处理成模型开发所需数据，为模型开发及最终决策提供高质量数据。数据处理是 MLOps 生命周期的上游环节，是模型训练的基础，高质量的数据有助于生成更优质的模型。核心要点：对接入的源数据进行数据清洗、数据转换、数据增强等处理，以减少数据异常、缺失、冗余等问题，提高数据质量。源数据通常包人工智能研发运营体系（MLOps）实践指南（2023 年）23 括结构化数据和非结构化数据（例如文本、图像、音频等），结构化数据的处理包括去重、处理无效值和缺失值等。文本数据的处理包括降低字频、添加生僻字等；图像数据的处理包括旋转、翻转、裁切等；视频数据的处理包括抽帧等；音频数据的处理包括降噪等。当使用了文本、图像等非结构化数据时，需对处理好的数据进行标注。例如，文本类标注包括文字检测框、文字内容识别等；图像类标注包括目标检测框、语义分割块、关键点等；点云类标注包括目标检测框、语义分割块等；视频类标注包括目标识别框、语义分割块、关键点等；音频类标注包括语音、语调、音素等。支持大批量数据的接入和处理，具备一定自动化数据处理能力。实践案例实践案例 1：广东移动的数据处理：广东移动的数据处理 广东移动的数智化运维平台在数据工程过程中，为了应对复杂、海量、多样化的运维数据的搜集、处理、标注带来的挑战，进行了如下改造：1.多类型数据处理能力：针对异构多数据源、多格式类型的数据，应用分类方法识别数据类型，对多种类型数据通过聚合运算、零值处理、缺失值填充等方式进行处理，并根据场景需要实时加载数据。2.海量数据传输保护：在整个数据处理过程中，为确保海量数据传输的完整性和效率，在数据工程全流程，包括数据采集、数据传输、数据处理、数据接收、数据存储等过程均设置了保护机制。一是应用多区、多宿主机上多 HUB(集线器)仓库处理中心，保证传输正常。二是设立流量限制和过载保护机制，如避免流量突增、设立表空间监控阈值等，保证处理集群的稳定性。来源：广东移动 图 11 广东移动的数据处理能力示意图 人工智能研发运营体系（MLOps）实践指南（2023 年）24 实践案例实践案例 2：格物钛的数据处理：格物钛的数据处理 格物钛通过数据平台为数据工程团队提供以数据为中心的高效、便捷、安全的管理能力，并提供数据核心管理模块：1.将数据工程中原本分散的原始数据、语义数据、元数据统一进行管理、高效读写、处理与检索。2.提供便捷的版本管理能力，保证数据与模型的迭代可追溯、可复现。3.提供在线可交互的可视化能力，使得所见即所得。4.提供细颗粒度的权限管控与访问记录能力，保证数据的使用安全与数据血缘追踪能力。5.自定义的自动化工作流，让数据工程人员可以快速搭建不同的数据处理管道，如数据清洗、数据降采样、数据预标注、模型训练等，加速数据的流动与处理效率。6.提供丰富的开发者工具让数据与代码、系统轻松完成集成。来源：格物钛 图 12 格物钛的数据处理能力示意图 人工智能研发运营体系（MLOps）实践指南（2023 年）25 实践案例实践案例 3：云测数据的数据处理：云测数据的数据处理 云测数据标注平台结合数据在环和模型迭代在环新方式，将数据采集、处理、标注、训练、模型输出等进行持续迭代集成，支持图像、点云、视频、文本、语音等数据的加工处理，帮助企业快速获得高质量训练数据。1.通过数据标注平台，一是引入模型输出预识别结果，进一步降低人力成本；二是在迭代后期，人员只处理关键高价值数据并对 AI 辅助标注结果进行审核验证，大幅降低算法研发人员投入成本，减少模型训练时间。2.通过数据管理系统，在数据安全、大容量数据处理、数据挖掘、数据增强等方面，大幅提升数据使用效率，通过数据分级检索和数据资产管理能力，提升团队协作效率，持续挖掘数据价值。3.基于标准化 API 接口，实现与企业数据底座无缝对接，加速企业 MLOps数据处理速度，实现业务数据处理和训练一体化。来源：云测数据 图 13 云测数据的数据处理能力架构图（二）模型训练（二）模型训练 模型训练是基于数据集和算法进行训练，包括算法选择、超参数优化、模型评估和选择等主要环节，最终输出已训练模型。模型训练的建模方式主要包括 Notebook 自定义开发编码方式、低代码拖拽建模方式、AutoML 自动机器学习建模方式等。模型训练是 MLOps 的人工智能研发运营体系（MLOps）实践指南（2023 年）26 核心步骤，训练过程的效率提升和训练结果的质量提升，对 MLOps整体质效的保障起着至关重要的作用。核心要点：快速找到模型的最佳算法及对应超参数。超参数选择的方法通常包括手动搜索和自动搜索（例如，网格搜索、随机搜索、贝叶斯优化、遗传算法等）。通过评估指标，对模型进行批量评估，并可视化和比较模型性能，选定最优模型。合理地最大化地使用训练资源。从工程化角度，组织希望同一时间并行执行多组模型训练，从成本角度，组织又希望有限的算力资源可以被高效利用，因此有效平衡资源的利用非常重要。支持多种 AI 框架开展模型训练。支持模型的可解释（例如采用特征重要性等方式）。实践案例实践案例 1：华为终端云的模型训练：华为终端云的模型训练 1.大模型的高效训练：华为终端云 MLOps 平台通过自研 PS 训练框架，结合华为自研算力硬件，提供近线增量训练能力，打通离线全量训练-近线增量训练-在线推理全流程，支撑推荐 500G 大模型的高效训练与上线。2.资源的合理调度：训练任务资源调度存在明显波峰波谷和多种资源(V100、A100、NVLink 等)诉求等现象，同时为满足训练 SLA 和优先级诉求，华为终端云从以下三方面增强调度能力：1)支持调度优先级与资源可预期排队能力，构建基线 超分的资源配额分配，满足高优先级任务 SLA。2)支持可视化任务调度日历图，辅助算法科学家合理设置任务调度时间，削峰填谷，提高整体资源占用率。3)支持跨资源池混合调用与资源弹性伸缩，满足算法工程师对资源的突发诉求。人工智能研发运营体系（MLOps）实践指南（2023 年）27 实践案例实践案例 2：百度的模型训练：百度的模型训练 百度智能云企业 AI 开发平台提供 Notebook 建模、可视化建模、作业建模、自动化建模、产线建模等多种建模方式，支持主流机器学习和深度学习开发框架，并能通过 Docker 镜像的形式来支持其他框架和第三方软件库。平台内置 ERNIE 等全面领先的 NLP 模型，以及各领域各方向的高精度预训练模型，并支持对大模型进行训练加速。该平台帮助不同建模水平的人员提升建模效率，助力企业构建统一的 AI 基础设施。来源：百度 图 14 百度的模型训练架构图（三）构建集成（三）构建集成 构建集成是将代码、模型、配置等要素进行构建打包和集成测试，生产出可交付物（交付物的形态例如有部署包、镜像等）的过程，涵盖模型构建（模型训练过程）和模型服务构建。构建集成是将模型转换为服务的关键环节，真正意义上实现从数据到服务的跨越。通过持人工智能研发运营体系（MLOps）实践指南（2023 年）28 续集成的标准化、自动化流程，大幅缩短交付周期，减少人工实施和返工成本。核心要点：对构建过程进行规划、设计和执行，包括构建的类型、触发方式、执行周期等内容。将构建与测试等环节进行衔接，形成持续集成流水线，通常包括模型构建、代码打包、集成测试、静态扫描等，某些情况下还包括模型转换与模型优化。当数据、代码、模型、配置等发生变更时，可快速触发持续集成流水线。对集成过程中出现的问题具备自动化反馈和管理机制（例如，对解决时长进行管理），以及一定的问题修复能力，为高频率集成提供基础。实践案例实践案例 1：马上消费的构建集成：马上消费的构建集成 在 MLOps 平台中，持续构建与集成需要解决不同角色（数据工程师、机器学习算法工程师、工程开发人员、模型运营人员等）的平滑协作、不同阶段（开发、构建、部署等）的自动化运行。马上消费的智马平台为了应对持续构建与集成的需求，支持以下持续化能力：1.新特性、新算法更新时触发自动持续构建集成，完成构建、集成、测试等完整的流程并发布新的 ML pipeline。2.更新数据、模型衰减时触发新的 ML pipeline 运行，完成持续训练和部署。3.按计划触发新的 ML pipeline 运行。4.按配置触发 ML pipeline 的不同阶段运行。人工智能研发运营体系（MLOps）实践指南（2023 年）29 来源：马上消费 图 15 马上消费的构建集成流程图 实践案例实践案例 2：腾讯的构建集成：腾讯的构建集成 腾讯的太极机器学习平台（Tai Ji Machine Learning Platform）为腾讯广告场景打造了一站式平台，贯穿特征管理、样本生产、模型训练、模型服务等主要环节，提供全流程广告模型开发功能和协作空间 workspace 能力，围绕构建与集成将各个环节自动化，提高生产效率。主要包括以下能力：1.持续实验：算法工程师可通过 fork 能力将线上基线模型及其参数配置等“复制”后进行持续实验，通过特征选择、模型结构优化和超参优化等实验探索效果更好的模型。2.持续训练：模型上线后不断有实时样本生成，通过持续训练将实时样本输入到模型中不断迭代训练，这样避免模型上线后的效果衰减。3.模型构建：模型经过离线评估后，通过集成腾讯智研 CI/CD 系统的Pipeline 能力，先进行模型一致性校验，然后将模型训练拓扑结构、模型及推理运行时自动构建为算法包制品，用于模型在线部署。4.沙箱验证：沙箱环境是一个预发布环境，通过引流一部分线上真实流量验证算法相关指标。沙箱验证不通过将会拦截模型线上实验和部署流程，沙箱验证通过后可经主动触发和批量调度将模型发布到生成环境进行流量实验和放量。人工智能研发运营体系（MLOps）实践指南（2023 年）30 5.在线实验：模型上线后需要在经过 AB 实验逐步进行小流量实验、放量实验和固化实验，通过线上对算法和业务指标的评估，逐步完成线上模型的更新替换。来源：腾讯 图 16 腾讯的 MLOps 平台示意图（四）模型服务（四）模型服务 模型服务是通过配置和管理所依赖的参数，形成模型服务部署至目标环境，以 API 接口等方式为业务系统所调用，输出预测结果，并根据用户需求灵活分配计算资源。模型服务通常包括实时服务和批量服务两种方式。模型服务是实现模型在线全生命周期托管，简化业务系统集成模型的过程。通常在大多数情况下，模型以独立服务的方式与业务系统解耦。核心要点：支持服务的可视化创建和编排，对服务启动过程进行监控，服务启动后支持在线缩扩容、服务停止、流量分配、服务限流、负载均衡等能力。使用参数配置构建在线、离线或流式推理服务镜像。集成常见 AI 框架，例如，Tensorflow、Pytorch、Marian、Mxnet、Sklearn 等。通过配置和触发更新策略，实现模型服务的自动化部署。更新策略通常包括灰度更新、滚动更新、蓝绿更新等。人工智能研发运营体系（MLOps）实践指南（2023 年）31 根据应用场景的需求，支持低延迟、近实时(在线)预测服务，或高吞吐量批处理(离线)预测服务。集成 A/B 测试能力，支持自定义实验、流量、指标、报表等，提供效果监控，为业务系统决策提供支撑。对模型服务进行版本化管理和权限控制。实践案例实践案例 1：浦发银行的模型服务：浦发银行的模型服务 浦发银行深度学习平台 MLP 实现对人工智能模型从训练、测试、部署、运行、迭代的全生命周期的研发管理，引入多种机器学习、深度学习先进算法和模型，实现模型开发与模型投产无缝衔接。主要模块包含：1.模型选择：内置多种经优调后的预训练模型，可查看模型整体评估情况（包括指标曲线和混淆矩阵等），全面对比分析各项指标。2.模型调试：内置多种模型优化技术用于优化模型推理性能，支持云边端各类硬件的部署要求，可配置模型在线测试和批量测试能力。3.服务编排：通过服务组件编排，对一系列原子能力进行组合，并支持多维度管理和调度编排服务。4.AB 实验：支持在控制变量的情况下完成模型效果比对，依据请求分发的流量策略进行 AB 测试的指标展示。5.发布上线：支持在线预测服务、离线预测服务，满足服务发布过程中的在线调试、异步批量预测、模型转换、压缩和加密等处理需求；支持通过血缘关系追踪模型和数据，根据已有关系快速更新模型；灵活支持各种预测服务的数据回流方式。6.指标监控：自动监控模型运行状态，并在检测出现问题时发送邮件警告；依据模型监控的整体情况，触发模型自动重训；支持对模型效果偏移的实时监控，保障业务应用效果。人工智能研发运营体系（MLOps）实践指南（2023 年）32 来源：浦发银行 图 17 浦发银行模型服务示意图 实践案例实践案例 2：建行的模型服务：建行的模型服务 中国建设银行的“天权人工智能平台”模型服务化模块可使模型更快、更合规地应用于生产，其包括模型管理、模型封装、模型部署、模型监控等功能，模型服务化提供两种解决方案：1.低代码解决方案，平台为用户提供丰富的推理服务器，支持对符合推理服务器规范的模型包进行快速部署。2.CI/CD 解决方案，平台为用户提供一系列 CI/CD 和编排工具，支持推理组件的构建和推理图的编排，具备模型组件化编排和部署能力。1)封装空间，提供云端的开发环境，支持多种技术栈，集成在线编辑器。2)封装实验，提供丰富的封装案例，支持在线运行封装案例，以便熟悉封装框架。3)封装流水线，提供多种类型的封装流水线模板，可用于快速构建不同类别的推理组件，具备持续集成能力。封装流水线种类包括基础镜像封装流水线、组件镜像封装流水线等。4)镜像仓库：对基础镜像和组件镜像进行统一管理。基础镜像包括官方基 人工智能研发运营体系（MLOps）实践指南（2023 年）33 础镜像和自定义基础镜像，组件镜像包括模型镜像、转换器镜像、路由器镜像、合并器镜像等。5)设计器：可用于在线编排推理组件，实现不同的推理逻辑，满足不同场景的推理需求。组件化的编排方式，提升了不同场景下组件的复用能力。6)推理图：提供推理图的统一管理能力，支持推理图的版本化管理。来源：建信金科 图 18 建行模型服务架构图 实践案例实践案例 3：中移在线中心：中移在线中心的部署发布的部署发布 中国移动在线营销服务中心负责中国移动全国 10 亿客户线上营销服务的统筹运营，其内部 Polaris MLOps 平台的模型部署方案遵循流动、反馈、实验等3 大原则。流动原则缩短了开发运维交付周期。反馈原则为建设安全可靠的工作体系提供保障。实验原则使组织的改进和创新成为日常工作的一部分。使用 Polaris MLOps 后，算法类服务发布频率由数月一次提升为每月数十次，发布周期大幅降低。1.代码、模型部署准备 1）已经通过评审的代码推送到 Git 仓库。始终确保代码和基础设施处于可部署状态，所有合并到主干的代码都可以安全地部署到生产环境。在源头保障代码质量。人工智能研发运营体系（MLOps）实践指南（2023 年）34 2）模型通过评估加密后，推送至基于 DVC 二次开发的模型仓库。为保证SLA，不推荐同时发布新版本代码、模型。2.执行 CI/CD 流水线 该过程以容器云平台为基础设施，动态完成镜像构建，镜像构建完成后实时销毁构建环境。整套持续集成、持续交付流程以开源工具或自主研发工具为主，以公共组件面向全在线中心提供服务。1）CI/CD 流水线在执行前应首先完成配置并通过测试验证。2）执行 CI 流水线，流水线将同时从模型仓库和 Git 仓库中分别拉取模型、代码，通过镜像构建工具完成代码编译、模型加载、镜像构建。3）通过自动化测试的镜像将被推送至镜像仓库或直接触发 CD 流水线执行完成模型部署。自动触发 CD 流水线功能可选择开启或关闭，开启时会自动触发 CD 流水线执行，关闭时镜像将被直接推送至镜像仓库。3.服务发布 1）平台默认提供蓝绿发布、滚动发布两种发布方式。可以通过 CD 流水线完成服务发布，发布方式可根据实际情况进行选择。2）服务发布过程出现异常时，可以通过平台轻松实现服务回滚。服务将从镜像仓库获取指定版本镜像，并从平台获取相应配置。3）自动化测试触发 CD 流水线选项被关闭时，手动选择执行蓝绿发布或滚动发布。来源：中移在线营销服务中心 图 19 中移在线中心 Polaris MLOps 平台模型部署流程 人工智能研发运营体系（MLOps）实践指南（2023 年）35 实践案例实践案例 4：星环科技：星环科技的部署发布的部署发布 星环科技的模型部署发布流程如下：1)将模型开发平台训练生成的模型文件，上架并注册至模型仓库。2)创建服务推理图，基于业务场景构建（一个或多个）模型的推理逻辑，选择模型运行时环境，并装载指定模型及其部署版本。3)将推理逻辑整体部署为模型服务，包括两类应用类型。一是将模型部署发布为实时应用服务，配置模型所需资源、部署策略等信息，最终生成实时响应的模型服务 API 接口；二是将模型部署为批处理作业，配置模型所需资源、数据来源、结果输出、调度方式等信息，最终生成模型批量预测任务。来源：星环科技 图 20 星环科技 MLOps 流程图（五）运营监控（五）运营监控 运营监控是对模型生产过程和线上运营情况进行持续监控，便于及时发现和排查问题，保障模型的效果稳定和可靠，辅助运营决策。运营监控通常分为模型监控和运维监控。1.模型监控包括，一是数据监控，对数据及特征进行监控，识别数据漂移情况，保障数据的及时、准确和完整性等；二是模型性能监控，对模型的性能指标（准确率、召回率等）进行评估，保障模型结人工智能研发运营体系（MLOps）实践指南（2023 年）36 果的可信；三是模型效果监控，根据模型服务的推理结果，监控业务指标，保障业务目标的达成。2.运维监控包括，一是基础设施监控，对主机或容器的健康状况、资源（CPU、GPU 等）使用率、I/O 占用率等进行监控，保障运行环境的稳定；二是服务监控，对模型服务性能（服务数量、访问量、时延、并发等）、异常调用等进行监控，保障模型服务的可靠性；三是过程监控，对各任务或流水线的运行情况（执行结果、SLA 等）进行监控，保障模型生产过程的稳定和可靠。运营监控是在环境变化的情况下，及时发现模型问题，以决策在线更新或重新训练模型，从而提供更稳健和更优质的推理服务，并可持续改进 MLOps 过程质效。核心要点：通过监控的自动化实时能力，实现持续监控和运营的目标。支持历史监控数据或事件的记录，保证监控过程的可追溯能力。建立健全的预警、分析和处置机制，包括全自动化的预警能力，部分自动化或智能化的分析和处置能力。与持续训练流水线高效衔接，在实时性要求较高等场景下，运营监控应为持续训练提供强有力的支持，实现模型重训和在线更新。实践案例实践案例 1：中国联通软件研究院中国联通软件研究院的运营监控的运营监控 1.模型生产监控模型生产监控，从数据质量监控、特征稳定度监控、模型稳定度监控、多维度监控等方面监控模型生产质量，是模型有效赋能的基础。数据层面：数据层面：进行数据质量监控和特征稳定度监控，包括及时性、空值率、波动率、特征稳定度等。模型层面：模型层面：监控模型推理结果的分布稳定度，以及模型在时间维度和省分维度。2.模型成效闭环运营分析模型成效闭环运营分析，从多维度、多指标实现模型赋能成效的运营分析。人工智能研发运营体系（MLOps）实践指南（2023 年）37 营销漏斗分析：剖析营销策略，客观评价模型成效，以成效引导模型赋能提升。时间维度分析：时间维度监控模型是否持续保持稳定且高质量的赋能成效，成效出现下滑时借助漏斗分析，甄别模型问题。省分维度分析：剖析同一模型在不同省分的表现差异，借助漏斗分析定位策略问题，沉淀标杆案例。多指标监控：监控触达量、办理量、办理率、触达办理率、topN 触达办理率等核心指标，分析运营问题，为模型优化提供建议。来源：联通软件研究院 图 21 联通软件研究院模型成效闭环运营分析示意图 实践案例实践案例 2：中原银行中原银行的运营监控的运营监控 中原银行的运营监控主要包括以下五大维度：1.基础平台：基础平台：CPU、GPU、内存、网络等维度的监控和预警。2.开发工具：开发工具：机器学习平台、智能决策平台、知识图谱等平台自身的运维监控。3.数据基础服务与治理平台：数据基础服务与治理平台：通用性数据：针对统一特征加工，全链路实现模型数据的监控，该部分通过特征特征加工平台实现(规划中)。定制性数据：通过数据加工平台（数栈、数据前置），监控加工过程中出现的逻辑等问题进行监控。例如，逻辑加工成功与否(数栈)、数据加工过程(天 人工智能研发运营体系（MLOps）实践指南（2023 年）38 梯)等。4.模型维度监控：模型维度监控：统计模型：性能(GINI、KS、AUC、LIFT)、稳定性(评分分布、PSI)等。规则模型：触发率等。变量评估：性能(IV)、稳定性(PSI)等。5.业务维度监控：业务维度监控：准入漏斗：申请量、通过量(通过率)、提款客户数(提款率)等。运营情况：累计授信金额、余额、违约余额、不良余额等。业务指标：贷中(预警率)、贷后(入催率、出催率等)。（六）模型重训（六）模型重训 模型重训是在机器学习项目的动态环境中，通过模型重训开展持续迭代，生成新模型替换旧模型，以维持模型性能。模型重训通常包括离线重训和在线（生产环境）重训两种。模型重训是为了减少由于数据漂移和内容漂移带来的风险，并为数据科学家提供模型持续优化的快速渠道，以降低训练成本，提升模型新鲜度。核心要点：模型重训包括两个前提，一是明确了监控指标和触发条件，二是具有配置好的模型训练流水线。通过持续监控流水线的输出（例如，当监控指标低于阈值时，输出触发请求），或人工方式，触发模型重训任务的执行。对于安全性要求较高的某些场景，或者当对模型需要进行较大变更时，可以选择离线重训。对于实时性要求较高的某些场景，可以选择在线重训。部署发布时，应考虑模型训练流水线的更新。例如，有的组织在部署发布模型服务时，将模型训练所需配置一并发布，以供持续训练流水线获取最新配置，便于重新训练的开展。人工智能研发运营体系（MLOps）实践指南（2023 年）39 实践案例：蚂蚁的模型重训实践案例：蚂蚁的模型重训 蚂蚁在构建持续训练能力时，首先解决三个问题何时应重新训练模型、应使用哪些数据重训、应该重新训练什么。来源：蚂蚁 图 22 蚂蚁的持续训练能力示意图 通过构建持续训练链路和自动化训练能力，当告警中心监测到模型性能出现衰退或数据漂移等情况后，通知博弈中心，并依据在博弈中心配置的迭代模板进行模型自迭代流程。一般迭代模板主要分为以下四大类：1.模型重训，包括 AutoRefit 和 AutoRetrain。1）AutoRefit 即模型自动迭代能力，是由监控中心持续对线上模型性能进行监控，当相关指标低于阈值时，触发训练中心的训练任务进行持续训练。训练中心收到监控中心发出的迭代请求后，从案件中心中获取最新样本集，依据AuotML 的自动模型选择和自动参数寻优能力自动训练出最新模型。最新模型推送到测评中心，由测评中心对模型进行性能、鲁棒性、公平性、机密性等全方位的测评，达到准出条件后，产出测评报告，并推送到发布中心。在发布中心通过一键部署、AB 测试和自动发布能力将模型发布到线上，由此完成一次完整的模型迭代过程。2）AutoRetrain 即模型自动生产能力，在 AutoRefit 效果甚微时自动触发。相较 AutoRefit，增加了自动特征工程能力,包括 AutoML 中的自动特征工程、自动模型选择和参数寻优（深度学习中是神经网络结构搜索 NAS）等全部人工智能研发运营体系（MLOps）实践指南（2023 年）40 能力，也实现了端到端的机器学习自动化全过程，打通了从研发到生产的全链路。2.增量学习，主要解决知识遗忘的问题。3.持续标注与主动学习，主要解决在没有标注的场景下模型监控与迭代问题。4.SOTA HPO，主要解决将最新模型快速在业务场景落地的问题。来源：蚂蚁 图 23 蚂蚁的持续训练流程图（七）实验管理（七）实验管理 实验管理是对实验过程和信息进行有序、有效的管理，管理内容包括环境、特征、参数、指标、模型信息等，并支持实验配置记录与版本控制、可视化管理、实验结果对比等能力，保证实验的可重复性，并提供可视化管理界面，支持实验结果对比，提升模型探索效率。实验管理是为了跟踪实验过程和变化，快速实现结果比对和过程重现，提升模型探索效率，提高可追溯能力。核心要点：人工智能研发运营体系（MLOps）实践指南（2023 年）41 收集并记录实验所需信息，包括实验结果、各环节执行结果、执行配置（数据、代码、参数等）。基于可追溯和可复现的要求，可跟踪并查看实验信息。开展实验版本管理，并对实验过程及结果进行对比。选择合适的实验跟踪方法，例如采用实验管理工具，或搭建定制的实验管理平台等方式，开展自动化跟踪。实验异常的原因定位，支持部分自动化或智能化定位和分析能力。实践案例实践案例 1：百度的实验管理：百度的实验管理 百度智能云企业 AI 开发平台提供实验管理能力，支持用户查看实验和训练任务的详细信息，跟踪每个训练任务的运行状态、指标和日志，提升模型开发质量。通过实验管理，一是用户可对比同建模或跨建模方式下的实验效果；二是以实验对比找到关键影响因素，方便复现和调优；三是实现全平台建模方式的全过程记录。来源：百度 图 24 百度的实验管理流程图 人工智能研发运营体系（MLOps）实践指南（2023 年）42 实践案例实践案例 2：华为终端云的实验管理：华为终端云的实验管理 华为终端云 MLOps 平台在实验管理方面的基本能力如下：1.支持以模型/任务为起点，结合实验配置版本管理（特征配置、算法配置、任务/参数配置）与实验过程记录留存能力，可视化追溯模型实验全过程，支持模型可复现。2.支持配置模型评估指标在多组实验间的快速对比能力，帮助开发者快速筛选出最佳实验。3.支持 AutoML、Jupyter 等工具，辅助开发者快速完成数据探索与超参优化过程。来源：华为终端云 图 25 华为终端云的实验管理界面 人工智能研发运营体系（MLOps）实践指南（2023 年）43 （八）流水线管理（八）流水线管理 流水线管理是通过提供机器学习任务的编排能力和容错能力，允许设置任务的依赖关系和调度配置，并对失败的任务生成报告和告警，从而为自动化高效执行任务提供基础。流水线管理使数据科学家等团队成员从繁琐的手动机器学习工作流程中解放出来，以便拥有更多时间研究和优化模型。核心要点：以模型为中心构建流水线，并通过数据处理、特征工程和模型训练等任务的周期性依赖关系进行关联。支持灵活的任务执行策略（例如，使用周期性、定时、消息等方式触发流水线），同时根据上下游依赖就绪情况持续运转流水线。支持可视化编排能力、串行及并行逻辑控制能力，和版本控制能力。将任务节点与推理组件沉淀为原子能力，支持流水线复用。实践案例实践案例 1：中国农业银行中国农业银行的流水线管理的流水线管理 中国农业银行构建标准的 AI 模型训练、验证、部署、后评价等流水线，规范各阶段工作，促进数据科学家、测试工程师、研发工程师等不同角色的人员协同，提质增效。流水线具备可视化编排、版本管理、便捷复用、易于追溯等特点，流水线之间能够顺畅、自动衔接。面向用户提供流水线服务，可满足自动化运行、实验可复现、可重复使用、并发执行、环境解耦等要求。模型流水线依赖数据流水线提供规范数据，也具备并拓展了 DevOps 流水线的相关能力适配 AI 模型的构建、集成、测试和部署等。后评价流水线主要用于判断、反馈并驱动 AI 模型的持续训练。人工智能研发运营体系（MLOps）实践指南（2023 年）44 来源：农行 图 26 农行的流水线管理示意图 实践案例实践案例 2：华为终端云的流水线管理：华为终端云的流水线管理 华为终端云 MLOps 平台，支持以模型为中心的任务 Pipeline，同时结合DataOps 数据管理与 DevOps 代码包开发部署能力，实现数据流转、代码部署、训练、推理的全流程编排和自动化实施，具备灵活的执行策略、可视化编排、组件复用等关键能力。来源：华为终端云 图 27 华为终端云的流水线编排可视化能力示意图 人工智能研发运营体系（MLOps）实践指南（2023 年）45 （九）特征管理（九）特征管理 特征管理是通过建立一个集中式存储区（如特征平台），对特征全生命周期进行标准化处理和管理（如生产、存储与消费等），提升特征工程效率。特征存储区别于传统数据管理方式，它需要同时考虑离线特征和在线特征的存储，一是为实验提供非实时的特征数据，二是为在线推理服务提供高吞吐、低延迟的服务。特征管理是为了将特征在组织内部统一管理和共享，并通过离线在线特征的统一，提高模型训练和推理服务效果的一致性。核心要点：对特征的基本元数据、数据来源、计算逻辑、特征版本等进行统一管理。对特征进行分组及多版本的集中存储，保证特征获取时的性能与稳定。通过特征重要性分析、相关性分析等过程，选择特征。根据场景需求，保证离线特征和在线特征处理逻辑及结果的一致性。（例如原始特征在线获取和特征在线转换等）。对特征生产、特征存储、样本生成等代码开展算子化、配置化开发。实践案例实践案例 1：华为终端云的特征管理：华为终端云的特征管理 华为终端云在落地特征工程时，面临高效特征实验与特征服务性能方面的挑战时，采取以下措施：实现高效特征实验能力。实现高效特征实验能力。一是，持快速的实验配置与实验管道定义能力；二是，支持实验管道 实验配置的编译执行，支持自动执行与人工确认节点；三是，实验管道支持可视化节点编排与模板能力。保障特征在线服务性能。保障特征在线服务性能。通过特征在线服务，支持 API 方式的特征实时获取与转换能力。在面对推荐场景下的高频特征获取和实时特征生产场景，通过 人工智能研发运营体系（MLOps）实践指南（2023 年）46 高性能的存储中间件来解决特征获取性能问题。来源：华为终端云 图 28 华为终端云的特征实验流程图 实践案例实践案例 2：浦发银行的特征工程：浦发银行的特征工程 浦发银行深度学习平台 MLP 提供特征工程能力，用于保证特征数据一致性和实现特征数据质量的全链路自动化监控。1.特征工程的自动化能力：自动进行特征构建、提取、选择等任务，支持特征血缘和下游影响分析能力，可配置特征计算逻辑，对特征数据进行比对设置和版本化管理。2.构建离在线一体特征库：解耦特征生产和特征消费环节，降低数据端到端的依赖；支持不同团队间的特征共享和复用，以及特征溯源和追踪；同时支持离线特征高吞吐使用场景和在线特征低延迟使用场景。3.特征数据自动化监控：通过 KS、AUC、PSI、排序性等指标开展特征实时监控；依据每个变量在训练时的分箱与上线后的分箱差异，判断特征分布是否发生了偏移，并实现自动预警；特征故障恢复：通过报警机制、自动定位和提醒处理机制提高特征故障恢复能力；支持定期监控报告（周、月、季度）反馈机制。人工智能研发运营体系（MLOps）实践指南（2023 年）47 来源：浦发银行 图 29 浦发银行的特征工程流程图（十）模型管理（十）模型管理 模型管理是通过标准化的模型接口，将大量的自训练模型和第三方模型进行统一集中管理。管理对象主要包括模型和模型服务。模型管理贯穿模型从上线到下线的全过程，有助于对模型资产进行统一盘点和管理，全面了解模型运行状态，便于模型共享使用，同时为模型风险管理、模型审计和模型可解释打下基础。核心要点：对模型进行注册和纳管。对模型资产进行管理，包括对模型文件、模型使用文档、模型评估指标与报告、模型服务的统一纳管。例如，增删改查、分类、权限管理、模型卡片等。对模型进行版本控制（包括基础信息、运行环境、输入输出等），支持更新查看、多维度比对、版本提交、版本回滚等能力。实践案例实践案例 1：河南移动的模型管理：河南移动的模型管理 河南移动融智工场通过算法中台对算法模型进行统一管控，包括模型接入、视图、分类、泛型、适配、共享复用等，提供算法模型的生命周期管理、版本管理、模型分享以及统一部署能力。人工智能研发运营体系（MLOps）实践指南（2023 年）48 1.模型接入管理：对开发型、内置型、三方型的算法模型进行管理，通过标准化的模型接入接口，将训练完成的模型纳入算法中台。2.模型视图管理：对接入算法模型的版本信息、脚本信息、和环境信息进行查询、修改，可实现对算法模理的清理、统一发布部署等。3.模型分类管理：对接入的算法模型进行聚类，提炼算法模型共性部分，为用户提供更加精准贴合需求的算法模型。目前算法中心沉淀了包括指标异常检测、指标预测、日志模式识别、日志异常检测、根因分析与推荐、告警降噪、多指标维度分析七大类场景的算法模型。4.模型泛型管理：将纳入管理的算法模型拆解重组装，形成和业务结合紧密的泛型，为后续服务化打下基础。提供算法模型及泛型的版本管理，支持对算法模型、算法泛型的效果和性能的评估、管理，支持多类算法、多类泛型的对比评估分析，可实现对算法模型、泛型进行标注说明。5.模型适配：根据多样化的业务需求进行算法模型、泛型推荐，使得模型更加适配实际场景的业务需求。6.模型共享复用：遵循 TMF Open API 标准提供规范的 RestAPI，将算法模型以服务化方式对外开放，实现模型能力的高复用、高敏捷、快速迭代。来源：河南移动 图 30 河南移动的模型管理示意图 人工智能研发运营体系（MLOps）实践指南（2023 年）49 实践案例实践案例 2：百度：百度的模型管理的模型管理 百度智能云企业 AI 开发平台通过模型中心的建设对模型进行集中纳管，包括模型导入、管理、评估、加速、加密、共享，支持构建和调试部署包，支持将模型快速部署至各类运行环境。1.模型纳管：可管理本平台训练得到的模型，也可导入第三方模型并进行统一管理。其中本平台训练模型可来源于零代码建模的图像、文本、语音、视频、结构化、场景建模模型，也可来源于全功能开发的 Notebook 建模、可视化建模、自动化建模及智能产线建模。第三方导入模型支持从本地上传或从存储选择，支持以模型文件或镜像形式导入。其中，模型文件支持 TensorFlow、PaddlePaddle、PyTorch、Sklearn、XGBoost、ONNX、PMML 等主流框架。2.多版本模型管理：可存储单个模型的多版本信息，包括版本号、模型来源、模型状态、模型类型、模型框架、网络结构/算法类型等，便于对多版本模型进行比较，以决定需采用的具体模型。3.部署包管理：可管理面向部署的模型镜像或 SDK 文件，以提升部署效率。支持基于模型文件、模型镜像或 Helm Chart 来构建部署包。4.模型评估：支持在云端和边缘环境下对多个模型的效果和性能进行全面评估。5.模型加速：可在降低少量模型推理准确性的情况下大幅压缩模型复杂度，提升模型性能，增加同等计算资源下预测推理服务的吞吐量。6.模型部署：支持模型云部署（发布为预测服务）和边缘部署（下发至边缘设备）。7.模型加密：导出模型时支持对压缩文件进行加密。8.模型共享：可将模型分享至当前项目所在组织或全平台。来源：百度 图 31 百度的模型管理流程图 人工智能研发运营体系（MLOps）实践指南（2023 年）50 实践案例实践案例 3：九章云极九章云极 DataCanvas 的模型管理的模型管理 九章云极 DataCanvas APS 机器学习平台，支持对机器学习模型、深度学习模型和预训练模型等进行分组和集中管理，并实现不同模型的统一评估和比对，从而识别冠军模型，以确保最佳模型性能。在某商业银行 ModelOps 平台建设过程中，应用 DataCanvas APS 构建了涵盖标准建模、过程管控、敏捷部署、灵活迭代、持续监控到退役下线的全生命周期模型管理闭环体系，打造适用于该商业银行的完整模型生态。通过模型管理模块注册纳管了平台自训练及第三方生产的近百个 AI 模型，按照业务场景细分为智能营销、智慧风控、运营支撑、审计合规、智能运维、创新应用等进行集中分类管理。通过对企业的 AI 模型资产的梳理分类、模型状态及版本的精细化管理，缩短了近 30%的模型迭代周期。来源：九章云极 图 32 九章云极 DataCanvas 模型管理功能示意图（十一）仓库管理（十一）仓库管理 仓库管理是建立多个仓库存储和管理不同的 AI 资产，包含元数据仓库、特征仓库、模型仓库、代码仓库、参数仓库等，以提供资产的版本化存档、访问、复用、追溯等能力。仓库管理实现了对各类资产的有序管理，是 AI 资产治理的基础。核心要点：人工智能研发运营体系（MLOps）实践指南（2023 年）51 版本管理：仓库管理承担重要信息存档的功能，需要支持版本控制及权限管理能力，以实现版本对比和追溯能力，并提高协作效率。任务复现：所存档的信息支持在新的任务中共享和复用。例如，元数据和特征，可以在新的训练任务中被引用，从而实现相关任务的复现。信息追溯：通过查询所存档信息被使用的情况，在操作时留痕，便于后续任务复现和项目复盘等阶段进行回溯。持续更新：仓库管理的信息支持用户进行编辑和更新，确保信息准确和可用。实践案例实践案例 1：中移研究院的元数据管理：中移研究院的元数据管理 中移研究院在落地 MLOps 过程中，通过 MongoDB 记录各任务元数据，并以日志方式将数据引入、特征工程、模型训练、模型服务等环节产生的元数据实时写入并存储。数据引入：引入时间、引入数据行数、列数、特征名、特征类型、数据特征（分布、空值比例、0 值数等统计数据）等。特征工程：数据行数、列数、特征名、特征类型、运行时间、运行时长、运行环境、函数、参数、特征工程模型位置、生成数据位置、生成数据行数、列数、衍生特征类型、衍生特征名称等。模型训练：引入数据位置、算法名称、算法版本、算法参数、资源消耗、运行时间、运行时长、模型性能、模型位置等。模型服务：数据行数、运行时长、运行结果、结果精度、结果位置等。实践案例实践案例 2：中信证券的：中信证券的 MLOps 平台和模型仓库平台和模型仓库 中信证券数据智能平台（DIP）作为一站式数据科学平台，是集数据准备与探索、环境构建、特征工程、算法实现、模型构建、模型管理、模型发布、模型服务运维于一体的多租户机器学习平台，实现了模型全生命周期闭环开发管理，形成了工程化的模型生产与批量化的模型管理体系。人工智能研发运营体系（MLOps）实践指南（2023 年）52 来源：中信证券 图 33 中信证券的机器学习生命周期示意图 1.环境：通过 Docker 技术为数据处理、代码编程、模型服务提供可定制化的运行时环境。2.数据：DIP 提供了数据的全生命周期管理功能，覆盖了数据采集、数据探索、数据处理等过程，提供了大量数据分析工具，实现高效地数据探查与数据分析。3.算子：算子是算法的载体，DIP 不但预置了常见的算子，还允许自定义新算子，极大的扩展了 DIP 可用范围，提升算子的高可用性与复用性。4.探索空间：基于 web 的多语言集成开发环境，用户不但可以操作工作空间中的各类文件，而且可以通过 FAAS 来直接使用项目下的数据集、算子等对象，编程人员可以在探索空间高效的进行数据处理、模型开发与验证等工作。5.自动建模：DIP 中预置了对常见数据分析场景的处理模型，用户只需要提供数据即可完成模型的自动训练。6.工作流：用户可以根据实际场景组合数据集和算子来构建工作流，从而解决特定场景下的机器学习问题。7.模型仓库：提供批量化的模型管理服务，如模型文件校验、模型评估、可视化解释等，被管理的模型既可以是基于工作流或自动建模训练的模型，也可以是使用代码基于开源机器学习框架训练的模型 人工智能研发运营体系（MLOps）实践指南（2023 年）53 8.模型服务：自动建模或工作流的训练得到模型，而服务则是模型的运行实例。（十二）模型安全（十二）模型安全 模型安全是指保障机器学习模型的机密性、完整性和可用性。机密性是为防止模型架构、参数及训练数据、测试数据被泄露的风险；完整性是为防止攻击者通过操控训练数据或测试数据而引导模型输出特定结果的风险；可用性是保障合法用户能够访问模型的准确输出和特征等权限内的信息。模型安全为行业应用提供安全保障，是决定模型是否可用的基础。通过模型安全的管控，使模型在数据收集、模型训练和模型应用等阶段减少遭受攻击的风险。核心要点：加强模型本身安全性。从算法和模型两个维度，一是从源头提升算法设计逻辑的安全性（例如算法设计不应存在歧视偏见等），以及算法依赖库的安全性；二是防范模型被攻击（例如药饵攻击、闪避攻击、模仿攻击、逆向攻击、供应链攻击、后门攻击等）。加强模型生产过程安全性。一是防范数据在传输、存储和使用过程中被窃取或泄露，并保证数据隐私性；二是防范算法和模型在传输、存储及使用过程中被窃取或泄露；三是保证模型生产过程相关步骤的安全性；四是保证数据准备过程、建模过程、部署上线过程的可追溯性。加强模型可解释性。贯穿生产过程对模型开展解释工作，包括特征可解释、算法可解释、参数可解释、模型无关可解释等。制定多方位的防御策略。例如，某一种针对对抗攻击的防御方案无法适用于所有类型的对抗攻击，因为在阻挡一种攻击时，可能给人工智能研发运营体系（MLOps）实践指南（2023 年）54 攻击者留下一个新的漏洞。因此，模型安全的防御需要通过集成的方式，均衡考虑和融合多种防御方案。实践案例实践案例 1：绿盟科技的模型安全绿盟科技的模型安全 模型在生命周期中潜藏着各种安全风险，因此绿盟科技在数据收集阶段、模型训练阶段和模型预测阶段均采取对应的防御措施保护数据、模型的安全，如下图所示。来源：绿盟科技 图 34 绿盟的模型安全防御策略示意图 在数据收集和模型训练阶段在数据收集和模型训练阶段，数据窃取会破坏数据机密性，数据投毒通过篡改数据或添加恶意数据影响模型性能。后门攻击则通过植入触发器影响模型决策结果。相应的防御策略包括恶意样本识别、数据清洗、隐私保护方法（同态加密、差分隐私、安全多方计算）、数据正则化、后门检测与移除等。在模型预测阶段在模型预测阶段，攻击者通过逃逸攻击误导模型的决策过程。相应的防御策略包括对模型输入或模型训练过程进行数据随机化、数据增强、对抗训练，通过防御蒸馏、梯度正则化来修改模型结构等。此外，攻击者也可以通过逆向工程、模型窃取、模型反演等方式推断出训练数据分布、训练集的属性信息或模型参数、模型架构等隐私。因此，模型持有者通常采用隐私保护方法、区块链技术等防御策略提升模型的安全性。人工智能研发运营体系（MLOps）实践指南（2023 年）55 实践案例实践案例 2：蚂蚁的模型安全：蚂蚁的模型安全 蚂蚁提供安全的 MLOps 生产链路，构建了从模型研发到发布、线上推理、监控可迭代的全生命周期。其核心点在于全链路自动化执行能力。在需求中心完成模型需求的对焦和立项；在案件样本中心完成样本口径确认、样本的生成和特征仿真，并依靠 AutoML 能力，自动完成特征生成、自动模型选择和自动训练；在蚁鉴测评中心，自动完成模型测评和模型压缩，产出模型评测报告；在发布中心对模型进行一键部署，发布到生产环境；在预测中心提供模型推理服务，并对在线模型进行实时预测；在监控中心持续对线上模型进行多维监控，当监控到模型性能衰退时，自动触发下一步的模型迭代流程。来源：蚂蚁 图 35 蚂蚁的 AntSecMLOps 架构图 在蚂蚁大安全有两类核心业务场景，一是与交易、转账等直接和资金打交道的资金安全场景，二是与小程序、文本、图片、音视频打交道的内容安全场景。针对这两种不同的场景，算法工程师和数据科学家们应用 AI 研发各种反洗钱、反欺诈、反赌博等各种守护用户安全的策略和模型。同时，蚂蚁通过其蚁鉴的 AI 安全检测平台，对样本、策略、模型、业务进行测评。一是对样本的质量、多样本的分布相似度、样本独立性、样本多样性进行评估；二是对策略的效能（例如覆盖率、打扰率）、策略间覆盖的重合度和增益进行评估；三是对模型多个维度进行测评（例如模型本身性能、模型稳定性 PSI、线上推理时性能（QPS/RT）及可信相关测评；四是在离线仿真环境下，模拟线上真实环境观测 人工智能研发运营体系（MLOps）实践指南（2023 年）56 策略、模型和策略 模型三者在业务上的表现。来源：蚂蚁 图 36 蚂蚁的蚁鉴-AI 安全检测平台 人工智能研发运营体系（MLOps）实践指南（2023 年）57 五、MLOps 总结与展望（一）总结（一）总结 从数字化到智能化时代的跨越中，人工智能不断为行业深化赋能，成为了组织可持续发展的重要方向。而 MLOps 作为人工智能生产落地的重要推动力，为行业缔造更多商业价值。MLOps 助力组织建立标准化管理体系，保障模型生产质量。为有效缓解 AI 生产过程的跨团队协作难度大、过程和资产管理欠缺、生产交付周期长等管理问题，MLOps 应时而生。MLOps 为机器学习模型全生命周期建设标准化、自动化、可持续改进的过程管理体系，使组织规模化、高质量、高效率、可持续地生产机器学习模型。MLOps 技术发展逐步成熟，但组织落地挑战不一而足。从 2015年至今，MLOps 前后经历了斟酌发酵、概念明确、落地应用等三大阶段。当前 MLOps 体系迅猛发展，带动着 MLOps 产品提供方和应用方的效能升级。一方面，资本市场持续火爆，MLOps 工具创新涌现；另一方面，MLOps 行业应用稳步推进，落地实践成果颇丰。组织将MLOps 引入到机器学习项目全生命周期是一个渐进式过程，在发展过程中仍面临着诸多挑战，例如，组织落地驱动力不足，支撑工具选型难、集成难，模型治理和可信道阻且长，环境间的交互难以平衡等。MLOps 框架体系趋向流程化，落地范式显露雏形。为填补国内MLOps 实践指南的空白和弥补行业可用标杆案例的不足，中国信通院联合产业专家对现有的业界 MLOps 框架体系做出梳理和归纳，覆盖到包含典型 MLOps 流程架构和典型 MLOps 相关角色。典型的MLOps 流程架构包含 7 大部分，需求分析与开发、数据工程流水线、模型实验工程流水线、持续集成流水线、模型训练流水线、模型服务流水线、持续监控流水线等；典型 MLOps 相关角色包含业务人工智能研发运营体系（MLOps）实践指南（2023 年）58 人员、项目经理、机器学习架构师、数据工程师、数据科学家、软件工程师、测试工程师和运维工程师等。此外，本指南收录了 12 大典型关键能力的 27 个业界实践案例，给各行业的组织布局规划MLOps 提供有益参考和指引。（二）展望（二）展望 MLOps 的高成熟度应用并不是一蹴而就的，实际生产的 MLOps体系还处于较低的成熟度。我们需要重视这一阶段爆发的待解决问题，如离线在线特征相互隔离、AI 资产缺少沉淀、自动化水平受制约等。因此，资产管理、过程管理、运营模式、特征平台、工具平台、大模型及可信 AI 等各项能力的持续发展跃迁，正成为 MLOps 发展的新趋势。MLOps 将在机器学习项目大规模高效率生产的基础上，不断迎接 AI 工程实践所带来的新挑战，推动 AI 资产安全有序管理，促进持续高效运营，保证模型及其生产过程更稳定、更可靠、更安全、更透明，充分发挥人工智能的经济价值和社会效益。第一，构建健全的 AI 资产治理体系。对数据、代码、特征、模型、元数据等 AI 资产进行有效管理和沉淀，将为组织带来更多长远价值。随着 AI 模型越来越多，已有诸多组织开始或已经构建了良好的模型管理体系，对模型开展了集中统一的管理和共享，但对模型安全和风险，以及算法和元数据等 AI 资产的管理略显薄弱或缺失。因此，构建组织级健全的 AI 资产治理体系，将是 MLOps 持续改进方向之一，也是提高 MLOps 能力成熟度水平的重要体现。比如，事前制定 AI 资产全局和局部的安全管理体系，事中做好 AI 资产生产过程保障，并对 AI 资产开展可追溯管理和运行监控，事后强化审计机制。人工智能研发运营体系（MLOps）实践指南（2023 年）59 第二，MLOps 自动化水平进一步提高。由于 MLOps 需多平台打通，与各资产仓库有效衔接，与各信息系统高效调度，当前诸多MLOps 实践过程中的自动化水平还不够高。接下来，数据工程、模型实验、持续集成、持续部署、持续训练、持续监控等流水线的自动化水平，及流水线间的衔接效率，将得到进一步提升，从而实现高效率、可持续的机器学习项目全生命周期管理能力。Analytics Insight 预测，AutoML 向 AutoMLOps 转变，将是 2023年 MLOps 十大发展趋势之一11。未来，我们不仅需要模型构建过程的自动化，更需要全链路的自动化能力。第三，构建可观测的高效模型运营体系。现阶段的 MLOps 模型运营主要是实现上线模型的监控，自动化发现问题并通知告警。未来将从三个方面持续优化运营模式，一是提高运营自动化水平，包括智能化分析能力、自动化处置能力等；二是提升运营的全面性，覆盖MLOps 全生命周期的运营体系，可有效地持续改进 MLOps 运行过程；三是增加可观测能力，提高决策速度、决策质量及决策智能化水平。构建更加高效、更加全面、更加智能化、可观测性更强的模型运营体系，将是全面落地 MLOps 的重要部分。第四，特征平台为高质量模型保驾护航。随着 FeatureOps 概念的深入和落地，特征平台将围绕离在线特征存储的互通和一致性、特征的高吞吐及低时延的调用、特征的自治化能力，持续挖掘和发挥特征的价值。特征平台作为特征管理的重要部分，将为模型训练、模型更新、在线推理提供更多支撑。第五，MLOps平台化能力持续提升。当前MLOps处于发展初期，工具繁杂，许多组织以解决问题为导向而选择工具，但又面临工具选 11https:/ 年）60 型和集成难的问题。而随着模型越来越多、业务需求越来越复杂，MLOps 平台化需求将成为趋势，帮助组织更体系化、更便捷、更灵活、更快速地使用 MLOps 助力产业升级。Gartner 预测，到 2026 年将有 80%的软件工程组织建立平台团队11。未来，组织将综合考虑 AI 项目的数量及需求、组织结构、战略规划、已有技术资产、成本，及当前 MLOps 成熟度水平等要素，选择端到端平台工具，或工具链 解决方案的方式，以平台化模式开展更大规模的落地。第六，提升 MLOps 能力应对大模型带来的挑战。随着大模型等新技术的落地应用，MLOps 应持续优化其技术架构，从低代码或无代码化、算力资源的访问和优化等方面持续提升性能，以应对大规模数据和预训练模型带来的挑战。例如，在搜索、广告、推荐等互联网核心业务场景，正从简单的小模型过渡到数万亿参数的大模型，而适用于普通模型生产的 MLOps 可能无法满足今后需求，因此 MLOps 将基于流水线，在海量样本构建、模型增量与全量的训练和部署、模型推理、模型回滚、模型回溯等方面提升能力；在大型语言模型方面，LLMOps 将成为 MLOps 发展的重要分支12，为基础模型的下游微调和部署发布等过程高效赋能。第七，可信 AI 助力组织可持续发展。落地 MLOps 的短期目标通常是提升模型迭代能力及效率，且在诸多组织中得以实现。而长期目标将在效率提升基础上，更多地关注模型安全与风险。通过保证模型的技术属性（准确、可信、鲁棒等）和社会属性（可解释、透明、隐私、安全、无偏见等），筑牢 AI 风险管理防线和安全防线，构建 AI可信体系，为组织生产更加更负责任的 AI 项目，助力组织可持续发 12 https:/ 年）61 展，将是未来持续探索之方向。人工智能研发运营体系（MLOps）实践指南（2023 年）62 参考文献参考文献 1.Mark Treveil&the Dataiku Team,Introducing MLOps:How to Scale Machine Learning in the Enterprise.2.Kreuzberger D,et al.Machine Learning Operations(MLOps):Overview,Definition,and ArchitectureJ.2022.3.Sculley D,et al.Hidden Technical Debt in Machine Learning SystemsJ.Advances in neural information processing systems,2015:2494-2502.4.Google.MLOps:Continuous delivery and automation pipelines in machine learning.5.Khalid Salama,et al.Practitioners guide to MLOps:A framework for continuous delivery and automation of machine learning.6.李攀登.MLOps 实战:机器学习从开发到生产.电子工业出版社,2022.7.彭河森，汪涵.构建实时机器学习系统.机械工业出版社,2017.8.周志华：机器学习，清华大学出版社,2016.63 附表附表 附表 1 MLOps 工具链清单 关键关键 能力能力 常用工具常用工具 国外国外 国内国内 数据处理数据处理 MapReduce、Labelme、CVAT、SQL、HDFS、Amazon Sagemaker、Alluxio、Spark、Pandas 百度 EasyData 智能数据服务平台、百度众测平台、华为云 ModelArts、华为云DataArts、整数智能数据平台、云测数据标注平台、九章云极 DataCanvas APS 机器学习平台、新华三绿洲平台 模型训练模型训练 Amazon Sagemaker、Microsoft Azure、Google Cloud Platform、Databricks 百度智能云企业 AI 开发平台、华为云ModelArts、九章云极 DataCanvas APS 机器学习平台、Colossal-AI 构建集成构建集成 Jenkins、CML(Continuous Machine Learning)、AWS CodePipeline and Step Functions、Azure DevOps 腾 讯 蓝 鲸、阿 里 云 效、九 章 云 极DataCanvas APS 机器学习平台、华为云CodeArts 模型服务模型服务 模型服务配置：Kubernetes、Docker；搭建API 服务的程序框架：Flask、Kubeflow的 KServing、TensorFlow Serving、Seldon.io服务、BentoML；批量推理：Apache Spark；云服务工具：Microsoft Azure ML REST API、AWS SageMaker Endpoints、IBM Watson Studio 和 Google Vertex AI 推理引擎：TensorRT、TensorFlow Lite 百度智能云企业 AI 开发平台、华为云ModelArts、九章云极 DataCanvas APS 机器学习平台 推 理 服 务 化：PaddlePaddle Serving、MindSpore Serving 推理引擎：MindSpore Lite（华为）、MNN（阿里）、TNN（腾讯）、MACE（小米）运营监控运营监控 Microsoft Azure、Algorithmia、Evidently AI 和 Deepchecks（结构化数据）、Seldon Alibi（非结构化数据）、Grafana、Kubeflow、MLflow、Amazon SageMaker 模型监控器、Prometheus Grafana 百度智能云企业 AI 开发平台、华为云ModelArts、星环科技 Sophon MLOps 模型重训模型重训 Airflow、Prefect、Ploomber 华为云 ModelArts 实验管理实验管理 MLflow、Neptune AI、Microsoft Azure、Amazon Sagemaker、Weights and Biases、DagsHub 百度智能云企业 AI 开发平台、九章云极DataCanvas APS 机器学习平台 特征管理特征管理 Google Feast、Featuretools、AWS Feature Store、Tecton.ai、Hopswork.ai 百度智能云企业 AI 开发平台、九章云极DataCanvas APS 机器学习平台、第四范式OpenMLDB 64 模型管理模型管理 Google Vertex AI、Microsoft Azure AI Builder、AWS SageMaker、Dataiku、MLflow 华为 ModelArts、百度智能云企业 AI 开发平台、九章云极 DataCanvas APS 机器学习平台、中国移动九天可视化建模平台 流水线管流水线管理理 Airflow、MLflow、Kubeflow、TensorFlow、ZenML、TFX 百度智能云企业 AI 开发平台、华为云ModelArts 代码仓库代码仓库 GitLab、GitHub 和 Gitea 码云 Gitee、华为云 CodeArts 元数据管元数据管理理 Kubeflow Pipelines、AWS SageMaker Pipelines、Azure ML 和 IBM Watson Studio、MLflow 百度智能云企业 AI 开发平台 数据版本数据版本管理管理 Dagshub、Databricks、DVC 百度智能云企业 AI 开发平台、九章云极DataCanvas APS 机器学习平台 模型安全模型安全 Cleverhans、Advertorch、DeepRobust、Opacus 百度 AdvBox、上海交通大学DAmageNet 端到端平端到端平台台 Kubeflow、MLflow、Neuro、Microsoft Azure、Google Cloud Platform、Amazon SageMaker、Valoha、Algorithmia、Neu.ro MLOps 百度智能云企业 AI 开发平台、华为终端云 MLOps 平台、华为 ModelArts、蚂蚁AntSecMLOps、腾讯太极机器学习平台、九章云极 DataCanvas APS 机器学习平台、绿盟科技 SecXOps、中国移动九天可视化建模平台 注：表格所述工具清单，来自于部分企业的调研报告，后续将持续更新。65 编制说明编制说明 本指南的撰写得到了 AI 领域多家企业与专家的支持和帮助，主要参与单位如下。参编单位：参编单位：中国信息通信研究院、华为终端有限公司、中国联合网络通信有限公司软件研究院、中国移动通信有限公司研究院、上海浦东发展银行股份有限公司、中国农业银行股份有限公司、建信金融科技有限责任公司、中原银行股份有限公司、中信证券股份有限公司、北京百度网讯科技有限公司、北京九章云极科技有限公司、思特沃克软件技术(北京）有限公司、新华三技术有限公司、中移动信息技术有限公司、中国移动通信集团广东有限公司、北京神州绿盟科技有限公司、中国移动通信有限公司在线营销服务中心、星环信息科技（上海）股份有限公司、格物钛（上海）智能科技有限公司、北京云测信息技术有限公司、蚂蚁科技集团股份有限公司、马上消费金融股份有限公司、腾讯科技（深圳）有限公司、北京华佑科技有限公司、中国移动通信集团河南有限公司、北京菱云科技有限公司、北京蔚时科技有限公司、云南白药集团医药电子商务有限公司、南京新一代人工智能研究院。66 中国信息通信研究院中国信息通信研究院 云计算与大数据研究所云计算与大数据研究所 地址：北京市海淀区花园北路地址：北京市海淀区花园北路 52 号号 邮编：邮编：100191 电话：电话：010-62309514 传真：传真：010-62304980 网址：网址：

46人已浏览 2023-03-17 72页 5星级

前言前言近几年，企业基础设施云原生化的趋势越来越强烈，从最开始的 IaaS 化到现在的微服务化，客户的颗粒度精细化和可观测性的需求更加强烈。容器网络为了满足客户更高性能和更高的密度，也一直在高速的发展和演进中，这必然对客户对云原生网络的可观测性带来了极高的门槛和挑战。鸟瞰容器网络，整个容器网络可以分为三个部分：Pod 网段，Service 网段和Node 网段。这三个网络要实现互联互通和访问控制，那么实现的技术原理是什么？整个链路又是什么，限制又是什么呢？Flannel，Terway 有啥区别？不同模式下网络性能如何？这些，需要客户在下搭建容器之前，就要依据自己的业务场景进行选择，而搭建完毕后，相关的架构又是无法转变，所以客户需要对每种架构特点要有充分了解。比如下图是个简图，Pod 网络既要实现同一个 ECS 的 Pod 间的网络互通和控制，又要实现不同 ECSPod 间的访问，Pod 访问 SVC 的后端可能在同一个 ECS也可能是其他 ECS，这些在不同模式下，数据链转发模式是不同的，从业务侧表现结果也是不一样的。为了提高云原生网络的可观测性，同时便于客户和前后线同学增加对业务链路的可读性，ACK 产研和 GTS-AES 联合共建，合作开发 ACK Net-Exporter 和云原生网络数据面可观测性系列，帮助客户和前后线同学了解云原生网络架构体系，简化对云原生网络的可观测性的门槛，优化客户运维和售后同学处理疑难问题的体验，提高云原生网络的链路的稳定性。目录一、容器网络内核原理.61.概述filter 框架.93.tc 子系统.184.eBPF 技术.26二、全景剖析阿里云容器网络数据链路.291.Flannel 模式架构设计.292.Terway ENI 模式架构设计.503.Terway ENIIP 模式架构设计.804.Terway IPVLAN EBPF 模式架构设计.1105.Terway ENI-Trunking 模式架构设计.1546.ASM Istio 模式架构.190三、容器网络常见观测工具及特点.2361.常见网络排查工具.2362.Net-Export 技术原理.240四、ACK Net-Exporter 快速上手.2431.Prometheus Grafana 配置.2442.ACK Net-Exporter 部署.2553.典型问题排查指南.267五、典型问题华山论剑.2741.某客户 nginx ingress 偶发性出现 4xx or 5xx.2742.某客户偶发 RTT 增高.2843.某客户反馈 pod 偶发性健康检查失败.2894.某客户偶发请求延迟.2945.某客户 SVC 后端负载不均.295容器网络内核原理6一、容器网络内核原理Linux 网络子系统是 Linux 系统最为基础的组成部分，理解 Linux 网络子系统的核心和基础架构，能够让我们在排查网络问题的过程中对问题有较为全局的认识，避免由于缺乏了解而多走弯路。本章节会以全景概览的方式对 Linux 网络子系统进行简单的描述。1.概述网络通信的本质是电磁波高低电位变化在物理介质上的传输，高低变化的电位形成二进制的数据传递给网络硬件设备，硬件网络设备则会根据特定的编码方式讲二进制的数据变成以太网报文，此时，物理网络的信息就被解调制成为了数据帧，在 OSI 七层网络协议的定义中，二进制的数据处于物理层，而以太网数据帧则处于数据链路层，对于 Linux内核来说，物理层和数据链路层之间的转换通常是由硬件设备的驱动完成，Linux 内核定义了与硬件设备驱动通信的标准，在完成数据链路层的收包后，硬件网络设备会将数据帧传递给操作系统 Linux 的内核进行处理，所以 Linux 网络协议栈的源头是数据链路层的数据帧报文。Linux 内核在处理数据帧报文是，按照数据帧的分片，TSO 等特性，将数据帧转化为可见的网络层报文，从而进行下一步的操作，内核在处理网络报文的时候，才用了一种非常高效的方式：内核通过一个 sk_buff 结构体，保存所有的报文数据。在网络层处理后传递给传输层的操作中，内核并不会为每一层进行复制，而是通过指针偏移的方式处理同一个 sk_buff 结构体。容器网络内核原理7下图是对 Linux 网络子系统的一个简单示意图：根据网络报文的流向，我们按照两个不同的方向对豹纹处理的流程进行概述。容器网络内核原理81)1)收包方向的报文处理收包方向的报文处理从上图中可以发现，当内核从网络驱动设备中获取到报文后：首先进行 TC 子系统的操作，在收包方向，不会有特别复杂的操作。完成了网络层报文的重组后，报文进入了网络层的处理，在网络层的处理中，比较重要的是，netfilter 框架和路由查找，这里实现了大量的功能，在云原生的场景中，netfilter 和路由子系统有着至关重要的作用。网络层完成处理后，会交由传输层进行处理，传输层的协议最常见的是 tcp 和 udp，其中 tcp 协议在传输层通过重传和序号校验等保证了连接的可靠性。传输层完成处理后，内核会将真正的报文数据提取出来并交给 socket 子系统，socket 子系统抽象了网络的所有操作，屏蔽了网络报文的细节，让用户程序可以按照文件 io 的方式读写网络数据。socket 子系统的数据最终会被用户程序读取，此时，一些编程语言的底层依赖库会进行一些封装，提供应用层协议的支持，如 http，mqtt 等，提供用户友好的操作体验。2)2)发包方向的报文处理发包方向的报文处理发包方向的处理，相比收包方向来说，一个重要的区别是，收包方向的操作是内核的软中端处理线程进行收包操作，而发包方向的操作则是由进程上下文进入内核态进行，因此，发包方向出现由于调度问题产生的偶发延迟都懂的概率比收包方向要小。应用程序通常都是调用编程语言或者第三方的类库提供的方法进行发包动作，而这些法宝动作最终都会调用 socket 子系统的写入调用来实现发送数据：应用程序写入 socket 后，在达到一定的条件，如内存充裕，tcp 发送窗口足够等情况下，内核会给当前需要发送的数据申请一个 sk_buff 结构体的内存，并将需要发送的数据填充到 sk_buff 的数据中。sk_buff 数据报文首先会经过传输层的处理，根据当前的系统状态，内核会给报文sk_buff 的 tcp 报头进行填充，然后调用网络层提供的方法进行发送。容器网络内核原理9网络层和收包方向类似，也会经历过 netfilter 框架的选取路由的动作，在这里实现了大量的雨网络抽象相关的逻辑。在网络层完成处理后，按照 OSI 七层网络定义，会进入数据链路层，实际上在 Linux 中，邻居子系统的信息填充，也会在路由子系统完成路由的选取后一并填入到报文的报头中，随后报文会进入发送方向的 TC 子系统。TC 子系统是实现网络流量整形的关键，和收包方向不同的是，发包方向的 TC 子系统会进行复杂的排序工作，通过数据包的类型与配置的规则进行匹配，实现网络流控的功能。TC 子系统会将优先级最高的报文传递给网络设备驱动。网络设备驱动的发送方法的实现逻辑细节已经不再属于 Linux 内核的范畴，通常在进入网络设备后，我们就可以认为数据包已经完成了发送。filter 框架netfilter 框架是 Linux 操作系统中内置的，通过向内核模块提供对协议栈中的网络数据包进行修改和操作的能力，来实现流量过滤，网络地址转换等高级功能。1)1)netfilternetfilter 如何工作如何工作对于网络数据报文，网络设备驱动通过将二层的以太网数据报文按照 Linux 内核定义的网络设备驱动规范，以 sk_buff 结构体的方式进行接收或者发送，即通常我们所描述的报文的最小单元 skb。内核通过将网络设备缓冲区环形队列中的 skb 取出，并按照以太网层，网络层，传输层的顺序处理后，将报文数据放置到对应的 Socket 缓冲区中，通知用户程序进行读取，从而完成收包。内核为 Socket 缓冲区的待发送数据封装为 skb，经过传输层，网络层和以太网层依次填充对应的报头后，调用网络设备驱动的方法将 skb 发送到网络上，从而完成发包。netfilter工作的核心原理则是在网络层，通过在五个不同的内核处理skb数据包的位置，执行注册到 netfilter 框架中的回调函数，并根据回调函数的返回来选择下一步的处理，容器网络内核原理10来实现复杂的功能。netfilternetfilter 触发触发的的时机时机netfilter 在内核网络数据包的处理流程中，注册了 5 个可以出发的实际，详情如下：/*IP Hooks*/*After promisc drops,checksum checks.*/#define NF_IP_PRE_ROUTING0/*If the packet is destined for this box.*/#define NF_IP_LOCAL_IN1/*If the packet is destined for another interface.*/#define NF_IP_FORWARD2/*Packets coming from a local process.*/#define NF_IP_LOCAL_OUT3/*Packets about to hit the wire.*/#define NF_IP_POST_ROUTING4#define NF_IP_NUMHOOKS5#endif/*!_KERNEL_*/根据源代码中的定义，我们可以参考下图：容器网络内核原理11从上面的代码定义和示意图中可以知道，在以下几个地方会调用 netfilter 定义好的方法对数据包进行处理：数据包从网卡进入协议栈后，所有的报文都会走到 NF_IP_PRE_ROUTING。数据包经过入向的路由选择后，确认是由本机的传输层进行处理的，会进入到NF_IP_LOCAL_IN。数据包经过入向的路由选择后，不是由本机处理，需要转发给其他机器的，会进入到 NF_IP_FORWARD。由本机的传输层发出的报文，都会经过 NF_IP_LOCAL_OUT。经过出向的路由选择后的报文，会经过 NF_IP_POST_ROUTING，包括从本机发出的和需要本机转发的。在以上五个时机，当数据包 skb 到达时，netfilter 框架定义的回调方法就会被内核执行。netfilternetfilter 如何操作网络数据如何操作网络数据使用 netfilter 框架的模块，需要按照 netfilter 定义的结构体来实现自己的行为，才能正确注册到 netfilter 框架中，并被内核调用，netfilter 约束的注册结构体的定义如下：struct nf_hook_ops/这是真正被内核执行的函数，会对 skb 进行读取和修改nf_hookfn*hook;struct net_device*dev;void*priv;u_int8_tpf;/hooknum 定义了回调函数生效的位置，从上文可知有五个位置可以选择unsigned inthooknum;/priority 定义了回调函数的优先级，通过每个 hook 时机都会有多个回调函数需要生效intpriority;以 ipvlan 模块为例：容器网络内核原理12static const struct nf_hook_ops ipvl_nfops=.hook=ipvlan_nf_input,.pf=NFPROTO_IPV4,.hooknum=NF_INET_LOCAL_IN,.priority=INT_MAX,#if IS_ENABLED(CONFIG_IPV6).hook=ipvlan_nf_input,.pf=NFPROTO_IPV6,.hooknum=NF_INET_LOCAL_IN,.priority=INT_MAX,#endif;我们可以看到，ipvlan 模块根据 IP 协议的版本定义了两个 hook 结构体，其中：hookfn 是核心的处理逻辑，ipvlan 模块注册了 ipvlan_nf_input 方法。pf 是 netfilter 的协议版本，ipvlan 模块分别注册了 IPv6 和 IPv4 对应的方法。hooknum 定义了这个 hook 在 netfilter 中生效的位置，ipvlan 模块将自己的回调方法注册到了 NF_INET_LOCAL_IN，也就是完成路由之后，进入传输层之前。priotity 定义了 hook 的优先级。那么，hookfn 作为真正核心的处理逻辑，他是如何工作的呢？以 ipvlan 注册在 NF_INET_LOCAL_IN 上的 hook 方法 ipvlan_nf_input 为例：unsigned int ipvlan_nf_input(void*priv,struct sk_buff*skb,const struct nf_hook_state*state)/参数中可以看到，有前一个生效的 hook 结构体，当前处理的 skb 报文本身以及当前netfilter 框架的上下文信息struct ipvl_addr*addr;unsigned int len;addr=ipvlan_skb_to_addr(skb,skb-dev);if(!addr)goto out;容器网络内核原理13skb-dev=addr-master-dev;len=skb-len ETH_HLEN;ipvlan_count_rx(addr-master,len,true,false);out:/这里返回了 netfilter 框架规定的返回码return NF_ACCEPT;从 ipvlan_nf_input 可以看到，注册到 netfilter 中的回调函数的核心在于两个约束：回调函数的入参定义，可以接受协议栈中真正的报文结构体 skb 以及 netfilter 的上下文状态为参数。回调函数的返回值，需要是 netfilter 规定好的返回值，他们的定义如下：/*Responses from hook functions.*/#define NF_DROP 0#define NF_ACCEPT 1#define NF_STOLEN 2#define NF_QUEUE 3#define NF_REPEAT 4#define NF_STOP 5/*Deprecated,for userspace nf_queue compatibility.*/#define NF_MAX_VERDICT NF_STOP从以上的分析不难看出，只要满足 netfilter 的注册条件，就可以在回调函数中直接对数据报文 skb 内容进行读取和修改操作，而通过返回值的定义，则可以借助 netfilter 框架完成对数据包的处理，比如丢弃，接收或者传递到用户态进行处理。netfilternetfilter 的内核实现的内核实现在负责对所有 hook 方法进行遍历处理的函数中，可以看到，netfilter 核心的工作流程就是在相应的触发时机调用这个时机上注册的所有方法，按照优先级进行处理，并根据每一次处理的结果进行操作，包括丢弃，传输给用户态等等：int nf_hook_slow(struct sk_buff*skb,struct nf_hook_state*state,const struct nf_hook_entries*e,unsigned int s)unsigned int verdict;int ret;容器网络内核原理14for(;s num_hook_entries;s )/在这里调用对应的 hook 时机上的所有注册的 hook 回调方法，然后根据结果选择是不是继续循环verdict=nf_hook_entry_hookfn(&e-hookss,skb,state);switch(verdict&NF_VERDICT_MASK)case NF_ACCEPT:break;case NF_DROP:kfree_skb(skb);ret=NF_DROP_GETERR(verdict);if(ret=0)ret=-EPERM;return ret;case NF_QUEUE:ret=nf_queue(skb,state,e,s,verdict);if(ret=1)continue;return ret;default:/*Implicit handling for NF_STOLEN,as well as any other*non conventional verdicts.*/return 0;return 1;2)2)netfilternetfilter 的常见应用的常见应用conntrackconntrack 连接跟踪连接跟踪conntrack 是 netfilter 提供的核心功能之一，通过对 tcp，udp 等协议的连接状态的记录，来实现连接的会话状态保持的功能，例如：对于 iptables 或者 ipvs 进行的 NAT 操作，可以记录单个已经建立的连接的 NAT信息，对于相同的 tcp 连接，可以减少 NAT 操作中分配五元组计算的频率，保持连接状态的存续。容器网络内核原理15对于没有建立完成的连接，也不是握手请求的情况，可以在差抄不到 conntrack 的情况下避免其进入协议栈，从而减少非必要的消耗。在 Linux 中，我们可以借助 conntrack-tools 工具提供的 conntrack 命令来管理conntrack 操作，常见的使用方法如下：#输出当前 netns 中所有的 conntrack 条目信息conntrack-L#通过 netlink stream 的方式实时观察 conntrack 的写入事件conntrack-E#查看按照 cpu 进行统计的 conntrack 数据conntrack-Sconntrack 在内核中也是通过注册在 netfilter 上的 hook 函数进行工作的，此外，conntrack机制还依赖于按照cpu的数量来为每一个cpu分配一块用于存放conntrack信息的内存，以下是 conntrack 机制在 Linux 上的实现：static const struct nf_hook_ops ipv4_conntrack_ops=.hook=ipv4_conntrack_in,.pf=NFPROTO_IPV4,.hooknum=NF_INET_PRE_ROUTING,.priority=NF_IP_PRI_CONNTRACK,.hook=ipv4_conntrack_local,.pf=NFPROTO_IPV4,.hooknum=NF_INET_LOCAL_OUT,.priority=NF_IP_PRI_CONNTRACK,.hook=ipv4_helper,.pf=NFPROTO_IPV4,.hooknum=NF_INET_POST_ROUTING,.priority=NF_IP_PRI_CONNTRACK_HELPER,.hook=ipv4_confirm,.pf=NFPROTO_IPV4,.hooknum=NF_INET_POST_ROUTING,.priority=NF_IP_PRI_CONNTRACK_CONFIRM,容器网络内核原理16,.hook=ipv4_helper,.pf=NFPROTO_IPV4,.hooknum=NF_INET_LOCAL_IN,.priority=NF_IP_PRI_CONNTRACK_HELPER,.hook=ipv4_confirm,.pf=NFPROTO_IPV4,.hooknum=NF_INET_LOCAL_IN,.priority=NF_IP_PRI_CONNTRACK_CONFIRM,;网络地址转换网络地址转换NAT 网络地址转换是 netfilter 框架提供的核心功能之一，NAT 作为网络中非常重要的概念，在云原生场景下提供很多功能，包括：在多种 cni 插件的数据面设计中，依赖 nat 实现跨节点的 pod 之间的通信。通过 nat 实现 service 与 pod 之间的负载均衡。iptables 和 ipvs 都可以实现 NAT 功能，其中 ipvs 通常都是用于对目的地址进行 NAT操作，也就是 DNAT，iptables 则具有包括 masquerade 在内的多种 NAT 组合而来的复杂功能，例如，在默认的 docker 容器访问公网的场景中，为了能够让节点内的，只有内网地址的 docker 容器可以正常访问公网，就需要添加如下的一条规则：#对于从 eth0 出节点的流量，访问目的为 123.12.23.43 的，自动将原地址切换为节点的出公网地址iptables-t nat-A POSTROUTING-o eth0-j SNAT-to 123.12.23.43iptables 的 NAT 有多个实现，目前版本较新并且被广泛采用的是基于 nft 的 iptables，对于 IPv4 协议，nft 实现的 NAT 功能在 netfilter 中注册的 hook 方法有如下几个：static const struct nf_hook_ops nf_nat_ipv4_ops=/*Before packet filtering,change destination*/.hook=nf_nat_ipv4_in,.pf=NFPROTO_IPV4,.hooknum=NF_INET_PRE_ROUTING,容器网络内核原理17.priority=NF_IP_PRI_NAT_DST,/*After packet filtering,change source*/.hook=nf_nat_ipv4_out,.pf=NFPROTO_IPV4,.hooknum=NF_INET_POST_ROUTING,.priority=NF_IP_PRI_NAT_SRC,/*Before packet filtering,change destination*/.hook=nf_nat_ipv4_local_fn,.pf=NFPROTO_IPV4,.hooknum=NF_INET_LOCAL_OUT,.priority=NF_IP_PRI_NAT_DST,/*After packet filtering,change source*/.hook=nf_nat_ipv4_fn,.pf=NFPROTO_IPV4,.hooknum=NF_INET_LOCAL_IN,.priority=NF_IP_PRI_NAT_SRC,;3)3)netfilternetfilter 在云原生中的应用在云原生中的应用基于基于 ipvsipvs 实现实现 ServiceServiceipvs 是基于 netfilter 框架实现的 Linux 内核态负载均衡器，通过 DNAT 方式来实现负载均衡，在云原生场景下，由于性能上的优势，ipvs 是实现 Service 功能的首选，我们可以通过以下命令来简单的查看 Service 真正产生在网络数据面的 ipvs 规则：#查看 ipvs connection 信息，在出节点是，ipvs connection 是独立并且优先于conntrack 机制的选择，即流量会优先匹配到 ipvs 的规则，如果没有命中，才会进入conntrack 的匹配逻辑ipvsadm-Lnc#添加一个 service 192.168.1.100:80，将 192.168.1.123 作为他的一个 realserver 后端ipvsadm-A-t 192.168.1.100:80-s rripvsadm-a-t 192.168.1.100:80-r 192.168.1.123-g-w 2容器网络内核原理18#查看不同的 ipvs service 的数据统计ipvsadm-Ln-stats基于基于 iptablesiptables 实现实现 NetworkPolicyNetworkPolicyNetworkPolicy 是云原生网络中非常重要的网络功能，其核心在于如何对流量进行权限管理，通常 cni 插件会采用 iptables 队 policy 未放行的流量进行屏蔽操作，实现NetworkPolicy 的功能。ipables 实现 NetworkPolicy 功能的数据面原理非常简单，通过白名单放行的方式，默认丢弃所有流量，只允许白名单中的流量，即可实现简单的 NetworkPolicy 功能，我们可以通过以下几个命令简单模拟 iptables 实现的 NetworkPolicy：#默认丢弃所有流量iptables-A INPUT-j DROP#将 192.168.1.100 的 80 端口进行放行iptables-A INPUT-s 192.168.1.100-p tcp-m tcp-dport 80-j ACCEPT3.tc 子系统Linux Traffic Control(TC)子系统是 Linux 操作系统中用于对从网络设备驱动进出的流量进行分配，整形，调度以及其他修改操作的子系统，借助对数据包比较直接的处理，可以实现流量控制，过滤，行为模拟和带宽限制等功能。1)1)LinuxLinux TrafficTraffic ControlControl 的核心原理的核心原理对于网络数据报文，网络设备驱动通过将二层的以太网数据报文按照 Linux 内核定义的网络设备驱动规范，以 sk_buff 结构体的方式进行接收或者发送，即通常我们所描述的报文的最小单元 skb。容器网络内核原理19内核通过将网络设备缓冲区环形队列中的 skb 取出，并按照以太网层，网络层，传输层的顺序处理后，将报文数据放置到对应的 Socket 缓冲区中，通知用户程序进行读取，从而完成收包。内核为 Socket 缓冲区的待发送数据封装为 skb，经过传输层，网络层和以太网层依次填充对应的报头后，调用网络设备驱动的方法将 skb 发送到网络上，从而完成发包。TC子系统通过工作在网络设备驱动操作和内核真正进行每一层的收包与发包动作之间，按照不同的模式对数据包进行处理，实现复杂的功能。TC 子系统比较常见的作用是对需要发送的数据包进行操作，由于作为收包一侧的 Linux内核，无法控制所有发送方的行为，因此 TC 子系统主要的功能实现都是围绕着发送方向，以下介绍也都是基于发送方向的 TC 子系统进行。TCTC 子系统的关键概念子系统的关键概念TC 子系统与 netfilter 框架工作在内核网络数据处理流程的不同位置，相比于 netfilter，TC 子系统工作的实际更加靠近网络设备，因此，在 TC 子系统的设计中，是与网络设备密不可分，在 TC 子系统中，有三个关键的概念用于对 TC 子系统的工作流程进行描述：Qdisc 是 queueing discipline 的简写，与我们理解的网卡的队列(queue)不同，qdisc 是 sk_buff 报文进行排队等待处理的队列，不同类型的 qdisc 有着不同的排队规则，TC 子系统会为每个网卡默认创建一个根队列，在跟队列的基础上，可以通过 Class 来创建不同的子队列，用于对流量进行分类处理。Class，如下图所示，class 将流量进行分类，不同分类的流量会进入不同的 qdisc进行处理。Filter，如下图所示，filter 通过制定匹配的规则来实现将流量进行分类的作用，filter与 class 配合之后就可以降流量按照特征，采用不同的 qdisc 进行处理。容器网络内核原理20不同的 qdisc 之间的主要差别就是他们对排队的数据包进行调度的算法的区别，你可以通过一下命令查看网卡的 qdisc 信息：#查看 eth0 的 class 为 2 的流量的默认 qdisc，其中 handle 指代 qdisc id,parent指代 class idtc qdisc show dev eth0 handle 0 parent 2常见的 qdisc 包含以下几种：mq（Multi Queue），即默认有多个 qdisc。fq_codel（Fair Queuing Controlled Delay），一种公平和随机分配流量带宽的算法，会根据数据包的大小，五元组等信息，尽量公平得分配不同的流之间的带宽。pfifo_fast，一种不分类的常见先进先出的队列，但是默认有三个不同的 band，可以支持简单的 tos 优先级。netem，network emulator 队列，常见的依赖 TC 子系统进行延迟，乱序和丢包模拟，都是通过 netem 来实现。clsact，这是 TC 子系统专门为了支持 eBPF 功能而提供的一种 qdisc 队列，在通过class 分配到这个 qdisc 之后，流量会触发已经挂载到 TC 子系统上的对应的 eBPF程序的处理流程。htb，一种通过令牌桶的算法对流量进行带宽控制的常用 qdisc，用于在单个往卡上对不同用户，场景的流量进行独立的带宽限流。容器网络内核原理21报文在报文在 TCTC 子系统的处理子系统的处理在 egress 方向，当以太网层完成数据报文 skb 的报头封装后，一个 skb 就可以直接调用网卡的方法进行发送了，而在 Linux 内核中，当以太网层完成封装并调用_dev_queue_xmit 时，会将 skb 放入他所在网络设备的 TC 队列中：static inline int c(struct sk_buff*skb,struct Qdisc*q,struct net_device*dev,struct netdev_queue*txq)if(q-flags&TCQ_F_NOLOCK)if(unlikely(test_bit(_QDISC_STATE_DEACTIVATED,&q-state)_qdisc_drop(skb,&to_free);rc=NET_XMIT_DROP;else/对于大多数数据包，都会从这里进入 qdisc 进行排队rc=q-enqueue(skb,q,&to_free)&NET_XMIT_MASK;qdisc_run(q);if(unlikely(to_free)kfree_skb_list(to_free);return rc;在入队动作发生后，内核一般都会直接进行一次 qdisc 的发包操作，将队列进行排序并按照规则发送符合条件的数据包：void _qdisc_run(struct Qdisc*q)int quota=dev_tx_weight;int packets;/每次 restart 都会发送数据包，直到发送完成，这并不意味着所有数据都发送完了，只是这次发送完成了条件while(qdisc_restart(q,&packets)quota-=packets;if(quota 22qdisc 每次被触发执行，都会将已经进入 qdisc 的数据进行入队操作，同时选择符合发送条件的数据包进行出队动作，也就是调用网卡的操作方法进行数据的发送，以pfifo_fast 为例：static int pfifo_fast_enqueue(struct sk_buff*skb,struct Qdisc*qdisc)/检测 Qdisc 队列数据包数量是否达到 dev 预定的最大值if(skb_queue_len(&qdisc-q)tx_queue_len)/确定数据包需要进入哪个通道int band=prio2bandskb-priority&TC_PRIO_MAX;struct pfifo_fast_priv*priv=qdisc_priv(qdisc);/获取通道列表的 headstruct sk_buff_head*list=band2list(priv,band);priv-bitmap|=(1 q.qlen ;/添加到通道队尾return _qdisc_enqueue_tail(skb,qdisc,list);return qdisc_drop(skb,qdisc);static struct sk_buff*pfifo_fast_dequeue(struct Qdisc*qdisc)struct pfifo_fast_priv*priv=qdisc_priv(qdisc);int band=bitmap2bandpriv-bitmap;if(likely(band=0)struct sk_buff_head*list=band2list(priv,band);struct sk_buff*skb=_qdisc_dequeue_head(qdisc,list);qdisc-q.qlen-;if(skb_queue_empty(list)priv-bitmap&=(1 23qdisc 流量控制由于设计非常复杂，所以很难简单概括其特性，通常在排查网络问题的过程中，我们需要了解的就是常见的 qdisc 的算法的大致工作原理，以及查看 qdisc 统计信息。2)Linux Traffic Control 在云原生中的应用基于基于 CgroupCgroup 的网络数据包的网络数据包 QosQosCgroup 子系统是容器技术的基础，通常我们对 cgroup 的理解都在于 cgroup 通过cgroupfs 文件接口，让内核在为应用程序提供 cpu 时间片分配和内存分配的过程中遵循一定的配额限制，实际上 cgroup 在较早的版本中已经支持对某个 cgroup 中的网络流量进行优先级的调整，以实现单个节点内不同 cgroup 之间的 Qos 动作。Cgroup 子系统中提供网络流量优先级的功能为 net_cls 和 net_prio，需要配合 TC 子系统一起生效，例如，我们给某一个容器所在的 cgroup 添加一个 net_cls 设置：mkdir/sys/fs/cgroup/net_cls/0echo 0 x100001/sys/fs/cgroup/net_cls/0/net_cls.classid在这里，我们选取了设定的 class 为 100001，然后，我们将 eth0 网卡的 root 根队列的 class 设置为 10，类型修改为 htb，用于进行限速：tc qdisc add dev eth0 root handle 10:htb我们在 10:这个根队列下，针对我们配置的 10:1 这个 class 配置带宽限流配置：tc class add dev eth0 parent 10:classid 10:1 htb rate 40mbit最后配置一个 filter，将 cgroup 流量引入到 10:1 的 class 中，完成对这个 cgroupnet_cls 的配置：tc filter add dev eth0 parent 10:protocol ip prio 10 handle 1:cgroup容器网络内核原理24而 net_prio 的原理则相对更加直观一点，通过在对应的 cgroup 路径中的 ifpriomap种配置网卡和对应的优先级数值，使对应的 cgroup 中管理的进程创建出来的 socket都具有priority属性，priority属性会成为sk_buff结构体的属性从而携带到进入qdisc，如果 qdisc 支持优先级调度，则会根据 priority 来完成流量的 Qos，操作如下：echo eth0 5 /cgroup/net_prio/iscsi/net_prio.ifpriomap基于基于 TCTC eBPFeBPF 的高性能可编程数据面实现的高性能可编程数据面实现从上文的介绍中，我们了解到，在 eBPF 的多个内核提供的可执行的触发点中，TC 子系统是其中原生支持的一种，实际上，许多开源的解决方案也都选择 TC 子系统作为 eBPF程序执行的触发点，包括 cilium 和 terway。我们通过一个简单的 eBPF 程序来对 TC 子系统支持 eBPF 的能力进行验证：首先，我们需要按照规范，在 TC 子系统提供的上下文环境中开发一个简单的 eBPF 程序：#include#include#include#include#ifndef _section#define _section(NAME)_attribute_(section(NAME),used)#endif#ifndef _inline#define _inlineinline _attribute_(always_inline)#endif#ifndef lock_xadd#define lock_xadd(ptr,val)(void)_sync_fetch_and_add(ptr,val)#endif#ifndef BPF_FUNC#define BPF_FUNC(NAME,.)容器网络内核原理25(*NAME)(_VA_ARGS_)=(void*)BPF_FUNC_#NAME#endifstatic void*BPF_FUNC(map_lookup_elem,void*map,const void*key);struct bpf_elf_map acc_map _section(maps)=.type=BPF_MAP_TYPE_ARRAY,.size_key=sizeof(uint32_t),.size_value=sizeof(uint32_t),.pinning=PIN_GLOBAL_NS,.max_elem=2,;static _inline int account_data(struct _sk_buff*skb,uint32_t dir)uint32_t*bytes;bytes=map_lookup_elem(&acc_map,&dir);if(bytes)lock_xadd(bytes,skb-len);return TC_ACT_OK;_section(ingress)int tc_ingress(struct _sk_buff*skb)return account_data(skb,0);_section(egress)int tc_egress(struct _sk_buff*skb)return account_data(skb,1);char _license _section(license)=GPL;随后我们创建一个 clsact 类型的 qdisc，并且将流量全部定位到这个 qdisc 中：clang-g-O2-Wall-target bpf-I/iproute2/include/-c tc-example.c-o tc-example.o#创建一个 clsact 类型的 qdisc 作为 root 根 qdisc，然后加载 ebpf 程序到发送方向tc qdisc add dev enp3s0 clsact容器网络内核原理26tc filter add dev enp3s0 egress bpf da obj tc-example.o sec egress#通过 filter show 可以查看到网卡在 egress 上家在的 ebpf 程序tc filter show dev enp3s0 egress4.eBPF 技术eBPF 是 Linux 内核提供可以在不借助内核模块的场景下，对内核进行观测，注入来实现高阶功能的机制。eBPF 技术作为内核当前最为突破性的技术，具有轻量级，无侵入的特性，在排查网络问题上可以提供很多帮助，在当前的 eBPF 生态中，bpftrace 和 bcc 都提供了很多出色的功能协助我们进行观测，本章节会简单介绍 eBPF 的实现原理以及 eBPF 在云原生场景下的应用的简单介绍。eBPF 能够在实现接近内核模块的功能的基础上，具备上述的有点，得益于内核为 eBPF提供的多个改变：提供了高效的 jit，eBPF 的代码在内核中会被编译为机器码从而向真正的内核代码一样被执行。bpf()系统调用和map机制以及bpf helper辅助函数的提供，让内核操作更加便捷。内核在高频通用的代码中提供了安全的注入点，让 eBPF 程序只需要关注于代码逻辑。下图是 eBPF 程序的生命流程概述。容器网络内核原理27对于一个 eBPF 程序来说，他的完整的生命流程包括：使用 eBPF 兼容的 C 语言子集进行代码开发，然后通过 clang 进行编译。通过各种开发框架进行初步的检查，然后通过 bpf()系统调用进行加载，在这个过程中会完成 map 的创建和替换以及符号的重定位。加载到内核的过程中，内核的 verifier 会对程序进行校验，如果通过了校验，则可以被 JIT 编译为字节码然后被添加到指定的位置。当内核代码执行到某个位置，内核会自动执行已经完成加载和attach的eBPF程序，例如 socket 的读取和写入会触发 sockops 这个执行点的 eBPF 程序的执行，完成流量的统计或者劫持动作。eBPF 在在安全，网络和可观测行上都有很广泛的应用，也诞生了许多影响力较大的开源项目。容器网络内核原理28Linux 内核为提升可观测性而提供了多个可执行的点，我们常用的包括：kprobe,kretprobe,fentry,fexit 通过执行到某个函数是，触发 INT3 中断，使得eBPF 程序可以在进程现场状态下观测到信息。tracepoint 内核 的 debugfs 子系 统提供 的可供 执行的 点，内核 在固定 的tracepoint 会执行注册的 eBPF 程序。我们可以通过一些开源的项目很快体验到 eBPF 的价值，例如通过 bpftrace，我们能够很快看到所有经过内核的数据报文在 netfilter 中的返回值：bpftrace-e kretprobe:nf_hook_slow printf(%d%sn,retval,comm)此外，eBPF 在容器网络中也扮演着越来越关键的角色，包括 cilium,terway,calico 等多个知名的网络插件都开始使用 eBPF 来取代传统的 netfilter 框架等机制的作用，达到更加高效的抽象。全景剖析阿里云容器网络数据链路29二、全景剖析阿里云容器网络数据链路鸟瞰容器网络，整个容器网络可以分为三个部分：Pod 网段，Service 网段和 Node 网段。这三个网络要实现互联互通和访问控制，那么实现的技术原理是什么？整个链路又是什么，限制又是什么呢？Flannel，Terway 有啥区别？不同模式下网络性能如何？这些，需要客户在下搭建容器之前，就要依据自己的业务场景进行选择，而搭建完毕后，相关的架构又是无法转变，所以客户需要对每种架构特点要有充分了解。比如下图是个简图，Pod网络既要实现同一个ECS的Pod间的网络互通和控制，又要实现不同ECSPod间的访问，Pod 访问 SVC 的后端可能在同一个 ECS 也可能是其他 ECS，这些在不同模式下，数据链转发模式是不同的，从业务侧表现结果也是不一样的。1.Flannel 模式架构设计Flannel 模式下，ECS 只有一个主网卡 ENI，无其他附属网卡，ECS 和节点上的 Pod 与外部通信都需要通过主网卡进行。ACK Flannel 会在每个节点创建 cni0 虚拟网卡作为Pod 网络和 ECS 的主网卡 eth0 之间的桥梁。全景剖析阿里云容器网络数据链路30集群的每个节点会起一个 flannel agent，并且会给每个节点预分配一个 Pod CIDR，这个 Pod CIDR 是 ACK 集群的 Pod CIDR 的子集。容器的网络命名空间内会有一个 eth0 的虚拟网卡，同时存在下一跳指向该网卡的路由，该网卡会作为容器和宿主内核进行数据交换的出入口。容器和宿主机之间的数据链路是通过 veth pair 进行交换的，现在我们已经找到 veth pair 其中一个，如何去找另一个veth 呢？全景剖析阿里云容器网络数据链路31如上图所示，我们可以容器的网络命名空间中通过 ip addr 看到一个 eth0if8 的标志位，其中81 这个将会协助我们在 ECS 的 OS 内找到找到和容器网络命名空间中的 vethpair 相对一个。在 ECS OS 内我们通过 ip addr|grep 81:可以找到 vethd7e7c6fd 这个虚拟网卡，这个就是 veth pair 在 ECS OS 侧相对的那一个。到目前为止容器内和 OS 数据链路已经建立链接了，那么 ECS OS 内对于数据流量是怎么判断去哪个容器呢？通过 OS Linux Routing 我们可以看到，所有目的是 Pod CIDR 网段的流量都会被转发到 cni0 这张虚拟网卡，那么 cni0 是通过 bridge 方式将不同目的的数据链路指向到不同的 vethxxx。到这里为止，ECS OS 和 Pod 的网络命名空间已经建立好完整的出入链路配置了。全景剖析阿里云容器网络数据链路321)1)FlannelFlannel 模式容器网络数据链路剖析模式容器网络数据链路剖析针对容器网络特点，我们可以将 Flannel 模式下的网络链路大体分为以 Pod IP 对外提供服务和以 SVC 对外提供服务两个大的 SOP 场景，进一步细分可以拆分到 10 个不同的小的 SOP 场景。对这 10 个场景的数据链路梳理合并，这些场景可以归纳为下面 5 类典型的场景：Client 和服务端 Pod 部署于同一个 ECS；Client 和服务端 Pod 部署于不同 ECS；全景剖析阿里云容器网络数据链路33访问 SVC External IP，ExternalTrafficPolicy 为 Cluster 时，Client 和服务端 Pod部署于不同 ECS，其中 client 为集群外；访问 SVC External IP，ExternalTrafficPolicy 为 Local 时,Client 和服务端 Pod 部署于不同 ECS，其中 client 为集群内；访问 SVC External IP，ExternalTrafficPolicy 为 Local 时,Client 和服务端 Pod 部署于不同 ECS，其中 client 为集群外；2)2)场景一：场景一：ClientClient 和服务端和服务端 PodPod 部署于同一个部署于同一个 ECSECS此场景包含下面几个子场景，数据链路可以归纳为一种：以 Pod IP 对外提供服务，Client 和 Pod 部署于同一个节点；以 SVC ClusterIP 对外提供服务，Client 和 SVC 后端 Pod 部署于同一节点；以 SVC ExternalIP 对外提供服务，ExternalTrafficPolicy 为 Cluster/Local 情况下，Client 和 SVC 后端 Pod 部署于同一节点；环境环境ap-southeast-1.10.0.0.180 节点上存在两个 pod：centos-67756b6dc8-rmmxt IP地址 172.23.96.23 和 nginx-7d6877d777-6jkfg 和 172.23.96.24。内核路由内核路由centos-67756b6dc8-rmmxt IP 地址 172.23.96.23，该容器在宿主机表现的 PID 是503478，该容器网络命名空间有指向容器 eth0 的默认路由。全景剖析阿里云容器网络数据链路34该容器 eth0 在 ECS OS 内对应 veth pair 是 vethd7e7c6fd。通过上述类似的办法，可以找到 nginx-7d6877d777-6jkfg IP 地址 172.23.96.24，该容器在宿主机表现的 PID 是 2981608，该容器 eth0 在 ECS OS 内对应 veth pair 是vethd3fc7ff4。在 ECS OS 内，有指向 Pod CIDR，下一跳为 cni0 的路由，以及 cni0 中有两个容器的vethxxx 网桥信息。全景剖析阿里云容器网络数据链路35小结小结可以访问到目的端数据链路转发示意图：全景剖析阿里云容器网络数据链路36内核协议栈示意图：数据链路：ECS1 Pod1 eth0-vethxxx1-cni0-vethxxxx2-ECS1 Pod2 eth0；数据链路要经过三次内核协议栈，分别是 Pod1 协议栈，ECS OS 协议栈和 Pod2 协议栈；3)3)场景二：场景二：ClientClient 和服务端和服务端 PodPod 部署于不同部署于不同 ECSECS此场景包含下面几个子场景，数据链路可以归纳为一种：以 Pod IP 对外提供服务，Client 和 Pod 部署于不同节点；以 SVC ClusterIP 对外提供服务，Client 和 SVC 后端 Pod 部署于不同节点；以 SVC ExternalIP 对外提供服务，ExternalTrafficPolicy 为 Cluster 情况下，集群内 Client 和 SVC 后端 Pod 部署于不同节点；环境环境全景剖析阿里云容器网络数据链路37ap-southeast-1.10.0.0.180 节点上存在两个 pod：centos-67756b6dc8-rmmxt IP地址 172.23.96.23 和 nginx1-76c99b49df-7plsr IP 地址 172.23.96.163Service nginx1 的 ExternalTrafficPlicy 为 Cluster。内核路由内核路由Pod 网络空间和 ECS OS 网络空间的数据交换在 2.1 场景一中已经做了详细描述，此处不再果断篇幅描述。源端源端 PodPod 所在所在 ECSECS 的的 IPVSIPVS 规则规则可以看到，源端数据链路访问 svc 的 clusterip 192.168.13.23 时，如果链路到达 ECS的 OS 内，会命中 ipvs 规则，被解析到 svc 的后端 endpoint 之一（本实例中只有一个pod，所以 endpoint 只有一个）。小结小结可以成功访问到目的端数据链路转发示意图：全景剖析阿里云容器网络数据链路38VPC 路由表会自动配置目的地址是 pod CIDR，下一跳为 Pod 网段所归属的 ECS 的自定义路由条目，该规则由 ACK 管控测通过 openapi 调用 VPC 去配置，无需手动配置和删除。内核协议栈示意图：全景剖析阿里云容器网络数据链路39Conntack 表信息（访问 SVC 情况）Node1:src 是源 pod IP，dst 是 svc 的 ClusterIP，并且期望是由 svc 的其中一个 endpoint172.23.96.163 来回消息给源端 pod。Node2:目的 pod 所在 ECS 上 conntrack 表记录是由源端 pod 访问目的 pod，不会记录 svc的 clusterip 地址。数据链路：ECS1 Pod1 eth0-vethxxx1-cni0-ECS 1 eth0-VPC-ECS2eth0-cni0-vethxxxx2-ECS2 Pod2 eth0；数据链路要经过四次内核协议栈，分别是 Pod1 协议栈，ECS1 OS 协议栈，ECS2 OS协议栈和 Pod2 协议栈；VPC 路由表会自动配置目的地址是 pod CIDR，下一跳为 Pod 网段所归属的 ECS的自定义路由条目，该规则由 ACK 管控测通过 openapi 调用 VPC 去配置，无需手动配置和删除；如果访问的 SVC 的 cluster IP，或者是 Cluster 模式下，访问 SVC 的 externalIP，数据链路通过 veth pair 进到 ECS OS 内后，会命中相应的 IPVS 规则，并根据负载规则，选择 IPVS 的某一个后端，进而打到其中的一个 SVC 的后端 endpoint，SVC的 IP 只会再 Pod 的 eth0，veth pair vethxxx 被捕捉到，其他链路环节不会捕捉到 svc 的 IP；全景剖析阿里云容器网络数据链路404)4)场景三：场景三：ExternalTrafficPolicyExternalTrafficPolicy 为为 LocalLocal 时，时，ClientClient 和服务端和服务端 PodPod 部部署于集群内不同署于集群内不同 ECSECS此场景包含下面几个子场景，数据链路可以归纳为一种：以 SVC ExternalIP 对外提供服务，ExternalTrafficPolicy 为Local 情况下，集群内 Client和 SVC 后端 Pod 部署于不同节点；环境环境ap-southeast-1.10.0.0.180 节点上存在两个 pod：centos-67756b6dc8-rmmxt IP地址 172.23.96.23 和 nginx1-76c99b49df-7plsr IP 地址 172.23.96.163Service nginx1 ExternalTrafficPolicy 为 Local。内核路由内核路由Pod 网络空间和 ECS OS 网络空间的数据交换在 2.1 场景一中已经做了详细描述，此处不再果断篇幅描述。全景剖析阿里云容器网络数据链路41源端源端 PodPod 所在所在 ECSECS 的的 IPVSIPVS 规则规则可以看到，源端数据链路访问 svc 的 externalip 8.219.164.113 时，如果链路到达 ECS的 OS 内，会命中 ipvs 规则，但是我们可以看到 EcternalIP 并没有相关的后端endpoint，链路达到 OS 后，会命中 IPVS 规则，但是没有后端 pod，所以会出现connection refused。小结小结不可以访问到目的端，此时会访问失败，Connection refused数据链路转发示意图：内核协议栈示意图：全景剖析阿里云容器网络数据链路42数据链路：ECS1 Pod1 eth0-vethxxx1-；数据链路要经过一次半内核协议栈，分别是 Pod1 协议栈，半个 ECS1 OS 协议栈；如果访问的 SVC 的 External IP，或者是 Local 模式下，访问 SVC 的 externalIP，数据链路通过veth pair进到ECS OS内后，会命中相应的IPVS规则，但是由于Local模式，External IP 的 IPVS 为空，所以命中规则但是无转发后端，整个链路会在 ipvs终止，访问失败。所以建议集群内采用 clusterip 访问，这也是 k8s 官方推荐的最佳实践；5)场景四：场景四：ExternalTrafficPolicyExternalTrafficPolicy 为为 LocalLocal 时，时，ClientClient 来自于集群外来自于集群外此场景包含下面几个子场景，数据链路可以归纳为一种：A.访问 SVC External IP，ExternalTrafficPolicy 为 Local 时,Client 和服务端 Pod 部署于不同 ECS，其中 client 为集群外。环境Deployment 为 nginx1，分别为三个 pod nginx1-76c99b49df-4zsdj 和nginx1-76c99b49df-7plsr 部署在 ap-southeast-1.10.0.1.206ECS 上，最后一个pod nginx1-76c99b49df-s6z79 部署在其他节点 ap-southeast-1.10.0.1.216 上Service nginx1 的 ExternalTrafficPlicy 为 Local。全景剖析阿里云容器网络数据链路43内核路由内核路由Pod 网络空间和 ECS OS 网络空间的数据交换在 2.1 场景一中已经做了详细描述，此处不再果断篇幅描述。SLBSLB 相关配置相关配置从 SLB 控制台，可以看到 SLB 后端的虚拟服务器组中只有两个 ECS 节点ap-southeast-1.10.0.1.216 和 ap-southeast-1.10.0.1.206。集群内的其他节点，比如 ap-southeast-1.10.0.0.180 并未被加到 SLB 的后端虚拟服务器组中。虚拟服务器组的 IP 为 ECS 的 IP，端口为 service 里面的 nodeport 端口 32580。故故 ExternalTrafficPolicyExternalTrafficPolicy 为为 LocalLocal 模式下模式下，只有有只有有 ServiceService 后端后端 podpod 所在的所在的 ECSECS 节点节点才会被加入到才会被加入到 SLBSLB 的后端虚拟服务器组中，参与的后端虚拟服务器组中，参与 SLBSLB 的流量转发，集群内的其他节点的流量转发，集群内的其他节点不参与不参与 SLBSLB 的转发的转发。SLBSLB 虚拟服务器组虚拟服务器组 ECSECS 的的 IPVSIPVS 规则规则从 SLB 的虚拟服务器组中的两个 ECS 可以看到，对于 nodeip nodeport 的 ipvs 转发规则是不同。ExternalTrafficPolicy 为 Local 模式下，只有该节点上的护短 pod 才会被加到该节点的 ipvs 转发规则中，其他节点上的后端 pod 不会加进来，这样保证了被全景剖析阿里云容器网络数据链路44SLB 转发的链路，只会被转到该节点上的 pod，不会转发到其他节点上。node1：ap-southeast-1.10.0.1.206node1：ap-southeast-1.10.0.1.216小结小结可以访问到目的端数据链路转发示意图：该图示意了只有后端 pod 所在 ECS 才会加到 SLB 后端中，从集群外部访问 SVC 的externalIP（SLB IP）的情况，可见数据链路只会被转发到虚拟服务器组中的 ECS，不会再被转发到集群内其他节点上。全景剖析阿里云容器网络数据链路45内核协议栈示意图：Conntack 表信息Node:src 是集群外部客户端 IP，dst 是节点 IP，dport 是 SVC 中的 nodeport。并且期望是由该 ECS 上的 pod 172.23.96.82 来回包给源端。数据链路：client-SLB-ECS eth0 ECS nodeport-cni0-vethxxxxx-ECS1Pod1 eth0；数据链路要经过两次内核协议栈，分别是 Pod1 协议栈，ECS1 OS 协议栈；ExternalTrafficPolicy 为 Local 模式下，只有有 Service 后端 pod 所在的 ECS 节点才会被加入到 SLB 的后端虚拟服务器组中，参与 SLB 的流量转发，集群内的其他节点不参与 SLB 的转发；全景剖析阿里云容器网络数据链路466)场景五：场景五：ExternalTrafficPolicyExternalTrafficPolicy 为为 ClusterCluster 时，时，ClientClient 来自于集群外来自于集群外此场景包含下面几个子场景，数据链路可以归纳为一种：访问 SVCExternal IP，ExternalTrafficPolicy 为 Cluster 时,Client 和服务端 Pod 部署于不同 ECS，其中 client 为集群外。环境环境Deployment 为 nginx1，分别为三个 pod nginx1-76c99b49df-4zsdj 和nginx1-76c99b49df-7plsr 部署在 ap-southeast-1.10.0.1.206ECS 上，最后一个pod nginx1-76c99b49df-s6z79 部署在其他节点 ap-southeast-1.10.0.1.216 上Service nginx2 的 ExternalTrafficPlicy 为 Cluster。内核路由内核路由Pod 网络空间和 ECS OS 网络空间的数据交换在 2.1 场景一中已经做了详细描述，此处不再果断篇幅描述。SLBSLB 相关配置相关配置从 SLB 控制台，集群内所有所有节点 ap-southeast-1.10.0.0.180、ap-southeast-1.10.0.1.216和ap-southeast-1.10.0.1.206都被加到SLB的虚拟服务全景剖析阿里云容器网络数据链路47器组中。其中虚拟服务器组的 IP 为 ECS 的 IP，端口为 service 里面的 nodeport 端口30875。故故ExternalTrafficPolicExternalTrafficPolicy y 为为CLusteCLuster r 模式下模式下，集群内所有集群内所有的的ECECS S节点都会被加入节点都会被加入到到SLSLB B的后端虚拟服务器组中，参与的后端虚拟服务器组中，参与 SLBSLB 的流量转发。的流量转发。SLBSLB 虚拟服务器组虚拟服务器组 ECSECS 的的 IPVSIPVS 规则规则从 SLB 的虚拟服务器组中的可以看到，对于 nodeip nodeport 的 ipvs 转发规则是一致的。ExternalTrafficPolicy 为 CLuster 模式下，所有的 service 后端 pod 都会被加到所有节点的 ipvs 的转发规则中，即使是该节点有后端 pod，流量也不一定会被转发到该节点上 pod，可能会被转发到其他节点上的后端 pod。node1：ap-southeast-1.10.0.1.206(该节点有后端 pod)node1：ap-southeast-1.10.0.1.216(该节点有后端 pod)node3:ap-southeast-1.10.0.0.180(该节无后端 pod)全景剖析阿里云容器网络数据链路48小结小结可以访问到目的端数据链路转发示意图：该图示意了集群内所有 ECS都会被加到SLB 后端中，从集群外部访问SVC 的externalIP（SLB IP）的情况，数据流量可能会被转发到其他节点上。内核协议栈示意图：内核协议栈示意图已经在 2.4 场景一中已经做了详细描述，此处不再过多篇幅描述。Conntack 表信息链路 1：ap-southeast-1.10.0.0.180:此时数据链路对应示意图中的链路 1，可以看到数据链路被转到全景剖析阿里云容器网络数据链路49ap-southeast-1.10.0.0.180 节点，该节点上并没有 service 的后端 pod，通过conntrack 信息，可以看到：src 是集群外部客户端 IP，dst 是节点 IP，dport 是 SVC 中的 nodeport。并且期望是172.23.96.163 来回包给 10.0.0.180。通过前述信息，可以得知 172.23.96.163 是nginx1-76c99b49df-7plsrPod，部署在 ap-southeast-1.10.0.1.206。ap-southeast-1.10.0.1.206：通过此节点 conntrack 表，可以看到 src 是 node ap-southeast-1.10.0.0.180，dst是 172.23.96.163 的 80 端口，回包也是直接回给 node ap-southeast-1.10.0.0.180。综上可以看到综上可以看到 srcsrc 变换了多次，故在变换了多次，故在 CLusterCLuster 模式下，会存在丢失真实客户端模式下，会存在丢失真实客户端 IPIP 的情的情况况。链路 2：src 是集群外部客户端 IP，dst 是节点 IP，dport 是 SVC 中的 nodeport。并且期望是由该 ECS 上的 pod 172.23.96.82 来回包给 172.23.96.65，此地址是 SLB 集群中的一个地址。数据链路：情景一：client-SLB-ECS eth0 ECS nodeport-cni0-vethxxxxx-ECS1Pod1 eth0；情景二：client-SLB-ECS1 eth0 ECS1 nodeport-VPC Routing-ECS2 eth0 Pod port-cni0-vethxxxxx-ECS2 Pod1 eth0；数据链路要经过三次内核协议栈，分别是 ECS1 OS、ECS2 OS 协议栈和 Pod 协议栈；全景剖析阿里云容器网络数据链路50ExternalTrafficPolicy 为 CLuster 模式下，kubernetes 所有 ECS 节点都会被加入到 SLB 的后端虚拟服务器组中，参与 SLB 的流量转发，此时会存在数据路在集群内被多个 ECS 转发的场景，该情况下会丢失真实客户端 IP 的情况；7)7)小结小结本节主要聚焦 ACK 在 Flannel 模式下，不同 SOP 场景下的数据链路转发路径。随着微服务化和云原生化，网络场景日趋复杂，作为 kubernetes 原生的网络模型Flannel，不同的访问环境，一共可以分为 10 个 SOP 场景。通过深入简出的剖析，可以归纳为 5个场景，并对这五个场景的转发链路，技术实现原理，云产品配置等一一梳理并总结，这对我们遇到 Flannel 架构下的链路抖动、最优化配置，链路原理等提供了初步指引方向。2.Terway ENI 模式架构设计Terway ENI 模式下，ENI 的网络都是和 VPC 同样的网段，ENI 网络就是从 Aliyun 的VPC 网络中创建和绑定一个弹性网卡到 ECS 节点上，然后 Pod 利用这个弹性网卡和别的网络互通，这里需要关注的是弹性网卡的数量是有限制的，具体的根据实例类型有不同的配额。全景剖析阿里云容器网络数据链路51Pod 所使用的的 CIDR 网段和节点的 CIDR 是同一个网段。pod 内部可以看到是有两张网卡的，一个是 eth0，另一个是 veth1，其中 eth0 的 IP就是 Pod 的 IP，此网卡的 MAC 地址和控制台上的 ENI 的 MAC 地址可以匹配，说明此此网卡就是附属网卡就是附属 ENIENI 网卡，被直接挂载到了网卡，被直接挂载到了 PodPod 的网络命名空间内。的网络命名空间内。Pod 内有指向 eth0 的默认路由，同时还有指向目的网段为 192.168.0.0/16，下一跳为veth1 网卡的路由，其中 192.168.0.0/16 网段为集群的 service 网段，说明集群内 Pod全景剖析阿里云容器网络数据链路52访问 SVC 的 clusterIP 网段，数据链路会经过 veth1 网卡到宿主机 ECS 的 OS 内进行下一步判断，其他情况是走 eth0 直接进入到 VPC。如上图所示，我们可以容器的网络命名空间中通过 ip addr 看到一个 veth1if19 的标志位，其中19 这个将会协助我们在 ECS 的 OS 内找到找到和容器网络命名空间中的veth pair 相对一个。在 ECS OS 内我们通过 ip addr|grep 19:可以找到cali38ef34581a9 这个虚拟网卡，这个就是 veth pair 在 ECS OS 侧相对的那一个。到目前为止，容器访问 SVC 的 ClusterIP 时，容器和 OS 数据链路已经建立链接了，那么 ECS OS 内对于数据流量是怎么判断去哪个容器呢？通过 OS Linux Routing 我们可以看到，所有目的是 Pod CIDR 网段的流量都会被转发到 Pod 对应的 calico 虚拟往卡上，到这里为止，ECS OS 和 Pod 的网络命名空间已经建立好完整的出入链路配置了。全景剖析阿里云容器网络数据链路531 1）TerwayTerway ENIENI 模式容器网络数据链路剖析模式容器网络数据链路剖析针对容器网络特点，我们可以将 Terway ENI 模式下的网络链路大体分为以 Pod IP 对外提供服务和以 SVC 对外提供服务两个大的 SOP 场景，进一步细分可以拆分到 8 个不同的小的 SOP 场景。对这 8 个场景的数据链路梳理合并，这些场景可以归纳为下面 8 类典型的场景：TerwayENI 架构下，不同的数据链路访问情况下，可以总结归纳为为 8 类：访问 Pod IP，同节点访问 pod;全景剖析阿里云容器网络数据链路54访问 Pod IP，同节点 pod 间互访;访问 Pod IP，异节点 pod 间互访;集群内访问 SVC IP（Cluster IP），源端和 SVC 后端 Pod 为同一节点;集群内访问 SVC IP（Cluster IP），源端和 SVC 后端 Pod 为不同节点;集群内访问 SVC IP（External IP），源端和 SVC 后端 Pod 为同一节点;集群内访问 SVC IP（External IP），源端和 SVC 后端 Pod 为不同节点;集群外访问 SVC External IP;2 2）场景一：访问场景一：访问 PodPod IPIP，同节点访问，同节点访问 podpod环境环境ap-southeast-1.10.0.0.196 节点上存在 nginx1-5969d8fc89-9t99h 和 10.0.0.203。内核路由内核路由nginx1-5969d8fc89-9t99h IP 地址 10.0.0.203，该容器在宿主机表现的 PID 是1094736，该容器网络命名空间有指向容器 eth0 的默认路由。和下一跳为 veth1，目的网段为 service 的两条路由。全景剖析阿里云容器网络数据链路55该容器 veth1 在 ECS OS 内对应 veth pair 是 cali5068e632525。在 ECS OS 内，有指向 Pod IP，下一跳为为 calixxxx 的路由，通过前文可以知道 calixxx网卡是和每个 pod 内的 veth1 组成的 pair，所以，pod 内访问 SVC 的 CIDR 会有指向veth1 的路由，不会走默认的 eth0 路由。故：calixx 网卡在这里的主要作用是用于：节点访问 Pod 2.当节点或者 Pod 访问 SVC 的 CIDR 时，会走 ECS OS 内核协议栈转换，走到 calixxx 和 veth1 访问 pod。全景剖析阿里云容器网络数据链路56小结小结可以访问到目的端nginx1-5969d8fc89-9t99h netns veth1 可以抓到数据包。nginx1-5969d8fc89-9t99h cali5068e632525 可以抓到数据包。全景剖析阿里云容器网络数据链路57数据链路转发示意图：数据链路是 ECS-Linux routing-calicxxx-Pod net ns veth1。数据链路完成，宿主机 ns 切换至 Pod ns；通过宿主机上的路由切换至 pod 所属的 veth pair；该网卡为被分配的 pod 独占，无法和其他 pod 进行共享；数据链路经过两次协议栈；3)3)场景二：访问场景二：访问 PodPod IPIP，同节点，同节点 podpod 访问访问 podpod环境环境全景剖析阿里云容器网络数据链路58ap-southeast-1.10.0.0.196 节点上存在两个 pod：centos-59cdc5c9c4-89f8x IP 地址 10.0.0.202 和 nginx1-5969d8fc89-9t99h 和 10.0.0.203。内核路由内核路由centos-59cdc5c9c4-89f8x IP 地址 10.0.0.202，该容器在宿主机表现的 PID 是2314075，该容器网络命名空间有指向容器 eth0 的默认路由。和下一跳为 veth1，目的网段为 service 的两条路由。通过上述类似的办法，可以找到 nginx1-5969d8fc89-9t99hIP 地址 10.0.0.203，该容器在宿主机表现的 PID 是 1094736。小结小结可以访问到目的端全景剖析阿里云容器网络数据链路59centos-59cdc5c9c4-89f8x netns eth1 可以抓到数据包。nginx1-5969d8fc89-9t99h netns eth1 可以抓到数据包。数据链路转发示意图：数据链路转发示意图：全景剖析阿里云容器网络数据链路60数据链路是 Pod1 netns eth1-VPC-Pod2 netns eth2。数据链路不经过宿主机host namespace，数据链路会先出 ECS，到 VPC 再回到原来的 ECS；在 pod 内的 net namespace 中，直接命中默认路有规则，从 eth0 网卡出 pod 直接到 VPC。这里的 eth0 其实就是附属网卡 ENI，直接被挂载在了 pod 的 net ns，走了 PCI 网卡；该网卡为被分配的 pod 独占，无法和其他 pod 进行共享；数据链路经过两次协议栈；4)4)场景三：访问场景三：访问 PodPod IPIP，异节点，异节点 podpod 访问访问 podpod环境环境全景剖析阿里云容器网络数据链路61ap-southeast-1.10.0.0.196 节点上存在 pod：centos-59cdc5c9c4-89f8x IP 地址10.0.0.202。ap-southeast-1.10.0.2.80节点上存在pod：nginx-6f545cb57c-jmbrq和10.0.2.86。内核路由内核路由centos-59cdc5c9c4-89f8x IP 地址 10.0.0.202，该容器在宿主机表现的 PID 是2314075，该容器网络命名空间有指向容器 eth0 的默认路由。和下一跳为 veth1，目的网段为 service 的两条路由。通过上述类似的办法，可以找到 nginx-6f545cb57c-jmbrq IP 地址 10.0.2.86，该容器在宿主机表现的 PID 是 1083623。全景剖析阿里云容器网络数据链路62小结小结可以访问到目的端centos-59cdc5c9c4-89f8x netns eth0 可以抓到数据包。nginx-6f545cb57c-jmbrq netns eth0 可以抓到数据包。全景剖析阿里云容器网络数据链路63数据链路转发示意图：数据链路转发示意图：数据链路是 ECS1 Pod1 netns eth0-VPC-ECS2 Pod2 netns eth0。数据链路不经过宿主机 host namespace，数据链路会先出 ECS1，到 AVS 再回到 ECS2；全景剖析阿里云容器网络数据链路64在 pod 内的 net namespace 中，直接命中默认路有规则，从 eth0 网卡出 pod 直接到 VPC。这里的 eth0 其实就是附属网卡 ENI，直接被挂载在了 pod 的 net ns，走了 PCI 设备；该网卡为被分配的 pod 独占，无法和其他 pod 进行共享；数据链路经过两次协议栈；5)5)场景四：集群内访问场景四：集群内访问 SVCSVC IPIP（ClusterCluster IPIP），源端和，源端和 SVCSVC 后端后端 PodPod 为为同一节点同一节点环境环境ap-southeast-1.10.0.0.196 节点上存在两个 pod：centos-59cdc5c9c4-89f8x IP 地址 10.0.0.202 和 nginx1-5969d8fc89-9t99h 和 10.0.0.203。Service是nginx1集群内clusterIP是192.168.41.244，external IP是8.219.175.179。内核路由内核路由centos-59cdc5c9c4-89f8x IP 地址 10.0.0.202，该容器在宿主机表现的 PID 是2314075，该容器网络命名空间有指向容器 eth0 的默认路由。和下一跳为 veth1，目的网段为 service 的两条路由。全景剖析阿里云容器网络数据链路65该容器 eth0 在 ECS OS 内对应 veth pair 是 cali38ef34581a9。通过上述类似的办法，可以找到 nginx1-5969d8fc89-9t99hIP 地址 10.0.0.203，该容器在宿主机表现的 PID 是 1094736，该容器 eth0 在 ECS OS 内对应 veth pair 是cali5068e632525。全景剖析阿里云容器网络数据链路66在 ECS OS 内，有指向 Pod IP，下一跳为为 calixxxx 的路由，通过前文可以知道 calixxx网卡是和每个 pod 内的 veth1 组成的 pair，所以，pod 内访问 SVC 的 CIDR 会有指向veth1 的路由，不会走默认的 eth0 路由。故 calixx 网卡在这里的主要作用是用于：节点访问 Pod 2.当节点或者 Pod 访问 SVC的 CIDR 时，会走 ECS OS 内核协议栈转换，走到 calixxx 和 veth1 访问 pod。全景剖析阿里云容器网络数据链路67小结小结可以访问到目的端centos-59cdc5c9c4-89f8x netns veth1 可以抓到数据包。centos-59cdc5c9c4-89f8x netns cali38ef34581a9 可以抓到数据包。全景剖析阿里云容器网络数据链路68nginx1-5969d8fc89-9t99h netns veth1 可以抓到数据包。nginx1-5969d8fc89-9t99h netns cali5068e632525 可以抓到数据包。全景剖析阿里云容器网络数据链路69数据链路转发示意图：数据链路转发示意图：数据链路是 ECS1 Pod1 netns veth1-calixxx1-calixxx2-ECS2 Pod2 netnsveth1；在 pod 内的 net namespace 中，命中 svc 的路由，从 veth1 网卡出 pod 到 ECS的 namespace，然后通过 linux routing 转到另一个 pod 的 calixx 网卡。这里的veth1 和 calixxx 是 veth pair；源端 pod 所分配的 veth，calicoxxx 网卡可以捕获到 svc IP 和源端 pod IP。SVC IP会在源端 ECS host 内命中 ipvs/iptables 规则，做了 nat 转化；目的段 pod 所分配的 veth，calicoxxx 网卡可以捕获 calicoxxx 网卡默认 ip 和目的pod IP；该网卡为被分配的 pod 独占，无法和其他 pod 进行共享；数据链路经过三次协议栈：Pod1，ECS OS 和 Pod2；全景剖析阿里云容器网络数据链路706)6)场景五：集群内访问场景五：集群内访问 SVCSVC IPIP（ClusterCluster IPIP），源端和，源端和 SVCSVC 后端后端 PodPod 为为不同节点不同节点环境环境ap-southeast-1.10.0.0.196 节点上存在 pod：centos-59cdc5c9c4-89f8x IP 地址10.0.0.202。ap-southeast-1.10.0.2.80节点上存在pod：nginx-6f545cb57c-jmbrq和10.0.2.86。Service 是 nginx 集群内 clusterIP 是 192.168.204.233，external IP 是 8.219.199.33。内核路由内核路由centos-59cdc5c9c4-89f8x IP 地址 10.0.0.202，该容器在宿主机表现的 PID 是2314075，该容器网络命名空间有指向容器 eth0 的默认路由。和下一跳为 veth1，目的网段为 service 的两条路由。该容器 eth0 在 ECS OS 内对应 veth pair 是 cali38ef34581a9。全景剖析阿里云容器网络数据链路71通过上述类似的办法，可以找到 nginx-6f545cb57c-jmbrqIP 地址 10.0.2.86，该容器在宿主机表现的 PID 是 1083623，该 pod 网卡 ENI 是直接被挂载到了 Pod 的网络命名空间内。小结小结可以访问到目的端全景剖析阿里云容器网络数据链路72数据链路转发示意图：数据链路转发示意图：数据链路是 ECS1 Pod1 netns veth1-cali38ef34581a9-ECS1 eth0-VPC-ECS2 Pod2 netns veth1；在客户端 pod 内的 net namespace 中，命中 svc 的路由，从 veth1 网卡出 pod到 ECS 的 namespace，然后通过 linux routing 转到客户端 ECS eth0 网卡,然后进入到 vpc 转发到目的 Pod 所属的 eth 网卡；源端 pod 所分配的 veth，calicoxxx 网卡可以捕获到 svc IP 和源端 pod IP；SVC IP 会在源端 ECS host 内命中 ipvs/iptables 规则，做了 fnat 转化。在源端 ECS所属的 eth0 只能捕获到 ipvs/iptables 规则所分配的目的 pod IP 和源 ECS IP；目的 pod 内 eth0 所捕获的 IP 是源端 ECS IP 和目的 POD IP。（源 POD IP 和 SVC IP不会体现）；该网卡为被分配的 pod 独占，无法和其他 pod 进行共享；数据链路经过三次协议栈：Pod1，ECS1 OS 和 Pod2；7)7)场景六场景六：集群内访问集群内访问 SVCSVC IPIP（ExternalExternal IPIP），源端和源端和 SVCSVC 后端后端 PodPod 为为同一节点同一节点环境环境全景剖析阿里云容器网络数据链路73ap-southeast-1.10.0.0.196 节点上存在两个 pod：centos-59cdc5c9c4-89f8x IP 地址 10.0.0.202 和 nginx1-5969d8fc89-9t99h 和 10.0.0.203Service 是 nginx1 集群内 clusterIP 是 192.168.221.163，external IP 是 10.0.2.89。内核路由内核路由centos-59cdc5c9c4-89f8x IP 地址 10.0.0.202，该容器在宿主机表现的 PID 是2314075，该容器网络命名空间有指向容器 eth0 的默认路由。和下一跳为 veth1，目的网段为 service 的 ClusterIP 的两条路由。SLBSLB 相关配置相关配置在 SLB 控制台，可以看到虚拟服务器组的后端只有 nginx1-5969d8fc89-9t99h 的 ENIeni-t4n6qvabpwi24w0dcy55。综上，可以判断如果访问的是 SVC 的 External IP，是走默认路由 eth0，直接出 ECS 进全景剖析阿里云容器网络数据链路74入到 avs，访问到 SLB 的实例，再由 SLB 实例转发到后端 eni 上。小结小结可以访问到目的端数据链路转发示意图：数据链路转发示意图：数据链路是 ECS1 Pod1 netns eth0-VPC-SLB-VPC-ECS1 Pod2 netnseth0。数据链路不经过宿主机 host namespace，数据链路会先出 ECS1，到 AVS再回到 ECS1；在 pod 内的 net namespace 中，直接命中默认路有规则，从 eth0 网卡出 pod 直接到 VPC。这里的 eth0 其实就是附属网卡 ENI，直接被挂载在了 pod 的 net ns，走了 PCI 设备；全景剖析阿里云容器网络数据链路75该网卡为被分配的 pod 独占，无法和其他 pod 进行共享；与 2.4 场景可以看到非常大的不同，虽然都是前后端 Pod 都是部署在同一个 ECS访问 SVC 的 IP，但是可以看到如果访问的是 SVC 的 ClusterIP，则数据链路会进入到 ECS OS 层面，会经过三次协议栈；如果访问的是 External IP，则不会经过 ECSOS，直接出 ECS，经过 SLB 转发到目的 Pod 上，只经过两次协议栈(Pod1 和 Pod2)；8)8)场景七：集群内访问场景七：集群内访问 SVCSVC IPIP（ExternalExternal IPIP），源端和，源端和 SVCSVC 后端后端 PodPod 为为不同节点不同节点环境环境ap-southeast-1.10.0.0.196 节点上存在 pod：centos-59cdc5c9c4-89f8x IP 地址10.0.0.202。ap-southeast-1.10.0.2.80节点上存在pod：nginx-6f545cb57c-jmbrq和10.0.2.86。Service 是 nginx 集群内 clusterIP 是 192.168.254.141，external IP 是 10.0.2.90。内核路由内核路由centos-59cdc5c9c4-89f8x IP 地址 10.0.0.202，该容器在宿主机表现的 PID 是2314075，该容器网络命名空间有指向容器 eth0 的默认路由。和下一跳为 veth1，目的网段为 service 的 ClusterIP 的两条路由。全景剖析阿里云容器网络数据链路76SLBSLB 相关配置相关配置在 SLB 控制台，可以看到 lb-t4nih6p8w8b1dc7p587j9 虚拟服务器组的后端只有nginx-6f545cb57c-jmbrq 的 ENI eni-t4n5kzo553dfak2sp68j。综上，可以判断如果访问的是 SVC 的 External IP，是走默认路由 eth0，直接出 ECS 进入到 avs，访问到 SLB 的实例，再由 SLB 实例转发到后端 eni 上。全景剖析阿里云容器网络数据链路77小结小结可以访问到目的端数据链路转发示意图：数据链路转发示意图：数据链路是 ECS1 Pod1 netns eth0-VPC-SLB-VPC-ECS2 Pod2 netnseth0。数据链路不经过宿主机 host namespace，数据链路会先出 ECS1，到 SLB再回到 ECS2；在 pod 内的 net namespace 中，直接命中默认路有规则，从 eth0 网卡出 pod 直接到 VPC。这里的 eth0 其实就是附属网卡 ENI，直接被挂载在了 pod 的 net ns，走了 PCI 设备；该网卡为被分配的 pod 独占，无法和其他 pod 进行共享；与 2.5 场景可以看到非常大的不同，虽然都是前后端 Pod 都是部署在不同 ECS 访问 SVC 的 IP，但是可以看到如果访问的是 SVC 的 ClusterIP，则数据链路会进入到ECS OS 层面，通过 ECS 的 eth0 出 ECS，进入到 AVS，会经过三次协议栈；如果访问的是 External IP，则不会经过 ECS OS，直接通过 Pod 所属的的附属 ENI 出ECS，经过 SLB 转发到目的 Pod 上，只经过两次协议栈(Pod1 和 Pod2)；9)9)场景八：集群外访问场景八：集群外访问 SVCSVC ExternalExternal IPIP环境环境全景剖析阿里云容器网络数据链路78ap-southeast-1.10.0.2.80节点上存在pod：nginx-6f545cb57c-jmbrq和10.0.2.86。ap-southeast-1.10.0.1.233 节点上存在 pod：nginx-6f545cb57c-25k9z 和10.0.1.239。Service 是 nginx 集群内 clusterIP 是 192.168.254.141，external IP 是 10.0.2.90。SLBSLB 相关配置相关配置在 SLB 控制台，可以看到 lb-t4nih6p8w8b1dc7p587j9 虚拟服务器组的后端服务器组是两个后端 nginxPod 的的 ENI eni-t4n5kzo553dfak2sp68j 和eni-t4naaozjxiehvmg2lwfo。从集群外部角度看，SLB 的后端虚拟服务器组是 SVC 的后端 Pod 所属的两个 ENI 网卡，内网的 IP 地址就是 Pod 的地址。没有经过后端 Pod 所在的 ECS 的 OS 层面，直接进入到了 OS 的的协议栈。全景剖析阿里云容器网络数据链路79小结小结可以访问到目的端数据链路转发示意图：数据链路转发示意图：数据链路：client-SLB-Pod ENI Pod Port-ECS1 Pod1 eth0；数据链路要经过一次内核协议栈，是 Pod1 协议栈；10)10)小结小结本篇文章主要聚焦 ACK 在 Terway ENI 模式下，不同 SOP 场景下的数据链路转发路径。伴随着客户对性能的极致追求的需求，在 Terway ENI 模式下，一共可以分为 8 个 SOP场景，并对这八个场景的转发链路，技术实现原理，云产品配置等一一梳理并总结，这对我们遇到 Terway ENI 架构下的链路抖动、最优化配置，链路原理等提供了初步指引方向。在 Terway ENI 模式下，ENI 是以 PCI 方式直接挂载到 Pod 的命名空间内，这就以为 ENI 属于被分配的 Pod 独享，而 ECS 所能部署的 Pod 数量取决于 ECS 所能挂载 ENI 网卡数量的限制，而这个限制和 ECS 的实例规格类型有关，比如神龙 ecs.ebmg7.32xlar全景剖析阿里云容器网络数据链路80ge，128C 512GB 也只支持最多 32 个 ENI，这往往会造成资源的浪费和部署密度的降低，为了解决这个资源效率问题，ACK 带来了 Terway ENIIP 的方式，来实现 ENI 网卡可以被多个 Pod 所共享，这大大增加了单个 ECS 上的 Pod 数量 quota，提升了部署密度，这也是目前线上集群采用最多的架构。下一系列我们将进入到 Terway ENIIP 模式的全景解析。3.Terway ENIIP 模式架构设计弹性网卡(ENI)支持配置多个辅助 IP 的功能，单个弹性网卡(ENI)根据实例规格可以分配6-20 个辅助 IP，ENI 多 IP 模式就是利用了这个辅助 IP 分配给容器，从而大幅提高了Pod 部署的规模和密度。在网络联通的方式上，Terway 支持选择 Veth pair 策略路由和 ipvlan l 两种方案，Terway 主要考虑了这些：在节点上如何把弹性网卡(ENI)的辅助 IP 的流量都走对应的弹性网卡出去，并使用弹性网卡本身的 mac 地址而不被丢包；2.如何兼容容器服务目前广泛的 Centos 7.x 的 3.10 的版本的内核；全景剖析阿里云容器网络数据链路81Pod 所使用的的 CIDR 网段和节点的 CIDR 是同一个网段。pod 内部可以看到是有一张网卡的，一个是 eth0，其中 eth0 的 IP 就是 Pod 的 IP，此网卡的 MAC 地址和控制台上的 ENI 的 MAC 地址不一致，同时 ECS 上有多张 ethx 的网卡，说明 ENI 附属网卡并不是直接挂在到了 Pod 的网络命名空间。全景剖析阿里云容器网络数据链路82Pod 内有只有指向 eth0 的默认路由，说明说明 PodPod 访问任何地址段都是从访问任何地址段都是从 eth0eth0 为统一的为统一的出入口。出入口。如上图所示，我们可以容器的网络命名空间中通过 ip addr 看到一个 eth0if63 的标志位，其中63 这个将会协助我们在 ECS 的 OS 内找到找到和容器网络命名空间中的veth pair 相对一个。在 ECS OS 内我们通过 ip addr|grep 63:可以找到cali44ae9fbceeb 这个虚拟网卡，这个就是 veth pair 在 ECS OS 侧相对的那一个。ECS OS 内对于数据流量是怎么判断去哪个容器呢？通过 OS Linux Routing 我们可以看到，所有目的是 Pod IP 的流量都会被转发到 Pod 对应的 calico 虚拟往卡上，到这里为止，ECS OS 和 Pod 的网络命名空间已经建立好完整的出入链路配置了。全景剖析阿里云容器网络数据链路83在 veth pair 中实现了多个 Pod 共享一个 ENI 的方式来提升了 ECS 的 Pod 部署密度，那么如何知道 Pod 是被分配到哪个 ENI 呢？TerwayPod 是通过 daemonset 的方式部署在每个节点上的，通过下面命令可以看到每个节点上的 TerwayPod。通过 terway-clishow factory 命令可以看到节点上的附属 ENI 数量、MAC 地址以及每个 ENI 上的 IP。全景剖析阿里云容器网络数据链路84故 Terway ENIIP 模式总体可以归纳为：在网络联通的方式上，采用选择 Veth pair 策略路由。一对 veth pair 来联通宿主机和 pod 的网络空间，pod 的地址是来源于弹性网卡的辅助 IP 地址，并且节点上需要配置策略路由来保证辅助 IP 的流量经过它所属的弹性网卡。同主机上的容器通信直接通过主机上的路由到同一个主机上别的容器对应的 veth上。不同主机的容器通信经过 VPC 的网络进行转发到对应的机器上，再通过机器上的路由转发到容器中。容器和其所在的宿主机之间的通信直接通过连接到宿主机 namespace 的 vethpair 和路由打通。容器到其他主机通过 VPC 的网络转发到对应的机器，其他主机到容器通过 VPC 网络转发到对应的弹性网卡，然后通过路由转发到容器的 Veth 上。容器到专线和共享服务也都是通过 VPC 的网络转发。容器到公网的访问经过 VSwitch 配置的 SNAT 网关直接将源 IP 转换成 EIP 的地址到外部网络。弹性网卡(ENI)支持配置多个辅助 IP 的功能，单个弹性网卡(ENI)根据实例规格可以分配 6-20 个辅助 IP，ENI 多 IP 模式就是利用了这个辅助 IP 分配给容器，从而大幅提高了 Pod 部署的规模和密度。1)1)TerwayTerway ENIIPENIIP 模式容器网络数据链路剖析模式容器网络数据链路剖析针对容器网络特点，我们可以将 Terway ENI 模式下的网络链路大体分为以 Pod IP 对外提供服务和以 SVC 对外提供服务两个大的 SOP 场景，进一步细分，可以归纳为 7 个不同的小的 SOP 场景。全景剖析阿里云容器网络数据链路85对这 8 个场景的数据链路梳理合并，这些场景可以归纳为下面 8 类典型的场景：TerwayENI 架构下，不同的数据链路访问情况下，可以总结归纳为为 8 类：访问 Pod IP，同节点访问 Pod访问 Pod IP/SVC IP(Cluster or Local)，同节点 pod 间互访（pod 属于同 or 不同ENI）访问 PodIP，异节点 pod 间互访集群内非 SVC 后端 pod 所在节点访问 SVC ClusterIPCluster 模式，集群内非 SVC 后端 pod 所在节点访问 SVC External IPLocal 模式，集群内非 SVC 后端 pod 所在节点访问 SVC External IP集群外访问 SVC External IP2)2)场景一：访问场景一：访问 PodPod IPIP，同节点访问，同节点访问 podpod环境环境全景剖析阿里云容器网络数据链路86cn-hongkong.10.0.1.82 节点上存在 nginx-7d6877d777-zp5jg 和 10.0.1.104。内核路由内核路由nginx-7d6877d777-zp5jg IP 地址 10.0.1.104，该容器在宿主机表现的 PID 是1094736，该容器网络命名空间有指向容器 eth0 的默认路由。该容器 eth0 在 ECS OS 内对应 veth pair 是 calif03b26f9a43。在 ECS OS 内，有指向 Pod IP，下一跳为为 calixxxx 的路由，通过前文可以知道 calixxx网卡是和每个 pod 内的 veth1 组成的 pair，所以，pod 内访问 SVC 的 CIDR 会有指向veth1 的路由，不会走默认的 eth0 路由。故：calixx 网卡在这里的主要作用是用于：1.节点访问 Pod 2.当节点或者 Pod 访问 SVC 的 CIDR 时，会走 ECS OS 内核协议栈转换，走到 calixxx 和 veth1 访问 pod。全景剖析阿里云容器网络数据链路87小结小结可以访问到目的端nginx-7d6877d777-zp5jg netns eth0 可以抓到数据包。nginx-7d6877d777-zp5jg calif03b26f9a43 可以抓到数据包。全景剖析阿里云容器网络数据链路88数据链路转发示意图：数据链路转发示意图：会经过calicao网卡，每个非hostnetwork的pod会和calicao网卡形成veth pair，用于和其他 pod 或 node 进行通信。整个链路不会和请求不会经过pod所分配的ENI，直接在OS的ns中命中Ip rule 被转发。整个请求链路是 OS-calixxxxx-ECSPod net eth0。整个链路会经过两次内核协议栈：ECS OS 和 Pod。数据链路要经过两次内核协议栈，是 Pod1 协议栈、ECS1 协议栈。全景剖析阿里云容器网络数据链路893 3）场景二：访问场景二：访问 PodPod IP/SVCIP/SVC IP(ClusterIP(Cluster oror Local)Local)，同节点，同节点 podpod 访访问问podpod（podpod 属于同属于同 oror 不同不同 ENIENI）环境环境cn-hongkong.10.0.1.82 节点上存在 nginx-7d6877d777-zp5jg 和 10.0.1.104cn-hongkong.10.0.1.82 节点上存在 centos-67756b6dc8-h5wnp 和 10.0.1.91Service 是 nginx，ClusterIP 是 192.168.2.115 ExternalIP 是 10.0.3.62。内核路由内核路由nginx-7d6877d777-zp5jg IP 地址 10.0.1.104，该容器在宿主机表现的 PID 是1094736，该容器网络命名空间有指向容器 eth0 的默认路由。该容器 eth0 在 ECS OS 内对应 veth pair 是 calif03b26f9a43。全景剖析阿里云容器网络数据链路90用上述类似办法可以发现 centos-67756b6dc8-h5wnp 的 veth pair 的cali44ae9fbceeb，Pod 网络空间只有默认路由。在 ECS OS 内，有指向 Pod IP，下一跳为为 calixxxx 的路由，通过前文可以知道 calixxx网卡是和每个 pod 内的 veth1 组成的 pair，所以，pod 内访问 SVC 的 CIDR 会有指向veth1 的路由，不会走默认的 eth0 路由。故：calixx 网卡在这里的主要作用是用于：1.节点访问 Pod 2.当节点或者 Pod 访问 SVC 的 CIDR 时，会走 ECS OS 内核协议栈转换，走到 calixxx 和 eth0 访问 pod。全景剖析阿里云容器网络数据链路91说明相关的路由转发是在 ECS OS 层面进行的，Pod 的 calixx 网卡起到了一个桥梁和连通的作用。源端源端 ECSECS 上的上的 IPVSIPVS 规则（如果访问的是规则（如果访问的是 SVCSVC IPIP）如果同节点上访问的是 SVC 的 IP（ClusterIP or ExternalIP）,在节点上我们查看 SVC的相关 IPVS 转发规则：ServiceService 的的 ExternalTrafficPolicyExternalTrafficPolicy 是是 LocalLocalSVC nginx CLusterIP 是 192.168.2.115，ExternalIP 是 10.0.3.62。后端是 10.0.1.104和 10.0.3.58。全景剖析阿里云容器网络数据链路92cn-hongkong.10.0.1.82对于 SVC 的 ClusterIP，可以看到 SVC 的后端两个 Pod 都会被加到 IPVS 的转发规则。对于 SVC 的 ExternalIP，可以看到 SVC 的后端，只有该节点的后端 Pod 10.0.1.104 才会被加到 IPVS 的转发规则在在LoadBalanceLoadBalancer r 的的SVSVC C模式下模式下，如如果果ExternalTrafficPolicExternalTrafficPolicy y 为为LocalLocal，对对于于ClusterIClusterIP P来说，会把所有来说，会把所有 SVCSVC 后端后端 PodPod 都会加到该节点的都会加到该节点的 IPVSIPVS 转发规则；对于转发规则；对于 ExternalIPExternalIP，只会把该节点上的只会把该节点上的 SVCSVC 后端后端 PodPod 才会加到才会加到 IPVSIPVS 规则中。如果该节点没有规则中。如果该节点没有 SVCSVC 后后端端PodPod，则该节点上的，则该节点上的 PodPod 访问访问 SVCSVC 的的 ExternalIPExternalIP 将会是失败。将会是失败。ServiceService 的的 ExternalTrafficPolicyExternalTrafficPolicy 是是 ClusterClusterSVC nginx1 CLusterIP 是 192.168.2.253，ExternalIP 是 10.0.3.63，后端是 10.0.1.104和 10.0.3.58全景剖析阿里云容器网络数据链路93cn-hongkong.10.0.1.82对于 SVC 的 ClusterIP，可以看到 SVC 的后端两个 Pod 都会被加到 IPVS 的转发规则。对于 SVC 的 ExternalIP，可以看到 SVC 的后端两个 Pod 都会被加到 IPVS 的转发规则。在在 LoadBalancerLoadBalancer 的的 SVCSVC 模式下，如果模式下，如果 ExternalTrafficPolicyExternalTrafficPolicy 为为 ClusterCluster，对，对于于ClusterIPClusterIP 或或 ExternalIPExternalIP 来说，会把所有来说，会把所有 SVCSVC 后端后端 PodPod 都会加到该节点的都会加到该节点的 IPVSIPVS 转发转发规则。规则。小结小结可以访问到目的端全景剖析阿里云容器网络数据链路94ConntrackConntrack 表信息表信息ServiceService nginxnginx 的的 ExternalTrafficPolicyExternalTrafficPolicy 是是 LocalLocal。SVC nginx CLusterIP 是 192.168.2.115，ExternalIP 是 10.0.3.62。后端是 10.0.1.104和 10.0.3.58。如果访问的是 SVC 的 ClusterIP，通过 conntrack 信息，可以看到 src 是源端 Pod10.0.1.91，dst 是 SVC ClusterIP 192.168.2.115，dport 是 SVC 中的 port。并且期望是 10.0.1.104 来回包给 10.0.1.91。如果访问的是 SVC 的 ExternalIP，通过 conntrack 信息，可以看到 src 是源端 Pod10.0.1.91，dst 是 SVC ExternalIP 10.0.3.62。dport 是 SVC 中的 port。并且期望是 10.0.1.104 来回包给 10.0.1.91。Service nginx1 的 ExternalTrafficPolicy 是 Cluster。SVC nginx1 CLusterIP 是 192.168.2.253，ExternalIP 是 10.0.3.63，后 端 是10.0.1.104 和 10.0.3.58。如果访问的是 SVC 的 ClusterIP，通过 conntrack 信息，可以看到 src 是源端 Pod10.0.1.91，dst 是 SVC ClusterIP 192.168.2.253，dport 是 SVC 中的 port。并且期望是 10.0.1.104 来回包给 10.0.1.91。如果访问的是 SVC 的 ExternalIP，通过 conntrack 信息，可以看到 src 是源端 Pod10.0.1.91，dst 是 SVC ExternalIP 10.0.3.63，dport 是 SVC 中的 port。并且期望是节点 ECS 的 IP 10.0.1.82 来回包给 10.0.1.91。全景剖析阿里云容器网络数据链路95综上可以看到 src 变换了多次，故在 Cluster 模式下，会存在丢失真实客户端 IP 的情况。数据链路转发示意图：数据链路转发示意图：会经过calicao网卡，每个非hostnetwork的pod会和calicao网卡形成veth pair，用于和其他 pod 或 node 进行通信；整个链路不会和请求不会经过pod所分配的ENI，直接在OS的ns中命中Ip rule 被转发；整个请求链路是ECS1 Pod1 eth0-Pod1 calixxxx-Pod2 calixxxx-ECS1 Pod2eth0；访问 SVC IP，SVC 会在源端 pod eth0 和 calixxx 网卡捕捉到，在目的端 pod 的eth0 和 calixxx 时捕捉不到；在 LoadBalancer 的 SVC 模式下，如果 ExternalTrafficPolicy 为 Local，对于ClusterIP 来说，会把所有 SVC 后端 Pod 都会加到该节点的 IPVS 转发规则；对于ExternalIP，只会把该节点上的 SVC 后端 Pod 才会加到 IPVS 规则中；全景剖析阿里云容器网络数据链路96在 LoadBalancer 的 SVC 模式下，如果 ExternalTrafficPolicy 为 Cluster，对于ClusterIP 或 ExternalIP 来说，会把所有 SVC 后端 Pod 都会加到该节点的 IPVS 转发规则，同时无法保留 src 地址；数据链路要经过三次内核协议栈，是 Pod1 协议栈、ECS1 协议栈、Pod2 协议栈；4)4)场景三：访问场景三：访问 PodIPPodIP，异节点，异节点 podpod 间互访间互访环境环境cn-hongkong.10.0.1.82 节点上存在 centos-67756b6dc8-h5wnp 和 10.0.1.91cn-hongkong.10.0.3.49 节点上存在 nginx-7d6877d777-lwrfc 和 10.0.3.58。内核路由内核路由centos-67756b6dc8-h5wnp IP 地址 10.0.1.104，该容器在宿主机表现的 PID 是2211426，该容器网络命名空间有指向容器 eth0 的默认路由。用上述类似办法可以发现 centos-67756b6dc8-h5wnp 的 veth pair 的cali44ae9fbceeb，Pod 网络空间只有默认路由。全景剖析阿里云容器网络数据链路97在 ECS OS 内，有指向 Pod IP，下一跳为为 calixxxx 的路由，通过前文可以知道 calixxx网卡是和每个 pod 内的 veth1 组成的 pair，所以，pod 内访问 SVC 的 CIDR 会有指向veth1 的路由，不会走默认的 eth0 路由。故：calixx 网卡在这里的主要作用是用于：1.节点访问 Pod 2.当节点或者 Pod 访问 SVC 的 CIDR 时，会走 ECS OS 内核协议栈转换，走到 calixxx 和 eth0 访问 pod,对于目的为外部地址，则走 Pod 所属的 ENI 出 ECS 进入到了 VPC。全景剖析阿里云容器网络数据链路98小结小结可以访问到目的端数据链路转发示意图：数据链路转发示意图：会经过calicao网卡，每个非hostnetwork的pod会和calicao网卡形成veth pair，用于和其他 pod 或 node 进行通信;整个链路请求会经过 pod 所分配的 ENI，直接在 OS 的 ns 中命中 Ip rule 被转发；出 ECS 后，根据要访问的 pod 和该 pod ENI 所属 vswitch，命中 VPC 路由规则或者直接 VSW 上的二层转发；整个请求链路是 ECS1 Pod1 eth0-ECS1 Pod1 calixxxxx-ECS1 ethx-vpcroute rule(如有)-ECS2 ethx-ECS2 Pod2 calixxxxx-ECS2 Pod2 eth0;数据链路要经过四次内核协议栈，Pod1 协议栈、ECS1 协议栈、Pod2 协议栈、ECS2协议栈;全景剖析阿里云容器网络数据链路995)5)场景四：群内非场景四：群内非 SVCSVC 后端后端 podpod 所在节点访问所在节点访问 SVCSVC ClusterIPClusterIP环境环境cn-hongkong.10.0.3.49 节点上存在 nginx-7d6877d777-h4jtf 和 10.0.3.58cn-hongkong.10.0.1.82 节点上存在 centos-67756b6dc8-h5wnp 和 10.0.1.91。Service1 是 nginx，ClusterIP 是 192.168.2.115 ExternalIP 是 10.0.3.62。Service2 是 ngin1，ClusterIP 是 192.168.2.253 ExternalIP 是 10.0.3.63。内核路由内核路由内核路由部分已经在 2.2 和 2.3 小结中详细说明，这里不再进行过多阐述。源端源端 ECSECS 上的的上的的 IPVSIPVS 规则规则根据 2.2 小结中的源端 ECS 上的 IPVS 规则，我们可以得到：无论在哪种 SVCSVC 模式下模式下，对于对于 ClusterIPClusterIP 来说，会把所有来说，会把所有 SVCSVC 后端后端 PodPod 都会加到该节点的都会加到该节点的 IPVSIPVS 转发规则转发规则。小结小结可以访问到目的端全景剖析阿里云容器网络数据链路100Conntrack 表信息Service nginx 的 ExternalTrafficPolicy 是 LocalSVC nginx CLusterIP 是 192.168.2.115，ExternalIP 是 10.0.3.62。后端是 10.0.1.104和 10.0.3.58cn-hongkong.10.0.1.82源端 ECS 上 src 是源端 Pod 10.0.1.91，dstdst 是是 SVCSVC ClusterIPClusterIP 192.168.2.115192.168.2.115，dport是 SVC 中的 port。并且期望是 10.0.3.58 来回包给 10.0.1.91。cn-hongkong.10.0.3.49目的端 ECS 上 src 是源端 Pod 10.0.1.91，dstdst 是是 PodPod 的的 IPIP 10.0.3.5810.0.3.58,port 是 pod 的port。并且期望此 pod 来回包给 10.0.1.91。Service nginx1 的 ExternalTrafficPolicy 是 ClusterCluster。SVC nginx1 CLusterIP 是 192.168.2.253，ExternalIP 是 10.0.3.63，后端是 10.0.1.104和 10.0.3.58。cn-hongkong.10.0.1.82源端 ECS 上 src 是源端 Pod 10.0.1.91，dstdst 是是 SVCSVC ClusterIPClusterIP 192.168.2.115192.168.2.115，dport是 SVC 中的 port。并且期望是 10.0.3.58 来回包给 10.0.1.91。全景剖析阿里云容器网络数据链路101cn-hongkong.10.0.3.49目的端 ECS 上 src 是源端 Pod 10.0.1.91，dstdst 是是 PodPod 的的 IPIP 10.0.3.5810.0.3.58，dport 是 pod的 port。并且期望此 pod 来回包给 10.0.1.91。对于 ClusterIP 来说，源端 ECS 会把所有 SVC 后端 Pod 都会加到该节点的 IPVS 转发规则，目的端 ECS 是捕获不到任何 SVC ClusterIP 信息的，只能捕获到源端 Pod 的 IP，所以回包的时候会回到源端 Pod 的附属网卡上。数据链路转发示意图：数据链路转发示意图：会经过calicao网卡，每个非hostnetwork的pod会和calicao网卡形成veth pair，用于和其他 pod 或 node 进行通信；整个链路请求会经过 pod 所分配的 ENI，直接在 OS 的 ns 中命中 Ip rule 被转发；出 ECS 后，根据要访问的 pod 和该 pod ENI 所属 vswitch，命中 VPC 路由规则或者直接 VSW 上的二层转发；整个请求链路是去方向：ECS1 Pod1 eth0-ECS1 Pod1 calixxxxxx-ECS1 主网卡 eth0-vpc route全景剖析阿里云容器网络数据链路102rule(如有)-ECS2 附属网卡 ethx-ECS2 Pod2 calixxxxx-ECS2 Pod2 eth0；回方向：ECS2 Pod2 eth0-ECS2 Pod2 calixxxxx-ECS2 附属网卡 ethx-vpc routerule(如有)-ECS1 附属网卡 eth1-ECS1 Pod1 calixxxxxx-ECS1 Pod1 eth0；对于 ClusterIP 来说，源端 ECS 会把所有 SVC 后端 Pod 都会加到该节点的 IPVS 转发规则，目的端 ECS 是捕获不到任何 SVC ClusterIP 信息的，只能捕获到源端 Pod的 IP，所以回包的时候会回到源端 Pod 的附属网卡上；数据链路要经过四次内核协议栈，Pod1 协议栈、ECS1 协议栈、Pod2 协议栈、ECS2协议栈；6 6）场景五：场景五：ClusterCluster 模式，集群内非模式，集群内非 SVCSVC 后端后端 podpod 所在节点访问所在节点访问 SVCSVCExternalExternal IPIP环境环境cn-hongkong.10.0.3.49 节点上存在 nginx-7d6877d777-h4jtf 和 10.0.3.58cn-hongkong.10.0.1.82 节点上存在 centos-67756b6dc8-h5wnp 和 10.0.1.91Service2 是 ngin1，ClusterIP 是 192.168.2.253 ExternalIP 是 10.0.3.63。内核路由内核路由内核路由部分已经在 2.2 和 2.3 小结中详细说明，这里不再进行过多阐述。全景剖析阿里云容器网络数据链路103源端源端 ECSECS 上的上的 IPVSIPVS 规则规则根据 2.2 小结中的源端 ECS 上的 IPVS 规则，我们可以得到：ExternalTrafficPolicy 为Cluster 模式下，对于 ExternalIP 来说，会把所有 SVC 后端 Pod 都会加到该节点的 IPVS转发规则。小结小结可以访问到目的端Conntrack 表信息Service nginx1 的 ExternalTrafficPolicy 是 Cluster。SVC nginx1 CLusterIP 是 192.168.2.253，ExternalIP 是 10.0.3.63，后端是 10.0.1.104和 10.0.3.58。cn-hongkong.10.0.1.82源端 ECS 上 src 是源端 Pod 10.0.1.91，dst 是 SVC ExternalIP 10.0.3.63，dport 是SVC 中的 port。并且期望是 10.0.3.58 来回包给源端 ECS 的地址 10.0.1.82。cn-hongkong.10.0.3.49目的端 ECS 上 src 是源端 Pod 所在的 ECS 地址 10.0.1.82，dst 是 Pod 的 IP 10.0.3.58，dport 是 pod 的 port。并且期望此 pod 来回包给源端 ECS 的地址 10.0.1.82。全景剖析阿里云容器网络数据链路104在在 ExternalTrafficPolicyExternalTrafficPolicy 为为 ClusterCluster 下，对于下，对于 ExternalIPExternalIP 来说，源端来说，源端 ECSECS 会把所会把所有有SVCSVC 后端后端 PodPod 都会加到该节点的都会加到该节点的 IPVSIPVS 转发规则，目的端转发规则，目的端 ECSECS 是捕获不到任何是捕获不到任何 SVCSVCExternalIPExternalIP 信息的信息的，只能捕获到源端只能捕获到源端 PodPod 所在的所在的 ECSECS 的的 IPIP，所以回包的时候会回到源所以回包的时候会回到源端端 PodPod 所在的所在的 ECSECS 的主网卡上，这一点明显和的主网卡上，这一点明显和 2.42.4 小结中访问小结中访问 CusterIPCusterIP 有很明显区有很明显区别。别。数据链路转发示意图：数据链路转发示意图：会经过calicao网卡，每个非hostnetwork的pod会和calicao网卡形成veth pair，用于和其他 pod 或 node 进行通信；整个链路请求会经过 pod 所分配的 ENI，直接在 OS 的 ns 中命中 Ip rule 被转发；出 ECS 后，根据要访问的 pod 和该 pod ENI 所属 vswitch，命中 VPC 路由规则或者直接 VSW 上的二层转发；整个请求链路是 ECS1 Pod1 eth0-ECS1 Pod1 calixxxx-ECS1 主网卡 ENI eth0-vpc route rule(如有)-ECS2 附属网卡 ethx-ECS2 Pod2 calixxx-ECS2Pod2 eth0；在 ExternalTrafficPolicy 为 Cluster 下，对于 ExternalIP 来说，源端 ECS 会把所有SVC 后端 Pod 都会加到该节点的 IPVS 转发规则，目的端 ECS 是捕获不到任何 SVCExternalIP 信息的，只能捕获到源端 Pod 所在的 ECS 的 IP，所以回包的时候会回到源端 Pod 所在的 ECS 的主网卡；全景剖析阿里云容器网络数据链路105数据链路要经过四次内核协议栈，Pod1 协议栈、ECS1 协议栈、Pod2 协议栈、ECS2协议栈；7 7）场景六：场景六：LocalLocal 模式，集群内非模式，集群内非 SVCSVC 后端后端 podpod 所在节点访问所在节点访问 SVCSVCExternalExternal IPIP环境环境cn-hongkong.10.0.3.49 节点上存在 nginx-7d6877d777-h4jtf 和 10.0.3.58cn-hongkong.10.0.1.82 节点上存在 centos-67756b6dc8-h5wnp 和 10.0.1.91Service1 是 nginx，ClusterIP 是 192.168.2.115 ExternalIP 是 10.0.3.62。内核路由内核路由内核路由部分已经在 2.2 和 2.3 小结中详细说明，这里不再进行过多阐述。源端 ECS 上的的 IPVS 规则Service 的 ExternalTrafficPolicy 是 LocalSVC nginx CLusterIP 是 192.168.2.115，ExternalIP 是 10.0.3.62。后端是 10.0.1.104和 10.0.3.58。全景剖析阿里云容器网络数据链路106cn-hongkong.10.0.1.82对于 SVC 的 ExternalIP，可以看到 SVC 的后端，无任何转发规则。根据 2.2 小结中的源端 ECS 上的 IPVS 规则，我们可以得到：ExternalTrafficPolicExternalTrafficPolicy y为为 LocalLocal 模式下模式下，对于对于 ExternalIPExternalIP 来说来说，只会把本节点上的只会把本节点上的 SVCSVC 的后端的后端 PodPod 加到节点加到节点上的上的 IPVSIPVS 转发规则，如果该节点没有转发规则，如果该节点没有 SVCSVC 后端，则不会有任何可以转发的规则。后端，则不会有任何可以转发的规则。小结小结不可以访问到目的端Conntrack 表信息Service 的 ExternalTrafficPolicy 是 LocalSVC nginx1 CLusterIP 是 192.168.2.253，ExternalIP 是 10.0.3.63，后端是 10.0.1.104和 10.0.3.58。全景剖析阿里云容器网络数据链路107cn-hongkong.10.0.1.82 无任何 conntrack 记录表生成。数据链路转发示意图：数据链路转发示意图：会经过calicao网卡，每个非hostnetwork的pod会和calicao网卡形成veth pair，用于和其他 pod 或 node 进行通信；整个链路请求不会经过 pod 所分配的 ENI，直接在 OS 的 ns中命中 Ip rule 被转发；整 个 请 求 链 路 是 ECS1 Pod1 eth0-ECS1 Pod1 calixxxx-ECS host 空 间ipvs/iptables 规则，无后端转发 ep 终止链路；ExternalTrafficPolicy 为 Local 模式下，对于 ExternalIP 来说，只会把本节点上的SVC 的后端 Pod 加到节点上的 IPVS 转发规则，如果该节点没有 SVC 后端，则不会有任何可以转发的规则；全景剖析阿里云容器网络数据链路1088 8）场景七：集群外访问场景七：集群外访问 SVCSVC ExternalExternal IPIP环境环境cn-hongkong.10.0.3.49 节点上存在 nginx-7d6877d777-h4jtf 和 10.0.3.58。cn-hongkong.10.0.1.47 节点上存在 nginx-7d6877d777-kxwdb 和 10.0.1.29。Service1 是 nginx，ClusterIP 是 192.168.2.115 ExternalIP 是 10.0.3.62。SLBSLB 相关配置相关配置在 SLB 控制台，可以看到 lb-j6cw3daxxukxln8xccive 虚拟服务器组的后端服务器组是两个后端 nginxPod 的的 ENI eni-j6c4qxbpnkg5o7uog5kr 和eni-j6c6r7m3849fodxdf5l7。从集群外部角度看，SLB 的后端虚拟服务器组是 SVC 的后端 Pod 所属的两个 ENI 网卡，内网的 IP 地址就是 Pod 的地址。全景剖析阿里云容器网络数据链路109小结小结可以访问到目的端数据链路转发示意图：数据链路转发示意图：数据链路：client-SLB-Pod ENI Pod Port-ECS1 Pod1 eth0；数据链路要经过二次内核协议栈，Pod1 协议栈和 ECS 协议栈；9 9）小结小结本篇文章主要聚焦 ACK 在 Terway ENIIP 模式下，不同 SOP 场景下的数据链路转发路径。伴随着客户对性能的极致追求的需求，在 Terway ENIIP 模式下，一共可以分为 7个 SOP 场景，并对这七个场景的转发链路，技术实现原理，云产品配置等一一梳理并总结，这对我们遇到 Terway ENIIP 架构下的链路抖动、最优化配置，链路原理等提供了初步指引方向。在 Terway ENIIP 模式下，利用 veth pair 来联通宿主机和 pod 的网络空间，pod 的地址是来源于弹性网卡的辅助 IP 地址，并且节点上需要配置策略路由来保证辅助 IP 的流量经过它所属的弹性网卡，通过此种方式可以实现 ENI 多 Pod 共享，大大提升了 Pod的部署密度，但是 veth pair 必然会利用 ECS 的内核协议栈进行转发，此架构下性能必然不如 ENI 模式，ACK 产研为了提升性能，结合内核的 ebpf 和 ipvlan 技术，开发了全景剖析阿里云容器网络数据链路110Terway ebpf ipvlan 架构。下一系列我们将进入到 Terway ENIIP 模式的全景解析4.Terway IPVLAN EBPF 模式架构设计弹性网卡(ENI)支持配置多个辅助 IP 的功能，单个弹性网卡(ENI)根据实例规格可以分配6-20 个辅助 IP，ENI 多 IP 模式就是利用了这个辅助 IP 分配给容器，从而大幅提高了Pod 部署的规模和密度。在网络联通的方式上，Terway 支持选择 Veth pair 策略路由和 ipvlan l 两种方案，Linux 在 4.2 以上的内核中支持了 ipvlan 的虚拟网络，可以实现单个网卡虚拟出来多个子网卡用不同的 IP 地址，而 Terway 便利用了这种虚拟网络类型，将弹性网卡的辅助 IP 绑定到 IPVlan 的子网卡上来打通网络，使用这种模式使 ENI多 IP 的网络结构足够简单，性能也相对 veth 策略路由较好。Pod 所使用的的 CIDR 网段和节点的 CIDR 是同一个网段全景剖析阿里云容器网络数据链路111Pod 内部可以看到是有一张网卡的，一个是 eth0，其中 eth0 的 IP 就是 Pod 的 IP，此网卡的 MAC 地址和控制台上的 ENI 的 MAC 地址不一致，同时 ECS 上有多张 ethx 的网卡，说明 ENI 附属网卡并不是直接挂在到了 Pod 的网络命名空间。Pod 内有只有指向 eth0 的默认路由，说明说明 PodPod 访问任何地址段都是从访问任何地址段都是从 eth0eth0 为统一的为统一的出入口。出入口。那么 Pod 是如何 ECS OS 进行通信呢？在 OS 层面，我们一看到 ipvl_x 的网卡，可以看到是附属于 eth1 的，说明在 OS 层面会给每个附属网卡创建一个 ipvl_x 的网卡，用于建立 OS 和 Pod 内的连接隧道。全景剖析阿里云容器网络数据链路112ECS OS 内对于数据流量是怎么判断去哪个容器呢？通过 OS Linux Routing 我们可以看到，所有目的是 Pod IP 的流量都会被转发到 Pod 对应的 ipvl_x 虚拟往卡上，到这里为止，ECS OS 和 Pod 的网络命名空间已经建立好完整的出入链路配置了。到目前为止介绍了 IPVLAN 在网络架构上实现了。对于 eni 多 IP 的实现，这个类似于Terway ENIIP 模式架构原理，TerwayPod 是通全景剖析阿里云容器网络数据链路113过 daemonset 的方式部署在每个节点上的，通过下面命令可以看到每个节点上的TerwayPod。通过 terway-cli show factory 命令可以看到节点上的附属 ENI 数量、MAC 地址以及每个 ENI 上的 IP。那么对于 SVC 来说，是如何实现的呢？看过前面 四个系列的朋友，应该知道对于 Pod 访问 SVC，容器是利用各种办法将请求转发到 Pod 所在的 ECS 层面，由 ECS 内的 netfilter 模块来实现 SVC IP 的解析，这固然是个好办法，但是由于数据链路需要从 Pod 的网络命名空间切换到 ECS 的 OS 的网络命名空间，中间经过了 2 次内核协议栈，必然会产生性能损失，如果对高并发和高性能有机制追求，可能并不完全满足客户的需求。那么对于高并发和延迟敏感业务，该如何实现呢？有没有办法让 Pod 访问 SVC 直接在 Pod 的网络命名空间中就实现了后端解析，这样结合 IPVLAN 这样至实现了一次内核协议栈。在 4.19 版本内核中，ebpf 的出现，很好的实现了这个需求，这里不对 ebpf 做过多说明，感兴趣的可以访问官方链接，小伙伴们只需要知道 ebpf 是一种可以安全在内核层面运行的安全沙盒，当触发内核的指定行为，ebpf 设定程序会被执行。利用这个特性，我们可以实现在 tc 层面对访问 SVC IP 的数据包进行修改。全景剖析阿里云容器网络数据链路114例如，同上图，可以看到集群内有一个名为 nginx 的 svc，clusterIP 是 192.168.27.242，后端 pod IP 是 10.0.3.38.通过 cilium bpf lb list 可以看到在 ebpf 程序中对于clusterIP 192.168.27.242 的访问会被转到 10.0.3.38 这个 IP 上，而 Pod 内只有一个默认路由。此处说明，此处说明，IPVLAN EBPFIPVLAN EBPF 模式下，如果模式下，如果 PodPod 访问访问 SVCSVC IPIP，SVCIPSVCIP 在在 PoPod d的网络命名空间内就会被的网络命名空间内就会被 ebpfebpf 转为某个转为某个 SVCSVC 后端后端 podpod 的的 IPIP，之后数据链路被发，之后数据链路被发出出PodPod。也就是说。也就是说 SVCIPSVCIP 只会在只会在 PodPod 内被捕获，在源端内被捕获，在源端 ECSECS，目的端，目的端 PodPod 和目的端和目的端的的PodPod 所在所在 ECSECS 都无法被捕获到。都无法被捕获到。假如一个 SVC 后后段有 100 Pod，因为 ebpf 存在，Pod 外无法捕获到 SVCIP，所在一旦出现网络抖动，对于抓包该抓那个后端 IP 或该在哪个后端 Pod 出抓包呢？想一想，是不是一个非常头疼又无解非常头疼又无解的场景?目前容器服务和 AES 共创了 ACK Net-Exporter容器网络可观测性工具，可以针对此场景进行持续化的观测和问题判断。故故 TerwayTerway IPVLAN EBPFIPVLAN EBPF 模式总体可以归纳为：模式总体可以归纳为：4.2 以上内核中支持了 ipvlan 的虚拟网络，可以实现单个网卡虚拟出来多个子网卡用不同的 IP 地址，而 Terway 便利用了这种虚拟网络类型，将弹性网卡的辅助 IP绑定到 IPVlan 的子网卡上来打通网络，使用这种模式使 ENI 多 IP 的网络结构足够简单，性能也相对 veth 策略路由较好。节点访问pod 需要经过host 的协议栈，pod 和pod 间访问不经过host的协议栈。IPVLAN EBPF 模式下，如果 Pod 访问 SVC IP，SVCIP 在 Pod 的网络命名空间内就会被ebpf转为某个SVC 后端pod的IP，之后数据链路被发出Pod。也就是说SVCIP只会在 Pod 内被捕获，在源端 ECS，目的端 Pod 和目的端的 Pod 所在 ECS 都无法被捕获到。1)TerwayTerway IPVLAN EBPFIPVLAN EBPF 模式容器网络数据链路剖析模式容器网络数据链路剖析针对容器网络特点，我们可以将 Terway IPVLAN EBPF 模式下的网络链路大体分为以Pod IP 对外提供服务和以 SVC 对外提供服务两个大的 SOP 场景，进一步细分，可以归纳为 12 个不同的小的 SOP 场景。全景剖析阿里云容器网络数据链路115对这 15 个场景的数据链路梳理合并，这些场景可以归纳为下面 11 类典型的场景：TerwayENI 架构下，不同的数据链路访问情况下，可以总结归纳为为 11 类：访问 Pod IP，同节点访问 Pod；访问 Pod IP，同节点 pod 间互访（pod 属于同 ENI）；访问 Pod IP，同节点 pod 间互访（pod 属于不同 ENI）；不同节点间 Pod 之间互访；集群内 Pod 访问的 SVC ClusterIP（含 Terway 版本1.2.0，访问 ExternalIP），SVC后端 Pod 和客户端 Pod 配属同一个 ENI；集群内 Pod 访问的 SVC ClusterIP（含 Terway 版本1.2.0，访问 ExternalIP），SVC后端 Pod 和客户端 Pod 配属不同 ENI（同 ECS）；集群内 Pod 访问的 SVC ClusterIP（含 Terway 版本1.2.0，访问 ExternalIP），SVC后端 Pod 和客户端 Pod 不属于不同 ECS；集群内 Pod 访问的 SVC ExternalIP（Terway 版本1.2.0），SVC 后端 Pod 和客户端 Pod 配属同一个 ENI；集群内 Pod 访问的 SVC ExternalIP（Terway 版本1.2.0），SVC 后端 Pod 和客户端 Pod 配属不同 ENI（同 ECS）；集群内 Pod 访问的 SVC ExternalIP（Terway 版本1.2.0），SVC 后端 Pod 和客户端 Pod 部署于不同 ECS；全景剖析阿里云容器网络数据链路116集群外访问 SVC ExternalIP；2)2)场景一：访问场景一：访问 PodPod IPIP，同节点访问，同节点访问 podpod环境环境cn-hongkong.10.0.3.15 节点上存在 nginx-7d6877d777-j7dqz 和 10.0.3.38。内核路由内核路由nginx-7d6877d777-j7dqz IP 地址 10.0.3.38。该容器在宿主机表现的 PID 是 329470，该容器网络命名空间有指向容器 eth0 的默认路由。该容器 eth0 在 ECS OS 内是通过 ipvlan 隧道的方式和 ECS 的附属 ENI eth1 建立的隧道，同时附属 ENI eth1 还有个虚拟的 ipvl_8eth1 网卡。全景剖析阿里云容器网络数据链路117通过 OS Linux Routing 我们可以看到，所有目的是 Pod IP 的流量都会被转发到 Pod对应的 ipvl_x 虚拟往卡上，这样就建立完毕 ECS 和 Pod 之间的连接隧道了。全景剖析阿里云容器网络数据链路118小结小结可以访问到目的端nginx-7d6877d777-zp5jg netns eth0 可以抓到数据包。ECS 的 ipvl_8 可以抓到数据包。全景剖析阿里云容器网络数据链路119数据链路转发示意图：数据链路转发示意图：不会经过分配给 pod 的附属网卡；整个链路是通过查找路由表进入 ipvl_xxx 不需要经过 ENI；整个请求链路是 node-ipvl_xxx-ECS1 Pod1；3)3)场景二：访问场景二：访问 PodPod IPIP，同节点，同节点 podpod 间互访（间互访（podpod 属于同属于同 ENIENI）环境环境cn-hongkong.10.0.3.15 节点上存在 nginx-7d6877d777-j7dqz 和全景剖析阿里云容器网络数据链路120centos-6c48766848-znkl8 两个 pod，IP 分别为 10.0.3.38 和 10.0.3.5。通过此节点的 terwayPod，我们可以利用 terway-cli show factory 的命令看到 这两个 IP（10.0.3.5 和 10.0.3.38）都属于同一个 MAC 地址 00:16:3e:04:08:3a，说明这两个 IP 属于同一个 ENI，进而可以推断出 nginx-7d6877d777-j7dqz 和centos-6c48766848-znkl8 属于同一个 ENI 网卡。内核路由内核路由centos-6c48766848-znkl8 IP 地址 10.0.3.5，该容器在宿主机表现的 PID 是 2747933，该容器网络命名空间有指向容器 eth0 的默认路由。有且只有一条，说明 pod 访问所有地址都需要通过该默认路由。nginx-7d6877d777-j7dqz IP 地址 10.0.3.38。该容器在宿主机表现的 PID 是 329470，该容器网络命名空间有指向容器 eth0 的默认路由。全景剖析阿里云容器网络数据链路121该容器 eth0 在 ECS OS 内是通过 ipvlan 隧道的方式和 ECS 的附属 ENI eth1 建立的隧道，同时附属 ENI eth1 还有个虚拟的 ipvl_8eth1 网卡。全景剖析阿里云容器网络数据链路122小结小结可以访问到目的端centos-6c48766848-znkl8 netns eth0 可以抓到数据包。nginx-7d6877d777-zp5jg netns eth0 可以抓到数据包。全景剖析阿里云容器网络数据链路123ipvl_8 网卡并没有捕获到相关的数据流量包。数据链路转发示意图：数据链路转发示意图：不会经过分配给 pod 的附属网卡。不会经过任何宿主机 ECS 的网络空间的中间节点；整个链路不会和请求不会经过pod所分配的ENI，直接在OS的ns中命中Ip rule 被转发到对端 pod；整个请求链路是 ECS1 Pod1-ECS1 Pod2（发生在 ECS 内部），和 IPVS 相比，避免了 calico 网卡设备的两次转发，性能是更好的；全景剖析阿里云容器网络数据链路1244)4)场景三：访问场景三：访问 PodPod IPIP，同节点，同节点 podpod 间互访（间互访（podpod 属于不同属于不同 ENIENI）环境环境cn-hongkong.10.0.3.15 节点上存在 nginx-7d6877d777-j7dqz 和busybox-d55494495-8t677 两个 pod，IP 分别为 10.0.3.38 和 10.0.3.22。通过此节点的 terwayPod，我们可以利用 terway-cli show factory 的命令看到 这两个 IP（10.0.3.22 和 10.0.3.38）都属于同一个 MAC 地址 00:16:3e:01:b7:bd 和 00:16:3e:04:08:3a，说明这两个 IP 属于不同 ENI，进而可以推断出 nginx-7d6877d777-j7dqz 和 busybox-d55494495-8t677 属于不同 ENI 网卡。内核路由内核路由busybox-d55494495-8t677 IP 地址 10.0.3.22，该容器在宿主机表现的 PID 是2956974，该容器网络命名空间有指向容器 eth0 的默认路由。有且只有一条，说明 pod访问所有地址都需要通过该默认路由。全景剖析阿里云容器网络数据链路125nginx-7d6877d777-j7dqz IP 地址 10.0.3.38。该容器在宿主机表现的 PID 是 329470，该容器网络命名空间有指向容器 eth0 的默认路由。该容器 eth0 在 ECS OS 内是通过 ipvlan 隧道的方式和 ECS 的附属 ENI eth1 建立的隧道，通过 mac 地址一样可以看到，nginx-7d6877d777-j7dqz和busybox-d55494495-8t677 分别被分配eth1和eth2。全景剖析阿里云容器网络数据链路126小结小结可以访问到目的端busybox-d55494495-8t677 netns eth0 可以抓到数据包。nginx-7d6877d777-zp5jg netns eth0 可以抓到数据包。全景剖析阿里云容器网络数据链路127数据链路转发示意图：数据链路转发示意图：不会经过分配给 pod 的附属网卡。不会经过任何宿主机 ECS 的网络空间的中间节点；整个链路是需要从客户端 pod 所属的 ENI 网卡出 ECS 再从目的 POD 所属的 ENI网卡进入 ECS；整个请求链路是 ECS1 Pod1-ECS1 eth1-VPC-ECS1 eth2-ECS1 Pod2；5)5)场景四：不同节点间场景四：不同节点间 PodPod 之间互访之间互访环境环境cn-hongkong.10.0.3.15 节点上存在 nginx-7d6877d777-j7dqz，IP 分为 10.0.3.38。全景剖析阿里云容器网络数据链路128cn-hongkong.10.0.3.93 节点上存在 centos-6c48766848-dz8hz，IP 分为10.0.3.127。通过此节点的 terwayPod，我们可以利用 terway-cli show factory 的命令看到nginx-7d6877d777-j7dqz IP 10.0.3.5 属于cn-hongkong.10.0.3.15 上的MAC地址为 00:16:3e:04:08:3a 的 ENI 网卡。通过此节点的 terwayPod，我们可以利用 terway-cli show factory 的命令看到centos-6c48766848-dz8hz IP10.0.3.127 属于 cn-hongkong.10.0.3.93 上的MAC 地址为 00:16:3e:02:20:f5 的 ENI 网卡。内核路由内核路由centos-6c48766848-dz8hz IP 地址 10.0.3.127，该容器在宿主机表现的 PID 是1720370，该容器网络命名空间有指向容器 eth0 的默认路由。有且只有一条，说明 pod访问所有地址都需要通过该默认路由。全景剖析阿里云容器网络数据链路129nginx-7d6877d777-j7dqz IP 地址 10.0.3.38。该容器在宿主机表现的 PID 是 329470，该容器网络命名空间有指向容器 eth0 的默认路由。ECS OS 内是通过 ipvlan 隧道的方式和 ECS 的附属 ENI eth1 建立的隧道，通过 mac地址一样可以看到两个 pod 分配的 ENI 地址 centos-6c48766848-dz8hz。全景剖析阿里云容器网络数据链路130nginx-7d6877d777-j7dqz全景剖析阿里云容器网络数据链路131小结小结可以访问到目的端此处不再对抓包进行展示，从客户端角度，数据流可以在 centos-6c48766848-dz8hz的网络命名空间 eth0，以及 此 pod 所部署的 ECS 对应的 ENI eth1 上可以被捕获到；从服务端角度，数据流可以在 nginx-7d6877d777-j7dqz 的网络命名空间 eth0，以及此 pod 所部署的 ECS 对应的 ENI eth1 上可以被捕获到。数据链路转发示意图：数据链路转发示意图：不会经过任何宿主机 ECS 的网络空间的中间节点；整个链路是需要从客户端 pod 所属的 ENI 网卡出 ECS 再从目的 POD 所属的 ENI网卡进入 ECS；整个请求链路是 ECS1 Pod1-ECS1 ethx-VPC-ECS2 ethy-ECS2 Pod2；全景剖析阿里云容器网络数据链路1326)6)场景五：集群内场景五：集群内 PodPod 访问的访问的 SVCSVC ClusterIPClusterIP（含（含 TerwayTerway 版本版本 1.2.01.2.0，访问访问 ExternalIPExternalIP），SVCSVC 后端后端 PodPod 和客户端和客户端 PodPod 配属同一个配属同一个 ENIENI环境环境cn-hongkong.10.0.3.15 节点上存在 nginx-7d6877d777-j7dqz 和centos-6c48766848-znkl8 两个 pod，IP 分别为 10.0.3.38 和 10.0.3.5。通过此节点的 terwayPod，我们可以利用 terway-cli show factory 的命令看到 这两个 IP（10.0.3.5 和 10.0.3.38）都属于同一个 MAC 地址 00:16:3e:04:08:3a，说明这两个 IP 属于同一个 ENI，进而可以推断出 nginx-7d6877d777-j7dqz 和centos-6c48766848-znkl8 属于同一个 ENI 网卡。通过 describe svc 可以看到 nginxPod 被加入到了 svc nginx 的后端。SVC 的CLusterIP 是 192.168.27.242。如果是集群内访问 External IP，对于 Terway 版本1.20 来说，集群内访问 SVC 的 ClusterIP 或 External IP，整个链路架构是一致的，此小节不在针对 External IP 单独说明，统一用 ClusterIP 作为示例（Terway 版本 1.20情况下，访问 External IP，会在后续小节说明）。全景剖析阿里云容器网络数据链路133内核路由内核路由centos-6c48766848-znkl8 IP 地址 10.0.3.5，该容器在宿主机表现的 PID 是 2747933，该容器网络命名空间有指向容器 eth0 的默认路由。有且只有一条，说明 pod 访问所有地址都需要通过该默认路由。nginx-7d6877d777-j7dqz IP 地址 10.0.3.38。该容器在宿主机表现的 PID 是 329470，该容器网络命名空间有指向容器 eth0 的默认路由。全景剖析阿里云容器网络数据链路134在 ACK 中，是利用 cilium 去调用 ebpf 的能力，可以通过下面的命令可以看到nginx-7d6877d777-j7dqz 和 centos-6c48766848-znkl8 identity ID 分别是 634 和1592。通过 centos-6c48766848-znkl8Pod，可以找到此 pod 所在的 ECS 的 TerwayPod 为terway-eniip-6cfv9，在 TerwayPod 中运行下面的 cilium bpf lb list|grep-A5192.168.27.242 命令可以看到 ebpf 中对于 CLusterIP 192.168.27.242:80 记录的后端是 10.0.3.38:80。这上述的一切都是通过 EBPF 记录到了源端 Podcentos-6c48766848-znkl8Pod 的 tc 中。全景剖析阿里云容器网络数据链路135通过以上，可以理论推断出，如果集群内的 pod 访问 SVC 的 CLusterIP or External IP地址（Terway 1.20），数据流会在 pod 的网络命名空间内就被转化为相应的 SVC 的后端 Pod IP 后，再被从 Pod 网络命名空间的 eth0 发出 pod，进入到 pod 所在的 ECS，然后通过 IPVLAN 隧道，转发到同 ECS 或通过相应的 ENI 出 ECS。也就是说，我们如果抓包，不管在 pod 内抓包还是在 ECS 抓包，都无法捕获到 SVC 的 IP，只能捕获到 PodIP。EBPF 技术让集群内访问避开了 ECS OS 内部的内核协议栈和减少了部分 pod 内核协议栈，大大提高了网络性能和 Pod 密度，带来了不弱于单独 ENI 的网络性能，但是此方式会对我们观测带来巨大的改变和影响。试想一下，如果您的集群内存在互相调用情况，这个调用的 IP 是 SVC 的 IP，加入此SVC 后端所引用的 Pod 有几十上百个。源端 pod 调用时候出现问题，一般情况下报错是connect to failed 等类似信息，传统的抓包手段是在源端 Pod 内，目的Pod，ECS 上等进行抓包，筛选 SVC IP 来串起来不同包之间的同一个数据流，可是 ebpf情况下由于上述技术实现，造成无法捕获 SVC IP，是不是对偶发抖动情况下的观测带来了巨大挑战呢？小结小结可以访问到目的端从客户端 Pod centos-6c48766848-znkl8 访问 SVC，我们可以看到访问成功。全景剖析阿里云容器网络数据链路136客户端的 centos-6c48766848-znkl8 网络命名空间内 eth0 抓包，抓包地址是目的SVC 的 IP 和 SVC 的后端 POD IP。可以看到只能抓到 SVC 后端 Pod IP，无法捕获到 SVCIP。全景剖析阿里云容器网络数据链路137目的端 SVC 的后端 POD nginx-7d6877d777-zp5jg 网络命名空间 eth0 抓包，抓包地址是目的 SVC 的 IP 和 Pod IP。可以看到只能抓到客户端 Pod IP。cilium 提供了一个 monitor 的功能，我们使用 cilium monitor-related-to，可以看到，源端 POD IP 访问 SVCIP 192.168.27.242，之后被解析到SVC 的后端 POD IP 10.0.3.38。说明 SVC IP 直接在 tc 层做了转发，这也解释了为什么抓包无法抓到 SVC IP，因为抓包是在 netdev 上抓的，此时已经过了协议栈和 tc。后续小节如果涉及 SVC IP 的访问，如有类似，不再做详细的抓包展示。全景剖析阿里云容器网络数据链路138数据链路转发示意图：数据链路转发示意图：不会经过任何宿主机 ECS 的网络空间的中间节点；整个链路不会和请求不会经过pod所分配的ENI，直接在OS的ns中命中Ip rule 被转发到对端 pod；整个请求链路是 ECS1 Pod1-ECS1 Pod2（发生在 ECS 内部），和 IPVS 相比，避免了 calico 网卡设备的两次转发，性能是更好的；ECS1 Pod1 的 eth0 网卡无法捕捉到 SVC IP，SVC IP 在 Pod 网络命名空间内已经通过 ebpf 转换成了 SVC 后端 Pod 的 IP；8)场景六：集群内场景六：集群内 PodPod 访问的访问的 SVCSVC ClusterIPClusterIP（含（含 TerwayTerway 版本版本 1.2.01.2.0，访访问问 ExternalIPExternalIP），SVSVC C 后后端端 PoPod d 和客户和客户端端 PoPod d 配属不配属不同同 ENIENI（同同 ECSECS）环境环境全景剖析阿里云容器网络数据链路139cn-hongkong.10.0.3.15 节点上存在 nginx-7d6877d777-j7dqz 和busybox-d55494495-8t677 两个 pod，IP 分别为 10.0.3.38 和 10.0.3.22。通过此节点的 terwayPod，我们可以利用 terway-cli show factory 的命令看到 这两个 IP（10.0.3.22 和 10.0.3.38）都属于同一个 MAC 地址 00:16:3e:01:b7:bd 和00:16:3e:04:08:3a，说明这两个 IP 属于不同 ENI，进而可以推断出nginx-7d6877d777-j7dqz 和 busybox-d55494495-8t677 属于不同 ENI 网卡。通过describe svc 可以看到 nginxPod 被加入到了 svc nginx 的后端。SVC 的 CLusterIP 是 192.168.27.242。如果是集群内访问 External IP，对于 Terway版本 1.20 来说，集群内访问 SVC 的 ClusterIP 或 External IP，整个链路架构是一致的，此小节不在针对 External IP 单独说明，统一用 ClusterIP 作为示例（Terway 版本 1.20 情况下，访问 External IP，会在后续小节说明）。全景剖析阿里云容器网络数据链路140内核路由内核路由busybox-d55494495-8t677 IP 地址 10.0.3.22，该容器在宿主机表现的 PID 是2956974，该容器网络命名空间有指向容器 eth0 的默认路由。有且只有一条，说明 pod访问所有地址都需要通过该默认路由。全景剖析阿里云容器网络数据链路141nginx-7d6877d777-j7dqz IP 地址 10.0.3.38。该容器在宿主机表现的 PID 是 329470，该容器网络命名空间有指向容器 eth0 的默认路由。在 ACK 中，是利用 cilium 去调用 ebpf 的能力，可以通过下面的命令可以看到nginx-7d6877d777-j7dqz 和busybox-d55494495-8t677 identity ID 分别是634和3681。全景剖析阿里云容器网络数据链路142通过 busybox-d55494495-8t677Pod，可以找到此 pod 所在的 ECS 的 TerwayPod为 terway-eniip-6cfv9，在 TerwayPod 中运行下面的 cilium bpf lb list|grep-A5192.168.27.242 命令可以看到 ebpf 中对于 CLusterIP 192.168.27.242:80 记录的后端是 10.0.3.38:80。这上述的一切都是通过 EBPF 记录到了源端 Podcentos-6c48766848-znkl8Pod 的 tc 中。这里不再过多对于 svc ClusterIP 的 ebpf 转发进行描述，详细信息可以参考 2.5 小节。中的描述，从上述描述情况，可以得知被访问的 SVC 的 IP 在 客户端 busybox 的网络命名空间中已经被 ebpf 转为 svc 的后端 pod 的 IP，在任何 dev 上都无法捕获到客户端访问的 SVC 的 IP。故此场景和 2.3 小节的网络架构非常类似，只是在客户端内会由cilium ebpf 转发的动作。全景剖析阿里云容器网络数据链路143小结小结数据链路转发示意图：数据链路转发示意图：不会经过任何宿主机 ECS 的网络空间的中间节点；整个链路是需要从客户端 pod 所属的 ENI 网卡出 ECS 再从目的 POD 所属的 ENI网卡进入 ECS；整个请求链路是 ECS1 Pod1-ECS1 eth1-VPC-ECS1 eth2-ECS1 Pod2；在客户端/服务端 Pod 内或者 ECS 的 ENI 网卡都无法捕捉到 SVC IP，SVC IP 在 客户端 Pod 网络命名空间内已经通过 ebpf 转换成了 SVC 后端 Pod 的 IP；8)8)场景七：集群内场景七：集群内 PodPod 访问的访问的 SVCSVC ClusterIPClusterIP，SVCSVC 后端后端 PodPod 和客户和客户端端PodPod 不属于不同不属于不同 ECSECS环境环境全景剖析阿里云容器网络数据链路144cn-hongkong.10.0.3.15 节点上存在 nginx-7d6877d777-j7dqz，IP 分为 10.0.3.38。cn-hongkong.10.0.3.93 节点上存在 centos-6c48766848-dz8hz，IP 分为10.0.3.127。通过此节点的 terwayPod，我们可以利用 terway-cli show factory 的命令看到nginx-7d6877d777-j7dqz IP 10.0.3.5 属于cn-hongkong.10.0.3.15 上的MAC地址为 00:16:3e:04:08:3a 的 ENI 网卡。通过此节点的 terwayPod，我们可以利用 terway-cli show factory 的命令看到centos-6c48766848-dz8hz IP10.0.3.127 属于 cn-hongkong.10.0.3.93 上的MAC 地址为 00:16:3e:02:20:f5 的 ENI 网卡。通过 describe svc 可以看到 nginxPod 被加入到了 svc nginx 的后端。SVC 的CLusterIP 是 192.168.27.242。如果是集群内访问 External IP，对于 Terway 版本1.20 来说，集群内访问 SVC 的 ClusterIP 或 External IP，整个链路架构是一致的，此小节不在针对 External IP 单独说明，统一用 ClusterIP 作为示例（Terway 版本 1.20情况下，访问 External IP，会在后续小节说明）。全景剖析阿里云容器网络数据链路145内核路由内核路由Pod 访问 SVC 的 Cluster IP，而 SVC 的后端 Pod 和 Pod 部署在不同 ECS 上，此架构类似 2.4 小节中的不同 ECS 节点上的 Pod 间互访情况，只不此场景是 Pod 访问 SVC 的ClusterIP，要注意此处是访问 ClusterIP，如果是访问 External IP，那么场景会进一步复杂了，本门的后面几个小节会详细说明。对于 ClusterIP 的 ebpf 转发进行描述，详细信息可以参考 2.5 小节。中的描述，和前面几个小节一样，在任何 dev 上都无法捕获到客户端访问的 SVC 的 IP。小结小结数据链路转发数据链路转发示意图：示意图：全景剖析阿里云容器网络数据链路146不会经过任何宿主机 ECS 的网络空间的中间节点；整个链路是需要从客户端 pod 所属的 ENI 网卡出 ECS 再从目的 POD 所属的 ENI网卡进入 ECS；整个请求链路是 ECS1 Pod1-ECS1 eth1-VPC-ECS2 eth1-ECS2 Pod2；在客户端/服务端 Pod 内或者 ECS 的 ENI 网卡都无法捕捉到 SVC IP，SVC IP 在 客户端 Pod 网络命名空间内已经通过 ebpf 转换成了 SVC 后端 Pod 的 IP；9 9）场景八场景八：集群内集群内 PodPod 访问的访问的 SVCSVC ExternalIPExternalIP（TerwayTerway 版本版本 1.2.01.2.0），SVCSVC 后端后端 PodPod 和客户端和客户端 PodPod 配属同一个配属同一个 ENIENI环境环境此处环境和2.5 小节 情况类似，不做过多描述，只是此小节是在terway 版本小于1.2.0情况下，访问 External IP 47.243.139.183。全景剖析阿里云容器网络数据链路147内核路由内核路由请参考 2.5 小节。由于客户端 Pod 和被访问的 SVC 的后端 Pod 同属于同一个 ENI，那么在 terway 版本小于 1.2.0 的情况下，访问 External IP，实际上数据链路会通过 ENI 出 ECS 到 ExternalIP 的 SLB，在被转发到同一个 ENI 上。四层 SLB 目前是不支持同一个 EI 同时作为客户端和服务端，所以会形成回环，详细信息可以参考下面连接：https:/ ECS1 Pod1-ECS1 eth1-VPC-SLB-中断；Terway 版本小于 1.2.0 时，集群内访问 external IP，会出 ECS ENI 到 SLB，再由SLB 转发到 ECS ENI 上，如果源 pod 所属的 ENI 和被转发的 ENI 为同一个，将访问不成功，原因是四层 SLB 会形成回环；解决方案（任何一个）：通过 SVC annotation 将 SLB 配置为 7 层监听；将 Terway 版本升级之 1.2.0 以及上，并开启集群内负载均衡。Kube-Proxy 会短路集群内访问 ExternalIP、LoadBalancer 的流量，即集群内访问这些外部地址，实际流量不会到外部，而会被转为对应后端的 Endpoint 直接访问。在 TerwayIPvlan 模式下，Pod 访问这些地址流量由 Cilium 而不是 kube-proxy 进行处理，在 Terway v1.2.0 之前版本并不支持这种链路的短路。在 Terway v1.2.0 版本发布后，新建集群将默认开启该功能，已创建的集群不会开启。（此处就是 2.5 小节场景）；https:/ PodPod 访问的访问的 SVCSVC ExternalIPExternalIP（TerwayTerway 版本版本 1.2.01.2.0），SVCSVC 后端后端 PodPod 和客户端和客户端 PodPod 配属不同配属不同 ENIENI（同（同 ECSECS）环境环境此处环境和2.6 小节 情况类似，不做过多描述，只是此小节是在terway 版本小于1.2.0情况下，访问 External IP 47.243.139.183。全景剖析阿里云容器网络数据链路149内核路由内核路由请参考 2.6 和 2.8 小节。由于客户端 Pod 和被访问的 SVC 的后端 Pod 虽然同属于同一个 ECS，但是不属于同一个 ENI，那么在 terway 版本小于 1.2.0 的情况下，访问 External IP，实际上数据链路会通过客户端 pod ENI 出 ECS 到 External IP 的 SLB，在被转发到另一个一个 ENI 上。虽然从外部感知上看 两个客户端 Pod 和 SVC 的后端 Pod 都是在同一个 ECS，但是由于属于不同 ENI，所以不会形成回环，可以访问成功，此处的结果和 2.8 小节完全不同，需要注意。小结小结数据链路转发示意图：整个请求链路是 ECS1 Pod1-ECS1 eth1-VPC-SLB-ECS1 eth2-ECS1Pod2；Terway 版本小于 1.2.0 时，集群内访问 external IP，会出 ECS ENI 到 SLB，再由SLB 转发到 ECS ENI 上，如果源 pod 所属的 ENI 和被转发的 ENI 为同一个，将访问不成功，原因是四层 SLB 会形成回环；如果源 pod 所属的 ENI 和被转发的 ENI 为是同一个节点上的不同 ENI，可以访问成功；全景剖析阿里云容器网络数据链路1501111）场景十场景十：集群内集群内 PodPod 访问的访问的 SVCSVC ExternalIPExternalIP（TerwayTerway 版本版本 1.2.01.2.0），SVCSVC 后端后端 PodPod 和客户端和客户端 PodPod 部署于不同部署于不同 ECSECS环境环境此处环境和2.6 小节 情况类似，不做过多描述，只是此小节是在terway 版本小于1.2.0情况下，访问 External IP 47.243.139.183。内核路由内核路由请参考 2.7 和 2.9 小节。此处和 2.7 的架构场景相似，都是客户端 Pod 和 SVC 的后端 Pod 不属于不同的 ECS 节点，客户端去访问 SVC 的 External IP。只有 Terway 的版本不同，2.7 小节 Terway 版本是1.2.0，此小节是1.2.0，仅仅是 Terway 版本和 eniconfig 的不同，两者访问链路一个会经过 SLB，一个则不会经过 SLB，这一点需要关注。置于不同的原因是因为1.2.0 Terway 版本之后开启集群内负载均衡，对于访问 ExternalIP 会被负载到Service 网段，具体信息请见 2.8 小节。全景剖析阿里云容器网络数据链路151小结小结数据链路转发示意图：数据链路转发示意图：整个请求链路是 ECS1 Pod1-ECS1 eth1-VPC-SLB-ECS2 eth1-ECS2Pod2；Terway 版本小于 1.2.0 时，集群内访问 external IP，会出 ECS ENI 到 SLB，再由SLB 转发到 ECS ENI 上，如果源 pod 所属的 ENI 和被转发的 ENI 为同一个，将访问不成功，原因是四层 SLB 会形成回环；1212）场景十一：集群外访问场景十一：集群外访问 SVCSVC ExternalIPExternalIP环境环境cn-hongkong.10.0.3.15 节点上存在 nginx-7d6877d777-j7dqz，IP 分为 10.0.3.34通过 describe svc 可以看到 nginxPod 被加入到了 svc nginx 的后端。SVC 的CLusterIP 是 192.168.27.242。全景剖析阿里云容器网络数据链路152内核路由内核路由在 SLB 控制台，可以看到 lb-j6cj07oi6uc705nsc1q4m 虚拟服务器组的后端服务器组是两个后端 nginxPod 的的 ENI eni-j6cgs979ky3evp81j3n8。从集群外部角度看，SLB 的后端虚拟服务器组是 SVC 的后端 Pod 所属的 ENI 网卡，内网的 IP 地址就是 Pod 的地址。全景剖析阿里云容器网络数据链路153小结小结数据链路转发示意图：数据链路转发示意图：ExternalTrafficPolicy 为 Local 或 Cluster 模式下，SLB 只会将 Pod 分配的 ENI挂在到 SLB 的虚拟服务器组；数据链路：client-SLB-Pod ENI Pod Port-ECS1 Pod1 eth0；13)13)小结小结本篇文章主要聚焦 ACK 在 Terway IPVLAN EBPF 模式下，不同 SOP 场景下的数据链路转发路径。伴随着客户对性能的极致追求的需求，在 Terway IPVLAN EBPF 相比Terway ENI，有更高的 Pod 密度；相比 Terway ENIIP，有更高的性能，但因此也带了网络链路的复杂性和可观测性带来了调整，此场景可以分为 11 个 SOP 场景，并对这11 个场景的转发链路，技术实现原理，云产品配置等一一梳理并总结，这对我们遇到Terway IPVLAN 架构下的链路抖动、最优化配置，链路原理等提供了初步指引方向。在 Terway IPVLAN 模式下，利用 EBPF 和 IPVLAN 隧道，避免了数据链路在 ECS OS 内核协议栈的转发，这必然带来了更高的性能，同时也有 ENIIP 模式一样的多 IP 共享 ENI的方式来保证 Pod 密度。但是随着业务场景越来越趋于复杂，业务的 ACL 管控也更加全景剖析阿里云容器网络数据链路154趋于 Pod 维度去管理，比如需要针对 Pod 维度进行安全 ACL 规则设置的需求等。下一系列我们将进入到 Terway ENI-Trunking 模式的全景解析。5.Terway ENI-Trunking 模式架构设计弹性网卡中继 Trunk ENI 是一种可以绑定到专有网络 VPC 类型 ECS 实例上的虚拟网卡。相比弹性网卡 ENI，Trunk ENI 的实例资源密度明显提升。启用 Terway Trunk ENI 功能后，指定的 Pod 将使用 Trunk ENI 资源。为 Pod 开启自定义配置是可选功能，默认情况下创建的 Pod，未开启 Terway Trunk ENI 功能，使用的是共享 ENI 上的 IP 地址。只有当您主动声明为指定 Pod 开启自定义配置后，相应的 Pod 才能使用 Pod 自定义配置能力，Terway 才可以同时使用共享 ENI 以及 Trunk ENI 为 Pod 分配 IP。两种模式共享节点最大 Pod 数量配额，总部署密度和开启前一致。金融、电信，政府等行业对数据信息安全有着非常严格的数据安全要求，通常，重要的核心数据会放在自建的机房内，并且对访问此数据的客户端有严格的白名单控制，通常会限制具体的 IP 访问源。业务架构上云时，往往是通过专线，VPN 等打通自建机房和云上资源打通，由于传统容器中 PodIP 是不固定的，NetworkPolicy 只能在集群内生效，这对客户的白名单设置有了非常大的挑战。ENI 在 Trunk 模式下，可以配置独立的安全组、vSwitch 能力，带来更为细化的网络配置能力，提供极具竞争力的容器网络解决方案。全景剖析阿里云容器网络数据链路155在 trunking 的命名空间内可以看到相关的 pod 信息和节点信息，其中 pod 应用的 IP的网络我们稍后会详细说明。全景剖析阿里云容器网络数据链路156Pod 内有只有指向 eth0 的默认路由，说明说明 PodPod 访问任何地址段都是从访问任何地址段都是从 eth0eth0 为统一的为统一的出入口。出入口。那么 Pod 是如何 ECS OS 进行通信呢？在 OS 层面，我们一看到 calicxxxx 的网卡，可以看到是附属于 eth1 的，对于节点和 Pod 的通信连接，这个类似于Terway ENIIP 模式架构群内非 SVC 后端 pod 所在节点访问 SVC ClusterIP。通过 OS Linux Routing我们可以看到，所有目的是 Pod IP 的流量都会被转发到 Pod 对应的 calico 虚拟往卡上，到这里为止，ECS OS 和 Pod 的网络命名空间已经建立好完整的出入链路配置了。让我们把目光聚焦 ENI Trunking 本身。ENI Truning 是如何实现 Pod 的交换机和安全组的配置呢？Terway 增加一种名为 PodNetworking 的自定义资源来描述网络配置。您可以创建多个 PodNetworking，来规划不同网络平面。创建 PodNetworking 资源后，Terway 将同步网络配置信息，只有 status 成为 Ready全景剖析阿里云容器网络数据链路157后，该网络资源才能对 Pod 生效。如下图所示，类型为 Elastic，只要 namespce 的标签的符合 tryunking：zoneb，就给 pod 使用指定的安全组和交换机。创建 Pod 时，Pod 将通过标签去匹配 PodNetworking。如果 Pod 没有匹配到任何PodNetworking，则 Pod 将使用默认的共享 ENI 上的 IP。如果 Pod 有匹配到PodNetworking，则将使用 PodNetworking 中定义的配置分配 ENI。关于 Pod 标签的相关内容，请参见标签。Terway 会为这类 Pod 创建相应的名为 PodENI 的自定义资源，用于跟踪 Pod 所使用的资源，该资源由 Terway 管理，您不可修改该资源。如下 trunking 命名空间下的centos-59cdc5c9c4-l5vf9Pod 匹配了相应的 podnetworking 设置，被分配了相应的memeber ENI、对应的 Trunking ENI，安全组，交换机和被绑定的 ECS 实例，这样就实现了 Pod 维度的交换机，安全组的配置和管理。全景剖析阿里云容器网络数据链路158通过 ECS 的控制台，我们也可以清楚的看到 memenber ENI 和 Trunking ENI 之间的关系，相应的安全组交换机等等信息。通过上面的配置，我们了解如何去给每个 Pod 单独配置交换机，安全组等信息，让每个 pod 在通过 Trunking ENI 出 ECS 后，可以自动走到对应的配置 Member ENI 上，全景剖析阿里云容器网络数据链路159让这些配置生效。那么所有的配置其实落到宿主机上都是通过相关的策略实现的，Trunking ENi 网卡是如何知道把对应 Pod 的流量转发到正确的对应的 Member ENI 上的呢？这其实通过的 vlan 来实现的。在 tc 层面可以看到 VLAN ID。所以在 egress 或者 ingress 的阶段会打上或者去除 VLAN ID。、故 Terway ENI-Trunking 模式总体可以归纳为：弹性网卡中继 Trunk ENI 是一种可以绑定到专有网络 VPC 类型 ECS 实例上的虚拟网卡。相比弹性网卡 ENI，Trunk ENI 的实例资源密度明显提升Terway Trunk ENI 支持为每个 Pod 配置固定 IP、独立的虚拟交换机、安全组，能提供精细化流量管理、流量隔离、网络策略配置和 IP 管理能力。使用 Terway 插件，您需要选择较高规格和较新类型的 ECS 神龙机型，即 5 代或者6 代的 8 核以上机型，且机型要支持 Trunk ENI。更多信息，请参见实例规格族。单节点所支持的最大 Pod 数取决于该节点的弹性网卡（ENI）数。共享 ENI 支持的最大 Pod 数=（ECS 支持的 ENI 数-1）单个 ENI 支持的私有 IP 数。Pod 安全组规则不会应用到同节点 Pod 间流量及同节点上节点与 Pod 间流量。如果您需要限制，可以通过 NetworkPolicy 进行配置。Pod 和对应 MemeberENI 流量对应是通过 VLAN ID 来实现的。1)1)TerwayTerway ENI-TrunkingENI-Trunking 模式容器网络数据链路剖析模式容器网络数据链路剖析可以看到由于可以实现 Pod 维度的安全组，交换机设置，那么宏观上不同链路访问必然更加趋于复杂，我们可以将 Terway ENI-TRunking 模式下的网络链路大体分为以Pod IP 对外提供服务和以 SVC 对外提供服务两个大的 SOP 场景，进一步细分，可以归全景剖析阿里云容器网络数据链路160纳为 10 个不同的小的 SOP 场景。对这 11 个场景的数据链路梳理合并，这些场景可以归纳为下面 10 类典型的场景：通节点访问 Pod（相同 or 不同安全组）；同节点同安全组 TrunkPod 互访（含访问 SVC IP，源端和 svc 后端部署在同一节点）；同节点不同安全组 TrunkPod 互访（含访问 SVC IP，源端和 svc 后端部署在同一节点）；不同节点同安全组 TrunkPod 互访；不同节点不同安全组 TrunkPod 互访；集群内源端访问 SVC IP（源端和 SVC 后端不同节点，相同安全组，含 Local 模式访问 external IP）；集群内源端访问 SVC IP（源端和 SVC 后端不同节点，不同安全组，含 Local 模式访问 external IP）；Cluster 模式下，集群内源端访问 SVC ExternalIP（源端和 SVC 后端不同节点，不同安全组）；Cluster 模式下，集群内源端访问 SVC ExternalIP（源端和 SVC 后端不同节点，相同安全组）；全景剖析阿里云容器网络数据链路161集群外访问 SVC IP；2 2)场景一：通节点访问场景一：通节点访问 PodPod（相同（相同 oror 不同安全组）不同安全组）环境环境cn-hongkong.10.0.4.22 节点上存在 nginx-6f545cb57c-kt7r8 和 10.0.4.30。内核路由内核路由nginx-6f545cb57c-kt7r8 IP 地址 10.0.4.30，该容器在宿主机表现的 PID 是 1734171，该容器网络命名空间有指向容器 eth0 的默认路由。该容器 eth0 在 ECS OS 内是通过 ipvlan 隧道的方式和 ECS 的附属 ENI eth1 建立的隧道，同时附属 ENI eth1 还有个虚拟的 calxxx 网卡。全景剖析阿里云容器网络数据链路162在 ECS OS 内，有指向 Pod IP，下一跳为为 calixxxx 的路由，通过前文可以知道 calixxx网卡是和每个 pod 内的 veth1 组成的 pair，所以，pod 内访问 SVC 的 CIDR 会有指向veth1 的路由，不会走默认的 eth0 路由。故：calixx 网卡在这里的主要作用是用于：节点访问 Pod；当节点或者 Pod 访问 SVC 的 CIDR 时，会走 ECS OS 内核协议栈转换，走到 calixxx和 veth1 访问 pod；trunking 命名空间下的nginx-6f545cb57c-kt7r8 Pod匹配了相应的podnetworking设置，被分配了相应的 memeber ENI、对应的 Trunking ENI，安全组，交换机和被绑定的 ECS 实例，这样就实现了 Pod 维度的交换机，安全组的配置和管理。全景剖析阿里云容器网络数据链路163在 tc 层面可以看到 VLAN ID 1027，所以数据流量在 egress 或者 ingress 的阶段会打上或者去除 VLAN ID。ENI 的网卡所属的安全组可以看到只允许了指定的 IP 可以访问 nginxPod 的 80 端口。全景剖析阿里云容器网络数据链路164置于数据面流量在 OS 层面的流量转发逻辑，这个类似于Terway ENIIP 模式架构群内非 SVC 后端 pod 所在节点访问 SVC ClusterIP，不在这里做过多的叙述。小结小结可以访问到目的端数据链路转发示意图：数据链路转发示意图：全景剖析阿里云容器网络数据链路165会经过calicao网卡，每个非hostnetwork的pod会和calicao网卡形成veth pair，用于和其他 pod 或 node 进行通信；整个链路不会和请求不会经过pod所分配的ENI，直接在OS的ns中命中Ip rule 被转发 1；整个请求链路是 ECS1 OS-calixxxx-ECS1 Pod1；因为是通过 os 内核 routing 转发，不经过 member eni，所以安全组不生效，此链路与 pod 所属的 member eni 的安全组无关；3)3)场景二场景二：同节点同安全组同节点同安全组 TrunkPodTrunkPod 互访互访（含访问含访问 SVCSVC IPIP，源端和源端和 svsvc c后端部署在同一节点）后端部署在同一节点）环境环境cn-hongkong.10.0.4.22 节点上存在 nginx-6f545cb57c-kt7r8，10.0.4.30 和busybox-87ff8bd74-g8zs7，10.0.4.24。内核路由内核路由nginx-6f545cb57c-kt7r8 IP 地址 10.0.4.30，该容器在宿主机表现的 PID 是 1734171，该容器网络命名空间有指向容器 eth0 的默认路由。全景剖析阿里云容器网络数据链路166该容器 eth0 在 ECS OS 内是通过 ipvlan 隧道的方式和 ECS 的附属 ENI eth1 建立的隧道，同时附属 ENI eth1 还有个虚拟的 calixxxx 网卡。在 ECS OS 内，有指向 Pod IP，下一跳为为 calixxxx 的路由，通过前文可以知道 calixxx网卡是和每个 pod 内的 veth1 组成的 pair，所以，pod 内访问 SVC 的 CIDR 会有指向veth1 的路由，不会走默认的 eth0 路由。故 calixx 网卡在这里的主要作用是用于：节点访问 Pod；当节点或者 Pod 访问 SVC 的 CIDR 时，会走 ECS OS 内核协议栈转换，走到 calixxx和 veth1 访问 pod；全景剖析阿里云容器网络数据链路167trunking 命名空间下的 busybox-87ff8bd74-g8zs7 和 nginx-6f545cb57c-kt7r8Pod 匹配了相应的 podnetworking 设置，被分配了相应的 memeber ENI、对应的Trunking ENI，安全组，交换机和被绑定的 ECS 实例，这样就实现了 Pod 维度的交换机，安全组的配置和管理。全景剖析阿里云容器网络数据链路168在 tc 层面可以看到 VLAN ID 1027，所以数据流量在 egress 或者 ingress 的阶段会打上或者去除 VLAN ID。ENI 的网卡所属的安全组可以看到只允许了指定的 IP 可以访问 nginxPod 的 80 端口。全景剖析阿里云容器网络数据链路169置于数据面流量在 OS 层面的流量转发逻辑，这个类似于Terway ENIIP 模式架构群内非 SVC 后端 pod 所在节点访问 SVC ClusterIP，不在这里做过多的叙述。小结小结可以访问到目的端数据链路转发示意图：数据链路转发示意图：会经过calicao网卡，每个非hostnetwork的pod会和calicao网卡形成veth pair，用于和其他 pod 或 node 进行通信；整个链路不会和请求不会经过pod所分配的ENI，直接在OS的ns中命中Ip rule 被转发；整个请求链路是 ECS1 Pod1 eth0-cali1xxxxxx-cali2xxxxxx-ECS1 Pod2eth0；pod 属于同 or 不同 ENI，链路请求是一致的，不经过 ENI；全景剖析阿里云容器网络数据链路170因为是通过 os 内核 routing 转发，不经过 member eni，所以安全组不生效，此链路与 pod 所属的 member eni 的安全组无关；访问 Pod IP 和访问 SVC IP（external ipor clusterip）的区别是:访问 SVC IP，SVC会在源端 pod eth0 和 calixxx 网卡捕捉到，在目的端 pod 的 eth0 和 calixxx 时捕捉不到；4 4)场景三：同节点不同安全组场景三：同节点不同安全组 TrunkPodTrunkPod 互访（含访问互访（含访问 SVCSVC IPIP，源端，源端和和svcsvc 后端部署在同一节点）后端部署在同一节点）环境环境cn-hongkong.10.0.4.244 节点上存在 nginx-96bb9b7bb-wwrdm，10.0.5.35 和centos-648f9999bc-nxb6l，10.0.5.18。内核路由内核路由相关的 Pod 的容器网络命名空间，路由等不在进行过多描述，详情可以见前面两小节。通过 podeni 可以看到 centos-648f9999bc-nxb6l 所分配的 ENI，安全组 sg，交换机vsw 等。全景剖析阿里云容器网络数据链路171通过安全组 sg-j6ccrxxxx 可以看到 centos 的 pod 可以访问外部所有的地址。同理，可以查看出服务端 Pod 的 nginx-96bb9b7bb-wwrdm 的安全组sg-j6ccrze8utxxxxx 是只允许 192.168.0.0/16 可以访问。全景剖析阿里云容器网络数据链路172小结小结可以访问到目的端数据链路转发示意图：数据链路转发示意图：会经过calicao网卡，每个非hostnetwork的pod会和calicao网卡形成veth pair，用于和其他 pod 或 node 进行通信；整个链路不会和请求不会经过pod所分配的ENI，直接在OS的ns中命中Ip rule 被转发；整个请求链路是 ECS1 Pod1 eth0-cali1xxxxxx-cali2xxxxxx-ECS1 Pod2eth0；pod 属于同 or 不同 ENI，链路请求是一致的，不经过 ENI；全景剖析阿里云容器网络数据链路173因为是通过 os 内核 routing 转发，不经过 member eni，所以安全组不生效，此链路与 pod 所属的 member eni 的安全组无关；访问 Pod IP 和访问 SVC IP（external ipor clusterip）的区别是:访问 SVC IP，SVC会在源端 pod eth0 和 calixxx 网卡捕捉到，在目的端 pod 的 eth0 和 calixxx 时捕捉不到；5)5)场景四：不同节点同安全组场景四：不同节点同安全组 TrunkPodTrunkPod 互访互访环境环境cn-hongkong.10.0.4.20 节点上存在客户端 centos-59cdc5c9c4-l5vf9 和 IP10.0.4.27。cn-hongkong.10.0.4.22 节点上存在服务端 nginx-6f545cb57c-kt7r8 和 IP10.0.4.30。内核路由内核路由相关的 Pod 的容器网络命名空间，路由等不在进行过多描述，详情可以见前面两小节。通过 podeni 可以看到 centos-59cdc5c9c4-l5vf9 所分配的 ENI，安全组 sg，交换机vsw 等。通过安全组 sg-j6cf3sxrlbuwxxxxx 可以看到 centos 和 nginx 的的 pod 属于同一个安全组 sg-j6cf3sxrlbuxxxxx。全景剖析阿里云容器网络数据链路174全景剖析阿里云容器网络数据链路175小结小结是否可以访问取决于安全组配置数据链路转发示意图：数据链路转发示意图：会经过calicao网卡，每个非hostnetwork的pod会和calicao网卡形成veth pair，用于和其他 pod 或 node 进行通信；整个链路不会和请求不会经过pod所分配的ENI，直接在OS的ns中命中Ip rule 被转发；出 ECS 后，根据要访问的 pod 和该 pod ENI 所属 vswitch，命中 VPC 路由规则或者直接 VSW 上的二层转发；整 个 请 求 链 路 是 ECS1 Pod1 eth0-cali1xxx Trunk eni(ECS1)-Pod1member eni-vpc route rule(如有)-Pod2 member eni-Trunk eni(ECS2)cali2 xxx-ECS2 Pod1 eth0；因为是通过 os 内核 routing 转发，经过 member eni，因为 member eni 属于同一个安全组，所以安全组内默认是互通的；全景剖析阿里云容器网络数据链路1766)6)场景五：不同节点不同安全组场景五：不同节点不同安全组 TrunkPodTrunkPod 互访互访环境环境cn-hongkong.10.0.4.20 节点上存在客户端 centos-59cdc5c9c4-l5vf9 和 IP10.0.4.27。cn-hongkong.10.0.4.244 节点上存在服务端 nginx-96bb9b7bb-wwrdm 和 IP10.0.5.35。内核路由内核路由相关的 Pod 的容器网络命名空间，路由等不在进行过多描述，详情可以见前面两小节。通过 podeni 可以看到 centos-59cdc5c9c4-l5vf9 所分配的 ENI，安全组 sg，交换机vsw 等。通过安全组 sg-j6cf3sxrlbuwxxxxx 可以看到centos的 pod可以访问外部所有的地址。全景剖析阿里云容器网络数据链路177同理，可以查看出服务端 Pod 的 nginx-96bb9b7bb-wwrdm 的安全组sg-j6ccrze8utxxxxx 是只允许 192.168.0.0/16 可以访问。全景剖析阿里云容器网络数据链路178小结小结是否可以访问取决于安全组配置数据链路转发示意图：数据链路转发示意图：会经过calicao网卡，每个非hostnetwork的pod会和calicao网卡形成veth pair，用于和其他 pod 或 node 进行通信；整个链路不会和请求不会经过pod所分配的ENI，直接在OS的ns中命中Ip rule 被转发；整 个 请 求 链 路 是 ECS1 Pod1 eth0-cali1xxx Trunk eni(ECS1)-Pod1member eni-vpc route rule(如有)-Pod2 member eni-Trunk eni(ECS2)cali2 xxx-ECS2 Pod1 eth0；因为是通过 os 内核 routing 转发，流量会经过 member eni，是否可以访问成功，安全组配置对此有着决定性的作用；全景剖析阿里云容器网络数据链路1797)7)场景六：集群内源端访问场景六：集群内源端访问 SVCSVC IPIP（源端和（源端和 SVCSVC 后端不同节点，相同安后端不同节点，相同安全组，含全组，含 LocalLocal 模式访问模式访问 externalexternal IPIP）环境环境cn-hongkong.10.0.4.20 节点上存在客户端 centos-59cdc5c9c4-l5vf9 和 IP10.0.4.27。cn-hongkong.10.0.4.22 节点上存在服务端 nginx-6f545cb57c-kt7r8 和 IP10.0.4.30。nginx 的 svc 的 ClusterIP 是 192.168.81.92 External IP 是 8.210.162.178。内核路由内核路由ENI-Trunking 相比较 ENIIP 来说，只是在 VPC 侧增加了对应的 Truning 和 MemberENI，在 OS 内并无区别，此处可以参考 Terway ENIIP 模式架构 群内非 SVC 后端 pod所在节点访问 SVC ClusterIP。全景剖析阿里云容器网络数据链路180小结小结是否可以访问取决于安全组配置数据链路转发示意图：数据链路转发示意图：会经过calicao网卡，每个非hostnetwork的pod会和calicao网卡形成veth pair，用于和其他 pod 或 node 进行通信；整个链路不会和请求不会经过pod所分配的ENI，直接在OS的ns中命中Ip rule 被转发；出 ECS 后，根据要访问的 pod 和该 pod ENI 所属 vswitch，命中 VPC 路由规则或者直接 VSW 上的二层转发；整个请求链路是：去方向：ECS1 Pod1 eth0-cali1xxx ECS eth0-Pod1 member eni-vpcroute rule(如有)-Pod2 member eni-Trunk eni(ECS2)cali2 xxx-ECS2Pod1 eth0；回方向：ECS2 Pod1 eth0-Trunk eni(ECS2)cali2 xxx-Pod2 member eni-vpc route rule(如 有)-Pod1 member eni-Trunk eni(ECS1)-cali1xxx-ECS1 Pod1 eth0；全景剖析阿里云容器网络数据链路181经过 ipvs 规则 fnat 转化，数据包是以源 pod IP 从 ECS eth0 出，请求目的 pod IP。（访问 SVC clusterIP，以及 Local 模式下访问 External IP）；这个经过的 ENI 有 ECS1 的 eth0，Pod1 member eni，Pod2 member eni。所以这三个网卡的安全组的配置都会影响数据链路的连通性；8)8)场景七：集群内源端访问场景七：集群内源端访问 SVCSVC IPIP（源端和（源端和 SVCSVC 后端不同节点，不同安后端不同节点，不同安全组，含全组，含 LocalLocal 模式访问模式访问 externalexternal IPIP）环境环境cn-hongkong.10.0.4.20 节点上存在客户端 centos-59cdc5c9c4-l5vf9 和 IP10.0.4.27。cn-hongkong.10.0.4.244 节点上存在服务端 nginx-96bb9b7bb-wwrdm 和 IP10.0.5.35。nginx 的 svc 的 ClusterIP 是 192.168.31.83 External IP 是 47.243.87.204。内核路由内核路由ENI-Trunking 相比较 ENIIP 来说，只是在 VPC 侧增加了对应的 Truning 和 MemberENI，在 OS 内并无区别，此处可以参考Terway ENIIP 模式架构Cluster 模式，集群内非 SVC 后端 pod 所在节点访问 SVC External IP。全景剖析阿里云容器网络数据链路182小结小结是否可以访问取决于安全组配置数据链路转发示意图：数据链路转发示意图：会经过calicao网卡，每个非hostnetwork的pod会和calicao网卡形成veth pair，用于和其他 pod 或 node 进行通信；整个链路不会和请求不会经过pod所分配的ENI，直接在OS的ns中命中Ip rule 被转发；出 ECS 后，根据要访问的 pod 和该 pod ENI 所属 vswitch，命中 VPC 路由规则或者直接 VSW 上的二层转发；整个请求链路是：去方向：ECS1 Pod1 eth0-cali1xxx ECS eth0-Pod1 member eni-vpcroute rule(如有)-Pod2 member eni-Trunk eni(ECS2)cali2 xxx-ECS2Pod1 eth0；全景剖析阿里云容器网络数据链路183回方向：ECS2 Pod1 eth0-Trunk eni(ECS2)cali2 xxx-Pod2 member eni-vpc route rule(如 有)-Pod1 member eni-Trunk eni(ECS1)-cali1xxx-ECS1 Pod1 eth0；经过 ipvs 规则 fnat 转化，数据包是以源 pod IP 从 ECS eth0 出，请求目的 pod IP。（访问 SVC clusterIP，以及 Local 模式下访问 External IP）；这个经过的 ENI 有 ECS1 的 eth0，Pod1 member eni，Pod2 member eni。所以这三个网卡的安全组的配置都会影响数据链路的连通性。需要保证安全组互相放通Pod 和 ECS 的响应 IP；9)9)场景八场景八：ClusterCluster 模式下模式下，集群内源端访问集群内源端访问 SVCSVC ExternalIPExternalIP（源端和源端和 SVSVC C后端不同节点，不同安全组）后端不同节点，不同安全组）环境环境全景剖析阿里云容器网络数据链路184cn-hongkong.10.0.4.20 节点上存在客户端 centos-59cdc5c9c4-l5vf9 和 IP10.0.4.27。cn-hongkong.10.0.4.244 节点上存在服务端 nginx-96bb9b7bb-wwrdm 和 IP10.0.5.35。nginx 的 svc 的 ClusterIP 是 192.168.31.83 External IP 是 47.243.87.204,ExternalTrafficPolicy 是 Cluster 模式。内核路由内核路由ENI-Trunking 相比较 ENIIP 来说，只是在 VPC 侧增加了对应的 Truning 和 MemberENI，在 OS 内并无区别，此处可以参考Terway ENIIP 模式架构。小结小结是否可以访问取决于安全组配置数据链路转发示意图：数据链路转发示意图：会经过calicao网卡，每个非hostnetwork的pod会和calicao网卡形成veth pair，用于和其他 pod 或 node 进行通信；全景剖析阿里云容器网络数据链路185整个链路不会和请求不会经过pod所分配的ENI，直接在OS的ns中命中Ip rule 被转发；出 ECS 后，根据要访问的 pod 和该 pod ENI 所属 vswitch，命中 VPC 路由规则或者直接 VSW 上的二层转发；整个请求链路是 ECS1 Pod1 eth0-cali1xxx ECS eth0-vpc route rule(如有)-Pod2 member eni-Trunk eni(ECS2)cali2 xxx-ECS2 Pod1 eth0；经过 ipvs 规则 fnat 转化，数据包是以源 pod IP 从 ECS eth0 出，请求目的 pod IP。（访问 SVC clusterIP，以及 Local 模式下访问 External IP）；这个经过的 ENI 有 ECS1 的 eth0，Pod2 member eni。所以这两个网卡的安全组的配置都会影响数据链路的连通性。需要保证安全组互相放通 Pod 和 ECS 的响应IP；10)10)场景九：场景九：ClusterCluster 模式下，集群内源端访问模式下，集群内源端访问 SVCSVC ExternalIPExternalIP（源端（源端和和SVCSVC 后端不同节点，相同安全组）后端不同节点，相同安全组）环境环境全景剖析阿里云容器网络数据链路186cn-hongkong.10.0.4.20 节点上存在客户端 centos-59cdc5c9c4-l5vf9 和 IP10.0.4.27。cn-hongkong.10.0.4.22 节点上存在服务端 nginx-6f545cb57c-kt7r8 和 IP10.0.4.30。nginx 的 svc 的 ClusterIP 是 192.168.81.92 External IP 是 8.210.162.178ExternalTrafficPolicy 为 Cluster。内核路由内核路由ENI-Trunking 相比较 ENIIP 来说，只是在 VPC 侧增加了对应的 Truning 和 MemberENI，在 OS 内并无区别，此处可以参考Terway ENIIP 模式架构Cluster 模式，集群内非 SVC 后端 pod 所在节点访问 SVC External IP。全景剖析阿里云容器网络数据链路187小结小结是否可以访问取决于安全组配置数据链路转发示意图：数据链路转发示意图：会经过calicao网卡，每个非hostnetwork的pod会和calicao网卡形成veth pair，用于和其他 pod 或 node 进行通信；整个链路不会和请求不会经过pod所分配的ENI，直接在OS的ns中命中Ip rule 被转发；出 ECS 后，根据要访问的 pod 和该 pod ENI 所属 vswitch，命中 VPC 路由规则或者直接 VSW 上的二层转发；整个请求链路是 ECS1 Pod1 eth0-cali1xxx ECS eth0-vpc route rule(如有)-Pod2 member eni-Trunk eni(ECS2)cali2 xxx-ECS2 Pod1 eth0；经过 ipvs 规则 fnat 转化，数据包是以源 pod IP 从 ECS eth0 出，请求目的 pod IP。（访问 SVC clusterIP，以及 Local 模式下访问 External IP）；这个经过的 ENI 有 ECS1 的 eth0，Pod2 member eni。所以这两个网卡的安全组的配置都会影响数据链路的连通性。需要保证安全组互相放通 Pod 和 ECS 的响应全景剖析阿里云容器网络数据链路188IP；11)11)场景十：集群外访问场景十：集群外访问 SVCSVC IPIP环境环境cn-hongkong.10.0.4.20 节点上存在客户端 centos-59cdc5c9c4-l5vf9 和 IP10.0.4.27。cn-hongkong.10.0.4.22 节点上存在服务端 nginx-6f545cb57c-kt7r8 和 IP10.0.4.30。nginx 的 svc 的 ClusterIP 是 192.168.81.92 External IP 是 8.210.162.178ExternalTrafficPolicy 为 Cluster。SLBSLB 相关配置相关配置在 SLB 控制台，可以看到 lb-j6cmv8aaojf7nqdai2a6a 虚拟服务器组的后端服务器组是两个后端 nginxPod 的的 ENI eni-j6cgrqqrtvcwhhcyuc28,全景剖析阿里云容器网络数据链路189eni-j6c54tyfku5855euh3db 和 eni-j6cf7e4qnfx22mmvblj0，这几个 ENI 都是member ENI。小结小结是否可以访问取决于安全组配置数据链路转发示意图：数据链路转发示意图：会经过calicao网卡，每个非hostnetwork的pod会和calicao网卡形成veth pair，用于和其他 pod 或 node 进行通信；数据链路：client-SLB-Pod Member ENI Pod Port-Trunking ENI-ECS1Pod1 eth0；全景剖析阿里云容器网络数据链路190ExternalTrafficPolicy 为Local或Cluster模式下，SLB只会将Pod分配的memberENI 挂在到 SLB 的虚拟服务器组；SLB 转发请求只会转发到目标 member ENI 上，然后通过 vlan 发送到 Trunk ENI，再由 Trunk ENI 转发到 Pod；6.ASM Istio 模式架构近几年，企业基础设施云原生化的趋势越来越强烈，从最开始的 IaaS 化到现在的微服务化，客户的颗粒度精细化和可观测性的需求更加强烈。容器网络为了满足客户更高性能和更高的密度，也一直在高速的发展和演进中，这必然对客户对云原生网络的可观测性带来了极高的门槛和挑战。为了提高云原生网络的可观测性，同时便于客户和前后线同学增加对业务链路的可读性，ACK 产研和 AES 联合共建，合作开发 ack net-exporter 和云原生网络数据面可观测性系列，帮助客户和前后线同学了解云原生网络架构体系，简化对云原生网络的可观测性的门槛，优化客户运维和售后同学处理疑难问题的体验，提高云原生网络的链路的稳定性。图:服务网格示例全景剖析阿里云容器网络数据链路191图 Istio 数据面示意图Kubernetes 的横空出现打破了底层服务器、底层网络等计算资源的界限，给业务的灵活部署、快速恢复、弹性伸缩，资源效率最大化带来了无限可能。但是业务场景的贪婪是无限的，随着微服务趋势大肆发展，业务上对于同一个 service，不同版本版本和流量控制有着更精细化的颗粒度的需求，最好能实现 Pod 维度的流量控制，可观测性等等。这些在 kubernetes 上是无法实现的：从流量角度，k8s 最小的控制维度是 service，其他比如金丝雀 等发布，借助各种ingress controller 或者其他组件实现，并且这些也无法实现 Pod 之间的流量和连接状态的可观测性。k8s 给服务微型化，小型化创造了条件，如果前后端服务存在调用关心，他们如果使用共享通信库，则会在开发阶段就要求所有微服务使用相同的逻辑语言和堆栈，这从某种程度上又大大限制微服务的独立化，无法实现完全的漠不关心将原来集成在同一个 ECS 上的服务拆分成不同的模块，这些模块之间调用涉及跨ECS 等，那么必然需要在代码开发阶段需要考虑超时，重试，连接失败等逻辑机制，全景剖析阿里云容器网络数据链路192而这些与微服务最核心的服务应用其实没有太大关系，但是开发工作往往耗费大量的经历在逻辑设计上。那么，有没有办法实现上述和微服务的业务完全隔离呢？Istio 的出现给这个带来了相对完美的解决方案，让应用这和开发者更加关注业务本身的开发迭代。Istio 利用了 k8s的 Pod 概念，会根据使用者的配置，在每个被注入的 Pod 部署时，自动注入 istio-proxy容器和 initial 容器。Initial 容器的目的是通过修改 Pod 单独网络命名空间的 iptables 规则，让需要代理的流量进入到 istio-proxy 监听的端口，istio-proxy 监听出入 两个端口，根据网格配置，来实现对出入流量的代理实现和干预。而被同一个 istio 注入的载体，都被视为同一个服务网格之内，他们之间的调用已经脱离了 service 的层面，会命中相关的 istio cluster配置的 endpoint，这样我们就可以实现 Pod 维度的流量管理、观测性、安全性等配置。1)PodPod 注入注入ASM 默认提供了一个 Webhook 控制器，可以将 Sidecar 代理自动添加到可用的 Pod中。通过下面的命令可以看到 ASM 注入的集群有个 istio-sidecar-injector-1-15-3 的mutatingwebhookconfiguration，查看 webhook 内容，可以看到其中一条就是有istio-inject：enabled 标签的 namespace里的 pod 创建时候会自动注入。除了命名空间维度，还有 Pod 维度，其他注解方式等多种维度实现 K8s 集群是否被加入到 Istio 服务网格中。为了充分利用服务网格的所有特性，服务网格中 ACK 集群的应用 Pod 必须包含一个 Sidecar 代理。除了手动注入方式外，通常建议启用自动注入的方式来简化部署，ASM 已经实现了注入配置的可视化操作，具体请见多种方式灵活开启自动注入。全景剖析阿里云容器网络数据链路1932)PodPod 流量转发流量转发通过 describe 被注入的 Pod，可以发现 Pod 中除了设置好的业务 container，还多出两个容器：istio-proxy 和 init container：istio-init。这两个容器的镜像是一样的，只是运行的命令的不一样，这样的好处是只需要拉取一份镜像，节省了拉取镜像的时间。全景剖析阿里云容器网络数据链路1943)3)InitInit ContainerContainerInit container 利用的是 k8s 的特性，一种具有特权的特殊容器，在 Pod 内的应用容器启动之前运行。Init 容器可以包括一些应用镜像中不存在的实用工具和安装脚本。每个Pod 中可以包含多个容器和多个 Init 容器。他与普通容器很像，但是有自己独特点：多个 init 容器是串行运行的。也就是说多个 init 容器会依序运行，等上一个 init 容器运行完毕结束后，才会开始运行下一个容器。只有等到所有的 init 容器全部运行结束退出后，业务容器才开始启动，在这之前，pod 不会处于 ready。如果 Pod 的 Init 容器失败，kubelet 根据 pod 设置的 restartPolicy 进行相应的action。既然现在了解了 Init container 的作用，那我们来看一下 istio-init 在启动的过程中做了全景剖析阿里云容器网络数据链路195哪些事情，可以通过下面的命令：kubectl logs-n istio-inject productpage-v1-797d845774-dndmk-c istio-init。全景剖析阿里云容器网络数据链路196可以看到 istio-init 在启动过程中进行了一连串的 iptables 规则的生成和配置，比如出方向转发到 15001 端口；入方向转发到 15006 端口；访问 15008 端口，直接 return不进行流量劫持等等。那有什么办法可以自定义配置么？查看 pod 的信息可以看到相关配置的启动参数，也就通过相关规则实现了出入流量重定向到设置的端口。-p:所有出方向的流量被 iptables 重定向到 15001 端口-z:所有入方向的流量被 iptables 重定向到 15006 端口-u:用于排除用户 ID 为 1337，可以视为 envoy 应用本身使用 UID 1337-m:流量重定向模式，“REDIRECT”或“TPROXY”-i:重定向出方向的地址范围，“*”表示重定向所有出站流量。-x:指将从重定向出方向中排除的 IP 地址范围-b:重定向入站端口列表-d:重定向入站端口中排除的端口列表全景剖析阿里云容器网络数据链路197我们从 Pod 的视角去观察，将 Pod 视为一个整体，里面有 istio-proxy 容器和业务容器APP container。入方向流量转发入方向流量转发根据上文的 iptables 规则，我们可以归纳出被入方向代理转发的端口，比如 80 等，在Pod 的 网 络 命 名 空 间 netfilter 模 块 经 过 流 程 是 Client-RREROUTING-ISTIO_INBOUND-ISTIO_IN_REDIRECT-INPUT-Envoy 15006（Inbound）-OUTPUT-ISTIO_OUTPUT-POSTROUTING-APP。这样就实现了入方向流量先被转发到 sidecar 容器后，在转发到业务容器的监听端口。其中在步骤 5 和 6 之间，流全景剖析阿里云容器网络数据链路198量会按照设置好的 istio 规则进行处理。出方向流量转发出方向流量转发根据上文的 iptables 规则，我们可以归纳出被入方向代理转发的端口，比如 80 等，在Pod 的网络命名空间 netfilter 模块经过流程是 APP OUTPUT-ISTIO_OUTPUT-ISTIO_REDIRECT-Envoy 15001（Outbound）-OUTPUT-ISTIO_OUTPUT-POSTROUTING-DST。这样就实现了出方向流量先被转发到 sidecar 容器后，在转发到目的监听端口。其中在步骤 d 和 e 之间，流量会按照设置好的 istio 规则进行处理。全景剖析阿里云容器网络数据链路199入方向流量免转发入方向流量免转发对于入方向的某些端口或者自定义端口，我们不需要它经过 sidecar 容器，iptables 规则会设置将符合条件的入方向流量避免转发到 15006 端口，直接转发到业务容器监听端口 RREROUTING-ISTIO_INBOUND-INPUT-APP。全景剖析阿里云容器网络数据链路200出方向流量免转发出方向流量免转发对于出方向的某些端口或者自定义端口，我们不需要它经过 sidecar 容器，iptables 规则会设置将符合条件的入方向流量避免转发到 15001 端口，直接离开 Pod 的网络命名空间 APP-OUTPUT-ISTIO_OUTPUT-POSTROUTING-DST。全景剖析阿里云容器网络数据链路2014)4)Istio-proxyIstio-proxy可以看到 15001 和 15006 被 envoy 应用所监听，而 envoy 应用就是 istio-proxy 容器程序。Init 容器启动的时候根据所设置的参数中指定将出入站流量重定向到 Envoy的模式为“REDIRECT”或者“TPROXY”。使用 REDIRECT 方式，一旦 Pod 注入了 Sidecar 代理之后，所有入站流量都是从 Envoy重定向，Envoy 将流量发送到绑定了本地地址（127.0.0.1）的应用程序，所以应用看不到真正的原始 IP。在服务网格环境下如何保持服务访问时的客户端源 IP 呢？可以使用 TPROXY 模式，目前 ASM 已经支持了 TPROXY 模式，具体详情请见https:/ TPROXY 模式下，Pod 的网络命名空间的 iptables 会有 mangle 配置。ADSADS 聚合服务发现聚合服务发现全景剖析阿里云容器网络数据链路202我们已经知道了服务网格会在每个注入的 Pod 内注入两个容器：istio-init 和istio-proxy。一旦在网格控制面进行相关配置的修改，会通过 pilot 下发到每个istio-proxy 容器去生效。而 istio 是通过 xDS 服务接口去实现相关配置的动态下发的，其中 xDS 包含了 LDS（Listener Discover Service）、CDS（Cluster Discover Service）、EDS（Endpoint Discovery Service）和 RDS（Route Discover Service）。一般情况下，在更新配置过程中应该先更新 Cluster-之后 CLuster 的 Endpoint 开始更新-开始更新 Cluster 和 Endpoint 相对应的 Listener-Route 开始更新新配置的Listener 信息-最后删除不在使用 Cluster 和 Endpoint 以保证更新过程中流量无损。但是这些 xDS 接口是相互独立，所以在配置下发的时候，存在某些依赖关系的 DS 因配置生效前后关系造成了部分流量被丢弃，这在某些生产环境中是无法接受的。为了保证数据面配置的一致性，服务网格利用 gRPC 流来进行 ADS 聚合发现服务，通过一个 gRPC 流来保证各个 xDS 接口的调用顺序，避免各个接口独立性造成数据配置的不匹配。详细信息可以参考：https:/www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocolenvoy-rev.jsonenvoy-rev.json可以看到 istio-proxy 启动了 pilot-agent 程序，pilot-agent 作为父进程启动了子进程/usr/local/bin/envoy。其中/etc/istio/proxy/envoy-rev.json 是 envoy 初始化的配置文件。Node包含了 istio-proxy 所在节点，当前 Pod，istio 版本、ACK 集群 ID、ASM 版本、必要端口等相关信息。全景剖析阿里云容器网络数据链路203administio-proxy 相关日志，管理端口等信息。dynamic_resourcesADS 相关配置信息，比如 api 协议，版本，超时时间等。全景剖析阿里云容器网络数据链路204static_resources包含了 prometheus_stats、agent、sds-grpc、xds-grpc 和 zipkin 五个 cluster 和一个在15090上监听的listener，xds-grpc cluster对应前面dynamic_resources中ADS配置。prometheus_stats cluster 和 15090 用于对外提供 prometheus 采集端口。zipkin cluster 是外部的 zipkin 服务器调用地址。全景剖析阿里云容器网络数据链路205tracing分布式链路跟踪，这里的 collector_cluster 是前面 static_resources 里面定义的 zipkincluster。访问日志分析访问日志分析通过前文，我们已经知道两个互相被注入的 pod 访问，流量会被各自的 istio-proxy 所劫持并处理，那么只要分析客户端和服务端的 istio-proxy 日志并进行加工，就可以对流量进行可观测性解读。我们在这里还是以官方例子来举例。访问 http:/productpage，productpage 应用会自动调用 details 服务，reviews 服务。我们以 productpage 和details 之间链路来进行举例分析。productpage-v1-797d845774-dndmk IP 是 10.0.1.130，details 应用的 svc 的名称是 details，svc 地址是 192.168.1.125，svc 端口是 9080。请求发送方 productpage-v1-797d845774-dndmk 的 istio-proxy 日志upstream_host:10.0.1.127:9080,downstream_remote_address:10.0.1.130:49586,downstream_local_address:192.168.1.125:9080,duration:6,upstream_cluster:outbound|9080|details.istio-inject.svc.cluster.local,path:/details/0,protocol:HTTP/1.1,upstream_local_address:10.0.1.130:50026,method:GET,user_agent:Mozilla/全景剖析阿里云容器网络数据链路2065.0(Windows NT 10.0;Win64;x64)AppleWebKit/537.36(KHTML,like Gecko)Chrome/109.0.0.0Safari/537.36,route_name:default,request_id:834147c2-435f-94a7-af11-8491df9ab4f8,start_time:2023-01-31T14:23:20.603Z,upstream_transport_failure_reason:null,upstream_service_time:5,response_flags:-,bytes_received:0,authority_for:details:9080,authority:details:9080,requested_server_name:null,istio_policy_status:null,trace_id:9712c9f3da936a8c927f227bfe536c16,response_code:200,x_forwarded_for:null,bytes_sent:178请求接受方 details-v1-6758dd9d8d-dtbdc 的 istio-proxy 日志。x_forwarded_for:null,start_time:2023-01-31T14:23:20.608Z,method:GET,response_flags:-,route_name:default,istio_policy_status:null,requested_server_name:outbound_.9080_._.details.istio-inject.svc.cluster.local,bytes_received:0,request_id:834147c2-435f-94a7-af11-8491df9ab4f8,response_code:200,upstream_host:10.0.1.127:9080,trace_id:9712c9f3da936a8c927f227bfe536c16,downstream_remote_address:10.0.1.130:50026,protocol:HTTP/1.1,bytes_sent:178,upstream_transport_failure_reason:null,downstream_local_address:10.0.1.127:9080,upstream_local_address:127.0.0.6:46225,authority:details:9080,authority_for:details:9080,upstream_service_time:0,upstream_cluster:inbound|9080|,duration:1,path:/details/0,user_agent:Mozilla/5.0(Windows NT 10.0;Win64;x64)AppleWebKit/537.36(KHTML,like Gecko)Chrome/109.0.0.0Safari/537.36日志内容解读upstream_host:10.0.1.127:9080,对于 outbound，此是上游某个Endpoint 的地址和端口；downstream_remote_address:10.0.1.130:49586,对于 outbound，此为本 pod-ip：随机端口 1；downstream_local_address:192.168.1.125:9080,对于 outbound，此为目的 svc-ip：svc-port；duration:6,整个请求时间，单位 ms；upstream_cluster:outbound|9080|details.istio-inject.svc.cluster.local,cluster 信息；path:/details/0；全景剖析阿里云容器网络数据链路207protocol:HTTP/1.1；upstream_local_address:10.0.1.130:50026,对于 outbound，此为本pod-ip：随机端口 2；method:GET；user_agent:Mozilla/5.0(Windows NT 10.0;Win64;x64)AppleWebKit/537.36(KHTML,like Gecko)Chrome/109.0.0.0 Safari/537.36；route_name:default,路由名称；request_id:834147c2-435f-94a7-af11-8491df9ab4f8；start_time:2023-01-31T14:23:20.603Z；upstream_transport_failure_reason:null；upstream_service_time:5,上游返回请求时间，单位 ms；response_flags:-,返回标志，关于连接或返回的详细信息；bytes_received:0；authority_for:details:9080；authority:details:9080；requested_server_name:null；istio_policy_status:null；trace_id:9712c9f3da936a8c927f227bfe536c16,此 ID 为唯一值，可以在上游 istio-proxy 对应；response_code:200,返回状态码；x_forwarded_for:null；bytes_sent:178；日志解读可以详细见官方连接：https:/www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usageUPSTREAM_HOST上游主机的 host，表示从 envoy 发出的请求的目的端。通常来说，对于 outbound cluster，此值是上游 pod-ip:Pod-port，而对于inbound cluster，此值是本 pod-ip:Pod-port。全景剖析阿里云容器网络数据链路208UPSTREAM_LOCAL_ADDRESS上游连接中，当前 envoy 的本地地址。通常来说，对于 outbound cluster，此值是本 pod-ip:随机端口 2，而对于inbound cluster，此值是127.0.0.6:随机端口 3，此处的 127.0.0.6 对应了【1.2Pod 流量转发-Init Container】中的 iptables 会将来自 127.0.0.6 的流量免于 istio 代理，因为这个流量是从 sidecar 本身发出的。DONSTREAM_LOCAL_ADDRESS下游连接中，当前 envoy 的本地地址。通常来说，对于 outbound cluster，此值是 目的 service-ip:service-port，而 对 于inbound cluster，此 值 是 当 前pod-ip:Pod-port，此处和下游的 upstream_host 应该相对应。DOWNSTREAM_REMOTE_ADDRESS通常来说，对于 outbound cluster，此值是当前 pod-ip:随机端口 ，而对于inbound cluster，此 值 是 下 游 pod-ip:随 机 端 口 2 ，此 处 和 下 游 的upstream_local_address 相对应。5 5）EnvoyEnvoy 配置简读（数据链路）配置简读（数据链路）背景背景全景剖析阿里云容器网络数据链路209还是用官方的示例，以 productpage 访问 reviews 服务来举例。通过 Kubernets 集群资源，我们可一看到 reviews 有三个版本 分贝为 v1，v2，v3，Pod 数量各一个。SVC reviews 是 ClusterIP 模式，svc 端口是 9080，targetport 是pod 的 9080 端口，v1，v2，v3 都被加到了 reviews SVC 的 endpointslice。在未被 istio 注入的情况下，集群内 productpagePod 访问 reviews.istio-inject 服务，会被 netfilter 以 round-robin 的方式平均转发到 v1，v2，v3 三个 pod 上，每个 pod全景剖析阿里云容器网络数据链路210应该承受 1/3 的流量。在传统的 k8s 集群中，是无法通过 k8s 的 resource 控制不同版本的流量分配。但是实际的生产环境，我们是有这方面的需求的。比如 v1 版本是线上业务版本，承载了主要业务流量，v2 版本是开发完毕预上线版本，本质上是不希望影响线上流量的，可能需要引流线上流量的 5%到预发版本进行一段时间观察，来判断新版本是否有问题，之后再进一步扩大引流比例直至 100%之后，v1 版本才进行下线，从而实现从业务角度的平滑迁移。或者比如 v3 是测试版本，我们希望观察流量在网络波动超时情况下，业务的自我容灾和恢复情况的行为是否符合预期，以前这种需求需要通过在业务代码中写好熔断代码，不同熔断环境都需要重新发版。那么像这种流量控制在 ASM Istio 就可以很容易的实现。下面就是一个 ASM Istio 中的 vs 和 dr 的配置。apiVersion:networking.istio.io/v1beta1kind:VirtualServicemetadata:creationTimestamp:2023-01-30T06:25:21Zgeneration:1name:reviewsnamespace:istio-injectresourceVersion:651722274uid:63f715c9-b253-4fbb-8351-5313371df14espec:hosts:-reviews.istio-inject.svc.cluster.localhttp:-name:routeroute:-destination:host:reviewssubset:v1weight:10-destination:host:reviewssubset:v2weight:40-destination:host:reviewssubset:v3weight:50全景剖析阿里云容器网络数据链路211其中在 reviews vs 的定义了集群内访问 reviews.istio-inject.svc.cluster.local 是的http 协议的规则。其中指明了 v1 版本权重 10%，v2 版本权重 40%，v3 版本权重 50%apiVersion:networking.istio.io/v1beta1kind:DestinationRulemetadata:creationTimestamp:2023-01-30T06:28:46Zgeneration:2name:reviewsnamespace:istio-injectresourceVersion:654863578uid:fdbdfcea-1fcd-453e-96fb-ce41c91ded9bspec:host:reviewssubsets:-labels:version:v1name:v1-labels:version:v2name:v2-labels:version:v3name:v3trafficPolicy:connectionPool:http:http2MaxRequests:1000maxRequestsPerConnection:10tcp:maxConnections:100outlierDetection:baseEjectionTime:15mconsecutive5xxErrors:7interval:5mreviews dr 的定义了集群内 reviews 的几个版本，并定义了相关流量策略。其中http2MaxRequests 表明 http 最大的请求数。maxRequestsPerConnection 表明每个连接最大的请求数。tcp 最大连接数是 100。在熔断配置中，每隔 5min 中检测一次，连续 7 次 5xx，把后端移除 endpoint 15min。全景剖析阿里云容器网络数据链路212通过前文我们知道 pilot 通过 xDS 接口将服务网格的配置下发到每个被注入的 pod 中的 istio-proxy 中。那么对于每个 pod 中的 istio-proxy，我们是否有办法去查看相关的加载的配置信息呢？istio-proxy 通过 15000 端口对外暴露管理端口，我们可以通过如图所示的命令获取到相关的配置信息。其中可以通过 curl 127.0.0.1:15000/config_dump 可以获取到完整的配置信息，由于此配置信息超过 1 万多行，我们就不在这里做全部的展示。感兴趣的同学可以自行研究下，下文会针对此 config_dump 信息中的 cluster，Listener，endpoint，route 等关键信息做个相关展示和简要说明，同时也和前文的 xDS做个呼应。kubectlexec-nistio-injectproductpage-v1-797d845774-dndmk-cistio-proxy-it-curl 127.0.0.1:15000/config_dumpBootstrapBootstrapEnvoy 的初始化配置，与前文中的 envoy-rev0.json 是一致的。其中drainDuration 热重启期间 Envoy 关闭连接的时间(以秒为单位)，默认是 45s全景剖析阿里云容器网络数据链路213parentShutdownDuration 热重启期间，在完全关闭父进程之前，等到的最大时间，默认 60s。此数值应该大于 drainDuration。terminationDrainDuration 默认 5s。proxy 在关闭之前，允许连接关闭时间。通过前文，我们知道 pod 流量先过 istio 再被转发到业务容器。当应用发版时候，如果保证现有连接优雅关闭，保证 istio-proxy 容器在业务容器完全关闭现有连接后，再退出是发版更新时候需要考虑的问题，此值是实现业务平滑更新需要考虑的。static_resourcesstatic_resourcesconfig_dump 中静态资源，是来自 envoy-rev0.json，里面包含了 prometheus_stats、agent、sds-grpc、xds-grpc 和 zipkin 等配置。全景剖析阿里云容器网络数据链路214dynamic_resourcesdynamic_resources动态资源，是通过 xDS 接口下发到每个 istio-proxy 容器生效的 ASM Istio 的配置。也是上述 reviews dr，vs 配置后通过 ASM 管控侧下发的。我们接下来关注动态资源配置ListenersListenersEnvoy 采用的 listener 来接受到达 Envoy 的流量请求。Listener 和 IP Sock、UnixDomain Socket 绑定，也可以不绑定到具体的端口，而是接收从其他 listener 转发来的流量。ASM Istio 就是利用了 Envoy listener 的这一特性来实现转发给不同的服务请求交给不同的 Listeners 来处理。还是以 productpage 访问 reviews 来举例，productpage 访问的是 reviews 的 9080端口，根据上文我们知道 productpage container 访问 外部的 9080 端口会被先转发到 15001 端口，所以我们先看下 15001 的端口 listeners。全景剖析阿里云容器网络数据链路215VirtualOutboundVirtualOutbound ListenersListenersEnvoy 在 15001 端口创建了 Listeners，所有被 iptables 转发的对外请求都会被转到envoy 的 15001 端口。可以从配置看到，envoy 接受到了流量后，并不会做相关的业务动作，而是根据 use_original_dst:true,这个配置，依据请求的目的端口转发到相应的 listeners 进行处理。全景剖析阿里云容器网络数据链路216那么肯定有个疑问了，如果请求的目的端口并没有配置相关的 listeners 设置，流量该如何进行处理呢？这个取决于 outboundTrafficPolicy 的配置，详情请见https:/istio.io/latest/docs/reference/config/istio.mesh.v1alpha1/#MeshConfig-OutboundTrafficPolicy-ModeNameDescriptionREGISTRY_ONLY只有被注册到服务网格集群内的serviceentry才可以被成功转发出去。如果访问的目的端未被注册到服务网格集群内，请求会被转发到 BlackHoleCLuster，由于找不到匹配的 upstream host，则会被丢弃。ALLOW_ANY无论外部请求是否注册，都可以发送到目的地址。如果目的地址未被 listeners，则会将流量转发到 PassthroughCluster 的 TCPproxy filter，请求将会被发送到原始目的地址。OutboundOutbound ListenersListenersoutbound 监听命名是 0.0.0.0_9080，表明发向任何 IP 地址的 9080 端口都被此监听涵 盖。bind_to_port”:false 此 值 表 明 监 听 没 有 绑 定到 tcp 端 口，流 量 是 有virtualOutbound 转发而来的。那么首先我们需要区别这个监听是为了入方向还是出方向呢？对于入方向，流量会经过15006 端口的 virtualInbound 的 listeners，是不会进入 0.0.0.0_9080 的 listeners。全景剖析阿里云容器网络数据链路217从配置上可以看到 filter 中并没有特殊的志敏筛选条件，说明接受任何流量，其中config_source 为 ads，表明这个是来自动态发现。根据前文可以可看到 revirews,ratings,details 几个 service 都是 9080 端口，这些应用全景剖析阿里云容器网络数据链路218都被同一个服务网格注入，那么 productpage 访问的目的地址的 9080，Envoy 如何刚知道是哪个 service？是如何判断如果目的端口未 9080 的地址不是网格内，该如何处理呢？通过上图route_config_name:9080 可以看到存在一个9080的路由规则，在这个路由规则中规定不同的请求目的地的不同的处理结果，下一小节我们将讨论。RouteRoute前文我们已经知道 productpage 应用访问 reviews 的 9080 端口会被 listenersoutbound 0.0.0.0_9080 路由规则到 9080 的路由。以下是9080 路由的全部信息。我们可以看到一共有 5 个 virtual_hosts，分别是 allow_any、details、productpage、ratings、和 reviews。其中后面 4 个对应 4 个不同 outbound 的 cluster，allow_any对应的是 PassthroughCluster，当出方向请求找到相应的 Cluster 规则时候，会采用默认直接通过。可能有小伙伴很奇怪 productpage 不直接调用 ratings 服务，为什么 productpageenvoy 配置会包含 ratings 的信息。这是因为 ASM Istio 控制面是无法感知到数据面各个服务之间是如何调用的，因此会将所有的配置信息都下发到被注入的 envoy 里面，这样保证了网格配置的一致性，但是随着网格服务配置的增多，每个 envoy 接受和本 envoy 不相关的配置信息就会变多，这样对 envoy 资源使用会有一定影响，如果小伙伴有很好的 envoy 开发能力，并且对业务之间调用非常熟悉，想去除掉本 pod 中 envoy 无关的规则，可以通过 sidecar 规则自定义配置对 egress 和 ingress 进行调整，详情请见：https:/istio.io/latest/docs/reference/config/networking/sidecar/version_info:2023-01-30T06:25:21Z/19,route_config:type: productpage 调用 reviews 来举例，Envoy 会根据 HTTP header 中的 domains 来匹配 VirtualHost 中 domain，所以可以看到 domains 中列举了 reviews的集群内的长短域名，和 svc 的地址。match“/”会路由到三个 cluster outbound|9080|v1|reviews.istio-inject.svc.cluster.local、outbound|9080|v2|reviews.istio-i全景剖析阿里云容器网络数据链路226nject.svc.cluster.local和outbound|9080|v3|reviews.istio-inject.svc.cluster.local，权重分别为 10，40，50，名称是route，看到这里是不是有点熟悉？对的，这和前文 1.3 Envoy 配置简读-背景 中 reviews 的 VS 中的设置，故我们在 vs 中的相关配置信息，最

3人已浏览 2023-03-15 300页 5星级

点击查看更多第一新声：2022年中国高成长企业级SaaS行业研究报告 （60页）.pdf精彩内容。

26人已浏览 2023-03-15 60页 5星级

点击查看更多宝德计算：鲲鹏智慧边缘计算产品在运营商的应用（2022）（18页）.pdf精彩内容。

7人已浏览 2023-03-14 18页 5星级

中国联通云原生安全实践白皮书（2022）中国联通云原生安全实践白皮书（2022）中国联通研究院2022 年 12 月中国联通云原生安全实践白皮书（2022）版版权声明权声明本报告版权属于中国联合网络通信有限公司研究院，并受法律保护。转载、摘编或利用其他方式使用本报告文字或者观点的，应注明“来源：中国联通研究院”。违反上述声明者，本院将追究其相关法律责任。中国联通云原生安全实践白皮书（2022）目 录目 录一、背景概述.3（一）云原生成为新常态.3（二）云原生安全建设需求迫切.41 云原生安全风险升级.42 云原生安全事件频发.4二、云原生安全的发展.6（一）云原生安全理念.6（二）云原生安全典型模型.81 云原生安全防护责任共担模型.82 面向云原生的 ATT&CK 攻防矩阵模型.93 DevSecOps 开发安全运营一体化模型.11三、云原生安全防护体系.13（一）云原生安全原则与架构.131 云原生安全原则.132 云原生安全架构.15（二）云原生基础架构安全.171 网络安全.172 编排及组件安全.183 镜像安全.214 容器运行时安全.24（三）云原生应用安全.261 API 安全.262 微服务架构下的应用安全.283 Serverless 安全.29（四）云原生研发运营安全.331 安全需求分析.332 安全开发.343 安全检测.354 安全运营.37（五）云原生数据安全.40中国联通云原生安全实践白皮书（2022）-4-1 数据安全保护.402 数据安全审计.40（六）云原生安全管理.421 云原生资产统一管理.422 云原生安全事件统一管理.423 多云安全能力协同及统一管理.434 智能化的云原生安全管理.43四、云原生安全防护体系建设实践.45（一）云原生安全防御平台.461 安全编码.472 软件成分分析.483 交互式安全检测.484 应用运行时自保护.49（二）云原生容器安全管理平台.511 资产安全管控.522 安全配置基线核查.523 镜像安全.534 容器运行时安全.55五、云原生安全未来发展趋势及展望.58附录 1 英文缩略语.59附录 2 参考文献.60中国联通云原生安全实践白皮书（2022）-1-前 言云计算的飞速发展和广泛应用，使其已经成为“新基建”中信息基础设施的重要组成部分，并且在企业的数字化转型推进中发挥着重要的支撑作用。同时，云计算改变了传统的 IT 计算环境、网络、应用的整体架构以及存在模式。目前，企业的各项业务都在逐渐实现云化转型，如何在利用云计算为企业发展转型带来便利的同时，有效保证云安全，成为后续发展的重点。因此，云原生安全以其敏捷高效、使用便捷、响应快速、安全融合的特点，在云计算的发展过程中迅速得到推广和使用。云原生安全作为一种新型的安全理念，并不是只解决云原生技术带来的安全问题，而是强调以原生的思维构建云安全体系，推动安全与云计算的深度融合，使整个安全体系覆盖计算环境、软件应用、研发运营、网络、数据以及安全管理等各个方面。企业组织需要秉承云原生安全的理念，构建云原生的安全体系，才能够全面的解决云计算所面临的各类新型安全问题，如网络安全边界模糊、容器逃逸、软件编码风险、开源组件风险、软件运行风险、API 权限滥用、微服务互访难以管控等。本白皮书系统阐述了云计算所面临的新型安全问题，结合云原生安全的发展情况，系统性介绍了云原生安全防护体系，给出了中国联通研究院云原生安全防护体系建设实践，最终对云原生安全的未来发展趋势进行了展望，以期为云原生安全的发展和企业的云原生安全建设提供参考，同时进一步赋能垂直行业的相关技术发展和体系建设。中国联通云原生安全实践白皮书（2022）-2-编写组单位及成员编写组单位及成员：中国联合网络通信有限公司研究院：丁攀、徐雷、郭新海、刘安、蓝鑫冲、王戈、苏俐竹、张曼君、谢泽铖、陆勰、贾宝军、侯乐、陶冶、刘伟中国联合网络通信有限公司广东省分公司：莫俊彬、潘桂新、李文彬、彭健、聂勋坦北京神州绿盟科技有限公司：雷新、浦明、封宏涛北京小佑网络科技有限公司：袁曙光、白黎明、左伟震360 数字安全科技集团有限公司：蒋婉秋杭州默安科技有限公司：程进、王阔阔北京升鑫网络科技有限公司（青藤云安全）：胡俊、李漫厦门服云信息科技有限公司（安全狗）：安晓伟中国联通云原生安全实践白皮书（2022）-3-一、背景概述一、背景概述（一）云原生成为新常态（一）云原生成为新常态云计算自 2006 年提出至今，已经取得了突飞猛进的发展，国内外的云计算规模每年都在飞速的增长和扩大。根据 Gartner 统计结果显示，2021 年以 IaaS、PaaS 和 SaaS 为代表的全球云计算市场规模达到 3307 亿美元，增速 32.5%。据中国信息通信研究院（信通院）的统计结果显示，2021 年中国云计算市场规模达 3229 亿元，较 2020年增长 54.4%。其中公有云市场规模增长 70.8%至 2181 亿元，私有云市场同比增长 28.7%至 1048 亿元。由此可见，在数字化转型加快推进，软件行业快速发展的今天，云计算的地位日显重要，并且已经成为实际意义上的基础设施。随着云计算的发展，云原生作为一种理念也在不断的丰富、落实和实践，并且目前已经渡过了概念普及阶段，进入了快速发展时期。如今在各行各业的数字化业务环境中，以容器、不可变基础设施、微服务、服务网格、声明式 API 等为代表的云原生技术已经被广泛采用。根据信通院调研数据显示，2019 年我国云原生市场规模已达 350.2亿元。2020 年 43.9%的国内用户已在生产环境中采纳容器技术，超过七成的用户已经或计划使用微服务架构进行业务部署。由此可见，云原生技术已经成为云计算实现的新常态。中国联通云原生安全实践白皮书（2022）-4-（二）云原生安全建设需求迫切（二）云原生安全建设需求迫切1 云原生安全风险升级1 云原生安全风险升级云原生技术的使用，彻底改变了云计算的运行环境以及云端应用的设计、开发、部署和运行模式，这些改变为企业的生产和运营带来了极大的便利，提高了工作效率，但是同时也带来了新的安全挑战，使得云原生安全风险全面升级。其中，微服务的使用使网络边界更加模糊化，应用间交互式端口呈指数级增长，而且交互访问关系越来越复杂，传统的边界安全防御不再适用云原生安全架构；容器镜像的使用使得软件供应链的风险更加复杂，在使用镜像部署系统时，极易将安全漏洞、恶意软件和代码引入到生产环境中；独立的开发运营流程以及服务实例应用周期的变短，增加了安全监控和防护的难度，准确的检测网络攻击行为，以及针对 0day 漏洞和开源组件漏洞的检测与防护能力迫切需要提升。2 云原生安全事件频发2 云原生安全事件频发由于云原生技术的广泛使用，伴随的安全事件也逐渐增多。根据RedHat 2022 年发布的关于 Kubernetes 安全调研报告显示，参与调研的 93%的受访者表示其 Kubernetes 环境在过去的一年里至少经历过一次安全事件，55%的受访者表示由于安全原因减缓了应用程序的部署。因此，在云原生环境下，一旦没有实施全面有效的安全防护，黑客即可利用应用漏洞攻击容器上的服务，或可进一步利用容器漏洞，直接访问容器云上的敏感信息，获取服务器特权，从而对容器云进行中国联通云原生安全实践白皮书（2022）-5-修改并最终完全控制服务器，造成恶劣影响和重大损失。近年来云原生安全事件频发，已经严重威胁到了企业的安全。其中比较典型的安全事件包括：攻击团伙 TeamTNT 入侵 Kubernetes集群植入挖矿木马，该事件导致将近 50000 个 IP 被攻击；Docker Hub中存在用于加密货币挖矿攻击活动的恶意镜像文件，这些恶意镜像文件被挖矿软件劫持了至少两年之久，且已被下载了超过 2000 万次，导致大量的企业资源被非法利用；安全公司 Rapid7 遭到 Codecov供应链攻击，进而引发了大量公司连锁数据的泄露，受影响客户达到2.9 万。这些安全事件的发生，无不警示着各企业和组织抓紧推进云原生安全体系的构建。中国联通云原生安全实践白皮书（2022）-6-二、云原生安全的发展二、云原生安全的发展（一）云原生安全理念（一）云原生安全理念云原生安全作为一种新兴的安全理念，它不是单一的技术，而是一簇技术的集合。目前国内外的组织和企业都已经开展了云原生安全的相关研究，但是不同的组织和企业对云原生安全理念的理解不尽相同。云原生计算基金会（Cloud native computing foundation,CNCF）云原生计算基金会（Cloud native computing foundation,CNCF）认为云原生安全是一种将安全构建到云原生应用程序中的方法，安全性是应用程序全生命周期的一部分，旨在确保与传统安全模型相同标准的基础上，同时适应云原生环境的细节，即快速的代码更改和高度短暂的基础设施。KubernetesKubernetes 提出了云原生 4C 安全模型，自下而上分别是云基础设施(Cloud)、集群(Cluster)、容器(Container)和代码(Code)，该模型强调每一层的安全都受益于下层的保护。云原生产业联盟云原生产业联盟针对不同服务模式下的云原生系统，建立了云原生安全防护责任共担模型。在此模型下，应用拥有方和平台提供方共同承担不同区域的安全责任，共同实现云原生应用的整体安全。腾讯、信通院腾讯、信通院等单位联合发布的“云”原生安全白皮书指出，云原生安全指云平台安全原生化和云安全产品原生化。安全原生化的云平台，一方面通过云计算特性帮助用户规避部分安全风险，另一方面能够将安全融入从设计到运营的整个过程中，向用户交付更安全的云服务；原生化的云安全产品能够内嵌融合于云平台，解决用户云计算环境和传统安全架构割裂的痛点。绿盟科技集团股份有限公司绿盟科技集团股份有限公司对于中国联通云原生安全实践白皮书（2022）-7-云原生安全的理解包含两层含义，一是面向云原生环境的安全，其目标是防护云原生环境中的基础设施、编排系统和微服务的安全。二是具有云原生特征的安全，指具有云原生的弹性敏捷、轻量级、可编排等特性的各类安全机制。综上所述，我方认为云原生安全是云原生理念的延伸，旨在解决云原生技术面临的安全问题。抽象来看，云原生安全强调以原生的思维构建云安全，基于安全责任共同分担、安全左移、零信任、持续监控和响应、工作负载可观测等理念，将安全与云计算进行深度融合。在具体实践过程中，通过综合运用云原生基础架构安全、云原生应用安全、云原生研发运营安全、云原生安全管理等技术，共同实现云原生安全。综上所述，我方认为云原生安全是云原生理念的延伸，旨在解决云原生技术面临的安全问题。抽象来看，云原生安全强调以原生的思维构建云安全，基于安全责任共同分担、安全左移、零信任、持续监控和响应、工作负载可观测等理念，将安全与云计算进行深度融合。在具体实践过程中，通过综合运用云原生基础架构安全、云原生应用安全、云原生研发运营安全、云原生安全管理等技术，共同实现云原生安全。中国联通云原生安全实践白皮书（2022）-8-（二）云原生安全典型模型（二）云原生安全典型模型1 云原生安全防护责任共担模型1 云原生安全防护责任共担模型由于云原生采用的资源抽象和技术栈不同，所以云原生架构也可以采用多种模型来描述，其中主要的模型架构包括基础架构即服务(InfrastructureasaService,IaaS)、Kubernetes 即 服 务(KubernetesasaService,Kubernetes-aaS)、容 器 即 服 务(Container as a Service,CaaS)、功能即服务(Function as aService,FaaS)、软件即服务(Software as a Service,SaaS)五种不同的模型，利用这些不同的模型提供不同的服务模式。IaaS 以即用即付模式按需提供物理或虚拟化计算、存储和网络资源；Kubernetes-aaS 通过 Kubernetes 平台提供云计算服务，其中计算、存储、网络等功能均是通过以接口的形式提供、以插件的形式实现；CaaS 使用基于容器的抽象来管理和部署应用，它是 IaaS 的一种子集，CaaS 的基本资源为容器；FaaS 是一种无服务器云计算服务，用户仅管理功能和数据，而云提供商则管理应用程序；SaaS 允许用户通过Internet连接和使用基于云的服务,所有操作和维护任务以及应用程序数据均由服务提供商处理。云原生安全与传统的安全及云安全相比，更关注容器、Kubernetes、微服务、Serverless 等内容，但是总体上看云原生安全所保护的对象，是指以容器技术为基础底座，以 DevOps、面向服务等云原生理念进行开发,并以微服务等云原生架构构建的信息系统。中国联通云原生安全实践白皮书（2022）-9-在不同的服务模式下，平台提供方和应用拥有方所承担的安全责任也会有差别，具体的责任模型如图 1 所示图 1 云原生安全防护责任共担模型2 面向云原生的 ATT&CK 攻防矩阵模型2 面向云原生的 ATT&CK 攻防矩阵模型2013 年，MITRE 公司为解决网络安全治理中防守方所面临的困境，基于现实中发生的真实攻击事件，创建了一个丰富的对抗战术和技术知识库，即 Adversarial Tactics Techniques and Common Knowledge，简称为 ATT&CK。该知识库指出攻击者的 IP、域名、Hash 等指纹信息可能会随着环境的不同而改变，但是其攻击的手段是具有共性的，因此，基于此构建攻防矩阵模型，能够更加准确的把握攻击行为。截止到本白皮书发布，ATT&CK 的最新版本为 V12，该版本的 ATT&CK 框架包含了企业矩阵、移动端矩阵、工业控制系统矩阵，每类矩阵中都包含攻击者发起攻击所采用的战术、技术和子技术，并且战术、技术和中国联通云原生安全实践白皮书（2022）-10-子技术的种类一直在迭代增加的过程中。如今容器和 Kubernetes 已经成为事实意义上的容器及容器编排工具的标准，并且已经被国内外的各大企业广泛应用。MITRE 在已经发布的 ATT&CK V9 版本开始就新增了关于容器的攻防矩阵，具体的攻防矩阵如图 2，目前已经有越来越多的企业组织依托 ATT&CK 矩阵构建自己的云原生安全防护体系，为云原生安全提供更全面的防护。图 2 ATT&CK 容器矩阵在 ATT&CK 攻防矩阵被各组织企业广泛应用的同时，各组织企业也开始根据自己的实际情况构建符合自身的攻防矩阵，其中微软公司根据自身使用 Kubernetes 的实际情况，构建出了 Kubernetes 威胁矩阵，如图 3 所示。中国联通云原生安全实践白皮书（2022）-11-图 3 Kubernetes 威胁矩阵企业结合自己的建设实际，并参考 ATT&CK 攻防矩阵，通过全面分析黑客攻击 Docker 和 Kubernetes 的过程和手段，建设适合自身的云原生安全体系，可以让黑客无所遁形，进而更加有效的防止攻击行为的发生，助力企业全面提升云原生安全能力水平。3 DevSecOps 开发安全运营一体化模型3 DevSecOps 开发安全运营一体化模型DevOps 是为提升软件的研发和运维效率而诞生的，其初衷就是满足软件系统的快速交付和持续迭代。DevOps 的主要特点包括：追求敏捷、快速迭代，但忽视安全检查，倡导研发与运维之间的协作，却没有要求安全部门参与到双环流程。由于 DevOps 的这些特点，导致了许多安全问题的相继出现，如快速迭代过程中，第三方组件的大量引入，会将组件中存在的漏洞和不合规的许可声明引入到软件系统中，成为潜在风险；DevOps 实践中容器技术和微服务架构的使用，也会不可避免地引入安全风险，例如容器逃逸漏洞和 API 接口爆炸式增长等。面对这些问题，DevSecOps 理念被提出，相对于 DevOps 而中国联通云原生安全实践白皮书（2022）-12-言，DevSecOps 增加了安全要求，将安全能力内建到研发运营体系中，形成覆盖业务应用计划、创建、验证、预发布、发布、预防、检测、响应、预测和优化等阶段全生命周期的安全检测与防护工具链，实现安全开发、安全测试、安全部署和安全运营的统一融合，在提升软件系统研发过程标准化与自动化的同时，降低对效率的影响，也降低安全的成本。具体的 DevSecOps 开发安全运营一体化模型如图 4 所示：图 4 DevSecOps 软件安全开发生命周期模型中国联通云原生安全实践白皮书（2022）-13-三、云原生安全防护体系三、云原生安全防护体系面对云原生的使用所带来的安全问题，需要构建分层覆盖、全面包含的云原生安全防护体系，并在遵循云原生安全原则的基础上，针对企业自身的业务特点形成云原生安全架构，建设形成覆盖云原生整体架构的安全防护能力。（一）云原生安全原则与架构（一）云原生安全原则与架构1 云原生安全原则1）零信任原则1 云原生安全原则1）零信任原则“永不信任、持续验证”的零信任原则，其目标是为了降低资源访问过程中的安全风险，防止在未经授权情况下的资源访问。在此原则下，网络位置不再决定访问权限，在访问被允许之前，所有访问主体都需要经过身份认证和授权。身份认证不再仅仅针对用户，还将对终端设备、应用软件等多种身份进行多维度、关联性的识别和认证。零信任架构通过细粒度拆分、执行策略限制等技术手段，消除数据、资产、应用程序和服务的隐式信任，实现动态最小授权，从而减轻网络威胁横向扩散的可能性。2）安全左移原则2）安全左移原则在云原生安全建设中，容器实例生命周期短、业务复杂。因此，增加运行时的安全投入对整体业务和云计算环境安全水平的提高帮助有限。同时，在软件应用的生命周期中，越靠前修复安全问题的成本越低。因而，安全左移的思想逐渐成为共识，即将安全投入更多地中国联通云原生安全实践白皮书（2022）-14-放到云原生安全建设初期，包括安全需求分析、安全设计、安全编码、供应链（软件库、开源软件等）安全、镜像安全等。安全左移的思路不仅让团队能够及早发现安全风险，还能降低安全投入、提高整体的安全水平，以确保及时解决安全威胁。3）供应链安全原则3）供应链安全原则云原生技术中广泛的采用持续交付、DevOps、微服务和容器化的技术，这使得云原生应用的供应链安全风险数量随之增多，包括开发阶段的漏洞风险引入、测试阶段未进行安全测试、应用上线后缺少必要的安全防护与隔离手段、容器漏洞的引入等，都是云原生应用供应链中面临的安全风险。为保证供应链的安全，需要打造覆盖供应链各阶段的安全防护能力，包括安全编码、软件物料清单（Software Billof Materials，SBOM）梳理、开源组件检测、交互式安全检测、应用运行时自保护、镜像安全检测、容器运行安全防护等。4）持续监控和响应原则4）持续监控和响应原则云原生技术的使用，彻底改变了业务应用的存在形式，业务系统变得越来越开放，越来越复杂。微服务、容器和 Kubernetes 的使用，已经彻底消除了固定的防御边界，在原来“南北向”访问的基础上，增加了“东西向”访问。另外，新技术的应用所带来的新型漏洞和风险越来越多，攻击者的攻击手段也是灵活多变、从不间断的。面对这些问题，各企业继续依赖原有的安全防御体系已经难以有效的保护自身的安全。为解决传统防御的被动局面，需要遵循持续监控和响应原中国联通云原生安全实践白皮书（2022）-15-则，打造持续不间断的安全风险监控和响应能力，转被动防御为主动，建立多级纵深持续循环的安全防御体系，并形成持续的响应机制，帮助企业更高效的发现未知风险，精准定位攻击行为，全面提升响应效率。2 云原生安全架构2 云原生安全架构云原生安全架构覆盖全面，包含内容丰富，可以概括为基础设施安全、云原生基础架构安全、云原生应用安全、云原生研发运营安全、云原生数据安全以及云原生安全管理等其。中基础设施安全属于硬件安全，严格意义上属于云原生安全体系中的环境安全，不在本白皮书详细讨论范围。具体的云原生安全架构如图 5 所示。中国联通云原生安全实践白皮书（2022）-16-图 5 云原生安全架构图中国联通云原生安全实践白皮书（2022）-17-（二）云原生基础架构安全（二）云原生基础架构安全云原生基础架构安全面向云原生环境中的网络、镜像、编排组件以及容器运行时等提供安全检测与防御手段，主要包括网络安全、编排及组件安全、镜像安全和容器运行时安全。1 网络安全1 网络安全随着云原生技术的不断发展和演进，使得云原生的网络架构相对于传统的网络架构产生了很大的变化，在云原生的网络架构中基于端口映射的容器主机网络、基于 CNI 的 Kubernetes 集群网络和 ServiceMesh 层次化的 SDN 网络等均被广泛使用。这些技术的应用为云原生网络不可避免的引入了一些新型的风险，如东西向流量缺乏有效的检测和访问控制、容器网络与宿主机网络缺乏隔离机制、端口暴露量增加等。面对这些安全风险，需要针对云原生的网络架构，建立网络安全风险防御体系。1）基于零信任的云原生网络微隔离1）基于零信任的云原生网络微隔离在云原生网络中，由于容器或者微服务的普遍存在，相对于传统网络或者租户网络，在网络隔离方面，需要构建针对业务角色的更细粒度的访问隔离。同时，还要针对业务之间的关系，在隔离基础上实现访问控制，重点控制东西向业务之间的访问，防止攻击者进入网络内部后的横向移动，阻止威胁横向扩散。零信任网络访问（Zero TrustNetwork Access,ZTNA）是零信任实现中很重要的技术分支，在云原生网络安全建设中起着重要的作用，依托零信任网络访问技术，构建中国联通云原生安全实践白皮书（2022）-18-零信任的云原生网络微隔离体系，能够更有效的保证云原生网络安全。2）云原生网络入侵检测2）云原生网络入侵检测由于云原生环境下生态的开放性和容器网络的复杂性，传统的网络入侵检测系统，不能很好地监测到云原生环境中网络流量中隐藏的入侵行为，云原生环境需要构建与之相适应的网络入侵检测机制。针对云原生环境，构建形成适应云原生网络的入侵检测机制，能够实现对 Kubernetes 集群每个节点上 Pod 相关的东西及南北向流量的实时监控，使网络流量直观可视化，并对命中规则的流量进行告警和阻断，形成从检测到阻断的完整闭环。2 编排及组件安全2 编排及组件安全容器的编排工具包括 Kubernetes、OpenShift、Containership、Docker Swarm、Docker Compose 等等，其中 Kubernetes 作为编排和管理工具被广泛使用，已经成为分布式调度和自动化运维实际意义上的标准，本节主要介绍 Kubernetes 的安全策略。Kubernetes 中的组件众多，并且绝大多组件是以基于 HTTP 和HTTPS协议的API形式提供服务。在生产环境中我们常用的服务有APIServer、Kubelet、Dashboard、etcd 等，这些组件的使用使得编排平台存在 API 端口暴露、未授权访问、访问证书被窃取等风险。同时，Kubernetes 中访问控制机制限制过于宽松，并且未遵循最小权限等安全原则，这些都会导致相应的组件及整个平台面临严重的安全风险。面对这些安全风险，编排平台本身及外部都应该设置相应的安全防护中国联通云原生安全实践白皮书（2022）-19-机制来保证编排平台及组件的安全。1）编排组件自身的安全防护机制API Sever 认证：1）编排组件自身的安全防护机制API Sever 认证：API Server 是实现 Kubernetes 资源增删改查的接口，因而在用户通过 API Server 对资源进行操作之前，需要对用户进行相应的认证操作，从而防止未授权用户通过 API Server 进行非法操作。Kubernetes 支持多种认证方式，主要包括：静态令牌文件认证、X.509 客户端证书（即 HTTPS 证书）认证、服务账号令牌认证、身份认证代理认证等。API Sever 授权：API Sever 授权：当用户通过 Kubernetes API Server 认证后，就进入到了 API Server 的授权环节，授权环节能够对 API Sever 认证的输入进行校验，控制服务账户可访问的资源。Kubernetes 包含四类授权模式，分别为节点（Node）授权、基于属性的访问控制、基于角色的访问控制、基于钩子（Webhook）方式的授权。准入控制器(Admission Controller)：准入控制器(Admission Controller)：当用户请求通过 APIServer 认证和授权后，便进入了准入控制器环节，准入控制器能够对用户所请求的资源，例如 Deployment、Pod、Service、Daemonset、Statefulset 进行准入考量。相比前面提到的 API Server 认证授权机制，准入控制器是更为细粒度的资源控制机制，其支持 Kubernetes的许多高级功能，例如 Pod 安全策略（Pod Security Policy）、安全上下文（Security Context）、服务账户（Service Account）等。Secret 对象：Secret 对象：使用 Secret 对象来保存敏感信息，例如密码、令中国联通云原生安全实践白皮书（2022）-20-牌和 SSH 密钥等信息。相比于将敏感信息放入 Pod 定义的 Yaml 文件或容器镜像中，使用 Secret 方式更为灵活和安全。通过此方式保存敏感信息，能在一定程度上提高攻击者获取敏感信息的难度，更有效的保证敏感信息的安全，因此该方式也是目前开发者最常使用的密钥管理方式。在实际的生产环境中，根据自身建设的实际情况，合理的配置编排组件自身的安全防护机制，如 API Server 授权、API Server 认证、准入控制器和 Secret 对象等，能够有效的实现对用户的访问控制，防止未授权访问行为的发生。2）编排组件之外的安全防护机制安全配置基线核查：2）编排组件之外的安全防护机制安全配置基线核查：为保证 Kubernetes 平台及其组件的安全合规水平，缩小其风险暴露面，对平台及其组件开展安全基线配置核查。依靠安全基线配置核查标准，发现配置文件中的不合规项并加以整改，提高平台及组件的合规水平。漏洞扫描：漏洞扫描：Kubernetes 平台及其组件本身会存在一些已知的或未知的安全漏洞，这些漏洞一旦被攻击者利用将会影响到整个集群平台。因此，依靠自动化的漏洞扫描能力，针对平台及其自身的组件进行常态化的漏洞扫描，发现 Kubernetes、Docker 等编排组件和容器组件中的漏洞，并进行及时修复，能够防止漏洞被攻击者所利用。集群攻击实时监测：集群攻击实时监测：实时监测 Kubernetes 层面发生的异常或恶意行为，基于 Kubernetes 行为监测，对异常或恶意行为进行响应处中国联通云原生安全实践白皮书（2022）-21-置，能够有效的避免攻击者拿到集群的权限，从而控制所有容器，进而避免整个 Kubernetes 集群失陷。集群事件审计：集群事件审计：通过日志自采集或者与已有日志平台对接，分析Kubernetes 集群业务的相关操作行为，进行威胁溯源分析，绘制攻击链路，能够在安全事件发生后有效的总结经验，并制定防御措施，防止类似安全事件的再次发生。因此在实际的生产环境中，在有效配置编排组件自身的安全防护机制的同时，利用安全基线配置核查、漏洞扫描、攻击实时监测和集群事件审计等安全防护手段，能够进一步提高编排组件的安全性。3 镜像安全3 镜像安全容器的广泛使用给云原生安全带来了更多的不可控风险，在云原生环境中容器镜像提供了容器运行的模板，一旦镜像存在安全风险，将导致依赖此镜像启动的容器全部面临相同的安全风险，因此保证容器镜像的安全成为了关系容器安全重要的方面。为更全面的保证镜像安全，需要关注镜像的全生命周期，具体的措施可以从以下几个方面开展。1）镜像构建安全1）镜像构建安全镜像的构建方式通常有两种，即基于容器直接构建和基于Dockerfile 构建，镜像构建过程中通常存在的风险项包括：拉取的基础镜像存在后门或者其他风险项、Dockerfile 中存储了敏感信息以及不必要的软件扩大了攻击面。因此，针对以上风险项，可以从以中国联通云原生安全实践白皮书（2022）-22-下几个方面来保证镜像构建安全：验证镜像来源：验证镜像来源：开启 Docker 的内容信任机制，为向远程镜像仓库发送和接收的数据提供了数字签名功能，验证镜像标签的完整性和发布者，保证镜像内容的完整可信。镜像轻量化：镜像轻量化：只安装必要的软件包，不仅在提高容器性能方面有很大帮助，更重要的是减少了攻击面。正确使用镜像指令：正确使用镜像指令：在构建镜像时要选择恰当的指令，若需引入外部文件，在 Dockerfile 中尽量使用 COPY 指令而不是 ADD 指令，因为 COPY 指令只是将文件从本地主机复制到容器文件系统，ADD 指令却可以从远程 URL 下载文件并执行。敏感信息处理：敏感信息处理：在 Dockerfile 中不能存储密码、令牌、密钥和用户机密信息等，即使在创建好容器后再删除这些数据也会造成风险，因为镜像的历史记录中仍能检索到这些数据。2）镜像仓库安全2）镜像仓库安全镜像被打包后，一般会被保存在镜像仓库中，如何保障镜像从镜像仓库到部署端的完整性和一致性，也是一个重要安全问题。如果在交互过程中，遭受中间人攻击，导致拉取的镜像在传输过程中被篡改，就会造成镜像仓库和部署环境的安全风险。所以镜像安全应具备保障镜像完整性和一致性的功能，并提供阻断能力，即禁止不符合一致性校验的镜像部署到集群中。因此，镜像仓库安全大体可分为三个部分：镜像仓库自身安全：镜像仓库自身安全：镜像仓库需要有效的设定身份认证和访问控中国联通云原生安全实践白皮书（2022）-23-制策略，避免因访问控制策略设置不当和账户权限问题，导致镜像仓库被入侵，仓库内镜像被篡改。镜像仓库传输安全：镜像仓库传输安全：需要使用加密传输机制，避免镜像仓库明文传输，遭受中间人攻击，导致镜像被恶意攻击者篡改。镜像仓库兼容性：镜像仓库兼容性：在多云场景下，要考虑主流镜像仓库 Harbor、Jfrog 以及各个云厂商提供的镜像仓库的兼容性，防止镜像在多个仓库之间传输的过程中被攻击和篡改。3）镜像安全扫描3）镜像安全扫描镜像自身的安全扫描也是镜像安全的一部分，为保证镜像的安全，需要能够自动化的对镜像进行安全扫描，例如扫描镜像的漏洞、恶意文件、组件包信息、镜像分层信息等。针对已经扫描到的镜像漏洞，需要提供完整的漏洞治理能力，分析每个镜像漏洞的风险危害、可能造成的影响、风险扩散面、风险加固建议等，帮助镜像修复漏洞。对于不合格的镜像，应提供卡点阻断和禁止部署的能力。4）镜像安全传输4）镜像安全传输镜像在下载和上传时需保证完整性和一致性。镜像在上传到仓库的过程中，上传者需要给待上传的镜像签名，下载者获取镜像时先验证签名再使用，防止其被恶意篡改。另外，为避免引入可疑镜像，用户需要谨慎使用 insecure-registry 选项连接来源不可靠的镜像仓库。中国联通云原生安全实践白皮书（2022）-24-4 容器运行时安全4 容器运行时安全容器运行在宿主机上通常与宿主机共享内核，并使用宿主机提供的 CPU、内存、网络等各种资源。这意味着，容器在运行时如果存在安全风险，会影响到宿主机，而宿主机存在的安全风险，也可能会影响到容器。因此，容器运行时所面临的安全风险包括内核共享带来的容器逃逸风险、容器不受限制的资源共享带来的资源耗尽风险、不安全配置与挂载引起的隔离性被打破风险。面对这些风险，需要重点在容器运行时进行安全检测与防护，捕获攻击行为，精准发现已知威胁和未知威胁。1）基于规则的已知威胁检测1）基于规则的已知威胁检测基于规则的异常检测方法一直是最为经典的方案，容器环境下也依然适用。但是与传统网络环境不同的是，容器环境下出现了许多新的威胁，如容器逃逸、容器应用漏洞等。因此，通过规则的方式能够快速、精确的发现已知威胁，但其缺点是针对变化的、动态的未知威胁攻击，无法通过已有规则匹配。2）基于行为的未知威胁检测2）基于行为的未知威胁检测未知威胁检测需要从大量行为模式中将异常行为甄别出来，再对异常行为进行进一步的归类和判断，并采用自学习、无监督的方式，自动构建出合理的镜像进程行为基线。在行为基线建立完成之后，可以依托行为基线发现未知威胁和异常行为。通过行为基线的方式可以有效的发现容器内的恶意文件、恶意程序、攻击行为、反向连接行为、中国联通云原生安全实践白皮书（2022）-25-无文件攻击行为、逃逸行为等，从而更加全面的保证容器的安全运行。中国联通云原生安全实践白皮书（2022）-26-（三）云原生应用安全（三）云原生应用安全云原生应用相对于传统的应用发生了很大的变革，应用由传统单体架构转向微服务架构，云计算模式也相应的从 IaaS 转向为 CaaS 和FaaS。应用和云计算模式的这些变革，导致云原生应用在集成了传统的应用风险和 API 风险的同时，也引入了一些包括未授权访问、API和 Serverless 被滥用的新型风险，因此云原生应用安全应该面向 API、微服务架构下的应用以及 Serverless 提供安全检测与防护手段。1 API 安全1 API 安全虽然云原生应用架构的变化导致了API数量和API滥用风险都在不断增多，但是造成 API 风险的原因在本质上区别不大，因此可以利用传统的 API 防护能力进行云原生应用的 API 防护。另外，还可以采用API脆弱检测的方式发现由于不安全的配置或者API漏洞造成的安全风险，并采用云原生 API 网关对 API 的访问进行安全控制，从而更全面的保证 API 安全。1）传统 API 防护1）传统 API 防护针对传统的 API 风险，可以使用传统的 API 防护方式，例如针对失效的认证，可以采取多因素认证、账号锁定以及验证码的方式来防止攻击者对特定用户的暴力破解，再如针对失效的功能授权，可以默认拒绝所有访问，并显式授予特定角色访问某一功能等。针对传统的API 风险，传统的 API 防护方式能够起到很好的防护效果，更多典型的 API 防护方式各位读者可以参考 OWASP 组织在 2019 年发布的 API中国联通云原生安全实践白皮书（2022）-27-十大风险报告，此报告中有详细的风险及防护说明。2）API 自动发现能力2）API 自动发现能力API 发现方式目前大致分为两种：一种是基于流量，持续对正常的业务访问进行观测，发现可使用的 API。另一种和 DevOps 融合基于开发过程中的信息来发现 API。基于流量的方式中比较典型的是通过使用交互式应用安全检测类工具的插桩能力，自动化的获取应用所使用的 API；与 DevOps 融合的方式，则通过分析开发人员上传的swagger 文档的方式，解析出应用所使用的 API。两种方式都能够自动化的梳理应用所使用到的 API，形成完整的 API 列表，方便后续进一步对 API 进行安全检测和治理。3）API 脆弱性检测3）API 脆弱性检测API脆弱性主要针对的是服务端可能含有的代码漏洞、错误配置、供应链漏洞等，目前较为可行的方式是使用扫描器对服务端进行周期性的漏洞扫描。除此之外，API 脆弱性检测还应提供自动学习能力，能够对正常业务进行持续观测，进而对 API 地址、类型、参数、数值模式、调用频率等进行学习，形成推荐的访问控制策略。4）云原生 API 网关4）云原生 API 网关微服务应用环境中，云原生 API 网关充当着非常重要的一环，它不仅能够控制外部所有流量的接入，同时还能够在网关入口处根据不同类型请求提供流量控制、日志收集、性能分析、速率限制、熔断、重试等细粒度控制行为，通过云原生 API 网关能够有效降低风险行为中国联通云原生安全实践白皮书（2022）-28-的接入和访问。2 微服务架构下的应用安全2 微服务架构下的应用安全应用的微服务化带来的新风险主要包含数据泄露、未授权访问、拒绝服务攻击等，针对这些风险可以采用传统防护模式与微服务治理框架相结合的方式进行防护，具体的防护方法主要有以下几个方面：1）认证服务1）认证服务由于攻击者在进行未授权访问前首先需要通过系统的认证，因而确保认证服务的有效性非常重要，尤其在微服务应用架构下，服务的不断增多将会导致其认证过程变得更为复杂，因此对用户进行合理有效的认证，能够防止未授权访问的发生。2）授权服务2）授权服务授权服务是针对未授权访问风险最直接的防护手段，微服务应用架构下，由于服务的权限映射相对复杂，因而会导致授权服务变得更难，针对合法用户进行资源合理化的授权访问控制，能在一定程度上防止未授权访问的发生，有效保证应用安全。3）准入策略3）准入策略传统的容器安全产品准入策略，几乎都是基于容器与容器镜像的安全视角进行策略控制，如是否使用特权容器、Pod 是否与宿主机共享命名空间或是镜像是否存在风险漏洞等策略，而云原生应用除了容器与镜像视角，还有 DevOps 中产生的风险事件，如微服务在开发测试期间是否存在高危风险漏洞、是否使用了带有漏洞的第三方组件库中国联通云原生安全实践白皮书（2022）-29-等，这些在开发测试期间发现的安全风险都有可能致使微服务上线后产生安全风险，因此在此准入阶段需要再次做好安全卡点，防止微服务带病上线。4）云原生 WAF4）云原生 WAF云原生 WAF 是通过 Pod 或微服务的粒度来启用 WAF 防护，可以通过对 Pod 打上相关标签的方式按需启用安全防护能力，而不是只在流量出入口进行防护。通过使用云原生 WAF，能够有效的感知服务与服务之间的流量，并进行检测与响应，同时，控制粒度还可以细化到单个微服务或者Pod，从而达到有效抵御内部和外部流量的攻击的效果。5）其它防护5）其它防护除了上述防护方法之外，微服务治理框架还可以与 API 网关、准入策略、云原生 WAF 等结合以进行深度防护，通过这些方式可以在一定程度上缓解微服务环境中被拒绝服务攻击的风险。3 Serverless 安全3 Serverless 安全Serverless 作为一种新型的应用模式，传统应用的风险应对方式可以覆盖大部分的 Serverless 应用风险，尤其是应用系统的代码漏洞、依赖库漏洞以及应用漏洞都可以通过传统的方式来检测。但是Serverless 的使用也带来了新的变化，还需要去进行更深层次的防护，防护方式可以从两方面开展，一方面是针对 Serverless 应用本身的安全防护，另一方面是针对 Serverless 计算模型以及平台的安全防护。中国联通云原生安全实践白皮书（2022）-30-1）Serverless 应用安全防护1）Serverless 应用安全防护针对 Serverless 应用的安全防护，可以从函数隔离及底层资源隔离两个方面开展：函数隔离：函数隔离：一个 FaaS 应用通常由许多函数以既定的序列和逻辑组成，每个函数可以独立进行扩展和部署，但也同时可能被攻破，因此实际使用中为了应用的安全，应当将每个函数作为边界，使得安全控制粒度细化至函数级别，这对于创建能够长期保持安全的 FaaS 应用是非常必要的。底层资源隔离：底层资源隔离：对函数层面隔离是必要的，但是仍然存在一定的不足，例如攻击者仍可以利用函数运行时环境的脆弱性以获取服务端的 shell 权限。为了防止上述攻击行为的发生，应当从底层进行资源隔离，例如通过 KataContainer 从下至上进行防护、通过 Kubernetes的网络策略(NetworkPolicy)实现东西向的网络层面隔离等。2）Serverless 平台安全防护2）Serverless 平台安全防护针对 Serverless 平台的安全防护，可以考虑通过以下几种防护方式进行相应缓解。存储最佳实践：存储最佳实践：为了尽量避免用户在使用云厂商提供的Serverless 平台时因不安全的错误配置造成数据泄露的风险，主流云厂商应提供相应的存储最佳实践供开发者参考。监控资源：监控资源：云厂商应当为 Serverless 配备相应的监控资源，从而达到识别和报告异常行为的目的。中国联通云原生安全实践白皮书（2022）-31-账单告警机制账单告警机制：针对拒绝钱包服务（DoW）攻击，公有云厂商应当提供账单告警机制进行缓解，如 Serverless 使用者可通过设定调用频率与调用费用门限值进行及时的 DoW 攻击响应。除此之外，还可以使用基于资源限额进行控制，即函数到达一定副本数就不再进行扩展，从而降低 DoW 攻击带来的影响。3）其他防护措施3）其他防护措施除上述Serverless应用安全防护和Serverless平台安全防护以外，我们还可以采用其他的防护措施来共同保证 Serverless 的安全。Serverless 资产业务梳理：Serverless 资产业务梳理：开发者在不断完善应用的同时，可能疏于对应用数据及 API 的管理，从而导致攻击者利用敏感数据和不安全的 API 发起攻击。为了避免这种情况，开发者应当在应用的设计阶段对资产业务进行详细梳理，从而形成一个较为全面的应用全景图，通过应用的全景图便可以对应用有一个更全面的了解，从而针对性的进行安全整改及防护，这样便可在一定程度上降低应用被攻击的风险。定期清理非必要的 Serverless 实例：定期清理非必要的 Serverless 实例：由于 Serverless 应用通常遵循微服务的设计模式，因此一套完整的工作流应由许多函数组成，而开发者在部署时可能部署了非常多的 Serverless 应用，在这些应用中，必定存在一些长时间不被调用的实例，为了避免这些非必要的实例被攻击者利用，应当定期对 Serverless 应用进行检测，清理非必要的实例，从而降低安全隐患。限制函数策略：限制函数策略：开发者应当限制函数策略，给予其适当的访问权中国联通云原生安全实践白皮书（2022）-32-限，删除过于宽松的权限，这样即可以使攻击者拿到了访问凭证也无法对所有资源进行访问。中国联通云原生安全实践白皮书（2022）-33-（四）云原生研发运营安全（四）云原生研发运营安全在云原生技术被广泛应用的背景下，作为云原生技术不可或缺的持续交付、DevOps 技术在研发运营中被广泛应用。DevOps 的使用大幅提高了研发和运营工作的效率，但是引入的安全问题也日渐增多。因此，作为开发安全运营一体化的 DevSecOps 理念被提出，依托DevSecOps 理念，在研发运营周期的每个环节，都需要将安全贯穿其中，从安全需求到安全运营，都要考虑其安全风险点，并结合相应的安全措施进行安全防护。1 安全需求分析1 安全需求分析需要根据业务的安全策略、数据安全要求、合规需求、应用系统的特性等进行安全需求分析，从而制定不同的安全策略选取合适的安全活动。重点考虑的安全需求点包括身份识别、认证、访问控制和授权、日志审计、敏感数据保护、第三方开源软件选型等关键点。在这个阶段，通常涉及的安全活动主要包含安全培训、威胁建模、安全开发衡量指标制定等。1）安全培训1）安全培训需要让项目组成员清楚了解各个阶段需要承担的责任与义务，并进一步对 DevSecOps 体系整体过程进行学习。DevSecOps 工具使用方面需要对项目组成员进行培训，如：对开发人员、安全人员进行 SAST、SCA、IAST、DAST 等工具的使用培训，对运维管理人员进行安全基线配置核查工具、容器安全管理等工具的中国联通云原生安全实践白皮书（2022）-34-使用培训。2）威胁建模2）威胁建模为满足 DevOps 快速敏捷要求，采用轻量级威胁建模方式，主要实践步骤有以下几点：首先，通过动态调查问卷快速收集有关业务系统、部署环境和合规性要求等方面的重要且详细的信息，根据收集到的信息自动识别风险、威胁和潜在弱点。其次，根据预定义的安全和合规性策略对整体风险进行分类管理。最后，输出安全设计方案，并对安全问题进行跟踪。3）衡量指标3）衡量指标根据业务应用系统的不同安全级别来制定对应的安全开发衡量指标，用于评估实施效果。2 安全开发2 安全开发开发阶段是安全风险引入的源头阶段，由于开发人员安全意识不足，在使用一些开源组件和基础镜像时，很容易将漏洞引入到业务系统中来，这些漏洞的引入，都会给业务系统带来难以弥补的安全风险。从安全成本的角度来看，开发阶段是修复安全问题成本最低的时期，具体的安全开发措施有以下几点：1）代码安全1）代码安全研发人员要具备安全编码意识，遵守安全编码规范，使用安全的接口函数，在 CI 中融入代码审计工具，定期扫描源代码，及时发现代码中的漏洞；集成镜像的扫描工具，检测构建完成的镜像中的安全中国联通云原生安全实践白皮书（2022）-35-问题；定期对代码中发现的问题进行复盘，加强安全开发意识的培养。2）开源组件安全2）开源组件安全对于代码中引入的第三方组件，应使用开源组件成分分析工具对代码进行成分分析，及时识别组件中已知的安全漏洞或者潜在的许可证授权问题，把这些风险排查在应用系统投产之前。3）制品安全3）制品安全对制品进行安全检测，发现漏洞时及时修改和提供替换方案；引入镜像签名机制，并避免在构建中引入有风险的工具包；规范化镜像构建，不要泄露敏感信息（证书密钥、密码、认证 token 等）；使用可信的容器镜像，从信任的仓库中拉取镜像。4）开发安全管理4）开发安全管理使用分布式架构的代码管理工具（如 Git）进行开发，避免源头丢失导致的问题；使用 CI 系统与安全系统相结合，在镜像开发、编译等流程中增加监控点，保证镜像的安全性。3 安全检测3 安全检测系统开发完成后，需要结合业务场景、业务逻辑以及完整的代码流等对系统进行整体测试，构建多样化互补的安全自动化测试能力，全面检测系统中存在的安全漏洞，降低安全风险。1）静态应用安全测试1）静态应用安全测试静态应用安全测试(Static Application Security Testing,SAST)与人工代码审查相比，具有效率高、结果一致等优点，属于白中国联通云原生安全实践白皮书（2022）-36-盒测试的一种。利用 SAST 工具进行检测不需要运行测试的应用程序，而且理论上可以覆盖所有可能的程序路径，检测出来的漏洞多而全，但由于未对运行应用程序进行检测，因此 SAST 工具检测出的风险会存在一定程度的误报。2）软件成分分析2）软件成分分析软件成分分析(Software Composition Analysis,SCA)针对第三方开源软件以及商业软件涉及的各种源码、模块、框架和库进行分析、清点和识别，通过分析开源软件的组件及其构成和依赖关系，识别出已知的安全漏洞，并提供相应的修复建议，能够有效的帮助开发人员修复安全问题，从而把这些风险排查在应用系统投产之前。3）动态应用安全测试3）动态应用安全测试动 态 应 用 安 全 测 试(DynamicApplicationSecurityTesting,DAST)属于黑盒测试的类型，测试者无需了解架构、网络或者代码，而是从一个恶意攻击者的角度来测试应用程序。应用程序依赖于输入和输出运行，通过构造可疑的输入获得异常响应，从而确定漏洞。该方式是应用安全测试阶段最常用的一种测试方法，能够有效的发现应用系统安全漏洞。4）交互式应用安全测试4）交互式应用安全测试交互式应用安全测试(Interactive Application SecurityTesting,IAST)寻求结合 DAST 和 SAST 的优势，其实现原理通常为通过插桩的方式在应用环境安装 Agent，从而在软件代码特定位置插入中国联通云原生安全实践白皮书（2022）-37-探针，通过执行测试用例触发请求，跟踪获取请求、代码数据流、控制流等，然后依据测试用例的执行情况和反馈结果进行综合的判断，分析是否存在漏洞。相比于 DAST 和 SAST，IAST 既能识别漏洞所在代码位置，又能记录触发漏洞的请求，和 DAST 类似的是 IAST 工具仅仅能检测已执行的程序路径，因此其检测覆盖率方面的劣势有待提升，可以通过和现有自动测试生成工具（如模糊测试工具）相结合的方式来进一步提高覆盖率。5）渗透测试5）渗透测试对于一些应用系统的业务逻辑缺陷和特定的业务场景下所出现的安全问题，通过自动化的工具检测误报率和漏报率比较高，需要通过人工渗透测试的方式来检测，渗透测试的测试人员，模拟黑客的攻击行为通过各种手段进行渗透攻击，从而发现系统的存在的安全问题。4 安全运营4 安全运营业务系统上线后，仍然面临着各种安全威胁，有来自外部的直接攻击、系统自身的安全配置风险、安全管理疏漏造成敏感信息外泄、安全处置机制不健全造成风险处置滞后等，所以为保证业务系统的安全，需要从技术和管理等不同的方向来达到安全运营的目的。1）运行时应用程序自保护1）运行时应用程序自保护运 行 时 应 用 程 序 自 保 护(RuntimeApplicationSelf-protection,RASP)通过将安全能力原生化，内嵌于运行时的应用程序中，使得应用程序具备运行时安全攻击的检测和阻断能力。与中国联通云原生安全实践白皮书（2022）-38-Web 应用程序防火墙相比，RASP 的主要优势在于检测应用程序行为来确定访问请求是否为攻击，在面对 Web 应用防火墙无法防御的加密场景和其规则无法覆盖到的攻击行为时，RASP 能够进行有效的检测和防护。随着 DevSecOps 变得越来越普遍，RASP 因其具备识别攻击快速且准确、能够定位安全漏洞风险代码、持续实时的监控和快速融入软件开发等特性，逐步被业内的安全防护实践方案采用。2）安全监测2）安全监测持续的安全监测，能够及时的发现运行中的业务系统所遭受的攻击行为，并且能够有效地获得外部的漏洞情报和攻击行为进行分析，是转被动防御为主动防御的重要措施。因此在系统上线后，通过全网态势感知、应用攻击防御监测、威胁情报、终端异常行为检测等系统，构建持续的安全监测体系，更利于保证系统的安全运行。3）安全基线核查3）安全基线核查安全配置基线检查作为保证各类业务系统和设备基础安全水平的方法，一直被广泛应用，在云原生的场景下，需要进行安全基线配置核查的对象发生了很大的变更，因此需要针对云原生场景，制定对Docker、Kubernetes、Openstack 等对象的安全基线配置核查规范，并形成相应的安全核查能力。通过安全配置基线核查，对云原生的资产进行梳理和管控，发现其配置中存在的安全风险，然后进行修复，可以有效的提高业务系统环境的安全水平。4）安全运营管理4）安全运营管理中国联通云原生安全实践白皮书（2022）-39-在运营过程中建立严格的安全管理流程，包括安全策略/账号与权限变更管控、安全备案的管理、审批等。另外，将安全策略设置功能、账号权限管理功能等内生构建到云产品中，通过集中化管理平台进行对接，自动感知策略变动、权限变动、人员变动等，能够更加高效的实现安全的运营管理。5）应急响应5）应急响应建立安全事件响应和处置机制，尤其是在出现 0day 漏洞等重大安全事件的响应机制。做到安全事件发生后有着完整的处置流程与标准可寻，确保安全事件响应的时效性，让安全问题处置效果可控、可衡量。中国联通云原生安全实践白皮书（2022）-40-（五）云原生数据安全（五）云原生数据安全云原生理念及相关技术的使用，极大增大了业务迭代的频率，并有效促进了运维效率的提升，由于业务迭代频率和运维效率的提升，相应的业务系统的数据安全保护也有了新的挑战，因此，在发挥云原生优势的同时，需要保障数据的安全性。1 数据安全保护1 数据安全保护从传统应用到业务上云再到云原生应用，数据的使用场景也在不断变化。因此需要根据云原生技术架构的特点，构建云原生数据安全防护体系，云原生数据安全防护策略主要可以从以下 3 个方面入手：1）进行数据的分类治理，针对敏感数据和重要数据制定相应的保护策略；2）在数据传输存储的整个过程中，使用加密技术对数据进行加密和脱敏保护，通过密码技术保障数据的完整性和机密性。3）针对外部攻击和内部员工误操作导致数据泄露的问题，通过身份认证、角色管理等手段对数据获取权限进行统一管理，完善企业对数据访问的控制能力，最终形成云原生数据全生命周期的安全防护。2 2数据安全审计数据安全审计数据库中储存了业务交互过程中所需的数据，一旦发生数据泄露，往往会造成重大安全事故。因此，要保证数据的安全，需要挖掘数据库运行过程中各类潜在风险和隐患，对数据库各类会话信息、访问操作、SQL 语句进行全量双向审计、分析、告警以及日志归档留存，从中国联通云原生安全实践白皮书（2022）-41-而保障数据库安全存储与运行。中国联通云原生安全实践白皮书（2022）-42-（六）云原生安全管理（六）云原生安全管理云原生时代，资产和数据爆发式增长，API 接口广泛使用，端口服务暴露显著增多，并且资产的形态和数据的存储方式都发生了很大的变化。因此，为了减少安全风险，需要加强云原生安全管理，同时，使管理手段更加智能化。1 云原生资产统一管理1 云原生资产统一管理和传统的网络资产不同，云原生环境中引入了许多新型的资产，例如镜像、容器、Pod、进程、微服务等，这些资产和稳定性比较高的网络资产不同，具有高密度、高动态和高灵活的特点，这些特点导致了云原生资产时刻都在发生变化，从而给云原生资产的安全管理带来了新的挑战。面对新型的挑战，需要构建统一的云原生资产安全管理平台，打造自动化的云原生资产发现收集和梳理能力，将多云、多集群资产纳入平台统一管理，使得资产可视、可管，实现资产东西向及南北向互访关系、资产间调用链的可视化呈现，将资产全景态势与已有的检测能力进行结合，实时检测安全事件。2 云原生安全事件统一管理2 云原生安全事件统一管理为了更好的对云原生环境中各个集群中发生的安全事件进行统一纳管，需要形成安全事件的统一管理能力，包括事件的统一检测告警能力、处置响应能力和分析统计能力等。监测告警能力：监测告警能力：应检测不同集群多种安全事件类型，如容器微隔中国联通云原生安全实践白皮书（2022）-43-离事件、流量威胁事件、容器准入事件、容器逃逸事件、容器内恶意行为事件等，展示事件关键信息，帮助平台安全运营人员对事件产生原因进行分析，并给出处理建议。处置响应能力：处置响应能力：应针对事件类型，提供多种不同的处置方式与自动化处置能力，包括暂停容器、隔离容器、杀死进程、篡改文件恢复等。建设自动化处置能力，以降低安全运营成本，提高安全事件处置效率。分析统计能力：分析统计能力：应针对事件类型、风险等级、处置时间、处置速度、误报率等信息进行统计分析，持续优化事件处置效率，提高事件精准度，不断减少事件处置时间，缩小攻击者活动窗口。同时应对接第三方安全平台，进行实时安全事件的同步，建立统一安全运营中心。3 多云安全能力协同及统一管理3 多云安全能力协同及统一管理在云原生的环境中，由于云原生安全防护责任共担模型的不同、云服务提供厂商的不同、云架构体系的不同等原因，都会导致安全防护方式的不同。因此，出于数据主权、安全隐私等多方面考量，企业应该建立一套可接入多个云的平台，将不同云之间安全能力做统一规划与调整，并做到统一管理、统一运营、统一防护，实现多云安全能力协同和统一管理。4 智能化的云原生安全管理4 智能化的云原生安全管理云原生技术的落地实践和广泛应用，给安全管理带来了更大的挑战，为了更好的实现多云场景下的协同管理、云原生资产统一管控、中国联通云原生安全实践白皮书（2022）-44-云原生应用统计与监控以及开发运行一体化管理，迫切需要更加智能化的安全管理方式。在云原生技术的不断迭代发展的过程中，以云工作负载保护平台(Cloud Workload Protection Platform，CWPP)、云安全平台管理(Cloud Security Platform Management，CSPM)、云基础设施授权管理（Cloud Infrastructure Entitlements Management，CIEM）、云原生应用程序保护平台(Cloud-Native Application ProtectionPlatform，CNAPP)为代表的主流云安全技术都在被广泛应用和更新。其中 CNAPP 在 2021 年被 Gartner 提出后，因其具有可以保护从系统代码到业务开展的整个应用程序开发生命周期的特点，被业内的各个企业和组织所广泛使用，并且将在未来很大程度上替代 CSPM、CWPP、CIEM 等云安全技术。因此，各企业和组织需要根据自身的业务特点，结合 CNAPP 构建自身的云原生安全平台，打造智能化的云原生安全管理能力。为了方便企业选择更加合适的智能化安全管理方式，现分别对几种方式的特点进行说明，如表 1。表 1 智能化云原生安全管理技术比较名称主要能力面临挑战CWPP1、保护云和本地工作负载；2、能够收集有关漏洞、敏感信息、恶意软件扫描、资产版本等的详细信息，提供精细详细的可见性；3、提供运行时保护功能，支持文件完整性监控、恶意软件扫描、日志检查、应用程序控制；4、提供基于身份的隔离手段；5、将发现的风险分类到选定的合规性框架中，以便轻松、持续地报告和审计。1、需要维护一个单独的代理；2、无法深入了解云控制平面；3、资产覆盖程度受到代理覆盖率和兼容性的限制；4、缺乏横向移动风险检测。中国联通云原生安全实践白皮书（2022）-45-CSPM1、监控错误配置问题及合规风险，并在云环境中实施安全策略；2、通过对云配置的可见性，实现对多个云服务进行的集中管控；3、通过 API 连接，允许即时访问和审计跨多云环境的整个控制面配置；4、为云基础架构提供合规性报告，帮助组织审核其云基础架构的正确管理；5、与第三方威胁情报集成，帮助组织进一步识别风险1、无法深入了解工作负载的安全状况；2、缺乏横向的移动风险检测。CIEM1、身份和访问管理，在云环境中实行最小权限控制；2、持续监控和审查跨多个云服务提供商的所有访问权限；3、与身份提供商密切合作，将覆盖范围从系统和云服务扩展到所有拥有托管数字身份的人；4、CIEM 提供对有风险或不合规云授权的可见性，从而确定身份可以执行哪些任务以及可以跨组织的云基础架构访问哪些资源；5、能够了解整个云身份环境，为策略和补救措施提供最佳实践建议；6、不仅启用最小特权权限，而且还确保权限不会过度管理。1、不完整的身份和访问管理，无法识别“另类的”身份和访问管理(IAM)机制，例如磁盘上的 SSH 密钥和 AWS 密钥，以及横向移动风险；2、完整上下文和可见性方面的缺口：由于其专注于保护云的“新边界”，即身份访问管理，因此一般缺乏对 CSPM 提供的控制面以及实际工作负载中运行内容的可见性。CNAPP1、管理错误配置导致的风险，减少云原生应用程序的错误配置；2、整合安全投资，减少工具和供应商的数量；3、实现安全左移，以便在开发生命周期的早期阶段识别风险；4、分析攻击路径，识别看似不相关的“低危”风险如何组合以创建危险的攻击向量；5、简化治理，提高合规性；6、优先处理关键警报：允许安全部门根据关系(安全漏洞、错误配置、权限、暴露的秘密)了解攻击路径；7、提供 DevSecOps 全过程的安全能力，改善整体安全状况。重叠的能力：一个组织可能有他们无法删除的遗留云安全系统。四、云原生安全防护体系建设实践四、云原生安全防护体系建设实践如前所述，云原生的兴起和发展，将 DevOps、持续交付、微服务、容器化等技术广泛引入到生产环境，新技术的应用带来了新的安全问题，并且正在改变着企业的安全防护及运营体系，面对这些安全中国联通云原生安全实践白皮书（2022）-46-问题，需要以云原生的安全防护体系为指导，构建覆盖软件应用服务全生命周期的安全能力，打造更加安全的云原生计算环境，为此中国联通研究院结合自身的业务特点和云原生安全防护需求，重点打造了云原生安全防御平台和云原生容器安全管理平台，为云原生时代各类业务系统的安全运行保驾护航。（一）云原生安全防御平台（一）云原生安全防御平台云原生安全防御平台立足于云原生的研发运营安全，依托软件应用的 DevSecOps 研发运营安全体系，以安全左移、研发运营安全一体化、持续的监控与响应为设计理念，构建了覆盖业务应用计划、编码、构建、测试、部署、运营和监控全过程全生命周期的持续循环的安全检测与防御体系，具体的安全检测与防御体系如图 6 所示。图 6 云原生研发运营安全体系及能力建设中国联通云原生安全实践白皮书（2022）-47-1 安全编码1 安全编码为在软件应用的安全编码阶段就尽最大可能的消除安全风险，避免软件编写阶段引入漏洞，针对应用系统编码阶段所面临的安全问题，形成了安全编码规范和安全 SDK 库，用于指导开发人员进行安全编码，在编码阶段就能够做到有效收敛安全漏洞问题，赋予应用系统的云原生安全能力。目前针对覆盖 OWASP TOP10 2021 和 2017 的典型安全漏洞，制定了基于 JAVA 语言的安全编码规范，安全编码规范详细描述了安全编码方法、缺陷代码示例以及安全编码用例。具体的漏洞种类见表 2：表 2 安全编码规范覆盖的漏洞漏洞归属漏洞归属漏洞大类漏洞大类漏洞子类漏洞子类OWASP TOP 10OWASP TOP 10失效的访问控制路径遍历、访问控制不当、授权机制不恰当、通过用户控制密钥绕过授权机制加密失败根目录下敏感数据、加密问题、敏感数据明文存储、不充分的加密强度、侵犯隐私注入漏洞Sql 注入、命令注入、表达式注入、模板注入、NoSQL 注入、HQL 注入、LDAP 注入、邮件注入、XPATH 注入不安全的设计入参判断、整数溢出、资源未释放、越权漏洞安全配置错误Tomcat 任意文件写入、Tomcat AJP 文件包含、Spring Boot 远程命令执行使用含有已知漏洞的组件Weblogic 中组件、富文本编辑器失效的身份认证认证机制不恰当、会话固定不安全的反序列化Apache Commons Collections 反序列化、FastJSON 反序列化不足的日志记录和监控CRLF 日志注入、未记录可审计性事件中国联通云原生安全实践白皮书（2022）-48-服务端请求伪造 SSRF其他其他跨站请求伪造 CSRF、XML 外部实体（XXE）、URL 跳转与钓鱼、文件操作、Web 后门、前端配置不当、拒绝服务攻击、点击劫持漏洞、HTTP参数污染跨站脚本攻击（XSS）反射型 XSS、存储型 XSS、DOM 型 XSS2 软件成分分析2 软件成分分析针对软件应用系统在开发的过程中普遍使用开源组件，从而无法避免的将含有漏洞的开源组件引入到应用系统中的问题，研发形成了开源组件检测分析能力，通过开源组件检测，能够精准的识别应用系统中存在的已知安全漏洞或者潜在的许可证授权问题，发现漏洞后形成漏洞修复报告，从而指导开发人员将这些安全漏洞和风险排除在软件的发布上线之前，防止软件应用系统的带病入网运行。3 交互式安全检测3 交互式安全检测在云原生的安全原则中安全左移原则已经逐渐成为共识，并被安全从业人员广泛接受，而 IAST 技术推动了整个安全测试工作的左移，能够在应用功能的测试阶段同时进行安全漏洞检测，成为了 SDL 软件安全开发的生命周期和 DevSecOps 安全工具链中的必备测试手段，该测试方法能有效的发现静态安全检测和黑盒安全检测无法发现的安全漏洞，因此，为更加有效的检测应用系统中存在的安全问题，研发了交互式安全检测能力，如图 7 所示。目前已经能够对 OWASP TOP10、CWE 和一些特殊化场景漏洞进行有效的检测，并给出漏洞所在的代码位置，分析出风险漏洞的传播路径，为漏洞的修复提供建议参考。中国联通云原生安全实践白皮书（2022）-49-图 7 交互式安全检测能力4 应用运行时自保护4 应用运行时自保护为形成软件应用系统的自我免疫力，增强其防御 0day 漏洞攻击和开源组件漏洞攻击的水平，研发了 RASP 能力，RASP 能够将防御逻辑注入到 Java 底层 API 和 Web 应用程序中，实现防御手段与应用程序融为一体，实时分析和检测 Web 攻击，使应用程序具备自我保护能力，有效弥补原来防护体系的不足，RASP 的防御原理及部署位置如图 8 所示。依赖 RASP 与现有的纵深多级防御体系相结合，能够补上现网软件应用系统多级防御体系中的最后一环，让穿透后的攻击无法落地形成危害。另外，RASP 能够实现对应用系统的持续监控，监控应用系统所受到的攻击行为，并实时进行防护，保证应用系统的安全运行。中国联通云原生安全实践白皮书（2022）-50-图 8 RASP 对应用系统的防御目前依赖 RASP 形成的防御体系，实现了独特的能力，主要表现在以下方面：1）不受业务链路加密的影响，能够有效的抵御 HTTPS 场景下的攻击行为；2）能够实现代码级别的攻击阻断，几乎不存在误报，有效的将应用风险定位到代码行，对抗未知漏洞；3）打破现网防御体系依赖于防护规则的限制，更加注重攻击行为本身，实现针对攻击行为的精准拦截。中国联通云原生安全实践白皮书（2022）-51-（二）云原生容器安全管理平台（二）云原生容器安全管理平台为了更好应对容器化进程中的安全挑战，需要对容器全生命周期进行动态防护，包括但不限于以下三个方面：在构建阶段，在构建阶段，分析镜像构建使用的敏感操作、镜像文件包含的敏感信息、镜像软件组成存在的恶意文件等。在部署阶段，在部署阶段，对镜像签名校验、保障镜像传输安全、对危险镜像进行阻断等。在运行阶段在运行阶段，对运行环境安全进行合规性检查，实时监测容器运行状态，对失陷容器进行隔离与控制等。我方研发的云原生容器安全管理平台提供资产安全管控、安全配置基线核查、镜像安全、容器运行时安全等功能。通过打造云原生容器安全管理平台，形成了动态资产清单构建，资产与风险关联分析，容器全生命周期安全管控等能力。资产安全管控功能，通过自动化梳理云原生资产，实现云原生系统全面可视化。安全配置核查功能，提供对容器、容器编排工具、宿主机等设备的安全配置基线核查，保证云原生基础底座安全。镜像安全功能,将镜像扫描嵌入 DevOps 流程，提前感知镜像风险并修复，实现安全左移。容器运行时安全功能，基于智能 AI 算法，形成自学习的安全防护能力，有效保障容器的安全运行。整体的云原生容器安全管理平台的核心功能架构，如图 9 所示。中国联通云原生安全实践白皮书（2022）-52-图 9 云原生容器安全管理平台核心功能1 资产安全管控1 资产安全管控资产的安全管控是安全运营最基础性的工作，是保障安全事件处置、漏洞修复等工作能够顺利开展的关键要素。资产安全管控能力开展多维度、全方位的资产探查和测绘，实现资产精细化管理。云原生容器安全管理平台的可管控的资产包括镜像、容器、节点、仓库和集群。平台提供自动获取资产信息的能力，同时将资产信息与危险进行关联分析，根据危险等级进行分类梳理，帮助用户快速定位风险及其影响范围。在实现云原生资产可管控的基础之上，云原生容器安全管理平台将多集群多可用区打通，实现资产的统一可视化管理，消除安全与运维之间的信息壁垒，使业务环境内各项资产对用户清晰可见，能够在入侵事件发生时，帮助用户及时定位受损资产，并快速进行响应处理，以免恶意事件扩散造成更多资产的感染。2 安全配置基线核查2 安全配置基线核查基础运行环境是一切业务运行的底座，在业务系统上线运行之前，中国联通云原生安全实践白皮书（2022）-53-应对业务系统所在宿主机、容器、集群以及容器原镜像进行合规检测，从而发现不合规配置项，并进行整改，提高整体基础运行环境的安全水平。云原生容器安全管理平台提供了多种的基线合规检查能力，如图 10 所示。图 10 云原生容器安全管理平台基线核查范围通过云原生容器安全管理平台用户可以根据自身的安全需求，自定义配置安全合规检测项。安全配置核查完成后，用户可以通过检查项的说明、通过情况、修复建议等，快速了解基线检测的整体情况，从而针对性的及时进行安全整改。3 镜像安全3 镜像安全容器基于镜像运行，镜像作为容器运行的基础，镜像的安全性会直接影响到线上业务的安全。面对镜像中可能存在的问题，需要对节点上以及仓库中的镜像资产都进行安全扫描，云原生容器安全管理平台针对镜像存在的安全风险，提供了镜像配置风险检测、镜像扫描、镜像成分分析、镜像可信识别、风险镜像运行阻断等能力，实现安全左移，且可接入现有 CI/CD 流程。中国联通云原生安全实践白皮书（2022）-54-镜像配置风险检测镜像配置风险检测：对镜像构建配置 Dockerfile 进行语法性、安全性检测，同时针对镜像的编排配置 Yaml 进行安全性、效率性的检测，杜绝高权限启动、敏感目录挂载等问题，规避由于配置引发的安全风险。镜像扫描能力镜像扫描能力：对镜像可能含有的漏洞、木马病毒、密钥文件、敏感信息等进行安全扫描。基于扫描结果，自动评估出镜像的安全分数与安全等级，清晰明了的定位高风险镜像。镜像成分分析镜像成分分析：将镜像的软件成分进行记录并展示，包括镜像含有的软件、语言框架等。生成镜像的安全溯源，展示镜像的构建历史，快速定位风险。可信识别能力可信识别能力：可基于镜像、基础镜像、镜像仓库三个维度设定可信策略，当镜像来源不可信时，可阻断其运行。镜像阻断镜像阻断：基于漏洞、木马病毒、风险文件、软件许可、特权启动等设定镜像阻断策略，保证上线运行镜像都为可控、可信、安全的。镜像安全能力嵌入 DevOps 流程如图 11 所示，安全运营人员对基础镜像持续的更新加固，开发人员基于加固镜像构建业务镜像（序号 1、2）。业务镜像被推送到测试镜像仓库，平台对仓库新增镜像进行安全检查，运维人员根据检测结果对镜像进行修复（序号 3、4、5）。修复后的镜像再次推送镜像到测试仓库，平台对测试镜像仓库镜像进行二次扫描检查，运维人员确认漏洞已修复后，镜像将被同步到生产镜像仓库（序号 5、6）。平台会检查每一个节点上运行的镜像文件是中国联通云原生安全实践白皮书（2022）-55-否来自于生产仓库，若使用非生产仓库的镜像将会产生告警或阻断（序号 7、8）。图 11 嵌入镜像安全能力的 DevOps 流程4 容器运行时安全4 容器运行时安全容器运行时的安全是容器安全管控的重中之重，传统的入侵检测方式主要针对于主机或者网络层面，无法快速发现针对容器层面的入侵行为。云原生容器安全管理平台提供容器运行时的风险检测、风险预警、风险处置、风险溯源能力，依托这些能力形成安全闭环，平台提供的容器运行时安全检测与防护能力整体工作流程如图 12 所示。中国联通云原生安全实践白皮书（2022）-56-图 12 容器运行时安全监控工作流程风险检测及预警风险检测及预警：通过对已知威胁的实时内置策略检测和未知威胁的行为学习结合的方式，保证容器运行时的安全。内置策略检测内置策略检测是指通过对已知攻击的研究，落地形成针对性的检测规则，内置策略分为命令执行、读写文件、网络活动三大类别。未知威胁行为学习未知威胁行为学习是指对容器的进程、文件、网络、系统调用等进行学习，并辅以人工进行自定义的裁剪，最终形成容器的运行模型，当新的行为偏离模型时，则可进行预警。风险处置风险处置：在检测到风险并确认后，可对发现风险的容器进行紧急的隔离，将影响范围限定在容器范围内，同时可进入容器内部进行溯源，查看攻击现场等。在处理完成后，可将容器暂停，彻底杜绝风险容器流入集群环境。风险溯源风险溯源：云原生容器安全管理平台不但可以保留容器的基本信息，还可对容器运行过程中产生的行为进行保留，对平台内保留的信中国联通云原生安全实践白皮书（2022）-57-息进行分析，可以有效的开展风险溯源工作，确定攻击来源。中国联通云原生安全实践白皮书（2022）-58-五、云原生安全未来发展趋势及展望五、云原生安全未来发展趋势及展望云原生安全赋能“新基建”云原生安全赋能“新基建”：如今，云计算技术正在改变着各行各业的 IT 基础设施存在形态，并且以云计算为代表的新技术基础设施已成为“新基建”的重要组成部分，面对新型基础设施广泛应用所带来的各种新型风险，云原生安全已经成为了各行各业逐渐建设的能力。云原生安全将安全与云原生技术深度融合，赋予安全以零信任、弹性、可编排等能力，必将在未来云安全领域发挥更重要的作用，护航“新基建”行稳致远。从合规趋向于实战对抗：从合规趋向于实战对抗：当前云原生安全建设的驱动力主要是合规性要求，然而安全的本质是对抗，通过安全能力的运营，抵御各类威胁，才是安全的最终目标。随着云原生的广泛应用，攻击者将会更多的使用云原生技术来构建自己的武器库，并利用云原生技术进行攻击。因此，云原生安全的发展，未来将从合规性需求，转移到实战对抗的方向上来，从而为企业的安全防护发挥更重要的作用。云原生安全生态的快速形成：云原生安全生态的快速形成：云原生安全所涉及的范围越来越广，构成越来越复杂。未来，云服务商与安全厂商势必将加强深度合作，结合双方在技术研究、人才储备、产品应用等方面的积累和经验，建设一个更加完善、开放的云原生安全技术环境。中国联通云原生安全实践白皮书（2022）-59-附录 1 英文缩略语附录 1 英文缩略语APIApplication Programming Interface应用程序编程接口K8sKubernetes容器编排引擎IaaSInfrastructure as a Service基础架构即服务PaaSPlatform as a Service平台即服务SaaSSoftware as a Service软件即服务K8s-aaSKubernetes as a ServiceKubernetes 即服务CaaSContainer as a Service容器即服务FaaSFunction as a Service功能即服务DevOpsDevelopment Operation开发、运营DevSecOpsDevelopment Security Operation开发、安全、运营CNCFCloud Native Computing Foundation云原生计算基金会ATT&CKAdversarial Tactics、Techniques andCommon Knowledge对抗战术和技术知识库SBOMSoftware Bill of Materials软件物料清单CNIContainer Network Interface容器网络接口SDNSoftware Defined Network软件定义网络ZTNAZero Trust Network Access零信任网络访问OWASPOpen Web Application Security Project开放式 Web 应用程序安全项目WAFWeb Application Firewalls网站应用级入侵防御系统DOWDenial of Wallet拒绝钱包攻击SASTStatic Application Security Testing静态应用安全测试SCASoftware Composition Analysis软件成分分析IASTInteractiveApplicationSecurityTesting交互式应用安全测试DASTDynamic Application Security Testing动态应用安全测试RASPRuntime Application Self Protection运行时应用程序自保护CIContinuous Integration持续集成CDContinuous Deployment持续部署0dayZero day零日漏洞SQLStructured Query Language结构化查询语言CWPPCloud Workload Protection Platform云工作负载保护平台CSPMCloud Security Platform Management云安全平台管理CIEMCloudInfrastructureEntitlementsManagement云基础设施授权管理CNAPPCloud-NativeApplicationProtectionPlatform云原生应用程序保护平台SDKSoftware Development Kit软件开发工具包CWECommon Weakness Enumeration通用缺陷枚举中国联通云原生安全实践白皮书（2022）-60-附录 2 参考文献附录 2 参考文献1 中国信息通信研究院.研发运营安全白皮书R.北京：中国信息通信研究院,2020.2 中国信息通信研究院.研发运营一体化（DevOps）能力成熟度模型标准 R.北京：中国信息通信研究院,2018.3 中国信息通信研究院.云计算白皮书（2022 年）R.北京：中国信息通信研究院,2022.4 中国信息通信研究院.云计算发展白皮书（2020 年）R.北京：中国信息通信研究院,2020.5 中国信息通信研究院.云计算发展研究J.大数据时代,2020.6 云原生产业联盟 云原生架构安全白皮书（2021）R.北京：云原生产业联盟,2021.7 云原生产业联盟.云原生发展白皮书(2020)R.北京：云原生产业联盟,2020.8 中国联合网络通信有限公司研究院.CU-DevSecOps 实践白皮书R.广州：中国联合网络通信有限公司研究院,2021.9 腾讯云计算（北京）有限责任公司等.“云”原生安全白皮书R.北京：腾讯云计算（北京）有限责任公司,2020.10 绿盟科技等.云原生安全技术报告R.北京：绿盟科技,2020.11 厦门服云信息科技有限公司（安全狗）.云原生安全威胁分析报告R,厦门：厦门服云信息科技有限公司（安全狗），2022.12 360-CERT.安全事件分析报告（2020 下半年）R.北京：360-CERT,2020.13 郭新海,张小梅,刘安,等.云原生应用供应链安全风险防护方案探讨J.信息通信技术,2021,15(4):5.14 丁攀,张小梅,郭新海,等.云原生中的容器技术及其安全配置规范J.信息通信技术,2021,15(4):6.15 刘安,张小梅,郭新海,等.Web 应用代码安全防护方案研究J.信息通信技术,2021,15(6):6.16 RedHat.State of Kubernetes Security Report B/OL.2022.https:/ CNCF.Cloud Native Security Whitepaper(v2)R/OL.2022https:/cf.io/reports/cloud-native-security-whitepaper/18 CNCF.Cloud Native Security.https:/cf.io/cloud-native-security/19 Kubernetes.Overview of Cloud Native Security.https:/kubernetes.io/docs/concepts/security/overview/20 MITRE ATT&CK Containers Matrix.https:/attack.mitre.org/matrices/enterprise/containers/21 Yossi Weizman.Secure containerized environments with updated threat matrix for Kubernetes.https:/ OWASP.OWASP Serverless Top 10.https:/owasp.org/www-project-serverless-top-10/23 OWASP.OWASP API Security Project.https:/owasp.org/www-project-api-security/中国联通云原生安全实践白皮书（2022）-62-战略决策的参谋者技术发展的引领者产业发展的助推者战略决策的参谋者技术发展的引领者产业发展的助推者战略决策的参谋者技术发展的引领者产业发展的助推者战略决策的参谋者技术发展的引领者产业发展的助推者态度、速度、气度有情怀、有格局、有担当中国联通研究院是根植于联通集团（中国联通直属二级机构），服务于国家战略、行业发展、企业生产的战略决策参谋者、技术发展引领者、产业发展助推者，是原创技术策源地主力军和数字技术融合创新排头兵。联通研究院以做深大联接、做强大计算、做活大数据、做优大应用、做精大安全为己任，按照4 1 X 研发布局，开展面向 CUBE-Net 3.0 新一代网络、大数据赋能运营、端网边业协同创新、网络与信息安全等方向的前沿技术研发，承担高质量决策报告研究和专精特新核心技术攻关，致力于成为服务国家发展的高端智库、代表行业产业的发言人、助推数字化转型的参谋部，多方位参与网络强国、数字中国、智慧社会建设。联通研究院现有员工近 700 人，平均年龄36 岁，85%以上为硕士、博士研究生，以“三度三有”企业文化为根基，发展成为一支高素质、高活力、专业化、具有行业影响力的人才队伍。中国联通研究院是根植于联通集团（中国联通直属二级机构），服务于国家战略、行业发展、企业生产的战略决策参谋者、技术发展引领者、产业发展助推者，是原创技术策源地主力军和数字技术融合创新排头兵。联通研究院以做深大联接、做强大计算、做活大数据、做优大应用、做精大安全为己任，按照4 1 X 研发布局，开展面向 C3 网络、大数据赋能运营、端网边业协同创新、网络与信息安全等方向的前沿技术研发，承担高质量决策报告研究和专精特新核心技术攻关，致力于成为服务国家发展的高端智库、代表行业产业的发言人、助推数字化转型的参谋部，多方位参与网络强国、数字中国、智慧社会建设。联通研究院现有员工近 700 人，平均年龄 36 岁，85%以上为硕士、博士研究生，以“三度三有”企业文化为根基，发展成为一支高素质、高活力、专业化、具有行业影响力的人才队伍。中国联通研究院是根植于联通集团（中国联通直属二级机构），服务于国家战略、行业发展、企业生产的战略决策参谋者、技术发展引领者、产业发展助推者，是原创技术策源地主力军和数字技术融合创新排头兵。联通研究院以做深大联接、做强大计算、做活大数据、做优大应用、做精大安全为己任，按照4 1 X 研发布局，开展面向 C3 网络、大数据赋能运营、端网边业协同创新、网络与信息安全等方向的前沿技术研发，承担高质量决策报告研究和专精特新核心技术攻关，致力于成为服务国家发展的高端智库、代表行业产业的发言人、助推数字化转型的参谋部，多方位参与网络强国、数字中国、智慧社会建设。联通研究院现有员工近 700 人，平均年龄 36 岁，85%以上为硕士、博士研究生，以“三度三有”企业文化为根基，发展成为一支高素质、高活力、专业化、具有行业影响力的人才队伍。中国联通研究院是根植于联通集团（中国联通直属二级机构），服务于国家战略、行业发展、企业生产的战略决策参谋者、技术发展引领者、产业发展助推者，是原创技术策源地主力军和数字技术融合创新排头兵。联通研究院以做深大联接、做强大计算、做活大数据、做优大应用、做精大安全为己任，按照4 1 X 研发布局，开展面向 C3 网络、大数据赋能运营、端网边业协同创新、网络与信息安全等方向的前沿技术研发，承担高质量决策报告研究和专精特新核心技术攻关，致力于成为服务国家发展的高端智库、代表行业产业的发言人、助推数字化转型的参谋部，多方位参与网络强国、数字中国、智慧社会建设。联通研究院现有员工近 700 人，平均年龄 36 岁，85%以上为硕士、博士研究生，以“三度三有”企业文化为根基，发展成为一支高素质、高活力、专业化、具有行业影响力的人才队伍。中国联合网络通信有限公司研究院地址：北京市亦庄经济技术开发区北环东路 1 号电话：010-87926100邮编：100176

23人已浏览 2023-03-13 66页 5星级

白皮书借助 IP 满足中国不断演变的云呼叫中心技术需求Scott Durrant，新思科技云业务营销经理序言自从云计算技术在将近 20 年前推出以来，应用和计算资源不断从企业数据中心向云环境持续迁移。IT 基础架构向云端的迁移仍在继续，而据 Gartner 预测，到 2025 年，将有 80%的企业关停传统数据中心，同时，其物理基础架构将完全依赖云提供商而运行（图 1）。随着这一转变的推进，云服务提供商将面临在超大规模云环境中不断提高性能、扩展性和安全性的挑战。为达到所需的服务水平，这些超大规模云服务提供商采用一些工具，包括：增强计算、网络和存储基础架构 用于实现可视化计算和人工智能的新技术 将某些云服务前移到网络边缘图 1：向云基础架构过渡本文将探讨中国片上系统(SoC)开发人员在满足现代云基础架构需求方面所面临的一些挑战，以及可用于开发高效 SoC 解决方案的工具与技术。将关停传统数据中心的企业受访对象的比例资料来源：Gartner（2019年2月）保留所有权利当前2025推动云计算发展的主要趋势推动当前云计算市场发展的主要趋势有三个，而每个趋势都给 SoC 设计人员提出了挑战：云数据快速增长 无处不在地使用人工智能提取数据的含义 云服务向网络边缘扩展我们将在下文依次讨论每一项挑战。云数据的快速增长云数据正以指数级不断增长。受互连设备数量快速增长，流视频、社交媒体上共享的内容日益增多、在线增强现实和虚拟现实(AR/VR)体验以及 5G 无线网络的推动，IDC 预计，从 2020 年至 2025 年，云数据的数量将增长 3 倍。（图 2）图 2：2010-2025 年的全球互联网数据增长数据的增长给 SoC 开发人员带来了几个新的挑战，他们需要在两个方面快速而且有效地搬运大量数据：服务器之间以及服务器内部（即服务器内部设备之间）。这些挑战包括：提高每瓦特的性能，在现有功率/热量范围内增强计算能力 为设备间的数据访问提供高速、一致的芯片接口 在数据中心内部和之间提供低延时的高速联网 提供创新的存储方案，以增加容量并使数据更靠近处理器 保护数据机密性、完整性和可用性广泛使用人工智能提取数据含义云计算的第二个主要趋势是云环境中收集、存储和处理的数据迅速增多。由于数据量大，用于分析和提取数据含义的传统机制已不再能够满足需求。相反，企业纷纷利用人工智能(AI)工具分析数据，包括Web搜索、语言翻译、电子邮件过滤、产品推荐和语音助手等应用。为了促进将人工智能应用于众多服务中，云服务提供商纷纷在云端部署人工智能加速器。据估计，到 2023 年，大多数云服务器都将包含人工智能加速器。1 全球数据的年增长规模180160140120100806040200Zetabytes2010201120122013201420152016201720182019202020212022202320242025175 ZB资料来源：Seagate 赞助的2025 年的数据时代调研，数据来自 IDC全球数据报告。2018 年 11 月要从云端收集并存储的大量数据中有效获取价值，需要对 SoC 和云基础架构进行多项增强，包括：采用高能力、高性能的人工智能加速器进行基于机器的数据分析 利用高带宽内存/数据接口为人工智能加速器提供数据 通过高速、低延时的加速器互连实现人工智能加速器的扩展和数据传输向网络边缘扩展云数据增长的驱动因素之一是连接到云端的物联网设备激增。这些设备中有许多对延时敏感的应用，包括汽车控制系统、图像和语音识别与应答系统、流视频以及增强和虚拟现实应用。为了满足这些应用的最低时延要求，设计人员在边缘的分布式网络中将相关数据和数据处理能力部署到更靠近使用点的位置。随着云的扩展以满足边缘计算需求，SoC 开发人员必须满足边缘计算的新要求，包括：支持日益增多的机器间通信 亚毫秒级应用延时 在远程数据中心的功率限制和可变环境条件下运行 AR/VR 和其它可视化计算应用的加速器针对每个云数据中心市场的专项增强前文所述的挑战可通过增强云计算的六个主要功能领域而解决（图 3）：计算服务器 网络基础架构设备 存储系统 可视化计算解决方案 电信边缘基础架构设备 人工智能/机器学习(AI/ML)加速器服务器网络存储 增强高密度和边缘环境的功率效率 采用更快的接口进行数据传输 受富媒体和高速设备推动，从100GbE向400 GbE过渡 AR/VR、图形和视频内容要求高性能 图片处理 采用下一代PCIe、NVMe、SCM加快 数据访问 采用本地CPU尽量减少数据移动可视化计算边缘基础架构人工智能 云服务向边缘扩展 5G部署推动了更高的数据流量、更 低的延时 在云服务器中部署人工智能加速器，从大量数据集内获取洞察图 3：云计算的六个主要功能领域服务器云数据的增长推动着位于中心的超大规模数据中心和位于网络边缘的远程设施中计算密度不断增加。计算密度的提高需要更节能的 CPU，这样才能在现有数据中心设施的功耗和热量预算范围内提高计算能力。由于对更节能的 CPU 的需求，市场最近对于针对每瓦特性能而优化的基于 ARM 的服务器 CPU 再次表现出了极大的兴趣。数据量的增长对更快的服务器接口提出了需求，因为在服务器内部和服务器之间需要搬运大量数据。服务器内的数据移动可能是主要的瓶颈，也是延时的根源。通过最大限度地减少数据移动，并在数据需要移动时提供高带宽、低延迟接口，这对于最大程度提高性能、减少延时和功耗至关重要。要提高性能，所有内部服务器接口都在进行升级：DDR5 接口的速度提高到 6400 Mbps 当 PCIe 接口从 16GT/s 的 PCIe 4.0 过渡到 32GT/s 的 PCIe 5.0，再到 64GT/s 的 PCIe 6.0 时，其对带宽的需求翻了四倍。由于 PCIe 4.0 未广泛普及，某些设备的带宽会增加更多，因此，某些设备将直接从 PCIe 3.0(8GT/s)转到 PCIe 5.0 或 PCIe 6 NVMe SSD 正从 PCIe 3.0 转向 PCIe 5.0，使带宽增加 4 倍 Compute Express Link(CXL)提供了在 PCIe 电接口上运行的缓存一致性接口，并允许多个处理器/加速器有效共享数据和内存，从而减少系统中需要移动的数据量 通过采用 PAM4 编码并支持多种协议的 56Gbps 和 112Gbps 新型高速 SerDes 技术，可在包括晶片、芯片、加速器与背板的设备之间提供更快的接口除了上面列出的接口之外，多种类型的内存还可以满足不同用例的容量、功耗和性能要求。如果内存容量是主要考虑因素，DDR5则是必选的内存类型。如果内存带宽是最重要的考虑因素，HBM2E则可提供对内存中数据的高速访问，如图4所示。DRAM 容量与带宽1,0005001001,00010,00010容量（GB，对数分度）带宽(GBps)1,5002,000HBM2EDDR58642564,800双 128GB RDIMM8Gb 晶片，8DP16Gb 晶片，8HLPDDR5123286,400HBM2E41,024163,600DDR5LPDDR5DRAM#I/F I/F宽度（DQ比特）每I/F最大容量(GB)速度(Mbps)注释图 4：多种内存类型的容量与最大带宽对比举例来说，图 5 显示了一个服务器的典型框图，该服务器分别配备采用 CXL 和 PCIe 的一致性和非一致性 I/O 接口，以及一个大容量 DDR5 内存接口。为了在处理服务器之间传输的数据时提高性能和效率，许多服务器现在都整合了“智能 NIC”，它包含 NIC 上的嵌入式处理器，用于减轻主机 CPU 上的网络协议、安全功能，SDN 和其他功能的处理负担。智能 NIC 有助于以更高的性能对网络数据包进行处理，同时为应用的处理保留主机 CPU 带宽。具有代表性的智能 NIC 的实施框图如图 6 所示。Synopsys DesignWare IPSynopsys DesignWare IPDDR5/4 或 HBM2e PHY 安全协议加速器 信任根加密AMBA 互连DSPCCIX 或 CXL控制器CCIX或CXL/PCIe PHY USB 3.2 PHY多协议SerDes 1G/10G 多协议SerDes 25G/56G/112GUSB 3.2控制器1G/10G以太网控制器25G/50G/100G 以太网控制器数据包处理加速器NVMe PCIe 控制器PCIe 4.0/5.0 PHYDDR5/4 或HBM2e 控制器L1 和 L2 缓存USBx 以太网通道图 5：典型云服务器框图图 6：智能 NIC 框图Peripheral I/FPCIe 5.0 or 6.0 ControllerInline AES CryptographyPCIe 5.0 or 6.0 PHYStorage I/FPCIe 5.0 or 6.0PHYPCIe 5.0 or 6.0 ControllerNVMeCache Coherent ExpansionCCIX or CXLControllersPCIe 5.0 or 6.0 PHYInline AES CryptographyNetwork I/F56G/112GEthernet PHYs100G/400GEthernet ControllerProcessing SubsystemProcessorsCacheMemory I/FDDR5/4 or DDR5/4 or HBM2/2E PHYInterconnectEmbedded MemoriesLogic LibrariesSecuritySecurity Protocol AcceleratorsCryptographyRoot of TrustDie-to-Die I/F56G or 112G USR/XSR PHYHBI Die-to-Die PHYControllerHBM2/2E ControllerInterconnectAcceleratorsDSPPacket Processing AcceleratorCache Coherent ExpansionCCIX or CXL ControllerPCIe 5.0 or 6.0PHYInline AES CryptographyNetwork I/F56G or 112GEthernet PHYs100GEthernet ControllerProcessing SubsystemARC ProcessorsCacheEmbedded MemoriesLogic LibrariesDie-to-Die I/F56G or 112GUSR/XSR PHYHBI Die-to-DiePHYControllerMemory I/FDDR5/4 or HBM2/2E PHYDDR5/4 or HBM2/2E ControllerSecuritySecurity Protocol AcceleratorsCryptographyRoot of Trust在经历了2019年的些许下降之后，到2023年，服务器市场收入预计将以每年6%的速度增长，如图8所示。但应该注意的是，图 8 中的数据是在新冠肺炎疫情爆发之前预测的结果。IDC 在 2020 年 3 月曾预测，疫情对经济的影响之一是 2020 年全球最终用户的服务器支出同比减少 3.4%，随后将恢复增长，在 2019 年至 2024 年的整体复合年增长率为 4.9%。2 图 8：2016 2024 年全球计算机服务器市场（估计）图 7：按厂商收入排名的 2019 年第 4 季度数据中心服务器市场份额除了更快的接口和更高效的存储器外，保护数据对于云计算同样至关重要。随着数据在云端传输和存储的价值不断提高，数据的不当访问和滥用等方面的威胁也在增加。为了适当地保护授权用户可访问的数据的机密性、完整性和可用性，标准化机构纷纷将安全要求纳入数据接口协议中。要在这些高速接口中实施必需的安全算法，需要用于数据加密和解密的高质量加解密 IP、用于实施高速安全协议的安全协议加速器 IP，以及用于提供信任根和安全密钥管理的可信执行环境。为了避免在各个数据路径中产生瓶颈，用于实现这些功能的 IP 必须能够保持原数据路径线速率运行。数据中心计算服务器市场规模在过去几年间，全球数据中心市场呈现温和增长的态势，IT 支出从 2017 年的 1810 亿美元将增长到 2021 年预期的 2120亿美元（复合年增长率为 4.0%）。如图 8 所示，约三分之一的支出用于服务器系统。截至 2019 年第四季度，按收入计算的前 5 位供应商包括 HPE/New H3C Group 和 Dell Technologies，分别拥有约 16%的市场份额，IBM、浪潮和联想进入前五名。值得指出的是，华为的服务器提供商地位不断增强，由于中国的“一带一路”基础设施项目的推动，有望很快跻身前五名（图 7）。2019 年第 4 季度计算服务器市场份额（按厂商收入排名）HPE/New H3C Group15.9.3.7%9.1%6.8%6.6%5.1%.5ll TechnologiesIBMInspur/Inspur Power SystemsLenovoHuaweiODM Direct数据来源：IDC，2020 年 3 月全球计算机服务器市场销售额（十亿美元）出货量（百万）2019-2024财年的复合年增长率销售额=4.3%出货量=6.6%资料来源：IC Insights中国地区的服务器出货量增长势头强劲，2017 年出货量达到 262 万台服务器，预计到 2022 年，年均增长率达到12.5%（图 9）。网络基础架构如前文所述，数据增长对网络速度提出了更高的要求。许多数据中心正在将从服务器到架顶(ToR)交换机的网络接口速度从 25GbE 提高到 100GbE。在从 ToR 交换机到分支交换机和主干交换机的链路上以及数据中心设施之间安装了400GbE 基础架构。领先的以太网交换机厂商已经在开发基于 112G SerDes 的 800Gbps 交换机，而且随着数据量的持续增长，未来几年可能会推出 1.6Tbps 以太网（图 10）。2017-2022年中国服务器设备出货量（百万台）资料来源iResearch:Statista 2020更多信息：中国：iResearch；2017-2018出货量（百万台）至 TERABIT 的速度高度并行速度（例如QSFP-DD）四倍速（例如QSFP）二倍速（例如SFP-DD）串行速度（例如SFP）链路速度(b/s)标准完成以太网速度 正在开发的速度 可能的未来速度资料来源：以太网联盟，2019 年 图 10：以太网路线图图 9：2017-2022 中国服务器设备出货量支持 400Gbps 以太网端口的基础架构交换机可采用 56G x 8 或 112G x 4 SerDes 电接口，如图 11 所示。数据中心网络基础架构市场规模2019 年，数据中心网络基础架构（主要以全球以太网交换机和路由器市场为代表）与 2018 年相比略有增长，实现总收入 443 亿美元（以太网交换机为 288 亿美元，路由器为 155 亿美元）。华为和 Arista Networks 是前五名企业中在 2019全年相对于 2018 年实现市场份额增长的仅有两家供应商。3 图 12 显示了全球前五名以太网交换机厂商各自的市场份额。目前，中国是仅次于美国的全球第二大云基础架构市场，三家大型云服务提供商占据主导地位：阿里巴巴的云基础架构服务支出超过 46%，腾讯占 18%，百度 AI Cloud 占 8.8%。在 2019 年第四季度，中国云基础架构市场呈现 66.9%的强劲增长势头，达到 33 亿美元，占全球市场的 10.8%。4 Synopsys DesignWare IPx8CPUTCAM/SRAM调度程序2 x 10G以太网控制器25G/50G/100G以太网控制器400G以太网控制器MP SerDes56G/112GMP SerDes10GMP SerDes28G/56G/112G解析程序应用加速器嵌入式存储器逻辑库DDR5/4或HBM2e PHY安全协议加速器PCIe 4.0/5.0 PHY内联 AES 加密PCIe 控制器AMBA 互连带 tRoot 的硬件安全模块TRNG内联 AES 加密内联 AES 加密缓存AMBA 互连数据包处理管理端口32-128 以太网端口图 11：以太网交换机 SoC 框图50.9%9.6%7.0%5.4%3.2#.9 19 年按以太网交换机厂商收入排名的网络市场份额CiscoHuaweiAristaHP EnterpriseJuniper其他资料来源：IDC，2020 年 3 月图 12：2019 年按以太网交换机厂商收入排名的网络市场份额Host I/FPCIe 5.0 or 6.0 ControllerInline AES CryptographyPCIe 5.0 or6.0 PHYLookUpTCAM/SRAMApplication AcceleratorPacket ProcessingSchedulerParsersNetwork I/F56G or 112GEthernet PHYs100G Ethernet Controller200G/400G Ethernet ControllerManagement I/F10GEthernet PHYs10GEthernet ControllerProcessing SubsystemARC ProcessorsCacheEmbedded MemoriesLogic LibrariesDie-to-Die I/F56G or 112G USR/XSR PHYHBI Die-to-Die PHYControllerMemory I/FDDR5/4 or HBM2/2EPHYDDR5/4 or HBM2E ControllerSecuritySecurity Protocol AcceleratorsCryptographyRoot of Trust据Global Industry Analysts公司的数据表明，在2020年至2027年，中国企业网络设备市场将达到8.4%的复合年增长率，到 2027 年，市场规模将达到 205 亿美元。凭借在该细分市场的强劲增长，到本预测周期结束时，中国的企业网络设备市场在全球的份额将达到 21.1%。5 存储存储行业的最新进步要求管理不断增长的数据量，并使用加速器来处理数据。这些进步包括使用计算存储、存储类内存、与持久性存储器连接的缓存一致性接口，以及适用于更高数据传输速度的下一代 NVMe 接口。计算存储系统是智能存储系统，在存储服务器内完成应用处理任务，旨在最大程度减少从存储服务器到计算服务器的网络数据传输。计算存储系统可以查询本地数据库，并且仅将结果集发送到应用/数据库服务器，而不是将大量原始数据发送到应用/数据库服务器进行处理。通过仅发送结果集，计算存储系统可以减少网络负载，使应用处理器能够执行其他任务。存储类内存(SCM)为增强服务器性能提供了一种相对低成本、高性能、持久内存解决方案。SCM 可以根据应用的需求以多种方式部署。例如，使用 SCM 作为附加内存层可以在数据库服务器上实现在内存中进行数据处理，与 NAND 闪存驱动器相比，数据读写性能提高 10 倍或更多（图 14）。图 14：内存和存储层及相对延时图 13：2020-2027 年中国与全球企业网络设备市场规模对比DRAM NAND纳秒级微秒级内存磁带分钟级磁盘毫秒级存储缩短访问延时存储类内存企业网络设备市场规模（10 亿美元）中国资料来源：Global Industry Analysts 公司全球在存储应用中使用缓存一致性接口可以使多个设备在共享内存时保持缓存一致性，从而提高性能，并减少数据移动。Compute Express Link (CXL)就是这样一种接口。基于 PCIe 5.0 的 CXL 1.1 以 32GT/s 的速度为缓存、内存和 I/O 设备提供数据传输。NVMe 存储设备纷纷采用 PCIe 5.0 接口，将 SSD 吞吐量提高到每个 PCIe 通道 4GB/s。与 PCIe 3.0 相比，这一速度提高了 4 倍，目前，x86 服务器中一般都实施了 PCIe 3.0。企业级存储系统市场规模2019 年，企业级外部存储系统 OEM 排名前五位的公司是分别是戴尔、HPE/New H3C Group、IBM、NetApp 和华为（图15）。在 2019 年第 4 季度价值 79 亿美元的全球市场上，戴尔在存储系统市场上的份额遥遥领先，达到 27.6%，而其他四家厂商则占据 7.8%至 10.1%的份额。62020 年，由于新冠肺炎疫情，外部企业级存储系统的支出将下降 5.5%，而据 IDC 预测，2019-2024 年，该市场的整体复合年增长率为 1.3%。7 在中国市场，企业级外部存储销售额在 2019 年达到 40.1 亿美元，同比增长 16.8%。据 IDC 预测，到 2024 年，该细分市场的规模将增长到 63 亿美元8，复合年增长率为 9.46%。图 16 显示了 2019 年中国排名前五的企业级外部存储厂商及其各自的市场份额。27.6.1%9.1%8.9%7.86.5ll TechnologiesHPE/New H3C GroupIBMNetAppHuawei其他2019 年第 4 季度按厂商收入排名的存储系统市场份额资料来源：IDC，2020 年 3 月图 15：2019 年第 4 季度按厂商收入排名的存储系统市场份额图 16：2019 年中国企业级存储市场前五大厂商市场份额资料来源：IDC 中国，2020 年可视化计算随着云应用不断演进，出现了更多可视化内容，对可视化计算的支持已经成为云基础架构的一项额外功能，包括用于商业应用（包括在线协作）和娱乐（例如电影）的流视频、AR/VR 和图像分析（例如 ADAS、安全和其他需要实时图像识别的应用）。可视化计算的激增导致高性能 GPU 集成到云服务器中，并通过高速加速器接口连接到主机 CPU 基础架构，如图 17 所示。边缘基础架构云与边缘的融合将使云服务更靠近最终用户，从而提供更丰富、更高性能和更低的延时体验。同时，随着云服务提供商和电信提供商急于推销本地化、高响应性的服务，这将为他们创造新的商机，因为这些服务过去只能从云核心提供。在过去几年中，连接到互联网的设备数量一直在迅速增加，并且在未来几年中将以更快的速度增长。据 Statistica 估计，2018 年有 220 亿个联网设备，到 2025 年，这一数字将增长到 380 亿以上（图 18）。图 18：2018 年、2025 和 2030 年全球物联网设备数量资料来源：Statistica，2020 年 2 月图 17：基于服务器的图形加速器框图设备数量（10亿）Processing SubsystemGraphics ProcessorCacheInterconnectEmbedded MemoriesLogic LibrariesSecuritySecurity Protocol AcceleratorsCryptographyRoot of TrustCache Coherent Expansion&Host I/FPCIe 5.0 or 6.0 orCXL ControllerPCIe 5.0 or 6.0 PHYInline AES CryptographyDisplay SubsystemDisplayPort PHYDisplayPort ControllerDisplay EngineHDMI PHYHDMI ControllerVideo SubsystemMultimedia EngineDie-to-Die I/F56G or 112GUSR/XSR PHYHBI Die-to-Die PHYControllerMemory I/FHBM2/2E PHYHBM2/2E ControllerGDDR6PHYGDDR6 Controller在这些联网的设备中，很多都是传感器，用于收集数据并将其上传到云端，以分析并确定立即或将要采取的行动。信息安全、交通和物料流管理以及自动驾驶汽车是众多控制系统中的几个例子，而且这些控制系统已经或即将会通过互联网交换信息。特别需要指出的是，对于控制系统，数据必须可靠地传送，而且从收集数据到基于这些数据发出命令几乎不能有延时。换句话说，这些类型的应用需要延时极低的基础架构。要实现对控制系统和其他对延时敏感的应用的快速响应，最佳方法也许是使数据收集、存储和处理基础架构更靠近使用点，即网络边缘（图 19）。因此，我们看到越来越多的云服务提供商与电信公司合作，在多访问边缘计算(MEC)平台中提供云服务。Microsoft Azure9 和 Google Cloud10 已与 AT&T 合作，在 AT&T 的多访问边缘计算站点部署了云基础架构。另外，AWS 与 Sprint 11（现为 T-Mobile）和 Verizon12 合作，通过各自的基础架构部署 AWS 云服务。然而，在边缘基础架构中部署云服务要求运行云服务的设备能够容忍边缘环境，因为边缘环境不一定拥有与典型云数据中心相同的物理空间、环境控制或电力供应。因此，允许的延时越短，服务就越需要部署到边缘，而且允许的功耗也可能越低。人工智能最后，用于数据分析的人工智能已成为云数据中心的重要功能。人工智能加速器在设备中和云端无处不在。人工智能加速器支持执行卷积、递归、尖峰和其他深度神经网络，以支持大量应用。针对云环境的人工智能加速器一般针对 TOPS进行了优化，以提供最高的性能。这些加速器的设计支持扩展，以缩短训练时间并适应最复杂的人工智能算法（支持超过 80 亿个参数）。由于人工智能加速器倾向于处理大量数据，因此，内存接口通常是瓶颈所在，这使得高带宽内存对于这些设备特别有益（图 20）。地区数据中心边缘云边缘计算现场服务器本地服务器聚合器网关/接入10us-1ms 延时1ms-5ms 延时5ms-10ms 延时 网络 SoC存储存储存储存储存储存储AI加速器128-512 TOPSAI加速器64-128 TOPS本地服务器SoC65W基带/WiFi/网络 SoCAI 加速器16-64 TOPS网关服务器SoC30W服务器 SoC100W网络 SoC图 19：边缘计算分层图 20：有代表性的云托管式人工智能加速器框图AI AcceleratorNeural Network ProcessorsCacheMemory I/FHBM2/2EPHYInterconnectEmbedded MemoriesLogic LibrariesCache Coherent ExpansionCCIX or CXL ControllerPCIe 5.0 or 6.0PHYInline AES CryptographySecuritySecurity Protocol AcceleratorsCryptographyRoot of TrustNetwork I/F100G or 400G Ethernet Controller56G or 112G Ethernet PHYsDie-to-Die I/F56G or 112G USR/XSR PHYHBI Die-to-Die PHYControllerHBM2/2EController针对边缘计算（尤其是聚合器和网关应用）的人工智能加速器通常针对每瓦性能(TOPS/W)进行了优化，以解决边缘基础架构和服务的功耗与延时问题。这些设备具有较高的计算能力和相对简单的软件模型，能够提供快速响应能力。它们往往为实现低成本和低功耗而进行了优化，而这通常会要求使用低功耗 DDR(LPDDR)内存。为了支持人工智能解决方案的扩展，加速器必须包含一个高速接口，例如 56Gbps 或 112Gbps SerDes 或 HBI。芯片间的高速接口提供了加速器缩放和扩展能力，可满足苛刻的人工智能应用的需求。开放计算项目(OCP)组织正在推动芯片间互连的标准化（开放计算项目-ODSA 子项目，2020 年）13，旨在简化并改善加速器扩展接口的互操作性。这一工作的目的是为异构“小芯片”提供一个通用接口，从而使用通用功能构块来开发SoC。如果被业界采用，这项工作可缩短这些 SoC 的开发时间，降低开发和制造成本，从而简化加速器 SoC 的开发流程。适用于云基础架构的 IP 解决方案新思科技提供了高质量且经过硅验证的全面 IP 产品组合，使设计人员能够开发支持当前和未来云计算应用的 SoC。新思科技的 DesignWare 接口 IP、处理器 IP、安全 IP 和基础 IP 针对高性能、低延时和低功耗进行了优化，同时支持从16nm 到 5nm FinFET 的先进处理技术。新思科技针对云 SoC 的全面 IP 产品组合包括：DDR5/4 内存控制器和 PHY：提供一流的性能，数据速率高达 DDR5-6400，引入了 DDR5 相位感知调度引擎，与竞争对手相比，面积减少了 15%，功耗降低 10%HBM2/2E 内存 PHY：具有业界领先的面积和功耗，并且功耗比竞争对手的 IP 低 802G 多协议 SerDes：以 5.5pJ/比特的速率支持多种数据速率（1.25 至 112 Gbps）112G USR/XSR SerDes 和 HBI 接口：针对芯片间接口进行了面积优化 400G 和 800G 以太网解决方案为超大规模数据中心、网络和 AI SoCs 提供真正的长距离性能 新的 PCIe 6.0 IP 和当前的 PCIe 5.0 IP 解决方案：经过硅验证，并已被 90%的领先半导体公司使用 CXL 解决方案：基于新思科技经过硅验证的 PCIe 5.0 IP 而构建，可降低集成风险，其中包括用于验证 I/O、内存访问和一致性协议功能的 VC 验证 IP ARC HS处理器：提供从1到12个CPU内核的业界领先的扩展性，并支持多达16个用户硬件加速器，以适应极端工作负载 高能效 CCIX PHY 和最低 延时的控制器 USB 3.0、USB 3.1、USB 3.2 和 USB4 解决方案：具有行业领先的低功耗和小面积实施能力，在数百万 SoC 中提供了经验证的互操作性，并且降低设计风险 高质量、经过硅验证的基础IP：包括内存编译器和非易失性存储器(NVM)、逻辑库、通用I/O(GPIO)和测试解决方案，使片上系统(SoC)设计人员能够 降低集成风险，并加快产品上市速度 TCAM 和多端口内存：支持用于网络和其他应用的高速、低功耗网络解决方案 ASIP Designer：通过基于 C/C -编译器的高效软件开发套件而开发定制加速器，该套件可自动适应每种体系架构的变更，并自动生成针对功耗和面积而优化的可合成的 RTL 安全 IP：包括安全协议加速器、加密加速器、PCIe/CXL IDE 和信任根 IP，可为云计算和其他市场中的多种产品提供最高效的芯片设计和最高的安全性新思科技 DesignWare IP 产品组合是市场上最广泛的产品组合，涵盖大多数云 SoC 芯片中的绝大多数 IP。采用 DesignWare IP 保证流片成功新思科技 DesignWare IP 已被部署到数千种设计中，可帮助设计人员缩短全球云计算应用投入生产运行的时间。选择 DesignWare IP 作为云环境 SoC 的关键构件的领先公司包括 Habana Labs（英特尔旗下公司），该公司采用新思科技 DesignWare 控制器和 PHY IP for PCI Express 4.0 实现其 Goya 推理处理器 SoC 的首次流片成功。Habana Labs 的首席业务官Eitan Medina表示：“经过全面的评估，我们选择了新思科技领先的16 GT/s DesignWare IP for PCI Express 4.0，这是因为该产品在业界口碑良好，并且拥有最苛刻的数据密集型 SoC 所需要的先进功能。”Starblaze Technology 也使用 DesignWare IP 实现了 STAR1000 SSD 控制器的首次流片成功并投入批量生产。使用DesignWare ARC 处理器、基础 IP、安全 IP 和接口 IP，Starblaze 能够将功耗和 I/O 延时减少 50%，使 SoC 面积减少7%，并通过最佳的功耗、性能和面积组合实现了最高的安全性。Starblaze Technologies首席执行官Sky Shen表示：“新思科技广泛的 DesignWare IP 产品组合使我们能够获得所需的全部 IP，从而保证我们的 SSD 控制器实现首次流片成功。”AMD 通过新思科技的 DesignWare IP 产品组合交付了 Ryzen 和 EPYC 处理器。AMD 公司 I/O 和电路技术高级总监Rolands Ezers 表示：“通过选择具有定制功能的 DesignWare IP，我们能够按时完成计划，而且使我们的路线图得以实现。”DesignWare IP 使 AMD 凭借 EPYC 服务器和 Ryzen PRO 桌面处理器击败竞争对手。它还提供了标准和定制的 IP解决方案，而且这些解决方案提供了我们所需的功能、性能、功耗和面积。此外，新思科技经验丰富的设计团队还可以帮助 AMD 工程师满足紧张的开发和测试期限要求，支持其按原计划交付产品。展望下一代协议，Achronix 和 Astera Labs 等公司已经宣布，它们已将 DesignWare PCIe 5.0 用于高性能云的设计。总结云计算的演进为 SoC 开发人员带来了许多新的机遇和挑战。这种技术引发的一些关键变化包括互联网中传输以及云端存储或使用的数据量快速增长，云服务向网络边缘的扩展，以及为处理海量数据并从中获取洞察而广泛部署的人工智能。随着机器间的通信、流视频、增强现实和虚拟现实以及其他应用生成越来越多的数据，云基础架构必须不断增强，以最大程度减少需要移动的数据，并最大程度加快从一个位置向另一位置传输数据的速度，无论是长距离传输，还是服务器内部的一个芯片传输到另一个芯片。随着互联网用户和联网设备数量不断增多，互联网上数据的快速增长要求采用新的机制而减少数据移动，并加快数据从一个位置向另一位置的传输。借助高质量、经过硅验证的 IP 构件，设计人员能够开发用于高端云计算解决方案的 SoC，包括服务器、网络、存储、可视化计算、边缘计算和人工智能加速器应用。1“深度学习处理器指南”，The Linley Group，2019 年 1 月。2 IDC 全球季度服务器跟踪，2020 年 3 月 26 日。3 IDC 全球季度以太网交换机和路由器跟踪显示 2019 年第四季度市场疲软，2020 年 3 月 11 日4 Techcrunch，这个云基础架构市场 2019 年第 4 季度创收 33 亿美元，2020 年 3 月，2020 年 3 月 18 日，2020 年 4 月 16 日引用。5 Global Industry Analysts 公司。“企业级网络设备全球市场发展与分析”，2020 年 6 月 29 日引用。6 IDC，“据 IDC 调查，2019 年第 4 季度，全球企业级外部 OEM 存储系统市场收入下滑 0.1%”。2020 年 3 月。7 IDC 全球季度企业级存储系统跟踪，2020 年 3 月 26 日。8 “华为在中国企业级存储市场排名第一”2020 年 4 月。9“AT&T与Microsoft宣布结成战略联盟”，https:/ 年 4 月 14 日引用。10“AT&T 与 Google Cloud 携手推动企业采用网络边缘 5G 计算解决方案”。https:/ 年 3 月 5 日，2020 年 4 月 14 日引用。11“Amazon Web Services 将其云服务与 Sprint 的 Curiosity IoT 平台集成，向网络边缘提供可行的智能”，https:/ 年 2 月 25 日，2020 年 4 月 14 日引用。12“AWS 与 Verizon 携 手 提 供 5G 边 缘 云 计 算”，https:/ 年 12 月 3 日，2020 年 4 月 14 日引用。13 开放计算项目，ODSA 子项目，2020 年 6 月 19 日引用。2021 Synopsys,Inc.版权所有。保留所有权利。Synopsys 是 Synopsys,Inc.在美国和其他国家的商标。Synopsys 商标列表可从 获得。本文提及的所有其他名称均为其各自所有者的商标或注册商标。07/16/20.CS529828393 SG|云基础架构白皮书。发布日期：2021 年 6 月

5人已浏览 2023-03-13 15页 5星级

曦智研究院2023年3月大规模光电集成赋能智能算力网络白皮书目前，业界针对数据中心算力和算效的提升已做出大量的努力。其中，算力网络（Computing Power Network）的理念在全球范围内得到了广泛认可6。算力网络是一种根据业务需求，按需分配和灵活调度计算、存储以及网络等资源的新型信息基础设施。其终极目标是将硬件资源抽象化为算力，用户可根据实际的计算需求向数据中心购买算力，而无需购买或租赁硬件设备，从而实现像使用水、电、气一样便捷地使用算力。因此，国外也有文献把这个算力网络概念称为Utility Computing7。为实现这一愿景，算力网络需要具备众多高效的计算节点和节点间高效的数据互连。单节点内的纵向算力提升，为算力网络提供高效的计算资源。在此基础上，通过高效的数据互连，横向拓展算力，从而总体上形成庞大的算力容量。算力网络不仅能够帮助解决算力的利用率和扩展性问题，而且可以解决算力迁移和易用性问题，通过硬件资源的灵活调度，实现算力网络内更细粒度的资源共享。本章将简要介绍目前业界在纵向算力提升和横向算力拓展两方面的主要工作及面临的挑战。2.1 单节点算力纵向提升数据中心内，以一到两个CPU为核心的单个服务器通常被看作一个计算节点。在晶体管密度提升放缓的背景下，制程工艺迭代所能带来的性能提升愈发有限，单个节点的算力提升出现了多种思路。首先是通过芯片架构创新降低相对于CPU的通用性来换取超越CPU的计算效率。在此基础上，一些研究者寻求跳出传统的冯诺依曼范式和 CMOS晶体管技术，用颠覆性的新原理来获得超越摩尔定律的算力提升。另一种思路是通过在单个封装内容纳多个芯粒（Chiplet）来超越倍缩光罩（Reticle）导致的单芯片尺寸上限，从而获得更高的算力。2.1.1 异构计算架构创新早期的计算架构创新以通用计算架构为主，主要以提升指令级别并行（Instruction-Level Parallelism，ILP）为驱动力，尽最大努力挖掘摩尔定律带来的片上晶体管资源红利。例如，超标量CPU架构利用晶体管资源优势来使能从指令单发到多发（乱序发射乱序执行）再到更深的流水管线，针对单元数据实现了更多计算操作。同时，流水线管线加深有利于减少每一个阶段的计算操作，从而实现CPU频率的大幅提升。随着半导体工艺的演进，芯片面积的增大也使得芯片上可以集成更多的逻辑功能，包括更大和更多层的数据缓冲、数据预取等功能块，从而改善由于计算和内存速度的不均衡发展所产生的“内存墙”问题。近期，大规模、高效的数据迁移已成为突破单节点算力瓶颈的新动力。例如高带宽内存架构（High Bandwidth Memory，HBM）等创新技术，通过提高数据传输过程中的效率，为计算架构带来新一轮的性能提升。这一趋势在谷歌对其几代张量加速器（Tensor Processing Unit，TPU）架构演进的总结里有很好的反映8。最后，资源红利也赋能了计算架构朝着超线程、多核，再到以背景执行环境为支撑的成千上万个众线程架构方向发展。同时，加上数据向量化和单指令多数据流（Single Instruction Multiple Data，SIMD）等技术，这种线程级别并行（Thread-Level Parallelism，TLP）为计算架构性能带来多个数量级的飞跃。在上述通用计算架构的基础上，领域专用架构（Domain Specific Architecture,DSA）获得了长足的发展。随着人工智能、5G、自动驾驶、VR/AR等创新技术的涌现，不同应用场景对芯片算力、功能、功耗、成本、安全性等方面的需求日渐分化，算力需求多元化趋势下，领域专用架构应运而生。领域专用架构是针对某个应用领域的特殊性而定制设计的专用架构，包括特殊的计算单元、并行机制、数据类型和领域专用语言等。领域专用架构通过牺牲架构的通用性来加速应用性能，从而把硬件的原生计算能力更高效地发挥出来，同时实现比通用计算架构更好的节能效果。以英伟达最新发布的Hopper图形加速器（Graphics Processing Unit，GPU）架构9为例，其在典型的TLP架构的基础上，使用了更多、更强大的张量加速核（Tensor Core），并在张量加速核内部增加了更多有助于算力纵向提升的领域专用技术，包括细粒度的结构化稀疏计算和动态编程算法优化等。相对于上一代A100 GPU，基于Hopper架构的H100 GPU在AI训练任务集上约有24倍的性能提升。另一个比较典型的领域专用加速器是谷歌的张量处理器（TPU）。该加速器的脉动阵列模块是针对矩阵乘法优化的设计，通过增加对单位数据的多重计算，在缓解“内存墙”效应的同时，显著提升计算密度。然而，领域专用架构的定制化特征，通常使得其本身缺乏计算完备性。异构计算架构则是把CPU和多类DSA有机地结合在一起，通过让每一个DSA在自己擅长的领域内发挥出最大性能，从整体上实现最高性能和最佳能效。领域专用架构在取得大幅度算力提升的同时，依然受限于传统底层元器件以及冯诺伊曼架构。传统计算芯片的底层元器件是基于硅晶圆的CMOS晶体管，核心的工作原理是由电压信号来控制晶体管内的电流。随着CMOS制程的提升，晶体管的尺寸越来越小，量子隧穿效应使得控制电流的效率降低。突破这一瓶颈需要新的底层计算原理。同时，传统的计算硬件设计通常基于冯诺伊曼架构，即计算和数据分离架构，通过顺序控制逻辑把数据搬运到计算单元再执行计算。这种架构的主要问题是数据迁移导致了计算延迟以及处理单位数据时的功耗变大，暴露出“内存墙”问题。尽管现代架构通过向量化、超线程技术、流水线并行和多核架构的不断创新来提升性能，但冯诺伊曼架构的潜力空间越来越小。随着计算架构不断创新，非冯诺伊曼架构也开始出现百花齐放的趋势。这一类非基于顺序控制流执行的颠覆性计算架构（例如生物计算和量子计算），或为了克服冯诺伊曼架构的核心瓶颈而衍生出的架构（例如基于忆阻器的存内计算），通过崭新的计算模式创造了巨大的性能和能效提升空间。例如，基于3D混合封装的近内存计算引擎10，通过把多存储体内存直接连接到计算逻辑单元，让AI加速器在推荐模型上的性能大幅提升。2.1.2 芯粒系统由于晶体管密度提高的减缓，单个封装内的底层算力提升只能通过扩大芯片总面积实现。但芯片尺寸不可能无限大，在CMOS工艺的限制下，受限于倍缩光罩的尺寸，单个芯片的最大面积一般在800mm2左右。要进一步扩大芯片总面积，则需另辟蹊径，来突破单个芯片的面积上限，芯粒系统的新思路由此逐渐兴起。得益于先进封装技术的进步，将满足不同特定功能的多个芯粒封装在同一个基板上成为了可能。近年来，世界领先的芯片企业已经越来越多地将芯粒架构应用在高端计算系统里。例如，英特尔的Ponte Vecchio GPU11由超过40个芯粒组成，总面积超过了3,000mm2。Cerebras Systems的晶圆级计算引擎（Wafer Scale Engine，WSE）12总面积超过了40,000mm2，是当前倍缩光罩面积的50倍。除了提升芯片总面积之外，芯粒具有模块化特性，即来自不同晶圆厂、采用不同制程节点的芯粒可以按需组合，因此不仅具有解耦架构设计的灵活性，而且在大幅提升芯片工艺制程的良率的同时，有效降低制造成本。由于实现了芯片内部的领域专用异构计算，芯粒架构能够更高效地片上适配各种计算任务。目前的芯粒系统产品依然以私有架构为主。多个工业组织正在积极推动芯粒互连标准（例如UCIe和BOW），以发展片上异构计算。其中不乏行业巨头，如2021年谷歌发布了开放式芯粒（Open Chiplet）计算架构13，进一步推动芯粒技术生态的发展。然而，芯片总面积变大，会导致数据搬运的时间和能耗成本随之增加。电在进行数据传输的过程中，对能耗、片上面积等资源的消耗随着距离的增长而提高。在纯数字电路中，为了减小数据搬运的消耗，每个计算单元一般只会与其最邻近的计算单元进行数据传输，因此，跨越多个计算单元的数据搬运需要多次跳跃。同时，较大的计算任务通常会被映射到多个计算单元，为了避免长距离数据搬运，需使用非常复杂的算法来优化计算任务的映射。2.2 多节点算力横向扩展2.2.1 目前大规模分布式技术的挑战单个计算节点的架构创新和算力提升，并不能满足日益增长的大规模算力需求。数据中心一般需要部署数以万计的计算设备，而多个计算节点简单堆叠和组合往往会产生网络拥塞现象，特别是在数据密集型场景下，多个并行任务在通信网络中相互冲突，会造成大量额外的延时和性能损耗，导致整体系统的资源利用率不高。大部分数据中心的计算架构多根据接近于峰值时段的算力需求进行硬件规划，而其峰值算力需求通常比平时高出几倍，甚至数十倍。阿里巴巴官方公布的数据显示14，2017年“双11”实时数据处理峰值为4.72亿条/秒，是日常实时处理峰值（0.4亿条/秒）的10倍。因此，如果根据峰值算力需求进行硬件规划和部署，很容易造成设备闲置。另外，数据中心服务器内部的CPU、GPU和内存等资源配置比较固化，但不同计算任务对资源的需求又不尽相同，数据中心硬件配置一旦固定，由于算力无法灵活调度，其使用率在大部分时间内都相对较低。根据阿里云数据中心和字节跳动对GPU使用率的观测结果15,16，以GPU整卡为单位，其使用率大概在40%左右。若细分到以GPU内部的流式多处理器（Streaming Multiprocessor，SM）为使用单位，则资源利用率仅为10%左右。更好的做法是将计算资源整合，通过精细化管理，以灵活高效的方式分配给计算任务。这种思路通常被称为资源池化。传统模式的资源池化，包括计算池化和内存池化，主要集中在单计算节点之内的资源共享。这种共享模式通过虚拟机监控程序（Hypervisor）技术把CPU、内存等资源切分给不同的虚拟机，并实现多租户的虚拟机在物理主机上的资源隔离和共享。因此，传统池化模式没有突破单计算节点的物理边界，不能发挥出大规模计算节点间的资源共享优势。综上，传统服务器架构的挑战可以被总结为以下几点：随着数字经济时代的到来，万物感知、万物互联和万物智能对计算的需求呈现爆发性增长和多样化态势。人工智能、大数据和元宇宙等新兴领域的快速崛起，加速推动了全球数据总量和算力规模的高速增长。算力已成为推动数字经济高速发展的核心动力，对促进行业数字化转型以及支撑经济社会发展发挥着极其重要的作用。当前算力发展面临应用多元化、供需不平衡的挑战。未来的算力系统需要更系统化的设计思维以及更多样化的计算架构。同时，颠覆性计算技术也将不断从理论走向实践，取得突破与进展。光电集成技术有望突破现有计算系统在数据处理、搬运和存储上的瓶颈，为未来算力网络的发展提供一种更加高效的解决方案。这份白皮书围绕提升数据中心算力和算效的目标，聚焦所面临的关键问题与挑战，阐述了业界当前基于大规模光电集成技术的算力网络新趋势。同时，对于科研人员和业内人士具有很好的技术启示和产业洞察的意义。大规模光电集成技术的发展和进步，需要政府、高校、科研机构、企业等“政产学研用”多方力量发挥各自优势，融合创新，协同共进。让我们紧密携手，一起努力，期待光电集成技术为智能算力网络的发展做出更多贡献。李儒新院士目前，业界针对数据中心算力和算效的提升已做出大量的努力。其中，算力网络（Computing Power Network）的理念在全球范围内得到了广泛认可6。算力网络是一种根据业务需求，按需分配和灵活调度计算、存储以及网络等资源的新型信息基础设施。其终极目标是将硬件资源抽象化为算力，用户可根据实际的计算需求向数据中心购买算力，而无需购买或租赁硬件设备，从而实现像使用水、电、气一样便捷地使用算力。因此，国外也有文献把这个算力网络概念称为Utility Computing7。为实现这一愿景，算力网络需要具备众多高效的计算节点和节点间高效的数据互连。单节点内的纵向算力提升，为算力网络提供高效的计算资源。在此基础上，通过高效的数据互连，横向拓展算力，从而总体上形成庞大的算力容量。算力网络不仅能够帮助解决算力的利用率和扩展性问题，而且可以解决算力迁移和易用性问题，通过硬件资源的灵活调度，实现算力网络内更细粒度的资源共享。本章将简要介绍目前业界在纵向算力提升和横向算力拓展两方面的主要工作及面临的挑战。2.1 单节点算力纵向提升数据中心内，以一到两个CPU为核心的单个服务器通常被看作一个计算节点。在晶体管密度提升放缓的背景下，制程工艺迭代所能带来的性能提升愈发有限，单个节点的算力提升出现了多种思路。首先是通过芯片架构创新降低相对于CPU的通用性来换取超越CPU的计算效率。在此基础上，一些研究者寻求跳出传统的冯诺依曼范式和 CMOS晶体管技术，用颠覆性的新原理来获得超越摩尔定律的算力提升。另一种思路是通过在单个封装内容纳多个芯粒（Chiplet）来超越倍缩光罩（Reticle）导致的单芯片尺寸上限，从而获得更高的算力。2.1.1 异构计算架构创新早期的计算架构创新以通用计算架构为主，主要以提升指令级别并行（Instruction-Level Parallelism，ILP）为驱动力，尽最大努力挖掘摩尔定律带来的片上晶体管资源红利。例如，超标量CPU架构利用晶体管资源优势来使能从指令单发到多发（乱序发射乱序执行）再到更深的流水管线，针对单元数据实现了更多计算操作。同时，流水线管线加深有利于减少每一个阶段的计算操作，从而实现CPU频率的大幅提升。随着半导体工艺的演进，芯片面积的增大也使得芯片上可以集成更多的逻辑功能，包括更大和更多层的数据缓冲、数据预取等功能块，从而改善由于计算和内存速度的不均衡发展所产生的“内存墙”问题。近期，大规模、高效的数据迁移已成为突破单节点算力瓶颈的新动力。例如高带宽内存架构（High Bandwidth Memory，HBM）等创新技术，通过提高数据传输过程中的效率，为计算架构带来新一轮的性能提升。这一趋势在谷歌对其几代张量加速器（Tensor Processing Unit，TPU）架构演进的总结里有很好的反映8。最后，资源红利也赋能了计算架构朝着超线程、多核，再到以背景执行环境为支撑的成千上万个众线程架构方向发展。同时，加上数据向量化和单指令多数据流（Single Instruction Multiple Data，SIMD）等技术，这种线程级别并行（Thread-Level Parallelism，TLP）为计算架构性能带来多个数量级的飞跃。在上述通用计算架构的基础上，领域专用架构（Domain Specific Architecture,DSA）获得了长足的发展。随着人工智能、5G、自动驾驶、VR/AR等创新技术的涌现，不同应用场景对芯片算力、功能、功耗、成本、安全性等方面的需求日渐分化，算力需求多元化趋势下，领域专用架构应运而生。领域专用架构是针对某个应用领域的特殊性而定制设计的专用架构，包括特殊的计算单元、并行机制、数据类型和领域专用语言等。领域专用架构通过牺牲架构的通用性来加速应用性能，从而把硬件的原生计算能力更高效地发挥出来，同时实现比通用计算架构更好的节能效果。以英伟达最新发布的Hopper图形加速器（Graphics Processing Unit，GPU）架构9为例，其在典型的TLP架构的基础上，使用了更多、更强大的张量加速核（Tensor Core），并在张量加速核内部增加了更多有助于算力纵向提升的领域专用技术，包括细粒度的结构化稀疏计算和动态编程算法优化等。相对于上一代A100 GPU，基于Hopper架构的H100 GPU在AI训练任务集上约有24倍的性能提升。另一个比较典型的领域专用加速器是谷歌的张量处理器（TPU）。该加速器的脉动阵列模块是针对矩阵乘法优化的设计，通过增加对单位数据的多重计算，在缓解“内存墙”效应的同时，显著提升计算密度。然而，领域专用架构的定制化特征，通常使得其本身缺乏计算完备性。异构计算架构则是把CPU和多类DSA有机地结合在一起，通过让每一个DSA在自己擅长的领域内发挥出最大性能，从整体上实现最高性能和最佳能效。领域专用架构在取得大幅度算力提升的同时，依然受限于传统底层元器件以及冯诺伊曼架构。传统计算芯片的底层元器件是基于硅晶圆的CMOS晶体管，核心的工作原理是由电压信号来控制晶体管内的电流。随着CMOS制程的提升，晶体管的尺寸越来越小，量子隧穿效应使得控制电流的效率降低。突破这一瓶颈需要新的底层计算原理。同时，传统的计算硬件设计通常基于冯诺伊曼架构，即计算和数据分离架构，通过顺序控制逻辑把数据搬运到计算单元再执行计算。这种架构的主要问题是数据迁移导致了计算延迟以及处理单位数据时的功耗变大，暴露出“内存墙”问题。尽管现代架构通过向量化、超线程技术、流水线并行和多核架构的不断创新来提升性能，但冯诺伊曼架构的潜力空间越来越小。随着计算架构不断创新，非冯诺伊曼架构也开始出现百花齐放的趋势。这一类非基于顺序控制流执行的颠覆性计算架构（例如生物计算和量子计算），或为了克服冯诺伊曼架构的核心瓶颈而衍生出的架构（例如基于忆阻器的存内计算），通过崭新的计算模式创造了巨大的性能和能效提升空间。例如，基于3D混合封装的近内存计算引擎10，通过把多存储体内存直接连接到计算逻辑单元，让AI加速器在推荐模型上的性能大幅提升。2.1.2 芯粒系统由于晶体管密度提高的减缓，单个封装内的底层算力提升只能通过扩大芯片总面积实现。但芯片尺寸不可能无限大，在CMOS工艺的限制下，受限于倍缩光罩的尺寸，单个芯片的最大面积一般在800mm2左右。要进一步扩大芯片总面积，则需另辟蹊径，来突破单个芯片的面积上限，芯粒系统的新思路由此逐渐兴起。得益于先进封装技术的进步，将满足不同特定功能的多个芯粒封装在同一个基板上成为了可能。近年来，世界领先的芯片企业已经越来越多地将芯粒架构应用在高端计算系统里。例如，英特尔的Ponte Vecchio GPU11由超过40个芯粒组成，总面积超过了3,000mm2。Cerebras Systems的晶圆级计算引擎（Wafer Scale Engine，WSE）12总面积超过了40,000mm2，是当前倍缩光罩面积的50倍。除了提升芯片总面积之外，芯粒具有模块化特性，即来自不同晶圆厂、采用不同制程节点的芯粒可以按需组合，因此不仅具有解耦架构设计的灵活性，而且在大幅提升芯片工艺制程的良率的同时，有效降低制造成本。由于实现了芯片内部的领域专用异构计算，芯粒架构能够更高效地片上适配各种计算任务。目前的芯粒系统产品依然以私有架构为主。多个工业组织正在积极推动芯粒互连标准（例如UCIe和BOW），以发展片上异构计算。其中不乏行业巨头，如2021年谷歌发布了开放式芯粒（Open Chiplet）计算架构13，进一步推动芯粒技术生态的发展。然而，芯片总面积变大，会导致数据搬运的时间和能耗成本随之增加。电在进行数据传输的过程中，对能耗、片上面积等资源的消耗随着距离的增长而提高。在纯数字电路中，为了减小数据搬运的消耗，每个计算单元一般只会与其最邻近的计算单元进行数据传输，因此，跨越多个计算单元的数据搬运需要多次跳跃。同时，较大的计算任务通常会被映射到多个计算单元，为了避免长距离数据搬运，需使用非常复杂的算法来优化计算任务的映射。2.2 多节点算力横向扩展2.2.1 目前大规模分布式技术的挑战单个计算节点的架构创新和算力提升，并不能满足日益增长的大规模算力需求。数据中心一般需要部署数以万计的计算设备，而多个计算节点简单堆叠和组合往往会产生网络拥塞现象，特别是在数据密集型场景下，多个并行任务在通信网络中相互冲突，会造成大量额外的延时和性能损耗，导致整体系统的资源利用率不高。大部分数据中心的计算架构多根据接近于峰值时段的算力需求进行硬件规划，而其峰值算力需求通常比平时高出几倍，甚至数十倍。阿里巴巴官方公布的数据显示14，2017年“双11”实时数据处理峰值为4.72亿条/秒，是日常实时处理峰值（0.4亿条/秒）的10倍。因此，如果根据峰值算力需求进行硬件规划和部署，很容易造成设备闲置。另外，数据中心服务器内部的CPU、GPU和内存等资源配置比较固化，但不同计算任务对资源的需求又不尽相同，数据中心硬件配置一旦固定，由于算力无法灵活调度，其使用率在大部分时间内都相对较低。根据阿里云数据中心和字节跳动对GPU使用率的观测结果15,16，以GPU整卡为单位，其使用率大概在40%左右。若细分到以GPU内部的流式多处理器（Streaming Multiprocessor，SM）为使用单位，则资源利用率仅为10%左右。更好的做法是将计算资源整合，通过精细化管理，以灵活高效的方式分配给计算任务。这种思路通常被称为资源池化。传统模式的资源池化，包括计算池化和内存池化，主要集中在单计算节点之内的资源共享。这种共享模式通过虚拟机监控程序（Hypervisor）技术把CPU、内存等资源切分给不同的虚拟机，并实现多租户的虚拟机在物理主机上的资源隔离和共享。因此，传统池化模式没有突破单计算节点的物理边界，不能发挥出大规模计算节点间的资源共享优势。综上，传统服务器架构的挑战可以被总结为以下几点：2.1 单节点算力纵向提升2.1.1 异构计算架构创新2.1.2 芯粒系统3.2.1 物理层创新3.2.2 互连协议创新3.1.1 颠覆性计算新原理：光子矩阵计算（oMAC）3.1.2 助力高效芯粒系统：片上光网络（oNOC）2.2.1 目前大规模分布式技术的挑战2.2.2 可重构算力池化技术3.1 单节点算力提升方案2.2 多节点算力横向扩展2.3 算力网络发展关键挑战3.3 算力网络新范式3.2 多节点算力扩展方案：片间光网络（oNET）0304061517111407081107091815大规模光电集成赋能智能算力网络1然而，计算芯片的传统算力增长路径已经遇到了瓶颈。半导体产业发展60多年以来，算力提升长期遵循两个定律摩尔定律和登纳德缩放比例定律。摩尔定律提出晶体管的密度每18个月会翻一倍；而根据登纳德缩放比例定律2，晶体管在密度提升的同随着智慧交通、工业大脑、自动驾驶、物联网等人工智能（AI）应用的逐步推广和普及，人类社会每天都会产生包括语音、图像、视频等海量的数据。从这些数据中分析和提取有价值的信息，需要匹配强大的数据存储、传输和处理能力，这对当前的数据中心和边缘设备的计算能力提出了前所未有的挑战。与此同时，AI应用为了提高信息捕捉的质量和精度，其模型本身也在不断演进，参数规模与日俱增。模型参数的增加也意味着对模型的每单位数据输入形成了更大强度的计算需求。据OpenAI网站公布的数据，如图1所示，近年来，最先进的AI模型的大小按每年10倍的指数型增长，同时因数据量爆炸，AI模型训练的计算能力需求以每年10倍的速度提升1。2.2 多节点算力横向扩展2.2.1 目前大规模分布式技术的挑战单个计算节点的架构创新和算力提升，并不能满足日益增长的大规模算力需求。数据中心一般需要部署数以万计的计算设备，而多个计算节点简单堆叠和组合往往会产生网络拥塞现象，特别是在数据密集型场景下，多个并行任务在通信网络中相互冲突，会造成大量额外的延时和性能损耗，导致整体系统的资源利用率不高。大部分数据中心的计算架构多根据接近于峰值时段的算力需求进行硬件规划，而其峰值算力需求通常比平时高出几倍，甚至数十倍。阿里巴巴官方公布的数据显示14，2017年“双11”实时数据处理峰值为4.72亿条/秒，是日常实时处理峰值（0.4亿条/秒）的10倍。因此，如果根据峰值算力需求进行硬件规划和部署，很容易造成设备闲置。另外，数据中心服务器内部的CPU、GPU和内存等资源配置比较固化，但不同计算任务对资源的需求又不尽相同，数据中心硬件配置一旦固定，由于算力无法灵活调度，其使用率在大部分时间内都相对较低。根据阿里云数据中心和字节跳动对GPU使用率的观测结果15,16，以GPU整卡为单位，其使用率大概在40%左右。若细分到以GPU内部的流式多处理器（Streaming Multiprocessor，SM）为使用单位，则资源利用率仅为10%左右。更好的做法是将计算资源整合，通过精细化管理，以灵活高效的方式分配给计算任务。这种思路通常被称为资源池化。传统模式的资源池化，包括计算池化和内存池化，主要集中在单计算节点之内的资源共享。这种共享模式通过虚拟机监控程序（Hypervisor）技术把CPU、内存等资源切分给不同的虚拟机，并实现多租户的虚拟机在物理主机上的资源隔离和共享。因此，传统池化模式没有突破单计算节点的物理边界，不能发挥出大规模计算节点间的资源共享优势。综上，传统服务器架构的挑战可以被总结为以下几点：AI模型算力消耗的指数增长AI模型容量的指数增长模型大小(以十亿为单位)20182019202020212022Megatron-TuringNLG(530B)ELMo(94M)BERT-Large(340M)GPT-2(1.5B)T5(11B)Turing-NLG(17.2B)Megatron-LM(8.3B)GPT-3(175B)10001001010.10.01AI训练的算力消耗（千万亿次运算/秒天）1950 196019802000 2010 2020199019701e 41e 21e 01e-21e-41e-61e-81e-101e-121e-14PerceptronALVINNNETtalkTD-Gammor v2.1Deep Belief Nets andLayer-wise pretrainingAlexNetVGGNeural MachineTranslationAlphaGoZeroResNetsBERTDONRNN for SpeechLeNet-5BiLSTM for SpeechTeslaAutopilot每两年翻一番每年10倍时间(年)时间(年)图1 AI模型容量和算力消耗的指数增长趋势1大规模光电集成赋能智能算力网络2然而，计算芯片的传统算力增长路径已经遇到了瓶颈。半导体产业发展60多年以来，算力提升长期遵循两个定律摩尔定律和登纳德缩放比例定律。摩尔定律提出晶体管的密度每18个月会翻一倍；而根据登纳德缩放比例定律2，晶体管在密度提升的同目前，业界针对数据中心算力和算效的提升已做出大量的努力。其中，算力网络（Computing Power Network）的理念在全球范围内得到了广泛认可6。算力网络是一种根据业务需求，按需分配和灵活调度计算、存储以及网络等资源的新型信息基础设施。其终极目标是将硬件资源抽象化为算力，用户可根据实际的计算需求向数据中心购买算力，而无需购买或租赁硬件设备，从而实现像使用水、电、气一样便捷地使用算力。因此，国外也有文献把这个算力网络概念称为Utility Computing7。为实现这一愿景，算力网络需要具备众多高效的计算节点和节点间高效的数据互连。单节点内的纵向算力提升，为算力网络提供高效的计算资源。在此基础上，通过高效的数据互连，横向拓展算力，从而总体上形成庞大的算力容量。算力网络不仅能够帮助解决算力的利用率和扩展性问题，而且可以解决算力迁移和易用性问题，通过硬件资源的灵活调度，实现算力网络内更细粒度的资源共享。本章将简要介绍目前业界在纵向算力提升和横向算力拓展两方面的主要工作及面临的挑战。2.1 单节点算力纵向提升数据中心内，以一到两个CPU为核心的单个服务器通常被看作一个计算节点。在晶体管密度提升放缓的背景下，制程工艺迭代所能带来的性能提升愈发有限，单个节点的算力提升出现了多种思路。首先是通过芯片架构创新降低相对于CPU的通用性来换取超越CPU的计算效率。在此基础上，一些研究者寻求跳出传统的冯诺依曼范式和 CMOS晶体管技术，用颠覆性的新原理来获得超越摩尔定律的算力提升。另一种思路是通过在单个封装内容纳多个芯粒（Chiplet）来超越倍缩光罩（Reticle）导致的单芯片尺寸上限，从而获得更高的算力。2.1.1 异构计算架构创新早期的计算架构创新以通用计算架构为主，主要以提升指令级别并行（Instruction-Level Parallelism，ILP）为驱动力，尽最大努力挖掘摩尔定律带来的片上晶体管资源红利。例如，超标量CPU架构利用晶体管资源优势来使能从指令单发到多发（乱序发射乱序执行）再到更深的流水管线，针对单元数据实现了更多计算操作。同时，流水线管线加深有利于减少每一个阶段的计算操作，从而实现CPU频率的大幅提升。随着半导体工艺的演进，芯片面积的增大也使得芯片上可以集成更多的逻辑功能，包括更大和更多层的数据缓冲、数据预取等功能块，从而改善由于计算和内存速度的不均衡发展所产生的“内存墙”问题。近期，大规模、高效的数据迁移已成为突破单节点算力瓶颈的新动力。例如高带宽内存架构（High Bandwidth Memory，HBM）等创新技术，通过提高数据传输过程中的效率，为计算架构带来新一轮的性能提升。这一趋势在谷歌对其几代张量加速器（Tensor Processing Unit，TPU）架构演进的总结里有很好的反映8。最后，资源红利也赋能了计算架构朝着超线程、多核，再到以背景执行环境为支撑的成千上万个众线程架构方向发展。同时，加上数据向量化和单指令多数据流（Single Instruction Multiple Data，SIMD）等技术，这种线程级别并行（Thread-Level Parallelism，TLP）为计算架构性能带来多个数量级的飞跃。在上述通用计算架构的基础上，领域专用架构（Domain Specific Architecture,DSA）获得了长足的发展。随着人工智能、5G、自动驾驶、VR/AR等创新技术的涌现，不同应用场景对芯片算力、功能、功耗、成本、安全性等方面的需求日渐分化，算力需求多元化趋势下，领域专用架构应运而生。领域专用架构是针对某个应用领域的特殊性而定制设计的专用架构，包括特殊的计算单元、并行机制、数据类型和领域专用语言等。领域专用架构通过牺牲架构的通用性来加速应用性能，从而把硬件的原生计算能力更高效地发挥出来，同时实现比通用计算架构更好的节能效果。以英伟达最新发布的Hopper图形加速器（Graphics Processing Unit，GPU）架构9为例，其在典型的TLP架构的基础上，使用了更多、更强大的张量加速核（Tensor Core），并在张量加速核内部增加了更多有助于算力纵向提升的领域专用技术，包括细粒度的结构化稀疏计算和动态编程算法优化等。相对于上一代A100 GPU，基于Hopper架构的H100 GPU在AI训练任务集上约有24倍的性能提升。另一个比较典型的领域专用加速器是谷歌的张量处理器（TPU）。该加速器的脉动阵列模块是针对矩阵乘法优化的设计，通过增加对单位数据的多重计算，在缓解“内存墙”效应的同时，显著提升计算密度。然而，领域专用架构的定制化特征，通常使得其本身缺乏计算完备性。异构计算架构则是把CPU和多类DSA有机地结合在一起，通过让每一个DSA在自己擅长的领域内发挥出最大性能，从整体上实现最高性能和最佳能效。领域专用架构在取得大幅度算力提升的同时，依然受限于传统底层元器件以及冯诺伊曼架构。传统计算芯片的底层元器件是基于硅晶圆的CMOS晶体管，核心的工作原理是由电压信号来控制晶体管内的电流。随着CMOS制程的提升，晶体管的尺寸越来越小，量子隧穿效应使得控制电流的效率降低。突破这一瓶颈需要新的底层计算原理。同时，传统的计算硬件设计通常基于冯诺伊曼架构，即计算和数据分离架构，通过顺序控制逻辑把数据搬运到计算单元再执行计算。这种架构的主要问题是数据迁移导致了计算延迟以及处理单位数据时的功耗变大，暴露出“内存墙”问题。尽管现代架构通过向量化、超线程技术、流水线并行和多核架构的不断创新来提升性能，但冯诺伊曼架构的潜力空间越来越小。随着计算架构不断创新，非冯诺伊曼架构也开始出现百花齐放的趋势。这一类非基于顺序控制流执行的颠覆性计算架构（例如生物计算和量子计算），或为了克服冯诺伊曼架构的核心瓶颈而衍生出的架构（例如基于忆阻器的存内计算），通过崭新的计算模式创造了巨大的性能和能效提升空间。例如，基于3D混合封装的近内存计算引擎10，通过把多存储体内存直接连接到计算逻辑单元，让AI加速器在推荐模型上的性能大幅提升。2.1.2 芯粒系统由于晶体管密度提高的减缓，单个封装内的底层算力提升只能通过扩大芯片总面积实现。但芯片尺寸不可能无限大，在CMOS工艺的限制下，受限于倍缩光罩的尺寸，单个芯片的最大面积一般在800mm2左右。要进一步扩大芯片总面积，则需另辟蹊径，来突破单个芯片的面积上限，芯粒系统的新思路由此逐渐兴起。得益于先进封装技术的进步，将满足不同特定功能的多个芯粒封装在同一个基板上成为了可能。近年来，世界领先的芯片企业已经越来越多地将芯粒架构应用在高端计算系统里。例如，英特尔的Ponte Vecchio GPU11由超过40个芯粒组成，总面积超过了3,000mm2。Cerebras Systems的晶圆级计算引擎（Wafer Scale Engine，WSE）12总面积超过了40,000mm2，是当前倍缩光罩面积的50倍。除了提升芯片总面积之外，芯粒具有模块化特性，即来自不同晶圆厂、采用不同制程节点的芯粒可以按需组合，因此不仅具有解耦架构设计的灵活性，而且在大幅提升芯片工艺制程的良率的同时，有效降低制造成本。由于实现了芯片内部的领域专用异构计算，芯粒架构能够更高效地片上适配各种计算任务。目前的芯粒系统产品依然以私有架构为主。多个工业组织正在积极推动芯粒互连标准（例如UCIe和BOW），以发展片上异构计算。其中不乏行业巨头，如2021年谷歌发布了开放式芯粒（Open Chiplet）计算架构13，进一步推动芯粒技术生态的发展。然而，芯片总面积变大，会导致数据搬运的时间和能耗成本随之增加。电在进行数据传输的过程中，对能耗、片上面积等资源的消耗随着距离的增长而提高。在纯数字电路中，为了减小数据搬运的消耗，每个计算单元一般只会与其最邻近的计算单元进行数据传输，因此，跨越多个计算单元的数据搬运需要多次跳跃。同时，较大的计算任务通常会被映射到多个计算单元，为了避免长距离数据搬运，需使用非常复杂的算法来优化计算任务的映射。2.2 多节点算力横向扩展2.2.1 目前大规模分布式技术的挑战单个计算节点的架构创新和算力提升，并不能满足日益增长的大规模算力需求。数据中心一般需要部署数以万计的计算设备，而多个计算节点简单堆叠和组合往往会产生网络拥塞现象，特别是在数据密集型场景下，多个并行任务在通信网络中相互冲突，会造成大量额外的延时和性能损耗，导致整体系统的资源利用率不高。大部分数据中心的计算架构多根据接近于峰值时段的算力需求进行硬件规划，而其峰值算力需求通常比平时高出几倍，甚至数十倍。阿里巴巴官方公布的数据显示14，2017年“双11”实时数据处理峰值为4.72亿条/秒，是日常实时处理峰值（0.4亿条/秒）的10倍。因此，如果根据峰值算力需求进行硬件规划和部署，很容易造成设备闲置。另外，数据中心服务器内部的CPU、GPU和内存等资源配置比较固化，但不同计算任务对资源的需求又不尽相同，数据中心硬件配置一旦固定，由于算力无法灵活调度，其使用率在大部分时间内都相对较低。根据阿里云数据中心和字节跳动对GPU使用率的观测结果15,16，以GPU整卡为单位，其使用率大概在40%左右。若细分到以GPU内部的流式多处理器（Streaming Multiprocessor，SM）为使用单位，则资源利用率仅为10%左右。更好的做法是将计算资源整合，通过精细化管理，以灵活高效的方式分配给计算任务。这种思路通常被称为资源池化。传统模式的资源池化，包括计算池化和内存池化，主要集中在单计算节点之内的资源共享。这种共享模式通过虚拟机监控程序（Hypervisor）技术把CPU、内存等资源切分给不同的虚拟机，并实现多租户的虚拟机在物理主机上的资源隔离和共享。因此，传统池化模式没有突破单计算节点的物理边界，不能发挥出大规模计算节点间的资源共享优势。综上，传统服务器架构的挑战可以被总结为以下几点：时，功耗密度保持不变。结合摩尔定律和登纳德缩放定律，CMOS芯片可以在能耗和面积不变的情况下，随着晶体管数量的增加而不断提高算力。然而当芯片制造工艺发展到5nm、3nm，晶体管微缩已经接近物理极限，摩尔定律呈现出放缓趋势，并预计将在21世纪20年代结束3。而登纳德缩放比例定律早在2004年左右已经失效4，此后实现芯片集成度的提升，所需的功耗和散热要求越来越大，产生了“功耗墙”问题。另外，更先进工艺制程的流片和设计费用也越来越高，进而又产生了“成本墙”问题。传统的单芯片算力提升路径难以为继。同时，指数级的算力增长是单个计算硬件系统无法满足的，因此需要大规模地部署数据中心和计算设备来实现体系化的支撑。随着算力需求的快速增长，满足需求所消耗的资源与日俱增。据估算5，2020年国内数据中心年耗电量在760亿千瓦时左右，约占全国总用电量的1%，且呈逐年上升趋势。随着 全国一体化大数据中心协同创新体系算力枢纽实施方案、新型数据中心发展三年行动计划（2021-2023）等政策的出台以及国家“东数西算”工程的实施，算力基础设施建设将进入大规模发展阶段，并对大型数据中心的能效提出具体要求。根据联合国和国家发展计划，中国力争在2060年前实现碳中和。在“双碳”战略指引下，设计高效计算体系、减少能耗和碳排放，已经成为提升数据中心计算效率和实现国家碳中和目标的重要手段。本报告将围绕提升数据中心算力和算效，阐述业界当前探索的主流有效路径，并重点讨论这些路径分别面临的关键挑战，同时将提出一种基于大规模光电集成技术的算力网络新范式。本报告中的算力网络将专注于数据中心内部，以期为下一代数据中心的发展提供更高效的解决方案，为实现算力网络的愿景目标提供新的思路。大规模光电集成赋能智能算力网络3目前，业界针对数据中心算力和算效的提升已做出大量的努力。其中，算力网络（Computing Power Network）的理念在全球范围内得到了广泛认可6。算力网络是一种根据业务需求，按需分配和灵活调度计算、存储以及网络等资源的新型信息基础设施。其终极目标是将硬件资源抽象化为算力，用户可根据实际的计算需求向数据中心购买算力，而无需购买或租赁硬件设备，从而实现像使用水、电、气一样便捷地使用算力。因此，国外也有文献把这个算力网络概念称为Utility Computing7。为实现这一愿景，算力网络需要具备众多高效的计算节点和节点间高效的数据互连。单节点内的纵向算力提升，为算力网络提供高效的计算资源。在此基础上，通过高效的数据互连，横向拓展算力，从而总体上形成庞大的算力容量。算力网络不仅能够帮助解决算力的利用率和扩展性问题，而且可以解决算力迁移和易用性问题，通过硬件资源的灵活调度，实现算力网络内更细粒度的资源共享。本章将简要介绍目前业界在纵向算力提升和横向算力拓展两方面的主要工作及面临的挑战。2.1 单节点算力纵向提升数据中心内，以一到两个CPU为核心的单个服务器通常被看作一个计算节点。在晶体管密度提升放缓的背景下，制程工艺迭代所能带来的性能提升愈发有限，单个节点的算力提升出现了多种思路。首先是通过芯片架构创新降低相对于CPU的通用性来换取超越CPU的计算效率。在此基础上，一些研究者寻求跳出传统的冯诺依曼范式和 CMOS晶体管技术，用颠覆性的新原理来获得超越摩尔定律的算力提升。另一种思路是通过在单个封装内容纳多个芯粒（Chiplet）来超越倍缩光罩（Reticle）导致的单芯片尺寸上限，从而获得更高的算力。大规模光电集成赋能智能算力网络42.1.1 异构计算架构创新早期的计算架构创新以通用计算架构为主，主要以提升指令级别并行（Instruction-Level Parallelism，ILP）为驱动力，尽最大努力挖掘摩尔定律带来的片上晶体管资源红利。例如，超标量CPU架构利用晶体管资源优势来使能从指令单发到多发（乱序发射乱序执行）再到更深的流水管线，针对单元数据实现了更多计算操作。同时，流水线管线加深有利于减少每一个阶段的计算操作，从而实现CPU频率的大幅提升。随着半导体工艺的演进，芯片面积的增大也使得芯片上可以集成更多的逻辑功能，包括更大和更多层的数据缓冲、数据预取等功能块，从而改善由于计算和内存速度的不均衡发展所产生的“内存墙”问题。近期，大规模、高效的数据迁移已成为突破单节点算力瓶颈的新动力。例如高带宽内存架构（High Bandwidth Memory，HBM）等创新技术，通过提高数据传输过程中的效率，为计算架构带来新一轮的性能提升。这一趋势在谷歌对其几代张量加速器（Tensor Processing Unit，TPU）架构演进的总结里有很好的反映8。最后，资源红利也赋能了计算架构朝着超线程、多核，再到以背景执行环境为支撑的成千上万个众线程架构方向发展。同时，加上数据向量化和单指令多数据流（Single Instruction Multiple Data，SIMD）等技术，这种线程级别并行（Thread-Level Parallelism，TLP）为计算架构性能带来多个数量级的飞跃。在上述通用计算架构的基础上，领域专用架构（Domain Specific Architecture,DSA）获得了长足的发展。随着人工智能、5G、自动驾驶、VR/AR等创新技术的涌现，不同应用场景对芯片算力、功能、功耗、成本、安全性等方面的需求日渐分化，算力需求多元化趋势下，领域专用架构应运而生。领域专用架构是针对某个应用领域的特殊性而定制设计的专用架构，包括特殊的计算单元、并行机制、数据类型和领域专用语言等。领域专用架构通过牺牲架构的通用性来加速应用性能，从而把硬件的原生计算能力更高效地发挥出来，同时实现比通用计算架构更好的节能效果。以英伟达最新发布的Hopper图形加速器（Graphics Processing Unit，GPU）架构9为例，其在典型的TLP架构的基础上，使用了更多、更强大的张量加速核（Tensor Core），并在张量加速核内部增加了更多有助于算力纵向提升的领域专用技术，包括细粒度的结构化稀疏计算和动态编程算法优化等。相对于上一代A100 GPU，基于Hopper架构的H100 GPU在AI训练任务集上约有24倍的性能提升。另一个比较典型的领域专用加速器是谷歌的张量处理器（TPU）。该加速器的脉动阵列模块是针对矩阵乘法优化的设计，通过增加对单位数据的多重计算，在缓解“内存墙”效应的同时，显著提升计算密度。然而，领域专用架构的定制化特征，通常使得其本身缺乏计算完备性。异构计算架构则是把CPU和多类DSA有机地结合在一起，通过让每一个DSA在自己擅长的领域内发挥出最大性能，从整体上实现最高性能和最佳能效。领域专用架构在取得大幅度算力提升的同时，依然受限于传统底层元器件以及冯诺伊曼架构。传统计算芯片的底层元器件是基于硅晶圆的CMOS晶体管，核心的工作原理是由电压信号来控制晶体管内的电流。随着CMOS制程的提升，晶体管的尺寸越来越小，量子隧穿效应使得控制电流的效率降低。突破这一瓶颈需要新的底层计算原理。同时，传统的计算硬件设计通常基于冯诺伊曼架构，即计算和数据分离架构，通过顺序控制逻辑把数据搬运到计算单元再执行计算。这种架构的主要问题是数据迁移导致了计算延迟以及处理单位数据时的功耗变大，暴露出“内存墙”问题。尽管现代架构通过向量化、超线程技术、流水线并行和多核架构的不断创新来提升性能，但冯诺伊曼架构的潜力空间越来越小。随着计算架构不断创新，非冯诺伊曼架构也开始出现百花齐放的趋势。这一类非基于顺序控制流执行的颠覆性计算架构（例如生物计算和量子计算），或为了克服冯诺伊曼架构的核心瓶颈而衍生出的架构（例如基于忆阻器的存内计算），通过崭新的计算模式创造了巨大的性能和能效提升空间。例如，基于3D混合封装的近内存计算引擎10，通过把多存储体内存直接连接到计算逻辑单元，让AI加速器在推荐模型上的性能大幅提升。2.1.2 芯粒系统由于晶体管密度提高的减缓，单个封装内的底层算力提升只能通过扩大芯片总面积实现。但芯片尺寸不可能无限大，在CMOS工艺的限制下，受限于倍缩光罩的尺寸，单个芯片的最大面积一般在800mm2左右。要进一步扩大芯片总面积，则需另辟蹊径，来突破单个芯片的面积上限，芯粒系统的新思路由此逐渐兴起。得益于先进封装技术的进步，将满足不同特定功能的多个芯粒封装在同一个基板上成为了可能。近年来，世界领先的芯片企业已经越来越多地将芯粒架构应用在高端计算系统里。例如，英特尔的Ponte Vecchio GPU11由超过40个芯粒组成，总面积超过了3,000mm2。Cerebras Systems的晶圆级计算引擎（Wafer Scale Engine，WSE）12总面积超过了40,000mm2，是当前倍缩光罩面积的50倍。除了提升芯片总面积之外，芯粒具有模块化特性，即来自不同晶圆厂、采用不同制程节点的芯粒可以按需组合，因此不仅具有解耦架构设计的灵活性，而且在大幅提升芯片工艺制程的良率的同时，有效降低制造成本。由于实现了芯片内部的领域专用异构计算，芯粒架构能够更高效地片上适配各种计算任务。目前的芯粒系统产品依然以私有架构为主。多个工业组织正在积极推动芯粒互连标准（例如UCIe和BOW），以发展片上异构计算。其中不乏行业巨头，如2021年谷歌发布了开放式芯粒（Open Chiplet）计算架构13，进一步推动芯粒技术生态的发展。然而，芯片总面积变大，会导致数据搬运的时间和能耗成本随之增加。电在进行数据传输的过程中，对能耗、片上面积等资源的消耗随着距离的增长而提高。在纯数字电路中，为了减小数据搬运的消耗，每个计算单元一般只会与其最邻近的计算单元进行数据传输，因此，跨越多个计算单元的数据搬运需要多次跳跃。同时，较大的计算任务通常会被映射到多个计算单元，为了避免长距离数据搬运，需使用非常复杂的算法来优化计算任务的映射。2.2 多节点算力横向扩展2.2.1 目前大规模分布式技术的挑战单个计算节点的架构创新和算力提升，并不能满足日益增长的大规模算力需求。数据中心一般需要部署数以万计的计算设备，而多个计算节点简单堆叠和组合往往会产生网络拥塞现象，特别是在数据密集型场景下，多个并行任务在通信网络中相互冲突，会造成大量额外的延时和性能损耗，导致整体系统的资源利用率不高。大部分数据中心的计算架构多根据接近于峰值时段的算力需求进行硬件规划，而其峰值算力需求通常比平时高出几倍，甚至数十倍。阿里巴巴官方公布的数据显示14，2017年“双11”实时数据处理峰值为4.72亿条/秒，是日常实时处理峰值（0.4亿条/秒）的10倍。因此，如果根据峰值算力需求进行硬件规划和部署，很容易造成设备闲置。另外，数据中心服务器内部的CPU、GPU和内存等资源配置比较固化，但不同计算任务对资源的需求又不尽相同，数据中心硬件配置一旦固定，由于算力无法灵活调度，其使用率在大部分时间内都相对较低。根据阿里云数据中心和字节跳动对GPU使用率的观测结果15,16，以GPU整卡为单位，其使用率大概在40%左右。若细分到以GPU内部的流式多处理器（Streaming Multiprocessor，SM）为使用单位，则资源利用率仅为10%左右。更好的做法是将计算资源整合，通过精细化管理，以灵活高效的方式分配给计算任务。这种思路通常被称为资源池化。传统模式的资源池化，包括计算池化和内存池化，主要集中在单计算节点之内的资源共享。这种共享模式通过虚拟机监控程序（Hypervisor）技术把CPU、内存等资源切分给不同的虚拟机，并实现多租户的虚拟机在物理主机上的资源隔离和共享。因此，传统池化模式没有突破单计算节点的物理边界，不能发挥出大规模计算节点间的资源共享优势。综上，传统服务器架构的挑战可以被总结为以下几点：大规模光电集成赋能智能算力网络5以英伟达最新发布的Hopper图形加速器（Graphics Processing Unit，GPU）架构9为例，其在典型的TLP架构的基础上，使用了更多、更强大的张量加速核（Tensor Core），并在张量加速核内部增加了更多有助于算力纵向提升的领域专用技术，包括细粒度的结构化稀疏计算和动态编程算法优化等。相对于上一代A100 GPU，基于Hopper架构的H100 GPU在AI训练任务集上约有24倍的性能提升。另一个比较典型的领域专用加速器是谷歌的张量处理器（TPU）。该加速器的脉动阵列模块是针对矩阵乘法优化的设计，通过增加对单位数据的多重计算，在缓解“内存墙”效应的同时，显著提升计算密度。然而，领域专用架构的定制化特征，通常使得其本身缺乏计算完备性。异构计算架构则是把CPU和多类DSA有机地结合在一起，通过让每一个DSA在自己擅长的领域内发挥出最大性能，从整体上实现最高性能和最佳能效。领域专用架构在取得大幅度算力提升的同时，依然受限于传统底层元器件以及冯诺伊曼架构。传统计算芯片的底层元器件是基于硅晶圆的CMOS晶体管，核心的工作原理是由电压信号来控制晶体管内的电流。随着CMOS制程的提升，晶体管的尺寸越来越小，量子隧穿效应使得控制电流的效率降低。突破这一瓶颈需要新的底层计算原理。同时，传统的计算硬件设计通常基于冯诺伊曼架构，即计算和数据分离架构，通过顺序控制逻辑把数据搬运到计算单元再执行计算。这种架构的主要问题是数据迁移导致了计算延迟以及处理单位数据时的功耗变大，暴露出“内存墙”问题。尽管现代架构通过向量化、超线程技术、流水线并行和多核架构的不断创新来提升性能，但冯诺伊曼架构的潜力空间越来越小。随着计算架构不断创新，非冯诺伊曼架构也开始出现百花齐放的趋势。这一类非基于顺序控制流执行的颠覆性计算架构（例如生物计算和量子计算），或为了克服冯诺伊曼架构的核心瓶颈而衍生出的架构（例如基于忆阻器的存内计算），通过崭新的计算模式创造了巨大的性能和能效提升空间。例如，基于3D混合封装的近内存计算引擎10，通过把多存储体内存直接连接到计算逻辑单元，让AI加速器在推荐模型上的性能大幅提升。2.1.2 芯粒系统由于晶体管密度提高的减缓，单个封装内的底层算力提升只能通过扩大芯片总面积实现。但芯片尺寸不可能无限大，在CMOS工艺的限制下，受限于倍缩光罩的尺寸，单个芯片的最大面积一般在800mm2左右。要进一步扩大芯片总面积，则需另辟蹊径，来突破单个芯片的面积上限，芯粒系统的新思路由此逐渐兴起。得益于先进封装技术的进步，将满足不同特定功能的多个芯粒封装在同一个基板上成为了可能。近年来，世界领先的芯片企业已经越来越多地将芯粒架构应用在高端计算系统里。例如，英特尔的Ponte Vecchio GPU11由超过40个芯粒组成，总面积超过了3,000mm2。Cerebras Systems的晶圆级计算引擎（Wafer Scale Engine，WSE）12总面积超过了40,000mm2，是当前倍缩光罩面积的50倍。除了提升芯片总面积之外，芯粒具有模块化特性，即来自不同晶圆厂、采用不同制程节点的芯粒可以按需组合，因此不仅具有解耦架构设计的灵活性，而且在大幅提升芯片工艺制程的良率的同时，有效降低制造成本。由于实现了芯片内部的领域专用异构计算，芯粒架构能够更高效地片上适配各种计算任务。目前的芯粒系统产品依然以私有架构为主。多个工业组织正在积极推动芯粒互连标准（例如UCIe和BOW），以发展片上异构计算。其中不乏行业巨头，如2021年谷歌发布了开放式芯粒（Open Chiplet）计算架构13，进一步推动芯粒技术生态的发展。然而，芯片总面积变大，会导致数据搬运的时间和能耗成本随之增加。电在进行数据传输的过程中，对能耗、片上面积等资源的消耗随着距离的增长而提高。在纯数字电路中，为了减小数据搬运的消耗，每个计算单元一般只会与其最邻近的计算单元进行数据传输，因此，跨越多个计算单元的数据搬运需要多次跳跃。同时，较大的计算任务通常会被映射到多个计算单元，为了避免长距离数据搬运，需使用非常复杂的算法来优化计算任务的映射。2.2 多节点算力横向扩展2.2.1 目前大规模分布式技术的挑战单个计算节点的架构创新和算力提升，并不能满足日益增长的大规模算力需求。数据中心一般需要部署数以万计的计算设备，而多个计算节点简单堆叠和组合往往会产生网络拥塞现象，特别是在数据密集型场景下，多个并行任务在通信网络中相互冲突，会造成大量额外的延时和性能损耗，导致整体系统的资源利用率不高。大部分数据中心的计算架构多根据接近于峰值时段的算力需求进行硬件规划，而其峰值算力需求通常比平时高出几倍，甚至数十倍。阿里巴巴官方公布的数据显示14，2017年“双11”实时数据处理峰值为4.72亿条/秒，是日常实时处理峰值（0.4亿条/秒）的10倍。因此，如果根据峰值算力需求进行硬件规划和部署，很容易造成设备闲置。另外，数据中心服务器内部的CPU、GPU和内存等资源配置比较固化，但不同计算任务对资源的需求又不尽相同，数据中心硬件配置一旦固定，由于算力无法灵活调度，其使用率在大部分时间内都相对较低。根据阿里云数据中心和字节跳动对GPU使用率的观测结果15,16，以GPU整卡为单位，其使用率大概在40%左右。若细分到以GPU内部的流式多处理器（Streaming Multiprocessor，SM）为使用单位，则资源利用率仅为10%左右。更好的做法是将计算资源整合，通过精细化管理，以灵活高效的方式分配给计算任务。这种思路通常被称为资源池化。传统模式的资源池化，包括计算池化和内存池化，主要集中在单计算节点之内的资源共享。这种共享模式通过虚拟机监控程序（Hypervisor）技术把CPU、内存等资源切分给不同的虚拟机，并实现多租户的虚拟机在物理主机上的资源隔离和共享。因此，传统池化模式没有突破单计算节点的物理边界，不能发挥出大规模计算节点间的资源共享优势。综上，传统服务器架构的挑战可以被总结为以下几点：大规模光电集成赋能智能算力网络62.1.2 芯粒系统由于晶体管密度提高的减缓，单个封装内的底层算力提升只能通过扩大芯片总面积实现。但芯片尺寸不可能无限大，在CMOS工艺的限制下，受限于倍缩光罩的尺寸，单个芯片的最大面积一般在800mm2左右。要进一步扩大芯片总面积，则需另辟蹊径，来突破单个芯片的面积上限，芯粒系统的新思路由此逐渐兴起。得益于先进封装技术的进步，将满足不同特定功能的多个芯粒封装在同一个基板上成为了可能。近年来，世界领先的芯片企业已经越来越多地将芯粒架构应用在高端计算系统里。例如，英特尔的Ponte Vecchio GPU11由超过40个芯粒组成，总面积超过了3,000mm2。Cerebras Systems的晶圆级计算引擎（Wafer Scale Engine，WSE）12总面积超过了40,000mm2，是当前倍缩光罩面积的50倍。除了提升芯片总面积之外，芯粒具有模块化特性，即来自不同晶圆厂、采用不同制程节点的芯粒可以按需组合，因此不仅具有解耦架构设计的灵活性，而且在大幅提升芯片工艺制程的良率的同时，有效降低制造成本。由于实现了芯片内部的领域专用异构计算，芯粒架构能够更高效地片上适配各种计算任务。目前的芯粒系统产品依然以私有架构为主。多个工业组织正在积极推动芯粒互连标准（例如UCIe和BOW），以发展片上异构计算。其中不乏行业巨头，如2021年谷歌发布了开放式芯粒（Open Chiplet）计算架构13，进一步推动芯粒技术生态的发展。然而，芯片总面积变大，会导致数据搬运的时间和能耗成本随之增加。电在进行数据传输的过程中，对能耗、片上面积等资源的消耗随着距离的增长而提高。在纯数字电路中，为了减小数据搬运的消耗，每个计算单元一般只会与其最邻近的计算单元进行数据传输，因此，跨越多个计算单元的数据搬运需要多次跳跃。同时，较大的计算任务通常会被映射到多个计算单元，为了避免长距离数据搬运，需使用非常复杂的算法来优化计算任务的映射。大规模光电集成赋能智能算力网络72.2 多节点算力横向扩展2.2.1 目前大规模分布式技术的挑战单个计算节点的架构创新和算力提升，并不能满足日益增长的大规模算力需求。数据中心一般需要部署数以万计的计算设备，而多个计算节点简单堆叠和组合往往会产生网络拥塞现象，特别是在数据密集型场景下，多个并行任务在通信网络中相互冲突，会造成大量额外的延时和性能损耗，导致整体系统的资源利用率不高。大部分数据中心的计算架构多根据接近于峰值时段的算力需求进行硬件规划，而其峰值算力需求通常比平时高出几倍，甚至数十倍。阿里巴巴官方公布的数据显示14，2017年“双11”实时数据处理峰值为4.72亿条/秒，是日常实时处理峰值（0.4亿条/秒）的10倍。因此，如果根据峰值算力需求进行硬件规划和部署，很容易造成设备闲置。另外，数据中心服务器内部的CPU、GPU和内存等资源配置比较固化，但不同计算任务对资源的需求又不尽相同，数据中心硬件配置一旦固定，由于算力无法灵活调度，其使用率在大部分时间内都相对较低。根据阿里云数据中心和字节跳动对GPU使用率的观测结果15,16，以GPU整卡为单位，其使用率大概在40%左右。若细分到以GPU内部的流式多处理器（Streaming Multiprocessor，SM）为使用单位，则资源利用率仅为10%左右。更好的做法是将计算资源整合，通过精细化管理，以灵活高效的方式分配给计算任务。这种思路通常被称为资源池化。传统模式的资源池化，包括计算池化和内存池化，主要集中在单计算节点之内的资源共享。这种共享模式通过虚拟机监控程序（Hypervisor）技术把CPU、内存等资源切分给不同的虚拟机，并实现多租户的虚拟机在物理主机上的资源隔离和共享。因此，传统池化模式没有突破单计算节点的物理边界，不能发挥出大规模计算节点间的资源共享优势。综上，传统服务器架构的挑战可以被总结为以下几点：大规模光电集成赋能智能算力网络8传统服务器架构的计算资源配置不灵活，导致系统内资源使用不均衡不同计算任务对计算资源使用模式千差万别，被调度的计算资源颗粒度（例如GPU卡或者SM）无法精确匹配任务的算力需求，导致计算资源的闲置和浪费对于分布式计算资源的任务映射和优化，需要用户对底层架构有足够的理解，因用户缺乏相关的专业知识而导致计算资源优化的效率不高时有发生计算资源的隔离和容错性差，很难实现细粒度的资源共享2.2.2 可重构算力池化技术针对以上多种问题，业界出现了新的计算范式：可重构的算力池化。算力池化的主要目标是实现算力规模化和弹性化，通过解耦计算资源、再动态共享来提升资源利用率。算力池化的底层技术是解耦传统计算框架内的计算、内存和存储等多种资源，然后每一种资源形成各自的资源池，即所谓的解耦式资源池化。资源池内和资源池之间通过高带宽、低延迟的互连技术（例如最新的CXL标准），实现计算资源的灵活调配和算力的弹性扩展。如图2所示，传统数据中心的资源池化一般限于单个物理机内，容易造成局部资源闲置。而在可重构解耦架构下，每一类资源形成各自的独立池，包括CPU池（物理机0）、内存池（物理机1）、异构加速器池（物理机2）和存储池（物理机3）。调度系统根据计算任务的实际需求分配适当的计算资源，以动态组合模式重构计算实例（如虚拟机0、虚拟机1等）。借助新的解耦范式，传统数据中心未使用的闲置资源可以重新组合以创建新的虚拟机（虚拟机4），相同资源的情况下，虚拟机数量增加了25%。大规模光电集成赋能智能算力网络9然而，目前数据中心的基础设施设计难以支持高性能的资源池化。因大规模分布式计算设备之间的物理距离比较大，当前数据中心机柜之间通常采用基于以太网的数据通讯。由于受到以太网数据交换的带宽限制和较高的通讯延迟，数据中心很难做到接近线性的大规模算力扩展。而且，算力规模越大，扩展的线性度越低。例如，实验15表明，在基于以太网互连的GPU AI训练的场景中，当训练数据批量（Batch Size）较小，如果网络延迟和带宽分别从20微秒/50Gbps改变到160微秒/9.4Gbps，GPU性能将下降至原来的1/3。即使增大训练数据批量，也无法隐藏住性能损失。2.3 算力网络发展关键挑战算力网络技术的发展，同时需要领域专用架构的创新实现算力纵向提升，以及通过高效互连技术实现算力横向扩展，拓展资源池的总体算力容量，完成不同硬件间的算力灵活调度。除此之外，计算架构的软硬协同设计和优化也是大幅提升计算性能和计算2.2 多节点算力横向扩展2.2.1 目前大规模分布式技术的挑战单个计算节点的架构创新和算力提升，并不能满足日益增长的大规模算力需求。数据中心一般需要部署数以万计的计算设备，而多个计算节点简单堆叠和组合往往会产生网络拥塞现象，特别是在数据密集型场景下，多个并行任务在通信网络中相互冲突，会造成大量额外的延时和性能损耗，导致整体系统的资源利用率不高。大部分数据中心的计算架构多根据接近于峰值时段的算力需求进行硬件规划，而其峰值算力需求通常比平时高出几倍，甚至数十倍。阿里巴巴官方公布的数据显示14，2017年“双11”实时数据处理峰值为4.72亿条/秒，是日常实时处理峰值（0.4亿条/秒）的10倍。因此，如果根据峰值算力需求进行硬件规划和部署，很容易造成设备闲置。另外，数据中心服务器内部的CPU、GPU和内存等资源配置比较固化，但不同计算任务对资源的需求又不尽相同，数据中心硬件配置一旦固定，由于算力无法灵活调度，其使用率在大部分时间内都相对较低。根据阿里云数据中心和字节跳动对GPU使用率的观测结果15,16，以GPU整卡为单位，其使用率大概在40%左右。若细分到以GPU内部的流式多处理器（Streaming Multiprocessor，SM）为使用单位，则资源利用率仅为10%左右。更好的做法是将计算资源整合，通过精细化管理，以灵活高效的方式分配给计算任务。这种思路通常被称为资源池化。传统模式的资源池化，包括计算池化和内存池化，主要集中在单计算节点之内的资源共享。这种共享模式通过虚拟机监控程序（Hypervisor）技术把CPU、内存等资源切分给不同的虚拟机，并实现多租户的虚拟机在物理主机上的资源隔离和共享。因此，传统池化模式没有突破单计算节点的物理边界，不能发挥出大规模计算节点间的资源共享优势。综上，传统服务器架构的挑战可以被总结为以下几点：物理机0CPU池内存池计算池存储池虚拟机0CPUDRAMACCSSD虚拟机1CPUDRAMDRAMDRAMACCSSD物理机1虚拟机2虚拟机3CPU池内存池计算池存储池CPUDRAMCPUCPUCPUDRAMACCACCACCACCSSDSSDSSDSSD物理机0物理机1物理机3物理机2虚拟机0虚拟机2虚拟机1虚拟机3CPU池内存池计算池存储池CPUSSDCPUCPUCPUCPUCPUDRAMDRAMDRAMDRAMDRAMDRAMSSDSSDSSDSSDSSDACCACCACCACCACCACC传统数据中心可重构解耦架构数据中心闲置资源闲置资源虚拟机4图2 传统数据中心和可重构解耦架构数据中心对比示意图大规模光电集成赋能智能算力网络10超越传统CMOS的新底层计算原理，以及匹配商业化计算任务的异构计算架构高效可扩展的芯粒系统，包括超越传统电互连的物理层创新以及易用性强的计算任务适配软件栈高带宽、低延迟的跨机柜互连技术，包括硬件创新以及互连协议的进步能效的必要手段。综上所述，为实现真正的算力网络愿景，仍需克服多项技术挑战，具体包括：大规模光电集成赋能智能算力网络11前述章节中描述了数据中心持续提高算力和算效面临的技术瓶颈和现实挑战。而突破瓶颈、克服挑战，需要底层技术的创新。大规模光电集成技术在纵向提高单节点算力以及横向提高大规模分布式计算的效率两方面，都有着超越传统技术的潜力。成立于2017年的光电混合计算公司曦智科技是该领域的先行者。针对未来计算范式的大趋势，曦智科技拥有多项关键技术，为实现算力网络提供高效支撑。本章将简要介绍基于大规模光电集成技术的算力网络新范式。针对各项技术的详细内容将会在本系列后续的多个专题白皮书中展开论述。3.1 单节点算力提升方案3.1.1 颠覆性计算新原理：光子矩阵计算（oMAC）传统数字芯片的持续算力提升需要新的底层物理原理。数字芯片的算力提升受限于底层元器件：CMOS晶体管。而光学信号和光学器件遵循不同的物理原理。光学信号与散射介质的互动在大多数情况下是线性的，因此可以被映射为一种线性计算。生活中有诸多光学线性计算的现象，一个典型的例子是光学照相机的镜头。镜头前的光学信号在穿过镜头时，完成了两次二维空间光学傅立叶变换，然后在感光元件上成像，因此，照相机镜头可以被看作一种不可编程的光学线性计算单元。而拥有实用价值的计算单元必须具备可编程性。纵观目前主流的数据中心计算任务，如人工智能、数值仿真等，矩阵乘法占据着核心地位。因此超越摩尔定律的高效矩阵乘法器将拥有广泛的商业前景。矩阵乘法是一种典型的线性运算，可使用光子线性计算单元来加速。可编程的光子矩阵计算（Optical Multiply Accumulate，oMAC）17有望在摩尔定律失效后继续支持算力的不断提升，为数字经济时代提供强劲的硬件基础设施。以曦智科技于2021年发布的光子计算处理器PACE（Photonic Arithmetic Computing Engine，光子计算引擎）为例，如图3所示，PACE展示了一种可编程光学矩阵乘法器的实现方法。该系统在物理层面主要包括光芯片和电芯片，两块芯片由3D倒装堆叠的方式封装在一起；在功能层面主要包括信号输入、信号处理和信号输出三大部分。光信号在进入光芯片后，输入向量 被光学调制器转化为多个光信号，这些光信号在经过可编程的光学矩阵 后，输出的光信号阵列 即矩阵运算 的结果。在PACE中，所有的光器件都集成在一块光芯片上，而光芯片的控制电路和内存都部署在电芯片上。2.2 多节点算力横向扩展2.2.1 目前大规模分布式技术的挑战单个计算节点的架构创新和算力提升，并不能满足日益增长的大规模算力需求。数据中心一般需要部署数以万计的计算设备，而多个计算节点简单堆叠和组合往往会产生网络拥塞现象，特别是在数据密集型场景下，多个并行任务在通信网络中相互冲突，会造成大量额外的延时和性能损耗，导致整体系统的资源利用率不高。大部分数据中心的计算架构多根据接近于峰值时段的算力需求进行硬件规划，而其峰值算力需求通常比平时高出几倍，甚至数十倍。阿里巴巴官方公布的数据显示14，2017年“双11”实时数据处理峰值为4.72亿条/秒，是日常实时处理峰值（0.4亿条/秒）的10倍。因此，如果根据峰值算力需求进行硬件规划和部署，很容易造成设备闲置。另外，数据中心服务器内部的CPU、GPU和内存等资源配置比较固化，但不同计算任务对资源的需求又不尽相同，数据中心硬件配置一旦固定，由于算力无法灵活调度，其使用率在大部分时间内都相对较低。根据阿里云数据中心和字节跳动对GPU使用率的观测结果15,16，以GPU整卡为单位，其使用率大概在40%左右。若细分到以GPU内部的流式多处理器（Streaming Multiprocessor，SM）为使用单位，则资源利用率仅为10%左右。更好的做法是将计算资源整合，通过精细化管理，以灵活高效的方式分配给计算任务。这种思路通常被称为资源池化。传统模式的资源池化，包括计算池化和内存池化，主要集中在单计算节点之内的资源共享。这种共享模式通过虚拟机监控程序（Hypervisor）技术把CPU、内存等资源切分给不同的虚拟机，并实现多租户的虚拟机在物理主机上的资源隔离和共享。因此，传统池化模式没有突破单计算节点的物理边界，不能发挥出大规模计算节点间的资源共享优势。综上，传统服务器架构的挑战可以被总结为以下几点：大规模光电集成赋能智能算力网络12目前，业界针对数据中心算力和算效的提升已做出大量的努力。其中，算力网络（Computing Power Network）的理念在全球范围内得到了广泛认可6。算力网络是一种根据业务需求，按需分配和灵活调度计算、存储以及网络等资源的新型信息基础设施。其终极目标是将硬件资源抽象化为算力，用户可根据实际的计算需求向数据中心购买算力，而无需购买或租赁硬件设备，从而实现像使用水、电、气一样便捷地使用算力。因此，国外也有文献把这个算力网络概念称为Utility Computing7。为实现这一愿景，算力网络需要具备众多高效的计算节点和节点间高效的数据互连。单节点内的纵向算力提升，为算力网络提供高效的计算资源。在此基础上，通过高效的数据互连，横向拓展算力，从而总体上形成庞大的算力容量。算力网络不仅能够帮助解决算力的利用率和扩展性问题，而且可以解决算力迁移和易用性问题，通过硬件资源的灵活调度，实现算力网络内更细粒度的资源共享。本章将简要介绍目前业界在纵向算力提升和横向算力拓展两方面的主要工作及面临的挑战。2.1 单节点算力纵向提升数据中心内，以一到两个CPU为核心的单个服务器通常被看作一个计算节点。在晶体管密度提升放缓的背景下，制程工艺迭代所能带来的性能提升愈发有限，单个节点的算力提升出现了多种思路。首先是通过芯片架构创新降低相对于CPU的通用性来换取超越CPU的计算效率。在此基础上，一些研究者寻求跳出传统的冯诺依曼范式和 CMOS晶体管技术，用颠覆性的新原理来获得超越摩尔定律的算力提升。另一种思路是通过在单个封装内容纳多个芯粒（Chiplet）来超越倍缩光罩（Reticle）导致的单芯片尺寸上限，从而获得更高的算力。2.1.1 异构计算架构创新早期的计算架构创新以通用计算架构为主，主要以提升指令级别并行（Instruction-Level Parallelism，ILP）为驱动力，尽最大努力挖掘摩尔定律带来的片上晶体管资源红利。例如，超标量CPU架构利用晶体管资源优势来使能从指令单发到多发（乱序发射乱序执行）再到更深的流水管线，针对单元数据实现了更多计算操作。同时，流水线管线加深有利于减少每一个阶段的计算操作，从而实现CPU频率的大幅提升。随着半导体工艺的演进，芯片面积的增大也使得芯片上可以集成更多的逻辑功能，包括更大和更多层的数据缓冲、数据预取等功能块，从而改善由于计算和内存速度的不均衡发展所产生的“内存墙”问题。近期，大规模、高效的数据迁移已成为突破单节点算力瓶颈的新动力。例如高带宽内存架构（High Bandwidth Memory，HBM）等创新技术，通过提高数据传输过程中的效率，为计算架构带来新一轮的性能提升。这一趋势在谷歌对其几代张量加速器（Tensor Processing Unit，TPU）架构演进的总结里有很好的反映8。最后，资源红利也赋能了计算架构朝着超线程、多核，再到以背景执行环境为支撑的成千上万个众线程架构方向发展。同时，加上数据向量化和单指令多数据流（Single Instruction Multiple Data，SIMD）等技术，这种线程级别并行（Thread-Level Parallelism，TLP）为计算架构性能带来多个数量级的飞跃。在上述通用计算架构的基础上，领域专用架构（Domain Specific Architecture,DSA）获得了长足的发展。随着人工智能、5G、自动驾驶、VR/AR等创新技术的涌现，不同应用场景对芯片算力、功能、功耗、成本、安全性等方面的需求日渐分化，算力需求多元化趋势下，领域专用架构应运而生。领域专用架构是针对某个应用领域的特殊性而定制设计的专用架构，包括特殊的计算单元、并行机制、数据类型和领域专用语言等。领域专用架构通过牺牲架构的通用性来加速应用性能，从而把硬件的原生计算能力更高效地发挥出来，同时实现比通用计算架构更好的节能效果。以英伟达最新发布的Hopper图形加速器（Graphics Processing Unit，GPU）架构9为例，其在典型的TLP架构的基础上，使用了更多、更强大的张量加速核（Tensor Core），并在张量加速核内部增加了更多有助于算力纵向提升的领域专用技术，包括细粒度的结构化稀疏计算和动态编程算法优化等。相对于上一代A100 GPU，基于Hopper架构的H100 GPU在AI训练任务集上约有24倍的性能提升。另一个比较典型的领域专用加速器是谷歌的张量处理器（TPU）。该加速器的脉动阵列模块是针对矩阵乘法优化的设计，通过增加对单位数据的多重计算，在缓解“内存墙”效应的同时，显著提升计算密度。然而，领域专用架构的定制化特征，通常使得其本身缺乏计算完备性。异构计算架构则是把CPU和多类DSA有机地结合在一起，通过让每一个DSA在自己擅长的领域内发挥出最大性能，从整体上实现最高性能和最佳能效。领域专用架构在取得大幅度算力提升的同时，依然受限于传统底层元器件以及冯诺伊曼架构。传统计算芯片的底层元器件是基于硅晶圆的CMOS晶体管，核心的工作原理是由电压信号来控制晶体管内的电流。随着CMOS制程的提升，晶体管的尺寸越来越小，量子隧穿效应使得控制电流的效率降低。突破这一瓶颈需要新的底层计算原理。同时，传统的计算硬件设计通常基于冯诺伊曼架构，即计算和数据分离架构，通过顺序控制逻辑把数据搬运到计算单元再执行计算。这种架构的主要问题是数据迁移导致了计算延迟以及处理单位数据时的功耗变大，暴露出“内存墙”问题。尽管现代架构通过向量化、超线程技术、流水线并行和多核架构的不断创新来提升性能，但冯诺伊曼架构的潜力空间越来越小。随着计算架构不断创新，非冯诺伊曼架构也开始出现百花齐放的趋势。这一类非基于顺序控制流执行的颠覆性计算架构（例如生物计算和量子计算），或为了克服冯诺伊曼架构的核心瓶颈而衍生出的架构（例如基于忆阻器的存内计算），通过崭新的计算模式创造了巨大的性能和能效提升空间。例如，基于3D混合封装的近内存计算引擎10，通过把多存储体内存直接连接到计算逻辑单元，让AI加速器在推荐模型上的性能大幅提升。2.1.2 芯粒系统由于晶体管密度提高的减缓，单个封装内的底层算力提升只能通过扩大芯片总面积实现。但芯片尺寸不可能无限大，在CMOS工艺的限制下，受限于倍缩光罩的尺寸，单个芯片的最大面积一般在800mm2左右。要进一步扩大芯片总面积，则需另辟蹊径，来突破单个芯片的面积上限，芯粒系统的新思路由此逐渐兴起。得益于先进封装技术的进步，将满足不同特定功能的多个芯粒封装在同一个基板上成为了可能。近年来，世界领先的芯片企业已经越来越多地将芯粒架构应用在高端计算系统里。例如，英特尔的Ponte Vecchio GPU11由超过40个芯粒组成，总面积超过了3,000mm2。Cerebras Systems的晶圆级计算引擎（Wafer Scale Engine，WSE）12总面积超过了40,000mm2，是当前倍缩光罩面积的50倍。除了提升芯片总面积之外，芯粒具有模块化特性，即来自不同晶圆厂、采用不同制程节点的芯粒可以按需组合，因此不仅具有解耦架构设计的灵活性，而且在大幅提升芯片工艺制程的良率的同时，有效降低制造成本。由于实现了芯片内部的领域专用异构计算，芯粒架构能够更高效地片上适配各种计算任务。目前的芯粒系统产品依然以私有架构为主。多个工业组织正在积极推动芯粒互连标准（例如UCIe和BOW），以发展片上异构计算。其中不乏行业巨头，如2021年谷歌发布了开放式芯粒（Open Chiplet）计算架构13，进一步推动芯粒技术生态的发展。然而，芯片总面积变大，会导致数据搬运的时间和能耗成本随之增加。电在进行数据传输的过程中，对能耗、片上面积等资源的消耗随着距离的增长而提高。在纯数字电路中，为了减小数据搬运的消耗，每个计算单元一般只会与其最邻近的计算单元进行数据传输，因此，跨越多个计算单元的数据搬运需要多次跳跃。同时，较大的计算任务通常会被映射到多个计算单元，为了避免长距离数据搬运，需使用非常复杂的算法来优化计算任务的映射。前述章节中描述了数据中心持续提高算力和算效面临的技术瓶颈和现实挑战。而突破瓶颈、克服挑战，需要底层技术的创新。大规模光电集成技术在纵向提高单节点算力以及横向提高大规模分布式计算的效率两方面，都有着超越传统技术的潜力。成立于2017年的光电混合计算公司曦智科技是该领域的先行者。针对未来计算范式的大趋势，曦智科技拥有多项关键技术，为实现算力网络提供高效支撑。本章将简要介绍基于大规模光电集成技术的算力网络新范式。针对各项技术的详细内容将会在本系列后续的多个专题白皮书中展开论述。3.1 单节点算力提升方案3.1.1 颠覆性计算新原理：光子矩阵计算（oMAC）传统数字芯片的持续算力提升需要新的底层物理原理。数字芯片的算力提升受限于底层元器件：CMOS晶体管。而光学信号和光学器件遵循不同的物理原理。光学信号与散射介质的互动在大多数情况下是线性的，因此可以被映射为一种线性计算。生活中有诸多光学线性计算的现象，一个典型的例子是光学照相机的镜头。镜头前的光学信号在穿过镜头时，完成了两次二维空间光学傅立叶变换，然后在感光元件上成像，因此，照相机镜头可以被看作一种不可编程的光学线性计算单元。而拥有实用价值的计算单元必须具备可编程性。纵观目前主流的数据中心计算任务，如人工智能、数值仿真等，矩阵乘法占据着核心地位。因此超越摩尔定律的高效矩阵乘法器将拥有广泛的商业前景。矩阵乘法是一种典型的线性运算，可使用光子线性计算单元来加速。可编程的光子矩阵计算（Optical 逻辑控制发送端 接收端向量载入 权重调节输出结果权重驱动器及SRAMb1b2b3bNBc1c2c3cNCa11a21a31aM1a12a22a32aM2a13a23a33aM3.a1Na2Na3NaMNA图3 可编程光子矩阵乘法器原理示意图电芯片光芯片基板Multiply Accumulate，oMAC）17有望在摩尔定律失效后继续支持算力的不断提升，为数字经济时代提供强劲的硬件基础设施。以曦智科技于2021年发布的光子计算处理器PACE（Photonic Arithmetic Computing Engine，光子计算引擎）为例，如图3所示，PACE展示了一种可编程光学矩阵乘法器的实现方法。该系统在物理层面主要包括光芯片和电芯片，两块芯片由3D倒装堆叠的方式封装在一起；在功能层面主要包括信号输入、信号处理和信号输出三大部分。光信号在进入光芯片后，输入向量 被光学调制器转化为多个光信号，这些光信号在经过可编程的光学矩阵 后，输出的光信号阵列 即矩阵运算 的结果。在PACE中，所有的光器件都集成在一块光芯片上，而光芯片的控制电路和内存都部署在电芯片上。bcAbA2.2 多节点算力横向扩展2.2.1 目前大规模分布式技术的挑战单个计算节点的架构创新和算力提升，并不能满足日益增长的大规模算力需求。数据中心一般需要部署数以万计的计算设备，而多个计算节点简单堆叠和组合往往会产生网络拥塞现象，特别是在数据密集型场景下，多个并行任务在通信网络中相互冲突，会造成大量额外的延时和性能损耗，导致整体系统的资源利用率不高。大部分数据中心的计算架构多根据接近于峰值时段的算力需求进行硬件规划，而其峰值算力需求通常比平时高出几倍，甚至数十倍。阿里巴巴官方公布的数据显示14，2017年“双11”实时数据处理峰值为4.72亿条/秒，是日常实时处理峰值（0.4亿条/秒）的10倍。因此，如果根据峰值算力需求进行硬件规划和部署，很容易造成设备闲置。另外，数据中心服务器内部的CPU、GPU和内存等资源配置比较固化，但不同计算任务对资源的需求又不尽相同，数据中心硬件配置一旦固定，由于算力无法灵活调度，其使用率在大部分时间内都相对较低。根据阿里云数据中心和字节跳动对GPU使用率的观测结果15,16，以GPU整卡为单位，其使用率大概在40%左右。若细分到以GPU内部的流式多处理器（Streaming Multiprocessor，SM）为使用单位，则资源利用率仅为10%左右。更好的做法是将计算资源整合，通过精细化管理，以灵活高效的方式分配给计算任务。这种思路通常被称为资源池化。传统模式的资源池化，包括计算池化和内存池化，主要集中在单计算节点之内的资源共享。这种共享模式通过虚拟机监控程序（Hypervisor）技术把CPU、内存等资源切分给不同的虚拟机，并实现多租户的虚拟机在物理主机上的资源隔离和共享。因此，传统池化模式没有突破单计算节点的物理边界，不能发挥出大规模计算节点间的资源共享优势。综上，传统服务器架构的挑战可以被总结为以下几点：相比于传统的CMOS数字电路，光子矩阵计算最显著的优势在于低延迟。由于计算的过程即为光信号阵列在芯片中传输的过程，计算本身的延迟即可看作光在芯片中传输的时间，一般在1ns以下。如图4所示，对于一个 的脉动矩阵运算单元，其延迟正比于 。一些专门优化延迟的架构，在矩阵规模较小的情况下，延迟可以接近 。而光子矩阵计算消耗的时间主要来自于光电转换和数模转换，一般为数个O(N)O(logN)NN大规模光电集成赋能智能算力网络13时钟周期，和矩阵的尺寸几乎无关，相当于 。单次光子矩阵计算的延迟可以做到3ns以下。因此，在 较大的情况下，光子矩阵计算的延迟优势非常明显。除此之外，传统的数字计算，在28nm等相对成熟的制程下，较难实现全局1GHz以上的主频。而光子矩阵计算的控制电路达到数GHz的频率的难度较低，从而进一步提高了延迟优势。脉动矩阵计算延迟光子矩阵计算延迟延迟：L/Cng,1个时钟周期功耗：K1N K2N2延迟：kN 时钟周期功耗：KN2除了延迟优势以外，光子计算还拥有低能耗的特点。对于 的数字矩阵运算单元，其能耗为 ，其中 与单次乘加的功耗有关，正比于 。而对于光学矩阵乘法器，它的功耗可用 ，与向量输入和接收端的功耗关联，而 与矩阵权重部分的功耗关联。在矩阵本身刷新速度远低于信号输入的情况下，其能耗主要来自于前半部分，因此正比于 。在光学器件和其控制电路被较好的优化前提下，基于相对传统制程的光子计算的能效比可媲美甚至凌驾先进制程的数字芯片。相对于数字计算，光子计算也有一些弱点。例如，光子计算系统所需的光源，会占用一定的体积。目前光源小型化的研发可以使得每个服务器内所用的光源体积在几个硬币的尺寸。另外，光子计算作为一种模拟计算，无法支持浮点数，即使对于定点数，当精度超过8比特时，模拟计算在能耗方面的优势会减小。因此，对于基于浮点数或者8比特以上定点数的算法，需要经过量化的调整，才能够适用于光子计算硬件并体现优势。kN2k1N k2N2k1k2kO(N2)O(N)NN2.2 多节点算力横向扩展2.2.1 目前大规模分布式技术的挑战单个计算节点的架构创新和算力提升，并不能满足日益增长的大规模算力需求。数据中心一般需要部署数以万计的计算设备，而多个计算节点简单堆叠和组合往往会产生网络拥塞现象，特别是在数据密集型场景下，多个并行任务在通信网络中相互冲突，会造成大量额外的延时和性能损耗，导致整体系统的资源利用率不高。大部分数据中心的计算架构多根据接近于峰值时段的算力需求进行硬件规划，而其峰值算力需求通常比平时高出几倍，甚至数十倍。阿里巴巴官方公布的数据显示14，2017年“双11”实时数据处理峰值为4.72亿条/秒，是日常实时处理峰值（0.4亿条/秒）的10倍。因此，如果根据峰值算力需求进行硬件规划和部署，很容易造成设备闲置。另外，数据中心服务器内部的CPU、GPU和内存等资源配置比较固化，但不同计算任务对资源的需求又不尽相同，数据中心硬件配置一旦固定，由于算力无法灵活调度，其使用率在大部分时间内都相对较低。根据阿里云数据中心和字节跳动对GPU使用率的观测结果15,16，以GPU整卡为单位，其使用率大概在40%左右。若细分到以GPU内部的流式多处理器（Streaming Multiprocessor，SM）为使用单位，则资源利用率仅为10%左右。更好的做法是将计算资源整合，通过精细化管理，以灵活高效的方式分配给计算任务。这种思路通常被称为资源池化。传统模式的资源池化，包括计算池化和内存池化，主要集中在单计算节点之内的资源共享。这种共享模式通过虚拟机监控程序（Hypervisor）技术把CPU、内存等资源切分给不同的虚拟机，并实现多租户的虚拟机在物理主机上的资源隔离和共享。因此，传统池化模式没有突破单计算节点的物理边界，不能发挥出大规模计算节点间的资源共享优势。综上，传统服务器架构的挑战可以被总结为以下几点：相比于传统的CMOS数字电路，光子矩阵计算最显著的优势在于低延迟。由于计算的过程即为光信号阵列在芯片中传输的过程，计算本身的延迟即可看作光在芯片中传输的时间，一般在1ns以下。如图4所示，对于一个 的脉动矩阵运算单元，其延迟正比于 。一些专门优化延迟的架构，在矩阵规模较小的情况下，延迟可以接近 。而光子矩阵计算消耗的时间主要来自于光电转换和数模转换，一般为数个O(1)N图4 脉动矩阵计算和光子矩阵计算延迟对比示意图大规模光电集成赋能智能算力网络14目前主流的人工智能推理算法大多满足于8比特以下的定点数，与光子计算特性较为匹配；而科学计算领域的计算大多默认为高精度的浮点数，光子计算在这些领域的应用会涉及一些额外的软件优化工作。3.1.2 助力高效芯粒系统：片上光网络（oNOC）在光子矩阵计算之外，大规模光电集成还能够助力芯粒系统。芯粒系统通过更大的片上面积、更多种类的异构单元来提高单节点的算力和算效。然而，芯粒系统的规模扩大也带来了信号传输的瓶颈。一种解决以上问题的思路是使用片上光网络（Optical Network On Chip，oNOC）代替模块间的电互连，如图5(a)所示，两个电芯片被堆叠在同一个光芯片上，电芯片之间的数据传输由光芯片上的光波导链路实现。基于光传输对于距离不敏感的特点，片上光网络可以包括大量的长距离通道。如图5(b)所示，光芯片能够扩展到整个晶圆，从而实现晶圆级的光互连网络，可支持数十个以上的电芯片互连，实现二维环绕等各向同性网络拓扑（如图5(b)中橙线所示）。在这样的拓扑下，将计算任务映射到不同芯片的工作被极大简化，并且达到更高的利用率。不仅如此，片上光网络也凭借其高带宽和低延迟的特性可以为面向未来AI加速器的多形态计算架构18（Polymorphic Architecture）提供关键的片上互连基础设施。电芯片波导电芯片光芯片LGA基板（a）电芯片通过光波导互连的截面图（b）电芯片通过光波导互连形成的 晶圆级光网络俯视图激光器光波导互连电芯片光芯片图5 oNOC系统侧视图及俯视图大规模光电集成赋能智能算力网络153.2.1 物理层创新在一个互连系统中，信号在传播中会遭受损耗、串扰等影响，使得信号质量劣化。多种技术手段可以提高信号质量，满足误码率的要求。最直观的做法是提高信号本身的强度，但这通常意味着更高的能耗。另一种做法是使用一些纠错算法来降低误码率，例如前向纠错（Forward Error Correction,FEC），但这通常意味着更高的延迟。例如3.2 多节点算力扩展方案：片间光网络（oNET）目前基于以太网的分布式计算受限于互连延迟和带宽，在整体效率上有较大提升空间。如图6所示，在传统的数据中心架构中，计算芯片对外的光互连需要通过以太网卡。一种优化数据互连的延迟和带宽的方式是取消网卡，将计算芯片直接和光电转换模块连接。如果计算芯片使用了光子矩阵计算模块，计算的结果甚至有可能直接接入光互连网络。这类针对计算优化的光互连概念，尚未形成统一业界标准。业界对这类光互连的称呼包括“芯片出光（Optical I/O)”，“光学计算互连（Optical Compute Interconnect）”等19,20,21。后文中将这类计算芯片之间的光互连概念称为片间光网络（Optical inter-chip Networking），简称oNET，以区别前面所提及的片上光网络（oNOC)技术。实现低延迟、高带宽、低能耗的片间光网络，需要物理层和互连协议两方面的创新。计算芯片网卡计算芯片光电转换光电转换电信号电信号光信号光信号电信号以太网光互连计算芯片光互连图6 以太网光互连和计算芯片光互连大规模光电集成赋能智能算力网络16对于CPU而言，通用的对外通信通过PCIe协议实现。目前数据中心内的光互连解决方案绝大部分是为以太网设计的。基于PCIe的光互连解决方案几乎处于空白状态。如表1所示，相比于以太网，PCIe信号的通道数较多，单通道带宽较小，调制方法不同，对延迟的容忍度小很多。因此，基于以太网的光互连方案无法直接套用到PCIe应用场景，需要重新定义和设计。目前以太网中使用的FEC算法会带来100ns-200ns的额外延迟22。因此，要同时达到低延迟、低能耗等要求，最佳的办法是尽力减少信号传播中的劣化。通常计算芯片输出的是电信号，而电信号传输损耗对距离敏感，因此缩短计算芯片和光电转换模块之间的距离有助于降低系统功耗和延迟。如图7（a）所示，传统的服务器中，计算芯片对外的光通信通常使用可插拔的光收发模块。更进一步的方式是图7（b）所示，将光电转换模块放在主板上，尽量接近计算芯片，从而形成板载光学（OBO)互连。而终极的解决方案则是将光收发模块与计算芯片封装在同一个基板上。这种方式被称为共封装光学（Co-Packaged Optics，CPO）。（a）（b）（c）主板封装基板计算芯片封装基板重定时芯片可插拔光模块主板封装基板计算芯片板载光学主板封装基板计算芯片共封装光学图7 计算芯片与光电转换模块间互连方式的演进大规模光电集成赋能智能算力网络17基于PCIe通道数较多、延迟容忍度低的特点，集成硅光互连提供了一种较好的解决方案。图8展示了一种系统结构。光电转换由一组3D堆叠的电芯片和光芯片完成。整个结构可以被封装在计算芯片周围，实现共封装光学模块。这类光电转换模块也可以被安装在主板上，形成板载光学模块。3.2.2 互连协议创新当前主流的分布式计算主要使用基于以太网的软硬件生态系统，而这一系统存在诸多的提升空间。实现分布式算力网络需要高效的数据并行和同步机制。目前基于以太网的方案需要使用内存屏障甚至软件设定临界区，使得性能开销大、延迟长，在复杂的控制流程之下甚至会出现死锁。一种解决以太网缺陷的方法是基于PCIe物理层的CXL（Compute Express Link）23生主流数据格式调制方式延迟容忍度4100GPAM4不敏感1632GNRZ100nsEthernet(400G)PCIe/CXL(Gen 5.0)表1 以太网和PCIe/CXL 光互连解决方案的对比光纤电芯片光芯片LGA 基板计算芯片电芯片光芯片LGA 基板计算芯片图8 集成硅光互连方案系统架构大规模光电集成赋能智能算力网络18因此，结合光子矩阵计算（oMAC）、片上光网络（oNOC）和片间光网络（oNET）等技术，光电集成技术的光电混合数据中心新范式赋能智能算力网络将成为可能。态。CXL是由英特尔等公司牵头的开放互连协议。该协议基于PCIe物理层，强调高带宽、低延迟。CXL自2019年发布以来获得了广泛的支持。CXL董事会成员几乎囊括了全球所有主要互联网和半导体企业。相比于以太网协议，CXL协议提供了高效的数据同步，可以大大简化软件管理的复杂度，降低CPU处理网络功能的开销。点对点的传输延迟可以从以太网的10微秒量级减少到100纳秒量级。3.3 算力网络新范式如图9所示，光子计算提供了一条超越摩尔定律的算力提升路径；晶圆级片上光网络使得新范式的计算芯片可以和传统的电芯片以及存储芯片有效协同，在单节点内提高算力；在此之外，基于CXL协议的跨机柜光网络支持了高效的资源池化，使得大型分布式计算系统变得前所未有的高效、灵活和节能。片间光网络（oNET）CPU池计算池内存池存储池生态合作伙伴曦智科技解决方案CPUCPUCPUCPUCPUCPU片上光网络(oNOC)赋能的XPU系统光子矩阵计算(oMAC)服务器图9 光电集成技术的光电混合数据中心新范式示意图大规模光电集成赋能智能算力网络19人类对于算力的渴求永无止境。随着社会进入数字经济时代，数据已经成为核心战略资源，正在加速重构人类的生产和生活方式。生产力的发展将更多的人和物囊括于虚实结合的数字化空间中，通过采集、加工、挖掘、分析数据，人们借助更复杂的模型来洞察数据资源所蕴含的巨大价值，最终驱动生产方式深刻变革，推动数字经济高质量发展和国家信息化水平提升。算力基础设施则是驱动数据要素向生产力转化的核心引擎。因传统算力提升路径受限于物理原理，新的算力提升方式必然成为数字经济时代信息产业发展的焦点，加快算力网络创新发展对于构筑国家竞争优势尤其意义重大。在海量数据和丰富应用场景的驱动下，新的算力革命正在酝酿。其中，大规模光电集成技术在传统数字电路的基础上，引入基于集成硅光的信息处理和互连能力，提供了一条新的算力提升路径。如同历史上所有创新技术的发展历程，新的计算范式在供应链、生态、商业模式上必将经过一个变迁阶段，从最底层的光电元器件制造到最顶层的应用软件开发，在充分利用现有集成电路生态的同时，也需要摸索出最符合行业特性的做法。可以看到，站在电芯片生态的肩膀上，光电混合技术近几年发展迅速，孵化于麻省理工学院的光电混合计算初创企业曦智科技，从2017年其创始人沈亦晨博士发明光子矩阵计算技术（oMAC）到2021年发布全球首款6464光子张量协处理器PACE只用了四年时间，而电芯片达到同样阶段经历了数十年的历程。随着硅光全产业链的日益完善、相关技术标准的相继形成，以及学术界、产业界的大力推动，硅光产业发展和生态建设正不断加速。大规模光电集成的算力网络新范式必将形成更大的竞争优势，成为助推数字经济与实体经济融合的重要动力之一。大规模光电集成赋能智能算力网络20AIBOWCMOSCPOCXLDSAFECGPUHBMILPLGAOBOoMACoNEToNOCPCIeSIMDSMSRAM TLPTPUUCIeWSEXPUArtificial IntelligenceBunch of WiresComplementary Metal-Oxide-SemiconductorCo-Packaged OpticsCompute Express LinkDomain Specific ArchitectureForward Error CorrectionGraphics Processing UnitHigh Bandwidth MemoryInstruction-Level ParallelismLand Grid ArrayOn-Board OpticsOptical Multiply AccumulateOptical inter-chip NetworkingOptical Network On ChipPeripheral Component Interconnect ExpressSingle Instruction Multiple DataStreaming MultiprocessorStatic Random-Access MemoryThread-Level ParallelismTensor Processing UnitUniversal Chiplet Interconnect ExpressWafer Scale EngineCPU,GPU,.人工智能线束互连接口互补金属氧化物半导体共封装光学计算互连标准领域专用架构前向纠错图形处理器高带宽存储架构指令级别并行触点阵列封装板载光学光子矩阵计算片间光网络片上光网络外设组件互连标准单指令多数据流流式多处理器静态随机存取存储器线程级别并行张量加速器通用芯粒互连技术标准晶圆级计算引擎非特定架构处理器缩写全称中文大规模光电集成赋能智能算力网络211 Dario Amodei,Danny Hernandez,et al.AI and compute,2019 Online.Available:https:/ope- Dennard,Robert H.,et al.Design of ion-implanted MOSFETs with very small physical dimen-sions.IEEE Journal of solid-state circuits 9.5(1974):256-2683 David Rotman,Were not prepared for the end of Moores Law,MIT Tech Review,2020 Online.Available:https:/ Johnsson,L.,and Gilbert Netzer.The impact of Moores Law and loss of Dennard scaling:Are DSP SoCs an energy efficient alternative to x86 SoCs?,Journal of Physics:Conference Series.Vol.762.No.1.IOP Publishing,20165 中国信息通信研究院产业与规划研究所，阿里云计算有限公司，“新一代体系化创新的云”，20226 Yukun Sun,et al,Computing Power Network:A Survey,2022 Online.Available:https:/arxiv.org/pdf/2210.06080.pdf7 Padala,Pradeep et al.Adaptive contro