19. syyskuuta Moskovassa ensimmäinen teemakokous HUG (Highload++ User Group), joka oli omistettu mikropalveluille. Siellä oli esitys ”Operating Microservices: Size Matters, Even If You Have Kubernetes”, jossa jaoimme Flantin laajan kokemuksen mikropalveluarkkitehtuurin projekteista. Ensinnäkin se on hyödyllinen kaikille kehittäjille, jotka harkitsevat tämän lähestymistavan käyttämistä nykyisessä tai tulevassa projektissaan.
Esittelyssä (50 minuuttia, paljon informatiivisempi kuin artikkeli), sekä pääote siitä tekstimuodossa.
HUOM: Video ja esitys löytyvät myös tämän postauksen lopusta.
Esittely
Yleensä hyvällä tarinalla on alku, juoni ja ratkaisu. Tämä raportti on enemmän kuin alkusoitto ja traaginen. On myös tärkeää huomata, että se tarjoaa ulkopuolisen näkemyksen mikropalveluista. hyväksikäyttö.
Aloitan tällä kaaviolla, jonka kirjoittaja (vuonna 2015) Martin Fowler:
Se osoittaa, kuinka monoliittisessa sovelluksessa, joka saavuttaa tietyn arvon, tuottavuus alkaa laskea. Mikropalvelut eroavat toisistaan siinä, että niiden alkutuottavuus on alhaisempi, mutta monimutkaisuuden kasvaessa tehokkuuden heikkeneminen ei ole niille niin huomattavaa.
Lisään tähän kaavioon Kubernetesin käyttöä varten:
Miksi mikropalveluita sisältävä sovellus on parempi? Koska tällainen arkkitehtuuri asettaa arkkitehtuurille vakavia vaatimuksia, jotka vuorostaan kattavat täydellisesti Kubernetesin kyvyt. Toisaalta osa näistä toiminnoista on hyödyllistä monoliitille, varsinkin koska tyypillinen monoliitti ei ole juuri monoliitti (yksityiskohdat myöhemmin raportissa).
Kuten näette, lopullinen kaavio (kun sekä monoliittiset että mikropalvelusovellukset ovat Kubernetesin infrastruktuurissa) ei eroa kovinkaan paljon alkuperäisestä. Seuraavaksi puhumme Kubernetesilla toimivista sovelluksista.
Hyödyllisiä ja haitallisia mikropalveluita
Ja tässä pääidea:
Mikä on normaali mikropalveluarkkitehtuuri? Sen pitäisi tuoda sinulle todellista hyötyä, mikä lisää työsi tehokkuutta. Jos palataan kaavioon, se on tässä:
Jos soitat hänelle hyödyllinen, niin kaavion toisella puolella on haitallista mikropalvelut (häiritsee työtä):
Palatakseni "pääajatukseen": pitäisikö minun luottaa kokemukseeni? Tämän vuoden alusta olen katsonut 85 hanketta. Kaikki eivät olleet mikropalveluita (noin kolmanneksella - puolella heistä oli tällainen arkkitehtuuri), mutta luku on silti suuri. Me (Flant yritys) ulkoistajina onnistumme näkemään laajan valikoiman sovelluksia kehitettävinä sekä pienissä yrityksissä (5 kehittäjällä) että suurissa (~500 kehittäjää). Lisäetuna on, että näemme nämä sovellukset livenä ja kehittyvät vuosien varrella.
Miksi mikropalvelut?
Kysymykseen mikropalvelujen eduista on olemassa jo mainitulta Martin Fowlerilta:
- selkeät modulaarisuuden rajat;
- riippumaton käyttöönotto;
- vapaus valita teknologioita.
Olen puhunut paljon ohjelmistoarkkitehtien ja -kehittäjien kanssa ja kysynyt, miksi he tarvitsevat mikropalveluita. Ja tein listani heidän odotuksistaan. Tässä on mitä tapahtui:
Jos kuvaamme joitain kohtia "tunteissa", niin:
- selkeät moduulien rajat: täällä meillä on kauhea monoliitti, ja nyt kaikki järjestetään siististi Git-varastoissa, joissa kaikki on "hyllyillä", lämmin ja pehmeä ei sekoitu;
- käyttöönoton riippumattomuus: voimme ottaa palvelut käyttöön itsenäisesti, jotta kehitys sujuu nopeammin (julkaise uusia ominaisuuksia rinnakkain);
- kehitysriippumattomuus: voimme antaa tämän mikropalvelun yhdelle tiimille/kehittäjälle ja sen toiselle, jonka ansiosta voimme kehittyä nopeammin;
- боsuurempi luotettavuus: jos tapahtuu osittaista heikkenemistä (yksi mikropalvelu 20 putoamisesta), vain yksi painike lakkaa toimimasta ja järjestelmä kokonaisuudessaan jatkaa toimintaansa.
Tyypillinen (haitallinen) mikropalveluarkkitehtuuri
Selitän, miksi todellisuus ei ole sitä, mitä odotamme, esitän kollektiivinen kuva mikropalveluarkkitehtuurista, joka perustuu monista eri projekteista saatuihin kokemuksiin.
Esimerkkinä voisi olla abstrakti verkkokauppa, joka kilpailee Amazonin tai ainakin OZONin kanssa. Sen mikropalveluarkkitehtuuri näyttää tältä:
Useista syistä nämä mikropalvelut on kirjoitettu eri alustoille:
Koska jokaisen mikropalvelun on oltava itsenäinen, monet niistä tarvitsevat oman tietokannan ja välimuistin. Lopullinen arkkitehtuuri on seuraava:
Mitkä ovat sen seuraukset?
Fowlerilla on myös tämä — "maksusta" mikropalvelujen käytöstä:
Ja katsotaan täyttyvätkö odotuksemme.
Selkeät moduulien rajat...
Mutta kuinka monta mikropalvelua meidän on todella korjattava?toteuttaa muutos? Voimmeko edes selvittää, kuinka kaikki toimii ilman hajautettua jäljitysohjelmaa (joka tapauksessa puolet mikropalveluista käsittelee kaikki pyynnöt)?
Siinä on malli"", ja tässä se osoittautui jakautuneeksi likapalaksi. Tämän vahvistamiseksi tässä on likimääräinen kuva pyyntöjen toiminnasta:
Käyttöönoton riippumattomuus...
Teknisesti se on saavutettu: voimme ottaa jokaisen mikropalvelun käyttöön erikseen. Mutta käytännössä sinun on otettava huomioon, että se rullaa aina ulos monia mikropalveluita, ja meidän on otettava huomioon niiden käyttöönoton järjestys. Hyvällä tavalla meidän on yleensä testattava erillisessä piirissä, julkaisemmeko julkaisun oikeassa järjestyksessä.
Vapaus valita tekniikka...
Hän on. Muista vain, että vapaus rajoittuu usein laittomuuteen. Tässä on erittäin tärkeää olla valitsematta teknologioita vain "leikkimään" niillä.
Kehittämisen itsenäisyys...
Kuinka tehdä testisilmukka koko sovellukselle (niin monella komponentilla)? Mutta sinun on silti pidettävä se ajan tasalla. Kaikki tämä johtaa siihen tosiasiaan, että testipiirien todellinen määrä, jonka voimme periaatteessa sisältää, osoittautuu minimaaliseksi.
Entäpä tämän kaiken paikallisesti käyttöönottaminen?... Osoittautuu, että usein kehittäjä tekee työnsä itsenäisesti, mutta "satunnaisesti", koska hänen on pakko odottaa piirin vapautumista testaukseen.
Erillinen skaalaus...
Kyllä, mutta se on rajoitettu käytetyn DBMS:n alueella. Annetussa arkkitehtuuriesimerkissä Cassandralla ei ole ongelmia, mutta MySQL:llä ja PostgreSQL:llä.
Боsuurempi luotettavuus...
Ei vain yhden mikropalvelun vika todellisuudessa usein katkaisee koko järjestelmän oikeanlaista toimintaa, vaan mukana on myös uusi ongelma: Jokaisen mikropalvelun tekeminen vikasietoiseksi on erittäin vaikeaa. Koska mikropalvelut käyttävät erilaisia tekniikoita (memcache, Redis jne.), jokaisen on mietittävä kaikki ja otettava se käyttöön, mikä tietysti on mahdollista, mutta vaatii valtavia resursseja.
Kuorman mitattavuus...
Tämä on todella hyvää.
Mikropalvelujen "keveys"...
Meillä ei ole vain suuria verkon yläpuolella (DNS-pyynnöt lisääntyvät jne.), mutta myös aloittamiemme monien alikyselyjen vuoksi kopioida tietoja (kaupan välimuistit), mikä johti huomattavaan määrään tallennustilaa.
Ja tässä tulos odotustemme täyttämisestä:
Mutta ei siinä vielä kaikki!
koska:
- Todennäköisesti tarvitsemme viestiväylän.
- Kuinka tehdä johdonmukainen varmuuskopio oikeaan aikaan? Ainoa todellinen vaihtoehto on sulkea liikenne tätä varten. Mutta miten tämä tehdään tuotannossa?
- Jos puhumme useiden alueiden tukemisesta, niin kestävyyden järjestäminen jokaisella niistä on erittäin työvoimavaltainen tehtävä.
- Ongelmana on keskitettyjen muutosten tekeminen. Jos meidän on esimerkiksi päivitettävä PHP-versio, meidän on sitouduttava jokaiseen arkistoon (ja niitä on kymmeniä).
- Toiminnan monimutkaisuuden kasvu on kertakaikkiaan eksponentiaalista.
Mitä tehdä tämän kaiken kanssa?
Aloita monoliittisella sovelluksella. Fowlerin kokemus että lähes kaikki onnistuneet mikropalvelusovellukset alkoivat monoliitista, joka tuli liian suureksi ja sitten rikkoutui. Samaan aikaan lähes kaikissa alusta alkaen mikropalveluiksi rakennetuissa järjestelmissä oli ennemmin tai myöhemmin vakavia ongelmia.
Toinen arvokas ajatus on, että mikropalveluarkkitehtuurilla varustetun projektin menestyminen edellyttää, että se tiedetään hyvin ja aihealueet ja kuinka tehdä mikropalveluita. Ja paras tapa oppia aihealue on tehdä monoliitti.
Mutta entä jos olemme jo tässä tilanteessa?
Ensimmäinen askel minkä tahansa ongelman ratkaisemiseksi on hyväksyä se ja ymmärtää, että se on ongelma, josta emme enää halua kärsiä.
Jos umpeenkasvun monoliitin tapauksessa (kun meillä on loppunut mahdollisuus ostaa siihen lisäresursseja) leikkaamme sen, niin tässä tapauksessa käy päinvastaiseksi: kun liialliset mikropalvelut eivät enää auta, vaan estävät - leikkaa ylimääräinen ja suurenna!
Esimerkiksi edellä käsitellylle kollektiivikuvalle...
Päästä eroon kyseenalaisimmista mikropalveluista:
Yhdistä kaikki käyttöliittymän luomisesta vastaavat mikropalvelut:
...yhdeksi mikropalveluksi, joka on kirjoitettu yhdellä (nykyaikaisella ja normaalilla, kuten itse ajattelet) kielellä/kehyksellä:
Siinä on yksi ORM (yksi DBMS) ja ensin pari sovellusta:
... mutta yleensä voit siirtää paljon enemmän sinne, jolloin saat seuraavan tuloksen:
Lisäksi Kubernetesissa ajetaan tämä kaikki erillisissä tapauksissa, mikä tarkoittaa, että voimme silti mitata kuorman ja skaalata ne erikseen.
yhteenveto
Katso isompi kuva. Hyvin usein kaikki nämä ongelmat mikropalveluissa syntyvät siksi, että joku otti tehtävänsä, mutta halusi "leikkiä mikropalveluilla".
Sanassa "mikropalvelut" "mikro"-osa on tarpeeton.. Ne ovat "mikroja" vain siksi, että ne ovat pienempiä kuin valtava monoliitti. Mutta älä ajattele niitä pieninä.
Ja lopuksi palataan alkuperäiseen kaavioon:
Siihen kirjoitettu huomautus (Yläoikea) tiivistyy siihen tosiasiaan projektisi tekevän tiimin taidot ovat aina ensisijaisia — niillä on keskeinen rooli valittaessasi mikropalvelujen ja monoliitin välillä. Jos tiimillä ei ole tarpeeksi taitoja, mutta se alkaa tehdä mikropalveluita, tarina on varmasti kohtalokas.
Videot ja diat
Video puheesta (n. 50 minuuttia; valitettavasti se ei välitä vierailijoiden lukuisia tunteita, jotka suurelta osin määrittivät raportin tunnelman, mutta niin se on):
Raportin esittely:
PS.
Muita raportteja blogissamme:
- «» (Dmitry Stolyarov; 28. toukokuuta 2018 RootConfissa);
- «» (Dmitry Stolyarov; 7. marraskuuta 2017 HighLoad++:ssa);
- «» (Dmitry Stolyarov; 6. kesäkuuta 2017 RootConfissa);
- «» (Dmitry Stolyarov; 8. marraskuuta 2016 HighLoad++:ssa);
- «» (Dmitry Stolyarov; 31. toukokuuta 2016 RootConfissa).
Saatat olla kiinnostunut myös seuraavista julkaisuista:
- «";
- «";
- «'.
Lähde: will.com