一种通用的业务监控触发方案设计 | 京东云技术团队

一、背景

业务监控是指通过技术手段监控业务代码执行的最终结果或者状态是否符合预期,实现业务监控主要分成两步:一、在业务系统中选择节点发送消息触发业务监控;二、系统在接收到mq消息或者定时任务调度时,根据消息中或者任务中的业务数据查询业务执行的结果或状态并与业务预期的结果相对比。目前供销系统的方案如下:

由业务系统发送消息触发规则中心的校验任务,校验逻辑和报警规则通过规则中心的groovy脚本代码实现,该方案的缺点如下:
1.业务监控代码掺杂在正常的业务代码中,业务监控的代码侵入性高;
2.业务监控消息触发代码可复用性极低,各个应用都要维护一套代码,后期若要增加或维护某个功能时成本大;
3.增加业务监控的开发工作量,开发人员需要开发和维护与业务监控功能无关的代码,如:消息触发降级功能、性能监控、异步触发等功能;
为解决上述问题,本文提出了一种通用的业务监控触发方案。

二、方案介绍

  1. 通用mq消息体:
1public class BusinessCheckMessage { 2 /** 3 * 监控类型 4 */ 5 private String businessType; 6 /** 7 * 业务监控需要的参数 8 */ 9 private Object data; 10 /** 11 * 业务方 12 */ 13 private String businessSource; 14 /** 15 * 当前所属的topic 16 */ 17 private String topic; 18} 19

其中,
businessType用于区分业务监控的类型,如:终止合作、提单等;
data用于存储和业务相关的关键数据,如订单id、商家id等;
businessSource用于区分不同业务方的业务,如:万商的提单、供销的提单等;
topic用于隔离消息,如:业务监控任务执行快的可以用主题A、执行慢的的可以用主题B等;

2.自定义注解 + 切面
以供销系统业务监控为例,接近50%的场景是将方法体中的参数作为业务数据来触发业务监控,针对此场景,本文采用注解+切面解耦业务监控代码和正常业务代码,降低业务监控代码对正常的业务代码的侵入,其中自定义注解负责获取业务监控需要用到的方法入参中的相关数据,切面负责组装通用mq数据模型并完成消息的发送。自定义注解定义如下:

1public @interface BusinessCheckPoint { 2 /** 3 * 业务监控类型 4 */ 5 String businessType(); 6 /** 7 * 业务方 8 */ 9 String businessSource(); 10 /** 11 * 要发送的消息的topic 12 */ 13 String businessTopic(); 14 /** 15 * 方法参数的第几个参数作为消息内容,从0开始 16 */ 17 int dataIndex(); 18 /** 19 * 在执行业务流程前发送消息 20 * 默认在业务流程执行后发送消息 21 */ 22 boolean beforeOperate() default false; 23} 24

其中,
businesstype用于获取业务监控类型;
businessSource用于获取业务方;
businessTopic用于获取当前要发送的消息主体;
dataIndex用于获取方法体参数中的数据,从0开始;
beforeOperate用于获取消息发送的时间,在业务流程执行后发送消息还是业务流程执行前发消息;

3.侵入式触发业务监控
考虑到业务系统可能会在复杂场景下触发业务监控,本文也提供了通用的解决方案,具体如何使用见下一章节的实战介绍。

三、实战介绍

1.引入依赖

1<dependency> 2 <groupId>com.jd</groupId> 3 <artifactId>business.check</artifactId> 4 <version>1.0.0</version> 5</dependency> 6

2.初始化切面

1<bean id="businessCheckAspect" class="com.jd.gmall.monitor.aspect.BusinessCheckAspect"/> 2

3.Producer及线程池赋值

1<bean id="businessCheckHandler" class="com.jd.gmall.monitor.service.impl.BusinessCheckHandlerImpl"> 2 <property name="messageProducerMap"> 3 <map> 4 <entry key="gx_bussiness_check" value-ref="businessCheckProducer" /> 5 </map> 6 </property> 7 <property name="commonExecutor" ref="asyncTaskThreadPoolTaskExecutor"/> 8</bean> 9

其中,
messageProducerMap类型为Map<String, Producer>,用于指定topic对应的Producer;
commonExecutor用于指定异步发送消息时用到的线程池(建议自行创建线程池);

4.业务监控消息发送
场景一:
简单场景下可使用自定义注解来发送消息,如下所示

业务监控类型 = "100"
消息主题 = "gx_bussiness_check"
业务方 = "ws"
消息体中的业务数据data = req

场景二:
复杂场景下,可在服务中注入sdk中的消息发送服务,如下所示

场景二与场景一发送的消息内容一致。

5.业务监控降级不发送消息
sdk中的类BusinessCheckHandlerImpl中定义了控制降级的方法:

1public static void setBusinessCheckSwitch(boolean businessCheckSwitch) { 2 BusinessCheckHandlerImpl.businessCheckSwitch = businessCheckSwitch; 3} 4

此处给出了通过ducc控制降级的方法:

1@LafValue("business.check.switch") 2public void setBusinessCheckSwitch(boolean switch) { 3 BusinessCheckHandlerImpl.setBusinessCheckSwitch(b); 4} 5

switch:true,开启消息发送;false,降级

作者:京东零售 胡飞

内容来源:京东云开发者社区

点赞
收藏

评论区

加载中...

相关推荐

突破传统监测模式:业务状态监控HM的新思路

在系统架构设计中非常重要的一环是要做数据监控和数据最终一致性,这里主要讲如何去补偿?补偿的方案哪些?这就引出来数据监控系统了。有小伙伴会问了,为什么业务状态监控系统可以做补偿?别急,且看本文。

Promethus(普罗米修斯)监控

一、任务背景某某某公司是一家电商网站,由于公司的业务快速发展,公司要求对现有机器进行业务监控,责成运维部门来实施这个项目。任务要求1)部署监控服务器,实现7x24实时监控2)针对公司的业务及研发部门设计监控系统,对监控项和触发器拿出合理意见3)做好问题预警机制,对可能出现的问题要及时告警并形成严格的处理机制4)做好监控告警系统,要求可以实

IoT基础架构的演进 — 边云自定义消息传输

边缘计算不仅仅是将应用部署在边缘,并对其进行自动化的监控和运维。在许多应用场景里,边缘和云上应用需要进行特定的消息传输、数据交换等,以完成边云协同的业务处理。例如,用户需要从云端发送命令至边缘的应用来触发特定的业务,或者边缘设备需要将采集的业务信息上传至云端处理。KubeEdgev1.6版本增加了自定义边云消息传输的支持,用户可以根据场景,借助Rule

UAVStack的慢SQL数据库监控功能及其实现

!(https://oscimg.oschina.net/oscnet/4d6e0c184a1cee4f0acc5a7e689fc556ec7.png)UAVStack是一个全维监控与应用运维平台。UAV.Monitor具备监控功能,包含基础监控、应用/服务性能监控、日志监控、业务监控等。在应用监控中,UAV可以根据应用实例画像;其中应用实例

Linux应急响应(二):捕捉短连接

0x00前言​短连接(shortconnnection)是相对于长连接而言的概念,指的是在数据传送过程中,只在需要发送数据时,才去建立一个连接,数据发送完成后,则断开此连接,即每次连接只完成一项业务的发送。在系统维护中,一般很难去察觉,需要借助网络安全设备或者抓包分析,才能够去发现。0x01应急场景​

物流KA商家业务监控能力建设与实践

作者:京东物流林群一、背景在常规的运维及线上故障响应实践中,我们观察到系统监控指标(SystemLevelMetrics)的异常波动往往与业务监控指标(BusinessLevelMetrics)的异常呈现高度相关性。具体而言,当系统级监控指标出现异常时,业