Что такое микросервисная архитектура и какие вызовы она создает для тестирования?

Давай разберём эту микросервисную хрень, как она есть. Представь, что раньше у тебя была одна здоровенная, монолитная бандура — как будто ты купил целый торт. Уронил его — всё, пиздец, весь торт на полу. А теперь этот торт порезали на кусочки, и каждый кусочек живёт своей жизнью на отдельной тарелке. Это и есть микросервисы. Вроде бы удобно: один кусок упал — остальные целы. Но теперь, чтобы попробовать торт, тебе надо бегать между десятью тарелками с вилкой. Вот это и есть наша, блядь, работа.

Основные задачи, от которых волосы дыбом встают:

1. Окружение, ёпта, просто овердохуища сложное. Раньше запустил одно приложение — и всё. А теперь тебе надо поднять целый зоопарк: один сервис заказывает, другой платит, третий шлёт уведомления, а все они ещё и между собой болтают. Если какой-то из них ляжет, нихуя не работает. Спасают только Docker Compose или Kubernetes, которые всю эту мартышлюшку собирают в кучу одной командой. Просто пишешь конфиг, и он тебе разворачивает всё, как по маслу.

   # docker-compose.yml (кусок)
   version: '3.8'
   services:
     order-service: # Этот чувак заказы принимает
       build: ./order-service
       depends_on:
         - postgres-orders # И орет на свою базу данных
     payment-service: # А этот бабки считает
       build: ./payment-service
     postgres-orders: # Сама база, тихая и спокойная
       image: postgres:13

2. Интеграционное тестирование — это пиздец и боль. Самое страшное — когда сервисы друг друга не понимают. Один говорит: «Дай статус заказа», а другой в ответ: «Пошёл на хуй, я тебя не знаю». Чтобы такого не было, нужно контрактное тестирование. Это как два соседа договариваются: «Я стучу три раза — ты открываешь». Инструменты типа Pact это и проверяют. Один сервис (потребитель) говорит: «Я буду слать тебе вот такой запрос», а второй (поставщик) должен ответить точно так, как договорились. И если он вдруг начнёт выёбываться и слать другое, тесты это сразу выловят.

   // Пример такого договора (контракта) в Pact
   await provider.addInteraction({
     state: 'платёж принят', // Состояние: всё ок
     uponReceiving: 'запрос на обработку платежа', // Когда приходит запрос...
     withRequest: { // ...такого вида
       method: 'POST',
       path: '/api/payments',
       body: { orderId: '123' },
     },
     willRespondWith: { // ...ты должен ответить вот так
       status: 201,
       body: { paymentId: Matchers.uuid(), status: 'ACCEPTED' },
     },
   });

3. Тестирование на прочность — устроим им ад. Это самое весёлое. Надо проверить, что будет, если один сервис сдохнет. Упадёт платёжка — заказы тоже посыпятся или система будет держаться? Для этого есть Chaos Engineering. Можно специально убивать сервисы, создавать сетевые задержки или нагружать систему до упора. Инструменты — Chaos Monkey или Litmus. Если после таких издевательств основная функция жива — значит, архитектура годная.

4. Сквозные (E2E) тесты — медленные и ненадёжные, как хуй в пальто. Запустить тест, который проходит через 10 сервисов, — это как отправить письмо голубем: долго, и он ещё может по дороге обосраться. Поэтому такие тесты делаем только для самых главных сценариев (например, «создать заказ и оплатить»). Всё остальное покрываем изолированными тестами каждого сервиса и теми самыми контрактами между ними. Доверия ебать ноль к хрупким E2E-тестам, которые падают из-за ерунды.

5. Мониторинг и логи — без них ты слепой. Когда всё падает, главный вопрос: «А кто виноват?». Если каждый сервис пишет логи в свою дыру, искать причину — это пиздец. Поэтому все логи нужно сливать в одно место (ELK Stack, Loki). А ещё лучше — использовать распределённую трассировку (Jaeger, Zipkin). Она позволяет проследить один запрос через все сервисы, как нитку через бусины. Увидел, на каком сервисе нитка оборвалась, — вот тебе и виновник.

Что в этом хорошего? Ну, если не охуеть от сложности, то плюсы есть. Каждый сервис можно тестировать отдельно, быстро и без всей этой движухи вокруг. Юнит-тесты бегают за секунды. И если нужно обновить один сервис, не надо пересобирать и перетестировывать всю эту махину. В общем, игра стоит свеч, но готовься, чувак, тут тебе мозги точно понадобятся.