一种通用的业务监控触发方案设计

一种,通用,业务,监控,触发,方案设计 · 浏览次数 : 424

小编点评

**背景业务监控方案概述** **一、业务监控步骤** 1. 业务系统发送消息到规则中心。 2. 规则中心调用业务监控代码,查询业务执行结果或状态。 3. 如果结果符合预期,返回成功响应;否则,返回失败响应。 **二、通用mq消息体** `BusinessCheckMessage` 类定义了以下属性: * `businessType`: 业务监控类型,例如“100”表示终止合作。 * `data`: 业务相关参数,例如订单id。 * `businessSource`: 业务方,例如“ws”。 * `topic`: 消息发送的topic,例如“gx_bussiness_check”。 * `dataIndex`: 方法参数的索引,从0开始。 * `beforeOperate`: 是否在执行业务流程前发送消息,默认值为false。 **三、自定义注解 + 切面** 使用自定义注解可以简化业务监控代码并进行切面解耦: * 注解定义方法参数的`dataIndex`,获取方法体中的对应数据。 * 切面负责组装通用mq数据模型并完成消息的发送。 **四、实战介绍** 1. 导入依赖库。 2. 创建切面实例并配置消息发送参数。 3. 创建线程池和消息发送器。 4. 在业务监控消息发送场景中使用自定义注解发送消息。 5. 在服务中根据需要注入sdk中的消息发送服务,并设置降级逻辑。 **五、总结** 该方案提供了通用的业务监控触发方案,可简化业务监控代码,降低代码侵入性,提高代码维护性。

正文

一、背景

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

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

二、方案介绍

  1. 通用mq消息体:
public class BusinessCheckMessage {
    /**
     * 监控类型
     */
    private String businessType;
    /**
     * 业务监控需要的参数
     */
    private Object data;
    /**
     * 业务方
     */
    private String businessSource;
    /**
     * 当前所属的topic
     */
    private String topic;
}

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

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

public @interface BusinessCheckPoint {
    /**     
     * 业务监控类型     
     */    
   String businessType();    
   /**     
    * 业务方     
    */    
   String businessSource();    
   /**     
    * 要发送的消息的topic     
    */    
   String businessTopic();    
   /**     
    * 方法参数的第几个参数作为消息内容,从0开始     
   */    
   int dataIndex();    
   /**     
    * 在执行业务流程前发送消息     
    * 默认在业务流程执行后发送消息     
    */    
   boolean beforeOperate() default false;
}

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

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

三、实战介绍

1.引入依赖

<dependency>    
    <groupId>com.jd</groupId>    
    <artifactId>business.check</artifactId>   
    <version>1.0.0</version>
</dependency>

2.初始化切面

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

3.Producer及线程池赋值

<bean id="businessCheckHandler" class="com.jd.gmall.monitor.service.impl.BusinessCheckHandlerImpl">    
    <property name="messageProducerMap">        
        <map>            
            <entry key="gx_bussiness_check" value-ref="businessCheckProducer" />        
        </map>    
    </property>    
    <property name="commonExecutor" ref="asyncTaskThreadPoolTaskExecutor"/>
</bean>

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

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

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

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

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

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

public static void setBusinessCheckSwitch(boolean businessCheckSwitch) {            
    BusinessCheckHandlerImpl.businessCheckSwitch = businessCheckSwitch;
}

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

@LafValue("business.check.switch")
public void setBusinessCheckSwitch(boolean switch) {   
  BusinessCheckHandlerImpl.setBusinessCheckSwitch(b);
}

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

作者:京东零售 胡飞

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

与一种通用的业务监控触发方案设计相似的内容:

一种通用的业务监控触发方案设计

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

数据监控预警系统,实现不同端信息推送

数据是反映产品和用户状态最真实的一种方式,通过数据指导运营决策,驱动业务增长。数据可分为2种情况:数据监控和数据分析;Wyn嵌入式商业智能软件就提供了完整的数据监控和数据分析能力,下面就为大家进行一个详细介绍。 1.什么是数据监控? 数据监控是及时有效的反馈出数据异常的一种手段,通过对数据的监控去观

京东云开发者|提高IT运维效率,深度解读京东云AIOps落地实践

基于深度学习对运维时序指标进行异常检测,快速发现线上业务问题 时间序列的异常检测是实际应用中的一个关键问题,尤其是在 IT 行业。我们没有采用传统的基于阈值的方法来实现异常检测,而是通过深度学习提出了一种无阈值方法:基于 LSTM 网络的基线(一个 LSTM 框架辅助几个优化步骤)和无监督检测(神经

一分钟学会、三分钟上手、五分钟应用,快速上手责任链框架详解 | 京东云技术团队

责任链模式是开发过程中常用的一种设计模式,在SpringMVC、Netty等许多框架中均有实现。我们日常的开发中如果要使用责任链模式,通常需要自己来实现,但自己临时实现的责任链既不通用,也很容易产生框架与业务代码耦合不清的问题,增加Code Review 的成本。

JAVA动态增强一个BaseController的已经存在的接口

使用场景 前提场景 我们多个系统同时继承了某一个通用系统,通用系统的接口是不会允许随意改变的,其他子系统都依赖于Base系统的通用接口 目标需求场景 但是有一个业务,需要给某一个公共接口增加子系统独有的业务功能;比如某个接口完成之后会往其他的业务修改状态 解决方案 通常使用做法-01 集成BaseC

基于SqlSugar的开发框架循序渐进介绍(22)-- Vue3+TypeScript的前端工作流模块中实现统一的表单编辑和表单详情查看处理

在工作流页面中,除了特定的业务表单信息外,往往也需要同时展示通用申请单的相关信息,因此在页面设计的时候需要使用一些组件化的概念来实现动态的内容展示处理,本篇随笔介绍Vue3+TypeScript+ElementPus的前端工作流模块中实现统一的表单编辑和表单详情查看处理。

面向状态机编程:复杂业务逻辑应对之道

在研发项目中,经常能遇到复杂的状态流转类的业务场景,比如游戏编程中NPC的跳跃、前进、转向等状态变化,电商领域订单的状态变化等。这类情况其实可以有一种优雅的实现方法:状态机。本文重点介绍有限状态机,并结合具体项目,通过状态机的应用将状态和业务逻辑解耦,便于简化复杂业务逻辑,降低理解成本。另外,重点讲解如何优雅的解决更广泛的复杂业务问题。

为什么有了 HTTP 还要 RPC

哈喽大家好,我是咸鱼 随着互联网技术的发展,分布式架构越来越被人们所采用。在分布式架构下,**为了实现复杂的业务逻辑,应用程序需要分布式通信实现远程调用** 而这时候就需要一种协议来支持远程过程调用,以便实现不同应用程序之间的数据交换和信息传递。其中常用的协议包括 HTTP 协议和 RPC 协议 H

低代码平台如何借助Nginx实现网关服务

摘要:本文由葡萄城技术团队于博客园原创并首发。转载请注明出处:葡萄城官网,葡萄城为开发者提供专业的开发工具、解决方案和服务,赋能开发者。 前言 在典型的系统部署架构中,应用服务器是一种软件或硬件系统,它承载着应用程序的核心逻辑。它接收客户端的请求并处理相应的业务逻辑、数据操作等任务。应用服务器通常被

一种面向业务配置基于JSF广播定时生效的工具

作者:京东物流 王北永 姚再毅 李振 1 背景 目前,ducc实现了实时近乎所有配置动态生效的场景,但是配置是否实时生效,不能直观展示每个机器上jvm内对象对应的参数是否已变更为准确的值,大部分时候需要查看日志确认是否生效。 2 技术依赖 1)Jsf:京东RPC框架,用作机器之间的通讯工具 2)re