Что такое .NET Aspire?

Завершено

Облачные экосистемы, такие как Microsoft Azure и Amazon Web Services (AWS), глубоко внедрены в ИТ-отрасль и популярные решения для размещения веб-приложений и веб-служб. Скорее всего, система размещения в облаке — это выбор по умолчанию для приложений, поэтому необходимо убедиться, что созданные приложения предназначены для получения максимальных преимуществ от них.

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

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

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

Что такое ориентированное на облако приложение?

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

  • Облачная инфраструктура. Облачные приложения развертываются в облачных решениях размещения, а не в локальных фермах серверов.
  • Микрослужбы. Облачные приложения реализуются как набор микрослужб, каждый из которых реализует небольшую часть бизнес-функций.
  • Контейнеры. Микрослужбы и другие части приложения разрабатываются и развертываются в контейнерах для обеспечения согласованной среды выполнения.
  • Резервное копирование служб. Вспомогательные ресурсы, такие как базы данных и службы кэширования, можно использовать для предоставления общих функций микрослужб.
  • Современный дизайн. Облачные приложения соответствуют методологии двенадцатифакторных приложений, которая включает такие принципы, как непрерывная интеграция и непрерывное развертывание (CI/CD), удаление, привязка портов и т. д.
  • Автоматизация. Облачные приложения используют инфраструктуру как код (IaC) для автоматизации подготовки и развертывания платформы.

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

Для обеспечения гибкости облачное приложение состоит из набора микрослужб. Каждая микрослужба:

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

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

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

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

Облачные приложения могут реализовать множество преимуществ для вашего бизнеса. Например:

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

Проблемы, представленные облачными приложениями

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

  • Определение приложения. Если разработчики не задокументированы тщательно, разработчики могут понять, какие компоненты составляют полное облачное приложение.
  • Коммуникация. Каждой микрослужбе может потребоваться обмен сообщениями или данными с другими микрослужбами, чтобы сформулировать ответ на запрос пользователя. Хотя вы должны включить такое взаимодействие, это необходимо сделать таким образом, что не тесно связана одна микрослужба с другой. Кроме того, требуется взаимодействие, чтобы оставаться надежным в периоды высокого спроса или во время сбоев служб.
  • Устойчивость. Служба размещения не может быть доступна на 100 %. Необходимо убедиться, что в редких случаях, когда микрослужба недоступна, приложение обрабатывает сбои надежно и сохраняет запросы до тех пор, пока служба не возвращается.
  • Распределенные данные. Каждая микрослужба реализует собственный уровень хранения данных и может не использовать тот же сервер базы данных, что и другие. Необходимо учитывать способ запроса данных из нескольких микрослужб и способ реализации транзакций.
  • Секреты Если приложение обрабатывает любые конфиденциальные данные, каждая микрослужба должна пройти проверку подлинности каждого запроса, который он получает, прежде чем возвращать ответ. Часто секреты, такие как асимметричные и симметричные ключи шифрования, используются для защиты данных и положительной идентификации пользователей и микрослужб. Необходимо учитывать, как эти секреты хранятся и обмениваются в облачном приложении.
  • Подключение разработчика. Новые разработчики должны иметь возможность быстро понять архитектуру приложения и как работать с ним. Необходимо убедиться, что новые разработчики могут ускорить работу без большого количества междоменных знаний или локальной установки.

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

Что такое .NET Aspire?

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

Оркестрация

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

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

При создании решения .NET Aspire вы увидите новый проект в решении с именем <SolutionName>. AppHost. Этот проект реализует оркестрацию для приложения, и вы должны убедиться, что это начальный проект для решения.

Компоненты

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

  • Хранилище данных. Чтобы сохранить данные для поддержки каталогов продуктов, корзины покупок, магазинов удостоверений и других функций, микрослужбы должны хранить данные в структурированных или полуструктурированных хранилищах.
  • Кэширование. Чтобы повысить производительность, микрослужбы могут хранить частичные или полные ответы в кэше, чтобы последующие аналогичные запросы могли быть удовлетворены быстрее.
  • (Проекты разработки с открытым кодом в .NET). Слабо связанные микрослужбы должны взаимодействовать друг с другом, и вы должны убедиться, что эта связь надежна даже в том случае, если трафик является высоким или сетевым состоянием является сложным. Служба, которая помещает в очередь и распределяет сообщения от отправителей получателям, является общим требованием.

В .NET Aspire легко реализовать эти службы поддержки в каждой микрослужбе, так как стек включает компоненты .NET Aspire. Каждый компонент — это пакет NuGet, который можно добавить в решение и реализует стандартный интерфейс в службу резервной копии. Этот стандартный интерфейс гарантирует, что микрослужба подключается к своим службам резервного копирования последовательно и без проблем.

Встроенные компоненты .NET Aspire включают:

  • Компоненты хранилища данных, такие как для PostgreSQL, База данных SQL, Azure Cosmos DB и MongoDB.
  • Кэширование компонентов, таких как компонент Для Redis.
  • Компоненты обмена сообщениями, такие как RabbitMQ и Служебная шина Azure.

Внимание

.NET Aspire включает множество компонентов, которые работают со службами Azure, такими как служба хранилища Azure и Служебная шина Azure, но Azure не требуется для проектов .NET Aspire, и они работают одинаково хорошо со службами резервного копирования за пределами Azure, такими как RabbitMQ и MongoDB.

Средства

.NET Aspire также добавляет средства, доступные разработчикам в Visual Studio. Например:

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

Примечание.

Дополнительные сведения о средствах .NET Aspire см. далее в этом модуле.

Подробнее