Container- en microservicetoepassingen ontwerpen

Aanbeveling

Deze inhoud is een fragment uit het eBook, .NET Microservices Architecture for Containerized .NET Applications, beschikbaar op .NET Docs of als een gratis downloadbare PDF die offline kan worden gelezen.

PDF downloaden

Microservices bieden grote voordelen, maar brengen ook enorme nieuwe uitdagingen met zich mee. Architectuurpatronen voor microservices zijn fundamentele pijlers bij het maken van een toepassing op basis van microservices.

Eerder in deze handleiding hebt u basisconcepten geleerd over containers en Docker. Deze informatie was het minimum dat u nodig had om aan de slag te gaan met containers. Hoewel containers een goede ondersteuning bieden voor en goed passen bij microservices, zijn ze niet verplicht voor een microservicearchitectuur. Veel architectuurconcepten in deze architectuursectie kunnen zonder containers worden toegepast. Deze handleiding richt zich echter op het snijpunt van beide vanwege het reeds geïntroduceerde belang van containers.

Bedrijfstoepassingen kunnen complex zijn en bestaan vaak uit meerdere services in plaats van één servicetoepassing. Voor deze gevallen moet u andere architectuurbenaderingen begrijpen, zoals de microservices en bepaalde Domain-Driven Ontwerppatronen (DDD) plus concepten voor containerindeling. Let op dat in dit hoofdstuk niet alleen microservices op containers worden beschreven, maar ook elke containerized applicatie.

Principes voor containerontwerp

In het containermodel vertegenwoordigt een containerimage-instantie één proces. Door een containerimage als procesgrens te definiëren, kunt u primitieven maken die kunnen worden gebruikt om het proces te schalen of te batchen.

Wanneer u een containerimage ontwerpt, ziet u een ENTRYPOINT-definitie in de Dockerfile. Deze definitie definieert het proces waarvan de levensduur de levensduur van de container bepaalt. Wanneer het proces is voltooid, eindigt de levenscyclus van de container. Containers kunnen langlopende processen vertegenwoordigen, zoals webservers, maar kunnen ook kortstondige processen vertegenwoordigen, zoals batchtaken, die voorheen als Azure WebJobs zijn geïmplementeerd.

Als het proces mislukt, wordt de container beëindigd en neemt de orchestrator het over. Als de orchestrator is geconfigureerd om vijf exemplaren actief te houden en één exemplaar mislukt, maakt de orchestrator een andere containerinstantie om het mislukte proces te vervangen. In een batchtaak wordt het proces gestart met parameters. Wanneer het proces is voltooid, is het werk voltooid. Deze richtlijnen gaan later dieper in op orkestrators.

Mogelijk vindt u een scenario waarin u meerdere processen wilt uitvoeren in één container. Voor dat scenario kunt u, omdat er slechts één toegangspunt per container kan zijn, een script uitvoeren in de container waarmee zoveel programma's worden gestart als nodig is. U kunt bijvoorbeeld Supervisor of een vergelijkbaar hulpprogramma gebruiken om meerdere processen binnen één container te starten. Hoewel u echter architecturen kunt vinden die meerdere processen per container bevatten, is die benadering niet erg gebruikelijk.

VorigeVolgende