{"id":92806,"date":"2020-08-31T07:42:03","date_gmt":"2020-08-31T05:42:03","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita"},"modified":"2020-08-31T07:42:03","modified_gmt":"2020-08-31T05:42:03","slug":"kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita","title":{"rendered":"Cum s\u0103 renun\u021bi la \u00eengrijorare \u0219i s\u0103 \u00eencepi s\u0103 tr\u0103ie\u0219ti f\u0103r\u0103 monolit","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Cum
\n
\nTo\u021bi ne iubim pove\u0219tile. Ne place s\u0103 st\u0103m l\u00e2ng\u0103 foc \u0219i s\u0103 vorbim despre victoriile, luptele sau experien\u021bele noastre de munc\u0103.<\/p>\n

Ast\u0103zi este o astfel de zi. \u0218i, de\u0219i poate c\u0103 nu e\u0219ti l\u00e2ng\u0103 foc, avem totu\u0219i o poveste pentru tine. O poveste despre cum am \u00eenceput s\u0103 lucr\u0103m cu stocarea pe Tarantool.<\/p>\n

\u00cen vremuri de mult apuse, compania noastr\u0103 avea c\u00e2teva \u00abmonolite\u00bb \u0219i un \u00abtavan\u00bb comun, la care aceste monolite se apropiau lent, dar sigur, limit\u00e2nd zborul companiei noastre, dezvoltarea noastr\u0103. Era o \u00een\u021belegere clar\u0103: la un moment dat, ne vom lovi cu brutalitate de acest tavan.
\n<\/a><\/noindex>
\nAcum, ideologia de a \u00eemp\u0103r\u021bi totul \u0219i toate, de la echipamente la logica de afaceri, ne domin\u0103. Drept urmare, avem, de exemplu, dou\u0103 datacentere, practic independente la nivel de re\u021bea. Pe atunci, \u00eens\u0103, totul era cu totul diferit.<\/p>\n

Ast\u0103zi, pentru a face modific\u0103ri, avem o mul\u021bime de instrumente \u0219i mijloace sub form\u0103 de CI\/CD, K8S etc. \u00cen vremea \u00abmonolitic\u0103\u00bb, nu aveam nevoie de at\u00e2tea cuvinte str\u0103ine. Era suficient s\u0103 corect\u0103m pur \u0219i simplu \u00abstocarea\u00bb din baza de date.<\/p>\n

Dar timpul a trecut, iar volumul de cereri a crescut odat\u0103 cu el, ating\u00e2nd uneori RPS-uri care dep\u0103\u0219eau capacit\u0103\u021bile noastre. Odat\u0103 cu intrarea pe pia\u021ba \u021b\u0103rilor CSI, \u00eenc\u0103rcarea pe procesorul Bazei de Date a primului monolit nu a sc\u0103zut sub 90%, iar RPS-urile s-au men\u021binut la un nivel de 2400. \u0218i nu erau doar cereri mici, ci solicit\u0103ri mari cu multe verific\u0103ri \u0219i JOIN-uri, care puteau accesa aproape jum\u0103tate din date, \u00een condi\u021bii de input\/output ridicat.<\/p>\n

C\u00e2nd au \u00eenceput s\u0103 apar\u0103 v\u00e2nz\u0103rile reale de \u00abBlack Friday\u00bb \u2014 iar Wildberries a fost unul dintre primii din Rusia care le-a organizat \u2014 situa\u021bia a devenit cu adev\u0103rat trist\u0103. Asta pentru c\u0103 \u00eenc\u0103rcarea \u00een astfel de zile cre\u0219te de trei ori.
\nAh, aceste \u00abvreme monolitice\u00bb! Sunt sigur c\u0103 \u0219i tu ai avut parte de a\u0219a ceva \u0219i \u00eenc\u0103 nu po\u021bi s\u0103 \u00een\u021belegi cum a putut s\u0103 \u021bi se \u00eent\u00e2mple asta.<\/p>\n

Ce s\u0103-i faci \u2014 moda este o tr\u0103s\u0103tur\u0103 comun\u0103 \u0219i pentru tehnologii. Acum cinci ani, a fost necesar s\u0103 reg\u00e2ndim una dintre aceste tendin\u021be, sub forma site-ului nostru pe .NET \u0219i MS SQL Server, care p\u0103stra cu grij\u0103 toat\u0103 logica opera\u021bional\u0103 a site-ului. P\u0103stra at\u00e2t de mult, \u00eenc\u00e2t desfacerea unui astfel de monolit s-a dovedit a fi o pl\u0103cere lung\u0103 \u0219i deloc u\u0219oar\u0103.
\nO mic\u0103 deviere. <\/p>\n

La diferite tipuri de evenimente spun: \u201edac\u0103 nu ai spart monolitul, \u00eenseamn\u0103 c\u0103 nu ai crescut!\u201d A\u0219 dori s\u0103 \u0219tiu p\u0103rerea ta despre aceasta, te rog s\u0103-mi scrii \u00een comentarii.<\/p>\n

\u0218i a venit tunetul<\/h3>\n

\nRevenind la \u201ecasa noastr\u0103\u201d. Pentru a distribui sarcina func\u021bionalit\u0103\u021bii \u201emonolitice\u201d, am decis s\u0103 \u00eemp\u0103r\u021bim sistemul \u00een microservicii, bazate pe tehnologii open-source. Pentru c\u0103, cel pu\u021bin, scalarea lor este mai ieftin\u0103. \u0218i am \u00een\u021beles perfect c\u0103 va trebui s\u0103 scal\u0103m (\u0219i nu pu\u021bin) \u00een propor\u021bie de 100 %. \u00centruc\u00e2t, deja la acel moment, am reu\u0219it s\u0103 intr\u0103m pe pie\u021bele \u021b\u0103rilor vecine, iar num\u0103rul de \u00eenregistr\u0103ri, la fel ca \u0219i num\u0103rul de comenzi, a \u00eenceput s\u0103 creasc\u0103 \u0219i mai mult.<\/p>\n

Analiz\u00e2nd primii candida\u021bi pentru a ie\u0219i din monolit \u00een microservicii, am realizat c\u0103 \u00een 80% din cazuri, scrierea \u00een acestea provine \u00een 99% din sistemele back office, iar citirea \u2014 din prima linie. \u00cen primul r\u00e2nd, aceasta se referea la dou\u0103 subsisteme importante pentru noi \u2014 datele utilizatorilor \u0219i sistemul de calculare a pre\u021bului final al produselor pe baza informa\u021biilor despre reducerile \u0219i cupoanele clien\u021bilor.<\/p>\n

Ca o not\u0103 de subsol. Acum e \u00eensp\u0103im\u00e2nt\u0103tor s\u0103 ne imagin\u0103m, dar pe l\u00e2ng\u0103 subsistemele men\u021bionate mai sus, din monolitul nostru au fost de asemenea scoase cataloagele de produse, co\u0219ul utilizatorilor, sistemul de c\u0103utare a produselor, sistemul de filtrare a cataloagelor de produse \u0219i diverse sisteme de recomandare. Pentru func\u021bionarea fiec\u0103ruia dintre acestea, exist\u0103 clase separate de sisteme specializate, dar c\u00e2ndva toate tr\u0103iau \u00een acela\u0219i \u201ecas\u0103\u201d. <\/p>\n

Am planificat s\u0103 scoatem datele despre clien\u021bii no\u0219tri direct dintr-un sistem shardat. Scoaterea func\u021bionalit\u0103\u021bii pentru calcularea pre\u021bului final al produselor necesita o bun\u0103 scalabilitate \u00een citire, deoarece aceasta crea cea mai mare \u00eenc\u0103rc\u0103tur\u0103 pe RPS \u0219i era cea mai complex\u0103 \u00een execu\u021bie pentru baz\u0103 (foarte multe date sunt implicate \u00een procesul de calcul). <\/p>\n

Ca urmare a acestui fapt, a ap\u0103rut un schema care se potrive\u0219te bine cu Tarantool.<\/p>\n

Atunci, pentru func\u021bionarea microserviciilor, au fost alese scheme de lucru cu mai multe centre de date pe ma\u0219ini virtuale \u0219i fizice. A\u0219a cum este ilustrat \u00een imagini, au fost aplicate variante de replicare Tarantool at\u00e2t \u00een modul master-master, c\u00e2t \u0219i master-slave. <\/p>\n

\"Cum
\nArhitectur\u0103. Variante 1. Serviciul utilizatorilor<\/i><\/p>\n

\u00cen prezent, exist\u0103 24 de sharduri, fiecare av\u00e2nd c\u00e2te 2 instan\u021be (c\u00e2te una pentru fiecare centru de date), toate \u00een modul master-master.<\/p>\n

Deasupra bazei de date se afl\u0103 aplica\u021bii care acceseaz\u0103 replicile bazei de date. Aplica\u021biile interac\u021bioneaz\u0103 cu Tarantool prin intermediul bibliotecii noastre personalizate, care implementeaz\u0103 interfa\u021ba Go-driver-ului Tarantool. Aceasta vede toate replicile \u0219i poate lucra cu masterul pentru citire \u0219i scriere. Practic, implementeaz\u0103 modelul replica set, \u00een care este ad\u0103ugat\u0103 logica de selec\u021bie a replicilor, de retry, circuit breaker \u0219i rate limit.<\/p>\n

Exist\u0103 posibilitatea de a configura politica de selec\u021bie a replicii pe sharduri. De exemplu, prin round-robin.<\/p>\n

\"Cum
\nArhitectura. Varianta 2. Serviciul de calcul al costului final al produsului.<\/i><\/p>\n

Cu c\u00e2teva luni \u00een urm\u0103, cea mai mare parte a cererilor pentru calculul costului final al produselor a fost transferat\u0103 c\u0103tre un nou serviciu, care, \u00een principiu, func\u021bioneaz\u0103 f\u0103r\u0103 baze de date, dar, p\u00e2n\u0103 acum, 100% din cereri erau procesate de serviciul cu Tarantool sub capot\u0103.<\/p>\n

Baza de date a serviciului const\u0103 din 4 mastere, \u00een care sincronizatorul adun\u0103 datele, fiecare dintre aceste mastere \u00eemp\u0103r\u021bind datele c\u0103tre replicile readonly. Fiecare master are aproximativ 15 astfel de replici.<\/p>\n

At\u00e2t \u00een prima, c\u00e2t \u0219i \u00een a doua schem\u0103, \u00een cazul indisponibilit\u0103\u021bii unui datacenter, aplica\u021bia poate ob\u021bine date din cel de-al doilea.<\/p>\n

Merit\u0103 men\u021bionat c\u0103 \u00een Tarantool replicarea este destul de flexibil\u0103 \u0219i se poate configura \u00een runtime. \u00cen alte sisteme au ap\u0103rut dificult\u0103\u021bi. De exemplu, modificarea parametrilor max_wal_senders \u0219i max_replication_slots \u00een PostgreSQL necesit\u0103 repornirea masterului, ceea ce \u00een unele cazuri poate duce la \u00eentreruperea conexiunilor \u00eentre aplica\u021bie \u0219i SGBD.<\/p>\n

Caut\u0103 \u0219i vei g\u0103si!<\/h3>\n

\nDe ce nu am f\u0103cut \u00abca oamenii normali\u00bb \u0219i am ales o metod\u0103 atipic\u0103? Depinde ce consideri normal. Mul\u021bi formeaz\u0103 de fapt un cluster din Mongo \u0219i \u00eel distribuie pe trei datacenter-uri geografic dispersate.<\/p>\n

Atunci aveam deja dou\u0103 proiecte pe Redis. Primul \u2014 cache, iar al doilea reprezenta un stocare persistent\u0103 pentru date nu foarte critice. Cu acesta aveam destul de multe dificult\u0103\u021bi, par\u021bial din vina noastr\u0103. Uneori, volume mari st\u0103teau \u00een chei, iar din c\u00e2nd \u00een c\u00e2nd site-ul devenea lent. Foloseam acest sistem \u00een variant\u0103 master-slave. \u0218i au fost multe cazuri c\u00e2nd ceva se \u00eent\u00e2mpla cu masterul \u0219i replicarea se strica. <\/p>\n

Adic\u0103 Redis este bun pentru sarcini stateless, nu pentru stateful. \u00cen principiu, a rezolvat majoritatea sarcinilor, dar doar dac\u0103 erau solu\u021bii key-value cu c\u00e2teva indec\u0219i. \u00cens\u0103, \u00een acea perioad\u0103, Redis avea probleme semnificative cu persisten\u021ba \u0219i replicarea. \u00cen plus, existau pl\u00e2ngeri legate de performan\u021b\u0103.<\/p>\n

Ne-am g\u00e2ndit la MySQL \u0219i PostgreSQL. Dar primul nu a prins la noi, iar al doilea este un produs destul de complex, a\u0219a c\u0103 a construi servicii simple pe el ar fi fost nejustificat.
\nAm \u00eencercat RIAK, Cassandra, chiar \u0219i o baz\u0103 de date grafic\u0103. Toate acestea sunt solu\u021bii destul de ni\u0219ate, care nu se potriveau rolului de instrument universal pentru crearea de servicii.<\/p>\n

\u00cen cele din urm\u0103, ne-am oprit la Tarantool.<\/p>\n

Ne-am adresat lui c\u00e2nd era \u00een versiunea 1.6. Ne-a interesat sinergia dintre key-value \u0219i func\u021bionalitatea unei baze de date rela\u021bionale. Exist\u0103 indec\u0219i secundari, tranzac\u021bii \u0219i spa\u021bii, ce sunt ca tabelele, dar nu sunt simple, po\u021bi stoca diferite numere de coloane \u00een ele. Dar caracteristica uciga\u0219\u0103 a Tarantool au fost indec\u0219ii secundari combina\u021bi cu key-value \u0219i tranzac\u021bionalitatea.<\/p>\n

De asemenea, a avut un rol important comunitatea rusofon\u0103 reactiv\u0103, preg\u0103tit\u0103 s\u0103 ajute \u00een chat. Am folosit acest lucru activ \u0219i am tr\u0103it efectiv \u00een chat. \u0218i nu trebuie s\u0103 uit\u0103m de persisten\u021ba decent\u0103 f\u0103r\u0103 erori evidente \u0219i probleme. Dac\u0103 ne uit\u0103m la istoricul nostru cu Tarantool, am \u00eent\u00e2mpinat multe dureri \u0219i e\u0219ecuri cu replicarea, dar nu am pierdut niciodat\u0103 date din vina lui!<\/p>\n

Implementarea a \u00eenceput cu dificult\u0103\u021bi.<\/h3>\n

\nLa acea vreme, principalul nostru stack de dezvoltare era .NET, pentru care nu exista un conector pentru Tarantool. Am \u00eenceput imediat s\u0103 lucr\u0103m pe Go. Cu Lua a mers destul de bine. Principal\u0103 problem\u0103 era debuggingul: \u00een .NET era totul excelent, dar dup\u0103 aceea, a te cufunda \u00een lumea Lua embedded, c\u00e2nd nu ai altceva \u00een afar\u0103 de jurnale, era destul de complicat. \u00cen plus, replicarea se descompunea periodic, a\u0219a c\u0103 a trebuit s\u0103 ne aprofund\u0103m \u00een structura motorului Tarantool. Chatul ne-a ajutat \u00een acest sens, documenta\u021bia \u00eentr-o m\u0103sur\u0103 mai mic\u0103, uneori ne uitam la cod. La acea vreme, documenta\u021bia era destul de slab\u0103.<\/p>\n

A\u0219a, \u00een decursul c\u00e2torva luni, am reu\u0219it s\u0103 acumulez experien\u021b\u0103 \u0219i s\u0103 ob\u021bin rezultate notabile \u00een lucrul cu Tarantool. Am documentat \u00een git solu\u021biile de referin\u021b\u0103, care au fost utile pentru dezvoltarea noilor microservicii. De exemplu, c\u00e2nd ap\u0103rea sarcina de a crea un nou microserviciu, dezvoltatorul consulta codul surs\u0103 al solu\u021biei de referin\u021b\u0103 din depozit, iar crearea unui nou microserviciu nu dura mai mult de o s\u0103pt\u0103m\u00e2n\u0103. <\/p>\n

A fost o perioad\u0103 special\u0103. \u00cen esen\u021b\u0103, atunci puteai s\u0103 te apropii de administratorul de la biroul vecin \u0219i s\u0103 ceri: \u201eD\u0103-mi o ma\u0219in\u0103 virtual\u0103\u201d. Peste aproximativ treizeci de minute, ma\u0219ina era deja la tine. Te conectai singur, instalai totul \u0219i \u00eencepeau s\u0103-\u021bi direc\u021bioneze trafic pe ea.<\/p>\n

Ast\u0103zi, lucrurile nu mai stau a\u0219a: trebuie s\u0103 configurezi monitorizarea pe serviciu, s\u0103 implementezi jurnalizare, s\u0103 acoperi func\u021bionalitatea cu teste, s\u0103 comanzi o ma\u0219in\u0103 virtual\u0103 sau s\u0103 o implementezi \u00een Kuberen \u0219i a\u0219a mai departe. \u00cen general, a\u0219a va fi mai bine, de\u0219i mai \u00eendelungat \u0219i complicat.<\/p>\n

\u00cemp\u0103r\u021bi\u021bi \u0219i st\u0103p\u00e2ni\u021bi. Cum stau lucrurile cu Lua?<\/h3>\n

\nA fost o dilem\u0103 serioas\u0103: unele echipe nu reu\u0219eau s\u0103 implementeze modific\u0103ri \u00een serviciu cu un grad mare de logic\u0103 scris\u0103 \u00een Lua. De multe ori, acest lucru se \u00eenso\u021bea de nefunc\u021bionalitatea serviciului. <\/p>\n

Adic\u0103, dezvoltatorii preg\u0103tesc o anumit\u0103 modificare. Tarantool \u00eencepe s\u0103 fac\u0103 migrarea, iar replica \u00eenc\u0103 folose\u0219te codul vechi; acolo prime\u0219te, prin replicare, un DDL sau altceva, iar codul pur \u0219i simplu se destram\u0103, pentru c\u0103 nu a fost luat \u00een considerare. Ca urmare, procedura de actualizare a administratorilor era scris\u0103 pe o foaie A4: opre\u0219te replicarea, actualizeaz\u0103 asta, activeaz\u0103 replicarea, opre\u0219te aici, actualizeaz\u0103 acolo. Co\u0219mar! <\/p>\n

\u00cen consecin\u021b\u0103, acum \u00eencerc\u0103m de cele mai multe ori s\u0103 nu facem nimic \u00een Lua. Pur \u0219i simplu folosim iproto (protocol binar pentru interac\u021biunea cu serverul) \u0219i cam at\u00e2t. Poate c\u0103 acest lucru se datoreaz\u0103 lipsei de cuno\u0219tin\u021be a dezvoltatorilor, dar din aceast\u0103 perspectiv\u0103, sistemul este complex.<\/p>\n

Nu urm\u0103m \u00eentotdeauna orbe\u0219te acest scenariu. Ast\u0103zi, nu mai avem alb \u0219i negru: fie totul este \u00een Lua, fie totul este \u00een Go. \u00cencepem s\u0103 \u00een\u021belegem cum s\u0103 le combin\u0103m, astfel \u00eenc\u00e2t ulterior s\u0103 nu ne confrunt\u0103m cu probleme de migrare.<\/p>\n

Unde se afl\u0103 acum Tarantool?
\nTarantool este utilizat \u00een serviciul de calcul al pre\u021bului final al produselor, inclusiv cupoanele de reducere, cunoscut sub numele de \u201ePromotayzer\u201d. A\u0219a cum am men\u021bionat anterior, acum acesta se retrage: este \u00eenlocuit de un nou serviciu de catalog cu pre\u021buri pre-calculate, dar cu \u0219ase luni \u00een urm\u0103 toate calculele erau efectuate \u00een \u201ePromotayzer\u201d. O jum\u0103tate din logica sa a fost scris\u0103 \u00een Lua. Acum doi ani, serviciul a fost transformat \u00eentr-un depozit, iar logica a fost rescris\u0103 \u00een Go, deoarece mecanica reducerilor s-a schimbat pu\u021bin \u0219i serviciul nu avea suficient\u0103 performan\u021b\u0103. <\/p>\n

Unul dintre cele mai critice servicii este profilul utilizatorului. Asta \u00eenseamn\u0103 c\u0103 to\u021bi utilizatorii Wildberries sunt stoca\u021bi \u00een Tarantool, iar num\u0103rul acestora se ridic\u0103 la aproximativ 50 de milioane. Sistemul este shardat \u00een func\u021bie de ID-ul utilizatorului, distribuit pe mai multe centre de date, cu leg\u0103turi pe servicii Go.
\nLa RPS, liderul a fost odat\u0103 \u201ePromotayzer\u201d, ating\u00e2nd p\u00e2n\u0103 la 6 mii de cereri. La un moment dat aveam 50-60 de instan\u021be. Acum, liderul \u00een RPS este profilul utilizatorului, av\u00e2nd aproximativ 12 mii. \u00cen acest serviciu se aplic\u0103 un shardare personalizat\u0103 cu divizarea pe intervale de ID-uri de utilizator. Serviciul deserveste mai mult de 20 de ma\u0219ini, dar asta este prea mult; pl\u0103nuim s\u0103 reducem resursele alocate, deoarece patru-patru ma\u0219ini sunt suficiente.<\/p>\n

Serviciul de sesiuni este primul nostru serviciu pe vshard \u0219i Cartridge. Configurarea vshard \u0219i actualizarea Cartridge au necesitat un anumit efort din partea noastr\u0103, dar \u00een final totul a mers bine.<\/p>\n

Serviciul de afi\u0219are a diferitelor bannere pe site \u0219i \u00een aplica\u021bia mobil\u0103 a fost unul dintre primele lansate direct pe Tarantool. Acest serviciu este remarcabil deoarece are aproximativ 6-7 ani, este \u00eenc\u0103 func\u021bional \u0219i nu a fost niciodat\u0103 repornit. A fost utilizat\u0103 replicarea master-master. Niciodat\u0103 nu s-a defectat nimic.<\/p>\n

Exist\u0103 un exemplu de utilizare a Tarantool pentru func\u021bionalitatea de bucle rapide \u00een sistemul de depozit pentru a verifica rapid informa\u021biile \u00een anumite cazuri. Am \u00eencercat s\u0103 folosim Redis pentru acest lucru, dar datele \u00een memorie ocupau mai mult spa\u021biu dec\u00e2t \u00een Tarantool.<\/p>\n

Serviciile de list\u0103 de a\u0219teptare, subscrip\u021biile clien\u021bilor, pove\u0219tile la mod\u0103 \u0219i produsele am\u00e2nate func\u021bioneaz\u0103 de asemenea cu Tarantool. Ultimul serviciu ocup\u0103 aproximativ 120 GB \u00een memorie. Este cel mai voluminos serviciu din cele men\u021bionate anterior. <\/p>\n

Concluzie<\/h3>\n

\nDatorit\u0103 indexurilor secundare combinate cu key-value \u0219i tranzac\u021bionalitate, Tarantool este ideal pentru arhitecturi bazate pe microservicii. Totu\u0219i, ne-am confruntat cu dificult\u0103\u021bi atunci c\u00e2nd implementam modific\u0103ri \u00een servicii cu mult\u0103 logic\u0103 scris\u0103 \u00een Lua \u2014 serviciile adesea nu mai func\u021bionau. Nu am reu\u0219it s\u0103 \u00eenvingem acest lucru, iar \u00een timp am ajuns la combina\u021bii diferite de Lua \u0219i Go: \u0219tim unde s\u0103 folosim un limbaj \u0219i unde pe cel\u0103lalt.<\/p>\n

What else to read on the topic<\/b><\/p>\n