Mae llawer o fusnesau newydd wedi mynd trwy hyn: mae torfeydd o ddefnyddwyr newydd yn cofrestru bob dydd, ac mae'r tîm datblygu'n cael trafferth i gadw'r gwasanaeth i redeg.
Mae'n broblem braf i'w chael, ond ychydig o wybodaeth glir sydd ar y we am sut i raddio cymhwysiad gwe yn ofalus o ddim i gannoedd o filoedd o ddefnyddwyr. Yn nodweddiadol, mae naill ai atebion tân neu dagfeydd (ac yn aml y ddau). Felly, mae pobl yn defnyddio technegau ystrydebol braidd i raddio eu prosiect amatur yn rhywbeth gwirioneddol ddifrifol.
Gadewch i ni geisio hidlo'r wybodaeth ac ysgrifennu'r fformiwla sylfaenol. Rydyn ni'n mynd i raddio ein gwefan rhannu lluniau newydd Graminsta gam wrth gam o 1 i 100 o ddefnyddwyr.
Gadewch i ni ysgrifennu pa gamau penodol sydd angen eu cymryd pan fydd y gynulleidfa'n cynyddu i 10, 100, 1000, 10 a 000 o bobl.
1 defnyddiwr: 1 peiriant
Mae gan bron bob cais, boed yn wefan neu raglen symudol, dair cydran allweddol:
- API
- cronfa ddata
- cleient (cymhwysiad symudol ei hun neu wefan)
Mae'r gronfa ddata yn storio data parhaus. Mae'r API yn gwasanaethu ceisiadau i ac o amgylch y data hwn. Mae'r cleient yn trosglwyddo data i'r defnyddiwr.
Deuthum i'r casgliad ei bod yn llawer haws siarad am raddio cais os, o safbwynt pensaernïol, mae'r cleient ac endidau API wedi'u gwahanu'n llwyr.
Pan ddechreuwn adeiladu cais am y tro cyntaf, gellir rhedeg y tair cydran ar yr un gweinydd. Mewn rhai ffyrdd, mae hyn yn debyg i'n hamgylchedd datblygu: mae un peiriannydd yn rhedeg y gronfa ddata, API, a chleient ar yr un peiriant.
Mewn egwyddor, gallem ei ddefnyddio yn y cwmwl ar un enghraifft DigitalOcean Droplet neu AWS EC2, fel y dangosir isod:
Wedi dweud hynny, os bydd mwy nag un defnyddiwr ar wefan, mae bron bob amser yn gwneud synnwyr i gyflwyno haen cronfa ddata.
10 defnyddiwr: symud y gronfa ddata i lefel ar wahân
Bydd rhannu'r gronfa ddata yn wasanaethau a reolir fel Amazon RDS neu Digital Ocean Managed Database yn ein gwasanaethu'n dda am amser hir. Mae ychydig yn ddrutach na hunan-gynnal ar un peiriant neu enghraifft EC2, ond gyda'r gwasanaethau hyn rydych chi'n cael llawer o estyniadau defnyddiol allan o'r bocs a fydd yn ddefnyddiol yn y dyfodol: copi wrth gefn aml-ranbarth, darllenwch replicas, awtomatig copïau wrth gefn, a mwy.
Dyma sut olwg sydd ar y system nawr:
100 o ddefnyddwyr: symud y cleient i lefel ar wahân
Yn ffodus, roedd ein defnyddwyr cyntaf yn hoff iawn o'n cais. Mae traffig yn dod yn fwy sefydlog, felly mae'n bryd symud y cleient i lefel ar wahân. Dylid nodi bod gwahanu endidau yn agwedd allweddol ar adeiladu cais graddadwy. Wrth i un rhan o'r system dderbyn mwy o draffig, gallwn ei rannu i reoli sut mae graddfeydd y gwasanaeth yn seiliedig ar batrymau traffig penodol.
Dyma pam rwy'n hoffi meddwl am y cleient fel rhywbeth ar wahân i'r API. Mae hyn yn ei gwneud hi'n hawdd iawn meddwl am ddatblygu ar gyfer llwyfannau lluosog: gwe, gwe symudol, iOS, Android, cymwysiadau bwrdd gwaith, gwasanaethau trydydd parti, ac ati Maent i gyd yn gleientiaid yn unig sy'n defnyddio'r un API.
Er enghraifft, nawr mae ein defnyddwyr yn aml yn gofyn am ryddhau cymhwysiad symudol. Os byddwch chi'n gwahanu'r cleient ac endidau API, daw hyn yn haws.
Dyma sut olwg sydd ar system o'r fath:
1000 o ddefnyddwyr: ychwanegu cydbwysedd llwyth
Mae pethau'n edrych i fyny. Mae defnyddwyr Graminsta yn uwchlwytho mwy a mwy o luniau. Mae nifer y cofrestriadau hefyd yn cynyddu. Mae ein gweinydd API unigol yn cael amser caled yn cadw i fyny â'r holl draffig. Angen mwy o haearn!
Mae cydbwysedd llwyth yn gysyniad pwerus iawn. Y syniad allweddol yw ein bod yn rhoi cydbwysedd llwyth o flaen yr API, ac mae'n dosbarthu traffig i achosion gwasanaeth unigol. Dyma sut rydym yn graddio'n llorweddol, sy'n golygu ein bod yn ychwanegu mwy o weinyddion gyda'r un cod, gan gynyddu nifer y ceisiadau y gallwn eu prosesu.
Rydyn ni'n mynd i osod balanswyr llwyth ar wahân o flaen y cleient gwe ac o flaen yr API. Mae hyn yn golygu y gallwch chi redeg sawl achos yn rhedeg cod API a chod cleient gwe. Bydd y cydbwysedd llwyth yn cyfeirio ceisiadau at y gweinydd sy'n llai llwythog.
Yma cawn fantais bwysig arall - diswyddo. Pan fydd un achos yn methu (efallai wedi'i orlwytho neu'n chwalu), rydyn ni'n cael ein gadael gydag eraill sy'n parhau i ymateb i geisiadau sy'n dod i mewn. Pe bai dim ond un enghraifft yn gweithio, yna rhag ofn y byddai'r system gyfan yn methu.
Mae'r cydbwysedd llwyth hefyd yn darparu graddio awtomatig. Gallwn ei ffurfweddu i gynyddu nifer yr achosion cyn y llwyth brig, a'i leihau pan fydd pob defnyddiwr yn cysgu.
Gyda chydbwysedd llwyth, gellir graddio lefel yr API bron am gyfnod amhenodol, gan ychwanegu enghreifftiau newydd wrth i nifer y ceisiadau gynyddu.
Nodyn. Ar hyn o bryd mae ein system yn debyg iawn i'r hyn y mae cwmnïau PaaS fel Heroku neu Elastic Beanstalk ar AWS yn ei gynnig allan o'r bocs (a dyna pam maen nhw mor boblogaidd). Mae Heroku yn rhoi'r gronfa ddata ar westeiwr ar wahân, yn rheoli cydbwysedd llwyth sy'n graddio'n awtomatig, ac yn caniatáu ichi gynnal y cleient gwe ar wahân i'r API. Mae hwn yn reswm gwych i ddefnyddio Heroku ar gyfer prosiectau cyfnod cynnar neu fusnesau newydd - rydych chi'n cael yr holl wasanaethau sylfaenol allan o'r bocs.
10 o ddefnyddwyr: CDN
Efallai y dylem fod wedi gwneud hyn o’r cychwyn cyntaf. Mae prosesu ceisiadau a derbyn lluniau newydd yn dechrau rhoi gormod o straen ar ein gweinyddion.
Ar y cam hwn, mae angen i chi ddefnyddio gwasanaeth cwmwl ar gyfer storio cynnwys statig - delweddau, fideos a llawer mwy (AWS S3 neu Digital Ocean Spaces). Yn gyffredinol, dylai ein API osgoi trin pethau fel gweini delweddau a llwytho delweddau i'r gweinydd.
Mantais arall cynnal cwmwl yw'r CDN (mae AWS yn galw'r ychwanegyn hwn Cloudfront, ond mae llawer o ddarparwyr storio cwmwl yn ei gynnig allan o'r bocs). Mae'r CDN yn storio ein delweddau yn awtomatig mewn canolfannau data amrywiol ledled y byd.
Er y gall ein prif ganolfan ddata fod wedi'i lleoli yn Ohio, os bydd rhywun yn gofyn am ddelwedd o Japan, bydd darparwr y cwmwl yn gwneud copi ac yn ei storio yn eu canolfan ddata Japaneaidd. Bydd y person nesaf sy'n gofyn am y ddelwedd hon yn Japan yn ei derbyn yn gynt o lawer. Mae hyn yn bwysig pan fyddwn yn gweithio gyda ffeiliau mawr, fel lluniau neu fideos, sy'n cymryd amser hir i'w lawrlwytho a'u trosglwyddo ar draws y blaned.
100 o ddefnyddwyr: graddio'r haen ddata
Mae CDN wedi helpu llawer: mae traffig yn tyfu ar gyflymder llawn. Mae’r blogiwr fideo enwog Mavid Mobrick newydd gofrestru gyda ni a phostio ei “stori”, fel maen nhw’n dweud. Diolch i'r cydbwysedd llwyth, mae'r defnydd CPU a chof ar y gweinyddion API yn cael ei gadw'n isel (deg achos API yn rhedeg), ond rydym yn dechrau cael llawer o amser i ffwrdd ar geisiadau ... o ble mae'r oedi hwn yn dod?
Gan gloddio ychydig i'r metrigau, gwelwn fod y CPU ar y gweinydd cronfa ddata wedi'i lwytho 80-90%. Rydyn ni ar y terfyn.
Mae'n debyg mai graddio'r haen ddata yw'r rhan anoddaf o'r hafaliad. Mae gweinyddwyr API yn gwasanaethu ceisiadau heb wladwriaeth, felly rydym yn syml yn ychwanegu mwy o enghreifftiau API. Trwyn y mwyafrif ni all cronfeydd data wneud hyn. Byddwn yn siarad am systemau rheoli cronfa ddata perthynol poblogaidd (PostgreSQL, MySQL, ac ati).
caching
Un o'r ffyrdd hawsaf o gynyddu perfformiad ein cronfa ddata yw cyflwyno cydran newydd: haen y storfa. Y dull caching mwyaf cyffredin yw storfa gofnodion gwerth bysell mewn cof, fel Redis neu Memcached. Mae gan y rhan fwyaf o gymylau fersiwn wedi'i rheoli o'r gwasanaethau hyn: Elasticache ar AWS a Memorystore ar Google Cloud.
Mae storfa yn ddefnyddiol pan fydd gwasanaeth yn gwneud llawer o alwadau dro ar ôl tro i'r gronfa ddata i adalw'r un wybodaeth. Yn y bôn, dim ond unwaith rydyn ni'n cyrchu'r gronfa ddata, yn storio'r wybodaeth yn y storfa, ac nid ydym yn ei chyffwrdd eto.
Er enghraifft, yn ein gwasanaeth Graminsta, bob tro y bydd rhywun yn mynd i dudalen broffil y seren Mobrik, mae'r gweinydd API yn holi'r gronfa ddata am wybodaeth o'i broffil. Mae hyn yn digwydd dro ar ôl tro. Gan nad yw gwybodaeth proffil Mobrik yn newid gyda phob cais, mae'n wych ar gyfer caching.
Byddwn yn cadw'r canlyniadau o'r gronfa ddata yn Redis yn ôl allwedd user:id gyda chyfnod dilysrwydd o 30 eiliad. Nawr, pan fydd rhywun yn mynd i broffil Mobrik, rydyn ni'n gwirio Redis yn gyntaf, ac os yw'r data yno, rydyn ni'n ei drosglwyddo'n uniongyrchol o Redis. Nawr nid yw ceisiadau i'r proffil mwyaf poblogaidd ar y wefan bron yn llwytho ein cronfa ddata.
Mantais arall y rhan fwyaf o wasanaethau caching yw eu bod yn haws eu graddio na gweinyddwyr cronfa ddata. Mae gan Redis modd Clwstwr Redis adeiledig. Yn debyg i gydbwysedd llwyth, mae'n caniatáu ichi ddosbarthu'ch storfa Redis ar draws peiriannau lluosog (ar draws miloedd o weinyddion os oes angen).
Mae bron pob cais ar raddfa fawr yn defnyddio caching; mae'n rhan gwbl annatod o API cyflym. Mae prosesu ymholiadau cyflymach a chod mwy cynhyrchiol i gyd yn bwysig, ond heb storfa mae bron yn amhosibl graddio gwasanaeth i filiynau o ddefnyddwyr.
Darllen Replicas
Pan fydd nifer yr ymholiadau i'r gronfa ddata wedi cynyddu'n fawr, un peth arall y gallwn ei wneud yw ychwanegu atgynyrchiadau darllen yn y system rheoli cronfa ddata. Gyda'r gwasanaethau a reolir a ddisgrifir uchod, gellir gwneud hyn mewn un clic. Bydd y copi darllen yn parhau'n gyfredol yn y brif gronfa ddata ac mae ar gael ar gyfer datganiadau SELECT.
Dyma ein system nawr:
Camau gweithredu pellach
Wrth i'r cais barhau i raddfa, byddwn yn parhau i wahanu'r gwasanaethau i'w graddio'n annibynnol. Er enghraifft, os byddwn yn dechrau defnyddio Websockets, yna mae'n gwneud synnwyr i dynnu'r cod prosesu Websockets i mewn i wasanaeth ar wahân. Gallwn ei osod ar achosion newydd y tu ôl i'n cydbwysydd llwyth ein hunain, a all gynyddu ac i lawr yn seiliedig ar gysylltiadau Websockets agored a waeth faint o geisiadau HTTP a wneir.
Byddwn hefyd yn parhau i frwydro yn erbyn cyfyngiadau ar lefel y gronfa ddata. Ar hyn o bryd mae'n bryd astudio rhannu a rhannu cronfeydd data. Mae angen gorbenion ychwanegol ar y ddau ddull, ond maent yn caniatáu ichi raddio'r gronfa ddata bron am gyfnod amhenodol.
Rydym hefyd am osod gwasanaeth monitro a dadansoddi fel New Relic neu Datadog. Bydd hyn yn eich helpu i nodi ymholiadau araf a deall lle mae angen gwelliant. Wrth i ni ehangu, rydym am ganolbwyntio ar ddod o hyd i dagfeydd a'u dileu - yn aml gan ddefnyddio rhai o'r syniadau o adrannau blaenorol.
Ffynonellau
Mae'r swydd hon wedi'i hysbrydoli gan un o . Roeddwn i eisiau gwneud yr erthygl ychydig yn fwy penodol ar gyfer camau cychwynnol prosiectau a'i ddatglymu gan un gwerthwr. Byddwch yn siwr i ddarllen os oes gennych ddiddordeb yn y pwnc hwn.
Troednodiadau
- Er ei fod yn debyg o ran dosbarthiad llwyth ar draws sawl achos, mae gweithrediad gwaelodol clwstwr Redis yn wahanol iawn i gydbwysydd llwyth.
Ffynhonnell: hab.com