- 用户登录（简易未加密）
- 双方简易文本内容聊天
- 联系人列表
- 未读信息数（总未读和会话未读）
- 消息与联系人以及未读数量刷新
该版本采用短轮询，每三秒刷新一次消息与状态信息
- Spring Boot
- JPA
- Redis
- MySQL
- Thymeleaf
- bootstrap
进行中~~
- 实时性，保证消息实时触达
- 可靠性，“不丢消息”和“消息不重复”是系统值得信赖的前置条件
- 一致性，“多用户”“多终端”的一致性体验能大幅提升使用体验
- 安全性，“数据传输安全”“数据存储安全”“消息内容安全”提供全面隐私保护
- 简单、低效的短轮询逐步升级到相对效率可控的长轮询
- HTML5 的出现，全双工的 WebSocket 解决了服务端推送问题
- 同时基于 TCP 长连接衍生的各种有状态的通信协议，也能够实现服务端主动推送
- 业务层的 ACK 确认和重传机制，能解决大部分推送过程中消息丢失的情况
- 通过客户端去重机制，屏蔽重传过程中可能导致消息重复的问题，保证用户体验
- 重传不可达的场景，可通过消息完整性检查利用时间戳比对或全局自增序列实现
- 找到一个时序基准，根据业务特征可选择不同的全局序号生成器，如单调自增资源生成、分布式时间相关 ID 生成
- IM 服务器差异与多线程处理方式，不能保证推到接收方的顺序，可“服务包内整流”保证“严格有序”或接收方根据消息序号本地整流
- 传输安全
- 访问入口安全：HttpDNS 解决路由器被恶意篡改和运营商的 LocalDNS 问题
- TLS 传输层加密协议保证消息传输过程中不被截获、篡改、伪造
- 存储安全
- 密码采用“高强度单向散列算法”和“加盐”机制
- 在政策允许的情况下，服务端尽量不存储消息内容，采用“端到端加密”提供消息传输保护
- 内容安全
- 依托“敏感词库”“图片识别”“OCR 和语音转文字”“外链爬虫抓取分析”等手段，配合“联动惩罚处置”来进行风险识别后置闭环
- 分布式锁，较好普适性，但执行效率较差，锁的管理也比较复杂，适用于小规模即时消息场景
- 支持事务功能的资源，不需要额外维护锁资源，实现较简单，但乐观锁的 watch 机制在较高并发场景下失败率高，执行效率易出现瓶颈
- 原子化嵌入脚本，不需要额外维护锁资源，高并发场景下性能较好，开发需要额外的学习成本
- 心跳机制快速自动识别连接可用，同时避免运营商 NAT 超时断开
- 降低服务端连接维护无效连接的开锁
- 支持客户端快速识别无效连接，自动断线重连
- 连接保活，避免被运营商 NAT 超时断开
- 心跳探测业界采用方式
- TCP KeepAlive。
- 操作系统 TCP/IP 协议栈自带，无需二次开发，使用简单，不携带数据，网络流量消耗少
- 存在灵活性不够和无法判断应用层是否可用的缺陷
- 应用层心跳
- 应用自己实现心跳，需要一定的开发量，网络流量消耗稍多
- 心跳间隔灵活性好，配合智能心跳机制，可做到保证 NAT 不超时情况下最大化节约设备资源消耗
- 更精确反馈应用层的真实可用性
- TCP KeepAlive。
- 多终端漫游实现方式
- 要求在线状态需要支持用户设备维度进行维护
- 要求消息和信令在服务端进行用户维度的离线存储
- 需要“多终端和服务端状态同步机制”保证数据的最终一致性
- 业界常见方案是采用版本号机制根据客户端版本和服务端版本差异，在上线时获取增量消息和信令
- 离线消息存储未命中时，可通过持久化的最近联系人列表和索引表来进行有损的补救
- 离线消息的下推可通过“多条消息打包和压缩”的方式优化线上体验
- 在线状态本地化维护，降低远程资源依赖，提升单机处理能力
- 对服务整体拆分，区分核心和非核心服务，隔离易出瓶颈的服务
- 通过收集业务和机器两类指标，建立容量评估模型，自动进行服务扩缩容
- 根据后端机器负载水平调度全局，接入服务入口，解决扩容后新接入流量在新扩容机器和旧机器间流量不均衡问题
- 流控算法
- 漏桶算法，平滑实际流量速度，让被流控的服务始终按固定速度处理流量
- 令牌桶算法，不精确限制速度，限制请求的平均速度，允许出现一定突发流量请求
- 分布式业务控制全局流量，可通过中央式资源实现，如 Redis + Lua
- 可通过滑动窗口和细粒度分桶解决流量不均衡和边界处理不平滑问题
- 熔断机制快速失败解决突发流量和微服务间复杂依赖导致的雪崩问题
- 通道连不上问题
- 暴露多个业界验证过比较安全的端口，解决连通性问题
- 通过 Http Tunnel 解决某些网络情况下只允许 HTTP 协议数据传输问题
- 通过 HttpDNS 和客户端预埋方式，提供多个可选通道接入点，让某些接入点在连不上时能尝试其他接入点
- 通道连接慢问题
- 支持多运营商机房接入点，避免用户跨运营商访问
- 对于多接入点，客户端可采用“跑马竞速”方式优先使用连接速度最快接入点
- 通道不稳定问题
- 通道层服务与变化频繁的业务解耦，避免业务变动导致通道层服务不稳定
- 消息下行通道压力大的业务场景，可隔离消息上下行通道
- 多媒体的上传下载通道和消息收发的核心通道隔离
- 多上传节点策略，优化上传网络访问，避免用户跨运营商网络带来的高延迟和不稳定
- 优化上传链路，隔离多媒体消息文件上下行通道和普通消息收发通道，尽量缩短用户到文件存储服务的距离，针对语音消息可通过“先行下发”来降低语音聊天延迟
- 采用分片上传机制，并分出合适的分片大小，能较大改善上传成功率和速度，对于上传失败后重试也友好
- 断点续传和秒传功能，解决已上传文件流和片流不再需要重新上传的问题，节约成本，提升体验
- 通过 CDN 加速，让资源离用户更近
- 通过流加密来解决 CDN 上多媒体消息私密性问题
- 为图片提供多种中低分辨率的缩略图来提升图片预览性能
- 使用 WebP 和渐进式 JPEG 来对图片进行压缩，以降低体积，提升加载性能
- 针对热门小视频，采用 H.265 转码，在保证画质的同时，降低带宽成本并加快视频加载
- 通过视频的自动“预加载”，达到视频播放“秒开”的效果
- 借助长连接通道，对体积较小的音频和缩略图进行实时推送，提升用户浏览和播放体验
- iOS 端 APNs
- Android 端 Google 的 GCM 国内不可用，由各手机厂商维护推出 SDK
- 工信部推动“推必达”的统一推送联盟