# Shoprocket kelionė į mikropaslaugas, 1 dalis: ką padariau ne taip skaidydamas monolitą

> Inžinerijos komandos įrašas iš ankstyvųjų Shoprocket metų apie pirmą bandymą išskirti paslaugą iš PHP monolito. Kodėl pasirinkau netinkamą pirmą paslaugą, ko mane išmokė glaudus kodo susiejimas ir kokio Newman patarimo turėjau paklausyti anksčiau.

Winston Berty  - 2016 m. kovo 17 d. - 5 min. skaitymo

Po kelių mėnesių darbo Shoprocket pradėjau nerimauti. Turėjome PHP aplikaciją, kurią kūrė nedidelė komanda aštrių programuotojų, išsibarsčiusių po visą pasaulį, ir man atrodė, kad klaidų taisymai pagimdo naujų klaidų, naujų funkcijų integravimas buvo ne toks paprastas, kokio turėtų būti, o išleidimai buvo reti ir varginantys. Priežastis: stipriai susietas kodas.

Turėjome monolitinę aplikaciją, beveik visa ji gyveno viename GitHub saugykloje. Vienos funkcijos atnaujinimas ar taisymas dažnai reikalaudavo pakeitimų keliose vietose. Testavimui turėjome peržiūros procesą: bent du kiti programuotojai turėjo patvirtinti šaką, kad ji būtų sulieta į master ir išleista. Visa tai reiškė, kad kai klaida prasprukdavo, dažnai buvo sunku surasti ją sukėlusį pakeitimą. Radus, taisymas eidavo tuo pačiu keliu, o visą aplikaciją reikėdavo išleisti iš naujo.

Būdamas uolus jaunas programuotojas, nuolat ieškantis naujovių, kai užkliuvau už mikropaslaugų, pamaniau, kad tai išspręs visas mūsų problemas.

## Ką maniau esant mikropaslaugas

Formalaus mikropaslaugų apibrėžimo nėra, bet iš savo skaitymų supratau, kad mikropaslaugų architektūra yra būdas projektuoti programinę įrangą kaip nepriklausomų paslaugų paskirstytą sistemą, kurioje kiekviena paslauga labai specializuota ir turi savo gyvavimo ciklą. Išsamiam įvadui puikiai tinka Martin Fowler [straipsnis](https://martinfowler.com/articles/microservices.html).

Mane užkabino du aspektai. Pirma, mintis padalyti aplikaciją į paslaugas su griežtomis ribomis. Tai sumažina tikimybę, kad vieno verslo konteksto logika nutekės tarp komponentų, nes sąsajas tarp ribų reikia kruopščiai suplanuoti. Tai ne toks paprastas dalykas kaip vietinių funkcijų kvietimas. Antra, kiekvienas komponentas gali turėti savo nepriklausomą gyvavimo ciklą. Komandos gali valdyti savo kodą ir naudoti paslaugai tinkamiausią technologijų rinkinį, o pakeitimus galima išleisti po vieną paslaugą ir atšaukti, neliečiant likusių.

Buvau įtikintas. Shoprocket skaidys monolitą. Tai 1 dalis iš trumpos serijos apie šią kelionę. Tikiuosi, kad panašų perėjimą planuojantys ar jį išgyvenantys skaitytojai pasimokys iš mūsų sėkmių ir klaidų.

## Pirmas iššūkis buvo žmogiškas, ne techninis

Idėją turėjau parduoti likusiai komandai. Jie buvo smalsūs, bet entuziazmo nesidalijo ir nenorėjo atiduoti programavimo valandų tokiame ankstyvame produkto etape. Laimei, technikos vadovas norėjo, kad pasižiūrėčiau į mūsų sesijų valdymą, tad pasinaudojau proga: įtikinau jį, kad galiu išskirti sesijų paslaugą.

Žvelgiant atgal, tai buvo prastas pirmos paslaugos pasirinkimas. Mūsų produkte yra JavaScript valdiklis, kuris [įjungia el. prekybą bet kurioje svetainėje](https://v3.shoprocket.io/lt/funkcijos/pardavimas-bet-kurioje-svetaineje.md). Sesijas traktuojame kaip resursą, sesijos informaciją saugome duomenų bazėje, kad galėtume analizuoti paliktus krepšelius ir kitus rodiklius. Bet šis resursas ne toks apčiuopiamas kaip užsakymai ar užsakymo eilutės, o sesijas naudojome beveik kiekvieną kartą, kai keitėsi aplikacijos būsena. Tai reiškė, kad paslauga neišvengiamai nuolat kalbėtųsi su likusia aplikacija, ko nenumačiau ir kas mano užduotį padarė sunkesnę.

## Ko išmokau ją realiai kurdamas

Sustiprinau tyrinėjimus. Šalia Fowler, Sam Newman knyga **Building Microservices** pasirodė nepakeičiamas šaltinis.

Newman patarimas, žvelgiant atgal, buvo būtent tas, kurio turėjau paklausyti: pirmiausia pertvarkyti esamą aplikaciją į modulius, atspindinčius srities ribotus kontekstus (bounded contexts). Kai programuotojai patenkinti ribomis, *tada* išskirti modulius į atskiras paslaugas. Priežastis ta, kad daug lengviau išardyti ir perrašyti modulius su blogomis ribomis nei išardyti ir perrašyti ištisas paslaugas su visu papildomu infrastruktūros kodu ir nuolatiniais resursais.

To patarimo nepaklausiau. Karštai norėdamas sukurti savo komponentą, ėmiausi sesijų paslaugos.

Pasirinkau technologijų rinkinį, tik nežymiai besiskiriantį nuo monolito, ir pradėjau kurti. Pati paslauga susidėliojo greitai: per kelias savaites gavau atskirą aplikaciją su REST API. Sunkioji dalis buvo ne ten. Sunkiausia buvo priversti paslaugą kalbėtis su monolitu.

Paaiškėjo, kad sesijų valdymas stipriai susietas su likusiu kodu. Funkcijų kvietimų keitimas API kvietimais ėjo lėtai. Kadangi sesijų paslauga ir monolitas turėjo atskiras duomenų bazių schemas, teko perrašyti visą monolito logiką, naudojusią sesijų resursus iš senosios duomenų bazės, ir restruktūrizuoti duomenis aplikacijos riboje, kad klientai, tokie kaip mūsų JavaScript valdiklis, liktų suderinami.

Integravimas užtruko ilgiau nei kūrimas. Ir tai dar neapėmė didžiosios dalies pridėtinių darbų, kuriuos paprastai atneša mikropaslaugos: paslaugų aptikimo, žurnalų, stebėsenos, paskirstyto sekimo. Dar blogiau, glaudus susiejimas reiškė, kad pakeitimai plito per daugybę kodo vietų. Kadangi komanda visą tą laiką dirbo lygiagrečiai, sulieti ir paleisti sesijų paslaugą į gamybą būtų pareikalavę daug daugiau koordinavimo, nei buvau įvertinęs.

## Sąžiningas įvertinimas

Paslauga gal netrukus pateks į gamybą. Bet dabar jaučiu, kad turėjau paklausyti Newman ir pirmiausia investuoti pastangas į esamos aplikacijos modularizavimą. Nauda iš vienos atskirai gyvenančios paslaugos menka. Tikroji nauda ateina išskaidžius visą sistemą bent į stambias paslaugas, kurios kuo mažiau tarpusavyje kalbasi. Tam reikia gerai apgalvotų komponentų ribų, o mes dar nebuvome ten.

Mikropaslaugomis kaip idėja vis dar tikiu. Savo bandymą laikau naudingu eksperimentu. Daug sužinojau apie aplikacijų architektūrą, srities modeliavimą ir REST principus, o tos pamokos turėjo šalutinį poveikį kitoms mūsų kodo dalims.

Visiems, svarstantiems panašų perėjimą, mano sąžiningos rekomendacijos:

- Prieš apsisprendžiant kuo daugiau paskaitykite apie šią temą
- Atidėkite darbą, kol tikrai užtikrintai jausitės dėl esamo kodo ir savo srities modelio
- Atminkite, kad yra ir kitų būdų suteikti monolitui stabilumo ir atsparumo. Automatiniai vienetų ir funkciniai testai padeda milžiniškai. Testais grįstas programavimas mažina regresijas. Horizontalus mastelio didinimas palengvina išleidimus
- Pradėkite nuo monolito modularizavimo, tik paskui išskirkite paslaugas

Shoprocket tęs savo kelionę. 2 dalis yra ta, kur tampa įdomiau.

---

*Iš pradžių paskelbta kaip pirma trumpos serijos dalis, dokumentuojančios ankstyvąjį Shoprocket perėjimą nuo PHP monolito. Visa kelionė, įskaitant vėlesnėse iteracijose ištaisytas klaidas, tęsėsi per kiekvieną didelį platformos perrašymą nuo to laiko.*

---

- HTML version: https://v3.shoprocket.io/lt/tinklarastis/shoprocket-kelione-i-mikropaslaugas-1-dalis
- Language: Lietuvių (lt)
- Also in: [العربية](https://v3.shoprocket.io/ar/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Deutsch](https://v3.shoprocket.io/de/blog/shoprocket-microservices-teil-1-monolith-zerlegen-fehler.md), [Ελληνικά](https://v3.shoprocket.io/el/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [English](https://v3.shoprocket.io/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Español](https://v3.shoprocket.io/es/blog/shoprocket-microservicios-parte-1-lo-que-hice-mal-monolito.md), [Français](https://v3.shoprocket.io/fr/blog/shoprocket-vers-les-microservices-partie-1-decouper-le-monolithe.md), [עברית](https://v3.shoprocket.io/he/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [हिन्दी](https://v3.shoprocket.io/hi/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Bahasa Indonesia](https://v3.shoprocket.io/id/blog/perjalanan-shoprocket-menuju-microservices-bagian-1-salah-memecah-monolit.md), [Italiano](https://v3.shoprocket.io/it/blog/viaggio-di-shoprocket-verso-i-microservizi-parte-1-cosa-ho-sbagliato-sul-monolite.md), [日本語](https://v3.shoprocket.io/ja/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Norsk](https://v3.shoprocket.io/nb/blogg/shoprockets-vei-mot-mikrotjenester-del-1-hva-jeg-tok-feil-av.md), [Nederlands](https://v3.shoprocket.io/nl/blog/shoprocket-microservices-deel-1-monoliet-opknippen.md), [Polski](https://v3.shoprocket.io/pl/blog/droga-shoprocket-do-mikroserwisow-czesc-1-rozbijanie-monolitu.md), [Português](https://v3.shoprocket.io/pt/blog/jornada-do-shoprocket-para-microsservicos-parte-1-o-que-errei-ao-quebrar-o-monolito.md), [Română](https://v3.shoprocket.io/ro/blog/drumul-shoprocket-spre-microservicii-partea-1-ce-am-gresit-cu-monolitul.md), [Русский](https://v3.shoprocket.io/ru/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [ไทย](https://v3.shoprocket.io/th/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Türkçe](https://v3.shoprocket.io/tr/blog/shoprocket-mikroservis-yolculugu-1-monoliti-parcalarken-yanlis-yaptiklarim.md), [中文](https://v3.shoprocket.io/zh/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md)