企业官网建设流程全解析

预算 20 万，是想自己从头搭一套直播系统，还是直接接入云服务把转码分发这些重活外包出去？不少技术负责人在立项直播系统开发时被这个问题卡住，因为两条路线不只是花钱方式的差别，更牵涉工期、可控性与合规责任三件事。先把账算清楚，比拍脑袋选方向重要得多，选错一次，后面半年都要为这个决定还债。

完全自建到底要养哪些能力？

自建意味着你要自己拥有推流接入、媒体处理、内容分发、播放终端、内容二创的完整技术栈。光媒体处理域就有转码、封装、录制、截图、时移、水印、实时字幕、云端合流、云导播九大功能模块，每一块背后都是分布式转码集群与全球加速节点。业内主流云厂商的实现方式依托全球 3200+ 节点、9 大媒体中心，这套基建的自建成本对绝大多数企业是天文数字。自建的真实痛点不在写代码，在于养一支 7×24 能扛突发带宽与转码并发的运维团队，以及为合规审核、录制存储、带宽峰值持续付费——很多团队低估了"养"的成本，高估了"建"的难度，结果系统建起来没人能稳稳当当地运维。

接入云服务省了什么，又交出了什么？

接入路线把推流、媒体处理、分发交给云，企业只在自己的业务系统和运营后台上做定制开发。你拿到的是推流 SDK、播放器 SDK、OpenAPI、回调服务这一层能力，域名、流管理、模板、工单、数据、日志都在云侧总管理中心以 API 形式开放。省下的是基建与运维，交出的是对底层链路的完全可控性——当出现推流异常、编码缓存抖动、CDN 节点故障，你能做的排查受限于云提供的日志与监控接口。对多数业务型公司，这种交换是划算的方案，把稀缺工程人力集中到自己的业务差异上，而不是重复造一个转码集群，把团队从机房告警里解放出来做产品。

什么规模适合咬牙自建？

只有当直播是你的核心营收且并发与合规要求超出通用云服务边界时，自建才成立。比如需要把直播中心放在特定合规区域、需要自定义底层协议、需要把转码与自有 AI 推理链路深度耦合。实时音视频侧有 3 大混流/转推中心（上海、新加坡、沙特利雅得），若你的业务必须落在云尚未覆盖的节点，自建或自建中台加指定区域云的折中就不可避免。除此之外，中小规模的自建往往是成本陷阱：你为峰值预留的算力，在平日大量闲置，账单却照付不误，而云的弹性恰好能抹平这种波峰波谷。

容量上限也是选型绕不开的硬约束

无论选哪条路线，平台的容量天花板都会反推你的架构。每账号默认最多 20 个直播加速域名，需增加要提工单；北京、上海、深圳每域名最多 300 路转码并发，其他直播中心每域名 50 路，达到上限后超限播放连接会回退播放原始流。时移与封装同一主播流域名最大支持 10 万人观看，超出需提工单；监播每区域默认最多 20 个场次、每域名同时 20 个任务，且"监播中"状态一直计费。这些数字在立项时就要对照你的业务峰值，自建路线下它们是你自己要扛的集群规模，接入路线下它们是你套餐与工单的边界，漏算任何一个都会在促销大场直播时直接掉链子，到时候再扩容往往已经来不及。还有一个容易被忽略的容量细节：原始推流并发本身也有天花板，北京、上海、深圳每域名最多 300 路、其他中心 50 路，与转码并发同档；拉流转推每账号最多 100 路任务并发，超出需提工单；合流任务每 UID 并发 10 路、合流视频源最多 8 个，云导播每域名同时最多启动 20 个导播台。把这些数字和前一段的域名、转码、监播上限放在一起看，它们共同构成选型时的硬性容量边界。自建路线意味着这些上限全部由你自己的集群规模来扛，接入路线则对应套餐与工单边界，无论哪条路线，立项时漏算任意一个，都会在业务峰值来临时以"掉链子"的方式补上这一课。

混合架构：把重活交给云，把命门留给自己

最务实的方案是混合架构：自建运营中台与业务系统，分发与媒体处理接入云端。边界划法是——凡是需要弹性算力与全球节点的部分交给云，凡是涉及企业自有用户、订单、权限与数据的部分留在自己手里。这条路线下，PC 运营管理后台、移动端 App、微信小程序、H5 播放页五端仍然由你掌控，开播状态、弹幕、连麦状态的多端同步逻辑写在你的业务层，云只负责把流稳定送达。混合架构把成本结构从"养基建"变成"按用量付费"，又把核心数据主权留在企业内部，是成长型公司最不容易后悔的选择，也是很多上市公司在合规审计时最站得住的架构。

接入路线下，你仍要自己写哪些业务层？

即便选了接入路线，企业也不是只接个 SDK 就完事。你要在自己的业务系统里实现场次排期、推流地址下发、订单与付费、弹幕与连麦状态，以及面向 PC 运营管理后台、移动端 App、微信小程序、H5 的多端渲染与同步。云端提供的是推流、转码、分发、审核这些底层能力，业务差异——谁能在几点开播、哪些观众要付多少钱、连麦排队怎么排——必须写在你自己的代码里。这部分功能模块的工作量，往往比团队预估的大：它不像转码那样有现成 API，却直接决定产品体验，选型时漏算它，工期同样会失控，最后发现省下的基建钱又花在了自研业务层上。

角色权限在两条路线里怎么分？

无论自建还是接入，系统里都有明确的角色与权限划分。超级管理员管域名、密钥、配额、账务；运营管理员排期、下发推流地址、配模板、看数据看板；主播拿推流地址开播断流；审核员处理审核工单与处置；客服受理申诉与驳回补材料；财务核对用量账单；运维盯监控查日志。接入路线下这些角色权限由云的总管理中心托管，自建路线下你要自己把这套权限模型落到 RBAC。这里风控的复杂度不会因接入而消失——突发带宽 1 分钟增量达 50 Gbps 的限流、审核 block 后的断流处置，都得在你的工单流里闭环，权限模型设计错了，越权操作会直接击穿合规底线，酿成比技术故障更难收场的事故。

合规责任到底谁背？

这是两条路线差异最大的地方。内容审核由视频截帧与语音 ASR 检测覆盖涉黄、暴恐涉政、广告、无意义直播四类场景，回调带回 suggestion 三值，block 级直接断流，review 级进人工审核，客服对主播申诉做驳回或要求补资料。审核、日志、风控、监控四件事，接入路线由云提供能力、你负责配置与处置闭环；自建路线则全部由你实现并承担合规责任。域名准入红线（游戏私服、盗版、涉黄涉赌等不予接入）在两条路线都适用，泛域名下某个精确域名违规会下线整个泛域名，这个风险不会因为接入而转移，责任主体始终是你自己，出事 first 被约谈的是你而不是云厂商。具体到内容安全的能力边界，视频审核与语音审核都是付费服务，截图存入 OSS 另计存储费，且审核功能不支持其它平台的直播流地址，也暂不支持自行添加敏感词——这意味着接入路线下你买到的审核能力是有前提的，自建路线下这些限制同样存在。把这部分成本与限制写进立项评估，方案的可行性才不会在合规落地时打折。

带宽与转码的用量成本怎么估？

成本不能只算初始投入。接入路线下，带宽按下行流量计费、转码按分辨率档位与总转码时长计费，录制还按并发峰值路数加存储费。素材包里的分辨率档位直接决定账单：LD（长边≤640）码率 100-800kbps、SD（≤1280）200-1500、HD（≤1920）500-4000、2K 2000-8000、4K 4000-30000。同一路高清输入转成标清+流畅算 2 路转码流，达到域名并发上限后超限连接会回退播放原始流。窄带高清与 H.265 能显著压低码率从而降本，但 H.265 需要播放器支持。把这些档位和预估并发套进用量公式，才能得到一个贴近真实的月度成本，而不是拍一个 20 万的预算就开工，上线三个月发现账单远超预期。

一张决策矩阵帮你定方向

这张矩阵落到一个动作：先估自己未来 12 个月的并发峰值与合规边界，再决定哪一层必须留在自己手里，方案的范围自然就清楚了。