让我真正开始思考”架构”的那次讨论

一、那场讨论的背景

2024 年年初，我们有一个商品详情页面的性能问题。

用户反馈这个页面偶发性慢，SkyWalking 上看到最慢的请求超过 3 秒，但平均响应只有 400ms 左右，分布两极化。页面涉及的数据来源有三个：基础商品信息、库存状态、营销活动。

组内开了个讨论会，把负责这几个模块的同学都拉进来，想找一个解决方案。

二、我当时的第一反应

我的第一反应很直接：加缓存。

技术路线很清晰：Redis 缓存商品详情聚合数据，TTL 设 5 分钟，命中率上来之后数据库压力下去，响应时间自然稳定。我在会上把这个方案说出来，几个人点头，觉得可行。

从纯技术角度，这个方案没毛病——Cache Aside 是标准模式，复杂度不高，我大概估了一下，两天能实现，一天测试，上线。

三、转折：约束条件比技术方案更重要

会议进行到一半，技术负责人问了几个问题，让讨论转了一个方向。

第一个问题：**”这个页面的数据，业务上能接受多少延迟？”** 我说 5 分钟 TTL 应该可以接受。他说：库存状态能接受吗？如果活动刚开始或者库存刚售罄，用户看到的是旧数据，会发生什么？

我想了一下，意识到这不是一个技术问题。库存和活动是强实时的，用户看到”有货”下单，结果扣减失败，这个体验是不能接受的。

第二个问题：**”三个来源的数据，缓存失效的逻辑怎么做？”** 商品基础信息改了、库存变了、活动过期了——三个维度各有各的更新频率，统一 TTL 缓存会导致要么更新太慢，要么缓存命中率太低，根本起不到作用。

第三个问题：**”如果库存服务压力大，加缓存是治标还是治本？”** 这个问题让我意识到我没有看数据——慢请求里，慢在哪个模块？是数据库慢，还是服务间调用慢，还是什么别的？

那 15 分钟让我把之前想好的方案推倒了重来。

我们后来查了慢请求的分布，发现问题出在营销活动服务——它每次都要跑一个复杂的活动匹配逻辑，而且是同步调用。真正的解法是：把这个匹配结果异步预计算，提前缓存，而不是把整个商品详情页缓存起来然后想办法处理失效。

四、此后看待技术问题的方式有什么不同

这次讨论之后，我开始意识到架构判断和代码实现之间有一个很不一样的思维层次。

写代码时，问题是明确的：这个功能怎么实现？做架构判断时，问题本身往往是错的：我以为是”加缓存”的问题，其实是”哪里慢、为什么慢、业务能接受的边界在哪里”的问题。

之后我遇到类似讨论，开始养成一个习惯：在提出技术方案之前，先把约束条件列出来。

比如这类问题我现在会先问：

• 业务上，数据的实时性要求是什么？
• 这个方案的维护成本，团队能承受吗？
• 如果这个方向做了三年，会把我们带到哪里？

技术方案本身是相对容易的部分，难的是确认你在解决正确的问题。