/tags/openfeature/ Recent content in openfeature 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 不是目标值），新前端就已经在跑了。 所以"同时发布"更多是一种理想态，不是你可以依赖的策略。 /posts/spring-boot-openfeature-flagd-cross-stack/ Sun, 26 Apr 2026 15:00:00 +0800 /posts/spring-boot-openfeature-flagd-cross-stack/ 本文对应的 demo 项目：sb3-k8s-hot-reload（私有）。代码组织在 gateway/ order-service/ pricing-service/ ui/ k8s/ scripts/ 下，一条 ./scripts/e2e-demo.sh 从 kind 集群创建到端到端验证全跑完。 起点：一个朴素的约束 接到的题目是这样的： 在 Spring Boot 3.5 + Java 25 + Kubernetes（kind 本地）里，不用 Spring Cloud Config Server，不用 Netflix 套件（Eureka / Zuul / Ribbon / Hystrix）的前提下，验证一下"运行时配置变更不重启服务"这件事到底有哪些解、各自取舍是什么。后续要能支持 feature flag。 约束被排除的两块是有理由的：Config Server 在 K8s 原生场景里往往不再是首选（ConfigMap/Secret 已经在那里），Netflix 套件在 Spring Cloud 2023 起官方也已停止维护。但 Spring Cloud 不等于 Spring Cloud Config——spring-cloud-context、spring-cloud-kubernetes 这些仍然在维护，并且在 K8s 场景里依然是常见选择。 把约束精确化之后，问题就清晰了：在允许 spring-cloud-context 的前提下，K8s 上把"配置热加载"和"feature flag"分别做对，应该选什么。 热加载方案的选型矩阵 我把 2026 年还能找到、也比较贴近这个题目的可选项先压成一张表： /posts/spring-cloud-gateway-canary-release/ Tue, 14 Apr 2026 10:00:00 +0800 /posts/spring-cloud-gateway-canary-release/ 本文基于的项目：https://github.com/meirongdev/shop（私有）。相关实现主要在 services/api-gateway。 从一个具体问题开始 buyer-bff 要升级一版，改动涉及订单接口的返回结构。上线前我们想让两三个内部测试账号先跑一段时间，其他人继续走旧版。出问题时能立刻回切，整个过程不要重启任何服务。 前提：环境里没有 Istio、没有 Linkerd，也没有 Argo Rollouts。Kubernetes 只有原生的 Service 和 Ingress。 在这种约束下，灰度发布能放在哪一层？ Kubernetes Service 权重：原生 Service 不支持按权重或按用户分流，它只是 round-robin。 应用内开关：让每个服务各自根据用户属性判断走新旧逻辑。问题是"谁是灰度用户"的判断会散落到每个服务里重复实现，也没法在入口做统一观测。代码层面的 feature flag 不是不能用，它和 Gateway 路由解的是不同层次的问题——本文末尾会讨论两者如何互补。 Service Mesh：能干净地做这件事，但引入一整套 sidecar/control plane，对这个项目太重。 API Gateway：请求进入系统的第一跳，比较自然地成为流量决策点。只要 Gateway 能按请求属性选择 upstream，就够了。 这个项目选了第四条。下面把每一个设计选择拆开讲。 Spring Cloud Gateway 在这里担任什么角色 Shop Platform 的 api-gateway 是 Spring Cloud Gateway Server MVC（不是 WebFlux 那套），运行在虚拟线程上。它在系统里承担的事情是常规的那几件： 路径路由（/api/buyer/** → buyer-bff，/auth/** → auth-server……） 鉴权（解析 JWT、注入 X-Buyer-Id 等可信 Header） 限流（基于 Redis 的令牌桶） CORS、OpenAPI 聚合 按用户做灰度路由 ← 本文主题 灰度在这里不是外挂的新组件，而是复用 Gateway 的路由匹配能力加一个自定义谓词。 /posts/spring-boot-feature-toggle-openfeature/ Tue, 07 Apr 2026 10:00:00 +0800 /posts/spring-boot-feature-toggle-openfeature/ 在生产环境中推过新功能的人，几乎都遇到过同一个问题：“这个功能怎么在不开完整服务的前提下，先让一小部分人用起来？” Feature Toggle（特性开关）是回答这个问题的一种常见思路。但在 Spring Boot 微服务体系里，怎么实现一套不绑定具体供应商、能随代码一起版本管理、还能在生产环境动态切换的特性开关，仍然是很多团队需要摸索的事情。 本文结合 shop 项目中的 shop-starter-feature-toggle 模块，完整讲一遍从实现到部署的 Feature Toggle 落地路径。 为什么不用 LaunchDarkly / Unleash 直接上手 在开始之前，先明确一个关键问题：为什么不用现成的 SaaS Feature Flag 平台？ LaunchDarkly、Unleash、Split 等确实是成熟的产品，但在实际落地时往往面临几个门槛： 引入外部依赖：需要在生产环境部署或购买 SaaS，增加运维和成本复杂度 供应商锁定：一旦业务代码深度耦合某个平台的 SDK，切换供应商的成本很高 对于 POC 和中小项目来说过度工程化：很多团队只需要"开/关"级别的开关，不需要复杂的受众定位、A/B 测试等功能 OpenFeature 提供了第三条路。 OpenFeature：供应商无关的特性开关标准 OpenFeature 定义了一套供应商无关的特性 flag API。它的架构很简单： flowchart LR App["Spring Boot 应用"] SDK["OpenFeature SDK(供应商无关 API)"] Provider["Property Provider(从 Spring Config 读取)"] Config["K8s ConfigMap或 YAML 文件"] App --> SDK SDK --> Provider Provider --> Config 核心原则： 业务代码只依赖 OpenFeature SDK，不依赖任何具体 Provider Provider 可替换：当前用 Spring Property Provider，未来可以换成 Unleash、LaunchDarkly、flagd 等，业务代码改动通常可以控制在较小范围 标准化评估结果：ProviderEvaluation 统一返回 value、variant、reason、errorCode，便于监控和调试 参考：OpenFeature 规范、OpenFeature Concepts、OpenFeature Java SDK