Helo, habr. Mae cofrestru ar gyfer ffrwd cwrs newydd ar agor ar hyn o bryd yn OTUS . Ar drothwy dechrau'r cwrs, rwyf am rannu fy erthygl wreiddiol gyda chi.
Cyflwyniad
Mae'r dewis o arddull pensaernïol yn un o'r penderfyniadau technegol sylfaenol wrth adeiladu system wybodaeth. Yn y gyfres hon o erthyglau, rwy'n bwriadu dadansoddi'r arddulliau pensaernïol mwyaf poblogaidd ar gyfer ceisiadau adeiladu ac ateb y cwestiwn pryd pa arddull bensaernïol sydd fwyaf ffafriol. Yn y broses o gyflwyno, byddaf yn ceisio llunio cadwyn resymegol sy'n esbonio datblygiad arddulliau pensaernïol o fonolithau i ficrowasanaethau.
Tipyn o hanes
Os ceisiwch ofyn i ddatblygwyr: “Pam mae angen microwasanaethau arnom?”, fe gewch amrywiaeth o atebion. Byddwch yn clywed bod microservices yn gwella scalability, yn gwneud cod yn haws i'w ddeall, yn gwella goddefgarwch namau, ac weithiau byddwch yn clywed eu bod yn caniatáu ichi "lanhau'ch cod." Gadewch i ni edrych ar hanes i ddeall y pwrpas y tu ôl i ymddangosiad microwasanaethau.
Yn fyr, cododd microwasanaethau yn ein dealltwriaeth bresennol fel a ganlyn: yn 2011, tynnodd James Lewis, wrth ddadansoddi gwaith cwmnïau amrywiol, sylw at ymddangosiad patrwm “micro-app” newydd, a wnaeth optimeiddio SOA o ran cyflymu'r defnydd o gwasanaethau. Ychydig yn ddiweddarach, yn 2012, mewn uwchgynhadledd pensaernïaeth, ailenwyd y patrwm yn ficrowasanaeth. Felly, nod cychwynnol cyflwyno microwasanaethau oedd gwella'r drwg-enwog amser i farchnata.
Roedd microwasanaethau ar y don hype yn 2015. Yn ôl rhai astudiaethau, nid oedd un gynhadledd wedi'i chwblhau heb adroddiad ar bwnc microwasanaethau. At hynny, roedd rhai cynadleddau wedi'u neilltuo'n benodol i ficrowasanaethau. Y dyddiau hyn, mae llawer o brosiectau'n dechrau defnyddio'r arddull bensaernïol hon, ac os yw'r prosiect yn cynnwys tunnell o god etifeddiaeth, yna mae'n debyg bod mudo i ficrowasanaethau yn cael ei wneud yn weithredol.
Er gwaethaf yr uchod i gyd, mae nifer gweddol fach o ddatblygwyr yn dal i allu diffinio'r cysyniad o “microwasanaeth”. Ond byddwn yn siarad am hyn ychydig yn ddiweddarach ...
Monolith
Yr arddull bensaernïol sy'n cyferbynnu â microservices yw'r monolith (neu popeth-mewn-un). Mae'n debyg nad yw'n gwneud synnwyr i ddweud beth yw monolith, felly byddaf yn rhestru ar unwaith anfanteision yr arddull bensaernïol hon, a ysgogodd ddatblygiad pellach arddulliau pensaernïol: maint, cysylltedd, defnydd, scalability, dibynadwyedd ac anhyblygedd. Isod, cynigiaf edrych ar bob un o'r diffygion ar wahân.
Maint
Mae'r monolith yn fawr iawn. Ac fel arfer mae'n cyfathrebu â chronfa ddata fawr iawn. Mae'r cais yn mynd yn rhy fawr i un datblygwr ei ddeall o gwbl. Dim ond y rhai sydd wedi treulio llawer o amser yn gweithio ar y cod hwn all weithio'n dda gyda'r monolith, tra bydd dechreuwyr yn treulio llawer o amser yn ceisio darganfod y monolith ac nid oes unrhyw sicrwydd y byddant yn ei ddarganfod. Fel arfer, wrth weithio gyda monolith, mae yna bob amser uwch “amodol” sy'n adnabod y monolith fwy neu lai yn dda ac yn curo dwylo datblygwyr newydd eraill o fewn blwyddyn a hanner. Yn naturiol, mae uwch amodol o'r fath yn un pwynt methiant, a gall ei ymadawiad arwain at farwolaeth y monolith.
Cysylltedd
Mae'r monolith yn “belen fawr o fwd”, gall newidiadau ynddo arwain at ganlyniadau anrhagweladwy. Trwy wneud newidiadau mewn un lle, gallwch chi niweidio'r monolith mewn man arall (yr un peth “fe wnaethoch chi grafu'ch clust, syrthiodd *@”). Mae hyn oherwydd y ffaith bod gan y cydrannau yn y monolith berthynas gymhleth iawn ac, yn bwysicaf oll, nad ydynt yn amlwg.
Defnyddio
Mae defnyddio monolith, oherwydd y berthynas gymhleth rhwng ei gydrannau, yn broses hir gyda'i ddefod ei hun. Fel arfer nid yw defod o'r fath wedi'i safoni'n llwyr ac fe'i trosglwyddir “ar lafar.”
Scalability
Mae'n bosibl y bydd gan fodiwlau monolith anghenion adnoddau sy'n gwrthdaro, gan olygu bod angen cyfaddawdu o ran caledwedd. Dychmygwch fod gennych chi fonolith sy'n cynnwys gwasanaethau A a B. Mae gwasanaeth A yn feichus ar faint y gyriant caled, ac mae gwasanaeth B yn gofyn llawer ar RAM. Yn yr achos hwn, rhaid i'r peiriant y gosodir y monolith arno gefnogi gofynion y ddau wasanaeth, neu bydd yn rhaid i chi analluogi un o'r gwasanaethau yn artiffisial â llaw.
Enghraifft arall (mwy clasurol): mae gwasanaeth A yn llawer mwy poblogaidd na gwasanaeth B, felly rydych am gael 100 o wasanaethau A, a 10 gwasanaeth B. Unwaith eto, dau opsiwn: naill ai rydym yn defnyddio 100 o fonolithau llawn, neu ar rai wedyn bydd yn rhaid i wasanaethau B gael eu hanalluogi â llaw.
Dibynadwyedd
Gan fod yr holl wasanaethau wedi'u lleoli gyda'i gilydd, os bydd y monolith yn disgyn, yna mae pob gwasanaeth yn disgyn ar unwaith. Mewn gwirionedd, efallai na fydd hyn mor ddrwg, o leiaf ni fydd unrhyw fethiannau rhannol mewn system ddosbarthedig, ond ar y llaw arall, oherwydd nam mewn ymarferoldeb a ddefnyddir gan 0.001% o ddefnyddwyr, gallwch golli'r holl ddefnyddwyr o'ch system.
syrthni
Oherwydd maint y monolith, mae'n anodd newid i dechnolegau newydd. O ganlyniad, mae cadw'r un uwch hwnnw yn dasg ar wahân. Gall y pentwr technoleg a ddewisir ar ddechrau prosiect ddod yn floc sy'n rhwystro datblygiad y cynnyrch.
Casgliad
Y tro nesaf byddwn yn siarad am sut mae pobl wedi ceisio datrys y problemau hyn trwy symud i gydrannau a SOA.
Darllen mwy:
Ffynhonnell: hab.com