Zdá se, že vrchol humbuku pro mikroslužby je za námi. Už nečteme příspěvky několikrát týdně „Jak jsem přesunul svůj monolit na 150 služeb“. Nyní slyším více myšlenek selského rozumu: "Nenávidím monolit, jen mi záleží na účinnosti." Dokonce jsme pozorovali několik migrací . Při přechodu z jedné velké aplikace na více menších služeb budete muset vyřešit několik nových problémů. Uveďme je co nejstručněji.
Nastavení: od základní chemie po kvantovou mechaniku
Nastavení základní databáze a aplikace s procesem na pozadí byl poměrně jednoduchý proces. Zveřejňuji readme na Githubu - a často po jedné hodině, maximálně pár hodinách, vše funguje a začnu nový projekt. Přidání a spuštění kódu, alespoň pro počáteční prostředí, se provádí první den. Ale pokud se pustíme do mikroslužeb, počáteční doba spuštění raketově naroste. Ano, nyní máme Docker s orchestrací a shlukem strojů K8, ale pro začínajícího programátora je to všechno mnohem složitější. Pro mnohé juniory jde o zátěž, která je skutečně zbytečnou komplikací.
Systém není snadné pochopit
Pojďme se chvíli věnovat našemu juniorovi. U monolitických aplikací, pokud došlo k chybě, bylo snadné ji vystopovat a okamžitě přejít k ladění. Nyní máme službu, která komunikuje s jinou službou, která něco řadí do fronty na sběrnici zpráv, která zpracovává jinou službu – a pak dojde k chybě. Musíme dát všechny tyto části dohromady, abychom nakonec zjistili, že služba A běží na verzi 11 a služba E již čeká na verzi 12. To se velmi liší od mého standardního konsolidovaného protokolu: k procházení musím použít interaktivní terminál/ladicí program procesem krok za krokem. Ladění a porozumění se ze své podstaty stalo obtížnějším.
Pokud to nepůjde odladit, možná je otestujeme
Neustálá integrace a neustálý vývoj se nyní stávají samozřejmostí. Většina nových aplikací, které vidím, automaticky vytváří a spouští testy s každým novým vydáním a vyžaduje provedení a kontrolu testů před registrací. Jsou to skvělé procesy, které by se neměly opouštět a pro mnoho společností znamenaly velký posun. Ale nyní, abych službu skutečně otestoval, musím vytáhnout plnou funkční verzi své aplikace. Pamatujete si toho nového inženýra s clusterem K8 se 150 službami? No, teď naučíme náš CI systém, jak všechny tyto systémy vychovat, abychom si ověřili, že vše opravdu funguje. To je pravděpodobně příliš velké úsilí, takže otestujeme každou část izolovaně: jsem si jistý, že naše specifikace jsou dostatečně dobré, rozhraní API jsou čistá a selhání služby je izolované a neovlivní ostatní.
Všechny kompromisy mají svůj dobrý důvod. Že jo?
Existuje mnoho důvodů, proč přejít na mikroslužby. Viděl jsem to pro větší flexibilitu, pro škálování týmů, pro výkon, aby byla zajištěna lepší udržitelnost. Ale ve skutečnosti jsme investovali desetiletí do nástrojů a postupů k vývoji monolitů, které se neustále vyvíjejí. Spolupracuji s profesionály v různých technologiích. Obvykle mluvíme o škálování, protože narážejí na limity jednoho databázového uzlu Postgres. Většina rozhovorů je o .
Ale vždy mě zajímá jejich architektura. V jaké fázi přechodu na mikroslužby jsou? Je zajímavé vidět více inženýrů, kteří říkají, že jsou spokojeni se svou monolitickou aplikací. Mnoho lidí bude mít prospěch z mikroslužeb a výhody převáží nerovnosti na cestě migrace. Ale osobně mi prosím dejte mou monolitickou aplikaci, místo na pláži - a jsem naprosto šťastný.
Zdroj: www.habr.com