有多个双向通信流的系统最简洁的软件设计是什么？

Question

到目前为止我收到的答复帮助我制定了TLDR:

目前，观察者模式的实现是为了从传感器-执行器模块获取到单个蓝牙服务和LwM2M对象的信息。执行器也应该是可以控制的蓝牙/LwM2M。这可以通过让所有单独的蓝牙服务/ LwM2M对象直接连接到传感器-执行器模块来解决。

这导致模块之间有很多链接，而其中许多服务/对象需要相同的数据。当服务/对象需要相同的数据时，这种方法似乎是不可伸缩和丑陋的。

因此，问题(这可能只是服务/对象设计中的一个设计缺陷)：

当试图通过将数据采集移动到一个层并将数据分配给依赖的服务/对象来减少模块和服务/对象之间的链接时，执行器-部分变得更加困难，因为服务/模块失去了与那些传感器-执行器模块的直接链接。

原始(长)问题描述：

我有一个与外界有两个接口的系统: LwM2M和蓝牙。

该系统是基于Zephyr的，蓝牙和LwM2M都应该发送与它们从数据提供的线程中接收的信息相匹配的通知，这些线程从它们控制的(硬件)模块中获取数据。此外，蓝牙和LwM2M接口可以在系统上触发执行器。(所有通信都是双向的)

特别是:蓝牙必须从电池管理线程读取电池级别。该系统还提供了另一种传感器-执行器服务，从该服务中应该获得最新的读数，执行机构应该可以通过蓝牙进行控制。这里没有问题，服务可以只包含包含所需模块的API的头文件。服务在它们访问的线程中不重叠。

LwM2M带来了问题。有些对象需要信息，应该能够从相同的线程触发操作。我可以让所有对象直接与所需的线程进行接口，但让单个LwM2M模块与其他线程对话，并充当对象和线程之间的桥梁可能更优雅。然而，这将需要大量的内部对象被公开，并需要额外的沟通，因为中间人模块。

我对我的情况做了一个简化的原理图概述，以帮助说明我的奋斗(传感器执行器2转到两个(实际上更多)不同的LwM2M对象)：

解决这个问题最优雅的方法是什么？我希望蓝牙和LwM2M都有一个类似的解决方案(也许这是我的错误)。

我已经考虑并部分地实现了以下想法，但每次我最终都对这是最好的方法感到沮丧：

• 不同的蓝牙服务和LwM2M对象都可以直接访问所需的线程。编程似乎相对容易，但这会引入许多直接依赖/访问来自目标模块/线程的重叠数据。
• 由主蓝牙模块和主LwM2M模块控制服务/objects与目标模块/线程之间的所有数据流。这将减少服务/对象与目标模块/线程之间的数据读取依赖，但当从蓝牙/LwM2M接收数据时，它会极大地增加复杂性，并且某些东西必须通过附加的主要蓝牙/LwM2M模块进行处理。
• 让数据读取通过蓝牙和主LwM2M模块，以便这两个模块侦听来自模块/线程的重要数据更新，然后更新服务/对象。但是，与第一个选项不同，还可以在服务/对象中添加直接访问，以便它们可以直接从目标模块/线程触发操作。这也让人觉得奇怪。以这种方式编程可能相当容易，但是模块/线程之间有更多的直接依赖关系。

我肯定我忽略了一个更好和更优雅的解决方案，我将非常感谢您的洞察力！

Answer 1

让我们看一下发布/订阅和观察者模式。其中之一或两者都可能有帮助，除非您是资源受限和计数周期。

(来自https://en.wikipedia.org/wiki/Observer_模式)

观察者模式是一种软件设计模式，在这种模式中，一个名为subject的对象维护其依赖者的列表，称为观察者，并自动通知他们任何状态的变化，通常是通过调用他们的方法之一。

从更新的问题陈述中我们可以看出，这已经到位了。太好了，我们继续吧。

(来自https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_模式)

在软件体系结构中，发布-订阅是一种消息传递模式，在这种模式中，消息发送者(称为发布者)不对要直接发送给特定接收者(称为订阅者)的消息进行编程，而是将已发布的消息分类为不知道哪些订阅者(如果有的话)可能存在的类。类似地，订阅者表示对一个或多个类感兴趣，并且只接收感兴趣的消息，而不知道有哪些发布者(如果有的话)。发布-订阅是消息队列范式的兄弟，通常是面向消息的大型中间件系统的一部分。

因此，在您的上下文中，传感器和/或执行器可以将消息发送到内部的“事件队列”，感兴趣的组件可以相应地接收和响应。这是一个很好的方式来解耦任意一组发送器和接收器。您可能在对事件/消息进行分类中找到价值，也可能找不到价值。

来自OP的更新抱怨直接连接的丢失，这是pub/sub的主要要点之一。直接的、单向的连接在非常小的数目(n)的参与节点中工作得足够好.然而，它们呈指数增长(n *n -1)，因此不缩放。对于pub/sub，这种增长是线性的(n * 2)，因此是可扩展的。

在OP的原始问题中，只有4个节点。直接连接是一种可行的方法(12条单向路径).更优雅的解决方案(如pub/sub)的成本可以推迟到添加下一个传感器或执行器。问一问你为什么要寻找更优雅的东西，什么时候才是投资的合适时机，这可能会很有帮助。