关于微服务之间调用的超时hystrix熔断随记

微服务实现了服务之间的解耦,但是正如与单体项目的不同,服务之间的不可控性是必须直面的一个问题:
比如,库存服务A与WMS系统B之间的推送订单流程。
关于微服务之间调用的超时hystrix熔断随记_第1张图片就拿以上最常见的俩个流程来说,
1.第一个是库存服务查询WMS的批次信息,然后将批次库存落库;
2.库存服务推送出库单至wms或者是从wms取消已推送的出库单;
这里如果出现wms系统异常,请求超时会造成什么问题?首先这几步都会涉及到平台库存的变更(查询批次用于同步平台的可用库存,订单推送取消用于扣减平台已锁定的库存,做释放操作)

问题1:库存变更涉及到锁机制,长时间服务未响应,会导致一些锁时间过长而失效引发并发问题
问题2:因为卡在了服务调用这一块,数据库事务长时间未提交,如果这个时候有其他用户下单用到了当前批次,会造成数据库行锁等待,如果大批量行锁等待甚至会导致锁表的严重事故发生。

这俩块如果做超时熔断处理应该怎么操作?
1.设置超时熔断时间,就拿springcloud的feign举例,对feign做分类性超时管理,一些查询操作超时时间尽量设置短些,一些涉及到更新操作的超时时间尽量长一些,因为服务A使用redis做了分布式锁默认失效时长为30s,所以更新类的feign超时设置在30s左右即可
而普通的查询操作,设置在10s以内即可,甚至一些高流量的场景可设置在3s以内
关于微服务之间调用的超时hystrix熔断随记_第2张图片
2.做超时熔断补偿机制,如果服务A推单超时熔断,但是实际上wms在后续又处理完毕该怎么处理?
所以要考虑到一个补偿机制,针对推单失败的订单,熔断之后fallback需要调用取消订单再确认取消一次即可,这里只是简单点举例说明,复杂场景需复杂考虑
关于微服务之间调用的超时hystrix熔断随记_第3张图片

你可能感兴趣的:(自我摸索,数据库,java,redis)