队列和微服务的异步通信

什么是同步通信?

考虑以下微服务架构示例:

微服务架构

您让 Microservice1 调用 Microservice2,而 Microservice2 又调用 Microservice3。假设 Microservice3 提供简单的 Web 服务功能。因此,Microservice1 可以通过 HTTP 向其发送数据请求,并返回包含所请求数据的响应。

这两个微服务之间存在的通信称为同步通信。Microservice1发送请求,等待数据返回,然后继续。

同步通信的缺点

当响应几乎立即到达时,这种通信模式效果很好。但是,它对所涉及的微服务施加了限制。为了使 Microservice1 可用,Microservice2 也需要可用。

在某些情况下,同步通信甚至可能对用户不友好。

假设 Microservice2 宕机了。在这种情况下,需要告知提交请求的用户。你并不总是想这样做。在这种情况下,异步通信提供了更好的选择。

异步通信

看一下以下应用程序架构:

微服务应用架构

在上图中,我们使用了 ZipkinDistributedTracingServer。不同的微服务发送日志,最终在 Zipkin 跟踪服务中进行整合。每个微服务将其跟踪信息放入 RabbitMQ 消息队列中。服务器在消息进入队列时对其进行处理。

在此架构中,应用程序通过 RabbitMQ 进行通信。CurrencyCalculationService 将其自己的跟踪信息放入 RabbitMQ,然后忘记它。它不担心返回给它的响应。

现在,如果 ZipkinDistributedTracingServer 宕机会发生什么?

与之通信的服务一点也不担心。他们将继续向队列发送消息。当服务器恢复时,它会继续处理队列中存在的消息,并将它们保存到数据库中。

异步通信的优点

让我们看看异步通信的一些优点:

在涉及异步消息传递的系统中,服务器不需要始终启动并运行。放入消息队列的消息可以稍后批量处理。

您可以生成多个实例来减轻负载,而不是使用跟踪服务器的单个实例来处理消息队列。

如果您使用现代版本的消息队列,那么您很有可能使用重播功能。这有助于重新处理最初引发错误的消息。

异步通信对于需要最终一致性的系统来说非常有用。

最棒的是,只要我们修复错误并重新处理消息,发起错误请求的服务的用户甚至不需要知道它们。

异步通信的局限性

如果处理需要实时,即如果对某个请求的响应时间存在严格限制,则不能使用异步通信。

概括

相关推荐
眠りたいです20 小时前
基于脚手架微服务的视频点播系统-数据管理与网络通信部分的预备工作
c++·qt·ui·微服务·云原生·架构·媒体
虫小宝1 天前
返利软件的分布式缓存架构:Redis集群在高并发场景下的优化策略
分布式·缓存·架构
一水鉴天1 天前
整体设计 之 绪 思维导图引擎 之 引 认知系统 之 引 认知系统 之 序 认知元架构 之6 拼句 之1 (豆包助手 之8)
架构·认知科学
纪元A梦1 天前
Redis最佳实践——安全与稳定性保障之高可用架构详解
redis·安全·架构
Dontla1 天前
流行的前端架构与后端架构介绍(Architecture)
前端·架构
熊文豪1 天前
KingbaseES读写分离集群架构解析
数据库·架构·kingbasees·金仓数据库·电科金仓
往事随风去1 天前
别再纠结了!IM场景下WebSocket和MQTT的正确选择姿势,一文讲透!
后端·websocket·架构
爱读源码的大都督1 天前
为什么Spring 6中要把synchronized替换为ReentrantLock?
java·后端·架构
一水鉴天1 天前
整体设计 之 绪 思维导图引擎 之 引 认知系统 之 引 认知系统 之 序 认知元架构 之 元宇宙:三种“即是”逻辑与数据安全措施的适配(豆包助手 之10)
架构·认知科学