d'Ivan, всё хорошо. Чистим мусорные компоненты из развёрнутой копии сайта. Из модификаций делаем только косметику, а все работы по логике и доп. функционалу будут проводиться только после окончания расчистки, т.е. месяца через полтора-два. Таков родмап этого сайта.
Спасибо за подверждение моих умозаключений и опасений! Исходников проекта нет ни у кого - в процессе разматывания клубка выяснилось, что у подрядчиков были субподрядчики и работа нам кодом сайта шла по аналогии с гугл-табличкой, к которой есть доступ у 20+ человек. Никакого репозитория с коммитами и историей никогда не было - просто диск с грудой файлов. Будем думать что делать...
Refguser, как раз из-за того, что у меня есть сомнения в рекомендациях маркетологов, я и прошу рекомендаций на этом ресурсе. Я же не знаю какие CMS будет сопровождать проще, а какие сложнее. А сравнение с врачами и сантехниками здесь, увы, неуместно : )
tgarl, Сейчас спасает полная копия сайта, развёрнутая под тестовым доменом - вносятся изменения сначала в неё, если работает - перетаскиваем на прод версию. К сожалению, файлов так много, что вручную проверить всё выйдет дороже, чем делать сайт заново (тем более он не настолько большой). Спасибо за ответ, теперь хотя бы понятно, что задача громоздкая и по времени дорогая.
Adamos, я тоже разделяю мысль, что следует просто поддерживать текущий сайт, одновременно создавая аналог на другом сервисе. Пара на примете у маркетологов есть, но может вы что-нибудь можете порекомендовать? Смотрели в сторону конструктора от Т-Банка. У нас требований к функционалу немного:
- заполнять, менять, добавлять карточки;
- изменять ленты (новостей, продуктов и т.д.);
- добавлять страницы с самописными компонентами через iframe;
Спасибо, что не прошли мимо вопроса!
На самом деле эта схема уже сильно устарела) Однако, касательно именно этого рисунка - здесь сервисы "А" и "Б" вообще не знают о существовании друг друга. "А" просто кидает сообщение в RabbitMQ, а "Б" отрабатывает все новые, без передачи какой-либо обратной связи.
В результате просто распилили REST API и интеграционную шину на несвязанные между собой сервисы, т.е. REST API просто получает данные от клиентов и мнгновенно заносит их куда нужно, а шина уже работает с данными в своём темпе.
Vitsliputsli, спасибо вам за мини-консультацию. Теперь у меня хотя бы есть понимание в какую сторону двигаться и в каких парадигмах сочетаются REST API и брокеры. Думаю, что ветку можно считать закрытой.
Vitsliputsli, я разделяю ваши сомнения насчёт того, что брокер кажется излишним в этой небольшой цепочке сервисов. Изначальные мои схемы были без брокера, однако, мы будем соединять разношёрстные системы (SaaS-решения и софт на разных языках), а точкой распределения данных будет брокер. Хотя изначально вопрос ставился о том, нужно ли присоединять к нему REST API, через этот диалог постепенно прихожу к выводу, что это как минимум разделит ответственность между FastAPI-приложением и воркерами. Но теперь главный фокус будет на брокера, чтобы в нём не было никакого простоя.
Vitsliputsli, в принципе, всё что вы сказали коррелирует с тем, как мы хотим организоваться. Тогда подитожу:
1) Клиент шлёт запрос через API-шлюз, запрос попадает в FastAPI-приложение;
2) Приложение назначает запросу id и размещает его как сообщение в заранее объявленной durable-очереди RabbitMQ и ждет по нему ответа;
3) Сервис-обработчик прослушивает эту очередь, скачивает сообщение, работает с ним, а затем отправляет json с данными и кодом ответа;
4) Приложение обнаруживает, что сообщение обработалось и возвращает клиенту его содержимое;
5) Если всё завершилось ожидаемым сценарием, приложение закрывает сообщение с флагом "ack".
Сейчас у меня такая картина шины данных с брокером. Надеюсь, у вас тоже.
сергей кузьмин, наши шлюзы для API представлены как SaaS-решение, защищены политиками на уровне OpenAPI-3 и балансировщиком нагрузки. Но как передавать запросы со шлюза до сервера и брокера, в принципе, понятно.
Vitsliputsli, сейчас почти все сервисы работают как прямые интеграции, т.е. креды прописаны в каждом сервисе и запись напрямую в боевые БД. Правильно ли я вас понимаю - задача в том, чтобы назначить условный id (например либой uuid) сообщению (которое является post / get запросом клиента), а после этого "скачать" результат исполнения этой очереди и отдать его клиенту? В таком случае http-соединение не порвётся, так? Чувствуется, что время ожидания вырастет, но врядли это критично, если данные станут реально персистентны. P.s. 4я встреча по обсуждению плюсов/минусов послезавтра
