Monoliit vs mikroteenused

Jutt Pythonist “skaalal”.

Põhimõtteliselt kloonisõjad. Foto autor: Tere, ma olen Nik saidil Unsplash

Mõttekatse

Oletame, et meil on veebirakendus nimega MyApp. See võib olla Django, Spring või Ruby on Rails lehel, kuid see sai alguse ühe väikese rakendusena. Kõik kood asuvad samas hoidlas, kõik on paigutatud ühte artefakti ja kõik selle tabelid asuvad samas andmebaasis. Kuna rakendus kasvab ja meelitab rohkem kasutajaid, saab see rohkem andmeid. Samuti saab see rohkem arendajaid, andmebaasis rohkem tabeleid ja majutatakse rohkem masinaid. Koodipõhi hakkab lumepalli lööma. Edukamaks saades proovime skaleerida.

See sõltub sellest, millised teemad muutuvad kõige valusamaks. Oletame näiteks, et meil on samas andmebaasis sadu tabeleid ja iga tabeli saab ühendada mis tahes muu tabeliga. Toimivusprobleemid tekivad ja tõrkeotsing või mis tahes päringu optimeerimine on segane. Looduslik lahendus hõlmaks nimede eraldamist ja eraldamist. Saame eraldada tabeleid erinevatesse andmebaasidesse ja nende ümber programmeerimisliidese eraldada. Kutsugem seda rühma MyAggregate. Ressursside edasiseks isoleerimiseks võime hostida MyAggregate'i andmebaasi eraldi arvutis. See võimaldab meil MyAggregate'i jaoks eraldada spetsiaalset protsessorit, mälu ja salvestusruumi.

Sõltuvuse haldamine oma karjääri mingil hetkel. Lihtsalt oota seda. Foto autor Martijn Baudoin saidil Unsplash

Oletame, et proovime oma dollarit veelgi venitada ja märkame, et kuigi MyAggregate'i ümbruses tehtav töö on aeglane ja mälumahukas, saab seda teha ka asünkroonselt. Geniaalne insener soovitab, et meil võiks lasta rakendusel avaldada ülesanded järjekorda, et tööd maha laadida. Seejärel kutsuksime nende ülesannete tarbimiseks samast artefaktist protsessi. Võib-olla liigutame tarbijaprotsessid ka eriotstarbelistesse hostidesse.

Mõni päev hiljem saab sama insener aru, et kui nad muudavad ainult koodi, mis mõjutab MyAggregate'i, kuid mitte ülejäänud rakendust, võivad nad juurutada just kliendi. Varsti loovad MyAggregate'il töötavad insenerid oma CI / CD-protsessi. Nad lubavad vahetada stabiilse programmeerimisliidese. Testid kirjutatakse garantiina selle liidese vastu.

Sel hetkel on meil üks artefakt, mitu andmebaasi, mitu erinevat masinat, mitu juurutamisprotsessi ja liides, mis eraldab MyAggregate'i ülejäänud MyAppist. Võiksime kaaluda isegi eraldi esemete loomist. Võib-olla hoolib keegi meeskonnast selle eseme suurusest. Mõnikord tuleb neil kiirtesti saamiseks lihtsalt tarbijaprotsess käivitada ja kogu eseme allalaadimine võib võtta liiga kaua.

Kas see on ikka monoliit? Kas see on üsna mikroteenus? Kas see on modulaarne monoliit?

Skaleeritavus ja jõudlus

Aeg-ajalt on väidetud, et mikroteenused aitavad parandada skaleeritavust ja jõudlust. Kuigi need väited ja eelised on olulised tagantjärele hindamiseks ja hindamiseks, ei ole need tavaliselt monoliidi lagunemisel peamine tõuge. See on kena boonus: monoliidi refaktoriseerimise ja lagunemise ajal saame jõudluse kasvu sageli vabastada, kustutades tehnilise võla, kirjutades ümber vana tarkvara, ümberpaigutades võrgu paigutused ja järjekorrad, jagades monoliitse andmepoe või eraldades ressursid paremaks isoleerimiseks. .

Enamikul juhtudel halvendab monoliidi purustamine tavalise RPC abil jõudlust. See lisab kriitilisesse kohta sõlme, mis võib sisend / väljundi helvestada või blokeerida. Isegi HTTP / 2 ja gRPC korral võib serialiseerimine ja valideerimine lisada piisavalt üldkulusid, et õigustada kohandatud API-sid, mis käsitlevad jagatud taotlusi.

Tegelik mastaapsus on w.r.t. töötajate arv, nii et inseneri- ja tooteorganisatsioonide spetsialiseerunud meeskonnad saaksid töötada oma erialal. See vähendab kognitiivset koormust ja kommunikatsiooni üldkulusid, kuna iga spetsialiseeritud meeskond võib sõltuda stabiilsetest eelnevatest API-dest ja keskenduda stabiilse API pakkumisele allkasutajatele. Teisisõnu, kui mõtleme mastaapsuse üle, mis motiveerib monoliitset lagunemist, mõtleme sellele, mis võib muutuste tempot kiirendada, samal ajal kui organisatsiooni kiiresti palgata ja kasvatada.

Kas see skaala?
—10 Nõuanded nutikateks ilmumiseks koosolekutel, Cooperi ülevaade

Seega, kui teil on 10 inseneri ja 100 mikroteenust, teete seda valesti.

Kuidas mikro?

Tegelik proovikivi selle kohta, kui mikro- ja kui palju see on: kas spetsialiseeritud meeskonnad saavad iseseisvalt luua ja juurutada tarkvara, mis kuulub nende vastutusalasse?

Kuni selle tingimuse saavutamiseni tuleks monoliiti lagundada ja lõpetada, kui see on just õige. Seejärel, kui organisatsioon kasvab ja spetsialiseerub veelgi, algab protsess otsast peale.

Oluline tähelepanek on see, et kui organisatsioonis puuduvad spetsiaalsed meeskonnad, on hea kasutada monoliiti. Kui enamikul kaastöötajatel on töövood, mis kattuvad ühe toote mitme funktsiooniga, aeglustab mikroteenuste liiga vara sundimine arendusprotsessi. Ühelt teisele rändamine hõlmab konteksti hulga analüüsi, mida ühe komponendi jaoks vaja oleks - nõutav kontekst peab mahtuma ühe pea sisse.

Selle testi abil saab organisatsioon vältida sattumist olukorda, kus arendaja peab töötama mitme mikroteenuse kaudu, pidades silmas kolmandate osapoolte teekide versioonide erinevusi ja tegeledes iga muudatuse jaoks iga mikroteenuse eraldi kasutuselevõtuga. Samuti väldib see ka tavalist anti-mustrit, kus ühelt monoliidilt minnakse üle hulga aneemiliste CRUD-teenuste juurde.

Mõelge näiteks organisatsioonile, kus on umbes 60 inseneri ja kellel pole keskastme juhte. See viiakse läbi oluliste ümberkorralduste abil ja luuakse 5 insenerist koosnev spetsialiseeritud meeskond, kes vastutab ainult jagatud sõnumikomponendi hooldamise eest, mida saab kasutada kõigis toodetes. Tõenäoliselt saab see meeskond pühendunud juhi ja kuigi on olemas kogu ettevõtte KPI-d, hinnatakse seda meeskonda (ja stimuleeritakse) peamiselt sõnumsidekomponendi töökindluse ja toimivuse põhjal.

Need mõõdikud võivad hõlmata:

  • iga saatmistaotluse latentsus,
  • - kadude määr või tarneaste ja -
  • kas see võib vähem kui 2 tunni jooksul saata miljoneid e-kirju, teatisi ja tekstsõnumeid turunduskampaania jaoks.

Nüüd on see meeskond küps sõnumside API-liistu välja töötama ja selle komponendi monoliidist välja murdma, et nad saaksid seda iseseisvalt arendada, juurutada, jälgida ja toetada. See värskelt vermitud meeskond võiks isegi pidada läbirääkimisi erinevate SLA-de jaoks nende sidusliideste ja võrguühenduseta pakkide API-de osas. Oluline on märkida, et igapäevase töökorralduse osana ei pea nad välja mõtlema, kuidas sülearvutitel muid teenuseid (üles või allavoolu) käitada. CI / CD-protsess ei pruugi isegi teisi teenuseid käivitada, kuigi hoolikas tooteomanik testiks enne tootmisesse viimist olulisi muudatusi laval.

Kui see meeskond vastutab ka oma kasutajate kommunikatsioonieelistuste säilitamise eest, saavad nad uue loomise asemel valida selle funktsiooni ühendamise samasse sõnumside (mikro) teenusesse ja laiendada selle API-t.

Mikroteenused kaamera sees. Nad on väikesed. Foto autor Vadim Šerbakov saidil Unsplash

Kas see on mikro? Ma ei tea, kuid nad on kindlasti varasematest produktiivsemad ja joovad reedel Happy Houris, selle asemel et paluda kahetsusväärselt telefonilt luba monoliidi kasutamiseks pärast tavalist tundi.

CI ja arendaja kogemus

Selgub, et mikroteenustele eduka ülemineku olulisemad aspektid on kohaletoimetamise infrastruktuur ja DevX. Kuna meie eesmärk on kiirendada muutuste tempot, on need palju olulisemad kui valimine aRPC / gRPC / mRPC / 0rpc või kasutatava mikroteenuste raamistiku vahel. Lisaks on igal organisatsioonil erinevad harjumused ja ootused ning sel põhjusel ei saa te üle minna monoliidist sadadesse mikroteenustesse üleöö. Esimeste lagunenud teenuste kinnituspunktide täpsustamiseks ja vastuvõetava testimisstrateegia väljatöötamiseks on vaja pühendunud jõupingutusi. See hõlmab tööriistade väljatöötamist

  • kinnitada API-de stabiilsust ja ühilduvust,
  • aidata arendajatel teenuseid kohapeal käivitada ja peatada,
  • aitab arendajatel leida mõõdikuid ja logisid kõigis keskkondades,
  • - saata teatisi ja teateid õigetele inimestele, kellel on teenuse tervis ohus, ja -
  • võimaldada operaatoritel ja arendajatel tõrkeotsingut ja iga teenuse probleemide lahendamist.

See on tõeline töö, mis parandab mastaapsust.

Nägu, mis saate, kui ütlete 2019. aastal „DevOps”. „DevX” ja „o11y” võivad teid ilmselt targemaks muuta. Foto: Ben White saidil Unsplash

Raamatukogude jagamine

Üks olulisemaid otsuseid saab olema kolmanda osapoole sõltuvuste ja sisemiste raamatukogude haldamine. Vastamiseks on palju keerulisi küsimusi, sealhulgas:

  • Kas kõik esemed peaksid jagama samu versioone kõigist kolmanda osapoole teekidest? Kas sisemised raamatukogud peaksid tegema koostööd paljude kolmanda osapoole raamatukogudega? Kuidas seda katsetatakse?
  • Milline on kolmanda osapoole teegi väiksema versiooni täiendamise protsess? duur? Kes selle eest vastutab?
  • Kas kõik esemed peaksid kasutama kõigi sisemiste raamatukogude HEAD-i? Kas sisemised raamatukogud peaksid selle asemel kasutama semantilist versioonimist?
  • Kes vastutab sisemiste raamatukogude pidamise eest? Kes uuendab erinevates esemetes kasutatavat versiooni? Mitu suurt versiooni oleks vaja toetada?
  • Kuidas lahendatakse siseraamatukogude või kolmanda osapoole raamatukogude versioonide konfliktid?
  • Milline on protsess, mille abil tagatakse, et uuendame mõistlikult sisemiste või kolmandate osapoolte raamatukogude uusimat versiooni?
  • Kuidas täpsustatakse iga eseme ehitamise materjalide arve?
  • Kuidas kontrollida tsüklilisi sõltuvusi sisemistes raamatukogudes?

Arvamusi on palju erinevaid ja organisatsiooni loomiseks selle töö tegemiseks on palju võimalusi. Siiski on oluline mõista, et halva haldamise korral on see probleem, ning sellest saab hõõrdumise ja tüli tekitaja. Kui lubate kolmanda osapoole raamatukogude versioonidel artefaktide vahel erineda, võib eri meeskondadel olla hõlpsam uuendada olulist teeki eraldi ajakavade alusel, kuid selleks on vaja, et mõjutatud sisemised teegid toetaksid mitmeid peamisi versioone.

See võiks olla köitev võimalus kõik kokku tõmmata, kuid ilma selgete kohustuste ja uuendusprotsessita võivad projektid pikka aega varjata vananenud ja potentsiaalselt haavatavaid sõltuvusi.

Kas teie organisatsiooni jaoks sobib monoliit? Kas teenustele orienteeritud arhitektuur on sobiv? See on harva üks või teine ​​ning kaaluda tuleb olulisi kompromisse. Seisake vastu kiusatusele ametikohale asuda. Selle asemel õppige valvama heade / halbade kompromisside ja varajase / hilise ülemineku märkide eest. Analüüsige iga hõõrdeallikat, et teada saada, kas seda saab DevX-i häälestamise abil parendada.

Ka naljatlemine: see ei puudutanud kunagi seda, kuidas me oma monoliidi 100 mikroteenusele üle viisime.

Rohkem lugemist

  • https://engineering.shopify.com/blogs/engineering/deconstructing-monolith-designing-software-maximizes-developer-productivity
  • https://medium.com/@dan_manges/the-modular-monolith-rails-architecture-fb1023826fc4
  • https://martinfowler.com/articles/break-monolith-into-microservices.html
  • https://segment.com/blog/goodbye-microservices/
  • http://www.craigkerstiens.com/2019/03/13/give-me-back-my-monolith/