本文属于【Azure 架构师学习笔记】系列。
本文属于【Azure Logic Apps】系列。

前言

Azure Logic apps的学习也研究源自于最近项目的需要，对于新技术的学习，可以先了解What， why两部分， 也就是这是什么，为什么要用。另外在使用了几年Azure之后，我个人会更加重视去了解这个技术属于IaaS， PaaS还是SaaS。

什么是Logic Apps？

网上有很多描述，结合自己的经验，我会认为Logic Apps是一个无服务（Serverless）的PaaS服务， 同时从Azure Portal的布局上来看，它属于集成服务。是PaaS（由微软托管，是否为PaaS的一个标准是你需要管理的有多少）。

另外，Logic Apps用于创建和部署workflow（工作流）。由此可见，Logic Apps是以工作流为核心的一个PaaS。

既然它主要用来做数据集成，那么跟Azure Data Factory相比又有什么优势呢？

为什么要用Logic Apps？

在用过ADF(Azure Data Factory)后，再对比Logic Apps，会发现有不少相同的地方，比如低代码编程， 都是用于集成服务，费用低，能够连接多种数据源等等。

但是既然有这么多相似点，为什么还会出现Azure Logic Apps呢？

首先，要考虑我自己项目使用Logic Apps的原因，一开始我们有ADF进行数据移动和处理（Data Flow) ，但是后来发现有些数据ADF并不支持或者说要花费大力气进行定制化开发才能实现，同时还有ADF自定义警告。这些不足都可以使用Logic Apps来实现，所以才开始研究这个服务。这就是第一个原因：互补不足。

其次，考虑其性能，ADF是云原生的ETL工具，它在数据E, T, L过程是比较强大的，对于大数据量（不管是文件个数还是单个文件体积），都能很好地支持。而Logic Apps更加适合对小型文件和特定业务需求。所以第二个原因就是：需求不同。

最后，关注点不同，ADF关注的是数据，而Logic Apps关注的是集成其他“应用程序”。但是实际上，如果可以的话，ADF+Logic Apps会更好。比如使用Logic Apps进行特定数据源的数据准备，然后ADF进行处理，最后使用Logic Apps进行一些业务操作（比如发确认邮件）。

快速演示

接下来快速创建一个最简单的logic apps:

可以直接在搜索栏搜索Logic Apps，然后进入创建界面，然后输入资源组既资源的名字：

接下来会看到“计划”选项， 在这里可以看到有两个计划类型，一个是标准（Standard）另外一个是使用了“Consumption” ，不同的计划类型的后续选项不同，费用也不同，在正式环境中会考虑使用标准类型，不过作为演示，我们先使用另外一种。下面是标准类型的后续可选类容。同时注意【区域冗余】，它用于在正式环境中进行高可用设置。

下图是使用量类型的选择内容，可以看出可选项少了很多。

创建过程出现的选项，会在后续文章中做具体介绍。

创建完毕后，可以看到下面的资源界面。

小结

这是我学习的一个习惯性思路，先了解对象是什么，为什么要用，然后把它实践出来。但是不想用网上直接搜索的专业术语，而是希望通过自己的理解让记忆更加深刻。所以在前言部分，写的内容可能会不专业。