背景

專案第一次引入spring boot 封裝的rabbitMQ框架，用於接收庫存狀態的訊息，用於實時更新。

踩坑過程

踩坑一：資料格式約定

rabbitMQ開發過程中雙方需要提前約定以下資料：

• exchang :訊息交換機，指定訊息的路由傳送規則
• routing key：路由關鍵字，exchange根據關鍵字進行訊息投遞
• 資料格式：一般為application/json
• exchange型別（fanout,topic,direct等）

上圖為拿到的資料格式約定，exchange為topic。然而除錯過程中遇到以下問題

• 生產方在未通知的情況下，多次修改routing key,導致除錯過程中我消費方多次修改程式碼
• 約定資料格式為json,生產方由於不熟悉spring cloud配置，給到的資料格式為text/plain。生產方經過一天的除錯，終於發現只需要在配置檔案中增加spring.cloud.stream.bindings.myOutPut.content-type=application/json配置即可。至此，終於可以接收到json格式資料了。
• 約定的格式是JSON,但是生產方實際給到的格式是JSONARRAY,導致我消費方解析資料出錯。

以上，讓我深刻體會到契約精神多麼重要。由於種種資料格式問題，嚴重拖慢了開發進度。然鵝，生產方其實並未意識到這個問題，潛意識認為自己處於資料鏈路的上游，就可以隨意修改約定好的格式

踩坑二 ：exchange型別

終於開心（kubi)的完成了開發測試過程，準備開開心心線上做釋出了。結果程式碼在部署過程中大量報錯，伺服器直接done掉了。檢視報錯資訊

method<channel.close>(reply-code=406,reply-text=PRECONDITION_FAILED - inequivalent arg 'type' for exchange 'sim2es' in vhost '/': received 'topic' but current is 'fanout',class-id=40,method-id=10)
複製程式碼

exchange需要fanout型別，我消費方定義的是topic型別。 什麼鬼，明明測試環境是topic型別，到線上搖身一變變成廣播fanout了？經過與生產方溝通，發現生產方為了自己做線上消費的測試，上線的時候把exchange型別順手改成了fanout，導致與我消費方的topic型別不匹配，消費方直接宣告queue報錯。 生產方是沒有想到這樣改會導致exchange型別不匹配？還是其實根本不知道這個知識點，咱也不敢問。直接讓他老老實實把exchange型別改回topic。

以上，每個開發都應該嚴格按照開發規範，熟悉mq的各個欄位的含義和用法，而不是不動腦筋就隨便亂改，害人害己啊。

在不熟悉的領域更應該多檢視資料，由於開發大量使用框架，一些底層的東西被很好的封裝了起來，多閱讀原始碼，才能更好去使用框架