高仿真用户行为模拟可以使业务质量保障更加充分，优秀的程序设计也绝不会忽略功能在不同软硬件设备上的适配表现。所以，测试通常会引入兼容性测试、网络模拟测试、虚拟机测试等。这样不可避免的，会用到大量公共测试资源，如 机器设备（手机/主机等）、特征账号、虚拟资产......团队越庞大，资源越多，资源管理的难度就会越高，面临的异常问题也会越多。 伽利略曾提出一个“规模法则”，表达了如下观点：世间万事万物，都不能按照简单的线性关系放大。一个常见的例子就是，一颗树的长大，随着它越长越高，所关系到的体积和树干的承重力都是呈超线性关系增长的。团队里资源管理也是一样的，随着业务扩张，资源量增加，面临的问题和考验也是呈超线性关系增长的。 一些团队在规模较小的时候，使用手动管理的方式进行资源管理，但随着业务扩张，资源量达到一定程度的时候，手动进行资源管理就越发步履维艰。
B站游戏中心是一个游戏分发平台，它提供游戏下载、游戏评测、游戏攻略和游戏活动等相关内容，用户可以在这里找到各种优秀的游戏作品，预约测试，下载资源，以及参与游戏社区的互动。
笔者前段时间的工作中，某业务因为一行闭包错误使用的代码，引起了一次“血案”。闭包是一个函数及其相关的引用环境，可以捕获和记住函数定义时的状态信息并在函数执行时使用。 看一个例子：生活中我们在快餐店点餐时都会有点餐的号码，一般从1开始计数，每次顾客点餐时编号都会增加1，当两个顾客同时点餐的时候为了避免他们可能会得到相同的编号，就可以使用到闭包。Go语言提供了对闭包的支持，上述例子可以看到它在某些场景下是有作用的，但如果不小心，还是会踩坑的哦～ 本文会从golang闭包的基础知识、常见踩坑指南等方向解析，如果你也遇到过相同的问题为之困惑，欢迎阅读本文，跟我一起重新认识闭包正确使用姿势～
随着虚拟开播在B站等平台的火爆，越来越多的用户和主播对虚拟直播产生了浓厚的兴趣。3D写实风格的虚拟人不仅视觉效果出众，还能提供沉浸式的直播体验，为用户带来全新的观看感受。如抖音推出的3D超写实虚拟主播令颜欢，出道一周粉丝就突破了60万，全网视频播放量破亿，直播间更是突破了百万人次的场观水平。3D写实风格的虚拟人有望成为未来虚拟直播领域的市场趋势。
当我们在面对一些用户反馈的运行问题时，如白屏，页面加载时间过长，页面卡顿等等，如果能够知道客户端的哪些行为导致了问题的出现，那么在定位解决问题上一定会变得事半功倍。 如客户端白屏可能是某个静态资源挂了，页面加载时间过长可能是静态资源的cdn托管服务不稳定，页面卡顿可能是长耗时的js调用导致阻塞了主线程，为了帮助开发快速收集问题出现时客户端所发生的上下文信息
Monorepo 和 Bazel 给我们带了很多优势，比如快速、正确、易扩展、易协作等。虽然 Bazel 早期版本对于 iOS 开发并不太友好，甚至让一些团队产生了放弃使用 Bazel 的想法；但 Bazel 本身极其优秀的扩展性，使得社区对其一直抱有极高的热情，开发出了许多优秀的 Rules，促使社区和 Bazel 本身一直向前进化，如今的 Bazel 已不同往日，一些早期令人诟病的问题也被一一解决。目前我们正在使用 Bazel 6.1.2 版本，且即将紧跟官方的脚步更新到 6.3.0 版本。今天我们就来聊聊我们哔哩哔哩近一年（主要是Bazel 5.0.0 版本以后）所应用的一些新特性、新 rules 以及在自建 rules 方面的探索。
根据2022年第四季度的财报数据显示，B站在跨年晚会期间的直播人气峰值达到了3.3亿。直播业务对于B站来说是一个重要的增长点，而道具投喂（赠送礼物，后面统称为道具投喂，礼物统称为道具）在直播业务中扮演着重要的角色。在本文中，我们将介绍如何确保直播道具相关系统的高可用性，以实现99.99%的稳定性目标。文章将分为三个部分，分别是道具面板，道具投喂和多活。
公司在经过多年的发展，部门架构的演进，产生了大量的管理后台，包括运营平台、技术后台等。有持续迭代的，有年久失修的，也存在大量无人认领和维护的。 从技术层面看，大量的后台都存在基础能力缺失，或者重复建设，同时技术架构也各不相同。 在我们团队维护的后台里，很容易总结出如下共性问题，“技术栈不统一、规范不统一、重复建设”
本文对B站访问最频繁的视频详情页的实现技术与fanout read持续增长带来的问题进行深入分析，提出了构建业务关联索引的方案有效降低90%以上服务负载。同时针对更多的聚合展示场景提出并实现了一套通用数据聚合网关(DAGW)的解决方案。
