分类:  Azure入门    ◆ 标签:  #Azure   #基础   #Azure入门   #入门   ◆ 发布于: 2023-06-15 14:15:45

我们前面学习了如何使用Azure虚拟机，App Service，以及容器化的应用，这些服务部署的应用非常适合部署等待用户的请求，但是针对于一些通过条件出发的应用，例如监听队列消息等等应用，如果是部署在之前的服务上，用户不得不通过更多的编码来实现，例如在虚拟机上运行一个background service，但是这样的方案问题也是比较多的， 例如更新，维护，以及缩放都需要更多的工作。

Azure提供无服务计算来满足这种应用场景。特别适合各种通过异步消息队列解耦应用的场景，或者是自动工作流的场景。

无服务器计算是对服务器、基础结构和操作系统的抽象。 有了无服务器计算，Azure 将负责管理服务器基础结构和按需的资源分配和解除分配。 无需负责基础结构。 系统自动处理缩放和性能。 只需为具体使用过的资源付费。 甚至没有必要保留容量。

无服务器计算包括服务器抽象、事件驱动缩放和小额账单

• 服务器抽象：无服务器计算会对运行的服务器进行抽象。 永远不需要显式保留服务器实例。 平台会为你管理。 每个函数的执行可以在不同的计算实例上运行。 此执行上下文对代码是透明的。 采用无服务器体系结构，部署代码后，运行的同时可获得高可用性。

• 事件驱动缩放：无服务器计算非常适合响应传入事件的工作负载。 事件包括以下触发器：

  • 计时器，例如，如果某个函数需要在每天上午 10:00 UTC 运行。

  • HTTP，例如 API 和 webhook 方案。

  • 队列，例如订单处理时的队列。

    还有很多其他触发器。
    开发者不再编写整个应用程序，而是编写一个函数，使其包含有关其触发器和绑定的代码和元数据。 平台会自动安排函数运行，并根据传入事件的速率调整计算实例的数目。 触发器定义函数的调用方式。 绑定提供从代码内连接到服务的声明性方式。

• 小额账单：传统计算对一段时间进行计费，例如，按月或按年为网站托管付费。 这种计费方法非常方便，但并不总是经济高效。 即使客户的网站一天只点击了一次，仍然需要为一整天的可用性付费。 采用无服务器计算，只需为其代码运行的时间付费。 如果未执行任何活动的函数，则无需付费。 例如，如果代码一天运行一次，一次两分钟，则计费时只考虑这一次执行，且计算时间为两分钟。

Azure 有两种无服务器计算实现：

• Azure Functions：Functions 可以执行几乎任何现代语言的代码。
• Azure逻辑应用：逻辑应用在基于 Web 的设计器中设计，可执行由 Azure 服务触发的逻辑而无需编写代码。

Azure Functions

若只关心运行服务的代码，而不关心基础平台或基础结构，则使用Azure Functions是理想选择。 Functions需要执行工作以响应事件（通常通过 REST 请求）、计时器或来自其他Azure服务的消息，并且该工作可在几秒钟或更短时间内快速完成时，通常会用到它们。

Functions会自动按需缩放，所以当需求变化时，它们是可靠的选择。 例如，你可能收到来自用于监控运输车队的 IoT 解决方案的消息。 可能会在工作时间内收到更多数据。

使用基于虚拟机的方法，即使虚拟机处于空闲状态，也会产生成本。 借助函数，Azure 会在触发代码时运行代码，并在函数完成时自动释放资源。 在此模型中，只需为函数运行时使用的 CPU 时间付费。

函数可以是无状态或有状态的。 如果函数是无状态的（默认情况下），其行为与每次响应事件时都重启函数的效果一样。 如果函数是有状态的（称为 Durable Functions），会通过函数传递一个上下文来跟踪先前的活动。

函数是无服务器计算的关键组成部分。 它们也是运行所有类型的代码的常规计算平台。 如果开发人员的应用需求发生变化，你可以将项目部署到无服务器环境中。 这种灵活性使你可以管理缩放、在虚拟网络上运行，甚至完全隔离函数。

Azure 逻辑应用

逻辑应用类似于函数。 二者都可以基于事件触发逻辑。 Functions 执行代码时，逻辑应用执行从预定义逻辑块构建的工作流，这些工作流旨在自动完成业务方案。

每个 Azure 逻辑应用工作流都从触发器开始，在发生特定事件或新的可用数据符合特定条件的情况下触发。 许多触发器包括基本的计划功能，可以让开发人员指定工作负载的运行频率。 每当触发器触发时，逻辑应用引擎都会创建一个逻辑应用实例来运行工作流中的操作。 这些操作也可包括数据转换和流控制，如条件语句、开关语句、循环和分支。

可以在 Azure 门户或 Visual Studio 中使用可视化设计器创建逻辑应用工作流。 工作流将保留为具有已知工作流架构的 JSON 文件。

Azure 提供了 200 多个不同的连接器和处理块来与不同服务交互。 这些资源包括最常见的企业应用。 如果未涵盖需要与之进行交互的服务，还可以构建自定义连接器和工作流步骤。 然后，使用可视设计器将连接器和块链接在一起。 可以通过工作流来传递数据，从而执行自定义处理，通常完全不需要编写任何代码。

例如，假设逻辑应用收到一个票证。 你可以：

• 使用认知服务检测消息的意图。
• 在 Sharepoint 中创建一个项目来跟踪问题。
• 如果客户不在数据库中，将其添加到 Dynamics 365 CRM 系统中。
• 发送跟进电子邮件以确认他们的请求。

所有这些操作都可以在可视化设计器中设计，这使你可以轻松查看逻辑流。 出于此原因，它非常适合业务分析师使用。

Functions 与逻辑应用

函数和逻辑应用都可以创建复杂的业务流程。 业务流程是函数或步骤的集合，将执行这些函数或步骤来完成复杂任务。

借助 Functions，你可以编写代码来完成每个步骤。
借助逻辑应用，你可以使用 GUI 来定义操作以及它们之间的相关方式。
在构建业务流程、从逻辑应用中调用函数以及从函数中调用逻辑应用时，可以混合使用各种服务。 下面是两者之间的一些常见差异。