azure 入门_Azure函数代理快速入门

azure 入门

In this article, we'll discuss Azure Function Proxies. They provide “Reverse Proxy Functionality” for Azure Functions. Azure Function Proxies are quite similar to Azure API management.  

在本文中，我们将讨论Azure Function代理。 它们为Azure功能提供“反向代理功能”。 Azure Function代理与Azure API管理非常相似。

This post is largely inspired by Matthew Henderson the of Microsoft Azure Function Team. In his blog post, Azure Functions Proxies public preview, Matthew explains the reason behind why Microsoft came up with the ideology for Azure Function Proxies.

这篇文章的主要灵感来自Microsoft Azure Function Team的Matthew Henderson。 Matthew在他的博客文章Azure Functions Proxies公共预览中解释了Microsoft提出Azure Function Proxies意识形态的背后原因。

什么是Azure功能代理？ (What are Azure Function Proxies?)

The basic idea behind Azure Function Proxies is that they allow us to define a single API surface for multiple function apps. Now any function app can define an endpoint that serves as a Reverse Proxy for another API. The endpoint can be a function app or it can be anything else.

Azure Function Proxies的基本思想是，它们使我们能够为多个功能应用程序定义单个API表面。 现在，任何功能应用程序都可以定义一个端点，该端点充当另一个API的反向代理。 端点可以是功能应用程序，也可以是其他任何东西。

Are you looking out for an off the shelf tool to manage and monitor your Azure Functions? Try this one out here for free.

您是否正在寻找一种现成的工具来管理和监视Azure功能？ 免费在这里尝试这个 。

实施Azure功能代理的原因 (Reason for implementing Azure Function Proxies)

For some users, it's difficult to manage large solutions with a single function app. There are a bunch of organizations using Azure Function in their micro service architecture with deployment between individual components. In this case, each function app has its own hosting, so there are many different function apps to keep track of.

对于某些用户而言，使用单个功能的应用程序管理大型解决方案很困难。 有很多组织在其微服务体系结构中使用Azure Function，并在各个组件之间进行部署。 在这种情况下，每个功能应用程序都有自己的托管，因此需要跟踪许多不同的功能应用程序。

We could also have some function app combined with another API but they could be in various different regions. So we end up passing a lot of that complexity on down to our client or consuming system.

我们也可以将一些功能应用程序与另一个API组合在一起，但它们可能位于不同的区域。 因此，我们最终将很多复杂性传递给了客户或消费系统。

Azure Function Proxies come to the rescue by providing a unified URI (Uniform Resource Identifier) which the client can actually consume. In the meantime, we can abstract all of the different function apps or other APIs and it would also enable us to build our API at a faster rate.

通过提供客户端可以实际使用的统一URI(统一资源标识符)，Azure功能代理得以抢救。 同时，我们可以抽象所有不同的功能应用程序或其他API，这也使我们能够以更快的速度构建API。

说明 (Explanation)

In the Solution Architecture Diagram above, we have an Azure Function Proxy followed by an Azure Function and Service Bus Queue on the back-end to store information. At the other end of the diagram, we have Data Publishers. For the purposes of this discussion, let's say that the Power Equipment generates the tag event and forwards it to Azure Functions through Proxy.

在上面的解决方案体系结构图中，我们在后端具有一个Azure功能代理，后跟一个Azure功能和服务总线队列以存储信息。 在图的另一端，我们有数据发布者。 出于此讨论的目的，假设电源设备生成标记事件并将其通过代理转发给Azure Functions。

Initially, we create a function app by selecting the function option from the Azure portal. Here let's say we create an HTTP trigger for C# where the function of the HTTP trigger is to invoke a function with an HTTP request.

最初，我们通过从Azure门户中选择功能选项来创建功能应用程序。 假设我们为C＃创建一个HTTP触发器，其中HTTP触发器的功能是使用HTTP请求调用一个功能。

Now we create two functions: one is the PostTag which represents our post if we want to create a tag. The Code for the PostTag function is the following:

现在我们创建两个函数：一个是PostTag，如果要创建标签，它表示我们的帖子。 PostTag函数的代码如下：

Then, we create another function called GetTag with the code specified as follows:

然后，使用指定的代码创建另一个名为GetTag的函数，如下所示：

We use GetTag to pull the message from the queue, and the last tag value returns to the client.

我们使用GetTag从队列中提取消息，最后一个标签值返回给客户端。

We can select the link specified below to fetch the URL of both the functions. This link will provide us with a Security Token for authorization.

我们可以选择下面指定的链接来获取两个函数的URL。 该链接将向我们提供安全令牌以进行授权。

At this point, we move over to Function App Settings and enable the Azure Function Proxies that have the latest proxy runtime version of 0.2. Consequently, we select the “New Proxy” option from Function App Development which enables us to create two proxies. They are Proxy GetTag and Proxy PostTag. The available options in proxy are:

此时，我们转到“功能应用程序设置”，并启用具有0.2的最新代理运行时版本的Azure Function代理。 因此，我们从Function App Development中选择“ New Proxy”选项，这使我们能够创建两个代理。 它们是Proxy GetTag和Proxy PostTag。 代理中的可用选项包括：

• Proxy URL
  代理网址
• Route Template
  路线模板
• Backend URL
  后端网址

The URL specified in Proxy URL and the Route Template are the same regarding both the GetTag and PostTag event. The Backend URL of the Proxy GetTag will be related to the GetTag event - but for the Proxy PostTag it will be related to the PostTag event.

关于GetTag和PostTag事件，代理URL和路由模板中指定的URL相同。 代理GetTag的后端URL将与GetTag事件相关-但是对于代理PostTag，它将与PostTag事件相关。

结语 (Wrap-up)

Azure Function Proxies are a great way to mock and test your Azure Functions endpoint even before the actual back-end development begins. Also, they can even be used in production when you need to route one URI to another.

即使在实际的后端开发开始之前，Azure Function代理还是一种模拟和测试Azure Functions终结点的好方法。 另外，当您需要将一个URI路由到另一个URI时，它们甚至可以在生产中使用。

I would like to conclude that Azure Function Proxies are one of the most engaging and go to market features that the Azure Functions team has provided.

我想得出一个结论，Azure Function代理是Azure Functions团队提供的最具吸引力和最实用的功能之一。

This blog was originally published in Serverless360.

该博客最初发表在Serverless360上 。

翻译自: https://www.freecodecamp.org/news/introduction-to-azure-function-proxies/

azure 入门