Что такое consumer-driven contracts и зачем они нужны?

1️⃣ Как кратко ответить

Consumer-driven contracts — это подход к тестированию взаимодействия между микросервисами, где контракт между сервисами определяется потребителем (consumer) и проверяется поставщиком (provider). Они помогают гарантировать, что изменения в API поставщика не нарушат работу потребителя, обеспечивая стабильность и согласованность в распределенных системах.

2️⃣ Подробное объяснение темы

В современных распределенных системах, таких как микросервисные архитектуры, взаимодействие между сервисами происходит через API. Каждый сервис может быть как потребителем (consumer), так и поставщиком (provider) данных. Важно, чтобы изменения в API одного сервиса не нарушали работу других сервисов, которые зависят от него. Здесь на помощь приходят consumer-driven contracts.

Consumer-driven contracts (CDC) — это методология, при которой контракт между потребителем и поставщиком API определяется потребителем. Контракт описывает, как потребитель ожидает, что API будет себя вести. Поставщик затем использует этот контракт для проверки, что его API соответствует ожиданиям потребителя.

Зачем нужны consumer-driven contracts?

1. Стабильность системы: CDC помогает предотвратить ситуации, когда изменения в API одного сервиса нарушают работу других сервисов, которые от него зависят.
2. Независимость разработки: Потребители и поставщики могут разрабатывать и тестировать свои части системы независимо друг от друга, зная, что контракт обеспечит совместимость.
3. Ускорение разработки: CDC позволяет быстрее вносить изменения в систему, так как разработчики могут быть уверены, что их изменения не нарушат работу других сервисов.
4. Документация: Контракты служат живой документацией, которая всегда актуальна и отражает текущее состояние взаимодействия между сервисами.

Как это работает?

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

2. Проверка контракта: Поставщик использует контракт для тестирования своего API. Это может быть автоматизировано с помощью инструментов, таких как Pact, которые позволяют генерировать тесты на основе контракта.

3. Валидация изменений: Перед развертыванием изменений в API, поставщик проверяет, что его изменения не нарушают контракт. Это может быть частью процесса CI/CD.

Пример использования Pact

Pact — это один из популярных инструментов для реализации consumer-driven contracts. Рассмотрим простой пример использования Pact для тестирования взаимодействия между потребителем и поставщиком.

Пример кода

from pact import Consumer, Provider
import requests
​
# Создаем потребителя и поставщика
consumer = Consumer('ConsumerService')
provider = Provider('ProviderService')
​
# Определяем контракт
with consumer.has_pact_with(provider) as pact:
    # Ожидаемый запрос и ответ
    pact.given('User exists') \
        .upon_receiving('a request for user data') \
        .with_request('get', '/user/1') \
        .will_respond_with(200, body={'id': 1, 'name': 'John Doe'})
​
    # Проверка, что поставщик соответствует контракту
    with pact:
        # Выполняем запрос к поставщику
        response = requests.get('http://localhost:1234/user/1')
        # Проверяем, что ответ соответствует ожиданиям
        assert response.json() == {'id': 1, 'name': 'John Doe'}

• Создание потребителя и поставщика: Мы создаем объекты Consumer и Provider, которые представляют наш потребительский и поставщицкий сервисы.
• Определение контракта: Используем метод has_pact_with для определения контракта. В данном случае, мы ожидаем, что при запросе GET /user/1 поставщик вернет статус 200 и тело ответа с данными пользователя.
• Проверка контракта: Внутри блока with pact мы выполняем реальный HTTP-запрос к поставщику и проверяем, что ответ соответствует ожиданиям, описанным в контракте.

Consumer-driven contracts обеспечивают надежное взаимодействие между микросервисами, минимизируя риски, связанные с изменениями в API, и ускоряя процесс разработки.