文章目录
同步调用
同步调用的优缺点和使用场景
- 同步调用的优点：时效性较强，等待结果返回后继续执行。
- 同步调用的缺点：拓展性差，每次需求变更都需要修改代码；性能下降，调用链越长耗时越久；可能引发雪崩级联失败问题。
- 使用场景：需要根据调用结果进行后续处理的业务，如扣减余额。
同步调用在余额支付业务中的应用
- 业务背景：用户在黑马商城点击支付，需要扣减用户余额并更新支付状态。
- 调用流程：支付服务调用用户微服务扣减余额，更新支付流水状态，再调用交易服务更新交易订单状态。
- 同步调用的必要性：扣减余额需要等待结果返回，确保支付状态正确。
同步调用在更新交易订单状态中的问题
- 问题原因：交易订单状态更新不属于支付核心业务，增加不必要的代码耦合。
- 业务影响：可能导致支付服务处理更多无关业务，影响拓展性和性能。
- 解决方案：避免使用同步调用，减少不必要的远程调用。
同步调用的性能和可靠性问题：
- 问题描述：同步调用的性能问题主要体现在调用链较长时耗时较久，且受网络影响，可能导致整体业务性能下降。可靠性方面，同步调用依赖远程服务，若服务故障或响应时间过长，可能导致资源无效占用，甚至出现雪崩级联失败。
- 影响：随着调用链长度增加，性能下降，用户体验变差；同时，服务间的依赖关系可能导致一个服务的故障引发整个系统的失败。
- 解决方案：通过采用异步调用，可以减少调用耗时和系统间的耦合，降低对远程服务的依赖，从而提高系统性能和可靠性。
同步调用总结：
- 优点：确保实时反馈，适合需要立即处理结果的场景。
- 缺点：性能差，扩展性差，容易引发服务依赖故障（雪崩效应）。
- 适用场景：需要根据返回结果进行后续操作的业务，如支付扣款。
异步调用
同步调用与异步调用的区别
- 同步调用：
- 存在两个角色：服务提供者和调用者。
- 调用者通过API请求，等待服务提供者的响应。
- 异步调用：
- 基于消息通知方式，涉及三个角色：消息发送者、消息接收者、消息代理。
- 调用者将请求发送到消息代理，消息代理将消息转发给服务提供者，服务提供者处理消息后不直接返回响应。
异步调用的应用场景与优势
- 场景：
- 类比生活中的外卖送餐：如果外卖员（调用者）直接送餐到消费者（服务提供者），效率低下且存在等待和干扰问题。异步调用通过消息代理（如外卖柜）解耦送餐员（调用者）与消费者（服务提供者），提高效率。
- 优势：
- 提高效率：调用完成后，消息代理将负责处理后续步骤，调用者不需要等待，系统性能得到提升。
- 故障隔离：如果后续服务发生故障，调用者无需等待，可以继续执行其他任务，避免系统崩溃。
- 减少级联失败：异步调用解除了服务之间的直接依赖，避免了一个服务失败导致其他服务无法执行的情况。
- 流量削峰填谷：通过消息代理缓存消息，减少系统负载，提高流量处理能力。
- 提高效率：调用完成后，消息代理将负责处理后续步骤，调用者不需要等待，系统性能得到提升。
异步调用的缺点
- 时效性差：由于消息是异步投递，调用者无法及时获得响应结果，可能需要等到接收方处理完成才能得到结果。
- 依赖消息代理的可靠性：消息代理是异步调用的核心，一旦出现故障，可能会导致消息丢失或处理延迟。
异步调用总结
- 异步调用的优势：提高效率、增强扩展性、减少业务偶合、支持流量控制等。
- 异步调用的缺点：时效性差、依赖消息代理的可靠性。
异步调用与同步调用的选择
- 同步调用：适用于时效性要求较高的场景，需要立即得到结果并做进一步处理。
- 异步调用：适用于对调用结果不关心、对性能要求较高的场景，可以提高效率，避免阻塞。