队列和微服务的异步通信

什么是同步通信?

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

微服务架构

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

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

同步通信的缺点

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

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

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

异步通信

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

微服务应用架构

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

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

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

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

异步通信的优点

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

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

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

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

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

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

异步通信的局限性

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

概括

相关推荐
三坛海会大神55532 分钟前
k8s(六)Pod的资源控制器
云原生·容器·kubernetes
liming4952 小时前
k8s 安装 kuboardV3 报错
云原生·容器·kubernetes
ajax_beijing2 小时前
k8s的ReplicaSet介绍
运维·云原生
没有bug.的程序员3 小时前
服务治理与 API 网关:微服务流量管理的艺术
java·分布式·微服务·架构·wpf
宠友信息3 小时前
java微服务驱动的社区平台:友猫社区的功能模块与实现逻辑
java·开发语言·微服务
Guheyunyi4 小时前
风险感知中枢:监测预警系统的架构与核心
大数据·运维·安全·重构·架构·自动化
东城绝神4 小时前
《Linux运维总结:基于X86_64+ARM64架构CPU使用docker-compose一键离线部署consul 1.21.5容器版集群》
linux·运维·docker·架构·consul
shinelord明5 小时前
【大数据技术实战】Kafka 认证机制全解析
大数据·数据结构·分布式·架构·kafka
文火冰糖的硅基工坊6 小时前
[创业之路-702]:“第三次”与“第四次工业革命”的范式跃迁
大数据·人工智能·科技·嵌入式硬件·架构·嵌入式·gpu
粘豆煮包6 小时前
系统设计 System Design -4-2-系统设计问题-设计类似 TinyURL 的 URL 缩短服务 (改进版)
设计模式·架构