DeepSeek, Aspire, Gateway, Trading, Http

Итоги сегодняшней работы: Aspire Trading Gateway

Отвечаю по вашему каркасу. Там, где данных нет — пропускаю.

1. Контекст и отправная точка (Что было)

Бизнес-проблема:
Поиск «Золотого Руна» — способа связывать проекты внутри Aspire без выхода во внешние брокеры (RabbitMQ, Kafka, MassTransit). Индустрия навязывает очереди даже для задач уровня «сказать Привет», что ведёт к over-engineering.

Существующее решение (Status Quo):

Микросервисы на .NET 10, оркестрация через .NET Aspire 13.4.6.
Стандартный стек: ASP.NET Core, Blazor Server, YARP.
Отсутствие понимания, как правильно организовать взаимодействие между AddProject-ресурсами.

Критические недостатки старого подхода:

Спагетти-архитектура $N \times N$ : каждый сервис знает каждого.
Нет единой точки входа → сложно с CORS, аутентификацией, rate limiting.
Нет декларативного манифеста топологии → архитектура живёт в головах разработчиков, а не в коде.
Прямые HTTP-вызовы без Gateway → невозможно отследить сквозные трейсы, диагностика превращается в археологию.

Ограничения среды:

Windows Server 2025, Visual Studio, .NET 10.
Обучение и понимание — важнее скорости на этом этапе.

2. Концепция и цели (Что было задумано нового)

Формулировка гипотезы:
«Если внутри Aspire использовать центральный Gateway на HTTP + YARP, то можно получить прозрачную, отлаживаемую и наблюдаемую топологию без внешних брокеров».

Ключевые метрики успеха (KPI):

Работающая цепочка Web → Gateway → Orders/MarketData с HTTP-вызовами. ✅
Сквозные трейсы в Dashboard с единым TraceId. ✅ (проверено в трейсах)
Zero Trust через WithReference: у Web нет адресов Orders и MarketData. ✅
Dashboard показывает все 4 ресурса с эндпоинтами. ✅

Нереализованные альтернативы:

RabbitMQ / MassTransit — отброшены как over-engineering на этом этапе.
Wolverine — отложен на Этап 2-3, когда появится реальная боль.
gRPC — отложен, HTTP проще для старта и отладки.
SignalR как транспорт между сервисами — отброшен как антипаттерн.

Границы проекта (что решили НЕ делать):

Не подключать Outbox / Wolverine / брокеры на этом этапе.
Не делать синхронизацию состояния между вкладками.
Не добавлять аутентификацию / авторизацию.

3. Инновационность и новизна (Почему это Новое — является Новым)

Относительно рынка:
Стандартная практика — либо Full Mesh HTTP (хаос), либо сразу RabbitMQ/Kafka (over-engineering). Промежуточный паттерн «Центральный Gateway + HTTP + Aspire Service Discovery» — недооценён и почти не описан в литературе.

Относительно старой системы:
Закрывается технический долг:

Было: разрозненные HttpClient с захардкоженными адресами.
Стало: декларативный AppHost/Program.cs как исполняемая конституция топологии.

Интеллектуальная составляющая:

Комбинация: Aspire Service Discovery + YARP + WithReference + Blazor Server.
Идея: HTTP — это не «просто транспорт», а протокол прикладной адресации, который идеально ложится на философию Aspire.
Формулировка принципов:
- Zero Trust через физическое отсутствие путей.
- «Код как Конституция» — AppHost = исполняемый манифест.
- HTTP с большой буквы как «Золотое Руно».

Патентный ландшафт:
Пропускаю (не исследовался).

4. Реализация и результат (Что получилось)

Фактическая архитектура (то, что реально работает):

[Browser]
    │
    ▼
[Trading.Web] ──── http://gateway ────▶ [Trading.Gateway]
   (Blazor)                                 (YARP)
                                              │
                              ┌───────────────┴───────────────┐
                              ▼                               ▼
                     [orders-api]                   [market-data-api]
                  /api/orders                    /api/marketdata/{symbol}

Достигнутые показатели:

Показатель	План	Факт
Все 4 ресурса видны в Dashboard	Да	✅ Да
Web → Gateway → Orders работает	Да	✅ Да
Web → Gateway → MarketData работает	Да	✅ Да
Сквозные трейсы	Да	✅ Есть
Service Discovery резолвит `gateway`	Да	✅ Да
Zero Trust (нет прямых адресов)	Да	✅ Да

Положительные побочные эффекты:

Поняли, почему appsettings.json не копировался в bin: Microsoft.NET.Sdk vs Microsoft.NET.Sdk.Web. Это классическая ошибка, теперь знаем.
Разобрались с @rendermode InteractiveServer — «немая» ошибка Blazor Web App, при которой страница выглядит рабочей, но не является.
Научились диагностировать YARP через /debug/routes — быстрый способ увидеть, что реально загружено в IProxyConfigProvider.

Выжившие части старого:
Шаблон Trading.ApiService не используется, но остался в решении. Можно удалить.

Обратная связь:
Ваша цитата: «Да, сейчас кнопки работают. И высвечивают цифры. Помог @rendermode InteractiveServer».

5. Отклонения и неудачи (Что не получилось)

Несовпадение прогноза и реальности:

Ожидали, что AddProject + WithReference заработает «из коробки» — на деле вылезло 7 разных ошибок, каждая требовала отдельного разбирательства.
YARP требует явного AddServiceDiscoveryDestinationResolver() из отдельного пакета — не очевидно.

Архитектурные компромиссы (Технический долг v2.0):

Gateway работает в Production, а не Development — health checks /health и /alive не работают. Не критично, но надо исправить.
Gateway слушает только HTTP (порт 5000), без HTTPS. Позже нужно добавить HTTPS для production-сценариев.
Trading.Web не имеет явного WithExternalHttpEndpoints(). Пока работает, но лучше указать явно.

Выпавшие функции:

Sync-состояние между вкладками (не делали сознательно).
Аутентификация / авторизация (не делали).
Polly-политики на TradingApiClient (есть через ServiceDefaults, но не настроены параметры).
Idempotency-Key для POST /api/orders (не делали).

Неудачные эксперименты:

https+http://gateway не работает, если у Gateway нет HTTPS-эндпоинта. Заменили на http://gateway.
WeatherApiClient остался от шаблона, но apiservice не зарегистрирован в AppHost — страница Weather падает. Не критично, надо удалить.

Извлечённые уроки:

В Aspire всегда проверяйте Sdk="Microsoft.NET.Sdk.Web" для веб-проектов. Обычный SDK молча не копирует appsettings.json.
YARP маршрут /api/orders/{**catch-all} не матчит /api/orders без слэша. Нужны явные маршруты для базовых путей.
Blazor Web App без @rendermode InteractiveServer выглядит рабочим, но не реагирует на события.
UseAntiforgery() — обязателен для Blazor Server с интерактивным рендерингом.
Диагностика через /debug/routes экономит часы отладки.

6. Экономика и эксплуатация

Пропускаю (не исследовалось, учебный проект).

7. Взгляд в будущее (Куда идём дальше)

Roadmap следующих версий:

Этап 1 — Укрепление HTTP-фундамента:

Polly-политики: retry, circuit breaker, timeout на TradingApiClient.
Idempotency-Key для POST /api/orders.
ProblemDetails (RFC 7807) для ошибок.
Версионирование URL: /api/v1/orders.
WithEnvironment("ASPNETCORE_ENVIRONMENT", "Development") для Gateway.

Этап 2 — События:

Outbox в Gateway (таблица OutboxMessages в PostgreSQL).
Фоновый OutboxDispatcher.
POST /api/orders возвращает 202 Accepted мгновенно.

Этап 3 — Wolverine (Росомаха):

Замена самописного Outbox на Wolverine.
Готовые durability, idempotency, correlation, distributed tracing.

Этап 4 — Микропроцессорное ядро:

Отдельный Trading.Matching.Engine без HTTP-эндпоинтов.
Работа в одном потоке с CPU affinity.
LMAX Disruptor-подобные секвенсоры.

Масштабируемость:

Текущая архитектура выдержит рост за счёт добавления новых Gateway («Вселенных») и новых сервисов.
Множественные Gateway для изоляции bounded contexts — обсуждали, технически возможно.

План вывода из эксплуатации:
Пропускаю (слишком рано).

8. Риски и неопределённости

Уязвимости:

Нет аутентификации на Gateway — любой может обратиться к /api/orders.
Нет rate limiting — легко положить сервис.
HTTPS не настроен на Gateway.

Зависимости:

Aspire 13.4.6 — относительно новая версия, API может меняться.
YARP 2.3.0 + Microsoft.Extensions.ServiceDiscovery.Yarp — зависимость на конкретную версию.
Blazor Server требует WebSocket-соединения, что может быть проблемой за прокси.

Внешние угрозы:

Изменения в лицензировании NuGet-пакетов.
Изменения в API Aspire между версиями (например, AddServiceDiscoveryDestinationResolver может переехать).

🎯 Ключевые вешки на будущее

Золотое Руно найдено: HTTP с большой буквы — фундамент взаимодействия.
Три опоры: Микропроцессорная архитектура с events + правильные взаимодействия в Aspire + декларативность.
Работающая топология: Web → Gateway → Orders/MarketData.
Проверено: Zero Trust, Service Discovery, YARP-маршрутизация, сквозные трейсы, Blazor Server.
Следующий шаг: Этап 1 — Polly + Idempotency + ProblemDetails + версионирование.

Резюме дня:
Мы не просто запустили пример — мы построили работающий скелет «Управляемой Звезды» и прошли путь от теории (дискуссия об архитектуре) до практики (реально работающие HTTP-вызовы через Gateway с Service Discovery). Все ошибки, которые вылезли, — это классические грабли Aspire, и теперь у вас есть опыт их распознавания.

Фундамент заложен. Можно строить дальше.

GS.Aspire

пятница, 18 сентября 2026 г.

DeepSeek, Aspire, Gateway, Trading, Http

Итоги сегодняшней работы: Aspire Trading Gateway

1. Контекст и отправная точка (Что было)

2. Концепция и цели (Что было задумано нового)

3. Инновационность и новизна (Почему это Новое — является Новым)

4. Реализация и результат (Что получилось)

5. Отклонения и неудачи (Что не получилось)

6. Экономика и эксплуатация

7. Взгляд в будущее (Куда идём дальше)

8. Риски и неопределённости

🎯 Ключевые вешки на будущее

Комментариев нет:

Отправить комментарий

Ярлыки

Архив блога

пятница, 18 сентября 2026 г.

DeepSeek, Aspire, Gateway, Trading, Http

Итоги сегодняшней работы: Aspire Trading Gateway

1. Контекст и отправная точка (Что было)

2. Концепция и цели (Что было задумано нового)

3. Инновационность и новизна (Почему это Новое — является Новым)

4. Реализация и результат (Что получилось)

5. Отклонения и неудачи (Что не получилось)

6. Экономика и эксплуатация

7. Взгляд в будущее (Куда идём дальше)

8. Риски и неопределённости

🎯 Ключевые вешки на будущее

Комментариев нет:

Отправить комментарий

пятница, 18 сентября 2026 г.