Cloudeigen communicatiepatronen

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

Bij het bouwen van een systeemeigen cloud wordt communicatie een belangrijke ontwerpbeslissing. Hoe communiceert een front-endclienttoepassing met een back-end microservice? Hoe communiceren back-end microservices met elkaar? Wat zijn de principes, patronen en best practices waarmee u rekening moet houden bij het implementeren van communicatie in cloudtoepassingen?

Communicatieoverwegingen

In een monolithische toepassing is communicatie eenvoudig. De codemodules worden samen uitgevoerd in dezelfde uitvoerbare ruimte (proces) op een server. Deze benadering kan prestatievoordelen hebben, omdat alles samen wordt uitgevoerd in gedeeld geheugen, maar resulteert in nauw gekoppelde code die moeilijk te onderhouden, ontwikkelen en schalen wordt.

Cloudeigen systemen implementeren een architectuur op basis van microservices met veel kleine, onafhankelijke microservices. Elke microservice wordt uitgevoerd in een afzonderlijk proces en wordt doorgaans uitgevoerd in een container die in een cluster is geïmplementeerd.

Een cluster groeperen een groep virtuele machines samen om een maximaal beschikbare omgeving te vormen. Ze worden beheerd met een indelingsprogramma, dat verantwoordelijk is voor het implementeren en beheren van de in containers geplaatste microservices. Afbeelding 4-1 toont een Kubernetes-cluster dat is geïmplementeerd in de Azure-cloud met de volledig beheerde Azure Kubernetes Services.

Afbeelding 4-1. Een Kubernetes-cluster in Azure

In het cluster communiceren microservices met elkaar via API's en berichttechnologieën.

Hoewel ze veel voordelen bieden, zijn microservices geen gratis lunch. Lokale in-process methode-aanroepen tussen onderdelen worden nu vervangen door netwerkoproepen. Elke microservice moet communiceren via een netwerkprotocol, waardoor uw systeem complexer wordt:

• Netwerkcongestie, latentie en tijdelijke fouten zijn een constante zorg.

• Tolerantie (dat wil gezegd, mislukte aanvragen opnieuw proberen) is essentieel.

• Sommige aanroepen moeten idempotent zijn om consistente status te behouden.

• Elke microservice moet oproepen verifiëren en autoriseren.

• Elk bericht moet worden geserialiseerd en vervolgens gedeserialiseerd, wat duur kan zijn.

• Berichtversleuteling/-ontsleuteling wordt belangrijk.

Het boek .NET Microservices: Architecture for Containerized .NET Applications, gratis beschikbaar bij Microsoft, biedt een uitgebreide dekking van communicatiepatronen voor microservicetoepassingen. In dit hoofdstuk bieden we een algemeen overzicht van deze patronen, samen met implementatieopties die beschikbaar zijn in de Azure-cloud.

In dit hoofdstuk behandelen we eerst communicatie tussen front-endtoepassingen en back-end microservices. Vervolgens kijken we naar back-end microservices die met elkaar communiceren. We verkennen de up- en gRPC-communicatietechnologie. Ten slotte kijken we naar nieuwe innovatieve communicatiepatronen met behulp van service mesh-technologie. We zien ook hoe de Azure-cloud verschillende soorten back-upservices biedt ter ondersteuning van cloudeigen communicatie.

VorigeVolgende