Комментарии 20
Продумывание верной архитектуры
Столько Redis'ов на схеме - это кластер имеется в виду?. Или реально у каждого сервиса по своему отдельному Redis (standalone или cluster?
Подобная архитектура позволяет писать и поддерживать код без дополнительных усилий, ну почти, если сравнить с монолитом.
Это шутка такая, да?
"Это не совсем способ, а быстрее подход."
Статья обработана синонимайзером?)
Ну недоступен один сервис. А точнее одна ДБ - авторизации, и? :-)
Причем в следствии "бага в софте ДБ" который вызвал "багу в данных системных объектов ДБ" которые "честно размножились" на все экземпляры ДБ.... :-)
Что используете для реализации материализированного представления данных? Например нужно отдать фронтенду список инвойсов (+ валюту инвойса) с их инвойсПродуктами (+ название продукта). Но в них есть ссылки на ресурсы других микросервисов (валюты, продукты).
используется АПИ шлюз, кафка и кеширование для редко меняющихся данных. Шлюз собирает данные по сервисам, кафка в основном распространяет данные для обновлений в сервисах которые не связаны со шлюзам (эта в основном фоновые задачи, рассчеты, заполнение базы)
Данный вопрос наверное больше относится к теме паттерн микросервисной архитектуры, о которой планирую написать следующую статью, за одно и разобраться более детально. Но могу ошибиться
Желательно достигать значений близко 99.99%.
Ставки падают, сорок лет назад люди стремились к (и воплощали) nine nines.
Доберётесь до реализации саги
Или реализации отчётов из всех бд
Расскажите ещё раз)
Давайте будем честны, схемы приведенные автором - сферический конь в вакууме. Отвал одного из сервисов . Не беда, если ошибка обработанна. А вот гонять гигабайты трафика внутри сети это огромная нагрузка на инфраструктуру. Которая нужна.... Ни за чем.
Пример - нужно провести платеж через банкинг и потом получить ответ . Сайт или клиент , отправляет запрос , смотрит ответ если есть проблемы , повторяет через время , после нескольких попыток - создаёт тикет в поддержку. И создаётся задача на планировщик который опрашивает пс. Ошибки в логе приложения , задача выполняется, нахрена усложнять простые вещи .
Всегда при внедрении микросервисов нагрузка ложится на инфраструктуру. И трафик возрастает просто до диких объемов. Когда нужно передать событие внутри приложения, это вызов метода. Тут же нужно отправить сообщение а кафку, или апи , или ещё чего-нибудь. То есть добавляем дополнительный узел отказа.
Вообще видел таких умников , раздувают технологии, потом увольняются... А мне все это расхлёбывать
Может, конечно, что-то не корректно, но это не выдуманная архитектура, а то что работает. В опыте это первый мой проект, и тут я встретил подобное, что мне очень удобно в плане разработки. У каждого разработчика своя ответственность, он ни с кем не конфликтует. Плюс логика разделена, за платежи отвечает один сервис, за обновление и синхронизацию другой и так далее. Разве не удобно
Надежность и устойчивость в микросервисной архитектуре