Neu mae pob cwmni anhapus â monolith yn anhapus yn ei ffordd ei hun.
Dechreuodd datblygiad system Dodo IS ar unwaith, fel y busnes Dodo Pizza, yn 2011. Roedd yn seiliedig ar y syniad o ddigideiddio prosesau busnes yn gyflawn ac yn gyfan gwbl, a , a achosodd hyd yn oed wedyn yn 2011 lawer o gwestiynau ac amheuaeth. Ond ers 9 mlynedd bellach rydym wedi bod yn dilyn y llwybr hwn - gyda'n datblygiad ein hunain, a ddechreuodd gyda monolith.
Mae’r erthygl hon yn “ateb” i’r cwestiynau “Pam ailysgrifennu’r bensaernïaeth a gwneud newidiadau mor fawr a hirdymor?” yn ôl i'r erthygl flaenorol . Dechreuaf gyda sut y dechreuodd datblygiad Dodo IS, sut olwg oedd ar y bensaernïaeth wreiddiol, sut roedd modiwlau newydd yn ymddangos, ac oherwydd pa broblemau yr oedd yn rhaid eu gwneud i wneud newidiadau mawr.
Cyfres o erthyglau "Beth yw Dodo IS?" yn dweud am:
-
Monolith cynnar yn Dodo IS (2011-2015). (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...)
Pensaernïaeth gychwynnol
Yn 2011, roedd pensaernïaeth Dodo IS yn edrych fel hyn:
Y modiwl cyntaf yn y bensaernïaeth yw derbyn archeb. Y broses fusnes oedd:
-
mae'r cleient yn galw'r pizzeria;
-
mae'r rheolwr yn codi'r ffôn;
-
yn derbyn archeb dros y ffôn;
-
yn ei llenwi yn gyfochrog yn y rhyngwyneb derbyn archeb: mae'n ystyried gwybodaeth am y cleient, data ar fanylion archeb, cyfeiriad dosbarthu.
Roedd rhyngwyneb y system wybodaeth yn edrych rhywbeth fel hyn ...
Fersiwn gyntaf o Hydref 2011:
Roedd adnoddau ar gyfer datblygu'r modiwl cymryd trefn gyntaf yn gyfyngedig. Roedd yn rhaid i ni wneud llawer, yn gyflym a gyda thîm bach. Tîm bach yw 2 ddatblygwr a osododd y sylfaen ar gyfer system gyfan y dyfodol.
Eu penderfyniad cyntaf oedd tynged y pentwr technoleg:
-
Ôl-ôl ar ASP.NET MVC, C# iaith. Roedd y datblygwyr yn dotnetchiki, roedd y pentwr hwn yn gyfarwydd ac yn ddymunol iddynt.
-
Frontend ar Bootstrap a JQuery: rhyngwynebau defnyddwyr ar arddulliau a sgriptiau hunan-ysgrifenedig.
-
Cronfa ddata MySQL: dim costau trwydded, hawdd ei defnyddio.
-
Gweinyddwyr ar Windows Server, oherwydd gallai .NET wedyn fod o dan Windows yn unig (ni fyddwn yn trafod Mono).
Yn gorfforol, mynegwyd hyn i gyd yn y “dedic at the hoster”.
Archebu Pensaernïaeth Cais Derbyn
Yna roedd pawb eisoes yn siarad am ficrowasanaethau, a defnyddiwyd SOA mewn prosiectau mawr am 5 mlynedd, er enghraifft, rhyddhawyd WCF yn 2006. Ond yna fe ddewison nhw ateb dibynadwy a phrofedig.
Dyma fo.
Asp.Net MVC yw Razor, sydd, ar gais gan ffurflen neu gan gleient, yn rendro tudalen HTML gyda rendrad gweinydd. Ar y cleient, mae sgriptiau CSS a JS eisoes yn dangos gwybodaeth ac, os oes angen, yn perfformio ceisiadau AJAX trwy JQuery.
Mae ceisiadau ar y gweinydd yn dod i ben yn y dosbarthiadau *Rheolwr, lle mae prosesu a chynhyrchu'r dudalen HTML derfynol yn digwydd yn y dull. Mae rheolwyr yn gwneud ceisiadau i haen o resymeg o'r enw *Gwasanaethau. Roedd pob un o’r gwasanaethau’n cyfateb i rai agweddau ar y busnes:
-
Er enghraifft, dosbarthodd DepartmentStructureService wybodaeth ar pizzerias, ar adrannau. Mae adran yn grŵp o pizzerias sy'n cael ei redeg gan un deiliad masnachfraint.
-
Derbyniodd a chyfrifodd ReceivingOrdersService gyfansoddiad yr archeb.
-
Ac anfonodd SmsService SMS trwy ffonio gwasanaethau API i anfon SMS.
Roedd gwasanaethau'n prosesu data o'r gronfa ddata, yn storio rhesymeg busnes. Roedd gan bob gwasanaeth un *Storfa neu fwy gyda'r enw priodol. Roeddent eisoes yn cynnwys ymholiadau i weithdrefnau storio yn y gronfa ddata a haen o fapwyr. Roedd rhesymeg fusnes yn y storfeydd, yn enwedig yn y rhai a gyhoeddodd ddata adrodd. Ni ddefnyddiwyd ORM, roedd pawb yn dibynnu ar sql wedi'i ysgrifennu â llaw.
Roedd yna hefyd haen o'r model parth a dosbarthiadau cynorthwywyr cyffredin, er enghraifft, y dosbarth Archeb a oedd yn storio'r archeb. Yn yr un lle, yn yr haen, roedd cynorthwyydd ar gyfer trosi'r testun arddangos yn ôl yr arian cyfred a ddewiswyd.
Gellir cynrychioli hyn i gyd gan fodel o'r fath:
Ffordd Gorchymyn
Ystyriwch ffordd gychwynnol symlach o greu gorchymyn o'r fath.
I ddechrau, roedd y safle'n statig. Roedd ganddo brisiau arno, ac ar ei ben - rhif ffôn a'r arysgrif "Os ydych chi eisiau pizza - ffoniwch y rhif a archebwch." I archebu, mae angen i ni weithredu llif syml:
-
Mae'r cleient yn ymweld â safle sefydlog gyda phrisiau, yn dewis cynhyrchion ac yn galw'r rhif a restrir ar y wefan.
-
Mae'r cwsmer yn enwi'r cynhyrchion y mae am eu hychwanegu at yr archeb.
-
Yn rhoi ei gyfeiriad a'i enw.
-
Mae'r gweithredwr yn derbyn y gorchymyn.
-
Mae'r gorchymyn yn cael ei arddangos yn y rhyngwyneb archebion a dderbynnir.
Mae'r cyfan yn dechrau gydag arddangos y ddewislen. Dim ond un archeb ar y tro y mae defnyddiwr-weithredwr sydd wedi mewngofnodi yn ei dderbyn. Felly, gellir storio'r drol drafft yn ei sesiwn (mae sesiwn y defnyddiwr yn cael ei storio yn y cof). Mae gwrthrych Cart sy'n cynnwys cynhyrchion a gwybodaeth cwsmeriaid.
Mae'r cwsmer yn enwi'r cynnyrch, mae'r gweithredwr yn clicio arno + wrth ymyl y cynnyrch, ac anfonir cais at y gweinydd. Mae gwybodaeth am y cynnyrch yn cael ei thynnu o'r gronfa ddata ac mae gwybodaeth am y cynnyrch yn cael ei hychwanegu at y drol.
Nodyn. Ydw, yma ni allwch dynnu'r cynnyrch o'r gronfa ddata, ond ei drosglwyddo o'r blaen. Ond er eglurder, dangosais yn union y llwybr o'r gronfa ddata.
Nesaf, nodwch gyfeiriad ac enw'r cleient.
Pan gliciwch ar "Creu Gorchymyn":
-
Anfonir y cais i OrderController.SaveOrder().
-
Rydyn ni'n cael Cart o'r sesiwn, mae yna gynhyrchion yn y maint sydd ei angen arnom.
-
Rydym yn ategu'r Cart gyda gwybodaeth am y cleient ac yn ei drosglwyddo i ddull AddOrder o'r dosbarth ReceivingOrderService, lle caiff ei gadw i'r gronfa ddata.
-
Mae gan y gronfa ddata dablau gyda'r gorchymyn, cyfansoddiad y gorchymyn, y cleient, ac maent i gyd yn gysylltiedig.
-
Mae'r rhyngwyneb arddangos archeb yn mynd ac yn tynnu'r archebion diweddaraf allan ac yn eu harddangos.
Modiwlau newydd
Roedd cymryd y drefn yn bwysig ac yn angenrheidiol. Ni allwch wneud busnes pizza os nad oes gennych orchymyn i werthu. Felly, dechreuodd y system gaffael ymarferoldeb - tua 2012 i 2015. Yn ystod y cyfnod hwn, ymddangosodd llawer o flociau gwahanol o'r system, y byddaf yn eu galw modiwlau, yn hytrach na'r cysyniad o wasanaeth neu gynnyrch.
Mae modiwl yn set o swyddogaethau sy'n cael eu huno gan ryw nod busnes cyffredin. Ar yr un pryd, maent yn gorfforol yn yr un cais.
Gellir galw modiwlau yn flociau system. Er enghraifft, modiwl adrodd yw hwn, rhyngwynebau gweinyddol, , awdurdodiad. Mae'r rhain i gyd yn rhyngwynebau defnyddwyr gwahanol, mae gan rai hyd yn oed arddulliau gweledol gwahanol. Ar yr un pryd, mae popeth o fewn fframwaith un cais, un broses redeg.
Yn dechnegol, cynlluniwyd y modiwlau fel Ardal (parhaodd syniad o'r fath ynddo hyd yn oed ). Roedd ffeiliau ar wahân ar gyfer y blaen, modelau, yn ogystal â'u dosbarthiadau rheoli eu hunain. O ganlyniad, trawsnewidiwyd y system o hyn ...
...i mewn i hyn:
Gweithredir rhai modiwlau gan safleoedd ar wahân (prosiect gweithredadwy), oherwydd swyddogaeth gwbl ar wahân ac yn rhannol oherwydd datblygiad ychydig ar wahân, â mwy o ffocws. hwn:
-
safle - safle dodopizza.ru.
-
Export: uwchlwytho adroddiadau o Dodo IS ar gyfer 1C.
-
Personol - cyfrif personol y gweithiwr. Fe'i datblygwyd ar wahân ac mae ganddo ei bwynt mynediad a'i ddyluniad ar wahân ei hun.
-
fs — prosiect ar gyfer cynnal statig. Yn ddiweddarach symudon ni oddi wrtho, gan symud yr holl statics i'r Akamai CDN.
Roedd gweddill y blociau yn y cais BackOffice.
Esboniad o'r enw:
-
Ariannwr - ariannwr bwyty.
-
ShiftManager - rhyngwynebau ar gyfer y "Rheolwr Shift" rôl: ystadegau gweithredol ar werthiannau pizzeria, y gallu i roi cynnyrch ar y rhestr stopio, newid y drefn.
-
OfficeManager - rhyngwynebau ar gyfer y rolau "Rheolwr Pizzeria" a "Rhyddfraint". Dyma swyddogaethau a gasglwyd ar gyfer sefydlu pizzeria, ei hyrwyddiadau bonws, derbyn a gweithio gyda gweithwyr, adroddiadau.
-
Sgriniau Cyhoeddus - rhyngwynebau ar gyfer setiau teledu a thabledi sy'n hongian mewn pizzerias. Mae setiau teledu'n dangos bwydlenni, gwybodaeth hysbysebu, statws archeb wrth ddosbarthu.
Roeddent yn defnyddio haen gwasanaeth cyffredin, bloc dosbarth parth cyffredin Dodo.Core, a sylfaen gyffredin. Weithiau gallent barhau i arwain y trawsnewidiadau i'w gilydd. Gan gynnwys safleoedd unigol, fel dodopizza.ru neu personal.dodopizza.ru, aeth i wasanaethau cyffredinol.
Pan ymddangosodd modiwlau newydd, ceisiwyd ailddefnyddio'r cod gwasanaethau a grëwyd eisoes, gweithdrefnau storio a thablau yn y gronfa ddata i'r eithaf.
I gael gwell dealltwriaeth o raddfa’r modiwlau a wneir yn y system, dyma ddiagram o 2012 gyda chynlluniau datblygu:
Erbyn 2015, roedd popeth ar y map ac roedd hyd yn oed mwy yn cael ei gynhyrchu.
-
Mae derbyn archeb wedi tyfu i fod yn floc ar wahân o'r Ganolfan Gyswllt, lle mae'r gorchymyn yn cael ei dderbyn gan y gweithredwr.
-
Roedd sgriniau cyhoeddus gyda bwydlenni a gwybodaeth yn hongian mewn pizzerias.
-
Mae gan y gegin fodiwl sy'n chwarae'r neges llais "Pizza Newydd" yn awtomatig pan fydd archeb newydd yn cyrraedd, a hefyd yn argraffu anfoneb ar gyfer y negesydd. Mae hyn yn symleiddio'r prosesau yn y gegin yn fawr, yn caniatáu i weithwyr beidio â chael eu tynnu sylw gan nifer fawr o weithrediadau syml.
-
Daeth yr uned ddosbarthu yn Desg Dalu Dosbarthu ar wahân, lle rhoddwyd yr archeb i'r negesydd a oedd wedi cymryd y sifft yn flaenorol. Cymerwyd ei amser gwaith i ystyriaeth ar gyfer cyfrifo'r gyflogres.
Ochr yn ochr, rhwng 2012 a 2015, ymddangosodd mwy na 10 o ddatblygwyr, agorodd 35 pizzeria, anfonwyd y system i Rwmania a pharatoi ar gyfer agor siopau yn yr Unol Daleithiau. Nid oedd y datblygwyr bellach yn delio â'r holl dasgau, ond fe'u rhannwyd yn dimau. roedd pob un yn arbenigo yn ei ran ei hun o'r system.
Problemau
Gan gynnwys oherwydd y bensaernïaeth (ond nid yn unig).
Anrhefn yn y gwaelod
Mae un sylfaen yn gyfleus. Gellir sicrhau cysondeb ynddo, ac ar draul offer sydd wedi'u cynnwys mewn cronfeydd data perthynol. Mae gweithio gydag ef yn gyfarwydd ac yn gyfleus, yn enwedig os nad oes llawer o dablau ac ychydig o ddata.
Ond dros 4 blynedd o ddatblygiad, roedd gan y gronfa ddata tua 600 o dablau, 1500 o weithdrefnau wedi'u storio, ac roedd gan lawer ohonynt resymeg hefyd. Ysywaeth, nid yw gweithdrefnau storio yn dod â llawer o fantais wrth weithio gyda MySQL. Nid ydynt yn cael eu storio gan y sylfaen, ac mae storio rhesymeg ynddynt yn cymhlethu datblygiad a dadfygio. Mae ailddefnyddio cod hefyd yn anodd.
Nid oedd gan lawer o dablau fynegeion addas, yn rhywle, i'r gwrthwyneb, roedd yna lawer o fynegeion, a oedd yn ei gwneud hi'n anodd eu mewnosod. Roedd angen addasu tua 20 tablau - gallai'r trafodiad i greu gorchymyn gymryd tua 3-5 eiliad.
Nid oedd y data yn y tablau bob amser yn y ffurf fwyaf priodol. Rhywle roedd angen gwneud dadnormaleiddio. Roedd rhan o'r data a dderbyniwyd yn rheolaidd mewn colofn ar ffurf strwythur XML, roedd hyn yn cynyddu'r amser gweithredu, yn ymestyn yr ymholiadau ac yn cymhlethu'r datblygiad.
I'r un byrddau a gynhyrchwyd iawn ceisiadau heterogenaidd. Roedd tablau poblogaidd yn dioddef yn arbennig, fel y tabl a grybwyllwyd uchod. gorchmynion neu fyrddau pizzeria. Fe'u defnyddiwyd i arddangos rhyngwynebau gweithredol yn y gegin, dadansoddeg. Cysylltodd safle arall â nhw (), lle gallai llawer o geisiadau ddod yn sydyn ar unrhyw adeg benodol.
Ni chafodd y data ei agregu a gwnaed llawer o gyfrifiadau ar y hedfan gan ddefnyddio'r sylfaen. Creodd hyn gyfrifiadau diangen a llwyth ychwanegol.
Yn aml, roedd y cod yn mynd i'r gronfa ddata pan na allai fod wedi gwneud hynny. Yn rhywle nad oedd digon o weithrediadau swmp, yn rhywle byddai angen lledaenu un cais i sawl un trwy'r cod er mwyn cyflymu a chynyddu dibynadwyedd.
Cydlyniad a rhwystredigaeth yn y cod
Nid oedd modiwlau a oedd i fod i fod yn gyfrifol am eu rhan nhw o'r busnes yn ei wneud yn onest. Roedd gan rai ohonynt ddyblygu swyddogaethau ar gyfer rolau. Er enghraifft, roedd yn rhaid i farchnatwr lleol sy'n gyfrifol am weithgaredd marchnata'r rhwydwaith yn ei ddinas ddefnyddio'r rhyngwyneb "Gweinyddol" (i greu hyrwyddiadau) a'r rhyngwyneb "Rheolwr Swyddfa" (i weld effaith hyrwyddiadau ar y busnes). Wrth gwrs, roedd y tu mewn i'r ddau fodiwl yn defnyddio'r un gwasanaeth a oedd yn gweithio gyda hyrwyddiadau bonws.
Gallai gwasanaethau (dosbarthiadau o fewn un prosiect mawr monolithig) alw ar ei gilydd i gyfoethogi eu data.
Gyda'r dosbarthiadau model eu hunain sy'n storio data, roedd gwaith yn y cod yn cael ei wneud yn wahanol. Yn rhywle roedd adeiladwyr lle'r oedd modd nodi meysydd gofynnol. Yn rhywle gwnaed hyn trwy eiddo cyhoeddus. Wrth gwrs, roedd cael a thrawsnewid data o'r gronfa ddata yn amrywiol.
Roedd y rhesymeg naill ai yn y rheolwyr neu yn y dosbarthiadau gwasanaeth.
Mae'n ymddangos mai mân faterion yw'r rhain, ond fe wnaethant arafu datblygiad yn fawr a lleihau ansawdd, gan arwain at ansefydlogrwydd a chwilod.
Cymhlethdod datblygiad mawr
Cododd anawsterau yn y datblygiad ei hun. Roedd angen gwneud gwahanol flociau o'r system, ac yn gyfochrog. Daeth yn fwyfwy anodd gosod anghenion pob cydran mewn un cod. Nid oedd yn hawdd cytuno a phlesio'r holl gydrannau ar yr un pryd. Yn ychwanegol at hyn roedd cyfyngiadau mewn technoleg, yn enwedig o ran y gwaelod a'r blaen. Roedd angen rhoi'r gorau i jQuery tuag at fframweithiau lefel uchel, yn enwedig o ran gwasanaethau cleient (gwefan).
Mewn rhai rhannau o'r system, gellid defnyddio cronfeydd data mwy addas ar gyfer hyn.. Er enghraifft, yn ddiweddarach cawsom yr achos defnydd o symud o Redis i CosmosDB i storio basged archeb.
Roedd yn amlwg bod timau a datblygwyr sy'n ymwneud â'u maes eisiau mwy o ymreolaeth i'w gwasanaethau, o ran datblygu a chyflwyno. Cyfuno gwrthdaro, materion rhyddhau. Os yw'r broblem hon yn ddibwys i 5 datblygwr, yna gyda 10, a hyd yn oed yn fwy felly gyda'r twf arfaethedig, byddai popeth yn dod yn fwy difrifol. Ac ar y blaen oedd datblygu cymhwysiad symudol (cychwynnodd yn 2017, ac yn 2018 roedd yn ).
Roedd angen lefelau gwahanol o sefydlogrwydd ar wahanol rannau o'r system, ond oherwydd cysylltedd cryf y system, ni allem ddarparu hyn. Gallai gwall wrth ddatblygu swyddogaeth newydd yn y panel gweinyddol fod wedi digwydd wrth dderbyn archeb ar y wefan, oherwydd bod y cod yn gyffredin ac yn ailddefnyddiadwy, mae'r gronfa ddata a'r data hefyd yr un peth.
Mae'n debyg y byddai'n bosibl osgoi'r camgymeriadau a'r problemau hyn o fewn fframwaith pensaernïaeth monolithig-modiwlaidd o'r fath: gwneud rhaniad cyfrifoldeb, ailffactorio'r cod a'r gronfa ddata, gwahanu'r haenau oddi wrth ei gilydd yn glir, a monitro'r ansawdd bob dydd. . Ond arweiniodd yr atebion pensaernïol a ddewiswyd a'r ffocws ar ehangu ymarferoldeb y system yn gyflym at broblemau o ran sefydlogrwydd.
Sut mae blog Power of the Mind yn rhoi'r cofrestrau arian parod mewn bwytai
Pe bai twf y rhwydwaith pizzeria (a llwyth) yn parhau ar yr un cyflymder, yna ar ôl ychydig byddai'r cwympiadau yn golygu na fyddai'r system yn codi. Wel yn dangos y problemau y dechreuon ni eu hwynebu erbyn 2015, dyma stori o'r fath.
Yn y blog "” yn widget a oedd yn dangos data ar refeniw ar gyfer blwyddyn y rhwydwaith cyfan. Mae'r teclyn wedi cyrchu API cyhoeddus Dodo, sy'n darparu'r data hwn. Mae'r ystadegyn hwn ar gael ar hyn o bryd yn . Roedd y teclyn yn cael ei ddangos ar bob tudalen ac yn gwneud ceisiadau ar amserydd bob 20 eiliad. Aeth y cais i api.dodopizza.ru a gofynnodd:
-
nifer y pizzerias yn y rhwydwaith;
-
cyfanswm refeniw rhwydwaith ers dechrau'r flwyddyn;
-
refeniw ar gyfer heddiw.
Aeth y cais am ystadegau ar refeniw yn syth i'r gronfa ddata a dechrau gofyn am ddata ar archebion, agregu data ar y hedfan a dosbarthu'r swm.
Aeth desgiau arian parod mewn bwytai i'r un tabl archebion, dadlwytho rhestr o orchmynion a dderbyniwyd ar gyfer heddiw, ac ychwanegwyd archebion newydd ato. Roedd cofrestrau arian parod yn gwneud eu ceisiadau bob 5 eiliad neu ar adnewyddu tudalennau.
Roedd y diagram yn edrych fel hyn:
Un cwymp, ysgrifennodd Fyodor Ovchinnikov erthygl hir a phoblogaidd ar ei blog. Daeth llawer o bobl i'r blog a dechrau darllen popeth yn ofalus. Tra bod pob un o'r bobl a ddaeth yn darllen yr erthygl, roedd y teclyn refeniw yn gweithio'n iawn ac yn gofyn am yr API bob 20 eiliad.
Galwodd yr API weithdrefn storio i gyfrifo swm yr holl archebion ers dechrau'r flwyddyn ar gyfer pob pizzeria yn y gadwyn. Roedd y cyfanred yn seiliedig ar y tabl archebion, sy'n boblogaidd iawn. Mae holl ddesgiau arian parod yr holl fwytai agored ar y pryd yn mynd iddo. Peidiodd desgiau arian ag ymateb, ni dderbyniwyd archebion. Ni chawsant eu derbyn hefyd o'r wefan, nid oeddent yn ymddangos ar y traciwr, ni allai'r rheolwr shifft eu gweld yn ei ryngwyneb.
Nid dyma'r unig stori. Erbyn cwymp 2015, bob dydd Gwener roedd y llwyth ar y system yn hollbwysig. Sawl gwaith fe wnaethom ddiffodd yr API cyhoeddus, ac unwaith, bu'n rhaid i ni hyd yn oed ddiffodd y wefan, oherwydd nid oedd unrhyw beth wedi helpu. Roedd hyd yn oed restr o wasanaethau gyda gorchymyn cau o dan lwythi trwm.
O hyn ymlaen, mae ein brwydr gyda llwythi ac ar gyfer sefydlogi'r system yn dechrau (o hydref 2015 i hydref 2018). Dyna pryd y digwyddodd"" . Ymhellach, digwyddodd methiannau weithiau hefyd, roedd rhai yn sensitif iawn, ond bellach gellir ystyried bod y cyfnod cyffredinol o ansefydlogrwydd wedi mynd heibio.
Twf busnes cyflym
Pam na ellid ei wneud ar unwaith? Edrychwch ar y siartiau canlynol.
Hefyd yn 2014-2015 roedd agoriad yn Rwmania ac roedd agoriad yn yr UDA yn cael ei baratoi.
Tyfodd y rhwydwaith yn gyflym iawn, agorwyd gwledydd newydd, ymddangosodd fformatau newydd o pizzerias, er enghraifft, agorwyd pizzeria yn y llys bwyd. Roedd hyn oll yn gofyn am sylw sylweddol yn benodol i ehangu swyddogaethau Dodo IS. Heb yr holl swyddogaethau hyn, heb olrhain yn y gegin, cyfrif am gynhyrchion a cholledion yn y system, gan arddangos cyhoeddi gorchymyn yn neuadd y llys bwyd, prin y byddem yn siarad am y bensaernïaeth “gywir” a'r agwedd “gywir” tuag at hynny. datblygiad nawr.
Rhwystr arall i adolygu’r bensaernïaeth yn amserol a rhoi sylw cyffredinol i broblemau technegol oedd argyfwng 2014. Mae pethau fel hyn yn taro'n galed ar gyfleoedd i dimau dyfu, yn enwedig i fusnes ifanc fel Dodo Pizza.
Atebion Cyflym a Helpodd
Problemau angen atebion. Yn gonfensiynol, gellir rhannu atebion yn 2 grŵp:
-
Rhai cyflym sy'n diffodd y tân ac yn rhoi ymyl diogelwch bach ac yn prynu amser i ni newid.
-
Systemig ac, felly, hir. Ail-lunio nifer o fodiwlau, rhannu pensaernïaeth monolithig yn wasanaethau ar wahân (nid gwasanaethau micro yw'r rhan fwyaf ohonynt o gwbl, ond yn hytrach gwasanaethau macro, ac mae rhywbeth yn ei gylch ).
Mae'r rhestr sych o newidiadau cyflym fel a ganlyn:
Graddio i fyny meistr sylfaen
Wrth gwrs, y peth cyntaf sy'n cael ei wneud i ddelio â llwythi yw cynyddu gallu'r gweinydd. Gwnaethpwyd hyn ar gyfer y brif gronfa ddata ac ar gyfer gweinyddwyr gwe. Ysywaeth, dim ond hyd at derfyn penodol y mae hyn yn bosibl, yna mae'n mynd yn rhy ddrud.
Ers 2014, rydym wedi symud i Azure, fe wnaethom hefyd ysgrifennu am y pwnc hwn bryd hynny yn yr erthygl “" . Ond ar ôl cyfres o gynnydd yn y gweinydd ar gyfer y sylfaen, daethant i fyny yn erbyn y gost.
Atgynyrchiadau sylfaenol ar gyfer darllen
Gwnaethpwyd dau atgynhyrchiad ar gyfer y sylfaen:
DarllenReplica ar gyfer ceisiadau geirda. Fe'i defnyddir i ddarllen cyfeiriaduron, math, dinas, stryd, pizzeria, cynhyrchion (parth sydd wedi'i newid yn araf), ac yn y rhyngwynebau hynny lle mae oedi bach yn dderbyniol. Roedd 2 o'r atgynyrchiadau hyn, gwnaethom sicrhau eu bod ar gael yn yr un modd â'r meistri.
Darllenwch Replica ar gyfer Ceisiadau Adroddiad. Roedd argaeledd y gronfa ddata hon yn is, ond aeth pob adroddiad ati. Gadewch iddynt gael ceisiadau trwm am ailgyfrifiadau data enfawr, ond nid ydynt yn effeithio ar y brif gronfa ddata a rhyngwynebau gweithredol.
Caches yn y cod
Nid oedd unrhyw caches yn unrhyw le yn y cod (o gwbl). Arweiniodd hyn at geisiadau ychwanegol, nad oedd bob amser yn angenrheidiol, i'r gronfa ddata wedi'i llwytho. Roedd caches yn gyntaf er cof ac ar wasanaeth storfa allanol, hynny oedd Redis. Roedd popeth wedi'i annilysu gan amser, roedd y gosodiadau wedi'u nodi yn y cod.
Gweinyddion backend lluosog
Roedd angen graddio cefndir y cais hefyd i ymdrin â'r llwythi gwaith cynyddol. Yr oedd yn rhaid gwneyd clwstwr o un iis-weinydd. Rydym wedi aildrefnu o'r cof i RedisCache, a oedd yn ei gwneud hi'n bosibl gwneud sawl gweinydd y tu ôl i balancer llwyth syml gyda robin crwn. Ar y dechrau, defnyddiwyd yr un Redis ag ar gyfer caches, yna cafodd ei rannu'n sawl un.
O ganlyniad, mae'r bensaernïaeth wedi dod yn fwy cymhleth ...
… ond dilëwyd peth o'r tensiwn.
Ac yna roedd angen ail-wneud y cydrannau wedi'u llwytho, a wnaethom. Byddwn yn siarad am hyn yn y rhan nesaf.
Ffynhonnell: hab.com