О чем курс:
Компании, которые уходят от монолитной архитектуры к сервисной и микросервисной, часто терпят поражение — получают такой же монолит, только разбитый по нескольким репозиториям.
Мы расскажем, как избежать этих проблем — правильно разнести функциональность по сервисам и выбрать подходящий формат асинхронной коммуникации. Вы познакомитесь с Kafka, Event Streaming и понятием Schema Registry. Кроме того, мы упомянем о CQRS и SAGA.
О чём курс
Программа курса:
Проектирование
Изучим 6 шагов для проектирования системы — начиная от анализа бизнес-требований и заканчивая связями между компонентами
в системе. Разберёмся, как получить данные, необходимые для работы бизнес-логики, из другого сервиса или части.
На выходе получим полностью спроектированную систему, которая отвечает на все вопросы имплементации: разберёмся, какие данные нужны бизнесу, какие команды он хочет выполнять с ES like — подхода, а также составим модель данных, поймём, почему UML/ERD может быть избыточен.
Урок 2
Переводим язык бизнеса в процессы и модель данных
Урок 3
Переводим процессы и модель данных в сервисы и коммуникации
Имплементация
Выберем и сделаем механизм аутентификации. Отправим первое асинхронное сообщение, разберёмся в разнице между Distributed message Queue и Distributed log. А так как мы будем использовать kafka — разберёмся, как она работает на базовом уровне.
На выходе получим первые два сервиса из проекта системы:
SSO и первый сервис для бизнеса. А также свяжем их асинхронной коммуникацией для корректной работы всей системы.
Урок 4
Первый сервис — authn в распределённых системах, CUD и Business events на практике
Урок 5
Основной сервис инвентаризации, выбор message broker
Дорабатываем систему
Спроектируем логику для задачи, к которой система не приспособлена, — разберёмся с эволюцией событий и поймём, в каких случаях надо соблюдать прямую, а в каких — обратную совместимость.
Сделаем, чтобы с нашей системой можно было спокойно спать ночью: разберёмся в тестировании, чтобы новые фичи ничего не ломали, и придумаем, как обеспечить устойчивость системы и обрабатывать невалидные или failure-события.
На выходе разработаем план, что делать, когда изменение данных в событии потенциально может развалить всю систему. Также определим, как лучше тестировать асинхронную систему в каждом из случаев и что делать с событиями, которые сломались на уровне бизнес-логики или которые надо заретраить.
Урок 7
После запуска: тестирование, ретраи и обработка ошибочных событий
Урок 6
Добавляем незапланированный сервис: эволюция событий в системе
Личный опыт и выводы
Подведём итоги курса: поговорим о проблемах, которые Антон наблюдал в системах, мигрирующих на асинхронную коммуникацию. Это нейминг, проектирование, техническая реализация. Затронем data management patterns, чтобы показать, что это отдельные концепции, которые могут использоваться в асинхронной архитектуре, но не обязательно должны быть в ней. Обсудим, как практиковаться после курса и где искать идеи и места для новых проектов.
На выходе: составим список подводных камней и советов, которые помогут избежать проблем. Получим цельную картину и шаги/темы для дальнейшего изучения.
Урок 9
Итоги и что делать дальше
Урок 8
Опыт Антона: 4 асинхронные системы из реальной жизни
Тарифы:
Теория
— 9 видеоуроков
— Факультатив по биллингу и модели данных в записи
— Конспект самого главного
— Список дополнительных материалов
Практика
— Домашка из 6 частей, без обратной связи
Бонусы
— Доступ к материалам после окончания курса — 4 месяца