为何我最终替换掉了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

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