何时使用 Azure 逻辑应用
在这里，我们将讨论如何确定 Azure 逻辑应用是否是你场景的正确选择。 首先，我们将列出一些条件，指出 Azure 逻辑应用是否满足性能和功能目标。
决策条件
Azure 逻辑应用有助于协调通过不同系统的数据流。 Azure 逻辑应用可能不是最佳选项的情况通常涉及实时需求、复杂的业务规则或使用非标准服务。 下面是对这些因素的一些讨论。
| 因子 | 说明 |
|---|---|
| 集成 | 考虑 Azure 逻辑应用时要询问的关键问题是“是否需要集成服务？”需要让多个应用程序和系统协同工作时，Azure 逻辑应用非常有效。 如果要生成的应用没有外部连接，那么 Azure 逻辑应用可能不是最佳选择。 |
| “性能” | 下一个考虑因素是性能。 Azure 逻辑应用执行引擎可自动缩放应用。 Azure 逻辑应用可以并行处理大型数据集，从而实现高吞吐量。 但是，该服务并不保证进行超高速激活或对执行时间强制执行实时约束。 如果想要实现低次秒级响应时间，那么 Azure 逻辑应用可能不是最佳选择。 |
| 控制 | Azure 逻辑应用提供条件（布尔表达式）、切换操作和循环等控制构造，因此应用可以根据数据做出决策。 可以在逻辑应用工作流中构建高度复杂和深度嵌套的控制结构。 但是，你可能由于以下两个原因而不愿意这样做。 - 用代码编写条件逻辑通常比使用工作流设计器更容易。 - 嵌入业务规则不可与其他应用轻松共享。 一些人喜欢直接在其逻辑应用工作流中包括复杂的业务规则。 另一些人则认为编写 Azure 函数之类的内容可更轻松地封装条件逻辑并从所有应用中调用该函数。 |
| 连接器 | 最后一个考虑因素是，所有需要访问的服务或系统是否具有预生成连接器。 如果具有预生成连接器，则可以继续。 如果没有，则需要创建自定义连接器。 如果服务具有现有 REST 或 SOAP API，则可以在几个小时内创建自定义连接器，而无需编写任何代码。 如果没有，你就需要先创建 API 才可创建连接器。 |
应用条件
使用一些添加的控件逻辑集成多个服务时，Azure 逻辑应用的效果最佳。 让我们考虑一下如何将这些条件应用到我们的示例流程。
一家虚构的鞋业公司需要监视行业新闻，将旧视频移动到存档存储，并在线销售鞋品。 我们的目标是确定 Azure 逻辑应用是否适合处理这些任务。 为了制定决策，我们将使用已制定的四个条件来分析每个任务：集成、性能、控制和连接器。 下表汇总了结果：
| 集成 | “性能” | 控制 | 连接器 | 使用 Azure 逻辑应用？ | |
|---|---|---|---|---|---|
| 新闻监视 | 集成多个服务 | 不需要准实时低延迟 | 一个简单的条件操作 | 可用于所有所需系统的内置连接器 | 是 |
| 视频存档实用工具 | 仅需要访问一个服务，云存储 | 不需要准实时低延迟 | 两个简单的条件操作 | 可用于所有所需系统的预生成连接器 | 是 |
| 直接在线销售 | 集成多个服务 | 不需要准实时低延迟 | 多个复杂的条件 | 需要多个自定义连接器 | 可能 |
此分析会生成一些值得考虑的有趣事项：
视频存档任务非常适合使用 Azure 逻辑应用，即使该任务不会集成多个系统。
Azure 逻辑应用具有内置的计时器触发器和 Azure Blob 存储连接器，非常适合实现此过程。
在线销售流程可能包括复杂的业务逻辑。
例如，不同的购买量可能有不同的审批流程，不同目的地可能有不同的运货商。 Azure 逻辑应用可以轻松处理这些条件。 只需选择是否要在应用中嵌入这些业务规则。
在线销售流程可能会混合使用预生成连接器和自定义连接器。
我们可以使用预生成连接器进行电子邮件通知和数据库访问，但可能需要自定义连接器才能与我们的付款处理服务进行通信。
Azure 逻辑应用的性能适用于所有任务。
某些任务可能可以处理大量数据，但 Azure 逻辑应用可按需自动缩放以处理高吞吐量或峰值。 这些任务都不需要低延迟响应时间。 要使这一方面成为一个问题，我们需要有准实时要求。
Azure 逻辑应用可以处理所有这些任务，而在线销售流程是我们想要权衡所有选项的唯一任务。 如果我们具有构建所需自定义连接器的资源，那么使用 Azure 逻辑应用是一个不错的选择。
指南摘要
下面的流程图总结了在考虑使用 Azure 逻辑应用时要考虑的关键问题。
