为什么我最终替换掉了NATS

　　之前公司没有使用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

　　再也不用担心丢数据的问题了～