В чем отличие микросервисной архитектуры от монолита?
Что проверяют
Понимаете ли вы, что микросервисы это компромисс, и можете ли назвать, что именно усложняется. Для тестировщика ещё и то, как меняется проверка.
Как отвечать
Монолит это одно приложение и одна база: единый деплой, вызовы внутри процесса, транзакция охватывает всю операцию. Микросервисы это набор отдельно разворачиваемых сервисов со своими базами, общающихся по сети.
Что даёт разделение: команды выкатываются независимо, отказ одного сервиса не обязательно роняет всё, масштабировать можно только узкое место, технологии выбираются под задачу.
Чем платят, и это главная часть ответа: сеть ненадёжна, и любой вызов может не дойти или прийти дважды; распределённой транзакции нет, вместо неё согласованность в конечном счёте и саги с компенсациями; отладка требует сквозной трассировки; данные размазаны, и «просто сделать join» больше нельзя; инфраструктуры и наблюдаемости нужно втрое больше.
Что меняется для тестирования:
> «Модульные и API-тесты остаются у каждого сервиса. Появляются контрактные тесты, чтобы изменение ответа не сломало соседей. Интеграционные проверки поднимают зависимости в контейнерах или заменяют заглушками. Отдельно проверяются повторная доставка сообщений, поведение при недоступности соседа и таймауты. Сквозные сценарии становятся дорогими, поэтому их держат мало и только на критичный путь».
Где спотыкаются
Считают микросервисы по умолчанию лучшим выбором.
Не могут назвать ни одной сложности, кроме «сложнее разворачивать».
Забывают про согласованность данных, а это главная боль.
Предлагают одну общую базу на все сервисы, что убивает саму идею.