Distributed Systems: Communication and Transactions

Розподілені системи: комунікація та транзакційність без хаосу

Розподілені системи обіцяють масштабування та гнучкість, але разом із цим приносять чимало сюрпризів: від збоїв у комунікації до втрати узгодженості даних.
Чому класичні транзакції не працюють у такій архітектурі і що з цим робити?
На цій доповіді розберемося, як тримати систему під контролем і як уникнути хаосу при побудові розподілених архітектур.

Transcript

1. Розподілені системи КОМУНІКАЦІЯ ТА ТРАНЗАКЦІЙНІСТЬ БЕЗ ХАОСУ Інна Мосьпан
2. Всім привіт! PHP BACKEND DEVELOPER AT NEWFOLD DIGITAL Інна Мосьпан
3. Розподілені системи
4. Контракти між сервісами та їх комунікація Транзакційність в розподілених системах Saga-патерн: види, переваги та недоліки Зміст 4 Висновки 3 2 1
5. Погляд в минуле Проєкти не дуже складні Зазвичай це монолітна архітектура Бум MVC фреймворків
6. Розробник - може все Більшість розробників - full stack Розробник відповідає за всю технічну частину Команди не великі
8. Прийшов час думати про архітектуру Проєкти стають складніші Працювати з тим що є - все складніше, займає більше часу В вакансіях частіше можна побачити frontend та backend розробників, як окремі позиції Команди ростуть Активно зʼявляються позиції архітекторів
10. Що змінилось?
11. Комунікація
12. Контракти між сервісами REST gRPC Простіша логіка та дебаг Tight coupling: якщо один сервіс повільний або падає, це впливає на весь ланцюжок Event-Driven rabbitMQ, Redis, MQTT, Kafka і тд слабке зчеплення, краща масштабованість та відмовостійкість складніша логіка, eventual consistency, важче тестувати і дебажити
13. HTTP RESTful APIs Stateless Uniform Interface Cacheable Client-Server Layered System *Code on Demand (Optional)
14. Customer Setup Flow
15. Customer Setup Flow
16. Наслідки неузгодженості даних: Ненадійність інформації: Дані можуть бути невірними, що впливає на якість прийняття рішень. Зниження ефективності: Неточні дані знижують ефективність та продуктивність. Підвищення витрат: Виправлення помилок та пошук правильної інформації вимагають додаткових витрат. Підрив довіри: Неузгоджені дані можуть пошкодити репутацію та знизити довіру.
17. Monolitic Application
18. But in a microservices setup?
20. Кожен крок - окрема транзакція 1 SAGA
21. Кожен крок - окрема транзакція 1 Успіх - нова подія для наступного кроку 2 SAGA
22. Кожен крок - окрема транзакція 1 Успіх - нова подія для наступного кроку 2 Інакше - запускається компенсуюча транзакція 3 SAGA
23. Види SAGA VS Choreography Orchestration Кожен сервіс після закінчення своєї транзакції - публікує подію. Інші сервіси підписуються на ці події і реагують. Є центральний оркестратор, який координує кроки, відправляє запити сервісам і отримує відповіді з яких вирішує викликати наступний крок, чи запустити компенсуючі дії.
24. SAGA Choreography - Плюси Децентралізоване управління
25. SAGA Choreography - Плюси Децентралізоване управління Простота для малих систем
26. SAGA Choreography - Плюси Децентралізоване управління Висока масштабованість і надійність Простота для малих систем
27. SAGA Choreography - Плюси Природно підходить для event-driven архітектур Децентралізоване управління Висока масштабованість і надійність Простота для малих систем
28. SAGA Choreography - Мінуси Необхідність чіткого планування подій
29. SAGA Choreography - Мінуси Необхідність чіткого планування подій Ускладнення при зростанні системи
30. SAGA Choreography - Мінуси Необхідність чіткого планування подій Важко відслідковувати транзакції Ускладнення при зростанні системи
31. SAGA Choreography - Мінуси Всі знають про всіх Необхідність чіткого планування подій Важко відслідковувати транзакції Ускладнення при зростанні системи
32. SAGA Orchestration - Плюси Централізоване управління
33. SAGA Orchestration - Плюси Централізоване управління Простота керування складними процесами
34. SAGA Orchestration - Плюси Централізоване управління Простота керування складними процесами Прозорість
35. SAGA Orchestration - Мінуси Єдина точка відмови
36. SAGA Orchestration - Мінуси Єдина точка відмови Складність оркестратора
37. SAGA Orchestration - Мінуси Єдина точка відмови Складність оркестратора Менша гнучкість
38. Якщо обираєте SAGA Pattern 2 3 4 Logs & Metrics Distributed tracing SAGA UI 1 Idempotency
39. Якщо обираєте SAGA Pattern 2 3 4 Logs & Metrics Distributed tracing SAGA UI 1 Idempotency
40. Якщо обираєте SAGA Pattern 2 3 4 Logs & Metrics Distributed tracing SAGA UI 1 Idempotency
41. Якщо обираєте SAGA Pattern 2 3 4 Logs & Metrics Distributed tracing SAGA UI 1 Idempotency
42. Temporal
43. Висновки Масштабованість додає складності Обирайте тип комунікації свідомо Для складних процесів - Saga Спостережуваність - необхідна умова для стабільності 4 2 3 1
44. The Many Meanings of Event-Driven Architecture • Martin Fowler Event-Driven Architecture: магія чи хаос під капотом? microservices.io Мій LinkedIn Залишаймось на звʼязку Корисні посилання Презентація