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

文档地址： https://turms-im.github.io/docs/

我目前积极维护了 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 阅读。

另外：

1. 可能会有人来挑战这个标题“全球开源圈内最先进的 IM 项目”，Turms 用文档+代码服人，有不服 IM 项目可以 Battle Battle 。
2. 感谢下 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 进行二次开发。

#业务功能相关特性

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

#通用架构特性

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

#其他特性

1. 重视可观测性体系建设（详细文档：Turms 可观测性体系 open in new window）。具体而言包括以下三个维度：

   • 日志（针对事件）：共提供了三大类日志：监控日志、业务日志、统计日志
   • 度量（针对可聚合数据）。包括实时的系统运行状态信息，以及实时的业务数据
   • 链路追踪

   补充：Turms 服务端自身会在实现高效的前提下尽可能提供更多监控数据，但不提供一些尽管常见但对性能影响较大，且更适合第三方服务实现的功能（如：日活）。对于这类拓展功能，您可以通过对 Turms 的日志与度量数据进行离线或实时分析来实现该类功能。

2. 运作极为高效。

   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 服务端各功能模块充分利用本地内存缓存