Как происходит взаимодействие серверов между собой
Что проверяют
Понимаете ли вы, как связаны сервисы, чтобы тестировать не только интерфейс, но и то, что за ним. Интервьюер ждёт синхронные и асинхронные способы и то, как вы проверяете каждый. Следом обычно спрашивают, как протестировать ситуацию, когда один из сервисов недоступен.
Как отвечать
Сначала способы связи:
- REST: HTTP с JSON, сервис вызывает соседа и ждёт ответа. Важны коды статусов, таймауты и повторы;
- gRPC: поверх HTTP/2, данные в Protobuf, контракт описан в
.proto. Быстрее и строже по типам, но из браузера руками не проверишь, нуженgrpcurlили Postman; - SOAP: XML и WSDL, встречается в банках и старых интеграциях;
- брокер сообщений: сервис кладёт событие в Kafka или RabbitMQ и не ждёт ответа. Потребитель обработает его позже, возможно повторно;
- вебхуки: внешний сервис сам вызывает ваш URL при событии.
Между сервисами обычно стоят балансировщик или API-шлюз, а сквозной запрос несёт trace id, по которому его видно во всех сервисах, например в Jaeger или Grafana Tempo.
Потом как это тестировать:
- контракты: проверка схемы ответа, контрактные тесты вроде Pact;
- заглушки: WireMock или моки, чтобы изолировать сервис от соседей;
- асинхронность: убедиться, что событие реально ушло в топик, через Kafka UI или консольный консьюмер, и что потребитель спокойно пережил дубль;
- отказы: сосед вернул 500, ответил через 30 секунд, не ответил вовсе. Что увидит пользователь и не спишутся ли деньги дважды.
Где спотыкаются
Тестируют всё только через интерфейс. Когда что-то падает, непонятно, в каком из пяти сервисов проблема.
Считают, что брокер доставит сообщение ровно один раз. Обычно гарантия at-least-once, и проверка на дубликаты входит в тест.
Проверяют только успешный ответ соседа. Самые дорогие баги живут в таймаутах и частичных сбоях.