Slack实时消息处理架构，更新、更快、更稳定

Slack 最近公布了它们是如何实现在全球范围内每天发送数百万条实时消息的。该公司提供了对其Pub/Sub架构的全面讲解，这个架构的设计目标就是管理大规模的实时消息。它强调了在不同时区和地区发送实时消息的独特挑战，以及 Slack 的工程师如何设计基础设施来处理这些挑战的。

Slack 的高级软件工程师Sameera Thangudu阐述了这种架构的重要性：

我们的服务器要为每台主机上的数千万个通道以及数千万个连接的客户端提供服务，我们的系统要在 500 毫秒内将消息传递到世界各地。凭借当前架构的线性可扩展性，我们可以为更多客户提供服务。

她表示，该公司会加强其架构，以服务更多的客户群。

该系统的后端由多个服务组成。通道服务器（Channel Server，CS）是有状态的内存服务器，持有通道的历史。这里会有一个一致性散列机制将每个 CS 映射到通道的一个子集中。在峰值时期，每个主机大约为 1600 万个通道提供服务。一致性哈希环管理器（consistent hash ring manager，CHARM）会管理 CS 的一致性哈希环，确保在 20 秒内替换掉不健康的 CS。Consul 会存储一致性哈希值的最新配置。

图片来源：https://slack.engineering/real-time-messaging/

网关服务器（Gateway Server，GS），与 CS 类似，是有状态的内存服务器。它们维护用户信息和 WebSocket 通道订阅，并作为 Slack 客户端和 CS 之间的接口。GS 会被部署到多个地理区域，以优化连接速度。管理服务器（Admin Server，AS）是无状态的内存服务器，它们是 Webapp 后端和 CS 之间的接口。最后，状态服务器（Presence Server，PS）会跟踪在线用户，支撑 Slack 客户端的绿色状态点（green presence dot）。

每个 Slack 客户端有一个到 Slack 服务器的持久性 WebSocket 连接，以接收实时事件来维护其状态。客户端需要通过几个步骤来搭建 WebSocket 连接，比如从 Webapp 后端获取用户令牌和 WebSocket 连接的设置信息。然后，客户端会初始化一个 WebSocket 连接到最近的边缘区域，GS 获取用户信息并向客户端发送第一条消息。Envoy会平衡传入的流量并处理 TLS 终止。

客户端设置完成后，在通道中发送的每条消息都会广播至通道中所有在线的客户端。消息在发送至全球范围的每个订阅的 GS 之前，要经过 Webapp API、AS 和 CS。每个收到消息的 GS 都会将消息发送至订阅该通道 ID 的客户端。

除了聊天消息，实时改变客户端状态的另一种消息类型是事件。瞬时事件，比如用户在通道中进行输入，会遵循一个略有差异的流程，因为数据库不会持久化保存这些事件。下图说明了这个流程。

原文链接：

Real-Time Messaging Architecture at Slack