RTC（Real time communication）实时通信，是实时音视频的一个简称，我们常说的RTC技术一般指的是WebRTC技术。 WebRTC是一个由Google发起的实时通讯解决方案，其中包含视频音频采集，编解码，数据传输，音视频展示等功能，我们可以通过技术快速地构建出一个音视频通讯应用，在不借助中间媒介的情况下，建立点对点（Peer-to-Peer）的连接，实现视频流和（或）音频流或者其他任意数据的传输。虽然其名为WebRTC，但不光支持Web，还可以通过编译C++代码达到全平台的互通。 在 B站的直播业务中，有多个互动类型的业务，比如：视频连线、PK、语聊房、语音连麦等。这类业务都有实时性的要求，底层都采用了WebRTC技术。
作为国内领先的在线视频平台，哔哩哔哩（以下简称“B站”）正经历着业务体量和用户规模的快速增长。随着访问量的持续增长和业务复杂程度的增加，在相对有限的服务器资源下如何优化在线服务性能和提高资源利用率，成为了工程研发团队面临的重要挑战之一。 本文将以笔者所在的商业技术中心为例，重点讨论效果广告引擎的在线推理部分。文章将分享笔者在实际工作中遇到的挑战及相应的优化方案。首先，将介绍项目背景和当前系统的运行状况；接着，将详细探讨性能指标量化、服务调用、CPU计算、内存治理及网络IO等方面的优化策略；最后，将总结对性能优化的一些思考，并展望未来性能优化的方向。本文的目的是回顾并总结当前在线服务性能优化的工作，同时也希望这些经验能为其他研发人员在处理类似问题时提供参考和启发。
在文章的开头，我们可以先来了解一下直播业务的大致业务架构。将直播业务简单分为两大类场景"看播"、"开播"，前者主要面向C端观看用户，后者主要面向B端开播主播。主播通过"开播工具"的开播产品功能，经由"开播平台"完成一系列开播动作，最后将媒体信息采集推送到多媒体服务器，C端观看用户就可以从CDN看到直播的视频流内容。 从数据流向来讲，"开播"场景是产生数据和触发关键事件的源头。这些数据或事件会涉及多个领域，如安全合规信息、房间信息、主播信息、开播场次信息、安全审计信息、多媒体信息等。 打个不太准确的比喻。开播系统对于直播平台的重要性，等同于订单系统对于交易平台的重要性。开播工具作为播端功能入口，直接面向官方开播工具（直播姬、粉版大加号、三方工具如OBS开播）的用户以及内部平台方的用户（其他业务线、产品&运营），对开播体验负责。开播平台在其中的职责，是向开播工具和其他平台方提供开播相关的平台化业务能力，如开关播、开通直播间、切换分区等。
云原生，以容器、不可变基础设施、声明式API等核心技术，实现了业务与硬件及底层架构的分离，使业务实例具备了可移植性、环境一致性，极大地提升了运维效率，降低了线上运维操作的稳定性风险，同时又基于微服务、分布式技术解决了传统架构的单点可靠性问题，提升了业务稳定性和开发效率。近年来，越来越多的应用完成容器化、微服务化改造，并逐步将发布、运维流程迁移到PaaS，这在释放了云原生红利的同时也不可避免的引入了更高的系统复杂度，对生产环境的稳定性也提出了更高的要求。 生产环境的稳定性，是各个互联网行业相关公司都关注的，尤其是对于大型互联网公司来说，稳定性就显得更为重要。以B站为例，从诱发稳定性问题的原因分析来看，2022年至今变更及编码问题所占据的比例，在70%以上，问题的诱因也多种多样，譬如缺少稳定性相关必要的可观测指标、灰度观察过程缺失、故障处理机制不完善等等。同时，随着业务体量的不断增大，组织划分与团队协作关系也变得日益复杂，加剧了沟通成本，也间接导致了变更问题难以管控。 对于稳定性来说，业界的一个共识是：防控住变更风险，稳定性问题就解决了一半以上。
接口反爬，或者说更广义的接口安全，一直以来都是网站和app绕不开的基础问题。尤其是平台的规模扩大，各种功能性的接口包含的信息量越来越多，这也让各种目的的脚本爬虫有了获利的空间和爬取数据的动力。
喜欢观看历史剧的观众在B站刷剧时或许已经留意到，经典历史正剧《雍正王朝》悄然将画质从540p@25fps提升至1080p@50fps。在高清高帧率的加持下，这部描绘雍正皇帝生平的经典之作，以丝滑清晰的画面为观众带来了一场全新的视觉盛宴。
带货作为近年来一种新兴、高效的营销形式，在商业侧最早以耦合在必选和邀约广告的业务形态中存在，直到22年中开始作为明确的业务探索方向。从初步确定带货业务的基本定位，到短短的一年多时间，业务极速发展，无论是带货up数还是带货收益以及平台收益层面，均有较快的增长，到目前已形成初具规模的业务体量。期间对于技术侧而言，面对相当多的困难，特别是在几乎无任何基础无独立系统的历史状况下，如何构建高效稳定的平台体系去支撑带货业务的快速迭代和发展需求，存在极大的挑战。
B站的 CDN 下行边缘节点过去是非集群化架构。这种架构下有几个弊端： 增加调度逻辑复杂性； 同机房流量/负载难以均衡； 暴露过多的公网IP，增加安全隐患 (盗链等)； 灰度流量比例分配粒度大； 针对以上问题，我们调研了常见的四层负载均衡器， 传统的 SLB，LVS，DPVS 这类四层负载均衡器，在功能上也能满足我们现有的需求。但是以上几个负载均衡器均需要独占机器，进而造成成本升高，资源浪费。 有没有一种既不增加成本，又能解决边缘节点四层负载需求的方案呢？由 Cloudflare 提出的基于 Express Data Path (XDP) 的高性能四层负载均衡器 Unimog[1]性能优异，并且可以和后端服务同机部署，在性能上也完全满足我们边缘场景的要求。所以我们参考 Cloudflare Unimog 的思想，在其基础上自研了适用于B站的边缘四层负载均衡器 Nickel (以下简称 Ni) 。
Jinkela（金坷垃）Pipeline 是一套用于前端 DevOps 的实验性的胶水工具，解决了许多开发流程中的细节问题，希望简化前端发布的操作难度，如今能力被集成到 Dejavu(逮虾户) 这个在线平台，承载上百个前端业务仓库的 CI/CD 能力。
