Ответ
В микросервисной архитектуре используются устоявшиеся паттерны для решения общих проблем, таких как маршрутизация, отказоустойчивость и управление данными.
-
API Gateway
- Проблема: Как клиентам обращаться к множеству сервисов, не зная их адресов и не усложняя клиентский код?
- Решение: Единая точка входа, которая маршрутизирует запросы к нужным сервисам. Также может выполнять аутентификацию, авторизацию, SSL-терминацию, кэширование и агрегацию ответов.
-
Service Discovery (Обнаружение сервисов)
- Проблема: В динамической среде (контейнеры, VM) адреса сервисов постоянно меняются. Как сервисам находить друг друга?
- Решение: Центральный реестр сервисов (например, Consul, Eureka или встроенный механизм Kubernetes), где сервисы регистрируются при старте и куда другие обращаются за их актуальными адресами.
-
Circuit Breaker (Автоматический выключатель)
- Проблема: Один неработающий сервис может вызвать каскадный сбой всей системы из-за долгих таймаутов и исчерпания ресурсов.
- Решение: Паттерн, который отслеживает сбои при вызове сервиса. После определенного порога ошибок «выключатель» размыкается, и последующие вызовы немедленно завершаются ошибкой, не нагружая неисправный сервис. Пример в Go —
github.com/sony/gobreaker.
-
Saga
- Проблема: Как обеспечить консистентность данных между сервисами без использования распределенных транзакций (которые сложны и плохо масштабируются)?
- Решение: Управление транзакцией через последовательность локальных транзакций в каждом сервисе. При сбое одного из шагов запускаются компенсирующие транзакции для отката изменений. Бывает двух видов: Choreography (сервисы общаются через события) и Orchestration (центральный сервис-оркестратор управляет процессом).
-
CQRS (Command Query Responsibility Segregation)
- Проблема: Модель данных, удобная для записи, часто неэффективна для чтения, и наоборот.
- Решение: Разделение операций на команды (изменяющие состояние) и запросы (читающие состояние). Это позволяет использовать разные модели данных и даже разные базы данных для записи и чтения, оптимизируя каждую операцию независимо.
-
Event Sourcing (Событийная модель)
- Проблема: Как сохранить полную историю изменений состояния системы?
- Решение: Вместо хранения текущего состояния, система хранит полную последовательность событий, которые привели к этому состоянию. Текущее состояние можно восстановить, проиграв все события. Часто используется вместе с CQRS.
Ответ 18+ 🔞
Да блядь, ну вот смотри, микросервисы — это ж как табун овец, разбежавшихся по хуям. И чтобы они не перетоптали друг друга и не нассали в колодец, умные дядьки придумали паттерны. Это как правила выживания в этом ебучем зоопарке.
-
*API Gateway (Ебный швейцар)**
- Проблема: Клиенту надо позвать десять сервисов, а адреса у них меняются быстрее, чем трусы у мартышлюшки. И что, ему по каждому звонить отдельно? Заебись.
- Решение: Ставим одного крутого мужика на входе. Он один знает, кто где живёт. Клиент пришёл, сказал «нужна корзина и каталог», а этот швейцар сам сбегает, всё соберёт и отдаёт одной пачкой. Заодно и в дурку (неаутентифицированных) не пустит. Удобно, блядь.
-
Service Discovery (Где ты, сука?)
- Проблема: Сервисы в контейнерах живут, как бомжи — сегодня тут, завтра там. Один перезапустился — у него уже новый IP. Как им друг друга найти, если они сами хуй знают, где они?
- Решение: Делаем общую тусовку, типа «доски объявлений» (Consul, Eureka). Сервис встал — сразу кричит: «Эй, я тут, на таком-то порту!». Другой сервис хочет с ним потусить — идёт на эту доску, смотрит актуальный адрес и идёт в гости. Всё, проблемы нет.
-
Circuit Breaker (Автомат-хуятомат)
- Проблема: Один сервис лег и не встаёт. А другие-то товарищи наивные, продолжают ему стучаться: «Эй, ты живой? Эй, ответь!». И сами все зависают, ресурсы кончаются, и вся система накрывается медным тазом. Каскадный пиздец.
- Решение: Ставим умный рубильник. Он считает, сколько раз сервис не ответил. Как только перебор — херак! — рубильник вырубается. Все следующие вызовы сразу получают ошибку: «Сервис в жопе, не беспокоить». Система жива, ресурсы целы. Потом, через время, рубильник осторожно попробует «включить свет» — а вдруг тот сервис уже очухался? Гениально и просто.
-
Saga (Длинная и поучительная история)
- Проблема: Раньше была одна большая база и транзакция. Сделал пять действий — откатил всё к хуям, если ошибка. Теперь пять действий в пяти разных сервисах с пятью разными базами. Как сделать так, чтобы либо всё завершилось, либо нихуя не изменилось? Распределённые транзакции — это пиздопроебина полная, все их ненавидят.
- Решение: Делаем сагу. Это как план ограбления. Сначала идём в сервис «Заказ», создаём заказ. Потом идём в сервис «Оплата», списываем бабки. Если тут всё ок — идём дальше. Если на этапе оплаты всё пошло по пизде (карта не прошла), то надо откатить первый шаг — удалить заказ. Для этого сервис «Заказ» должен уметь отменять себя по команде. Либо сервисы сами договариваются через события (как в танце), либо есть главный по тарелочкам (оркестратор), который командует: «Сделай то! А теперь ты — откати это!». Сложно, но другого выхода нет.
-
CQRS (Разделяй и властвуй)
- Проблема: Ты пишешь данные в одну здоровенную таблицу с кучей связей, а потом пытаешься из неё же строить сложные отчёты. Это как из одной и той же кастрюли и суп варить, и говно кипятить. Получается медленно и вонюче.
- Решение: Разделяем, блядь! Пусть для записи (Command) будет одна оптимизированная модель — быстрая, согласованная. А для чтения (Query) — сделаем вообще отдельную, денормализованную хуйню, заточенную под конкретные отчёты. Можно даже в отдельной базе её держать. Пишем в одно место, а читаем из другого. Производительность взлетает, как ушлёпок с горки.
-
Event Sourcing (Память, как у слона)
- Проблема: В обычной базе ты хранишь только последнее состояние: «Баланс: 100 рублей». А как ты пришёл к этим ста рублям? Хуй знает. Может, было 200, потом списал 50, потом начислил 10, а потом ещё штраф 60. История потеряна.
- Решение: А давай хранить не состояние, а события! «Создан заказ», «Товар добавлен», «Оплата прошла», «Заказ отправлен». Вся история, как на ладони. Текущее состояние получаем, проиграв все события с начала. Хочешь посмотреть, как было вчера — отматывай события до вчерашнего дня и смотри. Часто эту хуйню используют с CQRS: события пишутся в лог, а на их основе строятся удобные модели для чтения. Мощная штука, но мозг сначала сносит.
Вот примерно так, ёпта. Без этих штук в микросервисах — как без штанов на параде: вроде идёшь, но все на жопу смотрят и смеются.