一、微服务交互模式
1.1、同步调用
特点：
- 请求服务方调用响应服务方，请求方阻塞等待响应处理结果，一直等待到超时或成功。
适用场景：
- 大规模，高并发的短小操作，不适用后端负载较高的场景。如：JDBC实现为BIO同步阻塞
1.2、异步调用
特点：
- 请求服务调用响应服务，响应服务受理成功后，请求服务继续其他操作，当响应服务操作成功后请求服务做后续处理操作
使用场景：
- 非核心链路处理，耗时长，对实时要求不高。
1.3、消息队列异步处理
特点：
- 发送者发送消息给接收者，发送者不等待接收者返回结果。实现了服务之间的解耦，一般应用于非核心链路负载较高环节。
使用场景：
- 用户支付成功后采用消息方式异步处理物流信息。
1.4、同步与异步选择
- 同步与异步选择原则：
1、尽量使用异步代替同步操作：
- 从实际业务出发，将耗时操作放在异步处理
2、能用同步解决的问题不用异步：
- 从技术架构出发没有性能问题使用同步操作
二、交互模式解决方案
2.1、同步调用解决方案
- 同步状态下服务会返回两种状态的数据
两种状态接口：成功，失败
三种状态接口：成功，失败，处理中
2.1.1、两状态的同步接口：成功，失败
1、服务调用同步接口时（返回失败时）：
- 调用方发起重试再次处理（重试需要进行幂等性处理）
2、服务之间调用时（返回失败时）：
- 使用快速失败策略：针对这个超时服务快速返回失败
- 调用方调用被调用方的冲正接口，通过冲正接口判断进行回滚操作还是幂等操作
2.1.2、三状态的同步接口：成功，失败，处理中
1、服务调用同步接口时（返回处理中时）：
- 补充一个亲戚的处理状态，与超时处理一致
2、服务之间调用时（返回处理时）：
- 返回处理中状态给用户，系统进行补偿执行出错部分
- 调用冲正接口判断回滚，重新发送，并进行幂等操作
2.2、异步调用解决方案
- 异步调用通常返回：受理，未受理还有处理成功和处理失败
2.2.1、异步调用接口超时（服务异步调用接口失败）
- 通过查询补齐状态
- 根据状态进行后续操作
2.2.2、异步调用内部超时（服务间调用超时）
- 服务间异步调用模式使用的是受理模式，一旦受理尽量将请求操作处理成功
处理流程
- 1、当前服务调用其他服务超时
- 2、当前服务调用其他服务的查询接口获取最新状态
- 3、根据最新状态补偿后续操作
2.2.3、异步调用回调超时（调用服务回调接口超时）
- 服务负责重新继续补偿，通常会设置一个通知时间按一定间隔递增策略。
2.3、消息队列异步处理解决方案
2.3.1、消息队列生产者超时
- 通过消息可靠模式来实现：消息状态保持到服务器
2.3.1、消息队列消费者超时
- 直接使用消息队列提供的机制来解决
1、自动增长消费的偏移量：
- 当消息取走后会自动增加消息偏移量，消息处理失败也不能从消息服务器再找到消息
2、手动提交消费的偏移量：（保证处理过程出现异常不影响消息）
- 1、消费者从消息服务器获取消息
- 2、消费者将消息进行持久化操作
- 3、消费者告知消息被消费
- 4、消息服务器移除消息
三、超时补偿原则
- 超时补偿一般用于服务间调用，服务间调用一般有远程服务响应或远程服务调用超时
3.1、当前服务调用远程服务成功
1、当前服务调用远程服务
2、远程服务响应当前服务并返回成功，当前服务结束调用
3、远程服务处理失败，远程服务负责重试或补偿
4、远程服务最佳实践：
- 远程服务收到消息将消息进行持久化，再告知当前服务接收成功，继续其他操作
3.2、当前服务调用远程服务失败
- 1、当前服务调用远程服务
- 2、远程服务没有给出明确的接收响应（如超时）
- 3、当前服务进行重试，直到确定收到消息（重试需要进行幂等操作）
来源：CSDN
作者：brusion
链接：https://blog.csdn.net/qq_34231253/article/details/85836832