управление очередями

[grigori]

сервисы работают по шине, создают в ней очереди, шлют друг другу сообщения, и для каждого случая создаются отдельные очереди для каждого типа сообщений

когда этих очередей становится 100500, нужна координация, надо как-то сообщать сервису какие очереди слушать и в какие писать

что вы делаете для управления очередями?

 

[WMix]

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

 

[grigori]

ну, я немного обобщил, "очередями" я назвал все реализации передачи сообщений - fifo, pub/sub, stream, weighted, scheduled

бывает и "адресная" доставка, и публикация для всех слушателей

 

[grigori]

вопрос про эту конфигурацию очередей, через которюу связка - как она хранится, откуда сервисы берут имя очереди?
yaml, mysql, consul, etcd, хардкод или провиженинг при деплое?

 

[fixxxer]

ну ты вроде все разумные варианты перечислил

у меня не 100500, мне хардкода хватает
был бы service mesh, делал бы через него

 

[WMix]

конфигурация
у нас есть команды и маппинг типа того

return [
    \My\Command\Class1::class = [
        'name' => 'foo:bar',
        'options' => [
            ['force', 'f', InputOption::VALUE_NONE, "don't ask"]
        ]
    ]
];

ну титпа для

$ php app.php foo:bar -f

далее маппим топики на команды

return [
  Topics::name1 => ['foo:bar']
];

чтоб создать новое сообщение есть метод
public function add($name, $data);

далее крутится демон, while($this->keepRunning) видит что пришло новое сообщение из конфигурации понимаем набор обработчиков, создаем по процессу, запускаем,
на итерацию проверяем статусы процессов, собираем stdout/err, записываем.

 

[grigori]

а, у тебя топики pub/sub - их меньше надо, конечно, у меня queue в ampq с адресной доставкой, там этих каналов плодиться по несколько штук на сервис

 

[MiksIr]

Просто в файлике лежат как переменные для хельмов, а в приложение через env