《GY-T402-2024视听媒体微服务技术架构规范.docx》由会员分享，可在线阅读，更多相关《GY-T402-2024视听媒体微服务技术架构规范.docx（52页珍藏版）》请在课桌文档上搜索。
1、GY中华人民共和国广播电视和网络视听行业标准GY/T4022024视听媒体微服务技术架构规范Specificationofmicroservicestechnologyarchitectureforaudiovisualmedia2024-05-132024-05-13发布国家广播电视总局目次前言Il引言V1 范围12 规范性引用文件I3 术语和定义14缩略语35总体架构46基础设施适配层56.1 系统资源适配功能区56.2 数据资源适配功能区66.3 媒体专有设备适配功能区67微服务治理能力层67.1 微服务治理基础功能区67.2 微服务治理扩展功能区98媒体业务服务层128.1 媒体共性支
2、撑功能区128.2 媒体专项业务功能区129平台服务层149.1 业务APl生命周期管理149.2 应用服务发布管理149.3 微服务质量管理149.4 流程引擎服务149.5 规则引擎服务149.6 微服务交易管理159.7 其他平台型服务1510应用集成层1510.1 总则1510.2 开放应用模型管理1510.3 应用适配管理1510.4 低代码开发平台1510.5 应用门户管理1610.6 微前端管理1610.7 其他集成能力16附录A（资料性）MMA应用过程参考17A.1MMA应用开发流程17A.2确定缺省微服务框架17A.3选择微服务框架兼容方式17A.4微服务技术应用成熟度划分参
3、考18附录B（资料性）MMA应用APl接口描述208.1 面向资源的APl设计208.2 UR1.格式参考208.3 APl文档218.4 APl鉴权21附录C（资料性）DevOps简述22C.1概述22C.2过程管理22C.3应用设计23C.4安全及风险管理23C.5Cl/CD管理23C.6防腐管理24附录D（资料性）微服务的类别和架构风格25D.1微服务类别25D.2微服务架构风格25附录E（资料性）MMA应用案例26E.1某省级广播电视台传输调度平台26E.2某网络视听平台内容生产系统29E.3某电视台5G新媒体平台33E.4某省县级融媒体中心省级技术平台37E.5某网络视听机构超高清综
4、合视频平台42参考文献48本文件按照GBT1.12020标准化工作导则第1部分：标准化文件的结构和起草规则的规定起草。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。本文件由全国广播电影电视标准化技术委员会（SAC/TC239）归口。本文件起草单位：国家广播电视总局广播电视规划院、国家广播电视总局广播电视科学研究院、中央广播电视总台、湖南广播电视台、北京深思云天科技有限公司、北京爱奇艺科技有限公司、湖南快乐阳光互动传媒有限公司、中国传媒大学、成都索贝数码科技股份有限公司、咪咕文化科技有限公司、北京中科大洋科技发展股份有限公司、腾讯云计算（北京）有限责任公司、中广电广播
5、电影电视设计研究院有限公司、广东广播电视台、苏州广播电视总台、央视频融媒体发展有限公司、四川传媒学院、优酷信息技术（北京）有限公司、新奥特（北京）视频技术有限公司、北京快手科技有限公司、北京艾嘉博瑞系统技术有限公司、清华大学、华为云计算技术有限公司。本文件主要起草人：邓向冬、郑涛、马艳、向荣、杨剑天、赵慰、易桂、赵明、周立宏、杨剑、覃益明、李春平、曾驾、倪业鹏、柴剑平、黄弘、张岳、王威、丁财志、李琳、陈望都、王彦彬、唐溥成、徐永太、杨政权、牛睿、万时华、邢卫东、刘涛、任科、付晓乐、韩嬷、穆维、王家福、马建明、钱凯、刘雪冬、赵显臣、商鹏、孟一平、高然、季向阳、连晓聪、赵华。本文件参考了ITU-T
6、J.1302:2021Specificationofacloud-basedconvergedmediaservicetosupportInternetprotocolandbroadcastcableIelevision-Systemarchitecture（支持IP和广播有线电视的基于云的融合媒体服务规范-系统架构）的设计原则，针对微服务技术与视听媒体业务的特点和需求，编制了视听媒体微服务技术架构规范。ITU-TJ.1302:2021针对云平台技术，规定了基于云的融合媒体服务的系统架构。本文件针对微服务技术，规定了基于容器、虚机和云等基础设施的视听媒体微服务架构，以支持在多种基础设施上采用
7、微服务方式开展的视听媒体业务。本文件从微服务治理的角度，实现了对当前多种主流微服务框架的兼容，并规定了分布式系统应具备的管理能力；从视听媒体业务的角度，定义了支持视听媒体制作、播出、传输、分发、互动等视听媒体业务的微服务组件；从平台和集成的角度，规定了平台应具有的服务能力，规范了应用集成所使用的技术方法。本文件在通用的微服务技术基础上，结合视听媒体的技术特点和业务需求，突出和体现了行业特色的微服务功能。视听媒体微服务技术架构规范1范围本文件规定了视听媒体微服务的技术架构及相关组成部分的功能要求。本文件适用于视听媒体微服务架构系统的设计、研发、建设、运行和维护。2规范性引用文件本文件没有规范性引
8、用文件。3术语和定义下列术语和定义适用于本文件。3.1糊艮务microservices可独立部署，并提供可实现某应用中特定功能的服务的制品。来源：GB/T425682023,3.1.33.2架构technologyarchitecture整个或部分技术系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法。来源：GB/T433352023,3.1.43.3微服务架构microservicesarchitecture一种软件开发的架构和组织方法，其中软件由若干小型独立的服务组成，这些服务通过定义的应用程序编程接口进行通信。注：该架构以治理微小粒度服务牌11的形式来实现应用程序，通过服务发现、
9、调用和协同的方式来完成业务构建和能力服务。该架构能支持业务快速构建和组装编排，使应用程序更易于扩展和迭代升级，并提供了多样化的技术选型，极大提升了开发人员的效率。3.4视听媒体金艮务架构audiovisualmediamicroservicesarchitecture;MMA面向视听媒体，以微服务为技术手段的系统构建方式，针对视听媒体相关的复杂应用场景，在系统研发、部署及维护中，采用微小化、分布式的手段向用户提供服务，从而避免随着业务场景不断增多而造成系统难以维护和升级的问题。来源：ITU-TJ.1306:2023,3.1.93.5组件component可以复用的软件组成部分（如一组相互关联的
10、微服务、软件应用的某些复用部分等），也称作构件。3.6服务网格servicemesh一组处理服务间大量进程以及相互网络通信的代理组件和任务管理组件。注：代理组件处理入站和出站数据包，任务管理组件控制流量，保障服务之间复杂调用的可靠性和易用性。来源：ITU-TJ.1306:2023,3.2.123.7容器container一套软件，用于提供隔离、资源控制和可移植性应用程序的虚拟化处理。来源：ITU-TY.3535:2022,3.2.13.8领箱containerrchestrati对容器的部署和组织，提供调度和管理容器集群的能力，包括容器自动化部署、管理、弹性伸缩和容器网络管理等。来源：ITU-
11、TJ.1306:2023,3.2.33.9开发运维一体化developmentandoperations;DevOps一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运维和质量保障部门之间的沟通、协作与整合。来源：ITU-TJ.1306:2023,3.2.63.10持续集成与发布continuousintegrationandcontinuousdeployment;Cl/CD一种帮助团队成员频繁集成和发布其工作成果的软件开发实践方法。注：持续集成的每次集成都会经过自动检验，以尽快发现集成错误，缩短系统开发生命周期。持续发布能够自动将己经验证的代码发布到存储库，从而建立可以
12、随时部署到生产环境的代码库。持续集成与发布在很大程度上需要依赖精细设计的自动化测试。来源：ITU-TJ.1306:2023,3.2.43.11API网关APIgateway在服务端实现的、对服务调用者提供统一接入管理的系统，对外部调用提供了统一的出入口，屏蔽了内部服务的实现机制。3.12第三方微服务模块thirdpartymicroservicescomponent通过容器镜像运行的方式，直接在MMA中进行管理和调用，由异构系统实现的微服务或微服务模块在纳入MMA治理时的称谓。3.13适应度函数fitnessfunction用于计算潜在解决方案与既定目标差距的一种目标函数。注：在演化计算中，可
13、决定一个算法是否在持续提升。来源：ITU-TJ.1306:2023,3.2.73.14数据仓库datawarehouse在数据准备之后用于永久性存储数据的数据库。来源：GB/T352952017,2.1,353.15数据湖datalake存储来自多个数据源、多种数据类型的原始数据，数据无需经过结构化处理，就可以进行存取、处理、分析和传输，集中存储各类结构化和非结构化数据的一个大型数据仓库。来源：ITU-TJ.1306:2023,3.2,53.16灰度发布grayscalerelease一种软件产品在生产环境安全上线、平滑过渡的迭代发布方式。注：灰度发布保证整体系统的稳定，能够在初始阶段发现问题
14、，减少影响的范围。3.17框架framework被应用开发者定制的应用骨架，遵照架构实施实现，包括一系列供开发者选用、完成系统实施的组件。3.18开放应用模型OPenapplicationmodel一种用于描述和规范应用程序的范式。注：开放应用模型在应用的生命周期内，通过提供规范的沟通方式，将应用开发者、应用运维人员和基础设施运维人员以一种标准化的方式连接起来，从而让云原生应用的开发、交付和运维变得更加简洁、高效并且可控。来源：ITU-TJ.1306:2023,3.2.113.19低代码开发平台low-codedevelopmentplatform无需编程或通过少量代码就能快速生成应用程序的开
15、发平台。注：低代码开发平台通过可视化的方式进行应用程序开发，使开发人员可以通过图形化的用户界面，使用拖胭件和模型驱动的逻辑来创建各类应用程序。来源：ITU-TJ.1306:2023,3.2.104缩略语下列缩略语适用于本文件。Al人工智能(ArtificialIntelligence)API应用程序编程接口(ApplicationProgrammingInterface)BFF服务于前端的后端(BackendForFrontend)BI商务智能(BusinessIntelligence)CDN内容分发网络(ContentDistributionNetwork)HTTP超文本传输协议(Hyper
16、TextTransferProtocol)HTTPS超文本传输安全协议(HyperTextTransferProtocolSecure)HTM1.5超文本标记语言第5版(HyperTextMarkup1.anguage5)IaaS基础设施即服务(InfrastructureasaSen,ice)ID1.接口定义语言(InterfaceDefinition1.anguage)JSONJaVaSCriPt对象表示法(JavaScriptObjectNotation)MAC媒体访问控制(MediaAccessControl)OCR光学字符识别(OpticalCharacterRecognition)
17、PaaS平台即服务(PEformasaSen,ice)REST表述性状态转移(RepresentationalStateTransfer)RPC远程过程调用(RemoteProcedureCall)SaaS软件即服务(SoftwareasaService)SPI服务商提供接口(SerViCeProviderInterface)TPS每秒事务数(TranSaCtionPerSecond)UR1.统一资源定位符(UniformResource1.ocator)XM1.可扩展标记语言(extensibleMarkup1.anguage)5总体架构MMA总体上应与图1相符合，包括基础设施适配层、微服务
18、治理能力层、媒休业务服务层、平台服务层和应用集成层共五层。其中，基础设施适配层和微服务治理能力层主要负责相关的基础资源调用和技术维护以及微服务的治理：媒体业务服务层、平台服务层和应用集成层主要负责提供视听媒体业务功能域的各类微服务，以及通过这些基础的业务功能性微服务形成平台服务和集成应用的能力。该架构实施的简要过程见附录A;关于系统接口描述，见附录B;MMA宜结合DeVOPS实施，见附录C;常见的微服务类别和微服务架构风格的描述，见附录D:MMA的典型应用案例见附录E。开放应用模型管理;应蠹配;1低代码开发平台鬻JjIIi_一一一一!微前端I其他管理集成能力微服务治理扩展功能区微服务治I分布式
19、第三方微服1I消息上加务器!异构框架事务管理:务模块接入j中间件管理勺料理Il兼容管理I调用链I!框架扩展III管理I能力管理III!III指理-S管一理-管一格-网r务Il度管应数适函!其他扩展;能力管理;注册中心服务通讯微服务治理基础功能区负载均衡服务容错APl网关请求管理I协议转换访问控制11路由策略网关协同过漉管理;J管理和I维护配置中心服务安全服务日志业务APl应用服务微服务质最i流程引擎!规则引擎I微服务交易其他平台平台服务层生命周期管理发布管理管理I服务I服务I1管理1II型服务II-j媒体业务服务层(数据资源适配功能区:媒体专有设备适育功能区、IS由仓系Tl大数据1同菽1IWI
20、阵噩j匕熟适/配/,巧二适胆了_!媒体处理;!媒体存储II媒体传输其他媒体卜专有设备I；专有设备I；专有设备；I专有设备；J)基础设施适配展系统资源运配功能区、1.容器编排系统适配公有/私有云适配I虚机系统适配:I边缘云适配；其他资源适配；1J!jIJJ可选说明:必选图1MMA总体架构6基础设施适配层系统资源适配功能区系统资源适配功能区对底层的基础设施(计算、存储、网络等)进行调用，提供对以下基础资源的适配。a) 应支持容器编排系统适配：提供与容器编排系统相适配的能力，包括与CPU/GPU资源相适配的能力，根据需求，容器编排可与各类具体资源耦合，连接更丰富的基础资源。b) 应支持公有/私有云适
21、配：提供公有云、私有云以及混合云的资源对接，支持以插件的形式提供不同云的接口，实现单一平台管理不同的云。c) 宜支持虚机系统适配：提供与虚机系统相适配的能力。d)宜支持边缘云适配：提供与边缘云相适配的能力。e)宜支持其他资源适配：提供与其他资源相适配的能力。6.2数据资源适配功能区数据资源适配功能区对数据资源进行调用，支持与以下数据资源的适配。a)应支持与分布式或云数据库的适配：提供与分布式数据库或云数据库相适配和调用的能力，应具备生成全局唯一标识符的能力。b)宜支持与湖仓系统的适配：提供与数据仓库/数据湖、数据湖仓一体、实时离线数仓一体等系统相适配能力。c)宜支持与大数据系统的适配：提供与其
22、他大数据系统相适配的能力。d) 提供与其他数据适配：由人工智能大模型带来的数据需求等，可考虑在此进行适配调用。6.3媒体专有设备适配功能区媒体行业的媒体处理专有设备、媒体存储专有设备、媒体传输专有设备、其他媒体专有设备等根据需求可适配融入MMAo7微服务治理能力层7.1 微服务治理基础功能区7.1.1 注册中心微服务注册中心具备以下能力。a) 应高可用。b) 应提供服务注册、服务订阅、服务续约和服务下线管理能力。c) 应提供服务发现的能力。d) 应支持维护服务注册表或库的能力。e) 应保证业务服务调用的安全，在服务注册、服务订阅、服务续约和服务下线等环节都进行严格的服务鉴权。f) 当注册中心的
23、部分节点出现故障时，应不膨响当前业务系统之间进行服务调用。g)宜支持无损发布，如在确定微服务实例己经能提供正常服务之后，才能被注册发布。h) 宜支持容器编排型的服务注册发现能力。i) 宜支持单元化：服务按照不同的逻辑单元进行单元化部署，单元之间会进行逻辑隔离，允许跨单元调度。7.1.2 服务通讯微服务间的通讯具备以下能力。a）应支持协议扩展能力（如通过服务商提供接口插件形式），对新协议进行管理。b）应支持同步通讯能力，对外的API调用以REST（HTTP/HTTPS+JSON）方式实现，对内的微服务通讯推荐以RPC方式实现。c）宜支持异步通讯能力（消息系统或任务管理，如JaVa消息服务、高级消
24、息队列协议等异步消息协议，可扩展消息和表示协议、消息队列遥测传输等实时消息服务协议）。7.1.3 APl网关7.1.3.1 基础功能APl网关应具备如下基础功能。a）请求管理：具备统一接入能力，需承担服务调用、负载均衡和协议转换的功能：需对接外部微服务、APP、小程序等各种前端渠道的服务调用。b）访问控制：具备基础的访问权限控制能力，如黑白名单控制等。c）协议转换：将外部请求的协议转换为内部服务支持的协议：支持异步与同步协议的能力；宜提供屏蔽异步过程的能力，即从前端看与正常同步调用无区别。d）路由策略：提供路由前端请求到服务的不同实现的路由策略能力。7.1.3.2 扩展功能API网关宜具备如下
25、扩展功能。a）网关协同：支持多注册中心，提供分布式网关集群下对多注册中心集群的切换管理功能。b）过滤管理：支持以过滤器的方式对网关功能进行无侵入的热插拔扩展，支持第三方插件扩展特性及动态加载机制。7.1.3.3 银加维护功能APl网关具备以下对网关的管理和维护功能。a）应具备网关集群管理、日志查询、预警管理等服务治理功能。b）宜支持可视化管理，提供实时路由拓扑、网关集群拓扑展示功能。c）可进行格式检查：可以使用模板引擎等技术手段配置和验证检查规则。d）可支持数据转换：支持将返回数据转换成JSON或XM1.等不同的格式，可以使用数据模板引擎。e）可支持BFF模式：将BFF作为服务网关的插件，在服
26、务网关中插拔实现。f）可支持可视化消息查看：提供任意两个服务间的可视化消息查看。7.1.4 负载均衡7.1.4.1 微服务的负载均衡为保证微服务的高可用性，支持以下对微服务的负载均衡能力。a）应支持后端微服务负载均衡能力。b）应支持常见的负载平衡策略，如随机、轮询、加权轮询、IP哈希、最小连接数等。c）宜支持客户端微服务负载均衡能力。d）宜支持粘性会话类型的负载均衡策略。e）宜支持对于同端口下、不同上下文根请求的请求分发。7.1.4 .2网络的负载均衡支持以下对网络的负载均衡能力，保证网络和硬件间负载均衡的协作。a）应支持1.7层负载均衡：在该层的负载均衡能力除了根据IP加端口进行负载外，可根
27、据UR1.、浏览器类别、请求头中关键字段信息等信息来负载均衡。b）应支持1.4层负载均衡：负载均衡服务器在收到第一个来自客户端的同步请求后，通过修改数据包的地址信息（IP+端口号）将流量转发到应用服务器。c）宜支持1.3层负载均衡：支持负载均衡服务器获取网络数据包。d）可支持1.2层负载均衡：支持链路层通过修改帧数据包中的MAC地址来达到转发的目的，所有的真实服务器和负载均衡服务器都有相同的IP（或虚拟IP）地址。7.1.5 服务容错通过以下服务容错手段保障系统的可用性。a）应支持关闭、打开和半打开三种模式的断路器容错模式，在断路器出现关闭状态或半打开状态时，提供必要的告警或通知手段。b）应支
28、持系统对处理的服务数量进行静态或动态的阈值设置，超过该阈值的请求会被直接拒绝或按配置降级返回。c）应支持对重要微服务的自动及手动熔断降级、限流处理，允许对单个微服务进行手动限流、降级和熔断处理。d）宜对一些不重要的服务进行降级设置，通过限流自动管理特定微服务的最大访问量限制或转流。e）宜支持微服务自动容错处理方式，包含提供服务健康自动检查、服务上下线过程中稳定性的保障手段、应用实例异常自动排除等。D宜支持微服务的全链路灰度发布能力。7.1.6 配置中心配置中心提供以下功能。a）应提供静态与动态配置：支持在系统初始化时加载配置信息并生效、不在运行期更改信息的静态配置方式；支持配置信息的动态刷新，
29、在应用程序不重启的情况下修改配置信息并动态生效的动态配置方式。b）应具备针对不同环境（开发或发布等阶段）、不同集群配置能力，宜具备配置权限、流程管理功能。c）宜提供控制管理功能：将分布式系统的配置集中管理，具备管理控制界面，支持权限管理，可以对配置信息进行编辑、发布、回滚，可以查看配置信息的历史版本，监控各节点的配置应用情况。d）宜支持多种配置模式：支持针对属性文件、XM1.文件等文件类型的配置管理，配置文件的内容可以加载到配置管理端，在管理端进行编辑，配置信息可以通过管理端实时刷新到业务系统内存中。支持通过控制台将配置下发到服务器的指定目录，应用程序无需重启即可通过读取该目录下的配置文件实现
30、特殊的业务逻辑。7.1.7 服务安全通过以下手段保障微服务的安全性。a）应通过APl网关对所有客户端请求进行安全的接收和管理。b）应具备基于HTTP/HTTPS的认证、基于会话的认证和基于令牌的开放安全协议认证。c) 应将身份认证存储到专门的授权服务器，为微服务提供访问权限。d) 如消息包含敏感信息，应对消息内容进行加密，对更重要的消息还宜提供验证以确保消息没有被篡改。e) 应支持常见鉴权方式，宜支持自定义鉴权插件。f) 宜支持网关上的令牌转换，APl网关提取访问令牌，并将其发送到授权服务器以鉴权。g) 宜支持多因子认证，含基于黑白名单等服务鉴权能力。h) 当与外部系统通信时，宜对消息进行加密
31、。7.1.8服务日志服务日志满足以下要求。a) 应记录系统基础日志信息：包括微服务系统运行的服务器、网络、存储、中间件、数据库等基础监控信息。b) 应保证日志的完整性：在记录日志时，对产生日志事件的等级、产生事件的类别和方法名称、相关堆栈跟踪信息和异常消息等，要进行完整存储记录。c) 应保证记录的ID的唯一性：系统的应用性能和业务日志记录里每个请求都应具有唯一的ID(可由系统自动生成字段和多个具备业务意义的字段组成)。d)应对应用日志和业务口志的属性进行记录：除了记录实际的日志消息之外，还应该包含附加属性。e)应对严重错误立即生成告警：当处理过程中出现严重错误，而且会一直影响业务并需要人工干预
32、时，应给出日志告警提示。f)宜具备自定义系统业务口志内容的功能：根据不同业务系统的业务规则自定义日志文件的格式和输出内容。g)宜支持灵活的检索能力：支持查看单条日志的上下文日志，支持关键词、正则表达式搜索日志，支持按调用链ID搜索日志查询。7.2微服务治理扩展功能区7.2.1分布式事务管理分布式事务管理具备以下能力。a) 应提供基础的基于分段式提交机制的事务管理能力。b) 应提供基于补偿机制的事务管理能力，同时覆盖短的和长的事务管理。c) 可提供基于可靠消息队列机制的事务管理能力。d) 可支持其他高级分布式事务管理能力。7. 2.2调用链管理调用链管理支持以下功能。a) 应提供关于任意一个微服
33、务调用的可追溯性，主要是提供全面的对微服务调用链的追踪和管理能力。b) 对每个调用链，应提供微服务实例相关信息，如微服务名称、微服务的开始时间和结束时间等基本信息，应提供对其他调用链的引用情况，宜提供微服务的客户化标识。c) 对每个请求调用，应利用跟踪ID和跨度ID,将整个调用链以及其中的每个调用环节串联起来，如请求发起时间、每个环节调用方和被调用方微服务名称、调用的开始时间和结束时间等基本信息。d) 应具备关于追踪数据的数据采集、数据持久化和数据展示等管理能力。e) 应支持调用链和日志的联动，在服务调用中可自动关联调用日志，提供快速排障的能力。f) 宜支持服务和中间件的调用联动，支持中间件（
34、如消息队列、远程字典服务、远程缓存等）、数据库的调用链层级展现。1 .2.3第三方微服务模块接入第三方微服务模块接入应支持以下能力。a）提供容器云平台和镜像仓库用以支持第三方微服务模块镜像的上载。b）提供支持主流微服务模块开发语言的运行环境。7 .2.4框架扩展能力管理框架扩展能力管理支持以下扩展方式。a）应具备过滤器方式：适用于简单的扩展需求，支持动态添加和删除。b）宜具备服务提供商插件（SPlPlug-in）方式：适用于对性能要求高或扩展系统复杂的情况。7. 2.5消息中间件管理7.1.1.1 微服务间异步通信短的消息中间件当消息中间件主要作为微服务间异步通信管理时，本模块具备如下消息管理
35、的能力。a）应提供保留消息数据的持久化机制。b）应提供发布订阅、轮询分发、消息拉回等消息分发机制。c）应具备分布式消息处理能力。d）不应使用HTTP协议作为消息传递协议。e）宜支持高级消息队列协议。D宜支持基于流处理、批流融合处理等消息协议。g）可支持消息队列遥测传输等适合物联网的消息协议。7.1.1.2 流计算引擎的消息中间件流计算引擎的消息中间件具备如下能力。a）应同时支持两类流系统：顺序处理流系统，该类系统对流元素进行缓冲后重排序；无序处理系统，该类系统通过信号来追踪数据流的处理进度，不会缓冲数据以强制排序。b）应满足数据一致性要求：跨越所有流计算上下游系统的数据，反映相同的信息。c）宜
36、支持流数据的完整性推理要求：即支持边界标记（Punctuation）.低水位标记（1.owWatermark）、宽限时间（SlaCkTime）、心跳检测（Heartbeat）等数据完整性推理方案。7.2.6度指标管理度量指标管理支持监控指标获取、日志采集等方式提供以下系统的运行状态指标。a）应提供关键性能参数：微服务APl的调用次数、响应时间、响应码状况和TPS值：网络传输中的关键指标延迟、丢包、抖动、带宽等指标；多媒体应用中的编码、码率、帧率、分辨率和加密状态。b）应提供关键事件参数：业务流程中的事件名称、发生时间，被触发的微服务发送或接收消息的状态。c）宜提供关键路径参数：业务流程中经过的
37、服务节点、参与流程的服务、节点的地址、微服务的端口号、节点之间的网络拓扑状况、连接数和跳数。d）宜提供业务级别的标识信息、业务流水号、用户的标识信息等。e）宜支持对度量指标的可视化图形展现（如在JaVa环境下，支持对JaVa虚拟机的可视化监控，包括线程、方法栈的调用等）。7.2.7无服务器函数管理无服务器函数支持以下管理功能。a） 应支持函数的生命周期管理和函数的触发执行：包括函数的上线、运行、删除、更新等操作。b） 应支持函数冷启动：该启动流程需要考虑到资源调度、容器启动、函数代码下载、函数启动、函数初始化和函数处理调用请求。O应支持函数弹性伸缩：依据应用的资源负载进行弹性决策，或依据请求流
38、量进行弹性决策。d）对有状态函数宜提供程序状态管理功能：状态管理的操作包括状态的生成、状态的访问、状态的操作、状态的删除及状态的回收。7.2.8服务网格管理服务网格管理提供以下功能。a）应提供高性能通信代理（SideCar）,负责各个服务之间通信；应具备对SideCar进行管理的能力，支持查看及管理当前工作空间中的SideCar实例，提供SideCar状态、注入时间等信息。b）具备以下控制面功能。1）应提供遥测记录服务，处理遥测记录，将代理SideCar产生的请求指标送到指定的后端。2）应提供策略执行服务，主要负责集群管理策略的执行。3）应提供认证服务：在服务和服务、用户和服务之间进行认证，实
39、现访问控制；宜包含公开密钥体系，在服务网格中为每个微服务提供客户端传输层安全性协议证书的生成、轮换、撤销以及端到端的验证服务。4） 宜支持多种开发语言应用接入。5） 宜将业务与服务治理能力相隔离，对代码无侵入。6） 宜提供自定义资源控制器，处理自定义资源的变更，并向服务网络中相关的其他服务进行内容分发；宜提供引导服务，对服务网格中的自定义资源，应提供规范配置和编排管理，引导其注入到代理的SideCar容器中。c）应具备数据面功能，能处理服务网格中微服务之间的网络连接，从控制面接收微服务的路由和策略规则，并向控制面报告连接被处理的结果。d）可与资源解耦，提供灵活的部署方式，支持部署在虚拟机与容器
40、上。7.2.9异构框架兼容管理异构框架兼容管理通过以下功能对异构类别的微服务和跨微服务框架的微服务进行兼容管理。a） 应支持统一的服务管理应对后端服务的访问请求，以提高链接收敛、服务治理、高速访问等能力。b） 应支持异构应用互相通信、统一服务治理，提供异构应用的统一管理能力。c） 宜使用一些中立的ID1.定义服务的API,使得在不同平台上运行的对象和用不同语言编写的程序可以相互通信交流，从而帮助实现最大限度的跨平台微服务APl调用。d） 可使用运行时来实现微服务的核心业务功能，而运行时根据执行环境的变化可以进行自动适应。注：运行时是指云计算语义下过程级别的虚拟机。7.2.10适应度函数管理适应
41、度函数支持以下管理工具。a）应支持度量工具：对第杂网络中节点和团组进行度量的工具。b）宜支持模拟工具：对度量参数进行模拟计算的工具。7.2.11其他扩展能力管理其他扩展能力管理包括以下内容。a）针对视听媒体领域微服务计算、存储和网络资源开销大的情况，可提供微服务在多云、多地、多中心的高效率、低成本的综合弹性伸缩能力。b）针对视听媒体领域存在的受法律法规、版权、运营商规则等限制比较严格的情况，可提供可配置的APl合规接入能力，例如涉及隐私请求转发到外部的微服务实例、限制非版权许可地区用户访问某影片、尽量少进行效果不可预测的跨运营商音视频内容传输等。c）针对处理时间较长、重要程度较高的任务环节（如
42、内容生产流程中的渲染、编码等）的情况，可提供对长任务处理过程的监控能力。8媒体业务服务层8.1 媒体共性支撑功能区媒体共性支撑功能区包含以下视听媒体共性服务能力。a）媒体文件管理服务：应包含对媒体文件的新增、加载、查询、传输和加速等服务，以及防盗链服务等。b）音视频内容处理：应包含关于多媒体流的编码服务、压缩服务、推送/接收服务、协议/格式转换、音频控制、抽帧服务、流媒体切片服务、流媒体直播加速，以及Al超清分辨率服务等。c）互动管理服务：应提供短信/彩信/消息网关、评论服务、弹幕服务等。d）用户属性管理服务：应提供IP归属地服务、儿童成人用户信息服务、无障碍访问服务等。e）版权管理：宣包括版
43、权凭证存档、版权确权登记、版权资产仓库管理、版权数据洞察等基础能力，可包括侵权判定、证据固定等维权保护能力，可增加针对版权缺乏查询、广告审核机制等风控预警等能力。O音视频AI能力服务：宜具备针对音视频内容的生成和处理能力，主要包括“人工智能模型即服务”（含视频内容分析、视频特效生成、人脸识别、语音识别、OCR识别、Al文本生成和Al图片和视频生成等）的能力以及模型生成的辅助功能等。g）资源统一缓存管理：宜提供对媒体大文件的本地缓存、分布式缓存、反向代理缓存、浏览器缓存和CDN缓存能力，宜提供热点缓存和多级缓存等缓存策略。h）音视频同步服务：宜提供关于多媒体流的音频和视频同步服务。1） 协议支持
44、：宜支持与媒体业务相关的协议，如终端和媒体网关协议（如基于IP的语音传输、会话邀请协议等），远程资源共享及控制协议（远程桌面协议、远程帧缓冲等），流媒体传输协议（实时传输协议、安全实时传输协议、实时流协议等）。j）其他共性服务：宜提供区块链支持的其他媒体服务等。8.2 媒体专项业务功能区8.2.1 洞察与规划域洞察与规划域的微服务组件宜具备以下能力。a）线索汇聚：开展面向多渠道的线索汇聚。b）舆情热点分析：可通过对时间、事件、人物、地域等进行个性化设置，分析舆情热点。c）选题策划：开展统一选题策划，实现选题创建和编辑、选题筛选、选题审核派发、组合报道等。8.2.2 制作与播出域制作与播出域的微
45、服务组件宜具备以下能力。a）内容汇聚：通过多渠道对文字、图片、音频、视频等内容进行汇聚。b）内容制作：面向多种发布渠道，实现视听媒体内容制作。c）内容播出：面向多种发布渠道，实现视听媒体节目的播出。8.2.3 传输与分发域传输与分发域的微服务组件宜具备以下能力。a）广播电视传输分发：面向广播电视频率频道进行节目的传输覆盖。b）客户端发布：面向媒体接收客户端发布视听媒体内容。c）网站发布：通过媒体网站发布视听媒体内容。8.2.4 运营域运营域的微服务组件宜具备以下能力。a）支持对平台用户和各类软件应用的运营管理。b）具备统一门户，支持用户统一认证登录。c）提供多租户服务。d）为用户提供个性化、可
46、编排的服务界面。e）具备向各应用系统提供必要用户信息的能力。8.2.5 2.5内容监管域内容监管域的微服务组件具备以卜.能力。a）应具备对视听媒体内容审核能力。b）宜具备对视听媒体技术质量进行检测的能力。8.2.6 安全域安全域的微服务组件应具备以卜能力。a）登录认证：支持对登录的用户进行身份标识和鉴别。C)d)e)f)安全审计数据安全签名验签威胁监测b）访问控制：通过授权、认证、访问控制列表、角色、单点登录、双因素认证对用户或其他系统的访问进行限制和管理。支持对重要的用户行为和重要安全事件进行审计。支持通过密码技术保证重要数据在传输、存储过程中的保密性。支持通过校验或密码保证重要数据在传输、存储
