上个月我们在客户的会议室里,为一套混合云直播架构吵了三个小时。白板擦了四次,最后落下来的方案跟大家进门时想的完全不是一回事。这篇就把那块白板上的内容原样还原一遍,包括中途被推翻的两版。混合云直播架构这个词现在被用得很泛,但真正落到边界怎么划、什么条件切、切完怎么回,大部分方案书里都是含糊过去的。
客户是一家做工业软件的公司,一年大概四十多场对外直播,其中六场是产品发布级别,峰值同时在线要奔着三万去。剩下的三十几场是技术分享和渠道培训,单场一两千人。他们原来全走公有云,今年出了两件事:一是三月那场发布会,公有云的转码集群在开播前十八分钟报了一次区域限流,虽然最后没出事,但技术总监的手一直在抖;二是法务提出,渠道培训里涉及未公开的产品路线图,不能出企业网络。
第一版白板:按"内外网"划,十五分钟被否
进门时大家的默认答案很简单——对内的走私有化,对外的走公有云。这个方案在白板上活了不到二十分钟。
否掉它的是客户的运维负责人,他问了一句:"那三万人的发布会,私有化那套要不要也搭一份?"没人接话。因为发布会既是对外的,又是全年最不能出事的。按内外网划,发布会全押在公有云上,恰恰是风险最集中的那一场没有兜底。
摄行科技这几年接的混合云直播架构项目里,这个误区出现的频率极高。内外网是网络属性,不是风险属性。真正该拿来划边界的,是"这场直播出事以后,谁来背"。
第二版:按并发量划,活了一个小时
第二版是按并发规模来的:两千人以下走私有化,两千人以上走公有云弹性。这版在白板上活得久一点,因为它至少跟成本挂上了钩。
我们当场算了一笔账。私有化那套按峰值两千并发配,需要 4 台转码节点加 2 台源站,一次性硬件投入落在二十七万左右,三年折旧下来每年九万。加上机房托管和带宽包年,年成本大概十六万八。公有云那边按用量结算,去年他们实际花了十一万三,其中光是三月发布会一场就吃掉四万二。
看着好像私有化不划算。但把发布会那六场单独拎出来算,公有云单场四万二里,有一万九是超出预留部分的按需溢价。这部分钱是被"临时扩容"这三个字吃掉的。如果这六场能提前七天锁量,溢价可以压掉大半。
问题在于,他们锁不了。客户的市场部有个习惯:发布会的邀请函要到开播前三天才发完,那之前谁也不知道会来多少人。
第三版:按"可预测性"划,这版留了下来
第三次擦白板的时候,已经下午四点多。我在上面写了两个词:确定量、不确定量。
思路是这样的:不管什么场次,把预期并发的基线部分放在私有化环境里跑,超出基线的部分溢到公有云。基线怎么定?拿过去十二场的历史数据,取第七十五百分位,而不是取平均或者峰值。他们的数据算出来是一千四百。
于是混合云直播架构最终长这样:私有化集群按一千八百并发配容量(基线上浮两成留余量),所有场次的主推流都进私有化源站,由私有化侧的分发层判断当前在线人数。一旦实时在线突破一千五百,自动向公有云 CDN 回源,新进入的观众被调度到公有云边缘节点。这个动作是无感的,观众端不会重连。
切换阈值定在一千五而不是一千八,是留了三百人的缓冲。因为从触发扩容到公有云边缘节点真正接住流量,实测有四十六秒的空窗。我们在他们的测试环境里连测了九次,最快三十一秒,最慢五十八秒,平均四十六秒。这个数字是后来写进 SLA 附件里的。
回切比切出去更容易出事
白板上最后半小时讨论的是回切。这个环节在大部分混合云直播架构方案里都是一句话带过——"低于阈值后自动回收公有云资源"。
真实情况没那么干净。直播结束前十分钟人数会开始掉,如果这时候按阈值自动回收,已经调度到公有云的那部分观众会经历一次强制重连。发布会的 Q&A 环节恰好就在最后十分钟,这时候掉线是最难看的。
所以我们把回切改成了手动确认加延迟锁定:在线人数低于阈值后,系统只做提示,不做动作;导播确认直播已结束、录制已封包之后,再执行资源回收。多花的钱是每场大约两百到四百块的公有云闲置时长,换的是最后十分钟不出岔子。摄行科技在几个类似项目里都用这个策略,客户从来没为这几百块提过意见。
灾备那条线怎么画
会议最后二十分钟补了一条:公有云侧要常备一路冷备源站。
这跟弹性扩容不是一回事。扩容解决的是人多,冷备解决的是私有化那套整体挂了。他们机房去年停过一次电,UPS 撑了四十分钟,那次没有直播。但如果撞上呢?
冷备的做法是编码器双推:一路推私有化源站,一路推公有云冷备源站,平时冷备源站只收不发,带宽消耗几乎为零。播放端的播放地址通过一个轻量的调度接口下发,主源站健康检查连续三次失败(共九秒)后,调度接口切换返回值,新请求走冷备,已在观看的用户在下一个分片请求时自然切过去。实测切换过程中观众端会有一次约两秒的卡顿,但不会黑屏。
这套双推方案对编码器的上行带宽要求会翻倍。他们现场是两条 200M 专线,推 1080p 双路完全够。如果只有一条百兆的场地,这条就得改成公有云侧从私有化源站拉流做备份,代价是主源站真挂了备份也跟着断——那就不叫灾备了。关于现场链路的可靠性设计,可以看5G背包直播真的能替代专线吗里讲的现场侧做法。
一些没写进方案书但很重要的细节
私有化那套的版本要跟公有云对齐。他们私有化用的是自建的 SRS 集群,公有云用的商业 CDN。两边对 HLS 分片时长的默认值不一样,一个 6 秒一个 4 秒。混流切换的时候会出现分片对不齐,观众端表现为进度条抽搐。这个问题我们是在第二次压测才发现的,统一改成 4 秒后消失。
监控要合在一张图上。这一条是摄行科技交付前的必查项。刚上线那两周,运维得开两个控制台来回切,私有化侧看 Grafana,公有云侧看厂商后台。第三周我们把公有云的 API 数据拉过来做了聚合,所有指标进同一块看板。这事听起来琐碎,但真出问题的时候,来回切窗口找数据要多花两三分钟,而直播事故的黄金处置窗口通常也就三五分钟。
成本要按场次归集,不能按月看。按月看的话公有云账单是一个数,谁也说不清哪场花超了。我们给他们做了个简单的标签规则,每场直播开播前打一个 event_id 标签,月底按标签拆账。第一个月拆出来就发现,有两场技术分享莫名其妙走了公有云——查下来是运维忘了开私有化侧的调度开关。
私有化环境下的交付标准怎么定,直播项目验收标准该写哪几条那篇里讲得更细。想了解大并发场景的承载能力,可以看WebRTC在企业直播里能不能扛住万人并发。
三个月后的实际数据
方案落地三个月,跑了十一场。私有化侧承接的并发占比平均 78%,触发扩容的有三场,其中两场是产品发布,一场是意外——某条渠道消息被转发到了一个五万人的行业群。那次实时在线冲到两万三,扩容在四十一秒内完成,后台记录到 17 次播放失败,占比 0.07%。
成本方面,三个月公有云支出两万一,比去年同期的四万六降了一半多。私有化那套的折旧和运维摊进去,综合下来每场直播的技术成本从原来的两千八降到一千九。
技术总监的原话是:"最大的变化不是省钱,是我现在敢在开播前十分钟去趟洗手间了。"
需要注意的是,混合云直播架构不是所有企业都划算。我们的经验是,年场次低于二十场、峰值并发不超过五千的,老老实实用公有云更省心;有明确合规隔离要求、或者年场次超过三十场的,混合方案才开始有意义。这个判断标准可以参考国家标准化管理机构公开的云计算服务安全能力相关要求(std.samr.gov.cn)和中国通信标准化协会发布的行业规范(ccsa.org.cn)。
想让人帮你把这块白板画一遍
如果你正在纠结混合云直播架构的边界怎么划,可以把三样东西发给摄行科技:过去一年的直播场次表(含实际峰值在线)、现有的网络出口情况、合规上明确不能出网的内容类型。我们会免费出一版分流边界建议和成本对照表,告诉你基线该定在多少、切换阈值怎么算、私有化那部分值不值得投。这一步不收费,聊完你自己去招标也行。要报价的话,把并发规模和年场次告诉摄行科技就够了,我们按实配给算,不做套餐。
#摄行科技
