Что такое зависимость между микросервисами
Что проверяют
Понимаете ли вы, что зависимость бывает разной, и знаете ли, чем опасна связанность по доступности.
Как отвечать
Зависимость это ситуация, когда один сервис не может выполнить свою работу без другого. Виды различаются по силе связи.
Синхронный вызов: самая сильная связь. Вызывающий ждёт ответа, поэтому зависит по доступности. Это ключевой момент: доступности перемножаются. Четыре сервиса по 99,9% в цепочке дают уже 99,6%, а это в четыре раза больше времени простоя. Плюс задержки складываются.
Асинхронное событие: слабая связь. Отправитель не знает получателей и не ждёт их. Получатель может быть недоступен и разберёт очередь позже. Плата это согласованность в конечном счёте.
Общие данные: сервисы работают с одной базой. Формально связи в коде нет, а фактически схема стала общим контрактом, и изменить её никто не может в одиночку. Считается антипаттерном.
Общая библиотека: связь на уровне сборки. Удобно для утилит, опасно для предметной логики: обновление библиотеки заставляет пересобирать и выкатывать всех.
Зависимость по контракту: даже при асинхронном обмене формат сообщения связывает стороны. Изменение обязано быть обратно совместимым.
Как уменьшать связанность:
- события вместо вызовов там, где ответ не нужен немедленно;
- локальная копия справочных данных, чтобы не ходить за ними на каждый запрос;
- правильные границы: если два сервиса постоянно дёргают друг друга, скорее всего граница проведена не там, и это один сервис;
- обязательная обвязка на каждый синхронный вызов: таймаут, ограниченные повторы, предохранитель, осмысленная деградация.
Отдельно про циклические зависимости: два сервиса, вызывающие друг друга, это удвоенная задержка, риск взаимного ожидания и невозможность выкатывать их независимо. Лечится вынесением общей части или объединением.
Где спотыкаются
Не учитывают перемножение доступностей в цепочке.
Интегрируются через общую базу.
Кладут предметную логику в общую библиотеку.
Строят синхронные цепочки без таймаутов и предохранителей.