使用 Docker 部署 RabbitMQ

为了更加熟悉我们现在所使用的微服务架构，了解每一个组件的特性，我将部署在 lc0 上的一系列微服务组件（网关、注册中心、配置中心、熔断监控等）尝试重新在 lc7 机器上再部署一遍。

在部署配置中心时，需要依赖一个 MQ 组件，项目中用的是 RabbitMQ，所以我需要在 lc7 上安装它。

RabbitMQ 是用 Erlang 编写的，直接部署的话需要先部署 Erlang 环境，比较麻烦。在 docker 环境下部署就比较简单了，直接使用 RabbitMQ 官方提供的镜像即可。

直接安装的方式可以参考 http://blog.didispace.com/spring-boot-rabbitmq/ 这篇文章，下边我主要来说下如何使用 Docker 部署 RabbitMQ。

运行 docker pull rabbitmq:management 从官方下载镜像到本地，这里使用的是带 Web 管理插件的镜像。

启动容器：

1
2
3

docker run -d --name rabbitmq --publish 5671:5671 \
 --publish 5672:5672 --publish 4369:4369 --publish 25672:25672 --publish 15671:15671 --publish 15672:15672 \
rabbitmq:management

容器启动之后就可以访问 Web 管理界面了 http://IP:15672

默认创建了一个 guest 用户，密码也是 guest。

通过这种方式来部署 RabbitMQ 非常方便，今后可以在部署测试环境时用起来，因为我们还没有大规模使用 Docker，所以暂时不建议在生产环境来使用。

AMQP 协议中的几个重要概念

Queue 是 RabbitMQ 的内部对象，用于存储消息。RabbitMQ 中的消息只能存储在 Queue 中，消费者从 Queue 中获取消息并消费。
Exchange 生产者将消息发送到 Exchange，由 Exchange 根据一定的规则将消息路由到一个或多个 Queue 中（或者丢弃）。
Binding RabbitMQ 中通过 Binding 将 Exchange 与 Queue 关联起来。
Binding key 在绑定（Binding） Exchange 与 Queue 的同时，一般会指定一个 binding key。
Routing key 生产者在将消息发送给 Exchange 的时候，一般会指定一个 routing key，来指定这个消息的路由规则。 Exchange 会根据 routing key 和 Exchange Type 以及 Binding key 的匹配情况来决定把消息路由到哪个 Queue。
Exchange Types RabbitMQ 常用的 Exchange Type 有 fanout、 direct、 topic、 headers 这四种。
- fanout 这种类型的 Exchange 路由规则非常简单，它会把所有发送到该 Exchange 的消息路由到所有与它绑定的 Queue 中，这时 Routing key 不起作用。
- direct 这种类型的 Exchange 路由规则也很简单，它会把消息路由到那些 binding key 与 routing key完全匹配的 Queue 中。
- topic 这种类型的 Exchange 的路由规则支持 binding key 和 routing key 的模糊匹配，会把消息路由到满足条件的 Queue。 binding key 中可以存在两种特殊字符 与 #，用于做模糊匹配，其中 用于匹配一个单词，# 用于匹配多个单词（可以是零个），单词以 . 为分隔符。
- headers 这种类型的 Exchange 不依赖于 routing key 与 binding key 的匹配规则来路由消息，而是根据发送的消息内容中的 headers 属性进行匹配。