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

Azure Active Directory
Управление API
Хранилище BLOB-объектов
Cosmos DB
Сеть доставки содержимого (CDN)
Функции
Azure Monitor
Pipelines

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

Логотип GitHub . Эталонная реализация для этой архитектуры доступна на сайте GitHub.

Эталонная архитектура для веб-приложения без сервера Скачайте SVG этой архитектуры.

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

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

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

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

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

Architecture

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

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

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

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

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

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

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

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

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

Azure Active Directory (Azure AD). Пользователи входят в веб-приложение, используя свои учетные данные Azure AD. Azure AD возвращает маркер доступа для API, используемый веб-приложением для проверки подлинности запросов API (см. раздел Проверка подлинности).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[FunctionName("GetStatusFunction")]
public static Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Function, "get", Route = null)] HttpRequest req,
    [CosmosDB(
        databaseName: "%COSMOSDB_DATABASE_NAME%",
        collectionName: "%COSMOSDB_DATABASE_COL%",
        ConnectionStringSetting = "COSMOSDB_CONNECTION_STRING",
        Id = "{Query.deviceId}",
        PartitionKey = "{Query.deviceId}")] dynamic deviceStatus,
    ILogger log)
{
    ...
}

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

Вопросы масштабируемости

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

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

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

Рекомендации по аварийному восстановлению

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

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

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

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

Вопросы безопасности

Аутентификация

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

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

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

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

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

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

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

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

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

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

Авторизация

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

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

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

CORS

В этой эталонной архитектуре веб-приложение и API не имеют общего источника. Это означает, что когда приложение вызывает API, это запрос CORS. Параметры безопасности веб-браузера предотвращают отправку запросов 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) с запросом. По умолчанию браузер не отправляет учетные данные с запросом CORS.

Примечание

Будьте очень осторожны, устанавливая для 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

Внешнее развертывание

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

  • Развертывайте приложение единообразно для пользователей в широкой географической области с глобально готовым CDN, используя статическое содержимое, размещенное в облаке. Это позволяет избежать необходимости использования выделенного веб-сервера. Чтобы приступить к работе, прочитайте статью Интеграция учетной записи хранения Azure с Azure CDN . Защитите приложение с помощью протокола HTTPS. Ознакомьтесь с рекомендациями по использованию сетей доставки содержимого для получения дополнительных рекомендаций.
  • Используйте быструю и надежную службу CI/CD, например Azure pipelines, для автоматической сборки и развертывания каждого изменения источника. Источник должен находиться в оперативной системе управления версиями. Дополнительные сведения см. в статье Создание первого конвейера.
  • Сжимать файлы веб-сайта, чтобы уменьшить потребление пропускной способности сети 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 векселя на подготовленную пропускную способность и потребляемую память за час. Подготовленная пропускная способность выражается в единицах запросов в секунду, которые могут использоваться для типичных операций с базами данных, таких как операции вставки, чтения. Цена зависит от емкости зарезервированных единиц запросов в секунду.

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

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

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

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

Ставка выставления счетов может отличаться в зависимости от региона выставления счетов на основе расположения исходного сервера, который доставляет содержимое конечному пользователю. Физическое расположение клиента не является регионом выставления счетов. Любой запрос HTTP или HTTPS, который обращается к CDN, — это оплачиваемое событие, включающее все типы ответов: Success, Failure или other. Различные ответы могут формировать разные объемы трафика.

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

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

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

Развертывание решения

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

Дальнейшие действия

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

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