Изменить

Поделиться через

Бессерверное веб-приложение

Microsoft Entra ID
Cлужба управления Azure API
хранилище BLOB-объектов Azure
Сеть доставки содержимого Azure
Функции Azure
Azure Monitor

Эталонная архитектура, которая демонстрирует бессерверное веб-приложение. Приложение передает статическое содержимое из хранилища BLOB-объектов Azure, а также реализует программный интерфейс с помощью Функций Azure. API считывает данные из Azure Cosmos DB и возвращает результаты в веб-приложение.

Логотип GitHubДве эталонные реализации для этой архитектуры доступны на сайте GitHub: приложение доставки дронов (ARM и Azure Pipelines) и Список дел App (Bicep и GitHub Actions).

Архитектура

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

Скачайте файл Visio для этой архитектуры.

Термин "бессерверный" может иметь два различных значения, которые тем не менее связаны между собой:

  • Серверная часть как услуга (BaaS). Внутренние облачные службы, такие как базы данных и хранилище, предоставляют API- интерфейсы, которые позволяют клиентским приложениям подключаться непосредственно к этим службам.
  • Функции как услуга (FaaS). В этой модели "функция" представляет собой фрагмент кода, который развертывается в облаке и выполняется в среде узла, которая полностью абстрагирует серверы, на которых запускается код.

Оба определения подразумевают общую идею о том, что разработчикам и персоналу DevOps не нужно развертывать, настраивать или администрировать серверы. Эта эталонная архитектура фокусируется на FaaS с помощью Функции Azure, хотя обслуживание веб-содержимого из Хранилище BLOB-объектов Azure может быть примером BaaS. Ниже приведены некоторые важные характеристики FaaS:

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

Функции выполняются при возникновении внешнего триггера, например HTTP-запроса или сообщения, поступающего в очередь. Благодаря этому тип управляемой событиями архитектуры является естественным для бессерверных архитектур. Чтобы координировать работу между компонентами в архитектуре, рассмотрите возможность использования брокеров сообщений или шаблонов публикаций и подписок. Сведения о выборе между технологиями обмена сообщениями в Azure см. в разделе "Выбор между службами Azure" для доставки сообщений.

Компоненты

Она состоит из следующих компонентов:

Хранилище больших двоичных объектов. Статический веб-контент, такой как HTML, CSS и файлы JavaScript, хранятся в Хранилище BLOB-объектов Azure и обслуживаются клиентами с помощью размещения статических веб-сайтов. Все динамическое взаимодействие происходит с помощью кода JavaScript, выполняющего вызовы внутренних API. Нет серверного кода для отрисовки веб-страницы. Размещение статических веб-сайтов поддерживает индексированные документы и настраиваемые страницы ошибок 404.

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

Приложения-функции. Функции Azure — это независимая от сервера служба вычислений. Она использует управляемую событиями модель, где часть кода ("функция") вызывается триггером. В этой архитектуре функция вызывается, когда клиент делает HTTP-запрос. Запрос всегда маршрутизируется через шлюз API, описанный ниже.

Управление API. Azure Управление API предоставляет шлюз API, который находится перед функцией HTTP. Службу управления API можно использовать для публикации программных интерфейсов, используемых клиентскими приложениями, а также для управления ими. Использование шлюза помогает отделить внешнее приложение от серверных API. Например, Управление API могут переписывать URL-адреса, преобразовывать запросы, прежде чем они достигают серверной части, задавать заголовки запросов или ответов и т. д.

Управление API также может использоваться для реализации сквозных задач, таких как:

  • Принудительное применение квот потребления и ограничений скорости.
  • Проверка токенов OAuth для аутентификации.
  • Включение запросов независимо от источника (CORS).
  • Кэширование ответов.
  • Мониторинг и ведение журнала запросов.

Если вам не нужны все функциональные возможности, предоставляемые службой управления API, можно использовать прокси-серверы Функций. Эта возможность Функций Azure позволяет вам определять единую поверхность API для нескольких приложений-функций, создавая маршруты к серверным функциям. Прокси-серверы Функций также могут выполнять ограниченные преобразования запросов и ответов HTTP. Тем не менее они не обеспечивают те же расширенные функциональные возможности управления API на основе политик.

Azure Cosmos DB. Azure Cosmos DB — это служба базы данных с несколькими моделями. В этом сценарии приложение-функция извлекает документы из Azure Cosmos DB в ответ на HTTP-запросы GET от клиента.

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

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

Azure Pipelines. Azure Pipelines — это служба непрерывной интеграции (CI) и непрерывной доставки (CD), которая создает, тестирует и развертывает приложение.

GitHub Actions. Рабочий процесс — это автоматизированный процесс (CI/CD), настроенный в репозитории GitHub. С помощью рабочего процесса вы можете выполнять сборку, тестирование, упаковку, выпуск и развертывание любого проекта в GitHub.

Подробности сценария

Потенциальные варианты использования

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

Рекомендации

Планы приложения-функции

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

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

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

  • Холодный запуск. В плане потребления функция, которая не вызывалась недавно, в следующий раз будет вызвана с дополнительной задержкой. Эта дополнительная задержка обусловлена ​​распределением и подготовкой среды выполнения. Обычно это зависит от порядка секунд, но зависит от нескольких факторов, включая количество зависимостей, которые необходимо загрузить. Дополнительные сведения см. в статье о холодном запуске в бессерверной архитектуре. Холодный запуск обычно больше относится к интерактивным (HTTP-триггеры), чем к асинхронным рабочим нагрузкам, связанным с сообщениями (триггеры очереди или концентраторов событий), потому что дополнительная задержка наблюдается непосредственно пользователями.
  • Период времени ожидания. В плане потребления функция должна выполняться в течение настроенного времени ожидания (максимум до 10 минут).
  • Изоляция виртуальной сети. Использование плана службы приложений позволяет выполнять функции внутри среды службы приложений, которая представляет собой выделенную и изолированную среду размещения.
  • Модель ценообразования. План потребления взимается по количеству выполнения и потребления ресурсов (время выполнения × памяти). В плане службы приложений счета выставляются ежечасно на основе номера SKU экземпляра виртуальной машины. Часто план потребления может быть дешевле, чем план службы приложений, так как вы платите только за те ресурсы вычислений, которые используете. Это особенно верно в случаях, если в трафике наблюдаются пики и спады. Однако если в приложении наблюдается постоянная высокая пропускная способность, план службы приложений может стоить меньше, чем план потребления.
  • Масштабирование. Большим преимуществом модели потребления является то, что она масштабируется динамически по мере необходимости в зависимости от входящего трафика. Хотя это масштабирование происходит быстро, существует еще период увеличения. Для некоторых рабочих нагрузок может потребоваться намеренная избыточная подготовка виртуальных машин, чтобы можно было обрабатывать всплески трафика без периода нарастания. В этом случае используйте план службы приложений.

Границы приложения-функции

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

Используйте приложения-функции для группирования функций с одинаковыми жизненным циклом и параметрами. Функции с разным жизненным циклом должны размещаться в различных приложениях-функциях.

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

Привязки функций

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

Например, GetStatus функция в эталонной реализации использует входную привязку Azure Cosmos DB. Эта привязка настроена для поиска документа в Azure Cosmos DB с помощью параметров запроса, взятых из строки запроса в HTTP-запросе. Если документ найден, он передается функции в качестве параметра.

[Function("GetStatusFunction")]
public IActionResult Run([HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req,
        [CosmosDBInput(
           databaseName: "%COSMOSDB_DATABASE_NAME%",
           containerName:"%COSMOSDB_DATABASE_COL%",
           Connection  = "COSMOSDB_CONNECTION_STRING",
           Id = "{Query.deviceId}",
           PartitionKey = "{Query.deviceId}")] DeviceState? deviceStatus)
{
  ...
}

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

Рекомендации

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

Масштабируемость

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

Azure Cosmos DB. Емкость пропускной способности для Azure Cosmos DB измеряется в единицах запросов (ЕЗ). Одна единица запроса соответствует пропускной способности операций GET, выполняемых для документа объемом 1 КБ. Чтобы масштабировать контейнер Azure Cosmos DB за последние 10 000 ЕЗ, необходимо указать ключ секции при создании контейнера и включить ключ секции в каждый создаваемый документ. Дополнительные сведения о ключах секций см. в статье Секционирование и масштабирование в Azure Cosmos DB.

Управление API. Управление API поддерживает горизонтальное увеличение масштаба и автоматическое масштабирование на основе правил. Процесс масштабирования занимает не менее 20 минут. Если ваш трафик прерывистый, следует подготовиться к максимальному всплеску трафика, который вы ожидаете. Однако автоматическое масштабирование полезно для обработки почасовых или ежедневных колебаний трафика. Дополнительные сведения см. в статье Автоматическое масштабирование экземпляра службы управления API Azure.

Аварийное восстановление

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

  • Служба управления API поддерживает развертывание в нескольких регионах, что позволяет распространять единый экземпляр службы управления API в любом количестве регионов Azure. Дополнительные сведения см. в статье Развертывание экземпляра службы управления Azure API в различных регионах Azure.

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

  • Azure Cosmos DB поддерживает несколько регионов записи, которые позволяют записывать данные в любой регион, добавленный в учетную запись Azure Cosmos DB. Если вы не включаете многозаписную запись, вы по-прежнему можете выполнить отработку отказа в основном регионе записи. Клиентские пакеты SDK для Azure Cosmos DB и привязки функций Azure автоматически обрабатывают отработку отказа, поэтому вам не нужно обновлять параметры конфигурации приложения.

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в разделе "Общие сведения о компоненте безопасности".

Проверка подлинности

GetStatus API в эталонной реализации использует идентификатор Microsoft Entra для проверки подлинности запросов. Идентификатор Microsoft Entra поддерживает протокол OpenID Connect, который является протоколом проверки подлинности, построенным на основе протокола OAuth 2.

В этой архитектуре клиентское приложение представляет собой одностраничное приложение (SPA), которое запускается в браузере. Этот тип клиентского приложения не может держать секрет клиента или код авторизации скрытым, поэтому неявный поток предоставления подходит. (См. сведения об использовании потока OAuth 2.0). Вот общий поток действий:

  1. Пользователь щелкает ссылку "Войти" в веб-приложении.
  2. Браузер перенаправляется на страницу входа Microsoft Entra.
  3. Пользователь входит в систему.
  4. Идентификатор Microsoft Entra перенаправляется обратно в клиентское приложение, включая маркер доступа в фрагменте URL-адреса.
  5. Когда веб-приложение вызывает API, оно добавляет маркер доступа в заголовок аутентификации. Идентификатор приложения отправляется в качестве утверждения целевой аудитории (aud) в маркере доступа.
  6. Внутренний API проверяет маркер доступа.

Чтобы настроить аутентификацию:

  • Зарегистрируйте приложение в клиенте Microsoft Entra. При этом создается идентификатор приложения, который клиент добавляет в URL-адрес входа.

  • Включите проверку подлинности Microsoft Entra в приложении-функции. Дополнительные сведения см. в статье Проверка подлинности и авторизация в Службе приложений Azure.

  • Добавьте политику validate-jw в службу управления API, чтобы предварительно авторизовать запрос, проверив маркер доступа.

Дополнительные сведения см. в файле сведений на сайте GitHub.

Рекомендуется создать отдельные регистрации приложений в идентификаторе Microsoft Entra для клиентского приложения и серверного API. Предоставьте клиентскому приложению разрешение вызывать веб-API. Этот подход позволяет определить несколько API и клиентов, а также управлять разрешениями для каждого из них.

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

Авторизация

Во многих приложениях внутренний API должен проверить, имеет ли пользователь разрешение на выполнение заданного действия. Рекомендуется использовать авторизацию на основе утверждений, где сведения о пользователе передаются поставщиком удостоверений (в данном случае идентификатором Microsoft Entra) и используются для принятия решений об авторизации. Например, при регистрации приложения в идентификаторе Microsoft Entra можно определить набор ролей приложения. Когда пользователь входит в приложение, идентификатор Microsoft Entra содержит roles утверждение для каждой роли, которую предоставил пользователь, включая роли, унаследованные через членство в группах.

Маркер идентификатора, возвращаемого идентификатором Microsoft Entra, клиенту содержит некоторые утверждения пользователя. В приложении-функции эти утверждения доступны в заголовке X-MS-CLIENT-PRINCIPAL запроса. Тем не менее, проще считывать эти сведения из данных привязки. Для других утверждений используйте Microsoft Graph для запроса идентификатора Microsoft Entra. (Пользователь должен согласиться на это действие при входе.)

Дополнительные сведения см. в статье "Работа с удостоверениями клиента".

CORS

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

<cors allow-credentials="true">
    <allowed-origins>
        <origin>[Website URL]</origin>
    </allowed-origins>
    <allowed-methods>
        <method>GET</method>
    </allowed-methods>
    <allowed-headers>
        <header>*</header>
    </allowed-headers>
</cors>

В этом примере атрибут allow-credentials имеет значение true. Это позволяет браузеру отправлять учетные данные (включая файлы cookie) с запросом. В противном случае браузер по умолчанию не отправляет учетные данные с запросом между источниками.

Примечание.

Будьте очень осторожны, устанавливая для allow-credentials значение true. Это означает, что веб-сайт может отправлять учетные данные пользователя в ваш API от имени пользователя без его ведома. Вы должны доверять разрешенному источнику.

Принудительное использование HTTPS

Для обеспечения максимальной безопасности требуйте использования HTTPS в конвейере запросов:

  • CDN. По умолчанию Azure CDN поддерживает HTTPS в поддомене *.azureedge.net. Чтобы включить HTTPS в сети CDN для имен личных доменов, ознакомьтесь со статьей Руководство по настройке протокола HTTPS для личного домена в сети доставки содержимого Azure.

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

  • Управление API. Настройте программные интерфейсы для использования только протокола HTTPS. Это можно настроить на портале Azure или с помощью шаблона Resource Manager.

    {
    "apiVersion": "2018-01-01",
    "type": "apis",
    "name": "dronedeliveryapi",
    "dependsOn": [
        "[concat('Microsoft.ApiManagement/service/', variables('apiManagementServiceName'))]"
    ],
    "properties": {
        "displayName": "Drone Delivery API",
        "description": "Drone Delivery API",
        "path": "api",
        "protocols": [ "HTTPS" ]
    },
    ...
}

  • Функции Azure. Включите параметр Только HTTPS.

Блокировка приложения-функции

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

  • Настройте в приложении-функции требование ключа функции. Шлюз службы управления API будет включать ключ функции при вызове приложения-функции. Это не позволяет клиентам вызывать функцию напрямую, минуя шлюз.

  • Шлюз службы управления API имеет статический IP-адрес. Ограничьте функцию Azure, чтобы разрешить вызовы только с этого статического IP-адреса. Дополнительные сведения см. в статье Ограничения статических IP-адресов в Службе приложений Azure. (Эта функция доступна только для служб ценовой категории "Стандартный".)

Защита секретов приложения

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

Кроме того, можно хранить секреты приложения в хранилище Key Vault. Это позволяет централизовать хранение секретов, контролировать их распределение и отслеживать, как и когда осуществляется доступ к ним. Дополнительные сведения см. в статье Руководство по настройке веб-приложения Azure для считывания секрета из Key Vault. Однако обратите внимание, что триггеры и привязки функций загружают параметры конфигурации из параметров приложения. Встроенный способ настройки триггеров и привязок для использования секретов Key Vault отсутствует.

DevOps

Безопасные методики развертывания автоматизированы с помощью надежной службы CI/CD, например Azure Pipelines или GitHub Actions. Эти службы используются для автоматической сборки и развертывания всех изменений источника в интерфейсной и серверной части. Источник должен находиться в системе управления версиями в сети. Дополнительные сведения о Azure Pipelines см. в статье "Создание первого конвейера". Дополнительные сведения о действиях GitHub для Azure см. в статье "Развертывание приложений в Azure".

Развертывание внешнего интерфейса

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

  • Разверните приложение равномерно для пользователей в широкой географической области с глобально готовой сетью CDN с статическим содержимым, размещенным в облаке. Это позволяет избежать необходимости выделенного веб-сервера. Ознакомьтесь с учетной записью хранения Azure с Azure CDN , чтобы приступить к работе. Защита приложения с помощью ПРОТОКОЛА HTTPS. Ознакомьтесь с рекомендациями по использованию сетей доставки содержимого для получения дополнительных рекомендаций.
  • Сжимайте файлы веб-сайта, чтобы уменьшить потребление пропускной способности в CDN и повысить производительность. Azure CDN позволяет сжимать летать на пограничных серверах. Кроме того, конвейер развертывания в этой эталонной архитектуре сжимает файлы перед развертыванием в хранилище BLOB-объектов. Это сокращает требования к хранилищу и дает вам большую свободу выбора средств сжатия независимо от каких-либо ограничений CDN.
  • CDN должна быть в состоянии очистить свой кэш , чтобы убедиться, что все пользователи обслуживаются самым свежим содержимым. Очистка кэша требуется, если процессы сборки и развертывания не являются атомарными, например, если они заменяют старые файлы только что созданными в той же папке источника.
  • Другая стратегия кэширования, например управление версиями с помощью каталогов, может не требовать очистки cdN. Конвейер сборки в этом интерфейсном приложении создает новый каталог для каждой созданной версии. Эта версия передается как атомарная единица в хранилище BLOB-объектов. Azure CDN указывает на эту новую версию только после завершения развертывания.
  • Увеличьте срок жизни кэша путем кэширования файлов ресурсов в течение длительного времени, охватывая месяцы. Чтобы убедиться, что кэшированные файлы обновляются при изменении, отпечаток имен файлов при перестроении. Это интерфейсное приложение отпечаток всех файлов, за исключением общедоступных файлов, таких как index.html. Так как index.html часто обновляется, он отражает измененные имена файлов, вызывающие обновление кэша. Дополнительные сведения см. в статье "Управление истечением срока действия веб-содержимого в Azure CDN".

Развертывание внутреннего сервера

Чтобы развернуть приложение-функцию, мы рекомендуем использовать файлы пакетов (команда "Запуск из пакета"). В рамках этого подхода вы загружаете ZIP-файл в контейнер хранилища BLOB-объектов, а среда выполнения Функций подключает ZIP-файл как файловую систему только для чтения. Так как это атомарная операция, вероятность того, что в случае сбоя при развертывании приложение останется в несогласованном состоянии, является низкой. Это также позволяет ускорить холодный запуск, особенно для приложений Node.js, так как все файлы меняются одновременно.

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

Управление версиями API

API — это контракт между службой и клиентами. В этой архитектуре контракт API определяется на уровне службы управления API. Служба управления API поддерживает две разные, но взаимодополняющие концепции присвоения версий:

  • Версии позволяют объектам-получателям выбрать версию API в зависимости от потребностей, например версию 1 или 2.

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

Если вы вносите критические изменения в API, опубликуйте новую версию в службе управления API. Разверните новую версию параллельно с исходной версией в отдельном приложении-функции. Это позволяет перенести существующих клиентов в новый API без нарушения клиентских приложений. В конце концов, вы сможете прекратить поддержку предыдущей версии. Служба управления API поддерживает несколько схем управления версиями: URL-путь, HTTP-заголовок или строка запроса. См. дополнительные сведения об управлении версиями веб-API RESTful.

Для обновлений, которые не нарушают изменения API, разверните новую версию в промежуточном слоте в том же приложении-функции. Убедитесь, что развертывание выполнено успешно, а затем замените промежуточную версию рабочей. Опубликуйте версию в службе управления API.

Оптимизация затрат

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

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

Функции Azure

Функции Azure поддерживают две модели размещения.

  • План "Потребление".

    Вычислительная мощность автоматически выделяется при выполнении кода.

  • План службы приложений.

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

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

Azure Cosmos DB

Счета за подготовленную пропускную способность и потребляемое хранилище в час в Azure Cosmos DB. Подготовленная пропускная способность выражается в единицах запросов в секунду (ЕЗ/с), которые можно использовать для типичных операций базы данных, таких как вставки, операции чтения. Цена основана на емкости в единицах ЕЗ/с, которые вы зарезервируют.

Плата за хранение взимается за каждый ГБ, используемый для хранимых данных и индекса.

Дополнительные сведения см. в модели ценообразования Azure Cosmos DB.

В этой архитектуре приложение-функция получает документы из Azure Cosmos DB в ответ на HTTP-запросы GET от клиента. Azure Cosmos DB является экономически эффективным в этом случае, так как операции чтения значительно дешевле, чем операции записи, выраженные в единицах запросов в секунду.

Сеть доставки содержимого

Тарифы выставления счетов могут отличаться в зависимости от региона выставления счетов в зависимости от расположения исходного сервера, предоставляющего содержимое конечному пользователю. Физическое расположение клиента не является регионом выставления счетов. Любой ЗАПРОС HTTP или HTTPS, который попадает в CDN, является оплачиваемым событием, которое включает все типы ответов: успех, сбой или другое. Различные ответы могут создавать разные объемы трафика.

В этой эталонной архитектуре развертывание находится в одном регионе Azure.

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

Дополнительные сведения см. в разделе "Затраты" в Microsoft Azure Well-Architected Framework.

Развертывание этого сценария

Сведения о развертывании эталонной реализации для этой архитектуры см. в GitHub readme.

Следующие шаги

Документация по продукту:

Обучайте модули:

Дополнительные сведения о эталонной реализации см. в пошаговом руководстве по коду: бессерверное приложение с Функции Azure.

Связанные руководства.