关于服务间一致性和前置校验的思考

发表于 |

每个服务都有相应的前置校验，有些前置校验逻辑不统一，就会导致服务间数据的不一致。比如风控拦截，服务A未拦截，而服务B却拦截了，从而导致不一致。

业务描述

  • 下面描述一个仓库送礼的场景
    送礼请求----------> 服务A(送礼服务)
           [1.出仓库礼物]------------>服务B(仓库服务)
           [2.收礼者加分成]------------>服务C(消费服务[含分成服务])

送礼请求----------> 服务A(送礼服务)
             [1.出仓库礼物]------------>服务B(仓库服务)
             [2.收礼者加分成]------------>服务C(消费服务[含分成服务])
                                [查询是否风险用户]------------>服务D(风控服务)

服务C增加查询之后，如果是风险用户，将会拦截加分成的操作。这样就会导致用户仓库礼物出仓了，但是收礼者却无法接收分成

如何解决

服务B也要进行风险用户判断，针对资金操作相关的校验，可以统一逻辑，避免相同逻辑维护多个地方

  1. 服务C增加一个统一判断接口
    送礼请求----> 服务A(送礼服务)
          [1.出仓库礼物]----->服务B(仓库服务)
                        [ 1.1查询用户是否允许资金变动]----->服务C
                                     [1.1.1查询是否风险用户]--->服务D(风控服务)
          [2.收礼者加分成]----->服务C(消费服务[含分成服务])
                            [2.1查询是否风险用户]----->服务D(风控服务)


若用户是风险用户，操作1就会返回失败，不出仓，也无后续的操作2，这样就避免不一致的问题

  1. 收敛消费入口，统一资产类的入口
    方案1的缺点明显，每个服务都要直接或间接的查询一次风控服务，实际上理想情况下，只需要查询一次即可。
    送礼请求----------> 服务A(送礼服务)
          [1.出仓库礼物和加分成]--------->服务C(消费服务)
                                [1.1查询是否风险用户]------------>服务D(风控服务)
                                [1.2出仓库礼物]------------>服务B(仓库服务)
                                [1.3收礼者加分成]


由消费服务统一对资产进行“出”和“入”

  1. 网关服务拦截
    由网关服务统一调风控服务进行判断，并支持业务类型定制(比如资产类接口应该进行哪些判断)