Käyttäjän toimintopalvelu: Monoliitista pilveen

(Souhaib Guitouni) (23. kesäkuuta 2020)

Johdanto

Historiallisesti BlaBlaCarin taustakuva oli iso PHP-monoliitti. Se antoi meille mahdollisuuden toistaa ja rakentaa ominaisuuksia nopeasti, mutta pitkällä aikavälillä sitä ei ollut helppo ymmärtää, ylläpitää ja kehittää. Viime vuosina olemme hajottaneet tämän vanhan monoliitin ja siirtyneet kohti palvelukeskeistä arkkitehtuuria.

Tämä artikkeli on yksi tarinoista siitä, miten hallitsemme tätä siirtymää, jossa on joitain yksityiskohtia työkalut, jotka auttoivat meitä matkan varrella. Se kattaa tekniset pinovalinnat, yleisen arkkitehtuurin ja palautteen käytetyistä työkaluista.

I – Miksi miksi

Kun BlaBlaCarin toiminta laajenee, monoliittisen arkkitehtuurin käyttö kasvaa yhä enemmän. rajoittava, lähinnä siksi, että:

  • Elämisen aikana monoliitit putoavat kytkentään;
  • On vaikea järjestää tiimejä, jotka työskentelevät erillisten lokien kanssa samalla koodipohjalla;
  • Monoliitteja on vaikea ymmärtää uusille tulokkaille;
  • Kaikista yllä mainituista uusista toiminnoista tulee erittäin kalliita.

Siksi olemme muutaman viime vuoden aikana suunnitelleet alustamme SOA-arkkitehtuuriksi, etsivät:

  • Toiminnallisesti rajatut palvelimet: palvelu hallinnoi yhtä toimintoa ja on täysin vastuussa sen toteuttamisesta.
  • Löyhästi kytketyt palvelut, jotka voivat kehittyä itsenäisesti. Joukkueet voivat työskennellä ja ottaa käyttöön omassa tahdissaan.
  • Lisää koodin omistusta, joten palveluilla on määritelty ja pienempi soveltamisala, jolloin tiimit voivat ylläpitää ja käyttää niitä helpommin.

II – Käyttäjätapahtumien laajuus ja historia

Viimeisimmät rivit, joista tehtiin itsenäinen palvelu, olivat käyttäjän toimet. Ne auttavat yhteisösuhdetiimiämme diagnosoimaan ja ratkaisemaan käyttäjien ongelmat, kuten hyvitysten antamisen ja poikkeavuuksien havaitsemisen tai vilpillisen käyttäytymisen jäljittämisen.

Käyttäjätapahtumien määrä, kuten voit odottaa, on valtava. Historiallisesti yhtenä SQL-taulukkona koodin tässä osassa oli suorituskykyongelmia. Löysimme ratkaisuja joka kerta, mutta laajentumisen myötä ongelmat kasvoivat ja kasvoivat:

  • Yksi ensimmäinen ratkaisu oli luoda hakemistoja kyselyjen nopeuttamiseksi.
  • Toinen oli sirpaleita tietokanta useisiin taulukoihin.

Nämä ratkaisut kuitenkin saavuttivat rajansa ja ajan myötä aloimme saada suorituskykyongelmia.

III – tietojen tallennus

1 – Tie NoSQL: ään

Tietovaraston valinta perustui pääasiassa tekniseen vaatimukset:

  • Tietoja on valtava määrä
  • Suuri määrä inserttejä
  • Useita lukuja sekunnissa, jolloin tarvitaan uutta tietoa ja suorituskykyä
  • Mahdollisuus suodattaa kohtuullisessa ajassa

Etsimme tietysti NoSQL-tietokantaa, koska jakelu antaisi meille mahdollisuuden tallentaa ja käsitellä suuria määriä dataa ja mittakaavaa, kun tarvitaan.

2 – Hallittu palvelu

Halusimme myös mennä hallitulla palvelulla ylläpitokustannusten alentamiseksi. Hajautetut tietokannat, kuten Hbase ja Cassandra, tunnetaan tunnetusti vaikeuksista, joita he hankkivat tietokannan hallintatiimeille. Vielä tärkeämpää on, että sovelluskehitystiimille halusimme keskittyä tuottamaan käyttäjien toimintojen logiikan sen sijaan, että vietämme aikamme tietokantainfrastruktuurin ongelmien korjaamiseen. Se oli myös mahdollisuus testata uutta tuotetta, koska sovelluksen laajuus ei ole liian laaja. Halusimme antaa jotain uutta laukausta!

3 – Lopullinen valinta

Valinta laskeutui Bigtable-levylle seuraavista syistä:

  • Määrä: Se on suunniteltu käsittelemään suuria tietomääriä, toisin kuin useimmat SQL-tietokannat, ilmentymä pystyy käsittelemään 10 000 lisäystä sekunnissa, joten valitsimme vähimmäiskokoonpano vain kolmella solmulla.
  • Skaalautuvuus: Se on skaalautuva ja helppo kopioida, voit hallita myös tietoversioita.
  • Hallintakustannukset: Se on hallittu palvelu.
  • Suorituskyky: Se on GCP-palvelu, joka antaa meille erinomaisen suorituskyvyn, koska se on samassa infrastruktuurissa kuin GKE: ssä käyttöön otettu palvelu.

III – Hyppääminen liikkuvasta junasta toiseen

Vaikea asia siirtyminen monoliitista palveluun on palvelun jatkuvuuden tarjoaminen ulkoisesta näkökulmasta eikä tietojen häviämistä.

Tämän tarjoamiseksi päätimme suorittaa uuden palvelun, pitää vanhan järjestelmän toiminnassa ja kirjoittaa uudet toiminnot molempiin REST: n kautta. Seuraava vaihe on siirtää historialliset tiedot monoliitista uuteen palveluun. Tämä toiminto saattaa aiheuttaa kaksinkertaisen määrän, joten alkuperäisen datakuorman tulisi käsitellä deduplikaatiota. Kolmas vaihe on lukea uudesta palvelusta vanhan järjestelmän sijaan. Viimeinen vaihe on sulkea monoliittinen osa ja vanha SQL-tietokanta, kun kaikki toimii palvelussa.

IV – tietojen siirtäminen

1 – MySQL: stä Bigtable-keskusteluun

Nyt kun päätimme, mikä kohdetallennustilamme on ja miten se otetaan käyttöön, aloimme ajatella tapoja siirtää tietoja monoliitista uuteen tietokantaan. Tällainen operaatio on kriittinen ja siirtotyön tulisi olla:

  • Yksinkertainen ja helppo kehittää: monimutkaisuus on tietokantaliittimissä
  • Suorituskykyinen: koska se lukee valtavasti tietomäärät, haluamme, että tulos on mahdollisimman nopea
  • Luotettava: emme halunneet tietojen menetystä
  • Helppo käynnistää uudelleen: jos asiat menevät pieleen, halusimme jotain mitä voisimme Käynnistä yksinkertaisesti uudelleen ilman paljon manuaalisia toimintoja, komentosarjojen komentosarjat kaikkialla ja monimutkainen menettely.
  • Muunnosten salliminen: Meidän oli yhdistettävä tietoja useista MySQL-tietokannoista ja taulukoista lopullisten Bigtable-tiedostojen saamiseksi, tämä voi olla vaikeaa, jos käsikirjoitettu.

2 – Apache Beam ja tietovirta

Päätimme käyttää Dataflowa, joka on Google Cloudin tarjoama hajautettu hallinnoitu palvelu, jonka avulla ihmiset voivat siirtää tietoja erä- ja suoratoistotiloissa.

Toisaalta Apache Beam on kehys, jota käytetään hajautettujen komentosarjojen koodaamiseen. . Voit sitten käyttää sitä monilla hajautetuilla moottoreilla, kuten Dataflow, Spark, Flink … Toisin sanoen, se on abstraktiokerros määrittelemään muunnoksesi, jotka voidaan ymmärtää useille moottoreille.

Toinen hieno asia Apache Beamista on että sillä on valmiina liittimet useisiin tietolähteisiin, mukaan lukien sekä MySQL että Bigtable. Joten loimme datan muunnokset lukemalla Mysql-vanhoista taulukoista, yhdistämällä ne ja sijoittamalla tuloksen Bigtable-kansioon.

2 – Kuinka se meni?

Teimme muutaman havainnon siirron suorittamisen aikana:

  • Se oli MySQL: lle uuvuttava tehtävä: suorituskykyongelmien välttäminen, sinun on ehdottomasti vältettävä sen suorittamista kriittisessä tietokannassa. Tämän ongelman välttämiseksi suoritimme sen tällaisia ​​tehtäviä varten tehdyssä kopiotietokannassa. Seurasimme seurantapalvelumme (Prometheus / Grafana) suoritusta, joka osoitti, että Dataflow-rinnakkaiskoneet pakottavat MySQL: n.
  • Bigtable ei myöskään ollut helppoa: meillä oli pieni 3 koneen esiintymä, joka pystyi antamaan 30.000 inserttiä. sekunnissa. Jos suoritat useita Dataflow-töitä, menet paljon pidemmälle. Ajattele siis viisaasti, kuinka monta konetta haluat olla rinnakkain, koska enimmäismäärä saa sinut menettämään rahaa.
  • MySQL Beam -liitin ei suoratoista tietoja: MySQL-liitin suorittaa SQL-käskyn ja odottaa ladata koko vastaus jatkaaksesi. Tämä aiheuttaa sinulle RAM-muistin ongelmia, jos lataat paljon tietoja. Joten sinun on testattava ja määritettävä käyttäjäryhmät, jotta vältetään muistipoikkeus.

V – Backend-palvelu

Useita arkkitehtuurimalleja oli mahdollista, me Halusin käyttää arkkitehtuuria, joka voi kehittyä tulevaisuudessa ja jonka voimme rakentaa askel askeleelta elävän liikenteen avulla ensimmäisestä vaiheesta.

Päätimme luoda palvelun Spring WebFluxin, reaktiivisen kehyksen avulla. , jotta sinulla olisi estämättömiä pyyntöjä ja sitten parempi suorituskyky toiminnallisilla päätepisteillä. Käytimme Reactoria parhaaseen integraatioon Springin kanssa.

1 – Integraatiotestaus Bigtable-levyllä

Integraatiotestit kutsuvat API: ta useilla hyötykuormilla / otsikoilla ja tarkistavat, onko vastaus odotettua. Tätä varten tarvitsimme palvelumme takana Bigtable-esiintymän, koska halusimme tosielämän testejä.

Tämä esiintymä on puhdistettava jokaisella ajona aloittaakseen samasta tilasta joka kerta.

Ratkaisuna oli käyttää Bigtable-asiakas SDK: ssa olevaa Bigtable-emulaattoria. SDK on erittäin rikas, ja sillä on enemmän ominaisuuksia, kuten järjestelmänvalvojan hallinta ja valvonta.

2 – Käyttöönotto ja infrastruktuuri

GCP-infrastruktuurimme on Google Kubernetesin ja Istion päällä. Me hoidamme koko asian Helmin ja Fluxin kanssa. Blogissamme on tulossa muita artikkeleita, joissa kerrotaan tarkemmin infrastruktuuristamme!

Palvelullamme oli tietysti klassinen seuranta-, loki- ja hälytyspää, ilman niitä emme pystyisi pitämään sitä julkisena , joka perustuu Prometheus / Grafanaan ja ELK: iin.

Viimeiset ajatukset

Suurten tietomäärien hallitsemiseksi menimme Bigtableen sen skaalautumiskyvyn ansiosta.Meillä oli useita haasteita, kuten tietomallin määritteleminen Bigtable-avainmallilla, suurten tietomäärien siirtäminen SQL-tilatietokannasta hallittuun NoSQL: ään, testaus ja seuranta.

Aluksi otimme palvelun käyttöön paikan päällä sijaitsevassa datakeskuksessamme ja siirtymällä GCP: hen jaoimme latenssin kolmella. Yhteisösuhdejoukkueillamme on nyt nopeampi vasteaika ja olemme innoissaan.