Pozdrav, ja sam Stanislav Yablonskiy, vodeći programer u Pixonic (MY.GAMES). Mikroslužbe su pristup razvoju softvera (prvenstveno backend razvoj) gdje je funkcionalnost podijeljena na najmanje moguće komponente, od kojih svaka radi samostalno. svaka takva komponenta ima svoj API. Mikroslužbe su danas vrlo popularne, ali njihova upotreba uvodi značajnu nadmoć u smislu mreže, memorije i CPU-a. Svaki poziv pretvara se u potrebu serializiranja, slanja i primanja podataka preko mreže.Osim toga, više nije moguće koristiti klasične transakcije baze podataka, što dovodi do distribuiranih transakcija ili konačne dosljednosti. Distribuirane transakcije su spore i skupe, dok eventualna dosljednost znači da se rezultati operacija možda ne pojavljuju odmah, a podaci mogu privremeno biti nedosljedni. Korištenje mikroslužbi prisiljava programere da napišu više koda u svakoj pojedinačnoj usluzi zbog poteškoća s pristupom već napisanoj logici iz drugih usluga. Microservices ‘Overheads’ Sljedeći članak Debug Overhead Debugiranje postaje mnogo teže s mikroslužbama. Redoviti debugger je gotovo beskoristan u takvim uvjetima jer ne možete debugirati sve usluge odjednom. To znači da vam je potrebno posebno okruženje u kojem ne radi samo usluga koja se debugira, već i sve njegove ovisnosti (druge usluge, baze podataka, redovi, itd.). HTTP na vrhu HTTP protokol ima puno ugrađenih funkcionalnosti. podržava različite rute, metode prolaska parametara, kodove odgovora i podržava ga mnogo usluga spremnih za uporabu (uključujući proxy). ali nije lagan - prisiljava svaku uslugu da implementira puno ne tako učinkovitog koda za analiziranje i generiranje putova, glava, i tako dalje. Protobuf iznad glave Serijaliziranje za mrežnu komunikaciju i deserializiranje pri primanju poruka su potrebni. Kada koristite protobuf za razmjenu poruka, morate: stvaranje predmeta, pretvoriti ih u zamjene, Odmah ih bacite nakon upotrebe. To stvara puno dodatnog rada za sakupljač smeća ili upravitelja dinamičkom memorijom. Mreža OVERHEAD Prijenos podataka preko mreže povećava vrijeme odgovora na usluge, povećava potrošnju memorije i CPU-a, čak i ako se mikroslužbe pokreću na istom domaćinu. Sjećanje na glavu Pošiljanje i primanje poruka zahtijeva održavanje dodatnih podatkovnih struktura, korištenje zasebnih žica i njihovo sinhroniziranje.Svaki zasebni proces, posebno onaj koji se izvodi u kontejneru, troši značajnu količinu memorije samo postojećim. CPU iznad glave Naravno, sva ta međuprocesna i međukontinencijska komunikacija zahtijeva računalne resurse. Overhead baza podataka Normalne transakcije su nemoguće kada operacije obuhvaćaju više mikroslužbi. Distribuirane transakcije su mnogo sporije i zahtijevaju složenu – često ručnu – koordinaciju. Mrežni disk overhead Kontejneri za mikroslužbe često se pokreću na diskovima na mreži, što povećava latenciju, smanjuje performanse (IOPS) i čini ih nepredvidljivima. Projekt Border Overhead Dizajn i razvoj mikroslužbi donosi poteškoće u razvoju i refaktoringu projekta. Nije lako promijeniti zonu odgovornosti usluge. Ne možete jednostavno premjestiti kod iz jedne usluge u drugu. To obično zahtijeva: puno vremena i truda, nekoliko različitih verzija, i složene migracije prije nego što se funkcionalnost može redistribuirati između usluga. Osim toga, ako želite ažurirati ili zamijeniti knjižnicu, morat ćete to učiniti na svim projektima, a ne samo na jednom. Infrastruktura iznad Ne možete samo "raditi microservices." Trebat će vam infrastruktura - ne, INFRASTRUKTURA: kontejneri (svaki koji sadrži kopije zajedničkih knjižnica), Sljedeći Kuberneti, cloud usluga, Hrvati (RabbitMQ i Kafka) alat za sinhronizaciju konfiguracije (Zookeeper, Etcd, Consul) i tako dalje. Sve to zahtijeva ogromne resurse i od strojeva i od ljudi. Neovisno raspoređivanje OVERHEAD Podupiranje neovisnih razmještanja znači: svaka služba mora biti raspoređena odvojeno, Svaki od njih mora imati vlastitu cijevnu cijev CI/CD. I najteži dio - API verzija. Svaka usluga će morati podržavati više verzija API-ja istodobno, a pozivatelji će morati pratiti te verzije i ažurirati svoje pozive na vrijeme. Podijeljena lopta od mudra Umjesto čistih mikroslužbi, završit ćete s rasprostranjenom kuglom blata - gdje je funkcionalnost slabo raspodijeljena, vanjski pozivi pokreću cijele lance internih poziva za usluge, a cijela stvar je strašno spora. Je li Monolith doista tako zastrašujuće? Modularni monoliti Modularni monoliti omogućuju izbjegavanje većine mikro-usluga, a istodobno pružaju odvajanje koje se može koristiti kasnije ako je potrebno. Ovaj pristup uključuje pisanje aplikacije (prvenstveno backend) kao jedinstvene usluge podijeljene na pojedinačne module s: jasno definirane granice i minimalne međusobne ovisnosti. To omogućuje njihovu podjelu na usluge ako to stvarno zahtijeva skaliranje. Čekaj, možeš li to učiniti? Mnoge prednosti pripisane arhitekturi mikroslužbi mogu se postići u jednom monolitu: Modularnost se može implementirati s jezičnim značajkama: razredima, imenskim prostorima, projektima i skupovima; višestruke baze podataka – moguće, ako je stvarno potrebno; Više jezika – također moguće, na primjer, kombiniranje C/C++/C#/Java sa skriptnim jezicima kao što su JavaScript, Python ili Erlang za razvoj na višoj razini; Interop – mnoge platforme podržavaju pozivanje C/C++ iz Java, C#, Python, JavaScript ili Erlang; Redovi za poruke – samo koristite odgovarajuću strukturu podataka. A kada želite debugirati - jedan tipkovnica, a cijela aplikacija je na dohvat ruke. Izvođači Frameworks Aktorski okviri omogućuju izgradnju mikroslužbi – bez mikroslužbi. Sva logika je podijeljena na klase (glumci) koji komuniciraju samo putem poruke bus (vremenice). Ti akteri mogu: postoji unutar jednog procesa, ili Podijeljeni su u više procesa. Na taj način dobivate model programiranja mikroslužbi, ali većinu infrastrukture upravlja sam okvir. Conclusion Zaključak Arhitektura se mora odabrati na temelju: zahtjevi za projekt, dostupni resursi, I stručnost tima. Mikroslužbe nisu srebrna metka, korisne su za velike projekte i timove, ali monolit nije zastarjel i nije tehnički dug po podrazumijevu. Ono što je najvažnije je ravnoteža između fleksibilnosti i složenosti, skalabilnosti i održivosti – tako da je sustav koji gradite učinkovit i održiv.
