本文篇幅有些长，但是相比阅读各类书籍，然后理解和吸收，会大大节省很多时间，对于一些书中难以理解的部分做了改进，帮助更好的理解。可能阅读本文需要一些软件方法的基础知识，才能更好理解和吸收，甚至提出反馈建议。希望文本对大家有帮助，当然这需要运用好“只字不差阅读”和“只字不差理解”。
本篇文章来源于「深响」对乐刻CTO澄识采访，主要探讨在火山引擎数据飞轮理念和工具的加持下，乐刻如何通过精细化运营、敏捷试错、个性化推荐三个关键路径，实现敏捷增长。
最近无论是在工作中的交谈，还是在日常刷屏的新闻，铺天盖地的都是大模型。我横竖是看不明白，费了大劲终于从字缝里看到了两个字，玄学。仿佛回到了我的学生时代。 还记得6年前刚进入研究生实验室时，师兄兴奋的对我说：小伙子，欢迎来到我们的修仙世界！——当时学校跟英伟达合作，刚刚从英伟达那里弄了500块Tesla显卡，供各个实验室申请使用。这，是我们崭新的炼丹炉。经过3年的研究生生涯，我对深度学习的理解，仅仅到能够使用深度学习模型的程度。期间也有一些小成绩，包括一篇CCF B类会议论文和一篇KBS期刊(影响因子8.038) ，文章内容主要是使用LSTM对用户兴趣偏好和用户兴趣迁移建模，以此来搭建一个推荐算法模型。 我们通过对各种神经网络模型的堆叠以及反复的对比实验，确实发现LSTM模型的能够在准确率、召回率等指标上有比较突出的效果。但是有一个很大的问题拦在我面前：我如何去解释它？确实，我们没法从直观定性的角度去解释，也没有数学逻辑能解释。索性我们当时就套用了大家统一的口径，解释说LSTM具有长短时记忆能力，因此能够归纳随着时间轴变化的数据规律。还好当时的审稿人并没有对我们的解释提出质疑
在上古时期，曾经的 Web 开发者们，应该会因为在一个庞大的 JavaScript 文件中寻找一个小小的函数而感到绝望？或者因为修改一个变量而不得不查找整个代码库？ 当下的前端开发中，webpack，rollup，vite 等构建打包工具大家应该都用的飞起了。它们都基于一个非常重要的概念 - 前端模块化。 在这篇文章中，我们将聊聊前端模块化的发展历程以及主流的一些方案。
商家后台前端代码目前代码量达到十万级，每个迭代团队需要在同一仓库中迭代几十个需求，在日渐庞大的巨石应用下如此活跃的迭代，开发效率与构建效率上给我们带来了一些挑战，我们需要优化以下几点： 代码构建体量大，随着时间推移，构建速度的优化空间较少。 巨石应用下各个业务模块没有做物理拆分，管理与维护难度提升。 应用粒度较粗，在发布节点上需要对应用做进一步拆分以优化发布粒度。 巨石应用下，组件与业务的关系需要梳理，避免出现重复开发的情况。 微前端是目前解决应用拆分的主要解决方案，但是由于其隔离性的机制使得各个子应用间完全隔离，使得用户在开发子应用时无法访问其他子应用页面，这对于各子应用存在关联关系需要同时访问开发的场景开发效率较低，并且目前市面上已经完全封装的主流微前端框架对我们来说是黑盒，无法做到高度自定义，无法满足特定拆分需求，因此我们决定采用模块联邦与大仓模式结合的方式解决以上问题。
自研业务存储平台-是 QQ 的富媒体（图片、视频、语音、文件等）数据传输、存储、处理等全链路解决方案的平台。致力于为用户提供稳定快速的群聊 、单聊图片上传和下载服务。为了面对突发热点也能快速响应，作者团队决定对其进行上云处理。本文着重以 QQ 聊天图片（简称：QQ 图片）为例讲述整个上云的过程及调优。 上云初阶段我们将存量使用的 TVM 统一替换为腾讯云提供的 CVM，一并将老旧云下外网服务升级到腾讯云的公网 CLB。今年我们又进一步实现容器上云目标，使用的是 TKE 平台。我们将所有核心模块作为上云目标，从而实现业务全链路上云。
在当前软件开发过程中，如何保证系统的稳定性和质量一直是一个重要的挑战。特别是对于复杂的业务系统，涉及多个流程和多个端，如何全面验证其功能和性能，并发现和解决潜在问题，成为了一个关键需求。因此，构建一个能够串联多个业务流程、覆盖多个端的全流程自动化测试平台，对于提高系统的稳定性和质量是至关重要的。本文将介绍背景、现状分析、具体实现和运营机制等方面，帮助读者全面了解和理解该平台的重要性和实现原理。
B站过去的客服系统是通过外部采购获得的，已经使用了几年。然而，这个外购的系统存在一系列问题： 稳定性低，缺乏良好的拓展性和伸缩性，经常出现bug，难以应对突发的流量高峰。 与B站产品体系无法打通，难以根据业务需求进行定制化。 由于系统逻辑老旧，稳定性不佳，导致效率低下，已经不再能满足进一步提升客服效率的要求。 虽然曾考虑过采购新的客服系统，但也面临一些问题，如： 昂贵的价格，特别是在当前降本增效的大背景下，这是一个重要因素。 更重要的是，该系统仍然无法与内部系统进行良好的整合，无法支持业务定制化。 因此，B站决定开展新客服系统的自研工作。
