上篇 一套亿级用户的IM架构技术干货:整体架构、服务拆分等( 二 )

  • 2)http短连接服务(就是最常用的http rest接口那些,也就是本文中的“IM业务系统”) 。
  • 通俗一点,也也就现在的IM系统,通常都是长、短连接配合一起实现的 。
    上篇 一套亿级用户的IM架构技术干货:整体架构、服务拆分等

    文章插图
     
    比如论坛里很多热门技术方案都是这样来做的,比如最典型的这两篇:《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”?》、《IM消息送达保证机制实现(二):保证离线消息的可靠投递》,文记里提到的“推”其实就是走的“长连接”、“拉”就上指的http短连接 。
    对于socket长连接服务就没什么好说,就是大家最常理解的那样 。
    IM业务系统详细来说,就是专注处理IM相关的业务逻辑,比如:
    • 1)维护用户数据:用户基本信息等;
    • 2)维护好友关系:好友请求、好友列表、好友信息等;
    • 3)维护群组信息:群创建、解散、成员管理等;
    • 4)提供数据:离线拉取、历史记录同步;
    • 5)其它逻辑:比如通过存储和推送系统,存储消息和发送通知;
    按照微服务的原则,IM业务系统也被分拆为多个服务,比如:
    • 1)GInfo服务:群组信息维护;
    • 2)IM服务:处理1V1消息;
    • 3)GIM服务:处理群组消息 。
    7、信令系统7.1 基本情况信令系统主要职责是3部分:
    上篇 一套亿级用户的IM架构技术干货:整体架构、服务拆分等

    文章插图
     


    推荐阅读