在企业数字化建设过程中，如何与客户保持线上链接是重要的组成部分。而IM通信系统就属于数字化建设的基础设施。那么，如何实现一个符合企业需求的IM系统呢？采购当然是其中需要考虑的方式之一。但就我个人的经验来看，市面上好的IM厂商很稀少，因为IM厂商需要做标准化产品，所以如果公司的业务并不是传统意义上的社交IM业务。那么IM厂商提供的功能大部分用不到，并且对于群聊，单聊等基础功能还要做二次开发。
今天，我们并不讨论在什么情况下需要采购，什么情况下需要自研，等后面写产品思考类的文章时可以分享这些。现在我们只讨论一个话题，如何设计开发一个属于自己的IM系统？
首先，熟悉业务场景是架构设计的一部分，因为它决定了IM系统的功能范围。我们可以为这个IM定义某个业务场景：
客服网聊场景：
1，如果该用户有专属客服，则和专属客服进行会话 如果专属客服不在线，进入等待队列，等坐席应答；如果该用户为VIP，则可以进入优先级较高的等待队列。否则正常排队；
2，客服可以在线邀请投顾或者其他专家，进入服务客户的三方会话
3，自定义消息卡片：
支持注册绑卡/产品预约；
支持当前业务进度通知：“用户正在填写身份证”，“用户绑卡失败” ，
支持消息优先级，比如“用户支付失败”
支持进入场景提前通知：比如用户从某会议进入，用户从app端会议/直播/交易页面进入
4，超大群聊：可以支持3000人的聊天群（需要设计“读扩散”和“写扩散”问题的解决机制）
结合以上的场景，我们接下来可以定义我们的功能设计：
各业务根据分配到的appid接入IM服务 （前端SDK植入）
支持PC/H5/小程序通过websocket连接,APP通过socket连接
支持单聊/群聊/超大群(3000人)/聊天室
支持文本/图文/音视频/自定义消息
支持离线/历史消息存储
支持单聊转群聊场景
支持可集群部署，gRPC远程调用
应用架构设计：
首先，IM包括最基本的三个功能模块，分别是IM Server负责连接管理，IM Route负责路由管理，以及IM stroage负责消息存储管理。
从前面的场景中，我们也能发现在IM通信过程中，需要考虑两个最重要的ID的设计：用户id，群id。可以说这两个id在消息的分库分表，负载均衡，服务扩容，服务宕机等场景中都会起到很重要的作用。其中，我们考虑两个方面：
A，平衡性：每台服务器均匀处理请求
B，单调性：扩容或者宕机时，部分数据迁移即可
