簡介
滿世界的后台都在向微服務架構發展，我對微服務的理解是將一個復雜的業務分拆為多個服務，由多個服務協作完成一個服務；在后台微服務架構時需要考慮高可用、一致性等問題，也要考慮在實現上、編碼上的復雜程度，大多同行采用消息服務中間件對服務進行解耦，微服務多個服務間通過消息中間件進行通信。當然有不少做法是采用RPC方式，當服務多、出現網狀RPC調用就會很復雜，管理上也不太方便。
之前我們采用NSQ進行通信（開發語言JAVA&Golang）,NSQ的離線消息存儲功能也蠻好用，如果程序掛了，重啟后不會丟消息。
為什么用NAT替換NSQ，各有什么優缺點
| 特性 | NSQ | NAT |
|---|---|---|
| 離線 | 支持 | 不支持 |
| 實時性 | 准實時 | 准實時 |
| 請求-應答 | 需自行封裝 | 自帶 |
NSQ的離線功能與消息順序
- 當程序掛掉重啟后可以繼續接收處理消息，保證消息不丟失，這項功能對實時性要求不高的業務是非常好用的，可以異步模式，PUB端發送到NSQ就ok，無需關心SUB端處理成功與否以及處理及時性；
- 消息是可能亂序的，這種情況出現在既有離線消息又有內存實時消息的時候，NSQ是不保證絕對的消息順序的；
NSQ的請求-應答模式
- NSQ本身只提供PUB-SUB，沒有請求-應答模式，需要自己進行封裝，當然也很簡單；在某些業務場景使用純異步模式不太合適，需要類似RPC的請求-應答模式；
使用NSQ消息中間件，部署應用服務（主備、雙主）
以下例子以單個微服務部署兩個應用為例子
- 兩個應用訂閱相同主題，使用相同的CHANNEL，同一條消息只有一個應用接收到，比如鑒權接口，只要一個鑒權通過即可；
- 兩個應用訂閱相同主題，使用不同的CHANNEL，同一條消息兩個應用接收到，比如處理臨時內存數據，兩個應用都需要更新自身內部內存數據；
NAT的優勢（什么性能之類的就不說，基本上都滿足需求的）
參考 http://blog.csdn.net/chszs/article/details/50996679
- PUB/SUB模型 針對同一個主題只有訂閱了都可以接收到，掉線了就接收不到（不存儲離線消息）
- Request/Reply模型 當有多個訂閱者收到請求后，只需要其中一個處理成功並Reply即算成功
- 隊列模型 在PUB/SUB和Request/Reply上增加隊列模型，同一條消息只有一個訂閱者接收到
- 使用隊列模型，當有多個訂閱者時是隨機選擇訂閱者發送消息，不保證負載均衡（切記）
以上，NAT支持異步調用、同步調用，雙主、主備模式，假負載模式；做內部消息通信、為微服務架構解耦是非常合適的。
PS:參考