发布机制-功能开关发布：百科

利用代码中的功能开关（Feature Flag/Toggle/Switch）来控制发布逻辑，一般不需要复杂的发布工具和智能 LB 配合，是一种相对比较低成本和简单的发布方式。这种方式也是支持现代 DevOps 理念，研发人员可以灵活定制和自助完成的发布方式。功能开关的原理如下图所示：

功能开关发布，图片来自附录 6.2

1. 功能开关发布需要一个配置中心或者开关中心这样的服务支持，例如携程的 Apollo 配置中心附录 6.3，或者开源的 FF4J附录 6.4，这些都支持开关发布，业界还有专门的功能开关 SaaS 服务，例如 LaunchDarkly附录 6.5。通过配置中心，运维或研发人员可以在运行期动态配置功能开关的值。当然，功能开关发布只是配置中心的一种使用场景，配置中心还能支持其它很多动态配置场景。

2. 功能开关服务一般提供客户端 SDK，方便开发人员集成。在运行期，客户端 SDK 会同步最新的开关值，技术实现有推方式 (push)，也有拉方式 (pull)，或者推拉结合方式。

3. 新功能（V2 new feature）和老功能（V1 old feature）住在同一套代码中，新功能隐藏在开关后面，如果开关没有打开，则走老代码逻辑，如果开关打开，则走新代码逻辑。技术实现上可以理解为一个简单的 if/else 逻辑。

4. 应用上线后，开关先不打开，然后运维或研发人员通过开关中心打开新功能，经过流量验证新功能没有问题，则发布完成；如果有问题，则随时可以通过开关中心切回老功能逻辑。

优势：

• 升级切换和回退速度非常快

• 相对于复杂的发布工具，实施比较简单，成本相对低廉

• 研发能够灵活定制发布逻辑，支持 DevOps 自助发布

不足：

• 切换是全量的，如果 V2 版本有问题，则对用户体验有直接影响；

• 对代码有侵入，代码逻辑会变复杂，需要定期清理老版本逻辑，维护成本变高

适用场合：

• 对用户体验有一定容忍度的场景

• 已有配置中心或开关中心服务

• 暂不具备研发复杂发布工具能力；

通过功能开关一次完成流量切换，图片来自附录 6.1