Logische architectuur versus fysieke architectuur
Tip
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.
Het is op dit moment handig om het onderscheid tussen logische architectuur en fysieke architectuur te stoppen en te bespreken, en hoe dit van toepassing is op het ontwerp van microservicetoepassingen.
Om te beginnen vereist het bouwen van microservices geen specifieke technologie. Docker-containers zijn bijvoorbeeld niet verplicht om een microservicearchitectuur te maken. Deze microservices kunnen ook worden uitgevoerd als gewone processen. Microservices is een logische architectuur.
Zelfs wanneer een microservice fysiek kan worden geïmplementeerd als één service, proces of container (in het belang van eenvoud is dat de benadering in de eerste versie van eShopOnContainers), is deze pariteit tussen zakelijke microservice en fysieke service of container niet noodzakelijkerwijs vereist wanneer u een grote en complexe toepassing bouwt die bestaat uit vele tientallen of zelfs honderden services.
Hier is een verschil tussen de logische architectuur en fysieke architectuur van een toepassing. De logische architectuur en logische grenzen van een systeem wijzen niet noodzakelijkerwijs een-op-een toe aan de fysieke of implementatiearchitectuur. Het kan gebeuren, maar vaak niet.
Hoewel u bepaalde zakelijke microservices of gebonden contexten hebt geïdentificeerd, betekent dit niet dat de beste manier om ze te implementeren altijd is door één service (zoals een ASP.NET Web-API) of één Docker-container te maken voor elke zakelijke microservice. Een regel die zegt dat elke zakelijke microservice moet worden geïmplementeerd met één service of container is te stijf.
Daarom is een zakelijke microservice of gebonden context een logische architectuur die mogelijk samenvalt (of niet) met fysieke architectuur. Het belangrijkste punt is dat een zakelijke microservice of gebonden context autonoom moet zijn door code en status onafhankelijk te kunnen versiebeheer, geïmplementeerd en geschaald.
Zoals in afbeelding 4-8 wordt weergegeven, kan de catalogus zakelijke microservice bestaan uit verschillende services of processen. Dit kunnen meerdere ASP.NET web-API-services of andere soorten services zijn die gebruikmaken van HTTP of een ander protocol. Belangrijker is dat de services dezelfde gegevens kunnen delen, zolang deze services samenhangen met betrekking tot hetzelfde bedrijfsdomein.
Afbeelding 4-8. Zakelijke microservice met verschillende fysieke services
De services in het voorbeeld delen hetzelfde gegevensmodel omdat de web-API-service op dezelfde gegevens is gericht als de Search-service. In de fysieke implementatie van de bedrijfsmicroservice splitst u die functionaliteit dus op, zodat u elk van deze interne services naar behoefte omhoog of omlaag kunt schalen. Misschien heeft de web-API-service meestal meer exemplaren nodig dan de Search-service, of omgekeerd.
Kortom, de logische architectuur van microservices hoeft niet altijd samen te vallen met de fysieke implementatiearchitectuur. In deze handleiding, wanneer we een microservice noemen, bedoelen we een bedrijf of logische microservice die kan worden toegewezen aan een of meer (fysieke) services. In de meeste gevallen is dit één service, maar dit kan meer zijn.
