IM即时通信选型
1. 需求
服务端开发语言：Java
终端：Android、iOS、Web、小程序
核心需求：发送文字、图片、文件、语音、视频、消息缓存、消息存储、消息未读、已读、撤回，离线消息、历史消息、单聊、群聊，多端同步，以及其他一些需求。
用户管理：添加好友、查看好友列表、删除好友、查看好友信息、创建群聊、加入群聊、查看群成员信息、退出群聊、修改群昵称、拉人进群、踢人出群、解散群聊、填写群公告、修改群备注以及其他用户相关的需求等。
权限管理： 针对群聊不同用户有不同的权限，比如群主、管理员、普通成员，普通成员可以发送消息、撤回消息、删除消息、修改消息、查看消息等，管理员可以管理群成员，修改群昵称、拉人进群、踢人出群、解散群聊、填写群公告、修改群备注等。
2. 原有方案评估
2.1 webrtc即时通信
优点：
- 实时性强：WebRTC 的设计初衷就是为实时通信提供低延迟的解决方案，适合需要快速响应的应用场景。
- P2P通信：WebRTC 支持点对点（P2P）通信，这可以减少延迟和服务器压力，适用于小规模的直接通信场景。
- 跨平台支持：WebRTC 在现代浏览器中原生支持，适用于多平台的应用开发。 缺点
- 复杂性：WebRTC 需要处理信令（比如通过 WebSocket 或其他方式），而且连接的建立和维护（如 NAT 穿透、ICE 候选等）较为复杂。
- 消息持久化和历史记录：IM 通常需要消息持久化和历史记录功能，而 WebRTC 本身不具备这些功能，需要额外的服务器支持。
- 扩展性问题：WebRTC 的 P2P 特性使其更适合于小规模的通信，如果用户量大或者需要支持大规模群聊，P2P 方式的扩展性会受到限制。
- 服务器压力：虽然 P2P 减少了服务器的带宽负担，但信令服务器和消息的中转（在一些情况下）仍然需要服务器支持，尤其是当点对点连接不可用时。
总结
WebRTC 可以用于即时通信，但它的优缺点使其更适合特定的场景。例如，如果你需要实现一个注重实时性的小规模视频通话或音频通话的应用， WebRTC 是一个很好的选择。但如果要构建一个大规模的、需要强大消息持久化和历史记录支持的 IM 应用，那么传统的基于 WebSocket更加适合。
远程会诊的通信技术使用的是WebRTC技术SFU架构，聊天功能模块是基于WebSocket的通信，WebRTC的优势是音视频通信，其即时聊天的多方建立连接需要依赖于信令服务器。 原有方案业务代码和会诊业务耦合度高，im通信不是其核心功能，很多功能需要从头实现，改造成本较大。
3. IM通信的难点
3.1 消息传递可靠性问题
离线消息需要被可靠地存储在服务器端，可能涉及大规模的数据存储需求。如何在不影响系统性能的情况下高效存储和检索离线消息？ 用户从离线到在线的状态切换时，如何处理未同步的离线消息与新接收的实时消息，并确保两者的有序合并？
3.2 消息重复问题
由于网络的不可靠性，如果在如上图的环节5(ack)丢包，则会出现服务端认为消息发送成功，但是客户端认为消息发送失败的问题。当客户端重试后，如果不进行处理， 则会在数据库出现2条相同的消息。
3.3 消息时序问题
IM类系统中，都需要考虑消息时序问题，如果后发送的消息先显示，可能严重扰乱聊天消息所要表达的意义。
消息时序是分布式系统架构设计中非常难的问题，一个分布式的IM系统必须要解决这个问题。
IM系统中主要有两类消息 （1）单聊消息，两个人之间的聊天。需要确保发送方和接收方消息时序展示一致。 （2）群聊消息，一群人在一起聊天。需要确保所有接收方消息顺序一致。
一、为什么会出现时序问题 1、时间不一致。 IM系统存在大量的客户端、IM服务器集群、长连接接入层集群、短连接接入层集群、数据库集群，这些应用分布在不同的机器上，时间很可能 不一致，时区也可能不一致。
2、网络传输 网络传输延迟不同。同一用户后发送的消息可能早与先发送的消息到达服务器；不同用户的发送的消息到达服务器的延时差异可能更大。如下 图，msg1先发送，msg2后发送。由于网络原因，可能msg2先到达消息服务器
3、服务集群时差 由于IM服务器分布式部署，不同的消息可能路由到不同的逻辑层处理。路由到不同logic的时延不同（尤其是跨机房），且不同logic之间存 在微量时差。
4、消息处理速度不一致 服务器收到消息后，不同logic，不同线程对消息的处理速度可能不同，导致投递消息的时序出现错乱。
3.4 音视频QoS问题
网络抖动、视频延迟、丢包问题... 当同时有多路音视频通话时，如何节流，如何保证通话质量，一般云服务器的出站（上行）带宽价格是非常高昂的。
跨网络如何保证质量？ M应用需要在不同的网络环境下（如Wi-Fi、4G/5G、宽带等）保持一致的服务质量，这需要解决不同网络类型的QoS兼容问题。
3.5 消息推送问题
可靠的推送机制：在移动设备上，确保应用能够在后台接收消息，并及时推送通知给用户，即使应用未启动或网络不佳。 推送服务选择：根据不同平台（如Android、iOS）选择合适的推送服务，如Firebase Cloud Messaging（FCM）、APNs等，并确保推送消息的延迟和成功率。 推送策略优化：在推送大量消息时，设计合理的推送策略，避免过度消耗设备电量或造成用户干扰，同时提供灵活的推送设置供用户选择。
3.6 技术栈问题
音视频通话都是基于C语言或者C++开发的，超出了java技术范围。 
4. 技术选型目标
1）业务目标：满足需求分析篇章中的各类需求场景；
2）技术目标：支持扩容，前期最大要能支持万级别用户同时在线聊天；
3）架构目标：高性能、高可用、可监控、可预警、可伸缩，支持扩展。
4）价格目标：免费开源或一次买断源码，再做二次开发
4. 候选方案
4.1 uni-im
4.1.1 简介
地址：https://doc.dcloud.net.cn/uniCloud/uni-im.html
uni-im是云端一体的、全平台的、免费的、开源即时通讯系统。
- 基于uni-app，App、小程序、web全端兼容
- 基于uniCloud，前后端都使用js开发
- 基于uni-push2，专业稳定的全端推送系统
- 基于uni-id，完善的账户体系
- 支持服务端为非uniCloud（比如：应用服务端的开发语言是php、java、go、.net、python、c#等）或 不基于uni-id-pages 开发的项目接入
4.1.2 优势
- 比较详细的文档支持
- 前端工作量大大减少
- 全端可用
- App端支持nvue，更好的长列表性能。list组件性能优势详情参考
- 中心化响应式数据管理，切换会话无需重新加载数据，更流畅的体验
- App端聚合多个手机厂商推送通道，app不在线也可以收到消息
4.1.3 劣势
- 服务收费，且价格不便宜
- 无法私有化部署
CDN流量、出网流量、存储费用比较贵
4.1.4 费用
按量计费：
- 调用10000次云函数0.0133元
- 调用10000次数据库查询仅0.015元
私聊一次： 1次云函数请求、2次数据库读操作、2次数据库写操作、1次uni-push2推送操作，即 (1 * 0.0133 + 2 * 0.015 + 2 * 0.05 + 1 * 0.0283)/10000 ≈ 0.000017元
500人的群聊：1次云函数请求、4次数据库读操作、2次数据库写操作、1次uni-push2推送操作，即 (1 * 0.0133 + 4 * 0.015 + 2 * 0.05 + 1 * 0.0283)/10000 ≈ 0.000020元
| 资源分类 | 资源细项 | 售价（元） |
|---|---|---|
| 云函数 | 资源使用量（GBs） | 0.000110592 |
| 调用次数（万次） | 0.0133 | |
| 出网流量（GB） | 0.8 | |
| 云数据库 | 容量（GB/天） | 0.07 |
| 读操作使用量（万RU） | 0.015 | |
| 写操作使用量（万RU） | 0.05 | |
| 云存储 | 容量（GB/天） | 0.0043 |
| 下载操作次数（万次） | 0.01 | |
| 上传操作次数（万次） | 0.01 | |
| CDN 流量（GB） | 0.18 | |
| 前端网站托管 | 容量（GB/天） | 0.0043 |
| 流量（GB） | 0.18 |
套餐计费：
| 资源分类 | 资源细项 | 免费版 | 基础版 | 标准版 | 专业版 | 企业版 | 旗舰版 |
|---|---|---|---|---|---|---|---|
| 云函数 | 资源使用量（GBs/月） | 1000 | 1万 | 20万 | 40万 | 150万 | 400万 |
| 调用次数（万次/月） | 1.5 | 15 | 300 | 600 | 2400 | 6000 | |
| 出网流量（GB/月） | 1 | 1 | 20 | 40 | 160 | 500 | |
| 云数据库 | 容量（GB） | 2 | 2 | 3 | 5 | 10 | 10 |
| 读操作使用量（万RU/天） | 0.05 | 5 | 25 | 50 | 150 | 500 | |
| 写操作使用量（万WU/天） | 0.03 | 3 | 15 | 30 | 100 | 300 | |
| 集合数量 | 100 | 100 | 100 | 100 | 100 | 100 | |
| 索引数量 | 400 | 400 | 400 | 400 | 400 | 400 | |
| 云存储 | 容量（GB） | 5 | 8 | 10 | 50 | 100 | 500 |
| 下载操作次数（万次/月） | 0.2 | 10 | 200 | 750 | 1500 | 3750 | |
| 上传操作次数（万次/月） | 0.1 | 5 | 100 | 300 | 600 | 1500 | |
| CDN流量（GB/月） | 1 | 2 | 10 | 50 | 150 | 500 | |
| 前端网页托管 | 容量（GB） | 5 | 8 | 10 | 50 | 100 | 500 |
| CDN流量（GB/月） | 1 | 2 | 10 | 50 | 150 | 500 | |
| 售价（元/月） | 免费 | 5 | 24 | 82 | 316 | 688 | |
名词解释：
| 资源分类 | 资源细项 | 说明 | 数据更新延迟时间 |
|---|---|---|---|
| 云函数 | 资源使用量（GBs） | 资源使用量GBs = 函数配置内存GB × 运行计费时长s。 例如，配置为256MB的函数，单次运行了1760ms，计费时长为1760ms，则单次运行的资源使用量为(256 / 1024) × (1760 / 1000) = 0.44GBs | 20分钟 |
| 调用次数 | - | 20分钟 | |
| 出网流量（GB） | 在云函数中访问外网时产生的出网流量，包含请求三方服务器发送的数据和返回给客户端的数据。 | 20分钟 | |
| 云数据库 | 容量（GB） | - | 1小时 |
| 读操作使用量（RU） | 读操作使用量（Read Unit）= ceil(查询数据量KB / 4)，即从数据表中读取一条4 KB数据（向上取整）计作1RU，例如读取7.6 KB的数据计作2RU。 | 20分钟 | |
| 写操作使用量（WU） | 写操作使用量（Write Unit）= ceil(写入数据量KB / 1)，即向数据表中写入一条1 KB数据（向上取整）计作1WU，例如写入1.8 KB的数据计作2WU。 | 20分钟 | |
| 云存储 | 容量（GB） | - | 6小时 |
| 下载操作次数 | 通过CDN加速访问的次数，回源次数暂不收费。 | 6小时 | |
| 上传操作次数 | - | 6小时 | |
| CDN 流量（GB） | 通过CDN加速产生的流量，回源流量暂不收费。 | 6小时 | |
| 前端网站托管 | 容量（GB） | - | 6小时 |
| CDN 流量（GB） | 通过CDN加速产生的流量，回源流量暂不收费。 | 6小时 |
4.2 J-IM
GIT地址：https://gitee.com/xchao/j-im
4.2.1 简介
J-IM 是用JAVA语言开发的轻量、高性能、单机支持几十万至百万在线用户IM，主要目标降低即时通讯门槛，快速打造低成本接入在线IM系统，通过极简洁的消息格式就可以实现多端不同协议间的消息发送如内置(Http、Websocket、Tcp自定义IM协议)等，并提供通过http协议的api接口进行消息发送无需关心接收端属于什么协议，一个消息格式搞定一切！
4.2.2 特性
1、高性能(单机可支持几十万至百万人同时在线) 2、轻量、可扩展性极强 3、支持集群多机部署 4、支持SSL/TLS加密传输 5、消息格式极其简洁(JSON) 6、一端口支持可插拔多种协议(Socket自定义IM协议、Websocket、Http),各协议可分别独立部署。 7、内置消息持久化(离线、历史、漫游)，保证消息可靠性，高性能存储 8、各种丰富的API接口。 9、零成本部署，一键启动。
4.2.3 劣势
- 项目不活跃长期不更新
- 没有完善的文档支持，官网打不开
4.3 cim
GIT地址: https://gitee.com/farsunset/cim
4.3.1 简介
CIM是一套完善的消息推送框架，可应用于信令推送，即时聊天，移动设备指令推送等领域。开发者可沉浸于业务开发，不用关心消息通道长连接、消息编解码协议等繁杂处理。
CIM采用业内主流开源技术构建，易于扩展和使用，并完美支持集群部署支持海量链接，目前支持websocket，android，ios，桌面应用，系统应用等多端接入持,可应用于移动应用，物联网，智能家居，嵌入式开发，桌面应用，WEB应用即时消服务。
4.3.2 优势
- 维护时间比较长，10年了 ，目前还在活跃提交代码
- 提供多个客户端SDK（android/.net/fluttter/ios/swift/uniapp/web）
- 有web/vue/android的demo，有后台管理
- 文档详细
4.3.3 劣势
- 按照平台SDK收费，uni-app（h5,android,ios）
4.4 V-IM
GIT地址:https://gitee.com/alyouge/V-IM
4.4.1 简介
开源与企业版功能点对比 
企业版优势
多终端支持：PC(windows、linux、mac、web) 手机（安卓、IOS、H5、小程序）； 上传支持两种方案(直接存服务器和minio)； 私有云代码仓库永久更新，无加密部分，不依赖第三方。 一对一技术支持。 bug修复优先级最高。 支持付费定制化需求。 功能更新频率高。 聊天记录存储在mongoDB； 支持国产化部署，服务端已对接到snowy开源项目（分支版本）。
4.4.2 企业版收费情况
2980元，交付源码
4.4.3 劣势
- 文档不够详细
- git不活跃
4.5 MobileIMSDK
GIT地址：https://gitee.com/jackjiang/MobileIMSDK
4.5.1 简介
历经10年、久经考验； 超轻量级、高度提炼，lib包50KB以内； 精心封装，一套API同时支持UDP、TCP、WebSocket三种协议（可能是全网唯一开源的）； 客户端支持iOS、Android、标准Java、H5(暂未开源)、微信小程序(暂未开源)、Uniap(暂未开源)； 服务端基于Netty，性能卓越、易于扩展 new； 可与姊妹工程 MobileIMSDK-Web 无缝互通实现网页端聊天或推送等； 可应用于跨设备、跨网络的聊天APP、企业OA、消息推送等各种场景。
4.5.2 优势
- 轻量级，可支持多端多协议，可扩展性极强
- 有自己的论坛，社区活跃，有开发者提供支持，作者响应及时
- 文档详细，收费版提供详细的代码注释
- 覆盖所有平台，所有平台客户端都提供源码，若需要定制可参考他的源码
4.5.3 劣势
- 仅支持单机部署（单机支持10万人同时在线）
- 按照终端收费，安卓/ios/web端分开收费
4.5.4 费用
4.6 野火IM/im-server
GIT地址：https://gitee.com/wfchat/im-server
4.6.1 简介
野火IM是一套通用的即时通讯和实时音视频组件，能够更加容易地赋予客户IM和RTC能力，使客户可以快速的在自有产品上添加聊天和通话功能或者直接使用野火提供的应用。使用野火可以替代云通讯产品或减少自研即时通讯和实时音视频的工作量，降低客户研发成本和难度。
4.6.2 提供产品
- 即时通讯服务(IM Server)
- 应用服务
- 推送服务
- Android 客户端
- iOS 客户端
- PC 客户端
- Web 客户端
- 小程序 Demo
- uni-app Demo
- 机器人服务
- 开发平台
- 频道（公众号）管理系统
- IM 管理后台系统
4.6.3 优势
- 文档齐全
- 支持多端
4.6.4 劣势
- 价格偏贵且后续升级需要付费（原价10% ）
- 购买SDK要绑定IP/域名，无法部署到不同机器
- 只通过github提供技术支持，响应会很慢
- 即使付费购买，产品的功能库也是闭源的，不提供源码，只提供demo源码
4.6.4 体验
4.6.5 收费
5. 总结
大厂的im比如腾讯im，都是卖服务卖套餐收费高昂，包括uniapp也是，所以不考虑。 其他都是提供SDK，基于SDK进行业务开发，SDK提供的功能差不多， 其中MobileIMSDK的资料最详细， 支持所有平台的部署，可单机10万人同时在线，10万人对我们业务来说绰绰有余了。另外MobileIMSDK有自己的社区，他的的文档是 最详细的，从社区数据来看作者比较活跃，能及时响应。 综合从费用、开发成本、文档支持、社区支持几个维度来看，MobileIMSDK比较适合。