обзор
UltraESB от AdroitLogic имеет глубокую поддержку протоколов HTTP / S и возможность балансировки нагрузки или отказов при запросах между несколькими бэкэнд-системами, используя циклический, взвешенный или случайный алгоритмы. Таким образом, его даже можно использовать для прокси-запросов к серверам Tomcat и балансировки нагрузки / отработки отказа между несколькими экземплярами — вместо использования Apache + mod_jk или mod_proxy и т. Д.
Обратитесь к полной статье, описывающей сценарий, и сравните определение прокси-службы на UltraESB и аналогичный подход с Apache2 + mod_jk и сравните простоту и мощь использования UltraESB самостоятельно. Кроме того, UltraESB имеет отличную поддержку REST, SOAP, XML, JSON, Cookies, аутентификации Baic / Digest / AWS S3 и т. Д., Что позволяет легко управлять сложными интеграциями.
Вступление
Требуется загрузить запросы балансировки от клиентов между несколькими экземплярами Tomcat, на которых размещаются распространяемые веб-приложения, выполняющие репликацию сеанса. Однако липкие сеансы желательны, чтобы переключение сеанса происходило только при неожиданном сбое узла Tomcat.
Типичное развертывание с использованием веб-сервера Apache2 с mod_jk
Эквивалентное развертывание с использованием UltraESB
Конфигурация экземпляров Tomcat
В этом примере мы использовали два сервера Tomcat 6.X на платформе Ubuntu и настроили репликацию и кластеризацию сеанса в соответствии со статьей:
http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html
Сервер Tomcat1 прослушивает HTTP на порт 8080 и ОЮЛ на порт 8009, в то время как Tomcat2 прослушивает HTTP на порт 8081 и ОЮЛ на порт 8010. server.xml для Tomcat1 можно найти здесь , в то время как server.xml для Tomcat2 можно найти здесь . Обратите внимание, что мы указали «tomcat1» в качестве jvmRoute для первого сервера и «tomcat2» в качестве jvmRoute для второго сервера.
e.g. <Engine name="Catalina" defaultHost="localhost" jvmRoute="tomcat1">
Вышеприведенное добавляет этот «jvmRoute» к cookie-файлу JSESSIONID или параметру пути jsessionid при перезаписи URL-адреса, чтобы разрешить сеансы флешки. Затем мы настроили пример приложения Tomcat для использования репликации сеанса, указав тег <distribtable /> в конце файла web.xml (находится в webapps / examples / WEB-INF) следующим образом:
<web-app .....
.....
<distributable/>
</web-app>
Теперь вы можете запустить экземпляры Tomcat и получить к ним прямой доступ по адресу http: // localhost: 8080 / examples. Для проверки репликации сеанса может помочь следующий сценарий.
Зайдите на http: // localhost: 8080 / examples / servlets / servlet / SessionExample, чтобы получить страницу, на которой вы можете установить атрибут сеанса. Если вы установите атрибут «a», например, «100», вы вернетесь на страницу, показанную ниже. Обратите внимание, что теперь URL содержит идентификатор jvmRoute экземпляра Tomcat, который обработал запрос и установил сеанс. Поскольку мы обращаемся к Tomcat1 через порт 8080, мы можем увидеть «.tomcat1» в конце идентификатора сеанса, как показано ниже.
HTTP: // локальный: 8080 / примеры / сервлеты / сервлет / SessionExample; JSESSIONID = 711442A37BE8AF883ED0237BF10219CF.tomcat1
Если вы теперь обращаетесь к Tomcat2 по адресу http: // localhost: 8081 / examples / servlets / servlet / SessionExample, вы все равно увидите атрибут a = 100, поскольку сеанс был реплицирован между экземплярами. Обратите внимание, что настройка деталей для Tomcat выходит за рамки данной статьи.
Конфигурация UltraESB
Пример сценария можно найти в файле конфигурации по адресу samples / conf / ultra-sample-111.xml, и существенный момент этой конфигурации показан ниже. Служба прокси «web-proxy» определяет шаблон URL, который он принимает как «*», и, таким образом, обрабатывает любой запрос, поступающий через его транспортный «http-8280», настроенный на прослушивание через порт HTTP 8280. Как только запрос поступает, mediation.getJvmRoute ( ) метод извлекает jvmRoute из файла cookie JSESSIONID или сегмента пути jsessionid или возвращает ноль, если он не найден. Затем мы используем условную маршрутизацию для отправки запроса определению конечной точки «tc1-failover» или «tc2-failover» в зависимости от экземпляра, содержащего активный сеанс, и, если сеанс не найден, мы используем циклическое распределение нагрузки для выбора между один из примеров.
<u:proxy id="web-proxy">
<u:transport id="http-8280">
<u:property name="url" value="*"/>
</u:transport>
<u:target>
<u:inSequence>
<u:java><![CDATA[
String jvmRoute = mediation.getJvmRoute(msg);
logger.debug("JVM Route : {}", jvmRoute);
if ("tomcat1".equals(jvmRoute)) {
mediation.sendToEndpoint(msg, "tc1-failover");
} else if ("tomcat2".equals(jvmRoute)) {
mediation.sendToEndpoint(msg, "tc2-failover");
} else {
mediation.sendToEndpoint(msg, "round-robin-loadbalance");
}
]]></u:java>
</u:inSequence>
<u:outDestination>
<u:address type="response"/>
</u:outDestination>
</u:target>
</u:proxy>
<u:endpoint id="tc1-failover" type="fail-over">
<u:address type="prefix">http://localhost:8080</u:address>
<u:address type="prefix">http://localhost:8081</u:address>
<u:property name="switchLocationHeadersTo" value="http://localhost:8280/"/>
</u:endpoint>
<u:endpoint id="tc2-failover" type="fail-over">
<u:address type="prefix">http://localhost:8081</u:address>
<u:address type="prefix">http://localhost:8080</u:address>
<u:property name="switchLocationHeadersTo" value="http://localhost:8280/"/>
</u:endpoint>
<u:endpoint id="round-robin-loadbalance" type="round-robin-with-fail-over">
<u:address type="prefix">http://localhost:8081</u:address>
<u:address type="prefix">http://localhost:8080</u:address>
<u:property name="switchLocationHeadersTo" value="http://localhost:8280/"/>
</u:endpoint>
Конечная точка «tc1-failover» выполняет обработку отработки отказа и всегда выбирает первый доступный адрес для пересылки сообщения. В случае сбоя этой конечной точки выбирается следующий доступный адрес в списке. Таким образом, «tc1-failover» всегда в первую очередь предпочитает сервер Tomcat1, а «tc2-failover» всегда в первую очередь предпочитает сервер Tomcat2. В случае сбоя предпочтительного экземпляра запрос отправляется другому. Конечная точка round-robin-loadbalance является балансировщиком нагрузки round-robin с переключением при сбое и используется для выделения запроса узлу с использованием политики round-robin. Если адрес на этом не удаётся, запрос переключается на следующий. UltraESB поддерживает взвешенную и случайную балансировку нагрузки с отказоустойчивостью и без нее. В заключение,свойство switchLocationHeadersTo конечных точек предписывает UltraESB перезаписывать любые заголовки Location (например, при использовании с вызовами REST или RESTful и т. д.), чтобы указывать на UltraESB, а не на отдельные экземпляры Tomcat.
Расширенные опции
Хотя это не показано в этом примере, UltraESB допускает сбои уровня HTTP, сбои SOAP и т. Д. С сервера, чтобы вызвать переключение на другой экземпляр; а также проверка успешного ответа пользовательским ResponseValidator — перед тем, как принять его как действительный ответ для отправки клиенту. Это позволяет UltraESB обнаруживать, например, что ответ HTTP 200, в котором говорится, что «Служба неактивна», идентифицируется как сбой, и переключать запрос на другой экземпляр. Кроме того, UltraESB может легко читать или записывать файлы cookie, заголовки HTTP и т. Д.
Настройка веб-сервера Apache2 с помощью mod_jk
В Ubuntu 9.04 для установки Apache2 с mod_jk потребовались следующие команды:
sudo apt-get установить apache2
sudo apt-get установить libapache2-mod-jk
Затем мы создали mod_jk.conf и workers.properties файл в / и т.д. / apache2 , как в этой статье , и отредактировали /etc/apache2/apache2.conf комментировать Виртуальные хосты, и включают в себя mod_jk.conf в самом конце , как показано ниже.
#Include /etc/apache2/sites-enabled/ Include /etc/apache2/mod_jk.conf
Тестирование сценариев
Как прокси-сервер Apache2, так и прокси-сервер UltraESB выполняют балансировку нагрузки и восстановление после сбоя с помощью зависших сессий, как и ожидалось. Чтобы протестировать внешний интерфейс Apache2, зайдите на http: // localhost / examples / servlets / servlet / SessionExample, а для тестирования на UltraESB — на URL http: // localhost: 8280 / examples / servlets / servlet / SessionExample. В обоих случаях уничтожение одного из серверов Tomcat, владеющих сеансом, приведет к переключению на другой экземпляр без потери содержимого сеанса.
Чтобы запустить пример конфигурации # 111 UltraESB, запустите его следующим образом и запустите два сервера Tomcat, как описано выше.
user@host:~/java/ultraesb-1.0.0/bin$ ./ultraesb.sh -sample 111
Чтобы сделать тестирование более значимым, вы можете отредактировать сервлет SessionExample в webapps / examples / WEB-INF / classes / SessionExample.java, чтобы сообщить имя экземпляра Tomcat в заголовке следующим образом:
Теперь, если исходный запрос был обработан «tomcat1», убейте этот экземпляр и повторите запрос — и вы попадете в экземпляр Tomcat2 следующим образом:
