13、微服务架构下的工作流与服务交互

微服务架构下的工作流与服务交互

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