SlideShare a Scribd company logo
Microservices interaction at scale
using Apache Kafka
• Software engineer at Upwork
• 3500 logged hours
• ivanursul.com
2
Agenda
1.Monolith to Microservices
2.Communication patterns
3.Apache Kafka
4.Kafka in details
3
Anti - Agenda
1.Pros/cons of microservices
architecture
2.How to build microservices right
4
Monolith to Microservices
Module 1 Module 2 Module 3 Module 4 Module 5
Database layer
Network layer DTO
Business
Model
ER
Model
5
Reality
6
7
Microservices goals
8
Scaling in terms of people
4 engineers 2 engineers 1 engineer
9
Scaling in terms of data
10
Service independence
11
Microservices
communication
12
Shared database
13
14
Database per service pattern
15
Service interfaces
16
Services equality
Microservice 1 Microservice 2
2000 rps
KO
2000 rps
200
rps
17
External request
Critical path
18
Consistency
19
Asynchronous messaging
20
Two types of data
Data-on-the-
outside
for your
storage
Data-on-the-
inside
for other services
21
“Pluggable” architecture
22
23
What is Apache Kafka ?
1.Distributed publish-subscribe
messaging system
2.Fast, Scalable, Durable
3.Created at LinkedIn, is now an Apache
project
4.confluent.io 24
time
Commit Log
msg
1
msg
4
msg
7
msg
10
msg
13P0
P1
P2
2x
2x
2x
Distributed Commit Log
Distributed, Replicated
Commit Log
msg
2
msg
5
msg
8
msg
11
msg
14
msg
3
msg
6
msg
9
msg
12
msg
15
25
Apache
Zookeper
Broker
Broke
r
Broke
r
Produc
er
Consum
er
Kafka Streams
Connec
t
Conne
ct
Send messagesRead messages
Zookeper for configuration
Adapter for
third-party
sources
At least one Broker/Node
Consume, process
and produce messages
Apache Kafka architecture
Kafka Cluster
26
Kafka usage patterns
1.Event Sourcing
2.Change Data Capture
3.Kafka Connect
27
Event Sourcing
28
Microservice 1 Microservice 2
Apache
Kafka
29
Write Request Read Request
Kafka Producer
Microservice 1
Command Query Responsibility
Segregation
UI
Write Model Read Model
Write DB Read DB
Event
s
Service structure
Microservice group
Write
Service
Event
Handler
Read
Service
2 instances 2 instances 3 instances
Benefits
32
1.Separate read and writes
2.Data can be replayed
3.Debugging
32
Drawbac
ks
1.Higher learning curve
2.Backward compatibility support
3333
Change Data Capture
3434
3535
Database
Cache
Search engine
Request
update/invalidat
e
Database
Request
insert
updat
e
delete insert
updat
e
Cache Search Index
WAL
3636
37
Bottled water
Apache
Kafka
Microservice infrastructureLegacy monolith
extract changes
38
Apache
Kafka
extract changes
39
Benefits
40
1.Useful for legacy databases
2.Eliminate dual writes
Drawbac
ks
1.Not every DB has support for CDC
2.Database upgrade
41
Kafka Connect
42
Apache
KafkaKafka
Connect
43
Benefits
44
1.Useful for legacy Databases
2.Eliminate dual writes
3.Supported by all storages
4.Custom connectors
Drawbac
ks
1.Additional queries
2.Indicator fields
45
Demo
Key
Roles:
Order
Service
Customer
Service
Frameworks
46
Kaf
ka
Customer
Service
Order
Service
New Order
5 order.payment.processed
4 order.processed
event handler
1 order.created
2 order.created
event handler
47
Apache Kafka in details
48
Anatomy of topic
Kafka
Topic
P0
P1
P2
msg 0
Topic is
divided
into
multiple
partitions
(P0, P1,
P2)
Each message
has an identifier
called offset
Producer
s write
message
s to the
end of
partitionPartition is a
unit of
parallelism
Consumers
can read from
any offset
Message
can have
key:value
msg 3
msg 1 msg 4 msg 7 msg 8
msg 2 msg 5
msg 6
49
Producers
• Publish to topics
• Round-robin
• Murmur 2
• Retry, Batching
• Async
• Broker list
50
Kafka Broker
0 1 2 3 4 5 6 7
0 1 2 3
0 1 2 3 4 5
0 1 2 3 4 5 6 7
0 1 2 3
P
0
P
1
P
2
0 1 2 3 4 5 6 7
0 1 2 3
0 1 2 3 4 5 0 1 2 3 4 5
Leader
partition
Replica
Each partition has
exactly one
leader
0 1 2 3 4 5 0 1 2 3 4 5
And >= 0 replicas.
They’re called In-
Sync Replicas
All read and
writes are made
using leader
partitionBroker 1 Broker 2 Broker 3
0 1 2 3 4 50 1 2 3 4 5
0 1 2 3 4 5 6 7
0 1 2 3
P
0
P
1
P
2
P
0
P
1
P
2
51
Consumers
• Multiple consumers
• List of partitions
• Offset management
• Offset backup to consumer_offsets
52
Consumer Groups
P0 P1 P2
Instance 1 Instance 1 Instance 2 Instance 1Instance 2Instance 3Instance 4
consumer group 1 consumer group 2 consumer group 3
Kafka
Cluster
53
Historical rewind
P0
Current Offset
Instance 1
Instance 1
Service 1
ms
g 1
msg
2
msg
3
msg
4
msg
5
54
Retention period
P0
P1
P2
msg
12
msg
15
msg
11
msg
14
msg
10
msg
13
msg
1
msg
4
msg
7
msg
2
msg
5
msg
8
msg
3
msg
6
msg
9
55
Log compaction
key 1 ->
value
key 2 ->
value
key 1 -> new value
56
Guarantees
• Messages are appended in the order
they send
• Ordering is guaranteed within partition
• Consumer reads a messages in the
order they are stored
• N - 1 Broker failures57
Delivery semantics
• at least once - by default
• at most once - configurable
• exactly once - Kafka Transactions, June
2017
58
Worst scenario
Unclean Leader Election
0 1 2 3 4 5 6 7
0 1 2 3
P
0
P
1
P
2
0 1 2 3 4 5
0 1 2 3 4 5 6 7
0 1 2 3
P
0
P
1
P
2
0 1 2 3 4 5 6 7
0 1 2 3
P
1
P
2
0 1 2 3 4 5
P
0
0 1 2 3 4 5
Leader
partition
Replica
Broker
1
Broker
2
Broker
3
0 1 2 3 4 5
0 1 2 3 4 5 6 7
0 1 2 3
0 1 2 3 4 5 6 7
0 1 2 3 4 5
0 1 2 3 4 5 6 7
0 1 2 30 1 2 3
Sync
0 1 2 3 4 5
0 1 2 3 4 5 6 7
0 1 2 3
Choose one of
the
unsynchronized
followers
Wait for Broker 1
to recover
59
Service Deployment
• No significant problems in producer side
• Consumers may have issues with blue-
green deployment
• Remember to reserve additional
partitions for blue and green stacks
60
Monitoring
• Broker, Producer and Consumer has
JMX support out of the box
• Additional option is to write custom
reporters
61
Kafka Streams
62
Apache Kafka
63
• Useful for large services
• Fault tolerant
• Consume, process and produce
messages
• Aggregations
• Stateful processing
• Distributed joins 64
Why Kafka ?
• Kafka doesn’t acknowledge messages
• Easy to use
• Configurable
• Super fast for reading tail messages
Summary
• Build an event driven backbone
• Add Service interfaces where needed
• Don’t forget about CDC and Kafka
Connect
66
www.slideshare.net/KennyBastani/in-the-eventual-consistency-of-succeeding-at-microservi
Do what makes sense
But don’t build microservices without events
Demo, Slides
ivanursul.com/microservices-interaction-apache-kafka
68
QA
69

More Related Content

What's hot (20)

PDF
Voldemort : Prototype to Production
Vinoth Chandar
 
PPT
MYSQL
gilashikwa
 
PDF
The Hows and Whys of a Distributed SQL Database - Strange Loop 2017
Alex Robinson
 
PDF
Robust ha solutions with proxysql
Marco Tusa
 
PPTX
The Missing Manual for Leveled Compaction Strategy (Wei Deng & Ryan Svihla, D...
DataStax
 
PDF
Scylla Summit 2016: Outbrain Case Study - Lowering Latency While Doing 20X IO...
ScyllaDB
 
PDF
Voldemort Nosql
elliando dias
 
PDF
Why stop the world when you can change it? Design and implementation of Incre...
confluent
 
PPTX
RedisConf18 - Redis as a time-series DB
Redis Labs
 
PDF
Ramp-Tutorial for MYSQL Cluster - Scaling with Continuous Availability
Pythian
 
PDF
Distribute Key Value Store
Santal Li
 
PDF
CockroachDB: Architecture of a Geo-Distributed SQL Database
C4Media
 
PDF
Running a distributed system across kubernetes clusters - Kubecon North Ameri...
Alex Robinson
 
PDF
Breda Development Meetup 2016-06-08 - High Availability
Bas Peters
 
PDF
Jay Kreps on Project Voldemort Scaling Simple Storage At LinkedIn
LinkedIn
 
PDF
HDFS Selective Wire Encryption
Konstantin V. Shvachko
 
PDF
Best practice-high availability-solution-geo-distributed-final
Marco Tusa
 
PDF
Scaling with sync_replication using Galera and EC2
Marco Tusa
 
PDF
Kafka Needs no Keeper( Jason Gustafson & Colin McCabe, Confluent) Kafka Summi...
confluent
 
PDF
MariaDB MaxScale
MariaDB plc
 
Voldemort : Prototype to Production
Vinoth Chandar
 
MYSQL
gilashikwa
 
The Hows and Whys of a Distributed SQL Database - Strange Loop 2017
Alex Robinson
 
Robust ha solutions with proxysql
Marco Tusa
 
The Missing Manual for Leveled Compaction Strategy (Wei Deng & Ryan Svihla, D...
DataStax
 
Scylla Summit 2016: Outbrain Case Study - Lowering Latency While Doing 20X IO...
ScyllaDB
 
Voldemort Nosql
elliando dias
 
Why stop the world when you can change it? Design and implementation of Incre...
confluent
 
RedisConf18 - Redis as a time-series DB
Redis Labs
 
Ramp-Tutorial for MYSQL Cluster - Scaling with Continuous Availability
Pythian
 
Distribute Key Value Store
Santal Li
 
CockroachDB: Architecture of a Geo-Distributed SQL Database
C4Media
 
Running a distributed system across kubernetes clusters - Kubecon North Ameri...
Alex Robinson
 
Breda Development Meetup 2016-06-08 - High Availability
Bas Peters
 
Jay Kreps on Project Voldemort Scaling Simple Storage At LinkedIn
LinkedIn
 
HDFS Selective Wire Encryption
Konstantin V. Shvachko
 
Best practice-high availability-solution-geo-distributed-final
Marco Tusa
 
Scaling with sync_replication using Galera and EC2
Marco Tusa
 
Kafka Needs no Keeper( Jason Gustafson & Colin McCabe, Confluent) Kafka Summi...
confluent
 
MariaDB MaxScale
MariaDB plc
 

Similar to Microservices interaction at scale using Apache Kafka (20)

PPTX
Getting Started with Kafka on k8s
VMware Tanzu
 
PPTX
Monitoring Apache Kafka
confluent
 
PDF
Apache Kafka - Event Sourcing, Monitoring, Librdkafka, Scaling & Partitioning
Guido Schmutz
 
PDF
SFBigAnalytics_20190724: Monitor kafka like a Pro
Chester Chen
 
PDF
Scaling big with Apache Kafka
Nikolay Stoitsev
 
PDF
Strimzi - Where Apache Kafka meets OpenShift - OpenShift Spain MeetUp
José Román Martín Gil
 
PPSX
Event Sourcing & CQRS, Kafka, Rabbit MQ
Araf Karsh Hamid
 
PPTX
Play With Streams
Tianjian Chen
 
PDF
Citi Tech Talk: Monitoring and Performance
confluent
 
PDF
A Deep Dive into Kafka Controller
confluent
 
PDF
BigDataSpain 2016: Introduction to Apache Apex
Thomas Weise
 
PDF
Learnings from the Field. Lessons from Working with Dozens of Small & Large D...
HostedbyConfluent
 
PDF
Introduction to Apache Kafka
Shiao-An Yuan
 
PPTX
Kafka at scale facebook israel
Gwen (Chen) Shapira
 
PPTX
Top Ten Kafka® Configs
confluent
 
PDF
Introduction to Apache Kafka
Ricardo Bravo
 
PPTX
How Criteo is managing one of the largest Kafka Infrastructure in Europe
Ricardo Paiva
 
PPTX
Intro to Apache Apex (next gen Hadoop) & comparison to Spark Streaming
Apache Apex
 
PDF
Concepts and Patterns for Streaming Services with Kafka
QAware GmbH
 
PDF
Cruise Control: Effortless management of Kafka clusters
Prateek Maheshwari
 
Getting Started with Kafka on k8s
VMware Tanzu
 
Monitoring Apache Kafka
confluent
 
Apache Kafka - Event Sourcing, Monitoring, Librdkafka, Scaling & Partitioning
Guido Schmutz
 
SFBigAnalytics_20190724: Monitor kafka like a Pro
Chester Chen
 
Scaling big with Apache Kafka
Nikolay Stoitsev
 
Strimzi - Where Apache Kafka meets OpenShift - OpenShift Spain MeetUp
José Román Martín Gil
 
Event Sourcing & CQRS, Kafka, Rabbit MQ
Araf Karsh Hamid
 
Play With Streams
Tianjian Chen
 
Citi Tech Talk: Monitoring and Performance
confluent
 
A Deep Dive into Kafka Controller
confluent
 
BigDataSpain 2016: Introduction to Apache Apex
Thomas Weise
 
Learnings from the Field. Lessons from Working with Dozens of Small & Large D...
HostedbyConfluent
 
Introduction to Apache Kafka
Shiao-An Yuan
 
Kafka at scale facebook israel
Gwen (Chen) Shapira
 
Top Ten Kafka® Configs
confluent
 
Introduction to Apache Kafka
Ricardo Bravo
 
How Criteo is managing one of the largest Kafka Infrastructure in Europe
Ricardo Paiva
 
Intro to Apache Apex (next gen Hadoop) & comparison to Spark Streaming
Apache Apex
 
Concepts and Patterns for Streaming Services with Kafka
QAware GmbH
 
Cruise Control: Effortless management of Kafka clusters
Prateek Maheshwari
 
Ad

Recently uploaded (20)

PDF
Letasoft Sound Booster 1.12.0.538 Crack Download+ Product Key [Latest]
HyperPc soft
 
PDF
Revenue streams of the Wazirx clone script.pdf
aaronjeffray
 
PDF
Thread In Android-Mastering Concurrency for Responsive Apps.pdf
Nabin Dhakal
 
PPTX
MiniTool Power Data Recovery Full Crack Latest 2025
muhammadgurbazkhan
 
PDF
Executive Business Intelligence Dashboards
vandeslie24
 
PPTX
3uTools Full Crack Free Version Download [Latest] 2025
muhammadgurbazkhan
 
PPTX
Tally software_Introduction_Presentation
AditiBansal54083
 
PDF
Why Businesses Are Switching to Open Source Alternatives to Crystal Reports.pdf
Varsha Nayak
 
PDF
Beyond Binaries: Understanding Diversity and Allyship in a Global Workplace -...
Imma Valls Bernaus
 
PPTX
Tally_Basic_Operations_Presentation.pptx
AditiBansal54083
 
PDF
Unlock Efficiency with Insurance Policy Administration Systems
Insurance Tech Services
 
PDF
Efficient, Automated Claims Processing Software for Insurers
Insurance Tech Services
 
PPTX
Feb 2021 Cohesity first pitch presentation.pptx
enginsayin1
 
PDF
Alarm in Android-Scheduling Timed Tasks Using AlarmManager in Android.pdf
Nabin Dhakal
 
PPTX
The Role of a PHP Development Company in Modern Web Development
SEO Company for School in Delhi NCR
 
PDF
GridView,Recycler view, API, SQLITE& NetworkRequest.pdf
Nabin Dhakal
 
PDF
Alexander Marshalov - How to use AI Assistants with your Monitoring system Q2...
VictoriaMetrics
 
PPTX
Human Resources Information System (HRIS)
Amity University, Patna
 
PDF
Salesforce CRM Services.VALiNTRY360
VALiNTRY360
 
PPTX
Revolutionizing Code Modernization with AI
KrzysztofKkol1
 
Letasoft Sound Booster 1.12.0.538 Crack Download+ Product Key [Latest]
HyperPc soft
 
Revenue streams of the Wazirx clone script.pdf
aaronjeffray
 
Thread In Android-Mastering Concurrency for Responsive Apps.pdf
Nabin Dhakal
 
MiniTool Power Data Recovery Full Crack Latest 2025
muhammadgurbazkhan
 
Executive Business Intelligence Dashboards
vandeslie24
 
3uTools Full Crack Free Version Download [Latest] 2025
muhammadgurbazkhan
 
Tally software_Introduction_Presentation
AditiBansal54083
 
Why Businesses Are Switching to Open Source Alternatives to Crystal Reports.pdf
Varsha Nayak
 
Beyond Binaries: Understanding Diversity and Allyship in a Global Workplace -...
Imma Valls Bernaus
 
Tally_Basic_Operations_Presentation.pptx
AditiBansal54083
 
Unlock Efficiency with Insurance Policy Administration Systems
Insurance Tech Services
 
Efficient, Automated Claims Processing Software for Insurers
Insurance Tech Services
 
Feb 2021 Cohesity first pitch presentation.pptx
enginsayin1
 
Alarm in Android-Scheduling Timed Tasks Using AlarmManager in Android.pdf
Nabin Dhakal
 
The Role of a PHP Development Company in Modern Web Development
SEO Company for School in Delhi NCR
 
GridView,Recycler view, API, SQLITE& NetworkRequest.pdf
Nabin Dhakal
 
Alexander Marshalov - How to use AI Assistants with your Monitoring system Q2...
VictoriaMetrics
 
Human Resources Information System (HRIS)
Amity University, Patna
 
Salesforce CRM Services.VALiNTRY360
VALiNTRY360
 
Revolutionizing Code Modernization with AI
KrzysztofKkol1
 
Ad

Microservices interaction at scale using Apache Kafka

Editor's Notes

  • #3: майже 2 роки на апворку на апворку можна заробляти, навіть якщо ваш замовник - сам апворк деколи пишу статті, на своєму сайті, заходьте, підписуйтесь
  • #6: Почнемо з ревью … Ідея зрозуміла, ви маєте систему, яка працює в межах одного процесу… Така система з часом виростає … І однією з форм еволюції такої системи є перехід на мікросервісну … В теорії, ви берете вашу монолітну однопроцесну систему, і розбиваєте її на багато - багато сервісів. В вас буде окрема команда В вас буде окремий деплоймент Це все - чиста теорія.
  • #7: Реальність виглядає ось так. По-перше, переважно, такі мікросервіси - динамічні, з постійно змінюваною адресою в інтернеті. Якщо вони не динамічні, тоді це не ті мікросервіси, які я знаю. По друге, таких сервісів багато, всі вони різні, по різному працюють, і мають різні дані. І останнє, це різні команди, різні підходи, різні думки. Це вносить корективи загалом.
  • #8: Щоб ще більше розвіяти картину, пропоную подивитись скільки їх може бути. Амазон і Нетфлікс, компанії - гіганти, які одні з перших впровадили мікросервісну архітектуру. Подивіться скільки в них сервісів.
  • #9: Які ж цілі потрібно ставити в мікросервісній архітектурі ?
  • #10: Перш за все, це скейлінг в термінах інженерів і спеціалістів. Як я вже казав, в вас будуть великі і маленькі сервіси, так от для великих …
  • #11: Також, скейлінг в межах даних. Якщо ваша організація переходить чи будує мікросервісну архітектуру, то даних в вас буде ну дуже багато. І дані ці будуть різні. І так як на сьогоднішній день ми маємо багато різних стореджів, ми можемо вибирати. Для графових даних нам… Якщо маєте пошукову логіку - Якщо в вас не стабільна схема, не підходить реляційна структура, то …
  • #12: І напевно, найголовніше, ви хочете бути незалежними. Незалежними від інших сервісів. Згадайте ту картинку з амазоном і нетфліксом і подумайте скільки людей працює там. В мікросервісах, такій команді потрібна незалежність, можливість працювати і не вклинюватись в інші команди. Така команда буде мати окремі мітинги, окремий пленінг, окремий кодбекс, деплоймент.
  • #13: Але компанії, так чи інакше, це колекції аплікацій, модулів, підсистем, які повинні працювати разом в якійсь степені, щоб досягти одного спільного результату. Іншими словами, їм потрібно комунікувати. Працюючи в моноліті, ви над цим не задумувались, оскільки це була одна аплікація. Так само і тут, маючи незалежні, окремі сервіси, які бігають по мережі, мають різні бази даних і пишуться окремими командами, їм теж потрібно комунікувати. Які існують патерни комунікації ?
  • #14: Перший і найгірший патерн - патерн шареної бази даних. Ідея полягає в тому, що всі, чи декілька сервісів використовують одну базу даних. Такий патерн можна ще назвати розподіленим монолітом, оскільки в довгостроковій перспективі ви нічого не вирішуєте. Все лишається те ж, що і в моноліті, тільки сервіси тепер бігають по мережі.
  • #15: Я довго думав як зобразити цей патерн, і знайшов цей твіт, який класно описує весь сюр, який трапляється при такому підході. Всі команди завязані на одну базу, комунікують теж через неї. При рості навантаження росте і база. З часом виростає в дуже велику. А чи всім сервісам потрібна така база ?
  • #16: Загальне правило - мати одну базу на один сервіс. Ситуація може мінятись від сервісу до сервісу, але ідея зрозуміла - чим більше команд працюють в одній базі даних, тим складніше її підтримувати і тим вона стає більша. Саме тому найкраще одній команді для одного сервісу мати одну базу даних.
  • #17: Ок, якщо не шарена база, то що ? Ми живемо в світі API і ендпоінтів. Їх потрібно написати, версіонувати, підтримувати. Це потрібно сусідньому сервісу, не вам. Створює real time coupling
  • #18: Не треба забувати, що сервіси не рівні між собою. І якщо більший сервіс викликає меншого - менший може просто завалитись.
  • #19: Інша річ, що не всі сервіси мають бути частиною критичного шляху, який повинен пройти ріквест перед тим, як віддати відповідь. Просто тому, що вам не потрібно робити все зразу. Створюючи якусь покупку і відправляючи запит в OrderService, ви напевно не захочете в ту ж хвилину відправляти запит в Shipping Service, щоб оформити трекінг код. Просто тому, що ваш домен так не працює. І Це створює додаткове лейтенсі, що негативно скажеться на продукті, який ви розробляєте.
  • #20: І навіть, якщо б вам потрібно було виконати все і зразу, за допомогою апішок чи ендпоінтів, ви б не зробили достатньо якісно. Якщо під час виконання цього шляху щось завалиться, а щось вже виконається, що тоді ? Двох фазний коміт CAP теорема
  • #21: І коли ми говорили про те, що комунікація за допомогою сервісних інтерфейсів звязує сервіси докупи, то пофіксити це можна за допомогою третьої сторони: замість того, щоб відправляти повідомлення між сервісами напряму, ми це зробимо за допомогою якогось меседж брокера, який, в доповненні до всього, це ж саме повідомлення може відправити і іншим сервісам, якщо їм це буде потрібно.
  • #22: Таким чином, виходить, що в нас буде два типи даних - дані, які ми будемо тримати в конкретному сервісі для того, щоб видавати цю інформацію в зовнішній світ, і дані, які будуть бігати через меседж брокер, і які будь який сервіс зможе прочитати.
  • #23: Такий підхід до комунікації створює більшу координацію і дозволяє новим сервісам створюватись і заходити на платформу без ніяких проблем.
  • #24: І кафка якраз є той меседж брокер, який буде відправляти зберігати ці повідомлення і відправляти їх всім охочим. За останні роки дала про себе знати, сьогодні Кафка - це технологія, яка дозволить принести комунікацію між вашими сервісами на новий рівень.
  • #28: Окей, а як реально можна застосувати Кафку в мікросервісній архітектурі ? Я виділив три приклади, при яких Кафка може бути дуже корисна
  • #29: Перше, Івент Сорсінг. Архітектурний підхід, який говорить нам, що стан системи визначається послідним ланцюжком подій. Таким чином, кожна зміна даних логується і зберігається.
  • #30: Візьмемо приклад. В нас є ріквест, який модифікує дані в одному сервісі, і ріквест, який читає якусь інформацію, в іншому сервісі. Як другому сервісі отримати інформацію з першого сервісу ? Можливо, комусь стало цікаво - а як же перший мікросервіс зберігає інформацію. Одна з хороших якостей івент сорсінгу полягає в тому, що мікросервіс 1 зберігає інформацію за таким ж принципом.
  • #31: І коли говорять про івент сорсінг системи, не можна не згадати такий патерн, як CQRS. Цей патерн часто використовують в звязці з event sourcing системами. Ідея в тому, що в вас є дві різні моделі для запису і для читання даних. Є багато різних думок з приводу цього підходу, є багато різних думок з приводу нього, і єдине, чому я згадав цей патерн - це тому, що він може нам дати відповідь на питання як організувати структуру таких сервісів.
  • #32: Перш за все, сервіс, який буде приймати write запити За ним слідує сервіс, який буде буде виступати в ролі івент хендлера і третій - інстанс, який буде читати дані з рід бази.
  • #33: Вьюшки і Сторед процедури
  • #34: Event sourcing не для всіх.
  • #35: Хто чув про цей підхід ???
  • #36: Почнемо з прикладу. В нас є якийсь сервіс, який повинен записати інформацію в базу, апдейтнути кеш, і зробити реіндекс в серш. І традиційно, ми послідовно записуємо інформацію спочатку в базу, потім в кеш, потім в серч інжин. Хто бачить в цьому якусь проблему ? Проблема в тому, що три сорси даних не можливо постійно апдейтити так, щоб не мати частковий фейлурів
  • #37: І коли ми говоримо про CDC, то нам потрібно і далі писати в базу, але не писати в Cache і Search Index. На сьогоднішній день, практично всі бази, які в більшій чи меншій мірі активно юзаються, мають можливість читати так званий Write Ahead Log змін, які відбуваються в базі. В Постгресі це можливо за допомогою Logical Decoding фічі, в MySQL є BinLog, в Oracle Golden Gate і навітьв в монго це можна зробити за допомогою OpLog-а. І зприходом хороших якісних меседжінг систем це стало особливо актуально, оскільки це дозволяє писати в базу, і з бази паралельно записувати в меседжінг систему.
  • #39: В Вас Напевно буде стара логіка Замість того, щоб читати з бази, краще стрімити ці зміни.
  • #42: Event sourcing не для всіх.
  • #46: Event sourcing не для всіх.
  • #54: В Кафці є можливість розміщувати консюмери в межах консюмер групи. В такій консюмер групі, один партишин буде читати один і тільки один консюмер. Приклад Ця ідея consumer груп класно мапиться на мікросервіси
  • #55: Оскільки консюмери можуть самі вибирати, з якого порядку місця читати повідомлення,
  • #56: Паттерн Checkpoint. В Кафці все відбувається по інакшому, так як повідомленя постійно стираються
  • #57: Кейси з мікросервісів, коли це корисно Так як лог нікуди не дівається, ми можемо використовувати як source of truth
  • #58: at least once retries at most once
  • #59: at least once retries at most once
  • #70: Висновок звідси http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data/