使用NATS的Synadia自適應邊緣架構示例分析

使用NATS的Synadia自適應邊緣架構示例分析，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

概述

在Synadia，我們的目標是統一所有云、邊緣和物聯網通信。我們引導公司從現在開始，高效地運行安全和彈性的現代分布式通信系統，并利用NATS.io項目，使他們通往那里。Derek Collison，NATS的創造者，創建了Synadia，負責NATS項目。

我們看到用戶以幾個方式部署NATS--單個集群K8s部署、云中的NATS服務器集群、VM上或裸機上。隨著公司的發展，我們看到許多多地區的部署在地理上分散開來，在數據中心，在云提供商之間，或者現在更常見的是混合部署。

最近，我們看到出現了一種模式，即由一組應用程序從邊緣節點服務和接收數據。通常有來自邊緣的遙測，有時邊緣節點有他們自己的命令和控制服務和訪問本地數據。這并不罕見--這是物聯網模式下的聯合邊緣計算。

企業將計算推向了邊緣時，真正有趣的是，我們看到這種模式應用到許多不同的垂直市場。通常，用戶將不同的技術與不同的安全域結合在一起，必然導致系統脆弱、不安全且維護成本高昂。使用我們所謂的自適應邊緣架構（Adaptive Edge Architecture）--一種覆蓋NATS多租戶安全模型的靈活部署拓撲--可以很好地避免這個問題。

安全

在NATS 2.0中，我們圍繞操作員（Operator）、帳戶（Account）和用戶（User）的概念增強了安全性。操作員是NATS部署的所有者，如公司、云提供商、CDN服務、邊緣提供商或移動運營商。操作員創建帳戶--可以把帳戶想象成“消息傳遞的容器”--真正的多租戶。帳戶可能包含代表一組應用程序、區域部署或業務單元的用戶。注意，我們正在走向零信任，因此在操作員模式中，即使使用帳戶和用戶的概念，NATS系統也不會存儲或訪問私有NATS密鑰。

https://docs.nats.io/nats-tools/nsc/nsc#creating-an-operator-account-and-user

當NATS客戶端連接時，它的憑證表明它屬于一個特定的帳戶。它的主題命名空間（它可以在其中發送和接收數據）只存在于它的帳戶中。這意味著在默認情況下，數據永遠不會穿越帳戶邊界，客戶端只能與同一帳戶中的其他客戶端直接通信，即使使用在其他帳戶中發現的相同主題。

但是，帳戶可以與其他帳戶一起導出和導入流（想想遙測）或服務（想想RPC），允許安全地共享特定數據和映射主題，有效地從應用程序主題命名空間分離數據訪問。在部署中，流和服務可以對所有帳戶進行公開導入，也可以為遵守最嚴格的安全策略而進行保密。由于安全性確實與連接分離，帳戶可能只存在于服務器的一個子集上，以創建數據豎井。

部署拓撲

除了NATS 2.0中的安全性之外，我們還希望解決輕松可靠地將不同區域的NATS服務器集群連接在一起的問題。在興趣傳播方面，對于大多數用例來說，一個分布在不同區域的大型NATS集群過于通信量大，因此我們創建了超級集群的概念，它通過網關連接將許多集群連接在一起。這種基于樣條（spline）的架構具有多個連接的彈性，同時對興趣傳播進行智能處理，從而自動減少冗余。這對于以當今的數據速率進行長距離傳輸或帶寬較低的連接來說是必要的優化。

在執行此操作時，Derek（NATS的創造者）提出了葉節點的概念，其中NATS服務器可以連接到群集，并且比服務器更像是客戶端，從而擴展了群集，從而有可能橋接安全域。同時在本地應用程序之間提供最佳延遲。當與遠程集群斷開連接時，它仍然可以工作。當時，我們不能確切地確定葉子節點將如何被接收，但有一些跡象表明它可能是一個休眠節點。

https://docs.nats.io/nats-server/configuration/leafnodes

事實證明，這比我們想象的要強大得多。然后，當與NATS 2.0安全性相結合時，我們最終得到了個真正優雅的解決方案，可以使用邊緣計算處理大規模聯邦部署--自適應邊緣架構。

使用NATS的Synadia自適應邊緣架構

這是相當簡單的。在后端建立許多NATS集群—-在數據中心、云、裸金屬或混合—-這對NATS無關緊要。然后通過葉節點將連通性擴展到邊緣，創建了一個龐大的數據連通性平面。這是第一層，就像數據的電網。安全性是下一個問題--將NATS安全性看作是一種開關，它精確地確定哪些數據可以流到哪里，應用程序連接受到NATS帳戶的限制，并且通過導入和導出流和服務來共享數據。將此部署模型與NATS多租戶特性相結合，你就可以創建一個既可管理又安全的真正大型系統。

因為帳戶包含自己的主題命名空間，所以每個邊緣部署看起來都完全相同，不會出現主題沖突。不再需要有會議決定如何分層設置命名空間！它是隔離的，這意味著你的應用程序很容易增強，并且不會影響系統的其他部分。導出和導入可以允許任何允許的NATS客戶端安全地、無縫地與部署中的任何其他允許的NATS客戶端交互。因為NATS服務器存在于邊緣，所以當與網絡分離時，你的遠程服務仍然可以自主操作。

這還可以將基于SaaS的系統與私人擁有和運營的系統混合匹配。我們在NGS中看到了這種模式的上升趨勢，用戶運行葉節點用于本地安裝，然后遠程連接以實現安全可靠的全球通信。

https://synadia.com/ngs

有意的數據豎井

雖然你將擁有完整的連接，但數據流應該受到限制，有時應該隔離在有限訪問的豎井中。人們可能會為了可管理性而這樣做--在邊緣聚集大量的傳感器數據，然后使用AI以流的方式提供有意義的上下文。或者，你可能需要執行一些策略，比如在一組服務器中保存有關運行狀況的醫療數據，以滿足GDPR遵從性。帳戶設置將保證數據永遠不會離開一個位置，除非它應該。

簡單的客戶端

不管安全性和部署拓撲如何，NATS客戶端仍然很簡單，因為它們只關心連接、發布和/或接收數據。不維護任何服務器狀態，允許你隨時伸縮或更改NATS服務器部署，而不影響客戶端，有效地驗證你的技術解決方案的未來性。

示例用例--工業4.0

讓我們看一個制造用例。隨著制造業繼續向工業4.0過渡，與制造過程相關的元數據比以往任何時候都更有價值。IIoT的采用創造了大量的數據。機器的溫度波動可用于預測故障分析，而零部件的元數據可能需要存儲數十年（例如航空）。其中大部分需要以極低的延遲來處理，在這種情況下，向云中的后端或遠程數據中心發送是站不住腳的。

工廠

我們有一條工廠生產線，有設備、傳感器、質量控制，有AR協助工程師，有AI監視和智能聚合數據。順便說一句，NATS在Unity平臺上工作得非常好，后者正在應用于工業4.0。

https://unity.com/solutions/automotive-transportation-manufacturing

總部、工廠和配送中心

從總體上看，我們有總部、配送中心和工廠。注意，所有這些都是連接的，數據通過NATS交換。雖然沒有圖，但數據的流和可用性是由帳戶決定的。這只是一個簡單的圖表；可以使用自適應邊緣架構提供供應鏈，以提供優化物流、庫存等的服務。

應用于垂直市場

看完上述內容，你們掌握使用NATS的Synadia自適應邊緣架構示例分析的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！