应用新需求回滚开关开发

每当一个新需求，新功能上线，总是伴随着担心受怕。本着无银弹的原则，新功能的开发总是会不可避免的存在隐性的影响，当这个影响再生产环境被放大后可能会产生不可预计的效果，墨菲定律又不得不让我们时刻保持警惕。

我们都知道 Java 的 class 在类加载器中加载一次，所以如果在线上出现问题需要处理时，就需要停服更新 class 来升级应用。虽然像我们之前提到的一些方法，也可以实现热加载( 类加载器与类的热替换(Hotswap) )，但生产环境里较少使用。

除了修改class文件外，我们还可以在代码里编写各种 If/else来进行开关判断，这个时候如果需要关闭功能是，停服更新的不再是class，而是配置信息。

我们在应用的页面里大概都写过类似符合某种条件展示xxx内容之类的判断，例如JSP、FreeMarker 之类的在通过一些条件标签来进行页面的渲染进行控制。

在前后端分离，API开发的时候，如何进行这些返回结果的控制呢？ 这不简单嘛， if / else 一把梭。

但有些时候，比如需要进行A/B Test， 需要根据Alpha、Beta 阶段进行用户控制，甚至是线上产生了问题，需要把新上的一个feature停掉... 等等这一系列

问题，如果硬编码到系统里，每次规则发生变更时，都需要修改代码，部署上线，不够灵活。

同时，对于A/B Test 这种想要快速实验的场景，也不够及时。

为了就对类似上述的场景， Matrin Flower 提出了一个 「Feature Toggle」的概念，对，就是那个提出DI 概念的哥们。(不要吐槽老M 的概念为啥这么多：))。

The basic idea is to have a configuration file that defines a bunch of toggles for various features you have pending. The running application then uses these toggles in order to decide whether or not to show the new feature.

这里的Toggle就是个开关，针对feature 的开关，决定在什么时候开启什么feature。

针对 feature，除了可以像上面解决线上临时问题时进行开关外，也可以进行访问权限控制，对于特定群组的用户提供某些功能，同时也可以用于实现快速的 A/B Test 的目的，来验证产品的猜想。

关于 feature toggle，各种语言有不同的实现，具体请参见这里：

http://featureflags.io/resources/

在Java中，较常用的是 Togglz。

Togglz 的使用类似这样：

if (MyFeatures.HOT_NEW_FEATURE.isActive()) {
  // 新特性写这里
}

你说这不就和我自己写if/else吗？ 当然不是啦。这个实现将用户获取，开关状态获取都进行了抽象，可以进行自己的Configuration实现，

public class MyTogglzConfiguration implements TogglzConfig {

    public Class<? extends Feature> getFeatureClass() {
        return MyFeatures.class;
    }

    public StateRepository getStateRepository() {
        return new FileBasedStateRepository(new File("/tmp/features.properties"));
    }

    public UserProvider getUserProvider() {
        return new ServletUserProvider();
    }}

然后具体的开关的状态就在stateRepository中进行了定义，可以放在内存中，文件中，数据库中等等。此时可以再搭配上 配置中心 等，来实现应用功能的动态开关，不影响你周末时光。:)