🥇 Notkunartilvik fyrir þjónustunet

Athugið. þýð.: Höfundur þessarar greinar (Luc Perkins) er talsmaður þróunaraðila hjá CNCF stofnuninni, sem er heimili slíkra Open Source verkefna eins og Linkerd, SMI (Service Mesh Interface) og Kuma (við the vegur, hefur þú líka velt því fyrir þér hvers vegna Istio er ekki á þessum lista? .). Enn og aftur reynir hann að færa DevOps samfélagið betri skilning á töff hype sem kallast „þjónustunet“, hann telur upp 16 einkennandi eiginleika sem slíkar lausnir veita.

Í dag þjónustunet ― eitt heitasta viðfangsefnið á sviði hugbúnaðarverkfræði (og með réttu!). Ég held að þessi tækni sé ótrúlega efnileg og myndi vilja sjá hana almennt tekið upp (þegar það er skynsamlegt, auðvitað). Hins vegar er það enn umkringt dulúð fyrir flesta. Á sama tíma, jafnvel þeir sem vel þekkt með því er oft erfitt að koma á framfæri kostum þess og hvað það er nákvæmlega (þar á meðal þinn satt). Í þessari grein mun ég reyna að leiðrétta ástandið með því að telja upp ýmislegt notkunartilvik „þjónustunet“*.

* Athugið þýðing: hér og lengra í greininni verður einmitt þessi þýðing („þjónustunet“) notuð fyrir hið enn nýja hugtak þjónustunet.

En fyrst vil ég gera nokkrar athugasemdir:

Ég hef aldrei unnið með þjónustumöskva eða notað þá utan verkefna sem byrjað var fyrir eigin menntun. Aftur á móti var ég sá sem skrifaði fullt af skjölum fyrir innri þjónustunet Twitter árið 2015 (það var ekki einu sinni kallað "þjónustunet" þá) og tók þátt í þróun vefsíðunnar og skjöl fyrir Linkerd, svo það þýðir eitthvað.
Listinn minn er áætlaður og ófullnægjandi. Það geta vel verið notkunartilvik sem mér eru óþekkt og nýir möguleikar munu líklega koma upp með tímanum eftir því sem tæknin þróast og vinsældir hennar aukast.
Á sama tíma styður ekki öll núverandi útfærsla á þjónustumöskvum öllum tilfellum sem skráð eru. Þess vegna ætti að lesa fullyrðingar mínar eins og „þjónustumöskva...“ sem „einstaklingar og kannski allar vinsælar útfærslur á þjónustumöskvum geta...“.
Röð dæmanna breytir engu.

Stutt listi:

þjónustuuppgötvun;
dulkóðun;
auðkenning og heimild;
álagsjafnvægi;
hringrás rof;
sjálfvirk stærð;
kanaríflugur;
blágrænar dreifingar;
heilsufarsskoðun;
álagslosun;
umferðarspeglun;
einangrun;
biðja um takmörkun á hraða, endurtilraunir og tímamörk;
fjarmæling;
endurskoðun;
sjónræning.

1. Þjónustuuppgötvun

TL;DR: Tengstu öðrum þjónustum á netinu með einföldum nöfnum.

Þjónusta ætti sjálfkrafa að geta „finnst“ hver aðra með því að nota viðeigandi nöfn - td, service.api.production, pets/staging eða cassandra. Skýumhverfi er teygjanlegt og eitt nafn getur falið mörg tilvik þjónustu. Það er ljóst að við slíkar aðstæður er líkamlega ómögulegt að harðkóða allar IP tölur.

Auk þess, þegar ein þjónusta finnur aðra, ætti hún að geta sent beiðnir til þeirrar þjónustu án þess að óttast að þær endi við inntak á brotnu tilviki hennar. Með öðrum orðum, þjónustunetið verður að fylgjast með heilsu allra þjónustutilvika og halda lista yfir gestgjafa eins uppfærðan og hægt er.

Hvert þjónustunet útfærir þjónustuuppgötvunarkerfi á annan hátt. Sem stendur er algengasta leiðin að úthluta til ytri ferla eins og Kubernetes DNS. Áður á Twitter notuðum við nafnakerfi í þessum tilgangi Finagle. Að auki gerir þjónustunetstækni það mögulegt fyrir sérsniðnar nafngiftir að koma fram (þó ég hafi ekki enn séð neina SM útfærslu með slíkri virkni).

2. Dulkóðun

TL;DR: Losaðu þig við ódulkóðaða umferð milli þjónustu og gerðu þetta ferli sjálfvirkt og skalanlegt.

Það er gaman að vita að árásarmenn komast ekki inn í innra netið þitt. Eldveggir gera þetta frábært starf. En hvað gerist ef tölvuþrjótur kemst inn? Mun hann geta gert hvað sem hann vill við umferð innan þjónustunnar? Við skulum vona að þetta gerist ekki eftir allt saman. Til að koma í veg fyrir þessa atburðarás ættir þú að innleiða núlltraust net þar sem öll umferð milli þjónustu er dulkóðuð. Flest nútíma þjónustunet ná þessu með gagnkvæmu TLS (gagnkvæm TLS, mTLS). Í sumum tilfellum virkar mTLS í heilum skýjum og þyrpingum (ég held að samskiptum milli pláneta verði einhvern tíma hagað á svipaðan hátt).

Auðvitað, fyrir mTLS þjónustunet valfrjálst. Hver þjónusta getur séð um sitt eigið TLS, en þetta þýðir að þú þarft að finna leið til að búa til vottorð, dreifa þeim á milli þjónustuhýsinga og setja kóða inn í forritið sem mun hlaða þessum skírteinum úr skrám. Já, ekki gleyma að endurnýja þessi skírteini með reglulegu millibili. Þjónustunet gera mTLS sjálfvirkan með kerfum eins og SPIFFE, sem aftur á móti gera sjálfvirkan ferli við útgáfu og skiptingu skírteina.

3. Auðkenning og heimild

TL;DR: Staðfestu hver umsækjandinn er og skilgreindu hvað þeim er heimilt að gera áður en beiðnin berst jafnvel þjónustuna.

Þjónusta vill oft vita hver framkvæmir beiðnina (staðfesting), og með því að nota þessar upplýsingar, ákveður að tilteknum aðila er heimilt að gera (heimild). Í þessu tilviki getur fornafnið „hver“ falið:

Önnur þjónusta. Þetta er kallað „auðkenning“ jafningi" Til dæmis þjónustu web vill fá aðgang að þjónustunni db. Þjónustunet leysa venjulega slík vandamál með því að nota mTLS: vottorð í þessu tilfelli virka sem nauðsynleg auðkenni.
Sumir mannlegir notendur. Þetta er kallað „auðkenning“ beiðni" Til dæmis notandi haxor69 vill kaupa nýjan lampa. Þjónustunet veita ýmsar aðferðir, t.d. JSON vefseðlar.
Mörg okkar hafa gert þetta í forritakóða. Beiðni kemur inn, við skoðum töfluna users, finndu notandann og berðu saman lykilorðið og athugaðu síðan dálkinn permissions o.s.frv. Ef um er að ræða þjónustunet, gerist þetta áður en beiðnin berst jafnvel þjónustunni.

Þegar við höfum staðfest frá hverjum beiðnin kom, þurfum við að ákvarða hvað þessi aðili hefur leyfi til að gera. Sum þjónustunet gera þér kleift að stilla grunnreglur (um hver má gera hvað) sem YAML skrár eða á skipanalínunni, á meðan önnur bjóða upp á samþættingu við ramma eins og Opna stefnumiðlara. Lokamarkmiðið er að þjónusta þín samþykki hvaða beiðni sem er, að því gefnu að hún komi frá traustum aðilum и þessi aðgerð er leyfð.

4. Álagsjöfnun

TL;DR: Dreifðu álaginu yfir þjónustutilvik í samræmi við ákveðið mynstur.

„Þjónusta“ innan þjónustuhluta samanstendur mjög oft af mörgum eins tilfellum. Til dæmis, í dag þjónustan cache samanstendur af 5 eintökum og á morgun gæti fjöldi þeirra aukist í 11. Beiðnir sendar á cache, verður að dreifa í samræmi við ákveðinn tilgang. Til dæmis, lágmarka leynd eða hámarka líkurnar á að komast í starfandi tilvik. Algengasta reikniritið er Round-robin, en það eru margir aðrir - til dæmis vegin aðferð (vegið) fyrirspurnir (þú getur valið valin markmið), hringdu (hringur) kjötkássa (með því að nota samkvæma kjötkássa yfir andstreymis gestgjafa) eða minnstu beiðni aðferð (valið er tilvikinu með fæstar beiðnir).

Klassískir jafnvægistæki hafa aðrar aðgerðir, svo sem HTTP skyndiminni og DDoS vernd, en þeir eru ekki mjög viðeigandi fyrir austur-vestur umferð (þ.e. fyrir umferð sem flæðir innan gagnaver - u.þ.b. þýðing) (dæmigert umfang þjónustunets). Auðvitað er ekki nauðsynlegt að nota þjónustunet fyrir álagsjafnvægi, en það gerir þér kleift að stilla og stjórna jöfnunarstefnu fyrir hverja þjónustu frá miðstýrðu stjórnlagi og þar með útiloka þörfina á að keyra og stilla aðskilda álagsjafnara í netstokknum .

5. Hringrás

TL;DR: Stöðvaðu umferð að erfiðu þjónustunni og stjórnaðu tjóninu í verstu tilfellum.

Ef þjónustan af einhverjum ástæðum getur ekki ráðið við umferðina, býður þjónustunetið upp á nokkra möguleika til að leysa þetta vandamál (aðra verður rætt í viðeigandi köflum). Brot á hringrás er alvarlegasti kosturinn til að aftengja þjónustu frá umferð. Hins vegar er það í sjálfu sér ekki skynsamlegt - öryggisafritunaráætlun er nauðsynleg. Hægt er að veita bakþrýsting (bak þrýstingur) til þjónustu sem leggja fram beiðnir (bara ekki gleyma að stilla þjónustunetið þitt fyrir þetta!), eða til dæmis lita stöðusíðuna rauða og vísa notendum á aðra útgáfu af síðunni með „fallandi hvali“ (“Twitter er niður“).

Þjónustunet leyfa þér ekki aðeins að skilgreina þegar lokun mun fylgja og að þetta kemur í kjölfarið. Í þessu tilviki getur „hvenær“ falið í sér hvaða samsetningu sem er af tilgreindum breytum: heildarfjölda beiðna fyrir ákveðið tímabil, fjölda samhliða tenginga, biðbeiðna, virkra endurtilrauna osfrv.

Þú vilt líklega ekki misnota rafrásir, en það er gaman að vita að þú ert með varaáætlun ef neyðartilvik eru.

6. Sjálfstærð

TL;DR: Auka eða minnka fjölda þjónustutilvika eftir tilgreindum forsendum.

Þjónustunet eru ekki tímasetningar, svo þeir gera það ekki framkvæma að stækka sjálfan þig. Hins vegar geta þeir veitt upplýsingar um hvaða skipuleggjendur munu byggja ákvarðanir sínar. Þar sem þjónustunet hefur aðgang að allri umferð á milli þjónustu hafa þeir miklar upplýsingar um hvað er að gerast: hvaða þjónustur lenda í vandræðum, hvaða þjónustur eru mjög léttar (getan sem þeim er úthlutað fer til spillis) o.s.frv.

Til dæmis skalar Kubernetes þjónustu út frá örgjörva og minnisnotkun fræbelgs (sjá skýrslu okkar "Sjálfvirk stærð og auðlindastjórnun í Kubernetes"- ca. þýðing.), en ef þú ákveður að skala út frá öðrum mælikvarða (í okkar tilfelli, umferðartengd), þarftu sérstaka mælikvarða. Stjórnun svona sýnir hvernig á að gera þetta með Sendiherra, Sama и Prometheus, en ferlið sjálft er frekar flókið. Við viljum að þjónustunetið einfaldaði þetta með því að leyfa okkur einfaldlega að setja skilyrði eins og „auka fjölda þjónustutilvika auth, ef fjöldi beiðna í bið fer yfir viðmiðunarmörk innan mínútu.“

7. Kanarídreifingar

TL;DR: Prófaðu nýja eiginleika eða þjónustuútgáfur á undirhópi notenda.

Segjum að þú sért að þróa SaaS vöru og ætlar að setja út nýja flotta útgáfu af henni. Þú prófaðir það í sviðsetningu og það virkaði frábærlega. En það eru samt ákveðnar áhyggjur af hegðun hennar við raunverulegar aðstæður. Með öðrum orðum, þú þarft að prófa nýju útgáfuna á raunverulegum vandamálum án þess að hætta á trausti notenda. Kanarí-uppsetningar eru frábærar fyrir þetta. Þeir gera þér kleift að sýna nýjan eiginleika fyrir undirmengi notenda. Þessi undirmengi getur samanstandið af tryggustu notendum eða þeim sem vinna með ókeypis útgáfu vörunnar, eða notendum sem hafa lýst yfir löngun til að vera „naggvín“.

Þjónustunet útfæra þetta með því að leyfa þér að tilgreina viðmið sem ákvarða hver mun sjá hvaða útgáfu af forritinu og beina umferð í samræmi við það. Hins vegar breytist ekkert fyrir þjónustuna sjálfa. Útgáfa 1.0 af þjónustunni telur að allar beiðnir komi frá notendum sem ættu að sjá hana og útgáfa 1.1 telur það sama fyrir notendur sína. Á sama tíma geturðu breytt hlutfalli umferðar á milli gömlu og nýju útgáfunnar, og vísað vaxandi fjölda notenda yfir í þá nýju ef það virkar stöðugt og „naggvínin“ þín gefa brautargengi.

8. Blágrænar dreifingar

TL;DR: Rúllaðu út flottan nýjan eiginleika, en vertu tilbúinn til að taka allt strax til baka.

Merking blágrænar dreifingar er að setja út nýja „bláa“ þjónustu, opna hana samhliða þeirri gömlu „grænu“. Ef allt gengur snurðulaust fyrir sig og nýja þjónustan gengur vel, þá er hægt að slökkva á gömlu smám saman. (Því miður, einhvern tíma mun þessi nýja „bláa“ þjónusta endurtaka örlög þeirrar „grænu“ og hverfa...) Blágræna uppsetningin er frábrugðin þeim kanarí að því leyti að nýja aðgerðin nær yfir allir í einu notendur (ekki hluti); Málið hér er að hafa „örugga höfn“ tilbúna ef eitthvað fer úrskeiðis.

Þjónustunet bjóða upp á mjög þægilega leið til að prófa „bláa“ þjónustu og skipta samstundis yfir í virka „græna“ ef vandamál koma upp. Svo ekki sé minnst á þá staðreynd að á leiðinni veita þeir miklar upplýsingar (sjá „Fjarmælingar“ hér að neðan) um starf „bláa“, sem hjálpar til við að skilja hvort það sé tilbúið fyrir fulla notkun.

Athugið. þýð.: Þú getur lesið meira um mismunandi dreifingaraðferðir í Kubernetes (þar á meðal nefndur kanarífugl, blár/grænn og fleiri) í Þessi grein.

9. Heilsufarsskoðun

TL;DR: Fylgstu með hvaða þjónustutilvik eru virk og bregðast við þeim sem eru ekki lengur virk.

Heilsufarsskoðun (heilsuskoðun) hjálpar til við að ákveða hvort þjónustutilvik séu tilbúin til að taka við og vinna úr umferð. Til dæmis, þegar um er að ræða HTTP þjónustu, gæti heilsufarsskoðun litið út eins og GET beiðni til endapunktsins /health... Svar 200 OK mun þýða að tilvikið sé heilbrigt, hvert annað - að það sé ekki tilbúið til að taka á móti umferð. Þjónustunet gerir þér kleift að tilgreina bæði hvernig virkni verður athugað og hversu oft þessi athugun verður framkvæmd. Þessar upplýsingar er síðan hægt að nota í öðrum tilgangi - til dæmis til að jafna álag og rofa.

Heilsuskoðun er því ekki sjálfstætt notkunartilvik heldur er það venjulega notað til að ná öðrum markmiðum. Einnig, allt eftir niðurstöðum heilsufarsskoðana, getur verið krafist aðgerða utan annarra þjónustunetsmarkmiða: til dæmis að uppfæra stöðusíðuna, búa til mál á GitHub eða fylla út JIRA miða. Og þjónustunet býður upp á þægilegan búnað til að gera allt þetta sjálfvirkt.

10. Álagslosun

TL;DR: Beindu umferð til að bregðast við tímabundinni aukningu í notkun.

Ef ákveðin þjónusta er ofhlaðin af umferð geturðu beint hluta þessarar umferðar tímabundið á annan stað (þ.e. „dump“, „flytja“ (skúr) hann þar). Til dæmis í öryggisafritunarþjónustu eða gagnaver eða í varanlegt ýta umræðuefni. Fyrir vikið mun þjónustan halda áfram að vinna úr sumum beiðnum í stað þess að hrynja og hætta að vinna allt. Álagslosun er æskilegri en að rjúfa hringrásina, en samt er ekki ráðlegt að misnota hana. Það hjálpar til við að koma í veg fyrir bilanir sem valda því að niðurstreymisþjónusta hrynur.

11. Umferðarsamsíða/speglun

TL;DR: Sendu eina beiðni á nokkra staði í einu.

Stundum þarf að senda beiðni (eða ákveðið úrval beiðna) til nokkurra þjónustu í einu. Dæmigerð dæmi er að senda hluta af framleiðsluumferð til sviðsetningarþjónustu. Aðalframleiðsla vefþjónn sendir beiðni til downstream þjónustunnar products.production og aðeins honum. Og þjónustunetið afritar þessa beiðni á skynsamlegan hátt og sendir hana til products.staging, sem vefþjónninn er ekki einu sinni meðvitaður um.

Annað tengt þjónustumöskva notkunartilvik sem hægt er að útfæra ofan á samhliða samsetningu umferðar er aðhvarfsprófun. Það felur í sér að sömu beiðnir eru sendar í mismunandi útgáfur þjónustunnar og athugað hvort allar útgáfur hagi sér eins. Ég hef ekki enn rekist á þjónustunetsútfærslu með samþættu aðhvarfsprófunarkerfi eins og Diffy, en hugmyndin sjálf virðist lofa góðu.

12. Einangrun

TL;DR: Skiptu þjónustunetinu þínu í smánet.

Líka þekkt sem skiptinguEinangrun er listin að skipta þjónustuneti í röklega aðgreinda hluta sem vita ekkert um hvert annað. Einangrun er svolítið eins og að búa til sýndar einkanet. Grundvallarmunurinn er sá að þú getur samt notið allra kosta þjónustunets (eins og þjónustuuppgötvunar), en með auknu öryggi. Til dæmis, ef árásarmaður getur komist inn í þjónustu á einu undirneti, mun hann ekki geta séð hvaða þjónustur eru í gangi á öðrum undirnetum eða stöðvað umferð þeirra.

Að auki geta ávinningurinn einnig verið skipulagslegur. Þú gætir viljað undirneta þjónustu þína á grundvelli fyrirtækjauppbyggingar þinnar og létta þróunaraðila við það vitræna álag að þurfa að hafa allt þjónustunetið í huga.

13. Biðja um takmörkun á gengi, endurtilraunir og tímamörk

TL;DR: Þú þarft ekki lengur að innihalda nöturleg beiðnistjórnunarverkefni í kóðagrunninum þínum.

Allir þessir hlutir gætu talist aðskilin notkunartilvik, en ég ákvað að sameina þá vegna eins sameiginlegs eiginleika: þeir taka yfir lífsferilsstjórnunarverkefni sem eru venjulega meðhöndluð af forritasöfnum. Ef þú ert að þróa vefþjón í Ruby on Rails (ekki samþætt við þjónustunet) sem gerir beiðnir um bakendaþjónustu í gegnum gRPC, mun umsóknin þurfa að ákveða hvað á að gera ef N beiðnir mistakast. Þú verður líka að finna út hversu mikla umferð þessi þjónusta mun geta unnið úr og hardkóða þessar breytur með því að nota sérstakt bókasafn. Auk þess verður forritið að ákveða hvenær það er kominn tími til að gefast upp og láta beiðnina renna út (byggt á tímamörkum). Og til að breyta einhverjum af ofangreindum breytum verður að stöðva vefþjóninn, endurstilla hann og ræsa hann aftur.

Að hlaða þessum verkefnum í þjónustunet þýðir ekki aðeins að þjónustuframleiðendur þurfa ekki að hugsa um þau, heldur einnig að hægt sé að skoða þau á alþjóðlegri hátt. Ef notuð er flókin keðja þjónustu, segjum A -> B -> C -> D -> E, þarf að taka tillit til alls líftíma beiðninnar. Ef verkefnið er að lengja tímamörk í þjónustu C, er rökrétt að gera þetta allt í einu, en ekki í hlutum: með því að uppfæra þjónustukóðann og bíða þar til dráttarbeiðnin er samþykkt og CI kerfið innleiðir uppfærðu þjónustuna.

14. Fjarmæling

TL;DR: Safnaðu öllum nauðsynlegum (og ekki alveg) upplýsingum frá þjónustu.

Fjarmæling er almennt hugtak sem inniheldur mælikvarða, dreifða rakningu og annála. Þjónustunet bjóða upp á kerfi til að safna og vinna allar þrjár tegundir gagna. Þetta er þar sem hlutirnir verða svolítið óskýrir vegna þess að fjöldi mögulegra valkosta er of mikill. Til að safna mælingum er til Prometheus og önnur verkfæri sem hægt er að nota til að safna annálum reiprennandi, Loki, Vektor o.fl. (til dæmis ClickHouse með okkar timburhús fyrir K8s - ca. þýðing.), fyrir dreifða rekja er Jaeger og svo framvegis. Hvert þjónustunet gæti stutt sum verkfæri en ekki önnur. Það verður fróðlegt að sjá hvort verkefnið geti Opna fjarmælingar veita nokkra samleitni.

Í þessu tilviki er kosturinn við þjónustunetstækni að hliðarvagnagámar geta í grundvallaratriðum safnað öllum ofangreindum gögnum frá þjónustu þeirra. Með öðrum orðum, þú hefur eitt fjarmælingarsöfnunarkerfi til umráða og þjónustunetið getur unnið úr öllum þessum upplýsingum á ýmsan hátt. Til dæmis:

halaskrár frá ákveðinni þjónustu í CLI;
fylgjast með magn beiðna frá mælaborði þjónustumöskva;
safna dreifðum ummerkjum og framsenda þau í kerfi eins og Jaeger.

Athygli, huglægt mat: Almennt séð er fjarmæling svæði þar sem mikil truflun frá þjónustunetinu er óæskileg. Það er fínt að safna grunnupplýsingum og fylgjast með nokkrum gylltum mælingum á flugi eins og árangurshlutfall beiðna og biðtíma, en við skulum vona að við sjáum ekki Frankenstein stafla koma fram sem reyna að koma í stað sérhæfðra kerfa, sem sum hver hafa þegar sannað sig og vel rannsakað .

15. Endurskoðun

TL;DR: Þeir sem gleyma lærdómi sögunnar eru dæmdir til að endurtaka þær.

Endurskoðun er listin að fylgjast með mikilvægum atburðum í kerfi. Ef um er að ræða þjónustunet gæti þetta þýtt að fylgst sé með því hver gerði beiðnir til ákveðinna endapunkta fyrir tiltekna þjónustu, eða hversu oft einhver öryggistengdur atburður átti sér stað í síðasta mánuði.

Ljóst er að endurskoðun er mjög nátengd fjarmælingum. Munurinn er sá að fjarmælingar eru venjulega tengdir hlutum eins og framleiðni og tæknilegum heilindum, á meðan endurskoðun getur tengst lagalegum og öðrum atriðum sem fara út fyrir strangt tæknilega sviðið (til dæmis samræmi við GDPR - almenna reglugerð ESB um gagnavernd).

16. Visualization

TL;DR: Lengi lifi React.js - ótæmandi uppspretta flottra viðmóta.

Það gæti verið betra hugtak, en ég veit það ekki. Ég meina einfaldlega myndræna framsetningu á þjónustuneti eða sumum íhlutum þess. Þessar sjónmyndir geta innihaldið vísbendingar eins og meðaltöf, upplýsingar um hliðarstillingar, niðurstöður heilsufarsskoðunar og viðvaranir.

Að vinna í þjónustumiðuðu umhverfi felur í sér mun hærra vitsmunalegt álag samanborið við Hans hátign. Þess vegna ætti að draga úr vitsmunalegum þrýstingi hvað sem það kostar. Einfalt grafískt viðmót fyrir þjónustunet með getu til að smella á hnapp og fá þá niðurstöðu sem óskað er eftir gæti verið afgerandi fyrir vöxt vinsælda þessarar tækni.

Voru ekki með á listanum

Ég ætlaði upphaflega að setja nokkur fleiri notkunartilvik á listann en ákvað svo að gera það ekki. Hér eru þær, ásamt ástæðum fyrir ákvörðun minni:

Fjölgagnamiðstöð. Að mínu mati er þetta ekki svo mikið notkunartilvik heldur þröngt og sérstakt notkunarsvið þjónustumöskva eða einhverja aðgerða eins og þjónustuuppgötvun.
Inngangur og útgangur. Þetta er skylt svæði, en ég hef takmarkað mig (kannski tilbúnar) við "austur-vestur umferð" notkunartilvikið. Inngangur og útgangur verðskulda sérstaka grein.

Ályktun

Það er allt í bili! Aftur, þessi listi er mjög handahófskenndur og líklega ófullnægjandi. Ef þú heldur að ég hafi misst af einhverju eða eitthvað rangt, vinsamlegast hafðu samband við mig á Twitter (@luckerkins). Vinsamlegast virðið velsæmisreglur.

PS frá þýðanda

Titilskreyting greinarinnar er byggð á mynd úr greininni “Hvað er þjónustunet (og hvenær á að nota það)?"(eftir Gregory MacKinnon). Það sýnir hvernig einhver virkni úr forritum (í grænu) hefur færst yfir í þjónustunet sem veitir samtengingar á milli þeirra (í bláu).

Lestu líka á blogginu okkar:

Heimild: www.habr.com