一个名为”大力出奇迹“的增长活动，于2023年4月26日在哔哩哔哩app上悄然发布。活动的其中一个核心玩法是：用户可以通过玩一个小游戏，来获取活动代币（其名为”大力币“）。在这个游戏中，用户在8秒内点击一个按钮，每多点击10次，就能多获取一定数量的代币。作为活动的前端部分的主要开发人员，我将把这个游戏拆分成3个主要部分：”倒计时“、”游戏主体“、”撒金币“和”额外赠送机会“等其他动效，并对其技术方案和实现细节进行详细地介绍。
建设低代码平台的目的，就是通过可视化的方式，加上可复用的建设能力，用较少的投入、以较快的速度来交付应用程序。 我们通过aPaaS架构思路，复用已经实现了的开发能力，解构业务模型，形成更通用的能力，对业务进行快速编排。实现低代码，甚至部分无代码的快速定制应用。将开发模式从做加法，改进为做乘法，48小时内快速定制大部分基础应用。 我们不单需要解决今天的可见需求，同时还需要解决明天潜在的问题。实现更少的投入，更聪明的办法，建设更好的产品，产生更大的价值。
你会如何总结你的工作内容？ “CURD”，这是不少业务开发者对自己工作内容，做出的“哲学级别”总结，不乏调侃和乏味之意。实际上，过来人都清楚，这和业务开发面临的复杂性和挑战不在一个层次。 一般情况下，互联网核心业务可以大体分为两类，其一是基础功能性业务，其二是围绕基础功能，刺激增长类业务。以直播为例，可以分为： 核心功能类：如送礼打赏、PK连麦等互动消费业务。 增长类：通过精细化运营等方式，以刺激核心业务增长(消费)为核心目的，如营收活动。 业务开发的第一挑战在于决策与实施的割裂，决策端和实施端是完全不同的两拨人，在关注点、信息量、职业技能、工作方式等方面差异较大，在软件旺盛的迭代协作之下，保障边际生产力是个难点。 在此基础上，核心功能类业务很考验“第一个程序员”，业务迭代就像为飞行中的火箭更换零件，更难的在于下次要怎么换，目前还不一定清楚。
B站过去的客服系统是通过外部采购获得的，已经使用了几年。然而，这个外购的系统存在一系列问题： 稳定性低，缺乏良好的拓展性和伸缩性，经常出现bug，难以应对突发的流量高峰。 与B站产品体系无法打通，难以根据业务需求进行定制化。 由于系统逻辑老旧，稳定性不佳，导致效率低下，已经不再能满足进一步提升客服效率的要求。 虽然曾考虑过采购新的客服系统，但也面临一些问题，如： 昂贵的价格，特别是在当前降本增效的大背景下，这是一个重要因素。 更重要的是，该系统仍然无法与内部系统进行良好的整合，无法支持业务定制化。 因此，B站决定开展新客服系统的自研工作。
哔哩哔哩已有接近一亿的日均活跃用户，用户互动非常频繁，这也为后端系统带来巨大挑战，为了实现更好的架构扩展性，我们采用了微服务+ CQRS的架构，在这种架构下，又会带来哪些问题，我们又是如何解决的呢？本文介绍异步事件处理railgun平台，其已经帮助近800个业务应用构建高性能、高稳定性的异步系统，接下来，我们将从一个简单的业务例子开始，一步步介绍异步事件的演进与治理之路。
哔哩哔哩动态是哔哩哔哩平台上的一项社交功能，可以让用户分享自己的生活、兴趣、观点等内容，并与其他用户进行互动和交流。用户可以在动态中发布文字、图片、视频等形式的内容，也可以分享自己的观看记录、点评、收藏等。 除了普通用户，哔哩哔哩的视频创作者（也被称为UP主）也会通过动态与粉丝互动。他们可以发布新视频的预告、幕后花絮、直播间链接等内容，也可以回答粉丝的问题、分享自己的创作经验等。 此外，哔哩哔哩动态还支持一种叫做“动态视频”的功能。用户可以录制一段15秒以内的视频，发布到自己的动态中，让其他用户更直观地了解自己的状态和想法。 总的来说，哔哩哔哩动态和直播功能为用户提供了更加多元化的内容和社交体验，让用户可以更加丰富地在平台上表达自己的想法和兴趣，并与其他用户、视频创作者进行互动和交流。
随着公司业务的不断扩张，用户流量不断提升，研发体系的规模和复杂性也随之增加，线上服务的稳定性也越来越重要，因此有必要搭建一个提供安全、高效、基于生产环境的故障演练系统，为线上服务保驾护航。 关于故障演练的建设理念，业界已经有了非常多的文章，但是涉及到具体的技术实现方面与落地，很少介绍。本文将基于故障演练系统，从设计到落地整个实践过程，来详细介绍下故障演练系统是具体如何设计，以及如何落地的。 对于容器级别的故障，我司已经有了较为成熟的产品混沌实验平台，但是针对我们电商事业部（主要语言为 Java），依旧有不少痛点问题无法避免，例如在实验时想对特殊用户产生故障行为，针对自动化测试平台的请求产生故障行为，在使用 RPC 组件调用下游时可以针对具体请求产生故障行为等，基于此我们研发了基于 Java 场景的故障演练平台。
高仿真用户行为模拟可以使业务质量保障更加充分，优秀的程序设计也绝不会忽略功能在不同软硬件设备上的适配表现。所以，测试通常会引入兼容性测试、网络模拟测试、虚拟机测试等。这样不可避免的，会用到大量公共测试资源，如 机器设备（手机/主机等）、特征账号、虚拟资产......团队越庞大，资源越多，资源管理的难度就会越高，面临的异常问题也会越多。 伽利略曾提出一个“规模法则”，表达了如下观点：世间万事万物，都不能按照简单的线性关系放大。一个常见的例子就是，一颗树的长大，随着它越长越高，所关系到的体积和树干的承重力都是呈超线性关系增长的。团队里资源管理也是一样的，随着业务扩张，资源量增加，面临的问题和考验也是呈超线性关系增长的。 一些团队在规模较小的时候，使用手动管理的方式进行资源管理，但随着业务扩张，资源量达到一定程度的时候，手动进行资源管理就越发步履维艰。
