Indelingspatroon voor schotten

Het patroon Bulkhead is een type toepassingsontwerp dat tolerant is voor fouten. In een schotarchitectuur, ook wel een celarchitectuur genoemd, worden elementen van een toepassing geïsoleerd in pools, zodat de andere elementen blijven functioneren als de ene mislukt. Het schotpatroon is vernoemd naar de gesectieerde partities (schotten) van de romp van een schip. Als een scheepsromp beschadigd raakt, vult alleen het beschadigde gedeelte zich met water, waardoor wordt voorkomen dat het schip zinkt.

Context en probleem

Een cloudtoepassing kan meerdere services bevatten en elke service heeft een of meer consumenten. Overmatige belasting of fouten in een service zijn van invloed op alle gebruikers van de service.

Bovendien kan een consument aanvragen naar meerdere services tegelijk verzenden en resources voor elke aanvraag gebruiken. Wanneer de consument een aanvraag verzendt naar een onjuist geconfigureerde of niet-reagerende service, blijven de resources die de aanvraag van de client gebruikt mogelijk gedurende een langere periode niet beschikbaar. Naarmate aanvragen voor de service worden voortgezet, zijn deze resources mogelijk uitgeput. De verbindingsgroep van de client kan bijvoorbeeld uitgeput zijn. Op dat moment worden de aanvragen van de consument voor andere services beïnvloed. Uiteindelijk kan de consument geen aanvragen verzenden naar andere services, niet alleen de oorspronkelijke service die niet reageert.

Resourceuitputting is van invloed op services met meerdere consumenten. Veel aanvragen van één client kunnen beschikbare resources in de service uitputten. Resourceuitputting kan betekenen dat andere consumenten de service niet kunnen gebruiken, wat een trapsgewijs storingseffect veroorzaakt.

Solution

Partitioneer service-instanties in verschillende groepen op basis van de consumentenbelasting en beschikbaarheidseisen. Dit ontwerp helpt fouten te isoleren. U kunt servicefunctionaliteit ondersteunen voor sommige consumenten, zelfs tijdens een storing.

Een consument kan ook resources partitioneren om ervoor te zorgen dat resources die worden gebruikt om een service aan te roepen, geen invloed hebben op de resources die worden gebruikt om een andere service aan te roepen. Een consument die meerdere services aanroept, kan bijvoorbeeld een verbindingsgroep voor elke service worden toegewezen. Als een service mislukt, is dit alleen van invloed op de verbindingsgroep die voor die service is toegewezen. De consument kan andere services blijven gebruiken.

Dit patroon biedt de volgende voordelen:

  • Gebruikers en services worden geïsoleerd van trapsgewijze fouten. Een probleem dat van invloed is op een consument of service, kan worden geïsoleerd binnen een eigen schot om te voorkomen dat de hele oplossing mislukt.

  • Behoudt bepaalde functionaliteit als er een servicefout optreedt. Andere services en functies van de toepassing blijven werken.

  • Biedt verschillende serviceniveaus voor het gebruik van applicaties. U kunt een consumentengroep met hoge prioriteit configureren voor het gebruik van services met hoge prioriteit.

Het volgende diagram toont schotten die zijn gestructureerd rond verbindingspools die afzonderlijke services opvragen. Als Service A mislukt of een probleem veroorzaakt, wordt de verbindingsgroep geïsoleerd, zodat alleen werkbelastingen die gebruikmaken van de threadgroep die aan Service A is toegewezen, worden beïnvloed. Werkbelastingen die gebruikmaken van Service B en C worden niet beïnvloed en kunnen zonder onderbreking blijven werken.

Diagram met schotten die zijn gestructureerd rond verbindingsgroepen die afzonderlijke services aanroepen.

In het volgende diagram ziet u meerdere clients die één service aanroepen. Elke client wordt toegewezen aan een afzonderlijk service-exemplaar. Client 1 doet te veel aanvragen en overweldigt zijn instantie. Omdat elk service-exemplaar van de andere exemplaren is geïsoleerd, kunnen de andere clients blijven bellen.

Diagram met meerdere clients die één service aanroepen.

Problemen en overwegingen

Houd rekening met de volgende punten wanneer u besluit hoe u dit patroon implementeert:

  • Definieer partities op basis van de zakelijke en technische vereisten van de toepassing.

  • Als u tactisch domeingestuurd ontwerp gebruikt om microservices te ontwerpen, moeten partitiegrenzen worden uitgelijnd met de gebonden contexten.

  • Wanneer u services of consumenten scheidt in geïsoleerde secties, moet u rekening houden met het isolatieniveau dat de technologie biedt en de overhead in termen van kosten, prestaties en beheerbaarheid.

  • Als u geavanceerdere foutafhandeling wilt bieden, kunt u schotten combineren met het opnieuw proberen van taken, circuitonderbrekers en snelheidsbeperkingspatronen.

  • Wanneer u de consumenten partitioneert in schotten, kunt u overwegen processen, threadpools en semaphoren te gebruiken. Projecten zoals resilience4j en Polly bieden een raamwerk voor het creëren van consumer bulkheads.

  • Wanneer u services partitioneert in isolatieafbakeningen, kunt u overwegen deze in te zetten in afzonderlijke virtuele machines, containers of processen. Containers bieden een goede balans tussen de isolatie van resources en relatief weinig overhead.

  • Services die communiceren met behulp van asynchrone berichten, kunnen worden geïsoleerd via verschillende sets wachtrijen. Elke wachtrij kan een toegewezen set exemplaren hebben die berichten in de wachtrij verwerken of één groep exemplaren die een algoritme gebruiken om de verwerking uit de wachtrij te halen en te starten.

  • Bepaal het granulariteitsniveau voor de schotten. Als u bijvoorbeeld tenants over partities wilt distribueren, kunt u elke tenant in een afzonderlijke partitie plaatsen of meerdere tenants in één partitie plaatsen.

  • Bewaak de prestaties en sla (Service Level Agreement) van elke partitie.

  • Gebruik ingebouwde platformbesturingselementen, zoals frequentielimieten voor Azure API Management, isolatie van Azure Cosmos DB-aanvraageenheden (RU) en resourcelimieten in Azure Kubernetes Service (AKS) of Azure Container Apps. Maak deze beperkings- en isolatiemechanismen niet opnieuw in uw toepassingscode.

  • AI- en deductieworkloads vereisen vaak strikte schotten vanwege quota op implementatieniveau en gelijktijdigheidslimieten, bijvoorbeeld het isoleren van Azure OpenAI-implementaties per workload of per tenant.

Wanneer gebruikt u dit patroon?

Gebruik dit patroon wanneer:

  • U wilt resources isoleren voor specifieke afhankelijkheden, zodat een onderbreking in één service niet van invloed is op de hele toepassing.
  • U wilt kritieke consumenten isoleren van standaardgebruikers.
  • U moet de toepassing beschermen tegen trapsgewijze fouten.

Dit patroon is mogelijk niet geschikt wanneer:

  • Minder efficiënt gebruik van resources is mogelijk niet acceptabel in het project.
  • De toegevoegde complexiteit is niet nodig.

Werklastontwerp

Evalueer hoe u het Bulkhead-patroon in het ontwerp van een workload gebruikt om de doelstellingen en principes aan te pakken die worden behandeld in de pijlers van het Azure Well-Architected Framework. De volgende tabel bevat richtlijnen over hoe dit patroon de doelstellingen van elke pijler ondersteunt.

Pijler Hoe dit patroon ondersteuning biedt voor pijlerdoelen
betrouwbaarheid ontwerpbeslissingen helpen uw workload tolerant te worden defect te raken en ervoor te zorgen dat deze herstelt naar een volledig functionerende status nadat er een storing is opgetreden. De strategie voor foutisolatie die is geïntroduceerd via de opzettelijke en volledige segmentatie tussen onderdelen, probeert fouten te bevatten in het schot dat het probleem ondervindt, waardoor de impact op andere schotten wordt voorkomen.

- RE:02 Kritieke stromen
- RE:07 Zelfbehoud
Beslissingen over beveiligingsontwerpen helpen de vertrouwelijkheid, integriteit en beschikbaarheid van de gegevens en systemen van uw workload te waarborgen. De segmentatie tussen onderdelen helpt beveiligingsincidenten te beperken tot de aangetaste afscherming.

- SE:04 Segmentatie
Prestatie-efficiëntie helpt uw workload efficiënt te voldoen aan de vereisten door middel van optimalisaties in schalen, gegevens en code. Elk schot kan afzonderlijk schaalbaar zijn om efficiënt te voldoen aan de behoeften van de taak die is ingekapseld in het schot.

- PE:02 Capaciteitsplanning
- PE:05 Schalen en partitioneren

Als dit patroon compromissen binnen een pijler introduceert, moet u deze tegen de doelstellingen van de andere pijlers overwegen.

Voorbeeld

Het volgende Kubernetes-configuratiebestand maakt een geïsoleerde-container voor het uitvoeren van één service, met een eigen CPU, geheugenresources en limieten.

apiVersion: v1
kind: Pod
metadata:
  name: drone-management
spec:
  containers:
  - name: drone-management-container
    image: drone-service
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "1"

Volgende stappen 

  • Last updated on