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

• 資深大佬 : codespots

  支持乙，主要是被调用方不可控，那可控的就只能是调用方了。

• 資深大佬 : Biu0617

  主要看业务，通知系统 B 的结果不重要的话就选用 乙方案，通知的结果比较重要就选甲方案并且要增加补推的机制。

• 資深大佬 : Biu0617

  举例
  乙方案：微信支付（即系统 A ）回调 /通知到 我们支付中心（系统 B ），微信会回调几次，支付中心无应答后也不会重试了。
  甲方案：我们支付中心（此时作为系统 A ） 通知到我们具体的业务系统（系统 B ），要确保支付状态的通知能够通知到位，则会一直请求直到业务系统应答，并且增加监控和异常补推等功能。

• 資深大佬 : wzzzx

  你是说通知，通知的话只需要确保对方知道这个事就可以了

• 主 資深大佬 : luckylo

  @Biu0617 http 状态码是 200 了，肯定是通知到位了。B 业务处理失败，返回业务状态码失败，这个不是 A 需要关心的。 因为 B 的这个失败，可能就是 B 无需处理，所以失败。
  还有就是，B 接到请求，在处理失败的时候，应该及时落库，如果需要重试处理的，也应该是 B 任务补偿而不是 A 继续通知。因为 A 根本不知道要不要继续通知

• 資深大佬 : Biu0617

  @luckylo 在理

• 資深大佬 : qiayue

  这个完全看文档如何定的，我们提供接口给平台回调，有些平台要求业务处理成功返回 http 码 200，不成功则返回其他错误码，当非 200 时，平台会重试，同一个数据最多回调 3 次，如果 3 次还不返回 200，由此带来的业务损失，由我们自己负责。

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

  你说这两个平台的处理方式有问题吗？
  都没问题，都能解决业务需求。

• 資深大佬 : eason1874

  直接学支付宝、微信那些大平台的做法，那些是经过检验的。

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

  我不太相信状态码，会担心哪天业务逻辑错误，请求没进到实际模块直接返回了 200 状态。

• 資深大佬 : yeqizhang

  两个不能都做吗

• 資深大佬 : zzh7982

  直接发给消息队列不就完了么

• 資深大佬 : haosamax

  一般支付平台的回调都是甲这种方案

• 資深大佬 : byzf

  实际情况里要反馈一下失败的，不反馈失败让用户自己猜失败原因吗。。。那你要反馈一个失败必然不能只靠 200 。

• 主 資深大佬 : luckylo

  @byzf 对方 200 证明拿到请求了。既然拿到请求，幂等 补偿不应该是对方自己的事？

• 主 資深大佬 : luckylo

  @byzf 0 成功，1 失败，2 无需处理，那我还需要判断这个干嘛？失败原因是啥，我还需要根据 N 多原因判断？没这说法吧？

• 主 資深大佬 : luckylo

  @byzf 要是对方 一个 NPE，导致失败了，我傻乎乎的重试？这本就是对方补偿的事吧

• 資深大佬 : byzf

  @luckylo 重试不重试也是业务需求。这个我也不知道啥叫傻乎乎，一般支付回调如果失败都是要重发的，不管是我去接别的大平台还是别人来接我公司的小平台，而且配置错误的各种可能中会返回一个 200 的状态码是很常见的