«phpClub» — архив тем ("тредов"), посвящённых изучению PHP и веб-технологий.
Аноним 2022/05/27 15:15:28  №2364965 1
>>2347129 (OP)
Доброго времени суток, форумчане. Просветите в вопросе о микросервисах.
Знаю что есть разные протоколы для связи между сервисами, типа http, amqp. И так вот: допустим есть микросервис-шлюз на него делает запрос пользователь(хочет что-то получить). Шлюз в свою очередь дергает нужный микросервис путём помещения job'a в очередь rabbitmq. В итоге обмен данными между сервисами происходит асинхронно, каким тогда образом шлюз должен дождаться ответа от сервиса, чтобы вернуть пользователю?

Я подозреваю что в таких случая общение между сервисами реализуется по другому, например http.
А такой синхронный тип общения между сервисами самый частный получается rabbitmq редко юзается?
Ответы: >>2374470
Аноним 2022/05/29 08:38:00  №2366172 2
image.png (9, 552x125)
125x552
Вопрос по Yii2.
В туториале ошибка валидации отображается красным цветом. Почему у меня черный? Как сделать красным?

На stackoverflow есть только один топик с такой проблемой. Решения предлагаются такие
1. В лоб прописать css.
2. Залезть в vendor и нахимичить с ассетом бутстрапа.

Я правильно понимаю, что вторым лучше не заниматься?
Есть ли другие способы кроме прописывания css?
Ответы: >>2366277 >>2374470
Аноним 2022/06/07 21:53:00  №2374470 3
>>2366172

То, что в папке vendor это сторонние библиотеки и править там что-то просто глупо. Так как при обновлении библиотеки все твои правки будут перезаписаны.

В твоем случае, скорее всего эту надпись выводит какой-то виджет, который отвечает за вывод полей формы. Тебе надо посмотреть, какие классы и правила CSS применены к этой надписи, узнать, как можно заменить стили форм на свои, и в своих стилях прописать нужные тебе правила.

>>2364965

А зачем в твоем примере rabbit? Его добавление выглядит как лишнее усложнение. Проще отправлять запросы напрямую.

Очереди событий, однако, имеет смысл использовать для надежного сохранения каких-то данных, если сами сервисы ненадежные. Например, ты пишешь госуслуги и у тебя есть сервис обработки заявлений на смену налогообложения. Сервис кривой и ненадежный, и если ты передаешь заявление пользователя в него, то он легко может его потерять.

Здесь мы используем очередь. Мы кладем заявление пользователя в очередь, а сервис налогообложения берет его из очереди и, если заявление успешно обработано, помечает заявление выполненным. А если сервис не смог обработать и упал, то заявление остается в очереди. Теперь заявление не потеряется.

Заметь, что если твой сервис надежный, то очередь становится не нужна. Но скорее всего сервис надежный как раз потому, что внутри него уже организована очередь - может не на основе rabbitmq, а например, в базе данных, но это все равно очередь с точки зрения архитектуры. И потому вторая очередь тут не нужна.

Другой пример использования очередей - фоновая обработка задач. Пользователь загружает на сайт видео, и тебе надо его конвертировать, но это медленно. Ты добавляешь задачу на конвертацию в очередь, и фоновый скрипт рано или поздно дойдет до нее и выполнит. А если не выполнит, то задача останется в очереди. Опять же, вместо rabbit ты можешь использовать очередь на основе БД.

То есть, попробуй при проектировании подумать, зачем тебе нужна очередь и что она дает. Никто не проектирует архитектуру наугад, каждое решение на чем-то основывается, есть причина, почему делают так, а не иначе.