En hurtig introduktion til Azure-funktionsproxyer

I denne artikel vil vi diskutere Azure Function Proxies. De leverer "Omvendt proxyfunktionalitet" til Azure-funktioner. Azure Function Proxies er meget lig Azure API-styring.  

Dette indlæg er stort set inspireret af Matthew Henderson fra Microsoft Azure Function Team. I sit blogindlæg, Azure Functions Proxies offentlig forhåndsvisning, forklarer Matthew årsagen til, hvorfor Microsoft kom op med ideologien til Azure Function Proxies.

Hvad er Azure Function Proxies?

Den grundlæggende idé bag Azure Function Proxies er, at de giver os mulighed for at definere en enkelt API-overflade til apps med flere funktioner. Nu kan enhver funktionsapp definere et slutpunkt, der fungerer som en omvendt proxy for en anden API. Slutpunktet kan være en funktionsapp, eller det kan være noget andet.

Ser du efter et værktøj fra hylden til at styre og overvåge dine Azure-funktioner? Prøv denne herude gratis.

Årsag til implementering af Azure Function Proxies

For nogle brugere er det vanskeligt at administrere store løsninger med en enkelt funktionsapp. Der er en masse organisationer, der bruger Azure Function i deres mikrotjenestearkitektur med implementering mellem individuelle komponenter. I dette tilfælde har hver funktionsapp sin egen hosting, så der er mange forskellige funktionsapps at holde styr på.

Vi kunne også have en funktionsapp kombineret med en anden API, men de kunne være i forskellige forskellige regioner. Så vi ender med at give en masse af den kompleksitet videre til vores klient eller forbrugende system.

Azure Function Proxies kommer til undsætning ved at levere en samlet URI (Uniform Resource Identifier), som klienten faktisk kan forbruge. I mellemtiden kan vi abstrahere alle de forskellige funktionsapps eller andre API'er, og det vil også gøre det muligt for os at opbygge vores API hurtigere.

Forklaring

Azure-funktionsproxyer

I løsningsarkitekturdiagrammet ovenfor har vi en Azure Function Proxy efterfulgt af en Azure Function and Service Bus-kø i back-enden til at gemme information. I den anden ende af diagrammet har vi Data Publishers. Med henblik på denne diskussion, lad os sige, at Power Equipment genererer taghændelsen og videresender den til Azure Functions via Proxy.

Oprindeligt opretter vi en funktionsapp ved at vælge funktionsindstillingen fra Azure-portalen. Lad os sige, at vi opretter en HTTP-trigger til C #, hvor HTTP-triggerens funktion er at påkalde en funktion med en HTTP-anmodning.

Nu opretter vi to funktioner: den ene er PostTag, der repræsenterer vores indlæg, hvis vi vil oprette et tag. Koden til PostTag-funktionen er følgende:

Post-tag

Derefter opretter vi en anden funktion kaldet GetTag med koden angivet som følger:

Få tag

Vi bruger GetTag til at hente beskeden fra køen, og den sidste tagværdi vender tilbage til klienten.

Vi kan vælge det link, der er angivet nedenfor, for at hente URL'en til begge funktionerne. Dette link giver os et sikkerhedstoken til godkendelse.

For at få funktions-URL

På dette tidspunkt flytter vi over til Funktionsappindstillinger og aktiverer Azure Function Proxies, der har den seneste proxy-runtime-version på 0.2. Derfor vælger vi indstillingen "Ny proxy" fra Function App Development, der giver os mulighed for at oprette to proxyer. De er Proxy GetTag og Proxy PostTag. De tilgængelige indstillinger i proxy er:

  • Proxy-URL
  • Ruteskabelon
  • URL til backend

URL'en, der er angivet i Proxy URL og ruteskabelonen, er den samme med hensyn til både GetTag- og PostTag-begivenheden. Backend URL til Proxy GetTag vil være relateret til GetTag-begivenheden - men for Proxy PostTag vil det være relateret til PostTag-begivenheden.

Afslutning

Azure Function Proxies er en fantastisk måde at spotte og teste dit Azure Functions-slutpunkt, selv før den egentlige back-end-udvikling begynder. De kan endda bruges til produktion, når du har brug for at dirigere en URI til en anden.

Jeg vil gerne konkludere, at Azure Function Proxies er en af ​​de mest engagerende og går til markedsfunktioner, som Azure Functions-teamet har leveret.

Denne blog blev oprindeligt offentliggjort i Serverless360.