На каком уровне я должен осуществлять связь между узлами в распределенной системе? - PullRequest
3 голосов
/ 21 июля 2009

Я создаю веб-приложение, которое с первого дня будет находиться в пределах возможностей одного сервера. Поэтому я рассматриваю возможность использования распределенной архитектуры с несколькими одинаковыми узлами. Цель состоит в том, чтобы обеспечить масштабируемость (добавить серверы для большего количества пользователей) и отказоустойчивость. Узлы должны разделять между собой состояние some , поэтому требуется некоторая связь между ними. Я считаю, что у меня есть следующие альтернативы для реализации этой коммуникации в Java:

  • Реализуйте его, используя сокеты и собственный протокол.
  • Использовать RMI
  • Использование веб-служб (каждый узел может отправлять и получать / анализировать HTTP-запрос).
  • Использовать JMS
  • Используйте другую структуру высокого уровня, такую ​​как Терракота или hazelcast

Хотелось бы узнать, как эти технологии сравниваются друг с другом:

  • Когда количество узлов увеличивается
  • Когда увеличивается объем обмена данными между узлами (1000 сообщений в секунду и / или сообщений до 100 КБ и т. Д.)
  • На практическом уровне (например, простота внедрения, доступная документация, вопросы лицензии и т. Д.)
  • Мне также интересно узнать, какие технологии используют люди в реальных производственных проектах (в отличие от экспериментальных или академических).

1 Ответ

1 голос
/ 21 июля 2009

Не забудьте Джини .

Он предоставляет вам автоматическое обнаружение службы, аренду службы и загружаемые прокси-серверы, так что фактический протокол связи клиент-сервер зависит от вас и не применяется средой (например, вы можете выбрать HTTP / RMI / что угодно).

Структура основана на признании 8 ошибок распределенных вычислений и вычислений, ориентированных на восстановление . то есть у вас будут проблемы с сетью, а архитектура построена так, чтобы помочь вам восстановить и поддерживать службу.

Если вы также используете Javaspaces , тривиально реализовать рабочие процессы и архитектуры производителей-потребителей. Производители будут писать в Javaspaces, а один или несколько потребителей будут брать эту работу из пространства (в рамках транзакции) и работать с ней. Таким образом, вы масштабируете его, просто предоставляя больше потребителей.

...