微服务之补偿服务架构

补偿服务是使用一个额外的协调服务来协调各个需要保证一致性的微服务，协调服务按顺序调用各个微服务，协调服务实现为一个通用的补偿框架，保证最终一致性。

当客户的一个预订请求达到时，协调服务（补偿框架）为请求生成一个全局唯一的业务流水号，并在调用各个工作服务的同时记录完整的状态.

 

做过支付宝交易接口的同学都知道，我们一般会在支付宝的回调页面和接口里，解密参数，然后调用系统中更新交易状态相关的服务，将订单更新为付款成功。同时，只有当我们回调页面中输出了success字样或者标识业务处理成功相应状态码时，支付宝才会停止回调请求。否则，支付宝会每间隔一段时间后，再向客户方发起回调请求，直到输出成功标识为止

 

业务方提供幂等接口，服务层周期调用。

接口格式按统一标准，比如code 10000是成功，其他标识 失败，失败继续调用。

 

首先业务方向服务层注册服务，提供notify_url和成功返回参数，系统返回生成的业务号business_id。

服务层提供接口，业务方通过该接口注册，请求url和参数

比如 xxxxx.com?appkey=xxx&business_id=xxxx&xxx=xxxxx

除了appkey和business_id参数，转发其他所有请求参数到填写的notify_url，识别到返回成功，停止请求。

后台配置成功标识

减少业务方工作量

否则业务方需要自己去做定时任务处理，且无法观察服务请求质量

接入到该服务，业务方仅提供标准api即可，可数据后台观察处理情况。

注意:

由于HTTP请求超时情况，提供接口需保证幂等。

 

 

 

核心链路统一补偿服务

1.主逻辑通知到子逻辑，子逻辑需保证以主逻辑的唯一票据为幂等参数，子逻辑不用关心自我处理情况，由主逻辑定时任务轮训子逻辑处理情况，直到处理成功。

好处:可以对两种情况进行补偿，1是网络原因通知子逻辑失败，2是子逻辑自己系统原因处理失败。

2.主逻辑只要通知到子逻辑即可，若子逻辑处理失败，自我进行修复

劣势:只能修复自我处理失败的情况，对网络原因主逻辑未通知到子逻辑的无法处理。