Helo, fy enw i yw Evgeniy. Rwy'n gweithio yn seilwaith chwilio Yandex.Market. Rwyf am ddweud wrth gymuned Habr am gegin fewnol y Farchnad - ac mae gennyf lawer i'w ddweud. Yn gyntaf oll, sut mae chwiliad y Farchnad yn gweithio, prosesau a phensaernïaeth. Sut ydyn ni'n delio â sefyllfaoedd brys: beth sy'n digwydd os bydd un gweinydd yn mynd i lawr? Beth os oes 100 o weinyddion o'r fath?
Byddwch hefyd yn dysgu sut rydym yn gweithredu swyddogaethau newydd ar griw o weinyddion ar unwaith. A sut rydym yn profi gwasanaethau cymhleth yn uniongyrchol wrth gynhyrchu, heb achosi unrhyw anghyfleustra i ddefnyddwyr. Yn gyffredinol, sut mae chwiliad y Farchnad yn gweithio fel bod pawb yn cael amser da.
Ychydig amdanom ni: pa broblem rydyn ni'n ei datrys
Pan fyddwch chi'n mewnbynnu testun, yn chwilio am gynnyrch yn ôl paramedrau, neu'n cymharu prisiau mewn gwahanol siopau, anfonir pob cais at y gwasanaeth chwilio. Chwilio yw'r gwasanaeth mwyaf yn y Farchnad.
Rydym yn prosesu pob cais chwilio: o'r safleoedd market.yandex.ru, beru.ru, y gwasanaeth Supercheck, Yandex.Advisor, cymwysiadau symudol. Rydym hefyd yn cynnwys cynigion cynnyrch mewn canlyniadau chwilio ar yandex.ru.
Wrth wasanaeth chwilio rwy'n golygu nid yn unig y chwiliad ei hun, ond hefyd cronfa ddata gyda'r holl gynigion ar y Farchnad. Y raddfa yw hyn: mae mwy na biliwn o geisiadau chwilio yn cael eu prosesu bob dydd. A dylai popeth weithio'n gyflym, heb ymyrraeth a chynhyrchu'r canlyniad a ddymunir bob amser.
Beth yw beth: Pensaernïaeth y farchnad
Disgrifiaf yn fyr bensaernïaeth gyfredol y Farchnad. Gellir ei ddisgrifio'n fras gan y diagram isod:
Gadewch i ni ddweud bod siop bartner yn dod atom ni. Mae'n dweud fy mod i eisiau gwerthu tegan: y gath ddrwg hon gyda gwichian. A chath ddig arall heb squeaker. A dim ond cath. Yna mae angen i'r siop baratoi cynigion y mae'r Farchnad yn chwilio amdanynt. Mae'r siop yn cynhyrchu xml arbennig gyda chynigion ac yn cyfathrebu'r llwybr i'r xml hwn trwy'r rhyngwyneb cyswllt. Yna mae'r mynegeiwr yn lawrlwytho'r xml hwn o bryd i'w gilydd, yn gwirio am wallau ac yn arbed yr holl wybodaeth i gronfa ddata enfawr.
Mae yna lawer o xmls o'r fath wedi'u cadw. Mae mynegai chwilio yn cael ei greu o'r gronfa ddata hon. Mae'r mynegai yn cael ei storio mewn fformat mewnol. Ar ôl creu'r mynegai, mae'r gwasanaeth Layout yn ei uwchlwytho i weinyddion chwilio.
O ganlyniad, mae cath flin gyda gwichiwr yn ymddangos yn y gronfa ddata, ac mae mynegai'r gath yn ymddangos ar y gweinydd.
Fe ddywedaf wrthych sut rydyn ni'n chwilio am gath yn y rhan am bensaernïaeth chwilio.
Pensaernïaeth chwilio'r farchnad
Rydym yn byw mewn byd o ficrowasanaethau: pob cais sy'n dod i mewn yn achosi llawer o subqueries, ac mae dwsinau o wasanaethau yn ymwneud â'u prosesu. Mae’r diagram yn dangos ychydig yn unig:
Cynllun prosesu ceisiadau symlach
Mae gan bob gwasanaeth beth gwych - ei gydbwysedd ei hun gydag enw unigryw:
Mae'r balancer yn rhoi mwy o hyblygrwydd i ni wrth reoli'r gwasanaeth: gallwch, er enghraifft, ddiffodd gweinyddwyr, sy'n aml yn ofynnol ar gyfer diweddariadau. Mae'r balancer yn gweld nad yw'r gweinydd ar gael ac mae'n ailgyfeirio ceisiadau yn awtomatig i weinyddion neu ganolfannau data eraill. Wrth ychwanegu neu dynnu gweinydd, mae'r llwyth yn cael ei ailddosbarthu'n awtomatig rhwng y gweinyddwyr.
Nid yw enw unigryw'r balans yn dibynnu ar y ganolfan ddata. Pan fydd gwasanaeth A yn gwneud cais i B, yna yn ddiofyn mae cydbwyseddwr B yn ailgyfeirio'r cais i'r ganolfan ddata gyfredol. Os nad yw'r gwasanaeth ar gael neu os nad yw'n bodoli yn y ganolfan ddata gyfredol, yna caiff y cais ei ailgyfeirio i ganolfannau data eraill.
Mae FQDN sengl ar gyfer pob canolfan ddata yn caniatáu i wasanaeth A dynnu'n llwyr o leoliadau. Bydd ei gais i wasanaeth B bob amser yn cael ei brosesu. Yr eithriad yw'r achos pan fydd y gwasanaeth wedi'i leoli ym mhob canolfan ddata.
Ond nid yw popeth mor rosy â'r cydbwysedd hwn: mae gennym ni gydran ganolradd ychwanegol. Gall y balancer fod yn ansefydlog, a chaiff y broblem hon ei datrys gan weinyddion segur. Mae oedi ychwanegol hefyd rhwng gwasanaethau A a B. Ond yn ymarferol mae'n llai nag 1 ms ac nid yw hyn yn hollbwysig i'r rhan fwyaf o wasanaethau.
Delio â'r Annisgwyl: Cydbwyso a Gwydnwch y Gwasanaeth Chwilio
Dychmygwch fod yna gwymp: mae angen i chi ddod o hyd i gath gyda squeaker, ond mae'r gweinydd yn damwain. Neu 100 o weinyddion. Sut i fynd allan? Ydyn ni wir yn mynd i adael y defnyddiwr heb gath?
Mae’r sefyllfa’n frawychus, ond rydym yn barod amdani. Fe ddywedaf wrthych mewn trefn.
Mae'r seilwaith chwilio wedi'i leoli mewn sawl canolfan ddata:
Wrth ddylunio, rydym yn cynnwys y posibilrwydd o gau un ganolfan ddata. Mae bywyd yn llawn syrpreisys - er enghraifft, gall cloddiwr dorri cebl tanddaearol (ie, digwyddodd hynny). Dylai'r capasiti yn y canolfannau data sy'n weddill fod yn ddigon i wrthsefyll llwyth brig.
Gadewch i ni ystyried un ganolfan ddata. Mae gan bob canolfan ddata yr un cynllun gweithredu cydbwysedd:
Mae un balancer yn o leiaf dri gweinydd corfforol. Gwneir y diswyddiad hwn ar gyfer dibynadwyedd. Mae balanswyr yn rhedeg ar HAProx.
Fe wnaethom ddewis HAProx oherwydd ei berfformiad uchel, ei ofynion adnoddau isel a'i ymarferoldeb eang. Mae ein meddalwedd chwilio yn rhedeg y tu mewn i bob gweinydd.
Mae'r tebygolrwydd y bydd un gweinydd yn methu yn isel. Ond os oes gennych lawer o weinyddion, mae'r tebygolrwydd y bydd o leiaf un yn mynd i lawr yn cynyddu.
Dyma beth sy'n digwydd mewn gwirionedd: gweinyddwyr yn chwalu. Felly, mae angen monitro statws yr holl weinyddion yn gyson. Os bydd y gweinydd yn stopio ymateb, caiff ei ddatgysylltu'n awtomatig o draffig. At y diben hwn, mae gan HAProxy archwiliad iechyd adeiledig. Mae'n mynd i bob gweinydd unwaith yr eiliad gyda chais HTTP “/ ping”.
Mae nodwedd arall o HAProxy: agent-check yn caniatáu ichi lwytho'r holl weinyddion yn gyfartal. I wneud hyn, mae HAProxy yn cysylltu â'r holl weinyddion, ac maent yn dychwelyd eu pwysau yn dibynnu ar y llwyth cyfredol o 1 i 100. Cyfrifir y pwysau yn seiliedig ar nifer y ceisiadau yn y ciw ar gyfer prosesu a'r llwyth ar y prosesydd.
Nawr am ddod o hyd i'r gath. Mae canlyniadau'r chwiliad mewn ceisiadau fel: /search?text=ddig+cath. Er mwyn i'r chwiliad fod yn gyflym, rhaid i'r mynegai cathod cyfan ffitio i mewn i RAM. Nid yw hyd yn oed darllen o'r SSD yn ddigon cyflym.
Un tro, roedd y gronfa ddata cynigion yn fach, ac roedd RAM un gweinydd yn ddigon ar ei gyfer. Wrth i'r sylfaen gynnig dyfu, nid yw popeth bellach yn ffitio i'r RAM hwn, a rhannwyd y data yn ddwy ran: shard 1 a shard 2.
Ond mae hyn bob amser yn digwydd: mae unrhyw ateb, hyd yn oed un da, yn arwain at broblemau eraill.
Roedd y balancer yn dal i fynd i unrhyw weinydd. Ond ar y peiriant lle daeth y cais, dim ond hanner y mynegai oedd. Roedd y gweddill ar weinyddion eraill. Felly, roedd yn rhaid i'r gweinydd fynd i ryw beiriant cyfagos. Ar ôl derbyn data gan y ddau weinydd, cafodd y canlyniadau eu cyfuno a'u hail-drefnu.
Gan fod y balancer yn dosbarthu ceisiadau'n gyfartal, roedd pob gweinydd yn ail-raddio, ac nid yn anfon data yn unig.
Digwyddodd y broblem os nad oedd gweinydd cyfagos ar gael. Yr ateb oedd nodi sawl gweinydd gyda gwahanol flaenoriaethau fel gweinydd “cymdogol”. Yn gyntaf, anfonwyd y cais at y gweinyddwyr yn y rac cyfredol. Os nad oedd ymateb, anfonwyd y cais at bob gweinydd yn y ganolfan ddata hon. Ac yn olaf, aeth y cais i ganolfannau data eraill.
Wrth i nifer y cynigion dyfu, rhannwyd y data yn bedair rhan. Ond nid dyma oedd y terfyn.
Ar hyn o bryd, defnyddir cyfluniad o wyth darn. Yn ogystal, er mwyn arbed hyd yn oed mwy o gof, rhannwyd y mynegai yn rhan chwilio (a ddefnyddir ar gyfer chwilio) a rhan pyt (nad yw'n rhan o'r chwiliad).
Mae un gweinydd yn cynnwys gwybodaeth ar gyfer un darn yn unig. Felly, i chwilio'r mynegai llawn, mae angen i chi chwilio ar wyth gweinydd sy'n cynnwys darnau gwahanol.
Mae gweinyddwyr yn cael eu grwpio i glystyrau. Mae pob clwstwr yn cynnwys wyth peiriant chwilio ac un gweinydd pytiau.
Mae'r gweinydd pytiau yn rhedeg cronfa ddata gwerth bysell gyda data statig. Mae angen iddynt gyhoeddi dogfennau, er enghraifft, disgrifiad o gath gyda gwichiwr. Mae'r data'n cael ei drosglwyddo'n arbennig i weinydd ar wahân er mwyn peidio â llwytho cof gweinyddwyr chwilio.
Gan fod IDau dogfennau yn unigryw o fewn un mynegai yn unig, gallai sefyllfa godi lle nad oes dogfennau yn y pytiau. Wel, neu ar gyfer un ID bydd cynnwys gwahanol. Felly, er mwyn i'r chwiliad weithio ac i'r canlyniadau gael eu dychwelyd, roedd angen cysondeb ar draws y clwstwr cyfan. Dywedaf wrthych isod sut yr ydym yn monitro cysondeb.
Mae'r chwiliad ei hun wedi'i strwythuro fel a ganlyn: gall cais am chwiliad ddod i unrhyw un o'r wyth gweinydd. Gadewch i ni ddweud iddo ddod i weinydd 1. Mae'r gweinydd hwn yn prosesu'r holl ddadleuon ac yn deall beth a sut i edrych amdano. Yn dibynnu ar y cais sy'n dod i mewn, gall y gweinydd wneud ceisiadau ychwanegol i wasanaethau allanol am y wybodaeth angenrheidiol. Gellir dilyn un cais gan hyd at ddeg cais i wasanaethau allanol.
Ar ôl casglu'r wybodaeth angenrheidiol, mae chwiliad yn dechrau yn y gronfa ddata cynigion. I wneud hyn, gwneir subqueries i bob un o'r wyth gweinydd yn y clwstwr.
Unwaith y derbynnir yr ymatebion, cyfunir y canlyniadau. Yn y pen draw, efallai y bydd angen sawl subqueries arall i'r gweinydd pytiau i gynhyrchu'r canlyniadau.
Mae ymholiadau chwilio o fewn y clwstwr yn edrych fel: /shard1?text=ddig+cath. Yn ogystal, gwneir subqueries o'r ffurflen yn gyson rhwng yr holl weinyddion o fewn y clwstwr unwaith yr eiliad: /statws.
Cais /statws yn canfod sefyllfa lle nad yw'r gweinydd ar gael.
Mae hefyd yn rheoli bod fersiwn y peiriant chwilio a'r fersiwn mynegai yr un peth ar bob gweinydd, fel arall bydd data anghyson o fewn y clwstwr.
Er gwaethaf y ffaith bod un gweinydd pyt yn prosesu ceisiadau gan wyth peiriant chwilio, mae ei brosesydd wedi'i lwytho'n ysgafn iawn. Felly, rydym yn awr yn trosglwyddo’r data pyt i wasanaeth ar wahân.
Er mwyn trosglwyddo data, rydym wedi cyflwyno allweddi cyffredinol ar gyfer dogfennau. Nawr mae'n amhosibl sefyllfa lle mae cynnwys o ddogfen arall yn cael ei ddychwelyd gan ddefnyddio un allwedd.
Ond nid yw'r newid i bensaernïaeth arall wedi'i gwblhau eto. Nawr rydym am gael gwared ar y gweinydd pytiau pwrpasol. Ac yna symud i ffwrdd o'r strwythur clwstwr yn gyfan gwbl. Bydd hyn yn ein galluogi i barhau i raddfa'n hawdd. Bonws ychwanegol yw arbedion haearn sylweddol.
Ac yn awr i straeon brawychus gyda diweddglo hapus. Gadewch i ni ystyried sawl achos o ddiffyg gweinydd.
Digwyddodd rhywbeth ofnadwy: nid yw un gweinydd ar gael
Gadewch i ni ddweud nad yw un gweinydd ar gael. Yna gall y gweinyddwyr sy'n weddill yn y clwstwr barhau i ymateb, ond bydd y canlyniadau chwilio yn anghyflawn.
Trwy wirio statws /statws mae gweinyddwyr cyfagos yn deall nad oes un ar gael. Felly, er mwyn cynnal cyflawnder, yr holl weinyddion yn y clwstwr fesul cais /ping maent yn dechrau ymateb i'r cydbwysedd nad ydynt ar gael ychwaith. Mae'n ymddangos bod yr holl weinyddion yn y clwstwr wedi marw (nad yw'n wir). Dyma brif anfantais ein cynllun clwstwr – dyna pam rydym ni eisiau dianc oddi wrtho.
Mae ceisiadau sy'n methu â gwall yn cael eu digio gan y balanswr ar weinyddion eraill.
Mae'r balancer hefyd yn rhoi'r gorau i anfon traffig defnyddwyr i weinyddion marw, ond yn parhau i wirio eu statws.
Pan fydd y gweinydd ar gael, mae'n dechrau ymateb i /ping. Cyn gynted ag y bydd ymatebion arferol i pings gan weinyddion marw yn dechrau cyrraedd, mae balanswyr yn dechrau anfon traffig defnyddwyr yno. Mae gweithrediad clwstwr yn cael ei adfer, hurray.
Hyd yn oed yn waeth: nid yw llawer o weinyddion ar gael
Mae rhan sylweddol o'r gweinyddwyr yn y ganolfan ddata yn cael eu torri i lawr. Beth i'w wneud, ble i redeg? Daw'r balancer i'r adwy eto. Mae pob balancer yn storio'r nifer presennol o weinyddion byw yn y cof yn gyson. Mae'n cyfrifo'n gyson yr uchafswm traffig y gall y ganolfan ddata gyfredol ei brosesu.
Pan fydd llawer o weinyddion mewn canolfan ddata yn mynd i lawr, mae'r balancer yn sylweddoli na all y ganolfan ddata hon brosesu'r holl draffig.
Yna mae'r traffig gormodol yn dechrau cael ei ddosbarthu ar hap i ganolfannau data eraill. Mae popeth yn gweithio, mae pawb yn hapus.
Sut rydym yn ei wneud: cyhoeddi datganiadau
Nawr gadewch i ni siarad am sut rydyn ni'n cyhoeddi newidiadau a wnaed i'r gwasanaeth. Yma rydym wedi cymryd y llwybr o symleiddio prosesau: mae cyflwyno datganiad newydd bron yn gyfan gwbl awtomataidd.
Pan gronnir nifer penodol o newidiadau yn y prosiect, caiff datganiad newydd ei greu'n awtomatig a bydd ei adeiladu'n dechrau.
Yna mae'r gwasanaeth yn cael ei gyflwyno i brofi, lle mae sefydlogrwydd gweithrediad yn cael ei wirio.
Ar yr un pryd, mae profion perfformiad awtomatig yn cael ei lansio. Ymdrinnir â hyn gan wasanaeth arbennig. Wna i ddim siarad amdano nawr - mae ei ddisgrifiad yn deilwng o erthygl ar wahân.
Os bydd cyhoeddi yn y profion yn llwyddiannus, bydd cyhoeddi'r datganiad yn prestable yn cychwyn yn awtomatig. Mae Prestable yn glwstwr arbennig lle mae traffig defnyddwyr arferol yn cael ei gyfeirio. Os bydd yn dychwelyd gwall, mae'r balans yn gwneud cais arall i gynhyrchu.
Yn prestable, mae amseroedd ymateb yn cael eu mesur a'u cymharu â'r datganiad blaenorol wrth gynhyrchu. Os yw popeth yn iawn, yna mae person yn cysylltu: yn gwirio'r graffiau a chanlyniadau'r profion llwyth ac yna'n dechrau eu cyflwyno i gynhyrchu.
Pob lwc i'r defnyddiwr: profion A/B
Nid yw bob amser yn amlwg a fydd newidiadau i wasanaeth yn dod â manteision gwirioneddol. Er mwyn mesur defnyddioldeb newidiadau, cynhyrchodd pobl brofion A/B. Byddaf yn dweud ychydig wrthych am sut mae'n gweithio mewn chwiliad Yandex.Market.
Mae'r cyfan yn dechrau gydag ychwanegu paramedr CGI newydd sy'n galluogi ymarferoldeb newydd. Gadewch i'n paramedr fod yn: market_new_functionality=1. Yna yn y cod rydym yn galluogi'r swyddogaeth hon os yw'r faner yn bresennol:
If (cgi.experiments.market_new_functionality) {
// enable new functionality
}Mae ymarferoldeb newydd yn cael ei gyflwyno i gynhyrchu.
Er mwyn awtomeiddio profion A/B, mae gwasanaeth pwrpasol sy'n darparu gwybodaeth fanwl . Mae arbrawf yn cael ei greu yn y gwasanaeth. Mae'r gyfran traffig wedi'i osod, er enghraifft, 15%. Pennir canrannau nid ar gyfer ymholiadau, ond ar gyfer defnyddwyr. Mae hyd yr arbrawf hefyd yn cael ei nodi, er enghraifft, wythnos.
Gellir cynnal nifer o arbrofion ar yr un pryd. Yn y gosodiadau gallwch chi nodi a yw croestoriad ag arbrofion eraill yn bosibl.
O ganlyniad, mae'r gwasanaeth yn ychwanegu dadl yn awtomatig market_new_functionality=1 i 15% o ddefnyddwyr. Mae hefyd yn cyfrifo'r metrigau a ddewiswyd yn awtomatig. Ar ôl cwblhau'r arbrawf, mae dadansoddwyr yn edrych ar y canlyniadau ac yn dod i gasgliadau. Yn seiliedig ar y canfyddiadau, gwneir penderfyniad i'w gyflwyno i gynhyrchu neu fireinio.
Llaw ddeheuig y farchnad: profi wrth gynhyrchu
Mae'n aml yn digwydd bod angen i chi brofi gweithrediad swyddogaeth newydd wrth gynhyrchu, ond nid ydych chi'n siŵr sut y bydd yn ymddwyn mewn amodau "ymladd" o dan lwyth trwm.
Mae yna ateb: gellir defnyddio baneri mewn paramedrau CGI nid yn unig ar gyfer profion A/B, ond hefyd i brofi ymarferoldeb newydd.
Gwnaethom offeryn sy'n eich galluogi i newid ffurfweddiad miloedd o weinyddion ar unwaith heb amlygu'r gwasanaeth i risgiau. Fe'i gelwir yn Stop Tap. Y syniad gwreiddiol oedd gallu analluogi rhai swyddogaethau yn gyflym heb gynllun. Yna ehangodd yr offeryn a daeth yn fwy cymhleth.
Cyflwynir y diagram llif gwasanaeth isod:
Mae gwerthoedd baner yn cael eu gosod trwy'r API. Mae'r gwasanaeth rheoli yn storio'r gwerthoedd hyn yn y gronfa ddata. Mae pob gweinydd yn mynd i'r gronfa ddata unwaith bob deg eiliad, yn pwmpio gwerthoedd baner allan ac yn cymhwyso'r gwerthoedd hyn i bob cais.
Yn y tap Stop gallwch chi osod dau fath o werth:
1) Mynegiadau amodol. Gwnewch gais pan fydd un o'r gwerthoedd yn wir. Er enghraifft:
{
"condition":"IS_DC1",
"value":"3",
},
{
"condition": "CLUSTER==2 and IS_BERU",
"value": "4!"
}Bydd y gwerth "3" yn cael ei gymhwyso pan fydd y cais yn cael ei brosesu yn lleoliad DC1. A'r gwerth yw "4" pan fydd y cais yn cael ei brosesu ar yr ail glwstwr ar gyfer y safle beru.ru.
2) Gwerthoedd diamod. Gwnewch gais yn ddiofyn os na chaiff unrhyw un o'r amodau eu bodloni. Er enghraifft:
gwerth, gwerth!
Os yw gwerth yn gorffen gyda phwynt ebychnod, rhoddir blaenoriaeth uwch iddo.
Mae parser paramedr CGI yn dosrannu'r URL. Yna cymhwyso'r gwerthoedd o'r Tap Stop.
Cymhwysir gwerthoedd gyda’r blaenoriaethau a ganlyn:
- Gyda mwy o flaenoriaeth gan y Tap Stop (ebychnod).
- Y gwerth o'r cais.
- Gwerth diofyn o Stop tap.
- Gwerth diofyn yn y cod.
Mae yna lawer o fflagiau sy'n cael eu nodi mewn gwerthoedd amodol - maen nhw'n ddigon ar gyfer pob senario sy'n hysbys i ni:
- Canolfan ddata.
- Amgylchedd: cynhyrchu, profi, cysgod.
- Lleoliad: market, beru.
- Rhif clwstwr.
Gyda'r offeryn hwn, gallwch chi alluogi swyddogaethau newydd ar grŵp penodol o weinyddion (er enghraifft, mewn un ganolfan ddata yn unig) a phrofi gweithrediad y swyddogaeth hon heb unrhyw risg benodol i'r gwasanaeth cyfan. Hyd yn oed os gwnaethoch gamgymeriad difrifol yn rhywle, dechreuodd popeth ddisgyn ac aeth y ganolfan ddata gyfan i lawr, bydd balanswyr yn ailgyfeirio ceisiadau i ganolfannau data eraill. Ni fydd defnyddwyr terfynol yn sylwi ar unrhyw beth.
Os byddwch chi'n sylwi ar broblem, gallwch chi ddychwelyd y faner i'w gwerth blaenorol ar unwaith a bydd y newidiadau'n cael eu rholio'n ôl.
Mae gan y gwasanaeth hwn ei anfanteision hefyd: mae'r datblygwyr wrth eu bodd yn fawr iawn ac yn aml yn ceisio gwthio'r holl newidiadau i'r Tap Stop. Rydym yn ceisio brwydro yn erbyn camddefnydd.
Mae'r dull Stop Tap yn gweithio'n dda pan fydd gennych chi god sefydlog eisoes yn barod i'w gyflwyno i gynhyrchu. Ar yr un pryd, mae gennych chi amheuon o hyd, ac rydych chi am wirio'r cod mewn amodau "ymladd".
Fodd bynnag, nid yw Stop Tap yn addas ar gyfer profi yn ystod datblygiad. Mae clwstwr ar wahân ar gyfer datblygwyr o’r enw “clwstwr cysgodol”.
Profi Cyfrinachol: Clwstwr Cysgodol
Mae ceisiadau gan un o'r clystyrau yn cael eu dyblygu i'r clwstwr cysgodol. Ond mae'r cydbwyseddwr yn anwybyddu'n llwyr yr ymatebion o'r clwstwr hwn. Mae'r diagram o'i weithrediad wedi'i gyflwyno isod.
Rydyn ni'n cael clwstwr prawf sydd mewn amodau “brwydro yn erbyn” go iawn. Mae traffig defnyddwyr arferol yn mynd yno. Mae'r caledwedd yn y ddau glwstwr yr un peth, felly gellir cymharu perfformiad a gwallau.
A chan fod y balancer yn anwybyddu ymatebion yn llwyr, ni fydd defnyddwyr terfynol yn gweld ymatebion o'r clwstwr cysgodol. Felly, nid yw'n frawychus gwneud camgymeriad.
Canfyddiadau
Felly, sut wnaethon ni adeiladu chwiliad y Farchnad?
Er mwyn gwneud i bopeth fynd yn esmwyth, rydym yn gwahanu ymarferoldeb yn wasanaethau ar wahân. Fel hyn gallwn raddio dim ond y cydrannau hynny sydd eu hangen arnom a gwneud y cydrannau'n symlach. Mae’n hawdd neilltuo cydran ar wahân i dîm arall a rhannu’r cyfrifoldebau am weithio arni. Ac mae arbedion haearn sylweddol gyda'r dull hwn yn fantais amlwg.
Mae’r clwstwr cysgodol hefyd yn ein helpu: gallwn ddatblygu gwasanaethau, eu profi yn y broses a pheidio ag aflonyddu ar y defnyddiwr.
Wel, profi mewn cynhyrchu, wrth gwrs. Angen newid ffurfweddiad ar filoedd o weinyddion? Hawdd, defnyddiwch y Tap Stop. Fel hyn, gallwch gyflwyno datrysiad cymhleth parod ar unwaith a rholio'n ôl i fersiwn sefydlog os bydd problemau'n codi.
Rwy'n gobeithio fy mod wedi gallu dangos sut rydym yn gwneud y Farchnad yn gyflym ac yn sefydlog gyda sylfaen gynyddol o gynigion. Sut rydym yn datrys problemau gweinydd, yn delio â nifer enfawr o geisiadau, yn gwella hyblygrwydd y gwasanaeth ac yn gwneud hyn heb dorri ar draws prosesau gwaith.
Ffynhonnell: hab.com