分布式系统连接问题克服：航空航天
作者：Jason Myers / 开发者
2024年6月28日
导航至
轨道上的航空航天操作维护和维修是一个相当大的挑战。将技术人员派往卫星上修复组件并不容易。这就是为什么在发射和部署这类设备之前，尽可能多地规划各种场景变得越来越关键。
为了了解轨道设备的情况，公司需要数据。如果数据流中断，优先级变为重新建立它，以避免昂贵的设备变得无用。
企业可以采用多种策略来帮助缓解或克服分布式系统中糟糕或不稳定的连接问题。在这里，我们假设有无数边缘设备试图向中心节点发送数据。
传输前
在尝试传输数据之前，您可以在本地实施一些策略来提高传输效率。其中一些将取决于设备上的资源，但同时，可用的资源应反映由连接问题产生的潜在需求。
- 数据缓存：当您需要使用一些本地生成的一些数据时，这尤其有用。将数据缓存到设备上，以便在设备等待将其传输到中央集线器时可以使用，可以帮助保持系统运行。
- 压缩：这很简单。尽可能多地压缩数据以减少发送数据到中央集线器所需的吞吐量。
- 优先级调度：某些数据比其他数据更重要吗？提前知道这一点并优先传输这些数据可以确保它们在有限的连接窗口内更有可能到达中央集线器。
- 校验和和散列：如果您担心数据损坏，可以在本地为该数据生成校验和或散列。将这些校验和包含在传输中可以帮助中央集线器验证数据。
传输
您可以使用许多方法为您的数据内置保障措施。虽然这份列表远远不够全面，但希望它能帮助您开始讨论。
工具
我将这部分内容进一步拆分，因为您最终选择的工具可能会影响您的配置选项。因此，让我们看看一些可以帮助您轻松利用不同配置选项的工具。
InfluxDB：这应该不会让人感到意外，但拥有一个本地的时间序列数据库实例可以帮助管理设备上各种系统和传感器的所有数据。特别是，一个支持边缘数据复制（EDR）的单节点实例是理想的。此功能创建了一个持久、本地的数据队列，以便在您的连接失败或中断时，数据库继续收集这些数据，并在连接恢复后刷新队列。
Kafka：使用Kafka队列是另一种对抗间歇或不稳定连接的方法。Kafka队列的工作方式与标准发布-订阅不同。队列系统将数据保存到队列中，一旦应用程序读取了这些数据，它就会被移除。（在发布-订阅方法中，数据可以持久化，因此读取后不会被清除。）多个设备可以向同一个队列发布，这对于队列具有可靠连接的情况很有帮助。与InfluxDB一样，Kafka队列在水平扩展方面表现良好，非常适合分布式系统。
配置
在InfluxDB和Kafka之间，您应该能够收集和存储您的数据。配置应用程序逻辑以解决连接问题是一项完全不同的任务。以下是一些需要考虑的概念和方法。
- 动态调整：这涉及根据当前连接条件调整传输速率和方法。在连接不良的时期，您希望这种应用程序逻辑降低传输速率或切换到更健壮的协议来传输数据。
- 前向纠错（FEC）：这将验证数据的负担放在接收器身上，因此如果您的边缘设备资源有限，这是一种可行的解决方案。此方法在传输中包含额外的数据，允许接收器检测和纠正错误，而无需重传。上面提到的生成校验和或散列的方法可以放入这个类别，尽管无疑还有其他选项。
- 边缘计算：在这里，拥有边缘数据库非常有用。如果您有可用资源，您可以在边缘本地处理数据，只将清洗和处理的数发送到中心枢纽。这可以最小化您需要传输的数据总量。
- 延迟容忍网络（DTN）：这是一种存储和转发的策略。DTN协议非常适合经历长时间延迟和中断的环境。这类似于消防员接力运水，数据存储在中间节点，直到有连接可以将其转发到中心枢纽。
- 优化路由算法：这里有几种选项属于这个类别。
- 机会路由：这涉及到编写您的应用程序逻辑，以利用任何可用的通信机会来转发数据。您可以通过根据当前网络条件动态选择路径来实现这一点。
- 多路径路由：而不是依赖于单一的数据传输路径，考虑配置多条路径以增加成功交付的机会。如果您将数据发送到中心InfluxDB实例，数据库具有自动去重的功能。这种方法可能会导致更多的聚合数据传输，因此最好将其作为备份策略，而不是克服连接问题的主要策略。
- 低带宽和高延迟网络的协议
- 轻量级协议：在合理的情况下，您可以使用为低带宽环境设计的通信协议，例如使用限制应用协议（CoAP）而不是HTTP。
- 高延迟协议：同样，您可以依赖可以处理高延迟的现有协议，例如针对长距离通信优化的TCP变体。
总结
尽管不太可能存在任何单一的配置选项是航空航天公司所寻找的万能药，但动态应用程序逻辑的组合以及拥有收集和管理您数据的正确工具，可以在很大程度上克服不可靠或间歇性连接问题。
