Микросервисы #

1. Монолит vs Микросервис #

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

Плюсы и минусы монолитов?

Плюсы:

• Не надо настраивать взаимодействие(Kafka например)
• Нет проблем с транзакциями в БД в отличии от микросервисов
• Выше производительность
• Простое развертывание для девопса
• Проще тестировать, т.к. монолит проще поднять нежели 10-ки микросервисов

Минусы:

• Если упадет монолит, то упадут все его части
• Долгая сборка тестов
• При увеличении нагрузки, приходится масштабировать всё приложение целиком, даже если проблема только в одной его части
• Сложность добавления нового функционала, т.к. надо понимать как компоненты работают, чтобы где то не упало что то
• Сложно добавлять новые технологии, потому что все взаимосвязано

Плюсы и минусы микросервисов?

Плюсы:

• Проще влиться в проект - не надо понимать весь проект
• Проще протестировать конкретный микросервис
• Отказоустойчивость – если упал какой-нибудь сервис, остальные продолжат работать
• Легче пробовать новые технологии, переписав один сервис, а не весь монолит
• Можно масштабировать только те сервисы, которые под нагрузкой, не трогая остальные

Минусы:

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

2. Паттерн Saga в микросервисной архитектуре #

Saga — это паттерн для управления распределёнными транзакциями в микросервисах. Он разбивает глобальную транзакцию на последовательность локальных транзакций, каждая из которых выполняется в рамках одного сервиса.

Решает проблему распределённых транзакций (которые отрабатывают в разных системах), чтобы при ошибке в одной из транзакций был rollback во всех

Плюсы SAGA

Минусы SAGA

Какие способы координации транзакций в Sag-e?

Для координации транзакций существует два основных способа:

• Хореография. Микросервисы сами обмениваются событиями между собой. Каждый сервис реагирует на события другого и выполняет свою локальную транзакцию, создавая новое событие для следующего сервиса
• Оркестрация. Есть один “управляющий” сервис, который следит за процессом. Он говорит каждому микросервису, что делать, и следит за успешностью каждого шага

Какие типы транзакций существуют в Sag-е (Компенсирующая, компенсируемая, поворотная, повторяемая)

• Компенсирующая - запускается, в случае возникновения ошибки в компенсируемой транзакции, которая откатывает все предыдущие транзакции
• Компенсируемая - это обычная транзакция, которую можно откатить в случае ошибки на следующих шагах
• Поворотная - это транзакция, после которой нельзя ничего откатить
• Повторяемая - это транзакция, которую можно выполнить снова, если возникли временные проблемы

3. CAP теорема #

CAP теорема гласит, что система может обладать лишь двумя из следующих трех свойств:

• C - Согласованность (Consistency). Данные во всех сервисах не противоречат друг другу
• A - Доступность (Availability). Система продолжает работу даже при частичном отказе сервисов
• P - Устойчивость к разделению (Partition Tolerance). Система продолжает работу при частичной потере коммуникации между сервисами

4. Паттерн Circuit Breaker #

Он мониторит вызовы к внешнему сервису и при обнаружении большого количества неудачных попыток временно “отключает” вызов, предотвращая падение всей системы. Circuit Breaker основывается на трех состояниях: закрытое, открытое и полуоткрытое

• Закрытое. Всё нормально, запросы проходят к сервису
• Открытое. Если ошибки становятся слишком частыми, Circuit Breaker перестаёт направлять запросы к проблемному сервису
• Полуоткрытое. После некоторого времени Circuit Breaker отправляет несколько тестовых запросов. Если всё нормально - он переходит в закрытое состояние. Если нет — остаётся в открытом состоянии

5. Паттерн API Gateway #

API Gateway это шлюз для API. Он анализирует запросы и решает, какой микросервис должен их обработать. Может объединять информацию от разных микросервисов в один ответ, а так же: управлять нагрузкой, кэшировать ответы (уменьшение времени отклика)

6. HTTP vs Kafka. Какой способ общения между микросервисами лучше и почему? #

• Использовать HTTP, если:

  • Нужно немедленное подтверждение результата (например, авторизация, выполнение команды).
  • Система проста и не требует сложной обработки сообщений.

• Использовать Kafka, если:

  • Требуется высокая производительность и масштабируемость.
  • Сервисы должны быть независимыми и работать асинхронно.
  • Важна надёжность передачи данных и минимизация влияния сбоев.

Идеальный подход — гибридное использование:

• Для взаимодействия в реальном времени применять HTTP.
• Для событийной модели и обработки больших объёмов данных — Kafka.

7. Шаблоны проектирования для микросервисов (паттерны) #