搞 Java 后端的人十有八九都在 SpringBoot 里碰過(guò) RabbitMQ。剛開(kāi)始用的時(shí)候功能倒是很快就能跑通但等你想把消息內(nèi)容打出來(lái)看看、或者想跨服務(wù)消費(fèi)數(shù)據(jù)時(shí)就會(huì)發(fā)現(xiàn)一個(gè)問(wèn)題消息體要么是一串看不懂的二進(jìn)制亂碼要么接收端直接報(bào)類轉(zhuǎn)換異常。這背后的罪魁禍?zhǔn)资邪司啪褪悄J(rèn)的消息轉(zhuǎn)換器——它用的是 JDK 原生序列化。這篇文章我就專門聊聊在 SpringBoot 項(xiàng)目里如何把消息轉(zhuǎn)換器切換成 JSON 格式徹底告別那些“能跑但很別扭”的序列化體驗(yàn)。項(xiàng)目里需要對(duì)接消息隊(duì)列的開(kāi)發(fā)者、剛接觸 SpringBoot 整合中間件的新手都可以拿這篇文章當(dāng)作一份可直接照做的實(shí)操筆記。1. 為什么默認(rèn)的消息轉(zhuǎn)換器應(yīng)該被換掉1.1 默認(rèn)轉(zhuǎn)換器到底做了什么事SpringBoot 整合 RabbitMQ 后核心入口是RabbitTemplate。你調(diào)用convertAndSend時(shí)消息對(duì)象會(huì)先經(jīng)過(guò)一個(gè)MessageConverter再寫入網(wǎng)絡(luò)。這個(gè)接口默認(rèn)的實(shí)現(xiàn)是SimpleMessageConverter它的工作方式很簡(jiǎn)單要求對(duì)象實(shí)現(xiàn)Serializable然后直接調(diào)用 Java 的原生序列化機(jī)制把整個(gè)對(duì)象圖變成一堆字節(jié)流。問(wèn)題就出在這個(gè)“默認(rèn)”上。Java 序列化產(chǎn)生的字節(jié)流不只是對(duì)象字段的二進(jìn)制數(shù)據(jù)還包含類描述、繼承關(guān)系、序列化版本號(hào)等大量附加信息。一個(gè)只有幾十字節(jié)的 JSON 字符串經(jīng)過(guò) JDK 序列化后有可能會(huì)膨脹到幾百甚至上千字節(jié)。消息量小的時(shí)候無(wú)所謂但一旦進(jìn)入高吞吐場(chǎng)景網(wǎng)絡(luò)帶寬和存儲(chǔ)成本都會(huì)被放大。更麻煩的是跨語(yǔ)言問(wèn)題。JDK 序列化格式只有 Java 能解析。如果你的生產(chǎn)者是 Java 服務(wù)消費(fèi)者是 Python 或 Node.js 服務(wù)那默認(rèn)轉(zhuǎn)換器根本沒(méi)辦法互通。非要硬接的話只能在消費(fèi)端寫一大堆底層字節(jié)解析邏輯完全違背了使用消息隊(duì)列解耦的初衷。還有一個(gè)隱患是反序列化安全。Java 原生反序列化機(jī)制這些年被曝出過(guò)不少漏洞攻擊者可以通過(guò)構(gòu)造惡意字節(jié)流觸發(fā)任意代碼執(zhí)行。雖然 RabbitMQ 本身有權(quán)限管控但消息內(nèi)容一旦經(jīng)過(guò)不可信來(lái)源默認(rèn)轉(zhuǎn)換器就成了一個(gè)風(fēng)險(xiǎn)點(diǎn)。在安全要求較高的系統(tǒng)里這通常是評(píng)審一票否決的問(wèn)題。1.2 JSON 轉(zhuǎn)換器解決了哪些痛點(diǎn)換成 JSON 格式的消息轉(zhuǎn)換器后上面這些問(wèn)題會(huì)得到明顯改善。JSON 格式是純文本體積比 JDK 序列化小一大截而且人類可讀排查問(wèn)題的時(shí)候可以直接在管理后臺(tái)看到消息內(nèi)容不需要再拿反序列化工具去猜原始對(duì)象結(jié)構(gòu)。跨語(yǔ)言是最直觀的收益。JSON 是事實(shí)上的通用數(shù)據(jù)交換格式無(wú)論是 Python、Go 還是 Node.js都有成熟的標(biāo)準(zhǔn)庫(kù)或者第三方庫(kù)可以解析。生產(chǎn)端和消費(fèi)端不再被綁定在 Java 體系內(nèi)只要雙方約定了字段結(jié)構(gòu)就能順利對(duì)接。還有一個(gè)容易被忽略的好處JSON 序列化機(jī)制本身更可控。像Jackson這樣的庫(kù)允許你通過(guò)注解控制字段忽略、命名策略、日期格式等細(xì)節(jié)靈活度比 JDK 原生序列化高很多。而且類型信息可以通過(guò)額外的消息屬性傳遞解析時(shí)不會(huì)因?yàn)槿笔ь愋投x而直接崩潰。所以結(jié)論很明確在新項(xiàng)目中直接配置 JSON 消息轉(zhuǎn)換器老項(xiàng)目也建議盡早切換。這套配置改動(dòng)量不大卻能讓整個(gè)消息鏈路的可維護(hù)性提升一個(gè)檔次。2. 消息轉(zhuǎn)換器的工作機(jī)制與選型2.1 從發(fā)送到接收的完整鏈路要配置好 JSON 轉(zhuǎn)換器先得搞清楚它在消息鏈路中處于哪個(gè)位置。生產(chǎn)者側(cè)RabbitTemplate.convertAndSend(exchange, routingKey, object)的調(diào)用鏈大致是方法入口 →convertMessageIfNecessary→MessageConverter.toMessage→ 返回Message實(shí)例 → 交給Channel發(fā)送。整個(gè)過(guò)程里轉(zhuǎn)換器負(fù)責(zé)把業(yè)務(wù)對(duì)象變成Message其中包含body字節(jié)數(shù)組和MessageProperties消息屬性。消費(fèi)者側(cè)是逆向過(guò)程。監(jiān)聽(tīng)容器收到消息后會(huì)調(diào)用MessageConverter.fromMessage把Message還原成業(yè)務(wù)對(duì)象再交給標(biāo)記了RabbitListener的方法。關(guān)鍵點(diǎn)在于生產(chǎn)者和消費(fèi)者的轉(zhuǎn)換器邏輯必須匹配。如果發(fā)送端用 JSON 序列化接收端還用默認(rèn)的 JDK 反序列化輕則解析異常重則直接消息丟失。這里還要注意一個(gè)細(xì)節(jié)RabbitTemplate本身可以獨(dú)立指定轉(zhuǎn)換器但監(jiān)聽(tīng)容器工廠也有自己的轉(zhuǎn)換器。SpringBoot 會(huì)自動(dòng)把容器里唯一的MessageConverterBean 注入到監(jiān)聽(tīng)容器工廠。如果你同時(shí)拉開(kāi)多個(gè)RabbitTemplate實(shí)例每個(gè)實(shí)例都要單獨(dú)設(shè)置轉(zhuǎn)換器否則很容易出現(xiàn)在一個(gè)地方改了、另一個(gè)地方?jīng)]改的尷尬情況。2.2 具體該選哪個(gè) JSON 轉(zhuǎn)換器實(shí)現(xiàn)Spring AMQP 體系中最常用的 JSON 轉(zhuǎn)換器是Jackson2JsonMessageConverter。這個(gè)類在舊版本中位于org.springframework.amqp.support.converter包新版本則遷移到了org.springframework.amqp.support.converter.jackson子包下。類名和核心方法基本一致依賴版本升級(jí)后代碼通常不需要改動(dòng)。選擇Jackson2JsonMessageConverter的理由有三個(gè)第一它是 Spring 官方維護(hù)的實(shí)現(xiàn)和RabbitTemplate、監(jiān)聽(tīng)容器等組件的兼容性最好不需要額外適配。第二它底層基于 Jackson本身支持ObjectMapper的自定義配置比如全局日期格式、空值處理策略等擴(kuò)展起來(lái)很順手。第三它默認(rèn)會(huì)在消息屬性中寫入類型信息頭消費(fèi)端靠這個(gè)頭信息還原具體的類比單純靠byte[]猜測(cè)要可靠得多。如果你的業(yè)務(wù)里消息都是統(tǒng)一的JSONObject或自由結(jié)構(gòu)數(shù)據(jù)也可以考慮直接用SimpleMessageConverter傳String或byte[]然后在業(yè)務(wù)代碼里手動(dòng)解析。但這種做法把序列化責(zé)任完全丟給了應(yīng)用層接口變更時(shí)容易出錯(cuò)。我的建議是只要消息對(duì)象是自定義 POJO就優(yōu)先用Jackson2JsonMessageConverter省心。3. 環(huán)境準(zhǔn)備與依賴引入3.1 快速搭建一個(gè)可運(yùn)行的 SpringBoot 項(xiàng)目在動(dòng)手配置之前先把基礎(chǔ)設(shè)施準(zhǔn)備好。這里以 SpringBoot 2.7 版本為例Maven 項(xiàng)目。需要引入的基礎(chǔ)依賴是spring-boot-starter-amqp它會(huì)連帶引入 Spring AMQP 和 RabbitMQ 客戶端庫(kù)。dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-amqp/artifactId /dependency如果你需要把消息內(nèi)容暴露成 HTTP 接口來(lái)測(cè)試發(fā)送和接收可以再加一個(gè)spring-boot-starter-web但這不是必須的。純粹的隊(duì)列收發(fā)場(chǎng)景只有 AMQP 這個(gè)依賴就夠了。配置文件方面最簡(jiǎn)單的連接信息如下spring: rabbitmq: host: 127.0.0.1 port: 5672 username: guest password: guest virtual-host: /生產(chǎn)環(huán)境建議使用獨(dú)立賬號(hào)不要用默認(rèn)的guest。guest賬號(hào)默認(rèn)只能在本地連接而且權(quán)限過(guò)大在任何遠(yuǎn)程環(huán)境下都會(huì)帶來(lái)安全隱患。3.2 定義業(yè)務(wù)消息對(duì)象為了演示效果我需要定義一個(gè)簡(jiǎn)單的消息 POJO。這里以用戶信息為例public class UserMessage { private Long id; private String name; private String email; // 必須提供無(wú)參構(gòu)造和 getter/setter // Jackson 反序列化依賴無(wú)參構(gòu)造 }需要注意Jackson在反序列化時(shí)依賴無(wú)參構(gòu)造函數(shù)。如果你只寫了帶參構(gòu)造沒(méi)有顯式提供無(wú)參構(gòu)造序列化沒(méi)問(wèn)題但反序列化階段會(huì)直接報(bào)錯(cuò)。這是非常常見(jiàn)的低級(jí)坑先提前標(biāo)記一下。字段命名上建議統(tǒng)一使用駝峰命名并在生產(chǎn)者和消費(fèi)者兩側(cè)保持一致。如果兩側(cè)的字段名不同Jackson 會(huì)把未知字段忽略掉結(jié)果就是接收方拿到一堆null。這種問(wèn)題不會(huì)拋異常排查起來(lái)特別費(fèi)勁。4. 核心實(shí)操JSON 消息轉(zhuǎn)換器的配置方式4.1 聲明 Jackson2JsonMessageConverter 的 Bean整個(gè)配置的核心就是一個(gè)Bean方法Configuration public class RabbitMessageConverterConfig { Bean public MessageConverter messageConverter() { return new Jackson2JsonMessageConverter(); } }這段代碼看起來(lái)簡(jiǎn)單但它同時(shí)解決了兩個(gè)方向的問(wèn)題。RabbitTemplate在發(fā)送時(shí)會(huì)自動(dòng)使用這個(gè)轉(zhuǎn)換器把對(duì)象序列化成 JSON 字節(jié)流監(jiān)聽(tīng)容器工廠在接收時(shí)會(huì)用同一個(gè)轉(zhuǎn)換器把 JSON 還原成對(duì)象。如果你需要自定義 ObjectMapper 的細(xì)節(jié)比如日期格式統(tǒng)一為yyyy-MM-dd HH:mm:ss可以這樣寫B(tài)ean public MessageConverter messageConverter(ObjectMapper objectMapper) { ObjectMapper customMapper objectMapper.copy(); customMapper.setDateFormat(new SimpleDateFormat(yyyy-MM-dd HH:mm:ss)); customMapper.setSerializationInclusion(JsonInclude.Include.NON_NULL); return new Jackson2JsonMessageConverter(customMapper); }這里我單獨(dú)copy了一個(gè) ObjectMapper而不是直接修改容器里的那個(gè)是為了避免影響 Http 接口的 JSON 序列化風(fēng)格。實(shí)際項(xiàng)目中很多人圖省事直接改全局 ObjectMapper結(jié)果接口返回?cái)?shù)據(jù)格式也跟著變了要是前端代碼沒(méi)跟上就會(huì)鬧出一堆問(wèn)題。4.2 確認(rèn) RabbitTemplate 真的用上了新轉(zhuǎn)換器只聲明一個(gè)MessageConverterBean在某些 SpringBoot 版本里默認(rèn)注入到RabbitTemplate的行為并不像你想象的那么自動(dòng)。最保險(xiǎn)的做法是顯式設(shè)置Configuration public class RabbitTemplateConfig { Bean public RabbitTemplate rabbitTemplate(CachingConnectionFactory connectionFactory, MessageConverter messageConverter) { RabbitTemplate rabbitTemplate new RabbitTemplate(connectionFactory); rabbitTemplate.setMessageConverter(messageConverter); return rabbitTemplate; } }這里傳入的MessageConverter正是上面定義的那個(gè) Bean。手動(dòng)setMessageConverter之后convertAndSend方法就會(huì)走 JSON 序列化路徑。為什么這么強(qiáng)調(diào)顯式配置因?yàn)槿绻阍诖a里手動(dòng)new RabbitTemplate(connectionFactory)SpringBoot 的自動(dòng)配置不會(huì)對(duì)它生效。我曾在一個(gè)多數(shù)據(jù)源項(xiàng)目里吃過(guò)這個(gè)虧連接工廠配了多個(gè)模板也是自己創(chuàng)建的結(jié)果消息發(fā)出去一直是 JDK 序列化格式檢查了半天才發(fā)現(xiàn)是模板沒(méi)有設(shè)置轉(zhuǎn)換器。4.3 消費(fèi)者側(cè)為什么一般不需要額外配置消費(fèi)者側(cè)的配置稍微有點(diǎn)繞。RabbitListener注解監(jiān)聽(tīng)的消息是由SimpleRabbitListenerContainerFactory處理的。SpringBoot 會(huì)自動(dòng)把容器里唯一的MessageConverterBean 注入到這個(gè)工廠里因此只要你聲明了轉(zhuǎn)換器 Bean消費(fèi)者就自動(dòng)支持 JSON 反序列化。不過(guò)前提是容器里只能有一個(gè)MessageConverter類型的 Bean。如果項(xiàng)目里有多個(gè)轉(zhuǎn)換器或者你自己額外定義了SimpleRabbitListenerContainerFactory那就需要手動(dòng)指定Bean public SimpleRabbitListenerContainerFactory rabbitListenerContainerFactory( SimpleRabbitListenerContainerFactoryConfigurer configurer, CachingConnectionFactory connectionFactory) { SimpleRabbitListenerContainerFactory factory new SimpleRabbitListenerContainerFactory(); configurer.configure(factory, connectionFactory); factory.setMessageConverter(new Jackson2JsonMessageConverter()); return factory; }如果你手寫了這個(gè)工廠卻又沒(méi)設(shè)置轉(zhuǎn)換器那監(jiān)聽(tīng)容器就會(huì)回到默認(rèn)的SimpleMessageConverter消息接收時(shí)就會(huì)嘗試 JDK 反序列化結(jié)果自然是各種ClassNotFoundException或類型不匹配。4.4 完整的發(fā)送與接收示例生產(chǎn)端代碼Service public class MessageProducer { private final RabbitTemplate rabbitTemplate; public MessageProducer(RabbitTemplate rabbitTemplate) { this.rabbitTemplate rabbitTemplate; } public void sendUserMessage(UserMessage user) { rabbitTemplate.convertAndSend(exchange.direct, user.created, user); } }消費(fèi)端代碼Service public class MessageConsumer { RabbitListener(queues queue.user.created) public void handleUserMessage(UserMessage user) { System.out.println(接收用戶: user.getName()); } }這里UserMessage在生產(chǎn)和消費(fèi)兩端都必須存在且包路徑、類名、字段結(jié)構(gòu)需要一致。如果兩端服務(wù)屬于不同應(yīng)用類名可以不同但接收方法的參數(shù)類型和 JSON 字段結(jié)構(gòu)必須對(duì)得上。后續(xù)我會(huì)詳細(xì)講跨服務(wù)不匹配時(shí)的處理辦法。5. 解碼 JSON 消息屬性與類型頭5.1 JSON 消息發(fā)出后里面到底有什么當(dāng)你用Jackson2JsonMessageConverter發(fā)送一個(gè)對(duì)象時(shí)最終消息的屬性會(huì)變得比較豐富。打開(kāi) RabbitMQ 管理后臺(tái)你會(huì)看到類似下面的信息headers: __TypeId__: com.example.UserMessage __ContentType__: application/json contentType: application/json__TypeId__是 Spring AMQP 自動(dòng)添加的類型頭記錄的是發(fā)送端的完整類名。消費(fèi)者解析時(shí)會(huì)優(yōu)先用這個(gè)頭信息來(lái)決定反序列化的目標(biāo)類型?？吹竭@里你就明白了發(fā)送端和接收端如果不在同一個(gè)項(xiàng)目里__TypeId__的值可能會(huì)不一致。比如發(fā)送端類名是com.example.producer.UserMessage接收端類名是com.example.consumer.UserDTO那消費(fèi)者直接按頭信息反序列化就會(huì)失敗。處理辦法有幾種后面講跨服務(wù)對(duì)接時(shí)再具體展開(kāi)。5.2 發(fā)送字符串或 Map 時(shí)的特殊表現(xiàn)如果你發(fā)送的不是對(duì)象而是String或MapJSON 轉(zhuǎn)換器的行為會(huì)有差異。對(duì)于String轉(zhuǎn)換器會(huì)直接序列化成一個(gè)帶雙引號(hào)的 JSON 字符串接收方拿到的String對(duì)象是正常的。對(duì)于Map轉(zhuǎn)換器會(huì)把每個(gè) key 和 value 都映射成 JSON 對(duì)象接收方會(huì)得到一個(gè)LinkedHashMap。如果你在消費(fèi)者里期待的是某個(gè) POJO但發(fā)送方發(fā)的是MapSpring 會(huì)嘗試把Map轉(zhuǎn)換成目標(biāo)類型前提是__TypeId__指明了正確的類。如果頭信息不匹配就會(huì)拋AmqpRejectAndDontRequeueException之類的異常。這個(gè)小坑困擾了不少初學(xué)者所以這里專門列出來(lái)提醒一下。5.3 消息冪等性與轉(zhuǎn)換器的邊界有一點(diǎn)要提醒消息轉(zhuǎn)換器只負(fù)責(zé)數(shù)據(jù)格式的轉(zhuǎn)換它不保證消息不重復(fù)。RabbitMQ 在消費(fèi)者異常斷開(kāi)、消息未確認(rèn)等場(chǎng)景下會(huì)重新投遞消息這屬于消息投遞語(yǔ)義層面的事和序列化格式無(wú)關(guān)。因此即使你把消息轉(zhuǎn)換器切成了 JSON依然需要在消費(fèi)端處理冪等性。常見(jiàn)手段是給每條消息生成唯一 ID消費(fèi)者根據(jù) ID 判斷是否處理過(guò)。這個(gè) ID 建議放在消息屬性里而不是塞進(jìn) JSON 字段中。這樣消費(fèi)端可以快速讀取屬性做判斷不需要先反序列化整個(gè)對(duì)象。6. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄6.1 消費(fèi)者收到亂碼或二進(jìn)制內(nèi)容現(xiàn)象消費(fèi)端打印消息時(shí)看到一堆\xAC\xED\x00\x05t...類似的字節(jié)流或者日志里出現(xiàn)Could not convert message的錯(cuò)誤。原因發(fā)送端用的是 JDK 序列化接收端配置的卻是 JSON 轉(zhuǎn)換器或者反過(guò)來(lái)。更常見(jiàn)的情況是發(fā)送端的RabbitTemplate沒(méi)有設(shè)置轉(zhuǎn)換器而接收端設(shè)置了 JSON 轉(zhuǎn)換器兩邊不對(duì)稱。排查思路打開(kāi) RabbitMQ 管理后臺(tái)查看消息的contentType。如果是application/x-java-serialized-object那發(fā)送端走的就是 JDK 序列化。檢查發(fā)送端RabbitTemplate是否顯式設(shè)置了MessageConverter。如果多個(gè)RabbitTemplate并存逐個(gè)確認(rèn)。6.2 消費(fèi)者報(bào) ClassNotFoundException現(xiàn)象監(jiān)聽(tīng)方法沒(méi)有執(zhí)行日志中出現(xiàn)ClassNotFoundException: com.example.some.UserMessage或IllegalArgumentException。原因發(fā)送端的消息類在消費(fèi)端不存在或者類名不一致。Jackson2JsonMessageConverter默認(rèn)會(huì)根據(jù)__TypeId__頭信息加載類加載不到就直接拋異常。處理辦法有三種方法一保證兩端類名一致這是最簡(jiǎn)單粗暴的方案。方法二在消費(fèi)端指定自定義ObjectMapper配置activateDefaultTyping策略或者通過(guò)setTypePrecedence調(diào)整類型解析規(guī)則。方法三接收方法參數(shù)直接使用Map或JsonNode繞開(kāi)類加載問(wèn)題。方法三在跨服務(wù)對(duì)接時(shí)非常實(shí)用。你的消費(fèi)者方法可以這樣寫RabbitListener(queues queue.user.created) public void handleMessage(JsonNode node) { String name node.get(name).asText(); // 業(yè)務(wù)處理 }這樣就不依賴消費(fèi)端是否存在UserMessage類只要 JSON 字段結(jié)構(gòu)對(duì)就行。缺點(diǎn)是失去強(qiáng)類型約束適合對(duì)接外部系統(tǒng)或者消息結(jié)構(gòu)頻繁變更的場(chǎng)景。6.3 發(fā) JSON 但消費(fèi)者拿到 LinkedHashMap現(xiàn)象發(fā)送和接收都成功但監(jiān)聽(tīng)方法參數(shù)如果是自定義 POJO拿到的卻是一個(gè)LinkedHashMap導(dǎo)致類型轉(zhuǎn)換異常。原因消費(fèi)者側(cè)沒(méi)有使用 JSON 轉(zhuǎn)換器消息被當(dāng)成了普通的字節(jié)流或 Map 映射。通常是監(jiān)聽(tīng)容器工廠沒(méi)有正確注入MessageConverter。排查方向確認(rèn)容器里MessageConverterBean 是否唯一。檢查自己是否自定義了SimpleRabbitListenerContainerFactory如果自定義了必須手動(dòng)設(shè)置轉(zhuǎn)換器。檢查RabbitListener所在的配置類是否被 SpringBoot 掃描到有時(shí)候配置類沒(méi)被加載轉(zhuǎn)換器 Bean 自然也就不生效。這個(gè)問(wèn)題的隱蔽性在于不報(bào)錯(cuò)但行為完全不符合預(yù)期。我遇到過(guò)好幾個(gè)同事排查到深夜最后發(fā)現(xiàn)只是配置類路徑?jīng)]被掃到。6.4 跨應(yīng)用傳遞時(shí)類型頭不一致生產(chǎn)者和消費(fèi)者分屬不同微服務(wù)時(shí)__TypeId__類頭幾乎必然不一致。兩個(gè)服務(wù)各自定義了自己的 DTO 類哪怕字段完全相同包路徑或類名也可能不同。此時(shí)如果消費(fèi)者強(qiáng)制要求強(qiáng)類型參數(shù)就會(huì)出現(xiàn)解析失敗。推薦的做法是統(tǒng)一使用自定義類型映射在消費(fèi)端配置setTypeIdMapper。也可以參考上面 6.2 的方法三直接用Map或JsonNode接收。如果團(tuán)隊(duì)內(nèi)的服務(wù)數(shù)量多我更推薦定義一套通用消息模型比如OrderMessage、PaymentMessage這類跨服務(wù)共享的 DTO 包然后全團(tuán)隊(duì)統(tǒng)一引用。這樣既保留強(qiáng)類型優(yōu)勢(shì)又避免類頭不一致。6.5 常見(jiàn)問(wèn)題速查表問(wèn)題現(xiàn)象可能原因首選排查動(dòng)作消息內(nèi)容顯示亂碼JDK 序列化與 JSON 序列化混用查看管理后臺(tái) contentType消費(fèi)報(bào) ClassNotFoundException兩端類名/包名不一致改用 Map 或 JsonNode 接收消費(fèi)拿到 LinkedHashMap監(jiān)聽(tīng)容器工廠未設(shè)置轉(zhuǎn)換器檢查 MessageConverter Bean消息發(fā)送成功但監(jiān)聽(tīng)無(wú)響應(yīng)隊(duì)列綁定錯(cuò)誤或路由鍵不匹配查看管理后臺(tái)隊(duì)列與綁定關(guān)系HTML 接口返回格式異常ObjectMapper 被全局修改使用 copy 或獨(dú)立 ObjectMapper7. 進(jìn)階玩法自定義消息轉(zhuǎn)換器與手動(dòng)獲取 Message7.1 繼承 AbstractMessageConverter 實(shí)現(xiàn)特殊邏輯有些場(chǎng)景下官方的Jackson2JsonMessageConverter滿足不了需求。比如消息體需要做加密壓縮后再發(fā)送或者需要在發(fā)送前對(duì) JSON 內(nèi)容做脫敏處理。這時(shí)候你可以自定義一個(gè)轉(zhuǎn)換器。核心思路是繼承AbstractMessageConverter重寫toMessage和fromMessage兩個(gè)方法public class EncryptMessageConverter extends AbstractMessageConverter { private final MessageConverter delegate new Jackson2JsonMessageConverter(); Override protected Message createMessage(Object object, MessageProperties messageProperties) { Message message delegate.toMessage(object, messageProperties); // 做加密、壓縮等其他處理 byte[] originalBody message.getBody(); byte[] encryptedBody encrypt(originalBody); return new Message(encryptedBody, message.getMessageProperties()); } Override public Object fromMessage(Message message) throws MessageConversionException { byte[] encryptedBody message.getBody(); byte[] decryptedBody decrypt(encryptedBody); return delegate.fromMessage(new Message(decryptedBody, message.getMessageProperties())); } }創(chuàng)建Message時(shí)需要注意MessageProperties里的contentLength要更新為處理后的字節(jié)長(zhǎng)度否則部分客戶端解析時(shí)會(huì)出問(wèn)題。這是個(gè)非常隱蔽的細(xì)節(jié)我第一次實(shí)現(xiàn)時(shí)就在這里栽了跟頭。自定義轉(zhuǎn)換器時(shí)還要重新考慮類型頭信息的寫入時(shí)機(jī)。委托給內(nèi)部Jackson2JsonMessageConverter處理時(shí)它會(huì)填充__TypeId__但如果你在createMessage之前就手動(dòng)構(gòu)建了MessageProperties要確保不會(huì)覆蓋掉已有屬性。7.2 手動(dòng)反序列化拿到原始 Message如果你不想改動(dòng)全局轉(zhuǎn)換器只想在特定的監(jiān)聽(tīng)方法里直接獲取原始數(shù)據(jù)可以把RabbitListener的方法參數(shù)聲明成Message然后手動(dòng)處理RabbitListener(queues queue.user.created) public void handleRawMessage(Message message) throws Exception { ObjectMapper mapper new ObjectMapper(); UserMessage user mapper.readValue(message.getBody(), UserMessage.class); // 業(yè)務(wù)邏輯 }這種方式靈活但犧牲了自動(dòng)轉(zhuǎn)換的便利性適合特殊場(chǎng)景下的臨時(shí)處理。在大部分業(yè)務(wù)代碼中我仍然建議優(yōu)先讓框架自動(dòng)完成對(duì)象轉(zhuǎn)換保持代碼干凈。7.3 關(guān)于平滑遷移的一點(diǎn)經(jīng)驗(yàn)老項(xiàng)目從默認(rèn)轉(zhuǎn)換器切換到 JSON 轉(zhuǎn)換器時(shí)最穩(wěn)妥的做法是先消費(fèi)端灰度再切換生產(chǎn)端。具體來(lái)說(shuō)先讓消費(fèi)端兼容兩種格式等生產(chǎn)端切換完成后再逐步下線舊格式解析邏輯。因?yàn)槟阋坏┌焉a(chǎn)端切到 JSON隊(duì)列里殘留的 JDK 序列化消息就再也無(wú)法被消費(fèi)了。生產(chǎn)環(huán)境如果存在大量積壓舊消息直接切換會(huì)造成數(shù)據(jù)丟失。這里的建議是把隊(duì)列與交換機(jī)先解綁等舊消息消費(fèi)完再切換新格式。這樣雖然操作繁瑣一點(diǎn)但能保證消息不丟。8. 最后分享一點(diǎn)我實(shí)際使用的體會(huì)做消息中間件集成最怕的就是只跑通正常流程卻不理解鏈路背后的組件協(xié)作方式。消息轉(zhuǎn)換器這個(gè)環(huán)節(jié)看起來(lái)只是一個(gè) Bean 的事實(shí)際上連接著發(fā)送模板、監(jiān)聽(tīng)容器、類型解析和多服務(wù)協(xié)作。把配置原理搞懂之后很多奇奇怪怪的現(xiàn)象都能快速找到根因。比如亂碼問(wèn)題不用猜直接看管理后臺(tái)的contentType就能定位是 JDK 序列化還是 JSON 序列化再比如消費(fèi)者拿到LinkedHashMap大概率是容器工廠沒(méi)有生效查配置類掃描路徑和 Bean 唯一性就能解決。我在實(shí)際項(xiàng)目中體會(huì)最深的還是跨服務(wù)類型頭不一致這個(gè)問(wèn)題。只要服務(wù)一多類路徑統(tǒng)一約束就變得很難執(zhí)行。所以我現(xiàn)在設(shè)計(jì)新系統(tǒng)時(shí)會(huì)直接把通用消息模型抽成獨(dú)立依賴包所有服務(wù)引用同一套 DTO。這樣既享受強(qiáng)類型編碼的便利又避免__TypeId__帶來(lái)的類加載風(fēng)險(xiǎn)。如果你正在做一個(gè)多微服務(wù)互通消息的新項(xiàng)目建議從一開(kāi)始就把這套規(guī)范定下來(lái)省得后面踩坑。