张翮做交易系统这么多年，有个很深的感触：中间件这类东西，平时不像业务代码那样天天写，但每一次线上事故背后，都有它的一份功劳或者一份锅。促销峰值把订单洪峰打下来了，那是消息队列在扛；服务间调用突然超时了，可能是连接池的配置在拖后腿；集群扩容后部分请求一直没生效，往往又是注册中心的缓存没刷干净。交易系统越复杂，对中间件的依赖就越深。
这篇把世界范围内绕不开的中间件产品和它们背后的公司、各自的适用场景、部署和优化经验，一次梳理清楚。前两节讲产品和公司，第三节开始讲国产中间件，第四节给一份宝兰德中间件的完整部署实操，最后一节聊消息中间件在交易场景下的选型与调优。中间穿插的踩坑记录，都是真实线上环境里沉淀下来的东西。
1. 交易链路里的中间件，到底在扛什么
1.1 从一次系统设计反推中间件的职责
如果你把一个交易系统拆开看，整个请求链路大概是这样的：用户请求进来，先经过网关和负载均衡，到应用服务器执行业务逻辑，应用要查数据就得访问数据库，要调别的服务就得走RPC或消息队列，服务之间的依赖关系还要靠注册中心来维护。在这个链条里，中间件扮演的角色很特殊——它不直接产生业务价值，但整个交易链路的稳定性、扩展性和数据一致性，全靠它托底。
我参与过一个典型的交易项目，需求是每秒支撑三万笔订单的写入，同时要保证这笔订单的状态变更能被下游十几个系统可靠地感知。一开始团队想靠数据库硬扛，结果压测刚跑到三千TPS，数据库的连接数就耗尽，CPU直接打满。后来把链路重构了一下：写操作全部通过消息中间件做削峰填谷，订单状态变更以事务消息的方式异步通知下游；热点账户的余额读取直接走缓存；服务发现和配置管理交给分布式协调组件。重构之后，压测峰值跑到四万TPS，数据库的压力反而降了百分之六十。
这个案例能说明一个道理：中间件的价值不是"用了就性能好"，而是它能把交易系统里那些跨进程、跨节点、跨机器的复杂问题抽象出来，用一种经过验证的通用方案去解决。没有消息中间件，削峰填谷就得自己写持久化队列；没有缓存中间件，热点数据的高并发读取就得靠数据库硬撑；没有协调服务，分布式锁和Leader选举就得每一家自己重复造轮子。
1.2 中间件演进的三个关键阶段
中间件这个概念，二十多年前和现在所指的东西已经完全不一样了。早年谈中间件，主要指Tuxedo、CORBA这类面向企业级交易处理的中间件平台，解决的问题是"异构系统之间如何通信"，核心价值在交易中间件和消息中间件这两个品类上。那个年代关系型数据库还没现在这么普及，一套交易系统经常要跑在多种硬件和操作系统上，中间件的作用就是屏蔽底层差异，让上层业务可以统一使用交易接口和数据访问接口。
到了JavaEE时代，中间件的重心转移到应用服务器。WebLogic、WebSphere、Tomcat这些名字开始频繁出现在企业IT采购清单里，它们承当了Web容器、EJB容器、JMS消息服务、事务管理这些能力。这个阶段中间件解决的问题变成了"企业级应用如何规模化开发、部署和运行"，也是一大批国产中间件公司起步的背景。
最近这十年，架构全面转向分布式和云原生，中间件的形态再次发生变化。消息队列、缓存、注册中心、配置中心、API网关、分布式事务、流处理平台，都是这个阶段的产物。中间件不再是一个单体软件，而是一整套技术栈。做技术选型的时候，你不会只挑一款中间件，而是要基于自己系统的规模和团队能力，从一整个生态里挑选合适的组件拼装起来。
从演进过程可以发现一件事：中间件的价值始终没变——它永远是"解决通用问题的通用层"。交易系统里那些数据库搞不定、业务代码写起来太重复的痛点，大概率最后都会演化成一个中间件产品。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 全球中间件版图：绕不开的七款产品和它背后的公司
2.1 消息类中间件：谁的可靠性基因最强
消息中间件是交易系统里存在感最强的一类。我自己盘点了一下，这十年来实际接触过、也看过源码或者深入调试过的消息产品，无非是IBM MQ、RabbitMQ、Apache Kafka、Apache RocketMQ这四款。它们背后代表四种不同基因。
IBM MQ是中间件界的元老级产品，最早叫MQSeries，后来改名为WebSphere MQ，再后来才是IBM MQ。在企业级市场它的地位无可撼动，尤其是银行核心系统、证券交易系统这类极度看重消息不丢失的场景。IBM MQ最值钱的地方在于它的传输保障机制：持久化消息、事务性消息、多级确认，配合IBM自己的队列管理器集群，能做到真正意义上的端到端不丢失。当然代价也直观——商业授权费是按CPU核数算的，而且它的管理界面和开发方式还停留在上个时代的风格，上手门槛高，年轻工程师普遍不愿意碰。
RabbitMQ则走了另一条路。它基于Erlang/OTP构建，天然支持高并发和热更新，核心优势是灵活的路由能力。RabbitMQ实现了AMQP协议，有exchange、binding、queue这些概念，消息的路由规则可以设计得非常细。团队在做需要复杂路由的中小规模交易场景时，RabbitMQ是很好的选择，比如按订单类型分发到不同的处理队列，按优先级处理不同等级的工单。它的弱点是吞吐量在纯日志类场景下远不如Kafka，集群模式在节点故障时的处理也不如Kafka优雅。
Apache Kafka的基因是日志系统。LinkedIn为了处理海量行为日志开发了它，后来捐给了Apache基金会。Kafka的设计目标是大吞吐、高可用、分区有序，核心在于利用了操作系统的PageCache和顺序写磁盘的特性。交易系统里Kafka最常见的用途是业务事件流、审计日志、以及大数据链路的数据管道。但很多人用Kafka做核心交易消息时忽略了一个问题：Kafka的"至少一次"语义下，消费者端需要自己做幂等处理，否则重复消费就是家常便饭。
Apache RocketMQ则是阿里开源的一款消息中间件，也是国内使用范围较广的消息产品。它最大的特点是事务消息和延迟消息的支持很完善，配合本地消息表可以比较优雅地解决分布式事务问题。RocketMQ在设计上吸收了Kafka的高吞吐思路，又在消息可靠性、消息轨迹、延迟消息、消息过滤这些企业级能力上做了补充。对于国内的交易系统，RocketMQ的上手成本和维护成本都比IBM MQ低很多，这也是为什么很多互联网交易平台最终会选它。
这四款产品的选择逻辑，我在后面第五节会详细展开。这里先记住一个结论：没有最好的消息中间件，只有最适合你交易场景的消息中间件。
2.2 应用服务器：Java后端绕不开的宿主
早几年做JavaWeb开发，绕不开应用服务器这个词。那会儿Tomcat几乎是每个Java工程师的标配，Spring Boot内嵌容器之后，很多新人对应用服务器的感知反而变弱了。但企业级交易系统里，应用服务器依然是一个不能回避的环节，尤其是涉及国计民生的大规模系统，WebLogic、WebSphere仍然大量存在。
Oracle WebLogic Server是BEA公司1995年推出的产品，后来BEA被Oracle收购。WebLogic在JavaEE时代是公认的强者，它的集群能力、事务管理、JMS集成、以及和Oracle数据库的深度配合，让它在一批银行、电信、政府项目中用过十多年都没被替换。WebLogic的定价不便宜，License按Processor计算，配置不当对性能影响也很大。我记得有一次排查一个交易系统偶发卡顿，最后定位到是WebLogic的JDBC连接池配置了未验证连接，导致每次从池里取出连接前都要去数据库校验，在高并发场景下这个校验操作被放大成了性能瓶颈。
Apache Tomcat则是另一个极端——轻量、开源、免费。Tomcat最初是Sun公司Servlet/JSP规范的参考实现，后来捐给Apache。它的定位就是Web容器，不像WebLogic那样带一堆企业级功能，但胜在简单可靠。交易系统里大量内部系统、中台服务、管理后台，用Tomcat跑完全够用。Spring Boot内嵌Tomcat之后，应用服务器的概念被弱化了，但底层还是这些组件在扛。
WildFly（原JBoss AS）背后是Red Hat公司，现在属于IBM。WildFly在JavaEE全栈支持上做得扎实，微服务架构下又推出了基于Vert.x的Thorntail。不过在交易系统领域，WildFly的份额一直不如WebLogic和Tomcat，更多出现在一些对开源生态有偏好的企业里。
选应用服务器这件事，我的经验是——除非有明确的企业级需求和预算，否则尽量轻量化。交易系统真正的高并发瓶颈很少是Web容器本身，而是应用代码、数据库连接池和线程池的配置。把Tomcat调好，配合Nginx做负载均衡，规模不大时完全够用。
2.3 缓存与编排：高并发场景的辅助枢纽
消息和应用服务器之外，交易系统里还有两类中间件虽然不像消息队列那么"显眼"，但同样不可或缺——缓存中间件和分布式协调组件。
Redis在这个位置上基本没有对手。它诞生于意大利程序员Salvatore Sanfilippo之手，开源之后迅速成为互联网公司的基础设施标配。Redis的价值在于把数据放在内存里，单线程处理命令天然避免了并发竞争，配合持久化可以做到不错的可靠性。交易系统里Redis最典型的应用是热点数据缓存、分布式锁、接口幂等、限流计数器。我记得有一次做秒杀系统，把库存预扣从数据库搬到了Redis的Lua脚本里，整体接口耗时从200ms降到20ms。但Redis也不是万能的，如果用了持久化机制RDB和AOF，在故障恢复时会有一段不可用窗口，这点被很多人忽视。
分布式协调这边，Apache ZooKeeper是绕不开的名字。ZooKeeper源自Hadoop生态，最初用于HBase的协调服务，后来被广泛应用在Dubbo、Kafka这些中间件里做元数据管理和Leader选举。ZooKeeper的核心是ZAB协议，能保证集群内数据强一致，代价就是写入性能一般。etcd是CoreOS推出的轻量级协调存储，使用Raft协议，现在Kubernetes、微服务配置中心这些场景基本被etcd接管。交易系统里注册中心的选择，老一代系统用ZooKeeper，新一代系统很多直接用etcd或者Nacos。Nacos是阿里的开源产品，把注册中心和配置中心合二为一，Spring Cloud Alibaba生态下用起来特别顺手。
缓存和编排类中间件的选型，核心看两点：你需要的是一致性还是可用性，以及团队对运维成本的承受力。要强一致就选ZooKeeper或etcd，要最终一致性和高可用，Redis Cluster配合Nacos也够用。
3. 国产中间件观察：金蝶、宝兰德们靠什么立住身
3.1 兼容性适配才是第一关
聊完国际主流产品，说回国内。金蝶天燕、宝兰德、东方通、中创，这些名字在国际市场上可能没什么声量，但国内的企业级市场它们一直有稳定的份额。
很多人对国产中间件有个刻板印象——觉得是国际大牌的廉价替代品，功能不行、性能拉胯。刚接触国产中间件时我也有类似的偏见，觉得直接用开源社区的东西不就好了，为什么要用这些看起来"没技术含量"的商业封装。真正在项目里用了才明白，国产中间件价值最大的一块不在技术本身，而在适配。
这个适配是多层次的。硬件层面，要能跑在鲲鹏、飞腾、海光这些国产芯片上；操作系统层面，要兼容麒麟、统信UOS这些国产操作系统；数据库层面，要能对接达梦、人大金仓、OceanBase、GaussDB等国产数据库。这些在开源社区里根本没人替你验证，出了问题也没有社区帮你解决，只能靠中间件厂商一家一家去适配和优化。宝兰德在这一点上做得算扎实，它的BES Application Server支持主流的国产CPU和操作系统组合，部署工具和管理控制台也针对国内的使用习惯做了定制。
另外，国产中间件在对JavaEE规范的支持完整度上也越来越接近国际水平。我在一个项目中把基于WebLogic的交易应用迁移到宝兰德BES上，除了少数涉及WebLogic专属API的地方需要小调整，大部分代码只需要改配置文件就能跑。这种兼容性对很多老系统来说意味着迁移成本大幅降低。
3.2 从部署到监控的完整工具链
国产中间件发展到现在，已经不是简单的"能跑就行"，而是逐步形成了一套完整的工具链。以宝兰德为例，它除了核心的BES Application Server之外，还有BES WebServer、BES MQ消息中间件、BES APM应用性能监控平台，覆盖了从应用托管、消息通信到链路追踪的完整环节。
这些工具链里，APM监控平台的实际价值很大。交易系统跑在生产环境后，最难的就是定位性能瓶颈——到底是数据库慢、代码堵、还是中间件本身的问题。宝兰德的APM能做到自动发现应用之间的调用关系，线上定位问题会快很多。这种能力在国际商业中间件里未必都有，但对维护老系统的团队来说非常实用。
部署工具方面，宝兰德的管理控制台支持Web图形化操作，可以完成应用发布、数据源配置、JVM参数调整、日志查看这些日常运维动作。团队里如果运维人力有限，这样的工具链能省不少事。不过也要客观说，国产中间件的社区生态和文档完善度和开源产品还有差距，遇到特别棘手的底层问题，有时还需要找原厂支持。
3.3 实用主义选型建议
国产中间件到底值不值得用？我的建议是分场景看。
新建的互联网架构项目，技术栈年轻、团队对开源组件熟悉，优先考虑开源中间件没问题。RocketMQ、Redis、Nacos、Spring Cloud这套组合完全能撑起大部分交易场景。这类项目选国产商业中间件，反而会因为License费用和技术生态的封闭性增加不必要的成本。
存量企业级系统，特别是那些从WebLogic、WebSphere时代走过来的老系统，以及有国产化替代需求的客户，国产中间件是更务实的方案。一方面是因为License成本比国际商业软件低不少，另一方面是因为适配工作已经被厂商做完，项目不用从零开始踩坑。我做过一个从WebLogic迁移到BES的项目，整个迁移加灰度验证大概用了两周时间，最终稳定运行。如果是反过来往TongWeb、Apusic上迁移，过程也类似，换汤不换药。
还有一点值得留意：不要只根据Benchmark来选中间件。国内厂商的性能测试PPT都很好看，但实际部署时的表现和硬件配置、网络环境、应用代码都有关系。选型前最好让厂商安排PoC测试，把你们自己的真实业务流量或者压测脚本放上去跑一圈，看数据再定。
4. 宝兰德中间件从零部署的一次完整实操
4.1 环境准备与安装包处理
我用一台CentOS 7.9的虚拟机做演示，物理机配置是4核8G。生产环境给中间件节点至少配8核16G，不要和数据库共用机器。基础环境需要JDK 8或JDK 11，推荐使用厂商配套发行的OpenJDK，避免某些JDK在特定硬件上的兼容性问题。
code复制# 检查JDK版本
java -version
# 如果系统没有JDK，先安装
yum install -y java-1.8.0-openjdk-devel
# 查看是否已就绪
/usr/lib/jvm/java-1.8.0-openjdk/bin/java -version
宝兰德中间件的安装包通常是一个tar.gz压缩包，下载完成后先解压。
code复制cd /opt
tar -zxvf BES_9.5.5.tar.gz
ls -l /opt/BES_9.5.5/
解压后你会看到bin、conf、deploy、lib、logs、modules这几个目录。bin目录下存放启动和管理脚本，conf目录是配置文件主目录，deploy目录用于存放应用部署包，logs目录输出运行日志。安装目录的路径不要带中文和空格，尽量放在固定路径下，比如/opt、/usr/local。
这里有一个经常被忽略的细节：不要以root用户直接启动中间件，最好创建独立用户运行。因为中间件本身是Java进程，一旦被攻破，如果以root运行风险极大。生产环境我通常会建一个名为bes的专用账户，把安装目录属主切给它。
code复制groupadd bes
useradd -g bes -s /bin/bash -d /home/bes bes
chown -R bes:bes /opt/BES_9.5.5
4.2 控制台启动与虚拟主机配置
切换到bes用户，启动中间件的管理控制台服务。宝兰德的管理控制台本身也是一个Web应用，启动后可以通过浏览器访问。
code复制su - bes
cd /opt/BES_9.5.5/bin
./startserver.sh
默认情况下管理控制台端口是8080，域名IP访问可能会比较慢，等待日志出现Server startup相关的提示就说明启动成功。浏览器打开http://服务器IP:8080/console，用管理员账号登录，初始密码是首次启动时自动生成在日志里的，按提示修改。
登录控制台之后，先别急部署应用，第一步是创建虚拟主机。虚拟主机类似于Nginx里的Server块，可以绑定域名和端口，不同虚拟主机可以互相隔离应用。交易系统里常见做法是每个业务集群一套虚拟主机，这样可以针对不同域名配置不同的访问日志和访问控制策略。
新建虚拟主机时填主机名和别名，端口默认8080。如果一台机器要跑多个应用且不想用不同端口，可以用不同域名绑定同一个端口；如果应用之间完全隔离，建议不同虚拟主机用不同端口。这个设计可以让后续的运维和权限隔离更清晰。
4.3 JVM参数与并发性能调优
中间件装上能跑只是第一步，调参才是真正拉开差距的地方。宝兰德基于Java，所以它的性能很大程度上取决于JVM参数配置。
JVM参数在conf目录的启动脚本或管理控制台的"服务器配置-JVM参数"里可以调整。交易系统最核心的调优方向是堆内存和大对象处理。我一般推荐初始堆和最大堆设置为同样的值，避免运行期堆反复扩容和缩容带来的GC开销。假设物理内存16G、中间件独占一台机器，可以给JVM分配8G堆内存。
code复制-Xms8192m
-Xmx8192m
-XX:MaxMetaspaceSize=1024m
-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
G1垃圾收集器适合大堆场景，目标停顿时间设为200ms比较中庸，可以根据线上GC日志再调整。线程池方面，BES的默认线程数通常偏保守，交易系统可以根据并发量调大。在线程池配置里，最小线程数和最大线程数建议按"CPU核数乘以4到8"来估算。4核机器上最大线程数设32比较合适，设置得过大反而会增加线程切换开销。
另外有一个容易踩的坑：数据库连接池的最大连接数要小于数据库侧的连接数上限，否则数据库连接被打满后，中间件队列里的请求会越积越多。我之前遇到一次线上事故，就是中间件连接池配了500，数据库设置的max_connections只有300，结果数据库直接拒绝连接，最终表现为接口大面积超时。
4.4 部署过程中最常见的三个问题
整个部署过程中我遇到过的比较典型的问题有三个，这里专门列出来。
第一个是端口冲突。生产机器上如果跑着别的服务占用了8080端口，启动中间件会直接起不来。排查方法很简单：先netstat -lnp | grep 8080看看谁在占用，然后通过配置把BES的HTTP端口改掉。这个属于小问题，但运维经验不足的同事往往会在这个上面卡很久。
第二个是JDK版本不匹配。宝兰德对JDK版本有明确要求，用JDK 17去跑只支持JDK 8的版本会报UnsupportedClassVersionError。安装前建议统一用中间件厂商指定的JDK版本，或者直接使用安装包自带的JRE。
第三个是应用部署后ClassNotFound或者NoClassDefFoundError。这种问题十有八九是应用依赖的jar包和中间件自身的类加载机制冲突了。宝兰德支持对特定应用配置优先加载classes还是lib，遇到这种报错时，在应用配置里调整类加载的优先级顺序，一般就能解决。这个机制和WebLogic的prefer-web-inf-classes类似，做过WebLogic迁移的人应该会有共鸣。
5. 消息中间件优化：交易场景下的性能与可用性考量
5.1 Kafka、RabbitMQ、RocketMQ怎么选
到了消息中间件选型，很多人会纠结。我把三款主流产品的定位和典型场景做了个对比：
| 维度 | Apache Kafka | RabbitMQ | Apache RocketMQ |
|---|---|---|---|
| 核心定位 | 分布式流平台，日志管道 | AMQP消息代理，路由灵活 | 分布式消息，企业级特性完整 |
| 吞吐量 | 极高，百万级TPS | 中等，十万级TPS级别 | 高，数十万级TPS |
| 消息可靠性 | At-least-once，需消费端幂等 | 支持事务，可靠性较高 | 支持事务和内置幂等支持 |
| 消息有序性 | 分区内有序 | 单队列有序 | 队列内有序，支持全局顺序 |
| 延迟消息 | 不直接支持低延迟调度 | 支持延迟队列插件 | 原生支持延迟消息 |
| 管理成本 | 较高，依赖ZooKeeper/KRaft | 较低，管理界面完善 | 中等 |
| 典型交易场景 | 审计日志、行为事件、监控数据 | 业务消息路由、任务分发 | 订单状态、支付回调、事务消息 |
我自己的判断标准很简单：如果数据量大、对乱序容忍度高、重点是"堆数据"，选Kafka；如果消息量适中、路由规则复杂、团队运维能力一般，选RabbitMQ；如果消息是核心交易链路的一部分、对数据一致性要求高、需要事务消息或者延迟消息，选RocketMQ。
曾经有个支付项目用RabbitMQ做核心支付状态消息，量起来之后频繁出现消息积压，加消费者也没用。后来定位到是因为RabbitMQ的路由键设计和队列绑定不合理，消息全挤在了一个队列里。解决方式是把单队列拆成多个业务队列，再结合消费者并发度调整，才把积压解决掉。这个案例说明，选型重要，但用对更重要。
5.2 面试和实战都绕不开的可靠性三问
消息中间件这个方向，面试也好、做架构评审也好，本质上都会落到三个问题上：消息会不会丢、会不会重复、会不会乱序。这三个问题不是背八股，每一个都需要在架构层面有明确方案。
消息不丢，要在三个环节分别确认。生产端：采用同步发送并确认发送结果，失败后重试，或者用事务消息保证本地事务和生产消息的原子性。Broker端：打开持久化，配置多副本，比如Kafka的replication.factor大于1，且min.insync.replicas配成大于1。消费端：先处理业务逻辑，后提交offset，而不是提交完offset再去处理业务——这个是很多人容易犯的错误，一旦处理抛异常，消息已经丢了。
消息重复，本质上是"至少一次"语义下的必然结果，所以核心不是"确保不重复"，而是"消费端幂等"。常用方案：用消息里的全局唯一业务ID作为主键，消费时先查重；或者用Redis做消费幂等标记，设置合理的过期时间；再或者利用数据库唯一索引约束，重复插入直接报错但不影响业务。交易系统里我建议直接走数据库唯一索引，最简单也最可靠。
消息乱序，要根据业务需求分级处理。如果只要部分有序，可以把同一订单号哈希到同一个分区或队列，以订单号为维度保证顺序。如果要求完全有序，吞吐量会明显下降，需要谨慎使用。支付回调场景，一般是按交易单号哈希到队列即可，不需要全局顺序。订单创建和订单关单这两个事件如果走了不同队列，消费端需要有状态机保护，否则可能会因为到达次序颠倒导致状态异常。
5.3 压测与调优的实测参数建议
交易系统引入消息中间件之前，压测是必须做的一道关卡。我建议至少关注这几个参数：生产端的批量大小、消费端的并发线程数、Broker端的刷盘策略、以及副本同步策略。
用Kafka举例，生产端通过batch.size和linger.ms来控制批量发送行为。batch.size默认是16KB，在高吞吐写场景可以调大到32KB或64KB；linger.ms默认是0，也就是有数据立即发，这样吞吐上不去但延迟低。日志类场景可以把这个值调到5ms到10ms，换取更高的吞吐。消费端的核心参数是max.poll.records和max.poll.interval.ms。max.poll.records控制单次poll返回的最大消息数，默认是500，如果你的单条消息比较大，这个值最好调小，避免单次处理时间过长触发rebalance。之前我遇到过消费端频繁rebalance的问题，排查后就是单条消息处理太慢导致max.poll.interval.ms超时，消费者被踢出分组。
RocketMQ的调优重点不一样。它的刷盘方式分为同步刷盘和异步刷盘，交易核心场景必须用同步刷盘，虽然吞吐有损失，但不会因为突然断电丢数据。生产端设置setSendMsgTimeout不要太小，高并发下如果超时时间设置成默认的3000ms，可能因为Broker处理慢导致大量发送超时。RocketMQ的消费并发度由消费线程数决定，可以通过consumer.setConsumeThreadMin和setConsumeThreadMax来调整，官方默认是20，可以根据实际处理耗时往上调，但别盲目调到几百，线程切换带来的开销会抵消并发收益。
还有一个经常被忽视的调优点——消息体大小。很多团队把大JSON对象直接塞进消息里，一条消息几十KB，对Producer端的序列化、网络传输、Broker的PageCache都会造成压力。交易系统里消息体尽量精简，只放关键字段和业务ID，详情数据接收方按需回查。这样做还有一个好处，消息的体积缩小后，批量发送的效率会明显上升。
回到实践层面，我建议每个团队维护一份自己的消息中间件配置清单。把生产环境验证过的最优参数记录下来，新项目直接套用，避免每次从默认参数开始反复摸索。这个清单里至少要包含版本号、Topic/Queue分区数、副本数、生产端参数、消费端参数、Broker的JVM参数、以及日志保留策略。这样才能做到可复制、可审计。
最后再分享一个小经验：中间件版本的升级路径一定要提前规划。很多团队上线时选了一个版本，后面两三年不管不顾，等到社区停止维护了才被迫升级，一次大版本跨级带来的兼容性问题和配置变更，往往比当初选型还折腾。交易系统追求稳定没有错，但稳定不等于永远不动，定期做小版本升级和补丁更新，才是长期运行的正确姿势。