SunRPC机制作为Client-Dispatcher-Server架构的局限性以及与Broker的比较
我正在读一本关于设计模式的书（旧版）“面向模式的软件架构< /a>”。在专门介绍 Client-Dispatcher-Server 的章节中，SunRPC 被引用为 Client-Dispatcher-Server 架构，端口映射器在 Client-Server 协商中充当 Dispatcher。我从未实际使用过 SunRPC，尽管我或多或少知道它是如何工作的。
我有三个问题：
- SunRPC 作为客户端-调度程序-服务器机制有哪些软件限制（在接口和功能方面）？
- 如今有哪些类似的更好系统可以实现相同的客户端-调度程序-服务器架构（无论语言如何）？
- Broker 架构和 Client-Dispatcher-Server 架构之间有哪些本质区别？
我确实意识到问题很多且复杂。我考虑过分成独立的问题，但这次提交的重点是关于一般架构原则和限制，并以一个具体示例（SunRPC）作为典型案例。出于这些考虑，我预先宣布，只要有机会，无论我对宽限期内的答案的满意度如何，我都会立即发放 100 名代表奖金。
I am reading a book on design patterns (an old edition) "Pattern-oriented software architecture". In the chapter dedicated to Client-Dispatcher-Server, SunRPC is cited as a Client-Dispatcher-Server architecture, with portmapper acting as Dispatcher in the Client-Server negotiation. I never used SunRPC practically, although I know more or less how it works.
I have three questions:
- What are the software limitations (in terms of interfaces and features) of SunRPC as a Client-Dispatcher-Server mechanism ?
- What are similar better systems today to achieve the same Client-Dispatcher-Server architecture (regardless of language) ?
- What are the intrinsic differences between a Broker architecture and a Client-Dispatcher-Server architecture ?
I do realize the questions are many and complex. I considered splitting into independent questions, but the point of this submission is about general architecture principles and limitations, with a specific example (SunRPC) as a typical case. Due to these considerations I preemptively announce that I will put a 100 rep bounty as soon as I have the chance, regardless of my level of satisfaction with answers during the grace period.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这个术语很不寻常（至少对我来说），也许这就是为什么你没有得到很多回复的原因。根据第 327 页上的图表，客户端-调度程序-服务器意味着在连接时发生到真实服务器的重定向，而代理介入整个通信（第 109 页）？假设现代术语分别是“重定向”（或“名称服务”或“目录服务”等）和“代理”。主要区别在于延迟和可用性之间的权衡，即当服务器崩溃时，代理能够修补问题，而调度程序则不能；但经纪人会在管道中增加一点处理时间。
这两种模式的现代实例都可以在大容量网站上找到：它们通常会采用 round- robin 或更复杂的负载-平衡 DNS 服务（调度程序）以及缓存反向代理（代理）。
我对 SunRPC 及其局限性了解不多，而且我不知道它是否可以以循环方式使用（在 Google 中搜索“portmap 负载平衡" 没有显示任何内容（FWIW）。端口映射器表中的条目通常会指向在同一主机上运行的单个服务器，即大多数情况下，此机制用于避免分配 SunRPC 服务的众所周知的 TCP 端口。
This terminology is unusual (to me at least), maybe that's the reason why you aren't getting many responses. Judging by the diagram on page 327, client-dispatcher-server means that a redirection to the real server occurs at connection time, while broker interposes in the whole communication (page 109)? Assuming that, modern-day terms would be "redirect" (or "name service" or "directory service" etc), and "proxy", respectively. The main difference is a trade-off between latency and availability, ie brokers are in a position to patch things up when a server dies, which dispatchers aren't; but brokers add a modicum of processing time to the pipeline.
Modern-day instances of both patterns can be found on high-volume Web sites: they will typically employ a round-robin or more sophisticated load-balancing DNS service (the dispatcher) as well as caching reverse proxies (brokers).
I don't know much about SunRPC and its limitations, and I have no idea if it can possibly be used in a round-robin kind of way (searching Google for "portmap load balancing" turns up nothing FWIW). An entry in the portmapper's table will typically point to a single server running on the same host, ie mostly this mechanism serves to avoid allocating well-known TCP ports to SunRPC services.
这是一组很好的问题。您可以尝试将 siemens-patterns 列表用作 uiuc。最后我知道它的数量相当低，但那里有很多敏锐的人，甚至包括一些作者。你可以询问并分享你的启示。
That's a good set of questions. You could try the siemens-patterns list serve as uiuc. Last I knew it was pretty low volume but there were a number of sharp folks there, even some of the authors. You could ask and share your enlightenment.