Kako preživeti u svetu 200 microservisa

05.05.2017 - 17:00

Mikroservisi, super popularno, svi pričaju samo o tome, ako ne razvijaš microservise potpuni si šonja. Ali da li je sve tako idealno u svetu mikroservisa? Mi radimo na sistemu koji pokreće preko 200 mikroservisa i prenosimo vam naša iskustva.

200 servisa - 200 API-ja

Kako se snaći u tolikoj količini API-ja? Kako znati koji servis pozvati za podatak koji ti treba?
Gde pronaći dokumentaciju APIja?

Šta uraditi:

Za početak, dokumentovati API-je na što bolji način. Standardni tool za API dokumentaciju je http://swagger.io/. To je polazna tačka ali svakako ne dovoljna. Ne daje odgovor na pitanje “koji servis da pozovem da bih uradio to i to”. Kod REST API-ja da bi se uradila jednostavna biznis operacija vrlo često je potrebno pozvati nekoliko različitih servisa. Tako da odgovor na pitanje “koji servis treba da pozovem da bih uradio to i to” je najčešće “pozoveš ovaj a onda ovaj, posle toga spojiš ta dva rezultata pa sa tim pozoveš treći, onda čekaš callback i vratiš odgovor klijentu”. Tu dolazimo do potrebe za API gateway-ima koji trebaju da pojednostave priču i za korisnika sakriju kompleksnost backend sistema.

Kako jednostavno kreirati i pustiti u rad novi servis?

Za novi mikroservis treba novi server, ili VM ili kontejner, treba podesiti taj server, mrežu, security, load balancer… Kod monolita to se uradi jednom i nadalje se samo puštaju izmene koda, kod mikroservisa sve ovo morate uraditi svaki put kada pravite novi servis.

Šta uraditi:

Automatizacija svega što se može automatizovati iliti Continuous Delivery. Ceo proces podizanja infrastrukture za novi servis, kao i deploy servisa mora biti kompletno automatizovan. Centralna tačka procesa je deployment pipeline. Jenkins je najpopularniji open-source alat za to, a mi koristimo komercijalno resenje GoCD. Lako reći ali komplikovano uraditi, vremenski zahtevno i zahteva konstantno održavanje i unapređivanje. Eto nama velike potrebe za pozicijom čudnog imena: DevOps.

Kako uraditi dijagnozu problema?

Korisnik besno prijavljuje da ne može da se uloguje, kako otkriti šta je uzrok? U moniltnoj arhitekturi je lako, pratite korisnikov zahtev kroz log i pre ili kasnije će se ispisati neki exception.

U mikroservis arhitekturti čak i u jednostavnim procesima kao što je logovanje na sajt može učestvovati desetine microservisa, ako je komunikacija asinhrona izmedju servisa, što je najčešći slučaj danas, tu niko živ ne zna ko sve reaguje na event koji je kreirao.

Šta uraditi:

Centralizovati logove i koristiti neke od alata za analizu logova je prvi korak. Najpopularniji alati za to su tzv. ELK stack - Elastic Search, LogStash, Kibana. Mi koristimo Splunk. Da bi alati imali punu vrednost, kvalitet logova mora biti veliki. Standardizacija načina na koji se pišu logovi i
strukturirani logovi umnogome olakšavaju analizu istih. Poseban zadatak je kako obezbediti da logovi budu željenog kvaliteta iliti kako neterati programere da pišu kvalitetne logove.

To svakako olakšava pretraživanje logova ali ne rešava problem. Da bi se lako kroz logove ispratilo šta je sve rađeno u procesiranju jednog korisnikovog requesta, neophodno je biti u stanju pratiti jedan request - transkaciju kroz više servisa. http://opentracing.io/ je dobar alat za to.

REST Microservisi mnogo pričaju

REST API je super, ali u jednom API pozivu dobijete jedan resurs, a obično vam za odredjeni use case treba nekoliko resursa pa samim tim se pravi i nekoliko API poziva. Ono što bi se u tradicionalnom programiranju završilo jednim pozivom metode ovde je to nekoliko. To pogotovu može biti problem kod mobilnih klijenata gde treba izbegavati suviše roundtripova ka serveru.

Šta raditi:

API Gateway je prirodno rešenje ili Backend za frontend što je varijacija API Gateway-a.

Kako uskladiti orkestar od 200 svirača

Suštinska ideja mikroservis arhitekture je povećanje stabilnosti sistema. Ali kad imate 200 nezavisnih elemenata koji medjusobno moraju saradjivati, lako se može desiti baš suprotno.

Šta raditi:

Testirati, testirati i testirati i pratiti metrike. Važnost automatskog testiranja je višestruko uvećana. Osim toga što je neophodno je imati više slojeva testiranja, unit, integracioni, acceptance, perfomance... Za svaki od testova koji zahtevaju neku vrstu integracije treba podići odgovarajuće okruženje. Nije dovoljno kao u monolitnoj arhitekturi jednostavno podići vaš server. Svako od tih orkuženja treba uspostaviti, konfigurisati održavati…

Monitoring je ključan element za uspostavljanje stabilnog produkcionog sistema. Pratiti kako se sistem ponaša kako u testnim okruženjima, tako i na live okruženju je od ključne važnosti. Počevši od monitoringa infrastrukture, servera, OS metrika.. Tu su tradicionalni alati kao sto su Nagios, Zabbix, SysDig. Onda je neophodan aplikacioni monitoring koji prati performanse same aplikacije. Popularniji su NewRelic i AppDynamics.

Vrlo povezano sa monitoringom je i alarming. Kada monitoring tool prepozna da nešto nije u redu mora da alarmima. Podesiti Alarme tako da nema lažnih poziva je nešto to do sada nismo uspeli da uradimo :). I to je važan problem. Ako ima suviše lažnih alarma niko na njih neće reagovati, a ako se kriterujumi za alarmiranje podese suviše kruto, onda se može desiti da se o nekom problemu ne pošalje alarm.

Uf, pa ovo je mnogo kompleksno da se ipak vratimo na monolite?

Ne. Problemi koje rešavamo su kompleksni pa tako i rešenja moraju biti. Sistem koji razvijamo, sa preko milion mesečno aktivnih korisnika bi apsolutno bio neodrživ kao monolit. Mikroservisi su nam omogućili 0 sati godišnjeg planiranog downtime-a, preko 9000 deploya godišnje. Dakle, stabilan sistem i stabilan razvoj i unapređenje. Samo je vrlo važno biti svestan da mikroservisi kao i sve lepe stvari u životu dolaze uz određenu cenu.

IT BUSINESS

Plain text

  • HTML tagovi nisu dozvoljeni
  • Web i email adrese automatski postaju linkovi
  • Redovi i paragrafi se prelamaju automatski.
NAPOMENA:
IT-KONEKT zadržava pravo izbora i skraćivanja komentara koji će biti objavljeni na veb sajtu.
Neće biti objavljivani komentari koji sadrže govor mržnje, pretnje, uvrede i psovke.
Očekujemo da tekstovi budu pravopisno i gramatički ispravni.
Komentari objavljeni na ovom veb sajtu predstavljaju privatno mišljenje njihovih autora a ne zvaničan stav IT-KONEKT tima.
CAPTCHA
This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.
Image CAPTCHA
Enter the characters shown in the image.