十、在 Azure 无服务器环境下使用 .NET Core

Azure 函数是利用各种触发器(包括 HTTP 请求)的无服务器计算模块。 通过使用 Azure 功能，开发人员可以创建业务逻辑容器，完全摆脱单一 web 应用范例和基础设施带来的问题。 它们可以用作简单的 HTTP 请求处理单元和所谓的微服务，也可以用于编排复杂的工作流。 Azure 函数有两种风格(编译型和基于脚本的)，可以用不同的语言编写，包括带有。NET Core 模块的 c#。

在本章中，您将有机会使用 Azure 函数的不同运行时，并了解 Azure 无服务器的可用配置、触发器和托管选项。 然后我们将把 Azure 功能合并到我们的基础设施中，这样我们就可以处理不同触发器上的数据。 然后，我们将把 Azure 的功能与一个逻辑应用集成在一起，它将在我们的设置中用作一个处理单元。

本章将涵盖以下主题:

  • 理解 Azure Serverless
  • 实现 Azure 功能
  • 创建逻辑应用
  • 将 Azure 服务与功能集成

在本章结束时，您将更多地了解 Azure 函数和逻辑应用的基本概念。 您将能够将 Azure 无服务器组件集成到您的云基础设施中，并根据您的需求实现功能。 换句话说，您将能够在您的下一个基于云的项目中，自信地为您的特殊需求设置 Azure 功能和逻辑应用。

了解 Azure 无服务器

在云平台上开发分布式系统有它的优点，也有它的缺点，例如，当您管理的数据分散在多个进程上时，复杂性会越来越大。 发现自己处于死锁的情况是非常常见的，在这种情况下，为了降低引入新特性的成本，您不得不在架构需求上做出妥协。 Azure 无服务器组件可以通过其简单的事件驱动计算经验为特殊需求提供灵活的解决方案。

在第八章,【5】创建一个数据存储与宇宙 DB,我们创建了一个文档结构库,后来,在【显示】第 9 章,【病人】创建 Microservices Azure 应用服务,我们实现了 ASP.NET Core 服务作为容器化的微服务，这样我们就可以涵盖我们的主要应用用例。 可以将这些用例视为通过应用的主要数据流，我们对性能的主要关注集中在这些数据路径上。 然而,第二个用例,如跟踪状态的拍卖的用户,他们曾参与,或创建一个提要通知用户有关新车拍卖,的功能,可以增加用户的回报率和维护用户群。 因此，我们需要一个坚定的、事件驱动的策略，它不会干扰主要功能，并且应该能够在不干扰基础设施的情况下伸缩。

简而言之，Azure 功能和其他 Azure 无服务器组件是为这些类型的事件驱动场景量身定制的 Azure 产品，在这些场景中需要协调一个或多个 Azure 基础设施服务。

开发 Azure 功能

Azure 功能，作为 Azure 无服务器生态系统中最早的成员之一，为开发语言和 sdk 提供了多种选择，欢迎来自不同平台的开发人员。 在本节中，我们将了解开发选项和功能集成选项。 我们最终将实现一个示例 Azure 函数，使用来自 Cosmos DB 数据库中不同文档存储的数据创建一个物化视图。

开发环境中用于开发 Azure 功能的可用选项包括但不限于以下选项:

  • 使用 Azure 门户
  • 使用 Azure CLI 和 Azure 功能的核心工具
  • 使用 Visual Studio 或 Visual Studio 代码
  • 使用其他 ide，如 Eclipse 或 IntelliJ IDEA

至于语言和运行时，我们可以用以下方法创建函数:

  • Java/Maven
  • Python
  • c#(.NET Core 和脚本)
  • JavaScript/Node
  • f#(。 净核心)

如您所见，可以使用多个平台和多个开发环境组合来创建 Azure 功能。 这意味着任何操作系统，包括 Windows、macOS 和 Linux，都可以用作开发站。 在接下来的部分中，我们将尝试使用这些平台和工具中的一些来开发 Azure 函数，以展示 Azure 函数的通用性。

使用 Azure 函数运行时

我们将从可用的 Azure 功能选项开始我们的旅程。 在本演示中，我们将首先使用 Python 创建一个 Azure 函数，只使用一个简单的文本处理程序，然后继续在。net 和 c#上执行同样的操作。

闲话少说，让我们从使用 macOS 的跨平台开发工具集开始，通过使用 Azure functions Core Tools 创建我们的示例函数:

  1. 为了安装平台运行时，我们将首先注册azure/functions存储库:

    brew tap azure/functions

  2. Once the azure/functions repository has been registered, continue with the installation of Azure Functions Core Tools:

    brew install azure-functions-core-tools

    安装应该不会花费很长时间，您应该会看到类似这样的输出:

    Figure 10.1 – Installing Azure Functions Core Tools

    图 10.1 -安装 Azure 功能核心工具

    安装完成后，我们可以继续开发示例函数。 为了演示函数，我们将创建一个简单的计算器函数(即x + y = z)。

  3. 接下来，初始化一个虚拟工作环境以从 Python 开发开始:

    $ python3 -V Python 3.6.4 $ python3 -m venv .env $ ls .env $ source .env/bin/activate (.env) $

  4. 创建并激活环境之后，使用以下命令初始化函数项目。 出现提示时，选择python作为运行时:

  5. 创建项目之后，创建一个名为add的新函数。 提示时，选择HTTP trigger作为模板:

    (.env) $ cd myazurefunctions/ (.env) $ func new Select a template: 1\. Azure Blob Storage trigger ... 9\. Timer trigger Choose option: 5 HTTP trigger Function name: [HttpTrigger] add

  6. Now that the function has been created, you can use any editor to edit the __init__.py file in order to implement the function, as follows:

    Figure 10.2 – Azure Function in Python

    图 10.2 - Python 中的 Azure 函数

  7. 为了测试我们的函数，在项目目录中，执行以下命令，它将启动本地函数服务器:

    func host start

  8. 一旦函数服务器运行，就在终端窗口上显示的给定端口上执行get查询。 这会触发 HTTP 请求并返回结果:

    curl 'http://localhost:7071/api/add?x=5&y=8' Addition result is 13

我们现在已经成功地使用 Python 和 HTTP 触发器模板创建了一个 Azure 函数。

如果在创建步骤中，我们让选择了第一个选项，也就是dotnet，那么这个项目将使用编译过的 c#函数模板创建:

$ func init myazurefunctions
Select a worker runtime: 
1\. dotnet
2\. node
3\. python
Choose option: 1
dotnet
$ cd myazurefunctions
$ func new
Select a template: 
1\. QueueTrigger
2\. HttpTrigger
...
12\. IotHubTrigger
Choose option: 2
Function name: add
$ nano add.cs
$ func host start

我们的add函数的源代码看起来类似如下:

Figure 10.3 – Azure Function in C#

图 10.3 - c#中的 Azure 函数

当然，虽然这只适用于演示的目的，但使用 Visual Studio(针对 macOS 和 Windows)以及 Visual Studio Code 进行开发将提供真实的. net 开发环境。

在本部分中，我们已经成功地在 Python 和。net 上创建了一个 http 触发函数。 在此过程中，作为一个开发环境，我们使用了一个简单的文本编辑器和 Azure CLI 来演示 Azure 功能开发的简单性。 在下一节中，我们将深入了解可用于函数的其他触发器，并了解绑定是如何工作的。

函数触发器和绑定

函数项目和我们在前一节中创建的函数，尽管它们是在完全独立的运行时上实现和执行的，但是携带函数的表现遵循相同的模式(即function.json)。 虽然 Python 实现的清单可以在与函数同名的文件夹中找到，但 dotnet 版本只能在编译时从实现中使用的属性中生成(可以在bin/output/<function>文件夹中找到)。 比较这两个清单，我们可以立即识别出为这些函数定义输入、输出和触发机制的各个部分:

Figure 10.4 – Azure Function bindings

图 10.4 - Azure 函数绑定

正如前面提到的，Azure 函数是事件驱动的 Azure 资源。 触发器机制不仅定义函数何时执行，还定义输入和输出数据类型和/或连接的服务。 例如，一个 blob 存储条目可以用作触发器，也可以用作输入和输出。

类似地，HttpTrigger可以定义执行方法以及输入和输出机制(如前面的示例所示)。 这样，额外的服务集成就可以作为声明性属性而不是功能性实现包含在函数中。

其中一些绑定类型如下:

Figure 10.5 – Available Azure Binding Options

图 10.5 -可用的 Azure 绑定选项

除了之外，还有其他扩展可以通过 Azure Functions Core Tools 或 NuGet 包获得，默认情况下，只有定时器和 HTTP 扩展会在函数运行时中注册。

如您所见，Azure Function 绑定提供了一种非常简单的清单方法来将函数与来自不同资源的各种事件集成在一起。 然而，清单可能不足以配置我们的事件驱动函数; 我们需要一个合适的配置设施。

功能配置

Azure 函数使用与 ASP 相同的配置基础设施.NET Core 应用，因此使用了Microsoft.Extensions.Configuration模块。

在开发期间，当应用在本地运行时上运行时，为了从local.settings.json文件读取配置值，需要创建一个配置构建器并使用AddJsonFile扩展方法。 创建配置实例后，可以通过配置实例的 indexer 属性访问配置值和连接字符串。

在部署到 Azure 基础设施的过程中，设置文件被用作模板，用于创建将通过 Azure 门户和资源管理器进行管理的应用设置。 也可以使用相同的原则访问这些值，但它们是作为环境变量添加的。

为了支持这两种场景，我们可以使用在创建配置实例时可用的扩展方法:

var config = new ConfigurationBuilder()
                .SetBasePath(context.FunctionAppDirectory)
                .AddJsonFile("local.settings.json", optional: true, 
 reloadOnChange: true)
                .AddEnvironmentVariables()
                .Build();

现在，我们已经熟悉了如何设置函数清单并配置它，让我们看看用于托管它的选项。

托管功能

Azure 功能一旦部署，就托管在 App Service 基础设施上。 在 App Service 中，正如您在前面的示例中看到的，只有计算资源(可能还有其他集成资源)会累积到您的账单中。 此外，在消费计划中，Azure 函数仅在被已配置的事件之一触发时才激活; 因此，在任务关键型集成场景中，Azure Functions 具有极高的成本效益。 函数资源还可以根据它们所处理的负载进行伸缩和缩小。

第二个可供功能使用的计划是保费计划。 在付费计划中，您可以选择设置始终运行的函数以避免冷启动，还可以配置无限的执行时间。 无限的持续时间对于长时间运行的进程来说很有用，因为默认情况下，Azure 函数有 5 分钟的硬限制，通过额外配置可以将其延长到 10 分钟。

本节总结了 Azure 函数可用的托管选项，并完成了对 Azure 函数基本概念的介绍。 现在，让我们使用这些概念为我们的ShopAcross应用实现一个 Azure 函数。

创建第一个 Azure 函数

前面在 Azure 的上下文中提到的模式之一是实体化视图。 例如，在我们的初始结构中，我们有关于嵌入在用户文档中的拍卖的基本信息。 通过这种方式，拍卖可以作为用户配置文件的一部分，并且可以根据用户参与成功拍卖的情况对他们进行评级。 在这种设置中，由于用户配置文件上的拍卖数据只是来自主拍卖表的非规范化数据块，因此服务不需要直接与拍卖表交互。

让我们看看下面的用户故事，看看我们如何实现这个解决方案:

“作为一个解决方案架构师，我想实现一个 Azure 功能，用修改过的拍卖数据来更新 Cosmos DB Users 集合，这样拍卖 API 就可以从用户 API 中分离出来。”

我们在这里的任务是实现一个 Azure 函数，该函数将在修改拍卖文档时触发。 本文档的更改应传播到用户集合:

Figure 10.6 – SynchronizingDocument Data on Cosmos DB

图 10.6 -在 Cosmos DB 上同步文档数据

在这个设置中，我们将从以下步骤开始:

  1. First, we will create our Azure Functions project, which will be hosted as a function app in our resource group:

    Figure 10.7 – Cosmos DB Triggered Function Template

    图 10.7 - Cosmos DB 触发函数模板

    这将创建我们的第一个函数，其声明如下:

    [FunctionName("Function1")] public static void Run( [CosmosDBTrigger( databaseName: "ProductsDb", collectionName: "AuctionsCollection", ConnectionStringSetting = "DbConnection", LeaseCollectionName = "leases")] IReadOnlyList<Document> input, ILogger log)

    通过使用CosmosDBTrigger,我们是指示 Azure 函数运行时创建一个租赁,这样我们可以连接到宇宙 DB 改变以给定的数据库(即ProductsDb)和集合(即AuctionsCollection)使用连接字符串集设置(即DbConnection)。

  2. 现在，让我们展开配置，以包含给定的连接字符串设置:

    { "ConnectionStrings": { "DbConnection": "AccountEndpoint=https://handsoncrossplatform.documents.azure.com:443/;AccountKey=...;" } }

  3. Let's now add the additional lease settings. After this step, our trigger declaration will look like this:

    [CosmosDBTrigger( databaseName: "ProductsDb", collectionName: "AuctionsCollection", ConnectionStringSetting = "DbConnection", LeaseCollectionPrefix = "AuctionsTrigger", LeaseCollectionName = "LeasesCollection")]

    通过定义租约集合，您可以记录 Azure 函数使用的触发器。 为了使用单个租赁集合，在LeaseCollectionName选项之上，我们还可以将LeasePrefix属性添加到声明中。 这样，每个租约条目将收到一个前缀值，这取决于函数声明。

  4. After this, we can run our function in debug mode and see whether our trigger is working as expected. After updating a document on the AuctionsCollection collection, you will receive the updated data almost immediately:

    Figure 10.8 – Executing the Azure Function

    图 10.8 -执行 Azure 功能

  5. 我们现在收到修改后的文件 如果修改仅基于传入的数据，我们可以添加一个带有单个文档的输出绑定或一个async收集器来修改或将文档插入到特定的集合中。 但是，我们想要更新用户参与的拍卖列表。 因此，我们将使用属性声明获得 Cosmos 客户端实例:

    [CosmosDBTrigger( databaseName: "ProductsDb", collectionName: "AuctionsCollection", ConnectionStringSetting = "DbConnection", LeaseCollectionPrefix = "AuctionsTrigger", LeaseCollectionName = "LeasesCollection")]IReadOnlyList<Document> input, [CosmosDB( databaseName: "ProductsDb", collectionName: "UsersCollection", ConnectionStringSetting = "DbConnection")] DocumentClient client,

现在，使用客户机，我们可以对 Users 文档集合执行必要的更新。

在本节中，我们已经成功地使用 Python 和 c#，使用 HTTP 和 Cosmos DB 触发器实现了函数。 现在我们对 Azure 功能的可用开发和集成选项有了更广泛的了解。 接下来，我们将研究 Azure 的另一个无服务器成员，逻辑应用。

开发逻辑应用

逻辑应用是简单的、事件驱动的工作流声明，可以利用许多内在的动作以及其他 Azure 无服务器资源。 他们还开发了与 Azure 功能类似的基于触发的执行策略。 在本节中，我们将学习如何使用逻辑应用创建简单的工作流，以及如何将它们与其他 Azure 资源集成。

从理论上讲，当一个开发人员需要实现一个逻辑应用时，除了文本编辑器，他不需要其他任何东西，因为逻辑应用是 ARM 资源模板的扩展。 逻辑应用的清单包含四个主要成分:

  • 参数
  • 触发器
  • 行动
  • 输出

参数、触发器和输出，类似于 Azure 函数中的绑定概念，定义应用何时以及如何执行。 操作定义应用应该做什么。

逻辑应用可以使用带有额外模式和/或可视化支持的 IDE(如 visual Studio)创建，也可以使用 web 门户在 Azure 门户上单独开发。

下面的章节将带你通过使用 logic App Designer、连接器、Azure 功能和内置流控制机制来创建和设计逻辑应用。

实现逻辑应用

为了用 Visual Studio 创建一个逻辑应用，我们需要做以下工作:

  1. We need to use the Azure Resource Group project template and select the Logic App template from the screen that follows:

    Figure 10.9 – Azure Logic App

    图 10.9 - Azure Logic App

    这将创建一个包含逻辑应用定义的资源组清单。 逻辑应用现在可以使用 Visual Studio 中的逻辑应用设计器进行修改，如果安装了 Azure logic Apps Tools 扩展(右键单击资源组 JSON 文件，并选择Open with logic app designer)。

  2. 实现 Logic App 的第一步是选择触发器，这将是我们工作流中的初始步骤。 对于本例，让我们选择当接收到 HTTP 请求时。

  3. Now that the logic app flow has been created, let's expand the HTTP request and paste a sample JSON payload as the body of a request we are expecting for this application trigger:

    Figure 10.10 – HTTP Trigger Schema

    图 10.10 - HTTP 触发器模式

    这将生成Request Body JSON Schema。 现在，我们可以发送请求，就像在示例 JSON 有效负载中一样。

  4. Next, we will add an action to send an email (there are many email solutions; for this example, we will be using the Send an email action using Outlook):

    Figure 10.11 – Send an Email

    图 10.11 -发送电子邮件操作

    如您所见，我们实际上正在使用触发器中定义的电子邮件、主题和消息参数来填充电子邮件操作。

  5. 最后，我们可以添加一个Response操作，并定义响应头和响应体。 现在，我们的应用已经准备好执行:

Figure 10.12 – HTTP Response

图 10.12 - HTTP 响应动作

部署逻辑应用之后，您可以从 Azure 门户设计器检索请求 URL 以及集成的安全令牌。 使用所需的参数执行简单的POST调用将触发逻辑应用并触发操作:

curl -H "Content-Type:application/json" -X POST -d '{"email":"can.bilgin@authoritypartners.com", "title":"Test", "subject":"Test", "message" : "Test Message"}' "https://prod-00.northcentralus.logic.azure.com:443/workflows/5bb----------/triggers/manual/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=eOB----------------"
Successfully sent the email to can.bilgin@authoritypartners.com

如您所见，使用逻辑应用，这些类型的简单或更复杂的业务工作流可以声明性地转换为 web 服务，并在诸如队列、提要和 webhook 等触发器上执行。 连接器是这个设置中的关键组件，它服务于这些操作和逻辑应用可用的触发器。

使用连接器

在前面的示例中，我们使用了 HTTP 触发器和响应操作，以及 Outlook 电子邮件操作。 这些操作和触发器被打包在逻辑应用基础设施的所谓连接器中。 连接器本质上是更大的 SaaS 生态系统的一部分，该生态系统还包括 Microsoft Flow 和 Power Apps，以及逻辑应用。 连接器可以描述为各种 SaaS 产品(例如，电子邮件、社交媒体、发布管理、HTTP 请求、文件传输等)的封装连接组件。

在标准的免费连接器集(包括第三方连接器)之上，企业集成包(EIP)是一个高级产品，它为 B2B 企业集成服务提供构建块。 这些集成场景通常支持围绕着行业标准,也就是说,电子数据交换【显示】(EDI)【病人】和企业应用集成(EAI*)。*

还可以创建自定义逻辑应用连接器，以便实现可用连接器集无法实现的其他自定义用例。

如果/当通过提供的操作不能满足需求，Azure 功能可以作为任务集成到逻辑应用中。 这样，任何自定义逻辑都可以通过。net Core 和逻辑应用和功能之间的简单 HTTP 通信嵌入到工作流中。

创建我们的第一个逻辑应用

到目前为止，主服务应用被构建为，以适应主要应用用例，并为用户提供数据，以便他们可以创建拍卖和用户配置文件，以及对拍卖进行投标。 然而，我们需要找到更多方法来利用用户的兴趣来吸引他们。 对于这种类型的业务模型，我们可以利用各种通知渠道。 这些渠道中最突出的是定期通知电子邮件设置。

我们在这个例子中使用的用户故事如下所示:

“作为产品所有者，如果有新的拍卖可用，我会定期向注册用户发送电子邮件，根据他们之前的兴趣，这样我就可以吸引用户，提高回报率。”

在开始实现逻辑应用之前，尽管可以使用 Cosmos DB 连接器来加载数据，但让我们再创建两个 Azure 函数来分别加载用户和电子邮件目标和内容的最新拍卖。 这两个函数都应该使用HttpTrigger，并且应该返回 JSON 数据作为响应。 对于本练习，您可以使用在前一节中创建的相同的 Azure 函数项目。 让我们开始:

  1. 返回我们将发送通知的用户列表的函数如下:

    [FunctionName("RetrieveUsersList")] public static async Task<IActionResult> Run( [HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)] HttpRequest req, ILogger log) { // TODO: Retrieve users from UsersCollection var users = new List<User>(); users.Add(new User{ Email = "can.bilgin@authoritypartners.com", FirstName = "Can"}); return (ActionResult)new OkObjectResult(users); }

  2. Next, we will need the data for the latest auctions:

    [FunctionName("RetrieveLatestAuctionsList")] public static async Task<IActionResult> Run( [HttpTrigger(AuthorizationLevel.Function, "get", "post", Route = null)] HttpRequest req, ILogger log) { // TODO: Retrieve latest auctions from AuctionsCollection var auctions = new List<Auction>(); auctions.Add(new Auction { Brand = "Volvo", Model = "S60", Year = 2017, CurrentHighestBid = 26000, StartingPrice = 25000 }); return (ActionResult)new OkObjectResult(auctions); }

    现在我们已经准备好了数据提要，我们可以开始实现逻辑应用了。

    重要提示

    在本例中，我们使用了 Azure 函数来检索一组 dto，以达到成本效益。 还可以创建一个更改提要功能，以便在数据存储用新用户或拍卖/投标更新时准备每日通知提要。 通过这种方式，逻辑应用可以直接从每日提要文档集合或表存储中加载数据。

  3. In our previous example, we created a logic app using an HTTP trigger. For this example, let's start with a recurrence trigger so that we can process our data and prepare a periodic feed:

    Figure 10.13 – Recurrence Trigger Setup

    图 10.13 -重复触发设置

  4. Next, let's retrieve the set of users using our Azure function. In order to select a function from the available actions, you should locate the Azure Functions action in the Choose an action dialog, then select the target function app that contains your functions, and finally, select the desired function:

    Figure 10.14 – Azure Functions with the Logic App

    图 10.14 - Azure 功能与逻辑应用

  5. Once we have retrieved the results from the Azure function, it will be in JSON format. In order to ease the design and access properties of the contained data items, it would be good to include a data parse action with a predefined schema. At this point, you can have a simple run and copy the results:

    Figure 10.15 – Calling the Azure Function

    图 10.15 -调用 Azure 功能

  6. Now, repeat the same actions for the auctions list data, so that we can start building out email content. Our current workflow should look similar to the following:

    Figure 10.16 – Sequential Azure Function Calls

    图 10.16 -顺序 Azure 函数调用

  7. 在我们继续准备电子邮件内容并将其发送给列表中的每个用户之前，让我们构造一下流，这样针对用户的数据检索操作和拍卖不会按顺序执行:

Figure 10.17 – Parallel Azure Function Calls

图 10.17 -并行 Azure 函数调用

到目前为止，我们已经创建了一个逻辑应用，它使用两个单独的 Azure 函数从 Cosmos DB 检索用户列表和可用拍卖。 然后逻辑应用解析 JSON 数据，以便下面的操作可以利用对象数据。 现在我们可以继续使用其他控制语句并准备电子邮件内容。

工作流执行控制

根据定义，作为一种编制工具，Logic Apps 使用诸如foreach、switch和conditionals等控制语句，以便使用可用的操作组成一个受控工作流。 这些控制语句可以使用逻辑应用上下文中其他操作的输入和输出值作为工作流中的操作。 可用的控制语句集如下:

  • 条件:用于评估一个条件，并根据结果定义两个不同的路径
  • Foreach:用于执行序列中每个项目的相关操作的路径
  • 作用域:用于封装动作块
  • 开关:根据开关输入，用于执行多个独立的动作块
  • Terminate:终止当前逻辑应用的执行
  • Until:用作while循环，其中执行动作块，直到定义的条件计算为true

这些语句可以通过Logic App Designer中的Control操作来访问:

Figure 10.18 – Control s

图 10.18 -控制动作

在我们的示例中，我们应该向每个用户发送一封带有最新拍卖列表的电子邮件。 对于用户列表中的每个操作，我们可以使用来实现这一点:

Figure 10.19 – Using variables from a For each loop

图 10.19 -从 For each 循环中使用变量

正如你所看到的,我们使用的是UsersList行动的主体(即body(UsersList),使用逻辑应用符号),列表中的每一项,我们检索电子邮件(即items('For_each')['email'])和firstName。 以类似的方式，我们可以准备拍卖的电子邮件主体，并将结果分配为主题的主体。 除了这个简单的设置外，还可以根据用户的兴趣使用可用的数据操作对内容进行过滤:

Figure 10.20 – Complete Azure Logic App View

图 10.20 -完整的 Azure Logic 应用视图

现在，我们将定期向用户发送拍卖更新，而不必妥协或增加我们当前服务基础设施的额外复杂性。

在本节中，我们已经了解了基本的逻辑应用概念，并使用几个控制语句、连接器和自定义 Azure 函数实现了一个功能齐全的 Azure logic 应用。 如您所见，Azure 逻辑应用设计的声明性和事件驱动特性使它们成为编排次要事件驱动流程的好选择。

与 Azure 服务集成

到目前为止，我们只在逻辑应用和 Azure 功能的上下文中使用了 Cosmos DB，在众多 Azure 服务中，我们可以将其与 Azure 无服务器组件集成。 在本节中，我们将分析 Azure 无服务器组件与其他 Azure 资源的其他可用集成选项。

如您所见，这些集成可以通过 Azure 功能的绑定和逻辑应用的连接器来实现。 使用这个集成的业务模型，可以组合多个体系结构模式，并且可以完成事件驱动的场景。

下面几节将带您了解可以与 Azure 无服务器组件集成的基于存储库、队列和事件的 Azure 资源。 让我们更深入地了解其中一些集成服务。

存储库

在 Azure 无服务器环境中，可以说几乎所有的 Azure 存储库模型都与基础设施紧密集成。 让我们来看看以下的 g 模型:

  • Cosmos DB:这为 Azure 函数提供了一个可用绑定。 这是一个具有各种操作的连接器，用于执行主流 CRUD 操作，以及用于创建、检索和执行存储过程的高级场景。 Cosmos DB 也可以用来触发 Azure 函数。
  • SQL ServerSQL Server:这是另一个存储库服务，可以通过可用的连接器集成到逻辑应用中，从而允许创建或修改条目等触发器。 逻辑应用也可以使用 SQL 和Azure SQL 数据仓库连接器在 SQL 实例上执行原始和结构化查询。 此外，SQL 连接可以在 Azure 函数中初始化，只需要使用作为。net Core 一部分可用的本机 SQL 客户端即可。
  • Azure Table Storage:这是另一个存储库模型，可以与 Azure 无服务器组件集成。 表存储表可以用作输入参数，也可以作为 Azure 功能基础设施中输出配置的一部分，接收新实体。 逻辑应用的连接器可以用来执行表存储上的各种操作:

Figure 10.21 – Azure Table Storage s

图 10.21 - Azure 表存储操作

  • Azure Blob Storage:这可以作为函数和逻辑应用的触发器。 可用的函数绑定和应用连接器提供了各种可以在无服务器应用模型中使用的任务和绑定元素。

队列处理

为了实现上述基于队列的负载均衡模式，Azure 分布式系统可以利用 Azure 队列和Azure 服务总线。 通过这种方式，可以实现各种异步处理模式。

Azure 队列可以配置来触发功能和逻辑应用。 绑定和连接器都有可用的操作，以便它们可以侦听特定的队列。 连接器包含用于执行基本操作的操作，包括但不限于创建消息队列、插入消息和检索消息。 Azure 消息队列还可以用作 Azure 函数的输出目标，以在配置的队列中创建消息。

Azure 服务总线的连接器和绑定具有一组扩展的可用操作和各种触发器。 作为触发器设置的一部分，队列和主题都可用于侦听新消息。 逻辑应用还可以执行几乎所有可能的操作，托管客户机可以通过与管理基本消息、死信队列、锁、主题和订阅相关的操作实现这些操作。

事件聚合

另一个 Azure 无服务器生态系统的成员，事件网格是在分布式服务组件之间实现经典的发布者/订户模型的最合适的候选人，特别是在涉及 Azure 功能和逻辑应用时。 在事件网格之外的中，对于涉及事件流而不是离散事件分发的大数据管道，事件集线器是最佳选择。

Event Grid 聚合从各种所谓的事件源收集的事件，例如容器注册中心、资源组、服务总线和存储。 事件网格还可以使用和交付由功能强大的组件发布的自定义主题。 然后将聚合的事件分散到注册的使用者或所谓的事件处理程序。 事件网格的事件处理程序包括但不限于以下内容:

  • Azure 自动化
  • Azure 的功能
  • 活动中心
  • 混合连接
  • 逻辑应用
  • 微软流
  • 队列存储
  • Webhooks

这种基础设施意味着开发人员不受功能和逻辑应用的可用触发器的限制，因为它们是某个关键任务场景的初始点。 他们还可以创建一个完整的事件驱动订阅模型。

事件 hub可以集成为事件网格事件的消费者，并用作 Azure 功能的触发器和输出。 一个连接器可用于具有触发器和动作的逻辑应用。 事件中心与 Azure 函数一起使用时，可以为处理大数据流创建一个非常敏捷的伸缩模型。

我们现在有了一个关于 Azure 无服务器组件的集成选项的完整的图片，以及在哪些场景中可以利用它们。

总结

总之，作为 Azure 无服务器平台的一部分，Azure 功能和逻辑应用提供了专门的事件驱动解决方案，以填补任何分布式云应用的空白。 在本章中，我们分析了 Azure 函数可用的开发选项。 我们已经实现了简单的 Azure 函数来在 Cosmos DB 设置上反规范化数据。 最后，我们通过使用开箱即用的连接器任务，以及使用 HTTP 和周期性触发器的 Azure 函数来创建逻辑应用。

本章结束了我们对 Azure 云服务相关主题的讨论。 在接下来的章节中，我们将研究更高级的主题，以改进 Xamarin 应用和基于云的服务后端之间的集成。

版权属于：月萌API www.moonapi.com，转载请注明出处

本文链接：https://moonapi.com/news/33629.html