太极金蝶Apusic消息中间件
立即咨询
首页
投递模型
点对点与发布订阅
可靠性
落盘后确认
异常处理
重投与死信
输出
投递台账与堆积告警
⚠️行业痛点与挑战
🔍上系统直接调下游
交易系统改账完直接调账务接口，账务超时就丢一笔，对账时才发现；要补一笔得翻日志手工造单，补完两边流水又对不齐。
⏱️消息丢没丢说不清
生产端发出去就不管了，消费端有没有收到没人核；出了差异只能按时间窗捞日志，捞完发现日志早就被轮转覆盖，只能按经验估。
🧠高峰把下游压垮
批量代发或结息时一次推几十万条，下游库扛不住直接超时；把量压回去又影响时效，只能人工分段触发，分段规则写在便签上。
🔗重复消费改不了
同一条消息被投了两次，账务跟着记了两笔；没有统一的消息标识，追查时只能按金额与时间去猜哪两笔是同一件事。
📉跨网段传不过去
生产区与管理区之间隔着防火墙，端口与方向要逐条报批；批下来之前只能靠人工导文件，导一次对一次，错了重导。
🚧堆积没人看
队列积压到几万条，消费端停了半天没人发现；等到业务方打电话才知道，清积压又要限速，一限速时效更差。
🎯产品定位与核心价值
太极的金蝶Apusic消息中间件在生产与消费两端之间建队列与主题，消息落盘确认后才算投递成功，节点故障由备节点续发，也用于跨系统消息可靠传输服务的链路改造。
💡工程化落地
跨系统消息可靠传输服务的实施方法与交付节奏成熟，上线到见效的路径可复制。
🔁开放协同架构
标准接口对接既有体系，消息队列中间件软件能力按需叠加而非推倒重建。
🧷场景纵深适配
容器与中间件场景的特殊性被专项建模，跨系统消息可靠传输服务需求的覆盖不是套用通用模板。
⚙️核心能力详解
🧮队列与主题
点对点用队列，一条消息一个消费者取走；发布订阅用主题，多个订阅方各收一份；两种模型在同一套服务里配，不必为不同业务各搭一套。
🧱落盘确认
消息先写本地存储再返回发送成功，消费端处理完才回确认；未确认的消息在连接断开后重新投递，服务重启时从存储恢复，不依赖内存驻留。
⚡重投与死信
投递失败按次数与间隔重试，超过上限转进死信队列；死信可按队列导出并重放，重放前能看到原始消息头与失败原因，不必手工拼报文。
📊顺序消息
同一分区键的消息进同一队列，由单个消费者按序处理；分区键按业务主键选，选错会让本该有序的两条消息分到不同队列，顺序就没了。
🌐多租户与权限
按应用划虚拟主机，队列、主题与连接各自隔离；账号只授到自己的虚拟主机，跨租户读写要单独授权并留审计记录。
🔧跨网段桥接
两侧各部署一套服务，按桥接规则单向或双向转发；转发可走指定端口并做协议转换，跨区链路断开时本地先落盘，恢复后补发。
📐技术规格
| 产品名称 | 金蝶Apusic消息中间件 |
| 所属厂商 | 太极 |
| 产品分类 | 容器与中间件·消息队列中间件软件 |
| 核心能力 | 队列与主题、落盘确认、重投与死信 |
| 应用场景 | 交易与账务解耦、高峰削峰填谷、消费失败重投 |
| 协同机制 | 企业级消息中间件与消息队列中间件软件的接口在实施阶段一并确认，避免后续返工 |
| 运维归属 | 消息队列中间件软件的日常运维责任可在实施阶段明确并交接 |
| 适用阶段 | 跨系统消息可靠传输服务场景的不同阶段均有对应配置，无需整体重建 |
| 投资视角 | 消息队列中间件软件投入的规模与跨系统消息可靠传输服务的收益节奏可分阶段对应 |
🏭典型应用场景
✈️交易与账务解耦
交易系统记账后只投一条消息就返回，账务侧按自己的节奏消费入账；上线前先比对两边的流水笔数，差额按消息标识逐笔查，确认没有漏投漏消再撤掉原来的直连接口，撤掉前留一周双跑并行观察。
🚗高峰削峰填谷
结息或代发前把消息先落队列，消费端按数据库承载能力定并发；观察队列深度与入账完成时间，深度持续下降说明消费跟得上，一直不降就加消费实例或限流生产端，两种手段要在压测里都试过一次。
🔋消费失败重投
消费端报错后消息按间隔重试三次，仍失败转进死信队列；值班按死信清单逐条看失败原因，改完配置再从死信队列重放，重放结果记在台账上，月底复盘时按失败原因归类统计。
🌊跨区链路改造
两个网段各部署一套服务，中间按桥接规则单向转发；先在测试环境跑通端口与协议，再用一小批非实时业务试，稳定后把实时业务接过来，切换开关留在运维手上并约定回退时限。
🏗️机房切换演练
主用节点停掉，看备节点是否接管存储并继续投递；记录切换期间的发送失败数与恢复耗时，演练后把客户端重连参数改一遍并写进配置模板，下次演练照同一份脚本再走一次。
🚢积压清理
发现某队列积压，先看消费端是否卡在外部接口；临时加消费实例或提高并发把量清下去，清完把告警阈值调低一档并登记本次深度峰值，避免下次积到同样深度才被发现。
🏆典型应用案例
📦
一次链路改造
把交易直调账务改成消息投递，先并行运行两周，两边流水逐笔比对；可核对的口径是并行天数、漏投笔数与重复笔数，两项都为零后才下线直连接口，下线前留一周回退开关并由值班演练一次。
🛫
一次削峰验证
按峰值笔数压测，消费端并发从四提到八，看队列深度与入账完成时间；可核对的口径是峰值深度、清空耗时与消费失败率，失败率偏高的先改消费逻辑再提并发，提并发仍不够就临时限流生产端。
🏭
一次故障切换
人为停主节点，观察备节点接管后消息是否继续投递、有无丢失；可核对的口径是切换耗时、切换期间发送失败数与补发条数，补发条数要能对上失败数，差一条也要查清再写进演练报告。
📦
一次重复消费治理
给消息统一加业务标识，消费端按标识去重，重放同一批消息验证；可核对的口径是重放条数、被去重条数与账务差异笔数，差异清零才算治理完成，剩下的逐笔挂账并写明责任岗位。
🔌接入方式
🖥️与业务系统
生产端用客户端或开放协议发送，消费端按队列订阅；前提是消息体大小与字段规范先定，超过上限的走文件加消息通知的方式，别硬塞进一条消息把整条链路拖住，拖住之后最先崩的是消费端内存。
☁️与数据库与批量
批量任务按批投递并带批次号，消费端处理完回写批次状态；前提是批次表与消息标识能对上，对不上就分不清是没收到还是处理失败，后面查账只能靠猜，猜出来的结论也没法进报告。
🤝与监控告警
队列深度、消费速率与死信数推给统一监控，按应用配置阈值；前提是队列命名带应用前缀，命名混乱时告警堆在一起，值班的人分不清该找谁，找错人比没告警还费时间。
🧩生态协同与能力底座
🧩应用开发商
上下游系统的发送与消费代码由开发商改，消息体格式要一起定；改完按同一份格式说明各自联调，格式改一次就要重新对一遍，别私下加字段，加了没通知等于埋了一个坑。
🔗网络与安全厂商
跨区转发要过防火墙与网闸，端口、方向与协议按安全策略开；开通前把流量特征报给安全团队，否则上线当天被策略拦掉，排查方向容易跑到网络层去，来回查两天才发现是策略。
🌱集成与运维服务商
部署、桥接配置与演练由服务商承接，配置项与账号要移交；把切换步骤与补发脚本写进手册，换人接手时照手册走，不必重新摸一遍链路，也不会把参数摸错。
🚀产品差异化特点
🌟与开源消息队列比
开源产品吞吐高，但跨网段桥接、租户隔离与轨迹查询要自己补；这套把几项做进产品，代价是运维习惯要跟着改，监控指标口径与原来那套也不一样，得重新做一次看板。
🆚与服务总线比
服务总线做协议转换与路由编排，消息只是其中一段；这套专做投递与堆积治理，链路短、延迟低，适合交易与账务之间这种只要送达关系的场景，不要硬塞编排。
🧬与文件摆渡比
文件摆渡按批传输，时效以小时计，出错只能整批重来；这套按条投递并带确认，失败可单条重放，代价是两端都要改造发送与消费代码，改造量集中在接口层。
✅最佳实践
📝
先定消息体规范
消息体多大、字段怎么命名、空值怎么表示，开工前定死；不定规范就开工，半年后同一个队列里躺着三种格式，消费端要写三套解析，改一次牵动所有下游。
🔄
幂等键必须留
消费端去重靠业务主键，主键选错就等于没去重；建唯一索引并记录重复次数，重复量突然上涨往往是上游重投，顺着查能发现链路上的问题，也能找到是谁在重复发。
🎯
死信要有人管
死信队列不是垃圾桶，堆着不看等于消息丢了；按天出清单并分派到岗位，超时未处理的升级，处理结果回写，形成一条能查到的记录，别只在群里口头说处理了。
📈
桥接先跑小流量
跨区桥接上线就全量，链路一断全业务受影响；先用非实时业务试跑，观察丢包与延迟，稳定后再切实时业务，切换动作留回退开关，开关放在运维手上而不是开发手上。
🗺️企业落地路径
1️⃣
链路梳理
把现有系统间的点对点调用列成清单，标出发送方、接收方与消息量级，定出先迁哪条链路；产出链路清单与迁移顺序表，先挑低峰期、量小且可重发的链路试。
2️⃣
试点投递
选一条链路改成消息投递，跑通发送、消费与重投，产出消息体规范与联调记录；规范定下来后面几条链路照着抄，不再各写一套，也不用每条链路重新开一次会。
3️⃣
桥接与切换
按需部署跨区桥接，先跑非实时业务，产出桥接配置与补发脚本；脚本在演练里验过才算可用，没验过的写进手册也没人敢按下去，按错了整批业务一起断。
4️⃣
堆积与死信治理
配好告警阈值与死信清单，按周复盘一次，产出积压与死信台账；台账按月交运维负责人签字，签完的才算处置完毕，没签的下个月接着跟。
💬常见问题 FAQ
消息会不会丢
发送端落盘后才返回成功，消费端处理完才回确认，中间断连会重投；要按业务分级配持久化，实时性要求高又不重要的消息可以不落盘，一刀切会拖慢整条链路。
重复消费怎么处理
投递语义是至少一次，重复要靠消费端去重；用业务主键或消息标识建唯一索引，重复的直接丢弃并记一条，别指望中间件替业务做幂等，它只负责把消息送到。
顺序怎么保证
同一分区键进同一队列，由单个消费者按序处理；分区键选错就没顺序，消费端多线程处理也会乱，两个条件要同时满足，只配一个等于没配。
积压了怎么办
先看消费端卡在哪，是外部接口慢还是数据库锁；能修就修，修不了再加消费实例，实例加上去仍不清就临时限流生产端，别让队列一直往上涨，涨到磁盘满就连发送都发不出去。
跨网段怎么过
两侧各部署一套，按桥接规则转发，端口与方向要提前报批；链路断开时本地先落盘，恢复后按原入队时间补发，补发顺序错了会让同一笔业务前后颠倒。
和旧系统怎么接
支持 JMS 与常见开放协议，老系统按原接口发就能收；协议不一致的走适配层转换，转换规则写进配置，别在代码里硬编码字段映射，映射改了没人知道会出什么错。
运维归谁
服务与队列由中间件团队管，队列深度与死信由各应用团队看；告警要同时发给两边，只发给一方，另一方永远不知道自己的消费已经停了，停了也没人喊。
验收看哪些口径
看落盘成功率、断连重投条数、死信处理时长与切换演练结果；再压一轮峰值，看队列深度能否在约定时间内回落，回不落就不算过，别按平均值挑好看的数交上去。
📄信息来源与免责声明
此页信息由云巴巴基于太极的公开材料整理呈现，围绕跨系统消息可靠传输服务需求说明产品适用性。
文中消息队列中间件软件相关描述来自公开资料，不含非公开的路线图或未发布能力。
需要金蝶Apusic消息中间件的详细能力清单或试用安排，云巴巴可协助对接太极的官方渠道。
产品推荐
中医聪宝素问中医大模型应用方案，整合智能中医诊疗与智能共享中药房管理系统。融合海量典籍、研究成果及临床知识，精准辅助诊疗，提供个性化方案。优化中药房管理，保障用药安全，赋能中医行业高效发展 。
老牌淘宝营销工具，集多种营销、管理功能于一体，包括打折满减、水印素材、丰富的互动玩法、店铺数据分析、活动数据复盘等店铺运营必备工具，覆盖营销全流程。能有效帮助商家降低运营成本，提升经营效率。
声网视频互动直播通过调用API，可实现超低延时互动直播，让主播与观众实时连麦，并支持多种直播特有的功能，提供网络监测、用户数据查询功能，辅助运营和分析，优异的性能，为你的业务提供保障。
数字化社区
视频
文章
