Onderdelen van een toepassing implementeren in een afzonderlijk proces of container om isolatie en inkapseling mogelijk te maken. Met behulp van dit patroon kunnen toepassingen ook worden samengesteld met heterogene onderdelen en technologieën.
Dit patroon heet Sidecar (zijspan) omdat het op de sidecar van een motor lijkt. In het patroon wordt de sidecar gekoppeld aan een bovenliggende toepassing. Daarmee worden ondersteunende functies aan de toepassing gegeven. De sidecar heeft ook dezelfde levenscyclus als de bovenliggende toepassing en wordt samen met die bovenliggende toepassing gemaakt en buiten gebruik gesteld. Het sidecar-patroon wordt soms aangeduid als het sidekick-patroon dat functioneert als een ontledingspatroon.
Context en probleem
Toepassingen en services vereisen vaak verwante functionaliteit, zoals controle, logboekregistratie, configuratie en netwerkservices. Deze neventaken kunnen worden geïmplementeerd als afzonderlijke onderdelen of services.
Als ze nauw zijn geïntegreerd in de toepassing, kunnen ze worden uitgevoerd in hetzelfde proces als de toepassing, waardoor gedeelde resources efficiënt worden gebruikt. Dit betekent echter ook dat ze niet goed geïsoleerd zijn en dat een storing in een van deze onderdelen van invloed kan zijn op andere onderdelen of de hele toepassing. Ze moeten doorgaans ook worden geïmplementeerd met behulp van dezelfde taal als de bovenliggende toepassing. Als gevolg daarvan zijn het onderdeel en de toepassing sterk van elkaar afhankelijk.
Als de toepassing is opgesplitst in services, kan elke service worden samengesteld met behulp van verschillende talen en technologieën. Hoewel dit voor meer flexibiliteit zorgt, betekent het ook dat elk onderdeel zijn eigen afhankelijkheden heeft en taalspecifieke bibliotheken vereist voor toegang tot het onderliggende platform en resources die worden gedeeld met de bovenliggende toepassing. Door deze functies als afzonderlijke services te implementeren kan bovendien latentie aan de toepassing worden toegevoegd. Het beheren van de code en afhankelijkheden voor deze taalspecifieke interfaces kan er ook toe leiden dat met name hosting, implementatie en beheer veel complexer worden.
Oplossing
Breng een coherente reeks taken onder bij de primaire toepassing, maar plaats ze wel in hun eigen proces of container, zodat er een homogene interface voor platformservices in alle talen wordt geboden.
Een sidecar-service maakt niet noodzakelijkerwijs deel uit van de toepassing, maar is daarmee verbonden. De service blijft dan in alle situaties gekoppeld aan de bovenliggende toepassing. Sidecars zijn ondersteunende processen of services die samen met de primaire toepassing zijn geïmplementeerd. Voor motoren geldt dat het zijspan (de sidecar) vastzit aan één motor en dat elke motor zijn eigen zijspan kan hebben. Op dezelfde manier is een sidecar-service gekoppeld aan de bovenliggende toepassing. Bij elk exemplaar van de toepassing wordt een exemplaar van de sidecar geïmplementeerd en gehost.
Dit zijn enkele voordelen van het gebruik van een sidecar-patroon:
Een sidecar staat los van de bijbehorende primaire toepassing in termen van runtime-omgeving en programmeertaal, dus het is niet nodig één sidecar per taal te ontwikkelen.
De sidecar heeft toegang tot dezelfde resources als de primaire toepassing. Een sidecar kan bijvoorbeeld systeembronnen controleren die door zowel de sidecar als de primaire toepassing worden gebruikt.
Vanwege de nabijheid van de primaire toepassing is er geen significante latentie bij het communiceren tussen deze toepassingen.
Zelfs voor toepassingen die geen uitbreidbaarheidsmechanisme bieden, kunt u een sidecar gebruiken om de functionaliteit uit te breiden door deze als een eigen proces in dezelfde host of subcontainer als de primaire toepassing te koppelen.
Het sidecar-patroon wordt vaak gebruikt met containers en aangeduid als een sidecar-container of sidekick-container.
Problemen en overwegingen
- Denk na over de implementatie- en verpakkingsindeling die u wilt gebruiken voor het implementeren van services, processen of containers. Containers zijn bijzonder goed geschikt voor het sidecar-patroon.
- Bij het ontwerpen van een sidecar-service moet u zorgvuldig zijn bij de keuze van de InterProcess Communication (IPC). Probeer gebruik te maken van taal- of framework-agnostische technologieën, tenzij dat onpraktisch is vanwege prestatievereisten.
- Voordat u functionaliteit in een sidecar opneemt, moet u overwegen of deze beter werkt als een afzonderlijke service of als een meer traditionele daemon.
- Denk er ook aan of de functionaliteit kan worden geïmplementeerd als een bibliotheek of met behulp van een traditioneel extensiemechanisme. Taalspecifieke bibliotheken zorgen misschien voor een dieper niveau van integratie en minder netwerkbelasting.
Wanneer dit patroon gebruiken
Gebruik dit patroon wanneer:
- Uw primaire toepassing maakt gebruik van een heterogene set talen en frameworks. Een onderdeel in een sidecar-service kan worden gebruikt door toepassingen die in verschillende talen zijn geschreven met behulp van verschillende frameworks.
- Een onderdeel is eigendom van een extern team of een andere organisatie.
- Een onderdeel of functie moet zich op dezelfde host bevinden als de toepassing.
- U hebt een service nodig die de hele levenscyclus van uw hoofdtoepassing deelt, maar wel onafhankelijk kan worden bijgewerkt.
- U hebt een fijnmazige controle over de resourcelimieten voor een bepaalde resource of specifiek onderdeel nodig. Misschien wilt u de hoeveelheid geheugen beperken waarvan een bepaald onderdeel gebruikmaakt. U kunt het onderdeel implementeren als een sidecar en het geheugengebruik onafhankelijk van de hoofdtoepassing beheren.
Dit patroon is mogelijk niet geschikt in de volgende gevallen:
- Wanneer InterProcess Communication (IPC) moet worden geoptimaliseerd. Communicatie tussen een bovenliggende toepassing en sidecar-services bestaat uit wat overhead, en dan met name uit latentie bij het aanroepen. Mogelijk is dit niet acceptabel voor chatty interfaces.
- Voor kleine toepassingen waar het voordeel van isolatie niet opweegt tegen de resourcekosten voor het implementeren van een sidecar-service voor elk exemplaar.
- Wanneer de service anders dan of onafhankelijk van de hoofdtoepassingen moet worden geschaald. In dat geval is het wellicht beter om de functie als een afzonderlijke service te implementeren.
Workloadontwerp
Een architect moet evalueren hoe het Sidecar-patroon 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:
| Pijler | Hoe dit patroon ondersteuning biedt voor pijlerdoelen |
|---|---|
| Beslissingen over beveiligingsontwerpen helpen de vertrouwelijkheid, integriteit en beschikbaarheid van de gegevens en systemen van uw workload te waarborgen. | Door deze taak in te kapselen en deze buiten het proces te implementeren, kunt u het oppervlak van gevoelige processen beperken tot alleen de code die nodig is om de taak uit te voeren. U kunt sidecars ook gebruiken om kruislingse beveiligingsmaatregelen toe te voegen aan een toepassingsonderdeel dat niet systeemeigen is ontworpen met die functionaliteit. - SE:04 Segmentatie - SE:07-versleuteling |
| Operational Excellence helpt bij het leveren van workloadkwaliteit via gestandaardiseerde processen en teamcohesie. | Dit patroon biedt een benadering voor het implementeren van flexibiliteit in de integratie van hulpprogramma's die de waarneembaarheid van de toepassing kunnen verbeteren zonder dat de toepassing directe implementatieafhankelijkheden hoeft te nemen. Hiermee kan de sidecar-functionaliteit onafhankelijk worden ontwikkeld en onafhankelijk van de levenscyclus van de toepassing worden onderhouden. - OE:04 Hulpprogramma's en processen - OE:07 Bewakingssysteem |
| Prestatie-efficiëntie helpt uw workload efficiënt te voldoen aan de vereisten door optimalisaties in schalen, gegevens, code. | U kunt kruislingse taken verplaatsen naar één proces dat kan worden geschaald op meerdere exemplaren van het hoofdproces. Hierdoor hoeft u geen dubbele functionaliteit te implementeren voor elk exemplaar van de toepassing. - PE:07 Code en infrastructuur |
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 sidecar-patroon kan op veel scenario's worden toegepast. Enkele algemene voorbeelden:
- Infrastructuur API. Het ontwikkelteam voor de infrastructuur maakt een service die bij elke toepassing wordt geïmplementeerd, in plaats van een taalspecifieke clientbibliotheek om toegang tot de infrastructuur te verschaffen. De service wordt geladen als een sidecar en biedt een algemene laag voor infrastructuurservices, waaronder logboekregistratie, omgevingsgegevens, configuratiearchief, statuscontroles en watchdog-services. De sidecar controleert ook de hostomgeving en het proces (of de container) van de bovenliggende toepassing en legt die informatie vast in een gecentraliseerde service.
- NGINX/HAProxy beheren. Implementeer NGINX met een sidecar-service die de status van de omgeving controleert, vervolgens het NGINX-configuratiebestand bijwerkt en het proces vernieuwt wanneer er een statuswijziging is vereist.
- Ambassador-sidecar. Implementeer een ambassador-service als een sidecar. De toepassing voert aanroepen uit via de ambassador, die registratie van aanvragen, routering, circuitonderbrekingen en andere aan connectiviteit gerelateerde functies afhandelt.
- Proxy-offload. Plaats een NGINX-proxy vóór een exemplaar van de service node.js-service om statische bestandsinhoud voor de service af te handelen.