19. septembril Moskvas esimene temaatiline kohtumine HUG (Highload++ User Group), mis oli pühendatud mikroteenustele. Toimus ettekanne “Operating Microservices: Size Matters, Even If You Have Kubernetes”, kus jagasime Flanti laialdasi kogemusi mikroteenuste arhitektuuriga projektide opereerimisel. Esiteks on see kasulik kõigile arendajatele, kes kaaluvad selle lähenemisviisi kasutamist oma praeguses või tulevases projektis.
Tutvustame (50 minutit, palju informatiivsem kui artikkel), samuti selle peamine väljavõte teksti kujul.
NB: Video ja esitlus on saadaval ka selle postituse lõpus.
Sissejuhatus
Tavaliselt on heal lool algus, põhilugu ja lahendus. See aruanne on pigem eelmäng ja seejuures traagiline. Samuti on oluline märkida, et see annab kõrvalseisja ülevaate mikroteenustest. ärakasutamine.
Alustan sellest graafikust, mille autor (2015. Martin Fowler:
See näitab, kuidas monoliitse rakenduse puhul, mis saavutab teatud väärtuse, hakkab tootlikkus langema. Mikroteenused erinevad selle poolest, et esialgne tootlikkus on nendega madalam, kuid keerukuse kasvades pole efektiivsuse halvenemine nende jaoks nii märgatav.
Kubernetese kasutamise puhul lisan sellele graafikule:
Miks on mikroteenustega rakendus parem? Sest selline arhitektuur seab arhitektuurile tõsised nõuded, mis omakorda on Kubernetese võimalustega suurepäraselt kaetud. Teisest küljest on osa sellest funktsionaalsusest kasulik monoliidi jaoks, eriti kuna tüüpiline monoliit tänapäeval ei ole täpselt monoliit (üksikasjad on aruandes hiljem).
Nagu näete, ei erine lõplik graafik (kui Kubernetesega infrastruktuuris on nii monoliitsed kui ka mikroteenuste rakendused) algsest väga palju. Järgmisena räägime Kubernetese abil töötavatest rakendustest.
Kasulikud ja kahjulikud mikroteenused
Ja siin on peamine idee:
Mis on normaalne mikroteenuste arhitektuur? See peaks tooma teile tõelist kasu, suurendades teie töö efektiivsust. Kui läheme tagasi graafiku juurde, siis siin on see:
Kui sa talle helistad kasulik, siis on graafiku teisel küljel kahjulikud mikroteenused (segavad tööd):
Tulles tagasi “põhimõtte” juurde: kas ma peaksin oma kogemust üldse usaldama? Selle aasta algusest olen vaadanud 85 projekti. Kõik need ei olnud mikroteenused (umbes kolmandikul kuni pooltel oli selline arhitektuur), kuid see on siiski suur arv. Meil (Flant firmal) kui allhankijatel õnnestub näha väga erinevaid rakendusi, mida arendatakse nii väikeettevõtetes (5 arendajaga) kui ka suurtes (~500 arendajat). Täiendav eelis on see, et näeme neid rakendusi reaalajas ja arenevad aastate jooksul.
Miks mikroteenused?
Küsimusele mikroteenuste eeliste kohta on olemas juba mainitud Martin Fowlerilt:
- selged modulaarsuse piirid;
- sõltumatu kasutuselevõtt;
- vabadus valida tehnoloogiaid.
Olen palju rääkinud tarkvaraarhitektide ja -arendajatega ning küsinud, miks neil mikroteenuseid vaja on. Ja ma koostasin oma nimekirja nende ootustest. See juhtus järgmiselt.
Kui kirjeldame mõnda punkti "aistingus", siis:
- moodulite selged piirid: siin on meil kohutav monoliit ja nüüd on kõik Giti hoidlates kenasti paigutatud, kus kõik on "riiulitel", soe ja pehme pole segunenud;
- juurutamise sõltumatus: saame teenuseid iseseisvalt kasutusele võtta, et arendus toimuks kiiremini (uute funktsioonide avaldamine paralleelselt);
- arendussõltumatus: saame anda selle mikroteenuse ühele meeskonnale/arendajale ja selle teisele, tänu millele saame kiiremini areneda;
- боsuurem töökindlus: kui toimub osaline halvenemine (üks mikroteenus 20-st kukkumisest), lakkab töötamast ainult üks nupp ja süsteem tervikuna töötab edasi.
Tüüpiline (kahjulik) mikroteenuste arhitektuur
Selgitamaks, miks reaalsus pole see, mida me ootame, esitan kollektiivne pilt mikroteenuste arhitektuurist, mis põhineb paljude erinevate projektide kogemustel.
Näiteks võib tuua abstraktse veebipoe, mis hakkab konkureerima Amazoni või vähemalt OZONiga. Selle mikroteenuse arhitektuur näeb välja selline:
Mitmel põhjusel on need mikroteenused kirjutatud erinevatele platvormidele:
Kuna igal mikroteenusel peab olema autonoomia, vajavad paljud neist oma andmebaasi ja vahemälu. Lõplik arhitektuur on järgmine:
Millised on selle tagajärjed?
Fowleril on ka see — mikroteenuste kasutamise eest maksmise kohta:
Ja vaatame, kas meie ootused said täidetud.
Selge moodulite piirid...
Kuid mitu mikroteenust me tegelikult parandama peame?muudatust ellu viia? Kas saame üldse aru, kuidas kõik ilma hajutatud jälgimisseadmeta toimib (kõik päringud töötlevad ju pooled mikroteenustest)?
Seal on muster"“, ja siin selgus, et see on hajutatud mustusetükk. Selle kinnitamiseks on siin ligikaudne näide päringute edenemisest.
Kasutuselevõtu sõltumatus...
Tehniliselt on see saavutatud: saame iga mikroteenuse eraldi kasutusele võtta. Kuid praktikas peate arvestama, et see veereb alati välja palju mikroteenuseid, ja me peame sellega arvestama nende levitamise järjekord. Heas mõttes peame üldiselt eraldi vooluringis testima, kas laseme väljalaske õiges järjekorras välja.
Tehnika valikuvabadus...
Ta on. Pidage meeles, et vabadus piirneb sageli seaduserikkumisega. Siin on väga oluline mitte valida tehnoloogiaid lihtsalt nendega “mängimiseks”.
Arengu sõltumatus...
Kuidas teha testtsüklit kogu rakenduse jaoks (nii paljude komponentidega)? Kuid peate seda siiski ajakohasena hoidma. Kõik see viib selleni, testahelate tegelik arv, mida saame põhimõtteliselt sisaldada, osutub minimaalseks.
Kuidas oleks selle kõige kohapeal juurutamisega?.. Selgub, et sageli teeb arendaja oma tööd iseseisvalt, kuid “juhuslikult”, sest on sunnitud ootama, kuni skeem testimiseks vabaks saab.
Eraldi skaleerimine...
Jah, kuid see on kasutatava DBMS-i valdkonnas piiratud. Antud arhitektuurinäites Cassandraga probleeme ei teki, küll aga MySQL-il ja PostgreSQL-il.
Боsuurem töökindlus...
Mitte ainult ühe mikroteenuse rike tegelikkuses ei riku sageli kogu süsteemi korrektset toimimist, vaid tekib ka uus probleem: iga mikroteenuse tõrketaluvaks muutmine on väga keeruline. Kuna mikroteenustes kasutatakse erinevaid tehnoloogiaid (memcache, Redis jne), tuleb igaühe jaoks kõik läbi mõelda ja rakendada, mis on muidugi võimalik, kuid nõuab tohutuid ressursse.
Koormuse mõõdetavus...
See on tõesti hea.
Mikroteenuste "kergus"...
Meil pole mitte ainult tohutu võrgu üldkulud (DNS-i päringud paljunevad jne), aga ka paljude alustatud alampäringute tõttu andmeid kopeerida (poe vahemälud), mis tõi kaasa märkimisväärse salvestusruumi.
Ja siin on meie ootustele vastamise tulemus:
Kuid see pole veel kõik!
Sest:
- Tõenäoliselt vajame sõnumibussi.
- Kuidas teha järjepidevat varukoopiat õigel hetkel? Ainus päris võimalus on liiklus selleks välja lülitada. Aga kuidas seda tootmises teha?
- Kui räägime mitme piirkonna toetamisest, siis igas neist on jätkusuutlikkuse korraldamine väga töömahukas ülesanne.
- Tekib tsentraliseeritud muudatuste tegemise probleem. Näiteks kui meil on vaja PHP versiooni värskendada, peame end igale hoidlale siduma (ja neid on kümneid).
- Operatsiooni keerukuse kasv on pealtnäha eksponentsiaalne.
Mida selle kõigega peale hakata?
Alustage monoliitsest rakendusest. Fowleri kogemus et peaaegu kõik edukad mikroteenuste rakendused said alguse monoliidist, mis muutus liiga suureks ja läks siis katki. Samas tekkisid peaaegu kõik algusest peale mikroteenustena ehitatud süsteemid varem või hiljem tõsiseid probleeme.
Veel üks väärtuslik mõte on see, et mikroteenuse arhitektuuriga projekti õnnestumiseks peate väga hästi teadma ja ainevaldkond ning kuidas teha mikroteenuseid. Ja parim viis ainevaldkonna õppimiseks on monoliidi valmistamine.
Aga mis siis, kui oleme juba selles olukorras?
Esimene samm iga probleemi lahendamisel on sellega leppida ja mõista, et see on probleem, et me ei taha enam kannatada.
Kui kinnikasvanud monoliidi puhul (kui meil on otsas võimalus selle jaoks lisaressursse osta) lõikame, siis sel juhul selgub vastupidine lugu: kui liigsed mikroteenused enam ei aita, vaid takistavad - lõika üleliigne ära ja suurenda!
Näiteks ülalpool käsitletud kollektiivse pildi jaoks...
Vabanege kõige küsitavamatest mikroteenustest:
Kombineerige kõik esiserva genereerimise eest vastutavad mikroteenused:
... ühte mikroteenusesse, mis on kirjutatud ühes (kaasaegses ja normaalses, nagu te ise arvate) keeles/raamistikus:
Sellel on üks ORM (üks DBMS) ja kõigepealt paar rakendust:
... kuid üldiselt saate sinna üle kanda palju rohkem, saades järgmise tulemuse:
Pealegi käitame Kubernetesis seda kõike eraldi, mis tähendab, et saame siiski koormust mõõta ja neid eraldi mõõta.
Kokku võtma
Vaata suuremat pilti. Väga sageli tekivad kõik need probleemid mikroteenustega seetõttu, et keegi võttis oma ülesande endale, kuid tahtis “mikroteenustega mängida”.
Sõnas "mikroteenused" on "mikro" osa üleliigne.. Need on "mikro" ainult seetõttu, et nad on väiksemad kui tohutu monoliit. Kuid ärge pidage neid millekski väikeseks.
Ja viimaseks mõtteks pöördume tagasi algse diagrammi juurde:
Sellele kirjutatud märge (üleval paremal) taandub tõsiasjale, et Teie projekti koostava meeskonna oskused on alati esmased — neil on võtmeroll teie valikul mikroteenuste ja monoliidi vahel. Kui meeskonnal pole piisavalt oskusi, aga hakatakse tegema mikroteenuseid, saab lugu kindlasti saatuslikuks.
Videod ja slaidid
Video kõnest (~50 minutit; kahjuks ei anna see edasi külastajate arvukaid emotsioone, mis suuresti määrasid reportaaži meeleolu, aga nii see on):
Aruande esitlus:
PS
Teised aruanded meie ajaveebis:
- «» (Dmitry Stolyarov; 28. mai 2018 RootConfis);
- «» (Dmitry Stolyarov; 7. november 2017, HighLoad++);
- «» (Dmitry Stolyarov; 6. juuni 2017 RootConfis);
- «» (Dmitry Stolyarov; 8. november 2016, HighLoad++);
- «» (Dmitry Stolyarov; 31. mai 2016 RootConfis).
Samuti võite olla huvitatud järgmistest väljaannetest:
- «";
- «";
- «'.
Allikas: www.habr.com