Missiomme Jitterbitillä on yksinkertaistaa monimutkaisimmatkin yhteyshaasteet ja antaa kenelle tahansa olla yhteydessä nykypäivän digitaalisessa maailmassa. Vaikka painotammekin, että sinun ei tarvitse olla kehittäjä käyttääksesi Jitterbitin tuotteita – jokaisen upean ohjelmistoratkaisun takana on joukko loistavia kehittäjiä. Jitterbit Tech Talkissa blog sarjassa Jitterbit-kehitystiimin jäsenet antavat meille tietoa yritysluokan pilvialustan rakentamisesta ja haasteista, jotka heidän oli ratkaistava usean vuokrauksen, skaalautuvuuden ja turvallisuuden alalla.
Tällä viikolla Pankaj Arora, vanhempi teknologiajohtajamme, tarkastelee, kuinka suunnittelet ja rakennat erittäin skaalautuvan yritysluokan pilvialustan.
Pilvi tarjoaa yrityksille tehokkaan tavan tarjota tuotteitaan ja palvelujaan, joita on helppo käyttää mistä tahansa ja millä tahansa laitteella. Se tarjoaa myös valtavia etuja toimittajalle, mukaan lukien näkyvyyden tarjontansa käyttöön, nopean kehityksen ja käyttöönoton sekä IT- ja ylläpitokustannusten yleiset alennukset. Tämän seurauksena melkein jokaisessa company tänään pyrkii tuomaan ratkaisunsa saataville pilvessä.
Mutta todelliseksi pilveksi tulemiseen liittyy paljon muutakin company kuin ohjelmiston asentaminen isännöidylle palvelimelle ja "pilvi" lyöminen markkinointimateriaaleihin.
Keskustelin äskettäin teknologiastrategin kanssa, ja he huomasivat, että noin 75 % yrityksistä haluaisi siirtää vanhat yritystarjouksensa pilveen. Yllättäen 90 % heistä laatii alkuperäisen suunnitelman, joka rakennettaisiin arkkitehtuurille, jossa heidän vanhat sovelluksensa otettaisiin vain käyttöön julkisesti saatavilla olevalla pilvipalvelimella. Tämä lähestymistapa kumoaa kaikki pilven tarjoamat edut.
Todellisen usean vuokralaisen pilvialustan rakentaminen edellyttää useiden erilaisten haasteiden ratkaisemista, kuten turvallisuutta, luotettavuutta, skaalautuvuutta, korkeaa käytettävyyttä, vikasietoisuutta, kirjaamista, valvontaa, ilmoitusjärjestelmää, jatkuvaa käyttöönottoa ja paljon muuta.
Tämänpäiväisessä postauksessa tarkastellaan tarkemmin, kuinka käsittelimme "skaalautuvuus"-haastetta kehittäessämme usean vuokraajan pilviintegraatioalustaa.
Sovelluksen skaalautuvuus on sidottu sen kykyyn skaalata pysty- ja vaakasuunnassa. Pilviympäristössä tämä tarkoittaa sellaisten palvelujen suunnittelua, jotka palvelevat ulkoisia pyyntöjä, jotka skaalautuvat siten, että ne voivat hyödyntää sisäisiä taustajärjestelmiä, kuten tietokantoja, välimuistia, välittäjäkerroksia, eräprosesseja (analyyttinen moottori, suositusmoottori) jne käsittelemään käytännössä loputtomia pyyntöjä kohtuullisessa ajassa. lyhyt aika. Aina ei ole mahdollista ennustaa alustallesi osuvien käyttäjien määrää. Suunnittelemalla arkkitehtuurin, joka ottaa tämän huomioon monivuokrausmallissa, tämä epävarmuus tekee yleisen skaalautuvuusongelman.
Pystysuuntainen skaalaus
Pystysuuntainen skaalautuvuus sisältää resurssien, kuten lisäsuorittimien tai muistin, lisäämisen järjestelmän yhteen solmuun, ja tämän pitäisi olla ensimmäinen asia, joka sinun tulee ajatella palveluitasi skaalattaessa. On erittäin tärkeää suunnitella sovelluksesi niin, että ne hyödyntävät näitä resursseja optimaalisesti. Otetaan yleinen hybridi-integraatiopilvialustamme käyttötapaus, jossa integraatiotoimintoja palvelee paikalla tai pilvipalvelinsolmu. Täällä palveluiden tulee ottaa pyyntö suorittaa integraatiot, välittää pyyntö palvelinsolmuille ja jatkaa lisäpyyntöjen palvelemista. Palvelukerroksen ei pitäisi olla riippuvainen järjestelmän eri kerroksissa tapahtuvista prosesseista tai estää ne. Sellaisenaan on erittäin tärkeää, että sinulla on asynkroninen, tapahtumalähtöinen arkkitehtuuri.
Yksinkertainen tapa ymmärtää asynkronista arkkitehtuuria on ajatella arkkitehtuuriasi ravintolana. Tarjoilija ottaa tilauksia pöydästä ja välittää ne kokille. Kun kokki, ruokajuoksu ja bussipoika hoitavat muun muassa ruoanlaiton, tarjoilun ja siivouksen, tarjoilija jatkaa uusien asiakkaiden palvelemista ja suorittaa tarkastukset palvelun päätteeksi.
Asynkronisuuden säilyttäminen järjestelmän toimiessa kaikkien komponenttien, kuten tietokannan, välimuistin ja välittäjäkerroksen kanssa, on erittäin tärkeää. Kuorman siirtäminen klusteroituihin, erittäin käytettävissä oleviin palvelinsolmuihin, jotka suorittavat integraatioita, vapauttaa palvelukerrokselle resursseja ottaa vastaan enemmän pyyntöjä ja vastata prosessien valmistuttua.
Vaakasuora skaalaus
Seuraava tärkeä seikka tulisi olla, että palvelut on kirjoitettu siten, että sillä ei pitäisi olla väliä kuinka monta kyseisten palveluiden esiintymää on käynnissä ja mikä jaettu järjestelmä suorittaa tapahtumia kulloinkin. Tämä antaa pilvialustallemme joustavuutta palvelukerroksen automaattiseen skaalaukseen. Jokainen taustajärjestelmän osa on erittäin saatavilla ja automaattisesti skaalautuva pysyäkseen kasvavien palvelusäiliöiden kysynnän tasalla.
Meillä ei kuitenkaan voi olla loputtomia säilöjä, jotka käyttävät palvelukerroksia, jotka käyttävät jaettuja komponentteja. Se ei ole optimaalinen muotoilu. Palataan ravintolaesimerkkiimme. Pystyskaalauksella yhdestä ravintolasta voisi tulla erittäin skaalautuva lisäämällä henkilökuntaa, mutta jossain vaiheessa resurssien määrä (kokit, juoksijat, bussipojat) saavuttaa kyllästymispisteen. Skaalautuakseen edelleen tämän yrityksen olisi avattava lisää toimipisteitä, jotka auttaisivat jakamaan asiakkaita ja tasapainottamaan kuormitusta.
On parempi jakaa koko alusta useisiin vyöhykkeisiin, jolloin jokainen vyöhyke toimii alkuperäisen vyöhykkeen kopiona. Tämä antaa meille mahdollisuuden käyttää useita vyöhykkeitä kuormituksen tasapainottamiseen tulevissa tarpeissa.
Tällä mallilla on useita etuja:
1. Mahdollinen ääretön vaakasuora skaalaus, koska voimme tuoda sisään minkä tahansa määrän vyöhykkeitä
2. Vikasietokyky, jos koko vyöhyke epäonnistuu luonnonkatastrofin vuoksi
3. Tietojen erottelu SaaS-alustassa, joka edellyttää jopa sijaintiin perustuvaa metatietojen erottelua, kuten USA:n, EMEA-alueen jne.
Haluttu lopputulos on, että käyttäjäkokemuksen tulee olla sama riippumatta siitä, missä he ovat ja mihin vyöhykkeeseen hän osuu. Käyttäjältä ei pitäisi tarvita manuaalista puuttumista työn suorittamiseen.
Meidän hybridi-integraatiopilvi blog, keskustelimme siitä, kuinka kohtasimme haasteen käyttää välittäjäkerrosta tavalla, joka tuki rajoitettua vertikaalista mittakaavaa. Kirjoittamalla oman räätälöidyn estottoman yhteyskerroksen, joka perustuu suojattuun HTTPS-siirtoon, pystyimme laajentamaan arkkitehtuuria 50-kertaiseksi pystysuunnassa. Tietysti se on myös vaakasuoraan skaalautuva. Tämä pysty- ja vaakaskaalauksen yhdistelmä antoi meille halvemman ja helposti laajennettavan kerroksen vastaamaan kasvaviin tarpeisiimme.
Jaettujen komponenttien käytön optimointi:
Jaettujen komponenttien tulee itsessään olla skaalautuvia ja erittäin saatavilla tukeakseen Cloud-alustaa. Mutta jaetut komponentit ovat jaettuja, ja sen seurauksena ne eivät ole yhtä skaalautuvia kuin palvelukerros. On erittäin tärkeää huolehtia joistakin komponenteista, jotka voivat olla herkkiä suurelle kuormitukselle, esimerkiksi tietokannat. Yksi malli voi olla jaettujen komponenttien käytön priorisointi ja asettaminen jonoon, kun useat samanaikaiset suuret kuormitukset voivat aiheuttaa ongelmia. Priorisointi voi vähentää kuormitusta ja vähentää virheitä kaikissa kriittisissä pyynnöissä. Takaisin ravintolaamme keittiö on yhteinen komponentti, ja vaikka tarjoilija voi ottaa ruokailijan tilauksen alkuruoasta, pääruoasta ja jälkiruoasta, keittiö priorisoi näiden tuotteiden valmistuksen ja tasapainottaa niiden kuormituksen.
Toinen tapa käsitellä kuormitusta voi olla tietojen tallentaminen välimuistiin, jotka muuttuvat harvoin estääkseen näiden osien runsaan käytön. Jos ranskalaiset ovat suosittuja ruokalistan kohteita, ravintola voi päättää "säilyttää" jatkuvan erän sen sijaan, että paistaisi niitä tilauksesta.
Komponenttien valvonta:
Lopuksi on erittäin tärkeää seurata jokaista komponenttia ja tietää sen rajoitukset. Järjestelmän pitäisi pystyä lisäämään kaistanleveyttä automaattisesti ja oikeaan aikaan, jotta järjestelmät pysyvät toiminnassa Cloud-alustan tarpeiden mukaisesti. Valvonta voi olla ulkoista tai sovelluslähtöistä, mutta molemmissa tapauksissa lopullisena tavoitteena on antaa järjestelmän skaalautua automaattisesti kuormituksen perusteella.
Seuraavassa blog postitse, puhumme seurannasta, kirjaamisesta ja muista arkkitehtuurin elementeistä.
