Джокер
Администратор
- Регистрация
- 1 Янв 2015
- Сообщения
- 133.850
- Реакции
- 76.355
Складчина: Паттерны отказоустойчивости в микросервисах на Go [Balun.Courses]
Глядя на архитектуру, возникают вопросы:
Упал один микросервис, а за ним вся система. Как разорвать цепочку
БД легла от всплеска запросов. Как правильно использовать кэш, чтобы оптимизировать хранение данных
В момент дежурства упала система. Как найти быстро найти причину, и какие действия предпринять для ее устранения без помощи старших коллег
Как правильно кэшировать данные, чтобы не получить тонны устаревшей информации при инвалидации кеша или падении Redis
Как написать повторную обработку сообщений, которая гарантированно не сломает систему
Как правильно использовать retry, чтобы он за минуты при нагрузке не положил прод
Чтобы решить задачу: Вместе c Senior из Ozon Tech поочередно рассмотришь все проблемы в коде, к каждой разберешь теорию и сразу напишешь best practice решение, как в BigTech
6 недель систематизированно изучаем применение паттернов отказоустойчивости. Попадешь в смоделированную ecom-компанию: микросервисная архитектура с десятками типичных проблем в коде. Поочередно разберешь каждую, получишь необходимую теорию и уже со второго занятия начнешь писать код
В результате освоишь hard’ы, без которых сложно вырасти до Senior’а
Научишься изолировать упавший сервис с помощью Circuit Breaker, а также писать Graceful Degradation и Fallback, чтобы один баг не ронял всю систему
Сможешь контролировать перегруз БД через Rate Limiter, «склейку» дублирующихся запросов через Single Flight и балансировку Nginx
Научишь систему заранее оповещать о предстоящих инцидентах, а если он уже случился — сможешь быстро их находить и решать
Реализуешь многоуровневое кеширование с LRU/LFU-вытеснением и настроишь Redis так, чтобы данные в кеше были всегда актуальны
Научишься внедрять идемпотентность и писать повторную обработку сообщений с outbox-паттерном и ручным управлением offset’ами в Kafka
Сможешь писать Retry, который не создает «шторм» запросов, и делает систему стабильной под нагрузкой
Курс подойдет для junior/middle Golang-разработчиков, которые хотят вырасти в грейде.
Программа состоит на 80% из практики, поэтому нужно знать язык и иметь базовые навыки работы с Kafka и Redis.
Программа:
Неделя 1. Ключевые проблемы и принципы отказоустойчивости
Неделя 2. Обработка ошибок и временные сбои
Неделя 3. Контроль нагрузки и балансировка
Неделя 4. Асинхронная коммуникация и очереди
Неделя 5. Эффекты слоя кеширования при построении высокодоступных систем
Неделя 6. Обнаружение отказа и методы реагирования
Спойлер: Программа подробно
Неделя 1. Ключевые проблемы и принципы отказоустойчивости
Особенности распределенных информационных систем:
Отказоустойчивость & Надежность
Каскадные сбои
CAP-теорема (Consistency, Availability, Partition Tolerance)
Классификация проблем и типы частичных отказов
Метрики надежности с примерами:
SLA (Service Level Agreement)
SLO (Service Level Objective)
SLI (Service Level Indicator)
Что такое «99,9%» доступности и для чего это нужно?
Влияние отказов на целостность данных:
Понятие целостности и угрозы ее потери
Идемпотентность
Split-brain & Failover
Кворумная запись/чтение
Разберем:
что такое WAL и зачем он нужен Postgres
почему важен replica factor > 1 в Kafka
Как ЮKassa обрабатывает дубликаты платежей
BigTech-инциденты и как их можно было избежать:
GitHub — как все упало на сутки
AWS us-east-1 — как пострадали сотни онлайн-сервисов по всему миру
Facebook, Instagram, WhatsApp — как отказ системы обрушил цену акции и привел к потере $6 млрд
GitLab — как легла БД и удалился пользовательский код
Случаи из личной практики в production
Результат недели:
понимаешь суть и последствия отказоустойчивости, как свойства системы
можешь выделить 2 из 3 свойств CAP-теоремы для выбранной системы
магические девятки в метриках надежности теперь прозрачны и понятны
Неделя 2. Обработка ошибок и временные сбои
Функционал работает идеально, и вроде бы всё хорошо. Но что происходит, когда база данных на секунду «ложится»? Или сторонний API начинает отвечать с задержкой в 30 секунд? А если сеть между микросервисами ненадолго пропадает?
В реальном мире такие инциденты неизбежны. И правильная реакция на них — барьер между грейдом middle и senior
Повторная попытка:
умный retry
грамотный выбор backoff + jitter
idempotent requests
hedging запросов
Контроль выполнения:
timeout, когда дольше уже нельзя
установка deadline
cancel propagation при прерывании пути запроса
Защита системы от каскадных сбоев:
circuit breaker для спасения от отказов частей системы
graceful degradation, когда отказ все же произошел
fallback по возможности
На практике:
внедрим circuit breaker между сервисами
обеспечим graceful degradation
применим fallback
выставим timeout'ы на синхронные вызовы
реализуем idempotent retry
Домашняя работа:
Ты на дежурстве, алерты стучатся в дверь, а пользователи недовольны работой системы. Задача — самостоятельно найти инцидент, выбрать нужный паттерн и реализовать его
Результат:
умеешь справляться с ошибками и временными сбоями
глубоко понимаешь суть каждого паттерна и сценария его применения
умеешь применять это на практике в реальном проекте
Неделя 3. Контроль нагрузки и балансировка
Что делать, если внезапный всплеск трафика, медленный запрос к базе или сбой в соседнем микросервисе роняет прод? В этом модуле учимся делать сервисы стабильными при любой нагрузке
Изоляция ресурсов:
планирование ресурсов
подход bulkhead
процессная изоляция
физическая изоляция
Контроль нагрузки:
глубокое погружение в rate limiting
single flight как фильтр
backpressure / load shedding
Распределение нагрузки:
клиентская / серверная
алгоритмы балансировки
стратегии деплоя и откат
upstream
active / passive health checks
nginx
На практике:
настроим балансировку на nginx
посмотрим на различные алгоритмы балансировки в действии
применим rate limiter и изучим его вдоль и поперек
разберем подкапотную магию single flight и применим его как щит
Домашнее задание:
QA во время стресс-тестов выявил деградацию системы. Найди инцидент, выбери нужный паттерн и реализуй его
Результат:
умеешь защищать свои и чужие сервисы в условиях непредусмотренных нагрузок
понимаешь, как все работает изнутри, и умеешь выделять общие паттерны применения подходов в реальных системах
разбираешься в подходах к распределению нагрузки
Неделя 4. Асинхронная коммуникация и очереди
Ты уверен(-а), что твои сообщения доходят? Что заказ не создастся дважды, а платеж не обработается несколько раз?
В этом модуле учимся строить асинхронный отказоустойчивый конвеер — гарантированно доставлять сообщения, легко отрабатывать сбои и бесшовно масштабироваться под нагрузку
Очереди и брокеры сообщений:
особенности работы с технологиями (Rabbit, Kafka)
буфферизация и выравнивание нагрузки
гарантии доставки сообщений
масштабирование при нагрузке
распределенные транзакции
SAGA vs 2PC
Грамотная запись:
подтверждение от брокера
умные retry
идемпотентность
outbox как лекарство от бед
Грамотное чтение:
offsets и восстановление
manual vs auto commit
как обработать дубликаты, будто их нет
inbox для чайников
dead letter queue
На практике:
как сообщения теряют события без нашего ведома, и как это исправить
применим outbox pattern
настроим механизм идемпотентности
научимся писать DLQ (Dead Letter Queue)
разберем подходы к реагированию на нештатные ситуации
Результат:
понимаешь, на что обращать внимание при проектировании асинхронного взаимодействия
не теряешь сообщения и умеешь справляться с дубликатами
умеешь писать паттернами inbox/outbox
умеешь применять DLQ и работать с ним
знаешь критически важные метрики и умеешь за нами наблюдать
Неделя 5. Эффекты слоя кеширования при построении высокодоступных систем
Добавили кэш, чтобы ускорить систему, а получили лавину запросов к базе в момент его протухания? Пользователи видят устаревшие данные и жалуются? В этом модуле изучаем best practices по использованию кеша
Stale Data (протухшие данные):
время жизни объектов (ttl)
активная инвалидация
событийная инвалидация
Data consistency (согласованность данных):
write-thorugh
управление ttl
блокировки и версионирование
Compare and swap (check and set)
репликация в зоопарке инструментов кеширования
Thundering Herd (грозовая стая):
signle flight
фоновая актуализация
soft ttl и мертвые данные
Cache avalanche (лавина кеша):
random ttl & jitter
многоуровневое кеширование
проактивное обновление
лимитирование ресурсов на источник данных
Стратегии вытеснения:
LRU / LFU / MRU / FIFO / Random
На практике:
реализуем кеширование с грамотной стратегией вытеснения
разберем все проблемы с внедрением кеш-слоя и изучим подходы к их решению
посмотрим на конфигурацию redis и выберем самые оптимальные параметры
разберем best practices по эксплуатации кеша
изучим перечень метрик для мониторинга
Результат:
понимаешь, как кеш слой может помочь при высоких нагрузках
знаешь, какие гарантии отказоустойчивости и проблемы он может принести
обладаешь необходимыми знаниями для грамотного построения кеш-слоя под любой тип нагрузки системы
Неделя 6. Обнаружение отказа и методы реагирования
Тушишь один инцидент, а на смену приходит следующий. Пользователи видят ошибки раньше, чем срабатывают алерты. Классика
В этом модуле научим систему предупреждать об отказах до удара по пользователю. Узнаешь, как быстро найти и локализовать сбой в синхронных вызовах или в лаге асинхронных очередей, и что делать, когда автоматика уже не справляется
Инциденты для всех:
централизация разбора нештатных ситуаций
важность ключевых бизнес метрик
кто такой координатор?
при чем тут обслуживание инфраструктуры и почему важно уведомлять о планируемых работах
что делать, если автоматика не помогла?
как наказать виновных?
Особенности синхронного взаимодействия:
следим за response time & response codes
контролируем утилизацию ресурсов
не забываем про наблюдаемость соседей и внешних инструментов
важность подробного логгирования
алерты и их влияние на скорость устранения инцидентов
Асинхронное взаимодействие:
метрики обработки топиков (скорость, время, имеющийся лаг на партициях)
наблюдаемость состояния consumer-групп
методы борьбы с лагом в неожиданные моменты
алерты, как средство оперативного реагирования на проблемы с топиками
ручные манипуляции с оффсетами и консьюмер группами.
Результат:
умеешь находить инциденты и отказы и бороться с ними, как это делают в BigTech
знаешь, на что обращать внимание в первую очередь при возникновении нештатной ситуации
знаешь, как локализовать отказ при синхронном и асинхронном взаимодействии
умеешь устранять последствия, инцидент все же произошел
Преподает Даниил Булыкин - senior в ozon tech.
Цену поставит организатор
СКАЧАТЬ СЛИВЫ КУРСОВ
Глядя на архитектуру, возникают вопросы:
Упал один микросервис, а за ним вся система. Как разорвать цепочку
БД легла от всплеска запросов. Как правильно использовать кэш, чтобы оптимизировать хранение данных
В момент дежурства упала система. Как найти быстро найти причину, и какие действия предпринять для ее устранения без помощи старших коллег
Как правильно кэшировать данные, чтобы не получить тонны устаревшей информации при инвалидации кеша или падении Redis
Как написать повторную обработку сообщений, которая гарантированно не сломает систему
Как правильно использовать retry, чтобы он за минуты при нагрузке не положил прод
Чтобы решить задачу: Вместе c Senior из Ozon Tech поочередно рассмотришь все проблемы в коде, к каждой разберешь теорию и сразу напишешь best practice решение, как в BigTech
6 недель систематизированно изучаем применение паттернов отказоустойчивости. Попадешь в смоделированную ecom-компанию: микросервисная архитектура с десятками типичных проблем в коде. Поочередно разберешь каждую, получишь необходимую теорию и уже со второго занятия начнешь писать код
В результате освоишь hard’ы, без которых сложно вырасти до Senior’а
Научишься изолировать упавший сервис с помощью Circuit Breaker, а также писать Graceful Degradation и Fallback, чтобы один баг не ронял всю систему
Сможешь контролировать перегруз БД через Rate Limiter, «склейку» дублирующихся запросов через Single Flight и балансировку Nginx
Научишь систему заранее оповещать о предстоящих инцидентах, а если он уже случился — сможешь быстро их находить и решать
Реализуешь многоуровневое кеширование с LRU/LFU-вытеснением и настроишь Redis так, чтобы данные в кеше были всегда актуальны
Научишься внедрять идемпотентность и писать повторную обработку сообщений с outbox-паттерном и ручным управлением offset’ами в Kafka
Сможешь писать Retry, который не создает «шторм» запросов, и делает систему стабильной под нагрузкой
Курс подойдет для junior/middle Golang-разработчиков, которые хотят вырасти в грейде.
Программа состоит на 80% из практики, поэтому нужно знать язык и иметь базовые навыки работы с Kafka и Redis.
Программа:
Неделя 1. Ключевые проблемы и принципы отказоустойчивости
Неделя 2. Обработка ошибок и временные сбои
Неделя 3. Контроль нагрузки и балансировка
Неделя 4. Асинхронная коммуникация и очереди
Неделя 5. Эффекты слоя кеширования при построении высокодоступных систем
Неделя 6. Обнаружение отказа и методы реагирования
Спойлер: Программа подробно
Неделя 1. Ключевые проблемы и принципы отказоустойчивости
Особенности распределенных информационных систем:
Отказоустойчивость & Надежность
Каскадные сбои
CAP-теорема (Consistency, Availability, Partition Tolerance)
Классификация проблем и типы частичных отказов
Метрики надежности с примерами:
SLA (Service Level Agreement)
SLO (Service Level Objective)
SLI (Service Level Indicator)
Что такое «99,9%» доступности и для чего это нужно?
Влияние отказов на целостность данных:
Понятие целостности и угрозы ее потери
Идемпотентность
Split-brain & Failover
Кворумная запись/чтение
Разберем:
что такое WAL и зачем он нужен Postgres
почему важен replica factor > 1 в Kafka
Как ЮKassa обрабатывает дубликаты платежей
BigTech-инциденты и как их можно было избежать:
GitHub — как все упало на сутки
AWS us-east-1 — как пострадали сотни онлайн-сервисов по всему миру
Facebook, Instagram, WhatsApp — как отказ системы обрушил цену акции и привел к потере $6 млрд
GitLab — как легла БД и удалился пользовательский код
Случаи из личной практики в production
Результат недели:
понимаешь суть и последствия отказоустойчивости, как свойства системы
можешь выделить 2 из 3 свойств CAP-теоремы для выбранной системы
магические девятки в метриках надежности теперь прозрачны и понятны
Неделя 2. Обработка ошибок и временные сбои
Функционал работает идеально, и вроде бы всё хорошо. Но что происходит, когда база данных на секунду «ложится»? Или сторонний API начинает отвечать с задержкой в 30 секунд? А если сеть между микросервисами ненадолго пропадает?
В реальном мире такие инциденты неизбежны. И правильная реакция на них — барьер между грейдом middle и senior
Повторная попытка:
умный retry
грамотный выбор backoff + jitter
idempotent requests
hedging запросов
Контроль выполнения:
timeout, когда дольше уже нельзя
установка deadline
cancel propagation при прерывании пути запроса
Защита системы от каскадных сбоев:
circuit breaker для спасения от отказов частей системы
graceful degradation, когда отказ все же произошел
fallback по возможности
На практике:
внедрим circuit breaker между сервисами
обеспечим graceful degradation
применим fallback
выставим timeout'ы на синхронные вызовы
реализуем idempotent retry
Домашняя работа:
Ты на дежурстве, алерты стучатся в дверь, а пользователи недовольны работой системы. Задача — самостоятельно найти инцидент, выбрать нужный паттерн и реализовать его
Результат:
умеешь справляться с ошибками и временными сбоями
глубоко понимаешь суть каждого паттерна и сценария его применения
умеешь применять это на практике в реальном проекте
Неделя 3. Контроль нагрузки и балансировка
Что делать, если внезапный всплеск трафика, медленный запрос к базе или сбой в соседнем микросервисе роняет прод? В этом модуле учимся делать сервисы стабильными при любой нагрузке
Изоляция ресурсов:
планирование ресурсов
подход bulkhead
процессная изоляция
физическая изоляция
Контроль нагрузки:
глубокое погружение в rate limiting
single flight как фильтр
backpressure / load shedding
Распределение нагрузки:
клиентская / серверная
алгоритмы балансировки
стратегии деплоя и откат
upstream
active / passive health checks
nginx
На практике:
настроим балансировку на nginx
посмотрим на различные алгоритмы балансировки в действии
применим rate limiter и изучим его вдоль и поперек
разберем подкапотную магию single flight и применим его как щит
Домашнее задание:
QA во время стресс-тестов выявил деградацию системы. Найди инцидент, выбери нужный паттерн и реализуй его
Результат:
умеешь защищать свои и чужие сервисы в условиях непредусмотренных нагрузок
понимаешь, как все работает изнутри, и умеешь выделять общие паттерны применения подходов в реальных системах
разбираешься в подходах к распределению нагрузки
Неделя 4. Асинхронная коммуникация и очереди
Ты уверен(-а), что твои сообщения доходят? Что заказ не создастся дважды, а платеж не обработается несколько раз?
В этом модуле учимся строить асинхронный отказоустойчивый конвеер — гарантированно доставлять сообщения, легко отрабатывать сбои и бесшовно масштабироваться под нагрузку
Очереди и брокеры сообщений:
особенности работы с технологиями (Rabbit, Kafka)
буфферизация и выравнивание нагрузки
гарантии доставки сообщений
масштабирование при нагрузке
распределенные транзакции
SAGA vs 2PC
Грамотная запись:
подтверждение от брокера
умные retry
идемпотентность
outbox как лекарство от бед
Грамотное чтение:
offsets и восстановление
manual vs auto commit
как обработать дубликаты, будто их нет
inbox для чайников
dead letter queue
На практике:
как сообщения теряют события без нашего ведома, и как это исправить
применим outbox pattern
настроим механизм идемпотентности
научимся писать DLQ (Dead Letter Queue)
разберем подходы к реагированию на нештатные ситуации
Результат:
понимаешь, на что обращать внимание при проектировании асинхронного взаимодействия
не теряешь сообщения и умеешь справляться с дубликатами
умеешь писать паттернами inbox/outbox
умеешь применять DLQ и работать с ним
знаешь критически важные метрики и умеешь за нами наблюдать
Неделя 5. Эффекты слоя кеширования при построении высокодоступных систем
Добавили кэш, чтобы ускорить систему, а получили лавину запросов к базе в момент его протухания? Пользователи видят устаревшие данные и жалуются? В этом модуле изучаем best practices по использованию кеша
Stale Data (протухшие данные):
время жизни объектов (ttl)
активная инвалидация
событийная инвалидация
Data consistency (согласованность данных):
write-thorugh
управление ttl
блокировки и версионирование
Compare and swap (check and set)
репликация в зоопарке инструментов кеширования
Thundering Herd (грозовая стая):
signle flight
фоновая актуализация
soft ttl и мертвые данные
Cache avalanche (лавина кеша):
random ttl & jitter
многоуровневое кеширование
проактивное обновление
лимитирование ресурсов на источник данных
Стратегии вытеснения:
LRU / LFU / MRU / FIFO / Random
На практике:
реализуем кеширование с грамотной стратегией вытеснения
разберем все проблемы с внедрением кеш-слоя и изучим подходы к их решению
посмотрим на конфигурацию redis и выберем самые оптимальные параметры
разберем best practices по эксплуатации кеша
изучим перечень метрик для мониторинга
Результат:
понимаешь, как кеш слой может помочь при высоких нагрузках
знаешь, какие гарантии отказоустойчивости и проблемы он может принести
обладаешь необходимыми знаниями для грамотного построения кеш-слоя под любой тип нагрузки системы
Неделя 6. Обнаружение отказа и методы реагирования
Тушишь один инцидент, а на смену приходит следующий. Пользователи видят ошибки раньше, чем срабатывают алерты. Классика
В этом модуле научим систему предупреждать об отказах до удара по пользователю. Узнаешь, как быстро найти и локализовать сбой в синхронных вызовах или в лаге асинхронных очередей, и что делать, когда автоматика уже не справляется
Инциденты для всех:
централизация разбора нештатных ситуаций
важность ключевых бизнес метрик
кто такой координатор?
при чем тут обслуживание инфраструктуры и почему важно уведомлять о планируемых работах
что делать, если автоматика не помогла?
как наказать виновных?
Особенности синхронного взаимодействия:
следим за response time & response codes
контролируем утилизацию ресурсов
не забываем про наблюдаемость соседей и внешних инструментов
важность подробного логгирования
алерты и их влияние на скорость устранения инцидентов
Асинхронное взаимодействие:
метрики обработки топиков (скорость, время, имеющийся лаг на партициях)
наблюдаемость состояния consumer-групп
методы борьбы с лагом в неожиданные моменты
алерты, как средство оперативного реагирования на проблемы с топиками
ручные манипуляции с оффсетами и консьюмер группами.
Результат:
умеешь находить инциденты и отказы и бороться с ними, как это делают в BigTech
знаешь, на что обращать внимание в первую очередь при возникновении нештатной ситуации
знаешь, как локализовать отказ при синхронном и асинхронном взаимодействии
умеешь устранять последствия, инцидент все же произошел
Преподает Даниил Булыкин - senior в ozon tech.
Цену поставит организатор
СКАЧАТЬ СЛИВЫ КУРСОВ
Для возможности скачивать складчины и сливы курсов нужно зарегистрироваться
Возможно, Вас ещё заинтересует:
- Спокойствие по запросу: что делать, когда накрывает тревожность [Level One] [Татьяна Смирнова]
- Сексуальность в паре: от инфантильных источников возбуждения к взрослому наслаждению [EduNote] [Эрик Смаджа]
- На каких языках мы говорим в аналитической кабинете? [EduNote] [Юрий Баранов]
- Таблица Биона: Вертикаль [EduNote] [Елена Ливач]
- Настойка для восстановления печени [Алёна Ковальчук]
- Точка глобального разлома [Владимир Левченко]
- Испанские глаголы: магия приставок [Гоар Карапетян]
- Пособия по современной испанской лексике: Libro del alumno + Libro del trabajo [Тариф Две части] [Анна Шалагинова, Мануэль Гомес-Пейна]
- Гайд-тренажер по прошедшим временам [Анна Шалагинова]
- Живая. Сексуальность, флирт и женственность [Анна Риттер, Сергей Воронцов]