Panašu, kad mikropaslaugų ažiotažas jau už nugaros. Mes nebeskaitome kelis kartus per savaitę pranešimų „Kaip aš perkėliau savo monolitą į 150 paslaugų“. Dabar girdžiu daugiau sveiko proto minčių: „Aš neapkenčiu monolito, man tiesiog rūpi efektyvumas“. Stebėjome net keletą migracijų iš mikropaslaugų atgal į monolitą. Pereinant nuo vienos didelės programos prie kelių mažesnių paslaugų, turėsite išspręsti keletą naujų problemų. Išvardinkime juos kuo trumpiau.

Nustatymas: nuo pagrindinės chemijos iki kvantinės mechanikos

Pagrindinės duomenų bazės ir programos nustatymas naudojant foninį procesą buvo gana paprastas procesas. Aš paskelbiu skaitymą „Github“ - ir dažnai po vienos valandos, daugiausiai poros valandų viskas veikia, ir aš pradedu naują projektą. Kodo pridėjimas ir vykdymas, bent jau pradinei aplinkai, atliekamas pirmą dieną. Bet jei imsimės mikropaslaugų, pradinis paleidimo laikas smarkiai padidės. Taip, dabar turime „Docker“ su orkestravimu ir K8 mašinų grupę, tačiau pradedantiesiems programuotojui visa tai yra daug sudėtingiau. Daugeliui jaunių tai yra našta, kuri yra tikrai nereikalinga komplikacija.

Sistema nėra lengvai suprantama

Trumpam susitelkime į savo jaunesnįjį. Naudojant monolitines programas, jei įvyko klaida, buvo lengva ją atsekti ir nedelsiant pereiti prie derinimo. Dabar turime paslaugą, kuri bendrauja su kita tarnyba, kuri kažką iškelia į pranešimų magistralę, kuri apdoroja kitą paslaugą, ir tada įvyksta klaida. Turime sujungti visas šias dalis, kad galiausiai sužinotume, kad paslauga A veikia 11 versijos, o paslauga E jau laukia 12 versijos. Tai labai skiriasi nuo mano standartinio konsoliduoto žurnalo: norint vaikščioti reikia naudoti interaktyvų terminalą / derintuvą. per procesą žingsnis po žingsnio. Derinimas ir supratimas iš prigimties tapo sunkesnis.

Jei nepavyks derinti, galbūt mes juos išbandysime

Nuolatinė integracija ir nuolatinis tobulėjimas dabar tampa kasdienybe. Dauguma naujų programų, kurias matau, automatiškai sukuria ir vykdo kiekvieno naujo leidimo testus ir reikalauja atlikti testus ir juos peržiūrėti prieš registraciją. Tai puikūs procesai, kurių nereikėtų atsisakyti ir kurie daugeliui įmonių buvo didelis poslinkis. Tačiau dabar, kad tikrai išbandyčiau paslaugą, turiu sukurti visą veikiančią programos versiją. Prisimenate tą naują inžinierių, turintį 8 paslaugų K150 klasterį? Na, dabar mes išmokysime savo CI sistemą, kaip pakelti visas šias sistemas, kad patikrintume, ar viskas tikrai veikia. Tai tikriausiai yra per daug pastangų, todėl mes tik išbandysime kiekvieną dalį atskirai: esu įsitikinęs, kad mūsų specifikacijos yra pakankamai geros, API yra švarios, o paslaugos gedimas yra atskirtas ir neturės įtakos kitiems.

Visi kompromisai turi rimtą priežastį. Tiesa?

Priežasčių pereiti prie mikropaslaugų yra daug. Mačiau, kad tai daroma siekiant didesnio lankstumo, komandų dydžio, našumo ir geresnio tvarumo. Tačiau iš tikrųjų mes dešimtmečius investavome į įrankius ir praktiką, kad sukurtume monolitus, kurie ir toliau vystosi. Dirbu su įvairių technologijų profesionalais. Paprastai kalbame apie mastelio keitimą, nes jie patenka į vieno Postgres duomenų bazės mazgo ribas. Dauguma pokalbių yra apie duomenų bazės mastelio keitimas.

Bet man visada įdomu sužinoti apie jų architektūrą. Kokiame perėjimo prie mikropaslaugų etape jie yra? Įdomu matyti, kad daugiau inžinierių sako, kad yra patenkinti savo monolitiniu pritaikymu. Daugeliui žmonių bus naudingos mikropaslaugos, o nauda bus didesnė už migracijos kelio nelygumus. Bet asmeniškai prašau duoti man savo monolitinę aplikaciją, vietą paplūdimyje – ir aš esu visiškai laimingas.

Šaltinis: www.habr.com