Шаблон надежного веб-приложения для .NET

В этой статье приведены рекомендации по реализации шаблона Reliable Web App. В этом шаблоне описывается изменение веб-приложений (replatform) для миграции в облако. Он предоставляет предписательную архитектуру, код и рекомендации по настройке, которые соответствуют принципам Azure Well-Architected Framework.

Почему шаблон Надежных веб-приложений для .NET?

Шаблон Reliable Web App — это набор принципов и методов реализации, определяющих способ переплатформирования веб-приложений при их переносе в облако. Он фокусируется на минимальных обновлениях кода, необходимых для успешного выполнения в облаке. В следующем руководстве в качестве примера используется эталонная реализация. Руководство следует переплатформе вымышленной компании Relecloud, чтобы обеспечить бизнес-контекст для вашего путешествия. Прежде чем реализовать шаблон Reliable Web App для .NET, Relecloud имел монолитное локальное веб-приложение для билетов, которое использовало платформу ASP.NET.

Реализация шаблона Reliable Web App

В этой статье содержатся рекомендации по архитектуре, коду и настройке для реализации шаблона Reliable Web App. Чтобы перейти к определенному руководству, воспользуйтесь приведенными ниже ссылками:

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

Бизнес-контекст

Первым шагом в переплатформировке веб-приложения является определение бизнес-целей. Необходимо задать немедленные цели, такие как цели уровня обслуживания (SLO) и целевые показатели оптимизации затрат, а также будущие цели для веб-приложения. Эти цели влияют на выбор облачных служб и архитектуру веб-приложения в облаке. Определите целевой SLO для веб-приложения, например 99,9 % времени простоя. Вычислите составное соглашение об уровне обслуживания для всех служб, влияющих на доступность веб-приложения.

Например, Relecloud имеет положительный прогноз продаж и ожидает повышенного спроса на их веб-приложение для билетов. Для удовлетворения этого требования они определили цели веб-приложения:

• Примените недорогие изменения кода с высоким уровнем стоимости.
• Достичь SLO 99,9%.
• Внедрение методик DevOps.
• Создание оптимизированных для затрат сред.
• Повышение надежности и безопасности.

Локальная инфраструктура Relecloud не была экономически эффективным решением для достижения этих целей. Они решили, что перенос веб-приложения в Azure является самым экономичным способом достижения своих непосредственных и будущих целей.

Руководство по архитектуре

Шаблон Reliable Web App содержит несколько важных архитектурных элементов. Вам требуется DNS для управления разрешением конечных точек, брандмауэром веб-приложения для блокировки вредоносного HTTP-трафика и подсистемой балансировки нагрузки для маршрутизации и защиты входящих запросов пользователей. Платформа приложений размещает код веб-приложения и выполняет вызовы ко всем внутренним службам через частные конечные точки в виртуальной сети. Средство мониторинга производительности приложений записывает метрики и журналы, которые помогут вам понять веб-приложение.

Рисунок 1. Основные архитектурные элементы шаблона Reliable Web App.

Разработка архитектуры

Настройте инфраструктуру для поддержки метрик восстановления , таких как цель времени восстановления (RTO) и цель точки восстановления (RPO). RTO влияет на доступность и должна поддерживать SLO. Определите RPO и настройте избыточность данных для соответствия RPO.

• Выберите надежность инфраструктуры. Определите количество зон доступности и регионов, необходимых для удовлетворения требований к доступности. Добавьте зоны доступности и регионы, пока составное соглашение об уровне обслуживания не будет соответствовать вашему SLO. Шаблон Reliable Web App поддерживает несколько регионов для конфигурации "активный— активный" или "активный- пассивный". Например, эталонная реализация использует активную-пассивный конфигурацию для соответствия SLO 99,9%.

  Для веб-приложения с несколькими регионами настройте подсистему балансировки нагрузки для маршрутизации трафика во второй регион для поддержки конфигурации "активный— активный" или "активный- пассивный" в зависимости от бизнес-потребности. Для двух регионов требуются одни и те же службы, кроме одного региона, есть виртуальная сеть концентратора, которая подключает регионы. Применяйте топологию сети концентратора и периферийной сети для централизованной и совместной работы с ресурсами, например брандмауэром сети. Если у вас есть виртуальные машины, добавьте узел бастиона в виртуальную сеть концентратора для управления ими с повышенной безопасностью. (См. рисунок 2.)

  

  Рисунок 2. Шаблон Reliable Web App со второй областью и звездообразной топологией.

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

Выбор правильных служб Azure

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

Например, прежде чем он был перемещен в облако, веб-приложение Relecloud по запросу было локальным монолитным приложением ASP.NET. Она выполнялась на двух виртуальных машинах и использовала базу данных SQL Server. Веб-приложение страдало от распространенных проблем с масштабируемостью и развертыванием функций. Эта отправная точка, их бизнес-цели и SLO привели к выбору их услуг.

• Платформа приложений: используйте службу приложение Azure в качестве платформы приложений. Relecloud выбрал службу приложений в качестве платформы приложений по следующим причинам:

  • Соглашение об уровне обслуживания (SLA). Он имеет высокий уровень обслуживания, соответствующий производственной среде SLO 99,9%.
  • Сокращение затрат на управление. Это полностью управляемое решение, которое обрабатывает масштабирование, проверки работоспособности и балансировку нагрузки.
  • Поддержка .NET. Она поддерживает версию .NET, написанную приложением.
  • Возможность контейнеризации. Веб-приложение может конвергироваться в облаке без контейнеризации, но платформа приложений также поддерживает контейнеризацию без изменения служб Azure.
  • Автоматическое масштабирование. Веб-приложение может автоматически масштабироваться в зависимости от пользовательского трафика и параметров конфигурации. Платформа также поддерживает масштабирование вверх или вниз для удовлетворения различных требований к размещению.

• Управление удостоверениями: используйте идентификатор Microsoft Entra в качестве решения для управления удостоверениями и доступом. Relecloud выбрал идентификатор Microsoft Entra по следующим причинам:

  • Проверка подлинности и авторизация. Приложению необходимо пройти проверку подлинности и авторизовать сотрудников центра обработки вызовов.
  • Масштабируемый. Идентификатор Microsoft Entra масштабируется для поддержки более крупных сценариев.
  • Элемент управления удостоверениями пользователя. Сотрудники центра обработки вызовов могут использовать существующие корпоративные удостоверения.
  • Поддержка протокола авторизации. Идентификатор Microsoft Entra поддерживает OAuth 2.0 для управляемых удостоверений.

• База данных: используйте службу, которая позволяет сохранить тот же ядро СУБД. Используйте дерево принятия решений хранилища данных, для руководства по выбору. Веб-приложение Relecloud использовало локальную среду SQL Server. Они хотели использовать существующую схему базы данных, хранимые процедуры и функции. Несколько продуктов SQL доступны в Azure, но Relecloud выбрал База данных SQL Azure по следующим причинам:

  • Надёжность. Уровень общего назначения обеспечивает высокий уровень обслуживания и избыточность в нескольких регионах. Он может поддерживать высокую нагрузку пользователя.
  • Сокращение затрат на управление. База данных SQL предоставляет управляемый экземпляр базы данных SQL.
  • Поддержка миграции. Она поддерживает миграцию базы данных из локальной среды SQL Server.
  • Согласованность с локальными конфигурациями. Она поддерживает существующие хранимые процедуры, функции и представления.
  • Упругость. Она поддерживает резервное копирование и восстановление на определенный момент времени.
  • Опыт и минимальная переработка. База данных SQL позволяет Relecloud воспользоваться существующим опытом и требует минимальной работы.

• мониторинг производительности приложений: использовать Application Insights для анализа данных телеметрии для приложения. Relecloud решил использовать Application Insights по следующим причинам:

  • Интеграция с Azure Monitor. Она обеспечивает лучшую интеграцию с Azure Monitor.
  • Обнаружение аномалий. Он автоматически обнаруживает аномалии производительности.
  • Устранение неполадок. Это помогает диагностировать проблемы в работающем приложении.
  • Контроль. Он собирает сведения о том, как пользователи используют приложение и позволяют легко отслеживать пользовательские события.
  • Разрыв видимости. Локальное решение не было решения для мониторинга производительности приложений. Application Insights обеспечивает простую интеграцию с платформой приложений и кодом.

• кэш: выбрать, следует ли добавлять кэш в архитектуру веб-приложения. кэш Azure для Redis является основным решением кэша Azure. Это управляемое хранилище данных в памяти, основанное на программном обеспечении Redis. Нагрузка веб-приложения Relecloud сильно сложена на просмотр концертов и сведений о месте проведения. Relecloud добавил кэш Azure для Redis по следующим причинам:

  • Сокращение затрат на управление. Это полностью управляемая служба.
  • Скорость и объем. Он имеет высокую пропускную способность и низкую задержку чтения для часто доступных, медленно изменяющихся данных.
  • Разнообразная поддержка. Это единое расположение кэша для всех экземпляров веб-приложения для использования.
  • Внешнее хранилище данных. Локальные серверы приложений выполнили кэширование локальной виртуальной машины. Эта настройка не выгружает часто задаваемые данные, и не удалось сделать недопустимые данные.
  • Нестистионные сеансы. Состояние внешнего сеанса поддерживает нестистиковые сеансы.

• Подсистема балансировки нагрузки: веб-приложения, использующие решения PaaS, должны использовать Azure Front Door, Шлюз приложений Azure или оба в зависимости от архитектуры и требований веб-приложения. Используйте дерево принятия решений подсистемы балансировки нагрузки для выбора правильной подсистемы балансировки нагрузки. Relecloud требуется подсистема балансировки нагрузки уровня 7, которая может маршрутизировать трафик в нескольких регионах. Компания нуждалась в веб-приложении с несколькими регионами для удовлетворения SLO 99,9%. Relecloud выбрал Azure Front Door по следующим причинам:

  • Глобальная балансировка нагрузки. Это подсистема балансировки нагрузки уровня 7, которая может маршрутизировать трафик в нескольких регионах.
  • Брандмауэр веб-приложения. Он интегрируется изначально с брандмауэром веб-приложений Azure.
  • Гибкость маршрутизации. Она позволяет группе приложений настраивать входящий трафик, который должен поддерживать будущие изменения в приложении.
  • Ускорение трафика. Он использует любую рассылку для достижения ближайшей точки присутствия Azure и поиска самого быстрого маршрута к веб-приложению.
  • Личные домены. Он поддерживает пользовательские доменные имена с гибкой проверкой домена.
  • Пробы работоспособности. Приложению требуется интеллектуальный мониторинг проб работоспособности. Azure Front Door использует ответы из пробы, чтобы определить лучший источник для маршрутизации клиентских запросов.
  • Поддержка мониторинга. Он поддерживает встроенные отчеты со встроенными панелями мониторинга как для Azure Front Door, так и для шаблонов безопасности. Вы можете настроить оповещения, которые интегрируются с Azure Monitor. Azure Front Door позволяет приложению регистрировать каждый запрос и неудачные пробы работоспособности.
  • Защита от атак DDoS. Он имеет встроенную защиту от атак DDoS уровня 3-4.
  • Сеть доставки содержимого. Он размещает Relecloud для использования сети доставки содержимого. Сеть доставки содержимого обеспечивает ускорение сайта.

• Брандмауэр веб-приложения: используйте Azure Брандмауэр веб-приложений для обеспечения централизованной защиты от распространенных веб-эксплойтов и уязвимостей. Relecloud использует брандмауэр веб-приложения Azure по следующим причинам:

  • Глобальная защита. Она обеспечивает улучшенную защиту глобальных веб-приложений без ущерба для производительности.
  • Защита botnet. Команда может отслеживать и настраивать параметры для решения проблем безопасности, связанных с ботнетами.
  • Четность с локальной средой. Локальное решение выполнялось за брандмауэром веб-приложения, управляемым ИТ-службой.
  • Простота использования. Брандмауэр веб-приложений интегрируется с Azure Front Door.

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

  • Гибкость. Он поддерживает флаги компонентов. Флаги функций позволяют пользователям отказаться от ранних предварительных версий функций в рабочей среде, не требуя повторного развертывания приложений.
  • Поддержка конвейера Git. Источник истины для данных конфигурации должен быть репозиторием Git. Конвейер, необходимый для обновления данных в центральном хранилище конфигурации.
  • Поддержка управляемого удостоверения. Она поддерживает управляемые удостоверения для упрощения и защиты подключения к хранилищу конфигураций.

• Диспетчер секретов: используйте Azure Key Vault , если у вас есть секреты для управления в Azure. Вы можете включить Key Vault в приложения .NET с помощью объекта ConfigurationBuilder. Локальное веб-приложение Relecloud хранит секреты в файлах конфигурации кода, но рекомендуется хранить секреты в расположении, поддерживающем RBAC и элементы управления аудитом. Хотя управляемых удостоверений являются предпочтительным решением для подключения к ресурсам Azure, Relecloud имел секреты приложений, необходимые для управления. Relecloud использовал Key Vault по следующим причинам:

  • Шифрование. Он поддерживает шифрование при хранении и передаче.
  • Поддержка управляемого удостоверения. Службы приложений могут использовать управляемые удостоверения для доступа к хранилищу секретов.
  • Мониторинг и ведение журнала. Key Vault упрощает доступ к аудиту и создает оповещения при изменении хранимых секретов.
  • Интеграция. Key Vault обеспечивает встроенную интеграцию с хранилищем конфигурации Azure (Конфигурация приложений) и платформой веб-размещения (Служба приложений).

• решение службы хранилища : см. варианты хранения Azure, чтобы выбрать подходящее решение для хранения в соответствии с вашими требованиями. Локальное веб-приложение Relecloud подключено к каждому веб-серверу, но команда хотела использовать внешнее решение для хранения данных. Relecloud выбрал Хранилище BLOB-объектов Azure по следующим причинам:

  • Расширенный доступ к безопасности. Веб-приложение может исключить конечные точки для доступа к хранилищу, доступ к общедоступному Интернету с анонимным доступом.
  • Шифрование. Хранилище BLOB-объектов шифрует неактивных и передаваемых данных.
  • Упругость. Хранилище BLOB-объектов поддерживает избыточное между зонами хранилище (ZRS). Хранилище, избыточное между зонами, реплицирует данные синхронно в трех зонах доступности Azure в основном регионе. Каждая зона доступности находится в отдельном физическом расположении с независимым питанием, охлаждением и сетью. Эта конфигурация должна сделать образы билетов устойчивыми к потере.

• безопасность конечных точек: использовать приватный канал Azure для доступа к решениям платформы как услуга (PaaS) через частную конечную точку в виртуальной сети. Трафик между виртуальной сетью и службой перемещается по магистральной сети Майкрософт. Relecloud выбрал Приватный канал по следующим причинам:

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

• Безопасность сети. Используйте брандмауэра Azure для управления входящим и исходящим трафиком на уровне сети. Используйте Бастион Azure для подключения к виртуальным машинам с повышенной безопасностью без предоставления портов RDP/SSH. Relecloud принял топологию сети концентратора и периферийной сети и хотел поместить общие службы безопасности сети в концентратор. Брандмауэр Azure повышает безопасность, проверяя весь исходящий трафик с периферийных узлов, чтобы повысить безопасность сети. Relecloud требуется Бастион Azure для развертывания расширенной безопасности с узла перехода в подсети DevOps.

Руководство по коду

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

Рисунок 3. Роли шаблонов конструктора.

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

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

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

3. шаблон Cache-Aside. Шаблон Cache-Aside загружает данные по запросу в кэш из хранилища данных. Реализуйте этот шаблон для запросов к базе данных.

Реализация шаблона повторных попыток

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

• Используйте встроенные механизмы повторных попыток. Используйте встроенный механизм повторных попыток, который большинство служб Azure предоставляют для ускорения реализации. Например, эталонная реализация использует устойчивость подключения в Entity Framework Core для применения шаблона повторных попыток в запросах к базе данных SQL:

  services.AddDbContextPool<ConcertDataContext>(options => options.UseSqlServer(sqlDatabaseConnectionString,
      sqlServerOptionsAction: sqlOptions =>
      {
          sqlOptions.EnableRetryOnFailure(
          maxRetryCount: 5,
          maxRetryDelay: TimeSpan.FromSeconds(3),
          errorNumbersToAdd: null);
      }));
  

• Используйте библиотеки программирования повторных попыток. Для связи HTTP интегрируйте стандартную библиотеку устойчивости, например Polly или Microsoft.Extensions.Http.Resilience. Эти библиотеки предоставляют комплексные механизмы повторных попыток, важные для управления взаимодействием с внешними веб-службами. Например, эталонная реализация использует Polly для применения шаблона повторных попыток каждый раз, когда код создает объект, вызывающий объект IConcertSearchService:

  private void AddConcertSearchService(IServiceCollection services)
  {
      var baseUri = Configuration["App:RelecloudApi:BaseUri"];
      if (string.IsNullOrWhiteSpace(baseUri))
      {
          services.AddScoped<IConcertSearchService, MockConcertSearchService>();
      }
      else
      {
          services.AddHttpClient<IConcertSearchService, RelecloudApiConcertSearchService>(httpClient =>
          {
              httpClient.BaseAddress = new Uri(baseUri);
              httpClient.DefaultRequestHeaders.Add(HeaderNames.Accept, "application/json");
              httpClient.DefaultRequestHeaders.Add(HeaderNames.UserAgent, "Relecloud.Web");
          })
          .AddPolicyHandler(GetRetryPolicy())
          .AddPolicyHandler(GetCircuitBreakerPolicy());
      }
  }
  
  private static IAsyncPolicy<HttpResponseMessage> GetRetryPolicy()
  {
      var delay = Backoff.DecorrelatedJitterBackoffV2(TimeSpan.FromMilliseconds(500), retryCount: 3);
      return HttpPolicyExtensions
        .HandleTransientHttpError()
        .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.NotFound)
        .WaitAndRetryAsync(delay);
  }
  

Реализация шаблона размыкателя цепи

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

Например, эталонная реализация применяет шаблон разбиения цепи ко всем запросам к API. Он использует логику HandleTransientHttpError для обнаружения HTTP-запросов, которые он может безопасно повторить, но ограничивает количество агрегатных сбоев в течение указанного периода времени:

private static IAsyncPolicy<HttpResponseMessage> GetCircuitBreakerPolicy()
{
    return HttpPolicyExtensions
        .HandleTransientHttpError()
        .OrResult(msg => msg.StatusCode == System.Net.HttpStatusCode.NotFound)
        .CircuitBreakerAsync(5, TimeSpan.FromSeconds(30));
}

Реализация шаблона "Кэш в сторону"

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

• Настройте приложение для использования кэша. Рабочие приложения должны использовать распределенный кэш Redis. Этот кэш повышает производительность, уменьшая количество запросов к базе данных. Кроме того, он включает нестистионные сеансы, чтобы подсистема балансировки нагрузки может равномерно распределять трафик. Эталонная реализация использует распределенный кэш Redis. Метод AddAzureCacheForRedis настраивает приложение для использования кэша Azure для Redis:

  private void AddAzureCacheForRedis(IServiceCollection services)
  {
      if (!string.IsNullOrWhiteSpace(Configuration["App:RedisCache:ConnectionString"]))
      {
          services.AddStackExchangeRedisCache(options =>
          {
              options.Configuration = Configuration["App:RedisCache:ConnectionString"];
          });
      }
      else
      {
          services.AddDistributedMemoryCache();
      }
  }
  

• Кэшировать данные с высокой потребностью. Примените шаблон Cache-Aside к данным с высоким уровнем необходимости, чтобы повысить эффективность работы. Используйте Azure Monitor для отслеживания ЦП, памяти и хранилища базы данных. Эти метрики помогают определить, можно ли использовать меньший номер SKU базы данных после применения шаблона Cache-Aside. Например, эталонная реализация кэширует данные с высоким уровнем необходимости, поддерживающие страницу предстоящих концертов. Метод GetUpcomingConcertsAsync извлекает данные в кэш Redis из базы данных SQL и заполняет кэш последними данными концерта:

  public async Task<ICollection<Concert>> GetUpcomingConcertsAsync(int count)
  {
      IList<Concert>? concerts;
      var concertsJson = await this.cache.GetStringAsync(CacheKeys.UpcomingConcerts);
      if (concertsJson != null)
      {
          // There is cached data. Deserialize the JSON data.
          concerts = JsonSerializer.Deserialize<IList<Concert>>(concertsJson);
      }
      else
      {
          // There's nothing in the cache. Retrieve data 
          // from the repository and cache it for one hour.
          concerts = await this.database.Concerts.AsNoTracking()
              .Where(c => c.StartTime > DateTimeOffset.UtcNow && c.IsVisible)
              .OrderBy(c => c.StartTime)
              .Take(count)
              .ToListAsync();
          concertsJson = JsonSerializer.Serialize(concerts);
          var cacheOptions = new DistributedCacheEntryOptions {
              AbsoluteExpirationRelativeToNow = TimeSpan.FromHours(1)
          };
          await this.cache.SetStringAsync(CacheKeys.UpcomingConcerts, concertsJson, cacheOptions);
      }
      return concerts ?? new List<Concert>();
  }
  

• Сохраняйте свежие данные кэша. Планирование регулярных обновлений кэша для синхронизации с последними изменениями базы данных. Используйте волатильность данных и пользователю необходимо определить оптимальную частоту обновления. Эта практика гарантирует, что приложение использует шаблон Cache-Aside для обеспечения быстрого доступа и текущей информации. Например, эталонная реализация кэширует данные только в течение одного часа и использует метод CreateConcertAsync для очистки ключа кэша при изменении данных:

  public async Task<CreateResult> CreateConcertAsync(Concert newConcert)
  {
      database.Add(newConcert);
      await this.database.SaveChangesAsync();
      this.cache.Remove(CacheKeys.UpcomingConcerts);
      return CreateResult.SuccessResult(newConcert.Id);
  }
  

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

  public async Task<UpdateResult> UpdateConcertAsync(Concert existingConcert), 
  {
     database.Update(existingConcert);
     await database.SaveChangesAsync();
     this.cache.Remove(CacheKeys.UpcomingConcerts);
     return UpdateResult.SuccessResult();
  }
  

Руководство по настройке

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

Настройка проверки подлинности и авторизации пользователей

При переносе веб-приложений в Azure настройте механизмы проверки подлинности и авторизации пользователей. Следуйте приведенным ниже рекомендациям.

• Используйте платформу удостоверений. Используйте платформу удостоверений Майкрософт для настройки проверки подлинности веб-приложения. Эта платформа поддерживает приложения, использующие один каталог Microsoft Entra, несколько каталогов Microsoft Entra из разных организаций и удостоверений Майкрософт или социальных учетных записей.

• Создайте регистрацию приложения. Идентификатор Microsoft Entra id требует регистрации приложения в основном клиенте. Регистрация приложения помогает гарантировать, что пользователи, получающие доступ к веб-приложению, имеют удостоверения в основном клиенте.

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

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

• Предпочитайте временный доступ к хранилищу. Используйте временные разрешения для защиты от несанкционированного доступа и нарушений. Например, можно использовать подписанные URL-адреса (SAS), чтобы ограничить доступ к периоду времени. Используйте SAS делегирования пользователей для обеспечения максимальной безопасности при предоставлении временного доступа. Это единственный SAS, использующий учетные данные идентификатора Microsoft Entra и не требующий постоянного ключа учетной записи хранения.

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

• Избегайте постоянных повышенных разрешений. Используйте Microsoft Entra управление привилегированными пользователями, чтобы предоставить JIT-доступ для привилегированных операций. Например, разработчикам часто требуется доступ на уровне администратора для создания и удаления баз данных, изменения схем таблиц и изменения разрешений пользователя. При использовании JIT-доступа удостоверения пользователей получают временные разрешения для выполнения привилегированных задач.

Использование управляемых удостоверений

Используйте управляемые удостоверения для всех служб Azure, поддерживающих их. Управляемое удостоверение позволяет ресурсам Azure (удостоверениям рабочей нагрузки) проходить проверку подлинности и взаимодействовать с другими службами Azure, не требуя управления учетными данными. Чтобы упростить миграцию, можно продолжать использовать локальные решения проверки подлинности для гибридных и устаревших систем, но их следует перенести в управляемые удостоверения как можно скорее. Чтобы реализовать управляемые удостоверения, выполните следующие рекомендации.

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

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

• Обеспечение безопасности оставшихся секретов. Сохраните все оставшиеся секреты в Azure Key Vault. Загрузите секреты из Key Vault при запуске приложения вместо каждого HTTP-запроса. Высокочастотный доступ в HTTP-запросах может превышать ограничения транзакций Key Vault. Хранение конфигураций приложений в Конфигурация приложений Azure.

Эталонная реализация использует аргумент Authentication в строке подключения к базе данных SQL, чтобы служба приложений подключиться к базе данных SQL с помощью управляемого удостоверения: Server=tcp:my-sql-server.database.windows.net,1433;Initial Catalog=my-sql-database;Authentication=Active Directory Default. Он использует DefaultAzureCredential, чтобы разрешить веб-API подключаться к Key Vault с помощью управляемого удостоверения:

    builder.Configuration.AddAzureAppConfiguration(options =>
    {
         options
            .Connect(new Uri(builder.Configuration["Api:AppConfig:Uri"]), new DefaultAzureCredential())
            .ConfigureKeyVault(kv =>
            {
                // Some of the values coming from App Configuration
                // are stored in Key Vault. Use the managed identity
                // of this host for the authentication.
                kv.SetCredential(new DefaultAzureCredential());
            });
    });

Среды rightsize

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

• оценить расходы; Используйте калькулятор цен Azure для оценки стоимости каждой среды.

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

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

• Используйте инфраструктуру в качестве кода (IaC) для определения номеров SKU. Реализуйте IaC для динамического выбора и развертывания правильных номеров SKU в зависимости от среды. Этот подход повышает согласованность и упрощает управление.

Например, эталонная реализация использует параметры Bicep для развертывания более дорогих уровней (SKU) в рабочей среде:

    var redisCacheSkuName = isProd ? 'Standard' : 'Basic'
    var redisCacheFamilyName = isProd ? 'C' : 'C'
    var redisCacheCapacity = isProd ? 1 : 0

Реализация автомасштабирования

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

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

• Уточнение триггеров масштабирования. Используйте использование ЦП в качестве начального триггера масштабирования, если вы не знакомы с требованиями к масштабированию приложения. Укажите триггеры масштабирования, чтобы включить другие метрики, такие как ОЗУ, пропускная способность сети и операции ввода-вывода диска. Цель заключается в том, чтобы соответствовать поведению веб-приложения для повышения производительности.

• Укажите буфер горизонтального масштабирования. Задайте пороговые значения масштабирования для активации до достижения максимальной емкости. Например, настройте масштабирование на уровне 85 % использования ЦП, а не до тех пор, пока не достигнет 100 %. Этот упреждающий подход помогает поддерживать производительность и избегать потенциальных узких мест.

Автоматическое развертывание ресурсов

Используйте автоматизацию для развертывания и обновления ресурсов Azure и кода во всех средах. Следуйте приведенным ниже рекомендациям.

• используйте инфраструктуру как код; Развертывание инфраструктуры в виде кода с помощью конвейеров непрерывной интеграции и непрерывной доставки (CI/CD). Azure предоставляет предварительно созданные Bicep, ARM (JSON) и шаблоны Terraform для каждого ресурса Azure.

• Используйте конвейер непрерывной интеграции и непрерывного развертывания (CI/CD). Используйте конвейер CI/CD для развертывания кода из системы управления версиями в различных средах, таких как тестирование, промежуточное размещение и рабочая среда. Используйте Azure Pipelines, если вы работаете с Azure DevOps. Используйте GitHub Actions для проектов GitHub.

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

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

• Выполнение проверок безопасности. Используйте статическое тестирование безопасности приложений (SAST), чтобы найти ошибки безопасности и ошибки программирования в исходном коде. Кроме того, проводите анализ композиции программного обеспечения (SCA), чтобы изучить сторонние библиотеки и компоненты для рисков безопасности. Средства для этих анализов легко интегрировать как в GitHub, так и в Azure DevOps.

Реализация мониторинга

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

• Сбор данных телеметрии приложения. Используйте автоинструментации в Azure Application Insights для сбора телеметрии приложений, таких как пропускная способность запросов, средняя длительность запроса, ошибки и мониторинг зависимостей. Чтобы использовать эту телеметрию, вам не нужно вносить изменения в код.

  Эталонная реализация использует AddApplicationInsightsTelemetry из пакета NuGet Microsoft.ApplicationInsights.AspNetCore для включения сбора данных телеметрии:

  public void ConfigureServices(IServiceCollection services)
  {
     ...
     services.AddApplicationInsightsTelemetry(Configuration["App:Api:ApplicationInsights:ConnectionString"]);
     ...
  }
  

• Создайте пользовательские метрики приложений. Используйте инструментирование на основе кода для телеметрии пользовательского приложения. Добавьте пакет SDK Application Insights в код и используйте API Application Insights.

  Эталонная реализация собирает данные телеметрии о событиях, связанных с действием корзины. this.telemetryClient.TrackEvent подсчитывает билеты, добавленные в корзину. Он предоставляет имя события (AddToCart) и задает словарь, имеющий concertId и count:

  this.telemetryClient.TrackEvent("AddToCart", new Dictionary<string, string> {
      { "ConcertId", concertId.ToString() },
      { "Count", count.ToString() }
  });
  

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

Развертывание эталонной реализации

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

• Реализуйте низкозатратные, высокоценные изменения кода.
• Достичь SLO 99,9%.
• Внедрение методик DevOps.
• Создание оптимизированных для затрат сред.
• Повышение надежности и безопасности.

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

рис. 4. Архитектура эталонной реализации. Скачайте файл Visio этой архитектуры.