对于一个前端工程师而言，每天都在面对的较多的需求场景就是调用后端的接口，但是因为众所周知的原因，前端目前已经有无数种调用接口的方式，例如：之前有基于 XHR、Axios、Fetch 进行封装的工具，大家都试图在统一接口的调用方式，但是他们看起来最后都需要再进行改造。于是，我们试图在 B 站开发一套能够综合上述工具之长处，并结合 B 站事实需要的工具， 推出一个具有统一错误处理、减少代码冗余、抹平风格差异、降低文档负担、优化代码提示等功能的统一请求库。
前期我们详细介绍了B站在定制化数据中心（R2-AZ2）项目上的探索[1]，主要集中在智慧节能数据中心的技术迭代和实施情况。数据中心的高效运作并非孤立存在，它依赖于复杂而精细的互联互通网络，确保数据中心内的服务器、存储和网络设备间的连接。 布线系统是实现数据中心互联互通的关键组成部分， 数据中心布线的管理不当问题会造成生产环境交付周期拉长、预留线缆过长、线缆布局混乱、设备安装困难、故障排除和维护时间增加，甚至会影响机柜的气流组织，导致局部过热从而影响电子信息设备的安全运行。 此外，随着AI技术及业务应用的快速发展，智算中心正在迅速崛起，网络正向大带宽、低延时、低功耗等方向发展，这也意味着对网络和布线系统的要求正在持续提高。 布线系统作为大型数据中心的关键基础设施之一，如何利用数字化管理工具提高其交付及运维管理效率，也是我们一直在思考的问题和探索实践的方向。
2024年4月26日是第23个世界知识产权日，每年4月20日-4月26日是全国知识产权宣传周。 在这期间，哔哩哔哩公司内部发起了2024年度哔哩哔哩技术专利投票活动。最终根据票选结果决出10个优秀技术专利。 我们希望可以通过本次活动加强B站同学对于知识产权的认知和投入，同样B站也会在中国向知识产权强国迈进的征程中，勇担使命，发掘潜能，创造不凡。
随着业务的高速发展，针对HDFS元数据的访问请求量呈指数级上升。在之前的工作中，我们已经通过引入HDFS Federation和Router机制实现NameNode的平行扩容，在一定程度上满足了元数据的扩容需求；也通过引入Observer NameNode读写分离架构提升单组NameSpace的读写能力，在一定程度上减缓了读写压力。但随着业务场景的发展变化，NameSpace数量也在上升至30+组后，Active+Standby+Observer NameNode 的架构已经无法满足所有的元数据读写场景，我们必须考虑提升NameNode读写能力，来应对不断上升的元数据读写要求。 如图1-1 所展示的B站离线存储整体架构所示，随着业务的不断增量发展，通过引入HDFS Router机制实现NameNode的平行扩容，目前NameSpace的数量已经超过30+组，总存储量EB级，每日请求访问量超过200亿次。各个NameSpace之间的读写请求更是分布非常不均衡，在一些特殊场景下，部分NameSpace的整体负载更高。
B站的下行CDN旧架构如下图所示，可以看到边缘CDN节点与中心调度服务有紧密协作，简单说是先由调度服务进行流量调度(负责均衡的调度到每个网关组件节点），再由回源组件进行集群内的回源收敛，最终到对应的回源节点进行回源。随着业务体量的增加，这种模式所带来的风险也不断的被暴露出来。
账号登录系统，作为游戏发行平台最重要的应用之一，在当前的发行平台的应用架构中，主要承载的是用户的账号注册、登录、实名、防沉迷、隐私合规、风控等职责。合规作为企业经营的生命线，同时，账号登录作为在线链路转化的第一站，因此账号登录系统的稳定性，一直面临极高的要求。 出于稳定性需要，游戏发行平台在很早期就实践了两地三中心的多活架构。目前以公司公司机房为中心，同时在华东公有云和华南公有云，实现了两地三中心部署方案。依托公有云的主要考量因素在于，早期公有云提供的快速弹性和按量付费的能力，能够高效的承接游戏业务方的发展诉求；其次，对于华南地区的选择，也是优先考虑重要合作方所处的地理位置。
Matroska是一种开放标准、功能强大的多媒体封装格式，可容纳多种不同类型的视频、音频及字幕流，其常见的文件扩展名为.mkv、.mka等。与应用广泛的MP4相比，Matroska更加灵活开放，可以同时容纳多个字幕，甚至可以包含章节、标签等信息，成为了许多用户的偏爱。B站Web投稿页上传的所有视频中，封装格式为Matroska的视频占比超过2%，是除MP4以外占比最高的格式。
Flink SQL在业务使用中有较多的双流join场景，当左右流的流量都较大，Join的等待时间即使为1小时，Flink Keyed State（Flink State分Operator State和Keyed State，后文所有State均代表后者）的存储大小也很容易达到TB级（内部默认使用的是RocksDBStateBackend）。 在State我们内部[1]之前就做了RT和长度的metric，当State的存储达到TB级别后，会发现State的scan/next/readNull请求RT会变得较高，另外双流Join不仅流量大，Join query的字段也较多，导致State的Value长度也较大，从而使得任务在流量高峰期CPU存在明显的周期性毛刺，根因是RocksDB的compaction引发。我们下面的内容主要是从业务场景跟进到RocksDB的读写行为，来优化RT耗时高的问题，并使用优化方案缓解compaction的压力。
随着直播业务和用户规模日益壮大，如何丰富直播间内容、增强直播间内用户互动效果，提升营收数据变得更加关键。为此，直播互动玩法应运而生。通过弹幕、礼物、点赞、大航海等方式，用户可以参与主播的直播内容。B站还通过开放平台，为第三方厂商和开发者提供了强大的技术支持，让直播互动玩法更加便捷、稳定和高效，为用户和主播创造了更多的乐趣和价值。
