— Официальная документация KEDA: база для workload-aware масштабирования в Kubernetes
— The Reactive Manifesto: про эластичность, отзывчивость и backpressure
— Concurrency Limits by Netflix: про динамическое управление параллелизмом
— Event-Driven Architecture: чтобы понять, как строить асинхронные системы и разделять fast-path и heavy-path. Что читать: книга Designing Event-Driven Systems Бена Стопфорда
— Kubernetes Custom Metrics API и Prometheus: чтобы масштабировать HPA не только по CPU и памяти. Что читать: документация Prometheus Adapter for Kubernetes Metrics APIs
— Теория массового обслуживания и закон Литтла: чтобы считать размеры пулов, длину очередей и время ответа. Что читать: Understanding Little’s Law и материалы по Queueing Theory
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
name: message-router-scaler
namespace: messaging-core
spec:
scaleTargetRef:
name: message-router-deployment
minReplicaCount: 2
maxReplicaCount: 50
triggers:
- type: kafka
metadata:
bootstrapServers: kafka-cluster.messaging:9092
consumerGroup: router-group
topic: incoming-client-events
lagThreshold: "1000"Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7
This media is not supported in your browser
VIEW IN TELEGRAM
😁8❤5🤣5
Отказоустойчивость 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
Наблюдаемость 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