🔥 Как просто добавить multi-tenant в .NET через заголовок запроса

Иногда нужно понимать, какому клиенту (tenant) принадлежит запрос.

Самый простой вариант - передавать X-TenantId в HTTP-заголовке и читать его в сервисе.

Пример сервиса:

public sealed class TenantProvider
{
    private const string TenantIdHeaderName = "X-TenantId";
    private readonly IHttpContextAccessor _httpContextAccessor;

    public TenantProvider(IHttpContextAccessor httpContextAccessor)
        => _httpContextAccessor = httpContextAccessor;

    public string TenantId =>
        _httpContextAccessor.HttpContext.Request.Headers[TenantIdHeaderName];
}

.NET 9 стал гораздо устойчивее к сбоям 💪

В .NET 9 появились официальные пакеты для отказоустойчивости:

- Microsoft.Extensions.Resilience
- Microsoft.Extensions.Http.Resilience

Они построены поверх Polly, поэтому API знакомый - легко описывать политики:

- retry
- circuit-breaker
- fallback
- timeout
- hedging
- rate limiter

Подключаете и ваши HTTP-клиенты и сервисы автоматически восстанавливаются при сетевых ошибках и таймаутах.

Итог: меньше падений и больше стабильности. Отлично для продакшена 🚀

Обещанного 3 года ...

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

Если ты используешь 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

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

⚡️ Автоматическая регистрация 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 => ServiceDenoscriptor.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);
    }
}

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

📦 Всё ещё не используешь 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.

Перестань падать из-за одного внешнего API - добавь Fallback в .NET через Resilience Pipeline 🛡️

Вместо того чтобы приложение валилось, когда GitHub (или любой сервис) не отвечает, ты можешь вернуть безопасный дефолт и продолжить работу.

Идея простая:
Ты добавляешь fallback-стратегию в pipeline, и если запрос падает — система вернёт запасной результат.

Что происходит в примере:

— В DI регистрируется Resilience Pipeline
— Добавляется FallbackStrategy
— Если вызов неудачный, возвращается GitHubUser.Empty вместо исключения

Дальше в endpoint ты не вызываешь HttpClient напрямую — ты запускаешь его через pipeline:

pipeline.ExecuteAsync(...)

И если API:
❌ упало
❌ вернуло ошибку
❌ словило таймаут

Пользователь не увидит 500. Он получит контролируемый ответ.

Это особенно важно для:
- внешних API
- микросервисов
- нестабильных сетей
- интеграций с SaaS

Fallback — это не про «скрыть ошибку».
Это про graceful degradation, когда система продолжает жить даже при частичных сбоях.

Надёжность — это архитектура, а не try/catch в каждом методе.
#dotnet #backend #architecture

🏗️ Пытаться вытаскивать микросервисы из “спагетти-монолита” - почти всегда плохая идея.

Вместо красивой архитектуры ты получишь распределённую кашу, ещё больше зависимостей, ошибок и боли при поддержке.

Самый безопасный путь миграции - паттерн Strangler Fig:
выносить функциональность по кускам, постепенно “замещая” монолит.

Но есть важное условие:
сначала нужно привести систему к Modular Monolith.

То есть:
- чётко выделить границы модулей
- изолировать данные
- оставить только чистые публичные API для общения между модулями

И только после этого выбирать, какой модуль выносить первым.

Как выбрать правильного кандидата на первый микросервис?
Ищи 4 “зелёных флага”:

1) Low Coupling - минимум зависимостей от других модулей
2) High Cohesion - логика внутри модуля максимально связная и цельная
3) Distinct Domain - чёткая бизнес-область (например, “платежи” или “инвойсинг”)
4) Scale Needs - модулю нужны другие ресурсы/масштабирование, чем остальной системе

Если модуль соответствует этим критериям - его можно вынести относительно безопасно,
не превращая архитектуру в распределённый хаос.