Hei Habr!
Muistutamme, että seuraamalla kirjaa noin olemme julkaisseet yhtä mielenkiintoisen teoksen kirjastosta .
Tällä hetkellä yhteisö on vasta oppimassa tämän tehokkaan työkalun rajoja. Joten äskettäin julkaistiin artikkeli, jonka käännöksen haluaisimme esitellä sinulle. Kirjoittaja kertoo omasta kokemuksestaan, kuinka Kafka Streamsistä tehdään hajautettu tietovarasto. Nauti lukemisesta!
Apache-kirjasto käytetään maailmanlaajuisesti yrityksissä hajautettuun stream-käsittelyyn Apache Kafkan lisäksi. Yksi tämän kehyksen aliarvostetuista puolista on se, että sen avulla voit tallentaa säikeenkäsittelyn perusteella tuotettua paikallista tilaa.
Tässä artikkelissa kerron kuinka yrityksemme onnistui hyödyntämään tämän mahdollisuuden kannattavasti kehittäessään tuotetta pilvisovellusten tietoturvaan. Kafka Streamsin avulla loimme jaetut tilamikropalvelut, joista jokainen toimii vikasietoisena ja erittäin saatavilla olevana luotettavana tiedon lähteenä järjestelmän objektien tilasta. Meille tämä on askel eteenpäin sekä luotettavuuden että tuen helppouden kannalta.
Jos olet kiinnostunut vaihtoehtoisesta lähestymistavasta, jonka avulla voit käyttää yhtä keskustietokantaa tukemaan objektien muodollista tilaa, lue se, se on mielenkiintoista...
Miksi ajattelimme, että oli aika muuttaa tapaamme työskennellä jaetun tilan kanssa
Meidän piti ylläpitää eri objektien tilaa agenttiraporttien perusteella (esimerkiksi: oliko sivusto hyökkäyksen kohteena)? Ennen siirtymistä Kafka Streamiin luotimme usein yhteen keskustietokantaan (+ palvelun API) tilanhallintaan. Tällä lähestymistavalla on haittapuolensa: johdonmukaisuuden ja synkronoinnin ylläpitämisestä tulee todellinen haaste. Tietokannasta voi tulla pullonkaula tai se voi päätyä sinne ja kärsivät arvaamattomuudesta.
Kuva 1: Tyypillinen split-state-skenaario, joka nähtiin ennen siirtymistä
Kafka ja Kafka Streams: agentit viestivät näkemyksensä API:n kautta, päivitetty tila lasketaan keskustietokannan kautta
Tutustu Kafka Streamseihin, joiden avulla voit luoda jaettuja valtion mikropalveluita
Noin vuosi sitten päätimme tarkastella tarkasti yhteisiä tilaskenaarioitamme näiden ongelmien ratkaisemiseksi. Päätimme heti kokeilla Kafka Streamia – tiedämme kuinka skaalautuva, erittäin saatavilla oleva ja vikasietoinen se on, mitä monipuolisia suoratoistotoimintoja siinä on (muunnoksia, myös tilallisia). Juuri mitä tarvitsimme, puhumattakaan kuinka kypsäksi ja luotettavaksi Kafkan viestintäjärjestelmä on tullut.
Jokainen luomamme tilallinen mikropalvelu rakennettiin Kafka Streams -esiintymän päälle, jolla oli melko yksinkertainen topologia. Se koostui 1) lähteestä 2) prosessorista, jossa oli pysyvä avainarvovarasto 3) nielu:
Kuva 2: Suoratoisto-instanssiemme oletustopologia tilapitoisille mikropalveluille. Huomaa, että tässä on myös arkisto, joka sisältää suunnittelun metatiedot.
Tässä uudessa lähestymistavassa agentit laativat viestejä, jotka syötetään lähdeaiheeseen, ja kuluttajat – esimerkiksi sähköposti-ilmoituspalvelu – saavat lasketun jaetun tilan nielun (tulostusaiheen) kautta.
Kuva 3: Uusi esimerkkitehtäväkulku skenaariolle, jossa on jaetut mikropalvelut: 1) agentti luo viestin, joka saapuu Kafka-lähdeaiheeseen; 2) mikropalvelu, jossa on jaettu tila (käyttäen Kafka Streamia) käsittelee sen ja kirjoittaa lasketun tilan lopulliseen Kafka-aiheeseen; jonka jälkeen 3) kuluttajat hyväksyvät uuden tilan
Hei, tämä sisäänrakennettu avainarvovarasto on todella hyödyllinen!
Kuten edellä mainittiin, jaettu tilatopologiamme sisältää avainarvovaraston. Löysimme useita vaihtoehtoja sen käyttämiseen, ja kaksi niistä on kuvattu alla.
Vaihtoehto 1: Käytä avainarvovarastoa laskelmiin
Ensimmäinen avainarvovarastomme sisälsi laskelmiin tarvitsemamme aputiedot. Esimerkiksi joissain tapauksissa jaettu valtio määrättiin "enemmistöäänten" periaatteella. Arkisto voisi sisältää kaikki viimeisimmät agenttiraportit jonkin objektin tilasta. Sitten, kun saimme uuden raportin yhdeltä tai toiselta agentilta, voimme tallentaa sen, hakea kaikilta muilta agenteilta raportit saman objektin tilasta tallennustilasta ja toistaa laskennan.
Alla oleva kuva 4 näyttää, kuinka altistimme avain/arvovaraston prosessorin prosessointimenetelmälle, jotta uusi viesti voitiin sitten käsitellä.
Kuva 4: Avaamme pääsyn prosessorin prosessointimenetelmän avainarvovarastoon (tämän jälkeen jokaisen jaetussa tilassa toimivan skriptin tulee toteuttaa menetelmä doProcess)
Vaihtoehto 2: Luo CRUD API Kafka Streamsin päälle
Kun perustehtäväkulkumme on luotu, aloimme yrittää kirjoittaa RESTful CRUD API:ta jaetuille tilamikropalveluillemme. Halusimme pystyä hakemaan joidenkin tai kaikkien objektien tilan sekä asettamaan tai poistamaan objektin tilan (hyödyllinen taustatukeen).
Kaikkien Get State API -sovellusliittymien tukemiseksi tallensimme sen sisäänrakennettuun avainarvovarastoon pitkän aikaa aina, kun jouduimme laskemaan tilan uudelleen käsittelyn aikana. Tässä tapauksessa on melko yksinkertaista ottaa käyttöön tällainen API käyttämällä yhtä Kafka Streams -esiintymää, kuten alla olevasta luettelosta ilmenee:
Kuva 5: Sisäänrakennetun avainarvovaraston käyttäminen objektin esilasketun tilan hankkimiseen
Objektin tilan päivittäminen API:n kautta on myös helppo toteuttaa. Periaatteessa sinun tarvitsee vain luoda Kafka-tuottaja ja käyttää sitä uuden tilan sisältävän levyn tekemiseen. Tämä varmistaa, että kaikki API:n kautta luodut viestit käsitellään samalla tavalla kuin muilta tuottajilta (esim. agenteilta) saadut viestit.
Kuva 6: Voit asettaa objektin tilan Kafka-tuottajalla
Pieni komplikaatio: Kafkassa on monia osioita
Seuraavaksi halusimme jakaa käsittelykuorman ja parantaa saatavuutta tarjoamalla klusterin jaettuja mikropalveluita skenaariota kohti. Asennus oli helppoa: kun määritimme kaikki esiintymät toimimaan samalla sovellustunnuksella (ja samoilla bootstrap-palvelimilla), melkein kaikki muu tehtiin automaattisesti. Määritimme myös, että kukin lähdeaihe koostuisi useista osioista, jotta kullekin esiintymälle voitaisiin määrittää tällaisten osioiden osajoukko.
Mainitsen myös, että on yleinen käytäntö tehdä varmuuskopio tilavarastosta niin, että esimerkiksi vikatilanteen palautuessa tämä kopio siirretään toiseen esiintymään. Jokaiselle Kafka Streamsin osavaltiokaupalle luodaan replikoitu aihe muutoslokin kanssa (joka seuraa paikallisia päivityksiä). Siten Kafka varmuuskopioi jatkuvasti valtion myymälää. Siksi, jos jokin Kafka Streams -esiintymä epäonnistuu, tilavarasto voidaan nopeasti palauttaa toiseen ilmentymään, johon vastaavat osiot menevät. Testimme ovat osoittaneet, että tämä tapahtuu muutamassa sekunnissa, vaikka kaupassa olisi miljoonia levyjä.
Siirtyminen yhdestä jaetun tilan mikropalvelusta mikropalveluklusteriin, Get State API:n käyttöönotto on vähemmän triviaalia. Uudessa tilanteessa kunkin mikropalvelun tilavarasto sisältää vain osan kokonaiskuvasta (ne objektit, joiden avaimet on kartoitettu tiettyyn osioon). Meidän piti määrittää, mikä ilmentymä sisälsi tarvitsemamme objektin tilan, ja teimme tämän säikeen metatietojen perusteella, kuten alla on esitetty:
Kuva 7: Viron metatietojen avulla määritämme, mistä esiintymästä halutun objektin tilaa kysytään; samanlaista lähestymistapaa käytettiin GET ALL API:n kanssa
Keskeiset havainnot
Kafka Streamsin valtion myymälät voivat toimia de facto hajautettuna tietokanta,
- toistetaan jatkuvasti Kafkassa
- CRUD API voidaan helposti rakentaa tällaisen järjestelmän päälle
- Useiden osioiden käsittely on hieman monimutkaisempaa
- On myös mahdollista lisätä yksi tai useampi tilavarasto suoratoistotopologiaan aputietojen tallentamiseksi. Tätä vaihtoehtoa voidaan käyttää:
- Laskelmiin tarvittavien tietojen pitkäaikainen tallennus virrankäsittelyn aikana
- Tietojen pitkäaikainen tallennus, josta voi olla hyötyä seuraavan kerran, kun suoratoisto-instanssi määritetään
- paljon enemmän...
Nämä ja muut edut tekevät Kafka Streamsistä hyvin soveltuvan globaalin tilan ylläpitämiseen meidän kaltaisessa hajautetussa järjestelmässä. Kafka Streams on osoittautunut erittäin luotettavaksi tuotannossa (emme ole käytännössä menettäneet viestejä sen käyttöönoton jälkeen), ja olemme varmoja, että sen ominaisuudet eivät lopu tähän!
Lähde: will.com