#circuit_breaker — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #circuit_breaker, aggregated by home.social.
-
Распилили монолит на 6 сервисов — и случайно собрали распределённый монолит: где мы ошиблись с границами
Монолит документооборота, менеджмент говорит: «пора пилить на микросервисы». Мы нарезали шесть сервисов, сверху повесили API Gateway, Load Balancer и Circuit Breaker и какое-то время искренне считали, что теперь у нас взрослая распределённая система. По факту мы собрали распределённый монолит. Те же зависимости, что и в монолите, только теперь по сети — с таймаутами, ретраями и без общей транзакции. Оно работало, спорить не буду. Просто каждая вторая проблема в итоге упиралась в одно и то же: границы сервисов мы провели не там, где надо . Это не туториал «как правильно резать монолит на DDD-bounded-context за 10 шагов» — таких на Хабре хватает. Это разбор конкретных мест, где границы у нас поехали, в порядке от «это все знают, но всё равно наступают» до «поняли только в проде под нагрузкой». Если вы сейчас режете свой монолит — читайте как чеклист. Если уже прошли — сверьте, сколько совпало. Дисклеймер: проект под NDA. Названия сервисов, домен и детали обобщены и изменены, часть цифр округлена. Сами грабли и порядок, в котором мы на них наступали, — настоящие.
https://habr.com/ru/articles/1076092/
#микросервисы #монолит #декомпозиция_монолита #распределённый_монолит #границы_сервисов #bounded_context #DDD #Kafka #Circuit_Breaker
-
Распилили монолит на 6 сервисов — и случайно собрали распределённый монолит: где мы ошиблись с границами
Монолит документооборота, менеджмент говорит: «пора пилить на микросервисы». Мы нарезали шесть сервисов, сверху повесили API Gateway, Load Balancer и Circuit Breaker и какое-то время искренне считали, что теперь у нас взрослая распределённая система. По факту мы собрали распределённый монолит. Те же зависимости, что и в монолите, только теперь по сети — с таймаутами, ретраями и без общей транзакции. Оно работало, спорить не буду. Просто каждая вторая проблема в итоге упиралась в одно и то же: границы сервисов мы провели не там, где надо . Это не туториал «как правильно резать монолит на DDD-bounded-context за 10 шагов» — таких на Хабре хватает. Это разбор конкретных мест, где границы у нас поехали, в порядке от «это все знают, но всё равно наступают» до «поняли только в проде под нагрузкой». Если вы сейчас режете свой монолит — читайте как чеклист. Если уже прошли — сверьте, сколько совпало. Дисклеймер: проект под NDA. Названия сервисов, домен и детали обобщены и изменены, часть цифр округлена. Сами грабли и порядок, в котором мы на них наступали, — настоящие.
https://habr.com/ru/articles/1076092/
#микросервисы #монолит #декомпозиция_монолита #распределённый_монолит #границы_сервисов #bounded_context #DDD #Kafka #Circuit_Breaker
-
Распилили монолит на 6 сервисов — и случайно собрали распределённый монолит: где мы ошиблись с границами
Монолит документооборота, менеджмент говорит: «пора пилить на микросервисы». Мы нарезали шесть сервисов, сверху повесили API Gateway, Load Balancer и Circuit Breaker и какое-то время искренне считали, что теперь у нас взрослая распределённая система. По факту мы собрали распределённый монолит. Те же зависимости, что и в монолите, только теперь по сети — с таймаутами, ретраями и без общей транзакции. Оно работало, спорить не буду. Просто каждая вторая проблема в итоге упиралась в одно и то же: границы сервисов мы провели не там, где надо . Это не туториал «как правильно резать монолит на DDD-bounded-context за 10 шагов» — таких на Хабре хватает. Это разбор конкретных мест, где границы у нас поехали, в порядке от «это все знают, но всё равно наступают» до «поняли только в проде под нагрузкой». Если вы сейчас режете свой монолит — читайте как чеклист. Если уже прошли — сверьте, сколько совпало. Дисклеймер: проект под NDA. Названия сервисов, домен и детали обобщены и изменены, часть цифр округлена. Сами грабли и порядок, в котором мы на них наступали, — настоящие.
https://habr.com/ru/articles/1076092/
#микросервисы #монолит #декомпозиция_монолита #распределённый_монолит #границы_сервисов #bounded_context #DDD #Kafka #Circuit_Breaker
-
Как тестировать распределенные системы: тайм-ауты, дубликаты, Saga и частичные отказы
Распределенная система может сломаться так, что по отдельности все ее части будут выглядеть исправными. Представим обычную оплату заказа: сервис отправил запрос платежному провайдеру, тот списал деньги и вернул успешный ответ. На обратном пути соединение оборвалось. Для платежной системы операция завершена, а сервис заказа получил тайм-аут и не знает, произошло списание или нет. Самое очевидное решение — повторить запрос. И получить второе списание. В монолите подобные ситуации встречаются реже: операция обычно проходит внутри одного процесса или одной транзакции, поэтому место сбоя проще определить. В распределенной системе между началом и концом одной бизнес-операции могут быть несколько сервисов, брокер сообщений, разные базы данных и внешний API (интерфейс программирования приложений). У каждого компонента при этом свое состояние и свое представление о том, что уже произошло. Так, проверки «отправили запрос — получили ожидаемый ответ» здесь недостаточно. Интереснее проверить, что будет, если ответ задержится или потеряется, запрос придет повторно, события поменяются местами, а один из сервисов восстановится после нескольких минут простоя. В таких ситуациях проявляются ошибки, которые сложно увидеть на happy path (позитивном сценарии). Ниже разберем, как их воспроизводить и что проверять, чтобы отказ одного компонента не превращался в некорректное состояние всей системы. Почему распределенную систему нельзя тестировать как обычное приложение Возьмем простой пример — оплату заказа в интернет-магазине.
https://habr.com/ru/articles/1070068/
#распределенные_системы #тестирование #таймауты #идемпотентность #Saga #Circuit_Breaker #Fault_Injection #Chaos_Engineering #eventual_consistency #микросервисы
-
Как тестировать распределенные системы: тайм-ауты, дубликаты, Saga и частичные отказы
Распределенная система может сломаться так, что по отдельности все ее части будут выглядеть исправными. Представим обычную оплату заказа: сервис отправил запрос платежному провайдеру, тот списал деньги и вернул успешный ответ. На обратном пути соединение оборвалось. Для платежной системы операция завершена, а сервис заказа получил тайм-аут и не знает, произошло списание или нет. Самое очевидное решение — повторить запрос. И получить второе списание. В монолите подобные ситуации встречаются реже: операция обычно проходит внутри одного процесса или одной транзакции, поэтому место сбоя проще определить. В распределенной системе между началом и концом одной бизнес-операции могут быть несколько сервисов, брокер сообщений, разные базы данных и внешний API (интерфейс программирования приложений). У каждого компонента при этом свое состояние и свое представление о том, что уже произошло. Так, проверки «отправили запрос — получили ожидаемый ответ» здесь недостаточно. Интереснее проверить, что будет, если ответ задержится или потеряется, запрос придет повторно, события поменяются местами, а один из сервисов восстановится после нескольких минут простоя. В таких ситуациях проявляются ошибки, которые сложно увидеть на happy path (позитивном сценарии). Ниже разберем, как их воспроизводить и что проверять, чтобы отказ одного компонента не превращался в некорректное состояние всей системы. Почему распределенную систему нельзя тестировать как обычное приложение Возьмем простой пример — оплату заказа в интернет-магазине.
https://habr.com/ru/articles/1070068/
#распределенные_системы #тестирование #таймауты #идемпотентность #Saga #Circuit_Breaker #Fault_Injection #Chaos_Engineering #eventual_consistency #микросервисы
-
Как тестировать распределенные системы: тайм-ауты, дубликаты, Saga и частичные отказы
Распределенная система может сломаться так, что по отдельности все ее части будут выглядеть исправными. Представим обычную оплату заказа: сервис отправил запрос платежному провайдеру, тот списал деньги и вернул успешный ответ. На обратном пути соединение оборвалось. Для платежной системы операция завершена, а сервис заказа получил тайм-аут и не знает, произошло списание или нет. Самое очевидное решение — повторить запрос. И получить второе списание. В монолите подобные ситуации встречаются реже: операция обычно проходит внутри одного процесса или одной транзакции, поэтому место сбоя проще определить. В распределенной системе между началом и концом одной бизнес-операции могут быть несколько сервисов, брокер сообщений, разные базы данных и внешний API (интерфейс программирования приложений). У каждого компонента при этом свое состояние и свое представление о том, что уже произошло. Так, проверки «отправили запрос — получили ожидаемый ответ» здесь недостаточно. Интереснее проверить, что будет, если ответ задержится или потеряется, запрос придет повторно, события поменяются местами, а один из сервисов восстановится после нескольких минут простоя. В таких ситуациях проявляются ошибки, которые сложно увидеть на happy path (позитивном сценарии). Ниже разберем, как их воспроизводить и что проверять, чтобы отказ одного компонента не превращался в некорректное состояние всей системы. Почему распределенную систему нельзя тестировать как обычное приложение Возьмем простой пример — оплату заказа в интернет-магазине.
https://habr.com/ru/articles/1070068/
#распределенные_системы #тестирование #таймауты #идемпотентность #Saga #Circuit_Breaker #Fault_Injection #Chaos_Engineering #eventual_consistency #микросервисы
-
Написал расширение, которое качает статьи Хабра в Markdown — и не долбит сервер
В прошлых двух статьях я разбирал DNS-трафик домашней сети и анализировал 1233 публикации Хабра, чтобы понять, за что площадка даёт рейтинг. И там, и там был вопрос, который я обходил: чем, собственно, я выгрузил эту тысячу статей? Не руками копировал и не скриптом на Python, который на двухсотом запросе получил бы 429 и бан по IP. Я написал расширение для Chrome, которое сохраняет статьи Хабра в Markdown — по одной, пакетом или автоматически по расписанию, — и делает это достаточно вежливо, чтобы сервер не считал его атакой. Главная мысль статьи оказалась не про парсинг HTML, а про хорошие манеры к серверу. Наивный качатель на голом fetch пишется за пять минут и получает бан на десятой. Инструмент, которым можно пользоваться постоянно, отличается тремя вещами: — держит принудительный интервал между запросами (1.5 секунды, гарантированно); — слушает 429 и при перегрузке сервера замолкает на три минуты целиком (паттерн circuit breaker), а не долбит сквозь ограничение; — работает с открытыми статьями для личного архива, а не сливает базу. Внутри: разбор вежливого граббера с кодом, почему парсинг чужой вёрстки ломается на каждом редизайне и как от этого защищаться фолбэками, формат Markdown с YAML-метаданными (тот самый, что сделал возможным анализ тысячи статей) и правовая рамка — где граница между «сохранил для себя» и «спарсил». Расширение с открытым кодом под MIT, ставится из Chrome Web Store в один клик.
https://habr.com/ru/articles/1061856/
#Chrome_extension #расширение #Habr #парсинг #Markdown #rate_limiting #Manifest_V3 #выгрузка_статей #circuit_breaker #архив
-
Написал расширение, которое качает статьи Хабра в Markdown — и не долбит сервер
В прошлых двух статьях я разбирал DNS-трафик домашней сети и анализировал 1233 публикации Хабра, чтобы понять, за что площадка даёт рейтинг. И там, и там был вопрос, который я обходил: чем, собственно, я выгрузил эту тысячу статей? Не руками копировал и не скриптом на Python, который на двухсотом запросе получил бы 429 и бан по IP. Я написал расширение для Chrome, которое сохраняет статьи Хабра в Markdown — по одной, пакетом или автоматически по расписанию, — и делает это достаточно вежливо, чтобы сервер не считал его атакой. Главная мысль статьи оказалась не про парсинг HTML, а про хорошие манеры к серверу. Наивный качатель на голом fetch пишется за пять минут и получает бан на десятой. Инструмент, которым можно пользоваться постоянно, отличается тремя вещами: — держит принудительный интервал между запросами (1.5 секунды, гарантированно); — слушает 429 и при перегрузке сервера замолкает на три минуты целиком (паттерн circuit breaker), а не долбит сквозь ограничение; — работает с открытыми статьями для личного архива, а не сливает базу. Внутри: разбор вежливого граббера с кодом, почему парсинг чужой вёрстки ломается на каждом редизайне и как от этого защищаться фолбэками, формат Markdown с YAML-метаданными (тот самый, что сделал возможным анализ тысячи статей) и правовая рамка — где граница между «сохранил для себя» и «спарсил». Расширение с открытым кодом под MIT, ставится из Chrome Web Store в один клик.
https://habr.com/ru/articles/1061856/
#Chrome_extension #расширение #Habr #парсинг #Markdown #rate_limiting #Manifest_V3 #выгрузка_статей #circuit_breaker #архив
-
Написал расширение, которое качает статьи Хабра в Markdown — и не долбит сервер
В прошлых двух статьях я разбирал DNS-трафик домашней сети и анализировал 1233 публикации Хабра, чтобы понять, за что площадка даёт рейтинг. И там, и там был вопрос, который я обходил: чем, собственно, я выгрузил эту тысячу статей? Не руками копировал и не скриптом на Python, который на двухсотом запросе получил бы 429 и бан по IP. Я написал расширение для Chrome, которое сохраняет статьи Хабра в Markdown — по одной, пакетом или автоматически по расписанию, — и делает это достаточно вежливо, чтобы сервер не считал его атакой. Главная мысль статьи оказалась не про парсинг HTML, а про хорошие манеры к серверу. Наивный качатель на голом fetch пишется за пять минут и получает бан на десятой. Инструмент, которым можно пользоваться постоянно, отличается тремя вещами: — держит принудительный интервал между запросами (1.5 секунды, гарантированно); — слушает 429 и при перегрузке сервера замолкает на три минуты целиком (паттерн circuit breaker), а не долбит сквозь ограничение; — работает с открытыми статьями для личного архива, а не сливает базу. Внутри: разбор вежливого граббера с кодом, почему парсинг чужой вёрстки ломается на каждом редизайне и как от этого защищаться фолбэками, формат Markdown с YAML-метаданными (тот самый, что сделал возможным анализ тысячи статей) и правовая рамка — где граница между «сохранил для себя» и «спарсил». Расширение с открытым кодом под MIT, ставится из Chrome Web Store в один клик.
https://habr.com/ru/articles/1061856/
#Chrome_extension #расширение #Habr #парсинг #Markdown #rate_limiting #Manifest_V3 #выгрузка_статей #circuit_breaker #архив
-
[Перевод] 9 AI-агентов делят одну API-квоту. Почему обычные ретраи только ломают систему
Девять AI-агентов делят одну API-квоту — и один ответ 429 быстро превращается в каскадный отказ всей системы. В этой статье разбираемся, почему стандартные ретраи и jitter перестают работать при общей квоте, и показывает архитектуру Rate Governor: с приоритетами, общим пулом токенов, предиктивным Circuit Breaker и координацией между агентами. Изучить паттерны
https://habr.com/ru/companies/otus/articles/1044504/
#AIагенты #мультиагентные_системы #rate_limiting #ограничение_запросов #APIквоты #Circuit_Breaker #распределённые_системы #backpressure #Redis
-
[Перевод] 9 AI-агентов делят одну API-квоту. Почему обычные ретраи только ломают систему
Девять AI-агентов делят одну API-квоту — и один ответ 429 быстро превращается в каскадный отказ всей системы. В этой статье разбираемся, почему стандартные ретраи и jitter перестают работать при общей квоте, и показывает архитектуру Rate Governor: с приоритетами, общим пулом токенов, предиктивным Circuit Breaker и координацией между агентами. Изучить паттерны
https://habr.com/ru/companies/otus/articles/1044504/
#AIагенты #мультиагентные_системы #rate_limiting #ограничение_запросов #APIквоты #Circuit_Breaker #распределённые_системы #backpressure #Redis
-
[Перевод] 9 AI-агентов делят одну API-квоту. Почему обычные ретраи только ломают систему
Девять AI-агентов делят одну API-квоту — и один ответ 429 быстро превращается в каскадный отказ всей системы. В этой статье разбираемся, почему стандартные ретраи и jitter перестают работать при общей квоте, и показывает архитектуру Rate Governor: с приоритетами, общим пулом токенов, предиктивным Circuit Breaker и координацией между агентами. Изучить паттерны
https://habr.com/ru/companies/otus/articles/1044504/
#AIагенты #мультиагентные_системы #rate_limiting #ограничение_запросов #APIквоты #Circuit_Breaker #распределённые_системы #backpressure #Redis
-
Как я довёл расходы на LLM до нуля: почему на бесплатных тарифах параллелизм — враг
Это продолжение первой статьи про Briefka — там я описывал самого бота и базовую архитектуру каскада LLM-провайдеров. За прошедшие 4 месяца бот органически вырос с 59 до 84 пользователей, и именно на этом масштабе бесплатный каскад начал срываться на платного провайдера. Расскажу, почему так вышло и как я вернул расходы к нулю — с цифрами и кодом. Код ниже — реальные фрагменты из боевого Briefka, слегка сокращённые для читаемости: убраны логирование и сбор статистики.
https://habr.com/ru/articles/1044546/
#llm #ratelimit #asyncio #telegrambot #groq #deepseek #fallback #circuit_breaker
-
Как я довёл расходы на LLM до нуля: почему на бесплатных тарифах параллелизм — враг
Это продолжение первой статьи про Briefka — там я описывал самого бота и базовую архитектуру каскада LLM-провайдеров. За прошедшие 4 месяца бот органически вырос с 59 до 84 пользователей, и именно на этом масштабе бесплатный каскад начал срываться на платного провайдера. Расскажу, почему так вышло и как я вернул расходы к нулю — с цифрами и кодом. Код ниже — реальные фрагменты из боевого Briefka, слегка сокращённые для читаемости: убраны логирование и сбор статистики.
https://habr.com/ru/articles/1044546/
#llm #ratelimit #asyncio #telegrambot #groq #deepseek #fallback #circuit_breaker
-
Как я довёл расходы на LLM до нуля: почему на бесплатных тарифах параллелизм — враг
Это продолжение первой статьи про Briefka — там я описывал самого бота и базовую архитектуру каскада LLM-провайдеров. За прошедшие 4 месяца бот органически вырос с 59 до 84 пользователей, и именно на этом масштабе бесплатный каскад начал срываться на платного провайдера. Расскажу, почему так вышло и как я вернул расходы к нулю — с цифрами и кодом. Код ниже — реальные фрагменты из боевого Briefka, слегка сокращённые для читаемости: убраны логирование и сбор статистики.
https://habr.com/ru/articles/1044546/
#llm #ratelimit #asyncio #telegrambot #groq #deepseek #fallback #circuit_breaker
-
AI Gateway для микросервисов: гайд по интеграции LLM в 2026
В микросервисной архитектуре LLM быстро превращаются из удобного инструмента в отдельный источник рисков: растут счета за токены, появляются задержки, дублируются запросы, а сервисы начинают зависеть от внешних моделей напрямую. В статье разбираем, как спроектировать AI Gateway — инфраструктурный слой для централизованной маршрутизации, кеширования, лимитов, observability и отказоустойчивости при работе с AI‑моделями.
https://habr.com/ru/companies/otus/articles/1031276/
#java #AI_Gateway #LLM #Spring_Cloud_Gateway #semantic_cache #circuit_breaker #microservices_architecture #OpenAI_API
-
AI Gateway для микросервисов: гайд по интеграции LLM в 2026
В микросервисной архитектуре LLM быстро превращаются из удобного инструмента в отдельный источник рисков: растут счета за токены, появляются задержки, дублируются запросы, а сервисы начинают зависеть от внешних моделей напрямую. В статье разбираем, как спроектировать AI Gateway — инфраструктурный слой для централизованной маршрутизации, кеширования, лимитов, observability и отказоустойчивости при работе с AI‑моделями.
https://habr.com/ru/companies/otus/articles/1031276/
#java #AI_Gateway #LLM #Spring_Cloud_Gateway #semantic_cache #circuit_breaker #microservices_architecture #OpenAI_API
-
AI Gateway для микросервисов: гайд по интеграции LLM в 2026
В микросервисной архитектуре LLM быстро превращаются из удобного инструмента в отдельный источник рисков: растут счета за токены, появляются задержки, дублируются запросы, а сервисы начинают зависеть от внешних моделей напрямую. В статье разбираем, как спроектировать AI Gateway — инфраструктурный слой для централизованной маршрутизации, кеширования, лимитов, observability и отказоустойчивости при работе с AI‑моделями.
https://habr.com/ru/companies/otus/articles/1031276/
#java #AI_Gateway #LLM #Spring_Cloud_Gateway #semantic_cache #circuit_breaker #microservices_architecture #OpenAI_API
-
Circuit breaker на Go: пишем свой за 100 строк и разбираем, почему gobreaker работает иначе
Когда один зависимый сервис начинает отвечать медленнее, проблема быстро перестает быть локальной: горутины ждут, соединения заканчиваются, таймауты разъезжаются по всей цепочке. Circuit breaker помогает остановить этот каскад до того, как он положит соседние части системы. В статье разберем, как написать простой breaker на Go примерно за 100 строк, где у такой реализации границы применимости и почему production‑библиотека gobreaker устроена гибче.
https://habr.com/ru/companies/otus/articles/1029182/
#Circuit_breaker #Go #Golang #gobreaker #отказоустойчивость #таймауты #retry #микросервисы #downstreamсервисы #планировщик_Go
-
Circuit breaker на Go: пишем свой за 100 строк и разбираем, почему gobreaker работает иначе
Когда один зависимый сервис начинает отвечать медленнее, проблема быстро перестает быть локальной: горутины ждут, соединения заканчиваются, таймауты разъезжаются по всей цепочке. Circuit breaker помогает остановить этот каскад до того, как он положит соседние части системы. В статье разберем, как написать простой breaker на Go примерно за 100 строк, где у такой реализации границы применимости и почему production‑библиотека gobreaker устроена гибче.
https://habr.com/ru/companies/otus/articles/1029182/
#Circuit_breaker #Go #Golang #gobreaker #отказоустойчивость #таймауты #retry #микросервисы #downstreamсервисы #планировщик_Go
-
Circuit breaker на Go: пишем свой за 100 строк и разбираем, почему gobreaker работает иначе
Когда один зависимый сервис начинает отвечать медленнее, проблема быстро перестает быть локальной: горутины ждут, соединения заканчиваются, таймауты разъезжаются по всей цепочке. Circuit breaker помогает остановить этот каскад до того, как он положит соседние части системы. В статье разберем, как написать простой breaker на Go примерно за 100 строк, где у такой реализации границы применимости и почему production‑библиотека gobreaker устроена гибче.
https://habr.com/ru/companies/otus/articles/1029182/
#Circuit_breaker #Go #Golang #gobreaker #отказоустойчивость #таймауты #retry #микросервисы #downstreamсервисы #планировщик_Go
-
Circuit Breaker в микросервисах: как защитить систему от каскадных отказов
Представьте: сервис А звонит сервису Б, а тот зависает. Сервис А ждёт, занимает потоки, не освобождает ресурсы. Потом к нему приходит другой сервис — и тоже встаёт в очередь. Так один сбой разрастается по всей системе, как снежный ком. Этот эффект называется каскадным отказом. Паттерн Circuit Breaker (предохранитель) решает эту проблему. В статье разбираем его на примере ассистента HR с зонтиком, показываем, как настроить Resilience4j, и делимся, какие ошибки стоит (а какие не стоит) учитывать в статистике. Описание Паттерн Circuit Breaker (предохранитель) занимает важное место среди паттернов архитектуры приложений, особенно в микросервисных системах. В чем его суть . Представим сервис А , который обращается к сервису Б . Сервис Б по каким-то причинам начинает плохо себя вести: долго отвечать на запросы или отвечать ошибкой — например, потерял соединение с базой данных. Тогда начинает «страдать» сервис А: он вынужден долго ждать на каждом запросе, занимая ресурсы — свободные потоки, соединения с БД, удерживая транзакции открытыми. Проблема распространяется и умножается на всю систему. У сервиса А занимается всё больше потоков, которые ничего не делают, а просто ждут. Если будут заняты все потоки, сервис А станет полностью неработоспособен. Так проблема разрастается по цепочке — этот эффект называется каскадным отказом (cascading failure). Чтобы решить проблему, сервис А должен иметь защитный механизм, который определяет, что сервис Б сейчас в аварийном состоянии, и временно не обращаться к нему. Этот механизм и называется Circuit Breaker (предохранитель).
https://habr.com/ru/articles/1025394/
#circuit_breaker #микросервисы #отказоустойчивость #java #Архитектура
-
Circuit Breaker в микросервисах: как защитить систему от каскадных отказов
Представьте: сервис А звонит сервису Б, а тот зависает. Сервис А ждёт, занимает потоки, не освобождает ресурсы. Потом к нему приходит другой сервис — и тоже встаёт в очередь. Так один сбой разрастается по всей системе, как снежный ком. Этот эффект называется каскадным отказом. Паттерн Circuit Breaker (предохранитель) решает эту проблему. В статье разбираем его на примере ассистента HR с зонтиком, показываем, как настроить Resilience4j, и делимся, какие ошибки стоит (а какие не стоит) учитывать в статистике. Описание Паттерн Circuit Breaker (предохранитель) занимает важное место среди паттернов архитектуры приложений, особенно в микросервисных системах. В чем его суть . Представим сервис А , который обращается к сервису Б . Сервис Б по каким-то причинам начинает плохо себя вести: долго отвечать на запросы или отвечать ошибкой — например, потерял соединение с базой данных. Тогда начинает «страдать» сервис А: он вынужден долго ждать на каждом запросе, занимая ресурсы — свободные потоки, соединения с БД, удерживая транзакции открытыми. Проблема распространяется и умножается на всю систему. У сервиса А занимается всё больше потоков, которые ничего не делают, а просто ждут. Если будут заняты все потоки, сервис А станет полностью неработоспособен. Так проблема разрастается по цепочке — этот эффект называется каскадным отказом (cascading failure). Чтобы решить проблему, сервис А должен иметь защитный механизм, который определяет, что сервис Б сейчас в аварийном состоянии, и временно не обращаться к нему. Этот механизм и называется Circuit Breaker (предохранитель).
https://habr.com/ru/articles/1025394/
#circuit_breaker #микросервисы #отказоустойчивость #java #Архитектура
-
Circuit Breaker в микросервисах: как защитить систему от каскадных отказов
Представьте: сервис А звонит сервису Б, а тот зависает. Сервис А ждёт, занимает потоки, не освобождает ресурсы. Потом к нему приходит другой сервис — и тоже встаёт в очередь. Так один сбой разрастается по всей системе, как снежный ком. Этот эффект называется каскадным отказом. Паттерн Circuit Breaker (предохранитель) решает эту проблему. В статье разбираем его на примере ассистента HR с зонтиком, показываем, как настроить Resilience4j, и делимся, какие ошибки стоит (а какие не стоит) учитывать в статистике. Описание Паттерн Circuit Breaker (предохранитель) занимает важное место среди паттернов архитектуры приложений, особенно в микросервисных системах. В чем его суть . Представим сервис А , который обращается к сервису Б . Сервис Б по каким-то причинам начинает плохо себя вести: долго отвечать на запросы или отвечать ошибкой — например, потерял соединение с базой данных. Тогда начинает «страдать» сервис А: он вынужден долго ждать на каждом запросе, занимая ресурсы — свободные потоки, соединения с БД, удерживая транзакции открытыми. Проблема распространяется и умножается на всю систему. У сервиса А занимается всё больше потоков, которые ничего не делают, а просто ждут. Если будут заняты все потоки, сервис А станет полностью неработоспособен. Так проблема разрастается по цепочке — этот эффект называется каскадным отказом (cascading failure). Чтобы решить проблему, сервис А должен иметь защитный механизм, который определяет, что сервис Б сейчас в аварийном состоянии, и временно не обращаться к нему. Этот механизм и называется Circuit Breaker (предохранитель).
https://habr.com/ru/articles/1025394/
#circuit_breaker #микросервисы #отказоустойчивость #java #Архитектура
-
Что делать, когда AI-агент «упал»: архитектура отказоустойчивости
API OpenAI лёг — что делает ваш агент? Circuit Breaker, Graceful Degradation и 5 уровней деградации. Код на Python + чеклист вопросов подрядчику. Нырнём глубже
https://habr.com/ru/articles/1005576/
#AIагенты #отказоустойчивость #circuit_breaker #LLM #graceful_degradation #SLA
-
Что делать, когда AI-агент «упал»: архитектура отказоустойчивости
API OpenAI лёг — что делает ваш агент? Circuit Breaker, Graceful Degradation и 5 уровней деградации. Код на Python + чеклист вопросов подрядчику. Нырнём глубже
https://habr.com/ru/articles/1005576/
#AIагенты #отказоустойчивость #circuit_breaker #LLM #graceful_degradation #SLA
-
Что делать, когда AI-агент «упал»: архитектура отказоустойчивости
API OpenAI лёг — что делает ваш агент? Circuit Breaker, Graceful Degradation и 5 уровней деградации. Код на Python + чеклист вопросов подрядчику. Нырнём глубже
https://habr.com/ru/articles/1005576/
#AIагенты #отказоустойчивость #circuit_breaker #LLM #graceful_degradation #SLA
-
Я почувствовал себя клоуном, подключая 5 библиотек ради устойчивого API-клиента
Если ваш API-клиент выглядит как башня декораторов — вы уже в зоне инженерной боли. Рассказываю, как я из этого выбрался.
-
Я почувствовал себя клоуном, подключая 5 библиотек ради устойчивого API-клиента
Если ваш API-клиент выглядит как башня декораторов — вы уже в зоне инженерной боли. Рассказываю, как я из этого выбрался.
-
Я почувствовал себя клоуном, подключая 5 библиотек ради устойчивого API-клиента
Если ваш API-клиент выглядит как башня декораторов — вы уже в зоне инженерной боли. Рассказываю, как я из этого выбрался.
-
Griddle
Lucas was in the middle of cooking when the power went out. After checking the circuit breaker, Lucas realized he wouldn't be finishing his slab of former neighbor Harry any time soon.
Linda Vista Hospital, Los Angeles, California 2012
#Griddle #Hogwash_Book_Four #circuit_breaker #Linda_Vista_Hospital #Los_Angeles #California #Hogwash #Hog_Wash #photography
https://flic.kr/p/JhLzVK -
Griddle
Lucas was in the middle of cooking when the power went out. After checking the circuit breaker, Lucas realized he wouldn't be finishing his slab of former neighbor Harry any time soon.
Linda Vista Hospital, Los Angeles, California 2012
#Griddle #Hogwash_Book_Four #circuit_breaker #Linda_Vista_Hospital #Los_Angeles #California #Hogwash #Hog_Wash #photography
https://flic.kr/p/JhLzVK -
Griddle
Lucas was in the middle of cooking when the power went out. After checking the circuit breaker, Lucas realized he wouldn't be finishing his slab of former neighbor Harry any time soon.
Linda Vista Hospital, Los Angeles, California 2012
#Griddle #Hogwash_Book_Four #circuit_breaker #Linda_Vista_Hospital #Los_Angeles #California #Hogwash #Hog_Wash #photography
https://flic.kr/p/JhLzVK -
Griddle
Lucas was in the middle of cooking when the power went out. After checking the circuit breaker, Lucas realized he wouldn't be finishing his slab of former neighbor Harry any time soon.
Linda Vista Hospital, Los Angeles, California 2012
#Griddle #Hogwash_Book_Four #circuit_breaker #Linda_Vista_Hospital #Los_Angeles #California #Hogwash #Hog_Wash #photography
https://flic.kr/p/JhLzVK -
Circuit Breaker Policy Fine-tuning Best Practice
https://devblogs.microsoft.com/dotnet/circuit-breaker-policy-finetuning-best-practice/ -
Circuit Breaker Policy Fine-tuning Best Practice
https://devblogs.microsoft.com/dotnet/circuit-breaker-policy-finetuning-best-practice/ -
Наш архитектурный подход к Python приложениям
Мы долгие годы писали сервисы исходя из каких-то своих внутренних ощущений правильности их написания. Но синхронизироваться по хорошим практикам в разных командах бывает довольно сложно и часто хорошие практики не выходили за рамки одной команды, а такого хотелось бы избежать. Поэтому мы решили объединить все хорошие по нашему мнению практики в единый справочник. Этот справочник получил название «Архитектурный гайд». Про него и поговорим в данной статье.
https://habr.com/ru/companies/raiffeisenbank/articles/885792/
#архитектура #архитектура_приложений #python #fastapi #litestar #райффайзенбанк #лучшие_практики #pytest #circuit_breaker #stamina
-
Наш архитектурный подход к Python приложениям
Мы долгие годы писали сервисы исходя из каких-то своих внутренних ощущений правильности их написания. Но синхронизироваться по хорошим практикам в разных командах бывает довольно сложно и часто хорошие практики не выходили за рамки одной команды, а такого хотелось бы избежать. Поэтому мы решили объединить все хорошие по нашему мнению практики в единый справочник. Этот справочник получил название «Архитектурный гайд». Про него и поговорим в данной статье.
https://habr.com/ru/companies/raiffeisenbank/articles/885792/
#архитектура #архитектура_приложений #python #fastapi #litestar #райффайзенбанк #лучшие_практики #pytest #circuit_breaker #stamina
-
Наш архитектурный подход к Python приложениям
Мы долгие годы писали сервисы исходя из каких-то своих внутренних ощущений правильности их написания. Но синхронизироваться по хорошим практикам в разных командах бывает довольно сложно и часто хорошие практики не выходили за рамки одной команды, а такого хотелось бы избежать. Поэтому мы решили объединить все хорошие по нашему мнению практики в единый справочник. Этот справочник получил название «Архитектурный гайд». Про него и поговорим в данной статье.
https://habr.com/ru/companies/raiffeisenbank/articles/885792/
#архитектура #архитектура_приложений #python #fastapi #litestar #райффайзенбанк #лучшие_практики #pytest #circuit_breaker #stamina
-
Использование resilience4j со Spring Boot
resilience4j библиотека, предоставляющая набор инструментов для повышения надежности и отказоустойчивости java приложений прежде всего в микросервисной архитектуре Рассмотрим какие в ней есть инструменты, как их использовать в Spring Boot приложении с помощью аннотаций, как настраивать и есть ли в них подводные камни
https://habr.com/ru/articles/793550/
#resilience4j #отказоустойчивость #java #spring_boot #spring_framework #circuit_breaker #rate_limiter #retry #webflux #hystrix
-
Использование resilience4j со Spring Boot
resilience4j библиотека, предоставляющая набор инструментов для повышения надежности и отказоустойчивости java приложений прежде всего в микросервисной архитектуре Рассмотрим какие в ней есть инструменты, как их использовать в Spring Boot приложении с помощью аннотаций, как настраивать и есть ли в них подводные камни
https://habr.com/ru/articles/793550/
#resilience4j #отказоустойчивость #java #spring_boot #spring_framework #circuit_breaker #rate_limiter #retry #webflux #hystrix
-
Паттерн Circuit Breaker
Привет, Хабр! Каждая секунда простоя может стоить компании целое состояние, важно иметь надежные механизмы защиты от сбоев. Здесь и приходит на помощь паттерн Circuit Breaker. Представьте себе обычный автоматический выключатель в вашем доме. Когда происходит перегрузка, он "выбивается", предотвращая возможные повреждения. Точно так же работает и Circuit Breaker в микросервисах. Он мониторит вызовы к внешнему сервису и при обнаружении слишком большого количества неудачных попыток временно "отключает" вызов, предотвращая тем самым падение всей системы. Этот паттерн основывается на трех основных состояниях: закрытое , открытое и полуоткрытое .
-
Паттерн Circuit Breaker
Привет, Хабр! Каждая секунда простоя может стоить компании целое состояние, важно иметь надежные механизмы защиты от сбоев. Здесь и приходит на помощь паттерн Circuit Breaker. Представьте себе обычный автоматический выключатель в вашем доме. Когда происходит перегрузка, он "выбивается", предотвращая возможные повреждения. Точно так же работает и Circuit Breaker в микросервисах. Он мониторит вызовы к внешнему сервису и при обнаружении слишком большого количества неудачных попыток временно "отключает" вызов, предотвращая тем самым падение всей системы. Этот паттерн основывается на трех основных состояниях: закрытое , открытое и полуоткрытое .