Nespadnite do pasce „Mikroservisy sú cool“ a vedzte, kedy sa radšej držať monolitu

Monolity a mikroslužby sú dva základné prístupy k budovaniu aplikácií. Niektorí ich považujú za dedičné a moderné, resp. Ale to nie je celkom správne. Výber medzi nimi je veľmi zložitá otázka, pričom obe majú svoje klady aj zápory.

Väčšina nových aplikácií nemusí byť hneď od začiatku mikroslužbami. Je rýchlejšie, jednoduchšie a lacnejšie začať ako monolit a prejsť na mikroslužby neskôr, ak to považujete za prospešné.

Postupom času, keď sa monolitné aplikácie stávajú menej a menej udržiavateľné, niektoré tímy sa rozhodnú, že jediný spôsob, ako vyriešiť problém, je začať refaktorovať rozdelením ich aplikácie na mikroslužby. Ostatné tímy robia toto rozhodnutie len preto, že „mikroslužby sú cool“. Tento proces si vyžaduje veľa času a niekedy prináša ešte väčšiu réžiu údržby. Predtým, ako sa do toho pustíte, je dôležité dôkladne zvážiť všetky výhody a nevýhody a uistiť sa, že ste dosiahli svoje súčasné limity architektúry monolitov. A pamätajte, že je ľahšie rozbiť ako postaviť.

V tomto článku nebudeme porovnávať monolity s mikroslužbami. Namiesto toho budeme diskutovať o úvahách, vzoroch a princípoch, ktoré vám pomôžu:

• získať to najlepšie zo svojho súčasného monolitu a potenciálne ho pripraviť na prienik do mikroslužieb;
• zabezpečiť bezproblémovú migráciu z monolitu na mikroslužby;
• pochopiť, čo sa ešte môže zmeniť migráciou mikroslužieb.

Modulárny monolit

Prvá vec, ktorú by ste mali urobiť, je pozrieť sa na štruktúru vášho projektu. Ak moduly nemáte, dôrazne vám ich odporúčam zvážiť. Nenútia vás zmeniť architektúru na mikroslužby (čo je dobré, pretože sa chceme vyhnúť všetkej zodpovedajúcej údržbe), ale brať z nich mnohé výhody.

V závislosti od vášho nástroja na automatizáciu tvorby projektu (napr. maven, gradle alebo iného) môžete svoj projekt rozdeliť na samostatné, nezávislé moduly. Niektoré moduly môžu byť spoločné pre iné, zatiaľ čo iné môžu zapuzdrovať špecifické oblasti domény alebo môžu byť špecifické pre jednotlivé funkcie, čím vnášajú do vašej aplikácie nezávislú funkčnosť.

Poskytne vám nasledujúce výhody:

1. Odpojené časti vašej aplikácie.
2. Funkcie môžu byť vyvinuté nezávisle, čím sa minimalizujú konflikty.
3. Je oveľa jednoduchšie prijať nových ľudí, pretože sa nemusia ponoriť hlboko do celého projektu; namiesto toho môžu začať od izolovaných častí.
4. Vylepšené testovanie, pretože teraz môžete testovať každý modul samostatne.
5. Ak nakoniec potrebujete migrovať na mikroslužby, máte na to veľmi silný základ.

Ako vidíte, modulárny monolit je spôsob, ako získať to najlepšie z oboch svetov. Je to ako prevádzkovanie nezávislých mikroslužieb v rámci jedného monolitu, ale vyhýbanie sa réžii vedľajších mikroslužieb. Jedným z obmedzení, ktoré môžete mať – je nemožnosť škálovať rôzne moduly nezávisle. Budete mať toľko monolitných inštancií, koľko vyžaduje najviac zaťažený modul, čo môže viesť k nadmernej spotrebe zdrojov. Ďalšou nevýhodou sú obmedzenia používania rôznych technológií. Napríklad nemôžete kombinovať Java, Golang a Python v modulárnom monolite, takže ste nútení držať sa jednej technológie (čo zvyčajne nie je problém).

Vzor Strangler Fig

Myslite na vzor Strangler Fig. Svoj názov má podľa stromu, ktorý sa ovinie a nakoniec nahradí svojho hostiteľa. Podobne vzor navrhuje, aby ste nahradili časti starej aplikácie novými službami jednu po druhej, čím modernizujete starý systém bez toho, aby ste spôsobili výrazné narušenie.

Namiesto toho, aby ste sa pokúšali o riskantnú a komplexnú opravu, aktualizujete systém kúsok po kúsku. Táto metóda je výhodná pri práci s veľkými, zložitými monolitmi, ktoré sú príliš nepraktické na to, aby sa dali nahradiť jedným úsilím. Prijatím vzoru Strangler Fig môžu tímy pomaly postupne vyraďovať starý systém a zároveň podporovať rast nového, minimalizovať riziká a zabezpečiť nepretržité poskytovanie hodnoty.

Ak chcete implementovať vzor Strangler Fig, musíte vykonať tri kroky:

1. Transformovať. Tu identifikujete, ktorá časť sa má extrahovať z monolitu a implementujete ju ako samostatnú mikroslužbu. Prepíšte túto časť pomocou moderných technológií a riešte problémy predchádzajúcej implementácie. Využite šancu urobiť to lepšie.
2. Koexistovať. Keď je nová mikroslužba pripravená na produkciu, spustíte ju vo svojej infraštruktúre, pričom zachováte starú implementáciu. Rozdeľujete návštevnosť v určitom pomere, postupne presúvate stále viac návštevnosti do novej implementácie, ale vždy máte svoju predchádzajúcu verziu ako rollback.
3. Eliminovať. Po určitom čase, keď si myslíte, že vaša nová mikroslužba je dostatočne spoľahlivá, presuňte všetku návštevnosť do novej mikroslužby a odstráňte starú.

Týmito tromi krokmi postupne rozbijete monolit na mikroslužby.

Kľúčové výhody použitia vzoru Strangler Fig sú:

• Postupná migrácia. Namiesto toho, aby ste prelomili zlé a začali včasné, zdrvujúce a riskantné úplné prepracovanie systému, vzor vám umožňuje prechod krok za krokom. Môžete pomaly aktualizovať svoj systém a synchronizovať túto transformáciu s plánmi vývoja funkcií. Môžete napríklad nájsť časť monolitu, ktorú vývoj niektorých funkcií vážne ovplyvní, a vybrať si ju ako kandidáta na migráciu mikroslužieb.
• Nepretržité doručovanie. Táto výhoda vychádza z predchádzajúceho tvrdenia. Proces modernizácie nebráni vášmu tímu v neustálom dodávaní nových funkcií. Zatiaľ čo jeden tím vyvíja nové funkcie, iný refaktoruje nezávislé moduly.
• Zmierňovanie rizika. Vzor Strangler Fig pomáha tímu zamerať sa na modernizáciu konkrétnych častí systému. Toto zameranie umožňuje tímu venovať väčšiu pozornosť detailom v konkrétnych oblastiach, nájsť potenciálne problémy skôr a minimalizovať celkový dopad na aplikáciu.

Problémy a úvahy

Pri aplikácii vzoru Strangler Fig by ste si mali starostlivo naplánovať stratégiu migrácie. Zahŕňa identifikáciu komponentov, ktoré treba nahradiť ako prvé, zabezpečenie správnej integrácie medzi starými a novými časťami a udržiavanie konzistentných dátových modelov. Tímy by tiež mali vytvoriť jasné komunikačné kanály a monitorovacie systémy na sledovanie pokroku a vplyvu každej výmeny.

Dôsledky migrácie mikroslužieb

Ako sme už diskutovali, prechod na mikroslužby prináša výhody. Sťažuje a predražuje však aj mnohé iné veci.

Napríklad tímy QA a Dev môžu čeliť situácii, keď už nebudú môcť testovať na lokálnych počítačoch, pretože schopnosť spúšťať viaceré mikroslužby lokálne je obmedzená. Alebo môžu byť vaše denníky menej prehľadné, pretože namiesto toho, aby jedna služba spracúvala jeden tok, ho teraz spracúvajú viaceré služby. Výsledkom je, že na zobrazenie kompletnej postupnosti protokolu musíte implementovať správne prístrojové vybavenie a sledovanie.

Poďme diskutovať o niekoľkých zásadných aspektoch, ktoré by ste mali zvážiť a možno naplánovať pred začatím transformácie mikroslužieb.

Rozmiestnenie a infraštruktúra

Monolit a mikroslužby majú rôzne minimálne požiadavky na infraštruktúru.

Pri spustení monolitnej aplikácie môžete zvyčajne udržiavať jednoduchšiu infraštruktúru. Postačia možnosti ako virtuálne stroje alebo riešenia PaaS (napríklad AWS EC2). Väčšinu škálovania, konfigurácie, upgradov a monitorovania môžete zvládnuť aj manuálne alebo pomocou jednoduchých nástrojov. V dôsledku toho sa môžete vyhnúť zložitým nastaveniam infraštruktúry a spoľahnúť sa na vývojárov alebo podporných inžinierov bez toho, aby ste potrebovali rozsiahle odborné znalosti DevOps.

Prijatie architektúry mikroslužieb však túto dynamiku mení. Ako počet služieb rastie, manuálny, praktický prístup sa rýchlo stáva nepraktickým. Ak chcete efektívne organizovať, škálovať a spravovať viacero služieb, budete potrebovať špecializované platformy ako Kubernetes alebo aspoň spravovanú kontajnerovú službu, ktorá prináša novú vrstvu zložitosti a prevádzkových požiadaviek.

Platformová vrstva

Udržiavanie aplikácie monolitu je pomerne jednoduché. Ak vznikne CVE, aktualizujete ovplyvnenú závislosť na jednom mieste. Potrebujete štandardizovať externú servisnú komunikáciu? Implementujte jeden obal a znova ho použite v celej kódovej základni.

V prostredí mikroslužieb sa tieto jednoduché úlohy stávajú oveľa zložitejšími. To, čo bolo predtým triviálne, teraz zahŕňa koordináciu zmien vo viacerých nezávislých službách, z ktorých každá má svoj životný cyklus a závislosti. Pridaná zložitosť zvyšuje náklady na čas aj zdroje. A situácia sa zhoršuje, keď máte veľa tímov a veľa rôznych služieb.

Preto mnohé organizácie zavádzajú vyhradenú platformovú vrstvu, ktorú zvyčajne riadi tím platformy. Cieľom je vytvoriť základ, ktorý môžu zdediť všetky mikroslužby: správa bežných závislostí, implementácia štandardizovaných vzorov a poskytovanie hotových obalov. Zjednotením týchto prvkov na úrovni platformy výrazne zjednodušíte údržbu a podporíte konzistentnosť v rámci celého systému.

Záver

Rozbitie monolitu na mikroslužby je významnou architektonickou transformáciou, ktorá si vyžaduje starostlivé zváženie a plánovanie.

V tomto článku sme rozobrali kroky, ktoré môžete podniknúť, aby ste sa naň pripravili a proces prešiel hladko. Držanie sa vzoru Strangler Fig vám poskytne postupný proces a zabezpečí stabilitu systému počas celej transformácie. Modulárny monolit môže byť nielen užitočným prípravným krokom, ale môže priniesť aj výhody, ktoré vás môžu podnietiť k prehodnoteniu vášho rozhodnutia o transformácii mikroslužieb a vyhnúť sa zodpovedajúcej prevádzkovej zložitosti.