Duket se kulmi i zhurmës për mikroshërbimet është prapa nesh. Ne nuk lexojmë më postime disa herë në javë "Si e zhvendosa monolitin tim në 150 shërbime". Tani dëgjoj më shumë mendime të arsyeshme: "Unë nuk e urrej monolitin, më intereson vetëm efikasiteti". Madje kemi vërejtur disa migrime . Kur kaloni nga një aplikacion i madh në shumë shërbime më të vogla, do t'ju duhet të zgjidhni disa probleme të reja. Le t'i rendisim ato sa më shkurt.
Vendosja: nga kimia bazë në mekanikën kuantike
Krijimi i një baze të dhënash bazë dhe aplikimi me një proces sfondi ishte një proces mjaft i thjeshtë. Unë e publikoj readme-në në Github - dhe shpesh pas një ore, më së shumti disa orë, gjithçka funksionon dhe filloj një projekt të ri. Shtimi dhe ekzekutimi i kodit, të paktën për mjedisin fillestar, bëhet në ditën e parë. Por nëse ndërmarrim mikroshërbime, koha fillestare e nisjes rritet në qiell. Po, tani kemi Docker me orkestrim dhe një grup makinerish K8, por për një programues fillestar e gjithë kjo është shumë më e ndërlikuar. Për shumë të rinj, kjo është një barrë që është vërtet një ndërlikim i panevojshëm.
Sistemi nuk është i lehtë për t'u kuptuar
Le të përqendrohemi tek i riu ynë për një moment. Me aplikacionet monolitike, nëse ndodhte një gabim, ishte e lehtë ta gjurmosh atë dhe të kalosh menjëherë në korrigjimin e gabimeve. Tani kemi një shërbim që po flet me një shërbim tjetër që është në radhë për diçka në një autobus mesazhesh që po përpunon një shërbim tjetër - dhe më pas ndodh një gabim. Ne duhet t'i bashkojmë të gjitha këto pjesë për të zbuluar përfundimisht se Shërbimi A po ekzekuton versionin 11 dhe Shërbimi E tashmë është duke pritur për versionin 12. Kjo është shumë e ndryshme nga regjistri im standard i konsoliduar: duhet të përdor një terminal/debuger interaktiv për të ecur përmes procesit hap pas hapi. Korrigjimi dhe të kuptuarit janë bërë në thelb më të vështira.
Nëse nuk mund të korrigjohet, mbase do t'i testojmë
Integrimi i vazhdueshëm dhe zhvillimi i vazhdueshëm tani po bëhen të zakonshme. Shumica e aplikacioneve të reja që shoh krijojnë dhe ekzekutojnë automatikisht teste me çdo version të ri dhe kërkojnë që testet të kryhen dhe rishikohen përpara regjistrimit. Këto janë procese të mëdha që nuk duhen braktisur dhe kanë qenë një ndryshim i madh për shumë kompani. Por tani, për të testuar vërtet shërbimin, më duhet të nxjerr një version të plotë funksional të aplikacionit tim. E mbani mend atë inxhinierin e ri me grupin e 8 shërbimeve K150? Epo, tani do të mësojmë sistemin tonë CI se si t'i sjellë të gjitha këto sisteme për të verifikuar që gjithçka funksionon vërtet. Kjo është ndoshta shumë përpjekje, kështu që ne thjesht do të testojmë çdo pjesë në izolim: kam besim se specifikat tona janë mjaft të mira, API-të janë të pastra dhe një dështim i shërbimit është i izoluar dhe nuk do të prekë të tjerët.
Të gjitha kompromiset kanë një arsye të mirë. E drejtë?
Ka shumë arsye për të kaluar në mikroshërbime. Unë e kam parë këtë të bërë për fleksibilitet më të madh, për shkallëzimin e ekipeve, për performancën, për të ofruar qëndrueshmëri më të mirë. Por në realitet, ne kemi investuar dekada në mjete dhe praktika për të zhvilluar monolite që vazhdojnë të evoluojnë. Unë punoj me profesionistë në teknologji të ndryshme. Zakonisht flasim për shkallëzimin sepse ato shkojnë në kufijtë e një nyje të vetme të bazës së të dhënave Postgres. Shumica e bisedave kanë të bëjnë me .
Por unë jam gjithmonë i interesuar të mësoj për arkitekturën e tyre. Në cilën fazë të kalimit në mikroshërbime ndodhen? Është interesante të shohësh më shumë inxhinierë që thonë se janë të kënaqur me aplikimin e tyre monolit. Shumë njerëz do të përfitojnë nga mikroshërbimet dhe përfitimet do të tejkalojnë gungat në rrugën e migrimit. Por personalisht, ju lutem më jepni aplikacionin tim monolit, një vend në plazh - dhe unë jam plotësisht i lumtur.
Burimi: www.habr.com
