Фон: Наша существующая система вовлекает два сервиса (один записанный в Java, другой в PHP), которые общаются друг с другом использование обратные вызовы HTTP. Мы хотели бы переместить от обратных вызовов HTTP до основанного на сообщении использования архитектуры ActiveMQ (или другой, при необходимости). Мы будем, вероятно, использовать, ТОПАЮТ для передачи между ними. В конечном счете сервис PHP будет переписан в Java, но это не часть этого проекта.
Вопрос: Как система ActiveMQ может уведомить PHP, что новое сообщение было добавлено очереди, на которую подписана система PHP? В существующей системе обратный вызов по сути звонит в PHP и инициировал его. Это уходит с основанной на сообщении архитектурой.
Возможные решения:
Проверьте Camel . Он может работать как в ActiveMQ, так и отдельно. Camel создает «маршруты» для сообщений. В этом случае я бы посоветовал вам оставить URL-адрес обратного вызова PHP как есть и настроить маршрут в Camel, который принимает сообщения из очереди и отправляет их на URL-адрес обратного вызова. Затем вы можете использовать Stomp в PHP для отправки сообщений в ActiveMQ. Ваш код Java может просто использовать JMS как для входящих, так и для исходящих сообщений.
Вопрос: Как может система ActiveMQ уведомить PHP о том, что новое сообщение было отправлено в очередь, на которую подписана система PHP? В текущей системе обратный вызов по своей сути вызывает PHP и запускает его. Это уходит от архитектуры, основанной на сообщениях.
Я думаю, вы работаете не в том направлении. Потребители периодически проверяют очередь на наличие новых сообщений, а не наоборот. Если очереди необходимо уведомить потребителя о чтении из нее, значит, вы на самом деле не развязали эти приложения, как вы думаете.
Можно ли заставить ActiveMQ выполнять команды оболочки? Если это так, просто пусть ActiveMQ выполняет сценарий PHP через командную строку всякий раз, когда появляется новое сообщение для обработки. Это избавляет вас от выполнения заданий cron и от длительного цикла PHP.
Я думаю, что проблема, которую они пытаются решить, заключается в том, что стек LAMP (частью которого является PHP) по своей природе привязан к механизму запроса / ответа, который на него навязывает протокол HTTP, поэтому наличие очереди Consumer (которая проверяет ActiveMQ), написанной на PHP, возможно, но время жизни процессов, естественно, ограничено любым тайм-аутом в протоколе HTTP.решение одно из:
1 - Не запускайте подписчика PHP внутри apache / HTTP, и в результате вы можете выполнить set_time_limit (0), и подписчик php будет работать вечно (пока он все равно не выйдет из строя) , ИЛИ
2 - Поймите, что подписчик на самом деле просто выполняет «периодические» проверки без большого количества промежуточных операций, поэтому вместо while (1) {do_queue_stuff (); спать(); } вы удаляете засыпание, удаляете цикл while и повторно вызываете его из Cron или подобного.
У каждого есть свои преимущества, но оба одинаково хороши, ЕСЛИ частота cron () достаточно настраиваема. Мой Cron ограничен запуском каждую минуту, что не очень часто, поэтому мне пришлось бы использовать комбинацию двух вышеперечисленных: вызывается из cron каждую минуту:
time = what_minute_is_it (); while (what_minute_is_it () == время) { do_queue_stuff (); сон (1); }
Я думаю, что люди могут стремиться к тому, чтобы система ActiveMQ «намекнула» системе PHP Consumer, что в очереди может быть что-то, требующее обработки, и, как результат, сэкономить на запуске всей этой обработки очереди. / stop / sleep / и т. д., если на самом деле делать нечего. Кажется, верблюд - лучший способ сделать это.