architecture - REQ-REP风格的ZeroMQ架构，具有（有时）长任务

我是ZeroMQ的初学者，即将为简单的IPC客户端 - 服务器应用程序选择架构。

最初它是一个简单的 REQ-REP ，没有任何性能需求，在同一台机器上回答客户端。对于一种消息类型，答案计算时间很长。

处理此计算时，服务器仍需要回答其他请求。其余的请求不需要异步进行，它们可以是同步的，因为请求的数量非常少。

根据我在ZeroMQ指南中所读到的内容，我需要一些代理人将消息分发给特殊的后台工作人员以执行长任务，将所有其他消息分发给另一个工作人员。

我考虑过 DEALER-ROUTER 架构，但我不清楚这两个工作人员是 REQ 还是 { {1}} 工作人员，以及经纪人的类型。

我应该在这里选择哪种架构？

（cit。）： 我应该在这里为建筑选择什么？

我们首先同意，任何关于使用REQ/REP或DEALER/ROUTER对行为原型的决定只是使用一组可能的候选人中的两个兼容项目的一个步骤，匹配一个常见的ZeroMQ / RFC定义（一个不能少做 - 因为任何选择不匹配的行为archtetypes会产生崩溃的废话）。

如上所述，这是架构的选择。

最佳下一步？

你可以为此做的最好的下一步是恕我直言以获得更多的全局视图，对于新手而言可能听起来很复杂，但不是具有你的专业经验范围的人，但是如果你至少跳到Code Connected, Volume 1 [asPdf->]的第265页，如果不是那里一步一步阅读。

最快的学习曲线将是图60 重新发布更新 <和<<>首先显示未公开的视图 strong>图62 HA克隆服务器对可能的高可用性方法，然后回到根，元素和细节。

enter image description here

需要非阻止操作吗？即使被推荐，也不要使用REQ/REP串联，因为它可能会导致无法解决的僵局。

需要缩放？
使用工作负载分配代理进行更好的设计，因为它可以比单一的SPOF更多地扩展。

需要远程分布式EoW式可检查代理？更好的设计代理，包括按照设计的迷你SoftRealTime嵌入式调度程序。

这些是成功关键的高级驱动程序，需要尝试草拟架构。

分布式系统设计更接近于交响乐组合，其中合作和多层次控制循环使切尔诺贝利型管理失败与Appolo-11期间显示的稳健性和弹性之间存在差异登月危机解决方案。这些来自明亮和/或糟糕设计的讲座清楚地表明，一个架构永远不会勾勒出一些命令式代码的pure-[SERIAL] SLOC。从不。

没有简单的快捷方式来自坚果＆amp;螺栓水平的细节视图，以成功登陆和远程控制MARS上的好奇心型机器人设备。

相反，相反的方法是有效的（而且螺母和螺栓只是结果，但在这里，确保安全地匹配主要目标）。

然后可以享受绘制可行架构的能力，以满足（并且更好地超越）所有定义的期望（即使＆＃34; XP ＆＃34;或＆＃34; 敏捷＆＃34;福音传播者试图让你相信它没有必要 - 它就是。

糟糕的架构决策是非常昂贵的，而且没有＆＃34; 敏捷＆＃34;发起人将永远能够支付最终坠毁的火星轨道飞行器的所有成本，或者只是由于从遗忘/错误的初始假设中重新设计延迟而导致的糟糕项目管理损失的收入）

祝你好运，享受智能设计的分布式系统的所有功能，至少和过去二十年一样多 - 绝对值得花时间和精力。