Prestandabegränsningar för ett monolitiskt program
Det finns många orsaker till att du kan välja att ändra arkitekturen för ett system. Driftsflexibilitet, kostnad, skalbarhet och prestanda är bara några av de faktorer som spelar en roll när det gäller att fastställa arkitekturen i ett system. I vårt exempel tittar vi närmare på hur prestanda blir en faktor för drönarleveranssystemet.
I takt med att fabrikams drönarleveransverksamhet växer ökar systembelastningen. Den aktuella arkitekturen är ansträngd under belastningen. Fabrikam vill ge bättre flexibilitet vid skalning av programmet som inte är tillgängligt i den aktuella monolitiska arkitekturen. Att förbättra programmets skalbarhet är en av de faktorer som fabrikam kan använda för att flytta programmet till en arkitektur för mikrotjänster.
Skala en monolit jämfört med mikrotjänster
En av de främsta fördelarna med en mikrotjänstarkitektur är de ökade skalningsfunktionerna. Eftersom tjänsterna är avgränsade är det enklare att skala varje tjänst individuellt när belastningen ökar mellan dem.
Vi kan se den här skillnaden i funktioner i drönarleveranssystemet. Med en monolitisk arkitektur finns alla tjänster i en enda instans av programmet. De exponerar ett API-gränssnitt för kunder för att skicka och hantera leveransbegäranden. När kundbegäranden ökar ökar belastningen på systemet. Fler resurser måste allokeras till systemet för att undvika att användarupplevelsen påverkas negativt.
I en monolitisk arkitektur kräver skalning av den här tjänsten individuellt också skalning av resurserna för de andra tjänsterna eftersom de finns i varje programinstans. Det här arrangemanget är ineffektivt eftersom belastningen för de andra tjänsterna kan vara minimal och inte kräver extra resursanvändning.
Eftersom varje tjänst är separat i en mikrotjänstarkitektur kan vi skala API:et oberoende av de andra tjänsterna. Det här arrangemanget ökar effektiviteten eftersom vi inte behöver använda resurserna för onödiga tjänster.
Utmaningar med monolitisk arkitektur för drönarleverans
Pakettjänsten identifierades som en kritisk del av verksamheten och var ursprungligen en del av monoliten. Kunderna ökar dramatiskt sitt beroende av det och prestanda påverkas negativt när den här belastningen ökar. För att hantera den här situationen dedikerade Fabrikam ett utvecklingsteam med fullständig kontroll över den här delen av verksamheten. Teamet planerar att utveckla och iterera på den här tjänsten och vara ensamt ansvarig för alla aspekter av pakettjänsten.
Eftersom pakettjänsten finns i monoliten kan teamet inte arbeta autonomt. De måste förlita sig på delade data och datastrukturer. De kan inte heller iterera så snabbt som de behöver. Tillsammans med prestanda- och skalbarhetsproblemen identifieras den här tjänsten som en utmärkt kandidat för en mikrotjänst.
Nu ska vi titta närmare på hur Fabrikam kan analysera och dela upp sitt program för att dra nytta av en arkitektur för mikrotjänster.