IM技术

呃，最近也是业务繁忙啊，搞了一波IM放到线上去了。在10年经验大佬的指导下，采用的IM通讯方案为：springboot+http+stomp+vue+uniapp来实现了PC端与微信小程序的通讯互通。技术架构选型方面暂未达到分布式集群的模式，仅将内存扩充到16G以及100M带宽就可以解决一家大型企业的通讯问题，因为该功能系统并不是主要的业务线，但是所有的处理流程都离不开互通互讯。
好吧，下面开始拆解IM搭建的流程：

1. 使用规模（吞吐量）+技术选型

怎么说呢，这块的业务线我是真的参与量少得很啊，只能道听途说大致有那么多些量吧。为啥呢，可能我不是决策者吧，仅仅是执行者。我就暂定用了他们给出的参考数据：日常线上10万活跃以下。
选型这块，因为我们整套业务线一开始就是使用了最近国内开发热度最高的springcloud+vue+uniapp体系，所以以效率优先级最高，选型自然是这样子。人员分配的话，最近确实也是很卷啊，我们这里是全员全栈选手。所以想做大型分布式系统，自然也就没啥沾边了，最多很多高级js使用的功能例子会让你去实现出来。我这里简单列举几项：签名技术，远程视频，IM技术等等吧。

2. 初步搭建

这里是指刚刚开始搭建IM前后台系统的时候，大致以下几点注意事项吧：

你使用的协议是否兼容多种情景使用，是否越轻量越好。
沟通情景：是否有点对点，是否有主题等等。
使用仅有一个端使用websocket还是说多端使用，如果多端使用，该怎么保证其协议兼容性。
当websocket配置完成之后，是否有考虑其安全性该怎么处理？是否有上线人数，未读数，历史记录，监控检测等功能情景。
可以搭配的中间件有什么，有什么好处。

大概就先列这些吧，因为并不会开发成像微信这样子功能很多，测试很成熟的产品，但是没有选择第三方通讯工具是因为乙方还有很多需要额外定制化处理的业务。比如在通讯界面加一些属于乙方自己特色业务线的内容，也可能不会让你去做点对点的通讯功能，会让你以他们给出的分组方式去合理分发消息。

3. 功能演进

当你实现了可以基本的沟通之后，你会发现，并不符合乙方给出的场景需求，因此你需要继续改进。比如，显示、隐藏功能，特色业务线开关功能，工作流处理流程等。因此你需要在后台处理好回显到底需要回显哪些真正的数据，是要进行过滤处理之后才可以的。当然，在改善的过程中，你就一点点质疑单体架构是否合理，于是就会引进分布式websocketSession的解决方案，这里并没有使用到它，但是既然已经实现出来了，自然可以先放在后端暂不使用它。再一点你会发现沟通的翻页与正常信息系统的翻页逻辑似乎不太一致，因为它是实时接收对方消息数据以及你自身也可以主动发送消息数据的，所以常规的翻页逻辑是不可行的，需要稍微调整一下。大致先这些吧，时间仓促，优先把文章编辑完再说。