应用程序拆分挑战 - 快速+简单的 RPC 技术？

Posted 2023-02-16

【中文标题】应用程序拆分挑战 - 快速+简单的 RPC 技术？

【英文标题】：The Application Split Challenge - fast+easy RPC technology?

【发布时间】：2011-01-24 09:25:43

【问题描述】：

以下内容试图了解哪些技术适用于特定（如概述的）分布式/RPC 问题。如果有不清楚的地方，我很乐意添加更多详细信息，但请在评论中提出这些要求，而不是在“答案”中。谢谢。

首先我将描述当前的情况，然后是我们想要实现的目标和实际问题。尽管这是一个相当长的帖子来获得一些背景信息，但问题本身很短（见最后）。

应用拆分挑战

应用说明：

该应用程序允许用户配置多个硬件设备(*) 然后与这些通信以控制和收集测量值 物理实验的通道。

(*) 硬件设备包括温度传感器、压力传感器、 电机，...通信范围从串口通信， TCP/UDP 通信与第 3 方驱动程序的接口 插件卡。

控制涉及向各种硬件设备发送命令 根据它们支持的协议配置它们。 测量涉及从（部分）这些设备获取数据。

我们很难以客户的身份保持整个业务运行 以更高的采样率要求越来越多的通道，我们必须 跟上将我们从所有设备获得的数据+时间戳写入 磁盘，显示数据的子集并仍然保留系统 正确响应。

现状：

[ DisplayAndControl.exe      ]

  ||                    /\
  || DLL Interface      ||
  ||                    || Window Messages (SendMessage, PostMessage)
  ||                    ||
  \/                    ||

[ ChannelManager.dll         ]

ChannelManager.dll（Windows 上的原生 C++ DLL）

管理 n 个数据通道（物理测量变量） 每个通道都可以保存任意数量的移动样本 高精度时间戳 允许对频道进行分组并写入其正在进行的更新或 历史值（“测量”）到磁盘 使用通道进行计算（算术、积分、平均值 值等） 与（实时）硬件设备的接口以获取时间戳 和渠道价值 从硬件获取值+时间戳并保存在内部 通道的环形缓冲区

DisplayAndControl.exe（Windows 上的原生 C++ MFC 应用程序）

控制ChannelManager.dll的功能（配置通道 和硬件设备） 实时显示所有通道的当前值/时间戳/变化 图表中（组）通道的图表值 打印通道值图表和表格

现状总结：

目前的应用程序已经有些模块化 因为（主）可执行文件执行显示+交互和 （几个之一）DLL进行数据管理（保存实时数据 到磁盘，与设备通信等）

从表演 POV，顺便说一句，交流。显示模块和 数据管理模块目前性能最佳。

新情况：

[ DisplayAndControl.exe      ]

  ||                     /\
  || ? RPC/Messaging     ||
  ||                     || ? RPC/Messaging
  ||                     ||
  \/                     ||

[ ChannelManager.exe (same PC or another)  ]

设想的新情况总结：

出于可用性、性能和安全原因，我们希望拆分 将此 Windows 应用程序分成两个独立的应用程序，以便 性能（和安全）敏感的 ChannelManager 模块可以作为 一个单独的进程，可能在单独的 Windows PC 上。

另外，既然我们已经要拆分这个，我们将 允许多个 DisplayAndControl.exe 应用程序连接到一个 单个 ChannelManager.exe。

现在的一个问题是我们应该使用什么技术来促进 顺便说一句，沟通。现在的两个（或者更确切地说是1 : small_n）应用程序。

性能很重要，因为顺便说一句，很多数据都在传输。这 两个应用程序和延迟应保持在最低限度。它只是” 需要在 Windows 上工作，但它应该可以在原生 C++ 中使用 只有这使得所有纯粹基于 .NET 的技术都没有吸引力。 （注意：将 DisplayAndControl.exe 的部分移植到 .NET/WPF 是 计划中，但 ChannelManager.exe 应该保持纯原生，因为我们 不希望在此进程中运行任何 .NET 内容。）

关于延迟：我们实现某种程度的延迟是很重要的 软实时，即小延迟是可以接受的，但是 对于可用性而言，大且特别变化的延迟是不可接受的 和安全原因。因此，任何有助于 获得某种（软）实时行为将是首选。

我们研究过的 RPC 技术：

WCF（或 .NET 远程处理）- 仅是 dotnet，因此不是 吸引人的。性能数据也不是很好。

(D)COM - COM 非常适合 Windows RPC 通信，但它 一旦您必须进行 PC 间通信就会崩溃，因为它是 让安全设置在公司 IT 中正常工作很糟糕 网络。

CORBA - 我们在 CORBA 通信方面有很好的经验 过去。沟通容易上手；没有 大量基础设施开销；它在 C++ 中运行良好；写作 .NET 包装器非常简单。 CORBA 的问题在于 在 C++ 中正确使用有点复杂（人们会使用 很多时间都在追逐内存泄漏，尤其是。没有经验的 C++ 开发人员）。这也将是每个开发人员的学习曲线，并且 每个新开发人员，因为没有人期望人们“了解” CORBA 如今。此外，它的性能可能不如我们希望的那么好，并且 据我所知，没有现成的实时支持。

Thrift - 在我们的场景中使用看起来仍然不成熟。

ICE（来自 ZeroC）——毕竟我更喜欢 ICE 而不是 CORBA 它有望成为“更好的 CORBA”，我认为它确实可以实现 那。但是，他们的许可政策非常不理想，因为他们不销售开发许可证，而只销售每个许可证 安装。 （上次我们在 2009 年底询问时，他们就是这么告诉我们的。）他们的许可政策还表明，任何可能对与我们的模块交互感兴趣的第三方都必须首先与 ZeroC 协商许可合同。

李>

Open MPI - 消息传递接口似乎针对 大量客户端“大量”分布的场景。似乎没有 来解决我们的问题。

使用 TCP/UDP 编写我们自己的通信层 - 天哪。 ID 而不是:-)

Google 协议缓冲区 - 不是一种 RPC 技术。

分布式共享内存 - 嗯。这被几个人扔了 开发人员和 我 不确定是否有工作 实施也不是我们的问题。

那么问题又来了 - 您更喜欢哪种“RPC”式技术 在这种情况下，为什么？

【问题讨论】：

是否需要将所有数据点视为一个一致的整体？还是应该改为更新流？ SNMP 能否为您的客户端提供简单的数据点，并通过另一个渠道处理命令？

@sarnold：数据传输和控制通信不一定要在同一个通道上。不过，我不确定 SNMP 是否是一个不错的选择。

【参考方案1】：

我可以详细说明约翰尼的回答。 CORBA 提供了一个健壮的基础设施，其服务远远超出了简单的 RPC。随着分布式应用程序的增长，您可以使用 CORBA 功能来管理接口和实现之间的映射、提供安全连接等。作为 RPC，CORBA 提供了轻松同步或异步调用的方法。

学习曲线也没有那么陡峭。虽然其中一些术语有些晦涩难懂，但今天的 C++ 程序员应该熟悉托管（计数）引用等概念。而当 C++0x 映射可用时，它会变得更加容易。培训可帮助您更轻松地完成这一过渡。

您提到不了解实时支持。事实上，CORBA for C++ 有丰富的 RT 支持。有一个 RT CORBA 规范和几个实现它的 C++ ORB。 TAO 是开源和商业支持的，具有广泛的 RT 支持，包括 RT_ORB、RT_POA，一种 TAO 特定的 RT 事件服务。使用这些工具，您可以为 ORB 中的线程指定优先级，并为不同的优先级提供单独的通信通道。

【参考方案2】：

我建议看看 Thrift。虽然它看起来半生不熟，但我相信它只是缺少文档 - 实现非常可靠。

【讨论】：

谢谢。也许我们应该再检查一次。

【参考方案3】：

CORBA 应该表现良好，并且有经验的人。我们意识到 IDL 到 C++ 的映射很难使用，OMG 有一个 RFP 要求新的 IDL 到 C++0x 的映射，这应该会更容易使用

【讨论】：

谢谢。也许您可以详细说明为什么您认为 CORBA 会是解决此问题的好（更好）解决方案。