26. helmikuuta järjestimme Apache Ignite GreenSource -tapaamisen, jossa avoimen lähdekoodin projektin osallistujat puhuivat . Tärkeä tapahtuma tämän yhteisön elämässä oli komponentin uudelleenjärjestely , jonka avulla voit ottaa käyttöön mukautettuja mikropalveluita suoraan Ignite-klusteriin. Hän puhui tästä vaikeasta prosessista tapaamisessa , ohjelmistosuunnittelija ja Apache Ignite -avustaja yli kahden vuoden ajan.
Aloitetaan siitä, mitä Apache Ignite yleensä on. Tämä on tietokanta, joka on hajautettu avain-/arvovarasto, joka tukee SQL:ää, transaktiota ja välimuistia. Lisäksi Igniten avulla voit ottaa mukautettuja palveluita käyttöön suoraan Ignite-klusteriin. Kehittäjällä on pääsy kaikkiin Igniten tarjoamiin työkaluihin - hajautettuihin tietorakenteisiin, viestintään, suoratoistoon, laskemiseen ja dataverkkoon. Esimerkiksi Data Gridiä käytettäessä erillinen tiedontallennusinfrastruktuurin hallinnointiongelma ja sen seurauksena siitä aiheutuvat yleiskustannukset poistuvat.
Service Grid API:n avulla voit ottaa palvelun käyttöön yksinkertaisesti määrittämällä käyttöönottomallin ja vastaavasti itse palvelun kokoonpanossa.
Tyypillisesti käyttöönottomalli on osoitus esiintymien määrästä, jotka tulisi ottaa käyttöön klusterin solmuissa. On olemassa kaksi tyypillistä käyttöönottosuunnitelmaa. Ensimmäinen on Cluster Singleton: yksi käyttäjäpalvelun esiintymä on taatusti saatavilla klusterissa milloin tahansa. Toinen on Node Singleton: yksi palvelun ilmentymä otetaan käyttöön jokaisessa klusterin solmussa.
Käyttäjä voi myös määrittää palveluinstanssien määrän koko klusterissa ja määrittää predikaatin sopivien solmujen suodattamiseen. Tässä skenaariossa Service Grid itse laskee optimaalisen jakelun palveluiden käyttöönotolle.
Lisäksi on olemassa sellainen ominaisuus kuin Affinity Service. Affiniteetti on funktio, joka määrittää avainten suhteen osioihin ja osapuolten suhteen topologian solmuihin. Avaimen avulla voit määrittää ensisijaisen solmun, johon tiedot tallennetaan. Näin voit liittää oman palvelusi avain- ja affiniteettifunktion välimuistiin. Jos affiniteettitoiminto muuttuu, automaattinen uudelleensijoittaminen tapahtuu. Näin palvelu sijoittuu aina lähelle sitä dataa, jota se tarvitsee käsitellä, ja vähentää siten tiedon saannin ylimääräistä kustannuksia. Tätä järjestelmää voidaan kutsua eräänlaiseksi kollokoiduksi laskennaksi.
Nyt kun olemme selvittäneet, mikä Service Gridin kauneus on, puhutaanpa sen kehityshistoriasta.
Mitä tapahtui ennen
Service Gridin edellinen toteutus perustui Igniten tapahtumakohtaiseen replikoituun järjestelmän välimuistiin. Igniten sana "välimuisti" viittaa tallennustilaan. Eli tämä ei ole jotain väliaikaista, kuten saatat ajatella. Huolimatta siitä, että välimuisti on replikoitu ja jokainen solmu sisältää koko tietojoukon, välimuistin sisällä sillä on osioitu esitys. Tämä johtuu tallennustilan optimoinnista.
Mitä tapahtui, kun käyttäjä halusi ottaa palvelun käyttöön?
- Kaikki klusterin solmut tilasivat tallennustietojen päivittämisen sisäänrakennetun Continuous Query -mekanismin avulla.
- Aloittava solmu teki luku-sitovan tapahtuman yhteydessä tietueen tietokantaan, joka sisälsi palvelukonfiguraation, mukaan lukien sarjoitetun ilmentymän.
- Kun koordinaattori sai ilmoituksen uudesta merkinnästä, hän laski jakauman kokoonpanon perusteella. Tuloksena oleva objekti kirjoitettiin takaisin tietokantaan.
- Jos solmu oli osa jakelua, koordinaattorin oli otettava se käyttöön.
Mikä ei sopinut meille
Jossain vaiheessa tulimme siihen tulokseen, että palveluiden kanssa ei toimi näin. Syitä oli useita.
Jos käyttöönoton aikana tapahtui virhe, se selvisi vain sen solmun lokeista, missä kaikki tapahtui. Käytössä oli vain asynkroninen käyttöönotto, joten kun hallinta palautettiin käyttäjälle käyttöönottomenetelmästä, palvelun käynnistämiseen tarvittiin lisäaikaa - eikä käyttäjä pystynyt tänä aikana hallitsemaan mitään. Palveluverkon kehittämiseksi edelleen, uusien ominaisuuksien luomiseksi, uusien käyttäjien houkuttelemiseksi ja kaikkien elämän helpottamiseksi, jonkin on muututtava.
Uutta Service Gridiä suunnitellessa halusimme ennen kaikkea taata synkronisen käyttöönoton: heti kun käyttäjä palautti hallinnan API:lta, hän pääsi heti käyttämään palveluita. Halusin myös antaa aloitteentekijälle mahdollisuuden käsitellä käyttöönottovirheet.
Lisäksi halusin yksinkertaistaa toteutusta eli päästä eroon transaktioista ja tasapainottamisesta. Huolimatta siitä, että välimuisti on replikoitu eikä tasapainotusta ole, ongelmia ilmeni laajan käyttöönoton aikana, jossa oli monia solmuja. Kun topologia muuttuu, solmujen on vaihdettava tietoja, ja laajalla käyttöönotolla nämä tiedot voivat painaa paljon.
Kun topologia oli epävakaa, koordinaattorin täytyi laskea palvelujen jakautuminen uudelleen. Ja yleensä, kun joudut työskentelemään epävakaan topologian tapahtumien kanssa, tämä voi johtaa vaikeasti ennakoitaviin virheisiin.
Ongelmat
Mitä ovat globaalit muutokset ilman niihin liittyviä ongelmia? Ensimmäinen niistä oli topologian muutos. Sinun on ymmärrettävä, että milloin tahansa, jopa palvelun käyttöönoton hetkellä, solmu voi tulla klusteriin tai poistua siitä. Lisäksi, jos solmu liittyy käyttöönoton yhteydessä klusteriin, on välttämätöntä siirtää johdonmukaisesti kaikki tiedot palveluista uudelle solmulle. Ja emme puhu vain siitä, mitä on jo otettu käyttöön, vaan myös nykyisistä ja tulevista käyttöönotoista.
Tämä on vain yksi ongelmista, jotka voidaan koota erilliseen luetteloon:
- Kuinka ottaa staattisesti määritettyjä palveluita käyttöön solmun käynnistyksen yhteydessä?
- Solmun jättäminen klusterista - mitä tehdä, jos solmu isännöi palveluita?
- Mitä tehdä, jos koordinaattori on vaihtunut?
- Mitä tehdä, jos asiakas muodostaa yhteyden uudelleen klusteriin?
- Pitääkö aktivointi-/deaktivointipyynnöt käsitellä ja miten?
- Entä jos he vaatisivat välimuistin tuhoamista, ja meillä on siihen sidottu affiniteettipalvelut?
Eikä siinä vielä kaikki.
päätös
Tavoitteeksi valitsimme Event Driven -lähestymistavan, jossa toteutetaan viestien avulla tapahtuva prosessiviestintä. Ignite toteuttaa jo kaksi komponenttia, joiden avulla solmut voivat välittää viestejä keskenään - communication-spi ja Discovery-spi.
Communication-spi sallii solmujen kommunikoida suoraan ja välittää viestejä. Se soveltuu hyvin suurten tietomäärien lähettämiseen. Discovery-spi antaa sinun lähettää viestin kaikille klusterin solmuille. Vakiototeutuksessa tämä tehdään rengastopologian avulla. Myös Zookeeperiin on integroitu, tässä tapauksessa käytetään tähtitopologiaa. Toinen tärkeä huomionarvoinen seikka on, että discovery-spi takaa, että viesti toimitetaan varmasti oikeassa järjestyksessä kaikkiin solmuihin.
Katsotaanpa käyttöönottoprotokollaa. Kaikki käyttäjien käyttöönotto- ja purkupyynnöt lähetetään Discovery-spi:n kautta. Tämä antaa seuraavan takuu:
- Pyynnön vastaanottavat kaikki klusterin solmut. Tämä mahdollistaa pyynnön käsittelyn jatkamisen koordinaattorin vaihtuessa. Tämä tarkoittaa myös sitä, että yhdessä viestissä jokaisella solmulla on kaikki tarvittavat metatiedot, kuten palvelun konfiguraatio ja sen serialisoitu ilmentymä.
- Viestien toimittamisen tiukka järjestys auttaa ratkaisemaan konfiguraatioristiriidat ja kilpailevat pyynnöt.
- Koska solmun pääsy topologiaan käsitellään myös Discovery-spi:n kautta, uusi solmu saa kaikki palveluiden kanssa työskentelyyn tarvittavat tiedot.
Kun pyyntö vastaanotetaan, klusterin solmut vahvistavat sen ja luovat käsittelytehtäviä. Nämä tehtävät asetetaan jonoon ja erillinen työntekijä käsittelee ne toisessa säikeessä. Se toteutetaan tällä tavalla, koska käyttöönotto voi viedä huomattavan paljon aikaa ja viivyttää kallista etsintävirtaa sietämättömästi.
Käyttöönoton johtaja käsittelee kaikki jonosta tulevat pyynnöt. Siinä on erityinen työntekijä, joka vetää tehtävän tästä jonosta ja alustaa sen käyttöönoton aloittamiseksi. Tämän jälkeen suoritetaan seuraavat toimet:
- Jokainen solmu laskee itsenäisesti jakauman uuden deterministisen osoitusfunktion ansiosta.
- Solmut luovat viestin käyttöönoton tuloksista ja lähettävät sen koordinaattorille.
- Koordinaattori kokoaa kaikki viestit ja luo koko käyttöönottoprosessin tuloksen, joka lähetetään Discovery-spi:n kautta kaikille klusterin solmuille.
- Kun tulos on vastaanotettu, käyttöönottoprosessi päättyy, minkä jälkeen tehtävä poistetaan jonosta.
Uusi tapahtumalähtöinen suunnittelu: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Jos käyttöönoton aikana tapahtuu virhe, solmu sisällyttää tämän virheen välittömästi viestiin, jonka se lähettää koordinaattorille. Viestien yhdistämisen jälkeen koordinaattorilla on tiedot kaikista käyttöönoton aikana tapahtuneista virheistä ja hän lähettää tämän viestin discovery-spi:n kautta. Virhetiedot ovat saatavilla missä tahansa klusterin solmussa.
Kaikki tärkeät tapahtumat Service Gridissä käsitellään tällä toiminta-algoritmilla. Esimerkiksi topologian muuttaminen on myös viesti discovery-spi:n kautta. Ja yleensä, verrattuna aiempaan, protokolla osoittautui melko kevyeksi ja luotettavaksi. Riittää käsittelemään kaikkia tilanteita käyttöönoton aikana.
Mitä tapahtuu seuraavaksi
Nyt suunnitelmista. Kaikki suuret muutokset Ignite-projektiin tehdään Ignite-parannusaloitteena, jota kutsutaan IEP:ksi. Service Grid -uudistuksessa on myös IEP - pilkkaavalla otsikolla "Öljynvaihto huoltoverkossa". Mutta itse asiassa emme vaihtaneet moottoriöljyä, vaan koko moottoria.
Jaoimme IEP:n tehtävät kahteen vaiheeseen. Ensimmäinen on suuri vaihe, joka koostuu käyttöönottoprotokollan uudelleenkäsittelystä. Se on jo mukana masterissa, voit kokeilla uutta Service Gridiä, joka ilmestyy versioon 2. Toinen vaihe sisältää monia muita tehtäviä:
- Kuuma uudelleenjärjestely
- Palvelun versiointi
- Lisääntynyt vikasietokyky
- Laiha asiakas
- Työkaluja erilaisten mittareiden seurantaan ja laskemiseen
Lopuksi voimme neuvoa sinua Service Gridissä vikasietoisten ja korkean käytettävyyden järjestelmien rakentamisessa. Kutsumme sinut myös käymään osoitteessa и jaa kokemuksesi. Kokemuksesi on todella tärkeä yhteisölle, se auttaa ymmärtämään, minne seuraavaksi siirryt, miten komponenttia kehitetään tulevaisuudessa.
Lähde: will.com