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

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

转载于:https://www.cnblogs.com/LoveJerryZhang/p/6340391.html

你可能感兴趣的:(为什么我最终替换掉了NATS)