Tundub, et mikroteenuste haibi haripunkt on selja taga. Me ei loe enam mitu korda nädalas postitusi "Kuidas ma teisaldasin oma monoliidi 150 teenuse juurde". Nüüd kuulen rohkem kaine mõistuse mõtteid: "Ma ei vihka monoliiti, ma lihtsalt hoolin tõhususest." Vaatasime isegi mitut rännet . Ühelt suurelt rakenduselt mitmele väiksemale teenusele üleminekul peate lahendama mitu uut probleemi. Loetleme need võimalikult lühidalt.
Seadistamine: algkeemiast kvantmehaanikani
Põhiandmebaasi ja -rakenduse loomine koos taustprotsessiga oli üsna lihtne protsess. Avaldan readme Githubis – sageli ühe tunni, kõige rohkem paari tunni pärast kõik töötab ja alustan uut projekti. Koodi lisamine ja käivitamine, vähemalt esialgse keskkonna jaoks, tehakse esimesel päeval. Kui aga asume kasutama mikroteenuseid, tõuseb esialgne käivitamisaeg hüppeliselt. Jah, nüüd on meil orkestratsiooniga Docker ja K8 masinate klaster, kuid algaja programmeerija jaoks on see kõik palju keerulisem. Paljude juunioride jaoks on see koorem, mis on tõesti tarbetu komplikatsioon.
Süsteemi pole lihtne mõista
Keskendume hetkeks oma juuniorile. Monoliitsete rakenduste puhul oli tõrke ilmnemisel lihtne sellele jälile saada ja kohe silumise juurde liikuda. Nüüd on meil teenus, mis räägib teise teenusega, mis seab midagi teist teenust töötlevas sõnumisiini järjekorda – ja siis ilmneb tõrge. Peame kõik need osad kokku panema, et lõpuks teada saada, et teenus A töötab versiooniga 11 ja teenus E ootab juba versiooni 12. See erineb oluliselt minu standardsest konsolideeritud logist: kõndimiseks tuleb kasutada interaktiivset terminali/silurit. protsessi samm-sammult läbi. Silumine ja mõistmine on muutunud oma olemuselt keerulisemaks.
Kui seda ei saa siluda, siis võib-olla testime neid
Pidev integratsioon ja pidev areng on nüüdseks muutumas igapäevaseks. Enamik uusi rakendusi, mida ma näen, loovad ja käitavad automaatselt iga uue versiooniga teste ning nõuavad enne registreerimist testide läbimist ja ülevaatamist. Need on suurepärased protsessid, millest ei tohiks loobuda ja mis on olnud paljude ettevõtete jaoks suur nihe. Kuid nüüd, et teenust tõeliselt testida, pean üles tõmbama oma rakenduse täisversiooni. Kas mäletate seda uut inseneri 8 teenusest koosneva K150 klastriga? Noh, nüüd õpetame oma CI-süsteemile, kuidas kõiki neid süsteeme kuvada, et kontrollida, kas kõik tõesti töötab. See on ilmselt liiga suur pingutus, seega testime iga osa eraldi: olen kindel, et meie tehnilised andmed on piisavalt head, API-d on puhtad ja teenusetõrge on isoleeritud ega mõjuta teisi.
Kõikidel kompromissidel on mõjuv põhjus. eks?
Mikroteenustele üleminekuks on palju põhjuseid. Olen näinud seda suurema paindlikkuse, meeskondade skaleerimise, jõudluse ja parema jätkusuutlikkuse tagamiseks. Kuid tegelikult oleme aastakümneid investeerinud tööriistadesse ja tavadesse, et arendada monoliite, mis arenevad edasi. Töötan erinevate tehnoloogiate professionaalidega. Tavaliselt räägime skaleerimisest, kuna need satuvad ühe Postgresi andmebaasisõlme piiridesse. Enamik vestlusi on teemal .
Kuid ma olen alati huvitatud nende arhitektuuri tundmaõppimisest. Millises mikroteenustele ülemineku etapis nad on? Huvitav on näha rohkem insenere, kes ütlevad, et nad on oma monoliitse rakendusega rahul. Paljud inimesed saavad mikroteenustest kasu ja kasu kaalub üles rändetee konarused. Aga isiklikult, palun andke mulle minu monoliitne rakendus, koht rannas - ja ma olen täiesti õnnelik.
Allikas: www.habr.com