Unleash 入门

最近由于需要对项目内的功能启用进行动态控制，所以了解到了 Feature Toggle，由于之前并没有想过的使用经验，所以进行了一些调研，并且最终选定使用开源方案 Unleash。本文将针对 Feature Toggle 的思想、基本原理和对于 Unleash 的基本使用方法和常见进行简单的描述。

Feature Toggle 简介

首先我们先简单介绍下 Feature Toggle，顾名思义就是表示 Feature 的开关，通常可以使用 Feature Toggle 来管理不同功能开关，并且可以根据不同的参数对开关进行动态配置。在项目中引入 Feature Toggle 可以更好的对于功能进行灰度发布和定向测试。

另外我们也可以使用 Feature Toggle 进行权限控制场景，比如我们有一些特殊功能，只想对指定的部分用户开发，而其他用户则不能访问到这些功能，那么我们可以在 Feature Toggle 中增加一个用户列表的策略，然后用户在访问时可以检查是否在这个列表中，如果存在则可以访问，否则无法访问。

对于 Feature Toggle 的使用场景，我们简单归结为以下几类：

1. A/B测试
2. 灰度功能
3. 功能开关
4. 权限控制

Feature Toggle 实现原理

其实从本质上来讲，Feature Toggle的实现原理非常简单，甚至我们在平时都会很常用到，只是我们没有这个概念罢了。

简单说就是一组配置信息。比如最简单的开关功能，可以在项目配置文件中增加一个 Boolean 类型的配置项，然后在应用中检查这个配置项，如果为 true 则认为开关打开，反之则认为开关关闭。这就是最简单的 Feature Toggle。

而对于一些相对成熟的 Feature Toggle 设施来说，还会包含更多类型的开关，比如按照用户ID进行划分，这种的本质就是在配置文件中增加一个白名单，然后检查用户是否在白名单中；再比如按照用户请求IP进行过滤，按照随机百分比进行过滤等等。

为什么要使用 Feature Toggle

那么这里有人肯定会有疑问，既然 Feature Toggle 实现原理如此简单，那么为什么我们还需要这个基础设施呢，如果我们直接用配置文件在应用内实现会怎样？

首先，使用配置文件确实在某种程度上可以达到和 Feature Toggle 相关的效果，但是在实际使用场景里面我们有很多时候是需要多个服务通过同一个开关控制的，而配置文件同时是对应到单个项目或者服务的，如果需要在服务间共享配置文件，会带来管理不便利的问题。

另外，一些简单的开关策略，我们使用配置文件实现没有难度，但是如果开关控制策略比较复杂，或者有多重开关策略叠加，这样的话就会增加我们的开发成本。所以总体上来看，如果遇到场景比较多的需求的时候，使用 Feature Toggle 设施是一个不错的选择。

除此之外，使用 Feature Toggle 可以将部署和发布两个环节进行解耦，可以灵活有效的控制发布策略，规避可能存在的风险。

Unleash 介绍

Unleash 是一个开源的 Feature Toggle 服务，Unleash 使用 Node.js 开发，使用 Postgres 进行数据存储。同时 Unleash 提供了 Java，Node.js，Go，Ruby，Python，.Net，PHP 等多种语言的 SDK。而且支持丰富的策略设置和多种常用的控制策略。

我们可以参照官方文档 进行安装。另外 Unleash 提供了一个简单的管理平台，我们可以在这个管理后台上进行 Feature Toggle 的管理和查看。

Unleash 策略

Unleash 默认支持很多开关策略，这里我们逐个了解下：

• default

表示默认的开关策略，仅由开和关两个状态，没有其他策略，通过手动控制。

• applicationHostname

参数为一个字符串数组，表示一个hostname列表，如果请求的hostname在列表内，则开关开启，否则开关关闭。

• userWithId

参数为一个字符串数组，表示一个用户ID的列表，如果请求中附带的用户ID在列表内，则开关状态为激活，否则为关闭状态。这个策略通常用于按照已登录用户进行A/B测试或者灰度测试。

• remoteAddress

参数为一个字符串数组，表示一个IP的列表，如果context中的IPAddress在列表中，则开关状态为激活，否则为关闭状态。

• gradualRolloutUserId

参数为一个百分比参数和一个groupID，groupID 用于和其他的 Feature Toggle 进行联动。

这个规则会按照 context 中传入的 userId 参数进行 hash，然后将 hash 的结果取 0 - 100，然后再按照百分比进行判断。在这样的策略下，就会有一个特点，如果百分比取值10%时候一个ID的开关状态是激活的时候，当百分比调整到20%的时候，这个ID的状态是不会变的。这样就可以保证同一个用户不会在参数发生变化的时候导致访问状态不一致。

• gradualRolloutSessionId

这个测试和上一个策略类似，只是检查的是 context 中的 sessionid 参数。原理和上一个策略是一致的。至于为什么要区分这两个策略呢？上一个策略重点是用户ID，更多的是在用户已经登录的情况下使用；而这个测试时按照sessionid，会包括未登录用户。

• gradualRolloutRandom

这个参数只有一个参数就是百分比，这个策略按照随机数生成方式进行匹配。

使用场景

功能开关

假设我们在项目中增加了一个新的功能，但我们并不想让这个功能马上开启，所以我们可以增加一个 default 策略，然后状态设置为关闭。然后当我们想要让这个功能开启时，把开关状态设置为开启就可以了。

A/B 测试

假设我们对项目中的一个功能进行了改版，但是我们并不确定用户的反馈，所以我们可以通过A/B测试来获取到用户对于新旧功能的反馈。这是我们可以增加一个 gradualRolloutUserId 策略，然后按照我们的需求进行百分比设置。这样我们就可以让不同的用户按照我们设置的比例去分别访问不同版本的功能。

灰度发布

和A/B测试比较类似，假设我们对于项目中增加了新的功能，但是我们想要现在内部进行测试，或者在有限范围内的用户进行测试。

那么我们可以增加一个 remoteAddress 策略，然后将办公网内的 IP 地址加入到策略中，我们就可以讲可以访问的范围控制在办公网范围内，而不影响其他用户。

同时我们也可以增加一个 gradualRolloutSessionId 策略，在办公网测试通过后，我们可以通过 sessionid 进行百分比灰度开放测试。直至功能全部打开。

总结

了解了 Feature Toggle 后，可以在我们的项目中进行开关控制，而 Unleash 也是目前功能相对比较完整的 Feature Toggle 服务之一，后续我们在针对实际的使用方法进行描述。