SunRPC机制作为客户机-调度服务器体系结构的局限性及与代理的比较

Question

我正在读一本关于设计模式(旧版本)的书"面向模式的软件架构“。在专门讨论客户机-调度-服务器的章节中，SunRPC被引用为客户机-调度-服务器体系结构，而portmapper在客户机-服务器协商中充当调度器。我从来没有实际使用过SunRPC，尽管我或多或少知道它是如何工作的。

我有三个问题：

• SunRPC作为客户机-调度服务器机制的软件限制(在接口和功能方面)是什么？
• 现在有什么类似的更好的系统来实现相同的客户机-调度-服务器体系结构(不管语言如何)？
• 代理体系结构和客户机-调度-服务器体系结构之间有什么内在的区别？

我确实意识到这些问题是多而复杂的。我考虑了分成几个独立的问题，但是这次提交的要点是关于一般的架构原则和限制，一个特定的例子(SunRPC)作为一个典型的例子。出于这些考虑，我先发制人地宣布，我将在有机会的时候立即发放100英镑的奖金，无论我在宽限期内对答案的满意程度如何。

Answer 1

这个术语是不寻常的(至少对我来说)，也许这就是为什么你没有得到多少回应的原因。从图见第327页判断，客户机-调度服务器意味着重定向到真正的服务器在连接时发生，而代理在整个通信(第109页)中插入？假设现代术语将分别是“重定向”(或“名称服务”或“目录服务”等)和“代理”。主要的区别是延迟和可用性之间的权衡，即代理可以在服务器死后修补事情，而调度员没有这样做；但是代理为管道增加了少量的处理时间。

这两种模式的现代实例都可以在大容量的网站上找到:它们通常使用周知博或更复杂负载平衡DNS服务( dispatcher)以及缓存反向代理 (代理)。

我对SunRPC和它的局限性不太了解，我也不知道它是否能以一种循环的方式使用(在谷歌搜索"portmap负载平衡“时没有发现任何FWIW)。portmapper表中的条目通常指向运行在同一主机上的单个服务器(大多数情况下这种机制可避免将众所周知的TCP端口分配给SunRPC服务)。

Answer 2

这是一个很好的问题。您可以尝试使用西门子-模式列表作为uiuc。上一次，我知道它的音量很低，但是那里有很多尖锐的人，甚至是一些作者。你可以问并分享你的启示。