基础设施更换的真实成本
Source: Dev.to
基础设施更换的真实成本
作为架构师，我已经参与了足够多的基础设施评估，能够辨认出能量离开的那一刻。那并不是有人质疑性能数据或成本模型的时候，而是有人打开代码库开始统计需要更改多少服务的时候。
基础设施可能更可靠、更易运维，或拥有更好的经济性，但如果实现它意味着要触及数十个服务中稳定的生产代码，那这些都无关紧要。对话从 “我们应该这么做吗？” 转变为 “我们能负担得起吗？”，答案通常是否定的。“这更好” 与 “我们真的能采用它” 之间的差距正是许多决策停滞或被否决的地方。
架构讨论往往遵循一种熟悉的模式。白板上布满了方框和箭头，权衡看起来合理，大家都同意最终会更好。然后有人问：我们需要触及多少代码？
这个问题并不关乎功能或基准测试，而是关乎风险。架构师在评估性能和可靠性的同时，也会评估变更的冲击范围。每一行需要迁移的应用代码、每一个需要替换的客户端库、每一种需要重新学习的行为，都会在你甚至还没跑出概念验证之前就增加成本。
对于已经在生产环境的系统，触及稳定代码会引入不确定性。它会延长审查周期，启动回归测试，并使回滚变得复杂。好点子往往在此阶段止步，因为将它们织入现有应用的成本太高。
为什么代码变更很重要
- 风险放大 – 每触及一个服务，冲击范围就会扩大。
- 审查开销 – 更大的变更需要更长的代码审查时间和更多的审查者。
- 测试负担 – 必须在众多组件上运行回归套件，增加 CI 时间。
- 回滚复杂度 – 撤销多服务的变更远比翻转一个配置标志要复杂得多。
这在热路径上的基础设施尤为相关。当缓存出现异常时，它可能会把其他系统一起拖垮。团队对这里的变更自然会保持谨慎，即使提案的基础设施方面非常有吸引力。
团队信任他们在生产环境中观察到的行为——命令的序列化方式、错误的呈现方式、负载下的重试行为。这些行为已经被真实流量、负载测试以及多年的增量修复所锤炼，实际上它们充当了 应用代码与基础设施之间的合同。
合同兼容性（RESP）
对于基于 Redis 或 Valkey 的缓存密集型系统来说，合同往往就是线协议本身——RESP（Redis Serialization Protocol）。应用并不依赖于“某个缓存”，而是依赖于这种特定的通信方式。
当你保持合同不变，只更换其背后的实现时，风险潜力会显著下降。团队无需重写缓存层或在所有服务中更换 SDK，只需：
- 将现有的 Redis/Valkey 客户端指向兼容的服务（例如 Momento）。
- 使用已有的认证方式并发送相同的命令。
基础设施发生了变化，运营模型也随之改变，而应用代码基本 不需要 变动。
通过配置变更降低风险
将更换视为一次 配置变更 而非重构，能够让团队：
- 观察真实的生产行为，而无需进行完整的重写。
- 轻松回滚——只需把端点改回原来的即可。
- 将评估风险从应用代码转移到基础设施层面，在那里更容易监控和推理。
这种方法并不能消除所有风险。RESP 兼容性有其边界和限制——并非所有 Redis 命令都受支持。然而，风险画像的转变是显著的：大部分工作变成了运维层面的关注，而不是代码库本身。
要点
- “更好”不足以说服，如果实现它需要动摇没人愿意触碰的代码。
- 能够真正被采纳的平台 在团队已有的环境中落地，尊重现有的合同和思维模型。
- RESP 兼容性正是这种理念的体现：它让团队在保持可信客户端合同的同时，换掉底层服务，以获得可扩展性、可用性以及降低运维复杂度等收益。
- 当评估看起来是可逆的，团队就会诚实地权衡利弊，而不是找理由原地不动。
在实践中，这种可逆性往往决定了有趣的技术能否真正被采纳。