之前公司沒有使用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
再也不用擔心丟數據的問題了～