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

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

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

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

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

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

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

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

Первым шагом в переплатформировке веб-приложения является определение бизнес-целей. Необходимо задать немедленные цели, такие как цели уровня обслуживания и целевые показатели оптимизации затрат, а также будущие цели для веб-приложения. Эти цели влияют на выбор облачных служб и архитектуру веб-приложения в облаке. Определите целевой 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. Она выполнялась на двух виртуальных машинах и имела базу данных Microsoft SQL Server. Веб-приложение страдало от распространенных проблем в развертывании масштабируемости и функций. Эта отправная точка, их бизнес-цели и SLO привели к выбору их услуг.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Шаблон "В сторону кэша": шаблон "Кэш-в сторону" добавляется и извлекается из кэша чаще, чем хранилище данных. Реализуйте этот шаблон для запросов к базе данных.

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

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

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

  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 Azure App Configuration
                // are stored in Key Vault. Use the managed identity
                // of this host for the authentication.
                kv.SetCredential(new DefaultAzureCredential());
            });
    });

Правильные среды размера

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

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

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

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

• Определение номеров SKU с помощью инфраструктуры в качестве кода (IaC). Реализуйте 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 Insights для сбора данных телеметрии приложений, таких как пропускная способность запросов, средняя длительность запроса, ошибки и мониторинг зависимостей без изменений кода.

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

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

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