A tots ens encanten les històries. Ens agrada seure al voltant del foc i parlar de les nostres victòries passades, batalles o simplement de la nostra experiència laboral.
Avui és només un dia així. I encara que ara mateix no estiguis al foc, tenim una història per a tu. La història de com vam començar a treballar amb l'emmagatzematge a Tarantool.
Hi havia una vegada, la nostra empresa disposava d'un parell de “monòlits” i un de “sostre” per a tots, als quals aquests monòlits s'anaven acostant a poc a poc, limitant el vol de la nostra empresa, el nostre desenvolupament. I hi havia una comprensió clara: un dia colpejarem fort aquest sostre.
Ara és la ideologia imperant de separar-ho tot i tothom, des dels equips fins a la lògica empresarial. Com a resultat, tenim, per exemple, dos DC que són pràcticament independents a nivell de xarxa. I després tot va ser completament diferent.
Avui dia, hi ha moltes eines i eines per fer canvis en forma de CI/CD, K8S, etc. En l'època "monolítica", no necessitàvem tantes paraules estrangeres. N'hi havia prou amb corregir l'"emmagatzematge" a la base de dades.
Però el temps va avançar i el nombre de sol·licituds va avançar juntament amb ell, de vegades disparant RPS més enllà de les nostres capacitats. Amb l'entrada al mercat dels països de la CEI, la càrrega del processador de bases de dades del primer monòlit no va baixar del 90% i RPS es va mantenir al nivell de 2400. I no només eren petits selectors, sinó consultes pesades amb un un munt de comprovacions i JOIN que es podrien executar gairebé per a la meitat de les dades en un context d'IO gran.
Quan les vendes de Black Friday van començar a aparèixer a l'escena, i Wildberries va ser un dels primers a mantenir-les a Rússia, la situació es va tornar completament trista. Després de tot, la càrrega en aquests dies augmenta tres vegades.
Oh, aquests "temps monolítics"! Estic segur que has viscut alguna cosa semblant i encara no pots entendre com et pot passar això.
Què pots fer? La moda és inherent a la tecnologia. Fa uns 5 anys, vam haver de replantejar una d'aquestes modificacions en forma d'un lloc existent al servidor .NET i MS SQL, que guardava acuradament tota la lògica del propi lloc. El vaig guardar amb tanta cura que serrar un monòlit així va resultar ser un plaer llarg i gens fàcil.
Una petita digressió.
En diversos esdeveniments dic: "si no vas veure un monòlit, llavors no vas créixer!" M'interessa la teva opinió sobre aquest tema, escriu-la als comentaris.
Un so de tro
Tornem a la nostra "foguera". Per distribuir la càrrega de la funcionalitat "monolítica", vam decidir dividir el sistema en microserveis basats en tecnologies de codi obert. Perquè, com a mínim, són més barats d'escalar. I enteníem al 100% que hauríem d'escalar (i molt). Després de tot, ja en aquell moment era possible entrar als mercats dels països veïns i el nombre de registres, així com el nombre de comandes, van començar a créixer encara més fort.
Després d'haver analitzat els primers candidats a la sortida del monòlit als microserveis, ens vam adonar que el 80% de l'escriptura en ells prové de sistemes de back office, i de lectura des de front office. En primer lloc, es tracta d'un parell de subsistemes importants per a nosaltres: dades d'usuari i un sistema per calcular el cost final dels béns basat en informació sobre descomptes i cupons addicionals dels clients.
Sagnat. Ara fa por d'imaginar-ho, però a més dels subsistemes esmentats anteriorment, també es van eliminar del nostre monòlit catàlegs de productes, un carretó de la compra d'usuaris, un sistema de cerca de productes, un sistema de filtratge de catàlegs de productes i diversos tipus de sistemes de recomanació. Per al funcionament de cadascun d'ells, hi ha classes separades de sistemes a mida, però una vegada tots vivien en una "casa".
Immediatament vam planejar transferir les dades dels nostres clients al sistema fragmentat. L'eliminació de la funcionalitat per calcular el cost final dels béns requeria una bona escalabilitat per a la lectura, ja que creava la càrrega RPS més gran i era la més difícil d'implementar per a la base de dades (en el procés de càlcul hi participen moltes dades).
Com a resultat, hem creat un esquema que encaixa bé amb Tarantool.
Aleshores, per al funcionament dels microserveis, es van escollir esquemes de treball amb diversos centres de dades en màquines virtuals i maquinari. Com es mostra a les figures, les opcions de replicació de Tarantool es van aplicar tant en mode mestre-mestre com en mode mestre-esclau.
Arquitectura. Opció 1. Servei d'usuari
Actualment, hi ha 24 fragments, cadascun dels quals té 2 instàncies (una per cada DC), tots en mode mestre-mestre.
A la part superior de la base de dades hi ha aplicacions que accedeixen a rèpliques de bases de dades. Les aplicacions funcionen amb Tarantool a través de la nostra biblioteca personalitzada, que implementa la interfície del controlador Tarantool Go. Veu totes les rèpliques i pot treballar amb el mestre per llegir i escriure. Essencialment, implementa el model de conjunt de rèpliques, que afegeix lògica per seleccionar rèpliques, realitzar reintents, un interruptor i un límit de velocitat.
En aquest cas, és possible configurar la política de selecció de rèpliques en el context de fragments. Per exemple, roundrobin.
Arquitectura. Opció 2. Servei de càlcul del cost final de la mercaderia
Fa uns mesos, la majoria de les sol·licituds de càlcul del cost final de la mercaderia anaven a un nou servei, que, en principi, funciona sense bases de dades, però fa un temps tot es va tramitar al 100% per un servei amb Tarantool sota el capó.
La base de dades del servei consta de 4 mestres en els quals el sincronitzador recopila dades i cadascun d'aquests mestres de rèplica distribueix dades a rèpliques de només lectura. Cada mestre té aproximadament 15 rèpliques d'aquest tipus.
Tant en el primer com en el segon esquema, si un DC no està disponible, l'aplicació pot rebre dades en el segon.
Val la pena assenyalar que la replicació a Tarantool és bastant flexible i es pot configurar en temps d'execució. En altres sistemes, van sorgir dificultats. Per exemple, canviar els paràmetres max_wal_senders i max_replication_slots a PostgreSQL requereix un reinici de l'assistent, que en alguns casos pot provocar la interrupció de les connexions entre l'aplicació i el SGBD.
Busqueu i trobareu!
Per què no ho vam fer "com la gent normal", sinó que vam triar una manera atípica? Depèn del que es consideri normal. Molts generalment fan un clúster a partir de Mongo i el distribueixen entre tres DC geodistribuïts.
Aleshores, ja teníem dos projectes de Redis. El primer era una memòria cau i el segon era un emmagatzematge persistent per a dades no massa crítiques. Va ser molt difícil amb ell, en part per culpa nostra. De vegades hi havia volums força grans a la clau, i de tant en tant el lloc es trobava malalt. Hem utilitzat aquest sistema en la versió mestre-esclau. I hi va haver molts casos en què li va passar alguna cosa al mestre i la replicació es va trencar.
És a dir, Redis és bo per a tasques sense estat, no amb estat. En principi, permetia resoldre la majoria de problemes, però només si eren solucions clau-valor amb un parell d'índexs. Però Redis en aquell moment estava bastant trist amb la persistència i la replicació. A més, hi va haver queixes sobre el rendiment.
Hem pensat en MySQL i PostgreSQL. Però el primer d'alguna manera no ens va enganxar, i el segon és un producte bastant sofisticat en si mateix, i seria inadequat construir-hi serveis senzills.
Vam provar RIAK, Cassandra, fins i tot una base de dades de gràfics. Totes aquestes són solucions bastant de nínxol que no eren adequades per al paper d'eina universal general per crear serveis.
Al final ens vam establir per Tarantool.
Ens hi vam recórrer quan estava a la versió 1.6. Ens hi va interessar la simbiosi de clau-valor i la funcionalitat d'una base de dades relacional. Hi ha índexs secundaris, transaccions i espais, són com taules, però no són senzills, hi pots emmagatzemar diferents nombres de columnes. Però la característica assassina de Tarantool eren els índexs secundaris combinats amb el valor-clau i la transaccionalitat.
La comunitat de parla russa sensible, disposada a ajudar en el xat, també va tenir un paper. Ho hem utilitzat activament i vivim directament al xat. I no us oblideu de la persistència decent sense errors i errors evidents. Si mireu la nostra història amb Tarantool, vam tenir molt de dolor i errors amb la rèplica, però mai vam perdre dades a causa de la seva culpa!
La implementació va tenir un començament difícil
En aquell moment, la nostra pila de desenvolupament principal era .NET, a la qual no hi havia connector per a Tarantool. De seguida vam començar a fer alguna cosa a Go. També va funcionar bé amb Lua. El principal problema en aquell moment era amb la depuració: a .NET tot va molt bé amb això, però després va ser difícil endinsar-se en el món del Lua incrustat, quan no tens cap depuració excepte els registres. A més, per alguna raó la replicació es va trencar periòdicament, així que vaig haver d'aprofundir en l'estructura del motor Tarantool. El xat va ajudar amb això i, en menor mesura, amb la documentació; de vegades vam mirar el codi. Aleshores, la documentació era així.
Així, al llarg de diversos mesos, vaig aconseguir desconcertar i obtenir resultats decents treballant amb Tarantool. Hem recopilat desenvolupaments de referència a git que van ajudar amb la formació de nous microserveis. Per exemple, quan va sorgir una tasca: per crear un altre microservei, el desenvolupador va mirar el codi font de la solució de referència al repositori i no va trigar més d'una setmana a crear-ne un de nou.
Eren temps especials. Convencionalment, llavors podríeu anar a l'administrador de la taula següent i preguntar-li: "Dóna'm una màquina virtual". Uns trenta minuts més tard el cotxe ja era amb tu. T'has connectat, ho has instal·lat tot i t'ha enviat trànsit.
Avui això ja no funcionarà: cal afegir monitorització i registre al servei, cobrir la funcionalitat amb proves, demanar una màquina virtual o lliurar a Kuber, etc. En general, serà millor així, encara que trigarà més temps i serà més molest.
Divideix i governa. Quin és el tracte amb la Lua?
Hi havia un greu dilema: alguns equips no van poder implementar de manera fiable canvis en un servei amb molta lògica a Lua. Això sovint anava acompanyat de la manca de funcionament del servei.
És a dir, els desenvolupadors estan preparant algun tipus de canvi. Tarantool comença a fer la migració, però la rèplica segueix amb el codi antic; Alguns DDL o alguna altra cosa hi arriba mitjançant la replicació, i el codi simplement es desfà perquè no es té en compte. Com a resultat, el procediment d'actualització per als administradors es va establir en un full A4: aturar la rèplica, actualitzar-la, activar la rèplica, desactivar aquí, actualitzar-hi. Un malson!
Com a resultat, ara sovint intentem no fer res a Lua. Només cal que utilitzeu iproto (un protocol binari per interactuar amb el servidor), i ja està. Potser això és un desconeixement entre els desenvolupadors, però des d'aquest punt de vista el sistema és complex.
No sempre seguim cegament aquest guió. Avui no tenim blanc i negre: o tot és a Lua, o tot és a Go. Ja entenem com podem combinar-los per no acabar amb problemes migratoris més endavant.
On és ara Tarantool?
Tarantool s'utilitza en el servei per calcular el cost final dels béns tenint en compte els cupons de descompte, també conegut com "Promotor". Com he dit abans, ara es jubila: el substitueix un nou servei de catàleg amb preus precalculats, però fa sis mesos tots els càlculs es van fer a Promotizer. Anteriorment, la meitat de la seva lògica estava escrita en Lua. Fa dos anys, el servei es va convertir en un magatzem, i la lògica es va reescriure a Go, perquè la mecànica dels descomptes havia canviat una mica i el servei mancava de rendiment.
Un dels serveis més crítics és el perfil d'usuari. És a dir, tots els usuaris de Wildberries estan emmagatzemats a Tarantool, i n'hi ha uns 50 milions. Un sistema fragmentat per ID d'usuari, distribuït en diversos DC connectats als serveis Go.
Segons RPS, Promoter va ser una vegada el líder, arribant a les 6 mil peticions. En un moment donat teníem 50-60 còpies. Ara el líder en RPS són els perfils d'usuari, uns 12. Aquest servei utilitza fragments personalitzats, dividits per rangs d'identificadors d'usuari. El servei dóna servei a més de 20 màquines, però això és massa; tenim previst reduir els recursos assignats, perquè la capacitat de 4-5 màquines n'hi ha prou.
El servei de sessió és el nostre primer servei a vshard i cartridge. Configurar vshard i actualitzar Cartridge ens va requerir un esforç, però al final tot va funcionar.
El servei de visualització de diferents bàners al web i a l'aplicació mòbil va ser un dels primers que es va llançar directament a Tarantool. Aquest servei destaca pel fet que té 6-7 anys, encara està en funcionament i no s'ha reiniciat mai. Es va utilitzar la replicació mestre-mestre. Mai no es va trencar res.
Hi ha un exemple d'ús de Tarantool per a una funcionalitat de referència ràpida en un sistema de magatzem per comprovar ràpidament la informació en alguns casos. Vam intentar utilitzar Redis per a això, però les dades de la memòria ocupaven més espai que Tarantool.
Els serveis de llista d'espera, subscripcions de clients, històries actualment de moda i productes ajornats també funcionen amb Tarantool. L'últim servei a la memòria ocupa uns 120 GB. Aquest és el servei més complet dels anteriors.
Conclusió
Gràcies als índexs secundaris combinats amb el valor clau i la transaccionalitat, Tarantool és molt adequat per a arquitectures basades en microserveis. Tanmateix, vam trobar dificultats a l'hora de desplegar canvis als serveis amb molta lògica a Lua: els serveis sovint deixaven de funcionar. No vam poder superar-ho, i amb el temps vam arribar a diferents combinacions de Lua i Go: sabem on utilitzar una llengua i on utilitzar una altra.
Què més llegir sobre el tema
- Creació d'una aplicació d'alta càrrega des de zero amb Tarantool
- Elecció líder de confiança en el cartutx Tarantool
- Canal de Telegram Tarantool amb notícies sobre el producte
- Parleu de Tarantool al xat de la comunitat
Font: www.habr.com