轉自：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/