Tolerante communicatie
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.
In dit boek hebben we een architectuurbenadering op basis van microservices omarmd. Hoewel een dergelijke architectuur belangrijke voordelen biedt, biedt deze veel uitdagingen:
Niet-verwerkte netwerkcommunicatie. Elke microservice communiceert via een netwerkprotocol dat netwerkcongestie, latentie en tijdelijke fouten introduceert.
Servicedetectie. Hoe detecteren en communiceren microservices met elkaar wanneer ze worden uitgevoerd op een cluster van computers met hun eigen IP-adressen en poorten?
Flexibiliteit. Hoe beheert u fouten met korte levensduur en houdt u het systeem stabiel?
Taakverdeling. Hoe wordt binnenkomend verkeer verdeeld over meerdere exemplaren van een microservice?
Beveiliging. Hoe worden beveiligingsproblemen zoals versleuteling op transportniveau en certificaatbeheer afgedwongen?
Gedistribueerde bewaking. - Hoe correleert en legt u traceerbaarheid en bewaking vast voor één aanvraag voor meerdere verbruikende microservices?
U kunt deze problemen oplossen met verschillende bibliotheken en frameworks, maar de implementatie kan duur, complex en tijdrovend zijn. U krijgt ook last van infrastructuurproblemen die zijn gekoppeld aan bedrijfslogica.
Service-mesh
Een betere aanpak is een zich ontwikkelende technologie genaamd Service Mesh. Een service-mesh is een configureerbare infrastructuurlaag met ingebouwde mogelijkheden voor het afhandelen van servicecommunicatie en de andere uitdagingen die hierboven worden genoemd. Deze problemen worden losgekoppeld door ze naar een serviceproxy te verplaatsen. De proxy wordt geïmplementeerd in een afzonderlijk proces (een sidecar genoemd) om isolatie van bedrijfscode te bieden. De sidecar is echter gekoppeld aan de service. De sidecar wordt ermee gemaakt en deelt de levenscyclus. In afbeelding 6-7 ziet u dit scenario.
Afbeelding 6-7. Service mesh met een zijwagen
In de vorige afbeelding ziet u hoe de proxy de communicatie tussen de microservices en het cluster onderschept en beheert.
Een service-mesh is logisch onderverdeeld in twee verschillende onderdelen: een gegevensvlak en een besturingsvlak. In afbeelding 6-8 ziet u deze onderdelen en hun verantwoordelijkheden.
Afbeelding 6-8. Service mesh-beheer en gegevensvlak
Zodra deze is geconfigureerd, is een service-mesh zeer functioneel. Het kan een bijbehorende groep exemplaren ophalen van een servicedetectie-eindpunt. De mesh kan vervolgens een aanvraag verzenden naar een specifiek exemplaar, waardoor de latentie en het reactietype van het resultaat worden opgenomen. Een mesh kan de instantie kiezen die waarschijnlijk een snelle reactie retourneert op basis van veel factoren, met inbegrip van de waargenomen latentie voor recente aanvragen.
Als een exemplaar niet reageert of mislukt, probeert de mesh de aanvraag opnieuw uit te voeren op een ander exemplaar. Als er fouten worden geretourneerd, wordt het exemplaar uit de load balancing-pool verwijderd en opnieuw uitgevoerd nadat het is hersteld. Als er een time-out optreedt voor een aanvraag, kan een mesh mislukken en vervolgens de aanvraag opnieuw proberen. Een mesh legt metrische gegevens en gedistribueerde tracering vast en verzendt deze naar een gecentraliseerd metrische gegevenssysteem.
Istio en Envoy
Hoewel er momenteel enkele service mesh-opties bestaan, is Istio het populairst op het moment van schrijven. Istio is een joint venture van IBM, Google en Lyft. Het is een opensource-aanbieding die kan worden geïntegreerd in een nieuwe of bestaande gedistribueerde toepassing. De technologie biedt een consistente en volledige oplossing voor het beveiligen, verbinden en bewaken van microservices. De functies zijn onder andere:
- Beveilig service-naar-service-communicatie in een cluster met sterke verificatie en autorisatie op basis van identiteiten.
- Automatische taakverdeling voor HTTP-, gRPC-, WebSocket- en TCP-verkeer.
- Fijnmazige controle over verkeersgedrag met uitgebreide routeringsregels, nieuwe pogingen, failovers en foutinjectie.
- Een pluggable beleidslaag en configuratie-API die toegangsbeheer, frequentielimieten en quota ondersteunt.
- Automatische metrische gegevens, logboeken en traceringen voor al het verkeer binnen een cluster, inclusief inkomend en uitgaand cluster.
Een belangrijk onderdeel voor een Istio-implementatie is een proxyservice met de naam Envoy-proxy. De service wordt naast elke service uitgevoerd en biedt een platformagnostische basis voor de volgende functies:
- Dynamische servicedetectie.
- Taakverdeling.
- TLS-beëindiging.
- HTTP- en gRPC-proxy's.
- Tolerantie van circuitonderbrekers.
- Statuscontroles.
- Rolling updates met canary-implementaties .
Zoals eerder besproken, wordt Envoy geïmplementeerd als sidecar voor elke microservice in het cluster.
Integratie met Azure Kubernetes Services
De Azure-cloud omarmt Istio en biedt directe ondersteuning voor deze cloud binnen Azure Kubernetes Services. Met de volgende koppelingen kunt u aan de slag:
