求助多个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：

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

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

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

引用：JackJiang 发表于 2020-07-28 15:18
是的，你这个余额检测、扣费动作，跟钱有关，所以需要很谨慎的实现。

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

做了两年了。 是这个意思。  我接入层是ws下发通知，尽量走http。因为是海外的，网络本来稳定度不高。  

引用：JackJiang 发表于 2020-07-28 15:18
是的，你这个余额检测、扣费动作，跟钱有关，所以需要很谨慎的实现。

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

我想知道，我两种 方案怎么样。 哪种好点，或者说不可行。 另外，大大有什么好的 方法么

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

第一种从技术上来说，成本太高了，请求太多。尽量考虑第二种，但需要你根据你的业务场景，深入的理清逻辑，把未来的扩展点都想清楚再动。

引用：JackJiang 发表于 2020-07-28 15:42
第一种从技术上来说，成本太高了，请求太多。尽量考虑第二种，但需要你根据你的业务场景，深入的理清逻辑 ...

顺便问下大大，这个问题这么优化：就是我推送消息，由于网络原因丢了，然后很长一段时间没有新消息来，这个消息 就一直没到，除非出去，重新点进APP。 这中影响实时性，有什么优化方案么？

引用：ykpeng 发表于 2020-07-29 16:01
顺便问下大大，这个问题这么优化：就是我推送消息，由于网络原因丢了，然后很长一段时间没有新消息来，这 ...

如果要确切知道推送有没有被收到，那就要加应答机制了，服务端在超时时间后，没有收到客户端应答的话，就再次推。