Jegyzet. ford.: A cikk szerzője (Luc Perkins) a CNCF szervezet fejlesztői szószólója, amely olyan nyílt forráskódú projekteknek ad otthont, mint a Linkerd, az SMI (Service Mesh Interface) és a Kuma (mellesleg, Ön is azon töprengett, miért az Istio nincs ezen a listán?.). Ismételten megpróbálja jobban megérteni a DevOps közösséget a "service mesh"-nek nevezett divatos hírverésről, 16 jellemző képességet sorol fel, amelyeket ezek a megoldások nyújtanak.
Ma ― az egyik legforróbb téma a szoftverfejlesztés területén (és joggal!). Szerintem ez a technológia hihetetlenül ígéretes, és szeretném, ha széles körben alkalmaznák (természetesen ha van értelme). A legtöbb ember számára azonban még mindig a titokzatosság aurája veszi körül. Ugyanakkor még azok is, akik jól ismert ezzel gyakran nehéz megfogalmazni az előnyeit és azt, hogy pontosan mi is az (beleértve az Önét is). Ebben a cikkben megpróbálom korrigálni a helyzetet különféle felsorolással használati esetek "szolgáltatási hálók"*.
* Jegyzet ford.: itt és a továbbiakban a cikkben pontosan ezt a fordítást („service mesh”) használjuk a még új szolgáltatásháló kifejezésre.
De először szeretnék néhány megjegyzést tenni:
- Soha nem dolgoztam szervizhálókkal, és nem használtam azokat a saját oktatásomra indított projekteken kívül. Másrészt én voltam az, aki 2015-ben egy csomó dokumentációt írtam a Twitter belső szolgáltatáshálójához (akkor még nem is hívták "szolgáltatáshálónak"), és részt vettem a webhely és a dokumentáció fejlesztésében. , tehát ez jelent valamit.
- A listám hozzávetőleges és hiányos. Előfordulhatnak számomra ismeretlen felhasználási esetek, és valószínűleg idővel új lehetőségek merülnek fel, ahogy a technológia fejlődik és népszerűsége növekszik.
- Ugyanakkor nem minden meglévő szolgáltatásháló megvalósítás támogatja az összes felsorolt használati esetet. Ezért az olyan kijelentéseimet, mint a „service mesh can...” úgy kell értelmezni, hogy „egyedi, és talán minden népszerű service mesh implementáció képes...”.
- A példák sorrendje nem tesz különbséget.
Rövid lista:
- szolgáltatás felfedezése;
- Titkosítás;
- hitelesítés és engedélyezés;
- terhelés elosztás;
- áramkör megszakítása;
- automatikus skálázás;
- kanári bevetések;
- kék-zöld bevetések;
- állapotfelmérés;
- tehermentesítés;
- forgalom tükrözés;
- szigetelés;
- kérések gyakoriságának korlátozása, újrapróbálkozások és időtúllépések;
- telemetria;
- könyvvizsgálat;
- megjelenítés.
1. Szolgáltatás felfedezése
TL;DR: Csatlakozás más szolgáltatásokhoz a hálózaton egyszerű nevek használatával.
A szolgáltatásoknak képesnek kell lenniük arra, hogy megfelelő nevek használatával automatikusan „megtalálják” egymást – pl. service.api.production, pets/staging vagy cassandra. A felhőkörnyezetek rugalmasak, és egyetlen név elrejtheti a szolgáltatás számos példányát. Nyilvánvaló, hogy ilyen helyzetben fizikailag lehetetlen az összes IP-címet hardcode-olni.
Ráadásul, amikor egy szolgáltatás talál egy másikat, akkor képesnek kell lennie arra, hogy kéréseket küldjön annak a szolgáltatásnak anélkül, hogy félne attól, hogy azok a sérült példány bemenetére kerülnek. Más szavakkal, a szolgáltatáshálónak figyelnie kell az összes szolgáltatáspéldány állapotát, és a gazdagépek listáját a lehető legfrissebbnek kell tartania.
Minden szolgáltatásháló másként valósítja meg a szolgáltatáskeresési mechanizmust. Jelenleg a legelterjedtebb módja a külső folyamatokhoz, például a Kubernetes DNS-hez való delegálás. A múltban a Twitteren elnevezési rendszert használtunk erre a célra . Ezenkívül a service mesh technológia lehetővé teszi az egyedi elnevezési mechanizmusok megjelenését (bár még nem láttam ilyen funkcióval rendelkező SM megvalósítást).
2. Titkosítás
TL;DR: Szabaduljon meg a szolgáltatások közötti titkosítatlan forgalomtól, és tegye ezt a folyamatot automatizálttá és méretezhetővé.
Jó tudni, hogy a támadók nem tudnak behatolni a belső hálózatba. A tűzfalak nagyszerű munkát végeznek ebben. De mi történik, ha egy hacker bejut? A szolgáltatáson belüli forgalommal azt csinálhat, amit akar? Reméljük, ez mégsem fog megtörténni. Ennek a forgatókönyvnek a megelőzése érdekében egy nulla megbízhatóságú hálózatot kell megvalósítania, amelyben a szolgáltatások közötti összes forgalom titkosítva van. A legtöbb modern szervizháló ezt kölcsönösen éri el (kölcsönös TLS, mTLS). Egyes esetekben az mTLS teljes felhőkben és klaszterekben működik (szerintem a bolygóközi kommunikációt is hasonló módon rendezik majd el).
Természetesen az mTLS szolgáltatáshálóhoz választható. Mindegyik szolgáltatás gondoskodhat a saját TLS-éről, de ez azt jelenti, hogy meg kell találnia a tanúsítványok létrehozásának, a szolgáltatásgazdagépek közötti szétosztásának módját, és kódot kell tartalmaznia az alkalmazásban, amely betölti ezeket a tanúsítványokat a fájlokból. Igen, ne felejtse el rendszeres időközönként megújítani ezeket a tanúsítványokat. A szolgáltatáshálók automatizálják az mTLS-t olyan rendszerekkel, mint , amelyek viszont automatizálják a tanúsítványok kiadásának és váltásának folyamatát.
3. Hitelesítés és engedélyezés
TL;DR: Határozza meg, ki a kérelmező, és határozza meg, mit tehet, mielőtt a kérés elérné a szolgáltatást.
A szolgálatok gyakran tudni akarják aki elvégzi a kérést (hitelesítést), és ezen információk felhasználásával dönt hogy egy adott entitás megteheti (felhatalmazás). Ebben az esetben a „ki” névmás rejtőzhet:
- Egyéb szolgáltatások. Ezt hívják "hitelesítésnek" egyenrangú" Például a szolgáltatás
webszeretne hozzáférni a szolgáltatáshozdb. A szolgáltatáshálók általában mTLS segítségével oldják meg az ilyen problémákat: ebben az esetben a tanúsítványok a szükséges azonosítóként szolgálnak. - Néhány emberi felhasználó. Ezt hívják "hitelesítésnek" kérés" Például felhasználó
haxor69új lámpát szeretne vásárolni. A szervizhálók különféle mechanizmusokat biztosítanak, pl. .Sokan megtettük ezt az alkalmazáskódban. Jön egy kérés, átnézzük a táblázatot
users, keresse meg a felhasználót és hasonlítsa össze a jelszót, majd ellenőrizze az oszlopotpermissionsstb. Service mesh esetén ez még azelőtt megtörténik, hogy a kérés elérné a szolgáltatást.
Miután megállapítottuk, hogy kitől érkezett a kérés, meg kell határoznunk, hogy ez az entitás mit tehet. Egyes szolgáltatáshálók lehetővé teszik az alapvető házirendek beállítását (arról, hogy ki mit tehet) YAML-fájlokként vagy parancssorban, míg mások olyan keretrendszerekkel való integrációt kínálnak, mint pl. . A végső cél az, hogy szolgáltatásai minden kérést elfogadjanak, biztonságosan feltételezve, hogy megbízható forrásból származnak и ez a művelet megengedett.
4. Terheléselosztás
TL;DR: A terhelés elosztása a szolgáltatáspéldányok között egy adott minta szerint.
A szolgáltatási szakaszon belüli „Szolgáltatás” nagyon gyakran sok azonos példányból áll. Például ma a szolgáltatás cache 5 példányból áll, holnap pedig számuk 11-re emelkedhet cache, meghatározott célnak megfelelően kell terjeszteni. Például minimalizálja a késleltetést, vagy maximalizálja a működő példányhoz való eljutás valószínűségét. A leggyakrabban használt algoritmus a Round-robin, de sok más is létezik - például a súlyozott módszer (súlyozott) lekérdezések (kiválaszthatja a preferált célpontokat), csenget (gyűrű) kivonatolás (konzisztens kivonatolás használata az upstream gazdagépek között) vagy a legkevesebb kérés módszere (előnyben részesítjük a legkevesebb kéréssel rendelkező példányt).
A klasszikus kiegyenlítők más funkciókkal is rendelkeznek, mint például a HTTP-gyorsítótár és a DDoS védelem, de a kelet-nyugati forgalom (vagyis az adatközponton belüli forgalom - kb. fordítás) szempontjából (a szolgáltatásháló jellemző hatóköre) nem nagyon relevánsak. Természetesen nem szükséges szolgáltatáshálót használni a terheléselosztáshoz, de lehetővé teszi az egyes szolgáltatásokhoz tartozó kiegyenlítési házirendek beállítását és vezérlését egy központi vezérlőrétegről, így nincs szükség külön terheléselosztók futtatására és konfigurálására a hálózati veremben. .
5. Áramkör megszakítása
TL;DR: A problémás szolgáltatás forgalmának leállítása és a károk szabályozása a legrosszabb forgatókönyv esetén.
Ha a szolgáltatás valamilyen oknál fogva nem tud megbirkózni a forgalommal, a szolgáltatásháló számos lehetőséget kínál a probléma megoldására (a többiről a megfelelő szakaszokban lesz szó). Az áramkör megszakítása a legsúlyosabb lehetőség a szolgáltatás forgalomból való leválasztására. Önmagában azonban nincs értelme - szükség van egy biztonsági tervre. Ellennyomás biztosítható () olyan szolgáltatásokhoz, amelyek kérelmet küldenek (csak ne felejtse el beállítani ehhez a szolgáltatáshálót!), vagy például az állapotoldalt pirosra színezi, és a felhasználókat az oldal másik verziójára irányítja át egy „hulló bálnával” („Twitter is” le").
A szervizhálók nem csak a definiálást teszik lehetővé mikor leállítás következik és hogy ez fog következni. Ebben az esetben a „when” a megadott paraméterek tetszőleges kombinációját tartalmazhatja: egy adott időszakra vonatkozó kérések teljes száma, párhuzamos kapcsolatok száma, függőben lévő kérések, aktív újrapróbálkozások stb.
Valószínűleg nem akar visszaélni az áramkör megszakításával, de jó tudni, hogy van tartalék terve vészhelyzet esetére.
6. Automatikus skálázás
TL;DR: Növelje vagy csökkentse a szolgáltatáspéldányok számát a megadott feltételektől függően.
A szolgáltatáshálók nem ütemezők, így nem is végrehajtani megméretteti magát. Ugyanakkor tájékoztatást adhatnak arról, hogy mely tervezők döntenek majd. Mivel a szolgáltatáshálók hozzáférnek a szolgáltatások közötti összes forgalomhoz, széleskörű információval rendelkeznek arról, hogy mi történik: mely szolgáltatások tapasztaltak problémákat, mely szolgáltatások nagyon enyhén terheltek (a rájuk rendelt kapacitás elpazarolt), stb.
Például a Kubernetes a szolgáltatásokat a pods CPU- és memóriahasználata alapján méretezi (lásd jelentésünket""- kb. fordítás.), de ha úgy dönt, hogy bármely más (esetünkben a forgalommal kapcsolatos) mérőszám alapján skáláz, akkor szüksége lesz egy speciális mérőszámra. Menedzsment megmutatja, hogyan kell ezt megtenni , и , de maga a folyamat meglehetősen bonyolult. Szeretnénk, ha a szolgáltatásháló leegyszerűsítené ezt azáltal, hogy lehetővé teszi számunkra, hogy egyszerűen olyan feltételeket állítsunk be, mint például a „szolgáltatáspéldányok számának növelése auth, ha a függőben lévő kérelmek száma egy percen belül meghaladja a küszöbértéket."
7. Kanári bevetések
TL;DR: Új funkciók vagy szolgáltatásverziók tesztelése a felhasználók egy részén.
Tegyük fel, hogy Ön egy SaaS-terméket fejleszt, és annak egy klassz új verzióját kívánja közzétenni. Kipróbáltad a bemutatón, és remekül működött. De még mindig vannak bizonyos aggodalmak a valós körülmények között való viselkedésével kapcsolatban. Más szóval, valódi problémákon kell tesztelnie az új verziót a felhasználói bizalom kockáztatása nélkül. A kanári bevetések erre kiválóak. Lehetővé teszik egy új funkció bemutatását a felhasználók egy részének. Ez a részhalmaz állhat a leghűségesebb felhasználókból vagy azokból, akik a termék ingyenes verziójával dolgoznak, vagy olyan felhasználókból, akik kifejezték vágyukat, hogy „tengerimalacok” legyenek.
A szolgáltatáshálók ezt úgy valósítják meg, hogy lehetővé teszik olyan feltételek megadását, amelyek meghatározzák, hogy ki fogja látni az alkalmazás melyik verzióját, és ennek megfelelően irányítja a forgalmat. Maguk a szolgáltatások esetében azonban semmi sem változik. A szolgáltatás 1.0-s verziója úgy véli, hogy minden kérés olyan felhasználóktól érkezik, akiknek látniuk kell, az 1.1-es verzió pedig ugyanezt hiszi a felhasználók számára. Eközben módosíthatja a forgalom százalékos arányát a régi és az új verzió között, és egyre több felhasználót irányíthat át az újra, ha az stabilan működik, és a „tengerimalacok” megadják az utat.
8. Kék-zöld bevetések
TL;DR: Vezessen be egy nagyszerű új funkciót, de készüljön fel arra, hogy mindent azonnal visszavesz.
jelentését egy új „kék” szolgáltatás bevezetése, a régi „zöld” szolgáltatással párhuzamosan. Ha minden gördülékenyen megy és az új szolgáltatás jól működik, akkor a régit fokozatosan le lehet tiltani. (Jaj, egyszer ez az új „kék” szolgáltatás megismétli a „zöld” sorsát és eltűnik...) A kék-zöld telepítések abban különböznek a kanáriaktól, hogy az új funkció egyszerre felhasználók (nem része); Itt az a lényeg, hogy legyen készen egy „biztonságos kikötő” arra az esetre, ha valami baj történne.
A szervizhálók nagyon kényelmes módot kínálnak a „kék” szolgáltatás tesztelésére, és probléma esetén azonnal átválthatunk működő „zöldre”. Arról nem is beszélve, hogy útközben rengeteg információval szolgálnak (lásd lentebb a „Telemetria” részt) a „kék” munkájáról, ami segít megérteni, hogy készen áll-e a teljes működésre.
Jegyzet. ford.: A Kubernetes különböző telepítési stratégiáiról (beleértve az említett kanári, kék/zöld és másokat) itt olvashat bővebben .
9. Egészségügyi ellenőrzés
TL;DR: Kövesse nyomon, mely szolgáltatáspéldányok működnek, és válaszoljon azokra, amelyek már nem működnek.
Állapotfelmérés (állapotfelmérés) segít eldönteni, hogy a szolgáltatáspéldányok készen állnak-e a forgalom fogadására és feldolgozására. Például HTTP-szolgáltatások esetén az állapotellenőrzés úgy nézhet ki, mint egy GET-kérelem a végponthoz /health... Válasz 200 OK azt jelenti, hogy a példány egészséges, minden más - hogy nem áll készen a forgalom fogadására. A szervizhálók lehetővé teszik a funkcionalitás ellenőrzésének módját és az ellenőrzés végrehajtásának gyakoriságát is. Ezt az információt ezután más célokra is fel lehet használni - például terheléselosztásra és áramkör-megszakításra.
Így az állapotfelmérés nem önálló felhasználási eset, hanem általában más célok elérésére szolgál. Ezenkívül az állapotellenőrzések eredményeitől függően más szolgáltatásháló-célokon kívüli műveletekre is szükség lehet: például az állapotoldal frissítésére, a GitHubon probléma létrehozására vagy a JIRA jegy kitöltésére. A szervizháló pedig kényelmes mechanizmust kínál mindezek automatizálására.
10. Teherleválasztás
TL;DR: Forgalom átirányítása a használat ideiglenes megugrása miatt.
Ha egy bizonyos szolgáltatás túlterhelt forgalommal, akkor a forgalom egy részét ideiglenesen átirányíthatja egy másik helyre (azaz „kiírat”, „átküld” (fészer) őt ott). Például egy biztonsági mentési szolgáltatáshoz vagy adatközponthoz, vagy egy állandó téma. Ennek eredményeként a szolgáltatás továbbra is feldolgoz bizonyos kéréseket ahelyett, hogy összeomolna és leállítaná a feldolgozást. A terhelés leválasztása előnyösebb, mint az áramkör megszakítása, de mégsem tanácsos visszaélni vele. Segít megelőzni a lépcsőzetes hibákat, amelyek a downstream szolgáltatások összeomlását okozzák.
11. Forgalom párhuzamosítása/tükrözése
TL;DR: Egy kérés küldése több helyre egyszerre.
Néha szükség van arra, hogy egy kérést (vagy bizonyos kéréseket) egyszerre több szolgáltatásnak küldjenek. Tipikus példa az éles forgalom egy részének elküldése egy átmeneti szolgáltatáshoz. A fő éles webszerver kérést küld a downstream szolgáltatásnak products.production és csak neki. A szervizháló pedig intelligensen lemásolja ezt a kérést, és elküldi a címre products.staging, amiről a webszerver nem is tud.
Egy másik kapcsolódó szolgáltatásháló használati eset, amely a forgalom párhuzamosításán felül megvalósítható . Ez magában foglalja ugyanazon kérések elküldését a szolgáltatás különböző verzióinak, és annak ellenőrzését, hogy az összes verzió ugyanúgy viselkedik-e. Még nem találkoztam integrált regressziós tesztelő rendszerrel rendelkező szolgáltatásháló megvalósítással, mint pl , de maga az ötlet ígéretesnek tűnik.
12. Szigetelés
TL;DR: Bontsa fel szolgáltatási hálóját minihálózatokra.
Más néven szegmentálásAz elkülönítés egy szolgáltatásháló logikailag elkülönülő szegmensekre való felosztásának művészete, amelyek semmit sem tudnak egymásról. Az elszigetelés kicsit olyan, mint a virtuális magánhálózatok létrehozása. Az alapvető különbség az, hogy továbbra is élvezheti a szolgáltatásháló minden előnyét (például a szolgáltatás felfedezését), de még nagyobb biztonsággal. Például, ha egy támadó képes behatolni egy szolgáltatásba az egyik alhálózaton, akkor nem láthatja, hogy milyen szolgáltatások futnak a többi alhálózaton, és nem fogja tudni elfogni azok forgalmát.
Ezenkívül az előnyök szervezeti jellegűek is lehetnek. Érdemes lehet szolgáltatásait a vállalati struktúra alapján alhálózatba helyezni, és megszabadítani a fejlesztőket attól a kognitív terheléstől, hogy a teljes szolgáltatáshálót szem előtt kell tartaniuk.
13. Kérjen sebességkorlátozást, újrapróbálkozásokat és időtúllépéseket
TL;DR: Többé nem kell belefoglalnia a kéréskezelési feladatokat a kódbázisba.
Mindezek a dolgok különálló használati eseteknek tekinthetők, de egy közös jellemző miatt úgy döntöttem, hogy kombinálom őket: átveszik az alkalmazáskönyvtárak által jellemzően kezelt kérés életciklus-kezelési feladatokat. Ha olyan webszervert fejleszt Ruby on Railsben (nem integrálva szolgáltatáshálóval), amely kéréseket küld a háttérszolgáltatásokhoz , az alkalmazásnak el kell döntenie, mit tegyen, ha N kérés sikertelen. Azt is meg kell találnia, hogy ezek a szolgáltatások mekkora forgalommal tudják feldolgozni és hardkódolni ezeket a paramétereket egy speciális könyvtár segítségével. Ráadásul az alkalmazásnak el kell döntenie, hogy mikor kell feladni, és hagyni, hogy a kérés megszűnjön (az időtúllépés alapján). A fenti paraméterek bármelyikének megváltoztatásához pedig a webszervert le kell állítani, újra kell konfigurálni és újra kell indítani.
Ha ezeket a feladatokat átrakja egy szolgáltatáshálóba, akkor nem csak azt jelenti, hogy a szolgáltatásfejlesztőknek nem kell rájuk gondolniuk, hanem azt is, hogy globálisabban is megtekinthetők lesznek. Ha összetett szolgáltatásláncot használunk, mondjuk A -> B -> C -> D -> E, akkor a kérés teljes életciklusát figyelembe kell venni. Ha a feladat az időtúllépések meghosszabbítása a C szolgáltatásban, akkor logikus, hogy ezt egyszerre, és nem részletekben kell megtenni: a szolgáltatás kódjának frissítésével és megvárásával, amíg a lehívási kérelem elfogadásra kerül, és a CI rendszer telepíti a frissített szolgáltatást.
14. Telemetria
TL;DR: Gyűjtse össze az összes szükséges (és nem egészen) információt a szolgáltatásoktól.
A telemetria egy általános kifejezés, amely magában foglalja a mérőszámokat, az elosztott nyomkövetést és a naplókat. A szolgáltatáshálók mechanizmusokat kínálnak mindhárom adattípus összegyűjtésére és feldolgozására. Itt a dolgok kissé elmosódnak, mert a lehetséges opciók száma túl sok. A mutatók gyűjtésére van lehetőség és egyéb naplók gyűjtésére használható eszközök , , stb (például ClickHouse a miénkkel K8-asokhoz - kb. fordítás.), az elosztott nyomkövetéshez van stb. Mindegyik szervizháló támogathat bizonyos eszközöket, másokat nem. Érdekes lesz látni, hogy a projekt képes lesz-e biztosítanak némi konvergenciát.
Ebben az esetben a service mesh technológia előnye, hogy az oldalkocsis konténerek elvileg az összes fenti adatot be tudják gyűjteni szolgáltatásaikból. Más szóval, egyetlen telemetriai adatgyűjtési rendszer áll az Ön rendelkezésére, és a szervizháló különféle módokon tudja feldolgozni ezeket az információkat. Például:
- faroknaplók egy bizonyos szolgáltatásból a CLI-ben;
- figyelemmel kíséri a kérések mennyiségét a szolgáltatási háló irányítópultjáról;
- összegyűjti az elosztott nyomokat, és továbbítja azokat egy olyan rendszernek, mint a Jaeger.
Figyelem, szubjektív ítélet: Általánosságban elmondható, hogy a telemetria olyan terület, ahol nem kívánatos a szervizháló által okozott erős interferencia. Az alapvető információk összegyűjtése és néhány olyan arany mérőszám menet közbeni nyomon követése, mint a kérések sikerességének aránya és a késleltetés, rendben van, de reméljük, hogy nem látunk olyan Frankenstein-veremeket, amelyek megpróbálják helyettesíteni a speciális rendszereket, amelyek közül néhány már bevált és alaposan tanulmányozott. .
15. Audit
TL;DR: Aki elfelejti a történelem leckéit, arra van ítélve, hogy megismételje azokat.
Az auditálás a fontos események megfigyelésének művészete egy rendszerben. Szolgáltatási háló esetén ez azt jelentheti, hogy nyomon követheti, hogy ki kért bizonyos szolgáltatások adott végpontjaihoz, vagy hányszor történt valamilyen biztonsággal kapcsolatos esemény az elmúlt hónapban.
Nyilvánvaló, hogy az auditálás nagyon szorosan kapcsolódik a telemetriához. A különbség az, hogy a telemetriát általában olyan dolgokkal társítják, mint a termelékenység és a műszaki integritás, míg az auditálás olyan jogi és egyéb kérdésekhez kapcsolódhat, amelyek túlmutatnak a szigorúan technikai szférán (például a GDPR-nek – az EU általános adatvédelmi rendeletének) való megfelelés.
16. Vizualizáció
TL;DR: Éljen a React.js – a divatos interfészek kimeríthetetlen forrása.
Lehet, hogy van jobb kifejezés, de nem ismerem. Egyszerűen egy szolgáltatásháló vagy egyes összetevőinek grafikus ábrázolására gondolok. Ezek a vizualizációk olyan mutatókat tartalmazhatnak, mint az átlagos késleltetési idő, az oldalkocsi konfigurációs információi, az állapotfelmérés eredményei és a figyelmeztetések.
A szolgáltatás-orientált környezetben végzett munka sokkal nagyobb kognitív terhelést jelent, mint Őfelsége, a Monolit. Ezért a kognitív nyomást minden áron csökkenteni kell. Egy egyszerű grafikus interfész a szervizhálóhoz, amely egy gombra kattintással és a kívánt eredmény elérésével döntő lehet e technológia népszerűségének növekedésében.
Nem szerepeltek a listán
Eredetileg még néhány használati esetet akartam felvenni a listára, de aztán úgy döntöttem, hogy nem teszem. Íme, döntésem indokaival együtt:
- Több adatközpont. Véleményem szerint ez nem annyira használati eset, mint inkább a szervizhálók vagy bizonyos funkciók, például a szolgáltatáskeresés szűk és specifikus alkalmazási területe.
- Be- és kilépés. Ez egy kapcsolódó terület, de én (talán mesterségesen) a "kelet-nyugati forgalom" használati esetére korlátoztam magam. A belépés és a kilépés külön cikket érdemel.
Következtetés
Ez minden most! Ez a lista ismét nagyon önkényes, és valószínűleg hiányos. Ha úgy gondolja, hogy kihagytam valamit, vagy valamit elrontottam, kérjük, vegye fel velem a kapcsolatot a Twitteren (). Kérjük, tartsa be a tisztesség szabályait.
PS a fordítótól
A cikk címillusztrációja a " cikkből származó képen alapul"(Gregory MacKinnon). Megmutatja, hogy az alkalmazások bizonyos funkciói (zöld színnel) hogyan kerültek át egy szolgáltatáshálóba, amely összeköttetést biztosít közöttük (kék).
Olvassa el blogunkon is:
- «";
- «";
- «".
Forrás: will.com
