Hey Habr! Məqalənin tərcüməsini diqqətinizə təqdim edirəm müəllif Matt Klein.
Bu dəfə mən həm xidmət şəbəkəsi komponentlərinin, həm məlumat müstəvisinin, həm də idarəetmə müstəvisinin təsvirini “istədim və tərcümə etdim”. Bu təsvir mənə ən başa düşülən və maraqlı göründü və ən əsası “Bu, ümumiyyətlə lazımdırmı?” anlayışına gətirib çıxardı.
"Xidmət şəbəkəsi" ideyası son iki ildə getdikcə populyarlaşdıqca (Orijinal məqalə 10 oktyabr 2017-ci il) və məkanda iştirakçıların sayı artdıqca, mən bütün insanlar arasında çaşqınlığın mütənasib artımını gördüm. müxtəlif həllərin müqayisəsi və müqayisəsi ilə bağlı texnoloji icma.
Vəziyyət iyul ayında yazdığım aşağıdakı tvitlər seriyası ilə ən yaxşı şəkildə ümumiləşdirilir:
Xidmət şəbəkəsi çaşqınlığı №1: Linkerd ~ = Nginx ~ = Haproxy ~ = Elçi. Onların heç biri İstio ilə bərabər deyil. Istio tamamilə fərqli bir şeydir. 1 /
Birincisi sadəcə məlumat təyyarələridir. Özləri heç nə etmirlər. Onlar daha çox şey üçün əhval-ruhiyyədə olmalıdırlar. 2/
Istio, hissələri bir-birinə bağlayan idarəetmə təyyarəsinin nümunəsidir. Bu başqa bir təbəqədir. /son
Əvvəlki tvitlərdə bir neçə fərqli layihədən (Linkerd, NGINX, HAProxy, Envoy və Istio) bəhs edilir, lakin daha vacibi məlumat müstəvisi, xidmət şəbəkəsi və idarəetmə təyyarəsi kimi ümumi anlayışları təqdim edir. Bu yazıda mən bir addım geri çəkilib "məlumat müstəvisi" və "idarəetmə təyyarəsi" terminləri ilə nə demək istədiyimi çox yüksək səviyyədə danışacağam, daha sonra tvitlərdə qeyd olunan layihələrə şərtlərin necə tətbiq olunduğundan danışacağam.
Həqiqətən xidmət şəbəkəsi nədir?
Şəkil 1: Xidmət şəbəkəsinə ümumi baxış
Şəkil 1 xidmət şəbəkəsi anlayışını ən əsas səviyyədə təsvir edir. Dörd xidmət klasteri (AD) var. Hər bir xidmət nümunəsi yerli proxy server ilə əlaqələndirilir. Tək tətbiq nümunəsindən olan bütün şəbəkə trafiki (HTTP, REST, gRPC, Redis və s.) yerli proksi vasitəsilə müvafiq xarici xidmət qruplarına ötürülür. Bu yolla, tətbiq nümunəsi bütövlükdə şəbəkədən xəbərsiz olur və yalnız yerli proksidən xəbərdar olur. Faktiki olaraq, paylanmış sistem şəbəkəsi xidmətdən çıxarıldı.
Məlumat müstəvisi
Xidmət şəbəkəsində tətbiq üçün yerli olaraq yerləşən proxy server aşağıdakı vəzifələri yerinə yetirir:
- Xidmət kəşfi. Müraciətiniz üçün hansı xidmətlər/tətbiqlər mövcuddur?
- Sağlamlığın yoxlanılması. Xidmət kəşfi ilə qaytarılan xidmət nümunələri sağlamdır və şəbəkə trafikini qəbul etməyə hazırdırmı? Buraya həm aktiv (məsələn, cavab/sağlamlıq yoxlaması) və həm də passiv (məsələn, qeyri-sağlam xidmət vəziyyətinin göstəricisi kimi 3 ardıcıl 5xx səhvindən istifadə) sağlamlıq yoxlamaları daxil ola bilər.
- Marşrutlaşdırma. REST xidmətindən "/foo" sorğusu alarkən sorğu hansı xidmət klasterinə göndərilməlidir?
- Yük balansı. Marşrutlaşdırma zamanı xidmət klasteri seçildikdən sonra sorğu hansı xidmət nümunəsinə göndərilməlidir? Hansı fasilə ilə? Hansı dövrə kəsmə parametrləri ilə? Sorğu uğursuz olarsa, yenidən cəhd edilməlidir?
- Doğrulama və avtorizasiya. Daxil olan sorğular üçün zəng edən xidmət mTLS və ya başqa mexanizmdən istifadə etməklə kriptoqrafik olaraq müəyyən edilə/icazə verilə bilərmi? Əgər o, tanınıbsa/səlahiyyətlidirsə, xidmətdə tələb olunan əməliyyata (son nöqtə) zəng etməyə icazə verilirmi və ya təsdiqlənməmiş cavab qaytarılmalıdır?
- Müşahidə qabiliyyəti. Hər bir sorğu üçün ətraflı statistika, qeydlər/loqlar və paylanmış iz məlumatları yaradılmalıdır ki, operatorlar paylanmış trafik axını və yaranan kimi sazlama problemlərini başa düşə bilsinlər.
Məlumat müstəvisi xidmət şəbəkəsindəki bütün əvvəlki nöqtələrə cavabdehdir. Əslində, xidmətin yerli proksisi (sidecar) məlumat müstəvisidir. Başqa sözlə, məlumat təyyarəsi xidmətə və ya xidmətdən göndərilən hər bir şəbəkə paketinin şərti olaraq yayımlanması, yönləndirilməsi və monitorinqinə cavabdehdir.
İdarəetmə təyyarəsi
Yerli proksinin məlumat müstəvisində təmin etdiyi şəbəkə abstraksiya sehrlidir(?). Bununla belə, proksi əslində B xidmətinə gedən "/foo" marşrutu haqqında necə bilir? Proksi sorğuları ilə doldurulmuş xidmət kəşfi datasından necə istifadə etmək olar? Parametrlər yük balansı, fasilə, dövrə kəsilməsi və s. üçün necə konfiqurasiya edilir? Mavi/yaşıl metoddan və ya zərif trafik keçid metodundan istifadə edərək tətbiqi necə yerləşdirirsiniz? Sistem miqyasında autentifikasiya və avtorizasiya parametrlərini kim konfiqurasiya edir?
Yuxarıda göstərilən maddələrin hamısı xidmət şəbəkəsinin idarəetmə müstəvisinin nəzarəti altındadır. İdarəetmə təyyarəsi bir sıra təcrid olunmuş vətəndaşlığı olmayan proksiləri götürür və onları paylanmış sistemə çevirir.
Düşünürəm ki, bir çox texnoloqların məlumat müstəvisi və idarəetmə təyyarəsi ilə bağlı ayrı-ayrı anlayışları çaşdırıcı tapmasının səbəbi, əksər insanlar üçün məlumat müstəvisinin tanış olması, idarəetmə təyyarəsinin isə xarici/anlaşılmaz olmasıdır. Biz uzun müddətdir ki, fiziki şəbəkə marşrutlaşdırıcıları və açarları ilə işləyirik. Biz başa düşürük ki, paketlər/sorğular A nöqtəsindən B nöqtəsinə keçməlidir və bunu etmək üçün aparat və proqram təminatından istifadə edə bilərik. Yeni nəsil proqram proksiləri uzun müddətdir istifadə etdiyimiz alətlərin sadə versiyalarıdır.
Şəkil 2: İnsan idarəetmə təyyarəsi
Bununla belə, biz uzun müddətdir ki, idarəetmə təyyarələrindən istifadə edirik, baxmayaraq ki, əksər şəbəkə operatorları sistemin bu hissəsini heç bir texnoloji komponentlə əlaqələndirməyə bilər. Səbəbi sadədir:
Bu gün istifadə edilən əksər idarəetmə təyyarələri... biz.
Haqqında Şəkil 2 “İnsan idarəetmə təyyarəsi” adlandırdığım şeyi göstərir. Hələ də çox yayılmış olan bu yerləşdirmə növündə, ehtimal ki, qəzəbli insan operatoru statik konfiqurasiyalar yaradır - potensial olaraq skriptlər vasitəsilə - və onları bəzi xüsusi proses vasitəsilə bütün proksilərə yerləşdirir. Proksilər daha sonra bu konfiqurasiyadan istifadə etməyə başlayır və yenilənmiş parametrlərdən istifadə edərək məlumat müstəvisini emal etməyə başlayır.
Şəkil 3: Təkmil xidmət şəbəkəsi idarəetmə təyyarəsi
Haqqında Şəkil 3 xidmət şəbəkəsinin “uzatılmış” idarəetmə müstəvisini göstərir. O, aşağıdakı hissələrdən ibarətdir:
- İnsan: Hələ də bütövlükdə bütün sistemlə bağlı yüksək səviyyəli qərarlar verən bir şəxs (ümid edirəm ki, daha az qəzəbli) var.
- İdarəetmə təyyarəsi UI: Bir şəxs sistemi idarə etmək üçün bir növ istifadəçi interfeysi ilə qarşılıqlı əlaqə qurur. Bu veb portal, komanda xətti proqramı (CLI) və ya başqa bir interfeys ola bilər. İstifadəçi interfeysindən istifadə edərək operator qlobal sistem konfiqurasiya parametrlərinə çıxış əldə edir, məsələn:
- Yerləşdirməyə nəzarət, mavi/yaşıl və/və ya tədricən trafikə keçid
- Doğrulama və Avtorizasiya Seçimləri
- Marşrut cədvəlinin spesifikasiyası, məsələn, A proqramı "/foo" baş verənlər haqqında məlumat tələb etdikdə
- Yük balanslaşdırıcı parametrləri, məsələn, fasilələr, təkrar cəhdlər, dövrə kəsmə parametrləri və s.
- İş yükü planlayıcısı: Xidmətlər Kubernetes və ya Nomad kimi bir növ planlaşdırma/orkestrasiya sistemi vasitəsilə infrastrukturda idarə olunur. Planlayıcı yerli proksi ilə birlikdə xidmətin yüklənməsinə cavabdehdir.
- Xidmət kəşfi. Planlayıcı xidmət nümunələrini işə saldıqda və dayandırdıqda, sağlamlıq vəziyyətini xidmət kəşf sisteminə bildirir.
- Sidecar proxy konfiqurasiya API-ləri : Yerli proksilər operatorun müdaxiləsi olmadan sonda ardıcıl modeldən istifadə edərək müxtəlif sistem komponentlərindən vəziyyəti dinamik şəkildə çıxarır. Hazırda işləyən bütün xidmət nümunələrindən və yerli proksi serverlərdən ibarət bütün sistem son nəticədə bir ekosistemə birləşir. Elçinin universal məlumat təyyarəsi API-si bunun praktikada necə işlədiyinin bir nümunəsidir.
Əslində, idarəetmə təyyarəsinin məqsədi məlumat müstəvisi tərəfindən son nəticədə qəbul ediləcək siyasəti təyin etməkdir. Daha təkmil idarəetmə təyyarələri düzgün işləmək şərti ilə bəzi sistemlərin daha çox hissəsini operatordan çıxaracaq və daha az əl əməliyyatı tələb edəcək!...
Məlumat müstəvisi və idarəetmə təyyarəsi. Məlumat müstəvisi və idarəetmə təyyarəsinin xülasəsi
- Xidmət mesh məlumat təyyarəsi: Sistemdəki hər paketə/istəyə təsir edir. Tətbiq/xidmət kəşfi, sağlamlığın yoxlanılması, marşrutlaşdırma, yük balansı, autentifikasiya/icazə və müşahidə oluna bilmə üçün cavabdehdir.
- Xidmət şəbəkəsinə nəzarət təyyarəsi: Xidmət şəbəkəsi daxilində işləyən bütün məlumat təyyarələri üçün siyasət və konfiqurasiya təmin edir. Sistemdəki heç bir paketə/sorğuya toxunmur. İdarəetmə təyyarəsi bütün məlumat təyyarələrini paylanmış sistemə çevirir.
Cari layihə mənzərəsi
Yuxarıdakı izahı başa düşdükdən sonra xidmət şəbəkəsi layihəsinin hazırkı vəziyyətinə nəzər salaq.
- Məlumat təyyarələri: Linkerd, NGINX, HAProxy, Envoy, Traefik
- İdarəetmə təyyarələri: Istio, Nelson, SmartStack
Yuxarıdakı həllərin hər birinin dərin təhlilinə keçmək əvəzinə, hazırda ekosistemdə çoxlu çaşqınlığa səbəb olduğuna inandığım bəzi məqamlara qısaca toxunacağam.
Linkerd, 2016-cı ilin əvvəlində xidmət şəbəkəsi üçün ilk məlumat təyyarəsi proksi serverlərindən biri idi və xidmət şəbəkəsi dizayn modelinə diqqəti və məlumatlılığı artırmaq üçün fantastik iş görüb. Bundan təxminən 6 ay sonra Elçi Linkerdə qoşuldu (baxmayaraq ki, o, 2015-ci ilin sonundan Lyft-də idi). Linkerd və Envoy, xidmət şəbəkələrini müzakirə edərkən ən çox xatırlanan iki layihədir.
İstio 2017-ci ilin mayında elan edilib. Istio layihəsinin məqsədləri göstərilən genişləndirilmiş idarəetmə təyyarəsinə çox oxşardır Şəkil 3. Istio üçün elçi standart proxydir. Beləliklə, Istio idarəetmə müstəvisi, Elçi isə məlumat müstəvisidir. Qısa müddətdə Istio çox həyəcan yaratdı və digər məlumat təyyarələri Elçinin əvəzi kimi inteqrasiya etməyə başladı (həm Linkerd, həm də NGINX Istio ilə inteqrasiya nümayiş etdirdi). Fərqli məlumat müstəvilərinin eyni idarəetmə müstəvisində istifadə oluna bilməsi o deməkdir ki, idarəetmə müstəvisi və məlumat müstəvisi mütləq bir-birinə sıx bağlı deyil. Envoy-un ümumi məlumat təyyarəsi API kimi API sistemin iki hissəsi arasında körpü yarada bilər.
Nelson və SmartStack idarəetmə müstəvisi ilə məlumat müstəvisinin ayrılmasını daha ətraflı təsvir etməyə kömək edir. Nelson Envoy-dan proxy kimi istifadə edir və HashiCorp yığını əsasında xidmət şəbəkəsi üçün etibarlı idarəetmə təyyarəsi qurur, yəni. Nomad və s. SmartStack bəlkə də xidmət şəbəkələrinin yeni dalğasının birincisi idi. SmartStack HAProxy və ya NGINX ətrafında idarəetmə müstəvisi qurur və idarəetmə müstəvisini məlumat müstəvisindən xidmət şəbəkəsindən ayırmaq qabiliyyətini nümayiş etdirir.
Xidmət şəbəkəsi olan mikroservis arxitekturası getdikcə daha çox diqqəti cəlb edir (doğru olaraq!) və getdikcə daha çox layihə və satıcı bu istiqamətdə işləməyə başlayır. Növbəti bir neçə il ərzində biz həm məlumat müstəvisində, həm də idarəetmə müstəvisində çoxlu yeniliklər, eləcə də müxtəlif komponentlərin daha da qarışdırılacağını görəcəyik. Nəhayət, mikroservis arxitekturası operator üçün daha şəffaf və sehrli (?) olmalıdır.
İnşallah daha az və daha az qıcıqlanar.
Əsas çıxışlar
- Xidmət şəbəkəsi iki fərqli hissədən ibarətdir: məlumat müstəvisi və idarəetmə müstəvisi. Hər iki komponent tələb olunur və onlarsız sistem işləməyəcək.
- Hər kəs idarəetmə təyyarəsi ilə tanışdır və bu anda idarəetmə təyyarəsi siz ola bilərsiniz!
- Bütün məlumat təyyarələri xüsusiyyətlər, performans, konfiqurasiya və genişlənmə qabiliyyətinə görə bir-biri ilə rəqabət aparır.
- Bütün idarəetmə təyyarələri xüsusiyyətlərə, konfiqurasiyaya, genişlənməyə və istifadə rahatlığına görə bir-biri ilə rəqabət aparır.
- Bir idarəetmə müstəvisi düzgün abstraksiyaları və API-ləri ehtiva edə bilər ki, çoxsaylı məlumat təyyarələri istifadə oluna bilsin.
Mənbə: www.habr.com