Omezení výkonu monolitické aplikace

Dokončeno

Existuje mnoho důvodů, proč se můžete rozhodnout změnit architekturu systému. Provozní flexibilita, náklady, škálovatelnost a výkon jsou jen některými faktory, které hrají roli při určování architektury systému. V našem příkladu se podrobněji podíváme na to, jak se výkon stane faktorem pro systém doručování dronů.

S rostoucím růstem firmy pro doručování dronů Fabrikam se zvyšuje zatížení systému. Aktuální architektura se zatěžuje zatížením. Společnost Fabrikam chce zajistit lepší flexibilitu při škálování aplikace, která není dostupná v aktuální monolitické architektuře. Vylepšení škálovatelnosti aplikace je jedním z důvodů, proč Fabrikam zvažuje přesun své aplikace do architektury mikroslužeb.

Škálování monolitů vs. mikroslužeb

Jednou z hlavních výhod architektury mikroslužeb je zvýšení možností škálování. Vzhledem k tomu, že jsou služby oddělené, je jednodušší škálovat jednotlivé služby jednotlivě při nárůstu zatížení.

Tento rozdíl můžeme vidět v možnostech v systému doručování pomocí dronů. V monolitické architektuře jsou všechny služby obsaženy v jedné instanci aplikace. Zpřístupňují rozhraní API zákazníkům, aby mohli odesílat a spravovat žádosti o doručení. S rostoucím nárůstem požadavků zákazníků se zvyšuje zatížení systému. Aby se zabránilo negativnímu ovlivnění uživatelského prostředí, je potřeba přidělit systému více prostředků.

V monolitické architektuře škálování této služby jednotlivě také vyžaduje škálování prostředků pro ostatní služby, protože jsou obsaženy v jednotlivých instancích aplikace. Toto uspořádání je neefektivní, protože zatížení ostatních služeb může být minimální a nevyžaduje dodatečné využití prostředků.

V architektuře mikroslužeb, protože každá služba je samostatná, můžeme rozhraní API škálovat nezávisle na ostatních službách. Toto uspořádání zvyšuje efektivitu, protože nepotřebujeme využívat prostředky nepotřebných služeb.

Problémy s monolitickou architekturou doručování pomocí dronů

Služba balíčků byla identifikována jako kritická součást firmy a původně byla součástí monolitu. Zákazníci se na něj výrazně spoléhají a při nárůstu tohoto zatížení je negativně ovlivněn výkon. Pro řešení této situace společnost Fabrikam věnovala vývojový tým s plnou kontrolou nad touto částí firmy. Tým plánuje vyvinout a iterovat tuto službu a být výhradně zodpovědný za všechny aspekty služby balíčků.

Vzhledem k tomu, že služba balíčků je v monolitickém prostředí, nemůže tým pracovat samostatně. Musí spoléhat na sdílená data a datové struktury. Nemůžou také iterovat tak rychle, jak potřebují. Společně s problémy s výkonem a škálovatelností se tato služba identifikuje jako hlavní kandidát na mikroslužbu.

Pojďme se podrobněji podívat, jak může společnost Fabrikam analyzovat a dekompilovat aplikaci, aby využívala architekturu mikroslužeb.