我有一个应用程序对传入的事件流（CEP引擎）执行分析。 此流程可以来自不同的来源（数据库，网络等）。
为了有效解耦，我希望此服务使用wcf公开命名管道，并允许其他应用程序从源读取数据并将其提供给服务。
因此，一个进程负责获取和处理传入的数据，而另一个进程负责分析它，使用wcf和命名管道绑定将两者连接起来。它们都将部署在同一台机器上。
问题是，如果我将两个服务简单地耦合到一个进程并使用常规事件，我会注意到在中间使用wcf的吞吐量较低吗？
答案 0 :(得分：6)
不，在现代主流操作系统中，IPC永远不会，也永远不会像进程中的事件一样快。其原因是与激活不同进程相关联的上下文切换的开销。即使对于不同进程在不同核心上运行的多核系统，尽管它们各自独立运行（因此激活一个进程与另一个进程没有相关的成本 - 它们都始终活动），跨进程的通信仍然需要跨越安全边界，访问网络堆栈（即使使用管道），等等。如果本地函数调用将在1000个cpu周期的数量级上调用，那么IPC将是数百万。
因此IPC将比进程内通信慢。这在你的案例中是否真正重要，是一个不同的问题。例如，假设您的操作需要运行2小时的蒙特卡罗模拟。在这种情况下，调用操作是否花费1ms或1000ms并不重要。
通常，通信的性能不是您想要优化的。即使性能很重要，关注性能的一个小方面 - 比方说，是否使用IPC或本地函数调用 - 可能是错误的方法。
我认为“CEP”指的是“复杂事件处理”，这意味着高吞吐量，高容量处理。所以我理解性能对你很重要。
但是，为了获得真正的可扩展性和可靠性，您不能简单地优化进程内事件;您将需要依赖多台计算机并向外扩展。这将意味着某种程度的IPC，无论如何。在较小规模（事件）中提高效率显然很重要，但您的整体高端性能将主要受到您选择用于扩展的架构的约束。
WCF很好，因为它允许将构建块从本地计算机移动到远程计算机，并且由于通道堆栈，您可以以模块化方式添加通信服务。
这对您来说是否重要，由您决定。