关于后端:微服务架构下消息服务多通道设计思路

6次阅读

共计 1629 个字符，预计需要花费 5 分钟才能阅读完成。

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

发送音讯接口响应工夫太长。当 mesage 服务接管到发送音讯申请后，能够做到实时向第三方进行发送，但第三方的音讯返回工夫不可管制。即发送音讯的接口响应工夫受到了第三方的限度。
只开发一个接口就能同时兼容不同的第三方发送行为。比方通过一个接口即可解决发邮件、发短信的行为。

个别通过第三方发送音讯的整体流程是：首先 client 提出发消息的申请，message 服务收到申请后对其进行解析，并判断需将此次音讯传输到哪个第三方。而后调用对应的第三方发送接口，由第三方收回音讯内容，并期待第三方返回后果后响应客户端。此时接口的响应工夫是受到第三方限度的，在这样的状况下，接口很容易超时。

如下图所示：

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

引入后的流程是：message 接管到发送的申请，跟后面的做法一样，也须要解析发送到哪些第三方。但与后面不同的是，咱们不立刻调用第三方，而是依据解析到的第三方，公布事件到不同的 topic。比方音讯须要发送 email 和 sms，就发往 email 和 sms 的 topic，message 服务再订阅对应的 topic。当对应的 topic 有新的事件时，即调用对应的第三方发送音讯的接口。

如下图所示：

一般来说，对于同一个事件，一个程序仅能作为一个角色，即事件的发布者或者事件订阅者。而依照下面的业务剖析，message 既是事件的发布者，又是事件的订阅者，从服务的架构上来看，这是耦合的。所以，须要再拆分出两个服务，专门来做邮件（emial）的发送和短信（sms）的发送，作为音讯的订阅者。其次要的工作，是监听对应的 topic，响应 topic 事件，触发对应的业务行为。

当有新的第三方发送音讯申请接入零碎，咱们只须要减少一个服务，专门解决新的第三方业务逻辑，而不须要批改之前的业务代码逻辑。

对于消息中间件的抉择，RabbitMQ、Kafka、Redis 等等都是能够的。不过以上模式也有有余的中央，在公布和订阅的服务中，不仅须要引入消息中间件的 sdk，解决跟中间件相干的逻辑，还须要保障音讯的可靠性传递。然而，业务并不关怀消息中间件相干的内容。

基于此，咱们能够引入 Dapr。Dapr 对相似像 Kafka、Redis 以及各大云厂商的中间件进行了整合，简化了在不同消息中间件间进行切换所需的操作。咱们只须要在配置文件中，重新配置消息中间件的相干信息，就能实现灵便的切换到不同的中间件，无需批改代码。除此之外，在服务中引入 Dapr 公布 / 订阅还具备以下劣势：

对立的音讯格局：Cloud Events
反对音讯过期工夫（per message TTL）
at-least-once 提供至多一次的保障

如果音讯组件原生反对音讯有效期，runtime 会间接转发 TTL 相干操作，过期的行为则由组件间接管制。对于那些不反对音讯有效期的组件，Dapr 会在 runtime 中补齐相干的过期性能。(CloudEvent 里有 expiration)

对于 message 服务来说，如果是实时发送，接口因第三方接口的限度，比拟容易超时。个别都采纳消息中间件 pub/sub 的形式，解耦 mesage 服务和第三方服务。同时，中间件音讯的可靠性也十分重要，Dapr 能把音讯至多一次的发送到音讯队列中，保障了音讯的可靠性。所以，如果不想通过在业务代码引入音讯两头的 sdk 来解决音讯的可靠性，那么能够把保护消息中间件的工作，交给 Dapr 去做，此时业务代码也能够更重视业务自身。