Шаблони архітектури застосунків в AWS

Розгортання застосунків в AWS

Dunieski Otano

Amazon Web Services Solutions Architect

Познайомтеся з викладачем

Викладач курсу Dunieski Otano, AWS Solutions Architect, близько десяти років досвіду в хмарі

Чому важливо обрати правильну архітектуру

Схема рішень у світлій темі: один вузол вибору архітектури розгалужується на три чинники — зв'язність, стан і комунікація; внизу піктограма ваг як натяк на компроміси

Архітектура — це набір компромісів, а не єдина відповідь
- Три запитання визначають вибір:
  - Наскільки щільно компоненти зв'язані?
  - Де зберігається стан?
  - Комунікація синхронна чи асинхронна?
- Підбирайте шаблон під навантаження, а не тренди

П'ятничний каскад збоїв

Повільний платіжний API «заморожує» весь чекаут
Усі сервіси чекали на нього синхронно
Рішення — архітектура, а не швидший API

Порівняння поряд: тісно зв'язані сервіси, що стопоряться, проти сервісів, розв'язаних чергою повідомлень

Чому архітектурні вибори визначають деплоймент

Діаграма: крихка тісно зв'язана архітектура, де збій одного сервісу тягне всі, проти стійкого дизайну, де буфер-черга ізолює збій і решта сервісів продовжують роботу

Обраний шаблон визначає, як застосунок масштабується й відмовляє
- Тісна зв'язність ламається під навантаженням
Правильний шаблон робить деплой передбачуваним
- Той самий код — зовсім інша поведінка в продакшені

Базові шаблони архітектури

Моноліт: один юніт деплою, легко стартувати
Мікросервіси: незалежні сервіси, деплояться окремо
Подійно-орієнтована: компоненти реагують на події, а не прямі виклики
- Fanout — підшаблон подійної архітектури: одна подія для багатьох споживачів

Три шаблони архітектури поряд: моноліт як єдиний блок, мікросервіси як незалежні сервіси, подійно-орієнтована з шиною подій; у панелі подій показано fanout — публікація однієї події багатьом споживачам

Станова проти безстанової

Безстанова: між запитами клієнтські дані не зберігаються
- Будь-який інстанс може обробити будь-який запит
Станова: інстанс пам'ятає попередні взаємодії
Безстановість дозволяє горизонтальне масштабування
- Винесіть спільний стан у DynamoDB чи ElastiCache

Безстанова функція зліва, до якої може потрапити будь-який запит, проти станової справа, прив'язаної до однієї сесії клієнта

Тісна vs слабка зв'язність

Тісна зв'язність: викликач блокується, чекаючи повільного викликаного, проти слабкої зв'язності: черга SQS буферизує повідомлення й продюсер працює далі

Тісна зв'язність: викликач чекає відповіді викликаного
Один повільний сервіс стопорить увесь ланцюг
Слабка зв'язність: між сервісами стоїть черга Amazon SQS
Продюсер працює далі, навіть якщо конс'юмер недоступний

Синхронна vs асинхронна

Синхронна: викликач блокується й чекає результат
Використовуйте, коли відповідь потрібна негайно
Асинхронна: викликач передає роботу й повертається
Підходить для повільних, «сплескових» або не термінових задач

Синхронний виклик з блокуванням до відповіді зліва проти асинхронного передання з негайним поверненням і фоновою обробкою справа

Шаблони стійкості для сторонніх викликів

Повтор із експоненційною затримкою: щораз довше очікування між спробами
Запобіжник (circuit breaker): тимчасово припинити виклики до сервісу, що падає
Черга «мертвих» листів: відкласти повідомлення, що постійно фейляться
Комбінуйте підходи; суцільні ретраї лише погіршують збої

Три шаблони стійкості: крива ретраїв із експоненційною затримкою, запобіжник, що зупиняє виклики до сервісу з помилками, і черга «мертвих» листів для повідомлень після вичерпання ретраїв

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

Розгортання застосунків в AWS