Apache Camel и балансировка нагрузки

Question

Мы планируем использовать Camel для интеграции между некоторыми внешними системами (FTP, SOAP-WS, REST-WS, темами, очередями и т. Д.).

Мы, вероятно, будем использовать конфигурацию Spring (контекст XML Camel), а поскольку количество информации велико, мы планируем развернуть ее в кластере Tomcat.

Я не нашел никакой документации, если это возможная конфигурация, и если оба приложения (пусть говорит, что это два tomcat для начала), могут помешать.

UPDATE

После использования Camel в течение трех лет она появляется это очень хорошо управляется в некоторых случаях: «JMS», и Web-служб, балансировка нагрузки работает хорошо в этих случаях, но в случае " JMS ', мы теряем порядок сообщений, если мы не используем заголовок JMSXGroupID.

Однако вопрос по-прежнему открыт для служб, которые потребляют из файла (или FTP, sFTP, FTPS). На данный момент мы активируем только одну ногу, чтобы потреблять из этого источника, и в случае, если нога опускается, к сожалению, нет автоматического запуска маршрута во втором ноге, чтобы потреблять файлы FTP.

Answer 1

До тех пор, пока вы не пишете на сеанс HTTP, вам не нужно ничего волновать - просто поместите некоторое количество узлов Tomcat за балансировщик нагрузки. Если вы пишете на сеанс HTTP, это все еще просто, но вы, вероятно, имеете (в зависимости от выбранной конфигурации) настройку репликации сеанса.

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

Оба этих приложения принимают HTTP-запросы. Один из них был полностью без гражданства (прокси-типа), а другой должен был хранить определенную информацию, относящуюся к сеансу. Для последнего мы должны были убедиться, что все объекты, помещенные в сеанс, являются Serializable и настраивают репликацию сеанса.

Мы провели много испытаний и, наконец, закончили проверенный сражениями DeltaManager, отсутствие липких сеансов и режим синхронной репликации. Это то, что вам нужно учитывать очень тщательно в зависимости от вашей архитектуры системы, но есть very good documentation, которые могут вам помочь.

Мы не использовали липкие сеансы, потому что каждый запрос состоял из большой обработки. Основа на тестах, которые мы сделали, и о характере запросов, для нас было лучше обработать циклическую обработку вместо того, чтобы снова нажимать один и тот же сервер для конкретного сеанса клиента. Также из-за отсутствия липкого сеанса мы использовали синхронную репликацию, чтобы убедиться, что все узлы получают полный сеанс до того, как ответ доставляется клиенту (он блокирует только этот единственный запрос, поэтому не стоит беспокоиться). Мы не хранили огромные объекты в сеансе (только некоторые важные сведения), поэтому у нас нет проблем с тем, что сеанс реплицируется во все узлы по умолчанию. Однако, если вы обнаружите, что это узкое место, вы можете уточнить конфигурацию, помещая некоторое подмножество узлов в кластеры.