[手动推广] 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-22 07:47:44 +08:00

@oott123 哈哈哈，那是。前一年多都没要求备案，最近 2 、3 个月开始要求备案，但我那域名是"turms.im"，“im”顶级域名国内备不了案，所以就被拦截了。之后我会把我那 demo 网站迁到 AWS ，之所以没马上迁，是 AWS 真的贵，心疼，哈哈哈。

@leipengcheng 开源 IM 领域能打的就 Turms 一款项目，而 IM 领域估计很难凉，IM 服务下能做支持其他业务的基础服务，上能独立做款应用。如果 IM 领域，Turms 凉了也没关系，我回家找块地耕耕。具体而言：
1. IM 系统自身细节繁多，而开发人员水平又参差不齐，很难保证做出来的项目质量如何。实现用户 A 能给用户 B/群 B 发消息最多也只是实现 IM 系统功能的 1%功能，并且这些功能模块不像是一些通用的依赖库可以随意插拔而是要定制实现并环环相扣的，各模块都要自研，需要设计人员与开发人员有很强的功底（若想了解 IM 系统具体有多少细节功能，可以参考 Turms 的文档）
2. 自研 IM 服务的市场需求大。即便现在到各招聘网站查询 IM 工程师相关岗位，也能发现国内外还有大量企业招聘 IM 相关人才，各公司投入上百或千万从零或基于古老的 IM 开源项目自研，重复造 IM 服务，社会资源利用率低

@TinyKube OpenIM 是最近几个月突然火起来的开源 IM 项目，之所以说突然是因为我最早关注它的时候，它才几百个 stars 。OpenIM 是我印象中除 Turms 以外，最专业的开源 IM 项目，但是：
1. 大的通用缺点可以看我在#8 楼的回复，基础模块就做了百分之几的功能，就不要把自己叫做 IM 系统了。人可以是专业的，但做出来的项目不一定是。很多问题是需要沉淀，不要着急为了抄热度，就匆匆忙忙地上了一些功能，到底来就只能重构：具体看③。
2. 它基于写扩散做架构设计，决定了它很多功能都做不了，且实现低效（ Tumrs 基于读扩散），这点相信这位专家心里也很清楚。我在这篇文章里有分析： https://turms-im.github.io/docs/for-developers/status-aware.html#%E8%AF%BB%E6%89%A9%E6%95%A3%E4%B8%8E%E5%86%99%E6%89%A9%E6%95%A3

3. 细节实现天上地下。
诸如我看它文档里提到：“mongodb 存储离线消息，并定时删除 14 天（可自行配置）前数据； mysql 存储全量历史消息以及用户相关资料”。这里它就危险了：
一是：mongodb 默认只存 14 天消息，以为着它甚至很可能连最基本的数据库负载均衡都没做（ Turms 默认就支持数据库负载均衡，并且开发者无需做任何配置）。
二是：它用 mysql 存储全量历史消息就犯了我在②提到的问题，要么它保持原样，功能受限；要么进行技术重构（我也是在 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 中提到的，IM 的表设计中有很多“陷阱”，如果你没想好一个功能的设计，就下手实现。通常，这就意味着：未来要么从数据库层重构，要么保持原样，无法拓展。当然，反正你也可能刷完简历，跳槽跑路了，但这对后来人就惨了，哈哈哈。

对比而言，Turms 已经对 MongoDB 负载均衡与数据的冷热分离（如消息表根据消息记录的创建时间，在数据库负载均衡地分布），而冷数据的备份应该通过类似 AWS Glacier 等专业的存储服务，做 Cold 数据存储（ Turms 目前还没具体设计这个方案，因为还为时过早，另外：哥，你数据都这个规模了，你不给我发发红包？说不过去啊，哈哈哈哈）

4. 架构有点过度设计，需求与架构有点脱节，甚至我有点怀疑是不是在“面向简历编程”。明明关键功能都没实现（看③），如果需求本来就不复杂，那为什么还把架构搞这么复杂？如果需求本来就很复杂，那③的现有设计岂不是得重构？
另外，为什么 Turms 的架构能做的很简单且运维很简单，请看这两篇文章：
1. https://turms-im.github.io/docs/for-developers/architecture.html#%E4%B8%8E%E5%85%B6%E4%BB%96im%E9%A1%B9%E7%9B%AE%E7%9A%84%E6%9E%B6%E6%9E%84%E5%8C%BA%E5%88%AB

2. 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
补充：Turms 在早期也有很多“开发优先”的态度，只要我能写得，都给用户包了（如日志分析、度量分析，后来我把这些功能都删了，真是心态），而没关注一个事实：很多功能其实是应该运维 /大数据来做的。诸如 Kafa 可不可以换成弹性伸缩、各种监控报警分析可不可以换成日监控服务（如 AWS CloudWatch ）。现在我已经想明白了，专业的事情就要专业的服务，没必要自己搞一套，要做的功能就必须要做到极致（即：我这方案，我觉得可以 8/90 分了，你要是能想出一个 100 分的方案，那就是你厉害，但我的方案也算优秀）。
自己搞一大堆技术栈，除了“面向简历编程”，对项目没什么实际好处。PS：很多学哲学的人也有这毛病，生怕别人看得懂，很喜欢“摔词”