İnternetdə (xidmət şəbəkəsi) və burada başqa biri var. Yaşasın! Bəs niyə? Sonra fikrimi bildirmək istəyirəm ki, xidmət şəbəkələri 10 il əvvəl, Docker və Kubernetes kimi konteyner platformalarının yaranmasından əvvəl daha yaxşı olardı. Mən demirəm ki, mənim baxış bucağım başqalarından daha yaxşı və ya pisdir, lakin xidmət şəbəkələri olduqca mürəkkəb heyvanlar olduğundan, çoxsaylı baxış nöqtələri onları daha yaxşı başa düşməyə kömək edəcək.
Mən yüzdən çox mikroservis üzərində qurulmuş və konteynerlərdə minlərlə tətbiqi dəstəkləyən dotCloud platforması haqqında danışacağam. Mən onu inkişaf etdirərkən və işə salarkən qarşılaşdığımız çətinlikləri və xidmət şəbəkələrinin necə kömək edə biləcəyini (və ya olmaya biləcəyini) izah edəcəyəm.
dotcloud tarixi
Artıq dotCloud-un tarixi və bu platforma üçün arxitektura seçimi haqqında yazmışam, lakin şəbəkə qatı haqqında çox danışmamışam. Oxumaq istəmirsinizsə dotCloud haqqında, bunun mahiyyəti budur: bu, müştərilərə geniş çeşidli məlumat xidmətlərini (Java, PHP, Python...) idarə etməyə imkan verən xidmət kimi PaaS platformasıdır. MongoDB, MySQL, Redis...) və Heroku kimi iş axını: siz kodunuzu platformaya yükləyirsiniz, o, konteyner şəkillərini qurur və onları yerləşdirir.
Mən sizə trafikin dotCloud platformasına necə göndərildiyini söyləyəcəyəm. Xüsusilə sərin olduğuna görə yox (baxmayaraq ki, sistem öz vaxtı üçün yaxşı işləyirdi!), lakin ilk növbədə ona görə ki, müasir alətlərin köməyi ilə belə bir dizayn təvazökar bir komanda tərəfindən qısa müddətdə asanlıqla həyata keçirilə bilər, əgər onlara marşrut üçün bir yol lazımdırsa. bir dəstə mikroservis və ya bir sıra proqramlar arasında trafik. Beləliklə, variantları müqayisə edə bilərsiniz: hər şeyi özünüz inkişaf etdirsəniz və ya mövcud xidmət şəbəkəsindən istifadə etsəniz nə olacaq. Standart seçim: özünüz edin və ya satın alın.
Yerləşdirilmiş proqramlar üçün trafik marşrutu
DotCloud-dakı proqramlar HTTP və TCP son nöqtələrini ifşa edə bilər.
HTTP son nöqtələri dinamik olaraq yük balanslaşdırıcı klaster konfiqurasiyasına əlavə edilmişdir . Bu, resursların bu gün etdiklərinə bənzəyir Kubernetesdə və yük balanslaşdırıcısı kimi .
Müştərilər uyğun domenlər vasitəsilə HTTP son nöqtələrinə qoşulurlar, domen adı nöqtələri dotCloud yük balanslaşdırıcılarına verir. Xüsusi heçnə.
TCP son nöqtələri port nömrəsi ilə əlaqələndirilir, daha sonra mühit dəyişənləri vasitəsilə həmin yığındakı bütün konteynerlərə ötürülür.
Müştərilər müvafiq host adı (gateway-X.dotcloud.com kimi) və port nömrəsindən istifadə edərək TCP son nöqtələrinə qoşula bilər.
Bu host adı "nats" server klasterinə həll olunur ( ) daxil olan TCP bağlantılarını düzgün konteynerə (və ya yük balanslaşdırılmış xidmətlər vəziyyətində, düzgün konteynerlərə) yönləndirəcək.
Kubernetes ilə tanışsınızsa, bu, yəqin ki, sizə xidmətləri xatırladacaq .
dotCloud platformasında ekvivalent xidmətlər yox idi : sadəlik üçün xidmətlərə giriş həm platforma daxilində, həm də kənardan eyni şəkildə baş verdi.
Hər şey olduqca sadə şəkildə təşkil edildi: HTTP və TCP marşrutlaşdırma şəbəkələrinin orijinal tətbiqləri, ehtimal ki, Python-un yalnız bir neçə yüz xətti idi. Platformanın böyüməsi və əlavə tələblərin ortaya çıxması ilə təkmilləşdirilmiş sadə (mən deyərdim, sadəlövh) alqoritmlər.
Mövcud kodun geniş refaktorinqi tələb olunmur. Xüsusilə, mühit dəyişənləri vasitəsilə əldə edilən ünvandan birbaşa istifadə edə bilər.
Bu müasir xidmət şəbəkəsindən nə ilə fərqlənir?
Məhdud görünürlük. Bizdə ümumiyyətlə TCP marşrutlaşdırma şəbəkəsi üçün heç bir ölçü yox idi. HTTP marşrutlaşdırmasına gəldikdə, daha yeni versiyalarda səhv kodları və cavab vaxtları ilə ətraflı HTTP ölçüləri var, lakin müasir xidmət şəbəkələri, məsələn, Prometheus kimi ölçü toplama sistemləri ilə inteqrasiyanı təmin edərək daha da irəli gedir.
Görünüş təkcə əməliyyat baxımından deyil (problemləri həll etmək üçün), həm də yeni funksiyalar buraxıldıqda vacibdir. Təhlükəsizliyə dair söhbət и .
Marşrutlaşdırma səmərəliliyi də məhduddur. DotCloud marşrutlaşdırma şəbəkəsində bütün trafik xüsusi marşrutlaşdırma qovşaqlarının çoxluğundan keçməli idi. Bu, potensial olaraq çoxsaylı AZ (mövcudluq zonası) sərhədlərini keçmək və gecikmə müddətində əhəmiyyətli artım demək idi. Hər səhifədə yüzdən çox SQL sorğusu yaradan və hər sorğu üçün SQL serverinə yeni bağlantı açan problemlərin aradan qaldırılması kodunu xatırlayıram. Lokal olaraq işə salındıqda, səhifə dərhal yüklənir, lakin dotCloud-da yüklənməsi bir neçə saniyə çəkir, çünki hər TCP bağlantısı (və sonrakı SQL sorğusu) onlarla millisaniyə çəkir. Bu vəziyyətdə, davamlı əlaqələr problemi həll etdi.
Müasir xidmət şəbəkələri bu cür problemlərin öhdəsindən daha yaxşı gəlir. Hər şeydən əvvəl, əlaqələri marşrutlaşdırıb yoxlayırlar mənbədə. Məntiqi axın eynidir: клиент → меш → сервис, lakin indi mesh yerli işləyir və uzaq qovşaqlarda deyil, buna görə də əlaqə клиент → меш yerli və çox sürətlidir (mikrosaniyələr əvəzinə).
Müasir xidmət şəbəkələri daha ağıllı yük balanslaşdırma alqoritmlərini də tətbiq edir. Arxa tərəflərin sağlamlığına nəzarət etməklə, daha sürətli arxa tərəflərə daha çox trafik göndərə bilər və nəticədə daha yaxşı ümumi performans əldə edilir.
təhlükəsizlik həm də daha yaxşıdır. DotCloud marşrutlaşdırma şəbəkəsi tamamilə EC2 Classic-də işləyirdi və trafiki şifrələmirdi (bu ehtimalla ki, kimsə EC2 şəbəkə trafikinə sniffer qoya bilsə, artıq böyük problemlə üzləşirsiniz). Müasir xidmət şəbəkələri, məsələn, qarşılıqlı TLS autentifikasiyası və sonrakı şifrələmə ilə bütün trafikimizi şəffaf şəkildə qoruyur.
Platforma xidmətləri üçün trafik marşrutu
Yaxşı, biz proqramlar arasında trafiki müzakirə etdik, bəs dotCloud platformasının özü haqqında nə demək olar?
Platformanın özü müxtəlif funksiyalara cavabdeh olan yüzə yaxın mikroservisdən ibarət idi. Bəziləri başqalarının sorğularını qəbul edirdi, bəziləri isə digər xidmətlərə qoşulan, lakin özləri əlaqələri qəbul etməyən fon işçiləri idi. Hər iki halda, hər bir xidmət qoşulmaq üçün lazım olan ünvanların son nöqtələrini bilməlidir.
Bir çox yüksək səviyyəli xidmətlər yuxarıda təsvir edilən marşrutlaşdırma şəbəkəsindən istifadə edə bilər. Əslində, XNUMX-dən çox dotCloud mikroxidmətinin çoxu dotCloud platformasının özündə adi proqramlar kimi yerləşdirilmişdir. Lakin az sayda aşağı səviyyəli xidmətlərə (xüsusən də bu marşrutlaşdırma şəbəkəsini həyata keçirənlərə) daha sadə, daha az asılılıq tələb olunurdu (çünki onlar işləmək üçün özlərindən asılı ola bilməzdilər - köhnə toyuq və yumurta problemi).
Bu aşağı səviyyəli, əsas xidmətlər konteynerləri birbaşa bir neçə əsas qovşaqda işlətməklə yerləşdirildi. Eyni zamanda, standart platforma xidmətləri cəlb edilməyib: bağlayıcı, planlaşdırıcı və qaçışçı. Müasir konteyner platformaları ilə müqayisə etmək istəyirsinizsə, bu, idarəetmə təyyarəsini işə salmağa bənzəyir docker run tapşırığı Kubernetes-ə həvalə etmək əvəzinə birbaşa qovşaqlarda. Konsepsiya baxımından olduqca oxşardır , istifadə edən və ya müstəqil klasteri yükləyərkən.
Bu xidmətlər sadə və kobud şəkildə ifşa olundu: YAML faylı onların adlarını və ünvanlarını sadaladı; və hər bir müştəri yerləşdirmə üçün bu YAML faylının surətini götürməli idi.
Bir tərəfdən bu, son dərəcə etibarlıdır, çünki o, Zookeeper kimi xarici açar/dəyər anbarının dəstəyini tələb etmir (xatırlayın, etcd və ya Konsul o zaman mövcud deyildi). Digər tərəfdən, bu, xidmətlərin daşınmasını çətinləşdirirdi. Hər dəfə bir hərəkət ediləndə, bütün müştərilər yenilənmiş YAML faylını (və potensial olaraq yenidən yükləməli) almalı idilər. Çox rahat deyil!
Sonradan hər bir müştərinin yerli proxy serverə qoşulduğu yeni sxemi tətbiq etməyə başladıq. Ünvan və port əvəzinə yalnız xidmətin port nömrəsini bilmək və vasitəsilə əlaqə saxlamaq lazımdır localhost. Yerli proksi bu əlaqəni idarə edir və onu faktiki serverə yönləndirir. İndi arxa ucu başqa bir maşına köçürərkən və ya miqyaslandırarkən, bütün müştəriləri yeniləmək əvəzinə, yalnız bütün bu yerli proksiləri yeniləmək lazımdır; və yenidən yükləmə artıq tələb olunmur.
(Həmçinin TLS bağlantılarında trafikin inkapsulyasiyası və qəbul edən tərəfdə başqa bir proksi serverin quraşdırılması, həmçinin yalnız bağlantıları qəbul etmək üçün konfiqurasiya edilmiş qəbuledici xidmətin iştirakı olmadan TLS sertifikatlarının yoxlanması planlaşdırılırdı. localhost. Bu haqda daha sonra).
Bu çox oxşardır Airbnb-dən, lakin əhəmiyyətli fərq SmartStack-in tətbiqi və istehsala yerləşdirilməsidir, dotCloud-un daxili marşrutlaşdırma sistemi isə dotCloud Docker-ə çevrildikdə qutuya qoyulmuşdur.
Mən şəxsən SmartStack-i Istio, Linkerd və Consul Connect kimi sistemlərin sələflərindən biri hesab edirəm, çünki onların hamısı eyni nümunəyə əməl edir:
- Hər qovşaqda bir proxy işlədin.
- Müştərilər proksiyə qoşulur.
- Nəzarət müstəvisi arxa uçlar dəyişdikdə proxy konfiqurasiyasını yeniləyir.
- ... Mənfəət!
Müasir Xidmət Mesh Tətbiqi
Bu gün oxşar bir şəbəkə tətbiq etmək lazımdırsa, oxşar prinsiplərdən istifadə edə bilərik. Məsələn, xidmət adlarını məkandakı ünvanlara uyğunlaşdırmaqla daxili DNS zonası qurun 127.0.0.0/8. Sonra hər bir xidmət ünvanında (həmin alt şəbəkədə) bağlantıları qəbul edərək, hər bir klaster node-da HAProxy-ni işə salın 127.0.0.0/8) və yükün müvafiq arxa tərəflərə yönləndirilməsi/balanslaşdırılması. HAProxy konfiqurasiyası idarə edilə bilər , backend məlumatlarını etcd və ya Consul-da saxlamağa və lazım olduqda avtomatik olaraq yenilənmiş konfiqurasiyanı HAProxy-ə köçürməyə imkan verir.
Istio belə işləyir! Ancaq bəzi fərqlərlə:
- İstifadə edir HAProxy əvəzinə.
- etcd və ya Consul əvəzinə Kubernetes API vasitəsilə arxa uç konfiqurasiyasını saxlayır.
- Xidmətlər 127.0.0.0/8 əvəzinə daxili alt şəbəkədə ünvanlar ayrılır (Kubernetes ClusterIP ünvanları).
- Müştəri və serverlər arasında qarşılıqlı TLS autentifikasiyası əlavə etmək üçün əlavə komponentə (Citadel) malikdir.
- Dövrə kəsmə, paylanmış izləmə, kanareyka yerləşdirmə və s. kimi yeni funksiyaları dəstəkləyir.
Gəlin bəzi fərqlərə qısaca nəzər salaq.
Elçi Proksi
Envoy Proxy Lyft [Uber-in taksi bazarındakı rəqibi - təqribən. başına]. Bu, bir çox cəhətdən digər proksilərə (məsələn, HAProxy, Nginx, Traefik...) bənzəyir, lakin Lyft öz xüsusiyyətlərini yazdı, çünki digər proksilərin malik olmadığı xüsusiyyətlərə ehtiyac duydular və genişləndirməkdənsə, yenisini yaratmaq daha məqsədəuyğun görünürdü. mövcud olan.
Elçi özü tərəfindən istifadə edilə bilər. Başqa xidmətlərə qoşulmalı olan xüsusi xidmətim varsa, mən onu Envoy-a qoşulmaq üçün quraşdıra və daha sonra digər xidmətlərin yeri ilə Envoy-u dinamik şəkildə konfiqurasiya edib yenidən konfiqurasiya edə, eyni zamanda görünürlük kimi bir çox əla əlavələr əldə edə bilərəm. Fərdi müştəri kitabxanası və ya zəng izləmə koduna inyeksiya əvəzinə biz Envoy-a trafik göndəririk və o, bizim üçün ölçüləri toplayır.
Amma Elçi olaraq da işləyə bilir məlumat müstəvisi (məlumat müstəvisi) xidmət şəbəkəsi üçün. Bu o deməkdir ki, indi bu xidmət şəbəkəsi üçün Elçi konfiqurasiya edilib idarəetmə təyyarəsi (idarəetmə təyyarəsi).
İdarəetmə təyyarəsi
İdarəetmə müstəvisində, Istio Kubernetes API-yə əsaslanır. Bu confd istifadə etməkdən çox da fərqlənmir, məlumat anbarında bir sıra açarları axtarmaq üçün etcd və ya Konsuldan istifadə edir. Istio, Kubernetes API vasitəsilə bir sıra Kubernetes resurslarına baxır.
Bu və sonra arasında: Mən şəxsən bunu faydalı hesab etdim hansı oxuyur:
Kubernetes API Server saxlama, versiyalaşdırma, yoxlama, yeniləmə və API resurs semantikasını təklif edən "axmaq serverdir".
Istio Kubernetes ilə işləmək üçün nəzərdə tutulmuşdur; və onu Kubernetes xaricində istifadə etmək istəyirsinizsə, onda siz Kubernetes API serverinin (və etcd köməkçi xidməti) nümunəsini işə salmalısınız.
Xidmət Ünvanları
Istio Kubernetesin ayırdığı ClusterIP ünvanlarına güvənir, buna görə də Istio xidmətləri daxili ünvan əldə edir (aralıqda deyil) 127.0.0.0/8).
Istio olmadan Kubernetes klasterində xüsusi xidmət üçün ClusterIP ünvanına trafik kube-proxy tərəfindən ələ keçirilir və proksinin arxa ucuna göndərilir. Əgər texniki detallarla maraqlanırsınızsa, kube-proxy ClusterIP ünvanına gedən bağlantıların təyinat IP ünvanlarını yenidən yazmaq üçün iptables qaydalarını (və ya konfiqurasiyasından asılı olaraq IPVS yük balanslaşdırıcıları) təyin edir.
Istio bir Kubernetes klasterində quraşdırıldıqdan sonra, konteyner təqdim etməklə müəyyən bir istehlakçı və ya hətta bütün ad sahəsi üçün açıq şəkildə aktivləşdirilənə qədər heç bir şey dəyişmir. sidecar xüsusi podlara. Bu konteyner Envoy instansiyasını işə salacaq və digər xidmətlərə gedən trafikin qarşısını almaq və həmin trafiki Envoy-a yönləndirmək üçün bir sıra iptables qaydaları quracaq.
Kubernetes DNS ilə inteqrasiya edildikdə, bu o deməkdir ki, kodumuz xidmət adı ilə qoşula bilər və hər şey "sadəcə işləyir". Başqa sözlə, kodumuz kimi sorğular verir http://api/v1/users/4242sonra api üçün müraciəti həll etmək 10.97.105.48, iptables qaydaları 10.97.105.48-dən bağlantıları kəsir və onları sorğunu faktiki API backendinə yönləndirəcək yerli Envoy proksisinə yönləndirir. vay!
Əlavə fırfırlar
Istio həmçinin mTLS (qarşılıqlı TLS) vasitəsilə uçdan uca şifrələmə və autentifikasiya təmin edir. Komponent çağırılır Citadel.
Bir komponent də var Qarışdırıcı, hansı Elçinin tələb edə bilər hər biri başlıqlar, arxa uçun yüklənməsi və s. kimi müxtəlif amillərdən asılı olaraq həmin sorğu ilə bağlı xüsusi qərar qəbul etməyi tələb edin... (narahat olmayın: Mikserin işləməsini təmin etmək üçün bir çox alət var və hətta qəzaya uğrasa belə, Elçi işləməyə davam edəcək. proxy kimi).
Və təbii ki, biz görmə qabiliyyətini qeyd etdik: Elçi paylanmış izləmə təmin edərkən çoxlu ölçülər toplayır. Mikroxidmətlər arxitekturasında, əgər tək API sorğusunun A, B, C və D mikroservislərindən keçməsi lazımdırsa, daxil olduqdan sonra paylanmış izləmə sorğuya unikal identifikator əlavə edəcək və bu identifikatoru bütün bu mikroxidmətlərə alt sorğular vasitəsilə saxlayacaq. bütün əlaqəli zəngləri, onların gecikmələrini və s.
İnkişaf etdirin və ya satın alın
Istio mürəkkəb bir sistem kimi tanınır. Bunun əksinə olaraq, bu yazının əvvəlində təsvir etdiyim marşrutlaşdırma şəbəkəsini qurmaq mövcud alətlərlə nisbətən asandır. Beləliklə, bunun əvəzinə öz xidmət şəbəkənizi yaratmağın mənası varmı?
Təvazökar ehtiyaclarımız varsa (görünürlük, elektrik açarı və digər incəliklərə ehtiyacımız yoxdur), onda düşüncələr öz alətimizi inkişaf etdirməklə bağlıdır. Lakin Kubernetes-dən istifadə ediriksə, buna ehtiyac olmaya bilər, çünki Kubernetes artıq xidmət kəşfi və yük balansı üçün əsas alətləri təmin edir.
Ancaq qabaqcıl tələblərimiz varsa, xidmət şəbəkəsini "almaq" daha yaxşı seçim kimi görünür. (Istio açıq mənbə olduğundan bu, həmişə "alış" deyil, lakin biz hələ də onu anlamaq, yerləşdirmək və idarə etmək üçün mühəndislik vaxtını sərf etməliyik.)
Nə seçmək lazımdır: Istio, Linkerd və ya Consul Connect?
İndiyə qədər biz yalnız Istio haqqında danışdıq, lakin bu, yeganə xidmət şəbəkəsi deyil. Populyar alternativdir , amma daha çoxu var .
Nə seçmək lazımdır?
Düzünü desəm, bilmirəm. Hazırda bu suala cavab vermək üçün özümü kifayət qədər bacarıqlı hesab etmirəm. Bir neçə var bu vasitələrin müqayisəsi ilə və hətta .
Bir perspektivli yanaşma kimi bir vasitədən istifadə etməkdir . O, xidmət şəbəkələri tərəfindən təmin edilən API-ləri sadələşdirmək və birləşdirmək üçün abstraksiya qatını həyata keçirir. Müxtəlif xidmət şəbəkələrinin spesifik (və mənim fikrimcə, nisbətən mürəkkəb) API-lərini öyrənmək əvəzinə, biz daha sadə SuperGloo konstruksiyalarından istifadə edə bilərik - və asanlıqla birindən digərinə keçid edə bilərik, sanki HTTP interfeyslərini və arxa tərəflərini təsvir edən ara konfiqurasiya formatımız var idi. Nginx, HAProxy, Traefik, Apache… üçün faktiki konfiqurasiya yaratmağa qadirdir.
Istio və SuperGloo ilə bir az oynadım və növbəti məqalədə SuperGloo-dan istifadə edərək mövcud klasterə Istio və ya Linkerd-i necə əlavə edəcəyimi və sonuncunun öz işini necə görəcəyini, yəni sizə keçid etməyə imkan verdiyini göstərmək istəyirəm. konfiqurasiyaları yenidən yazmadan bir xidmət şəbəkəsini digərinə köçürün.
Mənbə: www.habr.com