轉自： https://toutiao.io/posts/p883vaw/preview
參考翻譯自NATS官方文檔
https://nats-io.github.io/docs/
NATS
NATS是一個開源、輕量級、高性能的分布式消息中間件，實現了高可伸縮性和優雅的Publish/Subscribe模型，使用Golang語言開發。
NATS消息傳遞支持在計算機應用程序和服務之間交換分段為消息的數據。這些消息由主題解決，不依賴於網絡位置。這在應用程序或服務與底層物理網絡之間提供了一個抽象層。數據被編碼並構成消息並由發布者發送。該消息由一個或多個訂戶接收，解碼和處理。
NATS使程序可以輕松地跨不同環境，語言，雲提供商和內部部署系統進行通信。客戶端通常通過單個URL連接到NATS系統，然后訂閱或發布消息給主題。通過這種簡單的設計，NATS允許程序共享公共消息處理代碼，隔離資源和相互依賴性，並通過輕松處理消息量的增加進行擴展，無論是服務請求還是流數據。
NATS核心提供最多一次的服務質量。如果訂戶沒有收聽主題（沒有主題匹配），或者在發送消息時未激活，則不會收到消息。這與TCP / IP提供的保證級別相同。默認情況下，NATS是一種即發即棄的消息傳遞系統。如果您需要更高級別的服務，您可以使用NATS Streaming或通過經過驗證的可擴展參考設計為客戶端應用程序構建額外的可靠性。
NATS基於主題的消息傳遞
從根本上說，NATS是關於發布和收聽消息的。這兩者都嚴重依賴於將消息范圍限定為流或主題的主題。最簡單的是，主題只是一串字符，形成了發布者和訂閱者可以用來互相查找的名稱。
NATS服務器保留一些特殊的字符，規范說只有“字母數字”字符加上“.” 應該在主題名稱中使用。主題區分大小寫，不能包含空格。為了跨客戶端安全，應使用ASCII字符，盡管將來可能會有所變化。
主題層次結構
字符.用於創建主題層次結構。例如，世界時鍾應用程序可能會定義以下內容以對相關主題進行邏輯分組：
time.us time.us.east time.us.east.atlanta time.eu.east time.eu.warsaw
通配符
NATS提供了兩個通配符，可以取代點分隔主題中的一個或多個元素。訂閱者可以使用這些通配符通過單個訂閱來收聽多個主題，但是發布者將始終使用完全指定的主題，而不使用通配符
匹配單個令牌
第一個通配符是*，它將匹配單個標記 。例如，如果應用程序想要偵聽東部時區，則可以訂閱time.*.east，這將匹配time.us.east和time.eu.east。
匹配多個令牌
第二個通配符是>將匹配一個或多個令牌，並且只能出現在主題的末尾。例如，time.us.>將匹配time.us.east和time.us.east.atlanta，而time.us. *只匹配time.us.east，因為它不能匹配多個令牌。
監控和線控
根據您的安全配置，可以通過創建有時稱為有線點擊的內容來使用通配符進行監控。在最簡單的情況下，您可以為>創建訂戶。此應用程序將接收所有消息 -- 再次，根據安全設置 -- 在NATS群集上發送。
發布與的訂閱
NATS為一對多通信實現發布 - 訂閱消息分發模型。發布者在主題上發送消息，並且監聽該主題的任何活動訂閱者都會收到該消息。訂閱者還可以注冊對通配符主題的興趣，這些主題有點像正則表達式（但只是一點點）。這種一對多模式有時被稱為扇出。
通過瀏覽pub-sub教程，使用實時服務器自己嘗試NATS發布訂閱。
請求-回復
Request-Reply是現代分布式系統中的常見模式。發送一個請求，應用程序要么在響應時等待一定的超時，要么異步接收響應。現代系統復雜性的增加需要諸如位置透明度，放大和縮小，可觀察性等功能。許多技術需要額外的組件，側面卡和代理才能完成完整的功能集。
NATS通過其核心通信機制，發布和訂閱支持這種模式。對具有回復主題的給定主題發布請求，並且響應者聽取該主題並將回復發送給回復主題。回復主題通常是一個名為_INBOX的主題，它將被動態地定向回請求者，而不管任何一方的位置如何。
NATS允許多個響應者運行並形成動態隊列組以進行透明擴展。NATS應用程序在退出之前消耗的能力允許縮小而不會丟棄請求。由於NATS基於發布 - 訂閱，因此可觀察性就像運行另一個可以查看請求和響應以測量延遲，注意異常，直接可伸縮性等的應用程序一樣簡單。
NATS的強大功能甚至允許在使用第一個響應的情況下進行多次響應，系統會有效地丟棄其他響應。這允許復雜的模式使多個響應者減少響應延遲和抖動。
隊列訂閱和可擴展性
NATS提供稱為分布式隊列的內置負載平衡功能。使用隊列訂戶將平衡一組訂戶的消息傳遞，這可以用於提供應用程序容錯和擴展工作負載處理。
要創建隊列訂閱，訂戶會注冊隊列名稱。具有相同隊列名稱的所有訂戶構成隊列組。這不需要配置。當發布已注冊主題上的消息時，隨機選擇該組中的一個成員來接收該消息。盡管隊列組具有多個訂戶，但每個消息僅由一個消息使用。
NATS的一個重要特性是隊列組由應用程序及其隊列訂戶定義，而不是在服務器配置上定義。
隊列訂戶是擴展服務的理想選擇。向上擴展就像運行另一個應用程序一樣簡單，向下擴展是使用一個消耗飛行中請求的信號來終止應用程序。這種靈活性和缺乏任何配置變化使NATS成為一種優秀的服務通信技術，可以與所有平台技術協同工作
應答
在具有最多一次語義的系統中，有時可能會丟失消息。如果您的應用程序正在執行請求 - 回復，則應使用超時來處理任何網絡或應用程序故障。在請求上設置超時並擁有處理超時的代碼總是一個好主意。當您發布事件或數據流時，確保消息傳遞的一種方法是將其轉換為具有確認消息或ACK的概念的請求 - 答復。在NATS中，ACK可以簡單地是空消息，即沒有有效載荷的消息。
序列
一對多消息的常見問題是消息可能由於網絡故障而丟失或丟失。解決這種情況的一個簡單模式是在消息中包含序列id。接收方可以檢查序列ID以查看它們是否遺漏了任何內容。在沒有新數據的情況下，序列號與心跳相結合形成了一種強大而有彈性的模式來檢測損失。存儲和保留消息的系統也可以解決這個問題，但有時對於手頭的問題來說是過度的，通常會導致額外的管理和運營成本。
為了真正利用序列ID，需要記住以下幾點：
-
每個發件人都必須使用自己的序列
-
如果可能，接收者應該能夠通過id詢問丟失的消息
使用NATS，您可以在消息中嵌入序列ID，或將它們作為令牌包含在主題中。例如，發件人可以將消息發送到updates.1，updates.2等……訂閱者可以監聽更新.*並解析主題以確定序列ID。如果有效載荷未知或者在有效載荷中嵌入諸如序列號之類的附加數據是不可能的，則可能需要將序列令牌放入主題中。
以上文章參考翻譯自NATS官方文檔
https://nats-io.github.io/docs/