Please enable JavaScript.
Coggle requires JavaScript to display documents.
Building Event Driven Microsevices - Coggle Diagram
Building Event Driven Microsevices
Why EDM
То как мы передаем информацию влияет на архитектуру
Не только message-passing systems - события в них хранятся
DDD and bounded context
sole ownership
cross-cutting ownership
Communication structures
Business communication structure
бизнес подразделения/команды
Implementation communication structure
сами подсистемы/сервисы
Data communication structure
как организованы "потоки" данных
sync microservices vs async
недостатки синхронных
coupling
плохо скалируется - если зависимость не скалируется
service failure handling - что делать если зависимость не отвечает
api versioning
доступ к внешним данным
много межсервисных rpc - распределенные монолит
тестирование
преимущества синхронных
UI проще/привычней реализовывать
интеграция с внешними системами обычно синхронная
преимущества асинхронных
гранулярность
масштабируемость
гибкость выбора технологий
business requirement flexibility
loosely coupling
continuous delivery support
high testability
EDM Fundamentals
Topology
Business Topology
Microservice topology
Что такое event
что угодно (что меняется в системе)
Unkeyed Events
Entity Event
Materialization
table-stream duality
Compaction
Tombstone (v=null)
Keyed Event
Single writer - один стрим генерирует один producer
Event broken vs message broker
Event broker
Scalability, Durability, HighAvailability...
single source of truth
Message broker
Не хранит события
Communication and
Data Contracts
Data Contracts
Explicit Schema as Contract
Schema Definintion Comments
Compatibility
Forward
Backward
Full
Code Generation
Breaking Changes
Both old and new
Re-create all entities
New event stream for nonentity events
Event Format
Json not so good
Designing Events
Minimize the size
Avoid events as semaphores or signals
Integrating ED arch with
existing systems
Data Liberation
Patterns
Query based
Bulk and Job
Customizability
Independent polling period
Isolation of internal data models
Drawbacks
Untraceable hard deletion
Untraceable harddelete
Britle dependecy between dataset and output schema
Intermittent capture
Production resource controller
variable query performance due to data changes
Log based
benefits
Минимально влияет на performance data store
low latency
Delete tracking
drawbacks
Протекает схема
Denormalization outside of the data store
Britle dependecy between dataset and output schema
CDC, binlog, WAL
Outbox table based
Outbox
benefits
drawbacks
Capturing Change-Data using tirggers
drawbacks
performance overhead
Change management complexity
poor scaling
after the fact schema enfircement
benefits
low overhead for small data sets
supported by most databases
customizable logic
DDL changes to datasets under capture
источник проблем
To events broker first,
materialize secondly
Event-driven processing basics
event-driven microservice
Consume event
Process new event
Produce any necessary events
Composing stateless topologies
filter
map
mapValue
custom transform
repartitioning
copartitioning
Детерминированный процессинг
Вопросы
Как обрабатывать события из раличных партиций
как обрабатывать неупорядоченные и поздние события
как убедиться, что у нас детер=минированная обработка near real time vs последовательной обработки
timestamps
Event time
broker ingestion time
consumer ingestion time
processing time
NTP
few ms
для обычных бизнес приложений может и хватить
Watermarks
Stream time
Наиболее позднее время обработанного события
Out of order
Причины
Нарушен порядок входного потока
репартиционирование
Windowing
Tumbling
Sliding
Session
Handling late events
Drop
Wait
Grace period
Публикуются обновления
Stateful streaming
Materialized state
State store
Internal state
Собственное хранилище для каждого нода
Глобальное - храним данные всех партиций
Partition state store
+
Scalability requirements are offloaded from the developer
high perfomance disk based options
can use network-attached disk
-
limited to using runtime-defined disk
wated disk space
Scaling and recovery
Hot replicas
Changelogs
from event stream
Нужно предусмотреть то что будут генерироваться дублирующие выходные события
External state
+
Доступны данные других партиций (на чтение)
Можно использовать удобные организации технологии
-
MANAGEMENT OF MULTIPLE TECHNOLOGIES
PERFORMANCE LOSS DUE TO NETWORK LATENCY
FINANCIAL COST OF EXTERNAL STATE STORE SERVICES
FULL DATA LOCALITY
race conditions, non deterministic behaviour
Scaling and recovering
source streams
changelogs
Предпочитаются реплики хранилища, а не брокера
snapshots
Transactions and Effectively Once Processing
Если транзакции не поддерживаются брокером, то могут генерироваться дублированные события
Определение дубликатов
Id зависит от данных
Прикапываем все Id обработанных + можем использовать окно
Building workflows with microservices
Choreography
поменять порядок обработки сложно
Мониторинг зависит от структуры цепочки
Orchestration
Сервис который имплементирует workflow (при этом делегирует части другим сервисам)
Легче менять порядок wokflow
Мониторинг = materialized state оркестратора
Direct call vs Event Driven orchestration
Распределенные транзакции
choreography
При откате нужно слушать output stream + failed transaction stream от первого в цепочке
orchestrated transactions
compensation workflows
Microservices Using Function-as-a-Service
есть триггеры
легко скейлится
Как дизайнить
должны быть в баундед контексте
На один bounded context - 1 репозиторий
Коммитить оффсет после окончания обработки (рекомендуется)/или после старта функции и получения батча событий
Не реюзайте функции в разных контекстах
построение микросервисов из функций
Компоненты function-based решений
Функция
input event stream
triggring logic
based on new events
batch size/batch window
синхронные/асинхронные
consumer lag
schedule
webhooks
recource events
error and scaling policies