共计 2958 个字符，预计需要花费 8 分钟才能阅读完成。
一、背景
继上篇【稳定性：对于缩短 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 转载请注明起源
