Отказоустойчивость Cloud Ready: как не уронить весь сервис 🐯
Если сервис завязан на внешние зависимости, очереди, базы данных и сеть — сбой неизбежен. Главное не дать ему уронить весь сервис.
ИТ-тигр Иван Кузьминов собрал подходы, которые помогают не уронить весь сервис из-за одного сбоя. Из карточек вы узнаете:
— Где ставить Circuit Breaker
— Какие режимы деградации предусмотреть заранее
— Как изолировать ресурсы, чтобы один сбой не бил по всем
— Как проверять отказоустойчивость через Chaos Engineering
🔗 Полезное чтиво по теме:
— Паттерн Circuit Breaker от Martin Fowler: описание от гуру архитектуры
— Fault Tolerance patterns от Microsoft Architecture: каталог паттернов устойчивости
— Chaos Engineering: Principles of Chaos: принципы хаос-инженерии
🧭 Для глубокого изучения:
— SRE: книга Google SRE Book, особенное внимание главе Handling Overload
— Распределенные транзакции и паттерн Saga: статья Saga distributed transactions
— Health Check API и Readiness/Liveness probes: Kubernetes Documentation
Если сервис завязан на внешние зависимости, очереди, базы данных и сеть — сбой неизбежен. Главное не дать ему уронить весь сервис.
ИТ-тигр Иван Кузьминов собрал подходы, которые помогают не уронить весь сервис из-за одного сбоя. Из карточек вы узнаете:
— Где ставить Circuit Breaker
— Какие режимы деградации предусмотреть заранее
— Как изолировать ресурсы, чтобы один сбой не бил по всем
— Как проверять отказоустойчивость через Chaos Engineering
— Паттерн Circuit Breaker от Martin Fowler: описание от гуру архитектуры
— Fault Tolerance patterns от Microsoft Architecture: каталог паттернов устойчивости
— Chaos Engineering: Principles of Chaos: принципы хаос-инженерии
— SRE: книга Google SRE Book, особенное внимание главе Handling Overload
— Распределенные транзакции и паттерн Saga: статья Saga distributed transactions
— Health Check API и Readiness/Liveness probes: Kubernetes Documentation
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8👀5 4👨💻1🤪1
Наблюдаемость Cloud Ready: как связать метрики, логи и трейсы
Если система состоит из десятков сервисов, мало знать, что случился сбой. По одному алерту нельзя быстро понять, где именно проблема, какой сервис тормозит и что из-за этого ломается у пользователя. Из-за этого затягивается поиск причины, починка инцидента и приходится дольше возвращать продукт в норму.
💁🏻♂️Я рассказал, как собрать наблюдаемость, в которой метрики, логи и трейсы работают вместе. Листайте карточки🖱
🔗 Полезное чтиво по теме:
— Micrometer.io Official Docs: как правильно инструментировать код
— Grafana LGTM Stack: концепция единого стека наблюдаемости
— Prometheus.io: база по метрикам
— Introduction to Grafana Loki: как выстроить логирование без лишних затрат
🧭 Для глубокого изучения:
— OpenTelemetr: стандарт сбора телеметрии
— JVM Profiling: как смотреть, что происходит внутри потоков Java
— Перцентили и гистограммы: почему среднее значение часто врёт
Если система состоит из десятков сервисов, мало знать, что случился сбой. По одному алерту нельзя быстро понять, где именно проблема, какой сервис тормозит и что из-за этого ломается у пользователя. Из-за этого затягивается поиск причины, починка инцидента и приходится дольше возвращать продукт в норму.
💁🏻♂️Я рассказал, как собрать наблюдаемость, в которой метрики, логи и трейсы работают вместе. Листайте карточки
🔗 Полезное чтиво по теме:
— Micrometer.io Official Docs: как правильно инструментировать код
— Grafana LGTM Stack: концепция единого стека наблюдаемости
— Prometheus.io: база по метрикам
— Introduction to Grafana Loki: как выстроить логирование без лишних затрат
🧭 Для глубокого изучения:
— OpenTelemetr: стандарт сбора телеметрии
— JVM Profiling: как смотреть, что происходит внутри потоков Java
— Перцентили и гистограммы: почему среднее значение часто врёт
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6🔥4👾3 1
Состояние никуда не девается: как с ним работать в Cloud Ready
Долгое время в разработке жила идея: если сервис ничего у себя не хранит, то его будет проще масштабировать. Но в реальности любое полезное приложение всё равно хранит данные и контекст — в базе, кэше, событиях или внутри актора. Состояние не исчезает, а просто переезжает с места на место.
Я рассказал про четыре подхода, которые помогают работать с состоянием в распределенных системах. Смотрите карточки☝️
🔗 Полезное чтиво по теме:
— Event Sourcing Pattern: база для понимания событийных моделей
— CQRS Pattern: как проектировать раздельные модели данных
— Akka Actors Concepts: введение в модель акторов от создателей Akka
— The CAP Theorem: почему нельзя получить все и сразу в распределенных данных
🧭 Для глубокого изучения:
— Eventual Consistency: почему данные после записи появляются не сразу
— Паттерн Saga: как проводить операции между сервисами без тяжёлых транзакций
— Шардирование и партиционирование: как распределять данные без горячих точек
Долгое время в разработке жила идея: если сервис ничего у себя не хранит, то его будет проще масштабировать. Но в реальности любое полезное приложение всё равно хранит данные и контекст — в базе, кэше, событиях или внутри актора. Состояние не исчезает, а просто переезжает с места на место.
Я рассказал про четыре подхода, которые помогают работать с состоянием в распределенных системах. Смотрите карточки
🔗 Полезное чтиво по теме:
— Event Sourcing Pattern: база для понимания событийных моделей
— CQRS Pattern: как проектировать раздельные модели данных
— Akka Actors Concepts: введение в модель акторов от создателей Akka
— The CAP Theorem: почему нельзя получить все и сразу в распределенных данных
🧭 Для глубокого изучения:
— Eventual Consistency: почему данные после записи появляются не сразу
— Паттерн Saga: как проводить операции между сервисами без тяжёлых транзакций
— Шардирование и партиционирование: как распределять данные без горячих точек
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9👾3 3