背景
项目第一次引入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的各个字段的含义和用法，而不是不动脑筋就随便乱改，害人害己啊。
在不熟悉的领域更应该多查看资料，由于开发大量使用框架，一些底层的东西被很好的封装了起来，多阅读源码，才能更好去使用框架
