Front-endclientcommunicatie

Tip

Deze inhoud is een fragment uit het eBook, Cloud Native .NET Applications for Azure ontwerpen, beschikbaar op .NET Docs of als een gratis downloadbare PDF die offline kan worden gelezen.

PDF downloaden

In een systeemeigen cloud vereisen front-endclients (mobiele, web- en bureaubladtoepassingen) een communicatiekanaal om te communiceren met onafhankelijke back-end microservices.

Wat zijn de opties?

Om het eenvoudig te houden, kan een front-endclient rechtstreeks communiceren met de back-end microservices, weergegeven in afbeelding 4-2.

Afbeelding 4-2. Directe client-naar-servicecommunicatie

Met deze benadering heeft elke microservice een openbaar eindpunt dat toegankelijk is voor front-endclients. In een productieomgeving plaatst u een load balancer vóór de microservices, waarbij verkeer evenredig wordt gerouteerd.

Hoewel het eenvoudig te implementeren is, is directe clientcommunicatie alleen acceptabel voor eenvoudige microservicetoepassingen. Dit patroon koppelt front-endclients nauw aan de belangrijkste back-endservices, waarbij de deur voor veel problemen wordt geopend, waaronder:

• Clientgevoeligheid voor het herstructureren van back-endservices.
• Een bredere kwetsbaarheid voor aanvallen omdat de back-endservices rechtstreeks beschikbaar worden gesteld.
• Duplicatie van kruislingse zorgen voor elke microservice.
• Te complexe clientcode: clients moeten meerdere eindpunten bijhouden en fouten op een flexibele manier afhandelen.

In plaats daarvan is een algemeen geaccepteerd cloudontwerppatroon het implementeren van een API Gateway-service tussen de front-endtoepassingen en back-endservices. Het patroon wordt weergegeven in afbeelding 4-3.

Afbeelding 4-3. API-gatewaypatroon

In de vorige afbeelding ziet u hoe de API Gateway-service de microservices van de back-endkern abstraheert. Geïmplementeerd als een web-API, fungeert het als een omgekeerde proxy, het routeren van binnenkomend verkeer naar de interne microservices.

De gateway isoleert de client tegen interne servicepartitionering en -herstructurering. Als u een back-endservice wijzigt, kunt u deze in de gateway gebruiken zonder dat de client wordt onderbroken. Het is ook uw eerste verdedigingslinie voor kruislingse zorgen, zoals identiteit, caching, tolerantie, meting en beperking. Veel van deze kruislingse problemen kunnen worden uitgeschakeld van de back-endkernservices naar de gateway, waardoor de back-endservices worden vereenvoudigd.

Zorg ervoor dat de API Gateway eenvoudig en snel blijft. Normaal gesproken wordt bedrijfslogica buiten de gateway gehouden. Een complexe gateway riskeert een knelpunt te worden en uiteindelijk een monolith zelf. Grotere systemen maken vaak meerdere API-gateways beschikbaar die zijn gesegmenteerd op clienttype (mobiel, web, desktop) of back-endfunctionaliteit. Het patroon Back-end voor front-ends biedt richting voor het implementeren van meerdere gateways. Het patroon wordt weergegeven in afbeelding 4-4.

Afbeelding 4-4. Back-end voor front-endpatroon

In de vorige afbeelding ziet u hoe binnenkomend verkeer wordt verzonden naar een specifieke API-gateway, op basis van clienttype: web, mobiel of desktop-app. Deze benadering is logisch omdat de mogelijkheden van elk apparaat aanzienlijk verschillen tussen de beperkingen van de vormfactor, prestaties en weergave. Mobiele toepassingen bieden doorgaans minder functionaliteit dan een browser- of desktoptoepassingen. Elke gateway kan worden geoptimaliseerd zodat deze overeenkomt met de mogelijkheden en functionaliteit van het bijbehorende apparaat.

Eenvoudige gateways

Om te beginnen kunt u uw eigen API Gateway-service bouwen. Een snelle zoekopdracht van GitHub biedt veel voorbeelden.

Voor eenvoudige .NET-cloudtoepassingen kunt u de Ocelot-gateway overwegen. Open source en gemaakt voor .NET-microservices, het is lichtgewicht, snel, schaalbaar. Net als elke API-gateway is de primaire functionaliteit het doorsturen van binnenkomende HTTP-aanvragen naar downstreamservices. Daarnaast biedt het ondersteuning voor een groot aantal mogelijkheden die kunnen worden geconfigureerd in een .NET middleware-pijplijn.

YARP (Yet Another Reverse Proxy) is een andere open source omgekeerde proxy, geleid door een groep Microsoft-productteams. YaRP kan worden gedownload als een NuGet-pakket en sluit het ASP.NET framework aan als middleware en is zeer aanpasbaar. U vindt YARP goed gedocumenteerd met verschillende gebruiksvoorbeelden.

Voor cloudeigen bedrijfstoepassingen zijn er verschillende beheerde Azure-services die u kunnen helpen bij het starten van uw inspanningen.

Azure Application Gateway

Voor eenvoudige gatewayvereisten kunt u overwegen Azure-toepassing Gateway. Deze service is beschikbaar als Een Azure PaaS-service en bevat basisgatewayfuncties zoals URL-routering, SSL-beëindiging en een Web Application Firewall. De service biedt ondersteuning voor laag-7-taakverdelingsmogelijkheden . Met Laag 7 kunt u aanvragen routeren op basis van de werkelijke inhoud van een HTTP-bericht, niet alleen TCP-netwerkpakketten op laag niveau.

In dit boek willen we cloudeigen systemen in Kubernetes hosten. Een containerorchestrator, Kubernetes automatiseert de implementatie, schaalaanpassing en operationele problemen van workloads in containers. Azure-toepassing Gateway kan worden geconfigureerd als EEN API-gateway voor Azure Kubernetes Service-cluster.

Met de controller voor inkomend verkeer van Application Gateway kan Azure-toepassing Gateway rechtstreeks met Azure Kubernetes Service werken. In afbeelding 4.5 ziet u de architectuur.

Afbeelding 4-5. Controller voor inkomend verkeer van Application Gateway

Kubernetes bevat een ingebouwde functie die ondersteuning biedt voor HTTP-taakverdeling (niveau 7), met de naam Inkomend verkeer. Inkomend verkeer definieert een set regels voor de wijze waarop microservice-exemplaren binnen AKS kunnen worden blootgesteld aan de buitenwereld. In de vorige afbeelding interpreteert de ingangscontroller de regels voor inkomend verkeer die zijn geconfigureerd voor het cluster en configureert de Azure-toepassing Gateway automatisch. Op basis van deze regels stuurt Application Gateway verkeer naar microservices die worden uitgevoerd in AKS. De ingangscontroller luistert naar wijzigingen in toegangsbeheerregels en brengt de juiste wijzigingen aan in de Azure-toepassing Gateway.

Azure API Management

Voor middelgrote tot grootschalige cloudeigen systemen kunt u Azure API Management overwegen. Het is een cloudservice die niet alleen uw API Gateway-behoeften oplost, maar een volledige ontwikkelaar en administratieve ervaring biedt. API Management wordt weergegeven in afbeelding 4-6.

Afbeelding 4-6. Azure API Management

Om te beginnen maakt API Management een gatewayserver beschikbaar die gecontroleerde toegang tot back-endservices toestaat op basis van configureerbare regels en beleidsregels. Deze services kunnen zich in de Azure-cloud, uw on-premises datacenter of andere openbare clouds bevinden. API-sleutels en JWT-tokens bepalen wie wat kan doen. Al het verkeer wordt vastgelegd voor analytische doeleinden.

Voor ontwikkelaars biedt API Management een ontwikkelaarsportal die toegang biedt tot services, documentatie en voorbeeldcode voor het aanroepen ervan. Ontwikkelaars kunnen Swagger/Open API gebruiken om service-eindpunten te inspecteren en hun gebruik te analyseren. De service werkt op de belangrijkste ontwikkelplatforms: .NET, Java, Golang en meer.

In de uitgeversportal wordt een beheerdashboard weergegeven waarin beheerders API's beschikbaar maken en hun gedrag beheren. Servicetoegang kan worden verleend, servicestatus bewaakt en servicetelemetrie verzameld. Beheer istrators passen beleidsregels toe op elk eindpunt om het gedrag te beïnvloeden. Beleidsregels zijn vooraf gebouwde instructies die opeenvolgend worden uitgevoerd voor elke service-aanroep. Beleidsregels worden geconfigureerd voor een inkomende oproep, uitgaande aanroep of aangeroepen op een fout. Beleidsregels kunnen worden toegepast op verschillende servicebereiken om deterministische volgorde in te schakelen bij het combineren van beleidsregels. Het product wordt geleverd met een groot aantal vooraf samengestelde beleidsregels.

Hier volgen voorbeelden van hoe beleidsregels van invloed kunnen zijn op het gedrag van uw cloudeigen services:

• Servicetoegang beperken.
• Verificatie afdwingen.
• Beperk de aanroepen van één bron, indien nodig.
• Cache inschakelen.
• Oproepen van specifieke IP-adressen blokkeren.
• De stroom van de service beheren.
• Converteer aanvragen van SOAP naar REST of tussen verschillende gegevensindelingen, zoals van XML naar JSON.

Azure API Management kan back-endservices beschikbaar maken die overal worden gehost, in de cloud of in uw datacenter. Voor verouderde services die u mogelijk beschikbaar maakt in uw cloudeigen systemen, ondersteunt deze zowel REST- als SOAP-API's. Zelfs andere Azure-services kunnen worden weergegeven via API Management. U kunt een beheerde API plaatsen boven op een Azure-backingservice, zoals Azure Service Bus of Azure Logic Apps. Azure API Management bevat geen ingebouwde ondersteuning voor taakverdeling en moet worden gebruikt in combinatie met een taakverdelingsservice.

Azure API Management is beschikbaar in vier verschillende lagen:

• Ontwikkelaar
• Basic
• Standard
• Premium

De developer-laag is bedoeld voor niet-productieworkloads en -evaluatie. De andere lagen bieden geleidelijk meer kracht, functies en hogere service level agreements (SLA's). De Premium-laag biedt ondersteuning voor Azure Virtual Network en meerdere regio's. Alle lagen hebben een vaste prijs per uur.

De Azure-cloud biedt ook een serverloze laag voor Azure API Management. Aangeduid als de prijscategorie verbruik, is de service een variant van API Management die is ontworpen rond het serverloze computingmodel. In tegenstelling tot de vooraf toegewezen prijscategorieën die eerder werden weergegeven, biedt de verbruikslaag directe inrichting en prijzen voor betalen per actie.

Hiermee worden API Gateway-functies ingeschakeld voor de volgende use cases:

• Microservices die zijn geïmplementeerd met behulp van serverloze technologieën, zoals Azure Functions en Azure Logic Apps.
• Azure Backing Service-resources, zoals Service Bus-wachtrijen en onderwerpen, Azure-opslag en andere.
• Microservices waarbij verkeer af en toe grote pieken heeft, maar de meeste tijd laag blijft.

De verbruikslaag maakt gebruik van dezelfde onderliggende API Management-onderdelen van de service, maar maakt gebruik van een volledig andere architectuur op basis van dynamisch toegewezen resources. Het is perfect afgestemd op het serverloze computingmodel:

• Er is geen infrastructuur om te beheren.
• Geen niet-actieve capaciteit.
• Hoge beschikbaarheid.
• Automatisch schalen.
• De kosten zijn gebaseerd op het werkelijke gebruik.

De nieuwe verbruikslaag is een uitstekende keuze voor cloudeigen systemen die serverloze resources beschikbaar maken als API's.

Realtime communicatie

Communicatie in realtime of push is een andere optie voor front-endtoepassingen die communiceren met systeemeigen back-endsystemen via HTTP. Toepassingen, zoals financiële tickers, online education, gaming en jobvoortgangsupdates, vereisen onmiddellijke, realtime antwoorden van de back-end. Met normale HTTP-communicatie is er geen manier om de client te laten weten wanneer er nieuwe gegevens beschikbaar zijn. De client moet voortdurend aanvragen naar de server peilen of verzenden. Met realtime communicatie kan de server op elk gewenst moment nieuwe gegevens naar de client pushen.

Realtime systemen worden vaak gekenmerkt door gegevensstromen met hoge frequentie en grote aantallen gelijktijdige clientverbindingen. Het handmatig implementeren van realtime-connectiviteit kan snel complex worden, waardoor niet-triviale infrastructuur nodig is om schaalbaarheid en betrouwbare berichten naar verbonden clients te garanderen. U kunt een exemplaar van Azure Redis Cache en een set load balancers beheren die zijn geconfigureerd met plaksessies voor clientaffiniteit.

Azure SignalR Service is een volledig beheerde Azure-service die realtime communicatie vereenvoudigt voor uw cloudtoepassingen. Technische implementatiedetails, zoals capaciteitsinrichting, schalen en permanente verbindingen, worden weggeabstraheerd. Ze worden voor u afgehandeld met een service level agreement van 99,9%. U richt zich op toepassingsfuncties, niet op infrastructuurpruiming.

Zodra deze functie is ingeschakeld, kan een cloudgebaseerde HTTP-service inhoudsupdates rechtstreeks pushen naar verbonden clients, waaronder browser-, mobiele en desktoptoepassingen. Clients worden bijgewerkt zonder de server te hoeven peilen. Azure SignalR abstraheert de transporttechnologieën die realtime-connectiviteit maken, waaronder WebSockets, Gebeurtenissen aan de serverzijde en Long Polling. Ontwikkelaars richten zich op het verzenden van berichten naar alle of specifieke subsets van verbonden clients.

Afbeelding 4-7 toont een set HTTP-clients die verbinding maken met een cloudeigen toepassing waarvoor Azure SignalR is ingeschakeld.

Afbeelding 4-7. Azure SignalR

Een ander voordeel van Azure SignalR Service is het implementeren van serverloze cloudeigen services. Misschien wordt uw code op aanvraag uitgevoerd met Azure Functions-triggers. Dit scenario kan lastig zijn omdat uw code geen lange verbindingen met clients onderhoudt. Azure SignalR is geknipt voor deze situatie, omdat verbindingen al voor u worden beheerd via deze service.

Azure SignalR Service is nauw geïntegreerd met andere Azure-services, zoals Azure SQL Database, Service Bus of Redis Cache, waarmee u veel mogelijkheden voor uw cloudeigen toepassingen kunt openen.

VorigeVolgende