Коммуникация приложений

Проектирование и разработка распределенных программных систем, лекция 4

Компоненты распределенной системы взаимодействуют и обмениваются данными

Сложности при взаимодействии

• Ненадежность сети и компонентов
• Рассинхронизация состояния
• Изменения в компонентах

Ненадежность сети и компонентов

• Ошибки
• Запрос не дошел
• Сервис упал

Рассинхронизация состояния

• Невозможно моментально распространять информацию в распределенной системе

Изменения в компонентах

• Изменения в одном компоненте не должны повлиять на другие компоненты
• Должна быть возможность адаптироваться под новый формат взаимодействия

Как приложения могут взаимодействовать?

• Общая БД
• Удаленный вызов
• Обмен сообщениями

Общая БД

Общая БД

Несколько компонентов пишут и читают данные в одной и той же базе данных.

Общая БД: плюсы

• Легко реализовать
• Поддерживается везде
• Данные между сервисами согласованы

Общая БД: минусы

• Внутренняя реализация компонента доступна другим компонентам
• Очень сложно изменить схему данных
• Есть обмен данными, но логику приходится дублировать
• Все компоненты привязаны к одной технологии
• Сложно масштабировать

Своя БД у каждого сервиса

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

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

Дрейф состояния

Из-за ошибок при синхронизации данных между сервисами может происходить рассинхронизация их состояний.

Эту проблему решают с помощью регулярной полной синхронизации данных («догонятор»).

Удаленный вызов

Удаленный вызов

• Идет напрямую к адресату
• Ожидает ответа (синхронный вызов, оркестрация)
• Используется там, где ответ важен сейчас

Удаленный вызов

• RPC
• SOAP
• CORBA
• HTTP API

Удаленный вызов

• RPC gRPC
• SOAP
• CORBA
• HTTP API

REpresentational State Transfer (REST)

• Сервер без состояния
• Ресурсы
• Методы ресурсов

REST API

REST API ≠ HTTP API

Сложности REST API

• Как осуществлять действия, не вписывающиеся в стандартные глаголы?
• Как отдавать вложенные ресурсы?

Возможные решения

• HTTP API без REST
• GraphQL

GraphQL

Формат данных

• XML
• JSON
• Protocol buffers

Удаленные вызовы: плюсы

• Стандартизация
• Не требует дополнительной инфраструктуры
• Можно сохранять внешний интерфейс, меняя внутреннюю реализацию компонента

Удаленные вызовы: минусы

• Снижает скорость обработки запросов
• Сервер должен быть доступен, чтобы ответить
• Нужно предотвращать каскадные отказы

Обмен сообщениями

Обмен сообщениями

• Сообщение отправляется в брокер сообщений (например, RabbitMQ)
• Отправитель не ожидает ответа (асинхронный вызов, хореография)
• Получатели подписываются на определенные сообщения и обрабатывают их в порядке очереди
• Отправитель не получает ответа от получателя

Обмен сообщениями: плюсы

• Очень слабая связанность компонентов
• Регулируемая нагрузка
• Не требуется одновременная доступность отправителя и получателя
• Хорошо подходит для длительных задач

Обмен сообщениями: минусы

• Сложная модель программирования
• Требуется дополнительная инфраструктура
• Очередь может стать узким местом в производительности
• Несогласованность данных

Задача

Есть N микросервисов, каждый хранит у себя часть данных. Например: данные о пользователе, оплаты пользователя, начисления и списания продуктов, аналитика мобильного приложения. Заказчик просит сделать endpoint, который вернет данные с возможностью фильтровать и сортировать по любым полям, при этом нужны данные из всех микросервисов. Дополнительно должна быть возможность пагинации. Какие технические решения возможны и как ты будешь выбирать подходящее?

Ходить в БД микросервисов

Собирать данные напрямую из хранилищ, которыми пользуются микросервисы.

Ходить в БД микросервисов

• Можно сделать легко и быстро
• Не нужно вносить изменения в микросервисы
• Данные максимально актуальные

​

• Сломается на следующий день

Собирать данные в момент запроса через API

Когда приходит запрос на наш endpoint, делать запросы в другие микросервисы и формировать ответ из их результатов.

В микросервисах должны быть API, через которые мы можем фильтровать данные так, как нам надо.

Собирать данные в момент запроса через API

• Почти так же легко и быстро, как общая БД
• Интерфейс API не поменяется без предупреждения

​

• Может потребоваться работа на стороне микросервисов
• Ответ будет формировать долго
• Не получится реализовать все виды фильтрации и пагинацию
• Не cможем обработать запрос, если какой-то из N микросервисов упадет

Регулярно загружать данные через API в свою БД

Периодически по крону делать запросы во все микросервисы, чтобы собрать с них данные и сложить в свою БД.

В микросервисах должны быть API, через которые мы можем полностью выгружать необходимые нам данные.

Регулярно загружать данные через API в свою БД

• Все данные у нас, можно быстро выбрать нужные
• Можно использовать идеально подходящую модель данных

​

• Может потребоваться работа на стороне микросервисов
• Больше работы на нашей стороне
• Рассинхронизация данных (в рамках часа)

Собирать данные в свою БД через события

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

Наш сервис подписывается на события и обновляет свою БД.

В микросервисах должны быть API, через которые мы можем полностью выгружать необходимые нам данные (для догонятора)

Собирать данные в свою БД через события

• Быстрая выборка данных
• Идеальная модель данных
• Слабая связанность с другими микросервисами
• Небольшая рассинхронизация (до нескольких секунд)

​

• Может потребоваться работа на стороне микросервисов
• Много работы на нашей стороне

Итоговое решение?

Итоговое решение

Если бизнесу нужно срочно, делаем быстрое решение, потом заменяем нормальным.

Комбинируем стили взаимодействия по ситуации:

• Данные меняются редко — периодически опрашиваем
• Данные не используются для фильтрации — обогащаем на лету
• Нужны актуальные данные — подписываемся на события

Литература