Ограничения механизма SunRPC в качестве архитектуры Client-Dispatcher-Server и сравнение с брокером

Question

Я читаю книгу о шаблонах дизайна (старое издание) «Pattern-oriented software architecture». В главе, посвященной Client-Dispatcher-Server, SunRPC цитируется как архитектура Client-Dispatcher-Server, а portmapper выступает в качестве диспетчера в переговорах Client-Server. Я никогда не использовал SunRPC практически, хотя я знаю более или менее, как это работает.

У меня есть три вопроса:

• Какие ограничения программного обеспечения (с точки зрения интерфейсов и функций) в SunRPC в качестве механизма клиент-грузоотправитель-сервер?
• Что такое более современные системы для достижения той же архитектуры Client-Dispatcher-Server (независимо от языка)?
• Каковы внутренние отличия между архитектурой брокера и архитектурой Client-Dispatcher-Server?

Я понимаю, что вопросы много и сложны. Я рассматривал вопрос о разделении на независимые вопросы, но в данном случае речь идет об общих принципах и ограничениях архитектуры, в качестве типичного примера используется конкретный пример (SunRPC). В связи с этими соображениями я упреждающе объявляю, что я положу 100 рецензий, как только у меня появится шанс, независимо от моего уровня удовлетворенности ответами в течение льготного периода.

Answer 1

Эта терминология необычна (по крайней мере для меня), возможно, именно поэтому вы не получаете много ответов. Судя по diagram on page 327, клиент-диспетчер-сервер означает, что перенаправление на реальный сервер происходит во время соединения, а брокер вступает во все сообщение (page 109)? Предполагая, что современные термины будут «перенаправляться» (или «служба имени» или «служба каталогов» и т. Д.) И «прокси» соответственно. Основное различие заключается в компромиссе между латентностью и доступностью, т. Е. Брокеры могут исправлять ситуацию, когда сервер умирает, а диспетчеры - нет; но брокеры добавляют к конвейеру время обработки.

Современные экземпляры обеих моделей можно найти на веб-сайтах с большим объемом: они, как правило, используют round-robin или more sophisticated балансировки нагрузки DNS службы (диспетчер), а также кэширование reverse proxies (брокеров).

Я мало что знаю о SunRPC и его ограничениях, и я понятия не имею, можно ли его использовать в циклическом виде (поиск Google для «portmap load balancing» ничего не показывает FWIW). Запись в таблице portmapper обычно указывает на один сервер, работающий на одном и том же хосте, т. Е. В основном этот механизм позволяет избежать выделения well-known TCP ports сервисам SunRPC.

Answer 2

Это хороший набор вопросов. Вы можете попробовать список siemens-patterns служить uiuc. Последнее, что я знал, было довольно низким, но там было много острых людей, даже некоторых авторов. Вы можете спросить и поделиться своим просвещением.