Mae Habr yn newid y byd. Rydym wedi bod yn blogio ers dros flwyddyn bellach. Tua chwe mis yn ôl, cawsom adborth cwbl resymegol gan Khabrovites: “Dodo, rydych chi'n dweud ym mhobman bod gennych chi'ch system eich hun. A beth yw'r system hon? A pham mae cadwyn pizza ei angen?
Fe wnaethon ni eistedd, meddwl a sylweddoli eich bod chi'n iawn. Rydyn ni'n ceisio esbonio popeth ar ein bysedd, ond mae'n dod allan yn ddarnau wedi'u rhwygo ac nid oes disgrifiad cyflawn o'r system yn unman. Felly dechreuwyd taith hir o gasglu gwybodaeth, chwilio am awduron ac ysgrifennu cyfres o erthyglau am Dodo IS. Awn ni!
Diolchiadau: Diolch am rannu eich adborth gyda ni. Diolch iddo, fe wnaethom ddisgrifio'r system yn olaf, llunio radar technegol a byddwn yn cyflwyno disgrifiad mawr o'n prosesau yn fuan. Hebddoch chi, byddem wedi bod yn eistedd yno am 5 mlynedd arall.
Cyfres o erthyglau "Beth yw Dodo IS?" yn dweud am:
- Monolith cynnar yn Dodo IS (2011-2015). (Ar y gweill…)
- Llwybr y swyddfa gefn: canolfannau a bws ar wahân. (rwyt ti yma)
- Llwybr ochr y cleient: ffasâd dros y sylfaen (2016-2017). (Ar y gweill...)
- Hanes microwasanaethau go iawn. (2018-2019). (Ar y gweill...)
- Gorffen llifio'r monolith a sefydlogi'r bensaernïaeth. (Ar y gweill...)
Os oes gennych ddiddordeb mewn gwybod rhywbeth arall - ysgrifennwch y sylwadau.
Barn ar y disgrifiad cronolegol gan yr awdur
Rwy'n cynnal cyfarfod yn rheolaidd ar gyfer gweithwyr newydd ar y pwnc "System Architecture". Rydyn ni'n ei alw'n “Intro to Dodo IS Architecture” ac mae'n rhan o'r broses ymuno ar gyfer datblygwyr newydd. Gan ddweud mewn rhyw ffurf neu'i gilydd am ein pensaernïaeth, am ei nodweddion, rwyf wedi meithrin agwedd hanesyddol benodol at y disgrifiad.
Yn draddodiadol, rydym yn edrych ar y system fel set o gydrannau (technegol neu lefel uwch), modiwlau busnes sy'n rhyngweithio â'i gilydd i gyflawni rhyw nod. Ac os gellir cyfiawnhau safbwynt o'r fath ar gyfer dylunio, yna nid yw'n gwbl addas ar gyfer disgrifio a deall. Mae yna sawl rheswm yma:
- Mae realiti yn wahanol i'r hyn sydd ar bapur. Nid yw popeth yn gweithio allan fel y bwriadwyd. Ac mae gennym ddiddordeb yn y ffordd y mae'n troi allan ac yn gweithio mewn gwirionedd.
- Cyflwyno gwybodaeth yn gyson. Mewn gwirionedd, gallwch chi fynd yn gronolegol o'r dechrau i'r cyflwr presennol.
- O syml i gymhleth. Nid yn gyffredinol, ond yn ein hachos ni y mae. Symudodd y bensaernïaeth o ddulliau symlach i rai mwy cymhleth. Yn aml trwy gymhlethdod, datryswyd problemau cyflymder gweithredu a sefydlogrwydd, yn ogystal â dwsinau o eiddo eraill o'r rhestr o ofynion anweithredol ( dweud yn dda am gymhlethdod cyferbyniol â gofynion eraill).
Yn 2011, roedd pensaernïaeth Dodo IS yn edrych fel hyn:
Erbyn 2020, mae wedi dod ychydig yn fwy cymhleth ac wedi dod fel hyn:
Sut digwyddodd yr esblygiad hwn? Pam mae angen gwahanol rannau o'r system? Pa benderfyniadau pensaernïol a wnaed a pham? Gadewch i ni ddarganfod yn y gyfres hon o erthyglau.
Problemau cyntaf 2016: pam ddylai gwasanaethau adael y monolith
Bydd yr erthyglau cyntaf o'r cylch yn ymwneud â'r gwasanaethau a oedd y cyntaf i wahanu oddi wrth y monolith. I’ch rhoi yn eich cyd-destun, fe ddywedaf wrthych pa broblemau a gawsom yn y system erbyn dechrau 2016, sef yr oedd yn rhaid inni ymdrin â gwahanu gwasanaethau.
Un gronfa ddata MySql, lle ysgrifennodd yr holl gymwysiadau a oedd yn bodoli ar y pryd yn Dodo IS eu cofnodion. Y canlyniadau oedd:
- Llwyth trwm (gyda 85% o geisiadau yn cyfrif am ddarllen).
- Mae'r sylfaen wedi tyfu. Oherwydd hyn, daeth ei gost a'i gefnogaeth yn broblem.
- Pwynt sengl o fethiant. Pe bai un cais a oedd yn ysgrifennu at y gronfa ddata yn dechrau gwneud pethau'n fwy gweithredol yn sydyn, yna roedd rhaglenni eraill yn teimlo hynny arnyn nhw eu hunain.
- Aneffeithlonrwydd storio ac ymholiadau. Yn aml, roedd y data'n cael ei storio mewn rhyw strwythur a oedd yn gyfleus ar gyfer rhai senarios ond nad oedd yn addas ar gyfer eraill. Mae mynegeion yn cyflymu rhai gweithrediadau, ond gallant arafu rhai eraill.
- Cafodd rhai o'r problemau eu dileu gan caches a wnaed ar frys a replicas darllen i'r seiliau (bydd hon yn erthygl ar wahân), ond dim ond yn caniatáu iddynt ennill amser ac nid oeddent yn sylfaenol datrys y broblem.
Y broblem oedd presenoldeb y monolith ei hun. Y canlyniadau oedd:
- Rhyddhad sengl a phrin.
- Anhawster wrth ddatblygu nifer fawr o bobl ar y cyd.
- Anallu i gyflwyno technolegau newydd, fframweithiau newydd a llyfrgelloedd.
Disgrifiwyd problemau gyda’r sylfaen a’r monolith sawl gwaith, er enghraifft, yng nghyd-destun damweiniau ar ddechrau 2018 (, и ), felly ni fyddaf yn trigo gormod. Gadewch imi ddweud ein bod am roi mwy o hyblygrwydd wrth ddatblygu gwasanaethau. Yn gyntaf oll, roedd hyn yn ymwneud â'r rhai a oedd wedi'u llwytho fwyaf ac sydd â'r gwreiddiau mwyaf yn y system gyfan - Auth and Tracker.
Y Llwybr Swyddfa Gefn: Canolfannau a Bws ar Wahân
Llywio penodau
Cynllun monolith 2016
Dyma brif flociau monolith Dodo IS 2016, ac ychydig isod mae trawsgrifiad o'u prif dasgau.
Dosbarthu Ariannwr. Rhoi cyfrif am negeswyr, rhoi archebion i negeswyr.
Canolfan gyswllt. Derbyn archebion trwy'r gweithredwr.
safle. Ein gwefannau (dodopizza.ru, dodopizza.co.uk, dodopizza.by, ac ati).
Awdur. Gwasanaeth awdurdodi a dilysu ar gyfer y swyddfa gefn.
Traciwr. Archebu traciwr yn y gegin. Gwasanaeth ar gyfer marcio statws parodrwydd wrth baratoi archeb.
Desg arian parod y Bwyty. Cymryd archebion mewn bwyty, rhyngwynebau ariannwr.
Export. Lanlwytho adroddiadau mewn 1C ar gyfer cyfrifyddu.
Hysbysiadau ac anfonebau. Gorchmynion llais yn y gegin (er enghraifft, “Cyrhaeddodd pizza newydd”) + argraffu anfoneb ar gyfer negeswyr.
Rheolwr Sifft. Rhyngwynebau ar gyfer gwaith y rheolwr sifft: rhestr o orchmynion, graffiau perfformiad, trosglwyddo gweithwyr i'r sifft.
Rheolwr Swyddfa. Rhyngwynebau ar gyfer gwaith y deiliad masnachfraint a'r rheolwr: derbyniad gweithwyr, adroddiadau ar waith y pizzeria.
Bwrdd Sgorio Bwyty. Arddangos bwydlen ar setiau teledu mewn pizzerias.
gweinyddwr. Gosodiadau mewn pizzeria penodol: bwydlen, prisiau, cyfrifyddu, codau promo, hyrwyddiadau, baneri gwefan, ac ati.
Cyfrif Personol Gweithiwr. Amserlenni gwaith gweithwyr, gwybodaeth am weithwyr.
Bwrdd Cymhelliant Cegin. Sgrin ar wahân sy'n hongian yn y gegin ac yn dangos cyflymder y gwneuthurwyr pizza.
Cyfathrebu. Anfon sms ac e-bost.
Storio Ffeil. Gwasanaeth eich hun ar gyfer derbyn a chyhoeddi ffeiliau statig.
Roedd yr ymdrechion cyntaf i ddatrys y problemau o gymorth i ni, ond dim ond seibiant dros dro oedden nhw. Ni ddaethant yn atebion system, felly roedd yn amlwg bod yn rhaid gwneud rhywbeth gyda'r seiliau. Er enghraifft, i rannu'r gronfa ddata gyffredinol yn rhai mwy arbenigol.
Dechrau Dadlwytho'r Monolith: Gwahanu Awd a Traciwr
Y prif wasanaethau a oedd wedyn yn recordio ac yn darllen o'r gronfa ddata yn fwy nag eraill:
- Awd. Gwasanaeth awdurdodi a dilysu ar gyfer y swyddfa gefn.
- Traciwr. Archebu traciwr yn y gegin. Gwasanaeth ar gyfer marcio statws parodrwydd wrth baratoi archeb.
Beth mae Auth yn ei wneud?
Mae Auth yn wasanaeth lle mae defnyddwyr yn mewngofnodi i'r swyddfa gefn (mae mynedfa annibynnol ar wahân ar ochr y cleient). Gelwir hefyd yn y cais i sicrhau bod yr hawliau mynediad gofynnol yn bresennol ac nad yw'r hawliau hyn wedi newid ers y mewngofnodi diwethaf. Trwyddo, mae dyfeisiau'n mynd i mewn i'r pizzeria.
Er enghraifft, rydym am agor arddangosfa gyda statws gorchmynion gorffenedig ar y teledu sy'n hongian yn y neuadd. Yna rydym yn agor auth.dodopizza.ru, dewiswch "Mewngofnodi fel dyfais", mae cod yn ymddangos y gellir ei nodi ar dudalen arbennig ar gyfrifiadur y rheolwr sifft, sy'n nodi'r math o ddyfais (dyfais). Bydd y teledu ei hun yn newid i ryngwyneb dymunol ei pizzeria ac yn dechrau arddangos enwau cwsmeriaid y mae eu harchebion yn barod yno.
O ble mae'r llwythi?
Mae pob defnyddiwr sydd wedi mewngofnodi o'r swyddfa gefn yn mynd i'r gronfa ddata, i'r bwrdd defnyddwyr ar gyfer pob cais, yn tynnu'r defnyddiwr allan trwy ymholiad sql ac yn gwirio a oes ganddo'r mynediad a'r hawliau angenrheidiol i'r dudalen hon.
Mae pob un o'r dyfeisiau yn gwneud yr un peth yn unig gyda thabl y ddyfais, gan wirio ei rôl a'i fynediad. Mae nifer fawr o geisiadau i'r brif gronfa ddata yn arwain at ei lwytho a gwastraffu adnoddau'r gronfa ddata gyffredin ar gyfer y gweithrediadau hyn.
Wrthi'n dadlwytho Awd
Mae gan Auth barth ynysig, hynny yw, mae data am ddefnyddwyr, mewngofnodi neu ddyfeisiau yn mynd i mewn i'r gwasanaeth (am y tro) ac yn aros yno. Os oes eu hangen ar rywun, yna bydd yn mynd i'r gwasanaeth hwn i gael data.
YR OEDD. Roedd y cynllun gwaith gwreiddiol fel a ganlyn:
Hoffwn egluro ychydig sut y gweithiodd:
- Daw cais o'r tu allan i'r pen ôl (mae Asp.Net MVC), yn dod â chwci sesiwn gydag ef, a ddefnyddir i gael data sesiwn gan Redis(1). Mae naill ai'n cynnwys gwybodaeth am fynediadau, ac yna mae mynediad i'r rheolydd yn agored (3,4), neu ddim.
- Os nad oes mynediad, mae angen ichi fynd trwy'r weithdrefn awdurdodi. Yma, er mwyn symlrwydd, fe'i dangosir fel rhan o'r llwybr yn yr un priodoledd, er ei fod yn drawsnewidiad i'r dudalen mewngofnodi. Yn achos senario cadarnhaol, byddwn yn cael sesiwn wedi'i chwblhau'n gywir ac yn mynd at y Rheolwr Backoffice.
- Os oes data, yna mae angen i chi ei wirio am berthnasedd yn y sylfaen defnyddwyr. Ydy ei rôl wedi newid, oni ddylai gael ei ganiatáu ar y dudalen nawr? Yn yr achos hwn, ar ôl derbyn y sesiwn (1), mae angen i chi fynd yn uniongyrchol i'r gronfa ddata a gwirio mynediad y defnyddiwr gan ddefnyddio'r haen rhesymeg dilysu (2). Nesaf, naill ai i'r dudalen mewngofnodi, neu ewch i'r rheolydd. System mor syml, ond ddim yn hollol safonol.
- Os caiff yr holl weithdrefnau eu pasio, yna rydym yn hepgor ymhellach yn y rhesymeg mewn rheolwyr a dulliau.
Mae data defnyddwyr wedi'i wahanu oddi wrth yr holl ddata arall, mae'n cael ei storio mewn tabl aelodaeth ar wahân, mae'n bosibl iawn y bydd swyddogaethau o haen rhesymeg AuthService yn dod yn ddulliau API. Diffinnir ffiniau parth yn eithaf clir: defnyddwyr, eu rolau, mynediad at ddata, caniatáu a dirymu mynediad. Mae popeth yn edrych fel y gellir ei dynnu allan mewn gwasanaeth ar wahân.
DEWCH. Felly gwnaethant:
Mae gan y dull hwn nifer o broblemau. Er enghraifft, nid yw galw dull y tu mewn i broses yr un peth â galw gwasanaeth allanol trwy http. Mae hwyrni, dibynadwyedd, cynaladwyedd, tryloywder y llawdriniaeth yn hollol wahanol. Siaradodd Andrey Morevskiy yn fanylach am broblemau o'r fath yn ei adroddiad. .
Defnyddir y gwasanaeth dilysu ac, gydag ef, y gwasanaeth dyfais ar gyfer y swyddfa gefn, hynny yw, ar gyfer gwasanaethau a rhyngwynebau a ddefnyddir wrth gynhyrchu. Mae dilysu ar gyfer gwasanaethau cleientiaid (fel gwefan neu raglen symudol) yn digwydd ar wahân heb ddefnyddio Auth. Cymerodd y gwahaniad tua blwyddyn, ac yn awr rydym yn delio â'r pwnc hwn eto, gan drosglwyddo'r system i wasanaethau dilysu newydd (gyda phrotocolau safonol).
Pam y cymerodd y gwahaniad gymaint o amser?
Roedd yna lawer o broblemau ar hyd y ffordd a wnaeth ein harafu:
- Roeddem am symud data defnyddwyr, dyfeisiau a dilysu o gronfeydd data gwlad-benodol yn un. I wneud hyn, bu'n rhaid i ni gyfieithu pob tabl a defnydd o'r dynodwr int i'r dynodwr UUId byd-eang (ailweithio'r cod hwn yn ddiweddar a phrosiect ffynhonnell agored ). Mae gan storio data defnyddwyr (gan ei fod yn wybodaeth bersonol) ei gyfyngiadau ac ar gyfer rhai gwledydd mae angen eu storio ar wahân. Ond rhaid id byd-eang y defnyddiwr fod.
- Mae gan lawer o dablau yn y gronfa ddata wybodaeth archwilio am y defnyddiwr a gyflawnodd y llawdriniaeth. Roedd hyn yn gofyn am fecanwaith ychwanegol ar gyfer cysondeb.
- Ar ôl creu gwasanaethau api, bu cyfnod hir a graddol o drosglwyddo i system arall. Roedd yn rhaid i'r newid fod yn ddi-dor i ddefnyddwyr ac roedd angen gwneud gwaith llaw.
Cynllun cofrestru dyfais mewn pizzeria:
Pensaernïaeth gyffredinol ar ôl echdynnu gwasanaeth Auth and Devices:
Nodyn. Ar gyfer 2020, rydym yn gweithio ar fersiwn newydd o Auth, sy'n seiliedig ar safon awdurdodi OAuth 2.0. Mae'r safon hon yn eithaf cymhleth, ond mae'n ddefnyddiol ar gyfer datblygu gwasanaeth dilysu pasio drwodd. Yn yr erthygl "» fe wnaethom ni Alexey Chernyaev geisio dweud am y safon mor syml a chlir â phosibl fel eich bod yn arbed amser ar ei hastudio.
Beth mae Tracker yn ei wneud?
Nawr am yr ail o'r gwasanaethau llwytho. Mae'r traciwr yn cyflawni rôl ddeuol:
- Ar y naill law, ei dasg yw dangos i'r gweithwyr yn y gegin pa orchmynion sydd yn y gwaith ar hyn o bryd, pa gynhyrchion sydd angen eu coginio nawr.
- Ar y llaw arall, i ddigideiddio holl brosesau yn y gegin.
Pan fydd cynnyrch newydd yn ymddangos mewn trefn (er enghraifft, pizza), mae'n mynd i'r orsaf olrhain Cyflwyno. Yn yr orsaf hon, mae gwneuthurwr pizza sy'n cymryd bynsen o'r maint gofynnol ac yn ei rolio allan, ac ar ôl hynny mae'n nodi ar y dabled olrhain ei fod wedi cwblhau ei dasg ac yn trosglwyddo'r sylfaen toes wedi'i rolio i'r orsaf nesaf - "Cychwyn" .
Yno, mae’r gwneuthurwr pizza nesaf yn llenwi’r pizza, yna’n nodi ar y tabled ei fod wedi cwblhau ei dasg ac yn rhoi’r pizza yn y popty (mae hon hefyd yn orsaf ar wahân y mae’n rhaid ei nodi ar y tabled). Roedd system o'r fath o'r cychwyn cyntaf yn Dodo ac o ddechrau bodolaeth Dodo IS. Mae'n caniatáu ichi olrhain a digideiddio'r holl drafodion yn llawn. Yn ogystal, mae'r traciwr yn awgrymu sut i goginio cynnyrch penodol, yn arwain pob math o gynnyrch yn unol â'i gynlluniau gweithgynhyrchu, yn storio'r amser coginio gorau posibl ar gyfer y cynnyrch, ac yn olrhain yr holl weithrediadau ar y cynnyrch.
Dyma sut olwg sydd ar sgrin y dabled yng ngorsaf y traciwr "Raskatka"
O ble mae'r llwythi?
Mae gan bob un o'r pizzerias tua phum tabled gyda thraciwr. Yn 2016, roedd gennym fwy na 100 o pizzerias (a nawr mwy na 600). Mae pob un o'r tabledi yn gwneud cais i'r pen ôl unwaith bob 10 eiliad ac yn sgrapio data o'r tabl archebu (cysylltiad â'r cleient a'r cyfeiriad), cyfansoddiad archeb (cysylltiad â'r cynnyrch ac arwydd o faint), y tabl cyfrifo cymhelliant (y amser gwasgu yn cael ei olrhain ynddo). Pan fydd gwneuthurwr pizza yn clicio ar gynnyrch ar y traciwr, mae'r cofnodion ym mhob un o'r tablau hyn yn cael eu diweddaru. Mae'r tabl archeb yn gyffredinol, mae hefyd yn cynnwys mewnosodiadau wrth dderbyn archeb, diweddariadau o rannau eraill o'r system a darlleniadau niferus, er enghraifft, ar deledu sy'n hongian mewn pizzeria ac yn dangos archebion gorffenedig i gwsmeriaid.
Yn ystod y cyfnod o frwydro â llwythi, pan gafodd popeth a phopeth ei storio a'i drosglwyddo i replica asyncronig y sylfaen, parhaodd y gweithrediadau hyn gyda'r traciwr i fynd i'r prif sylfaen. Ni ddylai fod unrhyw oedi, dylai'r data fod yn gyfredol, nid yw wedi'i gysoni'n dderbyniol.
Hefyd, nid oedd diffyg tablau a mynegeion personol arnynt yn caniatáu ysgrifennu ymholiadau mwy penodol wedi'u teilwra at eu defnydd. Er enghraifft, gallai fod yn effeithlon i draciwr gael mynegai ar gyfer pizzeria ar fwrdd archebu. Rydyn ni bob amser yn tynnu archebion pizzeria o'r gronfa ddata olrhain. Ar yr un pryd, ar gyfer derbyn archeb, nid yw mor bwysig pa pizzeria y mae'n perthyn iddo, mae'n bwysicach pa gleient a wnaeth y gorchymyn hwn. Ac yn golygu bod y mynegai ar y cleient yn angenrheidiol. Nid oes angen ychwaith i'r traciwr storio id y dderbynneb argraffedig neu hyrwyddiadau bonws sy'n gysylltiedig â'r archeb yn y tabl archeb. Nid yw'r wybodaeth hon o ddiddordeb i'n gwasanaeth olrhain. Mewn cronfa ddata monolithig gyffredin, dim ond cyfaddawd rhwng yr holl ddefnyddwyr y gallai tablau fod. Roedd hwn yn un o'r problemau gwreiddiol.
YR OEDD. Y bensaernïaeth wreiddiol oedd:
Hyd yn oed ar ôl cael ei wahanu i brosesau ar wahân, roedd y rhan fwyaf o'r sylfaen cod yn parhau i fod yn gyffredin ar gyfer gwahanol wasanaethau. Roedd popeth o dan y rheolyddion yn sengl ac yn byw yn yr un ystorfa. Defnyddiasom ddulliau cyffredin o wasanaethau, ystorfeydd, sylfaen gyffredin, lle gorweddai tablau cyffredin.
Dadlwytho Traciwr
Y brif broblem gyda'r traciwr yw bod yn rhaid i'r data gael ei gydamseru rhwng gwahanol gronfeydd data. Dyma hefyd ei brif wahaniaeth o wahanu gwasanaeth yr Awd, gall y gorchymyn a'i statws newid a dylid ei arddangos mewn gwahanol wasanaethau.
Rydym yn derbyn archeb wrth Desg Dalu'r Bwyty (mae hwn yn wasanaeth), mae'n cael ei storio yn y gronfa ddata yn y statws "Derbyniol". Ar ôl hynny, dylai gyrraedd y traciwr, lle bydd yn newid ei statws sawl gwaith: o "Kitchen" i "Packed". Ar yr un pryd, gall rhai dylanwadau allanol o'r rhyngwyneb Ariannwr neu'r Rheolwr Shift ddigwydd gyda'r archeb. Byddaf yn rhoi statws y gorchymyn gyda'u disgrifiad yn y tabl:
Mae'r cynllun ar gyfer newid statws archeb yn edrych fel hyn:
Mae statws yn newid rhwng systemau gwahanol. Ac yma nid yw'r traciwr yn system derfynol lle mae'r data ar gau. Rydym wedi gweld sawl dull posibl ar gyfer rhannu mewn achos o'r fath:
- Rydym yn canolbwyntio pob gweithred archeb mewn un gwasanaeth. Yn ein hachos ni, mae'r opsiwn hwn yn gofyn am ormod o wasanaeth i weithio gyda'r archeb. Pe byddem yn stopio arno, byddem yn cael yr ail fonolith. Ni fyddem yn datrys y broblem.
- Mae un system yn gwneud galwad i un arall. Mae'r ail opsiwn eisoes yn fwy diddorol. Ond gydag ef, mae cadwyni o alwadau yn bosibl (), mae cysylltedd y cydrannau yn uwch, mae'n anoddach ei reoli.
- Rydym yn trefnu digwyddiadau, ac mae pob gwasanaeth yn cyfathrebu ag un arall trwy'r digwyddiadau hyn. O ganlyniad, hwn oedd y trydydd opsiwn a ddewiswyd, yn ôl y mae pob gwasanaeth yn dechrau cyfnewid digwyddiadau â'i gilydd.
Roedd y ffaith ein bod wedi dewis y trydydd opsiwn yn golygu y byddai gan y traciwr ei gronfa ddata ei hun, ac ar gyfer pob newid yn y drefn, byddai'n anfon digwyddiad am hyn, y mae gwasanaethau eraill yn tanysgrifio iddo ac sydd hefyd yn disgyn i'r brif gronfa ddata. I wneud hyn, roedd angen rhywfaint o wasanaeth arnom a fyddai'n sicrhau bod negeseuon yn cael eu cyflwyno rhwng gwasanaethau.
Erbyn hynny, roedd gennym eisoes RabbitMQ yn y pentwr, a dyna pam y penderfyniad terfynol i'w ddefnyddio fel brocer negeseuon. Mae'r diagram yn dangos trawsnewidiad archeb o'r Ariannwr Bwyty trwy'r Traciwr, lle mae'n newid ei statws a'i arddangosiad ar ryngwyneb Gorchmynion y Rheolwr. DEWCH:
Archebu llwybr gam wrth gam
Mae'r llwybr archeb yn cychwyn yn un o'r gwasanaethau ffynhonnell archeb. Dyma Ariannwr y Bwyty:
- Wrth y ddesg dalu, mae'r archeb yn hollol barod, ac mae'n bryd ei anfon at y traciwr. Mae'r digwyddiad y mae'r traciwr yn tanysgrifio iddo yn cael ei daflu.
- Mae'r traciwr, gan dderbyn archeb drosto'i hun, yn ei arbed i'w gronfa ddata ei hun, gan wneud y digwyddiad yn “Orchymyn a Dderbynnir gan Tracker” a'i anfon i RMQ.
- Mae sawl triniwr eisoes wedi tanysgrifio i'r bws digwyddiad fesul archeb. I ni, mae'r un sy'n gwneud cydamseru â sylfaen monolithig yn bwysig.
- Mae'r triniwr yn derbyn digwyddiad, yn dewis data sy'n arwyddocaol iddo: yn ein hachos ni, dyma statws y gorchymyn "Derbyniwyd gan y Traciwr" ac mae'n diweddaru ei endid archeb yn y brif gronfa ddata.
Os oes angen archeb ar rywun o'r gorchmynion tabl monolithig, yna gallwch chi ei ddarllen oddi yno hefyd. Er enghraifft, mae angen hyn ar y rhyngwyneb Gorchmynion yn y Rheolwr Shift:
Gall pob gwasanaeth arall hefyd danysgrifio i archebu digwyddiadau o'r traciwr i'w defnyddio drostynt eu hunain.
Os ar ôl ychydig mae'r gorchymyn yn cael ei gymryd i mewn i waith, yna mae ei statws yn newid yn gyntaf yn ei gronfa ddata (cronfa ddata Tracker), ac yna bydd y digwyddiad "OrderIn Progress" yn cael ei gynhyrchu ar unwaith. Mae hefyd yn mynd i mewn i RMQ, o ble mae'n cael ei gydamseru mewn cronfa ddata monolithig a'i ddosbarthu i wasanaethau eraill. Efallai y bydd problemau amrywiol ar hyd y ffordd, gellir dod o hyd i fwy o fanylion amdanynt yn adroddiad Zhenya Peshkov .
Pensaernïaeth derfynol ar ôl newidiadau yn Auth and Tracker
Wrth grynhoi'r canlyniad canolradd: I ddechrau, cefais y syniad i bacio hanes naw mlynedd y system Dodo IS mewn un erthygl. Roeddwn i eisiau siarad yn gyflym ac yn syml am gamau esblygiad. Fodd bynnag, wrth eistedd i lawr am y deunydd, sylweddolais fod popeth yn llawer mwy cymhleth a diddorol nag y mae'n ymddangos.
Gan adlewyrchu ar fanteision (neu ddiffyg) deunydd o'r fath, deuthum i'r casgliad bod datblygiad parhaus yn amhosibl heb hanesion llawn digwyddiadau, ôl-sylliadau manwl a dadansoddiad o'm penderfyniadau yn y gorffennol.
Gobeithio ei fod yn ddefnyddiol ac yn ddiddorol i chi ddysgu am ein llwybr. Nawr rwy'n wynebu dewis pa ran o system Dodo IS i'w disgrifio yn yr erthygl nesaf: ysgrifennwch y sylwadau neu bleidlais.
Dim ond defnyddwyr cofrestredig all gymryd rhan yn yr arolwg. os gwelwch yn dda.
Pa ran o Dodo IS yr hoffech chi wybod amdani yn yr erthygl nesaf?
-
24,1%Monolith cynnar yn Dodo IS (2011-2015)14
-
24,1%Problemau cyntaf a'u hatebion (2015-2016)14
-
20,7%Llwybr ochr y cleient: ffasâd dros y sylfaen (2016-2017)12
-
36,2%Hanes gwir ficrowasanaethau (2018-2019)21
-
44,8%Llifio'r monolith yn llwyr a sefydlogi'r bensaernïaeth26
-
29,3%Ynglŷn â chynlluniau pellach ar gyfer datblygu'r system17
-
19,0%Dydw i ddim eisiau gwybod dim am Dodo IS11
Pleidleisiodd 58 o ddefnyddwyr. Ataliodd 6 o ddefnyddwyr.
Ffynhonnell: hab.com