19. rujna u Moskvi prvi tematski sastanak HUG (Highload++ User Group), koji je bio posvećen mikroservisima. Održana je prezentacija "Operating Microservices: Size Matters, Even If You Have Kubernetes", u kojoj smo podijelili Flantovo opsežno iskustvo u upravljanju projektima s mikroservisnom arhitekturom. Prije svega, bit će koristan svim programerima koji razmišljaju o korištenju ovog pristupa u svom trenutnom ili budućem projektu.
Upoznavanje (50 minuta, puno informativnije od članka), kao i glavni izvadak iz njega u tekstualnom obliku.
NB: Video i prezentacija također su dostupni na kraju ovog posta.
Uvod
Obično dobra priča ima početak, glavni zaplet i razrješenje. Ovaj izvještaj je više kao uvod, i to tragičan. Također je važno napomenuti da pruža pogled izvana na mikroservise. eksploatacije.
Počet ću s ovim grafikonom čiji je autor (2015.) Martin Fowler:
Pokazuje kako, u slučaju monolitne primjene koja dosegne određenu vrijednost, produktivnost počinje opadati. Mikroservisi se razlikuju po tome što je kod njih početna produktivnost manja, no kako se kompleksnost povećava, degradacija učinkovitosti kod njih nije toliko primjetna.
Dodat ću ovom grafikonu za slučaj korištenja Kubernetesa:
Zašto je aplikacija s mikroservisima bolja? Jer takva arhitektura postavlja ozbiljne zahtjeve za arhitekturu, koji su pak savršeno pokriveni mogućnostima Kubernetesa. S druge strane, neke od ovih funkcionalnosti će biti korisne za monolit, pogotovo zato što tipični monolit danas nije baš monolit (detalji će biti kasnije u izvješću).
Kao što možete vidjeti, konačni grafikon (kada su i monolitne i mikroservisne aplikacije u infrastrukturi s Kubernetesom) ne razlikuje se puno od izvornog. Zatim ćemo govoriti o aplikacijama kojima se upravlja pomoću Kubernetesa.
Korisni i štetni mikroservisi
I evo glavne ideje:
Što je normalan arhitektura mikroservisa? To bi vam trebalo donijeti stvarne koristi, povećavajući vašu radnu učinkovitost. Ako se vratimo na grafikon, evo ga:
Ako je nazoveš koristan, onda će na drugoj strani grafikona biti štetan mikroservisi (ometaju rad):
Da se vratimo na “glavnu ideju”: trebam li uopće vjerovati svom iskustvu? Od početka ove godine sam gledao 85 projekata. Nisu svi bili mikroservisi (otprilike trećina do polovica ih je imala takvu arhitekturu), ali to je ipak veliki broj. Mi (tvrtka Flant) kao vanjski dobavljači uspijevamo vidjeti široku paletu aplikacija razvijenih kako u malim tvrtkama (s 5 programera), tako iu velikim (~500 programera). Dodatna prednost je to što ove aplikacije vidimo uživo i razvijamo se tijekom godina.
Zašto mikroservisi?
Na pitanje o prednostima mikroservisa postoji od već spomenutog Martina Fowlera:
- jasne granice modularnosti;
- neovisno raspoređivanje;
- sloboda izbora tehnologija.
Puno sam razgovarao sa softverskim arhitektima i programerima i pitao ih zašto im trebaju mikroservisi. I napravio sam popis njihovih očekivanja. Evo što se dogodilo:
Ako neke od točaka opišemo "u senzacijama", tada:
- jasne granice modula: ovdje imamo užasan monolit, a sada će sve biti uredno složeno u Git repozitorije, u kojima je sve “na policama”, toplo i meko se ne miješaju;
- neovisnost implementacije: moći ćemo samostalno uvesti usluge kako bi razvoj išao brže (paralelno objavljivati nove značajke);
- razvojna neovisnost: ovu mikrouslugu možemo dati jednom timu/developeru, a drugu drugoj, zahvaljujući čemu se možemo brže razvijati;
- боveća pouzdanost: ako dođe do djelomične degradacije (pada jedan mikroservis od 20), tada će samo jedan gumb prestati raditi, a sustav u cjelini će nastaviti funkcionirati.
Tipična (štetna) arhitektura mikroservisa
Kako bih objasnio zašto stvarnost nije ono što očekujemo, iznijet ću kolektivni slika arhitekture mikroservisa na temelju iskustva iz mnogih različitih projekata.
Primjer bi bila apstraktna online trgovina koja će konkurirati Amazonu ili barem OZON-u. Njegova mikrouslužna arhitektura izgleda ovako:
Zbog kombinacije razloga, ove su mikrousluge napisane na različitim platformama:
Budući da svaki mikroservis mora imati autonomiju, mnogi od njih trebaju vlastitu bazu podataka i predmemoriju. Konačna arhitektura je sljedeća:
Koje su njegove posljedice?
Fowler također ima ovo — o „plaćanju“ korištenja mikroservisa:
A jesu li nam se očekivanja ispunila, vidjet ćemo.
Jasne granice modula...
Ali koliko mikroservisa zapravo trebamo popraviti?uvesti promjenu? Možemo li uopće shvatiti kako sve funkcionira bez distribuiranog tragača (uostalom, svaki zahtjev obrađuje polovica mikroservisa)?
Postoji obrazac"“, a ovdje se pokazalo da je to raspoređena gruda zemlje. Da bismo to potvrdili, evo približne ilustracije kako idu zahtjevi:
Neovisnost postavljanja...
Tehnički, to je postignuto: možemo pokrenuti svaku mikroservis zasebno. Ali u praksi morate uzeti u obzir da se uvijek otkotrlja mnoge mikroservise, a moramo uzeti u obzir redoslijed njihovog izvođenja. U dobrom smislu, općenito trebamo testirati u zasebnom krugu da li oslobađamo ispravnim redoslijedom.
Sloboda izbora tehnologije...
Ona je. Zapamtite samo da sloboda često graniči s bezakonjem. Ovdje je vrlo važno ne birati tehnologije samo da bi se s njima “igrali”.
Neovisnost razvoja...
Kako napraviti testnu petlju za cijelu aplikaciju (s toliko komponenti)? Ali svejedno ga morate održavati ažurnim. Sve to dovodi do činjenice da stvarni broj ispitnih krugova, koje načelno možemo sadržavati, ispada minimalan.
Što kažete na to da sve to implementirate lokalno?.. Ispada da programer često radi svoj posao samostalno, ali "nasumično", jer je prisiljen čekati dok krug nije slobodan za testiranje.
Odvojeno skaliranje...
Da, ali je ograničen u području korištenog DBMS-a. U navedenom primjeru arhitekture Cassandra neće imati problema, ali MySQL i PostgreSQL hoće.
Боveća pouzdanost...
Ne samo da kvar jednog mikroservisa u stvarnosti često prekida ispravno funkcioniranje cijelog sustava, već postoji i novi problem: učiniti svaku mikroservis tolerantnom na greške vrlo je teško. Budući da mikroservisi koriste različite tehnologije (memcache, Redis itd.), za svaku morate sve promisliti 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 režijski troškovi mreže (zahtjevi za DNS se množe, itd.), ali i zbog mnogih podupita koje smo pokrenuli replicirati podatke (predmemorije pohrane), što je dovelo do značajne količine pohrane.
A evo i rezultata koji su ispunili naša očekivanja:
Ali to nije sve!
Jer:
- Najvjerojatnije će nam trebati sabirnica poruka.
- Kako napraviti dosljednu sigurnosnu kopiju u željenom trenutku? Jedini stvaran opcija je isključiti promet 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 naporan zadatak.
- Pojavljuje se problem centraliziranih promjena. Na primjer, ako trebamo ažurirati PHP verziju, morat ćemo se posvetiti svakom repozitoriju (a ima ih na desetke).
- Rast operativne složenosti je eksponencijalan.
Što učiniti sa svim ovim?
Započnite s monolitnom primjenom. Fowlerovo iskustvo da su gotovo sve uspješne mikrouslužne aplikacije započele kao monolit koji je postao prevelik i zatim se razbio. Istodobno, gotovo svi sustavi izgrađeni kao mikroservisi od samog početka prije ili kasnije doživjeli su ozbiljne probleme.
Još jedna vrijedna misao je da da bi projekt s mikroservisnom arhitekturom bio uspješan, morate vrlo dobro znati i predmetno područje, te kako napraviti mikroservise. A najbolji način da naučite predmetno područje je napraviti monolit.
Ali što ako smo već u ovoj situaciji?
Prvi korak u rješavanju bilo kojeg problema je složiti se s njim i shvatiti da je to problem, da ne želimo više patiti.
Ako ga u slučaju preraslog monolita (kada nam je ponestalo mogućnosti za kupnju dodatnih resursa za njega) presiječemo, onda se u ovom slučaju ispostavlja suprotna priča: kada pretjerani mikroservisi više ne pomažu, već smetaju - odrežite višak i povećajte!
Na primjer, za skupnu sliku o kojoj smo govorili gore...
Riješite se najupitnijih mikroservisa:
Kombinirajte sve mikroservise odgovorne za generiranje sučelja:
... u jedan mikroservis, napisan na jednom (modernom i normalnom, kako sami mislite) jeziku/okviru:
Imat će jedan ORM (jedan DBMS) i prvo par aplikacija:
... ali općenito tamo možete prenijeti mnogo više, dobivajući sljedeći rezultat:
Štoviše, u Kubernetesu sve to izvodimo u odvojenim instancama, što znači da i dalje možemo odvojeno mjeriti opterećenje i skalirati ih.
sažimanje
Pogledajte širu sliku. Vrlo često svi ovi problemi s mikroservisima nastaju jer je netko preuzeo njihov zadatak, ali se htio “igrati s mikroservisima”.
U riječi "mikrousluge" 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 na izvorni grafikon:
Bilješka napisana na njemu (Gore desno) svodi se na to da uvijek su primarne vještine tima koji radi vaš projekt — igrat će ključnu ulogu u vašem izboru između mikroservisa i monolita. Ako tim nema dovoljno vještina, a krene u izradu mikroservisa, priča će sigurno biti kobna.
Video zapisi i slajdovi
Video s govora (~50 minuta; nažalost, ne prenosi brojne emocije posjetitelja, koje su uvelike odredile raspoloženje reportaže, ali tako je):
Prezentacija izvješća:
PS
Ostala izvješća na našem blogu:
- «» (Dmitry Stolyarov; 28. svibnja 2018. na RootConfu);
- «» (Dmitry Stolyarov; 7. studenog 2017. na HighLoad++);
- «» (Dmitry Stolyarov; 6. lipnja 2017. na RootConfu);
- «» (Dmitry Stolyarov; 8. studenog 2016. na HighLoad++);
- «» (Dmitry Stolyarov; 31. svibnja 2016. na RootConfu).
Možda će vas zanimati i sljedeće publikacije:
- «»;
- «»;
- «".
Izvor: www.habr.com