微服务架构下的工作流与服务交互
1. 工作流概述
从Slack的角度来看,当用户输入消息时,配置好的URL会接收到JSON格式的信息。这些数据由Slack请求API接收,该API负责处理所有Slack消息,并选择合适的微服务作为目标。同时,会构建一个数据结构,用于包含回复消息的发送位置信息,就像消息的信封一样。动作处理服务无需理解这个结构,但向Slack发送回复的工具需要理解,未来还可以添加其他回复方式及其相关元数据。
如果Slack请求服务向微服务发出Web请求,需要等待其响应,这会导致API响应变慢,并且容错性较差。一旦某个组件出现故障,整个链条就会断裂,消息也会丢失。
为了解决这个问题,引入了消息队列。可以将消息传递给RabbitMQ,然后立即向Slack基础设施返回合适的状态码。RabbitMQ会接收消息,并确保将其传递给能够执行所需操作的工作进程。如果某个工作进程出现故障,消息会排队等待,直到服务恢复(除非设置了消息过期时间)。当创建好回复后,再次使用RabbitMQ将消息发送到Slack发布服务,这样可以提高消息处理的可靠性。
下面是工作流的mermaid流程图:
graph LR
A[用户输入消息] --> B[发送JSON信息到配置URL]
B --> C[Slack请求API接收数据]
C --> D[选择微服务]
D --> E[构建消息数据结构]
E --> F[消息传递给RabbitMQ]
F --> G[RabbitMQ传递消息到工作进程]
G --> H
超级会员免费看
订阅专栏 解锁全文

被折叠的 条评论
为什么被折叠?



