Как интегрировать микросервисы, управляемые событиями, с API-интерфейсами типа «запрос-ответ»?
Существует два типа внешних событий:
Автономно генерируемые события (аналитические события) Реактивно генерируемые события (события от запроса-ответа) Существует два подхода к обработке и обслуживанию запросов с использованием сервисов с отслеживанием состояния:
использование внутренних хранилищ состояний (с глупой или умной маршрутизацией) использование внешних хранилищ состояний (с обычным или с составным микросервисом) Способы обработки запросов в рамках управляемого событиями рабочего процесса:
Четвертый шаблон для создания микросервисов — использование легковесных фреймворков.
Легковесные фреймворки предоставляют функциональность, аналогичную тяжеловесным фреймворкам, но они в значительной степени зависят от:
брокера событий системы управления контейнерами (CMS) Во многих случаях они превосходят тяжеловесные фреймворки.
Различные приложения могут использовать любые/разные ресурсы из кластера, которые лучше соответствуют их потребностям. При этом по-прежнему обеспечивают масштабирование и восстановление после сбоев (опять же, сильно полагаясь на брокера событий и CMS).
К сожалению, на данный момент есть только два полнофункциональных варианта:
Тяжеловесные фреймворки потоковой обработки — это еще одна основа/шаблон для создания микросервисов.
Эти фреймворки обладают высокой масштабируемостью и позволяют эффективно решать множество аналитических задач. Но они не всегда хороши для шаблонов приложений микрослужб с отслеживанием состояния, управляемых событиями.
Тяжеловесные фреймворки работают с использованием централизованных кластеров ресурсов, что может потребовать дополнительных операционных издержек, мониторинга и координации для успешной интеграции в среду микросервисов. Однако недавние инновации двигают эти фреймворки в сторону решений для управления контейнерами (CMS), таких как Kubernetes, которые должны сократить ваши усилия.
Базовой шаблон производителя и потребителя (BPC) — это простой шаблон для создания микросервисов. Он формирует основу сервисов без сохранения состояния и с сохранением состояния.
Вы можете использовать его для:
реализации интерфейса взаимодействия между потоками событий и устаревшими системами использования внешних систем обработки потоков для расширения возможностей Но это требует ваших дополнительных усилий для реализации:
простой материализации состояния скедулинга событий принятия решений на основе временных меток Все это раскрыто в главе 10 книги, которую мы сейчас изучаем:
Функция как сервис (FaaS) — это область облачных вычислений, которая быстро развивается.
Здесь необходимо рассмотреть следующие вопросы:
Принципы FaaS Открытый исходный код и сторонние поставщики FaaS 4 компонента, которые следует учитывать при построении микросервисов как функций Холодный пуск против теплого пуска Различные триггеры, которые могут запускать FaaS: запуск на основе новых событий, запуск на основе задержки группы потребителей, запуск по расписанию, запуск с использованием веб-перехватчиков, запуск по событиям ресурсов. Поддержание состояния Два шаблона функций, вызывающих другие функции: управляемый событиями и прямой вызов.
Существует два шаблона построения микросервисов, управляемых событиями:
Хореография (без централизованной координации) Оркестровка (с централизованной координацией) У обоих есть плюсы и минусы (однако мне кажется, что оркестровка все-таки более удобный шаблон)
Как реализовать распределенные транзакции с хореографией и оркестровкой.
Как ИЗБЕЖАТЬ реализации распределенных транзакций — подход с компенсационным рабочим процессом.
Все это раскрыто в главе 8 книги, которую мы сейчас изучаем:
“Создание событийно-управляемых микросервисов” Адама Беллемара. Оригинал: “Building Event-Driven Microservices: Leveraging Organizational Data at Scale” by Adam Bellemare
Микросервисы, управляемые событиями, должны материализовать состояния. И это связано с важными вещами для размышлений. Два подхода на выбор:
Внутреннее хранилище состояний или внешнее хранилище состояний У обоих есть плюсы и минусы. Оба имеют важные соображения о масштабируемости и восстановлении.
Два подхода к изменению структур данных:
Перестраивать и Миграции Транзакции и как их эмулировать для реализации обработки Ровно Один Раз.
Все это раскрыто в главе 7 книги, которую мы сейчас изучаем:
Детерминированная потоковая обработка — это основа для создания масштабируемых систем, управляемых событиями. Отсутствие детерминизма может быть очень болезненным для бизнеса (представьте себе потерю финансовых транзакций, пропущенные оповещения, неправильную агрегацию данных).
Существуют определенные советы и приемы реализации детерминизма. Ключевые слова здесь:
Временные метки Планирование событий Водяные знаки Время потока Вы должны понимать природу неупорядоченых и запоздалых событий. И стратегии их обработки.
Также необходимо поддерживать повторную обработку.
И нужно учитывать периодические сбои.
Основы событийно-управляемой обработки в архитектурах, управляемых событиями:
Типовая структура микросервиса Типовые типы трансформации событий, 2 сценария ветвления, слияние потоков Перепартиционирование событий и когда это может быть полезно Сопартиционирование событий и когда это необходимо Назначение партиций конкретному микросервису занимающемуся обработкой данных. Три стратегии для этого. Восстановление после сбоев микросервисов обработки данных без поддержки состояния. Эти темы раскрыты в главе 5 книги, которую мы сейчас изучаем:
“Создание событийно-управляемых микросервисов” Адама Беллемара.
Освобождение данных — это процесс перехода от монолита к микросервисам путем разделения систем с точки зрения зависимостей данных.
Существуют три паттерна для освобождения данных:
На основе запросов На основе журнала На основе таблиц У каждого паттерна есть свои плюсы и минусы, а также другие важные соображения.
Изменения определения данных (миграция структуры данных) также должны поддерживаться выбранным подходом к освобождению данных.
Существуют различные фреймворки/инструменты, которые упрощают процесс освобождения данных. Обратите внимание, что инструменты CDC не являются конечным пунктом вашей архитектуры, а всего лишь начальным шагом ваших измерений.
