Вот список постов Стивена Тауба про улучшения производительности в разных версиях .NET. Удобно держать под рукой:
Надеюсь, завезет и про dotnet 10👍
👉 @KodBlog
.NET 9
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-9/
.NET 8
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-8/
.NET 7
https://devblogs.microsoft.com/dotnet/performance_improvements_in_net_7/
.NET 6
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-6/
.NET 5
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-5/
.NET 3.0
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-core-3-0/
.NET 2.1
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-core-2-1/
.NET 2.0
https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-core/
Надеюсь, завезет и про dotnet 10
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10❤2
This media is not supported in your browser
VIEW IN TELEGRAM
Как кеш может работать неправильно?
Есть несколько типичных ситуаций. Проблема стадного эффекта возникает, когда одновременно истекает много ключей. Все запросы начинают идти прямо в базу, и она перегружается.
Это решается добавлением случайного времени к сроку жизни ключей или ограничением доступа к базе только для критичных данных, пока кеш не восстановится.
Пробой кеша случается, когда ключа нет ни в кеше, ни в базе. Приложение не может обновить кеш и создаёт лишнюю нагрузку. В этом случае помогает кеширование null для несуществующих ключей или проверка ключа через bloom filter, чтобы лишний раз не обращаться к базе.
Есть и пробой по «горячему» ключу. Когда один популярный ключ истекает, вся нагрузка уходит в базу. Поскольку такие ключи могут составлять большую часть запросов, для них обычно не задают время жизни.
Кеш может и просто упасть. Тогда все запросы идут в базу, и система перестаёт справляться. Здесь выход либо в использовании circuit breaker, который блокирует обращения и к кешу, и к базе, либо в развёртывании кластера кеша, чтобы повысить его доступность.
А вы встречали такие ситуации в продакшене?😱
👉 @KodBlog
Есть несколько типичных ситуаций. Проблема стадного эффекта возникает, когда одновременно истекает много ключей. Все запросы начинают идти прямо в базу, и она перегружается.
Это решается добавлением случайного времени к сроку жизни ключей или ограничением доступа к базе только для критичных данных, пока кеш не восстановится.
Пробой кеша случается, когда ключа нет ни в кеше, ни в базе. Приложение не может обновить кеш и создаёт лишнюю нагрузку. В этом случае помогает кеширование null для несуществующих ключей или проверка ключа через bloom filter, чтобы лишний раз не обращаться к базе.
Есть и пробой по «горячему» ключу. Когда один популярный ключ истекает, вся нагрузка уходит в базу. Поскольку такие ключи могут составлять большую часть запросов, для них обычно не задают время жизни.
Кеш может и просто упасть. Тогда все запросы идут в базу, и система перестаёт справляться. Здесь выход либо в использовании circuit breaker, который блокирует обращения и к кешу, и к базе, либо в развёртывании кластера кеша, чтобы повысить его доступность.
А вы встречали такие ситуации в продакшене?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5❤2
В .NET 9 может быть самая удобная платформа для микросервисов и вот почему.
Обычно команды тратят недели, чтобы собрать в кучу отказоустойчивость, наблюдаемость, сервис-дискавери и API-шлюзы.
В .NET 9 всё это уже есть из коробки.
- Resilience
Встроенные ретраи, таймауты и circuit breakers, без сторонних библиотек.
- Observability
Поддержка OpenTelemetry из коробки. Трассировки, метрики и логи без лишних усилий.
- .NET Aspire
Cloud-native стек для быстрых распределённых систем.
- Service Discovery
Можно использовать логические имена сервисов вместо жёстко прописанных URL. В рантайме они резолвятся через конфиг.
- API Gateway
YARP — лёгкий reverse proxy, который работает и как API-шлюз, с минимальной настройкой.
Если вы строите микросервисы на .NET, больше не нужно собирать инфраструктуру вручную.
Подробности: ссылка
А как вы строите микросервисы?👍
👉 @KodBlog
Обычно команды тратят недели, чтобы собрать в кучу отказоустойчивость, наблюдаемость, сервис-дискавери и API-шлюзы.
В .NET 9 всё это уже есть из коробки.
- Resilience
Встроенные ретраи, таймауты и circuit breakers, без сторонних библиотек.
- Observability
Поддержка OpenTelemetry из коробки. Трассировки, метрики и логи без лишних усилий.
- .NET Aspire
Cloud-native стек для быстрых распределённых систем.
- Service Discovery
Можно использовать логические имена сервисов вместо жёстко прописанных URL. В рантайме они резолвятся через конфиг.
- API Gateway
YARP — лёгкий reverse proxy, который работает и как API-шлюз, с минимальной настройкой.
Если вы строите микросервисы на .NET, больше не нужно собирать инфраструктуру вручную.
Подробности: ссылка
А как вы строите микросервисы?
Please open Telegram to view this post
VIEW IN TELEGRAM
❤14👍4
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5🔥1
Как включить DATAS в .NET 8
Dynamic adaptation to application sizes (DATAS) по умолчанию включен в dotnet 9, и многие приложения благодаря этому заметно сократили потребление памяти.
В .NET 8 можно включить его через настройку выше.
Не забудь прогнать бенчмарки своего сценария до и после.
https://learn.microsoft.com/en-us/dotnet/standard/garbage-collection/datas
👉 @KodBlog
Dynamic adaptation to application sizes (DATAS) по умолчанию включен в dotnet 9, и многие приложения благодаря этому заметно сократили потребление памяти.
В .NET 8 можно включить его через настройку выше.
Не забудь прогнать бенчмарки своего сценария до и после.
https://learn.microsoft.com/en-us/dotnet/standard/garbage-collection/datas
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9🔥2
Redis полезен не только для кэширования.
С его помощью можно реализовать базовый Pub/Sub механизм.
Если ты когда-нибудь писал распределенные системы или микросервисы в dotnet, наверняка сталкивался с проблемой синхронизации сервисов.
Нужно как-то уведомлять другие сервисы о событиях, сбрасывать кэш или слать обновления на дашборд в реальном времени, а значит без механизма обмена сообщениями не обойтись.
RabbitMQ и Kafka отлично подходят для сложных сценариев, но иногда достаточно чего-то простого, быстрого и уже встроенного в стек. Здесь пригодится Redis Pub/Sub.
Эта встроенная возможность Redis позволяет сервисам отправлять и получать сообщения через именованные каналы. Publisher пишет сообщение в канал, а Subscriber слушает его и сразу обрабатывает входящие данные.
Работает это быстро, не требует хранения сообщений и практически не нагружает систему. Хорошо подходит для задач в реальном времени, где потеря пары сообщений не критична.
Например, для обновления интерфейсов в реальном времени, для инвалидации кэша между сервисами или для передачи сигналов между приложениями.
Пример реализации: https://thecodeman.net/posts/messaging-in-dotnet-with-redis✏️
👉 @KodBlog
С его помощью можно реализовать базовый Pub/Sub механизм.
Если ты когда-нибудь писал распределенные системы или микросервисы в dotnet, наверняка сталкивался с проблемой синхронизации сервисов.
Нужно как-то уведомлять другие сервисы о событиях, сбрасывать кэш или слать обновления на дашборд в реальном времени, а значит без механизма обмена сообщениями не обойтись.
RabbitMQ и Kafka отлично подходят для сложных сценариев, но иногда достаточно чего-то простого, быстрого и уже встроенного в стек. Здесь пригодится Redis Pub/Sub.
Эта встроенная возможность Redis позволяет сервисам отправлять и получать сообщения через именованные каналы. Publisher пишет сообщение в канал, а Subscriber слушает его и сразу обрабатывает входящие данные.
Работает это быстро, не требует хранения сообщений и практически не нагружает систему. Хорошо подходит для задач в реальном времени, где потеря пары сообщений не критична.
Например, для обновления интерфейсов в реальном времени, для инвалидации кэша между сервисами или для передачи сигналов между приложениями.
Пример реализации: https://thecodeman.net/posts/messaging-in-dotnet-with-redis
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤3
Для дотнетчиков подъехала полезная штука
Каждый год выходит новая версия C#, и уже давно стало трудно уследить за всеми фичами. Одни реально экономят время, другие просто красивые игрушки.💃
Чтобы не тонуть в апдейтах, появился чеклист Stay Sharp. В нём собрали 23 самых толковых фичи из C# 9–13. Для каждой есть короткое объяснение, кусок кода и пример вывода в консоли.
Чеклист можно забрать бесплатно (может потребоваться ВПН)
Отличный способ быстро апнуть скилл и не пропускать реально полезные возможности языка
👉 @KodBlog
Каждый год выходит новая версия C#, и уже давно стало трудно уследить за всеми фичами. Одни реально экономят время, другие просто красивые игрушки.
Чтобы не тонуть в апдейтах, появился чеклист Stay Sharp. В нём собрали 23 самых толковых фичи из C# 9–13. Для каждой есть короткое объяснение, кусок кода и пример вывода в консоли.
Чеклист можно забрать бесплатно (может потребоваться ВПН)
Отличный способ быстро апнуть скилл и не пропускать реально полезные возможности языка
Please open Telegram to view this post
VIEW IN TELEGRAM
❤12👍4😁1
Малоизвестная фича в C# —
Она позволяет давать новое имя уже существующему типу.
Мы использовали её в крупном проекте по модернизации, где было море конфликтов типов, и это реально спасло.
Причём alias работает даже с кортежами.
Кто-нибудь ещё применял это в продакшене?🤝
👉 @KodBlog
type aliasОна позволяет давать новое имя уже существующему типу.
Мы использовали её в крупном проекте по модернизации, где было море конфликтов типов, и это реально спасло.
Причём alias работает даже с кортежами.
Кто-нибудь ещё применял это в продакшене?
Please open Telegram to view this post
VIEW IN TELEGRAM
❤16👍6😁2👎1
Младший разработчик подключает EF Core прямо в контроллере.
Миддл делает схему
Сеньор использует Clean Architecture.
Архитектор снова возвращает EF Core в контроллер.
Почему так?☕️
Потому что в реальных проектах выигрывают простые решения.
Слои стоит добавлять только тогда, когда они действительно нужны.
Небольшое приложение спокойно живет с EF Core прямо в контроллерах или минимальных API эндпоинтах.
Проект среднего размера может выиграть от слоя приложений, например сервисов или хендлеров.
Большая система уже требует вертикальных срезов, Clean Architecture или даже DDD.
Главный урок в том, что не нужно перегружать архитектуру заранее. Строй по шагам.
Если понадобится больше сложности, можно добавить.
Если нет, оставляй всё простым и двигайся дальше.
Всегда есть возможность отрефакторить или расширить потом.
Фокусируйся на том, чтобы приносить пользу, а не плодить слои.
P.S. EF Core уже реализует паттерны Repository и Unit of Work, поэтому в большинстве случаев писать свои репозитории нет необходимости.
👉 @KodBlog
Миддл делает схему
Контроллер - Сервис - Репозиторий.Сеньор использует Clean Architecture.
Архитектор снова возвращает EF Core в контроллер.
Почему так?
Потому что в реальных проектах выигрывают простые решения.
Слои стоит добавлять только тогда, когда они действительно нужны.
Небольшое приложение спокойно живет с EF Core прямо в контроллерах или минимальных API эндпоинтах.
Проект среднего размера может выиграть от слоя приложений, например сервисов или хендлеров.
Большая система уже требует вертикальных срезов, Clean Architecture или даже DDD.
Главный урок в том, что не нужно перегружать архитектуру заранее. Строй по шагам.
Если понадобится больше сложности, можно добавить.
Если нет, оставляй всё простым и двигайся дальше.
Всегда есть возможность отрефакторить или расширить потом.
Фокусируйся на том, чтобы приносить пользу, а не плодить слои.
P.S. EF Core уже реализует паттерны Repository и Unit of Work, поэтому в большинстве случаев писать свои репозитории нет необходимости.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥18❤5😐4🤔1
Вышел экспресс курс по Keycloak 🎉
Keycloak это бесплатный сервер аутентификации который сразу даёт безопасные логины, управление паролями и JWT. Теперь не нужно тратить время на авторизацию с нуля и можно сосредоточиться на разработке приложения.
Всего за 45 минут показывают как поднять Keycloak в Docker, подключить и защитить .NET API, настроить OAuth 2.0 Authorization Code Flow, управлять пользователями, генерировать JWT и закрыть эндпоинты для неавторизованных запросов.
Полный курс тут
👉 @KodBlog
Keycloak это бесплатный сервер аутентификации который сразу даёт безопасные логины, управление паролями и JWT. Теперь не нужно тратить время на авторизацию с нуля и можно сосредоточиться на разработке приложения.
Всего за 45 минут показывают как поднять Keycloak в Docker, подключить и защитить .NET API, настроить OAuth 2.0 Authorization Code Flow, управлять пользователями, генерировать JWT и закрыть эндпоинты для неавторизованных запросов.
Полный курс тут
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13❤🔥4
Мало кто из разработчиков знает про Dynamic Authorization в
В
Это когда доступ к ресурсу зависит не только от роли пользователя, но и от его атрибутов, самого ресурса и окружения.
Примеры: автор может редактировать только свои книги, а региональный менеджер управляет данными только в своём регионе.
Реализуется это через Attribute-Based Authorization с
Подход полезен там, где нужно гибкое и контекстное управление правами.😊
Подробнее про best practices в
👉 @KodBlog
ASP.NET CoreВ
ASP.NET Core, помимо Role-Based и Claims-Based подходов, можно использовать Dynamic AuthorizationЭто когда доступ к ресурсу зависит не только от роли пользователя, но и от его атрибутов, самого ресурса и окружения.
Примеры: автор может редактировать только свои книги, а региональный менеджер управляет данными только в своём регионе.
Реализуется это через Attribute-Based Authorization с
IAuthorizationRequirement и AuthorizationHandler.Подход полезен там, где нужно гибкое и контекстное управление правами.
Подробнее про best practices в
ASP.NET Core читай тутPlease open Telegram to view this post
VIEW IN TELEGRAM
👍15🔥5❤3
Есть тема, о которой многие разработчики слышали вскользь, но глубоко не погружались, это рефлексия. Рефлексия это способность языка программирования «смотреть на себя», получать информацию о собственных структурах во время выполнения.
Она полезна для динамических валидаций, метапрограммирования и лежит в основе работы ORM, которые строят запросы и мапят объекты, опираясь на знания о типах и структурах.
Пример 1
Класс Beer имеет три свойства: Name, Brewery, Alcohol. Через рефлексию мы получаем их список и типы.
Вывод в консоль:
Во втором примере в класс добавили новое свойство Brand. Код не изменился, но при запуске список свойств автоматически расширился, и на консоли появился ещё один элемент:
Вывод в консоль:
👉 @KodBlog
Она полезна для динамических валидаций, метапрограммирования и лежит в основе работы ORM, которые строят запросы и мапят объекты, опираясь на знания о типах и структурах.
Пример 1
Класс Beer имеет три свойства: Name, Brewery, Alcohol. Через рефлексию мы получаем их список и типы.
// Смотрим тип объекта
Type type = typeof(Beer);
Console.WriteLine($"Тип: {type}");
// Свойства и их типы
Console.WriteLine("Свойства и типы:");
foreach (var prop in type.GetProperties())
{
Console.WriteLine($"{prop.Name} ({prop.PropertyType})");
}
// Класс для хранения пива
class Beer
{
public string Name { get; set; } = string.Empty;
public string Brewery { get; set; } = string.Empty;
public double Alcohol { get; set; }
}
Вывод в консоль:
Тип: Beer
Свойства и типы:
Name (System.String)
Brewery (System.String)
Alcohol (System.Double)
Во втором примере в класс добавили новое свойство Brand. Код не изменился, но при запуске список свойств автоматически расширился, и на консоли появился ещё один элемент:
// Смотрим тип объекта
Type type = typeof(Beer);
Console.WriteLine($"Тип: {type}");
// Свойства и их типы
Console.WriteLine("Свойства и типы:");
foreach (var prop in type.GetProperties())
{
Console.WriteLine($"{prop.Name} ({prop.PropertyType})");
}
// Класс для хранения пива
class Beer
{
public string Name { get; set; } = string.Empty;
public string Brewery { get; set; } = string.Empty;
public double Alcohol { get; set; }
// Новое свойство
public string Brand { get; set; } = string.Empty;
}
Вывод в консоль:
Тип: Beer
Свойства и типы:
Name (System.String)
Brewery (System.String)
Alcohol (System.Double)
Brand (System.String)
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8❤3🔥2
Большинство сеньоров советуют создавать репозитории для EF Core.
Но это не лучший способ писать код.
По мере роста .NET-проекта работа с данными становится все сложнее.
Многие команды начинают с паттерна Repository, оборачивая в него запросы EF Core.
Сначала всё ок. Но со временем ваши репозитории либо делают слишком мало, либо пытаются делать слишком много.
Код становится труднее понимать и менять по мере того, как меняются бизнес-требования.
Каждый раз, когда нужен новый фильтр или запрос, вы добавляете ещё один метод или даже новый репозиторий.
Помните, что DbContext в EF Core уже реализует паттерны Repository и Unit of Work.
Это прямо указано в официальной документации Microsoft по DbContext. Это же видно в summary DbContext в IDE.
Создавая репозиторий поверх EF Core, мы получаем абстракцию поверх абстракции. И часто приходим к переусложнённым решениям.
Как решить проблему? Ответ: паттерн Specification.😞
Паттерн Specification позволяет описывать, какие данные нужны из базы, с помощью небольших переиспользуемых классов — «спецификаций».
Каждая спецификация это правило или фильтр, который можно применить к запросу. Так можно собирать сложные запросы из простых и понятных блоков.
Полный разбор тут :
→ почему репозитории становятся узким местом в реальных проектах
→ что такое паттерн Specification
→ как внедрять спецификации в EF Core
→ продвинутые приёмы спецификаций
👉 @KodBlog
Но это не лучший способ писать код.
По мере роста .NET-проекта работа с данными становится все сложнее.
Многие команды начинают с паттерна Repository, оборачивая в него запросы EF Core.
Сначала всё ок. Но со временем ваши репозитории либо делают слишком мало, либо пытаются делать слишком много.
Код становится труднее понимать и менять по мере того, как меняются бизнес-требования.
Каждый раз, когда нужен новый фильтр или запрос, вы добавляете ещё один метод или даже новый репозиторий.
Помните, что DbContext в EF Core уже реализует паттерны Repository и Unit of Work.
Это прямо указано в официальной документации Microsoft по DbContext. Это же видно в summary DbContext в IDE.
Создавая репозиторий поверх EF Core, мы получаем абстракцию поверх абстракции. И часто приходим к переусложнённым решениям.
Как решить проблему? Ответ: паттерн Specification.
Паттерн Specification позволяет описывать, какие данные нужны из базы, с помощью небольших переиспользуемых классов — «спецификаций».
Каждая спецификация это правило или фильтр, который можно применить к запросу. Так можно собирать сложные запросы из простых и понятных блоков.
Полный разбор тут :
→ почему репозитории становятся узким местом в реальных проектах
→ что такое паттерн Specification
→ как внедрять спецификации в EF Core
→ продвинутые приёмы спецификаций
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9❤5👎2
Паттерн CQRS часто кажется сложным, но на деле он строится вокруг простых принципов.
Разработчики рекомендуют организовывать код вокруг use case'ов, которые отражают конкретный функционал приложения, например получить данные пользователя, добавить товар в корзину или оформить возврат.
То есть можно думать о use case как о бизнес-возможности.
Для реализации часто используют библиотеку MediatR, хотя после перехода проекта на платную модель многие задумываются о собственных решениях или остаются на бесплатной версии.
Подробнее о подходе CQRS можно почитать в блоге Милана Йовановича💯
👉 @KodBlog
Разработчики рекомендуют организовывать код вокруг use case'ов, которые отражают конкретный функционал приложения, например получить данные пользователя, добавить товар в корзину или оформить возврат.
То есть можно думать о use case как о бизнес-возможности.
Я строю код вокруг одного конкретного use case.
Есть два типа use case'ов:
Commands → бизнес-логика, работа с базой, побочные эффекты
Queries → возвращают данные в нужном виде для UI
Для реализации часто используют библиотеку MediatR, хотя после перехода проекта на платную модель многие задумываются о собственных решениях или остаются на бесплатной версии.
Подробнее о подходе CQRS можно почитать в блоге Милана Йовановича
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6😁2
Вместо того чтобы:
→ городить здоровенный метод с 5+ параметрами
→ и постоянно добавлять туда новые параметры
Сделай так:
1. Создай новый класс.
2. Свойства класса — это те же самые параметры метода.
3. Замени параметры метода на новый класс.
4. Поправь вызовы метода.
Этот рефакторинг называется Introduce Parameter Object.
И он быстро улучшит поддерживаемость кода.🤝
👉 @KodBlog
→ городить здоровенный метод с 5+ параметрами
→ и постоянно добавлять туда новые параметры
Сделай так:
1. Создай новый класс.
2. Свойства класса — это те же самые параметры метода.
3. Замени параметры метода на новый класс.
4. Поправь вызовы метода.
Этот рефакторинг называется Introduce Parameter Object.
И он быстро улучшит поддерживаемость кода.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍17😁5❤3🤯3
Есть десктопное приложение под Mac, Windows и Linux, которое обучает работе с Git через практику. Никаких лекций, только реальные задания в Git и GitHub. Репозитории создаются прямо в вашем аккаунте, результат сохраняется навсегда. Плюс доступна поддержка разных языков.
Ссылка: https://github.com/jlord/git-it-electron
👉 @KodBlog
Ссылка: https://github.com/jlord/git-it-electron
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10🔥3
Как писать условные и при этом читаемые запросы?
Всё что нужно, это выражение CASE.
Оно работает так же, как if else if else в C#. Как только условие срабатывает, чтение останавливается и возвращается результат, если ни одно условие не выполнилось, возвращается значение из ветки ELSE.
Главный плюс CASE в том, что уменьшается количество обращений к данным в базе, не нужно писать несколько разных запросов с разными условиями, достаточно одного CASE и одного запроса, чтобы получить нужные значения.
Кроме того, CASE полезен, если у вас несколько ORDER BY для многоуровневой сортировки.
Но есть важный момент, который я сам однажды понял на практике, использовать CASE лучше в SELECT, а не в WHERE.
Почему? потому что WHERE почти всегда работает быстрее для фильтрации строк.
👉 @KodBlog
Всё что нужно, это выражение CASE.
Оно работает так же, как if else if else в C#. Как только условие срабатывает, чтение останавливается и возвращается результат, если ни одно условие не выполнилось, возвращается значение из ветки ELSE.
Главный плюс CASE в том, что уменьшается количество обращений к данным в базе, не нужно писать несколько разных запросов с разными условиями, достаточно одного CASE и одного запроса, чтобы получить нужные значения.
Кроме того, CASE полезен, если у вас несколько ORDER BY для многоуровневой сортировки.
Но есть важный момент, который я сам однажды понял на практике, использовать CASE лучше в SELECT, а не в WHERE.
Почему? потому что WHERE почти всегда работает быстрее для фильтрации строк.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7❤4🔥2
Please open Telegram to view this post
VIEW IN TELEGRAM
❤13😁12🌚3🏆3🔥1
9 паттернов, которые делают приложения реально живучими
В мире распределённых систем падения неизбежны. Вопрос не если, а когда. Но есть проверенные подходы, которые позволяют системе вставать после каждого сбоя.
→ 1. Circuit Breaker
• Работает как электрический предохранитель
• При постоянных сбоях сервис временно отключается от потока запросов
• Даёт возможность восстановиться без перегрузки
• Состояния: Closed — запросы проходят, Open — запросы сразу отваливаются
• Защищает от каскадных фейлов и изолирует проблемные сервисы
→ 2. Retry
• При падении запроса система повторяет его несколько раз
• Помогает при временных проблемах: сетевые глюки, недоступность сервиса
• Повышает доступность и сглаживает сбои
• Важно: избегать retry storm, использовать exponential backoff
→ 3. Timeout
• Ограничивает максимальное время выполнения запроса
• Если ответ не пришёл вовремя, считаем его неудачным
→ 4. Bulkhead
• Делит приложение на изолированные "отсеки" или пулы
• Сбой в одном отсеке не валит всё приложение
→ 5. Rate Limiting
• Контролирует поток входящих запросов
• Защита от перегрузки и DDoS
• Поддерживает стабильность и справедливое использование
→ 6. Fallback
• Возвращает запасной ответ или действие при сбое основного
• Улучшает доступность и UX, лучше частичный сервис, чем ошибка
→ 7. Hedging (Redundancy)
• Отправляет дублирующие запросы в несколько сервисов
• Использует самый быстрый ответ
• Уменьшает влияние медленных откликов и падений
→ 8. Load Shedding
• Отбрасывает второстепенные запросы при перегрузке
• Сохраняет работу ключевых функций
• Держит систему живой в пиковые моменты
→ 9. Backpressure
• Обратная связь между продюсером и консъюмером
• Консъюмер сообщает о своей нагрузке, продюсер регулирует скорость
Стратегии:
• Reactive Pull — консъюмер тянет данные сам
• Rate Limiting — продюсер ограничивает скорость по фидбеку
• Buffering — данные временно хранятся в буфере
👉 @KodBlog
В мире распределённых систем падения неизбежны. Вопрос не если, а когда. Но есть проверенные подходы, которые позволяют системе вставать после каждого сбоя.
→ 1. Circuit Breaker
• Работает как электрический предохранитель
• При постоянных сбоях сервис временно отключается от потока запросов
• Даёт возможность восстановиться без перегрузки
• Состояния: Closed — запросы проходят, Open — запросы сразу отваливаются
• Защищает от каскадных фейлов и изолирует проблемные сервисы
→ 2. Retry
• При падении запроса система повторяет его несколько раз
• Помогает при временных проблемах: сетевые глюки, недоступность сервиса
• Повышает доступность и сглаживает сбои
• Важно: избегать retry storm, использовать exponential backoff
→ 3. Timeout
• Ограничивает максимальное время выполнения запроса
• Если ответ не пришёл вовремя, считаем его неудачным
→ 4. Bulkhead
• Делит приложение на изолированные "отсеки" или пулы
• Сбой в одном отсеке не валит всё приложение
→ 5. Rate Limiting
• Контролирует поток входящих запросов
• Защита от перегрузки и DDoS
• Поддерживает стабильность и справедливое использование
→ 6. Fallback
• Возвращает запасной ответ или действие при сбое основного
• Улучшает доступность и UX, лучше частичный сервис, чем ошибка
→ 7. Hedging (Redundancy)
• Отправляет дублирующие запросы в несколько сервисов
• Использует самый быстрый ответ
• Уменьшает влияние медленных откликов и падений
→ 8. Load Shedding
• Отбрасывает второстепенные запросы при перегрузке
• Сохраняет работу ключевых функций
• Держит систему живой в пиковые моменты
→ 9. Backpressure
• Обратная связь между продюсером и консъюмером
• Консъюмер сообщает о своей нагрузке, продюсер регулирует скорость
Стратегии:
• Reactive Pull — консъюмер тянет данные сам
• Rate Limiting — продюсер ограничивает скорость по фидбеку
• Buffering — данные временно хранятся в буфере
Please open Telegram to view this post
VIEW IN TELEGRAM
❤13👍5🔥2