Я новичок в Storm и изучал его возможности в соответствии с нашими требованиями CEP. Различные примеры, которые я наткнулся, реализуют носики как услугу опроса от брокера сообщений, базы данных. Как реализовать нагнетательный носик, т. Е. Сервер Thrift, работающий внутри носика? Как я должен информировать своих клиентов о том, где работают мои носики, чтобы они могли нажимать на него данные?Push stelled storm spout
Резервуары предназначены и предназначены для опроса, поэтому вы не можете нажать на них. Однако многие люди используют такие вещи, как Redis, Thrift или Kafka, как услуги, которые вы можете нажимать на сообщения, а затем ваш носик может их опросить.
Управление, которое у вас есть на том, где и когда работает носик, ограничено, так что это немного хлопот, чтобы внешние процессы связывались напрямую с носиками. Это, безусловно, возможно, но это не самое простое решение.
Стандартное решение состоит в том, чтобы выталкивать сообщения в какую-либо внешнюю очередь сообщений и позволять вашим носикам опросить эту очередь сообщений.
Есть реализации носиками, которые делают именно это для часто используемых служб очереди сообщений, таких как Кафка, пустельги и JMS, в storm-contrib
Я не целый большой опыт либо Бури или Кафка/Kestrel или CEP, в общем, но я ищу аналогичное решение - надавите на носик Storm. Как насчет использования балансировки нагрузки между источником событий и кластером Storm? Для моего случая использования Syslog-сообщений от rsyslog до Storm, балансировщик нагрузки может отслеживать, какие узлы Storm запускают прослушивающий носик, а какие - вниз, а также распределять входящую нагрузку на основе разных параметров. Я менее склонен представить другой слой, например, шину сообщений между источником и носиком.
Редактировать: Я читаю ваш блог и суммирую, если единственная проблема с прослушивающим носиком заключается в том, как источник найдет его, тогда шина сообщений может быть неправильным ответом. Существуют более простые/лучшие решения для прямого сетевого трафика в приемнике на основе простого состояния сети или более высокой логики уровня приложения. Но да, если вы хотите использовать все дополнительные функции шины сообщений, то, очевидно, Kafka/Kestrel будут хорошими вариантами.
Это не типичное использование Storm, очевидно, вы не можете связать несколько экземпляров носика на одной машине с одним и тем же портом. В распределенной настройке было бы неплохо сохранить текущий IP-адрес API и порт, например. на ZooKeeper, а затем на балансировщик, который будет перенаправлять запросы на ваш API.
Вот проект с простой REST API на Storm:
почему бы не позволить им передавать данные в очередь, как указано @Gordon .. п то и потреблять и кормить сообщение для Ur носики .. используя что-то вроде [storm] (https://github.com/nathanmarz/storm/wiki) с очередью сообщений, например [Kakfka] (http://kafka.apache.org/), может сделать вашу жизнь намного лучше, я верю .. что именно ваши требования? – user2720864