#java #java-ee-6 #cluster-computing
#java #java-ee-6 #кластерные вычисления
Вопрос:
Мне нужно проверить, готово ли существующее веб-приложение к развертыванию в кластерной среде.
Кластер:
несколько блоков Linux. Потоком управляет балансировщик нагрузки, который использует простой алгоритм циклического перебора с привязкой сеанса.
Веб-приложение Java без приложения (надеюсь), которое извлекает содержимое из бэк-офиса и соответствующим образом форматирует его.
У меня есть доступ к исходному коду. Что я должен проверить в коде, чтобы быть уверенным, что он будет выполняться в кластере?
- Убедитесь, что что-то не кэшировано в памяти или файловой системе, которая хранит состояние приложения.
- …Что-то еще?
Ответ №1:
Если вы используете EJBs (что рекомендуется при доступе к базе данных), то вот список ограничений:
http://java.sun.com/blueprints/qanda/ejb_tier/restrictions.html
Я предполагаю, что аналогичные ограничения применяются к веб-приложению.
Комментарии:
1. Я полагаю, что не только способ чтения и записи данных в базе данных определяет, может ли ваше приложение запускаться в кластерной среде!?
2. @Liv: Я этого не говорил. Но эта ссылка предоставляет полезные советы, например, о доступе к файловой системе.
Ответ №2:
Самый простой способ проверить приложение — запустить его на 2 серверах с одинаковыми данными, чтобы при запуске оба находились в одинаковом состоянии. Давайте предположим, что для завершения пользователем операции браузер отправит 2 последовательных HTTP-запроса к вашему веб-приложению — все, что вам нужно сделать, это выполнить веб-сервер 1 с первым вызовом и веб-сервер 2 со вторым вызовом; затем попробуйте наоборот, затем с обоими запросами, идущими на один и тот же веб-сервер — и если вы получаете один и тот же результат каждый раз, то, скорее всего, у вас есть готовое к кластеру приложение. (Это не означает, что приложение готово к кластеризации, поскольку в памяти могут храниться состояния объектов и т.д., Которые нелегко определить из интерфейса, но это дает вам более высокую вероятность того, что ЭТО МОЖЕТ БЫТЬ нормально для запуска в кластере.)
Ответ №3:
Если бы оно действительно было «без состояния», проблем бы не было, вы могли бы сделать любой запрос к любому серверу в любое время, и все бы просто работало. Большинство вещей не так просты, поэтому любое состояние должно либо передаваться на страницу и с нее по мере ее перемещения от клиента к серверу, либо храниться на серверной части, и какой-либо токен передается туда и обратно, чтобы извлечь его из любого общего хранилища данных, которое вы используете для этого. Если они используют HttpSession, то все, что извлекается из сеанса, если оно изменено, должно быть возвращено в сеанс с помощью session.setAttribute(ключ, значение). Эта настройка атрибута действует как сигнал о том, что все, что хранится в сеансе, должно быть реплицировано на резервные серверы. Убедитесь, что все, что хранится в сеансе, реализовано и фактически является сериализуемым. Некоторые серверы позволят вам хранить объекты (я смотрю на ваш weblogic), но затем выдадут исключение при попытке репликации объекта. Многие мои коллеги жаловались, что необходимость возвращать содержимое в сеанс должна быть избыточной, и, возможно, так и должно быть, но это просто способ, которым все работает.
Ответ №4:
Наличие состояния не является большой проблемой, если все сделано правильно. В любом случае, все приложения имеют состояние. Даже если файл обслуживается несколько статично, содержимое файла, связанное с URL, действительно является частью состояния.
Проблема в том, как это состояние распространяется и совместно используется.
- состояние внутри сеанса пользователя не вызывает затруднений. Используйте механизм репликации сеанса (медленнее, но без потери сеанса при сбое узла) или балансировщик нагрузки с привязкой сеанса, и ваша проблема решена.
Все остальные общие состояния действительно являются проблемой. В частности, даже состояние кэша должно быть общим и абсолютно согласованным, иначе обновление на одной и той же странице может генерировать разные результаты случайным образом в зависимости от веб-сервера witch и, следовательно, кеша, к которому вы обращаетесь.
Вы все еще можете кэшировать данные, используя общий кэш (например, ehcache), или при сбое возврата к привязке сеанса.
Я предполагаю, что довольно сложно быть уверенным, что приложение действительно будет работать в кластеризованной среде, потому что синглтон в какой-то непонятной службе, статический элемент где-нибудь, что угодно может потенциально привести к странным результатам. Вы можете проверить общую архитектуру наверняка, но вам нужно будет сделать в реальности и выполнить некоторый проверочный тест перед запуском в производство.