Содержание
- Краткое резюме
- Введение в микросервисную архитектуру
- Преимущества и недостатки микросервисной архитектуры
- Вызовы межпроцессного взаимодействия
- Стили взаимодействия микросервисов
- Особенности событийной модели
- Заключение и курс OTUS по микросервисам
- Резюме по выбору стилей взаимодействия
- Итоги
Краткое резюме
- Микросервисная архитектура является следующим этапом развития ПО после монолитных систем и сервис-ориентированных архитектур (SOA).
- Основные преимущества микросервисов: гибкость, масштабируемость, модульность, кроссплатформенность и локализация ошибок.
- Недостатки: технологическая сложность, сложность координации, расходы на инфраструктуру, тестирование и безопасность.
- Взаимодействия между микросервисами бывают синхронными (блокирующими), асинхронными (неблокирующими), через общие данные, запрос-ответ и событийные.
- Каждый стиль взаимодействия имеет свои плюсы и минусы, выбор зависит от конкретных бизнес-задач и требований.
- Использование брокеров сообщений и паттернов проектирования помогает строить отказоустойчивые и масштабируемые системы.
- В учебном курсе Вебинара OTUS по микросервисной архитектуре разбираются эти темы на практике с примерами, домашними заданиями и проектной работой.
Введение в микросервисную архитектуру
Первоначально программные системы создавались по монолитному принципу: два слоя — интерфейс пользователя и бизнес-логика с хранилищем данных — работали в одном приложении. Масштабирование такого приложения достигалось путем увеличения мощности одного сервера. Однако с ростом бизнеса и появлением новых требований монотонный монолит стал неэффективен: усложнилась поддержка, расширение и интеграция с новыми функциональностями и партнёрами.
В ответ возникла сервис-ориентированная архитектура (SOA), где функциональность делится на отдельные сервисы с чёткими обязанностями. SOA позволила масштабировать систему, локализовать изменения и смешивать различные технологии.
Для цифрового рынка с высокими пиковыми нагрузками появилась микросервисная архитектура, где большое приложение разбивается на множество небольших автономных сервисов с чётко определённой функцией. Каждый микросервис независим, взаимодействует по API и может разрабатываться разными командами на разных стековых технологиях.
«Микросервис — небольшой автономно работающий сервис с чётко определённой функцией.»
Преимущества и недостатки микросервисной архитектуры
Преимущества:
- Гибкость. Изменения в одном микросервисе не влияют на другие.
- Кроссплатформенность. Разные сервисы могут использовать разные языки и технологии.
- Модульность. Система делится на независимые компоненты, которые можно разрабатывать и поддерживать отдельно.
- Масштабируемость. Возможность горизонтального масштабирования — запуск нескольких копий сервиса.
- Безопасность. Разделение позволяет контролировать зависимости и локализовать ошибки.
- Стабильность. Ошибки в одном сервисе обычно не влияют на всю систему.
Недостатки:
- Технологическая сложность. Использование разнообразных технологий требует от команд широких знаний.
- Сложность координации. Регулирование взаимодействия между сервисами и управление сетью — сложная задача.
- Рост затрат на инфраструктуру. Каждому сервису необходима своя инфраструктура и мониторинг.
- Сложность тестирования. Нужно учитывать множество состояний и порядок взаимодействия.
- Проблемы безопасности. В микросервисах увеличивается число точек передачи данных по сети, что повышает риск кибератак.
Вызовы межпроцессного взаимодействия
Взаимодействия между микросервисами — это межпроцессные вызовы, которые требуют передачи данных по сети, сериализации/десериализации и сопровождаются задержками. В отличие от внутрипроцессных вызовов, межпроцессные требуют дополнительных ресурсов и порой вызывают проблемы производительности.
Для оптимизации межпроцессных вызовов рекомендуется:
- Уменьшать объём передаваемых данных, исключая избыточные поля.
- Использовать эффективные бинарные форматы сериализации (Protobuf, MessagePack вместо JSON).
- Применять асинхронные вызовы и пакетную передачу сообщений (batching).
«Если количество вызовов между микросервисами слишком велико, вероятно, возникла ошибка в архитектуре и стоит пересмотреть гранулярность сервисов.»
Стили взаимодействия микросервисов
1. Синхронная блокировка
- Микросервис делает вызов другому и ожидает ответ, блокируя выполнение.
- Прост в реализации, распространён в традиционных запросах (HTTP, SQL).
- Минусы: высокая связанность, замедление всей цепочки при сбое одного сервиса.
- Используется в простых случаях или при переходе от монолита к микросервисам.
- Улучшение: перевод долгих операций и вспомогательных процессов в фоновые задачи.
2. Асинхронная неблокирующая связь
- Отправитель вызывает сервис и продолжает работу, не ожидая немедленного ответа.
- Подходит для длительных процессов (например, обработка и доставка товара).
- Повышает устойчивость к недоступности сервисов.
- Сложнее в реализации из-за множества вариантов и выбора технологий.
- Используется для слабосвязанных процессов с разными временными интервалами.
3. Связь через общие данные
- Сервисы обмениваются данными через общее хранилище (базы данных, файловые системы).
- Асинхронный характер, сервисы сами проверяют наличие новых данных.
- Проста в реализации, подходит при ограничениях технологий.
- Минус — возможные задержки из-за пулинга и риск несоответствия схем данных.
- Используется для развязывания блокировок между компонентами.
4. Запрос-ответ
- Один сервис посылает запрос, ждёт и получает ответ.
- Может быть реализовано и в синхронном, и в асинхронном формате.
- Требует организации порядка и контроля транзакций.
- Используется, когда результат нужен для продолжения обработки или для компенсации ошибок.
5. Событийное взаимодействие
- Сервис публикует события, которые потребляются другими сервисами.
- Взаимодействие асинхронное и слабосвязное.
- Сервис-издатель не знает о потребителях событий.
- Обеспечивает масштабируемость и отказоустойчивость.
- Используются брокеры сообщений (Kafka, RabbitMQ).
- Применяется для широкого уведомления застав и реакции на состояние.
«Событийный стиль снижает степень связанности, что критично для масштабируемых и отказоустойчивых систем.»
Особенности событийной модели
- Событие — утверждение о факте (изменение состояния).
- Содержит идентификатор и необходимые данные (например, ID клиента, email).
- Возможны проблемы с избыточной связанностью, если сервисы требуют дополнительного обогащения данных.
- Баланс между слабой связанностью и объёмом передаваемой информации — ключевой момент при проектировании.
- Для надёжности доставки сообщений применяются механизмы гарантии типа «exactly once».
Заключение и курс OTUS по микросервисам
- Микросервисная архитектура требует глубокого понимания стилей взаимодействия и паттернов проектирования.
- OTUS предлагает онлайн-курс, стартующий 25 июня, длительностью 4 месяца, ориентированный на архитекторов, разработчиков и аналитиков.
- Программа курса охватывает: микросервисные паттерны, контейнеризацию, брокеры сообщений, принципы CICD, observability (мониторинг, алертинг), канвасы хранения и проектную работу.
- Обучение проводится на русском языке, с практическими заданиями и поддержкой наставников.
- После завершения выдается сертификат или диплом о переподготовке, возможен налоговый вычет.
- Курс подойдет слушателям с базовыми знаниями программирования (Java, Python и др.) и опытом работы с IT.
«Микросервисы — это не про конкретный язык, а про архитектурные решения для гибкости и масштабируемости.»
Резюме по выбору стилей взаимодействия
| Стиль взаимодействия | Плюсы | Минусы | Рекомендации к применению |
|---|---|---|---|
| Синхронная блокировка | Простота, понятность | Высокая связанность, проблемы масштабируемости | Простые сценарии, первые этапы миграции |
| Асинхронная неблокирующая | Отсутствие блокировок, масштабируемость | Сложность реализации и поддержки | Длительные процессы, слабосвязные операции |
| Через общие данные | Простота реализации | Задержки, риск несогласованности данных | Ограниченные технические условия |
| Запрос-ответ | Контроль результата, упрощение управления ошибками | Возможные задержки, сложности согласования | Когда нужен результат для дальнейшей обработки |
| Событийный стиль | Слабая связанность, масштабируемость | Сложности организации и поддержки | Массовая асинхронная коммуникация |
Итоги
Вебинар предоставляет основу по пониманию микросервисной архитектуры и стилей взаимодействия между сервисами. Глубокое освоение темы требует практики и систематического изучения паттернов. Для этого предлагает помощь курс OTUS, объединяющий теорию и практику, позволяющий освоить построение современных распределённых систем.
Спасибо за внимание!