通用接口开放平台设计与实现——(7)消息服务框架设计

消息服务的组成划分

对于消息通知的处理,我们设计的是发布-订阅者模式,消息中心在消息的生产者和消费者之间充当经纪人角色,负责二者的解耦,对于生产者来说,不需要知道会被哪些消费者消费,对于消费者来说,也不需要知道消息是怎么产生的,由消息中心进行逻辑处理和调度,包括消息的解析、复制、转发等。

消息服务实际是一个独立的系统,性质上又分为两类,一类是消息服务端,我们称之为消息服务中心;另外一类是消息客户端,并且这个消息客户端,有可能是消息的生产者,也可能是消息的消费者,甚至是两种角色兼而有之。

注意,实际应用中,客户端和服务端分属于不同系统,独立部署的。
甚至于,只要约定好通信协议和消息格式,我们用java技术栈实现消息服务端,而客户端可以自由使用任意技术栈,如.net。

这里我们假设客户端也是采用java技术栈实现的,并且希望将其封装为sdk,内部技术细节如心跳、重发、去重、自动重连等内置实现,将来把SDK提供给对接系统,便于他们直接进行业务逻辑开发。

服务端与客户端通过消息进行数据交换,都使用netty组件,因此不可避免的会有较多的公用类,如消息和事件的实体类、枚举类型、公共消息处理器、工具类等,因此提取公共部分,形成一个单独工程,来实现复用的目的。

最终,我们的消息服务组成如下:
platform-cip-common:公共基础
platform-cip-message:基于netty的web socket服务端提供消息服务
cip-client:消息

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

学海无涯,行者无疆

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值