美文网首页系统架构
消息系统设计

消息系统设计

作者: loloxiaoz | 来源:发表于2018-06-03 13:27 被阅读325次

消息推送和聊天功能是移动时代的重要功能,广泛存在于各种业务中

一、特性

  1. 消息推送(单播、组播、广播);
  2. 聊天(聊天室、单聊);
  3. 业务低成本接入;
  4. 用户数据反馈和统计,需要辅助业务去做精准营销;
  5. 业务定制扩展,插件机制,如上行聊天敏感词过滤等;
  6. 性能(推送能力&实时性)、可靠性;
  7. 数据安全;
  8. 协议,兼容更多设备。

二、对比

场景
对比 消息推送服务 聊天服务
使用场景 移动端推送 IM聊天、社交
面向对象 设备 用户、账号
消息对象 App 运营人员或者 App Server 向用户推送 用户之间互相交流
发送方式 支持广播、多播、单播 单聊、群群
协议
Protocol XMPP MQTT
优点 组件成熟,成本低 3.1版本,协议轻量级,最小消息头仅有2字节,省流量,专门为IOT设计的弱网弱设备协议
缺点 协议冗杂,耗流量耗电 缺点是组件不够成熟,开发略复杂

三、设计

整体上,系统用etcd做服务发现和配置加载(本地配置做etcd容灾),并结合etcd做微服务的rpc通用架构(技术沉淀),接入层、用户逻辑层、状态存储层,三层之间弱耦合,层内水平扩展,接入层和业务逻辑层弱状态,状态存储层分布式状态保证状态可用,同时为了可用性保证,考虑在状态存储层遇到宕机情况,当前已接入设备的恢复过程。为了调试、 调优、追查的效率考虑,基础框架嵌入trace机制

接入层:

包括dispatcher服务和access服务:
dispatcher模块的主要功能是给client提供接入点,根据一定的调度策略,达到负载 均衡的作用。dispatcher的调度策略 dispatcher需要能够通过分配算法的合理分配给client的access地址。dispatcher根据用户 的信息以及etcd中的上报的access信息综合选择。
access模块负责client的接入,client直接和access建立连接。

  1. dispatcher:
    a) 介绍:根据用户的ip、位置、设备属性、网络运营商, 给其分配access服务器,用户sdk后续连接到分配到的access进行服务。
    b) 调度算法:
    输入1:用户的ip、位置、设备属性、网络运营商
    输入2:根据topic在access中的分布,和用户订阅的topic来动态调整
    分配算法:位置第一、运营商第二、topic参与调整(topic的user在access中分布不能太散,也不能太集中(阈值))
  2. access:
    a)接入用户端,与sdk直接通信,兼容多协议,向后端业务逻辑层传递归一 化后的协议数据
    b)核心功能点:
    i. 接入客户端,兼容客户端协议mqtt
    ii. 注册etcd,并从etcd拉取配置(兼容本地配置做etcd容灾)
    iii. 数据安全,加密解密
    iv. 维持长连接,心跳逻辑
    v. 与status服务配合,维护设备(用户)的上下线状态和分布,并维护心跳,同时进行断网恢复
    vi. 与task服务配合,按照task服务寻址指定进行消息推送,并接受到达ack逻辑,和点击ack逻辑
    vii. 与logic服务配合,按照logic服务的寻址指定进行消息下发,并接收到达ack逻辑
    viii. 接收用户的loginwithtoken请求,赋予上行权限,并后续进行上行消息的向logic服务转发
业务逻辑层:

包括task服务和logic服务:

  1. task服务:
    a) 介绍:用于推送服务,接收业务方推送请求,并寻址到对应用户, 进行转发和存储
    b) 核心功能点:
    i. 接收推送请求,根据推送目标(单播、组播、广播),到status服务中寻找这些用户在access上分布,批量发往access服务消息进行推送
    ii. 组播部分,可以是一批eid,也可以是tag,也可以是用户定义的条件,进行解析,并发送给access
    iii. 对于批量推送任务,生成task_id,时刻维护task_id状态(完成与否,完成
    量),向业务反馈
    iv. Task_id与推送到达率等相结合,供效果查询点击率等
    v. 根据status服务做分发寻址
    vi. 配合msg_server做离线消息存储和消息备份(备份可以用来做retain msg)
  2. logic服务:
    a) 介绍:用于聊天服务,做中间的路由寻址和存储转发。同时维护用户订阅等逻辑处理(不限于聊天服务,包括推送,因为接入层不做逻辑处理)
    b) 下行消息(topic下发),类似于如上task服务,不同点在于上行消息的处理
    c) 上行消息,需要调用自定义插件(如违禁词过滤、消息复制通知mq等)
状态存储层:

状态存储模块维护各个topic和长连接状态关系,和维持长连接心跳信息。
包括msg服务、status服务、user cluster服务:

  1. msg:
    a) 介绍:存储用户离线消息,存储topic retain消息。
  2. status:
    a) 存储用户eid->access_server的映射关系,考虑到同一个eid会看多个topic,所以需要中间多一层映射,即为:eid->conn_id, connid->access_server
    b) 用户上下线,需要修改eid->access的映射和状态
    c) 接收access转发来的心跳包,并结合超时机制,修改eid->access的映射和状态
    d) 接收logic服务转发来的订阅请求,存储eid到topic_ids的映射关系
    e) 如断网重连等情况,需要维护同一个eid不能出现在两个access上的逻辑,需要主动对access服务发送清理命令
  3. user cluster:
    a) 维护业务自定义tag(cache),底层还是放到es中
    b) 根据用户自定义查询条件,到es中进行检索,返回eids,并缓存

相关文章

  • 消息系统设计

    消息推送和聊天功能是移动时代的重要功能,广泛存在于各种业务中 一、特性 消息推送(单播、组播、广播); 聊天(聊天...

  • 消息系统设计

    最近需要做到关于消息的功能,参考着博客写下自己的一点感悟(读后感),参考博客链接。 消息分为两大类:私信和公告/提...

  • Salesforce 消息设计指南-1:Lightning Me

    消息设计概述 闪电消息传递框架是 Salesforce 生态系统中消息传递模式的设计指南。有效的消息传递灌输对系统...

  • Apache kafka实战一 认识Kafka

    1,消息引擎系统 1)Kafka是消息引擎系统,两个重要因素: 消息设计、传输协议设计。2)Kafka消息是结构化...

  • 消息系统的设计

    消息系统的

  • 消息系统的设计

    背景 在一个系统中,资源,数据会持续不断的更新。而用户如果需要知道这些数据的更新,就需要一个系统,将系统中不断更新...

  • 消息系统设计与实现「下篇」

    关联文章:消息系统设计与实现「上篇」 模型设计 Notify Save Remind消息表,我们需要target、...

  • cc消息流设计

    消息流设计 1. 简介 消息系统也可称为队列消费系统,主要是将业务操作以消息的形式转发给服务端(消息系统),服务端...

  • 产品 | 消息通知系统设计

    网站的消息通知系统设计漫谈 一、通知的本质功能 网站把某些对用户有价值的信息及时告知用户。 比如常见的SNS关系中...

  • 如何设计消息通知系统

    消息通知系统设计注意事项 总结一下我在设计消息通知系统时候,遇到的难点与考虑到的问题,供大家参考,如有疏漏,还请多...

网友评论

    本文标题:消息系统设计

    本文链接:https://www.haomeiwen.com/subject/iaptdftx.html