默认
开启辅助访问
发表评论 7
即时通讯网»社区 › 综合互动区 › 自由讨论 › 求助多个APP想提炼通用的IM服务端，有什么好的方案建议 ...
想开发IM：买成品怕坑？租第3方怕贵？找开源自已撸？尽量别走弯路了... 找站长给点建议
推荐 方案：MobileIMSDK框架、RainbowChat产品、RainbowChat-Web产品 / 签到领积分！ / 官方技术交流群：185926912
求助多个APP想提炼通用的IM服务端，有什么好的方案建议？
阅读（46706） | 评论（7） 收藏 淘帖1 赞
ykpeng Lv.1 4 年前 | 只看该作者 倒序浏览 |阅读模式
之前公司就一个IM产品。 现在 扩张，做新的APP，有IM的，也有手游的。  然后都需要IM。 为了降低成本。想要做通用的IM。求方案。

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

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


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

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

即时通讯网 - 即时通讯开发者社区！ 来源： - 即时通讯开发者社区！

标签:IM开发 IM架构设计 IM开发咨询 求助
上一篇：求助IM中，协议设计时，如何更优雅的区分单聊、群聊消息？▪下一篇：Soul客户端自研IM -网络处理篇

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

相关文章
推荐方案
评论 7
2 楼: JackJiang Lv.9 精华之王 白金版主 终身成就 4 年前 | 只看该作者
是的，你这个余额检测、扣费动作，跟钱有关，所以需要很谨慎的实现。

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

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

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

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

评分

1

查看评分
3 楼: ykpeng Lv.1 楼主 4 年前 | 只看该作者
引用：JackJiang 发表于 2020-07-28 15:18
是的，你这个余额检测、扣费动作，跟钱有关，所以需要很谨慎的实现。

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

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

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

我想知道，我两种 方案怎么样。 哪种好点，或者说不可行。 另外，大大有什么好的 方法么
5 楼: JackJiang Lv.9 精华之王 白金版主 终身成就 4 年前 | 只看该作者
引用：ykpeng 发表于 2020-07-28 15:27
我想知道，我两种 方案怎么样。 哪种好点，或者说不可行。 另外，大大有什么好的 方法么

第一种从技术上来说，成本太高了，请求太多。尽量考虑第二种，但需要你根据你的业务场景，深入的理清逻辑，把未来的扩展点都想清楚再动。
6 楼: ykpeng Lv.1 楼主 4 年前 | 只看该作者
引用：JackJiang 发表于 2020-07-28 15:42
第一种从技术上来说，成本太高了，请求太多。尽量考虑第二种，但需要你根据你的业务场景，深入的理清逻辑 ...

顺便问下大大，这个问题这么优化：就是我推送消息，由于网络原因丢了，然后很长一段时间没有新消息来，这个消息 就一直没到，除非出去，重新点进APP。 这中影响实时性，有什么优化方案么？
7 楼: JackJiang Lv.9 精华之王 白金版主 终身成就 4 年前 | 只看该作者
引用：ykpeng 发表于 2020-07-29 16:01
顺便问下大大，这个问题这么优化：就是我推送消息，由于网络原因丢了，然后很长一段时间没有新消息来，这 ...

如果要确切知道推送有没有被收到，那就要加应答机制了，服务端在超时时间后，没有收到客户端应答的话，就再次推。
8 楼: Magicnana Lv.1 4 年前 | 只看该作者
1 单从 IM 角度本身来讲，怎么做都可以的。这里边有个问题，本质上这是一个要不要 类似私有云（中台？）的问题。

如你所说，和钱相关的要不要抽象？ IM 的用户，肯定还有个 User 吧，从此衍生出的授权呢，如果都抽象是不是还得有个后台，管理这些功能？

2 来回四次也不是问题啊，反正都是内网
签名: 。。。。。。
返回列表 发新帖 发表评论
打赏楼主 ×
使用微信打赏！ 使用支付宝打赏！
即时通讯技术的分享和传播需要您的支持，感谢打赏！

返回顶部