微服务实现了服务之间的解耦,但是正如与单体项目的不同，服务之间的不可控性是必须直面的一个问题：
比如，库存服务A与WMS系统B之间的推送订单流程。
就拿以上最常见的俩个流程来说，
1.第一个是库存服务查询WMS的批次信息，然后将批次库存落库；
2.库存服务推送出库单至wms或者是从wms取消已推送的出库单；
这里如果出现wms系统异常，请求超时会造成什么问题？首先这几步都会涉及到平台库存的变更（查询批次用于同步平台的可用库存，订单推送取消用于扣减平台已锁定的库存，做释放操作）
问题1：库存变更涉及到锁机制，长时间服务未响应，会导致一些锁时间过长而失效引发并发问题
问题2：因为卡在了服务调用这一块，数据库事务长时间未提交，如果这个时候有其他用户下单用到了当前批次，会造成数据库行锁等待，如果大批量行锁等待甚至会导致锁表的严重事故发生。
这俩块如果做超时熔断处理应该怎么操作？
1.设置超时熔断时间，就拿springcloud的feign举例，对feign做分类性超时管理，一些查询操作超时时间尽量设置短些，一些涉及到更新操作的超时时间尽量长一些，因为服务A使用redis做了分布式锁默认失效时长为30s，所以更新类的feign超时设置在30s左右即可
而普通的查询操作，设置在10s以内即可，甚至一些高流量的场景可设置在3s以内
2.做超时熔断补偿机制，如果服务A推单超时熔断，但是实际上wms在后续又处理完毕该怎么处理？
所以要考虑到一个补偿机制，针对推单失败的订单，熔断之后fallback需要调用取消订单再确认取消一次即可，这里只是简单点举例说明，复杂场景需复杂考虑
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
