京东云开发者软件架构 一、背景
继上篇【稳定性：关于缩短MTTR的探索】后，看到一些线上问题应急预案采用的是回滚方案，但是在大部分牵扯代码场景下，开关技术才是线上问题快速止血的最佳方式。比如履约平台组的Promise作为下单黄金链路，如遇线上问题的话，采用通用的回滚方式需要5-10+分钟(500+台机器）并且回滚如果操作不当会加重问题,而采用开关技术则是秒级。同时Promise在处理日常迭代需求和稳定性保障方面，功能开关技术同样发挥了重要的作用。针对改动范围大、影响面广的需求，我通常会问上线了最坏情况是什么？应急预案是什么？你带开关了吗？。当然开关也是有成本的，接下来本篇跟大家一起交流下高频发布支撑下的功能开关技术理论与实践结合的点点滴滴。
二、什么是功能开关？
功能开关其实就是一个轻量级的动态配置框架，它可以帮助您在代码中动态管理配置项（你可以理解可以动态干预代码逻辑走向）。通过使用功能开关，您可以根据需要为应用开启或关闭部分功能。这种方法通常适用于以下场景：设置黑白名单、降级业务功能、流量切量以及大促活动时的动态调整日志级别等。
从代码的角度来讲，每个开关的本质就是一个＂if......else"条件语句块。
三、开关用途
对于高频率的发布上线来说，开关技术是一种合理的技术手段，被赋予了两种新的用途。
四、开关成本
使用开关技术也会带来成本。
五、开关管理
为了能够最大化利用开关带来的好处，并尽可能减少它带来的成本，应该对开关进行系统化的管理，并尽可能遵循以下原则。
6. 安全性：功能开关应该具有足够的安全措施，以确保只有授权的用户才能修改和配置开关状态。此外，功能开关还应该能够防止未经授权的访问和攻击。如DUCC权限管理及XBP审批管理。
总之，持续交付中使用功能开关技术的原则应该是灵活、可靠、安全、标准化、自动化、可追溯性和可扩展性的综合体现，以确保系统能够在不同的环境和需求下保持稳定和高效。
六、典型应用场景
开关可分为发布开关、运维开关、A/B实验开关、权限开关。具体应用场景如下：
capactiySwitch.enable=truekaPromiseSwitch.whiteList=010***,011***,012***jitSwitch.storeId=1-1,1-2,1-3,1-4,****log4j.logger=infocommonSwith.fence=truecommonSwith.percent=10七、开关实践
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 转载请注明来源
Tags：
![[爱了]](/js/img/d1.gif)
![[尴尬]](/js/img/d16.gif)