微服务架构下消息服务多通道设计思路_业务消息通道常见设计

在微服务架构软件中，消息是极其重要的一部分，一般会独立成一个服务，称为 message 服务。其主要作用就是发送消息，并且支持向多种第三方发送，如站内信、邮件、短信等。

发送消息难点

1. 发送消息接口响应时间太长。当 mesage 服务接收到发送消息请求后，可以做到实时向第三方进行发送，但第三方的消息返回时间不可控制。即发送消息的接口响应时间受到了第三方的限制。
2. 只开发一个接口就能同时兼容不同的第三方发送行为。比如通过一个接口即可处理发邮件、发短信的行为。

解决思路

一般通过第三方发送消息的整体流程是：首先 client 提出发消息的请求，message 服务收到请求后对其进行解析，并判断需将此次消息传输到哪个第三方。然后调用对应的第三方发送接口，由第三方发出消息内容，并等待第三方返回结果后响应客户端。此时接口的响应时间是受到第三方限制的，在这样的情况下，接口很容易超时。

如下图所示：

要解决这个问题，我们需要解耦 message 服务与第三方服务，引入消息中间件的发布订阅模式，即 pub/sub 方式。

引入后的流程是：message 接收到发送的请求，跟前面的做法一样ÿ