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

[JamesChen]

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

[superfatboy]

看完介绍，一句话：太牛逼了！

[NexTooo]

star=学了，谢谢。

[superliwei]

申请撸串！

[JamesChen]

@superliwei 哈哈哈，大兄弟这深圳大冷天的，我回到家都觉得冷。网上激情聊天，有问必答

[oott123]

请问楼主如何评价 Tinode 呢

[JamesChen]

@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%必达，如何做的？数据库如何做冷热分离？等等

[teem]

请问楼主如何评价 TIO 呢

[JamesChen]

@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]

@teem 接着补充一点，比较重要的。除非是很有技术含量+细致的技术实现（如 jctools 的并发数据结构、Netty 的网络实现与内存管理），就是其实自研不管是代码效率上（我们只要定制功能），还是学习难度上都比一般的抽象库优秀，用 TIO 不如直接用 Netty 。在 https://turms-im.github.io/docs/intro/redevelopment.html#%E5%85%B3%E4%BA%8E%E4%BE%9D%E8%B5%96%E5%BA%93%E7%9A%84%E4%BD%BF%E7%94%A8 文章里，我有做具体的论述。
很多抽象库干的只是体力活，这点相信很多程序员都有感觉：面对一个需求，我们的脑力其实更多的是花在我们“有没有必要实现这个功能”，真写代码的时候基本可以不过脑子（就像我现在打字一样，不用准备什么资料、看什么文档。只要手放键盘上，就是一把劲地敲）

[qq316107934]

看完之后起了一个疑问，
一方面：毫无疑问楼主这个项目完成度相当高，甚至让我怀疑项目已经被商用或者背后有一个强大的技术团队支持。
另一方面：楼主全部开源，免费使用所有功能，并且没有任何引流和收费。

听起来这两者是矛盾的啊。

[ufan0]

@JamesChen 请问楼主，该文档的 UI 设计有现成框架可用吗？

[JamesChen]

@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

[JamesChen]

@ufan0 客户端 UI 我没做，也没计划做。
1. 国内外这类比较漂亮的开源 IM UI 项目还有些，你可以搜搜
2. 的设计与实现与具体业务场景、具体的编程语言、具体的技术架构、具体的运行平台都密切相关。而 Turms 引擎一直是致力于高效地满足各种复杂多变的即时通讯业务场景，不希望因为 Demo 限制了开发者的想象力。并且开发与维护 Demo 也非常地费时费力，会拖慢 Turms 项目的开发进度。
3. 我能画 UI ，但我不会设计 UI 呀。专业设计师和我这些设计 UI 极其业余的人相比，我们设计出来的 UI 也是天上地下，我技不如人，就没必要多此一举了，哈哈哈。
如上所述，既然 IM UI 的需求也如此多变，其实 Turms 这类项目更应该让其生态来做，但大公司有号召力能主导开源圈，为其做贡献，Turms 可没有什么生态，哈哈哈。要么自研 UI ，要么基于第三方自研吧。

PS：Turms 项目里带 UI 的只有一个 turms-admin Web 管理系统，用来做后台管理的。

[SuperMild]

@JamesChen 技术与思想的境界都很高，敬佩！

[oott123]

至少从楼主的帖子、文档来看，感觉是挺值得尝试的。

谢谢楼主的回复。

[oott123]

不过楼主的演示站域名好像没备案被拦截了……

[ihipop]

没看代码，光看你介绍的第一感觉，比之前那在 V 站堆反复堆各种语言关键词搞置顶推什么分布式事务的老哥要靠谱

[leipengcheng]

厉害，但是感觉可能没有很大的应用市场？

[NOspy]

我来说点废话：牛掰，加油！
@leipengcheng 其实很多企业都有这个需求。

[TinyKube]

怎么评价由前微信技术专家打造的 OpenIM ，个人用过融云，暂时没尝试过开源 IM

[christopheredwar]

支持！

[JamesChen]

@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：很多学哲学的人也有这毛病，生怕别人看得懂，很喜欢“摔词”

[aceimnorst]

楼主是腾讯的核心开发工程师

[bruce0hh]

还没看项目，看这贴就觉得 op 不是一般人🤣

[ffgrinder]

感谢楼主分享，
所以如果按照您在#6 的回复，企业内部比较合适的 IM 您推荐 Rocket Chat ，对吗？

[keppelfei]

这贴确实有点意思啊，OP 有点屌。
话说回来，国内开源的 IM 框架真的大多数恰烂饭.令人作恶,除了 最近出来的 OpenIM 有点诚意，其余的都是打着开源的幌子恰烂饭。

[xia15]

楼主写的很好，看的出来是个用心的项目

[awalkingman]

哈哈我以前搞过 IM ，还挺感兴趣的，代码先 fork 了一份。就冲楼主开源的出来的行为，献上一个感谢～

[HENQIGUAI]

虽然看不懂但是很厉害，学习 IM 必备项目。收藏了

[madlifer]

祝贺，感觉楼主的思维方式比项目更可贵

[zzq825924]

请注意您的 goole 邮箱，因为 v 站没有私信功能，所以邮件私信了。

[yanbo92]

虽然好多都看懂，但是我去给个 star 支持一下

[googlehub]

太腻害了，值得学习。

[KevinBlandy]

插个眼，有空好好学一学。谢谢楼主的开源。

[991894172]

准备 fork 学习一下

[JamesChen]

首先，感谢下各位 v2exer 的热情，谢谢各位赏脸给 star 。

@aceimnorst 大哥，你这是给我“保送”跳槽了吗？可能认错人了，哈哈哈

@ffgrinder Rocket Chat 适合企业内部通信，但企业内部通信也可以考虑用国内第三方云，一方面更有安全保证；二是企业通信也没什么特殊逻辑，没必要上 Turms 从底层自研。具体还是我在： https://turms-im.github.io/docs/#%E4%BA%A7%E5%93%81%E5%AF%B9%E6%AF%94 写的 IM 方案对比。

@keppelfei 是呀，看得我都不服，哈哈哈

@yanbo92 互相学习。Turms 到底是把各模块融会贯通，写一个比较完整的 IM 系统，而不是孤立的技术文档+口嗨。我在“https://github.com/turms-im/turms/issues/862”写了，Turms 没什么“原创性”，双数组 Trie AC 自动算法、数据库负载均衡 冷热分离也不是我发明的，我只是拾人牙慧，把他们融汇贯通到 Turms 这项目中，能发明这些算法 /设计的才是真大佬。

[Donahue]

虽然看不懂，但是感觉很厉害的样子，star 了~楼主好有耐心，3 年做一件没有短期回报的东西

[NeedforV2]

LZ 这个有些牛 B 了

[JackZhu0Amazing]

楼主很耐心，加油

[love2020]

starred

[akajoker]

楼主的境界我看来一时半会是达不到了，帮忙点个 Star ，希望能让更多的人看到这个项目。

[q474818917]

我看有些语法好像上升到 jdk16 啦

[JamesChen]

@q474818917 是的，因为服务端用 JDK17 写得。

题外话，至于为什么用 JDK17 而不用 JDK11 或 8 ，这个问题的思路其实不太对。应该翻过来，为什么不用 JDK17 ，而用 JDK11 或 8 。其实 Turms 服务端在从 JDK11 升到 17 的时候，什么 BUG 都没遇到，就跟升个 Spring 版本一样简单。Java 自身是一个很保守的语言，它比我们程序员还怕犯错，与将精力花在其担心 Java 会出错，不如担心自己的业务逻辑有没有 BUG 。哈哈哈

[liangtao927190]

楼主厉害，支持一下。

[sawyera]

感觉找到喜欢的东西了，周末仔细学习学习

[omysho]

有个问题想问一下，有无计划支持 E2EE ？

[JamesChen]

@omysho 没计划支持，因为这 feature 做了没什么意义。中国合规的 IM 应用不可能搞加密，有加密需求的群体估计也都上 TG 了，哪方都讨不好，所以完全没相关计划。

[aviator]

对 IM 方向挺感兴趣的，还记得当初毕设就是做的一个简单的 BS 的 IM 项目，希望后面能往这个方向发展下

[ownSun]

老哥加油! 牛

[Slogen]

老哥牛逼了，学习学习

[cedoo22]

最近有 IM 二开项目需求， 了解了一圈，
国内的开源，都是社区版要么核心功能被限制，要么只开源 UI 不开源 SDK ，动不动就要收费。

[kwh]

@JamesChen 这么自信？好，我决定了，争取把你的代码看完，把你的变成我的。

[7897894]

泰酷辣 对于小白来说不能开箱即用很难受，希望有大佬可以基于 Turms 做一个带客户端的出来，我想白嫖😁

[QGabriel]

@JamesChen 能留个联系方式吗