Взаимодействие сервисов

Сервисы должны уметь договариваться

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

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

Что разберём

• Основы взаимодействия сервисов. Поймём, чем сетевой вызов отличается от обычного вызова метода и почему контракт между сервисами становится частью архитектуры.
• Синхронное взаимодействие. Разберём модель, где вызывающий сервис ждёт ответ и продолжает работу только после него.
• Асинхронное взаимодействие. Посмотрим, как передавать работу без ожидания немедленного результата и зачем это нужно при нестабильной или большой нагрузке.
• REST. Разберём распространённый HTTP-подход к API и правила, которые делают такой интерфейс понятным для клиентов.
• gRPC. Познакомимся с контрактами Protocol Buffers и эффективными RPC-вызовами между сервисами.
• Messaging. Увидим роль брокера сообщений между отправителем и получателем.
• Request-Response. Разберём взаимодействие, в котором один участник отправляет запрос и ожидает связанный с ним ответ.
• Publish-Subscribe. Посмотрим, как одно событие может независимо получить сразу несколько подписчиков.
• Идемпотентность. Научимся проектировать операции так, чтобы повторная доставка запроса или сообщения не портила состояние системы.

Сначала мы сформируем общую модель межсервисного вызова, затем сравним способы доставки, после этого разберём конкретные протоколы и паттерны, а в конце решим одну из главных практических проблем распределённой связи — повторы.