一、背景
继上篇【稳定性：关于缩短MTTR的探索】后，看到一些线上问题应急预案采用的是回滚方案，但是在大部分牵扯代码场景下，开关技术才是线上问题快速止血的最佳方式。比如履约平台组的Promise作为下单黄金链路，如遇线上问题的话，采用通用的回滚方式需要5-10+分钟(500+台机器）并且回滚如果操作不当会加重问题,而采用开关技术则是秒级。同时Promise在处理日常迭代需求和稳定性保障方面，功能开关技术同样发挥了重要的作用。针对改动范围大、影响面广的需求，我通常会问上线了最坏情况是什么？应急预案是什么？你带开关了吗？。当然开关也是有成本的，接下来本篇跟大家一起交流下高频发布支撑下的功能开关技术理论与实践结合的点点滴滴。
二、什么是功能开关？
功能开关其实就是一个轻量级的动态配置框架，它可以帮助您在代码中动态管理配置项（你可以理解可以动态干预代码逻辑走向）。通过使用功能开关，您可以根据需要为应用开启或关闭部分功能。这种方法通常适用于以下场景：设置黑白名单、降级业务功能、流量切量以及大促活动时的动态调整日志级别等。
从代码的角度来讲，每个开关的本质就是一个＂if......else"条件语句块。
三、开关用途
对于高频率的发布上线来说，开关技术是一种合理的技术手段，被赋予了两种新的用途。
快速止血：一旦生产环境出了问题，直接找到对应功能的开关选项，将其设置为“关闭”。
隔离：即将功能代码隔离在线上执行路径之外，对用户不产生影响。
四、开关成本
使用开关技术也会带来成本。
首先，每个开关选项最少有两个状态，“开”和“闭”。当我们在发布之前对软件进行功能验证时，需要考虑每个开关在系统中的状态，有时候甚至要进行组合测试，开关的数量越多，可能就会产生越多组合测试的成本。
其次，并不是所有的开关代码都能以优雅的方式实现，给代码的编写和维护都带来了一定的复杂性，需要细心设计。
最后，开关在系统中存在的时间越长，维护它的成本就越高。比如Promise系统历史原因已经200多个开关了，没有及时清理现在不敢动。
五、开关管理
为了能够最大化利用开关带来的好处，并尽可能减少它带来的成本，应该对开关进行系统化的管理，并尽可能遵循以下原则。
在满足业务需求及稳定性的前提下，尽可能少用开关技术。开关本质上是if…else…的语句，它会带来程序的复杂性，尤其是代码设计混乱、代码模块职责不清晰时，更容易出错。
易于管理：软件团队应对开关配置进行统一管理，方便查找和查看状态。
开关策略标准化：开关策略是指开关的定义、命名以及如何配置。功能开关应该遵循统一的标准和规范，以便不同团队之间的协作和沟通更加顺畅。目前小组开关命名等也不规范，正在标准化路程中。
可扩展性：功能开关应该具有可扩展性，以便在需要时能够轻松地添加新的功能或修改现有的功能。这可以通过使用模块化的设计和开放的接口来实现。
在确保稳定性的前提下，尽量定期检查和清理不必要的开关项。Promise新功能开关逐步清理中。
6. 安全性：功能开关应该具有足够的安全措施，以确保只有授权的用户才能修改和配置开关状态。此外，功能开关还应该能够防止未经授权的访问和攻击。如DUCC权限管理及XBP审批管理。
总之，持续交付中使用功能开关技术的原则应该是灵活、可靠、安全、标准化、自动化、可追溯性和可扩展性的综合体现，以确保系统能够在不同的环境和需求下保持稳定和高效。
六、典型应用场景
开关可分为发布开关、运维开关、A/B实验开关、权限开关。具体应用场景如下：
功能发布更加灵活：这些开关允许该代码功能提前部署到生产环境中，但功能不生效。比如Promise系统在下单黄金链路属于下游，很多需求需要系统先上线，待上游都上线完成后再打开开关进行业务验证。如下图DUCC配置：
capactiySwitch.enable=true黑白名单功能：黑白名单是常用的访问控制规则，通过功能开关可以快速实现黑白名单功能。比如Promise中的KA时效白名单开关。如下图DUCC配置：
kaPromiseSwitch.whiteList=010***,011***,012***线上验证：系统上线后，业务需要在生产环境中测试验证，由于生产环境中测试验证存在一定的风险，功能开关可以配置相关的验证参数组合（比如下单前根据用户pin、下单后订单号、仓库ID等），这样可以在生产环境中不影响其他用户体验的情况下去测试功能，可以更早地发现问题。如下图DUCC配置：
jitSwitch.storeId=1-1,1-2,1-3,1-4,****运行时动态调整日志级别：在应用运行时动态修改日志级别的功能。比如Promise在618&双11大促峰值期间对日志进行降级（只打印出入参及下游依赖的出入参），TP99从30ms降低到13ms，待大促峰值过后日志调整回来，方便排查。如下图DUCC配置：
log4j.logger=info降级业务功能：例如在大促到来的时候，可以通过开关将非核心的业务逻辑降级，减少一些非必要的资源消耗。或者依赖下游JSF问题，如业务有损可接受，也可进行开关降级，通过开关关闭则不调用下游JSF。如下图DUCC配置：
commonSwith.fence=true切量验证：重构新功能上线后，根据订单号或者pin百分比逐步切量进行线上验证。如下图DUCC配置：
commonSwith.percent=10控制客户端行为能力：对于APP来说，这种控制可能意味着客户端周期性地和服务器联系，例如多久同步一次和重试的频率、心跳时间等
七、开关实践
7.1、复用型开关
比如很多场景发送MQ，目前可通过复用开关来配置发送MQ是异步还是同步方式。而不是每个topic配置一个开关，把相同的场景统一设置为一个通用的开关。但需要注意通用开关的隔离性差，如果不进行配置校验验证则可能影响其他开关功能。
jmqUtil.asyncTopics=topic1,topic2,topic3,topic4,....比如依赖下游JSF三方接口较多，设计一个复用型开关判断是否需要降级下游
7.2、特定时间生效开关
开关特性:开关可配置多个属性值，根据指定时间生效对应value
使用场景：比如仓库产能审批，之前业务是要求0点开关要生效对应版本，研发需要0点的时候配置，长期这样配置，研发效率低下，并且还需要按时按点对ducc开关进行修改。故设计为一个开关可提前配置好生效时间和生效的value值。比如下面是产能审批的ducc开关，effectiveTime代表生效日期，version代表对应生效版本。
[
{
"effectiveTime": "2023-03-09 12:00",
"version": "76"
},
{
"effectiveTime": "2023-04-20 12:00",
"version": "77"
},
{
"effectiveTime": "2023-05-14 00:00",
"version": "78"
}
]
八、总结
总的来说，功能开关可以帮助技术团队更有效地工作，同时还可以改善用户体验，降低发布新功能的风险。
参考：
持续交付2.0业务引领的DevOps精要
作者：京东物流 冯志文
来源：京东云开发者社区 自猿其说Tech 转载请注明来源
