【稳定性】秘密武器--功能开关技术 | 京东物流技术团队

京东云开发者
• 阅读 330

一、背景

继上篇【稳定性:关于缩短MTTR的探索】后,看到一些线上问题应急预案采用的是回滚方案,但是在大部分牵扯代码场景下,开关技术才是线上问题快速止血的最佳方式。比如履约平台组的Promise作为下单黄金链路,如遇线上问题的话,采用通用的回滚方式需要5-10+分钟(500+台机器)并且回滚如果操作不当会加重问题,而采用开关技术则是秒级。同时Promise在处理日常迭代需求和稳定性保障方面,功能开关技术同样发挥了重要的作用。针对改动范围大、影响面广的需求,我通常会问上线了最坏情况是什么?应急预案是什么?你带开关了吗?。当然开关也是有成本的,接下来本篇跟大家一起交流下高频发布支撑下的功能开关技术理论与实践结合的点点滴滴。

二、什么是功能开关?

功能开关其实就是一个轻量级的动态配置框架,它可以帮助您在代码中动态管理配置项(你可以理解可以动态干预代码逻辑走向)。通过使用功能开关,您可以根据需要为应用开启或关闭部分功能。这种方法通常适用于以下场景:设置黑白名单、降级业务功能、流量切量以及大促活动时的动态调整日志级别等。

从代码的角度来讲,每个开关的本质就是一个"if......else"条件语句块。


三、开关用途

对于高频率的发布上线来说,开关技术是一种合理的技术手段,被赋予了两种新的用途。

  1. 快速止血:一旦生产环境出了问题,直接找到对应功能的开关选项,将其设置为“关闭”。

  2. 隔离:即将功能代码隔离在线上执行路径之外,对用户不产生影响。

四、开关成本

使用开关技术也会带来成本。

  1. 首先,每个开关选项最少有两个状态,“开”和“闭”。当我们在发布之前对软件进行功能验证时,需要考虑每个开关在系统中的状态,有时候甚至要进行组合测试,开关的数量越多,可能就会产生越多组合测试的成本。

  2. 其次,并不是所有的开关代码都能以优雅的方式实现,给代码的编写和维护都带来了一定的复杂性,需要细心设计。

  3. 最后,开关在系统中存在的时间越长,维护它的成本就越高。比如Promise系统历史原因已经200多个开关了,没有及时清理现在不敢动。

五、开关管理

为了能够最大化利用开关带来的好处,并尽可能减少它带来的成本,应该对开关进行系统化的管理,并尽可能遵循以下原则。

  1. 在满足业务需求及稳定性的前提下,尽可能少用开关技术。开关本质上是if...else...的语句,它会带来程序的复杂性,尤其是代码设计混乱、代码模块职责不清晰时,更容易出错。

  2. 易于管理:软件团队应对开关配置进行统一管理,方便查找和查看状态。

  3. 开关策略标准化:开关策略是指开关的定义、命名以及如何配置。功能开关应该遵循统一的标准和规范,以便不同团队之间的协作和沟通更加顺畅。目前小组开关命名等也不规范,正在标准化路程中。

  4. 可扩展性:功能开关应该具有可扩展性,以便在需要时能够轻松地添加新的功能或修改现有的功能。这可以通过使用模块化的设计和开放的接口来实现。

  5. 在确保稳定性的前提下,尽量定期检查和清理不必要的开关项。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 转载请注明来源

点赞
收藏
评论区
推荐文章
Wesley13 Wesley13
2年前
FLV文件格式
1.        FLV文件对齐方式FLV文件以大端对齐方式存放多字节整型。如存放数字无符号16位的数字300(0x012C),那么在FLV文件中存放的顺序是:|0x01|0x2C|。如果是无符号32位数字300(0x0000012C),那么在FLV文件中的存放顺序是:|0x00|0x00|0x00|0x01|0x2C。2.  
Stella981 Stella981
2年前
SpringBoot整合Redis乱码原因及解决方案
问题描述:springboot使用springdataredis存储数据时乱码rediskey/value出现\\xAC\\xED\\x00\\x05t\\x00\\x05问题分析:查看RedisTemplate类!(https://oscimg.oschina.net/oscnet/0a85565fa
Wesley13 Wesley13
2年前
mysql设置时区
mysql设置时区mysql\_query("SETtime\_zone'8:00'")ordie('时区设置失败,请联系管理员!');中国在东8区所以加8方法二:selectcount(user\_id)asdevice,CONVERT\_TZ(FROM\_UNIXTIME(reg\_time),'08:00','0
Easter79 Easter79
2年前
SpringBoot整合Redis乱码原因及解决方案
问题描述:springboot使用springdataredis存储数据时乱码rediskey/value出现\\xAC\\xED\\x00\\x05t\\x00\\x05问题分析:查看RedisTemplate类!(https://oscimg.oschina.net/oscnet/0a85565fa
Stella981 Stella981
2年前
Hibernate纯sql查询结果和该sql在数据库直接查询结果不一致
问题:今天在做一个查询的时候发现一个问题,我先在数据库实现了我需要的sql,然后我在代码中代码:selectdistinctd.id,d.name,COALESCE(c.count_num,0),COALESCE(c.count_fix,0),COALESCE(c
Wesley13 Wesley13
2年前
MySQL部分从库上面因为大量的临时表tmp_table造成慢查询
背景描述Time:20190124T00:08:14.70572408:00User@Host:@Id:Schema:sentrymetaLast_errno:0Killed:0Query_time:0.315758Lock_
为什么mysql不推荐使用雪花ID作为主键
作者:毛辰飞背景在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一),而是推荐连续自增的主键id,官方的推荐是auto_increment,那么为什么不建议采用uuid,使用uuid究
【稳定性】关于缩短MTTR的探索 | 京东物流技术团队
一、什么是MTTR?当系统出现系统故障时,我们需要通过一些指标来衡量故障的严重程度和影响范围。其中MTTR(MeanTimeToRepair名为平均修复时间)是一个非常重要的指标,它可以帮助我们了解修复系统所需的平均时间。花费太长时间来修复系统是不可取的,
京东云开发者 京东云开发者
10个月前
线上SQL超时场景分析-MySQL超时之间隙锁 | 京东物流技术团队
前言之前遇到过一个由MySQL间隙锁引发线上sql执行超时的场景,记录一下。背景说明分布式事务消息表:业务上使用消息表的方式,依赖本地事务,实现了一套分布式事务方案消息表名:mqmessages数据量:3000多万索引:createtime和statuss
京东云开发者 京东云开发者
5个月前
【稳定性】浅谈团队如何做好系统稳定性
背景稳定性建设需要一系列具体的建设活动推进和落地,这些建设活动涉及人员、机制和文化,全方位的建设活动才能更好地落实建设模式。一、稳定性保障机制稳定性涉及团队所有不同水平技术人员、所有系统、研发所有环节、线上时时刻刻,单个技术人员是无法保障好的,必须建立团队