桌面应用程序 azure_Azure Logic应用程序用例–黑色星期五

桌面应用程序 azure

This blog gives an overview of how Azure Serverless technologies came to rescue when the custom-built integration system went down. Also, it shows the high-level architecture solution built using Azure Serverless services like Logic Apps, Service Bus Queue and Topics, etc to replace the legacy system.

该博客概述了自定义集成系统出现故障时如何利用Azure无服务器技术进行救援。 此外，它还显示了使用Azure无服务器服务(例如Logic Apps，Service Bus Queue和Topics等)构建的高层体系结构解决方案，以替代旧系统。

This article was originally published at Serverless360.com

本文最初发布于Serverless360.com

一切如何开始？ (How it all Started?)

About three years ago, Northwind, a company who runs their business in B2B space wanted to extend its business to B2C. So, the company wanted to open a Web Shop (SaaS). Since it was a B2B specialized company there were no warehouse and transport service to serve the customers effectively. The company chose to go ahead with LSP (Logistics Service Provider) instead. The legacy system was built using a middleware to connect the Web Shop and the LSP. Later, the legacy system was integrated with the email system. The complexity of the system increased as several branches (Web shops) opened across the globe.

大约三年前，一家在B2B领域开展业务的公司Northwind希望将其业务扩展到B2C。 因此，该公司希望开设一个网上商店(SaaS)。 由于它是一家B2B专业公司，因此没有有效的仓库和运输服务来为客户提供服务。 该公司选择继续使用LSP(物流服务提供商)。 遗留系统是使用中间件构建的，以连接Web Shop和LSP。 后来，旧系统与电子邮件系统集成在一起。 随着全球各地数家分支机构(网络商店)的开业，系统的复杂性也随之增加。

One day, the whole system went down, and the company started losing hundreds of orders. Then, the company approached an expert team to fix their middleware.

一天，整个系统出现故障，该公司开始失去数百份订单。 然后，该公司联系了一个专家团队来修复其中间件。

需要考虑的要求 (Requirements to be considered)

• Stability – the system needs to be stable enough to handle a lot of orders.
  稳定性–系统需要足够稳定才能处理大量订单。
• Monitoring – the system should be monitored to alert the operation personnel when something goes wrong.
  监视–发生问题时，应监视系统以警告操作人员。
• To handle 10,000 orders per hour.
  每小时处理10,000个订单。
• New SaaS webshop
  新的SaaS网上商店

解决方案 (The Solution)

The expert team replaced the middleware using Azure serverless technologies. Predominantly, Logic Apps and other Serverless entities like Azure Functions, Service Bus Queues and Topics were used. The stateful middleware was changed to stateless using event-based approach.

专家团队使用Azure无服务器技术替换了中间件。 主要使用了Logic Apps和其他无服务器实体，例如Azure Functions，Service Bus Queue和Topic。 使用基于事件的方法将有状态中间件更改为无状态。

什么是无服务器？ (What is Serverless?)

The abstraction of server, platform, and runtime – There is no need to provision or maintain any servers. There is no software or runtime to install, maintain, or administer.

服务器，平台和运行时的抽象 –无需配置或维护任何服务器。 没有要安装，维护或管理的软件或运行时。

Event-driven scaling – This is one of the important characteristics of Serverless, you shouldn’t worry about scaling your solution if demand arises.

事件驱动的扩展 –这是Serverless的重要特征之一，如果需求出现，您不必担心扩展解决方案。

Micro-billing – When your code is executed you pay per execution. Typically, the vendors calculate this based on memory consumption and the time it takes for the execution.

微计费 –执行代码时，您需要为每次执行付费。 通常，供应商基于内存消耗和执行所花费的时间来计算。

优点 (Advantages)

Manage apps not servers – The significant advantage of serverless is that the user does not manage the servers, but the cloud service providers do.

管理应用程序而不是服务器 –无服务器的显着优势是用户不管理服务器，而云服务提供商可以管理。

Reduced DevOps – It reduces the DevOps cost as the infrastructure is maintained by CSP.

降低DevOps –由于CSP维护基础架构，因此降低了DevOps成本。

Faster time to Market – It reduces the time to market as serverless technology screens the ground works and lets the developer focus on the logic.

加快产品上市时间 –由于无服务器技术屏蔽了基础工作并让开发人员专注于逻辑，因此缩短了产品上市时间。

Azure逻辑应用 (Azure Logic Apps)

You can run a business workflow in Azure using the Logic App service.

您可以使用Logic App服务在Azure中运行业务工作流。

The Logic App is a logical container for one workflow you can define using triggers and actions. A trigger can instantiate a workflow, which can consist of one or many activities (actions). For instance, you can trigger a workflow by sending an HTTP request or schedule a workflow every hour to retrieve data from a public website. There are 200+ out-of-the-box connectors available for enterprise integration.

Logic App是一个工作流程的逻辑容器，您可以使用触发器和操作对其进行定义。 触发器可以实例化工作流程，该工作流程可以包含一个或多个活动(动作)。 例如，您可以通过发送HTTP请求来触发工作流，或者每小时安排一个工作流以从公共网站检索数据。 有200多个现成的连接器可用于企业集成。

好处 (Benefits)

• Out-of-the-box connector reduces the integration challenges
  开箱即用的连接器减少了集成挑战
• Connect and Integrate data from the cloud to on-premises
  连接和集成云中的数据到本地
• B2B and enterprise messaging in the cloud
  云中的B2B和企业消息传递
• A powerful web-based workflow designer
  强大的基于Web的工作流程设计器

Azure Logic应用的定价 (Pricing of Azure Logic Apps)

The pricing is very simple. It works on the pay-as-you-go model, it would cost you only a few nickels. For instance, if you process 1000 service bus messages a day, with a workflow of five actions it would cost you EUR 4.62 approx. To execute a normal action, it would cost $ 0.000025 and for a Standard connector, it would cost you $0.000125. Even, the Enterprise connector would cost you only $0.001. For more information see the pricing page here.

定价非常简单。 它适用于现收现付模式，只需花费几分钱。 例如，如果您每天处理1000条服务总线消息，并且有五个操作的工作流程，则将花费您约4.62欧元。 要执行正常操作，将花费0.000025美元，对于标准连接器，将花费0.000125美元。 甚至，企业连接器也只需0.001美元。 有关更多信息，请参见此处的定价页面。

基本架构解决方案 (Basic Architecture Solution)

Initially, there is a webshop connected to Webshop publisher Logic App through Webhook. The Webshop publisher Logic Apps act as the orchestrator for the workflow. The data from the Webshop is converted into Canonical entity and passed to the Canonical Order Mapper Logic App. Subsequently, the control flows to the CE publisher where the translation of the object happens. Then, the translated object is sent to Service Bus Topic. Topic Subscriptions provide a one-to-many form of communication, in a publish/subscribe pattern. Get to know about Topic Subscription rules here.  Based on the filter, the orders are sent to LSP Subscriber and MS (Marketing System) Subscriber.

最初，有一个网上商店通过Webhook连接到Webshop发布者Logic App。 Webshop发布者Logic Apps充当工作流程的协调器。 来自Webshop的数据将转换为Canonical实体，并传递到Canonical Order Mapper Logic App。 随后，控制流向CE发布者，在此对象发生翻译。 然后，将转换后的对象发送到服务总线主题。 主题订阅以发布/订阅模式提供一对多的交流形式。 在此处了解主题订阅规则。 基于筛选器，将订单发送到LSP订阅服务器和MS(营销系统)订阅服务器。

Azure Logic应用程序令人印象深刻的可伸缩性 (Impressive Scalability of Azure Logic Apps)

On running the above workflow, it could process 73,120 orders in 20 min. Every order would get processed in less than 3 seconds and the success rate was above 98 percent. The above log shows that there were 73,120 runs completed and out of which 72,972 runs were accomplished and 148 runs were failed.

运行上述工作流程后，它可以在20分钟内处理73,120个订单。 每个订单将在不到3秒的时间内得到处理，成功率超过98％。 上面的日志显示，已经完成了73,120次运行，其中完成了72,972次运行，失败了148次。

资源组中实体的视图 (View of Entities in a Resource Group)

The above picture represents how the entities will be listed in a Resource Group. For better management of the entities use the Display Name tag. It helps the user to debug the workflow in case of failure.

上图表示如何在资源组中列出实体。 为了更好地管理实体，请使用显示名称标签。 如果发生故障，它可以帮助用户调试工作流程。

Webshop Publisher逻辑应用程序 (Webshop Publisher Logic App)

Out-of-the-box, there is an HTTP trigger which initiates the Logic App and sends 201 response directly for the received message. 201 response represents that request has been fulfilled and has resulted in one or more new resources being created. Subsequently, sends the order message to the other Logic App (Map order to Canonical order) and to Publish canonical order.

现成的HTTP触发器可启动Logic App，并直接为收到的消息发送201响应。 201响应表示请求已被满足，并导致创建了一个或多个新资源。 随后，将订单消息发送到另一个Logic App(将订单映射到规范订单)并发布规范订单。

跟踪属性 (Tracked properties)

In “Response 201 directly” action, the following properties are tracked

在“直接响应201”操作中，跟踪以下属性

• Customer Email
  客户电邮
• Flow
  流
• Order ID
  订单编号
• Shop ID
  店铺编号

规范顺序映射器 (Canonical Order Mapper)

The Logic App gets triggered by receiving the HTTP request. Then, the message would be passed to Data Operation actions to compose canonical order items and create shop reference data.  Subsequently, composes the canonical order using Data Operation action and sends back the response.

通过接收HTTP请求来触发Logic App。 然后，该消息将传递到“数据操作”操作以组成规范的订单项目并创建商店参考数据。 随后，使用“数据操作”操作编写规范的顺序，并发送回响应。

服务总线资源管理器 (Service Bus Explorer)

For easy management of the entities use Service Bus Explorer. It provides filter option for Service Bus Topic using which the message can be sent to the defined subscriptions (LSP). The message will be filtered based on the properties defined in the Service Bus Topic. Here is how Serverless360 makes a better option for Service Bus Explorer.

为了方便管理实体，请使用Service Bus Explorer。 它为服务总线主题提供了过滤器选项，通过该选项可以将消息发送到已定义的订阅(LSP)。 该消息将根据服务总线主题中定义的属性进行过滤。 这是Serverless360为Service Bus Explorer提供更好的选择的方式。

监控方式 (Monitoring)

The above picture shows the Log Analytics dashboard. It provides a graphical representation and monitoring capability for the entities associated with the Log analytics. Inside the Log Analytics, the user can run powerful quires and inspect the database if something goes wrong.

上图显示了Log Analytics仪表板。 它为与Log Analytics相关的实体提供了图形表示和监视功能。 在Log Analytics内部，用户可以运行功能强大的查询并检查数据库是否出了问题。

演示–已付款的订单 (Demo – order paid)

To test the new solution architecture, send the test order, use the Postman tool to send a POST message to the Logic App. On sending the successful order, you can see the 201 response at the bottom left corner of the Postman tool. On receiving the order, the Logic Apps gets triggered and finally, the order message would reach any one of the respective LSP.

要测试新的解决方案体系结构，请发送测试订单，使用邮递员工具将POST消息发送到Logic App。 发送成功的订单后，您可以在Postman工具的左下角看到201响应。 在接收到订单后，逻辑应用将被触发，最后，订单消息将到达各个LSP中的任何一个。

CI / CD管道 (CI/CD pipeline)

The above picture represents the CI/CD pipeline architecture. There are three blocks namely Developer context, Azure DevOps and Azure subscription. The Developer context contains PowerShell, IDE’s, etc. Once the developer checks in the code, it commits to the repository. On switching the Build option, build pipeline deploys the code to the Blob storage. Once Build pipeline is done with the work, Release pipeline kicks off and tells the ARM to reflect the changes in Development, Testing, and Production environment.

上图表示CI / CD管道体系结构。 有三个块，分别是Developer上下文，Azure DevOps和Azure订阅。 开发人员上下文包含PowerShell，IDE等。一旦开发人员签入代码，它将提交到存储库。 切换Build选项时，构建管道会将代码部署到Blob存储。 一旦构建管道完成工作，发布管道就会启动，并告诉ARM反映开发，测试和生产环境中的更改。

好处 (Benefits)

• No manual steps required to deploy the code.
  部署代码无需手动步骤。
• Quality control can be done
  可以进行质量控制
• The organization can have a bigger development team
  组织可以拥有更大的开发团队

挑战性 (Challenges)

• A lot of housekeeping is required around ARM templates.
  ARM模板周围需要进行大量整理工作。
• Things get complex if any ARM template goes down. Because the failure can be spotted only during release.
  如果任何ARM模板崩溃，事情就会变得复杂。 因为只有在发布期间才能发现故障。
• The rhythm of the service changes rapidly
  服务节奏快速变化

以上解决方案的主要收获 (Key Takeaways from the Above Solution)

• Faster time to market: There were only three developers and they could get the project done within 3 months.
  加快产品上市时间：只有三个开发人员，他们可以在3个月内完成项目。
• Resilient and scalable: As we saw above the application was highly scalable. It could handle about 73 thousand orders in 20 minutes.
  弹性和可扩展性：如我们上面所见，该应用程序具有高度可扩展性。 它可以在20分钟内处理大约73000个订单。
• It is best suitable for business-critical systems
  最适合关键业务系统

This blog is an extraction of the session “Black Friday? Logic Apps to the rescue” presented by Aarjan Meirink at MSBuild 2019.

该博客摘自“黑色星期五？ 由Aarjan Meirink在MSBuild 2019上展示的逻辑应用程序。

翻译自: https://www.freecodecamp.org/news/azure-logic-apps-use-case-black-friday/

桌面应用程序 azure