[手动推广] IM 开源圈子太黑，自荐下 Turms 这一全球开源圈内最先进的 IM 项目

Gayhub 地址： https://github.com/turms-im/turms

我目前积极维护了 Turms 这项目快 3 年，对 stars 的态度比较佛系，原本是想等 v1.0 做完再发的，但看同 IM 开源圈的一些老哥太“黑”了，开源了 IM 系统的 1%功能就敢刷上千 stars ，当专家了。我日语 N1 水平（最高级），我也知道我日语水平真就是个菜鸡水平，别人说我“日语牛皮”，我心里都很清楚自己到底几斤几两，哪敢给别人辅导日语。打开这些 IM 开源项目的源码一看——触目惊心，让我真切地相信了一些程序员真得需要有“中年危机”。看着一些低质量的 IM 开源项目占据的最多的流量，看着一批批老哥被带到坑里。电影不看演技看流量，一堆路人被坑，真演员无人问津，这谁顶得住。国内一些真心维护过开源项目的朋友估计也有很深切的感受。

Turms 一方面有非常详尽的设计文档（见上面的 Link ）与实现，涵盖了诸如可观察性体系、敏感词过滤、防刷限流、全局黑名单等等体系建设，不是说用户 A 能把用户 /群 B 发消息就能叫 IM 系统的，这可能只是 IM 系统的 1%功能。只要你能想到的 Turms 基本都有文档 /代码，如果 Turms 不支持，Turms 文档中通常也会明确告诉你为什么 Turms 不做这些功能。相信大家都看过不少技术公众号，很多技术公众号喜欢纸上谈兵，极少有能真把技术讲好的，并且理论毕竟是理论，实践很可能是另外一回事。全球范围内目前还没有 Turms 这种能 Hold 住架构设计 /文档 /代码的 IM 项目。

如果各位对各种架构、技术实现细节（如实用但网上没什么人能讲好的敏感词过滤实现）感兴趣，我也知无不言（ PS：我也不是全知全能，大伙见谅），保证大家也能学到一些书本上+公众号+IM 课程上学不到的知识，互利双赢，就算各位大佬不搞 IM ，也能从中受益。综上，欢迎各位走过路过的大哥大佬，赏个脸，点个 star ，大家互相学习。

下文是简介：大佬们要有兴趣，也可以进上面的 Link 阅读。

另外：

可能会有人来挑战这个标题“全球开源圈内最先进的 IM 项目”，Turms 用文档+代码服人，有不服 IM 项目可以 Battle Battle 。
感谢下 V2EX 给我们这些默默无闻的码农提供了作品分享的平台

Turms 基于读扩散消息模型进行架构设计，对业务数据变化感知同时支持推模式、拉模式与推拉模式（详细文档：Turms 业务数据变化感知 open in new window），其他大部分的设计细节也源自商用即时通讯项目。并且相比很多技术栈落后的开源项目或闭源商用项目，Turms 解决方案也是全球即时通讯开源领域内唯一一个基于现代化架构与现代化工程技术，并且适合中大规模部署的解决方案。

另外，架构设计是权衡的艺术，部分 IM 产品以功能丰富为口号，但功能丰富的代价就是只适用于小体量的用户规模（如企业内部通讯）。而 Turms 以极限性能为第一要义，同时支持完整的（而非丰富的） IM 业务功能，以支持中大规模即时通讯场景。具体原因可查阅Turms 集合设计 open in new window以及Turms 可观测性体系 open in new window相关文档。

当您需要将 Turms 与其他开源 IM 项目做具体特性的比对时，您可以先照着 Turms 下述的特性与其他开源 IM 项目进行比对。通常情况下，您能通过这样的比对，发现专业 IM 项目与业余 IM 项目之间的区别。另外，在产品对比章节下，我们也提到了 Turms 项目的缺点供您参考。

注意：当前 Turms 项目的主要缺点是不对直播 /聊天室业务场景提供支持。直播 /聊天室业务场景的技术实现并不难，但其产品需求、质量属性要求与约束性条件与一般的社交场景存在着较大差异，故 Turms 第一版设计不对其提供支持；另外，Turms 也不太适用于小规模的企业通讯场景，用 Turms 往企业通讯场景上套就有点“杀鸡用牛刀”，因为企业通讯更强调功能丰富而非极限性能，与 Turms 的目标不符，所以二者的上层设计也不同。如果希望支持企业通讯场景，您还需要对 Turms 进行二次开发。

#业务功能相关特性

（业务功能完善性） Turms 支持几乎所有商用即时通讯产品所支持的即时通讯相关功能 open in new window（甚至还有更多的业务功能），且无业务功能限制。比如 Turms 支持敏感词过滤（基于双数组 Trie 的 AC 自动机算法实现）等高级 IM 功能。（数据分析与挖掘功能会在之后发布 turms-data 的时候提供，具体细节可查阅 Turms 数据分析 open in new window）
（功能拓展性） Turms 同时支持两种拓展模式：配置参数与开发插件。当然您也完全可以对源码进行修改。目前用于接入的 MinIO 对象存储服务的插件 turms-plugin-minio 就是基于 turms-plugin 实现的。
（配置灵活性） Turms 提供了上百个配置参数供用户定制，以满足各种需求。并且大部分配置都可以在集群运作时（不需要停机），进行集群级别的同步更新，并且无性能损失。

#通用架构特性

（敏捷性）支持在用户无感知的情况下，对 Turms 服务端进行停机更新，为快速迭代提供可能
（可伸缩性）无状态架构，Turms 集群支持弹性扩展与异地多活的部署实现，用户可通过 DNS 就近接入
（可部署性）支持容器化部署，方便与云服务对接，以实现全自动化部署与运维。Turms 默认提供了 docker 镜像、docker-compose 脚本、Terraform 模块三套容器化部署方案
（可观测性）具备相对完善的可观测性体系设计，为业务统计与错误排查提供可能
（可拓展性）能同时支持中大型即时通讯场景，即便用户体量由小变大也无需重构（当然，对于大型运用场景还有很多优化的工作需要做，但当前架构不影响后期的无痛升级）
（安全性）提供限流防刷机制与用户 /IP 黑名单机制，以抵御大部分 CC 攻击
（简单性）核心架构“轻量”，方便学习与二次开发（原因请查阅 Turms 架构设计 open in new window）
Turms 使用 MongoDB 分片架构，以支持请求路由（如读写分离），同时也支持跨地域多活部署与数据主主同步，为大规模跨国部署提供实际操作的可能

#其他特性

重视可观测性体系建设（详细文档：Turms 可观测性体系 open in new window）。具体而言包括以下三个维度：
- 日志（针对事件）：共提供了三大类日志：监控日志、业务日志、统计日志
- 度量（针对可聚合数据）。包括实时的系统运行状态信息，以及实时的业务数据
- 链路追踪
补充：Turms 服务端自身会在实现高效的前提下尽可能提供更多监控数据，但不提供一些尽管常见但对性能影响较大，且更适合第三方服务实现的功能（如：日活）。对于这类拓展功能，您可以通过对 Turms 的日志与度量数据进行离线或实时分析来实现该类功能。
运作极为高效。

Turms 服务端在所有业务流程的代码实现上，都对性能有着极致追求，具体请查阅代码实现。
- 网络
  - I/O：Turms 服务端基于响应式编程，Turms 服务端的所有网络请求在底层都是基于 Netty 的异步无阻塞模型实现的（包括数据库调用、Redis 调用、服务发现注册、RPC 等）。因此 Turms 服务端在各个功能模块上都能充分利用硬件资源（而传统服务端不能）
  - 编码：Turms 服务端与 Turms 客户端间的通信数据采用 Protobuf 编码； Turms 服务端之间的 RPC 请求与响应均采用定制化的二进制编码，以保证极致的高效。
- 线程
  - Turms 服务端具有优秀的线程模型，其线程数恒定，与在线用户规模以及请求数无关。由于 Turms 接入层默认线程数与 CPU 数一致，因此 Turms 服务端能充分利用 CPU 缓存，并相比传统服务端，极大地减少了线程上下文切换开销
  - 业务逻辑处理过程中，无同步加锁操作，只有 CAS 操作
- 内存
  - 在划分内存空间时，合理且充分地循环利用堆内存与直接内存
  - Turms 通过重写 MongoDB/Redis 客户端依赖的部分实现，保证了 Turms 服务端中无冗余的内存分配，极大地提高了内存的有效使用率
- 缓存：Turms 服务端各功能模块充分利用本地内存缓存

JamesChen

2021-12-21 19:05:21 +08:00

@oott123 Turms 有对比过各种主流的 IM 解决方案，还算比较详细的，具体见 https://turms-im.github.io/docs/#%E4%BA%A7%E5%93%81%E5%AF%B9%E6%AF%94
。
Tinode 的定位其实和 Rocket Chat 差不多，用 Tinode ，不如考虑 Rocket Chat 。

我这里就在我文档的基础上，总结+补充几个比较重要的点：
1. Tinode 与 Rocket Chat 这类都是很常见的、定位为企业内部通讯的 IM 项目，强调开箱即用，功能五花八门（如音视频会议、文件传输）。而什么功能都支持就必定意味着它必然不高效。我在下面这个文档里论述了为什么“IM 功能丰富是致命的陷阱”，不累述了：
https://turms-im.github.io/docs/for-developers/schema.html#%E5%8A%9F%E8%83%BD%E4%B8%B0%E5%AF%8C%E7%9A%84%E8%87%B4%E5%91%BD%E4%BB%A3%E4%BB%B7
另外，Tinode 适用的用户规模从它文档的第一段就能看出来了：“Persistent storage is any one of RethinkDB, MySQL or MongoDB”。要知道数据库模型决定了上层能高效支持什么业务。Turms 服务端针对数据库做了太多的设计。诸如：Turms 的雪花 ID 算法，并不是常规的雪花 ID ，而是类似于倒序的雪花 ID ，以最终实现数据库自身的负载均衡。如果像 Tinode 这样玩花，啥技术都支持，那就说明它只做了一些最浅显的功能，没做什么优化。这些东西你在其他文章中基本学不到的，都是到实践才会发现的。

2. Turms 的定位和它们很不同，这个就看上面的文档，不累述了。

3. IM 细节大多，如果一个开源 IM 项目不写它的系统是怎么设计的，我基本就不会往里边看了，因为不同业务场景的 IM 系统设计千差万别。不写 IM 系统的设计文档，如同在简历上不写应聘岗位，不写技术栈，全靠面试官猜。细节包括如：系统读扩散、写扩散，有没有做消息 100%必达，如何做的？数据库如何做冷热分离？等等

JamesChen

2021-12-21 19:34:54 +08:00

@teem TIO 这类项目就是项目就是我常说的“做了 IM 系统的 X%功能”就敢自称“系统”了（ PS：没别的意思，我本人很 peace ，这只是就事论事）。
我就随便举几个非常直观的问题：
1. 它如何做限流防刷机制的、有无全局黑名单机制，如何实现增量拉取，实现是否高效？（ Turms 对应的文档： https://v2ex.com/t/823554#reply6 ）
2. 如何做可观察性体系建设，日志 /度量 /链路追踪都如何设计的？还是裸奔？（ Turms 文档： https://turms-im.github.io/docs/for-developers/observability.html#%E5%BA%A6%E9%87%8F ）
3. 集群是如何设计的？ RPC 是如何实现的？（ Turms 文档： https://turms-im.github.io/docs/for-developers/cluster.html#%E7%BA%AF%E8%87%AA%E7%A0%94%E7%9A%84%E5%8E%9F%E5%9B%A0 ）
4. 数据库是如何做数据冷热分离的？（ Turms 文档： https://turms-im.github.io/docs/for-developers/schema.html#%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90%E4%B8%8E%E9%9B%86%E5%90%88%E7%BB%93%E6%9E%84%E8%AE%BE%E8%AE%A1 ）
5. 如何做敏感词过滤的？（ Turms 文档： https://turms-im.github.io/docs/for-developers/anti-spam.html ）。
特别一提，目前为止，全球开源圈内，所有编程语言，没有比 Turms 更优秀的敏感词过滤实现
6. 文档全不全、细不细致。很多 IM 项目不敢写文档，一是能力不够，一些就露馅，二是怕被同行抄。我敢写，一是因为我有绝对实力在，其他 IM 开源项目要水平比我还高，那我真是求之不得，我也想学习下大佬的经验，可惜开源 IM 圈里没有这类项目。

另外，跟我比实际项目的性能优化，它们就还太嫩了。这个 Turms 文档里详细说明 Turms 的各个模块是如何做到极致的性能的。举个最近一个月的例子，Turms 使用自研 Logging 框架，直接将 Java 基础数据写入 DirectByteBuffer ，并直接 Flush 进文件描述符，除非竞品切语言跟我 PK ，在 Java 这圈子没有比我这更快的了。非常多 Java 知名依赖（如 Spring 、Log4j2 ）用内存都是放飞自我，你如果看过它们对内存的使用，那真叫一个触目惊心。也因此 Turms 很多模块都是自研的。

PS：我看代码比我看中文流利，如果有自信的 IM 项目敢直接贴源码，我也可以帮忙 review 下。

JamesChen

2021-12-21 21:35:21 +08:00

@qq316107934 平心而论，确实完成度挺高的，毕竟我默默勤快地做了快 3 年，我自己也盼 v1.0 也盼了 3 年，但真不“敢”发，毕竟还有一些很重要+细节的优化空间。当然，其实使用者可以规避点这些点，只是我个人不搞定这些问题，不愿意发。反正也没人给我发工资，催我 N 季度不发，就给个 Z 绩效，我要做的只是：一直写下去。

关于“全部开源，免费使用所有功能，并且没有任何引流和收费”，首先这是事实，没有任何引流+收费是因为：
1. 我偶尔 diss 部分国人半开源、面向 KPI 开源、开源没创造力（都电商、博客等），一个 gayhub 中文流量榜单基本都是面向个人的小玩具 /资料，“吹”国外开源才是真开源。因此如果我只 diss 别人，自己却不搞个开源，说不过去，哈哈哈哈。（ PS：当然，国内还有很不错的个人发展来的开源项目，如 ant-design-vue 、openresty 等等）

2. 我开源的态度一些人不一样，我最开始写开源就跟一些人打游戏、打篮球一样，我初中开始写代码，写有意思的代码，我就很爽（我高中的时候还写了一个很有创意的马里奥表白游戏，哈哈哈，这是题外话了）。但这只是初衷，在我学了乐器和接受美学学习的时候，我发现我可以借由“开源”这一手段培养我对诸如“自我意识与世俗欲望”的思考，并借由开源本心与世俗欲望这一具体感受，此我更加思考诸如“人活着为什么，人因什么而快乐与幸福”等必须经过自我审视的人生议题，当然也包括培养一些比较显式的能力，如“专注力”、“学会闲暇”，又或者是陪我度过一个又一个漫漫长夜。因此其实这个角度来说，我个人还挺感谢“开源”行为本身的，如果在这过程中别人能从中受益，那又何乐不为。

我试图超越一些世俗的规约，诸如不要动不动就是为了搞钱（不是说搞钱不好，我也像搞钱。但毕竟不能主客颠倒，人得控制钱，而不是钱控制人），因为一些规约并不是我本心，害怕被蒙蔽了双眼而被环境所利用，如果被利用了，人可就活得憋屈，不自在了。尤其是现在资本家与社会意识占据着媒体的话语权，更是要吾日三省吾身。

同样，我认为一些真心喜欢开源的朋友也要有意识地要避免让一些世俗的想法“伪装”成了自己的想法，而忘却自己的初衷，这样的忘却是丢失“自我”，而变成一个木头人，同时也可以借由开源这一体验，思考自我与世俗之间的距离，想清楚点，活得自在些。这是一个很大的话题，也是比较个人的问题，有兴趣可以看看一些我关于人生的思考，哈哈哈：

1. https://github.com/turms-im/turms/issues/862
2. https://github.com/JamesChenX/introspection