ProHoster > Blogs > Administrācija > Servisa tīkla datu plakne pret vadības plakni

Servisa tīkla datu plakne pret vadības plakni

Čau Habr! Piedāvāju jūsu uzmanībai raksta tulkojumu "Pakalpojuma tīkla datu plakne pret vadības plakni" autors Matt Klein.

Servisa tīkla datu plakne pret vadības plakni

Å oreiz ā€œgribēju un pārtulkojuā€ gan servisa tÄ«kla komponentu, gan datu plaknes, gan vadÄ«bas plaknes aprakstu. Å is apraksts man Ŕķita saprotamākais un interesantākais, un pats galvenais, kas noveda pie izpratnes ā€œVai tas vispār ir vajadzÄ«gs?ā€

Tā kā ideja par "Servisa tīklu" pēdējo divu gadu laikā ir kļuvusi arvien populārāka (sākotnējais raksts 10) un dalībnieku skaits telpā ir palielinājies, esmu novērojis proporcionālu apjukuma pieaugumu starp visiem tehnoloģiju kopiena par to, kā salīdzināt un pretstatīt dažādus risinājumus.

Situāciju vislabāk var apkopot Ŕādās tvÄ«tu sērijās, kuras rakstÄ«ju jÅ«lijā:

Pakalpojuma tīkla apjukums Nr. 1: Linkerd ~ = Nginx ~ = Haproxy ~ = sūtnis. Neviens no viņiem nav vienāds ar Istio. Istio ir kaut kas pavisam cits. 1/

Pirmās ir vienkārÅ”i datu plaknes. PaÅ”i paÅ”i viņi neko nedara. Viņiem jābÅ«t noskaņotiem kaut kam vairāk. 2/

Istio ir vadības plaknes piemērs, kas savieno daļas. Šis ir vēl viens slānis. /beigas

IepriekŔējie tvÄ«ti piemin vairākus dažādus projektus (Linkerd, NGINX, HAProxy, Envoy un Istio), bet vēl svarÄ«gāk ir iepazÄ«stināt ar vispārÄ«gajiem datu plaknes, pakalpojumu tÄ«kla un vadÄ«bas plaknes jēdzieniem. Å ajā ierakstā es sperÅ”u soli atpakaļ un ļoti augstā lÄ«menÄ« runāŔu par to, ko es domāju ar jēdzieniem "datu plakne" un "vadÄ«bas plakne", un pēc tam runāŔu par to, kā termini attiecas uz tvÄ«tā minētajiem projektiem.

Kas īsti ir servisa tīkls?

Servisa tīkla datu plakne pret vadības plakni
1. attēls. Servisa tīkla pārskats

Skaitlis 1 ilustrē pakalpojumu tÄ«kla jēdzienu tās visvienkārŔākajā lÄ«menÄ«. Ir četri pakalpojumu klasteri (AD). Katrs pakalpojuma gadÄ«jums ir saistÄ«ts ar vietējo starpniekserveri. Visa tÄ«kla trafika (HTTP, REST, gRPC, Redis u.c.) no vienas lietojumprogrammas instances caur vietējo starpniekserveri tiek nodota atbilstoÅ”ajām ārējo pakalpojumu klasteriem. Tādā veidā lietojumprogrammas instance nezina tÄ«klu kopumā un zina tikai savu vietējo starpniekserveri. Faktiski izplatÄ«tās sistēmas tÄ«kls tika noņemts no pakalpojuma.

Datu plakne

Pakalpojuma tīklā starpniekserveris, kas atrodas lokāli lietojumprogrammai, veic Ŕādus uzdevumus:

  • Pakalpojuma atklāŔana. Kādi pakalpojumi/lietojumprogrammas ir pieejamas jÅ«su lietojumprogrammai?
  • VeselÄ«bas pārbaude. Vai pakalpojuma atklāŔanā atgrieztās pakalpojuma instances ir veselas un ir gatavas pieņemt tÄ«kla trafiku? Tas var ietvert gan aktÄ«vās (piemēram, atbildes/veselÄ«bas pārbaudes), gan pasÄ«vās (piemēram, izmantojot 3 secÄ«gas 5xx kļūdas, kas norāda uz neveselÄ«ga pakalpojuma stāvokli) veselÄ«bas pārbaudes.
  • MarÅ”rutÄ“Å”ana. Kuram pakalpojumu klasterim pieprasÄ«jums jānosÅ«ta, saņemot pieprasÄ«jumu uz "/foo" no REST pakalpojuma?
  • Slodzes balansÄ“Å”ana. Kad marÅ”rutÄ“Å”anas laikā ir atlasÄ«ts pakalpojumu klasteris, uz kuru pakalpojuma gadÄ«jumu jānosÅ«ta pieprasÄ«jums? Ar kādu taimautu? Ar kādiem ķēdes pārtraukuma iestatÄ«jumiem? Ja pieprasÄ«jums neizdodas, vai tas ir jāmēģina vēlreiz?
  • Autentifikācija un autorizācija. Vai ienākoÅ”ajiem pieprasÄ«jumiem zvanÄ«Å”anas pakalpojumu var kriptogrāfiski identificēt/autorizēt, izmantojot mTLS vai kādu citu mehānismu? Ja tas ir atpazÄ«ts/autorizēts, vai pakalpojumā ir atļauts izsaukt pieprasÄ«to darbÄ«bu (galapunktu), vai arÄ« ir jāatgriež neautentificēta atbilde?
  • NovērojamÄ«ba. Katram pieprasÄ«jumam ir jāģenerē detalizēta statistika, žurnāli/žurnāli un izplatÄ«tie izsekoÅ”anas dati, lai operatori varētu izprast sadalÄ«tās trafika plÅ«smas un atkļūdoÅ”anas problēmas, kad tās rodas.

Datu plakne ir atbildÄ«ga par visiem iepriekŔējiem apkalpoÅ”anas tÄ«kla punktiem. Faktiski pakalpojuma vietējais starpniekserveris (blakusvāģis) ir datu plakne. Citiem vārdiem sakot, datu plakne ir atbildÄ«ga par katras tÄ«kla paketes, kas tiek nosÅ«tÄ«ta uz pakalpojumu vai no pakalpojuma, nosacÄ«tu apraidi, pārsÅ«tÄ«Å”anu un uzraudzÄ«bu.

Vadības plakne

TÄ«kla abstrakcija, ko lokālais starpniekserveris nodroÅ”ina datu plaknē, ir maÄ£iska (?). Tomēr kā starpniekserveris faktiski zina par "/foo" marÅ”rutu uz pakalpojumu B? Kā var izmantot pakalpojumu atklāŔanas datus, ko aizpilda starpniekservera pieprasÄ«jumi? Kā ir konfigurēti parametri slodzes lÄ«dzsvaroÅ”anai, taimautai, ķēdes pārtraukumiem utt.? Kā izvietot lietojumprogrammu, izmantojot zilo/zaļo metodi vai graciozo satiksmes pārejas metodi? Kas konfigurē visas sistēmas autentifikācijas un autorizācijas iestatÄ«jumus?

Visi iepriekÅ” minētie vienumi atrodas apkopes tÄ«kla vadÄ«bas plaknes kontrolē. VadÄ«bas plakne ņem izolētu bezpastāvju starpniekserveru kopu un pārvērÅ” tos sadalÄ«tā sistēmā.

Es domāju, ka iemesls, kāpēc daudzi tehnologi uzskata, ka atseviŔķie datu plaknes un vadÄ«bas plaknes jēdzieni ir mulsinoÅ”i, ir tas, ka lielākajai daļai cilvēku datu plakne ir pazÄ«stama, bet vadÄ«bas plakne ir sveÅ”a/nesaprasta. Mēs jau ilgu laiku strādājam ar fiziskajiem tÄ«kla marÅ”rutētājiem un slēdžiem. Mēs saprotam, ka paketēm/pieprasÄ«jumiem ir jānonāk no punkta A uz punktu B un ka mēs varam izmantot aparatÅ«ru un programmatÅ«ru, lai to paveiktu. Jaunās paaudzes programmatÅ«ras starpniekserveri ir vienkārÅ”i izdomātas to rÄ«ku versijas, ko esam izmantojuÅ”i jau ilgu laiku.

Servisa tīkla datu plakne pret vadības plakni
2. attēls. Cilvēka vadības plakne

Tomēr mēs jau ilgu laiku esam izmantojuÅ”i vadÄ«bas plaknes, lai gan lielākā daļa tÄ«kla operatoru Å”o sistēmas daļu var nesaistÄ«t ar kādu tehnoloÄ£iju komponentu. Iemesls ir vienkārÅ”s:
Lielākā daļa mūsdienās izmantoto vadības plakņu ir... mēs.

uz 2. attēls parāda to, ko es saucu par ā€œCilvēka kontroles plakniā€. Šāda veida izvietoÅ”anā, kas joprojām ir ļoti izplatÄ«ta, iespējams, kaŔķīgs cilvēks-operators izveido statiskas konfigurācijas ā€” iespējams, izmantojot skriptus ā€” un izvieto tās, izmantojot kādu Ä«paÅ”u procesu, visos starpniekserveros. Pēc tam starpniekserveri sāk izmantot Å”o konfigurāciju un sāk apstrādāt datu plakni, izmantojot atjauninātos iestatÄ«jumus.

Servisa tīkla datu plakne pret vadības plakni
3. attēls. Uzlabotā apkalpoÅ”anas tÄ«kla vadÄ«bas plakne

uz 3. attēls parāda apkalpoÅ”anas tÄ«kla ā€œpaplaÅ”inātoā€ vadÄ«bas plakni. Tas sastāv no Ŕādām daļām:

  • Cilvēks: Joprojām ir cilvēks (cerams, ka mazāk dusmÄ«gs), kurÅ” pieņem augsta lÄ«meņa lēmumus attiecÄ«bā uz visu sistēmu kopumā.
  • VadÄ«bas plaknes UI: persona mijiedarbojas ar noteikta veida lietotāja interfeisu, lai kontrolētu sistēmu. Tas varētu bÅ«t tÄ«mekļa portāls, komandrindas lietojumprogramma (CLI) vai kāda cita saskarne. Izmantojot lietotāja interfeisu, operatoram ir piekļuve globālajiem sistēmas konfigurācijas parametriem, piemēram:
    • IzvērÅ”anas kontrole, zila/zaļa un/vai pakāpeniska satiksmes pāreja
    • Autentifikācijas un autorizācijas iespējas
    • MarÅ”rutÄ“Å”anas tabulas specifikācijas, piemēram, kad lietojumprogramma A pieprasa informāciju par "/foo", kas notiek
    • Slodzes lÄ«dzsvarotāja iestatÄ«jumi, piemēram, taimautu, atkārtotu mēģinājumu, ķēdes pārtraukumu iestatÄ«jumi utt.
  • Darba slodzes plānotājs: pakalpojumi tiek darbināti infrastruktÅ«rā, izmantojot noteikta veida plānoÅ”anas/orÄ·estrācijas sistēmu, piemēram, Kubernetes vai Nomad. Plānotājs ir atbildÄ«gs par pakalpojuma ielādi kopā ar vietējo starpniekserveri.
  • Pakalpojuma atklāŔana. Kad plānotājs sāk un aptur pakalpojumu gadÄ«jumus, tas ziņo par veselÄ«bas stāvokli pakalpojuma atklāŔanas sistēmai.
  • Blakusvāģa starpniekservera konfigurācijas API : lokālie starpniekserveri dinamiski iegÅ«st stāvokli no dažādiem sistēmas komponentiem, izmantojot galu galā konsekventu modeli bez operatora iejaukÅ”anās. Visa sistēma, kas sastāv no visiem paÅ”laik strādājoÅ”ajiem pakalpojumu gadÄ«jumiem un vietējiem starpniekserveriem, galu galā saplÅ«st vienā ekosistēmā. Envoy universālā datu plaknes API ir viens no piemēriem, kā tas darbojas praksē.

Būtībā vadības plaknes mērķis ir iestatīt politiku, kas galu galā tiks pieņemta datu plaknē. Uzlabotas vadības plaknes no operatora noņems vairāk dažu sistēmu daļu un prasīs mazāk manuālas darbības, ja tās darbojas pareizi!...

Datu plakne un vadības plakne. Datu plaknes un vadības plaknes kopsavilkums

  • Servisa tÄ«kla datu plakne: ietekmē katru paketi/pieprasÄ«jumu sistēmā. AtbildÄ«gs par lietojumprogrammu/pakalpojumu atklāŔanu, veselÄ«bas pārbaudi, marÅ”rutÄ“Å”anu, slodzes lÄ«dzsvaroÅ”anu, autentifikāciju/autorizāciju un novērojamÄ«bu.
  • Servisa tÄ«kla vadÄ«bas plakne: nodroÅ”ina politiku un konfigurāciju visām pakalpojumu tÄ«klā esoÅ”ajām datu plaknēm. Nepieskaras nevienai paketei/pieprasÄ«jumam sistēmā. VadÄ«bas plakne pārvērÅ” visas datu plaknes sadalÄ«tā sistēmā.

PaÅ”reizējā projekta ainava

SapratuÅ”i iepriekÅ” minēto skaidrojumu, apskatÄ«sim pakalpojumu tÄ«kla projekta paÅ”reizējo stāvokli.

  • Datu plaknes: Linkerd, NGINX, HAProxy, Envoy, Traefik
  • VadÄ«bas plaknes: Istio, Nelsons, SmartStack

Tā vietā, lai padziļināti analizētu katru no iepriekÅ”minētajiem risinājumiem, es Ä«sumā aplÅ«koÅ”u dažus punktus, kas, manuprāt, Å”obrÄ«d rada lielu apjukumu ekosistēmā.

Linkerd bija viens no pirmajiem datu plaknes starpniekserveriem pakalpojumu tÄ«klam 2016. gada sākumā, un tas ir paveicis fantastisku darbu, lai palielinātu izpratni un uzmanÄ«bu pakalpojuma tÄ«kla dizaina modelim. Apmēram 6 mēneÅ”us pēc tam sÅ«tnis pievienojās Linkerd (lai gan viņŔ bija kopā ar Lyft kopÅ” 2015. gada beigām). Linkerd un Envoy ir divi projekti, kas visbiežāk tiek minēti, apspriežot pakalpojumu tÄ«klus.

Istio tika paziņots 2017. gada maijā. Istio projekta mērÄ·i ir ļoti lÄ«dzÄ«gi attēlā parādÄ«tajai paplaÅ”inātajai vadÄ«bas plaknei 3. attēls. Istio sÅ«tnis ir noklusējuma starpniekserveris. Tādējādi Istio ir vadÄ«bas plakne, un Envoy ir datu plakne. ÄŖsā laikā Istio radÄ«ja lielu aizrautÄ«bu, un citas datu plaknes sāka integrēt kā Envoy aizstājēju (gan Linkerd, gan NGINX demonstrēja integrāciju ar Istio). Fakts, ka vienā vadÄ«bas plaknē var izmantot dažādas datu plaknes, nozÄ«mē, ka vadÄ«bas plakne un datu plakne ne vienmēr ir cieÅ”i saistÄ«tas. API, piemēram, Envoy vispārÄ«gā datu plaknes API, var veidot tiltu starp divām sistēmas daļām.

Nelson un SmartStack palÄ«dz tālāk ilustrēt vadÄ«bas plaknes un datu plaknes atdalÄ«Å”anu. Nelsons izmanto Envoy kā savu starpniekserveri un izveido uzticamu vadÄ«bas plakni pakalpojumu tÄ«klam, pamatojoties uz HashiCorp steku, t.i. Nomads utt. SmartStack, iespējams, bija pirmais no jauna pakalpojumu tÄ«klu viļņa. SmartStack izveido vadÄ«bas plakni ap HAProxy vai NGINX, demonstrējot spēju atsaistÄ«t vadÄ«bas plakni no servisa tÄ«kla no datu plaknes.

Mikropakalpojumu arhitektÅ«ra ar servisa tÄ«klu iegÅ«st arvien lielāku uzmanÄ«bu (pareizi!), un arvien vairāk projektu un pārdevēju sāk strādāt Å”ajā virzienā. Dažu nākamo gadu laikā mēs redzēsim daudz jauninājumu gan datu plaknē, gan vadÄ«bas plaknē, kā arÄ« turpmāku dažādu komponentu sajaukÅ”anu. Galu galā mikropakalpojumu arhitektÅ«rai jākļūst caurspÄ«dÄ«gākai un maÄ£iskākai (?) operatoram.
Cerams, ka arvien mazāk aizkaitināts.

Atslēgas lÄ«dzņemÅ”anai

  • Servisa tÄ«kls sastāv no divām dažādām daļām: datu plaknes un vadÄ«bas plaknes. Ir nepiecieÅ”ami abi komponenti, un bez tiem sistēma nedarbosies.
  • Ikviens ir pazÄ«stams ar vadÄ«bas plakni, un Å”ajā brÄ«dÄ« vadÄ«bas plakne varētu bÅ«t jÅ«s!
  • Visas datu plaknes konkurē savā starpā par funkcijām, veiktspēju, konfigurējamÄ«bu un paplaÅ”ināmÄ«bu.
  • Visas vadÄ«bas plaknes konkurē savā starpā funkciju, konfigurējamÄ«bas, paplaÅ”ināŔanas un lietoÅ”anas vienkārŔības ziņā.
  • Viena vadÄ«bas plakne var saturēt pareizās abstrakcijas un API, lai varētu izmantot vairākas datu plaknes.

Avots: www.habr.com

Pievieno komentāru