本系列前面两篇文章已经分别在图片库和网络库的角度介绍了诸多白屏问题的定位和解决方案，但都是相对独立的问题，并且像OSCP，CDN节点异常之类的第三方问题无法彻底根治，因此为了长治白屏并发掘更多问题，就需要一套相对完善的白屏检测+问题归因体系。 本文将介绍从用户视角出发的白屏检测方案以及线上白屏问题的大致归因思路。
图片加载作为重中之重的App体验指标，端侧的白屏问题则是其中最为严重的问题之一。想象一下如果你在浏览交易商品、社区帖子等核心场景下，图片无法完成加载是多么糟糕的体验。 网络作为图片资源加载的最主要来源途径，如果不能够快速的响应请求，那对上层图片库而言，就是巧妇难为无米之炊了。 而且，通过线上白屏问题归因，我们看到网络问题导致比例最高，占比达81.97%。除去常见的弱网/无网等问题外，还有很多各种各样的网络环境问题我们是可以进行优化的，例如设备不支持IPv6，CDN节点异常，证书超时等。
近期，我们在大模型集群的部署过程中遇到了一些挑战。公司有多个业务场景，每个场景都基于自身的数据进行微调，训练出相应的大模型并上线。然而，这些场景的调用量并不高，同时大模型的部署成本较为昂贵，这造成了资源的浪费。 本文将介绍我们如何利用多Lora技术，将多个场景合并部署，从而有效解决这一问题。同时，我们也将探讨大模型训练与推理过程中Lora技术的应用。
图片加载作为重中之重的App体验指标，端侧的白屏问题则是其中最为严重的问题之一。想象一下如果你在浏览交易商品、社区帖子等核心场景下，图片无法完成加载是多么糟糕的体验，线上过往也陆续有一些白屏的用户反馈。 客户端架构侧从用户白屏问题反馈出发，深入分析每一个用户的实际情况，从0到1完成了白屏体系监控建设，借助独立搭建的白屏分析平台能力，从图片库、网络库、CDN质量等3个维度进行了专项治理优化。本文重点带你了解得物图片库是如何完成白屏精细化监控的基础能力、问题定位、治理优化，实现线上用户白屏问图片库相关Issue反馈基本清零。
随着近几年得物的业务和技术的快速发展，我们不管是在面向C端场景还是B端供应链；业务版本的迭代更新，技术架构的不断升级；不管是业务稳定性还是架构稳定性，业务灰度的能力对我们来说都是一项重要的技术保障，越来越受到我们业务研发的关注。然而，传统的灰度发布服务往往过于定制化，缺乏灵活性和通用性，无法满足不断变化的业务需求，往往灰度的场景可能通过代码硬编码或者简单的配置中心配置。在这样的背景下，本文将介绍一种全新的、轻量级的灰度平台，它将为大家的业务带来全新的灰度体验。
Raft算法是一种分布式一致性算法，由Diego Ongaro和John Ousterhout在2013年提出。它主要用于分布式系统中，保证系统中的数据在多个节点间保持一致性。 Raft算法被广泛应用于众多分布式系统中，尤其是在需要强一致性保证的场景中，例如： 分布式存储系统：如ETCD、Consul等键值存储系统，它们利用Raft算法来保证数据的强一致性和高可用性。 分布式数据库：一些分布式数据库管理系统（DBMS），如CockroachDB等。 分布式锁服务：例如Google的Chubby以及微软的Azure Service Bus等。 得物的多个内部中间件也是使用Raft算法作为多分片一致性的保证。 长期以来，大部分开发者都是将Raft作为一个黑盒使用，只知道它能保证多分片的一致性，对其运行原理也停留在纸面。当面临Raft性能调优或者奇怪的Raft问题排障的时候则束手无策。 费曼说过：“What I cannot create, I do not understand。” 我们中国先贤也强调“知行合一，以致良知”。如果我们不能亲手编写一次Raft算法，对这个东西就不能算作理解。
本文详细描述了SQL限流特性的需求设计方案以及使用方式，开发、测试人员可根据本文实现功能的开发、测试，DBA可根据本文合理使用SQL限流功能。
