Microservices

Как интегрировать микросервисы, управляемые событиями, с API-интерфейсами типа «запрос-ответ»?

Существует два типа внешних событий:

• Автономно генерируемые события (аналитические события)
• Реактивно генерируемые события (события от запроса-ответа)

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

• использование внутренних хранилищ состояний (с глупой или умной маршрутизацией)
• использование внешних хранилищ состояний (с обычным или с составным микросервисом)

Способы обработки запросов в рамках управляемого событиями рабочего процесса:

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

Подходы для приложений запрос-ответ, их плюсы и минусы:

Четвертый шаблон для создания микросервисов — использование легковесных фреймворков.

Легковесные фреймворки предоставляют функциональность, аналогичную тяжеловесным фреймворкам, но они в значительной степени зависят от:

• брокера событий
• системы управления контейнерами (CMS)

Во многих случаях они превосходят тяжеловесные фреймворки.

Различные приложения могут использовать любые/разные ресурсы из кластера, которые лучше соответствуют их потребностям. При этом по-прежнему обеспечивают масштабирование и восстановление после сбоев (опять же, сильно полагаясь на брокера событий и CMS).

К сожалению, на данный момент есть только два полнофункциональных варианта:

Тяжеловесные фреймворки потоковой обработки — это еще одна основа/шаблон для создания микросервисов.

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

Тяжеловесные фреймворки работают с использованием централизованных кластеров ресурсов, что может потребовать дополнительных операционных издержек, мониторинга и координации для успешной интеграции в среду микросервисов. Однако недавние инновации двигают эти фреймворки в сторону решений для управления контейнерами (CMS), таких как Kubernetes, которые должны сократить ваши усилия.

Базовой шаблон производителя и потребителя (BPC) — это простой шаблон для создания микросервисов. Он формирует основу сервисов без сохранения состояния и с сохранением состояния.

Вы можете использовать его для:

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

Но это требует ваших дополнительных усилий для реализации:

• простой материализации состояния
• скедулинга событий
• принятия решений на основе временных меток

Все это раскрыто в главе 10 книги, которую мы сейчас изучаем:

Функция как сервис (FaaS) — это область облачных вычислений, которая быстро развивается.

Здесь необходимо рассмотреть следующие вопросы:

• Принципы FaaS
• Открытый исходный код и сторонние поставщики FaaS
• 4 компонента, которые следует учитывать при построении микросервисов как функций
• Холодный пуск против теплого пуска
• Различные триггеры, которые могут запускать FaaS: запуск на основе новых событий, запуск на основе задержки группы потребителей, запуск по расписанию, запуск с использованием веб-перехватчиков, запуск по событиям ресурсов.
• Поддержание состояния
• Два шаблона функций, вызывающих другие функции: управляемый событиями и прямой вызов.
• Прекращение и завершение работы
• Настройка и масштабирование

Все это раскрыто в главе 9 книги, которую мы сейчас изучаем:

Существует два шаблона построения микросервисов, управляемых событиями:

• Хореография (без централизованной координации)
• Оркестровка (с централизованной координацией)

У обоих есть плюсы и минусы (однако мне кажется, что оркестровка все-таки более удобный шаблон)

Как реализовать распределенные транзакции с хореографией и оркестровкой.

Как ИЗБЕЖАТЬ реализации распределенных транзакций — подход с компенсационным рабочим процессом.

Все это раскрыто в главе 8 книги, которую мы сейчас изучаем:

“Создание событийно-управляемых микросервисов” Адама Беллемара. Оригинал: “Building Event-Driven Microservices: Leveraging Organizational Data at Scale” by Adam Bellemare

Основы событийно-управляемой обработки в архитектурах, управляемых событиями:

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

Эти темы раскрыты в главе 5 книги, которую мы сейчас изучаем:

“Создание событийно-управляемых микросервисов” Адама Беллемара. Оригинал: “Building Event-Driven Microservices: Leveraging Organizational Data at Scale” by Adam Bellemare

Введение в архитектуру микросервисов, управляемых событиями (EDM), состоит из следующих тем:

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

Эти темы раскрыты в главе 2 книги, которую мы сейчас изучаем:

“Создание событийно-управляемых микросервисов” Адама Беллемара. Оригинал: “Building Event-Driven Microservices: Leveraging Organizational Data at Scale” by Adam Bellemare

Книжный клуб нашей компании выбрал книгу о микросервисах. Это “Создание событийно-управляемых микросервисов” Адама Беллемара. Оригинал: “Building Event-Driven Microservices: Leveraging Organizational Data at Scale” by Adam Bellemare

Глава 1 содержит вводную информацию:

Типы архитектур и различия между ними:

1. Традиционные монолитные архитектуры
2. Сервисно-ориентированные архитектуры (SOA)
3. Архитектуры управляемых событиями микросервисов (EDM)

Уровни коммуникативных структур и связанный с ними закон Конвея:

• бизнес
• реализация
• данные

Проблемы с традиционными архитектурами (монолит и SOA), когда вам нужно:

• добавить новое бизнес-требование
• вырастить команду и разделить ее на две команды

И как избежать этих проблем при использовании архитектуры EDM

Есть ряд бизнесов и бизнес-задач когда необходимо визуально проектировать, изменять и контролировать исполнение бизнес-процессов.

Крупные компании уровня SAP, IBM, Oracle играют на этом рынке и предлагают свои тяжелые и дорогие решения.

Но есть и более легковесное и дешевое решение на этой поляне.