Azure 上以事件為基礎的雲端自動化Event-based cloud automation on Azure

使用 無伺服器技術將雲端上的工作流程和重複性工作自動化,可大幅提升組織 DevOps 團隊的生產力。Automating workflows and repetitive tasks on the cloud using serverless technologies, can dramatically improve productivity of an organization's DevOps team. 無伺服器模型最適合用於符合 事件驅動方法的自動化案例。A serverless model is best suited for automation scenarios that fit an event driven approach. 此參考架構說明兩個這類雲端自動化案例:This reference architecture illustrates two such cloud automation scenarios:

  1. 成本中心標記:此實行會追蹤每個 Azure 資源的成本中心。Cost center tagging: This implementation tracks the cost centers of each Azure resource. Azure 原則服務會標記具有預設成本中心識別碼的群組中的所有新資源The Azure Policy service tags all new resources in a group with a default cost center ID. 事件方格會監視資源建立事件,然後呼叫 Azure 函數The Event Grid monitors resource creation events, and then calls an Azure function. 函數會與 Azure Active Directory 互動,並驗證新資源的成本中心識別碼。The function interacts with Azure Active Directory, and validates the cost center ID for the new resource. 如果不同,則會更新標記,並將電子郵件傳送給資源擁有者。If different, it updates the tag and sends out an email to the resource owner. 為了簡單起見,Azure Active Directory 的 REST 查詢會模擬出來。The REST queries for Azure Active Directory are mocked out for simplicity. Azure AD 也可以使用 Azure AD PowerShell 模組適用于 Python 的 ADAL 程式庫來整合。Azure AD can also be integrated using the Azure AD PowerShell module or the ADAL for Python library.

  2. 節流回應:此實行會監視 Cosmos DB 資料庫以進行節流。Throttling response: This implementation monitors a Cosmos DB database for throttling. 當 CosmosDB 的資料存取要求超過要求單位 (或 ru) 的容量時,就會觸發Azure 監視器警示Azure Monitor alerts are triggered when data access requests to CosmosDB exceed the capacity in Request Units (or RUs). 已設定 Azure 監視器動作群組 ,以呼叫 automation 函式來回應這些警示。An Azure Monitor action group is configured to call the automation function in response to these alerts. 此函式會將 ru 調整為較高的值、增加容量,以及輪流停止警示。The function scales the RUs to a higher value, increasing the capacity and in turn stopping the alerts. 請注意, CosmosDB autopilot 模式 (Preview) 是此實作為的替代方案。Note that the CosmosDB autopilot mode (Preview) is an alternative to this implementation.

無伺服器雲端自動化

GitHub 標誌您 可在 github上取得此架構的參考實施。GitHub logo The reference implementations for this architecture are available on GitHub.

這些函式中的函式是使用 PowerShell 和 Python 撰寫的,這是自動化中最常見的兩種指令碼語言。The functions in these implementations are written in PowerShell and Python, two of the most common scripting languages used in automation. 它們是使用 Azure Functions Core Tools 在 Azure CLI 中部署。They are deployed using Azure Functions Core Tools in Azure CLI. 或者,您可以嘗試使用預覽版本的 PowerShell Cmdlet 來部署和管理 Azure FunctionsAlternatively, you can try a preview version of PowerShell cmdlet to deploy and manage Azure Functions.

以事件為基礎的自動化模式Patterns in event-based automation

以事件為基礎的自動化案例最好使用 Azure Functions 來執行。Event-based automation scenarios are best implemented using Azure Functions. 它們會遵循下列常見的模式:They follow these common patterns:

  • 回應資源上的事件Respond to events on resources. 這些是事件的回應,例如 Azure 資源或資源群組的建立、刪除、變更等等。These are responses to events such as an Azure resource or resource group getting created, deleted, changed, and so on. 此模式會使用 事件方格 來觸發這類事件的函式。This pattern uses Event Grid to trigger the function for such events. 成本中心標記實作為此模式的範例。The cost center tagging implementation is an example of this pattern. 其他常見案例包括:Other common scenarios include:

    • 將新建立的資源群組的存取權授與 DevOps 小組granting the DevOps teams access to newly created resource groups,
    • 在刪除資源時將通知傳送至 DevOps,以及sending notification to the DevOps when a resource is deleted, and
    • 回應資源的維護事件,例如 (Vm) 的 Azure 虛擬機器。responding to maintenance events for resources such as Azure Virtual Machines (VMs).
  • 排定的工作。Scheduled tasks. 這些通常是使用 計時器觸發的函式執行的維護工作。These are typically maintenance tasks executed using timer-triggered functions. 這種模式的範例包括:Examples of this pattern are:

    • 在夜間停止 VM,並從早上早上開始stopping a VM at night, and starting in the morning,
    • 定期讀取 Blob 儲存體內容,並轉換為 Cosmos DB 檔reading Blob Storage content at regular intervals, and converting to a Cosmos DB document,
    • 定期掃描不再使用的資源,並將其移除,以及periodically scanning for resources no longer in use, and removing them, and
    • 自動備份。automated backups.
  • 處理 Azure 警示Process Azure alerts. 此模式會利用 Azure Functions 輕鬆整合 Azure 監視器警示和動作群組。This pattern leverages the ease of integrating Azure Monitor alerts and action groups with Azure Functions. 此函式通常會採取補救動作,以回應來自應用程式和基礎結構的計量、記錄分析和警示。The function typically takes remedial actions in response to metrics, log analytics, and alerts originating in the applications as well as the infrastructure. 節流回應的實作為此模式的範例。The throttling response implementation is an example of this pattern. 其他常見案例如下:Other common scenarios are:

    • 當 SQL Database 達到大小上限時,截斷資料表truncating the table when SQL Database reaches maximum size,
    • 當 VM 錯誤地停止時,重新開機 VM 中的服務,以及restarting a service in a VM when it is erroneously stopped, and
    • 在函式失敗時傳送通知。sending notifications if a function is failing.
  • 與外部系統協調Orchestrate with external systems. 此模式可讓您使用 Logic Apps 來協調工作流程,以便與外部系統整合。This pattern enables integration with external systems, using Logic Apps to orchestrate the workflow. Logic Apps 連接器 可以輕鬆地與數個協力廠商服務和 Microsoft 服務(例如 Microsoft 365)整合。Logic Apps connectors can easily integrate with several third-party services as well as Microsoft services such as Microsoft 365. Azure Functions 可用於實際的自動化。Azure Functions can be used for the actual automation. 成本中心標記實行會示範這個模式。The cost center tagging implementation demonstrates this pattern. 其他常見案例包括:Other common scenarios include:

    • 監視 IT 進程(例如變更要求或核准),以及monitoring IT processes such as change requests or approvals, and
    • 在自動化工作完成時傳送電子郵件通知。sending email notification when automation task is completed.
  • 公開為 web 攔截或 APIExpose as a web hook or API. 使用 Azure Functions 的自動化工作可以整合到協力廠商應用程式,甚至是命令列工具,其方式是使用 HTTP 觸發程式將函式公開為 web 攔截/API。Automation tasks using Azure Functions can be integrated into third-party applications or even command-line tools, by exposing the function as a web hook/API using an HTTP trigger. PowerShell 和 Python 都可使用多個驗證方法來保護對函式的外部存取。Multiple authentication methods are available in both PowerShell and Python to secure external access to the function. 自動化會因應用程式特定的外來事件而發生,例如,與 power apps 或 GitHub 整合。The automation happens in response to the app-specific external events, for example, integration with power apps or GitHub. 常見案例包括:Common scenarios include:

    • 觸發失敗服務的自動化,以及triggering automation for a failing service, and
    • 將使用者上架到組織的資源。onboarding users to the organization's resources.
  • 建立 ChatOps 介面Create ChatOps interface. 這種模式可讓客戶建立聊天型操作介面,並以人為共同作業的方式執行開發和操作功能和命令。This pattern enables customers to create a chat-based operational interface, and run development and operations functions and commands in-line with human collaboration. 這可以與 Azure Bot Framework 整合,並使用 Microsoft 小組或使用時間的命令來部署、監視、常見問題等等。This can integrate with the Azure Bot Framework and use Microsoft Teams or Slack commands for deployment, monitoring, common questions, and so on. ChatOps 介面會建立即時系統來管理生產事件,每個步驟都會自動記載于聊天上。A ChatOps interface creates a real-time system for managing production incidents, with each step documented automatically on the chat. 閱讀 ChatOps 如何協助您更深入地 DevOps ,以取得詳細資訊。Read How ChatOps can help you DevOps better for more information.

  • 混合式自動化Hybrid automation. 此模式會使用 Azure App Service 的混合 式連線,在您的本機電腦上安裝軟體元件。This pattern uses the Azure App Service Hybrid Connections to install a software component on your local machine. 此元件可讓您安全地存取該電腦上的資源。This component allows secure access to resources on that machine. 使用 PowerShell 函式的 Windows 系統目前提供 管理混合式環境 的能力。The ability to manage hybrid environments is currently available on Windows-based systems using PowerShell functions. 常見案例包括:Common scenarios include:

    • 管理您的內部部署機器,以及managing your on-premises machines, and
    • 管理防火牆後方的其他系統 (例如,透過 跳躍式伺服器的內部部署 SQL Server) 。managing other systems behind the firewall (for example, an on-premises SQL Server) through a jump server.

架構Architecture

此架構包含下列區塊:The architecture consists of the following blocks:

Azure FunctionsAzure Functions. Azure Functions 在此架構中提供事件驅動的無伺服器計算功能。Azure Functions provide the event-driven, serverless compute capabilities in this architecture. 當事件或警示觸發函式時,函式會執行自動化工作。A function performs automation tasks, when triggered by events or alerts. 在參考的執行中,會使用 HTTP 要求來叫用函數。In the reference implementations, a function is invoked with an HTTP request. 您可以藉由開發 無狀態的函式和 等冪,將程式碼複雜度降至最低。Code complexity should be minimized, by developing the function that is stateless, and idempotent.

等冪函式的多個執行會建立相同的結果。Multiple executions of an idempotent function create the same results. 為了維護等冪性,節流案例中的函式調整會保持簡單。To maintain idempotency, the function scaling in the throttling scenario is kept simplistic. 在真實世界的自動化中,請務必適當地相應增加或相應減少。In real world automation, make sure to scale up or down appropriately.

請參閱 優化 Azure Functions 的效能和可靠性 ,以取得撰寫函數時的最佳做法。Read the Optimize the performance and reliability of Azure Functions for best practices when writing your functions.

Logic AppsLogic Apps. Logic Apps 可以用來執行更簡單的工作,使用 內建的連接器輕鬆地執行。Logic Apps can be used to perform simpler tasks, easily implemented using the built-in connectors. 這些工作的範圍可從電子郵件通知,到與外部管理應用程式整合。These tasks can range from email notifications, to integrating with external management applications. 若要瞭解如何搭配協力廠商應用程式使用 Logic Apps,請參閱 Azure 中的基本企業整合To learn how to use Logic Apps with third-party applications, read basic enterprise integration in Azure.

Logic Apps 不提供程式 代碼較低 的程式碼視覺化設計工具,可單獨用於某些自動化案例中。Logic Apps provides a no code or low code visual designer, and may be used alone in some automation scenarios. 請閱讀 Azure Functions 與 Logic Apps 之間的這種比較 ,以查看哪一個服務可符合您的案例。Read this comparison between Azure Functions and Logic Apps to see which service can fit your scenario.

事件方格Event Grid. 事件方格內建支援來自其他 Azure 服務的事件,以及自訂事件 (也稱為 自訂主題) 。Event Grid has built-in support for events from other Azure services, as well as custom events (also called custom topics). 使用事件方格的內建機制,可輕鬆地將作業事件(例如資源建立)傳播至 automation 函式。Operational events such as resource creation can be easily propagated to the automation function, using the Event Grid's built-in mechanism.

事件方格利用 發行-訂閱模型簡化了事件型自動化,讓透過 HTTP 傳遞的事件可提供可靠的自動化。Event Grid simplifies the event-based automation with a publish-subscribe model, allowing reliable automation for events delivered over HTTP.

Azure 監視器Azure Monitor. Azure 監視器警示可以監視重大狀況,並使用 Azure 監視器動作群組來採取矯正措施。Azure Monitor alerts can monitor for critical conditions, and take corrective action using Azure Monitor action groups. 這些動作群組很容易與 Azure Functions 整合。These action groups are easily integrated with Azure Functions. 這有助於監看並修正基礎結構中的任何錯誤狀況,例如資料庫節流。This is useful to watch for and fix any error conditions in your infrastructure, such as database throttling.

自動化動作Automation action. 這個廣泛的區塊代表您的函式可以與之互動的其他服務,以提供自動化功能。This broad block represents other services that your function can interact with, to provide the automation functionality. 例如,在第一個案例中,針對標記驗證 Azure Active Directory,或在第二個案例中布建的資料庫。For example, Azure Active Directory for tag validation as in the first scenario, or a database to provision as in the second scenario.

恢復功能考量Resiliency considerations

Azure FunctionsAzure Functions

處理 HTTP 超時Handle HTTP timeouts

若要避免較長自動化工作的 HTTP 超時,請在 服務匯流排中將此事件排入佇列,並在另一個函式中處理實際的自動化功能。To avoid HTTP timeouts for a longer automation task, queue this event in a Service Bus, and handle the actual automation in another function. 節流回應自動化案例會說明此模式,即使實際的 Cosmos DB RU 布建很快也是一樣。The throttling response automation scenario illustrates this pattern, even though the actual Cosmos DB RU provisioning is fast.

Automation 函數中的可靠性

保留調用之間狀態的長期函式,可提供上述方法的替代方法。Durable functions, which maintain state between invocations, provide an alternative to the above approach. 目前只有在 JavaScript 和 c # 中才支援這些功能。These are currently supported only in JavaScript and C#.

記錄失敗Log failures

最佳做法是,函式應記錄執行自動化工作的任何失敗。As a best practice, the function should log any failures in carrying out automation tasks. 這可讓您適當地針對錯誤狀況進行疑難排解。This allows for proper troubleshooting of the error conditions. 參考會使用 Application Insights 作為遙測系統。The reference implementations use the Application Insights as the telemetry system.

並行Concurrency

確認 automation 函數的並行需求。Verify the concurrency requirement for your automation function. 平行存取的限制是在檔案 maxConcurrentRequests host.js中設定變數。Concurrency is limited by setting the variable maxConcurrentRequests in the file host.json. 這項設定會限制在函數應用程式中執行的並行函式實例數目。This setting limits the number of concurrent function instances running in your function app. 由於每個實例都會耗用 CPU 和記憶體,因此必須針對需要大量 CPU 的作業調整此值。Since every instance consumes CPU and memory, this value needs to be adjusted for CPU-intensive operations. maxConcurrentRequests如果您的函數呼叫似乎太慢或無法完成,請降低。Lower the maxConcurrentRequests if your function calls appear to be too slow or aren't able to complete. 如需更多詳細資料,請參閱 設定主機行為以更妥善地處理並行 存取。See the section Configure host behaviors to better handle concurrency for more details.

等冪Idempotency

請確定您的自動化函式為等冪。Make sure your automation function is idempotent. Azure 監視器和 Event Grid 都可能發出警示或事件,指出進度(例如您的訂閱事件已 解決、已 引發、正在 進行中等等)、您的資源正在布 建立成功等,甚至是因為設定錯誤而傳送錯誤警示。Both Azure Monitor and Event Grid may emit alerts or events that indicate progression such as your subscribed event is resolved, fired, in progress, etc., your resource is being provisioned, created successfully, etc., or even send false alerts due to a misconfiguration. 請確定您的函式僅適用于相關的警示和事件,並忽略所有其他事件,使錯誤或設定錯誤的事件不會造成不必要的結果。Make sure your function acts only on the relevant alerts and events, and ignores all others, so that false or misconfigured events do not cause unwanted results. 如需詳細資訊,請閱讀 這篇有關等冪性模式的 blog 文章For more information, read this blog post on idempotency patterns.

事件方格Event Grid

如果您的工作流程使用事件方格,請檢查您的案例是否可能產生大量事件,足以堵塞方格。If your workflow uses Event Grid, check if your scenario could generate a high volume of events, enough to clog the grid. 請參閱 事件方格訊息傳遞,然後重試 以瞭解在未認可傳遞時如何處理事件,並據以修改您的邏輯。See Event Grid message delivery and retry to understand how it handles events when delivery isn't acknowledged, and modify your logic accordingly. 因為它只會監看資源群組中的資源建立事件,所以成本中心工作流程不會為此執行額外的檢查。The cost center workflow does not implement additional checks for this, since it only watches for resource creation events in a resource group. 監視整個訂用帳戶中建立的資源,可能會產生更大量的事件,需要更具復原性的處理。Monitoring resources created in an entire subscription, can generate larger number of events, requiring a more resilient handling.

Azure 監視器Azure Monitor

如果產生足夠大量的警示,且自動化會更新 Azure 資源,則可能會達到 Azure Resource Manager 的節流限制If a sufficiently large number of alerts are generated, and the automation updates Azure resources, throttling limits of the Azure Resource Manager might be reached. 這可能會對該訂用帳戶中的其餘基礎結構造成負面影響。This can negatively affect the rest of the infrastructure in that subscription. 藉由限制 Azure 監視器產生的警示 頻率 來避免這種情況。Avoid this situation by limiting the frequency of alerts getting generated by the Azure Monitor. 您也可以限制針對特定錯誤產生的警示。You may also limit the alerts getting generated for a particular error. 如需詳細資訊,請參閱 Azure 監視器警示的相關檔Refer to the documentation on Azure Monitor alerts for more information.

安全性考量Security considerations

控制函數的存取權Control access to the function

藉由設定 授權等級來限制對 HTTP 觸發函式的存取。Restrict access to an HTTP-triggered function by setting the authorization level. 使用 匿名 驗證時,您可以輕鬆地使用 URL (例如)來存取函數 http://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>With anonymous authentication, the function is easily accessible with a URL such as http://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>. 函數 層級驗證可以透過要求 URL 中的函式索引鍵來模糊化 HTTP 端點。Function level authentication can obfuscate the http endpoint, by requiring function keys in the URL. 此層級是在檔案 function.js中設定:This level is set in the file function.json:

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "Request",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "Response"
    }
  ]
}

在生產環境中,可能需要額外的策略來保護函式。For production environment, additional strategies might be required to secure the function. 在參考的執行中,函式會由其他 Azure 服務在 Azure 平臺內執行,且不會向網際網路公開。In the reference implementations, the functions are executed within the Azure platform by other Azure services, and will not be exposed to the internet. 函數授權已足夠用於以 webhook 形式存取的函式。Function authorization is sufficient for functions accessed as web hooks.

考慮在函式驗證之上新增安全性層級,例如Consider adding security layers on top of function authentication, such as,

  • 使用用戶端憑證進行驗證,或authenticating with client certificates, or
  • 使用 簡單的驗證整合,確定呼叫端屬於或可存取裝載函式的目錄。making sure the caller is part of or has access to the directory that hosts the function, by using Easy Auth integration.

請注意,函式層級驗證是 Azure 監視器動作群組唯一可用的選項。Note that function-level authentication is the only option available to Azure Monitor action groups.

如果需要從協力廠商應用程式或服務呼叫函式,則建議使用 API 管理 層來提供其存取權。If the function needs to be called from a third-party application or service, it is recommended to provide access to it with an API Management layer. 這一層應強制執行驗證。This layer should enforce authentication. API 管理現在具有與 Azure Functions 整合的 耗用量層 ,可讓您只在執行 API 時支付費用。API Management now has a consumption tier integrated with Azure Functions, which allows you to pay only if the API gets executed. 如需詳細資訊,請參閱 使用 OpenAPI 建立及公開您的函式。For more information, read Create and expose your functions with OpenAPI.

如果呼叫服務支援服務端點,則可以考慮下列越大選項:If the calling service supports service endpoints, the following costlier options could be considered:

  • 您可以使用專用的 App Service 方案,在其中鎖定虛擬網路中的函式來限制其存取。Use a dedicated App Service plan, where you can lock down the functions in a virtual network to limit access to it. 這在以耗用量為基礎的無伺服器模型中無法這麼做。This is not possible in a consumption-based serverless model.
  • 使用 Azure Functions Premium 方案,其中包含您的函式應用程式所要使用的專用虛擬網路。Use the Azure Functions Premium plan, which includes a dedicated virtual network to be used by your function apps.

若要比較這些選項之間的定價和功能,請參閱 Azure Functions 規模和裝載To compare pricing and features between these options, read Azure Functions scale and hosting.

控制函數可存取的內容Control what the function can access

適用于 Azure 資源的受控識別(Azure Active Directory 功能)可簡化函式驗證及存取其他 Azure 資源和服務的方式。Managed identities for Azure resources, an Azure Active Directory feature, simplifies how the function authenticates and accesses other Azure resources and services. 此程式碼不需要管理驗證認證,因為它是由 Azure AD 管理。The code does not need to manage the authentication credentials, since it is managed by Azure AD.

受控身分識別有兩種:There are two types of managed identities:

  • 系統指派的受控識別:這些識別會建立為 Azure 資源的一部分,而且無法在多個資源之間共用。System-assigned managed identities: These are created as part of the Azure resource, and cannot be shared among multiple resources. 刪除資源時就會刪除這些資源。These get deleted when the resource is deleted. 在涉及單一 Azure 資源或需要獨立身分識別的案例中使用這些案例。Use these for scenarios, which involve single Azure resource or which need independent identities. 這兩個參考會使用系統指派的身分識別,因為它們只會更新單一資源。Both the reference implementations use system-assigned identities since they update only a single resource. 受控識別只需要更新其他資源。Managed identities are only required to update another resource. 例如,函式可以讀取沒有受控識別的資源標記。For example, a function can read the resource tags without a managed identity. 請參閱 下列指示 ,以將系統指派的身分識別新增至您的函式。See these instructions to add a system-assigned identity to your function.

  • 使用者指派的受控識別:這些識別會建立為獨立的 Azure 資源。User-assigned managed identities: These are created as stand-alone Azure resources. 這些資源可以在多個資源之間共用,而且需要明確刪除。These can be shared across multiple resources, and need to be explicitly deleted. 請參閱 下列指示 ,以瞭解如何將使用者指派的身分識別新增至您的函式。Read these instructions on how to add user-assigned identity to your function. 在下列案例中使用這些:Use these for scenarios that:

    • 需要存取可共用單一身分識別的多個資源,或Require access to multiple resources that can share a single identity, or
    • 在布建期間需要預先授權才能保護資源,或Need pre-authorization to secure resources during provisioning, or
    • 具有經常回收的資源,而許可權需要一致。Have resources that are recycled frequently, while permissions need to be consistent.

一旦將身分識別指派給 Azure 函式,請使用 角色型存取控制 將角色指派給它, (RBAC) 來存取資源。Once the identity is assigned to the Azure function, assign it a role using role-based access control (RBAC) to access the resources. 例如,若要更新資源,必須將 參與者 角色指派給函式身分識別。For example, to update a resource, the Contributor role will need to be assigned to the function identity.

成本考量Cost considerations

使用 Azure 定價計算機來估計成本。Use the Azure pricing calculator to estimate costs. 以下是降低成本的一些考慮。Here are some considerations for lowering cost.

Azure Logic AppsAzure Logic Apps

邏輯應用程式具有隨用隨付定價模型。Logic apps have a pay-as-you-go pricing model. 每次邏輯應用程式執行時,都會計量觸發程式、動作和連接器的執行次數。Triggers, actions, and connector executions are metered each time a logic app runs. 所有成功和不成功的動作(包括觸發程式)都會視為執行。All successful and unsuccessful actions, including triggers, are considered as executions.

邏輯應用程式也有固定的定價模型。Logic apps have also a fixed pricing model. 如果您需要執行與 Azure 虛擬網路中安全資源通訊的邏輯應用程式,您可以在整合服務環境中建立它們, (ISE) If you need to run logic apps that communicate with secured resources in an Azure virtual network, you can create them in an Integration Service Environment (ISE).

如需詳細資訊,請參閱 Azure Logic Apps 的定價模型For details, see Pricing model for Azure Logic Apps.

在此架構中,會在成本中心標記案例中使用邏輯應用程式來協調工作流程。In this architecture, logic apps are used in the cost center tagging scenario to orchestrate the workflow.

內建連接器是用來連接到 Azure Functions,並在自動化工作完成時傳送電子郵件通知。Built-in connectors are used to connect to Azure Functions and send email notification an when an automation task is completed. 這些函式會使用 HTTP 觸發程式公開為 web 攔截/API。The functions are exposed as a web hook/API using an HTTP trigger. 只有在發生 HTTPS 要求時,才會觸發邏輯應用程式。Logic apps are triggered only when an HTTPS request occurs. 相較于設計,函式會持續輪詢和檢查特定準則,這是符合成本效益的方式。This is a cost effective way when compared to a design where functions continuously poll and check for certain criteria. 每個輪詢要求都會計量為一個動作。Every polling request is metered as an action.

如需詳細資訊,請參閱 Logic Apps 定價For more information, see Logic Apps pricing.

Azure FunctionsAzure Functions

下列三個定價方案有提供 Azure Functions。Azure Functions are available with the following three pricing plans.

  • 使用量方案Consumption plan. 這是最符合成本效益的無伺服器方案,您只需針對函式執行的時間付費。This is the most cost-effective, serverless plan available, where you only pay for the time your function runs. 在此方案中,函式一次最多可以執行10分鐘。Under this plan, functions can run for up to 10 minutes at a time.

  • Premium 方案Premium plan. 請考慮將 Azure Functions Premium 方案用於具有額外需求的自動化案例,例如專用的虛擬網路、較長的執行持續時間等等。Consider using Azure Functions Premium plan for automation scenarios with additional requirements, such as a dedicated virtual network, a longer execution duration, and so on. 這些函式最多可執行一小時,而且應針對較長的自動化工作(例如執行備份、資料庫索引編制或產生報表)選擇。These functions can run for up to an hour, and should be chosen for longer automation tasks such as running backups, database indexing, or generating reports.

  • App Service 方案App Service plan. 使用 Azure App Service 混合式連線的混合式自動化案例將需要使用 App Service 方案。Hybrid automation scenarios that use the Azure App Service Hybrid Connections, will need to use the App Service plan. 在此方案下建立的函式可以執行無限持續時間,類似于 web 應用程式。The functions created under this plan can run for unlimited duration, similar to a web app.

在此架構中 Azure Functions 用於在 Azure Active Directory 中更新標記的工作,或藉由將 ru 向上擴充為較高的值來變更 cosmos DB 設定。In this architecture Azure Functions are used for tasks such as updating tags in Azure Active Directory, or changing cosmos DB configuration by scaling up the RUs to a higher value. 取用 方案 適用于此使用案例,因為這些工作是互動式的,而不是在進行中。The Consumption plan is the appropriate for this use case because those tasks are interactive and not on going.

Azure Cosmos DBAzure Cosmos DB

針對布建的輸送量和每小時使用的儲存體,Azure Cosmos DB 帳單。Azure Cosmos DB bills for provisioned throughput and consumed storage by hour. 布建的輸送量會以每秒的要求單位表示 (RU/秒) ,可用於一般的資料庫作業,例如插入、讀取。Provisioned throughput is expressed in Request Units per second (RU/s), which can be used for typical database operations, such as inserts, reads. 儲存體會針對您儲存的資料和索引所使用的每 GB 進行計費。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 的資料存取要求超過要求單位 (或 ru) 的容量時,Azure 監視器會觸發警示。In this architecture, when data access requests to Cosmos DB exceed the capacity in Request Units (or RUs), Azure Monitor triggers alerts. 為了回應這些警示,會將 Azure 監視器動作群組設定為呼叫 automation 函數。In response to those alerts, an Azure Monitor action group is configured to call the automation function. 函數會將 ru 調整為較高的值。The function scales the RUs to a higher value. 這有助於降低成本,因為您只需支付工作負載所需的資源(以每小時為基礎)。This helps to keep the cost down because you only pay for the resources that your workloads need on a per-hour basis.

若要取得工作負載的快速預估成本,請使用 Cosmos DB 容量計算機To get a quick cost estimate of your workload, use the Cosmos DB capacity calculator.

如需詳細資訊,請參閱 Microsoft Azure 架構良好的架構中的「成本」一節。For more information, see the Cost section in Microsoft Azure Well-Architected Framework.

部署考量因素Deployment considerations

對於管理應用程式行為的關鍵自動化工作流程,必須使用有效率的 DevOps 管線來達成零停機部署。For critical automation workflows that manage behavior of your application, zero downtime deployment must be achieved using an efficient DevOps pipeline. 如需詳細資訊,請參閱 無伺服器後端部署For more information, read serverless backend deployment.

如果自動化涵蓋多個應用程式,請將自動化所需的資源保留在 個別的資源群組中。If the automation covers multiple applications, keep the resources required by the automation in a separate resource group. 如果自動化涵蓋單一應用程式,則可以在自動化和應用程式資源之間共用單一資源群組。A single resource group can be shared between automation and application resources, if the automation covers a single application.

如果工作流程牽涉到許多自動化函式,請將這些函式在單一函式應用程式中,以一種案例來分組。If the workflow involves a number of automation functions, group the functions catering to one scenario in a single function app. 如需詳細資訊,請參閱 管理函數應用程式Read Manage function app for more information.

當您部署應用程式時,您將需要監視它。As you deploy your application you will need to monitor it. 請考慮使用 Application Insights ,讓開發人員監視效能及偵測問題。Consider using Application Insights to enable the developers to monitor performance and detect issues.

如需詳細資訊,請參閱 Microsoft Azure 架構良好架構中的 DevOps 一節。For more information, see the DevOps section in Microsoft Azure Well-Architected Framework.

部署解決方案Deploy the solution

若要部署此架構的參考執行,請參閱 GitHub 上的部署步驟 以取得所需的工作流程。To deploy the reference implementations for this architecture, see the deployment steps on GitHub for the desired workflow.

後續步驟Next steps

深入瞭解 無伺服器的執行。Learn more about the serverless implementations.