Я разрабатываю бэкэнд для нового веб-приложения Java и пытаюсь решить, следует ли использовать Event Bus; в частности Guava EventBus.
Большинство запросов на стороне сервера будут синхронными: то есть пользователь запрашивает данные и требует ответа в течение нескольких секунд. Тем не менее, существует также довольно много запросов, которые могут быть асинхронными и "пожарными и забытыми" на стороне клиента. До тех пор, пока они в конечном итоге будут обработаны, клиент может заботиться о нем меньше, если он занимает 2 секунды для обработки или 2 часа.
Для этих асинхронных запросов я планирую, что сервлет, прослушивающий на сопоставленном URL, публикует запросы в очередь. Затем потребитель отбрасывает каждый запрос и направляет его соответствующему обработчику. Здесь EventBus может или не может вступить в игру. Бизнес-логика для маршрутизации запроса правильному обработчику довольно сложна. Обычно маршрут верблюда был бы идеальным решением. В моем случае я задаюсь вопросом, могу ли я просто подключить кучу "процессоров" (обработчиков событий) к одной и той же шине событий, а затем каждый из них запускает и принимает события друг с другом, пока не будет достигнут конечный результат производится.
Я хотел бы сказать, что я уже изучал использование Apache Camel и что я верю, что Camel - правильный инструмент для работы здесь. К сожалению, по причинам, выходящим за рамки этого вопроса, я не буду использовать его. Поэтому я начал выдумывать решения, подобные Camel, а именно то, как я прибыл в Guava EventBus. Но это может быть не подходящая замена.
Я думаю, что я ищу классификацию проблем, которую решает шаблон Event Bus, а затем мне нужно определить, соответствует ли это моему прецеденту.
