JamesChen

国内大部分的开源项目太没想象力了（电商、博客、刷题），真是给国内教育洗脑洗傻了。OP 要做的话，就要结合自己兴趣爱好来做，不然坚持不下来。
我读大学的时候学日语，于是就做了一个兼有日语背单词、语法、刷 JLPT （ N1~N5 ）考题的 APP ，前后端都做，后来这 APP 太侵权了，听说被抓的话，就要吊销 JLPT 证书，就没继续做下去。
后来我学乐器，又想在 Web 端搞个通过 MIDI 键盘的输入，以如图（ https://www.reddit.com/r/piano/comments/fsqyte/i_made_a_piano_visualizer_free_to_download/）形式展示，并自动生成对应的 ABC notation 形式（一种可以显示成五线谱的文本，并且这文本 /五线谱可以放到 Markdown 里）。当然，这个我还没做，已经有开源项目要维护，就没精力再开一个了。

实在对啥都没兴趣，不如刷题。

op“家产 1500+W ，复旦毕业”，如#39 说的，“追求个姑娘都再三犹豫，缩头缩脚的”。
国男能不能别那么羞涩？自己没那脸皮，不敢上，就不要怪是所谓的“客观原因”：“自己匹配不上”，多多检讨自己的主观原因，你交女性朋友都直奔结婚去的？交个朋友总行吧。建议交几个混夜店的朋友，让他们带你见识下夜生活，或者抽空学学 PUA 技巧，不要把男女交往想得那么保守+矜持，心态放开

看到“代码开源，自架免费”，有点感慨。国内这环境，这话可不太可信，算是一句空头支票。国内有很多“半”开源项目了，社区版做了一个垃圾出来，几个月更新一次，更到后面就不更了，然后就靠卖商业版赚服务费 /咨询费。看到这类项目，我一般称之为“屎壳郎”，见面就直接 diss 。虽然 op 可能没这么想，但是国内大环境就是如此，你要别人怎么信任你呢？你今天可能没这么想，那以后要是赚大钱了呢？国内的开源项目能有 1/10 讲信用 /良心，就已经算“重大突破”了。
国内大环境都已经这么乌烟瘴气，那些愿意投钱的老哥也真是善良。

已点赞支持。程序员这圈子，其实有两条很清晰的路，一条刷流量，一条靠实力做内容，技术公众号 /开源项目就是很好的例子，要是想靠实力做内容，心态要尽量放平，不要跨路子跟别人搞流量的比。大家其实都是明眼人，看看内容 /看看代码，很容易就知道你是混内容的，还是混流量的。
长期做内容，一方面实力很重要，需要长时间沉淀，尽管这种教程播放量低，但别人知道你牛皮，不过我觉得这路子也不好混，好的技术教程太多了，我经常上 B 站看各种大学课，播放量能超 1W 的寥寥无几。要么就搞快餐，忽悠路过的小白，当然这跟程序员其实没啥关系了。另一方面，还是上面说的，心态要放平，不然做的心累，还不长久。

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

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

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

首先，感谢下各位 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 这项目中，能发明这些算法 /设计的才是真大佬。

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

@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 管理系统，用来做后台管理的。