Как устроена архитектура интеграции сервисов и как они взаимодействуют?

Что проверяют

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

Как отвечать

Способы взаимодействия:

• синхронный вызов (HTTP с REST или gRPC): вызывающий ждёт ответ. Просто и понятно, но связывает сервисы по доступности;
• асинхронный обмен через брокер: сервис публикует событие, остальные подписываются. Развязывает по времени и по составу получателей, платит согласованностью в конечном счёте;
• обратные вызовы: внешняя система сама дёргает ваш адрес, когда что-то произошло. Требует проверки подписи и идемпотентности;
• пакетный файловый обмен: выгрузка по расписанию. Архаично, но для обмена с внешними организациями встречается постоянно;
• общая база на два сервиса это антипаттерн: схема становится общим контрактом, и изменить её никто не может.

Обвязка, без которой интеграция не работает в проде:

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

Наблюдаемость: сквозной идентификатор запроса во всех логах и трассировка, иначе разбор проблемы между тремя сервисами превращается в гадание.

Безопасность: взаимная проверка сертификатов или служебные токены, а не открытый доступ внутри периметра.

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

Где спотыкаются

Делают цепочки синхронных вызовов и получают отказ всей цепи.

Не делают обработчики идемпотентными.

Ставят повторы без предохранителя и добивают упавший сервис.

Интегрируются через общую базу.