Микросервисная архитектура популярна, даже для небольших приложений. Развертывая сервисы в облаке, взаимодействие между ними происходит по сети, что влечет за собой ряд проблем.
Проблемы взаимодействия микросервисов по сети
- Доступность: Не всегда известно, какой микросервис доступен, а какой недоступен или потерял соединение.
- Задержка, потери и дублирование пакетов: Отправленный пакет может не быть принят получателем или принят несколько раз. Проблема иллюстрируется задачей двух генералов: невозможно гарантировать доставку сообщения между двумя сторонами, разделенными сетью.
- Нагрузка на трафик и память: Высокая нагрузка требует оптимизации общения, что усложняет процесс. Асинхронные системы требуют хранения информации, что создает вопросы утилизации памяти и дискового пространства.
- Отказоустойчивость: Падение одного сервиса может вызвать каскадное падение других, если они не могут получить ответ на запрос.
Способы общения микросервисов
Существует множество решений для взаимодействия микросервисов; идеального варианта не существует. Они делятся на синхронные и асинхронные.
Синхронные способы общения
- REST API: Один из самых популярных способов. Использует HTTP и JSON. Прост в использовании и отладке, но синхронный характер создает проблемы при недоступности сервиса. Текстовый формат приводит к лишнему трафику и потребляет ресурсы процессора. Отсутствует жесткая схема данных (хотя можно использовать OpenAPI/Swagger).
- gRPC: RPC на бинарном формате поверх HTTP/2 от Google. Эффективнее REST в плане трафика, имеет схему данных (DTO), обеспечивающую обратную совместимость. Поддерживает стриминг и back pressure. Недостаток – необходимость подключения библиотеки gRPC для каждого языка.
- SOAP: RPC с форматом XML. Часто встречается в старых системах. XML-формат сложнее JSON, многословнее и менее эффективен.
Асинхронные способы общения
- Message Brokers (RabbitMQ, ZeroMQ, ActiveMQ): Позволяют отправлять сообщения, которые будут обработаны позже. Бывают с брокером и без, с хранилищем и без, с балансировкой нагрузки и без, с подтверждением получения или без. Выбор зависит от конкретных потребностей проекта.
- Kafka: Похожа на message broker, но имеет отличия. Используется для построения модели «издатель-подписчик». Подходит для сложных архитектур с большим количеством сервисов. Сложна в настройке и требует глубокого понимания.
Сравнение инструментов
REST API удобен для небольших нагрузок и простого мониторинга. Kafka подходит для сложных архитектур и больших объемов данных, но сложна в настройке и эксплуатации. gRPC эффективен при высокой нагрузке и большом объеме данных, но менее удобен для внешних пользователей. SOAP используется редко, в основном для взаимодействия со старыми системами.
Выбор инструмента зависит от конкретных требований проекта: нагрузка, требования к отказоустойчивости, сложность архитектуры и другие факторы. Асинхронное взаимодействие обеспечивает отказоустойчивость, но усложняет отладку и мониторинг.
Выбор оптимального способа общения микросервисов зависит от многих факторов. Важно понимать преимущества и недостатки каждого решения, чтобы выбрать наиболее подходящий вариант для конкретного проекта.