关于运维:功能管理Feature-management搭建实战篇

在产品疾速迭代中，要做到高效的性能公布同时还要升高上线危险，须要采纳适合的技术对性能公布进行精细化的管控。上面会讲怎么通过性能粒度进行版本迭代公布。

一、动静配置

如果你没有接触过性能治理服务，那置信你对配置核心不会生疏。从分布式系统衰亡之后，配置核心曾经是分布式系统中不可或缺的一部分。从技术上来说，性能治理或配置核心实质上都是通过配置规定动静控制应用程序行为，所带来的益处是省去了批改代码、编译、打包、部署流程。在动静配置的实际中，咱们通常会以 Key-Value 的模式将配置规定存储在某个服务中对立治理，并通过数据散发将配置传输至应用程序中，同时还有一个能够给应用程序获取配置的客户端库 (SDK)。
上面通过一个示例演示 Key-Value 配置以及如何通过代码获取配置：

// key-value config:
{"enable_feature_124": true}

// sdk code: 
sdkClient.BooleanValue("enable_feature_124") => true

对于一些简略配置需要都能够用这种 Key-Value 形式组织和获取配置，例如：

• “管制性能 #124 敞开或开启”
• “将 ‘name’ 文本框的字符大小限度为 256 个字符”
• “redis 的连贯地址是 ‘172.48.1.4:6379’”

与上述相似的应用形式曾经在性能开关、应用程序配置、疾速限流降级等畛域被广泛应用。
上述基于一对一的 Key-Value 映射配置尽管曾经足够灵便通用，但依然难以反对一些较简单的性能场景。比方咱们很难在 Key-Value 配置中体现如下场景：

• 场景 1：“只有从北京拜访的且 ’ 级别 ’ 是 VIP 的用户启用性能 #124”
• 场景 2：“只有用户 APP 版本大于 1.0.1 且在每天 18:00~20:00 时开启经营流动，否则敞开流动并显示‘流动已完结’的提示信息”

上述场景的特点是应用程序在运行时须要依据上下文信息计算出相应的值，并且当上下文（需要）发生变化时，例如调整场景一为 “只有北京 10% 的用户启用性能 #124”，在不更改代码的状况下很难做到疾速反对。这也是 FeatureProbe 作为性能治理服务与传统 Key-Value 配置核心最大的区别：

上面通过一个简略示例演示性能治理服务的配置定义以及如何用代码获取相应的值：

// feature management config:
"enable_feature_124" : {if user ("city" equals "beijing" and "level" equals "vip") : true,
  else                                                       : false
}

// sdk code:
sdkClient.BoolValue("enable_feature_124", {city: "beijing", level: "vip"}) => true
sdkClient.BoolValue("enable_feature_124", {city: "shanghai", level: "vip"}) => false

二、渐进式公布

接下来咱们通过一个示例来介绍如何应用 FeatureProbe，比方当咱们须要公布一个新性能时，为了防止新性能的代码对线上产生影响，咱们会应用性能开关 （Feature toggles） 来管制新性能的代码只能被某个城市的某些用户拜访到。代码如下所示：

user := featureprobe.NewUser(reuqest.userid)
                    .With("city", request.city)
                    .With("username": request.username)

enableFeature123 := fpClient.BoolValue("enable_feature_123", user, false)
if enableFeature123 {// new code: use the feature} else {// old code: don't use the feature}

当咱们将新性能代码部署后，对应用程序简直不会产生任何影响，因为在默认状况下，所有新性能的代码都被性能开关管制，同时是否启用新性能的开关初始默认值为 false。上面为该性能开关配置规定：
FeatuteProbe toggle rules

"enable_feature_123": {
      "defaultServe": {"select": 1   // Return "variations[1]" by default => false
      },
      "variations": [
        true,
        false
      ]
}

当咱们要对新性能代码线上验证时，这时候心愿 “城市为 北京，且用户名为 ‘test’ 或 ‘admin’ 的特定测试用户能力应用该性能”, 以便于这些用户进行性能验证。此时咱们会对性能开关配置进行批改，最终生成的规定配置如下所示（对应规定执行逻辑为左边正文）：

{
    "enable_feature_123":{ 
        "rules":[
            {"conditions":[ // if city in ["beijing"] 
                    {
                        "type":"string",
                        "subject":"city",
                        "predicate":"is one of",
                        "objects":["beijing"]
                    }, // AND
                    {"type":"string", // username in ["test", "admin"]
                        "subject":"username",
                        "predicate":"is one of",
                        "objects":["test", "admin"]
                    }
                ]
                "serve":{"select":0 // return "variations[0]"  => true
                },
            }
        ]
         "defaultServe":{ // else
            "select":1 // return "variations[1]"  => false
        }, 
    },
    "variations": [
        true,
        false
      ]
}

该配置更新后，会通过咱们的数据散发服务 （FeatureProbe Server） 将配置下发到所有须要应用的应用程序中。当应用程序每次通过 SDK 获取返回值时，它将依据 key + user 属性以及最新配置规定所定义的逻辑来计算相应的后果。

当测试用户 “test” 在“北京” 测试该新性能发现问题时，能够通过将开关返回值更新回 false 疾速敞开新性能的应用。整个过程不波及到任何代码的变更，即使将需要调整为 “只有北京 10% 的用户能拜访该性能”，也仅需在页面就能实现逻辑的变更操作，而后将新的配置规定公布应用程序中即可，通常整个过程只须要几秒钟。

当性能开关被开启后，能够通过数据监控或集成测试来察看新性能对应用程序造成影响。当验证合乎预期的状况后，可就再进一步批改规定配置来让更多的用户应用该性能，如先让某个城市所有人应用该性能，接着持续将用户扩大到多个城市，并最终扩大所有用户。在整个放量过程中，检测到任何问题，都能够立刻更新规定或敞开开关来做到疾速回滚。通过这种渐进式性能公布 （Progressive Delivery） 的形式，可能帮忙咱们实现疾速、平安地进行线上变更。

当然，渐进式性能公布只是 FeatureProbe 的应用场景之一，其它基于规定的配置的场景也都能很好地反对，如按拜访流量放量、基于工夫规定的经营流动管制、A/ B 试验及配置核心等场景。

三、疾速试用

目前 FeatureProbe 应用 Apache 2.0 License 协定曾经齐全开源。你能够从 GitHub 或 Gitee 上搜寻 FeatureProbe 获取到所有代码，为了可能让大家疾速体验残缺的性能服务，咱们提供了在线体验环境。

四、总结

本文次要介绍了如何应用 FeatureProbe 疾速更新迭代产品性能，并且通过一个理论案例介绍如何应用它进行渐进式的性能公布，以升高线上变更的危险。