cimastone's blog

这两天回了趟南昌，主要做了两件事情，

• 和大学的老同学和老师在一起吃了个饭
• 参加好朋友的小孩周岁宴

这次南昌之旅对我影响挺大，夸张点说，冲击了我的三观；此时此刻正听着《The sound of silence》舒缓的旋律，记录着这次行程的心得；

自己已经到了而立之年，但无论以心智、成就和人生阶段来说，早已被同龄人甩的远远的了；车子、房子、票子、老婆、孩子到现在这个阶段，几乎是什么都没有；本来一个人躲在杭州的角落里已经被这种失败给麻痹了；但当同龄人在一起叙旧的时候；这种失败感迅速的笼罩着自身，难以言明；当然，我并不想以名利场来定义现在状态，却让我加深了之前长辈常讲的

什么阶段应该做什么事儿

对于这句话，更多了份赞同

能见到这么多老同学，还是非常开心的；很多同学现在都是刚有小孩脱不开身的时候；在百忙中抽出空来大家聚一聚，这份同学之情，大家都还是很珍惜的；看见他们，格外的透着份亲切:laughing: :laughing: :laughing:

第二天就去参加老朋友小孩的周岁宴了；朋友是医药行业的，其实按真实感受来说，这次吃饭并没有给我带来太多的欢快；他宴请的多半是在医药行业的朋友，和我跨着行业，还有这些人也都是生面孔；所以对我来说是挺无聊的；吃完饭后又到他新买的房子去看看了；然后他们就在聊着房子、车子、票子、老婆、小孩；这些话题基本都让我闭上了嘴，我假借有几分醉意，闷声不吭；

不过正是这顿饭，才真正的让我三观受着强大的冲击；从我朋友的状态我能感受的到，他是真的在这座城市扎下了根，正是有了老婆之后，选择了买房，整个人都是稳定的状态；紧接着和周边的同事、朋友形成着盘根错节的关系网；在他们的聊天中我能感受到他们的这份从容和自信；再一回头想下头天一起吃饭的同学们；其实他们也是如此；他们过的才是生活，踏踏实实，稳步向前的生活；

自视我现在的状态，实在是大相径庭；我这哪是生活啊，我犹如四处逃窜者，一直处于打一枪换一炮的状态；永远不会形成比较稳定的、相对社会上的这种人际关系；公司就是同事的关系，到家后就是自己一个人苦闷的世界；

所以，这是很明确且强意识的东西在警示着我，审视当下，尽快的改变现有的状态；加强自身的能力，解决紧迫性的问题；于我而言，这是紧要的！

这次南昌之旅，对我来说是有收获的，还有一点做的也是还不错的，没有把大学同学聚会搞成名利场；一直在谨防着给大家这样的感觉；永远保持着纯真的同学情！

风控系统（risk-admittance）介绍

系统流程

系统中含有许多流程，如公司牌流程、续租流程、个人牌流程、前置三期流程等,根据进件入参RiskAdmittanceQueryParams中的 riskScene 值进行判断该进件走哪个场景

   ...
   "riskScene":[
       {
           "riskFlowScene":"PRE_RISK"
       }
   ],
   ...

当时该值设计为list数据结构，riskFlowScene值为RiskFlowSceneEnum.name值

前置流程和前置三期区别：

• 进件入参，前置流程只有一个金融产品id，前置三期有多个金融产品id
• 匹配40000后，前置流程直接将消息发出，前置三期会继续走x策略、银行推荐策略等
• 高首付逻辑处理只针对前置三期流程
• 发送mq消息的tag，前置：pre_risk_for_tgc, 前置三期：pre_risk_v3_for_tgc

每个流程由不同的功能处理器拼接而成，以实现该流程的需求，接下来介绍每个流程的工作流

流程类型

guaranteeFlow(担保流程)：

personFlow（个人牌流程）：

companyFlow（公司牌流程）：

releFlow（续租流程）：

merchFlow（中小企业流程）：

preflow（前置流程）：

虚线代表异步处理
额度不足 -> 满足可提额的先决条件, 流程图中指定为A
基础风控策略拒绝|电审拒绝|首付比例无匹配 -> 只满足进担保的先决条件, 流程图中指定为B

preflow V3（前置三期流程）：

• 虚线代表异步处理
• 额度不足 -> 满足可提额的先决条件, 流程图中指定为A
• 基础风控策略拒绝|电审拒绝|首付比例无匹配 -> 只满足进担保的先决条件, 流程图中指定为B
• 指在与金融方案匹配完的结果为40000的首付比例不含有小于35，且基础首付比例大于35 -> 满足可提额的先决条件, 流程图中指定为C
• 指在与金融方案匹配完的结果为40000的首付比例不含有小于35，且基础首付比例含有小于35 -> 只满足进担保的先决条件, 流程图中指定为D
• 指在与金融方案匹配完的结果为40000的首付比例含有小于35，统称为低首付通过 -> 低首付比例通过
• 额度缓存/基础风控策略/电审的匹配结果 -> 第一次匹配
• 进件中有高首付标记 -> 可高首付，反之为不可高首付

功能处理器介绍

风控系统（risk-admittance）业务框架

流程介绍

根据系统流程介绍可知，系统核心是由多条流程组成，下图为流程类的类图

Flow

• main: 从starthandler开始执行整个流程
• access(access, type, reqParam): 从mq接入流程内
  • access：接入节点对象
  • type：是pass|cancel|reject
  • reqParam：进件大对象
• access(beanName, reqParam): 从测试接口接入流程内，只测某个或某些处理器
  • access：开始节点beanName
  • reqParam：进件大对象

BaseFlow

• start: 开始处理器
• terminate: 结束处理器
• pipeLine: 流程中的所有功能处理器都是由pipeLine进行串联的
• accessMap: 所有接入节点的集合，以接入节点对象的beanName为key，ConditionFunc对象为value的map结构体
• main: 实现接口
• access(access, type, reqParam): 实现接口
• access(beanName, reqParam): 实现接口
• init(): 抽象方法，子类实现
• afterPropertiesSet: 初始化HandlerContextPipeLine

CompanyFlow和所有子流程

• init: 添加该流程所需的功能处理器

功能处理器

每个流程是由多个功能处理器组成

特性介绍

我们通过两个纬度对每个功能处理器赋予特性：

1. 流程节点 | 接入节点

   
   public enum HandlerType {
   /**
    * 异步接收外部系统mq，将其接入到流程的节点定义为接入节点
    */
   ACCESS("接入节点", 1),
   /**
    * 每个flow初始化时定义的handler节点
    */
   PROCESS("流程节点", 2);
   }

2. 静态特性 | 动态特性
- 静态特性：该功能处理器在初始化时已知前驱节点和后驱节点
- 动态特性：该功能处理器根据运行过程中的数据判断是否有后驱节点和后驱节点的beanName  
由以上两种特性可衍生出三种节点类型

public enum FeatureType {
/**

• 根据初始化的顺序已经指定前驱节点和后驱节点
  */
  NORMAL("普通节点", 1),

/**

• 该节点为结束节点，有两种节点会是结束节点
• 1. 请求外部系统，等待异步接收mq消息返回
• 2. 最后一个节点
     */
     OVER("结束节点", 2),

/**

• 根据运行时的数据判断该节点为以下三种状态
• 1. 该节点为结束节点
• 2. 该节点下个节点为初始化默认的后驱节点
• 3. 该节点的后驱节点为计算后的节点
     */
     CONDITION("条件节点", 3);
     }

     
     一个流程中的所有节点，主要分为流程节点和接入节点，其次根据每个节点的动静特性分为普通节点/结束节点/条件节点
     但是无论是流程节点还是接入节点，都会被封装为DefaultHandlerContext对象

public class DefaultHandlerContext<T> extends AbstractHandlerContext {
    /**
     * 空节点，next节点等于该节点，表示当前节点为结束节点
     */
    public static final DefaultHandlerContext NULL_OBJECT = new DefaultHandlerContext();

    /**
     * 业务处理handler
     */
    private ProcessHandler<T> handler;

    /**
     * handler的beanName
     */
    private String beanName;

    ...
}

public abstract class AbstractHandlerContext<T> implements ProcessHandler<T> {

    /**
     * 默认为普通节点
     */
    protected FeatureType featureType = FeatureType.NORMAL;

    /**
     * 默认为流程节点
     */
    protected HandlerType handlerType = HandlerType.PROCESS;

    /**
     * 当前节点的前驱节点
     */
    protected DefaultHandlerContext prev;

    /**
     * 当前节点的后驱节点
     */
    protected DefaultHandlerContext next;

    /**
     * 当前节点为条件节点时的执行语句，以判断当前节点是否是结束节点，如果不是，获取下个节点的handler beanName
     */
    protected ConditionFunc<T> conditionFun;

    ...

}

流程节点介绍

DefaultHandlerContext中的handler类图如下：

ProcessHandler

• process: 处理业务方法
• getBeanName: 获取该handler beanName
• interface Internal: 内部接口 收集该handler处理器的返回值和需要更新的表数据等

AbstractProcessHandler

• process 处理业务组合方法

    public T process(ReqParam reqParam) {
       doBefore(reqParam);
       T result = doProcess(reqParam);
       doAfter(reqParam, result);
       internal.intern(reqParam, result);
  
       return result;
   }

• doBefore: 调用业务处理器的前置方法, 默认实现

• doProcess: 抽象方法，供子类处理器实现，真正业务处理方法

• doAfter: 调用业务处理器的后置方法，默认实现

• InternalImpl: 实现接口Internal，完成对业务处理运行时的数据收集，可供前端展示和问题定位分析使用

子类功能处理器（inTransitOrder、fraudQuery、fraudReceiver等）

• invoker: 处理非业务的数据处理执行器，如根据返回值判断该节点是否需要操作数据库、操作哪些表、返回值的存储等
• doProcess: 处理该功能处理器的业务方法，如在途订单：调用第三方接口，获取数据以判断是否含有在途订单等业务逻辑

流程内的节点可以是普通节点、结束节点、条件节点；
举例分析：

• 结束节点：
  • fraudQuery：反欺诈异步请求节点，流程在执行该节点后，线程已结束，等待策略mq消息返回
• 普通节点：
  • quotaMatchOfProList：多金融方案进行匹配完后，默认next节点就是discriOver调度节点
• 条件节点：
  • prePaymentQuery：额度缓存判断处理器，额度缓存存在则下个节点是quotaMatchOfProList（多金融方案匹配节点），不存在则异步请求基础风控策略，当前节点为结束节点
  • fraudReceiver：反欺诈策略接收处理器，反欺诈通过则下个节点是prePaymentQuery（额度缓存处理器节点），反欺诈拒绝则下个节点为preMqSendV3（发送mq消息）

接入节点介绍

Access类图如下：

FlowAccess:

• getBeanName: 获取该Access beanName

BaseAccess

• getBeanName: 获取该Access beanName
• pass: 通过（基础风控通过、电审通过、提额通过、担保通过等）
• reject: 拒绝（基础风控拒绝、电审拒绝、提额拒绝、担保拒绝等）
• cancel： 取消（提额拒绝、担保拒绝等）

子类接入流程处理器

• 复写父类的pass/reject/cancel方法

执行流程分析：

以前置三期流程为例

类图如下：

流程图：参考系统流程.md文件

所用到的功能处理器归纳如下：

初始化流程

BaseFlow#

    public void afterPropertiesSet() throws Exception {
        pipeLine = new HandlerContextPipeLine(new DefaultHandlerContext(start), new DefaultHandlerContext(terminate, FeatureType.OVER));
        init();
    }

HandlerContextPipeLine#

    // 当前flow流程的所有DefaultHandlerContext
    private Map<String, DefaultHandlerContext> contextMap = new HashMap<String, DefaultHandlerContext>() {{
        // 包含NULL_OBJECT
        put(null, DefaultHandlerContext.NULL_OBJECT);
    }};

    /**
     * HandlerContextPipeLine 构造函数
     * @param head
     * @param end
     */
    public HandlerContextPipeLine(DefaultHandlerContext head, DefaultHandlerContext end) {
        this.head = head;
        this.end = end;

        contextMap.put(head.getBeanName(), head);
        contextMap.put(end.getBeanName(), end);
        head.setNext(end);
        end.setPrev(head);
    }

• 先初始化流程中的pipeLine，每个HandlerContextPipeLine初始化都有start和terminate节点
• pipeLine中的每个节点都有前驱节点和后驱节点属性
• contextMap：该流程中所包含的所有功能处理器

  
  preflow#

/**
 * 流程节点初始化
 */
@Override
@SuppressWarnings("unchecked")
public void init() {
    pipeLine
            .add(new DefaultHandlerContext<>(HandlerUtil.getHandler("inTransitOrder"), inTransitFun))
            .add(new DefaultHandlerContext<>(HandlerUtil.getHandler("fraudQuery"), FeatureType.OVER))
            .add(new DefaultHandlerContext<>(HandlerUtil.getHandler("fraudReceiver"), fraudReceiverFun))
            .add(new DefaultHandlerContext<>(HandlerUtil.getHandler("prePaymentQuery"), prePaymentFun))
            .add(new DefaultHandlerContext<>(HandlerUtil.getHandler("quotaMatch"), quotaMatchFun))
            .add(new DefaultHandlerContext(HandlerUtil.getHandler("quotaMatchOfProList")))
            .add(new DefaultHandlerContext<>(HandlerUtil.getHandler("discriOver"), discrFun))
            .add(new DefaultHandlerContext<>(HandlerUtil.getHandler("xQuery"), FeatureType.OVER))
            .add(new DefaultHandlerContext<>(HandlerUtil.getHandler("xReceiver")))
            .add(new DefaultHandlerContext<>(HandlerUtil.getHandler("recommendBankQuery"), recommendBankQryFun))
            .add(new DefaultHandlerContext<>(HandlerUtil.getHandler("recommendBankReceiver"), recommendBankRecFun))
            .add(new DefaultHandlerContext(HandlerUtil.getHandler("guaranteeQuery"), FeatureType.OVER))
            .add(new DefaultHandlerContext<>(HandlerUtil.getHandler("guaranteeReceive"), guaFun))
            .add(new DefaultHandlerContext<>(HandlerUtil.getHandler("preMqSend"), preMqSendFun))
            .add(new DefaultHandlerContext(HandlerUtil.getHandler("preMqSendV3")));

}

HandlerContextPipeLine#
/**

• 新增节点时: 当前节点是普通节点时，设置当前节点的next节点为end

• --------- 上游节点是普通节点时，设置当前节点为上游节点的next节点

• @param handlerContext

• @return
  */
  public HandlerContextPipeLine add(DefaultHandlerContext handlerContext) {
  DefaultHandlerContext preContext = end.getPrev();
  end.setPrev(handlerContext);
  if (handlerContext.getFeatureType() == FeatureType.NORMAL) {
  handlerContext.setNext(end);
  }

  handlerContext.setPrev(preContext);
  if (preContext.getFeatureType() == FeatureType.NORMAL) {
  preContext.setNext(handlerContext);
  }

  contextMap.put(handlerContext.getBeanName(), handlerContext);
  return this;
  }

DefaultHandlerContext#

public DefaultHandlerContext(ProcessHandler handler, FeatureType type) {
    this(handler);
    this.featureType = type;
    if (featureType == FeatureType.OVER) {
        next = NULL_OBJECT;
    }
}

> - 当前节点为普通节点时，会初始化前驱节点和后驱节点
> - 当前节点为条件节点时，初始化不会设置next节点
> - 当前节点为结束节点时，初始化next节点为NULL_OBJECT

---
#### 进件流程
初始化结束后，进件执行流程如下：
根据进件选择执行具体流程

RiskExecutor#

public void execute(String bizNo, RiskAdmittanceQueryParams params) {
    Flow flow = getFlow(params);
    flow.main(bizNo, params);
}

执行flow的main方法：

BaseFlow#

/**
 * 从starthandler开始流程
 *
 * @param bizNo
 * @param params
 */
@Override
public void main(String bizNo, RiskAdmittanceQueryParams params) {
    pipeLine.start(getDataUtil().initReqParam(bizNo, params), getDataUtil());
}

执行HandlerContextPipeLine的start方法：

HandlerContextPipeLine#

/**
 * 流程的开始节点
 *
 * @param reqParam
 * @param dataUtil
 */
public void start(ReqParam reqParam, DataUtil dataUtil) {
    head.execute(reqParam, dataUtil, handlerFun);
}

执行AbstractHandlerContext的execute方法：

AbstractHandlerContext#

void execute(ReqParam reqParam, DataUtil dataUtil, Function<String, DefaultHandlerContext> handlerFun) {
    log.info(" === bizNo: {} - execute {} handler start", reqParam.getBizNo(), this.getBeanName());

    DefaultHandlerContext temp;
    if (FeatureType.CONDITION == featureType) {
        temp = handlerFun.apply(conditionFun.invoke(reqParam, this.process(reqParam)));
    } else {
        this.process(reqParam);
        temp = next;
    }

    // 对数据进行落库操作
    updateData(reqParam, dataUtil);

    // 判断该handler处理完是否终结
    if (temp == NULL_OBJECT) {
        log.info("=== bizNo: {} - execute {} handler end,当前流程已结束，数据：{}", reqParam.getBizNo(), this.getBeanName(), JSON.toJSONString(reqParam));
        return;
    }

    log.info("=== bizNo: {} - execute {} handler end, 当前handler处理后的数据：{},下个handlerName:{}", reqParam.getBizNo(), this.getBeanName(), JSON.toJSONString(reqParam.getCurrentInfo()), temp.getBeanName());
    temp.execute(reqParam, dataUtil, handlerFun);
}

> - 判断当前节点是否是条件节点
>   - 是，执行当前节点process方法，将返回值传入条件对象ConditFunc中，获取next节点
>   - 否，执行当前节点process方法，获取当前节点的默认next节点
> - 根据当前节点的HandlerInfo数据进行落库操作
> - 判断下个节点是否是NULL_OBJECT
>   - 是，当前线程结束，打印数据
>   - 否，执行下个节点的execute方法
---
#### 接入流程


> 接入节点通常都是条件节点

以反欺诈接入节点为例：

@Component
@Slf4j
@Data
public class FraudAccess extends BaseAccess {
}

@Access
@Data
@Slf4j
public abstract class BaseAccess implements FlowAccess {
...
/**

• 通过
• @param reqParam
  */
  public void pass(ReqParam reqParam) {
  log.info("进入接入{}类内，调用pass方法", this.getBeanName());
  // 额度匹配
  reqParam.getFlow().access(this, "pass", reqParam);
  }
  ...

}

> FraudAccess是空实现，直接调用父类方法  
> 通过reqParam可知当前接入节点所接入的流程，从而调用BaseFlow中的access方法

BaseFlow#

Map<String, Map<String, ConditionFunc>> accessMap = new HashMap<String, Map<String, ConditionFunc>>() {{
    // 反欺诈
    put("fraudAccess",
            new HashMap<String, ConditionFunc>() {{
                put("pass", (reqParam, o) -> "fraudReceiver");
            }});
            ...
}};

/**
 * 从mq接入流程内
 *
 * @param access
 * @param reqParam
 * @param type
 */
@Override
public void access(FlowAccess access, String type, ReqParam reqParam) {
    log.info("access:{}, type:{} 接入流程内", access.getBeanName(), type);
    String funcKey = access.getBeanName();
    ConditionFunc func = null;
    if (accessMap.containsKey(funcKey)) {
        func = accessMap.get(funcKey).get(type);
    } else if (access instanceof MatchQuotaAccess) {
        func = accessMap.get("matchAccess").get(type);
    }

    Assert.notNull(func, access.getBeanName() + "func should not null");
    pipeLine.access(funcKey, func, reqParam, getDataUtil());
}
...

}

> accessMap: 流程初始化时，以access beanName为key，ConditionFunc（确认下个节点的beanName）对象为value的map数据  
> access: 通过access beanName获取条件对象ConditionFunc, 调用HandlerContextPipeLine#access方法

HandlerContextPipeLine#

/**
 * mq接收数据接入流程
 *
 * @param beanName access name
 * @param func     要执行的func
 * @param reqParam
 * @param dataUtil
 */
public void access(String beanName, ConditionFunc<ReqParam> func, ReqParam reqParam, DataUtil dataUtil) {
    log.info("mq接收数据节点接入HandlerContextPipeLine内，beanName：{}", beanName);
    DefaultHandlerContext<ReqParam> handlerContext = new DefaultHandlerContext<>(func, beanName);
    handlerContext.execute(reqParam, dataUtil, handlerFun);
}

> 1. 通过beanName和ConditionFunc对象初始化DefaultHandlerContext对象
> 2. 执行AbstractContext.execute方法，由上述进件流程可知，因1创建的DefaultHandlerContext是条件节点，执行ConditionFunc执行器获取下个节点（流程中的节点），从而进入流程节点

ConditionFunc执行器接口定义：

@FunctionalInterface
public interface ConditionFunc {
String invoke(ReqParam reqParam, T t);
}

---
总结：该篇主要介绍系统业务架构的思想
1. 首先根据业务性质区分功能处理器特性
2. 用HandlerContextPipeLine将流程内的节点进行串接
3. 每个节点设置prev（前驱节点）和next（后驱节点），以达到系统灵活的扩展性