切换IM方案以及流程

Aug 31, 2016 · 1 minute read · Comments

切换IM方案以及流程

新版本和旧版本不相互通信，虽然这个逻辑很蛋疼，但最安全。

IM迁移

• 用户迁移，直接从服务器重新生成用户使用。
• 基础消息类型迁移，主要是逻辑迁移，UI不动
• 自定义消息类型迁移，主要是逻辑迁移，UI不动（较为繁琐和复杂，主要是处理各种自定义消息的逻辑） （困难）

预计周期，前端一个周，后端也要大半个周。 风险：自定义消息的处理

本地化数据迁移

本地数据的迁移风险很高。环信是登录后才能查阅本地数据，所以如果到时候环信停了，这个功能就相当于白做了。因为登不上环信，也取不出来本地聊天记录。 * 本地会话转存数据库 * 本地聊天记录转存数据库

预计周期：2-3天。 风险: 环信关闭。

如果新旧版本兼容

两个方案： 1. 环信和百川中间搭建消息路由。（这个逻辑上可以，但实践基本不可能，我们不可能要环信去请求百川服务的…） 2. 新版本同时发送新旧两个消息。（需要新版本同时处理两个消息的收发，会不稳定，主要不稳定体现在环信和百川两个长连接服务会抢夺资源，造成不稳定，开发周期和风险也很高，最蛋疼的是，环信如果被关闭后，这个直接没用了）