День восемьсот шестьдесят пятый.
Почему ASP.NET Приложение Такое Медленное? 10 Проблем с Производительностью и Их Решения. Продолжение
Начало (1)
Продолжение (2-4)

5. Ненужные клиентские запросы
Иногда удаётся значительно сократить количество клиентских запросов. Уменьшите это число, и вам потребуется будет меньше серверных машин или уменьшится нагрузка на существующие. Вот несколько способов сделать это:
- Тротлинг.
Рассмотрим механизм автозаполнения при поиске в Google. Когда вы начинаете вводить буквы, Google показывает раскрывающийся список с наиболее частыми поисковыми запросами, начинающимися с этих букв. Чтобы выдать эти данные автозаполнения, Google должен получить их с сервера. Допустим, вы набираете «Табуляция или пробелы». Google может отправить на свой сервер 15 запросов - на «Т», «Та», «Таб» и так далее. Но в этом нет необходимости. Лучше реализовать простой механизм тротлинга, который ожидает, пока вы не перестанете печатать, в течение 500 миллисекунд, а затем отправляет один запрос.
- Кэширование на стороне клиента.
Продолжая наш пример автозаполнения в поиске Google, есть много запросов, которые начинаются с одних и тех же слов. например, «Почему…», «Надо ли…», «Где…» и т. д. Вместо того, чтобы отправлять запросы для них каждый раз, Google может заранее сохранять наиболее распространённые результаты автозаполнения на стороне клиента, исключая ненужные запросы.
- Пакетная обработка.
Предположим на секунду, что Google шпионит за действиями пользователей, чтобы воспользоваться персонализированными данными… (предположим!). При использовании Gmail может потребоваться отправлять данные телеметрии каждый раз, когда вы читаете электронное письмо и наводите указатель мыши на определённое слово. Google может отправлять запрос для каждого такого случая, но будет более эффективным сохранить несколько таких случаев, а затем отправить их в одном запросе.

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

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

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

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

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

Решение, конечно, в масштабировании. Это можно сделать двумя способами: вертикальное (также известное как scaling up - больше ядер CPU и памяти) и горизонтальное (также известное как scaling out - добавление большего количества машин). Облачные провайдеры обычно предлагают варианты простого автоматического масштабирования, которые стоит рассмотреть.

Окончание следует…

Источник: https://michaelscodingspot.com/slow-asp-net-server/

День восемьсот шестьдесят шестой.
Почему ASP.NET Приложение Такое Медленное? 10 Проблем с Производительностью и Их Решения. Окончание
Начало (1)
Продолжение (2-4)
Продолжение (5-7)

8. Сбои сервера
Как и зависания запросов, сбои сервера могут проявляться как проблемы с производительностью. Когда во время запроса происходит обычное исключение, приложение не вылетает. Сервер возвращает ответ об ошибке 500, и всё продолжается как обычно. Но сбой может произойти, если исключение случится вне контекста запроса, например, в потоке, который вы запустили сами. Помимо этого, существуют катастрофические исключения, такие как OutOfMemoryException, ExecutionEngineException и моё любимое StackOverflowException. Они приводят к сбою процесса независимо от того, сколько блоков catch вы разместите.

Когда приложение ASP.NET, размещённое в IIS, даёт сбой, сервер временно отключается. IIS выполняет перезапуск пула приложений, который перезапустит ваш сервер и вернётся к обычному режиму работы. Последствием для клиента будут временные медленные ответы или ошибки 503.

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

9. Чрезмерная функциональность для каждого запроса
Довольно часто ваши запросы украшают дополнительными функциями. Они могут иметь форму промежуточного ПО ASP.NET Core или фильтров действий. Эти функции могут включать в логирование, авторизацию, добавление заголовков ответов или что-то еще. Обратите особое внимание на эти фрагменты кода, потому что они выполняются для каждого запроса.

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

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

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

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

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

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

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

Источник: https://michaelscodingspot.com/slow-asp-net-server/

День восемьсот шестьдесят седьмой.
Работа с Текстом в .NET с Помощью Humanizer
Для передачи сообщений в UI нам довольно часто требуется работать с текстом. NuGet пакет Humanizer серьёзно упрощает эту работу, позволяя выполнять десятки различных преобразований с помощью вызова методов расширения на строках и числах. Например:

"hello_world".Humanize(); // hello world

Помимо этого, методу можно передать значение перечисления LetterCasing и сделать заглавной первую букву строки, первую букву каждого слова или все буквы. При этом он не трогает популярные аббревиатуры, вроде HTML. Возможно и обратное преобразование из предложения в PascalCase строку.

Пока не сильно впечатляет? Подождите, вот лишь некоторые функции, которые мне показались наиболее интересными:
- Truncate(n) – обрезает строку до n символов и добавляет многоточие,
- Humanize(), применённая к значению enum, выдаёт либо предложение из PascalCase имени значения, либо значение атрибута Description, если он задан. Кроме того, если значение помечено атрибутом Display с данными локализации (Description и ResourceType), Humanize() выдаст локализованное описание.
- Humanize() на значении типа DateTime выдаст популярные в соцсетях строки о времени размещения поста: (минуту назад, час назад, вчера и т.п.) – всё относительно текущего времени.
- Humanize() на значении типа TimeSpan распишет период с заданной точностью, вроде: 2 недели, 3 дня, 6 часов и 24 минуты.
- ToQuantity(n) – выдаст строку вида «n штук» с правильным окончанием.
- Ordinalize() на целом значении выдаст порядковый номер, вроде 1ый, 2ой и т.п.
- ToWords() на числе выдаст число словами, например: сто двадцать три.
- ToOrdinalWords() на числе выдаст порядковый номер.
- ToOrdinalWords() на дате выдаст полное написание даты в текущей культуре, например, January 1st, 2015 для en-US.
- ToRoman() и FromRoman() – перевод из арабских чисел в римские и наоборот.
- Seconds(), Minutes(), Hours(),… позволяют использовать Fluent API для дат, например: DateTime.Now + 2.Days() + 3.Hours() - 5.Minutes()
- Bytes(), Kilobytes(), Megabytes(),… - аналогично позволяют переводить размеры в байтах, а Humanize() на результате выдаст «человеческое» представление размера, например:

(.5).Gigabytes().Humanize(); // 512 MB

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

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

Подробнее читайте на страничке проекта в GitHub.

Источник: https://youtu.be/bLKXqJwRNSY

День восемьсот шестьдесят восьмой. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
88. Убунту-программирование
Часто мы пишем код в изоляции, и этот код отражает нашу личную интерпретацию проблемы, а также наше индивидуальное видение решения. Мы можем быть частью команды, но мы изолированы от команды. Мы слишком легко забываем, что этот код, созданный в изоляции, будет выполняться, использоваться, расширяться и использоваться другими. Легко упустить из виду социальную сторону создания программного обеспечения. Создание программного обеспечения - это техническая задача, смешанная с социальной задачей. Нам просто нужно чаще поднимать голову, чтобы понять, что мы не работаем изолированно, и мы несём общую ответственность за повышение вероятности успеха для всех, а не только для команды разработчиков.

Вы можете писать качественный код изолированно, всё время находясь в себе. С одной стороны, это эгоцентричный подход (эго в смысле эгоизма, а в смысле личности). Этого же придерживается Дзен: когда вы создаёте код, всё крутится вокруг вас. Я всегда стараюсь жить настоящим моментом, потому что это помогает мне писать более качественно, но при этом я живу в собственном моменте. А как насчёт момента моей команды? Мой момент совпадает с моментом команды?

На зулусском языке философия Убунту формулируется как «Umuntu ngumuntu ngabantu», что примерно переводится как «Человек - это личность в глазах (других) личностей». Мне становится лучше, потому что ты делаешь меня лучше. Обратной стороной является то, что ты становишься хуже в том, что делаешь, когда я плох в том, что я делаю. Что касается разработчиков, мы можем сузить эту формулировку до «Разработчик - это разработчик в глазах (других) разработчиков». Или совсем узко: «Код - это код с точки зрения (другого) кода».

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

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

Дзен – это про личность. Убунту - это дзен для группы людей. Мы очень редко мы создаём код только для самих себя.

Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Aslam Khan

День восемьсот шестьдесят девятый. #ЗаметкиНаПолях
Различные Способы Проверки на Null в C#
В .NET существует несколько способов проверки на null. Но не все они равнозначны. Рассмотрим различные способы проверки:

object obj = ...;

// Основные проверки
obj == null;
object.Equals(obj, null);
object.ReferenceEquals(obj, null);

// Аналогичны ReferenceEquals(obj, null)
obj is null;
(object)obj == null;

// Аналогичны !ReferenceEquals(obj, null)
obj is not object;
obj is not {};

// Не работает, выдаёт NullReferenceException 
obj.Equals(null);

Есть 3 основных способа:
1. object.ReferenceEquals(obj, null)
ReferenceEquals возвращает true, если экземпляры объекта являются одним и тем же экземпляром. В этом случае он возвращает true, если obj имеет значение null.

2. object.Equals(obj, null)
Equals аналогичен ReferenceEquals, когда один аргумент имеет значение null. Однако логика этого метода сложнее, чем ReferenceEquals, и немного медленнее, поскольку вызов метода не всегда встраивается.

3. obj == null
Оператор == аналогичен ReferenceEquals, если вы не определяете оператор равенства для класса. Если оператор определён, компилятор использует его вместо оператора по умолчанию. В этом случае логика сравнения настраивается, и она может и не учитывать проверку на null. Вы можете заставить компилятор использовать оператор ==, определённый для object, путём явного преобразования объекта к object.

Заметьте, что is null не работает со структурами, кроме обнуляемых:

MyStruct a = default;

// Ошибка компиляции
_ = a is null;

// Работает, только если MyStruct 
//  определяет оператор ==
_= a == null;  

Span<char> span = default;

// Ошибка компиляции
_ = span is null;

// Работает, т.к. Span определяет оператор ==
_ = span == null;

int? b = null;
// Аналогично !b.HasValue 
_ = b is null;

Заметьте, что хотя сопоставления с образцом is not null, is object и is {} аналогичны одной и той же проверке на null (см. выше), использование их вместе с объявлением переменной различается:

// Ошибка компиляции
if (obj is not null x) { … }
// OK, х – типа object
if (obj is object x) { … }
// OK, x – того же типа, что и obj
if (obj is {} x) { … }

Источник: https://www.meziantou.net/null-check-in-csharp.htm

День восемьсот семидесятый. #Оффтоп
Добрейшей пятницы. Пока желающие качают превью Visual Studio 2022, вот вам развлечение на это время.

Давненько я не рекомендовал интересных YouTube каналов. И вот на днях попался мне канал Dave’s Garage. А конкретнее, видео «Software Drag Racing: C++ vs C# vs Python - Which Will Win?» Какой язык программирования быстрее? Что может быть более холиварной темой?

Автор канала – David Plummer, бывший инженер операционных систем в Microsoft, работавший ещё аж над MS DOS и Windows 95 (в частности, он создатель Диспетчера задач Windows). Так вот, он решил проверить, какой язык быстрее справится с алгоритмом нахождения всех простых чисел меньше заданного.

В видео рассказывается про собственно алгоритм (сильно оптимизированный, байто…черы оценят), его реализацию на Python, C# и C++, ну и, собственно, бенчмарк в виде количества выполнений алгоритма за 5 секунд.
Результаты спойлерить не буду, смотрите видео.

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

А вообще, канал очень понравился. Олдам зайдут и другие видео с байками, вроде Почему возникает синий экран смерти, и почему он синий, Почему перезагрузка решает все проблемы (и при чём тут ботинки) или Секретная история активатора Windows.

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

День восемьсот семьдесят первый.
Странное Разрешение Имён Перечислений в C#
Рассмотрим следующий код:

using System;
namespace Test
{
  enum Foo {
    A = 1, B = 1, C = 1
  }
    
  public static class Program
  {
    public static void Main()
    {
      Console.WriteLine("{0}, {1}, {2}", 
        Foo.A, Foo.B, Foo.C);
    }
  }
}

Странно, но этот код выдаёт строку B, B, B. Это поведение одинаково и в .NET Framework, и в .NET Core 3.x, и в .NET 5.

Почему он выбирает B?

Согласно документации для Enum.GetName():
Если несколько членов перечисления имеют одно и то же значение, метод GetName гарантирует, что он вернёт имя одного из этих членов перечисления. Однако он не гарантирует, что всегда будет возвращать имя одного и того же члена перечисления.

Так что формально могло бы возвратиться что угодно. Почему же всё-таки возвращается B?

За объяснением можно обратиться к реализации GetEnumName().

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

Источник: https://stackoverflow.com/questions/67091644/weird-enum-name-resolution-in-c-sharp

День восемьсот семьдесят второй. #Оффтоп #КакСтатьСеньором

Проектирование
Почему я ставлю проектирование после написания кода и тестирования? Оно может идти и первым, но, если бы я не писал код и не тестировал его в среде, в которой я нахожусь (под средой тут понимается в том числе и стек технологий), я, вероятно, не смог бы спроектировать систему, которая учитывает особенности среды.
При проектировании системы нужно о многом подумать:
- Какая будет нагрузка?
- Сколько существует пользователей и каков их ожидаемый прирост? (Это может повлиять на размер БД)
- Какие могут быть подводные камни в будущем?

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

Конечно, просто собрать требования - это еще не всё, о чем стоит подумать. Включение процессов разработки в проектирование также окупается:
- Как будет организовано написание кода, сборка, развёртывание и CI/CD?
- Как мы будем проводить сквозное и нагрузочное тестирование?
- Как мы будем управлять секретами?

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

Проектирование с учетом поддержки
Проектировать системы - это увлекательно. Поддерживать их – не очень. Рано или поздно задаёшься вопросом, почему и как системы деградируют?

Во-первых, проблема в нежелании выбрасывать старые вещи, всегда добавляя новые. Склонность к добавлению вместо удаления (есть за вами такой грешок?)

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

Есть как минимум три способа снизить скорость деградации:
1. Разделяйте бизнес-логику и инфраструктуру. Обычно быстрее деградирует инфраструктура: увеличивается нагрузка, фреймворки устаревают, появляются уязвимости и т.д.
2. Стройте процессы вокруг поддержки. Обновляйте как новый, так и устаревший код. Это предотвращает различие между новыми и старыми частями и сохраняет весь код «современным».
3. Убедитесь, что вы на постоянной основе избавляетесь от всех ненужных/устаревших вещей.

Источник: https://neilkakkar.com/things-I-learnt-from-a-senior-dev.html
Автор оригинала – Neil Kakkar

День восемьсот семьдесят третий.
RestClient.Net 5
RestClient.Net упрощает HTTP-вызовы в .NET. Вы можете отправлять строго типизированный объект в теле запроса и получать обратно строго типизированный объект. Вы можете внедрить абстракцию в сервисные классы и легко имитировать его в тестах, не беспокоясь о подключении HTTP или преобразовании в JSON. RestClient.Net 5 значительно улучшен, относительно 4й версии: представлены неизменяемые типы и fluent API. Он прекрасно работает с внедрением зависимостей, интегрируется с Polly, а дизайн должен быть знаком и удобен программистам на F#.

Зачем использовать Rest Client?
HttpClient значительно затрудняет модульное тестирование вашего кода. Прежде всего, HttpClient не имеет простой абстракции. Если вы хотите имитировать HttpClient для модульного тестирования, вам необходимо внедрить DelegatingHandler в клиента. Даже в этом случае вам нужно имитировать преобразование в необработанные данные и обратно. Это отвлекает от простого действия по проверке того, что клиент отправляет и получает правильный объект.

RestClient.Net решает эту проблему с помощью интерфейса IClient. Вы отправляете строго типизированный объект и в теле ответа получаете строго типизированный объект.

using var client = new Client(
  "jsonplaceholder.typicode.com".ToHttpsUriFromHost());
UserPost userPost = 
  await client.PostAsync<UserPost, UserPost>(
    new UserPost { title = "Title" }, "posts"
  );

Внедрение зависимости
Вы можете напрямую внедрить интерфейс IClient или использовать фабричный подход с CreateClient. Пакет RestClient.Net.DependencyInjection работает с внедрением зависимостей ASP.NET Core и использует реализацию IHttpClientFactory по умолчанию для создания HttpClient. Это означает, что RestClient.Net всегда получает HttpClient через фабрику, которая поддерживается Microsoft.

Url-адреса
RestClient.Net использует библиотеку Urls вместо System.Uri. Это упрощает создание URL-адресов, делает их более читаемыми и менее подверженными ошибкам. Добавление пути и строки запроса к базовому URL-адресу всегда безопасно, и вам не нужно беспокоиться об объединении строк вручную:

var absoluteUrl =
  Host.ToHttpUrlFromHost(Port)
  .AddQueryParameter(FieldName1, FieldValue1)
  .WithCredentials(Username, Password)
  .AddQueryParameter(FieldName2, FieldValue2)
  .WithFragment(Fragment)
  .WithPath(PathPart1, PathPart2);

Этот подход я подробнее описывал для пакета Flurl.

Неизменяемые типы
HttpClient позволяет изменять множество свойств. Это означает, что, если несколько частей вашей системы используют один и тот же экземпляр, они могут изменить какое-то свойство и сломать другую часть системы. Например, один класс может добавить заголовок по умолчанию, а другой класс может удалить его.
Все классы в RestClient.Net неизменяемы. Вы не можете изменить их значения после создания экземпляра. Вы можете быстро клонировать существующего клиента, используя методы With или использовать параметры фабрики CreateClient, чтобы указать свойства клиента.

Кроме того
- RestClient.Net поддерживает .NET Framework 4.5 и .NET Standard 2.0.
- Тщательно протестирован с помощью Stryker Mutator.
- Простой в использовании и легко масштабируется. Вы можете выполнить HTTP-вызов в одну строку кода, а затем повторно использовать клиента и выполнять последующие вызовы, задавая новые URL.

Источник: https://christianfindlay.com/2021/05/26/restclient-net-5/

День восемьсот семьдесят четвёртый.
Ответы на Самые Популярные Вопросы по Микросервисам в .NET
1. При масштабировании сервисов как мы можем масштабировать базы данных, связанные с этими сервисами?
Существуют чётко определенные шаблоны и передовые методы повышения производительности и масштабирования баз данных. Обратитесь к разделу «Горизонтальное, вертикальное и функциональное разбиение данных», чтобы понять, как данные делятся на разделы для повышения масштабируемости, уменьшения числа конфликтов и оптимизации производительности. Чтобы углубиться в темы масштабирования микросервисов, распределённых данных, подхода «база данных на микросервис», выбора между реляционными или NoSQL базами данных, обратитесь к книге «Архитектура облачных приложений .NET для Azure» (PDF).

2. Нужно ли использовать отдельную базу данных для каждого микросервиса или микросервисы могут совместно использовать один и тот же экземпляр базы данных?
Автономность команд при работе со своими микросервисами - важнейшее преимущество архитектуры облачных приложений. Предпочтительно использовать независимые экземпляры базы данных, чтобы дать командам гибкость при развёртывании обновлений и исправлений в производственной среде, не нарушая работу других микросервисов. Архитектура облачных приложений вдохновлена известными методологиями 12-факторных приложений https://12factor.net/ru/. Один из факторов, «Сторонние сервисы», гласит, что вспомогательные ресурсы, такие как хранилища данных, кэши, брокеры сообщений, должны быть доступны через адресный URL. Поставщики облачных услуг предлагают широкий ассортимент управляемых сторонних сервисов.

3. Может ли монолитный веб-API взаимодействовать с микросервисами?
Да. Монолитные приложения могут взаимодействовать с микросервисами, если их конечные точки доступны внутри инфраструктуры или публично через безопасный протокол. Микросервисы и их данные могут использоваться либо синхронно через их конечные точки, либо асинхронно через обмен сообщениями, например шину событий. При модернизации приложения мы рекомендуем паттерн «Душитель» (Strangler), который помогает постепенно переходить с устаревшей системы на новую. В рамках решения вам необходимо создать фасад, который перехватывает запросы. Фасад направляет эти запросы либо в унаследованное приложение, либо в новые сервисы.

4. Если микросервисы слабо связаны и развертываются независимо, как они взаимодействуют друг с другом? Как синхронизировать данные между микросервисами?
Это довольно объёмный вопрос. Он подробно разъясняется в двух разделах книги «Архитектура облачных приложений .NET для Azure»:
- Модели связи в облаке
- Распределённые данные

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

Больше вопросов и ответов в видео Microsoft Let’s Learn: Microservices.

Источник: https://devblogs.microsoft.com/aspnet/your-top-dotnet-microservices-questions-answered/

День восемьсот семьдесят пятый.
ASP.NET Core 6 и Серверы Аутентификации
Начиная с .NET 3.0 IdentityServer4 поставляется как часть шаблона приложения для поддержки выпуска токенов JWT в приложениях SPA и Blazor. Через некоторое время выпуска продукта команда IdentityServer сделала объявление об изменении лицензии для будущих версий IdentityServer на взаимную общественную лицензию (RPL), в которой код по-прежнему является открытым, но, если он используется в коммерческих целях, необходимо покупать платную лицензию. Такой подход распространён в мире открытого исходного кода, где трудно поддерживать доход, поскольку ваш проект становится вашей работой на полную ставку.

Причинами для выпуска IdentityServer было четко выраженное желание сообщества не конкурировать с существующим проектом с открытым исходным кодом и глубокое понимание командой IdentityServer сферы идентификации. Команда .NET не является экспертами по OAuth и OIDC, поскольку они сосредоточены на предоставлении строительных блоков для вашего приложения. Создание и поддержка сервера аутентификации - это полноценная задача. И у Microsoft уже есть команда и продукт в этой области - Azure Active Directory, который позволяет бесплатно использовать 500 000 объектов. Команда ASP.NET считает, что управляемое облачное решение остается лучшим практическим вариантом для разработчиков: безопасность поддерживается, учётные данные не хранятся локально, что сопряжено с риском, а новые функции, такие как аутентификация без пароля, легко внедрить в рабочий процесс. Однако понятно, что облачное решение может быть невозможно для некоторых клиентов из-за проблем с нормативными требованиями или суверенностью данных.

Для .NET 6 Microsoft продолжит поставлять IdentityServer в шаблонах проектов, используя новую лицензию RPL. IdentityServer по-прежнему рассматривается как наиболее зрелый вариант для создания самостоятельно развёртываемой, локально размещённой службы токенов в ASP.NET Core. Требования к лицензированию будут отдельно описаны, если вы используете шаблон, который включает Duende IdentityServer. Новый Duende IdentityServer по-прежнему имеет открытый исходный код, но теперь имеет двойную лицензию. Эта лицензия позволяет использовать его бесплатно для разработки, тестирования и обучения, бесплатно для некоммерческих программ с открытым исходным кодом и бесплатно для использования в коммерческих условиях, если компания зарабатывает менее 1 миллиона долларов США в год. В других случаях лицензия требует платы за использование в коммерческих целях. Предыдущая версия IdentityServer будет по-прежнему поддерживаться, пока поддерживается .NET 5, примерно до февраля 2022 года.

Для .NET 7 вопрос создания инструментов, позволяющих разрабатывать и тестировать приложения с поддержкой OIDC (OpenID Connect), пока открыт. Вы всегда сможете выбрать любую систему идентификации, которая лучше всего подходит для вашей среды, обновив всего несколько строк кода.

Про лицензирование IdentityServer, кстати, говорили в недавнем выпуске подкаста .NET Rocks «Open Source in the Enterprise with Rocky Lhotka». Вообще обсуждалась проблема использования открытого кода в энтерпрайз приложениях. Какие риски возникают в связи с этим, как правильно использовать открытые лицензии, и что будет, если, к примеру, какой-то из используемых модулей перестанет поддерживаться (как это случалось неоднократно). В разрезе IdentityServer, по словам авторов подкаста, история была в том, что компании просили сделать платную лицензию, чтобы была постоянная возможность обращаться в техподдержку, а у создателей IdentityServer соответственно обязательство оперативно решать проблемы клиентов, которого не может возникать при использовании открытого кода.

Источник: https://devblogs.microsoft.com/aspnet/asp-net-core-6-and-authentication-servers/

День восемьсот семьдесят шестой. #ЧтоНовенького #ЗаметкиНаПолях
Работа с PriorityQueue в .NET 6
Я недавно писал про новый класс PriorityQueue, предложенный в .NET 6.
В отличие от обычной очереди, работающей по принципу FIFO (первым пришёл - первым ушёл), очередь с приоритетом не имеет красивого акронима. Заданный пользователем приоритет определяет, какой элемент является «первым». PriorityQueue определяет приоритет значений с помощью реализации интерфейса IComparer.

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

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

PriorityQueue<string, Greatness> heroes 
    = new(new GreatnessComparer());

heroes.Enqueue("Captain America", GOAT);
heroes.Enqueue("Spider-Man", Great);
heroes.Enqueue("Dr. Strange", Good);
heroes.Enqueue("Thor", Great);
heroes.Enqueue("Iron Man", Ok);
heroes.Enqueue("Hulk", Good);

while (superheroes.TryDequeue(out var hero, out var greatness))
  Console.WriteLine($"{hero} ({greatness})");

Здесь величие определяется в перечислении

public enum Greatness
{
  Ok, Good, Great, GOAT
}

Для него реализован компаратор:

public class GreatnessComparer 
   : IComparer<Greatness>
{
  // от большего к меньшему
  public int Compare(Greatness x, Greatness y) => y - x;
}

PriorityQueue будет определять приоритет наших супергероев, используя реализацию интерфейса IComparer. Запустив программу, мы должны увидеть следующий вывод:

Captain America (GOAT)
Spider-Man (Great)
Thor (Great)
Hulk (Good)
Dr. Strange (Good)
Iron Man (Ok)

Заметьте, что элементы с одинаковым приоритетом не следуют порядку FIFO. На самом деле, порядок их выдачи не определён, т.к. «под капотом» в PriorityQueue лежит дерево элементов.

Источник: https://khalidabuhakmeh.com/working-with-dotnet-six-priorityqueue

День восемьсот семьдесят седьмой. #ЧтоНовенького
Асинхронные Потоки в EF Core и ASP.NET Core 6
Давней проблемой в ASP.NET была невозможность обрабатывать возврат больших файлов JSON без использования большого количества памяти. По умолчанию фреймворк выполняет буферизацию всего вывода сразу, конвертирует его весь в JSON, а затем начинает передавать результаты клиенту. Это может привести к нехватке памяти, если объём данных достаточно велик.

Однако потоковая передача результатов не была проблемой для ASP.NET. При работе с более простыми форматами, такими как CSV, разработчик всегда имел возможность писать прямо в поток результатов.

Начиная с ASP.NET Core 5, класс Utf8JsonWriter может использоваться для достижения того же эффекта. Возникнет несколько сложностей, таких как необходимость явного отключения буферизации, но код сможет работать, если вы, например, последуете совету Александра Васильева.

ASP.NET Core 6 упрощает нашу жизнь, напрямую поддерживая IAsyncEnumerable. Если IAsyncEnumerable возвращается функцией, платформа интерпретирует его как запрос на асинхронную потоковую передачу данных клиенту без буферизации.

Один из способов получить IAsyncEnumerable - использовать Entity Framework Core. Фактически, эта функция присутствовала, начиная с EF Core 3, но до сих пор её полезность на веб-серверах была ограничена. ASP.NET Core не поддерживал результаты типа IAsyncEnumerable до версии 5, но даже в этом случае результаты буферизовались.

В объявлении №463 разработчики были проинформированы о том, что новое поведение IAsyncEnumerable следует рассматривать как критическое изменение.

В большинстве случаев приложение не отслеживает отсутствие буферизации. Однако некоторые сценарии могли непреднамеренно полагаться на семантику буферизации для правильной сериализации. Например, возврат IAsyncEnumerable<>, который поддерживается запросом EF для типа с отложенной загрузкой свойств, может привести к параллельному выполнению запроса, который может не поддерживаться поставщиком.

Чтобы вернуться к предыдущему поведению, разработчикам необходимо явно вызвать ToListAsync():

// До ASP.NET Core 6
public IActionResult Get()
{
  return Ok(dbContext.Blogs);
}

// Начиная с ASP.NET Core 6
public async Task<IActionResult> Get()
{
  return Ok(await dbContext.Blogs.ToListAsync());
}

Кроме того, для решения проблемы можно отключить отложенную загрузку.

Источник: https://www.infoq.com/news/2021/06/ASP-Net-Core-6-IAsyncEnumerable/

День восемьсот семьдесят восьмой. #Оффтоп #Здоровье
Сегодня не про программирование, но тема не менее важная – здоровье. Как всегда случайно наткнулся в ютубе на занятное видео про поддержание здоровья и продуктивности при нашем сидячем образе жизни. Там даётся 10 советов. Не могу сказать, что со всеми согласен, на некоторые, вроде регулируемого по высоте стола, придётся заметно потратиться. Но некоторые вещи, например, сидение на фитболе и режим работы 25-5 пробовал.

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

День восемьсот семьдесят девятый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
89. Используйте Правильные Алгоритмы и Структуры Данных
Большой банк с множеством филиалов жаловался, что новые компьютеры, которые он закупил для кассиров, слишком медленные. Это было ещё до того, как все начали использовать онлайн банки, а банкоматы не были так широко распространены, как сейчас. Люди ходили в банк гораздо чаще, а из-за медленных компьютеров выстраивались очереди. Тогда банк пригрозил разорвать контракт с поставщиком.

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

for (i=0; i<strlen(s); ++i) {
  if (… s[i] …) …
}

При этом строка s в среднем состояла из тысяч символов. Код (написанный банком) был быстро исправлен, и с тех пор кассиры жили долго и счастливо…

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

n=strlen(s);
for (i=0; i<n; ++i) {
  if (… s[i] …) …
}

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

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

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

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

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

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

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

Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Jan Christiaan “JC” Van Winkel

День восемьсот восьмидесятый. #BestPractices #CodeReview
Лучшие Практики для Эффективных Обзоров Кода. Начало
Обзор кода, если проведён правильно, позволяет разработчикам предоставлять оптимальный исходный код, одновременно узнавая больше об эффективном написании и отладке кода.

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

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

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

1. Знайте, что искать
Разработчики должны точно знать, какие аспекты им следует охватить: дизайн, функциональность, стиль, логику, структуру, согласованность, покрытие тестами, сложность кода и т.д. Некоторые из вышеупомянутых характеристик могут быть проверены автоматически благодаря статическим анализаторам кода (например, структура, логика или покрытие тестами), в то время как другие (например, дизайн и функциональность) требуют проверки вручную.

Чтобы сделать процесс проверки более эффективным, рецензенты должны сосредоточиться на следующих вопросах:
- Можно ли чётко понять, что делает код?
- Код работает так, как ожидалось?
- Соответствует ли код нормативным требованиям?
Если они могут ответить на эти вопросы с уверенностью «да», код можно считать хорошим.

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

3. Ограничьте время обзора
Эффективная проверка может быть проведена только тогда, когда разработчики на 100% сосредоточены на выполняемой задаче. Большинство исследований показывают, что, когда люди занимаются какой-либо деятельностью, требующей высокой концентрации, их эффективность снижается через 60 минут. При проверке кода не нужно торопиться. Лучше разбить этот процесс на короткие сеансы, что даст разработчикам возможность отдохнуть и тем самым улучшить качество проверки.

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

Окончание следует…

Источник: https://dzone.com/articles/9-best-practices-for-effective-code-review

День восемьсот восемьдесят первый. #BestPractices #CodeReview
Лучшие Практики для Эффективных Обзоров Кода. Окончание
Начало

5. Давайте конструктивную обратную связь
Взаимная проверка кода направлена на повышение производительности команды, а не на разжигание конкуренции между автором кода и рецензентом. В любом случае код необходимо проверять. И если разработчики воспринимают это как процесс обучения, а не критику своей работы, это способствует общему успеху проекта. Получение конструктивной обратной связи побудит разработчиков учиться на своих ошибках и расширять свои возможности. Рецензенты могут оставлять комментарии с префиксом «Nit:» (от «nitpicking» - придирки). Это означает, что такие вещи не обязательно должны исправляться, а имеют образовательную цель и помогают разработчикам постоянно совершенствовать свои навыки. Например:

var file = app != null && !string.IsNullOrEmpty(app.FilePath);
// Nit: может быть заменено на 
//  !string.IsNullOrEmpty(app?.FilePath);

6. Установка целей и сбор метрик
Если цели процесса обзора кода определены заранее, гораздо проще измерить эффективность кода и решить, приносит ли проверка пользу и помогает ли достичь ожидаемых результатов. Настройка внешних и внутренних показателей позволяет разработчикам улучшить качество кода. Примерами внешних показателей могут быть «уменьшение процента дефектов, сообщаемых конечными пользователями» или «уменьшение количества дефектов, обнаруженных до запуска продукта».

Внутренние показатели включают:
- Скорость проверки.
- Дефектность: среднее количество ошибок, обнаруженных за один сеанс.
- Плотность дефектов: среднее количество ошибок на строку кода.

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

// Начинаем с 1, чтобы 0 был недопустимым
// и это можно было проверять при передаче параметра извне
public enum SupplierStatsType {
  All = 1, General = 2, Custom = 3
}

8. Используйте чек-листы
Разработчик – человек, поэтому может упустить из виду некоторые аспекты кода. Чек-лист сделает процесс проверки более последовательным, поскольку будет постоянно напоминать о том, что следует проверять. Он особенно полезен для рецензента, поскольку помогает проводить проверку по конкретным критериям. Однако существует и такое понятие, как личный чек-лист. Если автор кода знает о своих типичных ошибках и недостатках в работе, он может составить чек-лист, чтобы постоянно улучшать качество своего кода. Кроме того, чек-листы проверки кода очень важны для выявления упущений, которые труднее всего проверять, потому что сложно обнаружить отсутствие чего-либо.

Вот некоторые вопросы для чек-листа:
- Легко ли понять код?
- Соответствует ли форматирование кода соглашению по проекту?
- Достаточно ли модульная структура кода?
- Соответствует ли выбранное решение требованиям?
- Проверена ли вся логика и все ошибки?
- Есть ли проблемы в безопасности?
- Как дела с производительностью? (Есть ли очевидные моменты для оптимизации?)
- Весь ли код покрыт тестами?
- Насколько эффективно и информативно описание пул реквеста?

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

Источник: https://dzone.com/articles/9-best-practices-for-effective-code-review

День восемьсот восемьдесят второй. #ЧтоНовенького
Горячая Перезагрузка и Другие Обновления ASP.NET Core в .NET 6 Preview 5
Горячая Перезагрузка (Hot Reload) - долгожданная функциональность, позволяющая разработчикам вносить изменения в код во время отладки, которые мгновенно отражаются в работающем приложении без необходимости перезапуска - была представлена ​​на конференции разработчиков May Build. Она поддерживалась в ранней неполной форме в Visual Studio 2019 версии 16.11 Preview 1. С тех пор были добавлены дополнительные улучшения.

Для ASP.NET Core основное улучшение Hot Reload затрагивает dotnet watch - инструмент командной строки (CLI), который выполняет команду .NET Core при изменении исходных файлов и обновляет браузер при обнаружении изменений в наблюдаемых файлах. Это позволяет перезагружать проекты ASP.NET Core в реальном времени.

Больше не нужно указывать hotReloadProfile в launchSettings.json. .NET Hot Reload с соответствующим поведением проекта теперь включена по умолчанию. Когда вносится изменение, которое не может быть перезагружено горячим способом («грубое» изменение), dotnet watch теперь спросит, хотите ли вы перезапустить приложение, чтобы применить изменение. «Грубые» изменения в приложениях Blazor WebAssembly будут применены при обновлении браузера или при загрузке приложения в отдельной вкладке или новом окне браузера.

Размеры загружаемых файлов Blazor WebAssembly были уменьшены с помощью функции, известной как повторное связывание (relinking). Она позволяет исключить ненужную логику выполнения - такую ​​как глобализация - из загрузки.

Другие новинки ASP.NET Core .NET 6 Preview 5:
- Шаблоны ASP.NET Core SPA обновлены до Angular 11 и React 17
- Использование синтаксиса Razor в элементах SVG foreignObject
- Настраиваемый порог буфера перед записью на диск в Json.NET
- Подкатегории для лучшей фильтрации журналов Kestrel
- Более быстрое получение и установка заголовков HTTP
- Настраиваемый размер входящего буфера для IIS

Пока существуют известные проблемы с использованием ASP.NET Core в .NET 6 Preview 5:
1. Начиная с .NET 6 Preview 1, существует проблема с запуском приложений Blazor WebAssembly с использованием сервера IIS Express во время разработки в Visual Studio. Чтобы обойти это, рекомендуется использовать Kestrel во время разработки.

2. Начиная с .NET 6 Preview 3, изменения представлений Razor не будут обновляться во время инкрементных сборок. Чтобы обойти это, вы можете:
- Осуществлять сборку из командной строки
- Настроить VS, чтобы всегда вызывать MSBuild при сборке проектов
- Очищать и собирать проекты, чтобы изменения отражались

3. Начиная с .NET 6 Preview 5, при использовании обработчика JWT Bearer в часовом поясе выше, чем UTC (например, UTC+2), вы можете наблюдать исключение ArgumentOutOfRangeException, если токен JWT не содержит значение nbf (Действует с). Проблема отслеживается здесь и будет исправлена в .NET 6 Preview 6.
Вы можете обойти это, всегда предоставляя ненулевое и не минимальное значение для параметра notBefore при использовании System.IdentityModel.Tokens.Jwt.JwtSecurityToken или поле 'nbf' при использовании другой библиотеки JWT.

Источник: https://visualstudiomagazine.com/articles/2021/06/18/aspnet-core-updates.aspx

День восемьсот восемьдесят третий. #DesignPatterns #Microservices
Микросервисная Архитектура и Паттерны Проектирования
Существует множество определений микросервисной архитектуры. Вот одно из них:
Микросервисная архитектура представляет собой вертикальное разделение больших сложных систем (по функциональным или бизнес-требованиям) на более мелкие подсистемы, которые являются отдельными процессами (следовательно, могут развёртываться независимо), и эти подсистемы взаимодействуют друг с другом через лёгкие, не зависящие от языка сетевые вызовы либо синхронным (например, через REST, gRPC) или асинхронным (через обмен сообщениями) способом.

Компонентное представление бизнес-веб-приложения с микросервисной архитектурой представлено на рисунке ниже.

Характеристики:
- Всё приложение разделено на отдельные процессы, каждый из которых может содержать несколько внутренних модулей.
- В отличие от модульных монолитов или сервисно-ориентированной архитектуры, микросервисное приложение разделено по вертикали (в соответствии с бизнес-потребностями или доменами).
- Границы микросервисов внешние, то есть микросервисы взаимодействуют друг с другом через сетевые вызовы (RPC или сообщения).
- Поскольку микросервисы являются независимыми процессами, их можно развёртывать независимо.
- Они общаются легко и не нуждаются в каком-то хитром канале связи.

Преимущества:
- Лучшее масштабирование разработки.
- Более высокая скорость разработки.
- Поддерживается итеративная или инкрементная модернизация.
- Возможность использовать преимущества современной экосистемы разработки ПО (облако, контейнеры, DevOps, бессерверная среда).
- Поддерживается как горизонтальное, так и гранулярное масштабирование (возможность масштабировать отдельные микросервисы).
- Благодаря меньшему размеру, снижается нагрузка на разработчиков, которым не приходится держать в голове большую систему.

Недостатки:
- Большее количество элементов (сервисы, базы данных, процессы, контейнеры, фреймворки).
- Сложность переходит от кода к инфраструктуре.
- Большее количество вызовов RPC и сетевого трафика.
- Управление безопасностью всей системы является сложной задачей.
- Проектировать всю систему сложнее.
- Возникают сложности распределённых систем.

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

Источник: https://towardsdatascience.com/microservice-architecture-and-its-10-most-important-design-patterns-824952d7fa41

День восемьсот восемьдесят четвёртый. #DesignPatterns #Microservices
Паттерны в Микросервисах
1. База Данных на Микросервис
Когда компания заменяет большую монолитную систему множеством мелких микросервисов, самое важное решение, с которым она сталкивается, - это база данных. В монолитной архитектуре используется большая централизованная база данных. Многие архитекторы предпочитают сохранять базу данных как есть, даже при переходе на микросервисную архитектуру. Хотя это даёт некоторую краткосрочную выгоду, это анти-шаблон, особенно в крупной системе, поскольку микросервисы будут тесно связаны на уровне базы данных. Весь смысл перехода на микросервисы (расширение возможностей команды, независимая разработка) потеряется.

Лучший подход - предоставить каждому микросервису собственное хранилище данных, чтобы не было сильной связи между службами на уровне базы данных (см. рисунок ниже). Здесь термин «база данных» используется, чтобы показать логическое разделение данных, то есть микросервисы могут совместно использовать одну и ту же физическую базу данных, но они должны использовать отдельную схему/коллекцию/таблицу. Это также гарантирует, что микросервисы правильно разделены в соответствии с предметно-ориентированным проектированием (DDD).

Плюсы
- Полное владение данными для каждого сервиса.
- Слабая связь между командами, разрабатывающими сервисы.

Минусы
- Обмен данными между службами становится проблематичным.
- Предоставление транзакционной гарантии ACID для приложения становится намного сложнее.
- Разделение монолитной базы данных на более мелкие части требует тщательного проектирования и является сложной задачей.

Когда использовать:
- В крупномасштабных корпоративных приложениях.
- Когда команде необходимо полное владение своими микросервисами для масштабирования и скорости разработки.

Когда не использовать:
- В небольших приложениях.
- Если одна команда разработает все микросервисы.

Поддержка
Все базы данных SQL и NoSQL предлагают логическое разделение данных (например, отдельные таблицы, коллекции, схемы, базы данных).

Подробнее:
- Microservices Pattern: Database per service
- Распределённые данные

Источник: https://towardsdatascience.com/microservice-architecture-and-its-10-most-important-design-patterns-824952d7fa41