Senarios defnyddio rhwyll gwasanaeth

Senarios defnyddio rhwyll gwasanaeth

Nodyn. traws.: Mae awdur yr erthygl hon (Luc Perkins) yn eiriolwr datblygwr yn y sefydliad CNCF, sy'n gartref i brosiectau Ffynhonnell Agored o'r fath fel Linkerd, SMI (Rhyngwyneb Rhwyll Gwasanaeth) a Kuma (gyda llaw, a ydych chi hefyd wedi meddwl pam mae Istio yn ddim ar y rhestr hon? .). Unwaith eto gan geisio dod â chymuned DevOps â gwell dealltwriaeth o'r hype ffasiynol o'r enw "rhwyll gwasanaeth", mae'n rhestru 16 o alluoedd nodweddiadol y mae atebion o'r fath yn eu darparu.

Heddiw rhwyll gwasanaeth - un o'r pynciau poethaf ym maes peirianneg meddalwedd (ac yn haeddiannol felly!). Rwy'n meddwl bod y dechnoleg hon yn hynod addawol a hoffwn ei gweld yn cael ei mabwysiadu'n eang (pan mae'n gwneud synnwyr, wrth gwrs). Fodd bynnag, mae'n dal i gael ei amgylchynu gan naws o ddirgelwch i'r rhan fwyaf o bobl. Ar yr un pryd, hyd yn oed y rhai sy'n adnabyddus gydag ef, mae'n aml yn anodd mynegi ei fanteision a beth yn union ydyw (gan gynnwys eich un chi mewn gwirionedd). Yn yr erthygl hon byddaf yn ceisio cywiro'r sefyllfa trwy restru amrywiol achosion defnydd "rhwyllau gwasanaeth"*.

* Nodyn transl.: yma ac ymhellach yn yr erthygl yn union bydd y cyfieithiad hwn (“rhwyll gwasanaeth”) yn cael ei ddefnyddio ar gyfer y rhwyll gwasanaeth tymor newydd.

Ond yn gyntaf hoffwn wneud ychydig o sylwadau:

  • Nid wyf erioed wedi gweithio gyda rhwyllau gwasanaeth nac yn eu defnyddio y tu allan i brosiectau a ddechreuwyd ar gyfer fy addysg fy hun. Ar y llaw arall, fi oedd yr un a ysgrifennodd griw o ddogfennaeth ar gyfer rhwyll gwasanaeth mewnol Twitter yn 2015 (nid oedd hyd yn oed yn cael ei alw'n "rhwyll gwasanaeth" bryd hynny) ac a gymerodd ran yn natblygiad y wefan a dogfennaeth ar gyfer Linkerd, felly mae hynny'n golygu rhywbeth.
  • Mae fy rhestr yn fras ac yn anghyflawn. Mae’n bosibl iawn y bydd achosion defnydd nad ydynt yn hysbys i mi, ac mae’n debygol y bydd opsiynau newydd yn codi dros amser wrth i’r dechnoleg ddatblygu a’i phoblogrwydd dyfu.
  • Ar yr un pryd, nid yw pob gweithrediad rhwyll gwasanaeth presennol yn cefnogi pob un o'r achosion defnydd rhestredig. Felly, dylid darllen fy natganiadau fel “gall rhwyll gwasanaeth...” fel “unigol, ac efallai y gall pob gweithrediad rhwyll gwasanaeth poblogaidd….”.
  • Nid yw trefn yr enghreifftiau yn gwneud unrhyw wahaniaeth.

Rhestr fer:

  • darganfod gwasanaeth;
  • amgryptio;
  • dilysu ac awdurdodi;
  • cydbwyso llwyth;
  • torri cylched;
  • awtoscaling;
  • lleoli caneri;
  • gosodiadau glaswyrdd;
  • archwiliad iechyd;
  • colli llwyth;
  • adlewyrchu traffig;
  • inswleiddio;
  • cyfyngu ar gyfraddau ceisiadau, ailgynigion a seibiannau;
  • telemetreg;
  • archwilio;
  • delweddu.

1. Darganfod gwasanaeth

TL; DR: Cysylltwch â gwasanaethau eraill ar y rhwydwaith gan ddefnyddio enwau syml.

Dylai gwasanaethau allu “canfod” ei gilydd yn awtomatig gan ddefnyddio enwau digonol - er enghraifft, service.api.production, pets/staging neu cassandra. Mae amgylcheddau cwmwl yn elastig, a gall un enw guddio sawl enghraifft o wasanaeth. Mae'n amlwg mewn sefyllfa o'r fath ei bod yn gorfforol amhosibl codio pob cyfeiriad IP.

Hefyd, pan fydd un gwasanaeth yn dod o hyd i wasanaeth arall, dylai allu anfon ceisiadau at y gwasanaeth hwnnw heb ofni y byddant yn y pen draw ar fewnbwn ei achos toredig. Mewn geiriau eraill, rhaid i rwyll y gwasanaeth fonitro iechyd pob achos gwasanaeth a chadw'r rhestr o westeion mor gyfredol â phosibl.

Mae pob rhwyll gwasanaeth yn gweithredu'r mecanwaith darganfod gwasanaeth yn wahanol. Ar hyn o bryd, y ffordd fwyaf cyffredin yw dirprwyo i brosesau allanol fel Kubernetes DNS. Yn y gorffennol ar Twitter defnyddiasom system enwi at y diben hwn Finagl. Yn ogystal, mae technoleg rhwyll gwasanaeth yn ei gwneud hi'n bosibl i fecanweithiau enwi arferol ddod i'r amlwg (er nad wyf eto wedi gweld unrhyw weithrediad SM gyda swyddogaeth o'r fath).

2. Amgryptio

TL; DR: Cael gwared ar draffig heb ei amgryptio rhwng gwasanaethau a gwneud y broses hon yn awtomataidd a graddadwy.

Mae'n braf gwybod na all ymosodwyr dreiddio i'ch rhwydwaith mewnol. Mae waliau tân yn gwneud gwaith gwych o hyn. Ond beth sy'n digwydd os yw haciwr yn mynd i mewn? A fydd yn gallu gwneud beth bynnag y mae ei eisiau gyda thraffig o fewn y gwasanaeth? Gobeithio na fydd hyn yn digwydd wedi'r cyfan. Er mwyn atal y senario hwn, dylech weithredu rhwydwaith dim ymddiriedaeth lle mae'r holl draffig rhwng gwasanaethau wedi'i amgryptio. Mae'r rhan fwyaf o rwyllau gwasanaeth modern yn cyflawni hyn trwy gydfuddiannol TLS (TLS ar y cyd, mTLS). Mewn rhai achosion, mae mTLS yn gweithio mewn cymylau a chlystyrau cyfan (dwi'n meddwl y bydd cyfathrebiadau rhyngblanedol yn cael eu trefnu yn yr un modd ryw ddydd).

Wrth gwrs, ar gyfer rhwyll gwasanaeth mTLS dewisol. Gall pob gwasanaeth ofalu am ei TLS ei hun, ond mae hyn yn golygu y bydd angen i chi ddod o hyd i ffordd i gynhyrchu tystysgrifau, eu dosbarthu ar draws gwesteiwyr gwasanaeth, a chynnwys cod yn y rhaglen a fydd yn llwytho'r tystysgrifau hyn o ffeiliau. Oes, peidiwch ag anghofio adnewyddu'r tystysgrifau hyn yn rheolaidd. Mae rhwyllau gwasanaeth yn awtomeiddio mTLS gyda systemau fel SPIFFE, sydd, yn ei dro, yn awtomeiddio'r broses o gyhoeddi a chylchdroi tystysgrifau.

3. Dilysu ac Awdurdodi

TL; DR: Sefydlu pwy yw'r ymgeisydd a diffinio'r hyn y caniateir iddo ei wneud cyn i'r cais gyrraedd y gwasanaeth hyd yn oed.

Yn aml mae gwasanaethau eisiau gwybod sy'n yn perfformio'r cais (dilysu), a chan ddefnyddio'r wybodaeth hon, yn penderfynu y caniateir i endid penodol wneud (awdurdodi). Yn yr achos hwn, gall y rhagenw “pwy” guddio:

  1. Gwasanaethau eraill. Gelwir hyn yn "dilysu" cyfoed" Er enghraifft, gwasanaeth web eisiau cael mynediad i'r gwasanaeth db. Mae rhwyllau gwasanaeth fel arfer yn datrys problemau o'r fath gan ddefnyddio mTLS: mae tystysgrifau yn yr achos hwn yn gweithredu fel y dynodwr angenrheidiol.
  2. Rhai defnyddwyr dynol. Gelwir hyn yn "dilysu" cais" Er enghraifft, defnyddiwr haxor69 eisiau prynu lamp newydd. Mae rhwyllau gwasanaeth yn darparu amrywiol fecanweithiau, e.e. Tocynnau Gwe JSON.

    Mae llawer ohonom wedi gwneud hyn yn y cod cais. Daw cais i mewn, edrychwn trwy'r bwrdd users, darganfyddwch y defnyddiwr a chymharwch y cyfrinair, yna gwiriwch y golofn permissions etc. Yn achos rhwyll gwasanaeth, mae hyn yn digwydd cyn i'r cais gyrraedd y gwasanaeth hyd yn oed.

Unwaith y byddwn wedi sefydlu o bwy y daeth y cais, mae angen i ni benderfynu beth y caniateir i'r endid hwn ei wneud. Mae rhai rhwyllau gwasanaeth yn caniatáu ichi osod polisïau sylfaenol (am bwy all wneud beth) fel ffeiliau YAML neu ar y llinell orchymyn, tra bod eraill yn cynnig integreiddio â fframweithiau fel Agored Asiant Polisi. Y nod yn y pen draw yw i'ch gwasanaethau dderbyn unrhyw gais, gan dybio'n ddiogel ei fod yn dod o ffynhonnell ddibynadwy и caniateir y weithred hon.

4. Cydbwyso llwyth

TL; DR: Dosbarthwch y llwyth ar draws achosion gwasanaeth yn ôl patrwm penodol.

Mae “Gwasanaeth” o fewn adran gwasanaeth yn aml iawn yn cynnwys llawer o achosion union yr un fath. Er enghraifft, heddiw y gwasanaeth cache yn cynnwys 5 copi, ac yfory gall eu rhif gynyddu i 11. Anfonir ceisiadau i cache, rhaid ei ddosbarthu yn unol â phwrpas penodol. Er enghraifft, lleihau hwyrni neu wneud y mwyaf o'r tebygolrwydd o gyrraedd lleoliad gwaith. Yr algorithm a ddefnyddir amlaf yw Round-robin, ond mae llawer o rai eraill - er enghraifft, y dull pwysoli (pwysol) ymholiadau (gallwch ddewis y targedau a ffefrir), ffoniwch (canwch) stwnsio (gan ddefnyddio stwnsio cyson ar draws gwesteiwyr i fyny'r afon) neu'r dull cais lleiaf (rhoddir blaenoriaeth i'r enghraifft gyda'r nifer lleiaf o geisiadau).

Mae gan balancers clasurol swyddogaethau eraill, megis HTTP caching a diogelu DDoS, ond nid ydynt yn berthnasol iawn ar gyfer traffig dwyrain-gorllewin (hynny yw, ar gyfer traffig sy'n llifo o fewn canolfan ddata - tua. transl.) (cwmpas arferol y rhwyll gwasanaeth). Wrth gwrs, nid oes angen defnyddio rhwyll gwasanaeth ar gyfer cydbwyso llwyth, ond mae'n caniatáu ichi osod a rheoli polisïau cydbwyso ar gyfer pob gwasanaeth o haen reoli ganolog, a thrwy hynny ddileu'r angen i redeg a ffurfweddu balanswyr llwyth ar wahân yn y pentwr rhwydwaith. .

5. Torri cylched

TL; DR: Atal traffig i'r gwasanaeth problemus a rheoli'r difrod yn y senarios gwaethaf.

Os na all y gwasanaeth ymdopi â'r traffig am ryw reswm, mae'r rhwyll gwasanaeth yn darparu sawl opsiwn ar gyfer datrys y broblem hon (trafodir eraill yn yr adrannau priodol). Torri cylched yw'r opsiwn mwyaf difrifol ar gyfer datgysylltu gwasanaeth oddi wrth draffig. Fodd bynnag, ar ei ben ei hun nid yw'n gwneud synnwyr - mae angen cynllun wrth gefn. Gellir darparu pwysau cefn (backpressure) i wasanaethau sy'n gwneud ceisiadau (peidiwch ag anghofio ffurfweddu eich rhwyll gwasanaeth ar gyfer hyn!), neu, er enghraifft, lliwio'r dudalen statws yn goch ac ailgyfeirio defnyddwyr i fersiwn arall o'r dudalen gyda “morfil yn cwympo” (“Twitter is i lawr”).

Mae rhwyllau gwasanaeth nid yn unig yn caniatáu ichi ddiffinio pan bydd cau i lawr yn dilyn a y bydd hyn yn dilyn. Yn yr achos hwn, gall “pryd” gynnwys unrhyw gyfuniad o baramedrau penodedig: cyfanswm nifer y ceisiadau am gyfnod penodol, nifer y cysylltiadau cyfochrog, ceisiadau sydd ar y gweill, ailgynigion gweithredol, ac ati.

Mae'n debyg nad ydych chi eisiau cam-drin torri cylched, ond mae'n braf gwybod bod gennych chi gynllun wrth gefn rhag ofn y bydd argyfwng.

6. Autoscaling

TL; DR: Cynyddu neu leihau nifer yr achosion gwasanaeth yn dibynnu ar y meini prawf penodedig.

Nid yw rhwyllau gwasanaeth yn amserlenwyr, felly nid ydynt yn gwneud hynny cario allan graddio eich hun. Fodd bynnag, gallant ddarparu gwybodaeth ar ba gynllunwyr fydd yn seilio eu penderfyniadau. Gan fod gan rwyllau gwasanaeth fynediad at yr holl draffig rhwng gwasanaethau, mae ganddynt wybodaeth helaeth am yr hyn sy'n digwydd: pa wasanaethau sy'n cael problemau, pa wasanaethau sydd wedi'u llwytho'n ysgafn iawn (mae'r capasiti a ddyrennir iddynt yn cael ei wastraffu), ac ati.

Er enghraifft, mae Kubernetes yn graddio gwasanaethau yn seiliedig ar CPU codennau a defnydd cof (gweler ein hadroddiad "Graddio awtomatig a rheoli adnoddau yn Kubernetes" - tua. cyfieithu.), ond os penderfynwch raddfa yn seiliedig ar unrhyw fetrig arall (yn ein hachos ni, yn ymwneud â thraffig), bydd angen metrig arbennig arnoch. Rheolaeth fel hyn yn dangos sut i wneud hyn gyda Gennad, Istio и Prometheus, ond mae'r broses ei hun yn eithaf cymhleth. Hoffem i'r rhwyll gwasanaeth symleiddio hyn trwy ganiatáu i ni osod amodau fel “cynyddu nifer yr achosion gwasanaeth auth, os bydd nifer y ceisiadau sydd ar y gweill yn fwy na'r trothwy o fewn munud."

7. Gosodiadau Dedwydd

TL; DR: Profwch nodweddion newydd neu fersiynau gwasanaeth ar is-set o ddefnyddwyr.

Gadewch i ni ddweud eich bod yn datblygu cynnyrch SaaS ac yn bwriadu cyflwyno fersiwn newydd cŵl ohono. Fe wnaethoch chi ei brofi wrth lwyfannu ac fe weithiodd yn wych. Ond mae rhai pryderon o hyd am ei hymddygiad mewn amodau real. Mewn geiriau eraill, mae angen i chi brofi'r fersiwn newydd ar broblemau go iawn heb beryglu ymddiriedaeth defnyddwyr. Mae gosodiadau caneri yn wych ar gyfer hyn. Maent yn caniatáu ichi ddangos nodwedd newydd i is-set o ddefnyddwyr. Gall yr is-set hon gynnwys y defnyddwyr mwyaf ffyddlon neu'r rhai sy'n gweithio gyda'r fersiwn am ddim o'r cynnyrch, neu ddefnyddwyr sydd wedi mynegi awydd i fod yn “foch cwta”.

Mae rhwyllau gwasanaeth yn gweithredu hyn trwy ganiatáu i chi nodi meini prawf sy'n pennu pwy fydd yn gweld pa fersiwn o'r cais, a llwybro traffig yn unol â hynny. Fodd bynnag, nid oes dim yn newid i'r gwasanaethau eu hunain. Mae fersiwn 1.0 o'r gwasanaeth yn credu bod pob cais yn dod oddi wrth ddefnyddwyr a ddylai ei weld, ac mae fersiwn 1.1 yn credu'r un peth ar gyfer ei ddefnyddwyr. Yn y cyfamser, gallwch newid canran y traffig rhwng y fersiynau hen a newydd, gan ailgyfeirio nifer cynyddol o ddefnyddwyr i'r un newydd os yw'n gweithio'n sefydlog a bod eich “moch cwta” yn rhoi sêl bendith.

8. Gosodiadau glaswyrdd

TL; DR: Cyflwyno nodwedd newydd cŵl, ond byddwch yn barod i gymryd popeth yn ôl ar unwaith.

Ystyr gosodiadau glaswyrdd yw cyflwyno gwasanaeth “glas” newydd, gan ei lansio ochr yn ochr â'r hen un “gwyrdd”. Os aiff popeth yn esmwyth a bod y gwasanaeth newydd yn perfformio'n dda, yna gellir analluogi'r hen un yn raddol. (Ysywaeth, ryw ddydd bydd y gwasanaeth “glas” newydd hwn yn ailadrodd tynged yr un “gwyrdd” ac yn diflannu...) Mae gosodiadau gwyrddlas yn wahanol i rai caneri gan fod y swyddogaeth newydd yn cwmpasu pawb ar unwaith defnyddwyr (ddim yn rhan); Y pwynt yma yw cael “harbwr diogel” yn barod rhag ofn i rywbeth fynd o’i le.

Mae rhwyllau gwasanaeth yn cynnig ffordd gyfleus iawn o brofi gwasanaeth “glas” a newid ar unwaith i un “gwyrdd” gweithredol rhag ofn y bydd problemau. Heb sôn am y ffaith eu bod ar hyd y ffordd yn darparu llawer o wybodaeth (gweler “Telemetreg” isod) am waith y “glas”, sy'n helpu i ddeall a yw'n barod ar gyfer gweithrediad llawn.

Nodyn. traws.: Gallwch ddarllen mwy am wahanol strategaethau defnyddio yn Kubernetes (gan gynnwys y caneri a grybwyllwyd, glas / gwyrdd ac eraill) yn Mae'r erthygl hon yn.

9. Gwiriad iechyd

TL; DR: Cadwch olwg ar ba achosion gwasanaeth sy'n weithredol ac ymateb i'r rhai nad ydynt bellach yn weithredol.

Gwiriad iechyd (gwiriad iechyd) helpu i benderfynu a yw achosion gwasanaeth yn barod i dderbyn a phrosesu traffig. Er enghraifft, yn achos gwasanaethau HTTP, gallai gwiriad iechyd edrych fel cais GET i’r diweddbwynt /health... Ateb 200 OK yn golygu bod yr enghraifft yn iach, unrhyw un arall - nad yw'n barod i dderbyn traffig. Mae rhwyllau gwasanaeth yn eich galluogi i nodi'r ffordd y bydd ymarferoldeb yn cael ei wirio a pha mor aml y bydd y gwiriad hwn yn cael ei wneud. Yna gellir defnyddio'r wybodaeth hon at ddibenion eraill - er enghraifft, ar gyfer cydbwyso llwythi a thorri cylchedau.

Felly, nid yw gwirio iechyd yn achos defnydd annibynnol, ond fe'i defnyddir fel arfer i gyflawni nodau eraill. Hefyd, yn dibynnu ar ganlyniadau gwiriadau iechyd, efallai y bydd angen camau gweithredu y tu allan i dargedau rhwyll gwasanaeth eraill: er enghraifft, diweddaru'r dudalen statws, creu problem ar GitHub, neu lenwi tocyn JIRA. Ac mae rhwyll gwasanaeth yn cynnig mecanwaith cyfleus i awtomeiddio hyn i gyd.

10. Llwyth shedding

TL; DR: Ailgyfeirio traffig mewn ymateb i gynnydd dros dro yn y defnydd.

Os yw gwasanaeth penodol wedi'i orlwytho â thraffig, gallwch chi ailgyfeirio rhywfaint o'r traffig hwn dros dro i leoliad arall (hynny yw, “dympio”, “trosglwyddo” (sied) ef yno). Er enghraifft, i wasanaeth wrth gefn neu ganolfan ddata, neu i ganolfan barhaol wasg pwnc. O ganlyniad, bydd y gwasanaeth yn parhau i brosesu rhai ceisiadau yn lle chwalu a stopio prosesu popeth yn gyfan gwbl. Mae colli llwyth yn well na thorri'r gylched, ond nid yw'n ddoeth ei gam-drin o hyd. Mae'n helpu i atal methiannau rhaeadru sy'n achosi i wasanaethau i lawr yr afon chwalu.

11. Paraleleiddio/drychau traffig

TL; DR: Anfonwch un cais i sawl lle ar unwaith.

Weithiau mae angen anfon cais (neu ddetholiad penodol o geisiadau) i sawl gwasanaeth ar unwaith. Enghraifft nodweddiadol yw anfon rhan o draffig cynhyrchu i wasanaeth llwyfannu. Mae'r prif weinydd gwe cynhyrchu yn anfon cais i'r gwasanaeth i lawr yr afon products.production ac iddo ef yn unig. Ac mae'r rhwyll gwasanaeth yn copïo'r cais hwn yn ddeallus ac yn ei anfon ato products.staging, nad yw'r gweinydd gwe hyd yn oed yn ymwybodol ohono.

Achos defnydd rhwyll gwasanaeth cysylltiedig arall y gellir ei weithredu ar ben cyfochrogiad traffig yw profion atchweliad. Mae'n golygu anfon yr un ceisiadau i wahanol fersiynau o'r gwasanaeth a gwirio a yw pob fersiwn yn ymddwyn yr un fath. Nid wyf eto wedi dod ar draws gweithrediad rhwyll gwasanaeth gyda system profi atchweliad integredig fel Diffy, ond mae'r syniad ei hun yn ymddangos yn addawol.

12. Inswleiddio

TL; DR: Rhannwch eich rhwyll gwasanaeth yn rwydweithiau bach.

Adwaenir hefyd fel segmentuArwahanrwydd yw'r grefft o rannu rhwyll gwasanaeth yn segmentau rhesymegol ar wahân nad ydynt yn gwybod dim am ei gilydd. Mae ynysu ychydig fel creu rhwydweithiau preifat rhithwir. Y gwahaniaeth sylfaenol yw y gallwch chi barhau i fwynhau holl fanteision rhwyll gwasanaeth (fel darganfod gwasanaeth), ond gyda diogelwch ychwanegol. Er enghraifft, os yw ymosodwr yn gallu treiddio i wasanaeth ar un isrwyd, ni fydd yn gallu gweld pa wasanaethau sy'n rhedeg ar is-rwydweithiau eraill neu ryng-gipio eu traffig.

Yn ogystal, gall y buddion fod yn rhai sefydliadol hefyd. Efallai y byddwch am is-rwydweithio eich gwasanaethau yn seiliedig ar strwythur eich cwmni a lleddfu datblygwyr o'r llwyth gwybyddol o orfod cadw'r rhwyll gwasanaeth cyfan mewn cof.

13. Cyfyngu ar gyfradd ceisiadau, ail-geisio a seibiannau

TL; DR: Nid oes angen i chi bellach gynnwys y tasgau rheoli ceisiadau nitty-gritty yn eich sylfaen cod.

Gellid ystyried yr holl bethau hyn yn achosion defnydd ar wahân, ond penderfynais eu cyfuno oherwydd un nodwedd gyffredin: maen nhw'n cymryd drosodd y tasgau rheoli cylch bywyd ceisiadau sy'n cael eu trin fel arfer gan lyfrgelloedd cymwysiadau. Os ydych chi'n datblygu gweinydd gwe yn Ruby on Rails (nad yw wedi'i integreiddio â rhwyll gwasanaeth) sy'n gwneud ceisiadau i ôl-wneud gwasanaethau trwy gRPC, bydd yn rhaid i'r cais benderfynu beth i'w wneud os bydd ceisiadau N yn methu. Bydd yn rhaid i chi hefyd ddarganfod faint o draffig y bydd y gwasanaethau hyn yn gallu prosesu a chodio'r paramedrau hyn gan ddefnyddio llyfrgell arbennig. Hefyd, bydd yn rhaid i'r cais benderfynu pryd mae'n bryd rhoi'r gorau iddi a gadael i'r cais ddrysu (yn seiliedig ar amser terfyn). Ac er mwyn newid unrhyw un o'r paramedrau uchod, bydd yn rhaid atal y gweinydd gwe, ei ailgyflunio a'i ddechrau eto.

Mae dadlwytho'r tasgau hyn i rwyll gwasanaeth nid yn unig yn golygu na fydd yn rhaid i ddatblygwyr gwasanaeth feddwl amdanynt, ond hefyd y gellir eu gweld mewn ffordd fwy byd-eang. Os defnyddir cadwyn gymhleth o wasanaethau, dywedwch A -> B -> C -> D -> E, rhaid ystyried cylch bywyd cyfan y cais. Os mai'r dasg yw ymestyn y cyfnodau amser yng ngwasanaeth C, mae'n rhesymegol gwneud hyn i gyd ar unwaith, ac nid mewn rhannau: trwy ddiweddaru'r cod gwasanaeth ac aros nes bod y cais tynnu'n cael ei dderbyn a bod y system CI yn defnyddio'r gwasanaeth wedi'i ddiweddaru.

14. telemetreg

TL; DR: Casglwch yr holl wybodaeth angenrheidiol (ac nid yn union) gan wasanaethau.

Mae telemetreg yn derm cyffredinol sy'n cynnwys metrigau, olrhain dosranedig, a logiau. Mae rhwyllau gwasanaeth yn cynnig mecanweithiau ar gyfer casglu a phrosesu'r tri math o ddata. Dyma lle mae pethau'n mynd ychydig yn aneglur oherwydd bod nifer yr opsiynau posibl yn rhy fawr. I gasglu metrigau mae Prometheus ac offer eraill y gellir eu defnyddio i gasglu boncyffion rhugl, Loki, fector ac ati (er enghraifft ClickHouse gyda'n ty boncyff am K8s - tua. cyfieithu.), ar gyfer olrhain dosranedig mae Jaeger ac yn y blaen. Gall pob rhwyll gwasanaeth gefnogi rhai offer ac nid eraill. Bydd yn ddiddorol gweld a all y prosiect Telemetreg Agored darparu rhywfaint o gydgyfeirio.

Yn yr achos hwn, mantais technoleg rhwyll gwasanaeth yw y gall cynwysyddion ceir ochr, mewn egwyddor, gasglu'r holl ddata uchod o'u gwasanaethau. Mewn geiriau eraill, mae gennych un system casglu telemetreg ar gael ichi, a gall y rhwyll gwasanaeth brosesu'r holl wybodaeth hon mewn gwahanol ffyrdd. Er enghraifft:

  • boncyffion cynffon o wasanaeth penodol yn y CLI;
  • monitro nifer y ceisiadau o'r dangosfwrdd rhwyll gwasanaeth;
  • casglu olion dosbarthedig a'u hanfon ymlaen i system fel Jaeger.

Sylw, barn oddrychol: Yn gyffredinol, mae telemetreg yn faes lle mae ymyrraeth gref o'r rhwyll gwasanaeth yn annymunol. Mae casglu gwybodaeth sylfaenol ac olrhain rhai metrigau euraidd ar-y-hedfan fel cyfradd llwyddiant ceisiadau a hwyrni yn iawn, ond gadewch i ni obeithio na welwn staciau Frankenstein yn dod i'r amlwg sy'n ceisio disodli systemau arbenigol, y mae rhai ohonynt eisoes wedi profi eu hunain ac wedi'u hastudio'n dda. .

15. Archwilio

TL; DR: Mae'r rhai sy'n anghofio gwersi hanes yn sicr o'u hailadrodd.

Archwilio yw'r grefft o arsylwi digwyddiadau pwysig mewn system. Yn achos rhwyll gwasanaeth, gallai hyn olygu olrhain pwy wnaeth geisiadau i bwyntiau terfyn penodol ar gyfer gwasanaethau penodol, neu sawl gwaith y digwyddodd rhyw ddigwyddiad yn ymwneud â diogelwch yn ystod y mis diwethaf.

Mae'n amlwg bod gan archwilio gysylltiad agos iawn â thelemetreg. Y gwahaniaeth yw bod telemetreg fel arfer yn gysylltiedig â phethau fel cynhyrchiant a chywirdeb technegol, tra gall archwilio ymwneud â materion cyfreithiol a materion eraill sy'n mynd y tu hwnt i'r maes cwbl dechnegol (er enghraifft, cydymffurfio â GDPR - Rheoliad Cyffredinol yr UE ar ddiogelu data).

16. Rhagolwg

TL; DR: Long live React.js - ffynhonnell ddihysbydd o ryngwynebau ffansi.

Efallai bod term gwell, ond dydw i ddim yn ei wybod. Yn syml, rwy'n golygu cynrychiolaeth graffigol o rwyll gwasanaeth neu rai o'i gydrannau. Gall y delweddau hyn gynnwys dangosyddion fel cuddni cyfartalog, gwybodaeth ffurfweddu ceir ochr, canlyniadau gwiriad iechyd, a rhybuddion.

Mae gweithio mewn amgylchedd gwasanaeth-ganolog yn golygu llwyth gwybyddol llawer uwch o'i gymharu â'i Fawrhydi'r Monolith. Felly, dylid lleihau pwysau gwybyddol ar bob cyfrif. Gallai rhyngwyneb graffigol syml ar gyfer rhwyll gwasanaeth gyda'r gallu i glicio ar fotwm a chael y canlyniad a ddymunir fod yn bendant ar gyfer twf poblogrwydd y dechnoleg hon.

Heb eu cynnwys yn y rhestr

Yn wreiddiol roeddwn yn bwriadu cynnwys ychydig mwy o achosion defnydd yn y rhestr, ond penderfynais wedyn beidio. Dyma nhw, ynghyd â’r rhesymau dros fy mhenderfyniad:

  • Canolfan aml-ddata. Yn fy marn i, nid yw hwn yn gymaint o achos defnydd â maes cul a phenodol o gymhwyso rhwyllau gwasanaeth neu rai set o swyddogaethau fel darganfod gwasanaeth.
  • Mynd i mewn ac allan. Mae hwn yn faes cysylltiedig, ond rwyf wedi cyfyngu fy hun (efallai yn artiffisial) i'r achos defnydd "traffig dwyrain-gorllewin". Mae mynd i mewn ac allan yn haeddu erthygl ar wahân.

Casgliad

Dyna i gyd am y tro! Unwaith eto, mae'r rhestr hon yn fympwyol iawn ac yn fwyaf tebygol yn anghyflawn. Os ydych chi'n meddwl fy mod i wedi methu rhywbeth neu wedi cael rhywbeth o'i le, cysylltwch â mi ar Twitter (@luckerkins). Parchwch y rheolau gwedduster.

PS gan y cyfieithydd

Mae’r darluniad teitl ar gyfer yr erthygl yn seiliedig ar ddelwedd o’r erthygl “Beth yw Rhwyll Gwasanaeth (a phryd i ddefnyddio un)?" (gan Gregory MacKinnon). Mae'n dangos sut mae rhywfaint o ymarferoldeb o gymwysiadau (mewn gwyrdd) wedi symud i rwyll gwasanaeth sy'n darparu rhyng-gysylltiadau rhyngddynt (mewn glas).

Darllenwch hefyd ar ein blog:

Ffynhonnell: hab.com

Prynu gwesteio dibynadwy ar gyfer gwefannau sydd â diogelwch DDoS, gweinyddwyr VPS VDS 🔥 Prynu cynnal gwefannau dibynadwy gyda diogelwch DDoS, gweinyddion VPS VDS | ProHoster