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

Так работает Strangler Fig. Название переводится как “фикус-душитель” — растение, которое разрастается вокруг дерева и со временем может его вытеснить. В нашем случае монолит тоже может полностью исчезнуть, после чего ненужную промежуточную прослойку можно убрать. Хотя иногда разработчики оставляют основную бизнес-логику в монолите, не избавляясь полностью от него — это нормально. На время переезда система станет сложнее: поддерживать придётся одновременно монолит и новые сервисы, поэтому такой переход имеет смысл, когда у разделения уже есть причина.

В коде это может выглядеть так: все запросы, начинающиеся с `/podcasts-svc` или `/musician-svc` будут перенаправляться по HTTP в соответствующие микросервисы, а все остальные запросы обрабатываться самим монолитом.

Фух, вроде процесс пошел. После нескольких недель работы мы смогли избавиться от монолита. После разделения клиенту нужен способ обращаться к нашим сервисам. Можно дать клиенту (браузеру) адреса всех апишек: например, `podcasts-api.py-music.ru`, `musician-api.py-music.ru`. Клиент в таком случае четко понимает куда обращается. Но спустя пару недель с таким сетапом бэкендеры начали жаловаться: если раньше логика аутентификации, ограничения количества запросов по IP-адресу были на стороне монолита, теперь этот код повторяется в каждом микросервисе. Разработчикам и лиду бэкенда это показалось неудобным. В итоге решили добавить прослойку между клиентом и всеми сервисами, чтобы она сама занималась маршрутизацией, а также аутентификацией и рейт лимитингом. Такая прослойка называется API Gateway.

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

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

Паттерн Database per Service (каждому сервису – своя база данных) закрепляет данные за конкретным сервисом: только он напрямую читает и меняет свои таблицы, управляет схемой, миграциями и технологией хранения. Остальные получают данные через его API, например по HTTP, или через события в Kafka и RabbitMQ.

Как мы только что выяснили, наш Transactional Outbox может отправить одно и то же сообщение несколько раз. Причём повторная доставка возможна и без аутбокса: например, сервис уведомлений успешно отправил уведомление пользователю о новом подкасте, но упал до того, как подтвердил брокеру получение сообщения. В итоге брокер решит, что сообщение не было обработано, и отправит его повторно.

Для пользователя это может обернуться двумя одинаковыми уведомлениями о новом подкасте, а если речь идёт об обработке событий оплаты, последствия могут быть гораздо неприятнее.

Наша команда как раз начала сталкиваться с подобными ошибками: то кому-то 3 раза пришло одно и то же уведомление, то оплата списалась 2 раза вместо одного. Причем любопытно, что эти ошибки происходили часто при падении или перезагрузке приложения — и команда долго не могла понять что не так. Поспрашивав гугл и нейронки, команда отыскала паттерн под названием Idempotent Consumer, или идемпотентный потребитель. Суть довольно простая: повторная обработка одного и того же сообщения не должна приводить к повторному выполнению бизнес-операции. То есть не должно быть ни двух одинаковых уведомлений, ни двух одинаковых платежей.

Как это реализовать? Ещё на стороне отправителя, в нашем случае сервиса подкастов, мы создаём для каждого события уникальный идентификатор, например в формате UUID. Если событие будет отправлено повторно, его идентификатор останется прежним, а сервис уведомлений сможет проверить, не получал ли он уже такую задачку. Для этого он хранит идентификаторы обработанных сообщений, например в специальной таблице `inbox`, и при повторном получении просто пропускает обработку. Причём проверку и сохранение идентификатора нужно реализовать так, чтобы два параллельных обработчика не могли одновременно принять одно сообщение за новое.

Почему вообще возникает такая проблема? Дело в том, что в распределённых системах довольно сложно обеспечить так называемый Exactly-Once, когда сообщение гарантированно обрабатывается ровно один раз. Гораздо проще организовать повторную доставку сообщений и сделать их обработку идемпотентной. Правда, если в ходе обработки мы выполняем внешнее действие, например отправляем письмо, одного `inbox` может оказаться недостаточно для полного исключения дублей.

При этом важно понимать, что отдельный Inbox нужен далеко не всегда. Например, если мы просто устанавливаем пользователю статус `active = true`, повторное выполнение такой операции ничего не изменит. А вот если при каждом получении события мы увеличиваем баланс пользователя на 100 рублей, повторная обработка уже приведёт к ошибке. Поэтому стоит смотреть на конкретную бизнес-логику и понимать, насколько опасны для нас повторные операции.

Следующий паттерн — Saga. И здесь мы вернёмся к проблеме, которая возникла у нас после внедрения Database per Service.

Представьте, что мы хотим сделать обычную транзакцию в PostgreSQL, внутри которой изменяются данные сразу в нескольких таблицах. Это довольно простая история: начинаем транзакцию, выполняем несколько запросов и, если что-то пошло не так, откатываем изменения через `ROLLBACK`. Но теперь представьте, что эти таблицы находятся в разных базах данных, принадлежащих разным микросервисам. Как мы обсуждали ранее, напрямую обращаться к чужим базам мы не должны, а обычная транзакция PostgreSQL не позволяет просто объединить произвольные операции нескольких независимых сервисов в один `BEGIN` и `COMMIT`.

И здесь на помощь приходит Saga, которая позволяет согласовывать изменения сразу в нескольких микросервисах. Вместо одной большой транзакции мы выполняем несколько небольших, причём каждая из них происходит внутри своего сервиса. Если на каком-то этапе возникает ошибка, мы можем выполнить компенсирующие операции, которые исправят последствия предыдущих действий. То есть это чем-то напоминает обычный `ROLLBACK`, просто теперь нам приходится самостоятельно продумывать, как отменять изменения.

И последний паттерн, который мы сегодня разберём, — Circuit Breaker.

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

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

И вот здесь нам помогает Circuit Breaker, который позволяет временно прекращать обращения к проблемному сервису. Например, если за определённый промежуток времени сервис подкастов пять раз не ответил, Circuit Breaker может решить, что сервис сейчас недоступен, и на некоторое время перестать отправлять ему запросы. Причём вместо того, чтобы каждый раз ждать по 10 секунд, мы можем сразу возвращать запасной результат — например, просто не показывать блок с подкастами на главной странице.

Но ведь нам нужно как-то понять, когда сервис восстановится? Поэтому спустя некоторое время Circuit Breaker пропускает несколько пробных запросов, чтобы проверить, нормально ли работает сервис подкастов. Если всё хорошо, возвращаемся к обычному режиму, а если ошибки продолжаются, опять временно прекращаем обращения. Для этого Circuit Breaker использует три состояния: Closed — запросы проходят в обычном режиме, Open — обращения блокируются, Half-Open — проверяем, восстановился ли сервис.