Бессерверное веб-приложение в AzureServerless web application on Azure

В этой эталонной архитектуре показано бессерверное веб-приложение.This reference architecture shows a serverless web application. Приложение передает статическое содержимое из хранилища BLOB-объектов Azure, а также реализует программный интерфейс с помощью Функций Azure.The application serves static content from Azure Blob Storage, and implements an API using Azure Functions. API считывает данные из Cosmos DB и возвращает результаты в веб-приложение.The API reads data from Cosmos DB and returns the results to the web app.

Логотип GitHub . Эталонная реализация для этой архитектуры доступна на сайте GitHub.GitHub logo A reference implementation for this architecture is available on GitHub.

Эталонная архитектура для веб-приложения без сервера Скачайте SVG этой архитектуры.Reference architecture for a serverless web application Download an SVG of this architecture. | Загрузите Visio этой архитектуры. | Download an Visio of this architecture.

Термин "бессерверный" может иметь два различных значения, которые тем не менее связаны между собой:The term serverless has two distinct but related meanings:

  • Серверная часть как услуга (BaaS).Backend as a service (BaaS). Серверные облачные службы, такие как базы данных и хранилище, предоставляют интерфейсы API, которые позволяют клиентским приложениям напрямую подключаться к этим службам.Back-end cloud services, such as databases and storage, provide APIs that enable client applications to connect directly to these services.
  • Функции как услуга (FaaS).Functions as a service (FaaS). В этой модели "функция" представляет собой фрагмент кода, который развертывается в облаке и выполняется в среде узла, которая полностью абстрагирует серверы, на которых запускается код.In this model, a "function" is a piece of code that is deployed to the cloud and runs inside a hosting environment that completely abstracts the servers that run the code.

Оба определения подразумевают общую идею о том, что разработчикам и персоналу DevOps не нужно развертывать, настраивать или администрировать серверы.Both definitions have in common the idea that developers and DevOps personnel don't need to deploy, configure, or manage servers. Эта Эталонная архитектура сосредоточена на FaaS с помощью функций Azure, хотя обслуживание веб-содержимого из хранилища больших двоичных объектов Azure может быть примером BaaS.This reference architecture focuses on FaaS using Azure Functions, although serving web content from Azure Blob Storage could be an example of BaaS. Ниже приведены некоторые важные характеристики FaaS:Some important characteristics of FaaS are:

  1. Вычислительные ресурсы динамически распределяются платформой по мере необходимости.Compute resources are allocated dynamically as needed by the platform.
  2. Ценообразование на основе потребления: вы платите только за вычислительные ресурсы, которые используются для выполнения кода.Consumption-based pricing: You are charged only for the compute resources used to execute your code.
  3. Вычислительные ресурсы масштабируются по запросу на основе трафика, и разработчику при этом не нужно выполнять какую-либо конфигурацию.The compute resources scale on demand based on traffic, without the developer needing to do any configuration.

Функции выполняются при возникновении внешнего триггера, например HTTP-запроса или сообщения, поступающего в очередь.Functions are executed when an external trigger occurs, such as an HTTP request or a message arriving on a queue. Благодаря этому тип управляемой событиями архитектуры является естественным для бессерверных архитектур.This makes an event-driven architecture style natural for serverless architectures. Чтобы координировать работу между компонентами в архитектуре, рассмотрите возможность использования брокеров сообщений или шаблонов публикаций и подписок.To coordinate work between components in the architecture, consider using message brokers or pub/sub patterns. Сведения о выборе между технологиями обмена сообщениями в Azure см. в статье Выбор между службами Azure, которые доставляют сообщения.For help with choosing between messaging technologies in Azure, see Choose between Azure services that deliver messages.

АрхитектураArchitecture

Она состоит из следующих компонентов:The architecture consists of the following components:

Хранилище BLOB-объектов.Blob Storage. Статическое веб-содержимое, такое как файлы HTML, CSS и JavaScript, сохраняется в хранилище BLOB-объектов Azure и обслуживается клиентами с помощью размещения статических веб-сайтов.Static web content, such as HTML, CSS, and JavaScript files, are stored in Azure Blob Storage and served to clients by using static website hosting. Все динамическое взаимодействие происходит через код JavaScript, осуществляющий вызовы интерфейсных API.All dynamic interaction happens through JavaScript code making calls to the back-end APIs. Для отображения веб-страницы не используется серверный код.There is no server-side code to render the web page. Размещение статических веб-сайтов поддерживает индексированные документы и настраиваемые страницы ошибок 404.Static website hosting supports index documents and custom 404 error pages.

CDN.CDN. Используйте сеть доставки содержимого Azure (CDN), чтобы выполнять кэширование содержимого с меньшей задержкой и более быстрой доставкой, а также предоставлением конечной точки HTTPS.Use Azure Content Delivery Network (CDN) to cache content for lower latency and faster delivery of content, as well as providing an HTTPS endpoint.

Приложения функций.Function Apps. Функции Azure — это независимая от сервера служба вычислений.Azure Functions is a serverless compute option. Она использует управляемую событиями модель, где часть кода ("функция") вызывается триггером.It uses an event-driven model, where a piece of code (a "function") is invoked by a trigger. В этой архитектуре функция вызывается, когда клиент делает HTTP-запрос.In this architecture, the function is invoked when a client makes an HTTP request. Запрос всегда маршрутизируется через шлюз API, описанный ниже.The request is always routed through an API gateway, described below.

Управление API.API Management. Управление API предоставляет шлюз API, который располагается перед функцией HTTP.API Management provides an API gateway that sits in front of the HTTP function. Службу управления API можно использовать для публикации программных интерфейсов, используемых клиентскими приложениями, а также для управления ими.You can use API Management to publish and manage APIs used by client applications. Использование шлюза помогает отделить внешнее приложение от серверных API.Using a gateway helps to decouple the front-end application from the back-end APIs. Например, управление API может перезаписывать URL-адреса, преобразовывать запросы перед достижением серверной части, задавать заголовки запроса или ответа и т. д.For example, API Management can rewrite URLs, transform requests before they reach the back end, set request or response headers, and so forth.

Управление API также может использоваться для реализации сквозных задач, таких как:API Management can also be used to implement cross-cutting concerns such as:

  • Принудительное применение квот потребления и ограничений скорости.Enforcing usage quotas and rate limits
  • Проверка токенов OAuth для аутентификации.Validating OAuth tokens for authentication
  • Включение запросов независимо от источника (CORS).Enabling cross-origin requests (CORS)
  • Кэширование ответов.Caching responses
  • Мониторинг и ведение журнала запросов.Monitoring and logging requests

Если вам не нужны все функциональные возможности, предоставляемые службой управления API, можно использовать прокси-серверы Функций.If you don't need all of the functionality provided by API Management, another option is to use Functions Proxies. Эта возможность Функций Azure позволяет вам определять единую поверхность API для нескольких приложений-функций, создавая маршруты к серверным функциям.This feature of Azure Functions lets you define a single API surface for multiple function apps, by creating routes to back-end functions. Прокси-серверы Функций также могут выполнять ограниченные преобразования запросов и ответов HTTP.Function proxies can also perform limited transformations on the HTTP request and response. Тем не менее они не обеспечивают те же расширенные функциональные возможности управления API на основе политик.However, they don't provide the same rich policy-based capabilities of API Management.

Cosmos DB.Cosmos DB. Cosmos DB — многомодельная служба базы данных.Cosmos DB is a multi-model database service. Для этого сценария приложение-функция извлекает документы из Cosmos DB в ответ на запросы HTTP GET от клиента.For this scenario, the function application fetches documents from Cosmos DB in response to HTTP GET requests from the client.

Azure Active Directory (Azure AD).Azure Active Directory (Azure AD). Пользователи входят в веб-приложение, используя свои учетные данные Azure AD.Users sign into the web application by using their Azure AD credentials. Azure AD возвращает маркер доступа для API, используемый веб-приложением для проверки подлинности запросов API (см. раздел Проверка подлинности).Azure AD returns an access token for the API, which the web application uses to authenticate API requests (see Authentication).

Azure Monitor.Azure Monitor. Monitor собирает метрики производительности о службах Azure, развернутых в решении.Monitor collects performance metrics about the Azure services deployed in the solution. Отобразив эти данные в визуализации на панели мониторинга, можно получить сведения о работоспособности решения.By visualizing these in a dashboard, you can get visibility into the health of the solution. Monitor также собирает журналы приложений.It also collected application logs.

Azure Pipelines.Azure Pipelines. Pipelines — это служба непрерывной интеграции (CI) и непрерывной поставки (CD), которая выполняет сборку, тестирование и развертывание приложений.Pipelines is a continuous integration (CI) and continuous delivery (CD) service that builds, tests, and deploys the application.

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

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

Функции Azure поддерживают две модели размещения.Azure Functions supports two hosting models. План потребления автоматически выделяет вычислительную мощность при выполнении кода.With the consumption plan, compute power is automatically allocated when your code is running. В плане службы приложений для кода выделяется набор виртуальных машин.With the App Service plan, a set of VMs are allocated for your code. План службы приложений определяет число и размер виртуальных машин.The App Service plan defines the number of VMs and the VM size.

Обратите внимание, что план службы приложений не является бессерверным в соответствии с определением, указанным выше.Note that the App Service plan is not strictly serverless, according to the definition given above. Модель программирования одна и та же, однако тот же код функции может выполняться как в плане потребления, так и в плане службы приложений.The programming model is the same, however — the same function code can run in both a consumption plan and an App Service plan.

Ниже приведены некоторые факторы, которые следует учитывать при выборе подходящего плана для использования.Here are some factors to consider when choosing which type of plan to use:

  • Холодный запуск.Cold start. В плане потребления функция, которая не вызывалась недавно, в следующий раз будет вызвана с дополнительной задержкой.With the consumption plan, a function that hasn't been invoked recently will incur some additional latency the next time it runs. Эта дополнительная задержка обусловлена ​​распределением и подготовкой среды выполнения.This additional latency is due to allocating and preparing the runtime environment. Обычно это занимает несколько секунд, но зависит от нескольких факторов, в том числе от количества зависимостей, которые необходимо загрузить.It is usually on the order of seconds but depends on several factors, including the number of dependencies that need to be loaded. Дополнительные сведения см. в статье о холодном запуске в бессерверной архитектуре.For more information, see Understanding Serverless Cold Start. Холодный запуск обычно больше относится к интерактивным (HTTP-триггеры), чем к асинхронным рабочим нагрузкам, связанным с сообщениями (триггеры очереди или концентраторов событий), потому что дополнительная задержка наблюдается непосредственно пользователями.Cold start is usually more of a concern for interactive workloads (HTTP triggers) than asynchronous message-driven workloads (queue or event hubs triggers), because the additional latency is directly observed by users.
  • Период времени ожидания.Timeout period. В плане потребления функция должна выполняться в течение настроенного времени ожидания (максимум до 10 минут).In the consumption plan, a function execution times out after a configurable period of time (to a maximum of 10 minutes)
  • Изоляция виртуальной сети.Virtual network isolation. Использование плана службы приложений позволяет выполнять функции внутри среды службы приложений, которая представляет собой выделенную и изолированную среду размещения.Using an App Service plan allows functions to run inside of an App Service Environment, which is a dedicated and isolated hosting environment.
  • Модель ценообразования.Pricing model. В плане потребления счета выставляются по количеству выполнений и потреблению ресурсов (память × время выполнения).The consumption plan is billed by the number of executions and resource consumption (memory × execution time). В плане службы приложений счета выставляются ежечасно на основе номера SKU экземпляра виртуальной машины.The App Service plan is billed hourly based on VM instance SKU. Часто план потребления может быть дешевле, чем план службы приложений, так как вы платите только за те ресурсы вычислений, которые используете.Often, the consumption plan can be cheaper than an App Service plan, because you pay only for the compute resources that you use. Это особенно верно в случаях, если в трафике наблюдаются пики и спады.This is especially true if your traffic experiences peaks and troughs. Однако если в приложении наблюдается постоянная высокая пропускная способность, план службы приложений может стоить меньше, чем план потребления.However, if an application experiences constant high-volume throughput, an App Service plan may cost less than the consumption plan.
  • Масштабирование.Scaling. Большим преимуществом модели потребления является то, что она масштабируется динамически по мере необходимости в зависимости от входящего трафика.A big advantage of the consumption model is that it scales dynamically as needed, based on the incoming traffic. Хотя это масштабирование происходит быстро, есть еще период постепенного повышения производительности.While this scaling occurs quickly, there is still a ramp-up period. Для некоторых рабочих нагрузок может потребоваться намеренная избыточная подготовка виртуальных машин, чтобы можно было обрабатывать всплески трафика без периода нарастания.For some workloads, you might want to deliberately overprovision the VMs, so that you can handle bursts of traffic with zero ramp-up time. В этом случае используйте план службы приложений.In that case, consider an App Service plan.

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

Приложение-функция выполняет одну или несколько функций.A function app hosts the execution of one or more functions. Приложение-функцию можно использовать для группирования нескольких функций в виде логической единицы.You can use a function app to group several functions together as a logical unit. Эти функции совместно используют одни и те же параметры приложения, план размещения и жизненный цикл развертывания.Within a function app, the functions share the same application settings, hosting plan, and deployment lifecycle. Каждое приложение-функция имеет собственное имя узла.Each function app has its own hostname.

Используйте приложения-функции для группирования функций с одинаковыми жизненным циклом и параметрами.Use function apps to group functions that share the same lifecycle and settings. Функции с разным жизненным циклом должны размещаться в различных приложениях-функциях.Functions that don't share the same lifecycle should be hosted in different function apps.

Рассмотрите подход с микрослужбами, где каждое приложение-функция представляет одну микрослужбу, которая может состоять из нескольких связанных функций.Consider taking a microservices approach, where each function app represents one microservice, possibly consisting of several related functions. В архитектуре микрослужб службы должны иметь слабую взаимозависимость и высокую функциональную слаженность.In a microservices architecture, services should have loose coupling and high functional cohesion. Слабая взаимозависимость означает, что вы можете изменить одну службу без необходимости одновременного обновления других служб.Loosely coupled means you can change one service without requiring other services to be updated at the same time. Слаженность означает, что служба имеет единую четко определенную цель.Cohesive means a service has a single, well-defined purpose. Более подробное описание этих идей см. в статье Проектирование микрослужб: анализ предметной области.For more discussion of these ideas, see Designing microservices: Domain analysis.

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

Используйте привязки функций, когда это возможно.Use Functions bindings when possible. Привязки предоставляют декларативный способ подключения кода к данным и интеграцию с другими службами Azure.Bindings provide a declarative way to connect your code to data and integrate with other Azure services. Входная привязка заполняет входной параметр из внешнего источника данных.An input binding populates an input parameter from an external data source. Выходная привязка отправляет возвращаемое значение функции в приемник данных, например в очередь или базу данных.An output binding sends the function's return value to a data sink, such as a queue or database.

Предположим, что функция GetStatus в эталонной реализации использует входную привязку Cosmos DB.For example, the GetStatus function in the reference implementation uses the Cosmos DB input binding. Эта привязка настроена для поиска документов в Cosmos DB с помощью параметров запроса, которые берутся из строки в HTTP-запросе.This binding is configured to look up a document in Cosmos DB, using query parameters that are taken from the query string in the HTTP request. Если документ найден, он передается в функцию как параметр.If the document is found, it is passed to the function as a parameter.

[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)
{
    ...
}

При использовании привязок не требуется писать код, который напрямую обращается к службе. Таким образом, код функции упрощается, а сведения об источнике или приемнике данных абстрагируются.By using bindings, you don't need to write code that talks directly to the service, which makes the function code simpler and also abstracts the details of the data source or sink. Однако в некоторых случаях может потребоваться более сложная логика, чем та, которую обеспечивает привязка.In some cases, however, you may need more complex logic than the binding provides. В этом случае используйте клиентские пакеты SDK Azure напрямую.In that case, use the Azure client SDKs directly.

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

Функции.Functions. Для плана потребления HTTP-триггер масштабируется на основе трафика.For the consumption plan, the HTTP trigger scales based on the traffic. Существует ограничение на количество параллельных экземпляров функций, но каждый экземпляр может обрабатывать несколько запросов одновременно.There is a limit to the number of concurrent function instances, but each instance can process more than one request at a time. Для плана службы приложений HTTP-триггер масштабируется в соответствии с количеством экземпляров виртуальных машин, которое может быть фиксированным значением или автоматически изменяться на основе набора правил автомасштабирования.For an App Service plan, the HTTP trigger scales according to the number of VM instances, which can be a fixed value or can autoscale based on a set of autoscaling rules. Дополнительные сведения см. в статье Масштабирование и размещение Функций Azure.For information, see Azure Functions scale and hosting.

Cosmos DB.Cosmos DB. Пропускная способность для Cosmos DB измеряется в единицах запроса (RU).Throughput capacity for Cosmos DB is measured in Request Units (RU). Одна единица запроса соответствует пропускной способности операций GET, выполняемых для документа объемом 1 КБ.A 1-RU throughput corresponds to the throughput need to GET a 1KB document. Чтобы масштабировать контейнер Cosmos DB на более чем 10 000 единиц запросов, необходимо указать ключ секции при создании контейнера и добавить этот ключ в каждый создаваемый документ.In order to scale a Cosmos DB container past 10,000 RU, you must specify a partition key when you create the container and include the partition key in every document that you create. Дополнительные сведения о ключах секций см. в статье Секционирование и масштабирование в Azure Cosmos DB.For more information about partition keys, see Partition and scale in Azure Cosmos DB.

Управление API.API Management. Управление API может масштабироваться и поддерживает автоматическое масштабирование на основе правил.API Management can scale out and supports rule-based autoscaling. Процесс масштабирования занимает не менее 20 минут.The scaling process takes at least 20 minutes. Если ваш трафик прерывистый, следует подготовиться к максимальному всплеску трафика, который вы ожидаете.If your traffic is bursty, you should provision for the maximum burst traffic that you expect. Однако автоматическое масштабирование полезно для обработки почасовых или ежедневных колебаний трафика.However, autoscaling is useful for handling hourly or daily variations in traffic. Дополнительные сведения см. в статье Автоматическое масштабирование экземпляра службы управления API Azure.For more information, see Automatically scale an Azure API Management instance.

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

Представленное здесь развертывание расположено в одном регионе Azure.The deployment shown here resides in a single Azure region. Для более гибкого подхода к аварийному восстановлению воспользуйтесь функциями геораспределения в различных службах:For a more resilient approach to disaster-recovery, take advantage of the geo-distribution features in the various services:

  • Служба управления API поддерживает развертывание в нескольких регионах, что позволяет распространять единый экземпляр службы управления API в любом количестве регионов Azure.API Management supports multi-region deployment, which can be used to distribute a single API Management instance across any number of Azure regions. Дополнительные сведения см. в статье Развертывание экземпляра службы управления Azure API в различных регионах Azure.For more information, see How to deploy an Azure API Management service instance to multiple Azure regions.

  • Используйте диспетчер трафика, чтобы направлять HTTP-запросы в основной регион.Use Traffic Manager to route HTTP requests to the primary region. Если приложение-функция, работающее в этом регионе, становится недоступным, диспетчер трафика выполняет отработку отказа в дополнительный регион.If the Function App running in that region becomes unavailable, Traffic Manager can fail over to a secondary region.

  • Cosmos DB поддерживает несколько основных регионов, что позволяет записывать данные в любой регион, добавляемый в учетную запись Cosmos DB.Cosmos DB supports multiple master regions, which enables writes to any region that you add to your Cosmos DB account. Если не включить несколько источников, можно по-прежнему выполнить отработку отказа в основной регион записи.If you don't enable multi-master, you can still fail over the primary write region. Клиентские пакеты SDK для Cosmos DB и привязки Функций Azure автоматически выполняют отработку отказа, поэтому нет необходимости обновлять параметры конфигурации приложения.The Cosmos DB client SDKs and the Azure Function bindings automatically handle the failover, so you don't need to update any application configuration settings.

Замечания по безопасностиSecurity considerations

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

API GetStatus в эталонной реализации использует Azure AD для аутентификации запросов.The GetStatus API in the reference implementation uses Azure AD to authenticate requests. Azure AD поддерживает протокол OpenID Connect Connect, который является протоколом проверки подлинности на основе протокола OAuth 2.Azure AD supports the OpenID Connect protocol, which is an authentication protocol built on top of the OAuth 2 protocol.

В этой архитектуре клиентское приложение представляет собой одностраничное приложение (SPA), которое запускается в браузере.In this architecture, the client application is a single-page application (SPA) that runs in the browser. Этот тип клиентского приложения не может хранить секрет клиента или код авторизации скрытым, поэтому следует использовать поток неявного предоставления разрешений.This type of client application cannot keep a client secret or an authorization code hidden, so the implicit grant flow is appropriate. (См. сведения об использовании потока OAuth 2.0).(See Which OAuth 2.0 flow should I use?). Вот общий поток действий:Here's the overall flow:

  1. Пользователь щелкает ссылку "Войти" в веб-приложении.The user clicks the "Sign in" link in the web application.
  2. Браузер перенаправляется на страницу входа Azure AD.The browser is redirected the Azure AD sign in page.
  3. Пользователь входит в систему.The user signs in.
  4. Azure AD выполняет перенаправление обратно в клиентское приложение, добавляя маркер доступа во фрагменте URL-адреса.Azure AD redirects back to the client application, including an access token in the URL fragment.
  5. Когда веб-приложение вызывает API, оно добавляет маркер доступа в заголовок аутентификации.When the web application calls the API, it includes the access token in the Authentication header. Идентификатор приложения отправляется в качестве утверждения целевой аудитории (aud) в маркере доступа.The application ID is sent as the audience ('aud') claim in the access token.
  6. API серверной части проверяет маркер доступа.The back-end API validates the access token.

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

  • Зарегистрируйте приложение в клиенте Azure AD.Register an application in your Azure AD tenant. При этом создается идентификатор приложения, который клиент добавляет в URL-адрес входа.This generates an application ID, which the client includes with the login URL.

  • Включите проверку подлинности Azure AD в приложении-функции.Enable Azure AD authentication inside the Function App. Дополнительные сведения см. в статье Проверка подлинности и авторизация в службе приложений Azure.For more information, see Authentication and authorization in Azure App Service.

  • Добавьте политику validate-jw в службу управления API, чтобы предварительно авторизовать запрос, проверив маркер доступа.Add the validate-jwt policy to API Management to pre-authorize the request by validating the access token.

Дополнительные сведения см. в файле сведений на сайте GitHub.For more details, see the GitHub readme.

Рекомендуется создавать отдельные регистрации приложений в Azure AD для клиентского приложения и API серверной части.It's recommended to create separate app registrations in Azure AD for the client application and the back-end API. Предоставьте клиентскому приложению разрешение вызывать веб-API.Grant the client application permission to call the API. Этот подход позволяет определить несколько API и клиентов, а также управлять разрешениями для каждого из них.This approach gives you the flexibility to define multiple APIs and clients and control the permissions for each.

В API используйте области, чтобы приложение могло управлять разрешениями, которые оно запрашивает у пользователя.Within an API, use scopes to give applications fine-grained control over what permissions they request from a user. Например, API может использовать области Read и Write, а определенное клиентское приложение может запросить у пользователя авторизовать только разрешения Read.For example, an API might have Read and Write scopes, and a particular client app might ask the user to authorize Read permissions only.

АвторизацияAuthorization

Во многих приложениях API серверной части должен проверить, имеет ли пользователь разрешение на выполнение данного действия.In many applications, the back-end API must check whether a user has permission to perform a given action. Рекомендуется использовать авторизацию на основе утверждений, где информация о пользователе передается поставщиком удостоверений (в данном случае Azure AD) и используется для принятия решений об авторизации.It's recommended to use claims-based authorization, where information about the user is conveyed by the identity provider (in this case, Azure AD) and used to make authorization decisions. Например, при регистрации приложения в Azure AD можно определить набор ролей приложения.For example, when you register an application in Azure AD, you can define a set of application roles. Когда пользователь входит в приложение, Azure AD включает roles утверждение для каждой роли, предоставленной пользователю, включая роли, унаследованные с помощью членства в группе.When a user signs into the application, Azure AD includes a roles claim for each role that the user has been granted, including roles that are inherited through group membership.

Маркер идентификации, который Azure AD возвращает клиенту, содержит некоторые утверждения пользователя.The ID token that Azure AD returns to the client contains some of the user's claims. В приложении-функции эти утверждения доступны в заголовке запроса X-MS-CLIENT-PRINCIPAL.Within the function app, these claims are available in the X-MS-CLIENT-PRINCIPAL header of the request. Однако проще прочитать эту информацию из привязки данных.However, it's simpler to read this information from binding data. Для других утверждений используйте Microsoft Graph , чтобы запросить Azure AD.For other claims, use Microsoft Graph to query Azure AD. (Пользователь должен согласиться с этим действием при входе в систему.)(The user must consent to this action when signing in.)

Дополнительные сведения см. в разделе Работа с удостоверениями клиентов.For more information, see Working with client identities.

CORSCORS

В этой эталонной архитектуре веб-приложение и API не имеют общего источника.In this reference architecture, the web application and the API do not share the same origin. Это означает, что когда приложение вызывает API, это запрос CORS.That means when the application calls the API, it is a cross-origin request. Параметры безопасности веб-браузера предотвращают отправку запросов AJAX с веб-страницы к другому домену.Browser security prevents a web page from making AJAX requests to another domain. Это ограничение называется политикой того же происхождения и предотвращает считывание вредоносными данными из другого сайта.This restriction is called the same-origin policy and prevents a malicious site from reading sensitive data from another site. Чтобы включить запрос общего доступа к ресурсам независимо от источника, добавьте политику CORS в шлюз службы управления API:To enable a cross-origin request, add a Cross-Origin Resource Sharing (CORS) policy to the API Management gateway:

<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.In this example, the allow-credentials attribute is true. Это позволяет браузеру отправлять учетные данные (включая файлы cookie) с запросом.This authorizes the browser to send credentials (including cookies) with the request. По умолчанию браузер не отправляет учетные данные с запросом CORS.Otherwise, by default the browser does not send credentials with a cross-origin request.

Примечание

Будьте очень осторожны, устанавливая для allow-credentials значение true. Это означает, что веб-сайт может отправлять учетные данные пользователя в ваш API от имени пользователя без его ведома.Be very careful about setting allow-credentials to true, because it means a website can send the user's credentials to your API on the user's behalf, without the user being aware. Вы должны доверять разрешенному источнику.You must trust the allowed origin.

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

Для обеспечения максимальной безопасности требуйте использования HTTPS в конвейере запросов:For maximum security, require HTTPS throughout the request pipeline:

  • CDN.CDN. По умолчанию Azure CDN поддерживает HTTPS в поддомене *.azureedge.net.Azure CDN supports HTTPS on the *.azureedge.net subdomain by default. Чтобы включить HTTPS в сети CDN для имен личных доменов, ознакомьтесь со статьей Руководство по настройке протокола HTTPS для личного домена в сети доставки содержимого Azure.To enable HTTPS in the CDN for custom domain names, see Tutorial: Configure HTTPS on an Azure CDN custom domain.

  • Размещение статического веб-сайта.Static website hosting. Включите параметр Требуется безопасное перемещение в учетной записи хранения.Enable the "Secure transfer required" option on the Storage account. Если этот параметр включен, учетная запись хранения разрешает запросы только с защищенных подключений HTTPS.When this option is enabled, the storage account only allows requests from secure HTTPS connections.

  • Управление API.API Management. Настройте программные интерфейсы для использования только протокола HTTPS.Configure the APIs to use HTTPS protocol only. Это можно настроить на портале Azure или с помощью шаблона Resource Manager.You can configure this in the Azure portal or through a Resource Manager template:

    {
        "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.Azure Functions. Включите параметр Только HTTPS.Enable the "HTTPS Only" setting.

Блокировка приложения-функцииLock down the function app

Все вызовы функции должны проходить через шлюз API.All calls to the function should go through the API gateway. Этого можно достичь следующим образом:You can achieve this as follows:

  • Настройте в приложении-функции требование ключа функции.Configure the function app to require a function key. Шлюз службы управления API будет включать ключ функции при вызове приложения-функции.The API Management gateway will include the function key when it calls the function app. Это не позволяет клиентам вызывать функцию напрямую, минуя шлюз.This prevents clients from calling the function directly, bypassing the gateway.

  • Шлюз службы управления API имеет статический IP-адрес.The API Management gateway has a static IP address. Ограничьте функцию Azure, чтобы разрешить вызовы только с этого статического IP-адреса.Restrict the Azure Function to allow only calls from that static IP address. Дополнительные сведения см. в статье Ограничения статических IP-адресов в Службе приложений Azure.For more information, see Azure App Service Static IP Restrictions. (Эта функция доступна только для служб ценовой категории "Стандартный".)(This feature is available for Standard tier services only.)

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

Не храните секреты приложений, такие как учетные данные базы данных, в файлах кода или конфигурации.Don't store application secrets, such as database credentials, in your code or configuration files. Вместо этого используйте параметры приложения, которые хранятся в зашифрованном виде в Azure.Instead, use App settings, which are stored encrypted in Azure. Дополнительные сведения см. в статье Безопасность в Службе приложений Azure и службе "Функции Azure".For more information, see Security in Azure App Service and Azure Functions.

Кроме того, можно хранить секреты приложения в хранилище Key Vault.Alternatively, you can store application secrets in Key Vault. Это позволяет централизовать хранение секретов, контролировать их распределение и отслеживать, как и когда осуществляется доступ к ним.This allows you to centralize the storage of secrets, control their distribution, and monitor how and when secrets are being accessed. Дополнительные сведения см. в статье Руководство по настройке веб-приложения Azure для считывания секрета из Key Vault.For more information, see Configure an Azure web application to read a secret from Key Vault. Однако обратите внимание, что триггеры и привязки функций загружают параметры конфигурации из параметров приложения.However, note that Functions triggers and bindings load their configuration settings from app settings. Не существует встроенного способа настройки триггеров и привязок для использования секретов Key Vault.There is no built-in way to configure the triggers and bindings to use Key Vault secrets.

Рекомендации для DevOpsDevOps considerations

Внешнее развертываниеFront-end deployment

Интерфейсная архитектура этой эталонной архитектуры — это одностраничное приложение, поддерживающее JavaScript, обращающееся к серверным интерфейсам API, и статическое содержимое, обеспечивающее быстрый пользовательский интерфейс.The front end of this reference architecture is a single page application, with JavaScript accessing the serverless back-end APIs, and static content providing a fast user experience. Ниже приведены некоторые важные рекомендации для такого приложения.The following are some important considerations for such an application:

  • Развертывайте приложение единообразно для пользователей в широкой географической области с глобально готовым CDN, используя статическое содержимое, размещенное в облаке.Deploy the application uniformly to users over a wide geographical area with a global-ready CDN, with the static content hosted on the cloud. Это позволяет избежать необходимости использования выделенного веб-сервера.This avoids the need for a dedicated web server. Чтобы приступить к работе, прочитайте статью Интеграция учетной записи хранения Azure с Azure CDN .Read Integrate an Azure storage account with Azure CDN to get started. Защитите приложение с помощью протокола HTTPS.Secure your application with HTTPS. Ознакомьтесь с рекомендациями по использованию сетей доставки содержимого для получения дополнительных рекомендаций.Read the Best practices for using content delivery networks for additional recommendations.
  • Используйте быструю и надежную службу CI/CD, например Azure pipelines, для автоматической сборки и развертывания каждого изменения источника.Use a fast and reliable CI/CD service such as Azure Pipelines, to automatically build and deploy every source change. Источник должен находиться в оперативной системе управления версиями.The source must reside in an online version control system. Дополнительные сведения см. в статье Создание первого конвейера.For more details, read Create your first pipeline.
  • Сжимать файлы веб-сайта, чтобы уменьшить потребление пропускной способности сети CDN и повысить производительность.Compress your website files to reduce the bandwidth consumption on the CDN and improve performance. Azure CDN обеспечивает Сжатие на лету на пограничных серверах.Azure CDN allows compression on the fly on the edge servers. Кроме того, конвейер развертывания в этой эталонной архитектуре сжимает файлы перед их развертыванием в хранилище BLOB-объектов.Alternatively, the deploy pipeline in this reference architecture compresses the files before deploying them to the Blob storage. Это снижает потребность в хранилище и предоставляет большую свободу выбора средств сжатия, независимо от ограничений CDN.This reduces the storage requirement, and gives you more freedom to choose the compression tools, regardless of any CDN limitations.
  • CDN должна иметь возможность очищать свой кэш , чтобы гарантировать, что все пользователи будут обслуживать актуальное содержимое.The CDN should be able to purge its cache to ensure all users are served the freshest content. Очистка кэша необходима, если процессы сборки и развертывания не являются атомарными, например при замене старых файлов новыми, созданными в той же исходной папке.A cache purge is required if the build and deploy processes are not atomic, for example, if they replace old files with newly built ones in the same origin folder.
  • Другая стратегия кэширования, такая как управление версиями с помощью каталогов, может не требовать очистки от сети CDN.A different cache strategy such as versioning using directories, may not require a purge by the CDN. Конвейер сборки в этом интерфейсном приложении создает новый каталог для каждой новой построенной версии.The build pipeline in this front-end application creates a new directory for each newly built version. Эта версия передается как атомарная единица в хранилище BLOB-объектов.This version is uploaded as an atomic unit to the Blob storage. Azure CDN указывает на эту новую версию только после завершения развертывания.The Azure CDN points to this new version only after a completed deployment.
  • Увеличьте срок жизни кэша путем кэширования файлов ресурсов в течение более длительного периода, охватывающего месяцы.Increase the cache TTL by caching resource files for a longer duration, spanning months. Чтобы обеспечить обновление кэшированных файлов при их изменении, Отпечатайте пальцами имена файлов при их перестроении.To make sure the cached files are updated when they do change, fingerprint the filenames when they are rebuilt. Эти приложения на основе этих интерфейсов имеют отпечатки пальцев для всех файлов, кроме общедоступных файлов, таких как index.html.This front-end application fingerprints all files except for public-facing files such as index.html. Поскольку index.html обновляется часто, он отражает измененные имена файлов, вызвавшие обновление кэша.Since the index.html is updated frequently, it reflects the changed filenames causing a cache refresh. Дополнительные сведения см. в разделе Управление сроком действия веб-содержимого в Azure CDN .See the Manage expiration of web content in Azure CDN for more information.

Развертывание серверной частиBack-end deployment

Чтобы развернуть приложение-функцию, мы рекомендуем использовать файлы пакетов (команда "Запуск из пакета").To deploy the function app, we recommend using package files ("Run from package"). В рамках этого подхода вы загружаете ZIP-файл в контейнер хранилища BLOB-объектов, а среда выполнения Функций подключает ZIP-файл как файловую систему только для чтения.Using this approach, you upload a zip file to a Blob Storage container and the Functions runtime mounts the zip file as a read-only file system. Так как это атомарная операция, вероятность того, что в случае сбоя при развертывании приложение останется в несогласованном состоянии, является низкой.This is an atomic operation, which reduces the chance that a failed deployment will leave the application in an inconsistent state. Это также позволяет ускорить холодный запуск, особенно для приложений Node.js, так как все файлы меняются одновременно.It can also improve cold start times, especially for Node.js apps, because all of the files are swapped at once.

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

API — это контракт между службой и клиентами.An API is a contract between a service and clients. В этой архитектуре контракт API определяется на уровне службы управления API.In this architecture, the API contract is defined at the API Management layer. Управление API поддерживает два отдельных, но более дополняющих основных понятия управления версиями:API Management supports two distinct but complementary versioning concepts:

  • Версии позволяют объектам-получателям выбрать версию API в зависимости от потребностей, например версию 1 или 2.Versions allow API consumers to choose an API version based on their needs, such as v1 versus v2.

  • Редакции позволяют администраторам API вносить в API обратно совместимые изменения и развертывать их вместе с журналом изменений, который содержит сведения об изменениях для объектов-получателей.Revisions allow API administrators to make non-breaking changes in an API and deploy those changes, along with a change log to inform API consumers about the changes.

Если вы вносите критические изменения в API, опубликуйте новую версию в службе управления API.If you make a breaking change in an API, publish a new version in API Management. Разверните новую версию параллельно с исходной версией в отдельном приложении-функции.Deploy the new version side-by-side with the original version, in a separate Function App. Это позволяет перенести существующих клиентов в новый API без нарушения клиентских приложений.This lets you migrate existing clients to the new API without breaking client applications. В конце концов, вы сможете прекратить поддержку предыдущей версии.Eventually, you can deprecate the previous version. Служба управления API поддерживает несколько схем управления версиями: URL-путь, HTTP-заголовок или строка запроса.API Management supports several versioning schemes: URL path, HTTP header, or query string. См. дополнительные сведения об управлении версиями веб-API RESTful.For more information about API versioning in general, see Versioning a RESTful web API.

Для обновлений, не нарушающих изменения API, разверните новую версию в промежуточном слоте в том же приложении-функции.For updates that are not breaking API changes, deploy the new version to a staging slot in the same Function App. Убедитесь, что развертывание выполнено успешно, а затем замените промежуточную версию рабочей.Verify the deployment succeeded and then swap the staged version with the production version. Опубликуйте версию в службе управления API.Publish a revision in API Management.

Рекомендации по стоимостиCost considerations

Для оценки затрат используйте калькулятор цен Azure.Use the Azure pricing calculator to estimate costs. Рассмотрите эти моменты, чтобы оптимизировать затраты на эту архитектуру.Consider these points to optimize cost of this architecture.

Функции AzureAzure Functions

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

  • План потребления.Consumption plan.

    Мощность вычислений автоматически выделяется при выполнении кода.Compute power is automatically allocated when your code is running.

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

    Набор виртуальных машин выделяется для кода.A set of VMs are allocated for your code. Этот план определяет количество виртуальных машин и размер виртуальной машины.This plan defines the number of VMs and the VM size.

В этой архитектуре функция вызывается, когда клиент выполняет HTTP-запрос.In this architecture, a function is invoked when a client makes an HTTP request. Так как Постоянная пропускная способность большого объема не ожидается в этом варианте использования, рекомендуется использовать план потребления , так как вы платите только за используемые ресурсы вычислений.Because a constant high-volume throughput is not expected in this use case, consumption plan is recommended because you pay only for the compute resources you use.

Azure Cosmos DBAzure Cosmos DB

Azure Cosmos DB векселя на подготовленную пропускную способность и потребляемую память за час.Azure Cosmos DB bills for provisioned throughput and consumed storage by hour. Подготовленная пропускная способность выражается в единицах запросов в секунду, которые могут использоваться для типичных операций с базами данных, таких как операции вставки, чтения.Provisioned throughput is expressed in Request Units per second (RU/s), which can be used for typical database operations, such as inserts, reads. Цена зависит от емкости зарезервированных единиц запросов в секунду.The price is based on the capacity in RU/s that you reserve.

Плата за хранилище взимается за каждый ГБ, используемый для хранимых данных и индекса.Storage is billed for each GB used for your stored data and index.

Дополнительные сведения см. в разделе модель ценообразования Cosmos DB .See Cosmos DB pricing model for more information.

В этой архитектуре приложение-функция извлекает документы из Cosmos DB в ответ на HTTP-запросы GET от клиента.In this architecture, the function application fetches documents from Cosmos DB in response to HTTP GET requests from the client. В этом случае Cosmos DB экономичнее, так как операции чтения значительно дешевле, чем операции записи, выраженные в единицах запросов в секунду.Cosmos DB is cost effective in this case because reading operations are significantly cheaper than write operations expressed on RU/s.

Сеть доставки содержимого (CDN)Content Delivery Network

Ставка выставления счетов может отличаться в зависимости от региона выставления счетов на основе расположения исходного сервера, который доставляет содержимое конечному пользователю.Billing rate may differ depending on the billing region based on the location of the source server delivering the content to the end user. Физическое расположение клиента не является регионом выставления счетов.The physical location of the client is not the billing region. Любой запрос HTTP или HTTPS, который обращается к CDN, — это оплачиваемое событие, включающее все типы ответов: Success, Failure или other.Any HTTP or HTTPS request that hits the CDN is a billable event, which includes all response types: success, failure, or other. Различные ответы могут формировать разные объемы трафика.Different responses may generate different traffic amounts.

В этой эталонной архитектуре развертывание находится в одном регионе Azure.In this reference architecture the deployment resides in a single Azure region.

Чтобы снизить затраты, рассмотрите возможность увеличения срока жизни кэша путем кэширования файлов ресурсов в течение более длительного времени и установки максимально продолжительного срока жизни для содержимого.To lower costs, consider increasing the cache TTL by caching resource files for a longer duration and setting the longest TTL possible on your content.

Дополнительные сведения см. в разделе "затраты" в Microsoft Azure хорошо спроектированной инфраструктурой.For more information, see the Cost section in Microsoft Azure Well-Architected Framework.

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

Сведения о развертывании эталонной реализации для этой архитектуры см. в файле сведений GitHub.To deploy the reference implementation for this architecture, see the GitHub readme.

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

Дополнительные сведения о реализации эталонного кода см. в разделе Пошаговое руководство по использованию приложений с помощью функций Azure.To learn more about the reference implementation, read Code walkthrough: Serverless application with Azure Functions.

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