Координація сервісів і керування станом

Розроблення застосунків на AWS

Ricardo Sueiras

Principal Technologist

Координація сервісів

 

• Кілька сервісів мають узгоджено виконати робочий процес.
• Потрібна стратегія координації.
• Два підходи: оркестрація і хореографія.

Оркестрація

 

• Центральний оркестратор координує робочий процес.
• Оркестратор керує послідовністю і вирішує, який сервіс запускати далі.
• Корисно для повторних спроб, умовної логіки та обробки помилок.
• В AWS: реалізується Step Functions разом із Lambda, ECS, DynamoDB.

Оркестрація

 

• Логіка робочого процесу в одному місці — простіше налагоджувати й моніторити.
• Компроміс: зʼявляється центральна залежність.

Хореографія

• Немає центрального контролера.
• Сервіси незалежно реагують на події.
• Кожен сервіс слухає потрібні події і виконує свою роботу.
• Жоден сервіс не знає весь робочий процес.
• Краще розвʼязування залежностей і масштабованість.

 

Хореографія

• В AWS: EventBridge, SNS, SQS.
• Висока масштабованість.
• Компроміс: зі зростанням процесів важче розуміти й налагоджувати.

 

Архітектура на основі подій

• Сервіси обмінюються подіями: публікують і споживають.
• Сприяє слабкому звʼязуванню між сервісами.
• Підвищує масштабованість.
• Дозволяє паралельну обробку подій.
• Нові сервіси можуть підписуватися без змін наявних.

 

Архітектура на основі подій

 

• Компроміси при впровадженні EDA:
• Проєктуйте з урахуванням зрештою узгодженості.
• Реалізуйте ідемпотентність.
• Обробка відмов складніша.

Ідемпотентність

 

• Багаторазовий запуск однієї операції дає той самий результат.
• Критичний принцип проєктування в асинхронних і подієвих системах.
• Розподілені системи можуть доставляти дублікати подій (ретраї, збої мережі, повторна обробка).
• Забезпечує коректність і надійність системи.

Черги «мертвих» листів (DLQ)

 

• Керує збоями в асинхронній взаємодії.
• Ізолює проблемні «отруйні» повідомлення.
• Після неодноразових невдалих ретраїв повідомлення переходить у DLQ.
• Основний потік обробки продовжує працювати.

Черги «мертвих» листів (DLQ)

• Використовуйте, коли порядок повідомлень не критичний.
• Пропускайте для некритичних систем, де припустима епізодична втрата даних.
• Уникайте, коли потрібно зберегти порядок повідомлень.

 

Керування станом

• Керування станом — основа cloud-native застосунків.
• Стан — це дані, збережені між взаємодіями.
• Локальне зберігання стану на сервері обмежує масштабованість і стійкість.

 

Керування станом

• Компроміси менеджменту стану залежать від того, що ви будуєте.
• Зовнішній стан підвищує масштабованість і стійкість.
• Вартість: додаткова затримка й складність.
• Враховуйте: узгодженість, кешування та шаблони доступу до даних.

 

Stateful

 

• Дані сесії зберігаються на сервері.
• Запити мають надходити до того ж екземпляра (sticky sessions).
• Обмежує гнучкість масштабування.
• У разі збою екземпляра сесія втрачається.

Stateless

 

• Кожен запит обробляється незалежно.
• Стан на сервері не зберігається.
• Стан зберігається в зовнішніх системах.
• Переважний підхід для cloud-native застосунків.
• Будь-який екземпляр може обробити будь-який запит — горизонтальне масштабування просте.

Давайте потренуємось!

Розроблення застосунків на AWS