Ограничения механизма SunRPC как архитектуры клиент-диспетчер-сервер и сравнение с брокером

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

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

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

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


architecture design-patterns broker sunrpc
person Stefano Borini    schedule 07.09.2010    source источник

Ответы (2)


arrow_upward
1
arrow_downward

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

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

Я мало что знаю о SunRPC и его ограничениях, и я понятия не имею, можно ли его использовать в циклическом режиме (ищите в Google "балансировка нагрузки portmap" ничего не дает FWIW). Запись в таблице портмаппера обычно указывает на один сервер, работающий на том же хосте, т.е. в основном этот механизм служит для того, чтобы избежать выделения известные порты TCP для служб SunRPC.

person DomQ    schedule 14.09.2010

arrow_upward
1
arrow_downward

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

person Paul Rubel    schedule 14.09.2010