It liket derop dat de peak fan hype foar mikrotsjinsten efter ús is. Wy lêze gjin berjochten mear ferskate kearen yn 'e wike "Hoe't ik myn monolith ferpleatse nei 150 tsjinsten." No hear ik mear gedachten fan sûn ferstân: "Ik haatsje de monolith net, ik skele gewoan oer effisjinsje." Wy hawwe sels ferskate migraasjes waarnommen . By it ferpleatsen fan ien grutte applikaasje nei meardere lytsere tsjinsten, sille jo ferskate nije problemen moatte oplosse. Lit ús list se sa koart mooglik.
Ynstelling: fan basischemie oant kwantummeganika
It opsetten fan in basisdatabase en applikaasje mei in eftergrûnproses wie in frij ienfâldich proses. Ik publisearje de readme op Github - en faaks binnen in oere, op syn heechst in pear oeren, wurket alles en begjin ik in nij projekt. Koade tafoegje en útfiere, teminsten foar de earste omjouwing, wurdt dien op dei ien. Mar as wy weagje oan mikrotsjinsten, rint de earste lansearringstiid op. Ja, no hawwe wy Docker mei orkestraasje en in kluster fan K8-masines, mar foar in begjinnende programmeur is dit alles folle yngewikkelder. Foar in protte junioaren is dit in lêst dy't wier in ûnnedige komplikaasje is.
It systeem is net maklik te begripen
Lit ús efkes rjochtsje op ús junior. Mei monolityske applikaasjes, as der in flater barde, wie it maklik om it op te spoaren en fuortendaliks oer te gean nei debuggen. No hawwe wy in tsjinst dy't praat mei in oare tsjinst dy't wat yn 'e wachtrige stiet op in berjochtbus dy't in oare tsjinst ferwurket - en dan is d'r in flater. Wy moatte al dizze stikken byinoar sette om úteinlik út te finen dat tsjinst A ferzje 11 draait, en tsjinst E al wachtet op ferzje 12. Dit is hiel oars as myn standert konsolidearre log: in ynteraktive terminal/debugger moatte brûke om te rinnen troch it proses stap foar stap. Debuggen en begripen binne ynherent dreger wurden.
As it net kin wurde debuggen, miskien sille wy se testen
Trochrinnende yntegraasje en trochgeande ûntwikkeling wurde no gewoanlik. De measte nije apps dy't ik sjoch automatysk tests meitsje en útfiere mei elke nije release en fereaskje dat tests wurde nommen en hifke foar registraasje. Dit binne geweldige prosessen dy't net moatte wurde ferlitten en hawwe in grutte ferskowing west foar in protte bedriuwen. Mar no, om de tsjinst echt te testen, moat ik in folsleine wurkferzje fan myn applikaasje ophelje. Unthâld dy nije yngenieur mei it K8-kluster fan 150 tsjinsten? No, no sille wy ús CI-systeem leare hoe't jo al dizze systemen ophelje om te ferifiearjen dat alles echt wurket. Dit is wierskynlik te folle muoite, dus wy sille elk diel gewoan yn isolemint testen: ik bin der wis fan dat ús specs goed genôch binne, de API's skjin binne, en in tsjinstfal is isolearre en sil gjin ynfloed hawwe op oaren.
Alle kompromissen hawwe in goede reden. Rjochts?
D'r binne in protte redenen om te ferhúzjen nei mikrotsjinsten. Ik haw dit dien sjoen foar gruttere fleksibiliteit, foar skaalfergrutting fan teams, foar prestaasjes, om bettere duorsumens te leverjen. Mar yn werklikheid hawwe wy desennia ynvestearre yn ark en praktiken om monoliten te ûntwikkeljen dy't trochgean te evoluearjen. Ik wurkje mei professionals yn ferskate technologyen. Wy prate normaal oer skaalfergrutting, om't se yn 'e grinzen rinne fan in inkele Postgres-databaseknooppunt. De measte petearen geane oer .
Mar ik bin altyd ynteressearre om te learen oer har arsjitektuer. Yn hokker stadium fan 'e oergong nei mikrotsjinsten binne se? It is nijsgjirrich om mear yngenieurs te sjen sizzen dat se bliid binne mei har monolityske tapassing. In protte minsken sille profitearje fan mikrotsjinsten, en de foardielen sille grutter wêze as de bulten yn it migraasjepaad. Mar persoanlik jou my asjebleaft myn monolityske applikaasje, in plak op it strân - en ik bin folslein bliid.
Boarne: www.habr.com