直播系统的多端口协同与角色权限体系怎么设计

同一个主播，移动端 App 显示"直播中"，微信小程序却显示"已结束"，观众在小程序里点进去是黑屏——这不是前端 bug，而是多端口之间的状态同步机制没设计对。直播系统开发里，推流端与播流端天然分离，五类端口各自消费同一路流却各自维护一份视图，状态不同步就会出这种割裂。这正是多端口协同最典型的痛点：你以为每个端自己能跑通，上线后发现它们对"同一场直播"的认知根本对不上，工单里全是"我这边显示正常"。

别把五端当成五个独立应用来写

从功能模块视角，直播系统的端口不是并列的五个 App，而是一条链路上不同位置的消费方。PC 运营管理后台是总管理中心，承载超级管理员、运营、审核员、财务、客服；移动端 App 是主播端与观众端的主入口，承载主播、观众、连麦嘉宾；微信小程序是轻量分发与裂变入口，承载观众与分享者；H5/Web 播放页负责浏览器跨端拉流；服务端 OpenAPI 与回调服务对接业务系统与第三方平台。架构上要先分清推流侧（主播 App/推流工具）与播流侧（小程序/H5/App 观众端），再设计两端的数据同步机制。推流侧产生的流状态要先落到直播中心，再由回调与统计接口同步给各播流侧端口，H5 与小程序因浏览器环境不同、缓存策略差异最大，是状态割裂的高发地。否则每个端各写一套状态机，后期永远对不齐，排查时谁都说自己没问题。五端不是五个独立项目，而是一套状态机的五个出口，出口越多，状态源越要唯一，这是多端口架构的第一条铁律。

角色权限不清，合规迟早爆雷

系统里至少 9 类角色，权限必须显式划分：超级管理员掌握域名、密钥、配额、账务、全局配置；运营管理员排期、下发推流地址、配模板、看数据看板；主播只拿推流地址、开播、断流、看个人数据；审核员处理审核工单、做违规判定与处置；客服受理申诉、补交材料、回填驳回理由；财务核对用量、资源包、账单、成本分摊；观众观看、弹幕、连麦、购买；运维盯推流质量、响应告警、查日志；第三方平台经 OpenAPI 对接。这套角色与权限矩阵是总管理中心的底座，权限越界一步，就可能让主播自己改掉延迟配置、让客服误操作禁推流，合规风险就从这里长出来，权限模型一旦留口子，安全合规域整层都会跟着松。权限模型里还有一处容易漏：禁推流（永久与限时）是内容治理的硬手段，ForbidLiveStream 上限 10000 路、频率 20 次/秒，通常由审核员或运维在处置违规流时触发；若把它也开放给一线运营，误操作会瞬间掐掉大量正常直播。角色与权限的划分要到这个粒度，系统才既放得开业务、又守得住安全，合规审计时也拿得出权限边界的证据。再补一个容易被忽略的角色——第三方平台。它经 OpenAPI 与回调对接，承担多平台分发的职责，但它同样需要走这套角色与权限模型，只是权限粒度被收束在"对接"这一层，不能越权触达域名、密钥或账务配置。一旦把第三方平台的凭证配成高权限，等于在系统边界上开了个不受控的口子，违规流可能从外部系统绕过内部审核直接放出。所以权限矩阵的划分要覆盖到所有接入方，不只是在自家运营后台里的那几个角色，否则多端口协同的治理会从最不起眼的外部对接处先崩。

Token 与身份体系要覆盖推流和播流两侧

身份体系不能只在管理后台做。推流侧，主播凭鉴权串（由协议+域名+AppName+StreamName+auth_key 组成）拿到推流地址，auth_key 用 timestamp-rand-uid-md5hash 构造，服务端校验失效时间与重算 HashValue，过期返回 403；播流侧，观众经 OpenAPI 或播放器 SDK 拉流，远程鉴权可把登录 Cookie 或 UUID 透传到自建鉴权中心判定合法用户。实时音视频 ARTC 侧还要 SDKAppID、ChannelID、UserID、Token 四元组做房间级隔离。回调鉴权本身也用 MD5：ALI-LIVE-SIGNATURE = LOWERCASE_HEX(MD5(SIGNCONTENT))，SIGNCONTENT 由任务 ID、时间戳、鉴权 KEY 拼接，鉴权 Key 必须 16~32 位字符。技术选型上，权限链路从推流地址的 auth_key 一直延伸到回调校验，整条身份链不能断，Token 与权限必须贯通推流、播流、管理三侧，否则会出现"能推不能管"或"能看不能审"的权限漏洞。

开播状态、弹幕、连麦状态必须走统一源

多端同步的核心，是让所有端口从同一个数据源读状态，而不是各自缓存。开播状态以推流侧的推断流回调为准：RTMP 推流在收到 On Publish 后 2 秒内不主动断开即发推流成功回调，10 秒内无数据则自动断流——这个事件要同时写进 PC 运营管理后台、移动端 App、微信小程序、H5。弹幕与连麦状态走播流侧的消息总线，App、小程序、H5 订阅同一份消息流，保证观众在任意端口看到的弹幕顺序一致。连麦状态则依赖 ARTC 的 ChannelID/UserID 房间模型，Role 决定主播可发布订阅、观众仅订阅。水印、时移这类模块的状态也同样回源，任何一端自己缓存状态而不回源，就会复现开头的"App 在播、小程序已结束"，所以状态源只能有一份，端口只负责渲染，写入权收在统一源。

回调可靠性是同步不丢事件的命根子

状态源要可靠，靠的是回调链路的可靠性设计。推流/断流事件用 HTTP GET（参数在 URL），其余事件用 HTTP POST（JSON Body），兼容 HTTPS。回调地址需可正常访问，超时 5 秒、重试 5 次、重试间隔 1 秒，响应必须返回 200；配置归属上，推流回调与双流灾备回调只能在推流域名配，录制/截图/审核回调只能在对应播流域名配。业务侧最佳实践是不只依赖回调判断推流接入正常，应结合查询域名在线流列表接口二次确认后再下发播放地址。这套可靠性机制，是"App 在播、小程序已结束"不再复现的工程底座——事件丢了，状态就偏了，重试与二次确认把这种偏差的概率压到最低。值得注意的是回调地址本身的可用性要求：超时 5 秒、重试 5 次、间隔 1 秒，且响应必须返回 200，任何一环不满足事件就可能被判定失败而丢弃；部分 SSL 证书与 HTTPS 回调不完全兼容，必要时可退回 HTTP 保证链路通畅。回调鉴权也不能省——ALI-LIVE-SIGNATURE 用 MD5 对任务 ID、时间戳与鉴权 KEY 拼接后的内容取小写十六进制，鉴权 KEY 必须 16~32 位字符，否则身份链会断。把"可靠"和"可信"两件事都做在回调层，多端口的状态同步才既不掉事件、也不被伪造事件污染，PC 后台、移动端、小程序、H5 四端读到的才始终是同一份真相。

审核驳回与日志风控必须跨端闭环

多端口的系统里，合规不能只在某一端做。内容审核在媒体处理环节截帧+语音 ASR，覆盖涉黄、暴恐涉政、广告、无意义直播四类场景，回调带回 suggestion 三值：pass 正常、review 需人工、block 违规。block 级流被断流或限制公开，review 级进人工审核工单，审核员处置后若主播不服，客服受理申诉、做驳回或要求补资料再复审——驳回理由要回填进工单闭环。整个过程，日志模块记录每次推流、断流、审核、处置动作，监控模块对推流质量做秒级盯防，风控模块在突发带宽 1 分钟增量达 50 Gbps 时限流，防止刷量产生高额成本。审核、驳回、日志、风控、监控跨五端统一，是合规直播系统的硬底线，任何一端绕开这套闭环，违规内容就可能从缝隙里漏出去，平台级的处置风险就从这里长出来。驳回不是终点，主播补交材料、复审通过后工单才真正闭环，否则流仍处在 review 待定态，监播与日志会一直把它标记为未决，直到处置动作落到最后一个节点。

这套方案的成本藏在同步链路的调用次数里

做对多端口协同的方案，成本不在五端本身，而在状态同步链路的调用频次与一致性保障。每一条开播/断流事件要同时触达 PC 后台、移动端、小程序、H5，回调可靠性要求超时 5 秒、重试 5 次、间隔 1 秒，响应必须 200。若为了省事只在推流端缓存状态，前面那种割裂故障会反复出现，后续排查的人天成本远超一开始做对同步的投入。一个务实的方案是：以回调事件为唯一状态源，各端口只读不写，OpenAPI 做兜底查询，这样五端的架构最干净、权限最可控、成本最可预期，系统上线后多端不一致的工单量会直接降一个量级，运维也能把精力从"对状态"转到真正的业务优化上。