.NET *

У вас не 5 микросервисов — у вас десятки. Бэкенд, который рос три года: монолит, расколотый на куски, GPS-фид от автопарка, мобильное приложение водителя, веб-кабинет диспетчера, интеграции с SAP / 1С / регуляторами / маркетплейсами, отдельный SMTP-воркер, отдельный PDF-генератор, отдельный шедулер ночных пересчётов. Между ними — Kafka (несколько кластеров, по топику на домен), RabbitMQ (RPC + pub/sub + DLQ), Redis (кэш, last-known-state, pub/sub-каналы), пара HTTP-эндпоинтов наружу, SFTP с поставщиком, SQL-polling outbox-таблицы старого монолита, MQTT с трекеров, IBM MQ для одного древнего банковского контура, SignalR-хабы для real-time-дашбордов. На каждом стыке — свой ретрай, свой DLQ (или нет DLQ), своя сериализация, свои метрики (или нет метрик), своя бойлерплейт-обвязка из консьюмеров и try/catch.

Каждый из этих стыков живёт своей жизнью в Program.cs соответствующего сервиса. Каждый — это hand-rolled цикл:

Каждый разработчик на .NET сталкивался с этим. Всё работает быстро, но иногда случается внезапный фриз. Игра проседает с 60 до 30 FPS на секунду. Сервис отвечает на запрос 100 мс вместо обычных 10. UI дёргается.

Виновник — Garbage Collector.

Когда GC решает собрать мусор, он останавливает все потоки приложения (Stop-The-World). Для игр и real-time сервисов это катастрофа.

Стандартные коллекции .NET создают мусор везде:

В real-time играх и серверах часто возникает задача: из N объектов нужно выбрать K лучших, чтобы обновить их в этом кадре.

Каждый игровой инженер сталкивался с этим. У вас есть 16.67 мс на кадр (60 FPS). В сцене 10 000+ объектов: враги, частицы, тени, декали, постыффекты. Нужно решить: на что потратить бюджет, чтобы игрок видел самое важное в максимальном качестве, а FPS не проседал?

Типичные подходы и их недостатки

1. Дистанционный LOD (расстояние до камеры)

Типизированное хранилище для .NET поверх Postgres и MSSQL. C#-класс как схема — без миграций, без Include, с полным LINQ. Работает в проде.

История о том, как Fleans — движок workflow на .NET Orleans и BPMN 2 — родился из упрямства, фрустрации, Camunda-которая-стала-платной и одного не самого очевидного разговора с ИИ.

Практически в каждом высоконагруженном .NET-проекте рано или поздно появляется один и тот же паттерн:

Есть коллекция данных.

Для каждого элемента нужно выполнить дорогую операцию.

Например:

вычислить хэш;

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

Заказал на Али недорогую рыбоглазую камеру и влепил её под потолок прямо над щитком. Но мой бюджет был ограничен, а в тумбочке лежит несколько неиспользуемых Андройд телефонов, их то я и решил применить в качестве NVR устройства, вместо покупки такового. А ещё телефон меньше жрут и совсем не шумят, в отличие от хардварных версий записывающих устройств. Встроенной карты памяти на камере нет, поэтому нужно внешнее устройство.

Загуглил, попробовал несколько программ и остановился на одной из них, которая выглядела как самая зрелая, с большим количеством функций, да ещё и платной версией. Платную версию конечно же купить у нас нельзя, но скачать её патченную сестру с 4pda можно, что я и сделал. Алексей (автор), прости, но другого варианта у меня не было.

Какие у неё функции достоинства:

Рассказываю, как написал кроссплатформенную .NET-библиотеку для глобального перехвата клавиатуры и мыши. Под капотом: WH_KEYBOARD_LL на Windows, CGEventTap на macOS и polling через XQueryKeymap на Linux. Один интерфейс, три реализации, ноль внешних зависимостей.

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

Ширина слоя — 5000 узлов. Количество слоёв — 60. Общее число узлов — 300 000.

Каждую секунду приходит 10 новых событий (изменений на входе). Наивный подход — пересчитать всё с нуля — будет перебирать все 300 000 узлов на каждое обновление. При 10 обновлениях в секунду это 3 млн вычислений узлов в секунду. А если ширина слоя 100 000 и слоёв 100? Получаем 10 млн узлов на пересчёт. Компьютер не справляется.

Финансовые системы предъявляют жёсткие требования к производительности.

Риск-департамент запрашивает переоценку портфеля из 200 000 опционов. Маржинальная система требует пересчитать все позиции клиентов после сильного движения рынка. Алгоритмический трейдер хочет оценить Greeks для тысяч потенциальных сделок за миллисекунды.

Стандартные подходы на .NET дают сбой по трём причинам.

Причина 1: Объектная модель

Каждый опцион становится отдельным объектом в куче. Виртуальные методы, ссылки, разрозненное расположение в памяти. Для 200 000 объектов — миллионы байтов, GC-паузы на сборку, промахи кэша процессора.

Причина 2: Позлементные вычисления

Вызов функции ценообразования в цикле — плохо. Процессор не может векторизовать код, потому что не видит всю картину целиком. SIMD-инструкции простаивают.

Причина 3: Аллокации в горячем пути

Каждый вызов new double[100000] для хранения промежуточных результатов — это давление на GC. В 24/7 сервисе такие аллокации накапливаются и вызывают непредсказуемые паузы.

Требования к решению

Допустим, вы делаете симуляцию города. Или RTS. Или RPG с открытым миром. И у вас в сцене одновременно находится 5, 10, а то и 20 тысяч живых существ. У каждого свои цели, приоритеты, эмоции, социальные связи.

Ваша архитектура AI начинает трещать по швам.

Классический подход — дать каждому NPC компонент с методом Update() — перестаёт работать где-то после 500–1000 объектов. Дальше начинаются проблемы:

TL;DR. Один «безобидный» foo.GetAsync().Result в middleware способен превратить ASP.NET Core, державший 50k RPS с p99 = 40 мс, в сервис с 12k RPS и p99 = 4 с — при CPU 8 %. Виноват не сам blocking call, а hill-climbing — фидбэк-луп в ThreadPool, в недрах которого живёт дискретное преобразование Фурье. Разбираем по исходникам CoreCLR, почему это вообще возможно, воспроизводим эффект на ~80 строках кода и разбираемся, почему SetMinThreads — не решение, а анестезия.

Если вы делаете RAG (Retrieval-Augmented Generation) на .NET, то рано или поздно упираетесь в вопрос: куда складывать эмбеддинги и как быстро искать по ним.

Существующие варианты делятся на два лагеря.

Внешние сервисы (Pinecone, Qdrant, Weaviate) — хороши, но требуют отдельной инфраструктуры. Сеть, авторизация, сериализация, мониторинг. Каждый запрос — это миллисекунды на HTTP. Плюс вы привязываетесь к конкретному облачному провайдеру или контейнеру.

Существующие .NET-решения — часто либо заброшены, либо имеют проблемы с производительностью (избыточные аллокации, медленный ANN, отсутствие гибридного поиска).

Но есть и третий путь: встраиваемая (embedded) векторная БД, которая работает прямо внутри вашего процесса. Никакой сети. Никакого внешнего сервиса. Только ваш код и процессор.

В этой серии туториалов мы реализуем простой Third Person Controller на базе MonoGame.

Серия рассчитана на читателей, уже знакомых с основами MonoGame и 3D-графики.

Пятница, 23:47. PagerDuty: “Платёж AmEx, провайдер вернул 5xx три раза подряд, билеты не зарезервированы.” Открываю логи – действительно три ответа провайдера 5xx, ни одной успешной транзакции по нашей базе. Закрываю как временный сбой на стороне провайдера, пишу короткую сводку в дежурный чат и иду досматривать. Через 40 минут второй алерт – уже от ночной поддержки: клиент прислал скрин выписки, 3 списания подряд за одну бронь. У клиента рейс через 6 часов, ему нужна действующая бронь и подтверждение, что он завтра нормально улетит, а не тикет в поддержку.

Мы делали B2B-платформу для деловых поездок: бронь авиа, отели, трансфер, страховка, в финале – оплата корпоративной картой через платежный шлюз. С этой ночи началась история, которая закончилась переписыванием всего платёжного слоя нашего booking-сервиса. По дороге мы поймали 5 граблей.

C# я до сих пор считаю одним из самых удобных языков для backend разработки. В нём много вещей к которым быстро привыкаешь: свойства, LINQ, async/await, generics без type erasure, хороший tooling и понятная модель разработки.

Но банковский enterprise редко выбирает стек только по удобству языка. На практике важны не только синтаксис и экосистема, но и инфраструктура, сопровождение, безопасность, регламенты, legacy, найм, CI/CD, требования к платформам и долгосрочная стратегия организации.

Так я оказался в ситуации где C# мне субъективно нравится больше, но Java объективно стала полезнее в конкретном банковском контуре.

Эта статья не про холивар C# vs Java. Это попытка спокойно разобрать почему backend разработчику в enterprise иногда приходится расширять стек, даже если текущий язык его полностью устраивает.

Введение

Content Pipeline — это официальный способ работы с ассетами в MonoGame. Однако в сообществе уже давно существует немалая группа разработчиков, которые его не любят и предпочитают загружать ассеты в «сыром» виде. Особенно это заметно в сообществе FNA(ещё одной реализации XNA4) — там такой подход используют практически все.

Я тоже давно в этой «партии» и в этой статье объясню, почему…

В dev-среде аутентификация может годами выглядеть безобидно: логин прошёл, cookie выпущена, [Authorize] работает. А потом приложение переезжает в продакшен — и часть пользователей начинает вылетать из системы без понятной ошибки. Иногда всплывает 431 Request Header Fields Too Large, иногда сервер просто перестаёт принимать сессию, которая ещё минуту назад выглядела корректной.

В статье разбираем, почему cookie аутентификации в ASP.NET Core разрастаются до опасных размеров, как это проявляется в реальных системах и какие решения помогают не лечить симптомы, а привести схему аутентификации в нормальное production-ready состояние.

При создании новой игры, одним из первых вопросов является выбор игрового движка.

Основные кандидаты у всех на слуху: Unity, Unreal Engine и Godot.

Но кроме них существует ещё немало движков второго эшелона, про которые мало кто знает.

Собственно, про один из них - под названием MonoGame - я и хочу рассказать.