1、背景

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

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

2、方案介绍

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

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，降级 。

作者：京东零售 胡飞 。

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

最后此篇关于一种通用的业务监控触发方案设计的文章就讲到这里了,如果你想了解更多关于一种通用的业务监控触发方案设计的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。