Im

Tinode源码解析

概述 有朋友需要做一个im,简单做了一下技术调研,开源的实现其实蛮多的,这里挑几个说一下: Synapse/dendrite,matrix系,客户端比较多,比较推荐的应该是element.io. 稳定版本是python写的,性能很一般,golang/rust的服务端还没有stable,不建议使用; Tinode/chat: 即本文主角,golang编写,架构比较简单,有MySQL就能跑,轻量级方案。支持web/ios/android,界面长得比较像telegram;支持chatbot. 国内用有点水土不服,主要是推送等组件依赖国外大厂的服务(S3, Firebase等),国内根本连不上,需要自己改成个推之类的方案。由于方案比较轻量,消息可靠性上有一些缺陷,内置了chatbot支持(可以用Python写); Open-IM-Server:据说是某个腾讯核心人员离职后自己开源的。服务端golang,架构基于微服务,有商业产品,自己试了一下目前版本大概有16个微服务,依赖kafka&zk、mysql、etcd、redis、miniIO和MongoDB。架构比较合理,早期是写扩散模型,v2.3之后群聊改为读扩散模型。主要问题是架构比较重,文档写的烂,需要自己分析代码,小团队维护比较吃力;另外客户端开源的只是demo,bug满天飞,不能直接拿来用。 turms-im/turms:java写的,读扩散模型。maintainer比较有自信,号称开源界最先进的方案,文档确实写的不错,很详细的技术分析。不过star数不多,实际使用者估计也寥寥。而且作者喜欢自研,Log/注册中心/配置中心这些都是自研的…有种自嗨过了头的感觉。整体来讲架构比较中庸,技术细节把控的比较好。java团队可以考虑,代码还比较易读,而且没有商业版,作者没有恰饭需求;客户端没有开源产品,只有sdk; wildfirechat/im-server:也是java做的,主要卖商业版,开源的功能做的很全了,和国内生态也结合的蛮好。开源版强行指定了使用七牛云做文件夹存储,然后服务端端口强行指定了80/1883,另外开源版不支持集群模式;国内的小规模内部使用推荐使用该项目(<10w人); Rocket.chat/mattermost:面向B端,类似zulip/Slack这种IM,有复杂B端需求的团队建议优先考虑。界面不太符合普通人使用im(qq/微信/钉钉)的习惯,办公人士用比较合适; 这几个项目是客户端生态做的最好的了,基本能开箱即用。其他一些如goim之类的,没有客户端只有服务器,那还不如用mqtt自己写一个,毕竟有emqx这种高性能broker,写一个im真不算啥难事。聊天存储用influxdb或者MongoDB,元数据存MySQL。设计好推拉模型,读写扩散,消息时序,topic规则,一个基本的im软件还是能很快成型的。
2022-11-14
12分钟阅读时长