求助多个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
顺便问下大大，这个问题这么优化：就是我推送消息，由于网络原因丢了，然后很长一段时间没有新消息来，这 ...

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

1 单从 IM 角度本身来讲，怎么做都可以的。这里边有个问题，本质上这是一个要不要 类似私有云（中台？）的问题。

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

2 来回四次也不是问题啊，反正都是内网

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

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

大佬，我感觉我现在比较认同你的理解，我司的 IM 基本就处于定制化和业务侵入比较严重的状态，基本导致他的能力基本不能复用。

同样历史团队中也开发过一个通用的长连接服务，包括 基于 netty 的接入层，以及维护用户和 entry ip 地址/群聊关系 缓存信息的 session层，也有上行和下行的消息分发层，例如上行的消息通过 MQ 发送，业务方自己处理后置的业务，包括落库等等，这套系统非常通用，他只关心单发和群发能力，业务协议数据也不会在这一层中关心，业务可以自己定义 IM 协议中包含的业务数据协议。

不过有一个疑惑点想请教一下，因为这个服务只负责处理连接、消息上下行推送等，没有任何业务，所以每一个业务接入都需要重新实现一套库表、逻辑，去处理联系人、历史消息这些数据吗，有同事提问过，有没有可能业务层也在这个通用的 IM 服务实现，而不需要每个业务方接入这个系统都要处理历史消息存储等问题。 或者说我们现有的一些三方产品，他们除了消息收发能力，肯定是有一定的存储能力的，是不是他们这种本身已经不够通用了。

引用：二境志 发表于 2025-02-20 23:51
大佬，我感觉我现在比较认同你的理解，我司的 IM 基本就处于定制化和业务侵入比较严重的状态，基本导致他 ...

如果你的表、逻辑、用户这些，在你们的其它业务里都能共通，仍然可以把共通的部分收敛到im服务里，这是肯定的。