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

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

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

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

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

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

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

本期作者傅嘉伟哔哩哔哩资深开发工程师背景建设低代码平台的目的，就是通过可视化的方式，加上可复用的建设能力，用较少的投入、以较快的速度来交付应用程序。我们通过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.

本期作者李渊驰哔哩哔哩资深开发工程师背景介绍作为一个拥有庞大年轻用户群体和多元化内容资源的视频平台，B站为广告主提供了丰富的投放场景。为了实现更精准的广告投放，B站商业化技术团队深入挖掘用户、物料、场景等多方面的数据特征，并构建精细化的目标受众画像。这些数据在经过特征计算后会成为模型训练所需的训练样本，通过模型训练得到能够对广告创意进行点击率、转化率预估的深度模型。当用户进行访问时，作为广告检索引擎的一部分，在线CTR预估服务会使用深度模型，对候选集内的广告创意逐个进行点击率、转化率预估，这些数值会在精选阶段用来挑选出价值最高的广告创意返回给用户。模型预估的准确性直接决定了广告检索引擎的效果，为了确保模型训练和模型推理阶段所使用的样本数据的一致性，提供一个全面、稳定、高效的广告特征平台显得尤为重要。遇到的问题模型训练模型训练分为离线训练和实时训练两部分，在构建特征平台之前，特征处理的主要流程如下图所示。离线训练离线训练主要用于训练以天为单位的模型，通过处理前一天的日志数据得到训练样本，分为数据拼接、样本生成、模型训练三个阶段：1)

本期作者季俊宇哔哩哔哩高级开发工程师李锐哔哩哔哩资深开发工程师背景基于ClickHouse的Billions2.0日志方案上线后（B站基于Clickhouse的下一代日志体系建设实践），虽然能够降低60%的存储成本，但仍然存在几个比较明显的问题，需要进一步的优化和解决。一、存储成本的优化对于大规模的日志数据，存储成本一直是困扰企业的一个问题。我们采用了基于ClickHouse的解决方案，该方案实现了高效的数据编码和压缩率，有效降低了存储成本。然而，当前ClickHouse日志表数据依赖于双副本方案，存储成本仍有优化空间。二、提升日志排障能力日志做为可观测性(logs/metrics/tracing/event)的一环,

本期作者戴彦哔哩哔哩资深算法工程师杨典哔哩哔哩资深开发工程师一、背景AI算法复杂度逐年上升，需要高效的方式支持AI模型的推理和部署。随着应用规模的扩大，算力资源消耗也在快速增长，对线上资源产生极大的压力。B站AI涉及计算机视觉（CV）、自然语言处理（NLP）、语音等多个场景，服务于内容安全审核、内容理解和创作的上百个应用场景。二、挑战和目标挑战线上资源随着流量线性增长，在降本增效的背景下，希望控制线上资源的增长。随着大语言模型在工业界的推广和落地，NLP场景部署了BERT，GPT，T5-Large模型，模型复杂度明显提升。帧级别的视频处理。例如，在OCR(Optical

本期作者刘俊哔哩哔哩资深开发工程师前言防挡脸弹幕，即大量弹幕飘过，但不会遮挡视频画面中的人物，看起来像是从人物背后飘过去的。机器学习已经火了好几年了，但很多人都不知道浏览器中也能运行这些能力；本文介绍在视频弹幕方面的实践优化过程，文末列举了一些本方案可适用的场景，期望能开启一些脑洞。mediapipe

本期作者兔兔哔哩哔哩资深开发工程师前言直播互动玩法，早在2014年就曾有人在Twitch平台进行尝试，在这一类玩法中，直播间观众可以通过弹幕指令共同操纵主播的游戏内容，在国内被称为“弹幕互动玩法”。2021年H2，随着修勾夜店在B站的爆火，直播弹幕互动玩法如雨后春笋般出现，直播技术团队也开始了对互动开放技术体系的探索。2021年底，直播开放平台立项，旨在基于B站的内容生态和直播技术，面向行业开发者开放核心直播技术能力，打造用户、创作者和平台多方共赢的开放生态。2022年H1，围绕直播间互动玩法和游戏化互动场景，直播开放平台迅速落地，提供了直播间数据开放、API支持、SDK支持、定制化支持等技术服务，为直播互动内容生态建立了坚实的基础。本文主要介绍直播技术团队在互动开放生态演进道路上的经验与思考。什么是弹幕互动玩法2021年10月，“互动派对”在虎牙首秀，通过弹幕和礼物，其主播弹幕量和礼物收入有比较大的增长。2021年11月，被称为狗子蹦迪的“修勾夜店”在B站首秀，尝鲜的观众大量涌入这一类互动直播间，通过弹幕和礼物，创造了60万只小狗一起在线云蹦迪的故事。图1

本期作者窦晨超哔哩哔哩资深开发工程师问题的发现动态综合页比较容易因为高热事件，引起大量用户持续消费feed流，导致线上拉取动态时间线feed流接口快速飙升至平时峰值2~3倍以上而大量超时，较多用户无法正常消费其feed流。从监控上发现outbox(用户发件箱)服务依赖的redis集群大量实例CPU使用率皆超过了95%甚至达到100%(如图1)。因此，瓶颈在于outbox

本期作者李方亮哔哩哔哩资深开发工程师领域驱动设计作为一种设计思维方式从被提出到现在，社区也不断丰富了领域事件，事件溯源，CQRS等设计元模型。随着个人对领域驱动设计的理解不断深入，结合自身在项目中的实践经验，以目前bilibili

本期作者赵孔明哔哩哔哩资深开发工程师一、背景数仓建设离不开数据模型，数据分析师通过数据模型分析归纳各类数据，模型中离不开各种数据表，表代表不同维度数据，从而表/数据之间有上下游依赖关系，数据的产出是由任务计算得出，分为周期性或实时产出，所以数据之间的依赖等价于计算任务的依赖。数据平台的调度系统作用为根据任务配置，包括调度时间与依赖的上游任务，进行调度任务，即等待到达调度时间且上游任务完成，才提交运行下游任务。调度系统的核心服务业务是数据开发，数据开发的开发模型为项目（Project），项目中可以创建多个任务（Job），项目由多个任务组成，计算分析一张表或多张表的任务DAG。基于项目模型，整体链路依赖模型为项目依赖，不支持跨项目的任务依赖，依赖模型不够准确，影响数据产出链路准确性以及实效。数据开发为周期调度的离线批处理任务，而数据产出还有流任务实时产出，或者非数据平台产出。离线批任务均在数据开发，由调度系统判断依赖与提交执行，而实时任务或非数据平台的计算任务依赖需要打通，来避免任务空跑。数据本身具有时间属性，比如4点小时计算得出上一个小时3点数据，明天计算得出今天的数据，周月类似，可以看出数据产出分为小时、天、周、月。回到依赖上，3点的小时数据可以依赖上游表3点数据，1号的天数据可以依赖1号0～23点小时数据做汇总，或者1号的天数据可以依赖1号23点小时数据取最新，这么看来上下游依赖不是简单的一条边，而是在边上还有属性，来准确灵活描述具体怎么依赖上游。二、名词解释为方便大家理解，对于涉及的名词先进行解释名词英文说明任务job任务开发和执行的最小管理单元，一个任务包括可执行代码（或jar包）、执行参数、血缘配置和调度依赖依赖DAG任务之间有数据依赖，从而形成的任务依赖，多个任务依赖组成运行的上下游链路或DAG图，表示数据的生产关系自依赖--后一个周期的数据依赖前一个周期的数据项目project调度开发的一种管理方式，为一组任务的画布实例instance任务每次执行产生的一次执行记录。包括该次执行的相关信息业务时间bizDate实例属性，即数据时间，任务计算产出表的分区时间触发时间--实例属性，任务被定时执行的触发时刻T-1--触发时间与业务时间相差一个周期，以此类推T-2，即相差2个周期偏移offsetT-1，其中的"-1"为偏移量，形容业务时间和触发时间的偏差或依赖数据的偏差三、依赖模型升级1.项目依赖到任务依赖由项目依赖过度到任务依赖难题：依赖为调度核心、依赖模型改造如何过渡、内外统筹，因此引入项目起始节点（root

本期作者张忻正哔哩哔哩技术专家引言最近AIGC的爆发引发了非常多行业的恐慌也包括程序员群体。如何掌握工具例如Copilot等是下一个时代最重要的能力。但是在当前苹果封闭的生态下，对于先进的生产力的渴望也是促使这篇文章诞生的原因。Xcode是苹果的用于研发苹果软件生态的集成研发环境（IDE）相信作为苹果最强生态的iOS研发应该完全不陌生。这个让人又熟悉又陌生的老兄弟跟着iOS的辉煌也已经快20岁了，笔者差不多是从3.x年代开始使用Xcode研发iOS

号外号外！基础架构岗位热招中↓岗位一：容器云架构师岗位二：资深DBA岗位三：Flink基础架构资深研发工程师岗位四：后端开发工程师-微服务治理平台岗位五：高级/资深SRE开发工程师📩

世界知识产权日

第1部分：冷板》等四项团体标准的公告：https://www.cesa.cn/tb/detail?id=276[7]

本期作者刘璟哔哩哔哩高级算法工程师齐竟雄哔哩哔哩高级算法工程师唐哲哔哩哔哩高级算法工程师李傲哔哩哔哩资深算法工程师一、需求背景当前站内存在一定比例的UP主投稿重复、低编辑度的低创视频投稿的情况。低编辑度重复投稿表现为，相同或不同视频作者对同一视频素材进行黑边、裁剪、渣清、模板、录屏、变形、滤镜、模糊填充等不影响内容实质的编辑后进行反复投稿，如下图所示。图1：同样的画面与文字内容，套用不同模板。图2：模糊填补、视频水印、播放器录屏、黑边填补多重嵌套。图3：直播录屏+水印+黑边多重嵌套。图4：包含滑动弹幕、super

上述日志中可概述为，当cdk在做信息收集时，会向api-server请求3次，分别访问/，/apis，/api/v1/namespaces，可根据这些特征做告警规则1、userAgent:

本期作者雪人哔哩哔哩资深开发工程师背景随着弹幕数量越来越多，以及我们会不断的往视频上面添加越来越多的动画，如何让各种弹幕流畅的展示给我们的用户，成为了我们必须要考虑的问题。这要求我们需要了解浏览器底层的渲染原理，才能以最低的性能消耗来实现我们的各种弹幕效果，知道哪些性能消耗是我们前端可以避免的。目标通过此篇介绍，可以了解到：我们实现的动画，在浏览器上具体是怎么显示到屏幕上，以及可以通过减少哪些地方的消耗，来实现更加流畅的动画。正文（一）chrome多进程模型1.1

本期作者吴剑雄哔哩哔哩技术专家蔡梦苑哔哩哔哩资深开发工程师高隆哔哩哔哩资深开发工程师B站大数据历史B站大数据成立历史公司流量快速增长、数据必然爆发式增长以增加资产解决资源瓶颈已不是长期方案互联网公司发展到一定阶段，各种场景的数据需求会越来越多，业务通过数据进行快速迭代、决策，已成为各家互联网公司必备的能力。要解决猛增

卡片，checkInlinePlayCard方法内对这部分记录的卡片进行差异化处理，这个需求看起来被“完美”的解决掉了。再后来，为了验证不同面板对播放时长及卡片点击的影响，产品大大提出了要将普通的

本期作者沈涛哔哩哔哩资深开发工程师众所周知，B站是个学习的网站，网页端和粉版移动端都非常的好用，不过，相对其它平台来说B站的PC客户端也算是大器晚成了。在有些场景PC客户端的优势也是显而易见的，比如，跓留电脑桌面的快捷、独立的应用窗口、特有的交互方式等，因此就有了很多喜欢B站的技术大佬整出了不少体验不错的第三方PC应用，比如云之幻版、逍遥橙子版等。当然我站也有一个源自三方的UWP客户端，但是由于历史原因一直没有得到很好的维护，在21年底，一个需要在电脑端预装的需求让我们有了开发一个全新的PC客户端的想法。一、PC客户端的技术选型选择一个什么样的技术，可以在降本增效的大背景下实现一个体验相对较好、易维护、跨平台且能快速推进的PC应用呢？图2

SDK，针对抽样埋点，实现不发版上报量就能动态控制埋点上报抽样比例，从全量上报到远程下线采集的自助配置，在业务高峰期能降低下游传输、存储压力；对标记为核心埋点数据传输链路上单独分流至高优队列，提升

Flink项目的Committer，目前在哔哩哔哩基础架构部门负责OLAP平台的建设，在此之前曾在阿里云和英特尔从事开源大数据框架的开发工作。以上分享内容将会在2023

本期作者杨一沐哔哩哔哩资深开发工程师李代琛哔哩哔哩资深开发工程师甄玉美哔哩哔哩高级开发工程师DCjanus哔哩哔哩高级开发工程师背景图片库加载服务是为bilibili打造的移动端一站式解决方案，集图像加载、显示、处理、监控于一体，以高可用、高性能、可高度定制、数据服务、省流量五大核心优势被公司各个业务接入使用，经过长期的迭代与维护，已成熟稳定。在如今越来越看重体验的大环境下，对图片库的要求也日益攀升。从成本的角度来看，使用AVIF格式可以节省大量的网络带宽和存储空间，减少网站加载时间，并且可以改善用户体验，进而提高网站的效率和收益，从而节约大量的费用。AVIF格式能够带来许多优势，首先，AVIF格式具有明显的压缩率优势，可以比其他常用图片格式（如JPEG、PNG）节省更多的存储空间，减少图片加载所需时间和带宽，提高网站加载速度，提高访问者的体验；其次，AVIF格式丰富的特性支持，可以支持更多的设备和浏览器，提高图片的可用性，并可以免专利费的优势；最后，AVIF格式支持图片的质量优化，可以保证图片的质量，同时节省更多的容量。一、AVIF图片格式研究1、图片格式编解码研究图片格式AVIF编解码详解（期待后续公布的分享）进行AVIF图片格式的研究，AVIF格式相比其他图片格式，有着更高的压缩比，可以支持更多的色彩深度，支持alpha通道，支持更多的图片尺寸，支持动态图片，支持更多的压缩选项，可以更有效地利用计算资源，支持多层编码，支持非码率压缩，支持虚拟化和硬件加速，支持缩略图和视频帧等。2、AVIF在B站落地的调研2022

。图中对多边形进行了命名，后文中同一多边形与此图命名相同。图中为一个简单多边形被单调化后的结果，其被拆分成三个单调多边形，每个单调多边形又由多个单调山组成。算法过程中维护的其他数据有所变化：(1)

本期作者陈世云哔哩哔哩资深开发工程师1.背景随着B站业务的高速发展，业务产生的数据每天以PB级的速度持续增长，之前主要应对方法是分析数据的使用频率，把数据分为热冷俩类数据，对冷数据进行高密存储来降低存储成本，以及对部分非核心的冷数据进行数据周期管理。随着体量的增大，即使TTL机制的运行，冷数据的存储量也越来越多，这部分数据长时间未有访问，但仍然具有一定的价值，不能随意清理，且占总体数据量的30%以上，现有的高密存储机制虽然能一定程度上降低存储成本，但是为了进一步的降本增效，我们计划用技术手段进一步节省存储成本。目前社区针对降低存储容量的手段主要就是EC策略，我们为此推动了HDFS

本期作者李昌海哔哩哔哩资深开发工程师韩志华大数据平台工具负责人1.序言Berserker是B站一站式数据开发及治理平台，基于常用大数据生态组件构建，满足公司内数据查询、数据分析、日常报表、数据集成、数据开发、实时计算和数据治理等各种业务场景。在B站，我们一般将Berserker简写为BSK。图1.

cgroup级别的的直接内存回收行为，造成延迟。可见由于离线任务使用了一定量内存，让在线任务的内存分配更早触碰到了A的limit，更糟糕的是，如果内存回收没有回收到需求的内存，则会在A节点触发mem

本期作者叶翠哔哩哔哩技术专家马永智哔哩哔哩高级运维工程师01.背景当前，降本增效是各大互联网公司的重要方向，IT成本则占据了互联网公司成本的大头。如何有效的降本？如何推动各业务线配合？如何平衡成本、质量和效率？本文将介绍B站的IT成本管理和优化的思路，介绍B站通过落地FinOps，推进成本洞察、技术优化和运营优化，提升资源效率的经验。2022年，在B站DAU稳步增长的情况下，IT成本花费金额低于21年同期，为公司节省了数亿成本。项目团队也获得了公司2022年度技术突出贡献奖。02.历史IT的成本管理主要是针对预算的管理，每财年开始的时候完成整个财年的预算编制。在预算编制的过程中，将业务目标转化为成本，结合技术优化方案，定下来降本目标。业务增长目标加上降本目标得出成本目标。预算定好了，降本目标也定好了，那是不是按部就班的执行就好了？这中间暴露出来几个问题：✓

端到端方案逐渐表现出它的优势，越来越多的公司选择端到端的方案。这里我们结合B站业务场景对比这两种方案：图三图三是一个典型的DNN-HMM框架，可以看出它的pipeline

稳定性、效率、成本乃SRE三板斧，所有工作都围绕此三方面展开，企业要想构建完善的SRE体系，需要统一规划好三者的能力建设，为此，dbaplus社群携手bilibili四位运维专家，围绕“甩掉技术债包袱，B站SRE体系建设与转型实践”这一主题开展线上直播分享，针对稳定性建设、容量运营治理、SLO运营体系与报警、风险预警等内容进行深入探讨，为各行各业的运维转型与SRE体系建设提供更多新思路。观看方式：线上直播间直播日期：2023年3月4日（周六）直播时间：14:00-17:00活动议程分享嘉宾及议题吉翔bilibili资深SRE工程师《服务稳定性建设：高可用架构与多活治理》议题要点及收获：B站高可用架构，包括接入层、数据层、缓存层、消息层等组件的高可用能力和优化演进；高可用架构下业务多活改造接入的方法；多活统一管控和治理的思路。嘉宾介绍：负责在线业务SRE相关工作，深度参与业务多活建设项目。当前专注于核心业务多活建设推进、多活管控治理等工作。张鹤bilibili资深SRE工程师《B站应用降本增效与容量运营治理》议题要点及收获：容量弹性伸缩在业务稳定性提升上如何落地；降本增效的大背景下，如何平衡稳定性和降本的关系；容量运营落地时遇到哪些难点，如何赋能业务。嘉宾介绍：2020年加入B站，先后负责社区/直播/OGV/推广搜相关的SRE工作，深度参与多活、活动保障、混沌工程、容量治理相关建设，主导容量管理平台、混沌平台的架构设计和落地，负责B站S赛、跨年晚会、拜年祭等相关活动的基础架构保障工作，目前主要负责推广搜业务的稳定性建设。武安闯bilibili基础架构部SRE负责人《SLO运营体系与报警：如何从工程理论探索到最佳实践》议题要点及收获：可用性指标的观测对象、观测方案和落地实践；Google