Waanzishaji wengi wamepitia hili: umati wa watumiaji wapya hujiandikisha kila siku, na timu ya maendeleo inatatizika kuweka huduma ikiendelea.

Ni shida nzuri kuwa nayo, lakini kuna habari kidogo wazi kwenye wavuti kuhusu jinsi ya kuongeza kwa uangalifu programu ya wavuti kutoka kwa chochote hadi mamia ya maelfu ya watumiaji. Kawaida kuna suluhisho la moto au suluhisho la chupa (na mara nyingi zote mbili). Kwa hivyo, watu hutumia mbinu za kubana ili kuongeza mradi wao wa amateur katika kitu kikubwa sana.

Hebu jaribu kuchuja habari na kuandika formula ya msingi. Tutaongeza tovuti yetu mpya ya kushiriki picha ya Graminsta hatua kwa hatua kutoka kwa watumiaji 1 hadi 100.

Hebu tuandike ni hatua gani mahususi zinahitajika kuchukuliwa wakati hadhira inapoongezeka hadi watu 10, 100, 1000, 10 na 000.

Mtumiaji 1: mashine 1

Takriban kila programu, iwe tovuti au programu ya simu, ina vipengele vitatu muhimu:

• API
• database
• mteja (programu ya rununu yenyewe au tovuti)

Hifadhidata huhifadhi data inayoendelea. API hutoa maombi kwa na karibu na data hii. Mteja hupeleka data kwa mtumiaji.

Nilifikia hitimisho kwamba ni rahisi zaidi kuzungumza juu ya kuongeza programu ikiwa, kutoka kwa mtazamo wa usanifu, mteja na vyombo vya API vimetenganishwa kabisa.

Tunapoanza kuunda programu, vipengele vyote vitatu vinaweza kuendeshwa kwenye seva moja. Kwa njia fulani, hii ni sawa na mazingira yetu ya maendeleo: mhandisi mmoja huendesha hifadhidata, API, na mteja kwenye mashine moja.

Kinadharia, tunaweza kuipeleka kwenye wingu kwenye mfano mmoja wa DigitalOcean Droplet au AWS EC2, kama inavyoonyeshwa hapa chini:

Kwa kusema hivyo, ikiwa kutakuwa na zaidi ya mtumiaji mmoja kwenye tovuti, karibu kila wakati inaeleweka kuweka wakfu safu ya hifadhidata.

Watumiaji 10: kuhamisha hifadhidata kwa kiwango tofauti

Kugawanya hifadhidata katika huduma zinazodhibitiwa kama vile Amazon RDS au Hifadhidata Inayodhibitiwa ya Bahari ya Dijiti kutatusaidia vyema kwa muda mrefu. Ni ghali kidogo kuliko kujipangisha mwenyewe kwenye mashine moja au mfano wa EC2, lakini kwa huduma hizi unapata viendelezi vingi muhimu kutoka kwa kisanduku ambavyo vitasaidia katika siku zijazo: nakala rudufu ya maeneo mengi, nakala za kusoma, otomatiki. chelezo, na zaidi.

Hivi ndivyo mfumo unavyoonekana sasa:

Watumiaji 100: kusogeza mteja kwa kiwango tofauti

Kwa bahati nzuri, watumiaji wetu wa kwanza walipenda sana programu yetu. Trafiki inazidi kuwa dhabiti, kwa hivyo ni wakati wa kusogeza mteja kwenye kiwango tofauti. Ikumbukwe kwamba kujitenga vyombo ni kipengele muhimu cha kujenga programu inayoweza kusambazwa. Sehemu moja ya mfumo inapopokea trafiki zaidi, tunaweza kuigawa ili kudhibiti jinsi mizani ya huduma kulingana na mifumo mahususi ya trafiki.

Hii ndio sababu napenda kufikiria mteja kama tofauti na API. Hii hurahisisha sana kufikiria kutayarisha majukwaa mengi: wavuti, wavuti ya rununu, iOS, Android, programu za kompyuta ya mezani, huduma za wahusika wengine, n.k. Wote ni wateja wanaotumia API sawa.

Kwa mfano, sasa watumiaji wetu mara nyingi huuliza kutoa programu ya rununu. Ukitenganisha mteja na vyombo vya API, hii inakuwa rahisi.

Hivi ndivyo mfumo kama huu unavyoonekana:

Watumiaji 1000: ongeza mizani ya mzigo

Mambo yanaelekea. Watumiaji wa Graminsta wanapakia picha zaidi na zaidi. Idadi ya usajili pia inaongezeka. Seva yetu pekee ya API ina wakati mgumu kufuata msongamano wote. Unahitaji chuma zaidi!

Mizani ya mzigo ni dhana yenye nguvu sana. Wazo kuu ni kwamba tunaweka kibawazishaji cha mzigo mbele ya API, na inasambaza trafiki kwa matukio ya huduma binafsi. Hivi ndivyo tunavyoweka ukubwa wa mlalo, kumaanisha kuwa tunaongeza seva zaidi na msimbo sawa, na kuongeza idadi ya maombi tunayoweza kushughulikia.

Tutaweka viambatanisho tofauti vya mizigo mbele ya mteja wa wavuti na mbele ya API. Hii inamaanisha kuwa unaweza kuendesha matukio mengi kwa kutumia msimbo wa API na msimbo wa mteja wa wavuti. Kisawazisha cha mzigo kitaelekeza maombi kwa seva ambayo haijapakiwa kidogo.

Hapa tunapata faida nyingine muhimu - redundancy. Tukio moja linaposhindikana (labda likiwa limejazwa au kuharibika), tunasalia na mengine ambayo yanaendelea kujibu maombi yanayoingia. Ikiwa kulikuwa na mfano mmoja tu unaofanya kazi, basi katika kesi ya kushindwa mfumo mzima ungeanguka.

Mizani ya mzigo pia hutoa kuongeza moja kwa moja. Tunaweza kuisanidi ili kuongeza idadi ya matukio kabla ya kilele cha upakiaji, na kuipunguza wakati watumiaji wote wanalala.

Kwa kusawazisha mzigo, kiwango cha API kinaweza kuongezwa karibu kwa muda usiojulikana, kwa kuongeza matukio mapya kadiri idadi ya maombi inavyoongezeka.

Kumbuka. Kwa sasa mfumo wetu unafanana sana na kampuni za PaaS kama Heroku au Elastic Beanstalk kwenye AWS hutoa nje ya boksi (ndiyo maana zinajulikana sana). Heroku huweka hifadhidata kwenye seva pangishi tofauti, hudhibiti kiweka sawa cha kupakia kiotomatiki, na hukuruhusu kupangisha mteja wa wavuti kando na API. Hii ni sababu nzuri ya kutumia Heroku kwa miradi ya hatua ya awali au inayoanzisha - unapata huduma zote za kimsingi nje ya boksi.

Watumiaji 10: CDN

Labda tulipaswa kufanya hivi tangu mwanzo. Kuchakata maombi na kukubali picha mpya kunaanza kuleta matatizo mengi kwenye seva zetu.

Katika hatua hii, unahitaji kutumia huduma ya wingu kuhifadhi yaliyomo tuli - picha, video na mengi zaidi (AWS S3 au Nafasi za Bahari ya Dijiti). Kwa ujumla, API yetu inapaswa kuepuka kushughulikia mambo kama vile kutoa picha na kupakia picha kwenye seva.

Faida nyingine ya upangishaji wa wingu ni CDN (AWS huita kiongezi hiki Cloudfront, lakini watoa huduma wengi wa hifadhi ya wingu hutoa nje ya boksi). CDN huhifadhi picha zetu kiotomatiki katika vituo mbalimbali vya data duniani kote.

Ingawa kituo chetu kikuu cha data kinaweza kuwa Ohio, mtu akiomba picha kutoka Japani, mtoa huduma wa wingu atafanya nakala na kuihifadhi katika kituo chao cha data cha Kijapani. Mtu anayefuata ambaye ataomba picha hii nchini Japani ataipokea kwa haraka zaidi. Hili ni muhimu tunapofanya kazi na faili kubwa, kama vile picha au video, ambazo huchukua muda mrefu kupakua na kusambaza duniani kote.

Watumiaji 100: kuongeza safu ya data

CDN imesaidia sana: trafiki inakua kwa kasi kamili. Mwanablogu maarufu wa video Mavid Mobrick amejiandikisha nasi na kuchapisha "hadithi" yake, kama wanasema. Shukrani kwa kusawazisha upakiaji, CPU na utumiaji wa kumbukumbu kwenye seva za API huwekwa chini (matukio kumi ya API yanaendelea), lakini tunaanza kupata muda mwingi wa kuisha kwa maombi... ucheleweshaji huu unatoka wapi?

Kuchimba kidogo kwenye metrics, tunaona kwamba CPU kwenye seva ya hifadhidata imepakiwa 80-90%. Tuko kwenye kikomo.

Kuongeza safu ya data labda ndio sehemu ngumu zaidi ya mlinganyo. Seva za API hutumikia maombi yasiyo na uraia, kwa hivyo tunaongeza matukio zaidi ya API. Pua wengi hifadhidata haziwezi kufanya hivi. Tutazungumza juu ya mifumo maarufu ya usimamizi wa hifadhidata ya uhusiano (PostgreSQL, MySQL, nk).

Kuhifadhi akiba

Mojawapo ya njia rahisi zaidi za kuongeza utendaji wa hifadhidata yetu ni kuanzisha sehemu mpya: safu ya kache. Njia ya kawaida ya kuweka akiba ni hifadhi ya kumbukumbu ya ufunguo wa thamani, kama vile Redis au Memcached. Wingu nyingi zina toleo linalodhibitiwa la huduma hizi: Elasticache kwenye AWS na Memorystore kwenye Google Cloud.

Akiba ni muhimu wakati huduma inapopiga simu mara kwa mara kwa hifadhidata ili kupata taarifa sawa. Kimsingi, tunapata hifadhidata mara moja tu, kuhifadhi habari kwenye kashe, na usiiguse tena.

Kwa mfano, katika huduma yetu ya Graminsta, kila wakati mtu anapoenda kwenye ukurasa wa wasifu wa nyota ya Mobrik, seva ya API huuliza hifadhidata kwa maelezo kutoka kwa wasifu wake. Hii hutokea tena na tena. Kwa kuwa maelezo ya wasifu wa Mobrik hayabadiliki kwa kila ombi, ni bora kwa kuakibisha.

Tutahifadhi matokeo kutoka kwa hifadhidata katika Redis kwa ufunguo user:id na muda wa uhalali wa sekunde 30. Sasa, mtu anapoenda kwenye wasifu wa Mobrik, kwanza tunaangalia Redis, na ikiwa data iko, tunaihamisha moja kwa moja kutoka kwa Redis. Sasa maombi kwa wasifu maarufu kwenye tovuti haipakii hifadhidata yetu.

Faida nyingine ya huduma nyingi za caching ni kwamba ni rahisi kupima kuliko seva za hifadhidata. Redis ina modi ya Kundi la Redis iliyojengewa ndani. Sawa na kusawazisha mzigo1, hukuruhusu kusambaza kashe yako ya Redis kwenye mashine nyingi (katika maelfu ya seva ikihitajika).

Takriban programu zote za kiwango kikubwa hutumia caching; ni sehemu muhimu kabisa ya API ya haraka. Uchakataji wa haraka wa hoja na msimbo wenye tija zaidi ni muhimu, lakini bila kache ni karibu haiwezekani kuongeza huduma kwa mamilioni ya watumiaji.

Soma nakala

Wakati idadi ya maswali kwenye hifadhidata imeongezeka sana, jambo moja zaidi tunaweza kufanya ni kuongeza nakala zilizosomwa katika mfumo wa usimamizi wa hifadhidata. Kwa huduma zilizosimamiwa zilizoelezwa hapo juu, hii inaweza kufanyika kwa mbofyo mmoja. Nakala iliyosomwa itasalia kuwa ya sasa katika hifadhidata kuu na inapatikana kwa kauli CHAGUA.

Huu hapa mfumo wetu sasa:

Vitendo zaidi

Kadiri programu inavyoendelea kupanuka, tutaendelea kutenganisha huduma ili kuziongeza kwa kujitegemea. Kwa mfano, ikiwa tutaanza kutumia Websockets, basi ni mantiki kuvuta msimbo wa usindikaji wa Websockets kwenye huduma tofauti. Tunaweza kuiweka kwenye matukio mapya nyuma ya kikisawazisha mizigo chetu, ambacho kinaweza kupanda na kushuka kulingana na miunganisho iliyofunguliwa ya Websockets na bila kujali idadi ya maombi ya HTTP.

Pia tutaendelea kupambana na vikwazo katika ngazi ya hifadhidata. Ni katika hatua hii kwamba ni wakati wa kusoma ugawaji wa hifadhidata na ugawaji. Njia zote mbili zinahitaji maelezo ya ziada, lakini hukuruhusu kuongeza hifadhidata karibu kwa muda usiojulikana.

Pia tunataka kusakinisha huduma ya ufuatiliaji na uchanganuzi kama vile New Relic au Datadog. Hii itakusaidia kutambua maswali ya polepole na kuelewa ni wapi uboreshaji unahitajika. Tunapofanya vipimo, tunataka kuzingatia kutafuta vikwazo na kuviondoa—mara nyingi kwa kutumia baadhi ya mawazo kutoka sehemu zilizopita.

Vyanzo

Chapisho hili limehamasishwa na mmoja wapo machapisho ninayopenda kuhusu uboreshaji wa hali ya juu. Nilitaka kufanya makala kuwa mahususi zaidi kwa hatua za awali za miradi na kuifungua kutoka kwa mchuuzi mmoja. Hakikisha kusoma ikiwa una nia ya mada hii.

Maelezo ya chini

1. Ingawa inafanana katika suala la usambazaji wa mzigo katika hali nyingi, utekelezaji wa msingi wa nguzo ya Redis ni tofauti sana na sawazisha mzigo. [kurudi]

Chanzo: mapenzi.com