V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
luckylo
V2EX  ›  程序员

闲聊—— 一个其他业务方对接的问题。

  •  
  •   luckylo · 2021-01-13 10:39:37 +08:00 via Android · 1852 次点击
    这是一个创建于 1171 天前的主题,其中的信息可能已经有所发展或是发生改变。
    场景描述。
    一个系统 A 的某个操作 需要通知到 系统 B 。

    甲 :一定要等到 系统 B 返回 业务状态码 为成功,否则就需要重试 (原因:业务方处理失败,应该自行主动重试)。

    乙 :通知 系统 B 的时候,只要 http 状态码 为 200,就不再重试。(原因:业务方处理失败,应该由业务方自己补偿)

    对于这个,我个人支持 乙 。各位大佬发表下看法。
    16 条回复    2021-01-14 15:30:39 +08:00
    codespots
        1
    codespots  
       2021-01-13 10:44:12 +08:00
    支持乙,主要是被调用方不可控,那可控的就只能是调用方了。
    Biu0617
        2
    Biu0617  
       2021-01-13 10:55:43 +08:00
    主要看业务,通知系统 B 的结果不重要的话就选用 乙方案,通知的结果比较重要就选甲方案并且要增加补推的机制。
    Biu0617
        3
    Biu0617  
       2021-01-13 11:01:41 +08:00   ❤️ 1
    举例
    乙方案:微信支付(即系统 A )回调 /通知到 我们支付中心(系统 B ),微信会回调几次,支付中心无应答后也不会重试了。
    甲方案:我们支付中心(此时作为系统 A ) 通知到我们具体的业务系统(系统 B ),要确保支付状态的通知能够通知到位,则会一直请求直到业务系统应答,并且增加监控和异常补推等功能。
    wzzzx
        4
    wzzzx  
       2021-01-13 11:03:03 +08:00
    你是说通知,通知的话只需要确保对方知道这个事就可以了
    luckylo
        5
    luckylo  
    OP
       2021-01-13 11:11:58 +08:00 via Android
    @Biu0617 http 状态码是 200 了,肯定是通知到位了。B 业务处理失败,返回业务状态码失败,这个不是 A 需要关心的。 因为 B 的这个失败,可能就是 B 无需处理,所以失败。
    还有就是,B 接到请求,在处理失败的时候,应该及时落库,如果需要重试处理的,也应该是 B 任务补偿而不是 A 继续通知。因为 A 根本不知道要不要继续通知
    Biu0617
        6
    Biu0617  
       2021-01-13 11:19:01 +08:00
    @luckylo 在理
    qiayue
        7
    qiayue  
       2021-01-13 11:20:02 +08:00
    这个完全看文档如何定的,我们提供接口给平台回调,有些平台要求业务处理成功返回 http 码 200,不成功则返回其他错误码,当非 200 时,平台会重试,同一个数据最多回调 3 次,如果 3 次还不返回 200,由此带来的业务损失,由我们自己负责。

    另一个平台则要求我们业务处理成功时返回 {"code":0},处理失败是返回 {"code":xxx} ,当返回 code 非 0 时,平台也会重试,也是最多回调 3 次。

    你说这两个平台的处理方式有问题吗?
    都没问题,都能解决业务需求。
    eason1874
        8
    eason1874  
       2021-01-13 11:23:11 +08:00   ❤️ 1
    直接学支付宝、微信那些大平台的做法,那些是经过检验的。

    要求系统 B 返回 success 表示通知到位,同步通知一次,没收到 success 就连续异步通知几次,间隔 4m 、10m 、10m 、1h 、2h 、6h 、15h 等等。

    我不太相信状态码,会担心哪天业务逻辑错误,请求没进到实际模块直接返回了 200 状态。
    yeqizhang
        9
    yeqizhang  
       2021-01-13 11:41:17 +08:00
    两个不能都做吗
    zzh7982
        10
    zzh7982  
       2021-01-13 14:40:59 +08:00
    直接发给消息队列不就完了么
    haosamax
        11
    haosamax  
       2021-01-13 15:18:28 +08:00
    一般支付平台的回调都是甲这种方案
    byzf
        12
    byzf  
       2021-01-14 02:58:12 +08:00
    实际情况里要反馈一下失败的,不反馈失败让用户自己猜失败原因吗。。。那你要反馈一个失败必然不能只靠 200 。
    luckylo
        13
    luckylo  
    OP
       2021-01-14 07:52:13 +08:00 via Android
    @byzf 对方 200 证明拿到请求了。既然拿到请求,幂等 补偿不应该是对方自己的事?
    luckylo
        14
    luckylo  
    OP
       2021-01-14 07:54:06 +08:00 via Android
    @byzf 0 成功,1 失败,2 无需处理,那我还需要判断这个干嘛?失败原因是啥,我还需要根据 N 多原因判断?没这说法吧?
    luckylo
        15
    luckylo  
    OP
       2021-01-14 07:55:31 +08:00 via Android
    @byzf 要是对方 一个 NPE,导致失败了,我傻乎乎的重试?这本就是对方补偿的事吧
    byzf
        16
    byzf  
       2021-01-14 15:30:39 +08:00
    @luckylo 重试不重试也是业务需求。这个我也不知道啥叫傻乎乎,一般支付回调如果失败都是要重发的,不管是我去接别的大平台还是别人来接我公司的小平台,而且配置错误的各种可能中会返回一个 200 的状态码是很常见的
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5384 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 08:38 · PVG 16:38 · LAX 01:38 · JFK 04:38
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.