Gelek destpêk bi vê yekê derbas bûne: girseyên bikarhênerên nû her roj qeyd dikin, û tîmê pêşkeftinê ji bo domandina karûbarê têkoşînê dike.
Pirsgirêkek xweş e, lê li ser tevneyê agahdariya zelal a hindik heye ku meriv çawa bi baldarî serîlêdanek webê ji tunebûnê bigire heya bi sed hezaran bikarhêneran. Bi gelemperî an çareseriyên agir an jî çareseriyên kêşanê hene (û pir caran herdu jî). Ji ber vê yekê, mirov teknîkên pir klîşîkî bikar tînin da ku projeya xwe ya amatorî li tiştek bi rastî cidî mezin bikin.
Werin em hewl bidin ku agahdariyan fîlter bikin û formula bingehîn binivîsin. Em ê malpera xweya nû ya parvekirina wêneyan Graminsta gav bi gav ji 1 berbi 100 bikarhêneran mezin bikin.
Werin em binivîsin ku gava temaşevan bigihîje 10, 100, 1000, 10 û 000 kesan, divê çi kiryarên taybetî bêne kirin.
1 bikarhêner: 1 makîne
Hema hema her serîlêdan, malperek an serîlêdana mobîl be, sê hêmanên sereke hene:
- API
- database
- xerîdar (serîlêdana mobîl bixwe an malper)
Database daneyên domdar hilîne. API ji van daneyan û li dora wan daxwaziyan dike. Xerîdar daneyan ji bikarhênerê re dişîne.
Ez gihîştim vê encamê ku heke, ji hêla mîmarî ve, xerîdar û saziyên API-ê bi tevahî ji hev veqetin, meriv li ser pîvandina serîlêdanê biaxive pir hêsantir e.
Gava ku em yekem car dest bi avakirina serîlêdanek dikin, her sê beş dikarin li ser heman serverê werin xebitandin. Bi hin awayan, ev dişibihe jîngeha pêşkeftina me ye: yek endezyar databas, API, û xerîdar li ser heman makîneyê dimeşîne.
Di teorîyê de, em dikarin wê di ewr de li ser yek Dropletek DigitalOcean an AWS EC2 bicîh bikin, wekî ku li jêr tê nîşandan:
Digel vê yekê, heke dê ji yek bikarhênerek zêdetir li ser malperek hebe, hema hema her gav watedar e ku meriv qatek databasê veqetîne.
10 bikarhêner: databasê berbi astek cûda veguhezînin
Parçekirina databasê li ser karûbarên rêvekirî yên mîna Amazon RDS an Database Rêvebir a Okyanûsa Dîjîtal dê ji bo demek dirêj ji me re baş xizmet bike. Ew ji xwe-mêvandariya li ser yek makîneyek an mînakek EC2 piçekî bihatir e, lê bi van karûbaran hûn gelek pêvekên bikêr ji qutiyê distînin ku dê di pêşerojê de bikêrhatî bibin: paşvekişandina pir-herêmê, kopiyên xwendinê, otomatîk hilanînê, û bêtir.
Ev sîstem niha dişibe:
100 bikarhêner: xerîdar berbi astek cihêreng veguhezînin
Xwezî, bikarhênerên me yên yekem bi rastî ji serlêdana me hez kirin. Trafîk her ku diçe aramtir dibe, ji ber vê yekê dem e ku meriv xerîdar berbi astek cihêreng veguhezîne. Divê bê zanîn ku veqetandinî sazûmanan aliyek bingehîn a avakirina serîlêdanek berbelav e. Ji ber ku yek perçeyek pergalê bêtir seyrûseferê distîne, em dikarin wê dabeş bikin da ku kontrol bikin ka karûbarê li gorî şêwazên seyrûsefera taybetî çawa pîvan dibe.
Ji ber vê yekê ez dixwazim ku xerîdar ji API-yê veqetandî bifikirim. Ev yek pir hêsan dike ku meriv li ser pêşvebirina ji bo gelek platforman bifikire: tevn, tevna mobîl, iOS, Android, serîlêdanên sermaseyê, karûbarên sêyemîn, hwd. Ew hemî tenê xerîdar in ku heman API-yê bikar tînin.
Mînakî, naha bikarhênerên me pir caran daxwaz dikin ku serîlêdanek mobîl derxînin. Ger hûn xerîdar û saziyên API-ê ji hev veqetînin, ev hêsantir dibe.
Pergalek weha xuya dike ev e:
1000 bikarhêner: balansa barkirinê zêde bikin
Tişt têne dîtin. Bikarhênerên Graminsta bêtir û bêtir wêneyan bar dikin. Hejmara qeydan jî zêde dibe. Pêşkêşkara meya API-ê ya yekane ji bo domandina hemî seyrûseferê demek dijwar e. Zêdetir hesin hewce ne!
Balansa barkirinê têgehek pir bi hêz e. Fikra bingehîn ev e ku em balansek barkirinê li ber API-yê datînin, û ew seyrûseferê li ser mînakên karûbarê kesane belav dike. Bi vî rengî em horîzontal pîvandinê dikin, tê vê wateyê ku em bi heman kodê bêtir pêşkêşkeran lê zêde dikin, hejmara daxwazên ku em dikarin pêvajoyê zêde bikin.
Em ê balansên barkirinê yên cihêreng li ber xerîdar û li ber API-yê bi cîh bikin. Ev tê vê wateyê ku hûn dikarin gelek mînakên ku koda API û koda xerîdar a malperê dimeşînin bimeşînin. Balansa barkirinê dê daxwaznameyên pêşkêşkara ku kêmtir barkirî ye rasterast bike.
Li vir em avantajek din a girîng digirin - zêdebûn. Gava ku mînakek têk diçe (dibe ku zêde were barkirin an têkçû), em bi yên din re dimînin ku berdewam dikin ku bersivê bidin daxwazên hatin. Ger tenê yek mînakek bixebite, wê hingê di rewşek têkçûyî de dê tevahiya pergalê têk biçe.
Balansa barkirinê jî pîvandina otomatîkî peyda dike. Em dikarin wê mîheng bikin da ku berî barkirina lûtkeyê hejmara bûyeran zêde bike, û dema ku hemî bikarhêner di xew de ne, wê kêm bikin.
Bi balansek barkirinê re, asta API-ê hema hema bêdawî dikare were pîvandin, her ku hejmara daxwazan zêde dibe, tenê mînakên nû lê zêde bike.
Not. Naha pergala me pir dişibihe ya ku pargîdaniyên PaaS yên mîna Heroku an Elastic Beanstalk li ser AWS ji qutiyê pêşkêşî dikin (ji ber vê yekê ew ew qas populer in). Heroku databasê datîne ser mêvandarek veqetandî, balansek barkirinê ya xweser-pîvazkirî rêve dibe, û dihêle hûn xerîdarê malperê ji API-yê cuda mêvandar bikin. Ev sedemek girîng e ku hûn Heroku ji bo projeyên qonaxa destpêkê an destpêkek bikar bînin - hûn hemî karûbarên bingehîn ji qutiyê digirin.
10 bikarhêner: CDN
Belkî diviyabû me ji destpêkê ve ev yek bikira. Pêvajoya daxwazan û pejirandina wêneyên nû dest pê dike ku pir zor li ser serverên me dixe.
Di vê qonaxê de, hûn hewce ne ku karûbarek ewr bikar bînin ji bo hilanîna naveroka statîk - wêne, vîdyoy û hêj bêtir (AWS S3 an Cihên Okyanûsa Dîjîtal). Bi gelemperî, API-ya me divê ji tiştên wekî xizmetkirina wêneyan û barkirina wêneyan li serverê dûr bixe.
Feydeyek din a mêvandariya ewr CDN e (AWS vê pêvekê gazî Cloudfront dike, lê gelek pêşkêşkerên hilanîna ewr wê ji qutiyê pêşkêş dikin). CDN bixweber wêneyên me li navendên daneyên cihêreng ên li çaraliyê cîhanê vedişêre.
Her çend dibe ku navenda daneya meya sereke li Ohio be jî, heke kesek wêneyek ji Japonya bixwaze, peydakarê ewr dê kopiyek çêbike û li navenda daneya xweya Japonî hilîne. Kesê din ê ku li Japonyayê vê wêneyê bixwaze dê pir zûtir wergire. Ev girîng e dema ku em bi pelên mezin re dixebitin, mîna wêne an vîdyoyan, ku ji bo dakêşandin û veguhestina li seranserê gerstêrkê demek dirêj digire.
100 bikarhêner: pîvandina qata daneyê
CDN gelek alîkarî kir: seyrûsefer bi tevahî leza mezin dibe. Bloggerê vîdyoyê yê navdar Mavid Mobrick tenê bi me re qeyd kir û "çîroka" xwe, wekî ku ew dibêjin, şandin. Bi saya balansa barkirinê, karanîna CPU û bîranînê li ser pêşkêşkerên API-yê kêm tê girtin (deh mînakên API-yê dixebitin), lê em dest pê dikin ku li ser daxwazan gelek dereng distînin... ev dereng ji ku têne?
Piçek li metrîkan dikolin, em dibînin ku CPU li ser servera databasê% 80-90 barkirî ye. Em li ser sînor in.
Scaling layer data belkî beşa herî dijwar a hevkêşeyê ye. Pêşkêşkerên API ji daxwazên bêdewlet re xizmetê dikin, ji ber vê yekê em tenê mînakên API-ê zêde dikin. Poz piraniya databases nikarin vê yekê bikin. Em ê li ser pergalên rêveberiya databasa pêwendiya populer (PostgreSQL, MySQL, hwd.) biaxivin.
Caching
Yek ji awayên herî hêsan ji bo zêdekirina performansa databasa me danasîna pêkhateyek nû ye: qata cache. Rêbaza cachkirinê ya herî gelemperî firoşgehek tomar-nirxa key-hişê ye, wek Redis an Memcached. Pir ewran xwedan guhertoyek rêveberî ya van karûbaran in: Elasticache li AWS û Memorystore li Google Cloud.
Dema ku karûbar gelek bangên dubare li databasê dike da ku heman agahdarî bistîne, cache bikêr e. Di bingeh de, em tenê carekê xwe digihînin databasê, agahdariya di cache de hilînin, û careke din dest nedin wê.
Mînakî, di karûbarê meya Graminsta de, her gava ku kesek diçe rûpela profîlê ya stêrka Mobrik, servera API ji databasê ji bo agahdariya ji profîla xwe dipirse. Ev dîsa û dîsa dibe. Ji ber ku agahdariya profîla Mobrik bi her daxwazê re nayê guheztin, ew ji bo cachkirinê hêja ye.
Em ê encaman ji databasa li Redis bi mifteyê veşêrin user:id bi demeke derbasdar 30 seconds. Naha, gava ku kesek diçe profîla Mobrik, em pêşî Redis kontrol dikin, û heke dane li wir bin, em bi tenê rasterast ji Redis vediguhezînin. Naha daxwazên profîla herî populer a li ser malperê bi pratîkî databasa me bar nakin.
Feydeyek din a piraniya karûbarên caching ev e ku ew ji pêşkêşkerên databasê hêsantir têne pîvandin. Redis xwedan moda Redis Cluster-ya çêkirî ye. Dişibin balansek barkirinê, ew dihêle hûn cache Redis-a xwe li ser gelek makîneyan belav bikin (heke hewce bike li nav hezaran serveran).
Hema hema hemî serîlêdanên mezin caching bikar tînin; ew perçeyek bêkêmasî ya API-ya bilez e. Pêvajoya lêpirsînê ya bilez û koda hilberdartir hemî girîng in, lê bêyî cache hema hema ne gengaz e ku meriv karûbarek bi mîlyonan bikarhêneran re pîvan bike.
Replicas bixwînin
Gava ku hejmara lêpirsînên li databasê pir zêde bû, tiştek din ku em dikarin bikin ev e ku em kopiyên xwendinê di pergala rêveberiya databasê de zêde bikin. Bi karûbarên birêvebir ên ku li jor hatine destnîşan kirin, ev dikare bi yek klîk were kirin. Replika xwendinê dê di databasa bingehîn de heyî bimîne û ji bo daxuyaniyên SELECT heye.
Niha pergala me li vir e:
Dersên din
Ji ber ku serîlêdan pîvandinê berdewam dike, em ê berdewam bikin ku karûbaran ji hev veqetînin da ku wan serbixwe binirxînin. Mînakî, heke em dest bi karanîna Websockets-ê bikin, wê hingê maqûl e ku em koda pêvajoyê ya Websockets bikişînin nav karûbarek cihê. Em dikarin wê li ser mînakên nû li pişt balansa barkirinê ya xweya xwe bi cîh bikin, ku dikare li ser bingeha girêdanên Websockets vekirî û bêyî ku ji hejmara daxwazên HTTP-ê bigire berz û jêr veke.
Em ê di asta databasê de jî têkoşîna qedexeyan bidomînin. Di vê qonaxê de ye ku ew dem e ku meriv dabeşkirin û parvekirina databasê lêkolîn bike. Her du nêzîkatî pêdiviya zêde zêde hewce dike, lê dihêle hûn databasê hema hema bêdawî pîvandin.
Em jî dixwazin karûbarek çavdêrî û analîtîkê mîna New Relic an Datadog saz bikin. Ev ê ji we re bibe alîkar ku hûn pirsên hêdî nas bikin û fêm bikin ka li ku derê çêtirkirin hewce ye. Gava ku em pîvan dikin, em dixwazin bala xwe bidin ser dîtina kêşan û rakirina wan - pir caran hin ramanên ji beşên berê bikar tînin.
Çavkaniyên
Ev post bi îlhama yek ji . Min xwest ku gotarê ji bo qonaxên destpêkê yên projeyan hinekî taybetîtir bikim û wê ji yek firoşkarê vekim. Ger hûn bi vê mijarê re eleqedar in, bi rastî bixwînin.
Jêrnivîs
- Her çend di warê belavkirina barkirinê de li ser gelek mînakan wekhev be jî, pêkanîna bingehîn a komika Redis ji balansek barkirinê pir cûda ye.
Source: www.habr.com