全球化的IM产品技术架构调研

原创 吴就业 161 0 2024-02-21

本文为博主原创文章,未经博主允许不得转载。

本文链接:https://wujiuye.com/article/ea799c3ed0ba45f292973bd86f3e6e68

作者:吴就业
链接:https://wujiuye.com/article/ea799c3ed0ba45f292973bd86f3e6e68
来源:吴就业的网络日记
本文为博主原创文章,未经博主允许不得转载。

主要调研学习Slack和WhatsApp这两个产品的全球化架构,单数据中心或是多数据中心,怎样做架构设计,能够解决异地多活和延迟问题。

Slack

产品定位:面向企业,同类产品如:飞书。

这类产品的消息是会持久存储,并支持搜索。

全球架构

参考几篇文章:

猜测:

  1. 数据中心在单一的一个区域,单元化在单一区域实现(多AZ),类比:同城多活。
  2. 每个区域一个边缘机房,实现用户就近接入,并在边缘区域做一些数据缓存。

一个大致的整体架构:

whiteboard_exported_image

  1. 事件不需要存储,走ws连接发送
  2. 消息需要存储,走api发送

消息

WebApp: 提供Webapp API 来发送消息,会存储消息并将消息推送给AS。

AS:AS 查看此消息中的通道 ID,通过一致的哈希环发现 CS,并将消息路由到托管此通道的实时消息传递的相应 CS。

CS: 当 CS 收到该频道的消息时,它会将消息发送给世界各地订阅该频道的每个 GS。

GS: 每个收到该消息的 GS 都会将其发送到订阅该通道 ID 的每个已连接客户端。

Flannel:缓存客户端启动数据,如用户、频道、机器人等的相关数据,提供查询 API 供客户端根据需要获取。

事件

事件,例如成员加入频道、对方输入中。

客户端:客户端通过websocket 将此消息发送给 GS

GS:GS 查看消息中的通道 ID,并根据一致的哈希环路由到相应的 CS。

CS:CS 发送给世界各地订阅该频道的所有 GS。

GS:向订阅此频道的所有用户websockets 广播事件。

单元化

参考文章:https://mp.weixin.qq.com/s/lKPoy1o0-PRKdtb_UHgibw

概念:

一个工作区只在一个特定的数据库分片、搜索服务分片、数据库分片上。

分片,其实跟阿里云的单元化架构中的“单元”是一个概念,只是用词不同。

whiteboard_exported_image (1)

跨组织(工作区)沟通,如何分发和存储消息?

whiteboard_exported_image (2)

WhatsApp

产品定位:面向C端,同类产品如:微信。也提供像企业微信一样的产品或者能力?

这类产品的消息通常只要确定接收端接收后就会删除,持久存储在客户端实现,客户端删除了消息就不存在了。

架构

参考:

youtube视频:https://www.youtube.com/watch?v=RjQjbJ2UJDg

公众号文章:https://mp.weixin.qq.com/s/q1dE8xFRL5rTvfDITB6DYQ

参考文章《Whatsapp 系统架构》和视频《WhatsApp System Design | FB Messenger System Design | System Design Interview Question》,Whatsapp的架构可能如下:

单聊架构

whiteboard_exported_image (3)

UserService提供用户相关的API,读取用户库。

用户与WebSocketHandler服务创建websocket长连接,用于消息通讯。

WebSocketHandler可无限横向扩展,并且可能位于不同区域机房中。

WebSocketHandler会在进程内维持一份userid->ws连接的缓存,同时也会写到redis,供其它websocket查询。

用户发送消息,WebSocketHandler将消息发给MessageService,以便赞存消息。(直到消息已读才会删除)

用户发送媒体消息:

  1. 先调用assets service上传文件。
  2. 将文件的hash和媒体类型包装成消息发送到WebSocketHandler。
  3. 剩下的跟普通消息一样。

群聊架构

whiteboard_exported_image (4)

群聊有单独的群聊服务,并且独立的群数据库。

消息发送:

  1. 用户a在群x里面发送一条消息到WebSocketHandler。
  2. WebSocketHandler将消息转发给Message Service。
  3. Message Service将消息存入DB,然后往kafka发送:用户a在群x发送消息xxx。
  4. 群聊服务(GroupService)订阅kafka,然后消费消息,将消息推给GroupMessageHandler。
  5. GroupMessageHandler调用GroupService api查询群x的所有用户的id,然后查询redis,获取在线用户连接的WebSocketHandler。(只需要推给在线用户)
  6. WebSocketHandler将消息推给客户端。

全球架构

未找到相关资料。。。

#中间件

声明:公众号、CSDN、掘金的曾用名:“Java艺术”,因此您可能看到一些早期的文章的图片有“Java艺术”的水印。

访客 2024-03-19

老板666啊

文章推荐

复盘我从0开发文件上传中间件,上线一年多遇到的疑难杂症

难题一:上传MFS文件MD5不一致;难题二:疑是go-ceph导致的内存泄漏;难题三:ceph文件首次下载慢。

文件上传ceph首次下载耗时慢问题排查

据业务反馈,AI生成图片上传后,首次立即下载耗时可能需要几秒,且出现概率极大,很容易复现。如果是上传后,过个几秒后再下载,耗时则只需要几百毫秒。

中间件服务上线,那跟电影里的拆炸弹一样刺激

而针对这种大迭代的发版,根本原因还是要解决灰度粒度问题,支持流量粒度,支持全链路的灰度。

Go语言内存泄漏问题排查实战-记一次线上容器重启问题排查

代码中,与tls有关的地方就是发送https请求从s3下载文件,所以检查下载文件调用链路上是否存在可疑的内存泄漏,发现如下疑点。统计了访问日记,发现确实经常出现响应403。所以问题就清晰了,由于403是有body的,没有close响应的body导致的内存泄漏。

Java内存GC故障问题排查实战-推送系统频繁GC告警问题排查

记录一次工作中实战的Java内存泄漏问题排查,Pod重启后无法查看现场,但通过gc日记可以确认存在内存泄露,并通过运行一段时间发现有个Java类的实例数量非常高。

cpu负载高故障排查实战-网关故障导致业务请求堆积

因为go标准库实现tls握手性能比较差,在一台8核的机器,只能到达2000这个量级,所以当到达某个临界点的时候,握手占用CPU过高,反过头来影响正常的业务请求,导致了业务请求处理变得十分慢。