Feature flags的部分应用场景

comiscience
1,188 阅读9分钟

什么是Feature Flags

Feature flags是种软件开发技术，旨在运行时控制功能模块(Feature)的发布与回滚。通过If/else或更复杂的决策树声明，解耦Feature的部署与发布，解耦大版本发布为多个Feature独立发布，从而实现：

1. 在生产环境下测试
2. 基于Feature细粒度的渐进式发布、灰度发布
3. 无需重新部署，基于Feature的秒级版本回滚
4. 随时部署上线，准备好时再发布

价值：缓解发布压力，降低发布风险，提高交付质量，提前试错时间，加快反馈速度\

本文主要列举部分Feature Management平台的应用场景：

  • 生产环境中测试Feature，缓解发布压力
  • Feature的渐进式发布（金丝雀、灰度）
  • 系统移植 - 数据处理架构变更的移植场景
  • 系统移植 - 数据库迁移场景
  • 使用Feature flags管理客户订阅权限
  • 多版本管理与持续交付
  • 链路灰度
  • 基于主干开发

场景案例

01 生产环境中测试Feature，缓解发布压力

在一连串的复杂的、精细的、多步骤的测试后(单元测试, 整体测试，性能测试, 安全测试，Acceptance Test)，正式上线至生产环境后仍然会有可能出现BUG。更何况在很多企业、很多场景中，正式上线前的测试覆盖率并不高。所以，就很有必要提出一种在真实生产环境中测试的方案，来缓解发布的压力，在交付给最终客户时有一个更好的保障。使用Beta环境、蓝绿发布、灰度发布的多重组合是一种解决方案：1. 程序运行在一个独立环境，数据和客户都在真实的生产环境2. 根据染色流量逐步的推向给用户，至100%无问题后进行切换相对传统的Beta、灰度环境，Feature flag拥有以下特点和优势：

  1. 100%的生产环境，包括数据、用户、服务器、网络资源等。
  2. 在发布至公众前，基于Feature独立测试，大幅减少延期可能。
  3. 无需重新部署，可以秒级直接回滚Feature版本。
  4. 不因一个Feature的问题影响整体的发布节奏。

综上，大大的缓解了工程师发布压力，尤其是缓解了因快交付节奏影响的质量问题和造成的巨大心理压力。

02 Feature的渐进式发布（金丝雀、灰度）

图片通过使用If/else或更复杂的决策树的Feature flag声明包裹功能特性 (Feature) 代码后，可以通过控制Feature flag的返回值实现对一个功能特性 (Feature) 的渐进式发布（金丝雀、灰度）。

If (flags.newFeatureA == “v1.0.2”) {    
    runFeatureAV2();
}

我们可以通过后台配置发布策略，如：

  1. 将新的版本发给测试组或一个分组 
  2. 将新的版本先发给10%的粘性用户
  3. 针对出现BUG的客户和Feature，独立回滚版本

03 系统移植

我们希望的系统移植一定是平滑的、客户无感知的、不出意外的、不宕机的。那么我们可以用Feature flags解决这个问题。

一个简单的数据处理架构变更的移植场景

为了处理更大的吞吐量，我们开发了个新的数据处理系统，将一个Web APP的数据存储处理从API内部执行转为了通过Amazon Kinesis连接至Lambda服务进行数据处理与存储。

  1. 生产环境内部测试新的数据处理方式，如果有问题修改BUG重新部署。
  2. 分配20%的流量使用新的数据处理方式。若某环节出现性能瓶颈时，回退到旧版处理方式。按此方式一次分流至新版本，直至100%

图片

数据库迁移场景

我们有可能会做大的数据库变更，如从sql数据存储方式转移至nosql数据存储，从MySql移植到TiDB，或者是从一个旧结构表格移植到新结构表格等等。

使用Feature flags，我们可以在新旧两个数据库（或数据表）之间进行选择性平滑迁移。下图展示了一个数据库间移植的全过程，先将写操作平滑移植后，再做读操作的平滑移植。这个Traffic的分配，可以是按照Feature模块、客户公司等逐步的测试、逐步的开放。除了整个数据库移植外，也可以略加调整实现数据表（或数据文档库）的移植。

比如在下面的移植过程中，有一个读写性能的问题（就是同一个程序同时读写两个数据库）。而敏捷开关提供的Feature flags除了控制分流外，也会致力于相关的性能优化与框架语法使用优化。

图片

04 使用Feature flags管理客户订阅权限

在软件中，订阅权限可以对个人或组织如何使用软件提供精细的控制。例如，软件即服务(SaaS)解决方案通常提供不同的会员计划。权限定义了每个计划可以访问的功能。权限有时被称为 "付费墙"，因为功能只对付费用户开放。管理订阅权限是一个耗时的、持续变化的工作：· 当新功能发布时，你需要决定哪些客户和订阅计划可以使用它· 随着竞争格局的变化，原来只对较高层次开发的订阅计划可能会对所有人开放· 销售团队想做一个限时促销，向低层计划提供该功能，以吸引他们升级· 客户成功部门想把某些功能提供给最近受到事件影响的客户，以示善意

图片

在Feature Management平台的背景下，Feature flags可以简化管理订阅权限的过程。从而带来更好的客户体验和更高的运营效率。与其为一个要求特定功能的客户创建一个定制的构建，不如在该功能上加上一个Flag，并将其发布给该特定客户。这样可以为客户释放额外的价值，减少管理技术债务，将风险降到最低。使用敏捷开关，可以更好地管理订阅，如：

· 给不同的员工赋予Feature flag不同的管理权限，指定可授权的客户级别与订阅计划。· 通过日志记录分析客户的付费意愿，并可以定位错误的权限变更及进行快速处理。· 通过Webhook，API等方式，与系统的其他相关模块关联，实现自动化的订阅权限切换。· 为某个临时权限设置预开启时间与结束时间，减少员工的时间管理方面的工作负担。

05 多版本管理与持续交付

很多产品面临着不同的客户需要定制不同服务，如MFA的技术方式不同，网络资源部署架构不同，数据的介入与导出的结构不同等等情况。各个模块的小版本不同，导致原本一个代码库从一个主分支，会慢慢地出现多个长周期的Branch，且每个Branch都不能被删除。每次代码版本的更新可能都需要与这些分支重新的合并、测试。造成随着系统的持续增长，代码管理的难度越来越大、“老赖”长分支越来越多。

而使用敏捷开关，可以在一定程度上缓解压力。敏捷开关通过If/Else或更复杂的决策树声明，使同一特性针对不同客户的不同版本的代码，存留在同一个代码仓库与分支中。在针对不同的客户进行部署、发布时，只需要通过根据客户画像进行Feature flag配置，即可快速交付一套符合客户画像的软件产品。敏捷开关也在为此提供更好的版本管理可视化工具，辅助操作。

06 基于Feature的链路灰度

目前，如Java的Dubbo, Spring Cloud，Istio都有类似的服务，这些方法都是通过一个微服务网格服务去实现的。而敏捷开关提供的Feature Management管理平台，通过纯软件维度实现类似的效果。

如右图所示，Feature Management平台加持的链路灰度，并不是基于大版本，而是基于Feature的。与微服务的链路灰度相比，具有如下的特质：

图片

Feature flag不一定适合所有的链路灰度场景。在微服务架构的全链路灰度，Feature flag也可以起到不一样的效果。敏捷开关在这方面也提供了更加灵活的支持。

图片

07 基于主干开发

被Feature flags包裹的Feature branch直接与主干分支(main或trunk)合并。Feature branch的功能模块的发布受Feature flag控制，即使随着其他代码共同部署上线，在正式被发布前，也不会影响其他特性的正常使用。使基于主干开发的优势发挥至最大化，即短周期分支合并 (Short - lived branches)，从而实现：

  1. 减少合并代码冲突，降低Code review难度。
  2. 可立刻部署上线。做到立刻试错、反馈。
  3. 只需测试主分支，大大减少QA测试压力。

图片

总结

相信大家对Feature flags技术产生了浓厚的兴趣，毕竟这些场景都是刚需场景（嘿嘿）。所以呢，小编会在未来将这些场景的具体实现以Show Me Code的案例方式依次地发推文出来，并将随着敏捷开关的持续升级做持续的案例代码更新。敬请期待！！

如果想在小编出Code前学习相关技术，我推荐几个Feature Management平台，大家可以提前学习：

  1. 年收入上亿美元的独角兽：launchdarkly.com
  2. Gitlab集成的三方Open Core产品：www.getunleash.io/
  3. 另一个开源的Open Core产品： Flagsmith - Open Source Feature Flag & Remote Config Service
  4. 国产的专注做Feature Mangement平台的Open Core的创业产品（小编团队哒）：敏捷开关, feature-flags.co github.com/feature-fla…
  5. 在谷歌上一搜，还可以搜到很多（一个相当卷的行业）
avatar
文章
阅读
粉丝