Duket se pikun i entuziazmit për mikroshërbimet e ka lënë pas. Ne nuk po lexojmë më disa herë në javë postime të tilla si "Si e transferova monolitin tim në 150 shërbime". Tani shpesh dëgjoj mendime më të arsyeshme: "Nuk e urrej monolitin, thjesht më intereson efikasiteti". Ne madje kemi vëzhguar disa migrime . Kur kaloni nga një aplikacion të madh në disa shërbime më të vogla, do t'ju duhet të zgjidhni disa probleme të reja. Le të përmendim ato sa më shkurt.
Instalimi: nga kimia bazë te mekanika kuantike
Konfigurimi i bazës së të dhënave dhe aplikacionit me një proces sfondor ishte një proces mjaft i qartë. Publikoj readme në Github - dhe shpesh pas një ore, maksimumi disa orë, gjithçka funksionon, dhe unë filloj një projekt të ri. Shtimi dhe aktivizimi i kodit, të paktën për ambientin fillestar, bëhet në ditën e parë. Por nëse ne guxojmë për mikroshërbime, koha e nisjes fillestare rritet ndjeshëm. Po, tani kemi Docker me orkestrimin dhe një grup makinash K8, por për një programues fillestar, gjithçka është shumë më e komplikuar. Për shumë juniorë, kjo është një barrë që realisht përbën një kompleksitet të panevojshëm.
Sistemi nuk është i lehtë për t'u kuptuar
Në një moment, le të ndalemi te juniori ynë. Me aplikacionet monolitike, në rast të një gabimi, ishte e lehtë të ndjehej dhe menjëherë të kalonte në debugim. Tani kemi një shërbim që komunikon me një shërbim tjetër, i cili vendos diçka në radhë në një autobus mesazhi, i cili përpunon një shërbim tjetër - dhe këtu ndodh një gabim. Ne duhet ta mbledhim bashkë të gjitha këto pjesë, për të arritur në fund që shërbimi A punon në versionin 11, ndërsa shërbimi E tashmë pret versionin 12. Kjo është shumë ndryshe nga regjistri im standard i konsoliduar: duhet të përdorim terminalin interaktiv/debugin për të kaluar nëpër procesin hap pas hapi. Debugimi dhe kuptimi në thelb janë bërë më të komplikuara.
Nëse nuk mund të debugojmë, ndoshta do t'i testojmë.
Integrimi të pandërprerë dhe zhvillimi i pandërprerë po bëhen gjithnjë e më të zakonshme. Shumica e aplikacioneve të reja që shoh, me çdo lëshim të ri, krijojnë dhe ekzekutojnë automatikisht teste dhe kërkojnë që testet të kalojnë dhe të shqyrtohen para regjistrimit. Këto janë procese të shkëlqyera që nuk duhet të anashkalohen; ato kanë sjellë një ndryshim të madh për shumë kompani. Por tani, për të vërtetuar shërbimin, duhet të ngrej një version të plotë funksional të aplikacionit tim. A e mbani mend atë inxhinierin e ri me klasterin K8 me 150 shërbime? Tani, do ta mësojmë sistemin tonë CI si të ngrejë të gjithë këto sisteme për të verifikuar që gjithçka funksionon siç duhet. Ndoshta kjo është shumë ndihmë, prandaj ne do të testojmë çdo pjesë në mënyrë të izoluar: jam i sigurt që specifikimet tona janë mjaft të mira, API-të janë të pastra, dhe shërbimi që dështoi është izoluar dhe nuk do të ndikojë te të tjerët.
Të gjitha kompromiset kanë një arsyetim të fortë. Ajo është e vërtetë?
Ka shumë arsye për të kaluar në mikroshërbime. Kam parë se bëhet për fleksibilitet më të madh, për të shkallëzuar ekipet, për performancën dhe për të siguruar qëndrueshmëri më të mirë në funksionim. Por në realitet, ne kemi investuar dekada në mjete dhe praktika për zhvillimin e monoliteve që vazhdojnë të evoluojnë. Punoj me profesionistë në teknologji të ndryshme. Zakonisht flasim për shkallëzimin, sepse ata përballen me kufijtë e një nodi të vetëm të bazës së të dhënave Postgres. Pjesa më e madhe e bisedave është e përkushtuar .
Por gjithnjĂ« mĂ« intereson tĂ« di pĂ«r arkitekturĂ«n e tyre. NĂ« cilin hap tĂ« kalimit nĂ« mikroshĂ«rbime janĂ«? ĂshtĂ« interesante tĂ« shihet se gjithnjĂ« e mĂ« shumĂ« inxhinierĂ« thonĂ« se janĂ« tĂ« kĂ«naqur me aplikacionin e tyre monolitik. PĂ«r shumĂ« mikroshĂ«rbimet do tĂ« sjellin pĂ«rfitime, dhe pĂ«rfitimet do tĂ« tejkalojnĂ« pengesat gjatĂ« migrimit. Por personalisht, do tĂ« doja, ju lutem, aplikacionin tim monolitik, njĂ« vend nĂ« plazh â dhe do tĂ« isha krejtĂ«sisht i lumtur.
Burimi: habr.com
