共计 3028 个字符，预计需要花费 8 分钟才能阅读完成。
使用 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 自适应边缘架构示例分析的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注丸趣 TV 行业资讯频道，感谢各位的阅读！
