/tags/feature-toggle/ Recent content in feature-toggle on Hugo -- gohugo.io en Tue, 07 Apr 2026 10:00:00 +0800 /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