消息中心上线了

最新推荐文章于 2024-05-23 10:37:50 发布
原创 最新推荐文章于 2024-05-23 10:37:50 发布 · 2.6k 阅读 · 2 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#服务器 #api #web

    消息中心，方便全站各应用将消息直接推送给用户，特别是一些重要的信息让用户立即知道，如有用户询盘、有人下单等消息直接推送到WEB端和旺旺客户端，让客户能够在第一时间收到这样的消息，立即响应，增加成交的机率；原来是每个应用都去实现一套单独的消息通知程序，浪费人力资源去重复开发，也浪费多余的服务器去实现这些消息的通知与处理，现在通过消息中心，全站各应用只需要将消息调用消息中心提供的API，将消息提交到到消息队列后，自己就不需要再做其它的事情了，以下是一个实现图：

    

本文出自：冯立彬的博客




前端开发实战：从零实现一个消息通知中心 简洁美观的消息通知页面 - 含标记已读与删除功能 Vue.js 消息通知中心：分组与交互功能全解析前端开发实战：从零实现一个消息通知中心 简洁美观的消息通知页面
南北极之间
12-16 1120
前端开发实战：从零实现一个消息通知中心 简洁美观的消息通知页面 - 含标记已读与删除功能 Vue.js 消息通知中心：分组与交互功能全解析前端开发实战：从零实现一个消息通知中心 简洁美观的消息通知页面 - 含标记已读与删除功能 Vue.js 消息通知中心：分组与交互功能全解析前端开发实战：从零实现一个消息通知中心 简洁美观的消息通知页面 - 含标记已读与删除功能 Vue.js 消息通知中心：分组与交互功能全解析前端开发实战：从零实现一个消息通知中心 简洁美观的消息通知页面 - 含标记已读与删除功能 Vue.
业务消息中心系统设计与实现(二)
keepd的博客
07-27 1724
本章节主要内容会讲述一下详细的场景与需求,以及设计的实现方案. 技术的产生源于去解决去问题,所以希望读到这里的小伙伴还是要认真阅读下本章节,详细了解产生这个方案的场景与背景. 先说下消息中心实现前现有的消息样式示例:如图下所示 商城app的 社交app的: 可能小伙伴觉得没啥问题.消息长得还不错,也和各自的业务有关系,那么问题来了 如果现在业务方新的需求来了,说要做一个新的app来聚合出来一些新的组合功能,包括商城订单的消息、社交的消息、甚至一些sms,email消息、i..
消息中心应用实例
12-23
主要使用消息中心进行视图之间的切换，减少视图之间的相互引用，简单代码，方便管理
金蝶BOS8.2 EAS客户端一直初始化解决方案
码艺丫嘿的博客！
06-03 2367
解决方案的客户端启动后,客户端界面一直显示”初始化” 在BOS工作空间工程路径下新建sp文件夹,如在E:\bosworkspace8.2\Project_0\lib 新建sp文件夹 然后将下载的kdupdater.jar包拷贝到E:\bosworkspace8.2\Project_0\lib\sp下,重启BOS工具后再尝试启动登陆客户端。 注意：必须要客户端kdupdater.jar文件 （文件...
Rabbitmq消息中心_消息中心总体方案
it_lihongmin的博客
05-01 6752
消息中心方案 一、消息中心简介 为了将各个应用系统之间进行业务解耦，对业务的透明化处理及技术架构的统一管理，方便对各应用的整体把控，保证系统的稳定性，也方便各应用的消息中间件的快速搭建，因此搭建消息中心，提供整体的解决方案。 相对于传统应用间定时或事件驱动获取数据的方式，使用消息中心让各应用感知其他应用的变动，采用主动推送的方式对数据的变化进行通知。 二、消息中心业务场景 2.1应用系统
添加 成功 提示
qq_26726077的博客
12-08 1642
Dim i As Integer = cmd.ExecuteNonQuery()         If (i > 0) Then             Label8.Text = "设置成功！"         Else             Label8.Text = "设置失败，请重新设置！"         End If
EAS BOS8.2/8.5 BOS提交单据无法进入流程解决方案
weixin_34029949的博客
07-27 610
2019独角兽企业重金招聘Python工程师标准>>> ...
阿里P7的消息中心架构设计笔记
架构师干货
06-28 7316
最近我们在重构消息中心，关于设计上的部分记录一下笔记，希望能够帮助到正在做类似设计的。
消息中间件MQ知识概括
weixin_41005188的博客
02-16 3314
消息中间件MQ知识概括MQ简介JMSMQ协议MQ方案对比 MQ简介 传统的http请求存在那些缺点: Http请求基于请求与响应的模型，在高并发的情况下，客户端发送大量的请求达到 服务器端有可能会导致我们服务器端处理请求堆积。 Tomcat服务器处理每个请求都有自己独立的线程，如果超过最大线程数会将该请求缓存到队列中，如果请求堆积过多的情况下，有可能会导致tomcat服务器崩溃的问题。 所以一般都会在nginx入口实现限流，整合服务保护框架。 http请求处理业务逻辑如果比较耗时的情况下，
消息队列七种经典应用场景
徐本锡的专栏
05-23 1万+
是高并发解决方案三剑客。ActiveMQ 、RabbitMQ 、Kafka 、RocketMQ 这些是知名的消息队列。
通信行业点评报告：5G消息服务在京上线，5G应用发展前景广阔.pdf
07-02
这份通信行业点评报告的中心议题是分析5G消息服务在北京地区的上线情况，及其对整个5G应用市场的影响。5G消息服务的上线，被看作是中国通信行业向5G时代迈进的重要步骤，同时5G消息服务有潜力成为5G技术应用的首个大...
消息中心构架设计说明书(2)[归纳].pdf
10-29
本《消息中心构架设计说明书(2)》主要针对消息中心的架构设计进行深入阐述，旨在为系统的设计、开发和维护提供清晰的指导。文档的目的在于规范消息中心的功能实现，确保系统的稳定性和可扩展性。文档的适用范围包括...
钉钉企业机器人单聊消息发送实践-大数据平台(XSailboat)消息中心消息推送
OkGogooXSailboat的博客
01-22 2064
在笔者开发的中有模块，用来全平台的消息收集，整理分拆、订阅发送等功能。消息推送方式支持钉钉群聊、钉钉单聊、短信通知。现记录一下企业机器人消息单聊推送的实现过程。
java.lang.ClassNotFoundException错误原因汇总
weixin_30606461的博客
09-12 4791
开发java很长时间了，还经常会遇到java.lang.ClassNotFoundException这样的错误，最近又处理了一次，起初怀疑是jdk版本比class文件的编译版本低了导致了，但是运维人员反馈的信息说经过查看这个是没有问题的。结果又反复折腾，最后实际上还是这个问题，只不过之前他确认的有问题。这里在汇总记录一下什么情况会导致这个问题，便于大家参考，不足之处，大家多提意见。 原因...
编译环境与生成环境的JDK版本不一样，报：java.util.zip.ZipException: error in opening zip file
热门推荐
冯立彬的博客
09-13 8万+
发布应用的时候，发现生产环境报将编译环境编译好的WAR包拿到生产环境，报异常如下：     Caused by: java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.(ZipFile.j
一个简单的EJB-Session Bean实例
冯立彬的博客
08-02 1万+
 一个简单的EJB-Session Bean实例       从现在开始，我也要开始学习EJB了，原来虽然有所了解，一直还没有动手操作过，现在的项目时间不紧，可以好好学习一下。具体的概念什么的我这里就不多说，因为我想如果你需要知道的话，我说还说不全，你不如去网上搜搜，多得很。       我用的开发IDE是Jdeveloper10.1.3，个人觉得这个东西非常的好使，并不比那些诸如MyEc
采用Jetty搭建简单的WebApplicationServer
冯立彬的博客
08-22 1万+
采用Jetty搭建简单的WebApplicationServer   一、基本设置 希望采用Web的方式，远程对服务的配置进行管理，考虑到Jetty作为Web容器是纯JAVA写的，并且能够很好的与JAVA应用程序集成在一起使用，于是就采用它了。下面是对搭建Jetty应用的记录过程。 当前的Jetty版本为：jetty-6.1.14，在Eclipse新建一个工程名为Test，并新建包：tes
初识iBATIS
冯立彬的博客
08-02 8123
 初识iBATIS现在最新的版本是（2007-8-2）2.3.0，也是第一个没有加入JAVA DAO（Data Access Object）框架的版本，在前面的版本中都加入有DAO，其目的在于推荐用户使用Spring框架。前面学了一下Hibernate，不过，没有学习多久，我就被它的复杂性以及这样那样的弯来弯去给吓回来了，太复杂了，真不知道那些写这样框架的人是怎么样想的，有没有担心过用
JDom结合XPath的查找一列
冯立彬的博客
07-01 7638
XML使用XPath的查询，就像我们平常操作数据库一样，根据某一关键字，然后取出关键字所对应的记录，然后再取出其对应的属性值。如果想更详细了解JDom中XPath的使用，请参阅文章：http://blog.youkuaiyun.com/fenglibing/archive/2007/07/01/1674201.aspximport java.io.FileInputStream;import java.uti
消息中心采用统分模式建设
最新发布
07-14
<think>我们正在设计一个消息中心的统分模式架构。统分模式通常指在分布式系统中，既要有统一的控制中心（统），又要允许分布式部署和处理（分），以实现系统的可扩展性、高可用性和灵活性。结合引用中提到的"自主创新"、"先进性"、"可扩展能力"以及"微服务架构"等关键词，我们可以设计一个基于微服务的消息中心统分架构。 ### 1. 总体架构设计 采用分层架构和微服务设计思想，将系统分为以下层次： - **接入层**：统一的消息入口，负责消息的接收、协议转换和路由分发。 - **服务层**：核心微服务集群，包括消息处理、存储、分发等服务。 - **存储层**：分布式存储，支持消息的持久化和高可用。 - **控制层**：统一的管理控制中心，负责配置管理、监控和调度。 #### 架构图 ```plaintext +----------------+ +----------------+ +----------------+ | 客户端/生产者 |---->| 接入层 |---->| 服务层 | +----------------+ | (统一入口) | | (微服务集群) | +----------------+ +-------|--------+ | +----------------+ +----------------+ +-------|--------+ | 客户端/消费者 |<----| 分发层 |<----| 存储层 | +----------------+ | (推送/拉取) | | (分布式存储) | +----------------+ +----------------+ ^ | +----------------+ | 控制层 | | (配置/监控) | +----------------+ ``` ### 2. 关键组件设计 #### (1) 接入层 - **统一消息网关**：提供HTTP、TCP、MQTT等协议接入，进行身份验证和协议转换，将消息转换为内部统一格式（如JSON）。 - **消息路由**：根据消息类型或主题，将消息路由到不同的处理队列。 #### (2) 服务层（微服务集群） - **消息处理服务**：负责消息的解析、过滤、转换和校验。 - **消息存储服务**：将消息持久化到分布式存储（如Kafka+分布式文件系统或分布式数据库）。 - **消息分发服务**：根据订阅关系，将消息推送给消费者或供消费者拉取。 - **订阅管理服务**：管理消费者订阅关系，支持动态订阅和取消订阅。 #### (3) 存储层 - **消息存储**：采用分布式消息队列（如Kafka）作为消息缓冲，保证消息不丢失；同时使用分布式数据库（如Cassandra）或对象存储（如MinIO）进行持久化。 - **元数据存储**：使用关系型数据库（如MySQL）或分布式协调服务（如ZooKeeper）存储订阅关系、配置信息等元数据。 #### (4) 控制层 - **配置中心**：统一管理微服务配置，支持动态更新。 - **监控中心**：收集各微服务运行指标（如消息处理延迟、错误率），实现实时监控和告警。 - **调度中心**：负责负载均衡和故障转移，动态调整服务实例数量（结合容器化部署）。 ### 3. 统分模式实现 - **统**：统一接入、统一管理、统一监控。 - 所有消息通过统一网关接入。 - 控制层集中管理配置和监控数据。 - **分**：分布式处理、分布式存储、分布式部署。 - 微服务可独立部署和扩展，例如消息处理服务可以水平扩展。 - 存储层采用分布式存储，提高可靠性和扩展性。 ### 4. 技术选型建议 - **微服务框架**：Spring Cloud或Dubbo（支持服务注册发现、负载均衡）。 - **消息中间件**：Kafka（高吞吐、持久化）。 - **分布式存储**：Cassandra（高可用、可扩展）或TiDB（分布式关系型数据库）。 - **配置中心**：Nacos或Apollo。 - **监控**：Prometheus + Grafana。 - **容器化部署**：Kubernetes，实现弹性伸缩。 ### 5. 实施方案步骤 1. **需求分析**：明确消息类型（如通知、短信、邮件）、吞吐量、延迟要求、可靠性要求等。 2. **架构设计**：完成详细设计（包括接口定义、数据模型）。 3. **技术选型**：确定具体技术栈。 4. **模块开发**： - 先实现接入层和基础消息处理。 - 再实现存储层和分发层。 - 最后实现控制层（配置、监控）。 5. **测试与优化**： - 功能测试：确保消息收发、存储、订阅等功能正常。 - 性能测试：模拟高并发场景，优化性能瓶颈。 - 容灾测试：模拟节点故障，验证系统自愈能力。 6. **部署上线**：采用灰度发布，先小流量验证，再逐步扩大范围。 ### 6. 关键问题解决 - **消息顺序性**：如果业务需要严格顺序，可在同一分区内保证顺序（如Kafka分区内有序）。 - **消息去重**：在存储层通过唯一ID（如雪花算法ID）实现去重。 - **高可用**：服务无状态设计，多副本存储，避免单点故障。 - **扩展性**：微服务可独立扩展，存储层通过分片扩展。 该架构满足引用中提到的"先进性"和"可扩展能力"，采用微服务架构，符合当前技术趋势，且通过容器化部署和自动化运维支持快速迭代和持续交付[^1][^2]。 §§相关问题§§ 1. 如何设计消息中心的高可用方案？ 2. 消息中心如何实现消息的可靠投递（不丢失、不重复）？ 3. 在微服务架构下，消息中心如何与其他服务集成？</think>### 消息中心统分模式架构设计方案 统分模式的核心是**统一管理、分布式处理**，既保证全局一致性，又支持局部灵活扩展。结合系统先进性、可扩展性和微服务架构要求[^1][^2]，设计方案如下： --- #### 一、整体架构设计（分层模型） ```mermaid graph TD A[统一接入层] --> B[消息路由中心] B --> C[分布式处理节点] C --> D[存储集群] D --> E[监控调度中心] E --> B ``` 1. **统一接入层** - 功能：接收所有消息请求（API/队列/事件），进行协议转换和身份认证 - 技术：`Spring Cloud Gateway` + `OAuth2.0` - 关键设计： - 支持多协议接入（HTTP/WebSocket/MQTT） - 请求限流熔断（Sentinel集成） 2. **消息路由中心（统）** - 功能：全局消息路由决策，负载均衡，策略管理 - 技术：`Nacos`配置中心 + `Redis`缓存路由表 - 关键特性： - 动态路由策略（如按业务类型、地理分区路由） - 消息优先级队列（RabbitMQ优先级队列） - 统一幂等控制（基于消息ID分布式锁） 3. **分布式处理节点（分）** - 功能：并行处理消息（推送/存储/转换） - 技术：`Kubernetes` + `Spring Boot`微服务 - 分区策略： ```java // 示例：基于一致性哈希的分区算法 int nodeIndex = consistentHash(messageId, nodeCount); ``` - 弹性扩展：K8s HPA根据CPU/消息堆积自动扩缩容 4. **存储集群** | 存储类型 | 技术方案 | 用途 | |----------------|-------------------|--------------------------| | 实时消息 | Kafka + Pulsar | 高吞吐消息流处理 | | 持久化存储 | TiDB | 事务型消息(如订单通知) | | 冷数据 | MinIO对象存储 | 审计日志/历史消息 | 5. **监控调度中心** - 功能：全链路监控+智能调度 - 技术栈： - 监控：`Prometheus`+`Grafana`（资源/MQ堆积量） - 日志：`ELK`收集处理节点日志 - 调度：基于QPS的自动流量切换 --- #### 二、核心创新点 1. **混合分区策略** - 水平分区：按用户ID分片（如`user_id % 128`） - 垂直分区：按业务域拆分（支付类消息→独立集群） - 动态切换：通过Nacos实时更新路由规则 2. **消息可靠性保障** ```mermaid sequenceDiagram Producer->>+MQ: 发送消息(带唯一ID) MQ-->>Producer: ACK确认 MQ->>Worker: 消息投递 Worker-->>MQ: 处理完成ACK MQ->>DB: 持久化状态 ``` - 三次确认机制（生产者→MQ→消费者） - 死信队列自动重试（指数退避算法） 3. **安全控制** - 端到端加密：TLS1.3传输 + 敏感字段AES-GCM加密 - 审计追踪：所有操作留痕（满足等保2.0要求） --- #### 三、实施步骤 1. **阶段一：基础搭建（2周）** - 部署统一接入层 + Nacos配置中心 - 实现最小化消息路由（静态路由表） 2. **阶段二：分布式扩展（3周）** - 部署K8s集群，上线处理节点微服务 - 开发动态分区算法（一致性哈希） 3. **阶段三：高可用加固（2周）** - 搭建跨机房存储集群（TiDB Raft协议） - 实施混沌工程测试（模拟节点故障） 4. **阶段四：智能运维（持续迭代）** - 集成Prometheus告警（企业微信通知） - 开发消息轨迹查询界面 --- #### 四、性能保障措施 1. **基准指标** - 单节点吞吐量：≥ 10,000 msg/s - 端到端延迟：< 100ms（P99） - 可用性：99.95%（全年故障<4.4小时） 2. **优化手段** - 消息压缩：Protobuf二进制编码 - 零拷贝传输：Netty堆外内存管理 - 批量处理：合并小于100KB的同类消息 --- ### 引用说明 本方案遵循"自主创新与重点突破"原则[^1]，采用微服务架构满足竞赛项要求的"开发、测试、运维一体化"能力[^2]，通过分层解耦实现系统可扩展性，支持未来智能化升级（如AI消息分类）。
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值