Shoprocket kelias į mikroservisus: 1 dalis

Praėjus keliems mėnesiams nuo mano darbo pradžios „Shoprocket“, pradėjau jausti frustraciją. Mūsų mažas, talentingų programuotojų komanda dirbo prie PHP programos, išsibarsčiusios po visą pasaulį. Kodėl aš taip jausdamasis? Man atrodė, kad klaidų taisymai sukeldavo daugiau klaidų, naujų funkcijų integravimas nebuvo toks paprastas, kaip galėtų būti, o diegimai buvo retai ir stresingi. Šių problemų priežastis: labai sujungtas kodas.

Turėjome monolitinę programą, o beveik visas mūsų kodas buvo viename Github repozitorijoje. Atnauginimai arba pataisymai vienai funkcijai dažnai vyko keliose vietose. Testavimui mes turėjome kolegų apžvalgos procesą, kurio metu bent du kiti programuotojai turėjo pritarti šakai prieš ją sujungiant su pagrindiniu įrautimu ir diegiant. Visi šie veiksmai reiškė, kad kai klaidos pavykdavo praslysti pro akis, dažnai buvo sunku rasti pertraukos pakeitimus. Ir kai jau tai padarydavome, pataisymai turėjo pereiti tą patį procesą ir visa programa turėjo būti vėl diegiama.

Būdamas entuziastingas jaunas programuotojas, nuolat ieškantis naujovių, kai susidūriau su mikroservisais, man atrodė, kad šis architektūrinis stilius išspręs visas mūsų problemas. Mikroservisų apibrėžimo nėra, tačiau iš mano tyrimų supratau, kad mikroservisų architektūra yra programinės įrangos programų projektavimo būdas kaip nepriklausomų paslaugų paskirstytos sistemos, kurios kiekviena yra specializuota ir turi savo gyvenimo ciklą. Skaitytojams, norintiems detalesnio įvado į šią sąvoką, rekomenduoju Martin Fowler puikų straipsnį.

Buvo daug aspektų, kurie mane domino mikroservisuose, tačiau du ypač: Pirmiausia, idėja padalinti programą į paslaugas su labai griežtomis ribomis. Tai sumažina galimybę, kad logika, specifinė vienam verslo kontekstui, išsilies tarp komponentų, nes sąsajos tarp ribų turi būti kruopščiai suplanuotos. Tai nėra taip paprasta kaip vietinių funkcijų skambinimas; Antra, kiekvienas komponentas gali turėti savo nepriklausomą gyvenimo ciklą. Tai leidžia komandoms perimti atsakomybę už savo kodą ir naudoti technologinį rinkinį, geriausiai tinkantį atskirai paslaugai. Taip pat tai leidžia daugiau smulkiai valdyti programą, nes pakeitimai gali būti diegiami po vieną paslaugą ir atšaukiami, neišplečiant likusios programos, jei kas nors nepavyksta.

Taigi, buvau įtikintas. „Shoprocket“ suardys monolitą! Tai pirmas trumpų tinklaraščio įrašų, sekiančių šią kelionę, serijoje. Tikiuosi, kad skaitytojai, planuojantys ar pereinantys per panašią transformaciją, išmoks iš mūsų sėkmių ir nesėkmių ir jausis geriau pasiruošę priimti šį iššūkį savo projektuose.

Mano pirmasis iššūkis nebuvo techninis, bet žmogiškas. Turėjau įtikinti likusią komandą dėl šios idėjos. Jie atrodė smalsūs, bet nepateikė tokio entuziazmo ir nenorėjo atsisakyti programavimo valandų šioje ankstyvoje mūsų produkto gyvenimo stadijoje. Laimei, CTO norėjo, kad paieškočiau mūsų sesijų valdymo ir pasinaudojau proga įtikindamas jį, kad galiu atskirti sesijų paslaugą.

Žvelgiant atgal, tai galbūt buvo ne pats geriausias pasirinkimas pirmajai paslaugai. Mūsų produktas apima javascript papildinį, kuris leidžia e-prekybą bet kuriame tinklalapyje. Mes traktuojame sesijas kaip išteklius, išsaugodami sesijos informaciją duomenų bazėje, kad galėtume detaliai analizuoti KPI, pavyzdžiui, prekių atsisaki mo rodiklius. Tačiau šis išteklius nėra toks apčiuopiamas kaip užsakymai ar linijų elementai. Be to, mes naudojome sesijų išteklius beveik su kiekvienu programos būsenos pakeitimu. Tai reiškė, kad paslauga neišvengiamai buvo labai apkalbama su likusia programa, ko aš neįvertinau, bet tai padarė mano užduotį sunkią.

Įtikindamas savo bosą, sustiprinau savo tyrimą apie mikroservisus. Be minėto straipsnio, taip pat radau Sam Newman knygą „Building Microservices“ kaip neįkainojamą šaltinį. Aš abu minėsiu dažnai savo įrašuose.

Savo knygoje Newman rekomenduoja pirmiausia restruktūruoti esamą programą į modulius, atspindinčius domeno ribotus kontekstus. Tuomet, kai programuotojai bus patenkinti, moduliai gali būti atskirti į savo paslaugas. To priežastis ta, kad daug lengviau išardyti ir perrašyti modulius, jei jų ribos buvo blogai pasirinktos, nei išardyti ir perrašyti visą paslaugą su visais jos papildomais vamzdynų kodais ir nuolatiniais ištekliais. Tačiau dėl laiko apribojimų ir mano noro sukurti savo komponentą nusprendžiau tęsti pirmąją paslaugą.

Pasirinkau technologinį krūvį, kuris buvo tik šiek tiek kitoks nei tas, kurį naudojome mūsų monolitui, ir pradėjau statyti. Statyba vyko gana greitai ir užtruko kelias savaites, kol buvo sukurtas savarankiškai veikiantis taikomasis programos su REST API. Tik tada prasidėjo tikrieji iššūkiai.

Turėjau sujungti paslaugą su monolitu. Šiuo metu sužinojau, kaip stipriai sesijų valdymas buvo susijęs su likusia kodu. Man užtruko kurį laiką, kol išardžiau esamus funkcijų skambučius ir juos konvertavau į API skambučius. Tai buvo nelengva. Kadangi sesijų paslauga ir monolitas turėjo savo duomenų bazių schemas, turėjau perrašyti bet kokią logiką monolite, kuri naudojo sesijų išteklius iš senos duomenų bazės, restruktūruodamas duomenis programos ribose, kad išlaikyčiau suderinamumą su klientais, tokiais kaip mūsų javascript papildinys.

Integruoti paslaugą su mūsų esama programa užtruko ilgiau nei ją parašyti, o tai neįskaičiavo daugelio papildomų išlaidų, kurias paprastai atneša mikroservisai, tokių kaip paslaugų atradimas, žurnalavimas ir stebėjimas. Be to, dėl stipraus sujungimo, pokyčiai buvo atliekami daugelyje kodo sričių. Kadangi komanda šiuo metu dirbo su įvairiomis kodo sritimis lygiagrečiai, reikėtų daug daugiau darbo, kad sujungtume pokyčius ir įvestume sesijų paslaugą į gamybą.

Tačiau paslauga greitai gali eiti į gamybą, tačiau dabar jaučiu, kad turėjau laikytis Newman patarimo ir skirti savo pastangas mūsų esamos programos moduliavimui. Vienos paslaugos egzistavimas individualiai yra menkas privalumas. Tikras privalumas atsiras skaidant visą dalyką, bent jau į šiurkščiai grūstinas paslaugas, kurios bendrauja kuo mažiau. Tai reikalauja labai gerai apgalvotų komponentų ribų, ir mes dar nesame ten.

Aš vis dar esu įsitikinęs mikroservisų idėja ir savo bandymą atskirti paslaugą vertinu kaip sėkmingą eksperimentą. Aš itin daug išmokau apie programų architektūrą ir domeno modeliavimą šiame procese ir pagerinau savo supratimą apie REST principus, tarp kitų dalykų. Tai turėjo tiesioginį poveikį kitose mūsų kodo srityse.

Skaitytojams, norintiems pereiti, visuomet rekomenduoju perskaityti kiek įmanoma daugiau apie šią tema ir atidėti darbą, kol būsite labai užtikrinti savo esamu kodo bazėje ir domeno modelyje. Yra kitų būdų, kaip įvesti stabilumą ir atsparumą monolitinėje programoje. Testavimo pagrindu plėtojama praktika ir automatizuoti vienetų bei funkciniai testai labai padeda. Horizontalus skalavimas taip pat padeda šiek tiek suminkštinti diegimus.

„Shoprocket“ tęs savo kelionę į mikroservisus. Laukiame, kol galėsime jums papasakoti daugiau antroje dalyje!