一、概述直播业务具有实时性强，复杂度高，排查链路长，影响面大等特征，线上问题如果不能立刻排查处理，分分秒秒都在影响用户的观看体验、主播的收入。但各端的问题可能都只是表象，例如，一个看似简单的画面卡顿问题，可能涉及到编码器配置、网络带宽分配、服务器负载等多个方面，各个团队经常在等待合作方的反馈，一整套流程下来，一个线上问题的定位可能要消耗掉数小时的人力。我们迫切的需要一套高效的跨端实时排障系统！为此我们采取了以下措施：关键业务监控：联合各协作方，对关键业务的接口、广播和核心处理逻辑实施了实时埋点监控，并附加了相关场景信息，确保了问题定位的准确性和全面性。统一追踪系统：为了实现单个业务链路所有埋点的跨端联络，我们设计了统一的trace_id字段，并在数据层进行串联，通过看板直观展示，极大地提升了问题追踪和定位的效率。这些措施带来了显著的成效：跨部门协作效率提升：通过实时数据共享和统一追踪系统，直播移动端、PC端、Web端、服务端以及流媒体等各个团队协作效率大幅提升。在开播、视频连线等9个核心业务的故障排查中，排障率达到了91%，异常定位的平均时间从2小时缩短至仅需5分钟。兄弟部门也采纳了我们的方案，有效减轻了工作压力。系统稳定性增强：这些措施还帮助我们优化了开播异常断流、连麦发布订阅失败等多项关键业务问题，确保了系统的高效运行，减少了因技术问题导致的用户流失。用户体验改善：我们的快速响应和问题解决能力极大地提升了主播和用户的直播体验。用户和主播的正面反馈络绎不绝，间接提高了主播收入稳定性，增强了平台的吸引力。二、技术方案详解1.

2023年8月中旬文档画中画特性跟随chrome116版本发布，基于该功能特性，我们于2023年10月中旬启动了B站跨页面播放队列功能的开发与功能灰度，并于2024年6月中旬完成了灰度全量。目前该功能入口位于B站网页端的首页，点击首页右侧对应按钮即可打开跨页面播放队列小窗。队列中的视频为稍后再看列表中的视频，在小窗开启情况下，该列表内容会实时响应B站主场景网页中的添加/移除稍后再看操作。文档画中画跨页面播放队列功能是基于文档画中画特性实现的，所以在正式介绍具体实现之前，需要先了解一下文档画中画是什么。文档画中画是一个由

应用将不再允许在其上运行。华为用户在哔哩哔哩的用户生态中一直占据着较大的比例。为了提供更好的用户体验，支持更多的应用生态，哔哩哔哩在去年年底启动了哔哩哔哩鸿蒙原生应用的开发。在对

执行的过程中，将会被解析成如下的一颗执行树：首先来描述一下该语句的执行流程，在解析得到这棵执行树之后，将会通过深度优先的方式依次来执行各个节点。具体流程如下指标数据查询：在叶子节点处，根据指标名称和

时远没有文中那么顺畅，有很多细碎知识点运用并不熟练，初期没有相互关联起来。好在一个问题有多个观察面，念念不忘，逐渐搜集证据和知识，终于破案。以此记录，希望对你能有所助益。推荐阅读：有关

背景介绍大家都知道，详情页承载了站内的核心流量。它的量级到底有多大呢？我们来看一下，日均播放次数数亿次，这么大的流量，其重要程度可想而知。在这样一个页面，每一个功能都是大量业务的汇总点。作为用户核心消费场景，详情页不仅需要承接各种业务的转化，还要负责展示各业务在播放页的功能。可以说，播放页的代码复杂度属于客户端最高的代码之一，这不仅因为播放页本身的功能复杂，还因为它需要融合大量外部业务功能。复杂的功能自然会带来较高的代码复杂度，而高代码复杂度往往意味着高代码维护成本。明确需求我们来看一下没有做这个项目之前的状态。如图所示，他们分别为三个业务团队各自维护。页面间相互独立。能力无法复用。通过这个项目，我们要将他们融合成了一个页面。产品的诉求就是将他们融合为一个，来达到多业务形态统一的目标。但是，这三个详情页并不像产品想象的那么简单。每个业务都有自己的特殊形态，如大型活动态、主客态、播单态、PUGV/OGV态等一系列业务形态。每种形态都有自己的特殊逻辑，而且这些业务形态间还可以互相切换。需求分析为了更好地达成目标，我们需要进行如下思考：从业务角度：要解决多业务形态不统一的问题。例如，产品既想要UGC大型活动的能力，又想要OGV的多视角功能。但这两个能力在之前分别是两个业务团队各自开发的，无法复用，产品在业务选择上无法兼得。从效率角度：要解决迭代方式不统一的问题。例如，进度条体验优化需求，产品在给UGC团队提需求的同时，还要复制一份给OGV团队。两个业务方的开发和测试都需要进入这个项目，并且双方的开发进度和排期可能不一致。如果产品强烈要求同一版本上线，还需要协调各方资源。从质量角度：要解决如何保障稳定性的问题。例如，多团队协作，之前都是组内同事协作开发，现在融入了两个新的业务团队，我们该如何保障稳定性。从团队角度：要解决如何让新人快速上手的问题。正常情况下，新人想要进入开发必须对这个系统足够了解后才行。更何况现在变成了三个业务融合的页面。有没有一种手段，让新人无需关心复杂的业务形态和业务逻辑，只需要关注自己的需求？具体方案针对以上问题，我们可以总结出通用详情页框架必须满足以上三点，分别为：复用性，灵活性，稳定性接下来我们继续对多业务形态进行分析。首先我们从横向上进行拆解，通过对比，我们可以发现多业务形态间其实有很多的相同模块。如互动，弹幕发送框，相关推荐等。从纵向上进行拆解，我们也可以发现很多相同模块，如弹窗管理器，主题组件，转场组件等。那么从横向和纵向上我们发现，多种业务形态间其实有很多可以复用的能力。基于前面的思考，我们设计了一套通用详情页的框架。将其分为三层：业务层：将业务模块分为两类，能够在多业务间复用的模块抽象到通用业务，业务独有模块则由各业务自行负责。组件层：抽象出各种通用组件，业务方可自由选取和组装。框架层：抽象生命周期管理、数据管理等核心逻辑，以此来保证整个详情页的稳定性。这样我们就初步解决了复用性的问题，但是随之而来的就是灵活性问题。我们以实际场景为例，相关推荐模块在课堂态不展示，但是在ugc和ogv下需要展示，另外他的点击事件在ugc和ogv下还会出现差异。同时相关推荐模块还强依赖简介模块。因为简介模块也是一个通用组件，业务方可以自由替换。如果哪天业务方替换了了简介模块，那相关推荐模块将无法正常运行。从相关推荐这个例子我们可以得出如果想让业务模块复用，必须满足两个条件。支持业务异化，即允许业务能插入自定义逻辑，否则现在抽象的通用模块在迭代的过程一定会变成非通用，或者里面掺杂各种if

一、背景&问题：背景：历史上公司点播CDN接入的厂商就比较多厂商之间回源的方式存在细节上的差异不同的厂商之间专线大小存在差异厂商之间的定位不同，有全镜像存储厂商，作为源站资源副本永久存储，也有镜像存储厂商问题：在有新的流量做调度切换或者专线异常恢复的时候，专线和UPOS源站的压力较大厂商回源策略有黑盒，在出现问题的时候定位难度较大，处理效率比较低二、点播回源架构的策略变化和演变：1、点播回源故障具体案例和反思多厂商专线在某次故障期间和专线恢复时存在专线带宽突发的情况事后我们分析，专线上涨是由于厂商专线下面不同类型回源影响到的，而在故障当下，我们因为缺失细粒度的专线监控，而且我们也不能做CDN切量的操作，因为会担心流量有雪崩的风险，所以定位和止损的效率不高

背景审核平台接入50+业务，提供在线审核及离线质检、新人培训等核心能力，同时提供数据报表、资源追踪、知识库等工具。随着平台的飞速发展，越来越多的新业务正在或即将接入审核平台，日均页面浏览量为百万级别。如今审核平台已是公司内容生产链路上的关键一环，是保障内容安全的重要防线，因此稳定性至关重要。过去一年我们曾对前端项目进行框架升级，考虑风险与成本最小化，选择了渐进式升级，利用微前端实现Vue2和Vue3共存，新接业务在Vue3仓库中开发。经过一年的迭代，Vue3项目趋于稳定，沉淀了大部分通用能力。为了降低多仓库维护心智，同时解决核心模块的技术债务，考虑将剩余活跃代码进行重构并迁移至新仓库。面向迁移的重构

arm64。再叠加上文提到的Toolchains能力缺失，这个问题再一次被指数级放大。这只是一种组合关系，我们设想一下在Gradle世界中这件事几乎是不可能完成的，所以也可以同样借鉴隔壁的bazel

小背包一个。6月21日中午12点开奖。如果喜欢本期内容的话，欢迎点个“在看”吧！往期精彩指路B站基于Clickhouse的下一代日志体系建设实践中后台平台化探索和演进猫耳

长连接作为我们实时通信的基础。在我们推进用户体验优化的工作中，其中用户成功进入直播间的时间是我们优化的一个重点指标，其包含了房间信息接口的调用、长连接的建立、播放器拉流的首帧等。本文主要介绍我们在

摘要H5页面给人的感觉通常是开发成本低、迭代速度快但使用体验不佳。其中最容易被用户感知的体验问题就是首屏速度，由于H5页面的所有资源都需要实时从网络上下载，提升这些资源的加载速度就可以明显提升首屏速度。我们通常将提前下发资源到App，并在打开H5页面时使用预载资源加速访问的技术称为“离线包”。B站的离线包技术方案与大部分互联网公司实现的方案在底层逻辑上是一致的，都实现了基础的资源下发和拦截匹配机制。但在此基础上我们也有一些创新，例如页面快照技术、AB实验能力，同时也做了很多优化，包括用扫码调试降低调试成本、版本快速收敛、预约定时错峰发布等。目前我们的离线包技术已经接入183个项目，覆盖12个业务线，在公司内被广泛使用。页面加载速度的瓶颈分析当我们用工具分析一个典型H5活动页（2024纪录片开放周）时，可以发现一个页面的速度瓶颈主要在这些方面：HTML请求通常按照HTML是否动态生成，将其分为SSR（服务器端渲染）和CSR（客户端渲染）页面。SSR受服务器负载、页面复杂度和网络拓扑影响，首字节时间相对较晚，但一旦收到HTML响应，浏览器引擎就会立刻开始解析和绘制，所以首屏时间相比CSR会更有优势。CSR的优势在于可以很容易地使用部署在各地的CDN服务节点来加速，且可以配置一定时间的缓存，所以首字节时间更短，但所有页面结构都需要JS运行后才可以产出，首屏时间会晚很多。通常CSR页面的响应时间大概在10ms-50ms，SSR页面通常50ms

跨平台语言benchmark大横评在这个部分，我们将对几种主要的跨平台语言进行比较，主要从执行效率、引入testcase前后app体积变化、运行内存峰值和运行内存的overhead这几个方面进行考察。对比的平台在iOS、AndroidOS、HarmonyOS这三个平台上进行测试，由于不同平台的硬件设备无法做到一致，所以我们会在各平台选一款设备作为测试标准。对比的语言在目前bilibili实际生产环境中使用到的语言，分别为Kotlin、JavaScript、Dart、C++、Swift。测试方式测试集关于测试集，考虑到真实研发场景在研发过程中其实多数在于Model的操作，又由于bilibili大多使用grpc作为通信协议，积累了较多的真实业务场景的protobuf文件，

榜单系统的定位和业务价值榜单遍布B站直播相关业务的各个角落，直播打赏、直播间互动、付费玩法、互动玩法、活动、主播PK、语聊房、人气主播排名、高价值用户排名、增值集卡、up主充电等等，在这众多的业务场景中，我们能看到各种各样的榜单。榜单的存在，可以激发主播提升表演水平、提高表演质量的积极性，从而吸引更多的观众。观众也可以通过榜单展现的排名，了解其他人对主播的互动打赏情况，激励他更加积极地参与互动或打赏，从而获得认同感和存在感。通过榜单，主播又能获得更高的收益和更多的曝光流量。总之，榜单是一道连接平台、主播、观众的重要桥梁，对提升整个直播的良好氛围有着极大的作用。另外，用户上榜的规则是多样化的，确保消费打赏行为不会过度商业化，在引导观众理性消费和平台健康发展方面也起着积极的作用。业务概览下面是榜单系统的产品业务架构图，虽然忽略了很多细节，但从此图可以对B站直播榜单系统的全貌有个初步的认识。系统介绍在文章开头已经介绍到了直播业务中榜单的种类是非常多的。从榜单成员角色看，有主播榜、用户榜、道具榜、房间榜、厅榜、公会榜；从竞争排名的范围看，有全站榜、分区榜、活动赛季榜、直播场次榜；从结榜时间粒度看，可以分为长期榜、季度榜、月榜、周榜、日榜、小时榜；从具体场景上看，一些业务还会对榜单进行“赛道”划分，如地区榜、男生女生榜，“赛道”的含义由业务方自定义、自理解。由此可见，榜单系统所承载的业务不仅仅是场景多，而且接入形态各异。所以从接入易用性和开发效率上讲，对榜单系统的通用性和灵活性有着较高的要求。接来下我们就从榜单配置化、业务接入、面临的挑战等几个方面介绍一下榜单系统。榜单配置经过这么长时间的发展，榜单几乎成了每次业务迭代的伴生需求。很多时候每上线一个新的业务需求，就会同时上线一个甚至多个新的榜单，榜单系统因此就成了日常业务需求迭代的“基础组件”。那我们如何快速配置上线一个新榜单呢？做法就是打开管理后台，配一配。基础配置榜单ID会在新榜单配置时由系统自动生成，生成后不再改变。后续通过接口进行榜单数据的读取、更新时，都需要指定榜单ID。榜单ID是榜单系统中的“硬通货”。

函数实现函数会检测代理的请求是否命中规则，命中后按规则描述篡权请求内容规则相对简单，使用语法解析是为了保持扩展性，字符串处理多写几个条件判断也能实现。数据存储数据（Mock

本期作者蔡尚志哔哩哔哩资深开发工程师刘勇江哔哩哔哩高级开发工程师杨成进哔哩哔哩高级开发工程师张建锋哔哩哔哩高级开发工程师背景介绍B站的下行CDN旧架构如下图所示，可以看到边缘CDN节点与中心调度服务有紧密协作，简单说是先由调度服务进行流量调度(负责均衡的调度到每个网关组件节点），再由回源组件进行集群内的回源收敛，最终到对应的回源节点进行回源。随着业务体量的增加，这种模式所带来的风险也不断的被暴露出来。注：同集群指在相同机房；节点指物理机器或者容器这种模式存在以下几种弊端：中心调度服务的负载均衡策略与边缘同集群内的回源收敛策之间的协作难度大(回源节点选择不一致、资源冷热判断不一致等等)，导致"事故"频繁边缘节点出故障后，中心调度服务从感知到故障事件，再到流量切走，再到长尾流量干涸，这一过程起码需要20分钟，遇到直播业务那就更惨资源(cpu、缓存)利用率不符合预期，存在毛刺多、不均衡和回源率高等问题，频繁触发SLO告警治理/提升用户播放体验的开发难度大且复杂性高，比如资源预热，需要提前知道直播流会分配到哪几个网关节点上等等根据以上几个点以及点/直播业务特性，我们提出了几个最基本的要求，以满足日益增长的流量和对播放质量的追求网关组件必须具备流量分流能力，具备7层负载均衡加4层负载均衡能力一套集群内组件服务状态检查机制，做到及时发现过载组件进行扩容以及能敏感发现故障组件进行踢出所有策略功能都收敛到中控组件来完成，避免同个资源在不同节点上出现两种不同流量策略，同时也让原有的其他组件改动最小化(保持单体架构的开发思维，提升开发效率)新架构设计网关组件：对外提供用户的访问协议(H1、H2、H3)，具备对访问流量进行鉴权、收敛等功能缓存组件：聚焦磁盘IO技术栈、文件系统以及缓存淘汰策略等回源组件：聚焦回源协议(私有/通用)以及如何提升回源速率等中控组件：聚焦集群内流量路由策略(热流打散、异常组件踢出等等)以及针对业务的定制化优化策略等网关组件具备流量分流能力部分可以拆分成4层负载均衡和7层负载均衡，其中4层负载均衡是由其他组同学完成的(见：B站边缘网络四层负载均衡器的探索与应用）4层负载均衡主要解决由于调度不均衡导致的节点负载不均衡问题，同时又能及时切走故障的7层节点，提升系统的整体容错性7层负载均衡主要解决当缓存组件或者回源组件出现问题时，踢掉问题组件并且重试到其他节点(回源依旧会优先回到之前的回源组件节点：图中5-1路线），保障用户的播放体验中控组件现在流量入口的问题已经解决了，部分节点故障已经影响不到服务质量，接下来我们重点看一下中控组件(中控组件本身是多节点，且保证查询接口是数据一致的)是如何将其他组件节点串起来的负载均衡策略直播和点播的业务场景还是有些区别的，叠合一些历史问题，这次改造将点/直播负载均衡策略拆成两个单独模块实现，后续计划还是会整合到一起直播负载均衡策略我们将负载能力划分成一个个小长方条，当某个资源(流)占据的条数>=N时，则会触发流量打散策略，将溢出的流量划分给其他组件，如图中“组件-1”内的深绿色大长方条，被平均切割成3个中长方条接着，我们可以看到网关组件会将每个请求的实时带宽同步到中控，这也是所有策略的数据源。中控组件对数据进行清洗、整合和观测，实时调整网关组件的流量链路，如图中绿色的实线链路点播负载均衡策略因点播文件大小普遍大于缓存组件的分片大小，所以在网关组件这边根据分片大小进行切分，并用一致性哈希方式进行负载均衡，虽然做法很糙，但也足够用这里我们在nginx

本期作者王妍君哔哩哔哩高级开发工程师背景Matroska是一种开放标准、功能强大的多媒体封装格式，可容纳多种不同类型的视频、音频及字幕流，其常见的文件扩展名为.mkv、.mka等。与应用广泛的MP4相比，Matroska更加灵活开放，可以同时容纳多个字幕，甚至可以包含章节、标签等信息，成为了许多用户的偏爱。B站Web投稿页上传的所有视频中，封装格式为Matroska的视频占比超过2%，是除MP4以外占比最高的格式。Web投稿页作为稿件生产的第一个环节，在获取到用户上传的视频后会根据视频内容为用户投稿提供辅助，其中包含：获取视频元信息，为快速转码提供预分析，缩短转码等待时间，同时为页面其他功能提供视频的基本数据。获取视频抽帧画面，对视频画面进行计算，根据计算结果进行AI智能推荐及自动填写，如封面推荐、分区推荐等，为用户填写稿件信息提供辅助。而这些内容的实现，都基于对视频文件的解析，其中又包含了解封装和解码两个部分。通用方案此前，Web投稿页的实现方案为使用Emscripten将FFmpeg编译为WebAssembly后在Web平台运行，借助FFmpeg的音视频处理能力来进行解封装和解码。这种方案的优点是支持的视频格式齐全，可以解析几乎所有视频格式，但其缺点也很明确——解析速度慢，无法使用硬件加速，性能不佳，内存消耗大，甚至可能导致页面崩溃。升级方案针对MP4格式视频的解析，Web投稿页已经实现了方案升级，改为使用mp4box（https://www.npmjs.com/package/mp4box）进行解封装，然后结合WebCodecs

本期作者吴盛哔哩哔哩高级开发工程师张梦瑶哔哩哔哩高级开发工程师贺一科哔哩哔哩高级开发工程师魏骏文哔哩哔哩资深开发工程师1.

作为年轻人群高度聚集的视频社区，哔哩哔哩在汇聚海量年轻用户、构建优质内容生态的同时，也在不断加大新技术的投入，为用户打造更智能、更安全、更流畅的使用体验。近日，哔哩哔哩宣布完成鸿蒙原生应用Beta版本开发，该版本已具备完备的中长视频消费功能，用户可轻松通过首页推荐、搜索、热门榜单、关注列表等多种方式，发现并欣赏自己喜爱的视频内容。同时，用户还能在此平台上进行一键三连、发表弹幕评论等社区互动活动，充分展现个人观点和喜好。在未来的版本中，B站将继续优化视频消费和社区互动功能，并充分利用鸿蒙原生的智能、安全、互联等特性，为用户带来内容智能流转、页面智能布局等创新体验。B站还将不断丰富产品线，以满足用户多元化的需求。值得一提的是，该应用是鸿蒙原生平台上首个完成Beta版本开发的支持弹幕的视频类应用，相信不久后能为广大用户带来全新的视觉和互动体验。自去年11月底，哔哩哔哩与华为达成合作并正式启动鸿蒙原生应用开发以来，双方团队一直密切配合，力求高质高效的完成开发。开发过程中，双方围绕鸿蒙的多模块管理、编译流水线、ArkUI原生开发以及鸿蒙跨平台等关键技术问题进行了多次深入探讨，共同解决了数百个技术难题，逐渐形成了一套适合复杂业务和多团队协同开发的应用架构。值得一提的是，在解决大量动态模块编译耗时过长的问题上，哔哩哔哩与华为的技术团队付出了巨大的努力。他们联合进行性能调优，深入剖析性能瓶颈，通过不断的尝试和优化，最终成功将原本需要20分钟以上的编译时间缩短至5分钟以内，大大提高了开发效率和便捷性。哔哩哔哩鸿蒙原生应用Beta版本的落地也为更多伙伴提供了值得借鉴的范本。

本期作者万成哔哩哔哩资深技术美术背景随着图形图像渲染技术的快速发展，如何在移动端呈现出高质量的数字人渲染效果，是实时渲染领域最主流的技术研究方向之一。对于B站移动端App而言，如果使用主流的实时渲染引擎如Unreal/Unity等，都会带来100-130M左右的安装包体积增量，进而增加应用安装和版本更新的成本。针对该问题，我们选择了更为灵活轻量的WebGL渲染方案，将包体增量大幅降低至1M以内，同时借助Web天然的开箱即用特性，加速了业务需求在移动端落地的整体节奏。经过对Web渲染能力的行业调研，我们最终从众多的Web3D渲染引擎中选择了Three.JS。Three.JS作为一款轻量级的JavaScript

本期作者姜健哔哩哔哩资深开发工程师1.背景会员购是B站2017年推出的IP消费体验服务平台，在售商品以手办、漫画、JK制服等贴合平台生态的商品为主。随着业务发展，会员购从最开始的预售，现货拓展到全款预售，盲盒，众筹等多种售卖方式，销售渠道也遍布

本期作者张锋哔哩哔哩资深开发工程师业务介绍web投稿页是B站的主要投稿来源，有很多高粉UP主使用web端进行投稿。封面部分是投稿过程中耗时占比较高的步骤，因此在过去，web投稿页已上线了自动的封面截取&推荐功能，有效提升了用户体验。同时在此过程中有了一定的技术积累。自动封面功能依赖于对用户上传视频进行截帧的能力，最简单的方式是在上传完成之后由服务端进行视频截帧并返回推荐的候选封面，但显然这一步会有大量的等待时间，因此我们采用的是纯前端视频截帧能力。实际上在web投稿页有多处需要截帧的地方：封面推荐：截取多张低清图在前端进行AI打分，基于打分结果截取最多10张高清图供UP主选择封面选帧：对默认推荐的帧不满意，手动获取准确时间点的帧画面分区&话题推荐：从视频中截取多帧，打包上传至后台进行分析后返回推荐结果过去方案过去web投稿页采取两套视频截帧方案，wasm优先，canvas兜底Video

本期作者陆元亘哔哩哔哩资深开发工程师在点播业务中，带宽成本在总成本（转码+存储+带宽）中占据绝对的大头。B站很早就开始利用技术手段，对带宽成本进行优化。由于带宽成本=带宽单价*带宽用量，一般降低成本的方式有两种：降低带宽单价：例如使用更廉价的CDN服务。降低带宽用量：例如大家熟悉的编码算法优化，可以在同画质的前提下，将稿件码率进行压缩。之前的优化主要在服务端，而带宽消费的最终端——播放器，在成本中起到的作用，却鲜有关注。针对这一盲区，B站播放器团队利用数据进行了理论分析，发现播放器在带宽用量上有较大的优化空间。从2022年初至今，我们利用播放器中的端智能策略持续降本增效，至今已降低15%的点播带宽成本。这篇文章将详细介绍我们播放器策略优化中的技术手段和思考沉淀。1.

间接调用了编解码器来实现特定功能：视频播放：MSE音频解码：WebAudio录制视频：MediaRecorder实时流媒体：WebRTC但没有方法可以灵活配置或直接访问编解码器，所以许多应用使用

本期作者李渊驰哔哩哔哩资深开发工程师一、引言作为国内领先的在线视频平台，哔哩哔哩（以下简称“B站”）正经历着业务体量和用户规模的快速增长。随着访问量的持续增长和业务复杂程度的增加，在相对有限的服务器资源下如何优化在线服务性能和提高资源利用率，成为了工程研发团队面临的重要挑战之一。本文将以笔者所在的商业技术中心为例，重点讨论效果广告引擎的在线推理部分。文章将分享笔者在实际工作中遇到的挑战及相应的优化方案。首先，将介绍项目背景和当前系统的运行状况；接着，将详细探讨性能指标量化、服务调用、CPU计算、内存治理及网络IO等方面的优化策略；最后，将总结对性能优化的一些思考，并展望未来性能优化的方向。本文的目的是回顾并总结当前在线服务性能优化的工作，同时也希望这些经验能为其他研发人员在处理类似问题时提供参考和启发。二、项目背景笔者所在的团队主要负责在线效果广告引擎的研发工作，该服务作为商业化系统的重要组成之一，为公司带来了实质性的商业贡献。通过精准高效的广告投放，能够为公司带来稳定且可观的广告收入，成为支撑平台发展的关键营收来源之一，进一步支持了平台的内容创新和技术研发，构成良性循环。对于广告主而言，效果广告引擎提供了精准定向用户的能力，显著提升了广告传播的效果，为其带来更高的广告转化和投资回报。对于用户而言，通过更贴近用户行为习惯的广告投放，确保了广告内容与用户兴趣和需求的高度匹配，最大限度地保障了用户体验。随着效果广告业务的快速发展，处理的业务复杂度不断提升，对在线服务的处理效率和吞吐量提出了更高要求。同时，B站的用户规模和使用时长的持续增长也加大了这一挑战。以在线推理服务为例，它需要对广告创意候选集进行一系列预估打分，主要包括特征计算和模型计算两个环节。特征处理阶段涉及用户和广告数据的提取、过滤、拼接等操作，随着特征数据的深入挖掘和应用，所需要处理的数据量也在不断增加。在模型计算阶段，支持的模型类型从LR、FM模型逐渐升级到DNN模型，增强了模型的表达能力，但同时也加大了算力资源的消耗。类似的资源开销增长问题也存在于效果广告引擎的其他服务中。因此，工程研发团队面临的挑战在于如何有效地对效果广告引擎进行性能优化，确保在硬件资源相对有限的情况下，依然能够支持并促进业务的持续增长。三、系统现状首先需要介绍一下效果广告引擎的系统构成，主要包含了以下几个服务：检索引擎：作为广告业务的入口，接受来自各个调用方的请求，并且会对流量进行预处理，其中包括对流量进行实验分组和标记。效果广告检索服务：作为效果广告的业务核心，负责对候选集中的广告创意进行优选，并且将胜选的结果回传给检索引擎。召回/粗排服务：根据流量的上下文信息，从所有在投的广告创意中挑选出一批符合条件的广告创意，并且进行粗排打分，将最终的Top

本期作者赵书彬哔哩哔哩高级开发工程师王清培哔哩哔哩资深开发工程师傅志超哔哩哔哩资深开发工程师郭宇霆哔哩哔哩资深开发工程师朱德江哔哩哔哩资深开发工程师1.背景"凡事预则立，不预则废。"——《礼记·中庸》在文章的开头，我们可以先来了解一下直播业务的大致业务架构。将直播业务简单分为两大类场景"看播"、"开播"，前者主要面向C端观看用户，后者主要面向B端开播主播。主播通过"开播工具"的开播产品功能，经由"开播平台"完成一系列开播动作，最后将媒体信息采集推送到多媒体服务器，C端观看用户就可以从CDN看到直播的视频流内容。从数据流向来讲，"开播"场景是产生数据和触发关键事件的源头。这些数据或事件会涉及多个领域，如安全合规信息、房间信息、主播信息、开播场次信息、安全审计信息、多媒体信息等。打个不太准确的比喻。开播系统对于直播平台的重要性，等同于订单系统对于交易平台的重要性。开播工具作为播端功能入口，直接面向官方开播工具（直播姬、粉版大加号、三方工具如OBS开播）的用户以及内部平台方的用户（其他业务线、产品&运营），对开播体验负责。开播平台在其中的职责，是向开播工具和其他平台方提供开播相关的平台化业务能力，如开关播、开通直播间、切换分区等。同时，开播平台与同级的业务平台一起协作，才能支撑起完整的开播工具产品能力，如语聊房业务需要开播工具管理平台（开播工具类支持）、主播互动平台（主播互动能力支持）、流媒体服务端共同参与才能完成，从不同的维度帮助开播工具生态完善化。一些涉及到的业务/技术名词，在此我们也做出列举并做出简单介绍：名词名词简述领域驱动设计（DDD）DDD

本期作者任奕豪哔哩哔哩资深开发工程师张凯哔哩哔哩资深开发工程师1、接口反爬背景接口反爬，或者说更广义的接口安全，一直以来都是网站和app绕不开的基础问题。尤其是平台的规模扩大，各种功能性的接口包含的信息量越来越多，这也让各种目的的脚本爬虫有了获利的空间和爬取数据的动力。而对于一个平台而言，爬虫流量不同于正常流量，基本上无法带来正向的效益（除了搜索引擎爬虫尚且有推广平台的效果），它们对平台的危害是多方面的：（1）对平台开发和运维，爬虫大量的恶意请求极大地占用了平台服务端带宽和计算资源，让平台无故增加了运维的成本，一些保护程度较低的接口还可能被爬虫流量撑爆，甚至会连锁反应造成平台的故障。（2）对于用户来说，个人的活动和隐私信息或多或少会存放在平台上，爬虫会造成用户的信息泄露，这些信息还可能会被用于诈骗等犯罪活动，导致无法挽回的恶劣影响。（3）对平台运营来说，平台上的活动信息被爬取，使得羊毛党团伙能够在第一时间获取到活动的相关信息，大量羊毛党小号涌入活动会挤占正常用户的活动参与名额，不仅危害业务功能的正常秩序，还会造成活动资金被羊毛党薅走，严重降低活动的运营效果。在B站，目前已知容易被爬虫攻击的接口，包括但不限于视频信息接口、用户信息接口、评论内容接口、直播间弹幕/礼物接口、直播抽奖信息接口、主站活动信息接口等等。这些爬虫怀着各种各样的目的，游走于互联网的灰色地带，有的是为了获取B站的运营数据（比如视频信息接口爬虫、用户信息接口爬虫）；有的是为了在获利的场景更高效率地薅羊毛（比如直播抽奖信息接口爬虫、主站活动信息接口爬虫）；随着NLP对话模型的火热，甚至会出现为模型提供语料而诞生的ugc内容爬虫（比如评论内容接口爬虫）。在站外开源的社区内部，也有一些会针对B站的api进行破解的项目，这些项目提供的接口，也会被爬虫团伙研究利用，成为爬虫的技术基础。为了解决爬虫肆虐的问题，风控、网关、前端、服务端合作推动了接口反爬的事项。而在推动接口安全能力不断完善的过程中，也遇到了不少的问题，同时产出了一些解决问题的探索和思考，下面将通过几个方面来介绍：（1）接口安全整体框架结构（2）风控接口接入方式改造、爬虫风险感知/识别以及处置能力演进（3）网关验签组件的设计和应用2、反爬数据流框架介绍接口流量在整个反爬防控过程中的数据流向如图所示。在整个请求的链路中，包含了两层异常识别的阶段：一层是网关侧在apigw上部署的验签组件，能够对粗暴的恶意接口调用进行识别并直接拦截请求；第二层是风控侧基于上报的设备、ip、账号等特征构建的异常流量识别策略体系，在识别出现的异常流量后，可以对该请求的主体在前端发起真人校验的处置（验证码、引导登录等）。具体来说，前端在请求时，首先会经由网关上报数据到apigw，此时验签组件会先解码请求的参数，校验参数准确无误后（校验不通过的请求会被直接拦截），apigw会将流量发送到风控的GAIA引擎，风控策略判定该请求是否有异常，对疑似爬虫的请求，会返回异常信号；前端在接收到异常信号后，会进入验证交互流程，通过拉起验证码/登录弹窗、请求验证网关/账号鉴权的方式对用户进行真人校验。这样的部署，请求的流量通过apigw作为中转直接到达风控平台，其中异常流量能够被拦截在服务网关之前，一定程度可以起到对业务服务的保护作用。2.1

这类四层负载均衡器，在功能上也能满足我们现有的需求。但是以上几个负载均衡器均需要独占机器，进而造成成本升高，资源浪费。有没有一种既不增加成本，又能解决边缘节点四层负载需求的方案呢？由

本期作者赵丹丹哔哩哔哩资深开发工程师吉翔哔哩哔哩资深运维工程师背景和目标英雄联盟全球总决赛是英雄联盟赛事每年度最受瞩目的节点，也是B站全年赛事热度最高的时段。第13届英雄联盟全球总决赛（下文简称S13）今年继续在B站进行直播，本文主要分享S13赛事保障的实践和思考。S13的业务主目标是观赛用户达到1.2亿，可拆解到赛前、赛中、赛后三个阶段：赛前重在流量蓄水，扩大目标用户，通过赛事活动预热、资源位投放、预约/Push召回，将流量引流到S13赛事主房间（下文简称主房间）观赛。赛中用户集中在主房间，重点在提升用户观赛以及互动体验，提高用户的转化率和留存率。赛后引导观赛用户到稿件播放页观看回放，在评论区参与选手打分，在动态/话题持续发表自己对赛事的观后感。图1

本期作者黄焱哔哩哔哩资深测试开发工程师王旭哔哩哔哩资深开发工程师背景在云原生的架构下，微服务的数量呈现爆炸式增长，服务间的调用关系错综复杂，对系统可靠性也提出了更高的要求。在这样的背景之下，混沌工程的关注度也不断提升。事实上，混沌工程早就不是什么新鲜的概念，早在2008年开始，混沌工程的思想就已经始萌芽，彼时，网飞公司由于数据库发生故障，导致了三天时间的停机，使得

针对以上典型场景，做了以下优化：用户侧前端静态资源业务上要求缓存有效期较短，对可用性要求高；在其他常规稳定性建设基础上，我们在第三方云存储内备份了全站静态资源文件；在源站整体不可用的最坏情况下，依赖

本期作者朱德江哔哩哔哩资深开发工程师王清培哔哩哔哩资深开发工程师赵书彬哔哩哔哩高级开发工程师序言罗马不是一天建成的。语聊房当前架构也是不断演进的结果。在技术架构层面，语聊房作为搭建在直播体系上的业务，使用既有技术架构体系可以帮助我们快速搭建早期产品，但随着业务迭代，已有技术体系又成为新的技术架构的负债。同样在业务架构层面，语聊房产品已经迭代一年，产品形态依然在快速变化，已有的业务架构又会成为新的业务架构的阻碍。每一次产品需求的迭代，都会对已有技术架构和业务架构造成双重冲击。本文将结合语聊房持续演进的过程，谈谈业务视角下的架构演进。以及如何构建能应对各种变化的系统，不断达到新的平衡。语聊房来龙去脉了解架构演进之前，我们先了解语聊房业务的来龙去脉。从语聊房的前身PC版本多人连线算起，整块业务到现在已经迭代一年。上图介绍了这一年来的语聊房产品迭代的2个主要阶段。第一个阶段是2022年7月，从0到1的产品探索期。直播已有的互动能力比如主播和主播视频PK，能力模型是围绕一对一建设的。一方发起另一方接受就可以开始互动，一方退出这一场互动就会结束。这种互动模型在产品上存在诸多限制，比如无法支持一个房间多个主播同时互动的业务。于是为了满足用户需求，我们开始探索了多主播间的互动能力，包括主播与主播，主播与观众的音视频互动的能力。在这个阶段主要目标是对齐竞品，同时完善我们开播工具的基础能力，丰富主播互动玩法。第二个阶段是2023年，语聊房项目经过战略升级，成为专项进行运营。既是一次巨大的机会，又是巨大的挑战。一方面我们在功能层面与竞品还有明显的距离。另一方面在技术架构层面，语聊房的架构是从主播与主播间互动模型演变过来，与语聊房主播与用户间的互动还有很多需要调整的地方。同时相比探索期，专项整体迭代节奏加快，而且对技术质量要求更高。所以在这个阶段，主要目标变成在功能层面快速迭代以满足用户诉求，

本期作者周深哔哩哔哩高级开发工程师李翔宇哔哩哔哩资深开发工程师引言性能优化是个恒久的话题，随着产品的演进，业务的增长，系统能力总有达到瓶颈的一天，它不可或缺的陪伴着我们走向壮大再走向衰败，是我们面临的不可回避的问题。下图1展示了风控系统近半年来承载流量的增长趋势，可见最近半年来流量高速增长，且对于可预见的未来而言，接入流量还会持续高增。伴随着流量的增长，系统各方面--存储、计算、IO等都表现出一定的瓶颈，通过原始简单的水平扩容并不能解决所有的问题，而且还会带来成本的上升。因此，我们近期对系统进行了一系列优化改造，

技术团队研发的一款适用于音视频、直播、特效播放等多种场景的跨进程播放框架。目前支持：音视频、直播、特效播放。支持自定义播放内核，目前内置了

本期作者刘瑞洲哔哩哔哩资深开发工程师王清培哔哩哔哩资深开发工程师引言房间系统是直播业务的“基石”，开播和看播两大体系都是围绕房间场景展开。房间系统架构也经历一系列的升级和挑战，从房间读多活、混沌流量治理、热点发现、多级缓存等，支撑了S11破千万PCU的流量洪峰冲击。为了应对业务更大的挑战，基于CQRS思想，分离大流量的用户高读场景（Query）和注重数据强一致性的开播创建房间等写场景（Command）。对于用户端可以无状态无限制的扩容服务副本，做到支持更大线上用户同时在线的目标。背景直播业务的技术服务体系也实践过从单体到微服务化的演进之路，以技术视角看微服务体现单一职责和关注分离的思想，从大单体应用的进程模块拓展到分布式的应用服务模块化。同时微服务也是有额外成本的，微服务的拆分思路不仅仅是技术层面，更多会取决于组织和团队（以及组织如何去看待业务）。如康威定律所说：Organizations

本期作者徐顺鑫哔哩哔哩高级算法工程师吕柯兴哔哩哔哩资深算法工程师成超哔哩哔哩资深开发工程师前言在线视频领域的繁荣离不开创作者在内容生产环节的辛勤耕耘。视频既是信息得以高速传播的有效载体，也是创作者的劳动成果，本质上也是一种虚拟资产。随着版权意识的崛起，越来越多的创作者和观众都在为保护版权做着不懈努力。然而整个版权环境的建立需要一定的过程，在此期间存在着大量的侵权行为，如对视频未经授权的盗用、剪辑、跨平台间的搬运、未经许可的商用行为等等。同时，对侵权行为的查验、举证、界定等环节都需要耗费大量的人力物力，并可能存在创作者较难处理的技术及法律难点，导致维权本身变成一个成本极高却收效胜微的事情，削减了版权所有者的创作热情。目前主流视频网站会在视频上添加明文水印，例如在视频右上角贴上平台的logo来声明视频的版权，这是一种非常直接且有效的手段。但是针对这种明文水印，有基础视频处理经验的人只需要对视频画面进行一定程度的裁剪就能够轻易去除，更有甚者会采用目前已经非常成熟的AI去明文水印的方法进行抹除。可以看出，版权保护与侵权行为始终进行着的攻防战，也正是这个攻防过程促进了视频水印技术的不断发展。图1

主推送荣誉周报，页面中首屏有非常大的篇幅显示的是本周关键词，效果如下图：这个场景有两处使用了特殊字体「方正FW筑紫黑」，一个是卡片标题「本周关键词」这几个字，这个是固定标题，用传统的切图方式也是

总结事实上，单一页面的复杂业务的拆分目前Android客户端并没有现成的方案，本文也是基于业务开发过程中的探索给出了一种可能性。针对Android客户端复杂业务页面的开发，本文结合当前Android

本期作者王栋辉哔哩哔哩开发工程师一个名为”大力出奇迹“的增长活动，于2023年4月26日在哔哩哔哩app上悄然发布。活动的其中一个核心玩法是：用户可以通过玩一个小游戏，来获取活动代币（其名为”大力币“）。在这个游戏中，用户在8秒内点击一个按钮，每多点击10次，就能多获取一定数量的代币。作为活动的前端部分的主要开发人员，我将把这个游戏拆分成3个主要部分：”倒计时“、”游戏主体“、”撒金币“和”额外赠送机会“等其他动效，并对其技术方案和实现细节进行详细地介绍。【视频

本期作者傅嘉伟哔哩哔哩资深开发工程师背景建设低代码平台的目的，就是通过可视化的方式，加上可复用的建设能力，用较少的投入、以较快的速度来交付应用程序。我们通过aPaaS架构思路，复用已经实现了的开发能力，解构业务模型，形成更通用的能力，对业务进行快速编排。实现低代码，甚至部分无代码的快速定制应用。将开发模式从做加法，改进为做乘法，48小时内快速定制大部分基础应用。我们不单需要解决今天的可见需求，同时还需要解决明天潜在的问题。实现更少的投入，更聪明的办法，建设更好的产品，产生更大的价值。整体架构我们一直在思考，如何通过简单的架构图，来方便的描述出高达的整体架构，看了一眼我们现有的复杂架构图，我们认为贴出这样一张图不会让大家更加清楚我们的架构，反而会变得非常迷茫，因此考虑到高达的组件过于庞大，中间的逻辑实在过多，我们使用一张非常简单的架构图来进行描述。就像所有的网站一样，高达分为三个部分：页面，逻辑，数据用户通过页面，访问API接口，APi接口一方面处理大量的业务逻辑，另一方面对内部和外部的数据进行处理更进一步的：在实现了基本的

本期作者赵伟哔哩哔哩资深开发工程师沈新华哔哩哔哩资深开发工程师前言你会如何总结你的工作内容？“CURD”，这是不少业务开发者对自己工作内容，做出的“哲学级别”总结，不乏调侃和乏味之意。实际上，过来人都清楚，这和业务开发面临的复杂性和挑战不在一个层次。一般情况下，互联网核心业务可以大体分为两类，其一是基础功能性业务，其二是围绕基础功能，刺激增长类业务。以直播为例，可以分为：核心功能类：如送礼打赏、PK连麦等互动消费业务。增长类：通过精细化运营等方式，以刺激核心业务增长(消费)为核心目的，如营收活动。业务开发的第一挑战在于决策与实施的割裂，决策端和实施端是完全不同的两拨人，在关注点、信息量、职业技能、工作方式等方面差异较大，在软件旺盛的迭代协作之下，保障边际生产力是个难点。在此基础上，核心功能类业务很考验“第一个程序员”，业务迭代就像为飞行中的火箭更换零件，更难的在于下次要怎么换，目前还不一定清楚。增长类业务不以“换发动机”这种艰巨场景为主，但基于刺激增长的目的，其在迭代节奏和开发量方面让人望而生畏，基本上是：上线时间已定、套路又变了、时间不多了、不能出问题、下一个需求已经来了···就规模和节奏而言，有人奔溃有人跑路，也正是这样，当越过山丘后，才发现这段路更接近工程的本质。本文，我们基于团队在营收活动业务中的实践经验，探讨如何在快节奏、复杂灵活、工作量大的增长类业务中，保证交付生产力和交付质量。营收活动简介在开始之前有必要介绍下营收活动业务。作为刺激消费为最终目的的业务，基本上有两个特点：联动各方资源(如公会)，绑定节日或时间节点，如春节活动、七月活动等。频率高，倒排期上线业务套路花样百变，联动平台几乎所有业务，巨量的细节和逻辑，高负荷开发量，历史上单活动MR普遍在6000+行以Bilibili

本期作者小雄哔哩哔哩客服业务技术负责人乐文哔哩哔哩资深开发工程师镇宇哔哩哔哩高级开发工程师四百块哔哩哔哩高级开发工程师JasonQian哔哩哔哩高级开发工程师宇琪哔哩哔哩资深开发工程师1

[]byte("test")}})事件处理示例：提供了并发消费、聚合消费等多样的消费SDK套件，使用时只需要提供消息解析与处理的方法，前文提到的所有消费模式都能在控制面按需控制。//

本期作者金斌武哔哩哔哩资深开发工程师一、业务概述哔哩哔哩动态是哔哩哔哩平台上的一项社交功能，可以让用户分享自己的生活、兴趣、观点等内容，并与其他用户进行互动和交流。用户可以在动态中发布文字、图片、视频等形式的内容，也可以分享自己的观看记录、点评、收藏等。除了普通用户，哔哩哔哩的视频创作者（也被称为UP主）也会通过动态与粉丝互动。他们可以发布新视频的预告、幕后花絮、直播间链接等内容，也可以回答粉丝的问题、分享自己的创作经验等。此外，哔哩哔哩动态还支持一种叫做“动态视频”的功能。用户可以录制一段15秒以内的视频，发布到自己的动态中，让其他用户更直观地了解自己的状态和想法。总的来说，哔哩哔哩动态和直播功能为用户提供了更加多元化的内容和社交体验，让用户可以更加丰富地在平台上表达自己的想法和兴趣，并与其他用户、视频创作者进行互动和交流。业务特点流量池子大：日均综合页pv

Agent，在目标方法的前后加上了自定义的拦截器，从而织入故障代码。再往上层就是故障演练平台的开发了，包括应用管理、用例管理、故障配置的动态下发、故障的调试和结果管理以及场景演练。那么

噪声多，锯齿明显，效果粗糙优化后，噪声过滤明显，边缘平顺，锯齿半透明渲染半透明头发渲染最大的挑战是如何正确的进行排序，我们尝试了以下两种方式来解决该问题。通过将头发分成内外层，其中内层采用alpha

本期作者蒋宇东哔哩哔哩技术专家何涛哔哩哔哩资深算法工程师杜睿哔哩哔哩资深算法工程师陈卫东哔哩哔哩资深算法工程师陈保友哔哩哔哩资深算法工程师产品介绍随着虚拟开播在B站等平台的火爆，越来越多的用户和主播对虚拟直播产生了浓厚的兴趣。3D写实风格的虚拟人不仅视觉效果出众，还能提供沉浸式的直播体验，为用户带来全新的观看感受。如抖音推出的3D超写实虚拟主播令颜欢，出道一周粉丝就突破了60万，全网视频播放量破亿，直播间更是突破了百万人次的场观水平。3D写实风格的虚拟人有望成为未来虚拟直播领域的市场趋势。然而，在3D虚拟人领域高昂的制作成本（几十万～几百万）和漫长的制作周期成为了规模化和商业化的阻碍，复杂的流程也令普通内容创作者望而却步。虚拟人的制做流程主要分为：建模、绑定、驱动、渲染。通过建模获得虚拟人漂亮的外表，然后给3D模型绑定骨骼让他能够像人一样动起来。按不同的精度要求，制作周期通常需要3-6个月以上的时间，价格从几万到百万的级别。传统上完成一场3D虚拟开播，还需要实时高精度动捕，业界通常采用光学设备来完成，单场的开播成本需要几万元。捕捉到的数据还需要经过引擎的驱动、重定向，准确的完成目标人物的动作还原，最终采用CG实时渲染技术，完成整个场景、人物、服饰、头发等细节的渲染效果。为了降低3D虚拟数字人的制作成本，B站人工智能平台和天工工作室共同打造了一套给普通用户的3D写实风幻星数字人技术解决方案，让每个普通人都可以实现自己的虚拟偶像梦！欢迎关注技术落地案例（https://space.bilibili.com/3494365152414319），梨雅Lya在直播间等你哦～用户可以通过幻星数字人技术解决方案提供的捏脸、塑体和换装能力，花几分钟到十几分钟的时间获取到符合个性化需求的3D虚拟人形象。使用普通的单目摄像头实现对创作者面部、身体以及手势动作的捕捉，并且实时的渲染到虚拟的场景中，即使在家里也能完成一场内容精彩的虚拟直播。背景和概述随着VR/AR等技术和应用的兴起，对于动作捕捉到需求越来越多。通过3D动捕捉技术，可以极大提升效率，提高用户的沉浸感，增加现实世界和虚拟世界的流畅结合。当前，不同的虚拟直播公司和项目使用的动捕技术可能会有所不同，主流动捕技术分为三类：光学动捕技术（Optical

本期作者刘江涛哔哩哔哩资深开发工程师根据2022年第四季度的财报数据显示，B站在跨年晚会期间的直播人气峰值达到了3.3亿。直播业务对于B站来说是一个重要的增长点，而道具投喂（赠送礼物，后面统称为道具投喂，礼物统称为道具）在直播业务中扮演着重要的角色。在本文中，我们将介绍如何确保直播道具相关系统的高可用性，以实现99.99%的稳定性目标。文章将分为三个部分，分别是道具面板，道具投喂和多活。一、道具面板（进入直播间后点击右下角礼物显示）背景：道具面板负责展示直播间所有道具，为了保证用户进入直播间后体验较好（不会出现loading），设计了预加载机制：用户进入房间时就拉取道具面板数据，从而在用户点击道具面板时不需要loading。挑战：面板的第一个tab显示的道具根据不同的直播间有所不同，这里通过直播间维度的缓存，可以实现很高的并发。然而特权和定制tab会根据直播间+用户显示不同内容，没办法根据直播间维护做缓存，在进房流量大的时候就会面临以下2个问题：1：道具面板依赖了几个不同用户维度的相关接口，根据不同的用户展示不同道具，但这些接口的稳定性可能存在一定问题，出现问题时会影响到道具面板的用户体验2：当直播间面临大型赛事时，进房的用户流量会突增，可能会超过接口的tps方案：上面2个问题除了推动提升服务的性能之外，目前采取的方案主要是熔断+降级，对依赖的外部系统接口都不信任，均改造成弱依赖，具体方案如下（针对以上两个问题）：1：假设某个用户的特权道具在相关接口超过50ms内没有返回，系统会默认降级，认为返回的数据为空。如果失败率超过50%，则会自动熔断一段时间。熔断/降级发生时会导致用户看不到特权道具，刷新后又恢复正常，虽然可能会影响用户的使用体验，但是至少保证了道具面板可以用。2：当流量增加时，网关层会自动识别热点房间，降级直接从内存中获取房间的缓存数据返回给前端，以确保接口的可用性。这种方式会让所有用户看到的道具面板都是相同的，可能会影响部分用户的体验，不过保证了所有用户都能看到道具面板。经过熔断和降级之后，热点赛事/晚会期间的系统稳定性提高了很多。虽然熔断和降级方案能够以少部分用户体验来换取全部用户的高可用性，但最好的解决方案仍然是进一步提升接口的性能（粉丝勋章正在性能优化）。二、道具投喂（送道具给主播）道具面板提供了各式各样的道具和礼物，包括盲盒、宝盒、小电视飞船等重要道具，同时还支持连击等操作。为了更好地理解相关系统的结构，可以看下面简要版的系统结构图：订单、商品以及清分/结算系统是我们的营收中台，这些系统不仅服务于道具系统，也为其他营收业务（比如大航海，人气红包等）提供服务。房间信息是整个直播系统的基础，因此它的可用性要求更高。这里为了保证4个9的可用性，我们所面临的一些主要挑战有：1、数据库不稳定：比如创建订单db超时突然增多，导致大量下单失败2、流量突增可能超出订单处理能力3、订单超时，但实际上却已经完成4、消息队列出现问题1、数据库不稳定数据库的不稳定性通常可以归结为两种情况：设计不合理和硬件问题。设计不合理可能导致性能瓶颈、查询效率低下和数据冗余等问题。针对这一点，查了chatgpt：我们采用的主要方式：拆！1、分集群：一个集群出现问题（包括硬件），还有另外的集群。按uid分集群，一个集群出问题时只影响部分用户2、分库分表：订单系统采用uid取模分10歌库，然后每个库按照月的维度再分表，保证表的数据量可控3、日常监控治理：每天运维会通过发送慢sql的邮件，我们都会记录下来作为待办的事项，对于可能会对重要流程有影响的及时处理，不重要的择期处理。还有观察报警日志，对于比较慢的接口和慢sql一样根据优先级进行处理，这样通过日常治理减少出现事故的概率。如果是硬件问题，比如msyql宕机，运维有一套自己的解决方案进行主从切换，这里就不多说了（了解的也不够多

本期作者孙嘉岐哔哩哔哩资深开发工程师为什么要做DDD业务成长之痛你的业务是否存在以下问题？每个业务强依赖几个牛逼的领域工程专家维护，接受新业务或新人上手时经验无法复用，需要重新熟悉几周甚至几个月。一些迭代不频繁的业务场景自己半年前的代码也很难看懂，偶尔迭代一下要熟悉很久，需要深入到编码细节才能理解业务过程。一旦出现项目交接痛不欲生，在不足文档、没有人讲的情况下效率极低，得把之前别人的坑重新踩一遍，通过经验培养出新的领域工程专家。随着需求变多项目越来越臃肿，复杂度指数增加，事故频发，开发效率不断下降。上面的问题可以归结为，缺少系统设计过的微服务框架和业务开发模式、缺少研发规范、面向过程编程。在业务早期阶段，一个人长期负责一个项目，系统复杂度也不高。上述问题在这一阶段不重要，过度强调设计模式和规范反而会降低效率，影响业务快速启动。然而当业务逐渐趋向成熟，出现部分业务必须多人合作，同时一个人又需要负责多个业务的情形下，高效上手、交接、维护、协作成了必选项，以上问题亟待解决。复杂度增长模式业务代码的复杂度是怎么增加的呢？随着业务持续迭代，代码实现业务能力、基础组件、中间件的复用，从而降低系统长期迭代产生的复杂度复杂度增加可能出现的三种常见模式：耦合模式随着业务需求增加，代码复杂度指数提升。业务逻辑无法内聚，后面写的功能需要在之前不相关的代码模块里加些特殊逻辑。发展一段时间之后，新写一个需求没有人能搞清楚系统中哪里会出点bug，每改一点都需要对系统进行全局测试。导致无法保证稳定性、无法持续迭代，整体呈混沌状态。烟囱模式随着业务需求增加，代码复杂度线性提升。业务逻辑无法复用，每次新需求都要从头写一整套，出现大量复制粘贴的重复代码。能低效支持业务迭代，但很难做微服务以及业务范围的基础组件升级、业务模块升级。因为分布在垂直烟囱结构当中，每一个功能模块都独立评估、更新、测试、监控，代价过高。同时交接、多人协作成本巨大。迭代几年之后，业务逻辑、历史坑、特殊逻辑会积累很多。交接时前团队不可能在一次讲全，接手团队也不可能把每一块细节代码全看一遍。无法快速有效获取系统的整体认知，只能靠探地雷式重新踩坑来获得领域知识。复用模式随着业务需求增加，代码复杂度对数提升。如果希望随着业务复杂度增加代码复杂度增长低于线性，那么必须通过复用相对静态的基建来承接动态的业务需求。DDD的核心目标是解决软件开发中的业务复杂度，通过架构分层、领域拆分和建模等手段实现关注点分离，提升代码自身的表达和约束能力，从而提升整体效率。这里的具体思路是：通过战略设计来划分领域上下文，实现领域的内聚和对外解耦。微服务架构选型上基于DDD的分层架构和六边形架构来清晰定义职责边界，层级间实现可插拔。领域建模上抽象出可复用、符合业务长期迭代方向的业务模型。这样，通过相对静态的领域划分、微服务架构和业务模型来实现业务能力、基础组件、中间件的复用来承接不断动态迭代的业务需求，从而降低系统长期迭代产生的复杂度。业务架构设计业务背景在具体介绍业务应用前先来看一下业务背景。因历史原因，点播和直播的弹幕平台由不同团队独立设计开发，业务逻辑、整体架构、代码框架、中间件、公共库等方面都有较大差异。一定程度上的重复建设导致了研发、产品、运维等多个团队都存在效能浪费。基于以上契机，我们根据DDD的战略设计来整合点播、直播两侧的弹幕平台，依据职能来划分业务子领域并定义领域上下文。在微服务架构层面，通过DDD的战术设计来实现框架结构统一、多层级关注点分离、领域模型充血。最终落地建设具备统一平台能力、服务于多业务场景的弹幕平台。

这里的重复建设不仅是业务功能模块的重复建设，在开发每个后台系统时，还存在大量的基础建设的开发，比如常见的身份鉴权和操作日志，这些都是重复建设和存在重复维护的相互独立，难以技术演进a.