线上问题的定位与优化是程序员进阶的必经之路，常见的问题定位手段有日志排查、分布式链路追踪和性能分析等，其中日志排查主要用来定位业务逻辑问题，分布式链路主要用来定位请求链路中具体是哪个环节出了问题，而如果服务本身的性能出了问题，如一段时间复杂度高的代码引发了CPU占比飙升、内存泄漏等，则需要依赖性能分析工具来帮我们定位此类问题。
随着业务规模增长、业务逻辑演进，项目工程的依赖树(二方依赖、三方依赖)变得愈发复杂。随之而来的便是【依赖冲突】问题。 当几个软件包对相同的共享包或库有依赖性，但它们依赖于不同的、不兼容的共享包版本时，就会出现依赖性问题。如果共享包或库只能安装一个版本，用户可能需要通过获得较新或较旧版本的依赖包来解决这个问题。反过来，这可能会破坏其他的依赖关系。 【依赖冲突】问题是软件工程广泛存在的问题，换句话说，各语言生态如Python、Golang、Nodejs、Java等都存在类似问题。但是由于Java语言的特殊机制，【依赖冲突】问题在Java中似乎有完美的解决方案，那就是【类隔离容器】。 从2000年的开源规范OSGI，到阿里巴巴自研Pandora容器，再到蚂蚁金服开源sofa-ark，业界在【类隔离容器】这个领域的实践方兴未艾。那到底什么是类隔离容器？怎么实现类隔离容器？为什么它听起来很完美但是却没有成为主流实践？
得物 Redis 管理平台目前管理着几百个集群、数万个 Redis-server 节点、几千台 server 宿主机，而且通过精细化运维管理，目前 Redis-server 宿主机平均内存使用率和内存分配率均达到一个合理且较高的水位，资源管理处于业内第一梯队，使用最低的成本做到最大的支撑业务缓存需求。 同时，随着业务使用量的持续增长，单台宿主机上的内存使用率越来越高，为了保证宿主机上所有节点的业务日常增长需求或者突发的业务内存上涨，以便能够做到秒级快速垂直扩容，以及添加节点、RDB 离线分析等功能需要的资源，单台宿主机的内存使用率都需要动态的控制在一个合理水位线以下，于是，Redis 管理平台会每天定期自动巡检所有宿主机内存使用率，对于超过合理阈值的宿主机，会选择一部分 server节点进行打散，迁移到其他宿主机上。
对于水印，相信大家都不陌生。在很多内部平台、对数据信息较为敏感的中后台系统当中，我们基本上都会在系统关键数据展示区域中，加上一个半透明的文字水印（通常是用户名或用户id等能够唯一识别用户的标识），以防止使用者通过截图、拍照等方式将目标页面的数据泄露出去。即使是泄露出去之后，也可以根据水印中的用户标识能够迅速定位到“始作俑者”，并采取一些必要的手段将泄密损失降到最低。 上述场景是水印最为常用的一个场景，但不代表水印只能用于这种场景，今天我们从水印技术的前世今生，一步步展开暗水印显隐术的神秘面纱，揭秘暗水印显隐术与 OCR的邂逅，如何提升测试、生产排障效率的。
随着浏览器版本的持续更新，浏览器对JavaScript的支持越来越强大，Babel的重要性显得较低了。但Babel的设计思路、背后依赖的ECMAScript标准化思想仍然值得借鉴。 本文涉及的Babel版本主要是V7.16及以下，截至发文时，Babel最新发布的版本是V7.25.6，未出现大版本更新，近2年也进入了稳定迭代期，本文的分析思路基本适用目前的Babel设计。
本系列前面两篇文章已经分别在图片库和网络库的角度介绍了诸多白屏问题的定位和解决方案，但都是相对独立的问题，并且像OSCP，CDN节点异常之类的第三方问题无法彻底根治，因此为了长治白屏并发掘更多问题，就需要一套相对完善的白屏检测+问题归因体系。 本文将介绍从用户视角出发的白屏检测方案以及线上白屏问题的大致归因思路。
图片加载作为重中之重的App体验指标，端侧的白屏问题则是其中最为严重的问题之一。想象一下如果你在浏览交易商品、社区帖子等核心场景下，图片无法完成加载是多么糟糕的体验。 网络作为图片资源加载的最主要来源途径，如果不能够快速的响应请求，那对上层图片库而言，就是巧妇难为无米之炊了。 而且，通过线上白屏问题归因，我们看到网络问题导致比例最高，占比达81.97%。除去常见的弱网/无网等问题外，还有很多各种各样的网络环境问题我们是可以进行优化的，例如设备不支持IPv6，CDN节点异常，证书超时等。
近期，我们在大模型集群的部署过程中遇到了一些挑战。公司有多个业务场景，每个场景都基于自身的数据进行微调，训练出相应的大模型并上线。然而，这些场景的调用量并不高，同时大模型的部署成本较为昂贵，这造成了资源的浪费。 本文将介绍我们如何利用多Lora技术，将多个场景合并部署，从而有效解决这一问题。同时，我们也将探讨大模型训练与推理过程中Lora技术的应用。
