17 ноябряAppleофициально представила устройства на базе своего нового ARM-процессораAppleM1. Естественно, это событие не могло быть не замечено со стороны компанииMicrosoft, которая с 2014 года начала активную экспансию .NET на новые платформы. Давайте посмотрим, что нас ждет в связи с этим в ближайшее время.

Начнем пожалуй с инструментов, а затем перейдем к самой платформе .NET, но если вам не терпится узнать, получат ли новые маки поддержку .NET, то вот вам небольшой спойлер:

Да, на новых маках будет .NET

Visual Studio Code

Команда разработчиков Visual Studio Code уже объявила о том, что работает над поддержкой новых процессоров. На странице загрузок Insider Preview для macOS уже появились опция для загрузки экспериментальной сборки с поддержкой ARM. Следить за работой команды можно на официальном аккаунте в GitHub.

Visual Studio for Mac

Если команда VS Code уже подготовила тестовые сборки с поддержкой Apple M1, то их коллеги из команды Visual Studio for Mac оказались не так расторопны:

Впрочем Visual Studio for Mac гораздо более крупный и сложный проект, поэтому портирование его на новый процессор может занять несколько больше времени. Сейчас эта версия IDE может работать при поддержке Rosetta 2.

На данный момент у владельцев новых ноутбуков Apple наблюдаются некоторые проблемы при отладке проектов на Xamarin.Forms для iOS. Соответствующий баг уже заведен в репозитории проекта Xamarin.iOS & Xamarin.Mac.

Rider

В JetBrains уже объявили, что они работают над переносом JetBrains Runtime (и всех продуктов, работающих на JVM, в том числе и Rider) на Apple Silicon. На данный момент IDE от JetBrains работают на чипах Apple Silicon через Rosetta 2. Правда не все функции работают в этом режиме стабильно. Так, например, многие жалуются на то, что отладка в Rider сейчас не работает.

Docker

Docker стал практически must have инструментом для современного разработчика. У Майкрософт есть обширный набор образов для .NET, но к сожалению, воспользоваться вы ими на ноутбуке с новым процессором от Apple пока не сможете.

Будем надеяться, что в ближайшее время поддержка M1 будет реализована в Docker.

.NET

А теперь перейдем к самому главному получит ли новый чип поддержку .NET?

Те, кто подсмотрели спойлер в начале статьи уже знают ответ на этот вопрос. Команда разработки .NET активно работает над поддержкой Apple M1. Для этого даже был создан отдельный проект в трекинге платформы. Стоит отметить тот факт, что текущая версия платформы (а именно, недавно ушедший в релиз .NET 5) будет работать поверх Rosetta. А вот в .NET 6 уже будет нативная поддержка нового чипа. Согласно планам Microsoft, произойдет это не раньше, чем через год:

Из того, что уже выполнено, я бы отдельно отметил такие задачи:

• Add initial CoreCLR compilation support for Apple Silicon

• Add osx-arm64 to packges/CI

• Enable building SOS on Apple Silicon

• Enable osx-arm64 cross compilation

• Support Runtime native build on Apple arm64

• Enable building .NET Core osx-arm64 in CI

• Enable Apple Silicon SDK builds

Также запланирована поддержка нового процессора в ASP.NET Core.

Но несмотря на то, что официальной поддержки новых процессоров придется ждать почти год, уже доступна к загрузке альфа-версия .NET 6.0. На момент написания статьи, это версия 6.0.0-alpha.1.0562.6.

Mono

Проект Mono, который обычно был догоняющим (так как команде приходилось реализовывать те возможности, которые уже были в .NET) на этот раз оказался слегка впереди. Пулреквест с поддержка нового процессора сделала сама Apple, которая ранее обещала помощь в поддержке M1 для проектов с открытым исходным кодом.

Самое большое изменение, которое было сделано для поддержки процессора M1 связанно с тем, как работает JIT, а именно, с изменение состояния потоков. Это было реализовано с помощью новых макросов в mono/mini.h. Они были встроены в систему из соображений производительности.

Rosetta 2

В этой публикации не один раз упоминалась технология Rosetta 2. Для тех, кто не знает, что это, приведем пояснение, которое размещено на странице портала Apple Developer:

Rosetta - это процесс трансляции, который позволяет пользователям запускать приложения, содержащие инструкции x86_64, на микросхеме Apple. Rosetta призвана упростить переход на микросхему Apple, давая разработчикам время на создание универсального двоичного кода приложений. Если исполняемый файл содержит только инструкции Intel, macOS автоматически запускает Rosetta и начинает процесс трансляции. По окончании трансляции система запускает подготовленный исполняемый файл вместо оригинала. Однако процесс перевода требует времени, поэтому транслированные приложения иногда запускаются или работают медленнее.

Итоги

Новый процессор (а соотвественно устройства, которые будут на основаны на нем) без сомнений получит нативную поддержку в .NET, впрочем эта задача не является приоритетной в текущем роадмапе, поэтому ждать ее придется не раньше, чем в релиз уйдет шестая версия платформы. До того момента можно будет работать c .NET, используя возможности Rosetta 2. Что касается инструментария для разработчиков, то я могу предположить, что в ближайшие пол года основные проблемы будут решены (возможно даже с участием Apple) и уже к апрелю можно будет потихоньку присматриваться к компьютерам на базе Apple M1 в качестве рабочего инструмента.

Не секрет, что Telegram является на данный момент одним из самых популярных мессенджеров. Особенно в среде ИТ-специалистов. Он удобен, в нем нет встроенной рекламы и работает весьма стабильно. Довольно большую часть времени я общаюсь как по работе, так и по личным вопросам именно в этом мессенджере. Поэтому в один прекрасный день я подумал о том, что было бы удобно, чтобы в этом же мессенджере я мог получать уведомления о работе некоторых своих сервисов. На тот момент я как раз активно работал над интеграцией проекта //devdigest и Telegram, поэтому используя тот же родной Telegram Bot SDK довольно быстро реализовал логгер.

Несколько дней назад я решил вернуться к этому проекту, слегка почистить и отрефакторить код, а затем выложить его в открытый доступ быть может возможность получения логов в Телеграм будет полезна кому-то еще.

Подготовка

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

Согласно инструкции на официальном сайте Telegram, для того чтобы создать бота нам нужен другой бот.Детально описывать весь процесс создания бота я здесь не буду, так как сами разработчики Telegram описали его максимально просто и доступно. Отмечу лишь то, что нам нужно будет получить токен новосозданного бота, а также этого бота нужно будет добавить администратором в тот канал, где мы хотим видеть логи.

Дале нужно получить идентификатор канала. Для публичных каналов все просто - в качестве идентификатора мы можем использовать имя канала. Для приватных каналов все чуть-чуть сложнее.

Получение идентификатора приватного канала.

Чтобы получить идентификатор приватного канала придется воспользоваться помощью еще одного бота @JsonDumpBot. Вам нужно будет любое сообщение из этого канала переслать в этот бот. В ответ вы получите сообщение примерно такого вида:

{  "update_id": 111001100,  "message": {    "message_id": 123456,    "from": {      "id": 12345678,      "is_bot": false,      "first_name": "FirstName",      "username": "username",      "language_code": "en"    },    "chat": {      "id": 123456,      "first_name": "FirstName",      "username": "username",      "type": "private"    },    "date": 1111111111,    "forward_from_chat": {      "id": -1123456789101,      "title": "torf.tv logs",      "type": "channel"    },    "forward_from_message_id": 1,    "forward_date": 1111111111,    "text": "test"  }}

Идентификатор канала находится в блоке forward_from_chat -> id

Теперь, имея идентификатор чата и токен бота мы можем перейти к настройке логгера.

Настройка логгера

Для конфигурации логгера используется класс TelegramLoggerOptions, который содержит следующие поля:

• AccessToken токен бота;

• ChatId идентификатор канала (приватного, или публичного), или чата, куда бот будет отправлять сообщения;

• LogLevel минимальный уровень сообщений, которые будут отправляться в канала. Обычно я в канал отправляю сообщения начиная с уровня Warning, или Error;

• Source удобочитаемое название сервиса. Полезно, если в один канал приходят сообщения из нескольких сервисов;

Существует несколько вариантов конфигурации логгера непосредственно через код, или через файл кофигурации.

Настройка логгера в коде

Для начала нужно создать и инициализировать экземпляр класса TelegramLoggerOptions.

var options = new TelegramLoggerOptions{    AccessToken = "1234567890:AAAaaAAaa_AaAAaa-AAaAAAaAAaAaAaAAAA",    ChatId = "-0000000000000",    LogLevel = LogLevel.Information,    Source = "Human Readable Project Name"};

Зачем передать этот объект в метод-расширение AddTelegram():

builder  .ClearProviders()  .AddTelegram(options)  .AddConsole();

Пример такой конфигурации можно посмотреть здесь.

Настройка логгера через файл конфигурации appconfig.json

Также блоггер можно настраивать через файл конфигурации приложения, как это показано ниже:

{  "Logging": {    "LogLevel": {      "Default": "Information",      "Microsoft": "Warning",      "Microsoft.Hosting.Lifetime": "Information"    },    "Telegram": {      "LogLevel": "Warning",      "AccessToken": "1234567890:AAAaaAAaa_AaAAaa-AAaAAAaAAaAaAaAAAA",      "ChatId": "@channel_name",      "Source": "Human Readable Project Name"    }  },  "AllowedHosts": "*"}

Далее, в метод-расширение AddTelegram() необходимо передать экземпляр IConfiguration,

public static IHostBuilder CreateHostBuilder(string[] args) =>    Host.CreateDefaultBuilder(args)        .ConfigureLogging((context, builder) =>        {            if (context.Configuration != null)                builder                    .AddTelegram(context.Configuration)                    .AddConsole();        })        .ConfigureWebHostDefaults(webBuilder => { webBuilder.UseStartup<startup>(); });

Пример находится здесь

Установка

Установить логгер можно из NuGet, или же интегрировать код прямо к себе в проект. Библиотека распространяется под лицензией MIT.

С выпуском .NET 5 миграция решений из .NET Framework увеличилась. В частности, мы начали наблюдать перемещение очень крупных решений. Чтобы обеспечить максимальное удобство, мы работали над оптимизацией Visual Studio для обработки решений, содержащих большое количество проектов .NET 5 и .NET Core. Многие из этих оптимизаций были включены в версию 16.8, и в этом посте рассматриваются внесенные нами улучшения.

Запуск компилятора C# и VB вне процесса

Roslyn, компилятор C# и Visual Basic, парсит и анализирует все решение для поддержки служб, таких как IntelliSense, Go to Definition и диагностика ошибок. В результате Roslyn имеет тенденцию потреблять ресурсы, которые увеличиваются пропорционально размеру открытого решения, что может стать весьма значительным для больших решений. Команда Roslyn уже работала над минимизацией этого воздействия, активно кэшируя информацию на диске, которая не требуется немедленно, но даже при таком кэшировании нельзя избежать необходимости хранить данные в памяти.

Чтобы уменьшить влияние на более крупные решения Visual Studio, команда Roslyn приложила значительные усилия, чтобы вывести компилятор Roslyn из процесса Visual Studio в его собственный процесс. Запуск Roslyn в собственном процессе освобождает ресурсы в самой Visual Studio и дает компилятору Roslyn больше места для выполнения своей работы. Для больших решений это может сэкономить до трети памяти, потребляемой Visual Studio при открытии большого решения.

Оптимизация узла зависимостей

Каждый проект .NET 5 и .NET Core имеет узел в обозревателе решений с именем Dependencies, который отображает все, от чего зависит проект: другие проекты, сборки, пакеты NuGet и т.д. В дополнение к отображению непосредственных зависимостей проекта, узел также показывает транзитивные зависимости проекта, т.е. все, от чего зависит каждая зависимость, и так далее. Для проекта любого разумного размера этот список транзитивных зависимостей может стать довольно большим.

К сожалению, первоначальная реализация узла Dependencies не была очень эффективной в том смысле, что она хранила информацию о переходных зависимостях в памяти. В нем содержалось гораздо больше информации, чем было необходимо, и большая часть данных была избыточной. Мы переписали код, чтобы сохранить только ту информацию, которая абсолютно необходима, и начали использовать существующую информацию о зависимостях, которая уже хранится в NuGet. Эта перезапись сэкономила до 1015% памяти, потребляемой Visual Studio при открытии большого решения.

Уменьшение дублирования информации в MSBuild

После Roslyn одним из других основных потребителей ресурсов в процессе Visual Studio является MSBuild. Это связано с тем, что в качестве механизма сборки большая часть среды IDE основана на объектной модели MSBuild. Хотя мы сделали сами файлы проектов намного меньше в .NET 5 и .NET Core, существует значительное количество вспомогательных файлов проектов, которые импортируются в проекты через SDK. Оценка всех этих файлов необходима для понимания и построения проекта и может потреблять до трети памяти, нужной Visual Studio при открытии большого решения.

Хотя файлы проекта генерируют много данных, большая часть этих данных повторяется, и мы начали дедупликацию этих данных в памяти. Строки - один из наиболее распространенных побочных продуктов системы проектов, и они хранят такую информацию, как имена файлов, параметры и пути. В частности, пути могут быть довольно длинными и потреблять много памяти, если их слишком много или они дублируются слишком много раз. Обеспечено хранение только одной копии строки, что позволяет сэкономить до 510% памяти, потребляемой Visual Studio при открытии большого решения.

Уменьшение количества копий проекта, удерживаемых системой проектов

Одним из важных аспектов проектирования системы проектов .NET 5 и .NET Core является асинхронность. Часто системе проекта требуется выполнять работу в ответ на действие пользователя (например, добавление новой ссылки в проект). Вместо того, чтобы блокировать Visual Studio, пока она завершает свою работу, система проектов позволяет пользователю продолжать работу в среде IDE и выполнять работу в фоновом режиме.

Поскольку пользователь может продолжать вносить изменения в проект (например, добавлять еще одну ссылку), пока система проектов обрабатывает предыдущие изменения в фоновом режиме, система проекта должна сохранять моментальные снимки данных проекта, чтобы гарантировать, что последующее действие не конфликтует с более ранним. В результате система проектов может легко получить сразу несколько копий данных проекта в памяти. Если система проекта не заботится об управлении этими копиями, они могут храниться дольше, чем необходимо, или даже просочиться и сохраниться навсегда. Мы активно работали над сокращением количества копий, которые мы храним одновременно.

Улучшения загрузки большого решения

Проделав всю эту работу, мы значительно оптимизировали работу с большими решениями .NET 5 и .NET Core. Начиная с версии 16.8, во многих наших тестах мы наблюдали увеличение в 2,5 раза размера решения, которое мы можем открыть, прежде чем столкнуться с проблемами ресурсов. Мы также наблюдаем снижение до 25% сбоев, сообщаемых из-за исчерпания ресурсов.

Перечисленные выше улучшения - это только начало изменений, которые мы вносим для улучшения работы с большими решениями в Visual Studio. Производительность отдельных решений по-прежнему может варьироваться в зависимости от размера решения, типа проектов, загруженных расширений и т.д., И есть области, которые мы ищем для улучшения. Мы рекомендуем всем пользователям, у которых возникают проблемы с медленной загрузкой или сбоями при загрузке решений, обращаться к нам по адресу vssolutionload@microsoft.com, чтобы мы могли продолжать улучшать загрузку решений всех типов!

В одно прекрасное утро вдруг пришла "гениальная" мысль а не протестировать ли мне что ни будь? Посмотрев по сторонам, на глаза мне попался он - герой этой статьи.

Это была вступительная минутка юмора, а если серьёзно то вопрос о тестировании web сервера стоял уже давно. Какого-то комплексного решения не было, поэтому я решил сделать хоть какие то первые шаги. Получить первые цифры. Благодаря которым можно было бы уже предметно разговаривать и продумывать дальнейшую стратегию.

И так дано - web сервер. Написан на .net core. Сервер используется в корпоративной разработке.

Посмотреть, как работает можно, например здесь бесплатный сервис хранение ссылок http://linkin.link. Про него я писал тут http://personeltest.ru/aways/habr.com/ru/users/developer7/posts

Вступление

Собственно, как тестировать web сервер? Если посмотреть на проблему в лоб то веб сервер должен отдавать все страницы, которые были запрошены клиентами. И желательно отдавать быстро.

Конечно, есть множество других сценариев. Ведь web сервер не работает сам по себе, как правило, он как минимум работает с какой-нибудь БД, связь с которой это отдельная большая тема. Опять же могут быть множество отдельных сервисов автаризационных и прочих. Перед web сервером может стоять балансировщик нагрузок. Всё это может размещается в множестве виртуальных контейнеров, которые опять же могут быть на разных физических серверах. В общем это целый зоопарк каналов передачи данных каждый из которых может стать узким горлышком.

Начинать надо с малого и для начала решил проверить самый простой и очевидный сценарий. Есть web сервер. Делаем на него запросы. Все запросы должны вернутся без ошибок и вовремя.

Задача поставлена. Тестировать решил так. На одной машине под windows 10 запускаю web сервер. На web сервере запущен сайт. На сайте размещено куча js, сss, mp4 файлов и, собственно, html страничка. Для простоты я просто взял страницу из готового сайта.

Чем досить сервер? Тут 2 пути скачать что-то готовое или написать свой велосипед. Я решил остановится на втором варианте. И этот выбор я сделал по нескольким причинам.

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

Httpdos

Сказано сделано.

Программа работает так - при старте читается файл urls.txt где занесены url которые надо скачивать. Далее нажимаем старт. Создаются список Task по количеству url. Каждый Task открывает socket, отправляет http запрос, получает данные, закрывает socket. Далее процедура повторяется.

Изначально использовал TcpClient но по каким-то причинам он выдавал почти сразу на старте множество ошибочных загрузок. Не стал разбираться, а спустился пониже. Реализовал отправку на socket.

В программу добавил таблицу url, количество удачных скачиваний, количество ошибок, размер закачки.

Ошибки считал по 2 сценариям. Все exception связанные с открытием, отсылкой, приёмом данных. Собирательно если хоть, где что-то не так убиваем socket, инкрементируем счётчик ошибок. Ещё добавил проверку длины данных. При первой закачке страницы запоминается длина данных, все повторные закачки сверяются с этим числом. Отклонение считается ошибкой. Можно было бы добавить и что-то другое но для начала мне и этого достаточно.

Всё для эксперимента готово. Запускаем web сервер. Запускаем httpdos так назвал программу, чтобы дальше можно было использовать это короткое название. И вижу следующую картину.

Тут я уточню некоторые технические данные. Количество потоков делающие запросы получилось 1200. Эта цифра количество url прочитанных из файла urls.txt, плюс я решил умножить все запросы в 20 раз. Все цифры взял из головы на момент написания программы. В любой момент можно поставить любые другие по желанию. Преимущество велосипеда.

Так же в последствии я добавил сбоку textarea куда вывожу все exception, и ещё решил добавить вывод - количество запросов в секунду.

Картинка меня порадовала. Во первых - всё работает ). Во вторых работает без ошибок. Количество обработанных запросов получилось где-то 4000-6000 в секунду.

Откуда такая цифра? По моим размышлениям она зависит от многих обстоятельств. Самая очевидное это какого размера сами запросы. Как я писал выше я просто скачиваю все данные с определённой web страницы, которая была взята из стороннего web проекта. И там много mp4 файлов, размер которых под 3 мегабайта. Если уменьшить размер запросов, например скачивать только css наверняка количество обработанных запросов увеличится. Мне даже стало интересно, и я начал играть с исходным кодом как со стороны web сервера, так и со стороны httpdos. Там есть куча различных таймеров, буферов и прочего. Я смотрел, как то или иное изменение, окажет влияние на скорость.

Но не буду писать об этом. Да и цель была проверить отказоустойчивость, а не скорость. Простая проверка для начала - зависнет ли сервер от dos атаки или просто будет медленнее обрабатывать запросы.

Так же существенное влияние на скорость оказывало, то что web сервер и httpdos был запущен в режиме отладки в Visual Studio.

Поработав пару минут ни одной ошибки. Посмотрел загрузку процессора диспетчер задач показал примерно 28% на web сервер и 20% на httpdos. Процессор стоит i7-8700k. Не разогнанный. Это 6 ядерный 12 поточный камень. В процессе работы куллер охлаждения не было слышно проц холодный. Специально температуру не смотрел.

Решил параллельно с httpdos сделать загрузки js файла через браузер. Файл закачивается мгновенно. Т.е. httpdos не оказывает существенного влияния на web сервер.

Продолжаю эксперименты. Решил запустить три программы httpdos одновременно. И понаблюдать за результатами. То, что я увидел, и я является причиной появления этой статьи.

А у видел я, что по каким-то причинам спустя примерно минуту начали появляться ошибки загрузок.

И я начал расследование.

Такого поведения просто не должно быть!

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

То, что произошло дальше заставило меня напрячься.

В процессе экспериментов я и так и сяк изгалялся над httpdos. И один сценарий привёл к неожиданным результатам.

Если запустить не менее 3 программ. Думаю, что такое количество связанно с количеством одновременных запросов в секунду. Начать dos атаку. Дождаться появления ошибок. Потом резко закрыть программы. То слушающий socket web сервера просто умирает! Вот так нету никакой ошибки на стороне сервера. Все потоки работают. А socket ничего не принимает. Это уже ни в какие ворота.

Эксперименты показали, что socket оживал примерно через 4 минуты, но, если dos атаку проводить долго socket умирал навсегда, по крайней мере я минут 15 ждал оживления, а дальше уже и не интересно было. Такого поведения просто не должно быть!

Эксперимент был проведён множество раз результат всегда один и тот же.

Если перезапускать web сервер, т.е. получается мы пересоздаём слушающий socket, то socket начинал принимать клиентов сразу.

Первый шаг

Первое что я сделал - решил попробовать получить более подробную информацию из exсeption на стороне httpdos. Полазив по интернету, нашёл что мне нужен SocketException, а в нём посмотреть свойство ErrorCode. Сделано. Получил код ошибки 10061 - WSAECONNREFUSED. Тут пояснение.

В соединении отказано.

Невозможно установить соединение, потому что целевой компьютер активно отказался от него. Обычно это происходит в результате попытки подключиться к службе, которая неактивна на чужом хосте, то есть к службе, на которой не запущено серверное приложение.

Ну информативно(сарказм) однако. Вроде как это стоит понимать, что socket, к которому мы хотим подключится как бы и нету.

Запускаем консоль. Вводим netstat -an и видим. Вот он родненький. Слушает 80 порт. Ну по крайней мере система так думает.

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

Пару слов о socket.

В веб сервере используется самый стандартный способ открытия и работы с socket в .net. Вот пример кода:

Socket listenSocket = new Socket(AddressFamily.InterNetwork,                                 SocketType.Stream, ProtocolType.Tcp){NoDelay = true,Blocking = false,ReceiveBufferSize = TLSpipe.TLSPlaintext_max_recive,SendBufferSize = TLSpipe.TLS_CHUNK};//~~~listenSocket.Bind(new IPEndPoint(point.ip, port.port));Socket socket = await listenSocket.AcceptAsync();

Как видно для работы с слушающим socket нужно 3 действия. Создали. Слушаем. Принимаем клиентов. Схема настолько простая что программисту не остаётся никаких способов для манёвров, ну или возможностей отстрелить себе ногу.

Предполагается что используй вот так (куда ещё проще?) и не иначе и всё у тебя должно работать. Но как показывает практика есть нюансы.

Хоть схема использования и проста, я всё же решил провести пару экспериментов что бы отсеять весь лишний код из подозрений. Первое что я сделал это очистил код от лишних действий и поставил точку остановки сразу после конструкции:

Soсket socket = await listenSocket.AcceptAsync();

Затем подвесил socket. Попытались присоединится клиентом. Программа висела в вышеприведённой строчки кода. Тут мы увидели, что проблема не в коде после socket, а где то внутри socket.

Дальше я решил поэкспериментировать с настройками открытия socket. Собственно, в своё время все настройки и так были исследованы, и оставлены только те, что нужно. Но в свете последних событий никто не уйдёт от (подозрений) экспериментов.

Под подозрения попали следующие настройки.

1. ReceiveTimeout

2. SendTimeout

3. Ttl

Конечно, если подумать ни одно из этих свойств не должно вызывать эффект, описанный выше, но в принципе вообще ничего не должно убивать socket. Но что-то же убивает. Да и провести этот эксперимент занимает десятки секунд, гораздо меньше, чем я этот текст пишу.

И вообще было проведено большое число разных спонтанных экспериментов. Пришла в голову идея. Изменил код. Запустил. Проверил. Забыл. Десятки секунд, не более.

Что касается тайм аутов. В коде сервера реализованы различные таймауты, но на более высоком уровне. В приёмнике есть таймауты на приём шапки http, определения длины body, расчёт времени на приём body исходя из длины body и сценария наихудшего канала связи, например 1024 кб/c.

Примерно такие же правила и на отправку.

И если таймауты выходят socket клиента закрывается и удаляется. Для socket вызывается shutdown и close. Всё как и предписывает microsoft.

Поставил таймауты для resive/transmite 2000ms. Не помогло. Идём далее.

Ttl

Что это за параметр? Wiki говорит:

Получает или задает значение, задающее время существования (TTL) IP-пакетов

Т.е. при прохождении очередного шлюза параметр уменьшается на 1. При достижении 0 пакет удаляется. И вроде это не наш случай. Потому как наша система вся на localhost. Но! При гугление я нашёл следующую информацию.

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

Поставил ttl в минимально возможное значение. Не помогло.

Утечка sockets?

Далее я подумал сервер открывает каждую секунду около 6000 тысяч sockets и закрывает их. И всё это крутится на кучи асинхронных Task. Вдруг количество открытых сокетов и закрытых не совпадает? И есть, некая утечка sockets?

Быстро набросав код принцип которого заключается в инкременте глобальной переменной при открытии socket и декременте при закрытии и вывода этого числа в консоль.

Весь дополнительный код состоял из 3 блоков:

Interlocked.Increment(ref Program.cnt);Interlocked.Decrement(ref Program.cnt);Task.Run(async () => { while (true) {await Task.Delay(1000);Console.WriteLine(Program.cnt); });}

Разумеется, каждый блок размещается в нужном месте.

Запустив программы, я получил следующее:

Видео можно разделить на три части. Запуск. Рабочее состояние длится около 3 минут. В этом состоянии ни одной ошибки. И первое появление ошибки. Собственно, вторую часть я вырезал как не интересную.

Как же нам интерпретировать результат? Во-первых, мы видим число примерно 400 выводящееся каждую секунду.

Как работает веб сервер? Идеальный сервер приняв клиента мгновенно формирует ответ, отправляет его клиенту и мгновенно закрывает socket (хотя в реальности socket не закрывается а ожидает следующих запросов, ну условимся что так работает идеальный сервер). Поэтому количество открытых socket в идеальном сервере каждую секунду было бы 0. Но тут мы видим, что каждую секунду у нас примерно 400 обрабатывающихся клиентов. Что ж, для неидеального сервера вполне норма. Вообще количество одновременных клиентов в нашем сервере задаётся глобальной настройкой. В данном случае 10000 что значительно выше 400.

Так же мы видим, что периодически подпрыгивающее значение до 1000-2000. Связанно это может быть с чем угодно. При желании можно и это выяснить. Может сборщик мусора, может что ещё. Но, собственно, ничего криминального в этом нет.

И вот появились первые ошибки. Я начал закрывать программы. На видео виден характерный момент при закрытии второй программы, в последней оставшейся программе, посыпались ошибки открытия socket. Это в очередной раз показал своё лицо баг который мы так пытаемся отловить, пока безуспешно. Одна радость повторяется он регулярно, поэтому хоть есть возможность поиска. Сама же эта ошибка нам пока ничего не даёт.

Главная цель текущего эксперимента сопоставить количество открытых и закрытых socket. Окончательная цифра 0. Всё, как и должно быть. Ладно идём дальше.

Динамический диапазон портов

Далее расследование завело меня в область настроек windows. Должны же быть какие-то настройки для работы tcp/ip стека? Гугление мне подкинуло множество, но особо я хотел бы остановится на наиболее подходящих к нашему случаю.

Собственно настройки tcp/ip стека для windows меня интересовали с самого начала. Я задавал себе вопросы - а какие вообще порты выделяются на клиенте? Да и количество портов как бы ограничено. Всего 65535 значений. Такое число обусловлено исторически переменной uint16 в протоколе TCP.

Если выделять тысячи портов в секунду то можно и исчерпать их всех.

Я даже вначале проверил следующий кейс. Изначально в httpdos использовался стандартный для .net способ открытия socket клиента.

new TcpClient().Connect("127.0.0.1", 80);

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

Поискав готовое решение я увидел, что это не простой способ в одну строчку. И я не стал развивать эту тему дальше. Windows виднее кокой мне порт дать.

Но какой же диапазон портов мне выдаёт Windows? Тут я узнал ответ. Честно ещё в десятке других мест. Правда в большинстве информация была устаревшая - мол диапазон 1025 до 5000. Но я из практики знал, что диапазон выделяется где-то от 50000.

В дальнейшем я и убедился в своей правоте. Как оказалось Microsoft изменила этот диапазон, и он составляет 49152-65535. И того где-то 15k портов. Явно меньше, чем 65535

Поэтому первая настройка увеличиваем этот диапазон.

Я применил следующую команду:

netsh int ipv4 set dynamicport tcp start=10000 num=55535

Команду запускаем под администратором. Проверить значение можно командой:

netsh int ipv4 show dynamicport tcp

Изменить то изменили но как проверить, что диапазон действительно расширен? Да и нужно ещё узнать повлияла ли эта настройка на наш баг.

Делаем вывод на стороне сервер, всех портов подключившихся клиентов. Ну и пытаемся увидеть какие-нибудь отклонения от нормы. Вдруг кусок выпадет из списка?

Добавляем код - 1 строка:

Console.WriteLine(((IPEndPoint)socket.RemoteEndPoint).Port);

Что показало нам запуск? При старте одной программы вылетела ошибка одного подключения. Не будем на это обращать внимание. А то так можно закопаться по уши в отладке. Дальше работало всё, как и ожидалось. Во-первых, мы чётко увидели, что диапазон выделяемых портов действительно стал 10000-65535. Во-вторых, порты выделяются последовательно без каких-то видимых провалов. Достигнув максимума, цикл повторяется. Я прогнал несколько циклов никаких отклонений.

Далее я начал закрывать программы и при закрытии второй программы серверный socket завис. Порты перестали выделятся. Во второй программе httpdos посыпались ошибки открытия socket.

Выводы проблема не в портах. По крайней мере порты явно не заканчиваются.

TIME WAIT

А что у нас есть вообще по протоколу TCP? Идём сюда и внимательно читаем.

Под подозрение попадает одно состояние TIME WAIT. Это одно из стояний, в котором может находится socket, т.е. пара ip+port. После его закрытия.

Получается, что мы закрыли socket но он ещё будет недоступен. Поиск показал, что это время находится в районе 4 минут.

Если бы мы играли в игру холодно-горячо, то я бы заорал горячо! Горячо! Похоже это именно наш случай.

Но зачем такое странное поведение. Опять же из справки получил пояснение. Т.к. протокол tcp/ip гуляет по сети пакетами, а сами пакеты могут пойти по разным маршрутам. И вообще застрять на некоторое время на каком-нибудь шлюзе, может получится ситуация, когда мы открыли socket, поработали с удалённым сервером. Закрыли socket. Потом этот socket открывает другая программа а ей начинают валится пакеты от предыдущей сессии. Как раз время таймаута и выбрано что бы отставшие все пакеты в сети удалились как мусорные.

OK, а можно ли изменить этот параметр? Оказывается в Windows есть целая ветка реестра, отвечающая за параметры tcp протокола.

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services: \Tcpip \Parameters

Нас интересуют пока 2 параметра:

1. TcpFinWait2Delay

2. TcpTimedWaitDelay

Цель установить минимальное значение. Минимальное значение 30. Что означает что через 30 секунд порт опять будет доступен. Устанавливаем. Ну а далее наша стандартная проверка.

Запускаем сервер. Запускаем клиенты. Досим. Дожидаемся отказа socket. Потом запускаем консоль и вводим команду:

netstat -an

Такое ощущение что весь выделенный диапазон портов находится в состоянии TIME WAIT. Это пока соответствует ожиданиям. Ждём 30с. Повторяем команду. Листинг уменьшился в разы. Все порты с WAIT TIME пропали.

Проверяем серверный socket на оживление. Глух ((( А такие надежды были на эту настройку.

Впрочем, определённые выводы сделать можно. Настройка наша работает. Пауза 30с. Оставляем полезная настройка для нагруженного сервера.

Wireshark

Решил посмотреть, что нам покажет Wireshark. Кто не знает это мощнейший анализатор всевозможных протоколов, в том числе и tcp/ip. До недавнего времени в программе не была реализована функция прослушки localhost и приходилось производить некоторые танцы с бубном. Ставить виртуальную сетевую карту. Трафик пускать через неё. А Wireshark уже мог подключатся к прослушке этой карты.

Недавно подвезли возможность прослушки localhost что очень облегчило работу.

Далее всё стандартно. Запускаем сервер, клиентов. Убиваем слушающий socket.

Запускаем Wireshark ставим фильтр на 80 порт. Открываем браузер пытаемся закачать файл javascript.

Вот какое непотребство мы увидели в сниффере:

Анализируем увиденное.

Видно, наш запрос. Браузер с порта 36036 пытается достучатся к порту 80. Выставляет флаг SYN. Это стандартно. Но вот с порта 80 нам возвращается флаг RST оборвать соединения, сбросить буфер. Всё. И так по кругу.

Вывод. Wireshark нам особо не помощник. Разве только мы увидели, что слушающий socket не мёртв совсем, а отвечает. Он работает по какой-то своей внутренней логике, а не просто умер.

Журнал windows

Решил посмотреть может что в журнале событий windows есть что-то интересное. Для этого захожу в журнал.

Панель управления-> Администрирование-> Управление компьютером-> Служебные программы-> Просмотр событий-> Журналы Windows

Либо запустите eventvwr.msc

Там, разумеется, есть миллионы записей. И чтобы не копаться в этих миллионах, я делаю следующее. Убиваю socket. Захожу в журнал и чищу подразделы. Захожу в браузер пытаюсь скачать файл. Захожу в журнал и смотрю что там только что появилось.

К сожалению, никаких событий, кусающихся моей проблемы, не появилось. Я даже нашёл такой раздел Microsoft/Windows/TCPIP. Но кроме одинокой записи работает, там ничего не было.

Финал?

Поиск в интернете всей доступной информации по проблеме периодически выдавал мне страницы подобной этим:

• Стр1

• Стр2

• Стр3

И ещё во многих других местах.

Отсюда я сделала 2 вывода я со соей проблемой не одинок, и как минимум периодически с ней сталкиваются и другие.

Есть ещё 2 параметра TCP стека с которыми можно поэкспериментировать.

1. TcpNumConnections - максимальное количество одновременных подключений в системе.

2. TcpMaxDataRetransmissions - количество повторных посылок при неудаче.

Поиск по этим параметрам для Windows 10 ничего не дал. Только для Windows 2003-2008 Server. Может плохо искал (наверняка). Но я всё же решил их проверить.

Установил следующие значения:

TcpNumConnections REG_DWORD: 00fffffe (hex)

TcpMaxDataRetransmissions REG_DWORD: 00000005 (hex)

Перезагрузился. Повторил в который раз все процедуры. И.

Socket жив. Всё проверив несколько раз, путём добавления и удаления из реестра параметров с последующей перезагрузкой компьютера. Все эксперименты показали, что с параметрами socket остаётся жив. Это всё?

В этом месте был завершающий текст с выводами и размышления на тему почему именно эти параметры помогли.

Но.

На следующий день, я решил закрепить полученную информацию. Запускаю эксперимент socket мёртв. Мы вернулись к тому, с чего начинали!

Эти параметры оказались бесполезны в решении нашей проблемы. Но я их всё-таки оставил потому как по смыслу они полезные.

Продолжаем.

Финал.

Продолжая эксперименты, я обнаружил в коде один хитрый перехватчик исключений на слушающим socket. Точка остановки в этом месте показала, что при возникновении нашего случая сюда начали валится куча exception со следующим сообщением:

Удаленный хост принудительно разорвал существующее подключение.

В этом exсeption была паузу. С пояснением исключение на socket случай неординарный, например socket занят другим приложением, делаем паузу что бы всё утряслось и в лог не сыпалось миллионы сообщений.

Как оказалось не неординарный.

Картина сложилась.

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

Ради интереса провёл эксперимент. Убил socket. Ввёл команду netstat -an. И не увидел ни одного socket клиента на нашем socket сервера. Хотя в приёмном socket сервера висело куча мёртвых подключений.

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

Выводы.

Ну что ж. Я, конечно, ожидал что геройски одержу победу над некоей эпичной ошибкой. А всё оказалось очень банально. Собственно, как всегда.

Все эксперименты у меня заняли где-то полтора дня. Эту статью я писал намного больше.

Из плюсов цель эксперимента достигнута. Сервер провёл часы под нагрузкой, вряд ли я бы столько тестировал его, не будь этой ошибки. Плюс я отдельно проверил некоторые важные механизмы работы сервера. Т.к. искал ошибку эта проверка была интересна. Если бы просто проверял то это была бы наискучнейшая работа.

Узнал новую информацию по поводу работы сети эти знания пригодятся впоследствии при решения очередного непонятного бага.

Почему у меня заняло так много времени на поиск банального Delay? Я думал над этим и пришёл к выводу, что все эксперименты уводили в сторону от ответа. Сложившееся картина показывала нам что умирал именно socket. Переставал принимать подключения. Спустя время оживал. Все сниферы показывали, что подключений не происходит.

Опять же было неправильное представление, что серверный socket работает в отдельном потоке. И в любом случае должен принимать клиентов. Поэтому я и скал проблему в настройках socket и tcp стека. Главная проблема я думал поток висит на socket. А в нашем аварийном случае он висел на exeption в Delay.

Я люблю открытое ПО. Я начал разрабатывать сторонний проект с открытым исходным кодом в 2006 году, и это был секрет развития моей карьеры. Благодаря моим экспериментам того времени, надеюсь, я вырос как разработчик и возвращаю что-то сообществу Open Source. По-моему мнению, открытый исходный код это драйвер роста компаний и разработчиков. И сегодня я хочу рассказать о своём опыте начавшейся в 2018 году работы над платформой low-code с открытым исходным кодом под названием RawCMS.

Провал

RawCMS начиналась как сторонний проект по улучшению будущего Asp.net core 3.1 и изучению возможности работы с неструктурированными данными для ускорения процесса разработки.

Во время разработки я столкнулся со многими проблемами и, наконец, пришёл к работающему доказательству концепции. Результат был колоссальным, и я должен много раз поблагодарить всех его участников (а их более 20).

Мы преодолели все технические ограничения и заставили программу работать. Некоторые темы были самыми современными, это позволило принять участие в важнейших европейских конференциях .Net, чтобы рассказать, чему мы научились.

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

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

Разрешение всей сложности, с которой мы столкнулись на своём пути, было великолепным, но, чтобы бороться со сложностью, нам нужна была сложность. Это мешало первоначально разобраться в логике приложения и внести в него свой вклад.

Вся эта сложность пугала разработчиков на подходе.

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

На этом этапе, прежде чем забыть о проекте, я хотел подумать о том, что сработало, а что нет в ретроспективе.

Окончательный вывод: для наших нужд мы выбрали худшую технологию.

Чтобы убедить человека внутри меня, который отказался от правды, я переосмыслил проект с самого начала. Используя Symfony вместо .Net, я потратил на работу чуть больше двух дней и получил работающее доказательство концепции. Я реализовал не весь набор функций, но почти уверен, что в новых обстоятельствах мы не обнаружим большое количество проблем. Это многому меня научило.

Как я смог за два дня сделать то же, что за два года?

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

Подходящий инструмент

Я не опоздал с .Net. Работаю с платформой с 2005 года, реализовал множество крупных корпоративных проектов, и меня приглашали на множество конференций, чтобы я поделился своим опытом.

Но я просто подобрал не тот инструмент для стороннего проекта. Я по-прежнему считаю, что .Net вероятно, лучший фреймворк для корпоративных приложений, а язык C# не имеет себе равных, с точки зрения производительности и впечатлений от разработки.

Проблема заключалась вот в чём: я выбрал .NET только потому, что это был фреймворк, в котором я чувствую себя более уверенно. Для меня выбор .Net был возможностью успеха. И я ошибался.

С тех пор как я начал этот проект, мне пришлось справляться с некоторыми функциями, которые .Net не поддерживает нативно; каждая отдельная проблема была преодолением.Я говорю об управлении нетипизированными данными (в частности маппинг и GraphQL), имея плагинную архитектуру и встраивая в неё модульный SPA.

Кстати, когда я попытался повторить то же самое с Symfony, то обнаружил, что этот функционал уже готов к использованию. Каждая из упомянутых возможностей оказалась включённой во фреймворк функцией, поэтому мне просто нужно было собрать всё вместе, а не изобретать что-то. Первой моей ошибкой был выбор неподходящего инструмента для работы.

Упорствовать вошибке от лукавого

Ошибки от человека, но упорство в ошибке от лукавого. Пытаясь заставить всё работать, я понял это на собственном опыте. Для меня это был важный урок.Сдаться перед огромной проблемой не всегда проявление слабости, а иногда, может быть, доказательство того, что вы умны. Я не остановился перед трудностями и победил зверя, но что потом?

Цена проделанной работы, как и её трудность, была огромной, я имею в виду, что много времени и усилий потрачено впустую, за исключением замечательного опыта и компетенций, которые позволили мне (виртуально) путешествовать по миру и рассказывать свою историю.

Что я понял? Вместе нам никогда не приходилось сдаваться перед проблемой, но столкнувшись со сложностью один на один...

Спросите себя, в чём проблема в самой проблеме или в вас?

Ещё до кодинга расскажите, как видите продукт

Большая проблема, с которой я столкнулся на этом проектом, порог вхождения в проект был очень высокий. Это оказалось весьма болезненным для меня: пришлось потратить много времени, чтобы помочь контрибьюторам в настройке рабочего окружения и в том, чтобы понять и реализовать задачу.

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

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

Этого бы не произошло, если бы система была проще и была основана на популярном фреймворке, таком как Symphony, с сообществом, где разработчики смогли бы найти ответы на свои вопросы.

Итак, благодаря этому проекту я научился делиться тем, как вижу проект, и хорошо объяснять цель проекта. Иметь контрибьюторов это замечательно, но, если они не смогут помочь, проект останется у вас на плечах, и единственным результатом вашей работы окажется обучение людей тому, от чего они вскоре откажутся.

Выводы

Мне по-прежнему нравится вносить свой вклад в мир открытого исходного кода. Думая о потраченном на RawCMS времени, на самом деле я не чувствую, что оно вообще потеряно.

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

И вот какую пользу я извлёк из этого опыта:

• Многое узнал о современных технологиях, что умножает мою ценность как профессионала.

• Был приглашён на множество международных конференций, чтобы прояснить то, чему научился.

• Помог начинающим разработчикам сделать первый шаг.

• Встретил много замечательных людей, которые, как и я, верят в дух открытого исходного кода.

• Вернул что-то сообществу открытого ПО.

Что ж, глядя на все эти нематериальные результаты, я действительно счастлив, что потратил два года своего свободного времени на неудачный проект.

Но ценный опыт можно получить и проще, например прокачав себя в разработке на направлении C#-разработчик. На нём можно не только повысить свою квалификацию, но и пообщаться с опытными менторами, которые разъяснят непонятные моменты.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Поговорим о способах ограничить число исходящих запросов враспределенном приложении. Это нужно, если внешний API непозволяет обращаться кнему тогда, когда вам вздумается.

Вводные

Для начала немного вводных. Есть наше приложение иесть некий внешний сервис. Например, какое-то банковское ПО, API для отслеживания почтовых отправлений, что угодно. При этом наше приложение непросто использует его, там куча очень важной для нас информации. Прибыль компании напрямую зависит отобъема выгруженных оттуда данных. Мыпонимаем, один сервер это слишком мало изаводим себе пару десятков машин. Чтобы приложение масштабировалось лучше, делаем так: разбиваем весь объем намаленькие задачи иотправляем ихвочередь. Каждый сервер извлекает ихоттуда поодной. Втаком сообщении указан, например, IDпользователя. Затем приложение скачивает данные для него исохраняет ихвбазе. Большая ибыстрая машина обработает много задач, маленькая имедленная поменьше.

Создатели внешнего сервиса понимают, что, если неограничивать наше взаимодействие, они начнут отказывать вобслуживании другим клиентам. Поэтому вводится лимит назапросы: теперь разрешено неболее 1000 одновременных обращений кним.

Немного подумав над условиями задачи находим решение семафор. Ондопускает, чтобы одновременно вкритической секции было не болееN потоков выполнения. Когда внутри скапливается предельное ихколичество новые желающие ожидают навходе. Кто-то выходит значит кто-то ещё может войти.

Один семафор на машину

Делим лимит запросов начисло доступных серверов (1000/20) иполучаем по50конкурентных обращений намашину.

private const int RequestsLimit = 50;private static readonly SemaphoreSlim Throttler =   new SemaphoreSlim(RequestsLimit);async Task<HttpResponseMessage> InvokeServiceAsync(HttpClient client){try{await Throttler.WaitAsync().ConfigureAwait(false);return await client.GetAsync("todos/1").ConfigureAwait(false);}finally{Throttler.Release();}}

В .NET Core можно сделать типизированный HttpClient, получится очень вдухе новых веяний, янебуду останавливаться наэтом подробнее, новыможете посмотреть сюда. Там ивцелом такой подход раскрывается детальнее, чем яделаю это здесь.

Попробуем проанализировать то, что получилось.

Вэтой конфигурации будут возникать ситуации, когда одна машина свободна, адругие перегружены. Этого можно избежать, беря задачу вработу при условии, что наконкретном сервере число сообщений вобработке недостигло предела. Тогда возникнет другая проблема как только задача выполнится занять еёместо будет некому, сперва потребуется получить новое сообщение изочереди. Можно постоянно держать систему слегка перегруженной это приведет ктому, что некоторые задачи-неудачники долго будут висеть навходе вкритическую секцию. Вцелом, утакого подхода есть потенциал, сним можно достигнуть хорошей производительности снебольшим тюнингом ипри определенных условиях.

Подведем ему некий итог:

Плюсы:

1. Простой код

2. Ресурсы машины используются эффективно

Минусы:

1. Не полностью утилизируется канал во внешний сервис

Один семафор на всех

Подумаем, вкакую сторону двинуться теперь. Попробуем сделать семафор общим ресурсом для всех серверов. Так тоже без проблем необойдется будет нужно тратить время перед каждым запросом вовнешнюю систему наобращение ксервису-throttler-у. Ноадминистрировать такое, наверное, проще засостоянием одного семафора легче следить, ненадо подбирать лимит под каждую машину вотдельности. Какже сделать общий троттлер? Ну, конечноже вRedis.

Сточки зрения пользователя Redis однопоточный (онтак выглядит). Это круто, большая часть проблем сконкурентным доступом кнему сразу снимается.

ВRedis нет готового семафора, номожно построить его насортированных множествах.

Писать код для него будем наLua. Интерпретатор Lua встроен вRedis, такие скрипты выполняются одним махом, атомарно. Мымоглибы без этого обойтись, нотак код получится ещё сложнее, придется учитывать конкуренцию между серверами заотдельные команды.

Теперь подумаем, что писать. Учтём, что машина, взявшая блокировку, может никогда еёнеотпустить. Вдруг кто-то решит выключить рубильник или что-то пойдет непоплану вмомент обновления нашего приложения. Учтём также, что унас может быть несколько таких семафоров. Это пригодится, например, для разных внешних сервисов, API-ключей или если мызахотим выделить отдельный канал под приоритетные запросы.

--[[  KEYS[1] - Имя семафора ARGV[1] - Время жизни блокировки ARGV[2] - Идентификатор блокировки, чтобы её можно было возвратить ARGV[3] - Доступный объем семафора ]]--   -- Будем использовать команды с недетерминированным результатом,  -- Redis-у важно знать заранее redis.replicate_commands()local unix_time = redis.call('TIME')[1]   -- Удаляем блокировки с истёкшим TTL redis.call('ZREMRANGEBYSCORE', KEYS[1], '-inf', unix_time - ARGV[1])   -- Получаем число элементов в множестве local count = redis.call('zcard', KEYS[1])   if count < tonumber(ARGV[3]) then-- добавляем блокировку в множество, если есть место  -- время будет являться ключем сортировки (для последующий чистки записей) redis.call('ZADD', KEYS[1], unix_time, ARGV[2])       -- Возвращаем число взятых блокировок (например, для логирования)    return count end   return nil

Чтобы освободить блокировку будем удалять элемент изсортированного множества. Это одна команда. Обойдемся без отдельного скрипта, многие клиенты вт.ч.идля .NET это умеют.

Подробнее о вариантах реализации блокировок с Redis и семафоров в частности можно посмотреть здесь.

Иногда внешний сервис ограничивает число обращений другим образом, например, разрешает делать неболее 1000 запросов вминуту. Вэтом случае вRedis можно завести счётчик сфиксированным временем жизни.

Вкоде нашего приложения сделаем оболочку вокруг написанного скрипта, некий класс, экземпляр которого заменит семафор изпервого варианта.

public sealed class RedisSemaphore{private static readonly string AcquireScript = "...";private static readonly int TimeToLiveInSeconds = 300;private readonly Func<ConnectionMultiplexer> _redisFactory;public RedisSemaphore(Func<ConnectionMultiplexer> redisFactory){_redisFactory = redisFactory;}public async Task<LockHandler> AcquireAsync(string name, int limit){var handler = new LockHandler(this, name);do{var redisDb = _redisFactory().GetDatabase();var rawResult = await redisDb.ScriptEvaluateAsync(AcquireScript, new RedisKey[] { name },new RedisValue[] { TimeToLiveInSeconds, handler.Id, limit }).ConfigureAwait(false);var acquired = !rawResult.IsNull;if (acquired)break;await Task.Delay(10).ConfigureAwait(false);} while (true);return handler;}public async Task ReleaseAsync(LockHandler handler, string name){var redis = _redisFactory().GetDatabase();await redis.SortedSetRemoveAsync(name, handler.Id).ConfigureAwait(false);}}public sealed class LockHandler : IAsyncDisposable{private readonly RedisSemaphore _semaphore;private readonly string _name;public LockHandler(RedisSemaphore semaphore, string name){_semaphore = semaphore;_name = name;Id = Guid.NewGuid().ToString();}public string Id { get; }public async ValueTask DisposeAsync(){await _semaphore.ReleaseAsync(this, _name).ConfigureAwait(false);}}

Посмотрим, что получилось.

Плюсы:

1. Просто конфигурировать лимит

2. Канал используется эффективно

3. Легко наблюдать за утилизацией канала

Минусы:

1. Дополнительный элемент инфраструктуры

2. Ещё одна точка отказа

3. Накладные расходы на обращение к Redis-у

4. Нетривиальный код

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

Легкость настройки такой блокировки это существенный плюс. Не надо все перенастраивать при каждом масштабировании, подбирать лимиты под машины. Можно следить за утилизацией канала в графане, это удобно.

Думаю, можно реализовать троттлинг исходящих запросов инауровне инфраструктуры, номне кажется удобным иметь вкоде контроль над состоянием блокировки. Кроме того, настроить это в чужих облаках наверняка будет непросто. Авам приходилось когда-нибудь ограничивать число исходящих запросов? Как делаете этовы?

Minecraft Server Query это простой протокол, позволяющий получить актуальную информацию о состоянии сервера путём отправки пары-тройки незамысловатых UDP-пакетов.

На вики есть подробное описание этого протокола с примерами реализации на разных языках. Однако меня поразило, насколько куцые реализации для .Net существуют на данный момент. Поискав некоторое время, я наткнулся на несколько репозиториев. Предлагаемые решения либо содержали банальные ошибки, либо имели урезанный функционал, хотя, казалось бы, куда ещё больше урезать-то.

Так было принято решение написать свою реализацию.

Скажи мне, кто ты...

Для начала, посмотрим, что из себя представляет сам протокол Minecraft Query. Согласно вики, мы имеем в распоряжении 3 вида пакетов запросов и, соотвественно, 3 вида пакетов ответа:

• Handshake

• BasicStatus

• FullStatus

Первый тип пакета используется для получения ChallengeToken, необходимого для формирования других двух пакетов. Привязывается он к IP-адресу отправителя на 30 секунд. Смысловая нагрузка оставшихся двух ясна из названий.

Стоит отметить, что хотя последние два запроса отличаются друг от друга лишь выравниванием на концах пакетов, присылаемые ответы отличаются способом представления данных. Для примера, вот так выглядит ответ BasicStatus

А вот так FullStatus

Все данные, помимо тех, что хранятся в short, представлены в big-endian. А для поля SessionId, которое постоянно в рамках одного клиент-сервер соединения, должно выполняться условие SessionId & 0x0F0F0F0F == SessionId.

В общем виде запрос выглядит так

Более подробно об этом об этом можно почитать на вики.

И я скажу тебе, как тебя распарсить

Для начала, определимся, что мы хотим получить на выходе. Готовая библиотека должна предоставлять API для отправки любого из 3 видов пакетов и получения результата в распаршеном виде.

При этом, я хочу больше свободы в плане поддержания жизнеспособности сокетов и обновления ChallengeToken. Если я буду запрашивать состояние сервера каждые 3 секунды, то я не хочу, чтобы вместо одного пакета запроса отправлялось два: хэндшейк и состояние. И наоборот, если я опрашиваю сервер раз в час, зачем мне слать запросы каждые 30 секунд? Поэтому работа с библиотекой будет происходить в "ручном" режиме.

Итак, определившись, можем уже представить, как будет выглядеть архитектура классов. Я вижу работу примерно таким образом

public static async Task<ServerState> DoSomething(IPAddress host, int port) {var mcQuery = new McQuery(host, port);  mcQuery.InitSocket();  await mcQuery.GetHandshake();  return await mcQuery.GetFullStatus();}

Здесь создаётся разовое соединение. Для долгоживущего потребуется проверять состояние сокета и инициализировать заново (об этом в конце статьи).

Для того, чтобы пакет отправить, его надо для начала сформировать. Этим будет заниматься класс Request.

public class Request{// Набор констант для формирования пакета    private static readonly byte[] Magic = { 0xfe, 0xfd };    private static readonly byte[] Challenge = { 0x09 };    private static readonly byte[] Status = { 0x00 };      public byte[] Data { get; private set; }        private Request(){}    public byte RequestType => Data[2];    public static Request GetHandshakeRequest(SessionId sessionId)    {        var request = new Request();              // Собираем пакет        var data = new List<byte>();        data.AddRange(Magic);        data.AddRange(Challenge);        data.AddRange(sessionId.GetBytes());                request.Data = data.ToArray();        return request;    }    public static Request GetBasicStatusRequest(SessionId sessionId, byte[] challengeToken)    {        if (challengeToken == null)        {            throw new ChallengeTokenIsNullException();        }                    var request = new Request();                var data = new List<byte>();        data.AddRange(Magic);        data.AddRange(Status);        data.AddRange(sessionId.GetBytes());        data.AddRange(challengeToken);                request.Data = data.ToArray();        return request;    }        public static Request GetFullStatusRequest(SessionId sessionId, byte[] challengeToken)    {        if (challengeToken == null)        {            throw new ChallengeTokenIsNullException();        }                var request = new Request();                var data = new List<byte>();        data.AddRange(Magic);        data.AddRange(Status);        data.AddRange(sessionId.GetBytes());        data.AddRange(challengeToken);        data.AddRange(new byte[] {0x00, 0x00, 0x00, 0x00}); // Padding                request.Data = data.ToArray();        return request;    }}

Здесь всё просто. Храним все константы внутри класса и формируем пакет в трёх статических методах. Можно ещё заметить класс SessionId, который может давать как байтовое, так и строковое представление по необходимости.

public class SessionId{    private readonly byte[] _sessionId;    public SessionId (byte[] sessionId)    {        _sessionId = sessionId;    }// Случайный SessionId    public static SessionId GenerateRandomId()    {        var sessionId = new byte[4];        new Random().NextBytes(sessionId);        sessionId = sessionId.Select(@byte => (byte)(@byte & 0x0F)).ToArray();        return new SessionId(sessionId);    }    public string GetString()    {        return BitConverter.ToString(_sessionId);    }    public byte[] GetBytes()    {        var sessionId = new byte[4];        Buffer.BlockCopy(_sessionId, 0, sessionId, 0, 4);        return sessionId;    }}

Дождавшись ответа сервера, мы получаем последовательность байт, которые хотим привести к человекочитаемому виду. Для этого служит класс Response, который представляет набор "парсеров" в виде статических полей.

public static class Response{public static byte ParseType(byte[] data){return data[0];}  // public static SessionId ParseSessionId(byte[] data){if (data.Length < 1) throw new IncorrectPackageDataException(data);var sessionIdBytes = new byte[4];Buffer.BlockCopy(data, 1, sessionIdBytes, 0, 4);return new SessionId(sessionIdBytes);}public static byte[] ParseHandshake(byte[] data){if (data.Length < 5) throw new IncorrectPackageDataException(data);var response = BitConverter.GetBytes(int.Parse(Encoding.ASCII.GetString(data, 5, data.Length - 6)));if (BitConverter.IsLittleEndian){response = response.Reverse().ToArray();}return response;}public static ServerBasicState ParseBasicState(byte[] data){if (data.Length <= 5)throw new IncorrectPackageDataException(data);var statusValues = new Queue<string>();short port = -1;data = data.Skip(5).ToArray(); // Skip Type + SessionIdvar stream = new MemoryStream(data);var sb = new StringBuilder();int currentByte;int counter = 0;while ((currentByte = stream.ReadByte()) != -1){if (counter > 6) break;      // Парсим нормер портаif (counter == 5){byte[] portBuffer = {(byte) currentByte, (byte) stream.ReadByte()};if (!BitConverter.IsLittleEndian)portBuffer = portBuffer.Reverse().ToArray();port = BitConverter.ToInt16(portBuffer); // Little-endian shortcounter++;continue;}      // Парсим параметры-строкиif (currentByte == 0x00){string fieldValue = sb.ToString();statusValues.Enqueue(fieldValue);sb.Clear();counter++;}else sb.Append((char) currentByte);}var serverInfo = new ServerBasicState{Motd = statusValues.Dequeue(),GameType = statusValues.Dequeue(),Map = statusValues.Dequeue(),NumPlayers = int.Parse(statusValues.Dequeue()),MaxPlayers = int.Parse(statusValues.Dequeue()),HostPort = port,HostIp = statusValues.Dequeue(),};return serverInfo;}  // "Секции" пакета резделены константными последовательностями байт,  // это можно испльзовать для проверки, что мы всё сделали правильноpublic static ServerFullState ParseFullState(byte[] data){var statusKeyValues = new Dictionary<string, string>();var players = new List<string>();var buffer = new byte[256];Stream stream = new MemoryStream(data);stream.Read(buffer, 0, 5); // Read Type + SessionIDstream.Read(buffer, 0, 11); // Padding: 11 bytes constantvar constant1 = new byte[] {0x73, 0x70, 0x6C, 0x69, 0x74, 0x6E, 0x75, 0x6D, 0x00, 0x80, 0x00};for (int i = 0; i < constant1.Length; i++)Debug.Assert(constant1[i] == buffer[i], "Byte mismatch at " + i + " Val :" + buffer[i]);var sb = new StringBuilder();string lastKey = string.Empty;int currentByte;while ((currentByte = stream.ReadByte()) != -1){if (currentByte == 0x00){if (!string.IsNullOrEmpty(lastKey)){statusKeyValues.Add(lastKey, sb.ToString());lastKey = string.Empty;}else{lastKey = sb.ToString();if (string.IsNullOrEmpty(lastKey)) break;}sb.Clear();}else sb.Append((char) currentByte);}stream.Read(buffer, 0, 10); // Padding: 10 bytes constantvar constant2 = new byte[] {0x01, 0x70, 0x6C, 0x61, 0x79, 0x65, 0x72, 0x5F, 0x00, 0x00};for (int i = 0; i < constant2.Length; i++)Debug.Assert(constant2[i] == buffer[i], "Byte mismatch at " + i + " Val :" + buffer[i]);while ((currentByte = stream.ReadByte()) != -1){if (currentByte == 0x00){var player = sb.ToString();if (string.IsNullOrEmpty(player)) break;players.Add(player);sb.Clear();}else sb.Append((char) currentByte);}ServerFullState fullState = new(){Motd = statusKeyValues["hostname"],GameType = statusKeyValues["gametype"],GameId = statusKeyValues["game_id"],Version = statusKeyValues["version"],Plugins = statusKeyValues["plugins"],Map = statusKeyValues["map"],NumPlayers = int.Parse(statusKeyValues["numplayers"]),MaxPlayers = int.Parse(statusKeyValues["maxplayers"]),PlayerList = players.ToArray(),HostIp = statusKeyValues["hostip"],HostPort = int.Parse(statusKeyValues["hostport"]),};return fullState;}}

Таким образом мы получаем полный инструментарий для формирования пакетов, их отправки, получения ответов и извлечения из них необходимой информации.

Долгоживущие приложения на основе библиотеки

Вернёмся к том, о чем я говорил выше. Это можно реализовать таким образом. Код взят из моего нотификатора пользовательской активности. Здесь каждые 5 секунд запрашивается FullStatus, поэтому имеет смысл обновлять ChallengeToken периодически сразу после истечения предыдущего. Всего приложение имеет 2 режима работы: штатный и режим восстановления соединения.

В штатном режиме приложение по таймерам обновляет токен и запрашивает FullStatus. При обнаружении упавшего сервера/оборванного соединения/etc (5 попыток передачи) приложение переходит в режим восстановления соединения и при удачной попытке получения сообщения снова возвращается в штатный режим.

Для начала напишем конструктор и два метода для запуска прослушивания сервера и окончания.

public StatusWatcher(string serverName, string host, int queryPort){    ServerName = serverName;    _mcQuery = new McQuery(Dns.GetHostAddresses(host)[0], queryPort);    _mcQuery.InitSocket();}public async Task Unwatch(){    await UpdateChallengeTokenTimer.DisposeAsync();    await UpdateServerStatusTimer.DisposeAsync();}public async void Watch(){  // Обновляем challengetoken по таймеру каждые 30 секунд    UpdateChallengeTokenTimer = new Timer(async obj =>    {        if (!IsOnline) return;                if(Debug)            Console.WriteLine($"[INFO] [{ServerName}] Send handshake request");        try        {            var challengeToken = await _mcQuery.GetHandshake();                      // Если всё ок, говорим, что мы в онлайне и сбрасываем счетчик попыток            IsOnline = true;                      lock (_retryCounterLock)            {                RetryCounter = 0;            }                        if(Debug)                Console.WriteLine($"[INFO] [{ServerName}] ChallengeToken is set up: " + BitConverter.ToString(challengeToken));        }              // Если что-то не так, увеличиваем счетчик неудачных попыток        catch (Exception ex)        {            if (ex is SocketException || ex is McQueryException || ex is ChallengeTokenIsNullException)            {                if(Debug)                    Console.WriteLine($"[WARNING] [{ServerName}] [UpdateChallengeTokenTimer] Server doesn't response. Try to reconnect: {RetryCounter}");                if(ex is McQueryException)                    Console.Error.WriteLine(ex);                                lock (_retryCounterLock)                {                    RetryCounter++;                    if (RetryCounter >= RetryMaxCount)                    {                        RetryCounter = 0;                        WaitForServerAlive(); // Переходим в режим восстановления соединения                    }                }            }            else            {                throw;            }        }            }, null, 0, GettingChallengeTokenInterval);            // По таймеру запрашиваем текущее состояние    UpdateServerStatusTimer = new Timer(async obj =>    {        if (!IsOnline) return;                if(Debug)            Console.WriteLine($"[INFO] [{ServerName}] Send full status request");        try        {            var response = await _mcQuery.GetFullStatus();                        IsOnline = true;            lock (_retryCounterLock)            {                RetryCounter = 0;            }                        if(Debug)                Console.WriteLine($"[INFO] [{ServerName}] Full status is received");                        OnFullStatusUpdated?.Invoke(this, new ServerStateEventArgs(ServerName, response));        }              // По аналогии с предыдущим        catch (Exception ex)        {            if (ex is SocketException || ex is McQueryException || ex is ChallengeTokenIsNullException)            {                if(Debug)                    Console.WriteLine($"[WARNING] [{ServerName}] [UpdateServerStatusTimer] Server doesn't response. Try to reconnect: {RetryCounter}");                if(ex is McQueryException)                    Console.Error.WriteLine(ex);                                lock (_retryCounterLock)                {                    RetryCounter++;                    if (RetryCounter >= RetryMaxCount)                    {                        RetryCounter = 0;                        WaitForServerAlive();                    }                }            }                        else            {                throw;            }        }            }, null, 500, GettingStatusInterval);}

Осталось только реализовать ожидание восстановления соединения. Для этого нам достаточно убедиться, что мы получили хоть какой-то ответ от сервера. Для этого мы можем воспользоваться тем же запросом хэндшейка, который не требует наличия действующего ChallengeToken.

public async void WaitForServerAlive(){    if(Debug)        Console.WriteLine($"[WARNING] [{ServerName}] Server is unavailable. Waiting for reconnection...");  // Отключаем отслеживание    IsOnline = false;    await Unwatch();    _mcQuery.InitSocket(); // Пересоздаём сокет    Timer waitTimer = null;    waitTimer = new Timer(async obj => {        try        {            await _mcQuery.GetHandshake();          // Говорим, что можно возвращаться в штатный режим и отключаем таймер            IsOnline = true;            Watch();            lock (_retryCounterLock)            {                RetryCounter = 0;            }            waitTimer.Dispose();        }            // Пересоздаем сокет каждые 5 (настраивается) неудачных соединений        catch (SocketException)        {            if(Debug)                Console.WriteLine($"[WARNING] [{ServerName}] [WaitForServerAlive] Server doesn't response. Try to reconnect: {RetryCounter}");            lock (_retryCounterLock)            {                RetryCounter++;                if (RetryCounter >= RetryMaxCount)                {                    if(Debug)                        Console.WriteLine($"[WARNING] [{ServerName}] [WaitForServerAlive] Recreate socket");                    RetryCounter = 0;                    _mcQuery.InitSocket();                }            }        }    }, null, 500, 5000);}

Важное вступление

В гайде описывается формирование отсоединенной подписи вформате PKCS7 (рядом с файлом появится файл в формате .sig). Такую подпись может запросить нотариус, ЦБ и любой кому нужно долгосрочное хранения подписанного документа. Удобство такой подписи в том, что при улучшении ее до УКЭП CAdES-X Long Type 1 (CMS Advanced Electronic Signatures [1]) в нее добавляется штамп времени, который генерирует TSA (Time-Stamp Protocol [2]) и статус сертификата на момент подписания (OCSP [3]) - подлинность такой подписи можно подтвердить по прошествии длительного периода (Усовершенствованная квалифицированная подпись [4]).

Код основан на репозиториях corefx и DotnetCoreSampleProject - в последнем проще протестировать свои изменения перед переносом в основной проект и он будет отправной точкой по сборке corefx. Судя по записям с форума компании [5], решение для .NET Core в стадии бета-тестирования. Далее по тексту я также буду ссылаться на этот форум. Разработка велась в Visual Studio Community 2019.

Для получения штампа времени использован TSP-сервис http://qs.cryptopro.ru/tsp/tsp.srf

Что имеем на входе?

1. КриптоПро CSP версии 5.0 - для поддержки Российских криптографических алгоритмов (подписи, которые выпустили в аккредитованном УЦ в РФ)

2. КриптоПро TSP Client 2.0 - нужен для штампа времени

3. КриптоПро OCSP Client 2.0 - проверит не отозван ли сертификат на момент подписания

4. КриптоПро .NET Client - таков путь

5. Любой сервис по проверке ЭП - я использовал Контур.Крипто как основной сервис для проверки ЭП и КриптоАРМ как локальный. А еще можно проверить ЭП на сайте Госуслуг

6. КЭП по ГОСТ Р 34.11-2012/34.10-2012 256 bit, которую выпустил любой удостоверяющий центр

Так, а что надо на выходе?

А на выходе надо получить готовое решение, которое сделает отсоединенную ЭП в формате .sig со штампом времени на подпись и доказательством подлинности. Для этого зададим следующие критерии:

1. ЭП проходит проверку на протале Госуслуг, через сервис для подтверждения подлинности ЭП формата PKCS#7 в электронных документах;

2. КриптоАРМ после проверки подписи

   1. Заполнит поле "Время создания ЭП" - в конце проверки появится окно, где можно выбрать ЭП и кратко посмотреть ее свойства

      Стобец "Время создация ЭП"

   2. В информации о подписи и сертификате (двойной клик по записе в таблице) на вкладке "Штампы времени" в выпадающем списке есть оба значения и по ним заполнена информация:

      1. Подпись:

         

      2. Доказательства подлинности:

         

   3. В протоколе проверки подписи есть блоки "Доказательства подлинности", "Штамп времени на подпись" и "Время подписания". Для сравнения: если документ подписан просто КЭП, то отчет по проверке будет достаточно коротким в сравнении с УКЭП.

3. Контур.Крипто при проверке подписи выдаст сообщение, что совершенствованная подпись подтверждена, сертификат на момент подписания действовал и указано время создания подпись:

   Усовершенствованная подпись подтверждена

Соберем проект с поддержкой ГОСТ Р 34.11-2012 256 bit

Гайд разделен на несколько этапов. Основная инструкция по сборке опубликована вместе с репозиторием DotnetCoreSampleProject - периодически я буду на нее ссылаться.

Первым делом создадим новую папку

... и положим туда все необходимое.

Инструкция делится на 2 этапа - мне пришлось выполнить оба, чтобы решение заработало. В папку добавьте подпапки .\runtime и .\packages

I - Сборка проекта без сборки corefx для Windows

1. Установите КриптоПро 5.0 и убедитесь, что у вас есть действующая лицензия. - для меня подошла втроенная в ЭП;

2. Установите core 3.1 sdk и runtime и распространяемый пакет Visual C++ для Visual Studio 2015 обычно ставится вместе со студией; прим.: на II этапе мне пришлось через установщик студии поставить дополнительное ПО для разработки на C++ - сборщик требует предустановленный DIA SDK.

3. Задайте переменной среды DOTNET_MULTILEVEL_LOOKUP значение 0 - не могу сказать для чего это нужно, но в оригинальной инструкции это есть;

4. Скачайте 2 файла из релиза corefx (package_windows_debug.zip и runtime-debug-windows.zip) - они нужны для корректной сборки проекта. В гайде рассматривается версия v3.1.1-cprocsp-preview4.325 от 04.02.2021:

   1. package_windows_debug.zip распакуйте в .\packages

   2. runtime-debug-windows.zip распакуйте в .\runtime

5. Добавьте источник пакетов NuGet в файле %appdata%\NuGet\NuGet.Config - источник должен ссылаться на путь .\packages в созданной вами папке. Пример по добавлению источника есть в основной инструкеии. Для меня это не сработало, поэтому я добавил источник через VS Community;

6. Склонируйте NetStandard.Library в .\ и выполните PowerShell скрипт (взят из основной инструкции), чтобы заменить пакеты в $env:userprofile\.nuget\packages\

   git clone https://github.com/CryptoProLLC/NetStandard.LibraryNew-Item -ItemType Directory -Force -Path "$env:userprofile\.nuget\packages\netstandard.library"Copy-Item -Force -Recurse ".\NetStandard.Library\nugetReady\netstandard.library" -Destination "$env:userprofile\.nuget\packages\"
   

7. Склонируйте репизиторий DotnetCoreSampleProject в .\

8. Измените файл.\DotnetSampleProject\DotnetSampleProject.csproj - для сборок System.Security.Cryptography.Pkcs.dll и System.Security.Cryptography.Xml.dll укажите полные пути к .\runtime;

9. Перейдите в папку проекта и попробуйте собрать решение. Я собирал через Visual Studio после открытия проекта.

II - Сборка проекта со сборкой corefx для Windows

1. Выполните 1-3 и 6-й шаги из I этапа;

2. Склонируйте репозиторий corefx в .\

3. Выполните сборку запустив .\corefx\build.cmd - на этом этапе потребуется предустановленный DIA SDK

4. Выполните шаги 5, 7-9 из I этапа. Вместо условного пути .\packages укажите .\corefx\artifacts\packages\Debug\NonShipping, а вместо .\runtime укажите .\corefx\artifacts\bin\runtime\netcoreapp-Windows_NT-Debug-x64

На этом месте у вас должно получиться решение, которое поддерживает ГОСТ Р 34.11-2012 256 bit.

Немного покодим

Потребуется 2 COM библиотеки: "CAPICOM v2.1 Type Library" и "Crypto-Pro CAdES 1.0 Type Library". Они содержат необходимые объекты для создания УКЭП.

В этом примере будет подписываться BASE64 строка, содержащая в себе PDF-файл. Немного доработав код можно будет подписать hash-значение этого фала.

Основной код для подписания был взят со страниц Подпись PDF с помощью УЭЦП- Page 2 (cryptopro.ru) и Подпись НЕОПРЕДЕЛЕНА при создании УЭЦП для PDF на c# (cryptopro.ru), но он использовался для штампа подписи на PDF документ. Код из этого гайда переделан под сохранение файла подписи в отдельный файл.

Условно процесс можно поделить на 4 этапа:

1. Поиск сертификата в хранилище - я использовал поиск по отпечатку в хранилище пользователя;

2. Чтение байтов подписанного файла;

3. Создание УКЭП;

4. Сохранение файла подписи рядом с файлом.

using CAdESCOM;using CAPICOM;using System;using System.Globalization;using System.IO;using System.Security.Cryptography;using System.Security.Cryptography.X509Certificates;using System.Security.Cryptography.Xml;using System.Text;using System.Threading.Tasks;using System.Xml;public static void Main(){  //Сертификат для подписиX509Certificate2 gostCert = GetX509Certificate2("отпечаток");  //Файл, который предстоит подписать  byte[] fileBytes = File.ReadAllBytes("C:\\Тестовое заявление.pdf");  //Файл открепленной подписи  byte[] signatureBytes = SignWithAdvancedEDS(fileBytes, gostCert);  //Сохранение файла подписи  File.WriteAllBytes("C:\\Users\\mikel\\Desktop\\Тестовое заявление.pdf.sig", signatureBytes);}//Поиск сертификата в хранилищеpublic static X509Certificate2 GetX509Certificate2(string thumbprint){  X509Store store = CreateStoreObject("My", StoreLocation.CurrentUser);  store.Open(OpenFlags.ReadOnly);  X509Certificate2Collection certCollection =    store.Certificates.Find(X509FindType.FindByThumbprint, thumbprint, false);  X509Certificate2Enumerator enumerator = certCollection.GetEnumerator();  X509Certificate2 gostCert = null;  while (enumerator.MoveNext())    gostCert = enumerator.Current;  if (gostCert == null)    throw new Exception("Certificiate was not found!");  return gostCert;}//Создание УКЭПpublic static byte[] SignWithAdvancedEDS(byte[] fileBytes, X509Certificate2 certificate){  string signature = "";    try  {    string tspServerAddress = @"http://qs.cryptopro.ru/tsp/tsp.srf";    CPSigner cps = new CPSigner();    cps.Certificate = GetCAPICOMCertificate(certificate.Thumbprint);    cps.Options = CAPICOM_CERTIFICATE_INCLUDE_OPTION.CAPICOM_CERTIFICATE_INCLUDE_WHOLE_CHAIN;    cps.TSAAddress = tspServerAddress;    CadesSignedData csd = new CadesSignedData();    csd.ContentEncoding = CADESCOM_CONTENT_ENCODING_TYPE.CADESCOM_BASE64_TO_BINARY;    csd.Content = Convert.ToBase64String(fileBytes);    //Создание и проверка подписи CAdES BES    signature = csd.SignCades(cps, CADESCOM_CADES_TYPE.CADESCOM_CADES_BES, true, CAdESCOM.CAPICOM_ENCODING_TYPE.CAPICOM_ENCODE_BASE64);    csd.VerifyCades(signature, CADESCOM_CADES_TYPE.CADESCOM_CADES_BES, true);        //Дополнение и проверка подписи CAdES BES до подписи CAdES X Long Type 1     //(вторая подпись остается без изменения, так как она уже CAdES X Long Type 1)    signature = csd.EnhanceCades(CADESCOM_CADES_TYPE.CADESCOM_CADES_X_LONG_TYPE_1, tspServerAddress, CAdESCOM.CAPICOM_ENCODING_TYPE.CAPICOM_ENCODE_BASE64);    csd.VerifyCades(signature, CADESCOM_CADES_TYPE.CADESCOM_CADES_X_LONG_TYPE_1, true);  }  catch (Exception ex)  {    throw ex;  }  return Convert.FromBase64String(signature);}

Пробный запуск

Для подписания возьмем PDF-документ, который содержит надпись "Тестовое заявление.":

Далее запустим программу и дождемся подписания файла:

Готово. Теперь можно приступать к проверкам.

Проверка в КриптоАРМ

Время создания ЭП заполнено:

Штамп времени на подпись есть:

Доказательства подлинности также заполнены:

В протоколе проверки есть блоки "Доказательства подлинности", "Штамп времени на подпись" и "Время подписания":

Важно отметить, что серийный номер параметров сертификата принадлежит TSP-сервису http://qs.cryptopro.ru/tsp/tsp.srf

Проверка на Госуслугах

Проверка в Контур.Крипто

Done.

Гайд написан с исследовательской целью - проверить возможность подписания документов УКЭП с помощью самописного сервиса на .NET Core 3.1 с формированием штампов подлинности и времени подписания документов.

Безусловно это решение не стоит брать в работу "как есть" и нужны некоторые доработки, но в целом оно работает и подписывает документы подписью УКЭП.

Это вообще законно?

С удовольствием узнаю ваше мнение в комментариях.

Ссылки на публичные источники

[1] CMS Advanced Electronic Signatures (CAdES) - https://tools.ietf.org/html/rfc5126#ref-ISO7498-2

[2] Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) - https://www.ietf.org/rfc/rfc3161.txt

[3] X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP - https://tools.ietf.org/html/rfc2560

[4] Усовершенствованная квалифицированная подпись Удостоверяющий центр СКБ Контур (kontur.ru)

[5] Поддержка .NET Core (cryptopro.ru)

[6] http://qs.cryptopro.ru/tsp/tsp.srf - TSP-сервис КриптоПро

UPD1: Поменял в коде переменную, куда записываются байты файла подписи.

Также я забыл написать немного про подпись штампа времени - он подписывается сертификатом владельца TSP-сервиса. По гайду это ООО "КРИПТО-ПРО":

Serilog на данный момент, пожалуй, самая популярная библиотека логирования для .NET. Зародилась эта библиотека ещё до появления платформы .NET Core, в которой разработчики платформы предложили своё видение подсистемы логирования приложения. В 2017 году Serilog создаёт библиотеку для интеграции в подсистему логирования .NET Core.

В этой серии статей мы пристально рассмотрим и проанализируем проблемы использования Serilog в .NET Core и постараемся ответить на вопрос как их решить?

В данной статье мы разберёмся с тем, какую роль в логировании играет глобальный логгер из библиотеки Serilog при интеграции Serilog в подсистему логирования .NET Core. А также выявим возможные проблемы и пути их решения.

Введение

В феврале 2013 года на github.com появился проект Opi, который уже через 6 дней получил знакомое имя Serilog. Этот проект изначально разрабатывался под .NET Framework 4.5. На момент его разработки, платформа .NET не предлагала из коробки никакого встроенного API логирования. На тот момент самыми популярными инструментами для решения этой задачи были NLog и log4net.

График на google trends.

Ещё до официального выхода первой версии .NET Core (27.06.2016) уже шли разговоры о поддержке этой платформы (как, например, тут). Сейчас уже сложно разобраться в подробностях тех времён и как начиналась поддержка .Net Core. Ясность наступает в августе 2017, когда на github.com был создан проект serilog-aspnetcore. Он изначально был разработан под .NET Standard 2.0, т.е. уже поддерживал использование в проектах .NET Core 2.0.

Но это была не переработка под .NET Core, а интеграция инструментов основной библиотеки Serilog в подсистему логирования .NET Core. Эта интеграция не подразумевала пересмотра подсистемы логирования Serilog через призму подходов, которые предлагает платформа .NET Core, как для расширения API логирования, так и для взаимодействия компонент приложения.

Предисловие

При написании статьи эксперименты проводились на платформе .NET Core 3.1. Модульные тесты написаны под xUnit. Для анализа использовались исходники актуальных на момент написания статьи версий библиотек Serilog:

• Serilog v2.10.0 https://github.com/serilog/serilog.git

• Serilog.AspNetCore v4.0.0 https://github.com/serilog/serilog-aspnetcore.git

• Serilog.Extensions.Logging v3.0.1 https://github.com/serilog/serilog-extensions-logging.git

• Serilog.Extensions.Hosting v4.1.1 https://github.com/serilog/serilog-extensions-hosting.git

Интеграция Serilog + .NET Core

В 100% случаев, когда Я сталкивался с применением Serilog, это был код одного из его примеров.

public static int Main(string[] args){    Log.Logger = new LoggerConfiguration()        .WriteTo.Console()        .CreateBootstrapLogger();    Log.Information("Starting up!");    try    {        CreateHostBuilder(args).Build().Run();        Log.Information("Stopped cleanly");        return 0;    }    catch (Exception ex)    {        Log.Fatal(ex, "An unhandled exception occured during bootstrapping");        return 1;    }    finally    {        Log.CloseAndFlush();    }}public static IHostBuilder CreateHostBuilder(string[] args) =>    Host.CreateDefaultBuilder(args)    .UseSerilog((context, services, configuration) => configuration                .ReadFrom.Configuration(context.Configuration)                .ReadFrom.Services(services)                .Enrich.FromLogContext()                .WriteTo.Console())    .ConfigureWebHostDefaults(webBuilder => { webBuilder.UseStartup<Startup>(); });

В этом примере мы видим, как разработчики Serilog предлагают его использовать:

• метод Main:

  • создаём глобальный статический логгер и конфигурируем для вывода в консоль. Это временно, пока не будет применена конфигурация приложения;

  • сообщаем о запуске приложения через глобальный логгер

  • запускаем хост приложения;

  • сообщаем об успешном останове приложения через глобальный логгер;

  • при необходимости логируем ошибку запуска приложения через глобальный логгер;

  • закрываем и флашим глобальный логгер;

• метод CreateHostBuilder:

  • интегрируем и конфигурируем Serilog, в том числе с помощью конфигурации приложения.

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

Далее в сервисах приложения, в контроллерах, если это вэб приложение, которые создаются с применением DI, можно получить логгер из подсистемы логирования .NET Core, записать туда лог и он попадёт в логгер Serilog и будет записан в соответствии с конфигурацией, определённой в методе CreateHostBuilder.

Глобальный логгер Как это работает?

Как написано в примере Program.cs перед инициализацией статического логгера:

The initial bootstrap logger is able to log errors during start-up. It's completely replaced by the logger configured in UseSerilog() below, once configuration and dependency-injection have both been set up successfully.

Т.е. инициализируется глобальный логгер, который действует до успешного вызова UseSerilog() при создании HostBuilder приложения. После чего он будет заменён на логгер, собранный в соответствии с конфигурацией приложения.

Глобальный логгер в Serilog - свойство Logger статического класса Log с get и set. Имеет значение по умолчанию объект типа SilentLogger, который ничего никуда не пишет:

public static class Log{    static ILogger _logger = SilentLogger.Instance;    /// <summary>    /// The globally-shared logger.    /// </summary>    /// <exception cref="ArgumentNullException">When <paramref name="value"/> is <code>null</code></exception>    public static ILogger Logger    {        get => _logger;        set => _logger = value ?? throw new ArgumentNullException(nameof(value));    }    ...}

Теперь исследуем UseSerilog и где назначается глобальный логгер.

Проходим в UseSerilog это где-то там назначается глобальный логгер. Что делает этот метод:

• определяет, можно ли переконфигурировать текущий глобальный логгер. Нужно переконфигурировать (перезагрузить в терминах кода), если верны все условия:

  • глобальный логгер является логгером, который можно переконфигурировать после его создания, т.е. он наследуется от ReloadableLogger;

  • входной параметр preserveStaticLogger (не трогать статический (читай глобальный) логгер) == false;

• если необходимо перезагрузить глобальный логгер, то для дальнейших целей используется переконфигурированный глобальный логгер. В противном случае на основе конфига приложения создаётся новый логгер;

• далее, в зависимости от необходимости сохранить глобальный логгер (вх параметр preserveStaticLogger), для интеграции в подсистему логирования .NET Core используется полученный на предыдущем этапе логгер, если глобальный логгер надо сохранить. И в противном случае заменяется глобальный логгер на полученный на предыдущем этапе, а для интеграции вместо логгера передаётся null, что потом приведёт к тому, что вместо конкретного переданного для интеграции логгера будет использоваться глобальный логгер.

По умолчанию preserveStaticLogger==false, поэтому глобальный статический логгер по умолчанию заменяется. Как это происходит:

• в фабрику логгеров Serilog передаётся неопределённый логгер (т.е. null). Эта фабрика интегрируется во встроенную в .NET Core подсистему логирования, как фабрика логгеров;

• в фабрике создаётся поставщик логгеров Serilog и туда передаётся логгер тоже null. Этот поставщик используется фабрикой, чтобы предоставить объект логгера, реализующий платформенный интерфейс Microsoft.Extensions.Logging.ILogger;

• поставщик логгеров создаёт и предоставляет платформенный логгер Serilog для интеграции во встроенную систему логирования .NET Core. В этот объект передаётся логгер Serilog , т.е. опять null;

• в платформенном логгере Serilog в конструкторе происходит выбор используемого логгера Serilog : если в качестве логгера передан null, то в дальнейшем в качестве логгера Serilog будет использоваться глобальный статический логгер из Log.Logger. И уже этот объект будет использоваться для логирования непосредственно в методе логирования этого платформенного логгера Serilog : тут и тут.

Эффект нескольких логгеров

Разработчики Serilog предлагают смешанный подход к использованию Serilog в .NET Core приложениях:

• через стандартную встроенную .NET Core подсистему логирования;

• с использованием глобального логгера через свойство Logger публичного статического класса Serilog.Log.

При этом встраивание Serilog в .NET Core предусматривает принципиально разные комбинации конфигурирования Serilog в зависимости от способа доступа к нему:

• чтобы логи через глобальный логгер писались так же, как через интегрированный в .NET Core (когда используется один и тот же объект preserveStaticLogger==false) как в конфигурации приложения

• чтобы логи через глобальный логгер писались как инициировано в самом начале (в примере в консоль), а интегрированный в .NET Core как в конфигурации приложения (preserveStaticLogger==true)

Таким образом, есть возможность получить две разные подсистемы логирования в пределах одного приложения просто перепутав входной параметр preserveStaticLogger. И поскольку логи это то, с помощью чего разбираются с багами, то с таким логированием эту проблему будет сложно найти.

Но всё не так плохо. Параметр preserveStaticLoggerпо умолчанию false. А это значит, если ничего специально не делать, логгер при обоих способах логирования будет один и будет иметь одну и ту же конфигурацию.

Проблемы с тестированием

Так как глобальный логгер хранится в статическом свойстве класса, то это единый объект на домен приложения. Инициализируется для коллекции сервисов, поэтому, если в рамках одного домена приложения будет создано несколько коллекций сервисов и инициализирована подсистема логирования, то в глобальном логгере будет конфигурация последнего из них и все логи от всех сервисов этих коллекций будут писаться через него. Такая проблема, например, возникает в модульных тестах.

Проверим это! Для этого понадобится вспомогательные классы.

Тестовый логгер

Тестовый логгер, который пишет в тестовый output лог-сообщение и добавляет в него префикс:

class TestLogger : Serilog.ILogger{    private readonly string _prefix;    private readonly ITestOutputHelper _output;    public TestLogger(string prefix, ITestOutputHelper output)    {    _prefix = prefix;    _output = output;    }    public void Write(LogEvent logEvent)    {    _output.WriteLine(_prefix + " " +  logEvent.MessageTemplate.Render(logEvent.Properties));    }}

Отправитель запросов

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

class ConcurrentLoggingTestRequestSender{    private readonly WebApplicationFactory<Startup> _webAppFactory;    private readonly ITestOutputHelper _output;    private readonly string _logPrefix;    public ConcurrentLoggingTestRequestSender(WebApplicationFactory<Startup> webAppFactory, ITestOutputHelper output, string logPrefix)    {        _webAppFactory = webAppFactory;        _output = output;        _logPrefix = logPrefix;    }    public async Task<HttpResponseMessage> Send()    {        var client = _webAppFactory.WithWebHostBuilder(b => b.UseSerilog(        (context, config) => config        .WriteTo.Logger(new TestLogger(_logPrefix, _output))        )).CreateClient();        return await client.SendAsync(new HttpRequestMessage(HttpMethod.Get, "/ping"));    }}

В методе Send инициируется приложение с добавлением Serilog и логированием в тестовый логгер.

Тесты

Тесты минимальны, почти одинаковы и отличаются только префиксом в выводимых лог-сообщениях.

Тест1:

public class ConcurrentLoggingTest_1of2 : IClassFixture<WebApplicationFactory<Startup>>{    private readonly ConcurrentLoggingTestRequestSender _requestSender;    private readonly ITestOutputHelper _output;    public ConcurrentLoggingTest_1of2(WebApplicationFactory<Startup> waf, ITestOutputHelper output)    {        _output = output;    _requestSender = new ConcurrentLoggingTestRequestSender(waf, output, "==1==");    }    [Fact]    public async Task Test()    {        _output.WriteLine("Test 1 of 2");        _output.WriteLine("");        var resp = await _requestSender.Send();        Assert.True(resp.IsSuccessStatusCode);    }}

Тест2:

public class ConcurrentLoggingTest_2of2 : IClassFixture<WebApplicationFactory<Startup>>{    private readonly ConcurrentLoggingTestRequestSender _requestSender;    private readonly ITestOutputHelper _output;    public ConcurrentLoggingTest_2of2(WebApplicationFactory<Startup> waf, ITestOutputHelper output)    {        _output = output;    _requestSender = new ConcurrentLoggingTestRequestSender(waf, output, ">>2<<");    }    [Fact]    public async Task Test()    {        _output.WriteLine("Test 2 of 2");        _output.WriteLine("");        var resp = await _requestSender.Send();        Assert.True(resp.IsSuccessStatusCode);    }}

Результаты тестирования

Test 1 of 2==1== Application started. Press Ctrl+C to shut down.==1== Hosting environment: "Development"==1== Content root path: "C:\Users\ozzye\Documents\prog\my\serilog-poke\src\SerilogPoke"==1== Request starting HTTP/1.1 GET http://localhost/ping  ==1== Executing endpoint '"SerilogPoke.Controllers.PingController.Ping (SerilogPoke)"'==1== Route matched with "{action = \"Ping\", controller = \"Ping\"}". Executing controller action with signature "Microsoft.AspNetCore.Mvc.IActionResult Ping()" on controller "SerilogPoke.Controllers.PingController" ("SerilogPoke").==1== Executing ObjectResult, writing value of type '"System.String"'.==1== Executed action "SerilogPoke.Controllers.PingController.Ping (SerilogPoke)" in 13.1068ms==1== Executed endpoint '"SerilogPoke.Controllers.PingController.Ping (SerilogPoke)"'==1== Request finished in 76.8507ms 200 text/plain; charset=utf-8Test 2 of 2>>2<< Application started. Press Ctrl+C to shut down.>>2<< Hosting environment: "Development">>2<< Content root path: "C:\Users\ozzye\Documents\prog\my\serilog-poke\src\SerilogPoke">>2<< Request starting HTTP/1.1 GET http://localhost/ping  >>2<< Executing endpoint '"SerilogPoke.Controllers.PingController.Ping (SerilogPoke)"'>>2<< Route matched with "{action = \"Ping\", controller = \"Ping\"}". Executing controller action with signature "Microsoft.AspNetCore.Mvc.IActionResult Ping()" on controller "SerilogPoke.Controllers.PingController" ("SerilogPoke").>>2<< Executing ObjectResult, writing value of type '"System.String"'.>>2<< Executed action "SerilogPoke.Controllers.PingController.Ping (SerilogPoke)" in 15.2088ms>>2<< Executed endpoint '"SerilogPoke.Controllers.PingController.Ping (SerilogPoke)"'>>2<< Request finished in 78.8673ms 200 text/plain; charset=utf-8

Test 1 of 2Test 2 of 2>>2<< Application started. Press Ctrl+C to shut down.>>2<< Application started. Press Ctrl+C to shut down.>>2<< Hosting environment: "Development">>2<< Hosting environment: "Development">>2<< Content root path: "C:\Users\ozzye\Documents\prog\my\serilog-poke\src\SerilogPoke">>2<< Content root path: "C:\Users\ozzye\Documents\prog\my\serilog-poke\src\SerilogPoke">>2<< Request starting HTTP/1.1 GET http://localhost/ping  >>2<< Request starting HTTP/1.1 GET http://localhost/ping  >>2<< Executing endpoint '"SerilogPoke.Controllers.PingController.Ping (SerilogPoke)"'>>2<< Executing endpoint '"SerilogPoke.Controllers.PingController.Ping (SerilogPoke)"'>>2<< Route matched with "{action = \"Ping\", controller = \"Ping\"}". Executing controller action with signature "Microsoft.AspNetCore.Mvc.IActionResult Ping()" on controller "SerilogPoke.Controllers.PingController" ("SerilogPoke").>>2<< Route matched with "{action = \"Ping\", controller = \"Ping\"}". Executing controller action with signature "Microsoft.AspNetCore.Mvc.IActionResult Ping()" on controller "SerilogPoke.Controllers.PingController" ("SerilogPoke").>>2<< Executing ObjectResult, writing value of type '"System.String"'.>>2<< Executing ObjectResult, writing value of type '"System.String"'.>>2<< Executed action "SerilogPoke.Controllers.PingController.Ping (SerilogPoke)" in 13.5891ms>>2<< Executed action "SerilogPoke.Controllers.PingController.Ping (SerilogPoke)" in 13.5891ms>>2<< Executed endpoint '"SerilogPoke.Controllers.PingController.Ping (SerilogPoke)"'>>2<< Executed endpoint '"SerilogPoke.Controllers.PingController.Ping (SerilogPoke)"'>>2<< Request finished in 78.0903ms 200 text/plain; charset=utf-8>>2<< Request finished in 78.0958ms 200 text/plain; charset=utf-8

Test 1 of 2==1== Application started. Press Ctrl+C to shut down.==1== Application started. Press Ctrl+C to shut down.==1== Hosting environment: "Development"==1== Hosting environment: "Development"==1== Content root path: "C:\Users\ozzye\Documents\prog\my\serilog-poke\src\SerilogPoke"==1== Content root path: "C:\Users\ozzye\Documents\prog\my\serilog-poke\src\SerilogPoke"==1== Request starting HTTP/1.1 GET http://localhost/ping  ==1== Request starting HTTP/1.1 GET http://localhost/ping  ==1== Executing endpoint '"SerilogPoke.Controllers.PingController.Ping (SerilogPoke)"'==1== Executing endpoint '"SerilogPoke.Controllers.PingController.Ping (SerilogPoke)"'==1== Route matched with "{action = \"Ping\", controller = \"Ping\"}". Executing controller action with signature "Microsoft.AspNetCore.Mvc.IActionResult Ping()" on controller "SerilogPoke.Controllers.PingController" ("SerilogPoke").==1== Route matched with "{action = \"Ping\", controller = \"Ping\"}". Executing controller action with signature "Microsoft.AspNetCore.Mvc.IActionResult Ping()" on controller "SerilogPoke.Controllers.PingController" ("SerilogPoke").==1== Executing ObjectResult, writing value of type '"System.String"'.==1== Executing ObjectResult, writing value of type '"System.String"'.==1== Executed action "SerilogPoke.Controllers.PingController.Ping (SerilogPoke)" in 12.7648ms==1== Executed action "SerilogPoke.Controllers.PingController.Ping (SerilogPoke)" in 12.7649ms==1== Executed endpoint '"SerilogPoke.Controllers.PingController.Ping (SerilogPoke)"'==1== Executed endpoint '"SerilogPoke.Controllers.PingController.Ping (SerilogPoke)"'==1== Request finished in 78.428ms 200 text/plain; charset=utf-8==1== Request finished in 78.4282ms 200 text/plain; charset=utf-8Test 2 of 2

Вывод по тестированию

Так как логгер глобальный и один на все тесты, а тесты выполняются параллельно, то после инициализации веб-приложения в каждом тесте, в качестве глобального логгера остаётся тот логгер, который был присвоен статическому полю Serilog.Log.Logger позже. Поскольку сдвиг по времени в работе тестов непредсказуем, то в разных случаях глобальным становится логгер из разных тестов.

Поэтому при выполнении кода в тестах надо всегда помнить и использовать при интеграции Serilog в .NET Core (метод UseSerilog()) параметр preserveStaticLogger = true, чтобы при инициализации в каждом тесте подсистемы логирования использовался в каждом случаи свой логгер. При этом будет возникать эффект нескольких логгеров с соответствующими последствиями.

Глобальный логгер где нужен?

При должном подходе, работа всего приложения сводится к взаимодействию объектов, создаваемых и связываемых по средствам DI платформой .NET Core, а точнее объектом хоста, который создаётся в примере при использовании метода CreateHostBuilder. И в этом случае самым подходящим способом логирования было бы использование встроенного механизма логирования.

Однако разработчики Serilogтак же предлагают нам так же использовать глобальный логгер в том месте, где нет DI платформы .NET Core в методе Main вне области работы объекта хоста:

• Запуск!

• Перехват необработанной ошибки

• Успешное окончание

Запуск!

На данном этапе мы ещё не добрались до конфигурации. Работа с конфигурацией и создание логгера в соответствии с конфигурацией будет позже. Поэтому тут можно иметь дело только с хардкодом. Самые популярные логгеры, которые не требуют конфигурирование это Console и Debug. Они не требуют конфигурирования, зависящего от окружения и их можно быстро прописать прямо в коде. Эти логгеры выводят сообщения туда, где и так понятно, что приложение запускается:

• в консоли мы в любом случае как-то понимаем, что приложение начало запускаться;

• Debug ну, это, скорее всего IDE и тут тоже понятно.

Вот и получается, что:

• это не даёт понимания о начале запуска приложения, так как оно уже запущено на этот момент и находится в процессе инициализации прикладных механизмов (инициализация объекта хоста, сервисов, загрузка конфигурации и прочее);

• после успешного запуска хоста веб приложения, хост сам отправит сообщение об успешном запуске:

[01:53:06 INF] Now listening on: http://localhost:5000[01:53:06 INF] Application started. Press Ctrl+C to shut down.[01:53:06 INF] Hosting environment: Development[01:53:06 INF] Content root path: C:\Users\ozzye\Documents\prog\my\serilog-poke\src\SerilogPoke

Вывод:

это лог-сообщение малоинформативное и избыточное

Перехват необработанной ошибки - что получаем?

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

Проведём пару тестов, в которых запустим веб-приложение а консоли и в методе конфигурации сервисов выкинем ошибку.

public class Startup{    public void ConfigureServices(IServiceCollection services)    {        throw new Exception("Ololo!");        services.AddControllers();    }}

Вывод в консоли:

Теперь закомментируем перехват необработанной ошибки в Main:

public static int Main(string[] args){    Log.Logger = new LoggerConfiguration()        .WriteTo.Console()        .CreateBootstrapLogger();    Log.Information("Starting up!");    try    {        CreateHostBuilder(args).Build().Run();        Log.Information("Stopped cleanly");        return 0;    }    //catch (Exception ex)    //{    //    Log.Fatal(ex, "An unhandled exception occured during bootstrapping");    //    return 1;    //}    finally    {        Log.CloseAndFlush();    }}

Вывод в консоли:

Вывод:

Даже без логирования через Serilog, необработанное исключение было выведено в консоль.

Перехват необработанной ошибки - что может случиться?

Теперь проведём тесты, в которых обернём запуск веб-приложения в try-catch и используем для логирования глобальный логгер Serilog, который будет выводить сообщения с префиксом initial, а при запуске веб-приложения установим другой логгер с префиксом configured.

Тест1: ошибка на этапе конфигурирования сервисов. В этом тесте ошибка происходит при конфигуировании сервисов приложения.

//Arrangevar initialLogger = new TestLogger("initial: ", _output);var configuredLogger = new TestLogger("configured: ", _output);HttpClient client;Log.Logger = initialLogger;Log.Information("Starting up!");try{    client = _waf.WithWebHostBuilder(        builder => builder        .UseSerilog((context, config) => config                    .WriteTo.Logger(configuredLogger))        .ConfigureServices(collection =>                           {                               throw new Exception("Ololo!");                           })    ).CreateClient();}catch (Exception e){    Log.Fatal(e, "An unhandled exception occured during bootstrapping");    throw;}finally{    Log.CloseAndFlush();}//Actvar resp = await client.SendAsync(new HttpRequestMessage(HttpMethod.Get, "/ping"));//AssertAssert.True(resp.IsSuccessStatusCode);

Лог:

initial:  Starting up!configured:  An unhandled exception occured during bootstrapping

Тест2: ошибка до инициализации подсистемы логирования .NET Core. В этом тесте ошибка происходит при попытке загрузить отсутствующий конфигурационный файл.

//Arrangevar initialLogger = new TestLogger("initial: ", _output);var configuredLogger = new TestLogger("configured: ", _output);HttpClient client;Log.Logger = initialLogger;Log.Information("Starting up!");try{    client = _waf.WithWebHostBuilder(        builder => builder        .UseSerilog((context, config) =>                         config.WriteTo.Logger(configuredLogger)                       )        .ConfigureAppConfiguration((context, configurationBuilder) =>                             configurationBuilder.AddJsonFile("absent.json"))                    )            .CreateClient();}catch (Exception e){    Log.Fatal(e, "An unhandled exception occured during bootstrapping");    throw;}finally{    Log.CloseAndFlush();}//Actvar resp = await client.SendAsync(new HttpRequestMessage(HttpMethod.Get, "/ping"));//AssertAssert.True(resp.IsSuccessStatusCode);

Лог:

initial:  Starting up!initial:  An unhandled exception occured during bootstrapping

Вывод:

В зависимости от места ошибки при запуске приложения, перехваченная ошибка может быть записана в лог разными логгерами: стартовым (обычно в консоль) или логгером, который создан по конфигурации приложения. Поэтому отсутствие такого сообщения в логах (не в консоли) может говорить о том, что ошибка не произошла или произошла на этапе до готовности подсистемы логирования .NET Core. Т.е. то ли была ошибка, то ли нет. А для вывода необработанного сообщения в консоль не обязательно это делать через логгер.

Успешное окончание

Сообщение об успешном завершении работы приложения по факту логируется ещё до факта завершения приложения. Как минимум, может произойти ошибка при дальнейшем обращении к логгеру с целью его закрыть в блоке finally:

public static int Main(string[] args){    ...    try    {        CreateHostBuilder(args).Build().Run();        Log.Information("Stopped cleanly");        return 0;    }    catch (Exception ex)    {        ...    }    finally    {        Log.CloseAndFlush();    }}

Вывод:

Данное сообщение не соответствует действительности.

Вывод по логированию в Main

Лог-записи о начале запуска приложения и окончании работы приложения это зона ответственности инфраструктуры, которая запускает и фиксирует факт остановки приложения. Само приложение должно отчитаться о том, что оно успешно запущено и готово к работе, и, возможно, что начинает процедуру останова.

По опыту, ошибки на этапе запуска веб-приложения это редкая ситуация, которая быстро выявляется и устраняется, потому что при запуске приложения в основном формируется и конфигурируется объектная модель приложения. Самые, наверное, вероятные ситуации:

• нет какой-то библиотеки

• нет конфига

И такие ошибки, конечно, приводят к тому, что приложение завершает свою работу. Поэтому при диагностике проблемы вариантов немного. Как показали тесты, весьма вероятны ситуации, когда на момент необработанной ошибки глобальный логгер будет начальный и запишет сообщение только в консоль. Учитывая, что даже если не логировать необработанное исключение, то оно всё равно будет выведено в консоль, почти так же, как если бы это делал логгер, то польза от данного логирования вызывает сомнения.

Таким образом, делаю вывод, что глобальный логгер в рекомендациях от разработчиков Serilog присутствует не из-за необходимости решить важную задачу, а чтобы как-то оправдать присутствие глобального логгера в .NET Core приложении после подключения Serilog.

Глобальный логгер Вред

Глобальный логгер это объект, через который осуществляется логирование в Serilog, присвоенный публичному статическому свойству Logger статического класса Serilog.Log. Это свойство инициализируется при запуске приложения с конфигурацией в коде, а затем второй раз инициализируется при инициализации хоста веб-приложения на основе загруженной конфигурации.

Таким образом это не Singleton в чистом виде. Но в пределах работы веб-приложения он задумывается как единственный глобальный экземпляр.

Проблемы:

• потеря лог-сообщений в модульных тестах. В зависимости от особенностей интеграции Serilog в .NET Core (параметр preserveStaticLogger в методе UseSerilog()) могут возникнуть проблемы:

  • с логированием в логгер из последнего теста

  • эффект нескольких логгеров

• по тем же причинам могут не задействоваться средства расширения подсистемы логирования, тестируемые в модульных тестах в составе развёрнутой подсистемы логирования .NET Core и Serilog

• возможность в любой момент использовать Serilog.Log.Logger мимо системы DI от .NET Core, которая реализуется под самыми весомыми предлогами:

  • это временно;

  • а ну чё, и так же работает;

  • Я так привык на .NET Framework;

• как следствие, использование в коде статического сервис-локатора - антипаттерн;

• т.к. статическое свойство Logger изменяемое, то есть вероятность несанкционированного замены логгера в непредназначенных для этого местах. Например, это могут быть временные костыли, которые имеют особенность становиться постоянными;

• в библиотеке присутствует нехарактерное решение для .NET Core. Сильно напоминает антипаттерн Boat Anchor .

Заключение

График на google trends.

Serilog был и есть отличным инструментом. Но он не был переработан и адаптирован в полной мере для .NET Core, поэтому в нём остались механизмы, которые больше характерны для решений на .NET Framework. Как показывает прогресс, .NET, в виде .NET 5, двигается в направлении архитектуры, взятой из .NET Core. Поэтому разработчикам Serilog рано или поздно придётся заняться вопросом адаптации более плотно.

К сожалению, простым запросом слияния в github проблему с глобальным логом полностью не решить. Тут требуется глобальный рефакторинг, который может, например включать такие изменения:

• вынести из основной библиотеки Serilog все механизмы, относящиеся к .NET Framework в отдельную библиотеку на подобии serilog-aspnetcore, которая будет использовать основную библиотеку. И туда перенести в т.ч. класс Serilog.Log. тогда при подключении Serilog к проекту на .NET Core в приложении этот класс не будет доступен;

• в serilog-aspnetcore в методе интеграции Serilog в подсистему логирования .NET Core всегда использовать алгоритм работы, соответствующий тому случаю, если указать вх. параметр preserveStaticLogger = true, т.е. вместо глобального логгера создать новый.

В данной статье мы разобрались с тем, какое место в логировании через Serilog в .NET Core занимает глобальный логгер и какие проблемы он может принести.

В следующих статьях будут разобраны другие особенности интеграции Serilog в .NET Core.

Автор: Андрей Жуков, .NET Team Leader, DataArt

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

Задача, поставленная заказчиком: Azure -> GCP

Заказчик решил перейти из одного облака (Azure) в другое (Google Cloud Platform). В некотором отдаленном будущем вообще планировалось перевести серверную часть на Node.js и развивать систему силами команды full-stack typescript-разработчиков. На момент моего входа в проект там существовала пара ASP.NET MVC приложений, которым решили продлить жизнь. Их мне и предстояло перенести в GCP.

Начальная состояние, факторы, мешающие сразу перейти на GCP

Первоначально имелось два ASP.NET MVC-приложения, которые взаимодействовали с одной общей MS SQL базой данных. Они были развернуты на Azure App Services.

Первое приложение назовем его Web Portal имело пользовательский интерфейс, построенный на базе Razor, TypeScript, JavaScript, Knockout и Bootstrap. С этими клиентскими технологиями никаких проблем не предвиделось. Зато серверная часть приложения использовала несколько сервисов, специфичных для Azure: Azure Service Bus, Azure Blobs, Azure Tables storage, Azure Queue storage. С ними предстояло что-то делать, т. к. в GCP ни один из них не поддерживается. Кроме того, приложение использовало Azure Cache for Redis. Для обработки длительных запросов была задействована служба Azure WebJob, задачи которой передавались через Azure Service Bus. По словам программиста, занимавшегося поддержкой, фоновые задачи могли выполняться до получаса.

Azure WebJobs тоже предстояло чем-то заменить. Архитектура с очередью заданий для длительных вычислений не единственное среди возможных решений можно использовать специализированные библиотеки для фоновых задач, например, Hangfire, или обратиться к IHostedService от Microsoft.

Второе приложение назовем его Web API представляло собой ASP.NET WEB API. Оно использовало только MS SQL базы данных. Вернее, в конфигурационном файле были ссылки на несколько баз данных, в реальности же приложение обращалось только к одной их них. Но об этом нюансе мне только предстояло узнать.

Оба приложения были в работающем, но плохом состоянии: отсутствовала архитектура как таковая, было много старого неиспользуемого кода, не соблюдались принципы построения ASP.NET MVC приложений и т. д. Заказчик и сам признавал низкое качество кода, а человек, изначально написавший приложения, уже несколько лет не работал в компании. Был дан зеленый свет любым изменениям и новым решениям.

Итак, нужно было перевести ASP.NET MVC приложения на ASP.NET Core 3.1, перевести WebJob c .NET Framework на .NET Core, чтобы можно было разворачивать их под Linux. Использовать Windows на GCP возможно, но не целесообразно. Надо было избавиться от сервисов, специфичных для Azure, заменить чем-то Azure WebJob, решить, как будем развертывать приложения в GCP, т. е. выбрать альтернативу Azure App Services. Требовалось добавить поддержку Docker. При этом неплохо было бы внести хоть какую-то архитектуру и поправить качество кода.

Общие принципы и соображения

Проводя рефакторинг, мы придерживались принципа пошаговых изменений: вся работа делилась на этапы, которые в свою очередь состояли из отдельных шагов.

В конце каждого этапа приложение должно находиться в стабильном состоянии, т. е. пройти хотя бы Smoke tests.

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

Шаги и этапы должны быть максимально короткими: работу нужно раздробить настолько, насколько это возможно. Порой нам все равно приходилось делать шаги, когда приложение не компилировалось в течение одного-двух дней. Случалось, что в конце шага компилировался только тот проект решения, который был недавно изменен. Если этап или шаг можно разбить по проектам, начинать работу надо с того проекта, который не зависит от других, и далее переходить к тем, которые зависят только от него, и т. д. План, который составили мы, представлен ниже.

При замене сервисов Azure можно либо подобрать альтернативный GCP-сервис, либо выбрать cloud-agnostic-решение. Выбор сервисов в этом проекте и его обоснование в каждом случае мы рассмотрим отдельно.

План работ

Высокоуровневый план в целом был продиктован заказчиком, где-то я добавил шаги, о необходимости которых на стороне клиента не знали или не придали им значения. План немного корректировался в ходе работы. На некоторых этапах добавлялся рефакторинг архитектуры и кода, который непосредственно не относился к переходу на другую платформу. Окончательный вариант можно увидеть ниже. Каждый пункт этого плана этап, в том смысле, что по его завершении приложение находится в стабильном состоянии.

1. Web Portal c ASP.NET MVC на ASP.NET Core

   1.1. Анализ кода и зависимостей Web Portal от сервисов Azure и сторонних библиотек, оценка необходимого времени.

   1.2. Перевод Web Portal на .NET Core.

   1.3. Рефакторинг с целью устранения основных проблем.

   1.4. Merge изменений Web Portal из основной ветки репозитория, сделанных параллельно другими разработчиками.

   1.5. Докеризация Web Portal.

   1.6. Тестирование Web Portal, устранение ошибок и развертывание новой версии на Azure.

2. Web API c ASP.NET MVC на ASP.NET Core

   2.1. Написание E2E автоматических тестов для Web API.

   2.2. Анализ кода и зависимостей Web API от сервисов Azure и сторонних библиотек, оценка необходимого времени.

   2.3. Удаление неиспользуемого исходного кода из Web API.

   2.4. Перевод Web API на .NET Core.

   2.5. Рефакторинг Web API с целью устранения основных проблем.

   2.6. Merge изменений Web API из основной ветки репозитория, сделанных параллельно другими разработчиками.

   2.7. Докеризация Web API.

   2.8. Тестирование Web API, устранение ошибок и развертывание новой версии на Azure.

3. Устранение зависимостей от Azure

   3.1. Устранение зависимостей Web Portal от Azure.

4. Развертывание в GCP

   4.1. Развертывание Web Portal в тестовой среде в GCP.

   4.2. Тестирование Web Portal и устранение возможных ошибок.

   4.3. Миграция базы данных для тестовой среды.

   4.4. Развертывание Web API в тестовой среде в GCP.

   4.5. Тестирование Web API и устранение возможных ошибок.

   4.6. Миграция базы данных для prod-среды.

   4.7. Развертывание Web Portal и Web API в prod GCP.

Целиком план представлен лишь в ознакомительных целях, далее в статье я постараюсь подробно раскрыть лишь наиболее интересные, с моей точки зрения, вопросы.

.NET Framework -> .NET Core

Перед началом переноса кода я нашел статью о миграции .Net Framework на .Net Core от Microsoft и далее ссылку на миграцию ASP.NET на ASP.NET Core.

С миграцией не-Web-проектов все обстояло относительно просто:

• преобразование формата хранения NuGet-пакетов с помощью Visual Studio 2019;

• адаптирование списка этих пакетов и их версий;

• переход с App.config в XML на settings.json и замена всех имеющихся обращений к конфигурационным значениям на новый синтаксис.

Некоторые версии NuGet-пакетов Azure SDK претерпели изменения, повлекшие несовместимость. В большинстве случаев удалось найти не всегда самую новую, зато поддерживаемую кодом .NET Core версию, которая не требовала бы изменений в логике старого программного кода. Исключением стали пакеты для работы с Azure Service Bus и WebJobs SDK. Пришлось с Azure Service Bus перейти на бинарную сериализацию, а WebJob перевести на новую, обратно несовместимую версию SDK.

C миграцией ASP.NET MVC на ASP.NET Core дело обстояло намного сложнее. Все перечисленные выше действия нужно было проделать и для Web-проектов. Но начинать пришлось с нового ASP.NET Core проекта, куда мы перенесли код старого проекта. Структура ASP.NET Core проекта сильно отличается от предшественника, многие стандартные классы ASP.NET MVC претерпели изменения. Ниже я привожу список того, что изменили мы, и большая его часть будет актуальна для любого перехода с ASP.NET MVC на ASP.NET Core.

1. Создание нового проекта ASP.NET Core и перенос в него основного кода из старого ASP.NET MVC проекта.

2. Корректировка зависимостей проекта от внешних библиотек (в нашем случае это были только NuGet-пакеты, соображения по поводу версий библиотек см. выше).

3. Замена Web.config на appsettings.json и все связанные с этим изменения в коде.

4. Внедрение стандартного механизма Dependency injection от .NET Core вместо любой его альтернативы, использовавшейся в Asp.NET MVC проекте.

5. Использование StaticFiles middleware для всех корневых папок статических файлов: изображений, шрифтов, JavaScript-скриптов, CSS-стилей и т. д.

app.UseStaticFiles(); // wwwrootapp.UseStaticFiles(new StaticFileOptions   {     FileProvider = new PhysicalFileProvider(         Path.Combine(Directory.GetCurrentDirectory(), "Scripts")),     RequestPath = "/Scripts"});

Можно перенести все статические файлы в wwwroot.

6. Переход к использованию bundleconfig.json для всех JavaScript и CSS-бандлов вместо старых механизмов. Изменение синтаксиса подключения JavaScript и CSS:

<link rel="stylesheet" href="~/bundles/Content.css" asp-append-version="true" /><script src="~/bundles/modernizr.js" asp-append-version="true"></script>

Чтобы директива asp-append-version="true" работала корректно, бандлы (bundles) должны находиться в корне, т. е. в папке wwwroot (смотри здесь).

Для отладки бандлов я использовал адаптированную версию хелпера отсюда.

7. Изменение механизма обработки UnhadledExceptions: в ASP.NET Core реализована его поддержка, остается с ней разобраться и использовать вместо того, что применялось в проекте раньше.

8. Логирование: я адаптировал старые механизмы логирования для использования стандартных в ASP.NET Core и внедрил Serilog. Последнее опционально, но, по-моему, сделать это стоит для получения гибкого structured logging c огромным количеством вариантов хранения логов.

9. Session если в старом проекте использовалась сессия, то код обращения к ней надо будем немного адаптировать и написать хелпер для сохранения любого объекта, поскольку изначально поддерживается только строка.

10. Routing: в старом проекте использовался механизм, основанный на templates, его надо было чуть-чуть подправить.

11. JSON-сериализация: В ASP.NET Core по умолчанию используется библиотека System.Text.Json вместо Newtonsoft.Json. Microsoft утверждает, что она работает быстрее предшественницы, однако, в отличие от последней, она не поддерживает многое из того, что Newtonsoft.Json умела делать из коробки безо всякого участия программиста. Хорошо, что есть возможность переключиться обратно на Newtonsoft.Json. Именно это я и сделал, когда выяснил, что большая часть сериализации в Web API была сломана, и вернуть ее в рабочее состояние с помощью новой библиотеки, если и возможно, очень непросто. Подробнее об использовании Newtonsoft.Json можно прочитать здесь.

12. В старом проекте использовался Typescript 2.3. С его подключением пришлось повозиться, потребовалось установить Node.js, подобрать правильную версию пакета Microsoft.TypeScript.MSBuild, добавить и настроить tsconfig.json, поправить файл определений (Definitions) для библиотеки Knockout, кое-где добавить директивы //@ts-ignore.

13. Код для принудительной поддержки HTTPS включается автоматически при включении этой опции в визарде проекта. Старый код, использующий пользовательский атрибут HttpsOnly, был при этом убран.

14. Все низкоуровневые действия, такие как получение параметров из body запроса, URL запроса, HTTP Headers и HttpContext потребовали изменений, т. к. API для доступа к ним претерпел изменения по сравнению с ASP.NET MVC. Работы было бы заметно меньше, если бы в старом проекте чаще использовались стандартные binding механизмы через параметры экшенов (Actions) и контроллеров (Controllers).

15. Был добавлен Swagger c помощью библиотеки Swashbuckle.AspNetCore.Swagger.

16. Нестандартный механизм Authentication потребовал рефакторинга для приведения его к стандартному виду.

Количество изменений было очень велико, поэтому часто приходилось оставлять только один контроллер и добиваться его работоспособности. Другие мы затем добавляли постепенно, следуя принципу пошаговых изменений.

Что делать со специфичными сервисами Azure?

После перехода на ASP.NET Core предстояло избавиться от Azure-сервисов. Можно было либо подобрать решения, которые не зависят от облачной платформы, либо найти что-то подходящее из списка GCP. Благо у многих сервисов есть прямые альтернативы у других облачных провайдеров.

Azure Service Bus мы по настоятельной рекомендации заказчика решили заменить на Redis Pub/Sub. Это достаточно простой инструмент, не настолько мощный и гибкий как, например, RabbitMQ. Но для нашего простого сценария его хватало, а в пользу такого выбора говорило то, что Redis в проекте уже использовался. Время подтвердило решение было правильным. Логика работы с очередью была абстрагирована и выделена в два класса, один из которых реализует отправку произвольного объекта, другой получает сообщения и передает их на обработку. На выделение этих объектов ушло всего несколько часов, а если сам Redis Pub/Sub вдруг потребуется заменить, то и это будет очень просто.

Azure Blobs были заменены на GCP Blobs. Решение очевидное, но все-таки различие в функциональности сервисов нашлось: GCP Blobs не поддерживает добавление данных в конец существующего блоба. В нашем проекте такой блоб использовался для создания подобия логов в формате CSV. На платформе Google мы решили записывать эту информацию в Google Cloud operations suite, ранее известный как Stackdriver.

Хранилище Azure Table Storage использовалось для записи логов приложения и доступа к ним из Web Portal. Для этого существовал логгер, написанный самостоятельно. Мы решили привести этот процесс в соответствие с практиками от Microsoft, т. е. использовать их интерфейс ILogger. Кроме того, была внедрена библиотека для структурного логирования Serilog. В GCP логирование настроили в Stackdriver.

Какое-то время проект должен был параллельно работать и на GCP, и на Azure. Поэтому вся функциональность, зависящая от платформы, была выделена в отдельные классы, реализующие общие интерфейсы: IBlobService, IRequestLogger, ILogReader. Абстрагирование логирования было достигнуто автоматически за счет использования библиотеки Serilog. Но для того, чтобы показывать логи в Web Portal, как это делалось в старом приложении, понадобилось адаптировать порядок записей в Azure Table Storage, реализуя свой Serilog.Sinks.AzureTableStorage.KeyGenerator.IKeyGenerator. В GCP для чтения логов изGoogle Cloud operations были созданы Log Router Sinks, передающие данные в BigQuery, откуда приложение и получало их.

Что делать с Azure WebJobs?

Сервис Azure WebJobs доступен только для Azure App Services on Windows. По сути он представляет собой консольное приложение, использующее специальный Azure WebJobs SDK. Зависимость от этого SDK я убрал. Приложение осталось постоянно работающим консольным и следует похожей логике:

static async Task Main(string[] args){.   var builder = new HostBuilder();  ...              var host = builder.Build();  using (host)  {     await host.RunAsync();  }...}

За всю работу отвечает зарегистрированный с помощью Dependency Injection класс

public class RedisPubSubMessageProcessor : Microsoft.Extensions.Hosting.IHostedService{...public async Task StartAsync(CancellationToken cancellationToken)...public async Task StopAsync(CancellationToken cancellationToken)...}

Это стандартный для .NET Core механизм. Несмотря на отсутствие зависимости от Azure WebJob SDK, это консольное приложение успешно работает как Azure WebJob. Оно также без проблем работает в Linux Docker-контейнере под управлением Kubernetes, о чем речь в статье пойдет позже.

Рефакторинг по дороге

Архитектура и код приложения были далеки от идеала. В ходе многих шагов постепенно производились небольшие изменения кода, который они затрагивали. Были и специально запланированные этапы рефакторинга, согласованные и оцененные вместе с заказчиком. На этих этапах мы устраняли проблемы с аутентификацией и авторизацией, переводили их на практики от Microsoft. Был отдельный этап по внесению некой архитектуры, выделению слоев, устранению ненужных зависимостей. Работа с Web API началась с этапа удаления неиспользуемого кода. При замене многих Azure-сервисов на первом этапе производилось определение интерфейсов, выделение данных зависимостей в отдельные классы.

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

Docker

С поддержкой Docker все сложилось довольно гладко. Dockerfile можно легко добавить с помощью Visual Studio. Я добавил их для всех проектов, соответствующих приложениям, для Web Portal, Web API, WebJob (который в дальнейшем превратился просто в консольное приложение). Эти стандартные Dockerfile от Microsoft не претерпели особенных изменений и заработали из коробки за единственным исключением пришлось в Dockerfile для Web Portal добавить команды для установки Node.js. Этого требует build контейнер для работы с TypeScript.

RUN apt-get update && \apt-get -y install curl gnupg && \curl -sL https://deb.nodesource.com/setup_12.x  | bash - && \apt-get -y install nodejs

Azure App Services -> GKE

Нет единственно правильного решения для развертывания .NET Core-приложений в GCP, вы всегда можете выбрать из нескольких опций:

• App Engine Flex.

• Kubernetes Engine.

• Compute Engine.

В нашем случае я остановился на Google Kubernetes Engine (GKE). Причем к этому моменту у нас уже были контейнеризованные приложения (Linux). GKE, оказалось, пожалуй, наиболее гибким из трех представленных выше решений. Оно позволяет разделять ресурсы кластера между несколькими приложениями, как в нашем случае. В принципе для выбора одного из трех вариантов можно воспользоваться блок-схемой по этой сслыке.

Выше описаны все решения по используемым сервисам GCP, кроме MS SQL Server, который мы заменили на Cloud SQL от Google.

Тестирование

Web Portal тестировался вручную, после каждого этапа я сам проводил простенький Smoke-тест. Это было обусловлено наличием пользовательского интерфейса. Если по завершении очередного этапа, новый кусок кода выпускался в Prod, к его тестированию подключались другие пользователи, в частности, Product Owner. Но выделенных QA-специалистов, в проекте, к сожалению, не было. Разумеется, все выявленные ошибки исправлялись до начала очередного этапа. Позднее был добавлен простой Puppeteer-тест, который исполнял сценарий загрузки одного из двух типов отчетов с какими-то параметрами и сравнивал полученный отчет с эталонным. Тест был интегрирован в CICD. Добавить какие-то юнит-тесты было проблематично по причине отсутствия какой-либо архитектуры.

Первым этапом миграции Web API, наоборот, было написание тестов. Для это использовался Postman, затем эти тесты вызывались в CICD с помощью Newman. Еще раньше к старому коду была добавлена интеграция со Swagger, который помог сформировать начальный список адресов методов и попробовать многие из них. Одним из следующих шагов было определение актуального перечня операций. Для этого использовались логи IIS (Internet Information Services), которые были доступны за полтора месяца. Для многих актуальных методов перечня было создано несколько тестов с разными параметрами. Тесты, приводящие к изменению данных в базе, были выделены в отдельную Postman-коллекцию и не запускались на общих средах выполнения. Разумеется, все это было параметризовано, чтобы можно было запускать и на Staging, и на Prod, и на Dev.

Тестирование позволило нам убедиться, что продукт после миграции сохранил стабильность. Конечно, идеальным вариантов было бы покрыть всю функциональность автоматизированными тестами. Поэтому в случае с Web API несмотря на гораздо большие усилия, затраченные в самом начале, миграция, поиск и исправление ошибок затем проходили гораздо легче.

Azure MS SQL -> GCP Managed MS SQL

Миграция MS SQL из Managed Azure в GCP Cloud SQL оказалась не такой простой задачей, как представлялось вначале. Основных причин тому оказался несколько:

• Очень большой размер базы данных (Azure портал показал: Database data storage /

  Used space 181GB).

• Наличие зависимостей от внешних таблиц.

• Отсутствие общего формата для экспорта из Azure и импорта в GCP Cloud SQL.

При миграции базы я в основном опирался на статью на испанском, которую автоматически перевел в Google Chrome. Она оказалась самой полезной из всех, что мне удалось найти.

Перед началом миграции нужно удалить все ссылки на внешние таблицы и базы данных, иначе миграция будет неудачной. Azure SQL поддерживает экспорт только в формат bacpac, более компактный по сравнению со стандартным backup форматом. В нашем случае вышло 6 Гб в bacpac против 154 Гб в backup. Но GCP Cloud позволят импортировать только backup, поэтому нам потребовалась конвертация, сделать которую удалось лишь посредством восстановления в локальную MS SQL из bacpac и создания backup уже из нее. Для этих операций потребовалось установить последнюю версию Microsoft SQL Server Management Studio, причем локальный сервер MS SQL Server был версией ниже. Немало операций заняли по многу часов, некоторые и вовсе длились по несколько дней. Рекомендую увеличить квоту Azure SQL перед импортом и сделать копию prod базы, чтобы импортировать из нее. Где-то нам потребовалось передавать файл между облаками, чтобы ускорить загрузку на локальную машину. Мы также добавили SSD-диск на 1 Тб специально под файлы базы данных.

Задачи на будущее

При переходе с Azure App Services на GCP Kubernetes мы потеряли CICD, Feature Branch deployments, Blue/Green deployment. На Kubernetes все это несколько сложнее и требует иной реализации, но наверняка делается посредством все тех же Github Actions. В новом облаке следуем концепции Iac (Infrastructure-as-Code) вместе с Pulumi.

От старого приложения нам достались низкая производительность и слишком продолжительное время запросов к базе данных. Устранение этих проблем среди приоритетов на ближайшее будущее.