之前公司没有使用msmq/rebbitmq等消息队列，一方面是觉得太重，想避免在引入中间件。另外的原因是公司的业务并不需要消息持久化和确保可送达（at-least-once VS at-more-once）。所以在一番调研之后，选择了nats:（https://nats.io/）用它来当消息队列使用。
nats的优点：
1.使用简单:github(https://github.com/nats-io/gnatsd)上直接clone下源码 go build 即可。
2.无需多配置:client端只需知道nats的节点和约定好的subject名称即可
3.快！由于nats的特性，只发送不确认送达
4.有多种客户端支持，由于公司有.net和go的代码，所以需要可以跨语言的消息中间件
5.拥抱开源，我很喜欢
项目上线了半年，发现了如下问题:
1机房出现故障，导致nats server端需要重连，但是我们运维实践下来发现说进程需要手工重启
2还是nats timeout后，需要在reconnection里要重新初始化连接，不方便
3我们使用thrift作为消息编码，感觉编码后的消息臃肿，不如protobuf
4需求的变更，谁知道会不会改成消息不可以丢失呢。。
于是决定替换为consul+grpc
consule:解决的是服务健康监控和服务发现的问题，一样对外只暴露一个IP
grpc:天生使用http2+protobuf3，编码和传输上不逊于thrift,而且对于熟悉thrift的同学来说pb3点语法so easy
再也不用担心丢数据的问题了～