/tags/full-stack/ Recent content in full-stack on Hugo -- gohugo.io en Thu, 30 Apr 2026 10:00:00 +0800 /posts/full-stack-flag-upgrade-order/ Thu, 30 Apr 2026 10:00:00 +0800 /posts/full-stack-flag-upgrade-order/ 本文是 《Spring Boot 3.5 + Java 25 + React：在 K8s 里跑通一套跨链路 OpenFeature flag》 的续篇，聚焦三个场景中的第三个——全链路共享 flag 在升级过程中的顺序选择。 对应的 demo 代码仓库：sb3-k8s-hot-reload（私有）。 从一篇文章引发的真实问题讲起 上一篇写完后，有人在评论区提了一个非常实际的问题： “你说的全链路 flag（full-stack shared flag）确实好理解——后端在 gateway 评估，前端通过 /experience/shared-flags 拿到同样的值。但实际加一个新 flag 的时候，先改哪一边？” 这个问题戳中了全链路 flag 最微妙的地方。 假设你的团队要上线一个"会员折扣算法 v2"功能： 后端：pricing-service 要用新算法计算价格 前端：UI 要在会员用户上展示"v2 折扣体验" 目标：u-vip-* 用户看到新体验，其他用户保持原样 先升级前端还是先升级后端？ 这不是一个语义问题，这是一个部署时序问题。部署时序错了，用户就会看到不一致的行为。 三种升级路径的风险拆解 路径一：前后端同时发布（“理想情况”） 前后端同时发布在理想状态下看起来很干净，但有几个现实坑点： CI/CD 不同步：后端在 order-service/，前端在 ui/，通常走不同的 PR、不同的 review、不同的 merge。让两个独立流水线在精确的同一分钟上线几乎不可靠。 回滚不对称：如果上线后 10 分钟发现后端有 bug，你 kubectl rollout undo 回滚了后端，前端已经在跑新逻辑——此时前端看到的行为和后端完全脱节。 A/B 验证困难：你想先让 10% 用户尝鲜，但 flag 还没在 flagd 里配好（或者配了但 defaultVariant 不是目标值），新前端就已经在跑了。 所以"同时发布"更多是一种理想态，不是你可以依赖的策略。