我正在设计Perl中的多层应用程序,我想知道各种IPC机制的优缺点.我正在考虑处理中等大小的数据,通常是几十千字节,但高达几兆字节,负载非常轻,每分钟最多几百个请求.
我主要关注的是可维护性和性能(按此顺序).我认为我不需要扩展到多个服务器,或者从我们的主平台(RHEL)移植,但我想这是需要考虑的事情.
我可以想到以下选项:
考虑到可扩展性和可移植性不是我主要关注的问题,我需要了解更多信息.什么是最好的选择,为什么？如果您需要其他信息,请发表评论.
编辑:我会尝试提供更多细节以回应ysth的问题 (警告,文本墙随后):
在这一点上,我正在考虑采用三层方法,但我不确定每层中有多少个进程.我认为我需要在左侧有更多的进程而在右侧有更少的进程,但也许我应该在全面拥有相同的数字:
.---------. .----------. .-------. | Request | -----> | Business | -----> | Data | | Manager | <----- | Logic | <----- | Layer | `---------' `----------' `-------'
这些名称仍然是通用的,可能不会以这些形式进入实现.
该请求管理器负责监听来自不同的接口的要求,例如Web请求和CLI(其中响应时间是很重要的)和电子邮件(其中响应时间是那么重要).它执行日志记录并管理对请求的响应(以适合请求类型的格式呈现).
它将有关请求的数据发送到业务逻辑,业务逻辑根据业务规则执行日志记录,授权等.
业务逻辑(如果需要)然后从数据层请求数据,数据层可以与(最常见的)内部MySQL数据库或我们团队控制之外的某些其他数据源(例如,我们组织的主LDAP服务器,或我们的DB2员工信息数据库等).这主要是一个包装器,它以统一的方式格式化数据,以便在业务逻辑中更容易处理.
然后,该信息将流回请求管理器以进行演示.
如果,当数据流向右侧时,阅读器正忙,对于交互式请求,我只想等待一段合适的时间,如果我在这段时间内无法访问,则返回超时错误(例如"稍后再试").对于非交互式请求(例如电子邮件),轮询系统可以简单地退出并在下次调用时再次尝试(可能每1-3分钟一次).
当数据向另一个方向流动时,不应有任何等待情况.如果其中一个进程在尝试返回左侧时已经死亡,我所能做的就是登录并退出.
无论如何,这是非常冗长的,因为我还处于早期设计阶段,我可能仍然有一些混乱的想法.我提到的一些内容可能与使用哪种IPC系统的问题相关.我对设计的其他建议持开放态度,但我试图将问题限制在范围内(例如,也许我应该考虑折叠到两层,这对IPC来说要简单得多).你的想法是什么？
如果您目前不确定您的确切要求,请尝试考虑一个可以编码的简单接口,任何 IPC实现(无论是临时文件,TCP/IP还是其他)都需要支持.然后,您可以选择特定的IPC风格(我会从最简单和/或最简单的调试开始 - 可能是临时文件)并使用它来实现接口.如果结果太慢,请使用例如TCP/IP实现接口.实际上,实现接口并不需要太多工作,因为您基本上只是将调用转发到某个现有库.
关键是您要执行高级任务("将数据从程序A传输到程序B"),这或多或少独立于其执行方式的细节.通过建立接口并对其进行编码,可以将主程序与需要更改实现的事件中的更改隔离开来.
请注意,您不需要使用任何重量级的Perl语言机制来充分利用具有接口的想法.你可以简单地拥有3个不同的包(用于临时文件,TCP/IP,Unix域套接字),每个包都导出相同的方法集.选择要在主程序中使用的实现相当于选择要使用的模块use.
临时文件（以及相关的东西，比如共享内存区域）可能是一个糟糕的选择。如果您想在一台计算机上运行服务器并在另一台计算机上运行客户端，则需要重写您的应用程序。如果您选择任何其他选项，至少语义本质上是相同的，如果您以后需要在它们之间切换的话。
不过，我唯一真正的建议是不要自己写这个。在服务器端，你应该使用POE（或Coro等），而不是select自己在socket上做。另外，如果您的接口是 RPC 式的，请使用CPAN 中的JSON-RPC-Common/之类的东西。
最后，还有 IPC::PubSub，它可能适合您。