现代 IM 系统中的消息系统架构—架构篇.docxVIP

现代 IM 系统中的消息系统架构—架构篇 IM 全称是『Instant Messaging』，中文名是即时通讯。在这个高度信息化的移动互联网时代，生活中 IM 类产品已经成为必备品，比较出名的如钉钉、微信、QQ 等以 IM 为核心功能的产品。当然目前微信已经成长为一个生态型产品，但其核心功能还是 IM。还有一些非以 IM 系统为核心的应用，最典型的如一些在线玩耍、社交应用，IM 也是其重要的功能模块。可以说，IM 系统已经是任何一个带有社交属性的应用需要具备的基础功能，网络上对于这类系统的设计与实现的争辩也越来越多。 IM 系统在互联网初期即存在，其基础技术架构在这十几年的进展中更新迭代多次，从晚期的 CS、P2P 架构，到现在后台已经演化为一个简单的分布式系统，涉及移动端、网络通信、协议、平安、存储和搜索等技术的方方面面。IM 系统中最核心的部分是消息系统，消息系统中最核心的功能是消息的同步、存储和检索： 消息的同步：将消息完整的、快速的从发送方传递到接收方，就是消息的同步。消息同步系统最重要的衡量目标就是消息传递的实时性、完整性以及能支撑的消息规模。从功能上来说，一般至少要支持在线和离线推送，高级的 IM 系统还支持『多端同步』。 消息的存储：消息存储即消息的长久化保存，传统消息系统通常只能支持消息在接收端的本地存储，数据基本不具备牢靠性。现代消息系统能支持消息在服务端的在线存储，功能上对应的就是『消息漫游』，消息漫游的好处是可以实现账号在任意端登陆查看全部历史消息。 消息的检索：消息一般是文本，所以支持全文检索也是必备的力量之一。传统消息系统通常来说也是只能支持消息的本地检索，基于本地存储的消息数据来构建。而现在消息系统在能支持消息的在线存储后，也具备了消息的『在线检索』力量。 本篇文章内容次要涉及 IM 系统中的消息系统架构，会引见一种基于阿里云表格存储 Tablestore 的 Timeline 模型构建的消息系统。基于 Tablestore Timeline 构建的现代消息系统，能够同时支持消息系统的众多高级特性，包括『多端同步』、『消息漫游』和『在线检索』。在功能和规模上，能够做到全量消息云端存储和索引，百万 TPS 写入以及毫秒级延迟的消息同步和检索力量。 之后我们会连续发表两篇文章，来更具体引见 Tablestore Timeline 模型概念及使用： 模型篇：具体引见 Tablestore Timeline 模型的基本概念和基础数据结构，并结合 IM 系统进行基本的建模。 实现篇：会基于 Tablestore Timeline 实现一个具备『多端同步』、『消息漫游』和『在线检索』这些高级功能的简易 IM 系统，并共享我们的源代码。 传统架构 vs 现代架构 传统架构下，消息是先同步后存储。对于在线的用户，消息会直接实时同步到在线的接收方，消息同步成功后，并不会在服务端长久化。而对于离线的用户或者消息无法实时同步成功时，消息会长久化到离线库，当接收方重新连接后，会从离线库拉取全部未读消息。当离线库中的消息成功同步到接收方后，消息会从离线库中删除。传统的消息系统，服务端的次要工作是维护发送方和接收方的连接形态，并供应在线消息同步和离线消息缓存的力量，保证消息肯定能够从发送方传递到接收方。服务端不会对消息进行长久化，所以也无法支持消息漫游。消息的长久化存储及索引同样只能在接收端本地实现，数据牢靠性极低。 现代架构下，消息是先存储后同步。先存储后同步的好处是，假如接收方确认接收到了消息，那这条消息肯定是已经在云端保存了。并且消息会有两个库来保存，一个是消息存储库，用于全量保存全部会话的消息，次要用于支持消息漫游。另一个是消息同步库，次要用于接收方的多端同步。消息从发送方发出后，经过服务端转发，服务端会先将消息保存到消息存储库，后保存到消息同步库。完成消息的长久化保存后，对于在线的接收方，会直接选择在线推送。但在线推送并不是一个必需路径，只是一个更优的消息传递路径。对于在线推送失败或者离线的接收方，会有另外一个统一的消息同步方式。接收方会自动的向服务端拉取全部未同步消息，但接收方何时来同步以及会在哪些端来同步消息对服务端来说是未知的，所以要求服务端必需保存全部需要同步到接收方的消息，这是消息同步库的次要作用。对于新的同步设备，会有消息漫游的需求，这是消息存储库的次要作用，在消息存储库中，可以拉取任意会话的全量历史消息。消息检索的实现依靠于对消息存储库内消息的索引，通常是一个近实时（NRT，near real time）的索引构建过程，这个索引同样是在线的。 以上就是传统架构和现代架构的一个简约的对比，现代架构上整个消息的同步、存储和索引流程，并没有变简单太多。现代架构的实现本质上是把传统架构内本地存储和索引都搬到云上