Mikropakalpojumi: izmēram ir nozīme, pat ja jums ir Kubernetes

19. septembrÄ« Maskavā notika pirmā tematiskā tikÅ”anās HUG (Highload++ User Group), kas bija veltÄ«ta mikropakalpojumiem. Notika prezentācija ā€œOperating Microservices: Size Matters, Even If You Have Kubernetesā€, kurā dalÄ«jāmies ar Flant plaÅ”o pieredzi projektu vadÄ«Å”anā ar mikropakalpojumu arhitektÅ«ru. Pirmkārt, tas noderēs visiem izstrādātājiem, kuri domā par Ŕīs pieejas izmantoÅ”anu savā esoÅ”ajā vai topoÅ”ajā projektā.

Mikropakalpojumi: izmēram ir nozīme, pat ja jums ir Kubernetes

Iepazīstinām reportāžas video (50 minūtes, daudz informatīvāks par rakstu), kā arī galvenais izraksts no tā teksta formā.

NB: Video un prezentācija ir pieejama arÄ« Ŕīs ziņas beigās.

Ievads

Parasti labam stāstam ir sākums, galvenais sižets un atrisinājums. Å is ziņojums ir vairāk kā prelÅ«dija, turklāt traÄ£iska. Ir arÄ« svarÄ«gi atzÄ«mēt, ka tas sniedz nepiederoÅ”u skatÄ«jumu uz mikropakalpojumiem. ekspluatācija.

SākÅ”u ar Å”o grafiku, kura autors (2015.g.) bija MārtiņŔ Faulers:

Mikropakalpojumi: izmēram ir nozīme, pat ja jums ir Kubernetes

Tas parāda, kā monolÄ«ta lietojuma gadÄ«jumā, kas sasniedz noteiktu vērtÄ«bu, produktivitāte sāk kristies. Mikropakalpojumi atŔķiras ar to, ka sākotnējā produktivitāte ar tiem ir zemāka, taču, pieaugot sarežģītÄ«bai, efektivitātes degradācija tiem nav tik jÅ«tama.

Es pievienoŔu Ŕai diagrammai Kubernetes izmantoŔanas gadījumā:

Mikropakalpojumi: izmēram ir nozīme, pat ja jums ir Kubernetes

Kāpēc lietojumprogramma ar mikropakalpojumiem ir labāka? Jo Ŕāda arhitektÅ«ra izvirza nopietnas prasÄ«bas arhitektÅ«rai, kuras savukārt lieliski nosedz Kubernetes iespējas. No otras puses, daļa no Ŕīs funkcionalitātes noderēs monolÄ«tam, jo ā€‹ā€‹Ä«paÅ”i tāpēc, ka mÅ«sdienu tipiskais monolÄ«ts nav gluži monolÄ«ts (sÄ«kāka informācija bÅ«s vēlāk ziņojumā).

Kā redzat, galÄ«gais grafiks (kad Kubernetes infrastruktÅ«rā atrodas gan monolÄ«tās, gan mikropakalpojumu lietojumprogrammas) Ä«paÅ”i neatŔķiras no sākotnējā. Tālāk mēs runāsim par lietojumprogrammām, kas darbojas, izmantojot Kubernetes.

Noderīgi un kaitīgi mikropakalpojumi

Un Ŕeit ir galvenā doma:

Mikropakalpojumi: izmēram ir nozīme, pat ja jums ir Kubernetes

Kas ir normāli mikropakalpojumu arhitektūra? Tam vajadzētu dot jums reālus ieguvumus, palielinot jūsu darba efektivitāti. Ja mēs atgriežamies pie grafika, tas ir:

Mikropakalpojumi: izmēram ir nozīme, pat ja jums ir Kubernetes

Ja tu viņai piezvani noderīga, tad grafika otrā pusē būs kaitīgs mikropakalpojumi (traucē darbu):

Mikropakalpojumi: izmēram ir nozīme, pat ja jums ir Kubernetes

Atgriežoties pie ā€œgalvenās domasā€: vai man vispār vajadzētu uzticēties savai pieredzei? KopÅ” Ŕī gada sākuma esmu skatÄ«jies 85 projekti. Ne visi no tiem bija mikropakalpojumi (apmēram treÅ”daļai lÄ«dz pusei no tiem bija Ŕāda arhitektÅ«ra), taču tas joprojām ir liels skaits. Mums (Flant company) kā ārpakalpojumu sniedzējiem izdodas redzēt ļoti dažādas aplikācijas izstrādātas gan mazos uzņēmumos (ar 5 izstrādātājiem), gan lielajos (~500 izstrādātāju). Papildu ieguvums ir tas, ka mēs redzam Ŕīs lietojumprogrammas tieÅ”raidē un attÄ«stās gadu gaitā.

Kāpēc mikropakalpojumi?

Uz jautājumu par mikropakalpojumu priekÅ”rocÄ«bām ir ļoti konkrēta atbilde no jau pieminētā Mārtina Faulera:

  1. skaidras modularitātes robežas;
  2. neatkarīga izvietoŔana;
  3. brīvība izvēlēties tehnoloģijas.

Esmu daudz runājis ar programmatÅ«ras arhitektiem un izstrādātājiem un jautājis, kāpēc viņiem nepiecieÅ”ami mikropakalpojumi. Un es izveidoju savu sarakstu ar viņu cerÄ«bām. LÅ«k, kas notika:

Mikropakalpojumi: izmēram ir nozīme, pat ja jums ir Kubernetes

Ja mēs aprakstam dažus punktus ā€œsajÅ«tāsā€, tad:

  • skaidras moduļu robežas: Å”eit mums ir baigais monolÄ«ts, un tagad viss bÅ«s glÄ«ti sakārtots Git krātuvēs, kurās viss ir ā€œpa plauktiņiemā€, siltais un mÄ«kstais nav sajaukts;
  • izvietoÅ”anas neatkarÄ«ba: pakalpojumus varēsim ieviest neatkarÄ«gi, lai attÄ«stÄ«ba noritētu ātrāk (paralēli publicējiet jaunas iespējas);
  • attÄ«stÄ«bas neatkarÄ«ba: mēs varam dot Å”o mikropakalpojumu vienai komandai/izstrādātājam, bet vienu otrai, pateicoties tam, mēs varam attÄ«stÄ«ties ātrāk;
  • Š±Š¾lielāka uzticamÄ«ba: ja notiek daļēja degradācija (viens mikropakalpojums no 20 kritieniem), tad tikai viena poga pārtrauks darboties, un sistēma kopumā turpinās darboties.

Tipiska (kaitīga) mikropakalpojumu arhitektūra

Lai izskaidrotu, kāpēc realitāte nav tāda, kādu mēs sagaidām, es iepazÄ«stināŔu kolektÄ«vs mikropakalpojumu arhitektÅ«ras attēls, kas balstÄ«ts uz daudzu un dažādu projektu pieredzi.

Piemērs varētu bÅ«t abstrakts tieÅ”saistes veikals, kas gatavojas konkurēt ar Amazon vai vismaz OZON. Tā mikropakalpojumu arhitektÅ«ra izskatās Ŕādi:

Mikropakalpojumi: izmēram ir nozīme, pat ja jums ir Kubernetes

Vairāku iemeslu dēļ Å”ie mikropakalpojumi ir rakstÄ«ti dažādās platformās:

Mikropakalpojumi: izmēram ir nozīme, pat ja jums ir Kubernetes

Tā kā katram mikropakalpojumam ir jābÅ«t autonomam, daudziem no tiem ir nepiecieÅ”ama sava datu bāze un keÅ”atmiņa. GalÄ«gā arhitektÅ«ra ir Ŕāda:

Mikropakalpojumi: izmēram ir nozīme, pat ja jums ir Kubernetes

Kādas ir tā sekas?

Fauleram arÄ« tas ir ir raksts ā€” par ā€œsamaksuā€ par mikropakalpojumu izmantoÅ”anu:

Mikropakalpojumi: izmēram ir nozīme, pat ja jums ir Kubernetes

Un mēs redzēsim, vai mūsu cerības piepildījās.

Skaidras moduļu robežas...

Bet cik daudz mikropakalpojumu mums patiesībā ir jālabo?ieviest izmaiņas? Vai mēs vispār varam izdomāt, kā viss darbojas bez izplatīta izsekotāja (galu galā jebkuru pieprasījumu apstrādā puse mikropakalpojumu)?

Ir modelis"liels netÄ«rumu kamolsā€œ, un Å”eit tas izrādÄ«jās izkliedēts netÄ«rumu kamols. Lai to apstiprinātu, Å”eit ir sniegts aptuvens pieprasÄ«jumu izpildes piemērs.

Mikropakalpojumi: izmēram ir nozīme, pat ja jums ir Kubernetes

IzvērÅ”anas neatkarÄ«ba...

Tehniski tas ir sasniegts: mēs varam izvērst katru mikropakalpojumu atseviŔķi. Bet praksē jāņem vērā, ka tas vienmēr izrullē daudzi mikropakalpojumi, un mums tas ir jāņem vērā to izlaiÅ”anas secÄ«ba. Labā nozÄ«mē, mums parasti ir jāpārbauda atseviŔķā ķēdē, vai mēs izlaižam laidienu pareizā secÄ«bā.

Tehnoloģiju izvēles brīvība...

Viņa ir. VienkārÅ”i atcerieties, ka brÄ«vÄ«ba bieži robežojas ar nelikumÄ«bām. Å eit ir ļoti svarÄ«gi neizvēlēties tehnoloÄ£ijas, lai tikai ar tām ā€œspēlētosā€.

Attīstības neatkarība...

Kā izveidot testa cilpu visai lietojumprogrammai (ar tik daudziem komponentiem)? Bet jums tas joprojām ir jāatjaunina. Tas viss noved pie tā, ka faktiskais testa ķēžu skaits, ko principā varam saturēt, izrādās minimāls.

Kā bÅ«tu ar to visu izvietoÅ”anu lokāli?.. Izrādās, ka bieži vien izstrādātājs savu darbu veic patstāvÄ«gi, bet ā€œizlases kārtÄ«bāā€, jo ir spiests gaidÄ«t, kamēr ķēde bÅ«s brÄ«va testÄ“Å”anai.

AtseviŔķa mērogoÅ”ana...

Jā, bet tas ir ierobežots izmantotās DBVS jomā. Dotajā arhitektūras piemērā Cassandra problēmu nebūs, bet MySQL un PostgreSQL radīsies.

Š‘Š¾lielāka uzticamÄ«ba...

Ne tikai viena mikropakalpojuma kļūme patiesÄ«bā bieži vien izjauc visas sistēmas pareizu darbÄ«bu, bet arÄ« rodas jauna problēma: ir ļoti grÅ«ti padarÄ«t katru mikropakalpojumu izturÄ«gu pret defektiem. Tā kā mikropakalpojumos tiek izmantotas dažādas tehnoloÄ£ijas (memcache, Redis u.c.), tad katram ir viss jāpārdomā un jāievieÅ”, kas, protams, ir iespējams, bet prasa milzÄ«gus resursus.

Slodzes izmērāmība...

Šis ir patieŔām labs.

Mikropakalpojumu "vieglums"...

Mums ir ne tikai milzÄ«gi tÄ«kla pieskaitāmās izmaksas (DNS pieprasÄ«jumi vairojas utt.), bet arÄ« daudzo uzsākto apakÅ”vaicājumu dēļ replicēt datus (veikala keÅ”atmiņas), kas radÄ«ja ievērojamu krātuves apjomu.

Un lūk, mūsu cerību piepildījuma rezultāts:

Mikropakalpojumi: izmēram ir nozīme, pat ja jums ir Kubernetes

Bet tas vēl nav viss!

Jo:

  • Visticamāk, mums bÅ«s nepiecieÅ”ams ziņojumu autobuss.
  • Kā izveidot konsekventu dublējumu Ä«stajā brÄ«dÄ«? VienÄ«gais Ä«sts iespēja ir izslēgt satiksmi Å”im nolÅ«kam. Bet kā to izdarÄ«t ražoÅ”anā?
  • Ja runājam par vairāku reÄ£ionu atbalstu, tad ilgtspējas organizÄ“Å”ana katrā no tiem ir ļoti darbietilpÄ«gs uzdevums.
  • Rodas problēma veikt centralizētas izmaiņas. Piemēram, ja mums ir jāatjaunina PHP versija, mums bÅ«s jāiesaistās katrā repozitorijā (un to ir desmitiem).
  • DarbÄ«bas sarežģītÄ«bas pieaugums ir eksponenciāls.

Ko darīt ar Ŕo visu?

Sāciet ar monolÄ«tu aplikāciju. Faulera pieredze saka ka gandrÄ«z visas veiksmÄ«gās mikropakalpojumu lietojumprogrammas sākās kā monolÄ«ts, kas kļuva pārāk liels un pēc tam tika salauzts. Tajā paŔā laikā gandrÄ«z visās sistēmās, kas no paÅ”a sākuma tika izveidotas kā mikropakalpojumi, agrāk vai vēlāk radās nopietnas problēmas.

Vēl viena vērtÄ«ga doma ir tāda, ka, lai projekts ar mikropakalpojumu arhitektÅ«ru bÅ«tu veiksmÄ«gs, jums tas ir ļoti labi jāzina un priekÅ”metu joma, kā arÄ« to, kā izveidot mikropakalpojumus. Un labākais veids, kā apgÅ«t mācÄ«bu priekÅ”metu jomu, ir izgatavot monolÄ«tu.

Bet ko darÄ«t, ja mēs jau esam Å”ajā situācijā?

Pirmais solis jebkuras problēmas risināŔanā ir tai piekrist un saprast, ka tā ir problēma, ka mēs vairs nevēlamies ciest.

Ja aizauguÅ”a monolÄ«ta gadÄ«jumā (kad ir beigusies iespēja tam iegādāties papildu resursus) mēs to nogriežam, tad Å”ajā gadÄ«jumā iznāk pretējs stāsts: kad pārmērÄ«gie mikropakalpojumi vairs nepalÄ«dz, bet traucē - nogriezt lieko un palielināt!

Piemēram, iepriekÅ” apspriestajam kolektÄ«vajam attēlam...

Atbrīvojieties no visvairāk apŔaubāmajiem mikropakalpojumiem:

Mikropakalpojumi: izmēram ir nozīme, pat ja jums ir Kubernetes

Apvienojiet visus mikropakalpojumus, kas ir atbildīgi par priekŔgala ģenerēŔanu:

Mikropakalpojumi: izmēram ir nozīme, pat ja jums ir Kubernetes

... vienā mikropakalpojumā, kas rakstīts vienā (mūsdienīgā un normālā, kā jūs pats domājat) valodā/ietvarā:

Mikropakalpojumi: izmēram ir nozīme, pat ja jums ir Kubernetes

Tam būs viens ORM (viena DBVS) un vispirms dažas lietojumprogrammas:

Mikropakalpojumi: izmēram ir nozīme, pat ja jums ir Kubernetes

... bet kopumā tur var pārsūtīt daudz vairāk, iegūstot Ŕādu rezultātu:

Mikropakalpojumi: izmēram ir nozīme, pat ja jums ir Kubernetes

Turklāt Kubernetes mēs to visu palaižam atseviŔķos gadÄ«jumos, kas nozÄ«mē, ka mēs joprojām varam izmērÄ«t slodzi un mērogot tos atseviŔķi.

Apkopot

Paskaties uz lielāku attēlu. Ä»oti bieži visas Ŕīs problēmas ar mikropakalpojumiem rodas tāpēc, ka kāds uzņēmās savu uzdevumu, bet gribēja ā€œspēlēties ar mikropakalpojumiemā€.

Vārdā "mikropakalpojumi" daļa "mikro" ir lieka.. Tie ir ā€œmikroā€ tikai tāpēc, ka ir mazāki par milzÄ«gu monolÄ«tu. Bet neuzskatiet tos par kaut ko mazu.

Un, lai iegūtu pēdējo domu, atgriezīsimies pie sākotnējās diagrammas:

Mikropakalpojumi: izmēram ir nozīme, pat ja jums ir Kubernetes

Uz tā uzrakstÄ«ta piezÄ«me (augŔējā labajā pusē) ir saistÄ«ts ar faktu, ka komandas, kas veido jÅ«su projektu, prasmes vienmēr ir primāras ā€” tiem bÅ«s galvenā loma jÅ«su izvēlē starp mikropakalpojumiem un monolÄ«tu. Ja komandai nepietiks prasmju, bet tā sāks veidot mikropakalpojumus, stāsts noteikti bÅ«s liktenÄ«gs.

Videoklipi un slaidi

Video no runas (~50 minūtes; diemžēl neizskan daudzās apmeklētāju emocijas, kas lielā mērā noteica reportāžas noskaņu, bet tā nu tas ir):

Ziņojuma prezentācija:

PS

Citi ziņojumi mūsu emuārā:

JÅ«s varētu interesēt arÄ« Ŕādas publikācijas:

Avots: www.habr.com

Pievieno komentāru