19. septembra u Moskvi prvi tematski sastanak HUG (Highload++ User Group) koji je bio posvećen mikroservisima. Održana je prezentacija „Upravljanje mikroservisima: veličina je bitna, čak i ako imate Kubernetes“, u kojoj smo podijelili Flantovo veliko iskustvo u upravljanju projektima s mikroservisnom arhitekturom. Prije svega, bit će korisno za sve programere koji razmišljaju o korištenju ovog pristupa u svom sadašnjem ili budućem projektu.
Predstavljamo (50 minuta, mnogo informativnije od članka), kao i glavni izvod iz njega u tekstualnom obliku.
Napomena: Video i prezentacija su također dostupni na kraju ovog posta.
Uvod
Obično dobra priča ima početak, glavnu radnju i rješenje. Ovaj izvještaj više liči na uvod, i to tragičan. Takođe je važno napomenuti da pruža pogled sa strane na mikrousluge. eksploatacija.
Počeću sa ovim grafikonom, čiji je autor (2015.) Martin Fowler:
Pokazuje kako, u slučaju monolitne aplikacije koja dosegne određenu vrijednost, produktivnost počinje opadati. Mikrousluge se razlikuju po tome što je početna produktivnost kod njih niža, ali kako se kompleksnost povećava, degradacija efikasnosti za njih nije toliko primjetna.
Dodat ću ovom grafikonu za slučaj korištenja Kubernetesa:
Zašto je aplikacija sa mikroservisima bolja? Jer takva arhitektura postavlja ozbiljne zahtjeve za arhitekturu, koji su zauzvrat savršeno pokriveni mogućnostima Kubernetesa. S druge strane, neke od ovih funkcionalnosti će biti korisne za monolit, posebno zato što tipični monolit danas nije baš monolit (detalji će biti kasnije u izvještaju).
Kao što vidite, konačni graf (kada su i monolitne i mikroservisne aplikacije u infrastrukturi sa Kubernetesom) ne razlikuje se mnogo od originalnog. Dalje ćemo govoriti o aplikacijama koje se koriste pomoću Kubernetesa.
Korisni i štetni mikroservis
A evo glavne ideje:
Šta je normalno mikroservisna arhitektura? Trebalo bi da vam donese stvarne koristi, povećavajući vašu radnu efikasnost. Ako se vratimo na grafikon, evo ga:
Ako je pozoveš korisno, onda će na drugoj strani grafa biti štetno mikroservis (ometa rad):
Da se vratim na „glavnu ideju“: da li uopšte treba da verujem svom iskustvu? Od početka ove godine sam gledao 85 projekata. Nisu svi bili mikroservis (otprilike trećina do polovina njih je imala takvu arhitekturu), ali to je ipak veliki broj. Mi (kompanija Flant) kao autsorci uspevamo da vidimo širok spektar aplikacija razvijenih kako u malim kompanijama (sa 5 programera), tako iu velikim (~500 programera). Dodatna prednost je što ove aplikacije vidimo kako žive i evoluiraju tokom godina.
Zašto mikroservis?
Na pitanje o prednostima mikroservisa postoji od već spomenutog Martina Fowlera:
- jasne granice modularnosti;
- nezavisno raspoređivanje;
- sloboda izbora tehnologija.
Mnogo sam razgovarao sa softverskim arhitektima i programerima i pitao zašto su im potrebne mikroservise. I napravio sam svoju listu njihovih očekivanja. Evo šta se dogodilo:
Ako neke od tačaka opišemo „u senzacijama“, onda:
- jasne granice modula: ovde imamo užasan monolit, a sada će sve biti uredno raspoređeno u Git repozitorijumima, u kojima je sve „na policama“, toplo i meko se ne mešaju;
- Nezavisnost implementacije: moći ćemo samostalno uvesti usluge kako bi razvoj išao brže (paralelno objavljivati nove funkcije);
- razvojna nezavisnost: možemo dati ovaj mikroservis jednom timu/programeru, a jedan drugom, zahvaljujući čemu se možemo brže razvijati;
- боveća pouzdanost: ako dođe do delimične degradacije (jedan mikroservis od 20 padne), tada će samo jedno dugme prestati da radi, a sistem kao celina će nastaviti da funkcioniše.
Tipična (štetna) arhitektura mikroservisa
Da objasnim zašto stvarnost nije ono što očekujemo, predstaviću kolektivno slika mikroservisne arhitekture zasnovana na iskustvu iz mnogih različitih projekata.
Primjer bi bila apstraktna internet trgovina koja će se takmičiti s Amazonom ili barem OZON-om. Njegova mikroservisna arhitektura izgleda ovako:
Iz kombinacije razloga, ove mikroservise su napisane na različitim platformama:
Pošto svaki mikroservis mora imati autonomiju, mnogima od njih je potrebna sopstvena baza podataka i keš memorija. Konačna arhitektura je sljedeća:
Koje su njegove posljedice?
Fowler ima i ovo — o “plaćanju” za korištenje mikrousluga:
A videćemo da li su naša očekivanja ispunjena.
Jasne granice modula...
Još koliko mikroservisa zapravo treba da popravimo?uvesti promjenu? Možemo li uopće shvatiti kako sve funkcionira bez distribuiranog tracera (na kraju krajeva, svaki zahtjev obrađuje polovina mikroservisa)?
postoji obrazac "“, a ovdje se ispostavilo da je to bila raspoređena gruda prljavštine. Da biste to potvrdili, evo približne ilustracije kako se zahtjevi odvijaju:
Nezavisnost raspoređivanja...
Tehnički, to je postignuto: svaki mikroservis možemo uvesti zasebno. Ali u praksi morate uzeti u obzir da se on uvijek pokreće mnoge mikroservise, i moramo uzeti u obzir redosled njihovog uvođenja. Na dobar način, generalno moramo testirati u zasebnom krugu da li pokrećemo izdanje ispravnim redoslijedom.
Sloboda izbora tehnologije...
Ona je. Samo zapamtite da sloboda često graniči sa bezakonjem. Ovdje je vrlo važno da se tehnologije ne biraju samo da bi se „igrale“ s njima.
Nezavisnost razvoja...
Kako napraviti test petlju za cijelu aplikaciju (sa toliko komponenti)? Ali i dalje ga morate ažurirati. Sve ovo dovodi do toga da stvarni broj ispitnih krugova, koje u principu možemo sadržati, ispada minimalno.
Šta kažete na to da sve ovo primenite lokalno?.. Ispostavilo se da često programer radi svoj posao nezavisno, ali „nasumično“, jer je primoran da čeka dok se kolo ne oslobodi za testiranje.
Odvojeno skaliranje...
Da, ali je ograničen u području korištenog DBMS-a. U datom primjeru arhitekture Cassandra neće imati problema, ali će MySQL i PostgreSQL.
Боveća pouzdanost...
Ne samo da kvar jednog mikroservisa u stvarnosti često narušava ispravno funkcioniranje cijelog sistema, već se javlja i novi problem: učiniti svaku mikroservis tolerantnom na greške je veoma teško. Budući da mikroservis koriste različite tehnologije (memcache, Redis, itd.), za svaku morate sve razmisliti i implementirati, što je, naravno, moguće, ali zahtijeva ogromne resurse.
Mjerljivost opterećenja...
Ovo je stvarno dobro.
"Lakoća" mikroservisa...
Ne samo da imamo ogromne mrežni troškovi (zahtjevi za DNS se množe itd.), ali i zbog brojnih potupita koje smo pokrenuli replicirati podatke (keš memorije trgovine), što je dovelo do značajne količine pohrane.
A evo i rezultat ispunjenja naših očekivanja:
Ali to nije sve!
Jer:
- Najvjerovatnije će nam trebati sabirnica poruka.
- Kako napraviti dosljednu sigurnosnu kopiju u pravom trenutku? Jedini pravi opcija je isključiti saobraćaj za ovo. Ali kako to učiniti u proizvodnji?
- Ako govorimo o podršci nekoliko regija, onda je organiziranje održivosti u svakoj od njih vrlo radno intenzivan zadatak.
- Pojavljuje se problem centraliziranih promjena. Na primjer, ako trebamo ažurirati verziju PHP-a, morat ćemo se posvetiti svakom spremištu (a ima ih na desetine).
- Rast operativne složenosti je, naprosto, eksponencijalan.
Šta sa svim ovim?
Počnite s monolitnom aplikacijom. Fowlerovo iskustvo da su gotovo sve uspješne mikroservisne aplikacije počele kao monolit koji je postao prevelik, a zatim pokvaren. Istovremeno, gotovo svi sistemi građeni kao mikroservis od samog početka prije ili kasnije su naišli na ozbiljne probleme.
Još jedna vrijedna misao je da da bi projekat sa mikroservisnom arhitekturom bio uspješan, morate dobro znati i predmetnu oblast, i kako napraviti mikroservise. A najbolji način da naučite predmetnu oblast je da napravite monolit.
Ali šta ako smo već u ovoj situaciji?
Prvi korak ka rješavanju bilo kojeg problema je da se složimo s njim i shvatimo da je to problem, da ne želimo više da patimo.
Ako ga u slučaju zaraslog monolita (kada nam je ponestalo mogućnosti da za njega nabavimo dodatne resurse) presečemo, onda se u ovom slučaju ispostavlja suprotna priča: kada prekomjerni mikroservis više ne pomaže, već ometa - odrežite višak i povećajte!
Na primjer, za skupnu sliku o kojoj smo gore govorili...
Riješite se najsumnjivijih mikroservisa:
Kombinirajte sve mikroservise odgovorne za generiranje frontenda:
... u jedan mikroservis, napisan na jednom (modernom i normalnom, kako i sami mislite) jeziku/okviru:
Imat će jedan ORM (jedan DBMS) i prvo nekoliko aplikacija:
... ali općenito tamo možete prenijeti mnogo više, dobivši sljedeći rezultat:
Štaviše, u Kubernetesu sve ovo pokrećemo u odvojenim instancama, što znači da i dalje možemo zasebno mjeriti opterećenje i skalirati ih.
Da rezimiramo
Pogledajte širu sliku. Vrlo često svi ovi problemi sa mikroservisima nastaju zato što je neko preuzeo njihov zadatak, ali je želeo da se „igra sa mikroservisima“.
U riječi "mikroservis" dio "mikro" je suvišan.. Oni su „mikro“ samo zato što su manji od ogromnog monolita. Ali nemojte ih smatrati nečim malim.
I za kraj, vratimo se originalnom grafikonu:
Beleška napisana na njemu (gore desno) svodi na činjenicu da veštine tima koji pravi vaš projekat su uvek primarne — oni će igrati ključnu ulogu u vašem izboru između mikroservisa i monolita. Ako tim nema dovoljno vještina, ali krene da pravi mikroservise, priča će svakako biti fatalna.
Video zapisi i slajdovi
Video sa govora (~50 minuta; nažalost, ne prenosi brojne emocije posetilaca, koje su u velikoj meri odredile raspoloženje reportaže, ali tako je):
Prezentacija izvještaja:
PS
Ostali izvještaji na našem blogu:
- «» (Dmitrij Stoljarov; 28. maja 2018. na RootConf-u);
- «» (Dmitrij Stoljarov; 7. novembar 2017. na HighLoad++);
- «» (Dmitrij Stoljarov; 6. juna 2017. na RootConf-u);
- «» (Dmitrij Stoljarov; 8. novembar 2016. na HighLoad++);
- «» (Dmitrij Stoljarov; 31. maja 2016. na RootConf-u).
Možda će vas zanimati i sljedeće publikacije:
- «»;
- «»;
- «".
izvor: www.habr.com