从多视角切换到低延迟分发：技术负责人许知远的架构复盘手记

一次切换卡顿引出的架构讨论

许知远是pg直营站视讯链路的技术负责人。他习惯把问题写在纸上再动手。那次多视角切换出现明显卡顿，用户反馈集中在一个时间段，他带着团队把切换路径逐段拆开，发现缓存预热没有覆盖到边缘节点。问题不大，但暴露了架构上的惯性：大家默认切换是轻操作，没把它当成需要独立保障的环节。pg直营站的解决方案栏目里，多视角切换耗时被明确要求不超过400毫秒，许知远说，这个数字逼着团队重新审视整条链路。

调整方案并不复杂：把切换前的缓存预热做成标准动作，在灰度阶段验证码率自适应命中率是否达到96%以上。上线后切换耗时稳定在350毫秒左右，播放错误率也压到0.3%以下。许知远在复盘手记里写：很多架构问题不是能力问题，是注意力分配问题。

低延迟分发的三次取舍

低延迟分发是许知远投入精力最多的方向。他总结了三段取舍。

• 第一段：优先保稳定。端到端时延放宽到800毫秒以内，先把月度可用性做到99.95%，再谈优化。
• 第二段：优先保画质。画质达标率提到98%以上，码率自适应策略从保守改为动态，卡顿率控制在1.5%以内。
• 第三段：优先保体验。首帧加载时长压到1.2秒以内，音画同步偏差收窄到80毫秒以内，切换与分发统一调度。

他说，这三段不是线性递进，而是根据业务阶段反复权衡。pg直营站的十二项核心指标像一把尺子，让每次取舍都有参照，而不是凭感觉拍板。

把复盘写成可执行的保障条目

许知远不喜欢写长篇复盘报告，他更愿意把结论变成保障条目。比如“灰度阶段必须验证多视角切换耗时”“全量前必须核对音画同步偏差”，一条条列清楚，谁执行、何时核对、偏差如何处理，都写明白。pg直营站的交付节奏里，周一评审到周五复盘形成闭环，保障条目就是闭环里的钩子。

他常对团队说，架构复盘不是写给上级看的，是写给下一次扩容的自己看的。低延迟分发没有终点，只有一轮又一轮的校准。许知远把手记最后一页留白，他说那是给下一次架构调整准备的。