OLAP引擎在得物的客服、风控、供应链、投放、运营、ab实验等大量业务场景发挥重要作用，在报表、日志、实时数仓等应用场景都有广泛的应用。 得物引入和使用OLAP引擎的过程中，每个业务都基于自己的需求选择当时最适合自己的引擎。现在得物内部同时使用阿里云上的Hologres、ADB、Clickhouse与ECS自建的开源Clickhouse与StarRocks 5种引擎产品，从业务使用成本和运维维护的角度长远看都是不利的。 2024年，我们开始向只保留1到2个引擎的方向努力。最近，我们把一套4000+核的业务，最复杂的Clickhouse集群迁移到了存算分离的自建StarRocks上，成本节约40%，查询耗时降低一半，单节点不可用导致的集群不可用耗时从15分钟减少到了30s。
得物App中嵌入了大量的前端Web页面用以承接各种灵活多变的业务场景和玩法，但因为众所周知的原因，Web应用的用户体验是很难与原生应用相比的。然而，随着搭建器功能的不断完善，支持的业务场景和组件也越来越多，越来越多的团队和部门优选使用搭建器搭建会场页面投放于得物App当中，这对搭建器的整体用户体验提出了更高的要求。 从我开始接触搭建器后，看到了很多搭建器项目为了用户体验优化所做的一些努力与优秀的解决方案，这些方案在各自的应用场景当中发挥了极其重要的作用。因此，抽时间以前端开发人员的视角梳理了现有的一些优秀方案，一则作为知识沉淀留档，方便之后查阅，二则也可以给后来者一些参考与借鉴。
在软件开发中，性能测试是不可或缺的一环。但是编写基准测试来正确衡量大型应用程序的一小部分的性能却又非常困难。当基准测试单独执行组件时，JVM或底层硬件可能会对您的组件应用许多优化。当组件作为大型应用程序的一部分运行时，这些优化可能无法应用。因此，实施不当的微基准测试可能会让您相信组件的性能比实际情况更好。编写正确的Java微基准测试通常需要防止JVM和硬件在微基准测试执行期间应用的优化，而这些优化在实际生产系统中是无法应用的。这就是JMH（Java 微基准测试工具）可以帮助您实现的功能。这篇文章我会全面给大家介绍下JMH的各个方面。
一年一更的彩虹桥系列又来了，在前面两期我们分享了在稳定性和性能2个层面的一些演进&优化思路。近期我们针对彩虹桥 Proxy 负载均衡层面的架构做了一次升级，目前新架构已经部署完成，生产环境正在逐步升级中，借此机会更新一下彩虹桥架构演进之路系列的第三篇。
在Go语言中，切片是一个非常常用的数据结构，很多开发者在编写代码时都会频繁使用它。尽管切片很方便，但有一个问题常常让人感到困惑：当我们把切片作为参数传递给函数时，为什么有时候切片的内容会发生变化？这让很多人一头雾水，甚至在调试时浪费了不少时间。 这篇文章简单明了地探讨这个问题，揭示切片按值传递时发生变化的原因。我们通过一些简单的示例，帮助大家理解这一现象是如何发生的，以及如何在实际开发中避免相关的坑。希望这篇文章能让你对Go切片有更清晰的认识，少走一些弯路！
Wasm，全称 WebAssembly，官网描述是一种用于基于堆栈的虚拟机的二进制指令格式。Wasm被设计为一个可移植的目标，用于编译C/C++/Rust等高级语言，支持在Web上部署客户端和服务器应用程序。 Wasm 的开发者参考文档： https://developer.mozilla.org/en-US/docs/WebAssembly 简单的来说就是使用C/C++/Rust等语言编写的代码，经过编译后得到汇编指令，再通过JavaScript相关API将文件加载到Web容器中，一句话解释就是运行在Web容器中的汇编代码。Wasm是一种可移植、体积小、加载快速的二进制格式，可以将各种编程语言的代码编译成Wasm模块，这些模块可以在现代浏览器中直接运行。尤其在涉及到GPU或CPU计算时优势相对比较明显。
推荐系统在当今的互联网应用中扮演着至关重要的角色，它极大地丰富了用户体验，帮助用户在海量信息中发现和探索他们可能感兴趣的内容。然而，随着数据量的激增和用户需求的日益多样化，传统的离线推荐系统已经难以满足用户对于实时性和个性化推荐的需求。在这种背景下，实时推荐系统应运而生，它能够迅速响应用户的行为变化，并提供更为精准的个性化推荐。 为了实现这一目标，高效的实时推荐系统必须能够持续更新用户和物品的特征，以实时捕捉和反映它们的最新行为和兴趣变化。在这个过程中，实时特征的准确性和稳定性变得至关重要，它们直接影响到推荐系统在生产环境中的效果表现。
