求助多个APP想提炼通用的IM服务端，有什么好的方案建议？

之前公司就一个IM产品。 现在 扩张，做新的APP，有IM的，也有手游的。  然后都需要IM。 为了降低成本。想要做通用的IM。求方案。

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

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


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

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

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

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

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

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

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

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

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

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