请选择 进入手机版 | 继续访问电脑版

默认
发表评论 6
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
求助多个APP想提炼通用的IM服务端,有什么好的方案建议?
之前公司就一个IM产品。 现在 扩张,做新的APP,有IM的,也有手游的。  然后都需要IM。 为了降低成本。想要做通用的IM。求方案。

我自己想的方案。
一种:是服务端完全与其他业务服务隔离。专门做IM。跟其他业务服务没有任何调用。
考虑这种场景,付费聊天。APP先去业务服务器检测余额够不够能不能发,能发就然后requst到IM服务上预发,response返回成功后(此时消息对接收方还是不可见),APP再去业务服务器上扣费,服务器返回扣费成功后,app再去IM服务器上告诉刚刚的msgid可见了。(这个时候消息对接受方可见了)。但是这样一来一回的就有4次请求了。业务方两次:检测余额、扣费。IM服务两次:预发,真正发。

另一种:
就是IM和其他业务服务打通的,但是只做IM逻辑,接入层接受到请求后,路由转发给其他APP的业务服务器,这些业务服务器判断是否余额够,不够直接返回。够的话,就调用IM这边服务存储消息(暂时接收方不可见),同时APP业务方去扣费,扣费成功再到IM服务,表明消息应该可见了。


上面说的付费聊天只是一种场景。 当然有更简单的,比如加测是否是好友,然后发消息。不需要后续扣费之类的操作。

你们怎么看。有什么好的方法。

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:求助IM中,协议设计时,如何更优雅的区分单聊、群聊消息?下一篇:Soul客户端自研IM -网络处理篇

本帖已收录至以下技术专辑

推荐方案
评论 6
是的,你这个余额检测、扣费动作,跟钱有关,所以需要很谨慎的实现。

我引导你正确理解一下im:

1)不管你的im如何设计,一定不要把im做重了:也就是能不要im做的尽可能不要im做,比如能用http接口实现的,就不需要动用im的长连接通道。原因是http的实现,无论是高可用、性能负载还是什么,做起来都有标准成熟的方案,比im这种不标准的东西实现起来要简单多了;

2)记住一点:IM永远只是一个实时的消息收、发“通道”:记住,它只是个通道,说白了,谁要发什么消息,收到消息要怎么处理,im只负责调度,具体逻辑由你的别的业务服务去处理。im只需要从你给他的列队中取消息并发给你指定的人,或它从用户实时收到的消息放到队列中(由你业务服务来取并决定怎么后绪处理)。

,你多体会一下我说的。一般im做的比较久了,很容易理解我说的。你如果对im没有太多经验,多理解一下我说的,回头你就会发现,确实该这样,不然越往 后做,你就越没法做,因为im越来越复杂,随之而来的:优化、扩展、重用都是大问题,因为复杂性增加,已经没有改进的空间了,或者说一团乱麻。

评分

1

查看评分

签名: 每天时间都过的好快啊
3 楼: ykpeng Lv.1 楼主 2 个月前 | 显示全部楼层
引用:JackJiang 发表于 2020-07-28 15:18
是的,你这个余额检测、扣费动作,跟钱有关,所以需要很谨慎的实现。

我引导你正确理解一下im:

做了两年了。 是这个意思。  我接入层是ws下发通知,尽量走http。因为是海外的,网络本来稳定度不高。  
4 楼: ykpeng Lv.1 楼主 2 个月前 | 显示全部楼层
引用:JackJiang 发表于 2020-07-28 15:18
是的,你这个余额检测、扣费动作,跟钱有关,所以需要很谨慎的实现。

我引导你正确理解一下im:

我想知道,我两种 方案怎么样。 哪种好点,或者说不可行。 另外,大大有什么好的 方法么
引用:ykpeng 发表于 2020-07-28 15:27
我想知道,我两种 方案怎么样。 哪种好点,或者说不可行。 另外,大大有什么好的 方法么

第一种从技术上来说,成本太高了,请求太多。尽量考虑第二种,但需要你根据你的业务场景,深入的理清逻辑,把未来的扩展点都想清楚再动。
签名: 每天时间都过的好快啊
6 楼: ykpeng Lv.1 楼主 2 个月前 | 显示全部楼层
引用:JackJiang 发表于 2020-07-28 15:42
第一种从技术上来说,成本太高了,请求太多。尽量考虑第二种,但需要你根据你的业务场景,深入的理清逻辑 ...

顺便问下大大,这个问题这么优化:就是我推送消息,由于网络原因丢了,然后很长一段时间没有新消息来,这个消息 就一直没到,除非出去,重新点进APP。 这中影响实时性,有什么优化方案么?
引用:ykpeng 发表于 2020-07-29 16:01
顺便问下大大,这个问题这么优化:就是我推送消息,由于网络原因丢了,然后很长一段时间没有新消息来,这 ...

如果要确切知道推送有没有被收到,那就要加应答机制了,服务端在超时时间后,没有收到客户端应答的话,就再次推。
签名: 每天时间都过的好快啊
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部