Logisk arkitektur jämfört med fysisk arkitektur
Dricks
Det här innehållet är ett utdrag från eBook, .NET Microservices Architecture for Containerized .NET Applications, tillgängligt på .NET Docs eller som en kostnadsfri nedladdningsbar PDF som kan läsas offline.
I det här läget är det bra att stoppa och diskutera skillnaden mellan logisk arkitektur och fysisk arkitektur, och hur detta gäller för utformningen av mikrotjänstbaserade program.
För att börja med att skapa mikrotjänster kräver inte användning av någon specifik teknik. Docker-containrar är till exempel inte obligatoriska för att skapa en mikrotjänstbaserad arkitektur. Dessa mikrotjänster kan också köras som oformaterade processer. Mikrotjänster är en logisk arkitektur.
Även om en mikrotjänst kan implementeras fysiskt som en enda tjänst, process eller container (för enkelhetens skull, det är den metod som används i den ursprungliga versionen av eShopOnContainers), krävs inte den här pariteten mellan affärsmikrotjänst och fysisk tjänst eller container i alla fall när du skapar ett stort och komplext program som består av många dussintals eller till och med hundratals tjänster.
Det är här det finns en skillnad mellan ett programs logiska arkitektur och fysiska arkitektur. Den logiska arkitekturen och de logiska gränserna för ett system mappar inte nödvändigtvis en-till-en till den fysiska arkitekturen eller distributionsarkitekturen. Det kan hända, men det gör det ofta inte.
Även om du kanske har identifierat vissa affärsmikrotjänster eller begränsade kontexter betyder det inte att det bästa sättet att implementera dem alltid är genom att skapa en enda tjänst (till exempel ett ASP.NET webb-API) eller en enskild Docker-container för varje företags mikrotjänst. Att ha en regel som säger att varje affärsmikrotjänst måste implementeras med en enda tjänst eller container är för strikt.
Därför är en affärsmikrotjänst eller begränsad kontext en logisk arkitektur som kan sammanfalla (eller inte) med fysisk arkitektur. Det viktiga är att en affärsmikrotjänst eller begränsad kontext måste vara autonom genom att tillåta att kod och tillstånd versionshanteras, distribueras och skalas separat.
Som bild 4–8 visar kan katalogverksamhetens mikrotjänst bestå av flera tjänster eller processer. Dessa kan vara flera ASP.NET webb-API-tjänster eller någon annan typ av tjänster som använder HTTP eller något annat protokoll. Ännu viktigare är att tjänsterna kan dela samma data, så länge dessa tjänster är sammanhängande med avseende på samma affärsdomän.
Bild 4-8. Mikrotjänst för företag med flera fysiska tjänster
Tjänsterna i exemplet delar samma datamodell eftersom webb-API-tjänsten riktar in sig på samma data som tjänsten Search. Så i den fysiska implementeringen av affärsmikrotjänsten delar du upp den funktionen så att du kan skala upp eller ned var och en av dessa interna tjänster efter behov. Webb-API-tjänsten kanske vanligtvis behöver fler instanser än tjänsten Search, eller tvärtom.
Kort och kort, den logiska arkitekturen för mikrotjänster behöver inte alltid sammanfalla med den fysiska distributionsarkitekturen. I den här guiden, när vi nämner en mikrotjänst, menar vi en affärs- eller logisk mikrotjänst som kan mappas till en eller flera (fysiska) tjänster. I de flesta fall är detta en enda tjänst, men det kan vara mer.
