Не все стратегии балансировки нагрузки одинаково полезны.

Если ты используешь YARP (Yet Another Reverse Proxy) в .NET - у него есть 5 встроенных способов распределять трафик между серверами. Но какой выбрать?

Вот понятный разбор:

1) RoundRobin (по кругу)
Классика: запросы равномерно идут по очереди на каждый сервер.
✅ просто
❌ плохо работает, если сервера/запросы не одинаковые по скорости

2) LeastRequests (минимум активных запросов)
Самый “умный” вариант: отправляет запрос туда, где сейчас меньше всего работы.
✅ отлично при разном времени обработки запросов
✅ помогает снизить задержки на “хвосте” (tail latency)

3) Random (случайно)
Сервер выбирается случайно.
✅ неожиданно хорошо работает при большом потоке однотипных запросов
❌ может иногда “не повезти” и нагрузить один сервер сильнее

4) PowerOfTwoChoices (2 случайных - выбираем лучший)
Баланс между качеством и стоимостью: берём 2 случайных сервера и выбираем тот, где меньше активных запросов.
✅ почти как LeastRequests, но дешевле по логике
✅ не надо проверять все сервера каждый раз

5) FirstAlphabetical (первый доступный)
Всегда выбирает “первый” сервер из списка (условно самый верхний/раньше по имени).
✅ хорошо для failover (есть основной сервер, остальные - запасные)
❌ плохо распределяет нагрузку (по сути почти без балансировки)

Большинство по привычке ставят RoundRobin, но если время обработки запросов разное - переход на LeastRequests часто заметно улучшает tail latency.

Разбор с примерами, как масштабировать ASP.NET Core API через YARP

А какая стратегия у тебя по умолчанию?

🎯 Открытый урок «Сетевой чат на C#».

🗓 22 января в 20:00 МСК
🆓 Бесплатно. Урок в рамках старта курса «C# Developer».

На вебинаре:
✔️ Рассмотрим написание сетевого приложения на C#.
✔️ Мы реализуем простые клиент и сервер с помощью одного из сетевых протоколов.
✔️Также затронем темы многопточности и асинхронности

Кому будет полезно:
• Вебинар будет полезен начинающим разработчикам, желающим разобраться в сетевом и многопочном\асинхронном программировании.

Что вы получите:
• По итогам вебинара смогут проектировать сетевые приложения.
• Получат представление о работе сетевых протоколов, и многопоточности\асинхронности в приложениях.
• На практике попробуют разработать такое приложение.

🔗 Ссылка на регистрацию: https://otus.pw/zifo/?erid=2W5zFJaPXHA

Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

⚡️ Автоматическая регистрация Minimal APIs в .NET - без ручного маппинга

Если в проекте 20+ endpoint’ов, app.MapGet/MapPost превращается в ад.
Решение - авторегистрировать endpoints через DI.

Идея:
1) Делаешь общий интерфейс IEndpoint
2) Каждый endpoint реализует его
3) На старте приложения сканируешь сборку, регистрируешь все реализации в DI
4) Достаёшь их из DI и вызываешь MapEndpoints()

Плюсы:
✅ чистый Program.cs
✅ каждый endpoint в отдельном файле
✅ масштабируется без хаоса
✅ легко тестировать и поддерживать

Пример паттерна:

builder.Services.AddEndpoints(typeof(Program).Assembly);

public interface IEndpoint
{
    void Map(IEndpointRouteBuilder app);
}

public static class EndpointExtensions
{
    public static IServiceCollection AddEndpoints(this IServiceCollection services, Assembly assembly)
    {
        var endpoints = assembly.DefinedTypes
            .Where(t => !t.IsAbstract && !t.IsInterface && typeof(IEndpoint).IsAssignableFrom(t))
            .Select(t => ServiceDescriptor.Transient(typeof(IEndpoint), t))
            .ToArray();

        services.TryAddEnumerable(endpoints);
        return services;
    }

    public static void MapEndpoints(this WebApplication app)
    {
        foreach (var endpoint in app.Services.GetServices<IEndpoint>())
            endpoint.Map(app);
    }
}

#ПятничныйКвиз #ДляСамыхМаленьких

🖥 Многопоточность в .NET часто сводят к lock. Но в реальных системах этого недостаточно — особенно под нагрузкой, в легаси-коде и распределённых сценариях.

📕 На открытом уроке разберём, какие инструменты действительно есть в .NET и как выбирать подходящий примитив под конкретную задачу. Рассмотрим Monitor, Mutex, Semaphore, а также другие примитивы из System.Threading: ReaderWriterLockSlim, Barrier, ManualResetEventSlim, SpinLock.

❗️ Вы увидите практические примеры, типовые ошибки и узнаете, где блокировки становятся узким местом. Урок будет полезен разработчикам, работающим с высоконагруженными системами и легаси-кодом, а также тимлидам, которые проектируют архитектуру и отвечают за производительность.

📣 Встречаемся 27 января в 20:00 МСК в преддверии старта курса «C# Developer. Professional». Регистрация открыта: https://otus.pw/t6Xj/

📦 Всё ещё не используешь Central Package Management в .NET?

Открой свой .csproj прямо сейчас.

Пакеты обычно выглядят так:
<PackageReference Include="Serilog" Version="4.3.0" />
<PackageReference Include="WolverineFx" Version="5.6.0" />

И в итоге проект превращается в мусорку из версий.

А теперь представь, что это будет так:
<PackageReference Include="Serilog" />
<PackageReference Include="WolverineFx" />

Вот в этом и кайф Central Package Management.

Что он даёт:
✅ .csproj становится чистым и читаемым
✅ никто случайно не поставит “левую” версию пакета
✅ вся команда работает на одинаковых версиях библиотек
✅ сборка становится предсказуемой и детерминированной

Как работает:
Ты управляешь версиями централизованно через файл
Directory.Packages.props в корне репозитория.

То есть версии пакетов задаются в одном месте, а проекты просто подключают зависимости без указания version.

Если у тебя монорепа или несколько проектов - это must-have.