爲何我最終替換掉了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

　　不再用擔憂丟數據的問題了～