桌面应用程序 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

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: 远程桌面应用程序的技术选型有很多种方案。 常见的技术包括: - VNC (Virtual Network Computing) - RDP (Remote Desktop Protocol) - SSH (Secure Shell) - TeamViewer 这些技术都可以用来在远程计算机上控制图形界面。 其中 VNC、RDP 和 SSH 都是开源的,可以自己搭建服务器端。 TeamViewer 是一个商业软件,但是提供免费版本供个人使用。 在选择技术时,你需要考虑自己的需求,比如是否需要支持 Windows、Linux、Mac 等多种操作系统,是否需要支持高分辨率和高带宽等。 你也可以根据需要调整协议的安全级别,比如 VNC 和 RDP 的默认协议都是明文传输,你可以使用加密通道来提高安全性。 ### 回答2: 当然可以帮您进行远程桌面应用程序的技术选型。在选择技术时,我会考虑以下几个因素: 1. 客户端平台:远程桌面应用程序需要在不同的操作系统上运行,如Windows,macOS,Linux等。因此,您需要选择一个跨平台的开发框架,以便在各种操作系统上实现一致的用户体验。 2. 网络传输协议:远程桌面应用程序的核心功能是实现屏幕、鼠标和键盘事件的传输。选择一个高效且安全的传输协议对于应用程序的性能和可靠性至关重要。您可以考虑使用基于TCP的协议,如RDP(远程桌面协议)或VNC(虚拟网络计算机),也可以选择基于Web的技术,如WebRTC。 3. 用户界面和交互:远程桌面应用程序的用户界面需要易于使用,并提供常见的桌面操作功能。您可以选择使用桌面应用程序的图形界面工具包,如Electron或Qt,或者使用Web技术创建响应式的用户界面。 4. 安全性:远程桌面应用程序需要确保传输的数据和用户隐私的安全。因此,您需要选择一个具有端到端加密功能的传输协议,并采取适当的安全措施来保护应用程序免受恶意攻击。 5. 性能和延迟:远程桌面应用程序需要实时传输屏幕和用户交互,因此对于网络延迟和带宽的要求较高。选择一个具有高性能的传输协议和数据压缩功能的技术可以提高应用程序的响应速度和用户体验。 综上所述,为了选择最适合您需求的技术,我建议您详细评估以上因素,并根据您的项目要求和限制来选择最适合的技术方案。 ### 回答3: 当然可以帮您选择远程桌面应用程序的技术。 远程桌面应用程序是一种允许用户远程访问和控制计算机桌面应用程序。在选择适合的技术时,我们需要考虑多个因素: 1. 客户端平台:您希望该应用程序能在哪些平台上运行?例如,Windows、Mac 或者移动设备(iOS/Android)等。 2. 带宽和延迟:您希望应用程序在何种网络环境下运行?如果带宽有限或网络延迟高,那么选择适当的压缩和传输协议非常重要。 3. 安全性:远程桌面应用程序通常需要处理敏感或机密的信息,因此数据传输和身份验证必须是安全的。确保选择支持加密和认证的技术。 4. 性能:客户端和服务器端的硬件要求需要考虑。如果服务器端的处理能力有限,那么选择一种轻量级的协议可能更加适合。 基于以上因素,以下列出几种常用的远程桌面技术供您参考: 1. VNC (Virtual Network Computing):VNC 是一种开源的远程桌面协议,支持跨平台和多种操作系统。它能在低带宽和高延迟的网络环境下工作,也支持加密和身份验证。 2. RDP (Remote Desktop Protocol):RDP 是由 Microsoft 开发的远程桌面协议,主要用于Windows操作系统。RDP 提供了较好的视频和图形性能,并支持远程应用程序的共享。 3. TeamViewer:TeamViewer 是一种商业远程桌面应用程序,适用于不同平台和操作系统。它通过云端服务器建立连接,支持高级安全功能,并提供简单易用的用户界面。 除了上述技术,还有其他的远程桌面解决方案,例如Citrix XenApp、Microsoft Azure RemoteApp等,具体选择还需根据您的需求和预算做出决策。 总体而言,根据您的需要和条件,我们可以帮您选择适合的远程桌面应用程序技术,并为您提供相应的技术支持。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值