kafka，建议换成nats

[Leadrive]

https://github.com/nats-io/nats-streaming-server 供参考。

[tonybase]

可以看公司消息队列进行选择的，其实这里应该做成interface进行init配置会比较合适

[tsingson]

已经试验性作了一个 支持 nats 的 goim , fork 在这里 ~~https://github.com/tsingson/ex-goim~~, 基本测试跑通了.

正在尝试以一个合适的方式与 goim 源进行合并, 当前正在处理 discovery 通用接口, 尝试中

欢迎建议与批评啊.......

祝愉快!

[helloddyl]

已经试验性作了一个 支持 nats 的 goim , fork 在这里 https://github.com/tsingson/ex-goim , 基本测试跑通了.

正在尝试以一个合适的方式与 goim 源进行合并, 当前正在处理 discovery 通用接口, 尝试中

欢迎建议与批评啊.......

祝愉快!

支持,kafka确实不是非常适合go的技术栈

[tsingson]

kafka 很好啊, 商用重器, 成功案例这么多.

[helloddyl]

kafka 很好啊, 商用重器, 成功案例这么多.

恩恩,不过总感觉kafaka部署方式感觉不符合go的哲学,尤其是zookeeper,只是一种芥蒂

[tsingson]

goim 支持 nats 已经处理了预编译的可执行文件(包括依赖 gnatsd / discovery 等, 支持 mac / linux ) , 见https://github.com/tsingson/ex-goim/releases

注: 上面 ex-goim 的 repo 已更换 nats , 加了一些依赖与 Makefile 能顺利跑起来. 个人尝试结束, 我的尝试 repo 暂时冻结.

[tsingson]

有几位朋友私信沟通闲聊, 想要一个同时支持 kafka / nats , 以便能 merge 回这里的主线, 我 fork 了一个 repo 来尝试实现这个想法, 这里 https://github.com/tsingson/goim

计划变更如下:

• [x] 在 internal/logic/conf 与 internal/job/conf 中增加 nats 的连接配置项, 与 选择 kafka ( 默认) 或 nats 的开关配置项
• [x] 把 internal/logic/dao 抽象为 interface , 同时支持 kafka / nats ( 仅是 nats )
• [ ] ~~把 internal/job 中 func (j *Job) Consume() 函数拆分为 func (j *Job) Consume() 支持 kafka / func (j *Job) ConsumeNats() 支持 nats~~
• [x] 把 internal/job 中增加 consume(j *Job) 的 interface 支持 kafka / nats
• [x] 配置文件支持 nats 开关项与连接配置
• [ ] 测试, 测试, 测试

除以上变更外, 所有代码尽量保持不变

以上, 祝愉快.

.

[weisd]

有几位朋友私信沟通闲聊, 想要一个同时支持 kafka / nats , 以便能 merge 回这里的主线, 我 fork 了一个 repo 来尝试实现这个想法, 这里 https://github.com/tsingson/goim

计划变更如下:

• [x] 在 internal/logic/conf 与 internal/job/conf 中增加 nats 的连接配置项, 与 选择 kafka ( 默认) 或 nats 的开关配置项
• [x] 把 internal/logic/dao 抽象为 interface , 同时支持 kafka / nats ( 仅是 nats )
• [ ] 把 internal/job 中 func (j *Job) Consume() 函数拆分为 func (j *Job) Consume() 支持 kafka / func (j *Job) ConsumeNats() 支持 nats
• [x] 把 internal/job 中增加 consume(j *Job) 的 interface 支持 kafka / nats
• [x] 配置文件支持 nats 开关项与连接配置
• [ ] 测试, 测试, 测试

除以上变更外, 所有代码尽量保持不变

以上, 祝愉快.

.

我觉得不用把整个Dao的方法都抽象成接口啊，只处理发消息部分的就行了，加个消息队列还要加redis操作有点多了

[tsingson]

有几位朋友私信沟通闲聊, 想要一个同时支持 kafka / nats , 以便能 merge 回这里的主线, 我 fork 了一个 repo 来尝试实现这个想法, 这里 https://github.com/tsingson/goim 计划变更如下:

• [x] 在 internal/logic/conf 与 internal/job/conf 中增加 nats 的连接配置项, 与 选择 kafka ( 默认) 或 nats 的开关配置项
• [x] 把 internal/logic/dao 抽象为 interface , 同时支持 kafka / nats ( 仅是 nats )
• [ ] 把 internal/job 中 func (j *Job) Consume() 函数拆分为 func (j *Job) Consume() 支持 kafka / func (j *Job) ConsumeNats() 支持 nats
• [x] 把 internal/job 中增加 consume(j *Job) 的 interface 支持 kafka / nats
• [x] 配置文件支持 nats 开关项与连接配置
• [ ] 测试, 测试, 测试

除以上变更外, 所有代码尽量保持不变 以上, 祝愉快. .

我觉得不用把整个Dao的方法都抽象成接口啊，只处理发消息部分的就行了，加个消息队列还要加redis操作有点多了

你说得对, 已经修改完成, 测试中......

nats 与 nats-streaming-server 不同的是, nats 不提供至少一次送达保障-------> 从这点来说, kafka 还是很适合的.

开始时, 用 nats + liftbridge 可以达到至少一次送到的效果, 现在改成只用 nats , 看看是否可以用 NATS Request Reply 方式.

[tsingson]

@weisd 读过你的技术 blog, 哈

[weisd]

@tsingson 哈哈，没看错吧，我的blog一直没坚持下来 https://github.com/weisd/goim 我也写了一个你看看

[tsingson]

@tsingson 哈哈，没看错吧，我的blog一直没坚持下来 https://github.com/weisd/goim 我也写了一个你看看

坚持不坚持不重要, 重点是有想法就写代码或写文章. 作为老司机, 查一下还是知道谁写的.

你代码我看了, 写得比我的漂亮多了, 抽取 brocker interface 写得真好.

[jinleileiking]

Imho. Kafka比nats好

[lchjczw]

为什么没人改成nsq呢？

[lchjczw]

@tsingson 想了下，感觉应该把goim对接的消息系统抽象成接口，整个goim不和消息系统做任何的关联，这样以后就好处理了

[tsingson]

@tsingson 想了下，感觉应该把goim对接的消息系统抽象成接口，整个goim不和消息系统做任何的关联，这样以后就好处理了

https://juejin.im/post/5cbd380c5188250a97133649

好几个朋友都各自改成抽象 interface 接口了.

[tsingson]

@tsingson 能帮我看看是什么原因吗

有更多信息不? 没有具体信息, 不知道如何帮你

[lchjczw]

@tsingson 不好意思没看到消息，解决了,是代码有点问题，我用的修改过的版本，后端用官方的nsq

[lchjczw]

不过goim的文档确实比较少，订阅是怎么订阅的？就是拿来做IM通讯，类似微信，有多个群，这种场景，怎么订阅收消息

[tsingson]

官方 nsq ..........

@lchjczw 看来, 你需要的不仅仅是源码.

[lchjczw]

@tsingson nsq这个我现在已经打包运行，没问题了

[lchjczw]

@tsingson 现在发消息这些也没问题，只是，有点逻辑没搞懂，他这个订阅，没看到api呢，压测里面，都是有个auth token，没看懂这个token格式，貌似就是订阅

[tsingson]

goim 的 issue 成了聊天室了, 也是趣事一件.

[tsingson]

不过goim的文档确实比较少，订阅是怎么订阅的？就是拿来做IM通讯，类似微信，有多个群，这种场景，怎么订阅收消息

goim 的文章已经很多了. 我写了 goim 文章后就有点后悔了, 因为很多文章已经把 goim 说明得很清楚很明白了, 只是有点散, 各人关注点不同(版本也不同) , 也就在自己关注或欣赏的点上写, 有些文章非常非常好. ------> 我有想过在 goim 这个 repo 的 wiki 上把这些文章放进去, 可惜没什么人阅读也没有反馈, 加上有些好文章上有标示版权声明, 就挂着了, 以后再说.

同时 , goim 被 fork 不少, 有相当部分朋友 fork 之后, 对代码修改也不少, 说明在阅读源代码上, 下的功夫不少.

从 goim 询问到的问题来看, 就两大类:

1. 阅读代码过程, 有些没看懂原始设计意图, 或对某些局部代码的使用不太清楚
2. 如何实现一些业务, 包括鉴权认证啦, 消息合并啦, 离线存储或聊天机器人如何写啦, 如何部署及压测啦....

我只能这样建议, 阅读代码, 阅读代码, 阅读代码, 代码说得比较清楚. ( 相比其他 im 开源库, 这是我欣赏 goim 的地方, 代码背后的设计意图一脉相承而又保持足够简单, 让 goim 成为一个优秀的 im 实现code base , 易于扩展/维护/集成...)

很开心的是, 因 goim 认识更多有趣的朋友, 谢谢!

[blusewang]

为什么没人改成nsq呢？

nsq 确是一个装逼神器。它的模块化，尤其是：nsqadmin！ 但nsq太久没人维护了。nsq消费时，一次只能订阅一个话题。这太不像话了。 一个服务进程，要处理100个话题，要弄出100个consumer对象+100个tcp长连接。简直没法用！

[blusewang]

kafka对于小的项目。使起来既别扭又浪费。 它首先不符合go的哲学。启动起来就吃了近500MB内存，这要是集个群.....。感觉跟内存1毛钱1G一样。

[blusewang]

我感觉Apache下的好多项目，要是用go重写一下。将带来及大的经济价值！ 哎！～

[tonybase]

nats好像出2.0了，看着还挺不错的

[blusewang]

nats好像出2.0了，看着还挺不错的

嗯，我感觉，nats是golang里唯一拿得出手的队列了。它缺少像nsqadmin那样便于维护的UI，但订阅起来很灵活。商业业务能力跟kafka比，还是差了一截，处理些廉价的消息数据还行。 而nats官方文档通篇不讲它的架构与实现原理。

[Leadrive]

没想到我抛的砖，引来了不少讨论，特别感谢楼上tsingson, weisd提供的修改。

@blusewang https://github.com/youzan/nsq 可以看下有赞对nsq的改造，改造说明在这里。https://studygolang.com/articles/10724