Schotpatroon

Het patroon Bulkhead is een type toepassingsontwerp dat tolerant is voor fouten. In een schotarchitectuur, ook wel bekend als architectuur op basis van cellen, worden elementen van een toepassing geïsoleerd in pools, zodat de andere, indien mislukt, blijven functioneren. Het is vernoemd naar de gesectiede 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 cloud-gebaseerde toepassing kan meerdere services omvatten, waarvan elke service een of meer gebruikers kan bevatten. Overmatige belasting of een fout in een service is van invloed op alle gebruikers van de service.

Bovendien kan een gebruiker aanvragen naar meerdere services tegelijk verzenden, waarbij er resources worden gebruikt voor elke aanvraag. Wanneer de gebruiker een aanvraag verzendt naar een service die onjuist is geconfigureerd of niet reageert, kunnen de resources die worden gebruikt door de aanvraag niet tijdig worden vrijgemaakt. Als er aanvragen voor de service blijven binnenkomen, raken deze resources mogelijk uitgeput. Zo kan de verbindingsgroep van de client bijvoorbeeld uitgeput raken. Op dat moment worden aanvragen van de consument naar andere services beïnvloed. Uiteindelijk kan de gebruiker geen aanvragen verzenden naar de service die niet meer reageerde, maar ook niet meer naar andere services.

Deze uitputting van resources is ook van invloed op services met meerdere gebruikers. Als er een groot aantal aanvragen afkomstig is van één client, raken de beschikbare resources in de service mogelijk uitgeput. Andere gebruikers kunnen de service niet meer gebruiken, wat een trapsgewijze fout veroorzaakt.

Oplossing

Services moeten in verschillende groepen worden gepartitioneerd op basis van de gebruikersbelasting en beschikbaarheidsvereisten. Met dit ontwerp kunnen fouten worden geïsoleerd en blijft de functionaliteit van de service voor bepaalde consumenten behouden, zelfs wanneer er een fout optreedt.

Een gebruiker kan ook resources partitioneren, om ervoor te zorgen dat resources die worden gebruikt voor het aanroepen van de ene service geen invloed hebben op de resources die worden gebruikt voor het aanroepen van een andere service. Het is bijvoorbeeld mogelijk dat er voor elke service een verbindingsgroep wordt toegewezen aan een gebruiker die meerdere services aanroept. Als er een storing in een service optreedt, heeft dit alleen invloed op de verbindingsgroep die is toegewezen voor die service, waardoor de gebruiker de andere services kan blijven gebruiken.

Dit patroon heeft de volgende voordelen:

• Gebruikers en services worden geïsoleerd van trapsgewijze fouten. Een probleem met een gebruiker of service kan worden geïsoleerd binnen een eigen schot, waardoor wordt voorkomen dat de storing in de gehele oplossing optreedt.
• Bepaalde functies blijven behouden wanneer er een storing in een service optreedt. Andere services en functies van de toepassing blijven werken.
• U kunt services implementeren die een andere Quality of Service bieden voor het gebruik van toepassingen. Er kan een gebruikersgroep met hoge prioriteit worden geconfigureerd voor het gebruik van services met hoge prioriteit.

Het volgende diagram toont schotten die zijn gestructureerd rond verbindingsgroepen die afzonderlijke services aanroepen. Als service A uitvalt of een ander probleem veroorzaakt, wordt de verbindingsgroep geïsoleerd, zodat dit alleen invloed heeft op werkbelastingen die gebruikmaken van de threadgroep die is toegewezen aan Service A. Werkbelastingen die gebruikmaken van Service B en C worden niet beïnvloed en blijven zonder onderbreking werken.

In het volgende diagram ziet u meerdere clients die één service aanroepen. Aan elke client is een afzonderlijk service-exemplaar toegewezen. Client 1 heeft te veel aanvragen uitgevoerd en het exemplaar is overbelast. Omdat elk service-exemplaar is geïsoleerd van de andere exemplaren, kunnen de andere clients aanroepen blijven verzenden.

Problemen en overwegingen

• Definieer partities op basis van de zakelijke en technische vereisten van de toepassing.
• Als u tactische DDD gebruikt om microservices te ontwerpen, moeten partitiegrenzen overeenkomen met de gebonden contexten.
• Wanneer u services of gebruikers in schotten partitioneert, moet u rekening houden met het isolatieniveau van de technologie, evenals de overhead wat betreft kosten, prestaties en beheerbaarheid.
• U kunt overwegen schotten te combineren met de patronen Opnieuw proberen, Circuitonderbreker en Beperking voor een meer geavanceerde foutafhandeling.
• Als u gebruikers partitioneert in schotten, kunt u overwegen processen, threadgroepen en semaforen te gebruiken. Projecten zoals resilience4j en Polly bieden een kader voor het maken van consumentenschotsen.
• Wanneer u services in schotten partitioneert, kunt u overwegen ze te implementeren 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 specifieke set exemplaren hebben voor de verwerking van berichten in de wachtrij, of één groep exemplaren die gebruikmaakt van een algoritme om items uit de wachtrij te verwijderen en verzenden.
• 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.
• Controleer de prestaties en SLA van elke partitie.

Wanneer dit patroon gebruiken

U gebruikt dit patroon voor het volgende:

• Isolatie van resources die worden ingezet voor het gebruik van een set back-endservices, vooral als de toepassing een bepaald functionaliteitsniveau kan bieden, zelfs als een van de services niet reageert.
• Isolatie van kritieke gebruikers van standaardgebruikers.
• Beveiliging van de toepassing tegen trapsgewijze fouten.

Dit patroon is mogelijk niet geschikt in de volgende gevallen:

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

Workloadontwerp

Een architect moet evalueren hoe het schotpatroon kan worden gebruikt in het ontwerp van hun workload om de doelstellingen en principes te verhelpen die worden behandeld in de pijlers van het Azure Well-Architected Framework. Voorbeeld:

Net als bij elke ontwerpbeslissing moet u rekening houden met eventuele compromissen ten opzichte van de doelstellingen van de andere pijlers die met dit patroon kunnen worden geïntroduceerd.

Opmerking

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

• Betrouwbare Azure-toepassingen ontwerpen

Verwante resources

• Patroon Circuitonderbreker
• Patroon Opnieuw proberen
• Patroon Beperking