Qeyd. tərc.: Service mesh — bir fenomen ki, hələ də rus dilində davamlı bir tərcüməsi yoxdur (2 ildən çox əvvəl «xidmətlər üçün şəbəkə» variantını təklif etmişdik və bir müddət sonra bəzi həmkarlar «xidmət duzdu» ifadəsini aktiv şəkildə irəlilətməyə başladılar). Bu texnologiya ilə bağlı müzakirələr, marketinq və texniki tərəflərin çox yaxından bağlı olduğu bir vəziyyətə gətirib çıxardı. Bu orijinal terminlərin müəlliflərindən biri tərəfindən yazılmış mükəmməl material mühəndislər üçün və yalnız onlara aydınlıq gətirmək məqsədini güdür.
Komiks
Giriş
Əgər siz proqram mühəndisisinizsə və arxa sistemlərdə işləyirsinizsə, «service mesh» termininin son bir neçə ildə şüur altınıza yerleşdiyinə şübhə yoxdur. Təəccüblü bir cəngəllik səbəbindən, bu söz birləşməsi sənayeni getdikcə daha çox ələ alır, və bununla bağlı olan hype və reklam təklifləri, aşağıya doğru sürüşən bir qar topu kimi sürətini artırır.
Service mesh, cloud native ekosisteminin murdar, əyilmiş sularda yaranmışdır. Təəssüf ki, bu, ona dair müzakirələrin «aşağı kalorili söhbətlərdən» və — texniki jargonla — açıq şəkildə cəfəngiyat olanlara qədər dəyişməsinə səbəb olur. Ancaq bütün bu səsi ayırdığınızda, service mesh-in tamamilə real, müəyyən və vacib bir funksiyası olduğunu görmək mümkündür.
Bu nəşrdə mən, məhz bunu etməyə çalışacağam: service mesh üçün ədalətli, dərin, mühəndislərə odaklanmış bir bələdçi təqdim edəcəyəm. Mən, yalnız sualı cavablandırmayacağam: «Bu nədir?», — həm də «Niyə?», eləcə də «Niyə məhz indi?». Nəhayət, bu texnologiyanın niyə (mənim fikrimcə) bu dərəcədə dəli bir ehtiras yaratdığını təsvir etməyə çalışacağam, bu özü də maraqlı bir hekayədir.
Mən kiməm?
Hər kəsə salam! Mənim adım . Mən service mesh-in ilk layihəsi olan — bu terminə sebəb olan layihədir (bağışlayın, dostlar!). service mesh Tərcümə ilə bağlı. (: Deyim ki, bu termin ilk ortaya çıxanda, 2,5 ildən çox əvvəl, biz artıq eyni müəllifin «Service mesh nədir və niyə ona ehtiyacım var [mikroservisli bulud tətbiqi üçün]?».) Buoyant Dive .
«Niyə bu qədər service mesh müzakirə olunur?» «Почему так много разговоров о service mesh?», — burada öz fikirlərimi paylaşacağım. Bu rəhbərliyi mümkün qədər obyektiv etmək üçün bütün gücümü sərf edəcəyəm. Konkret misallarda əsasən Linkerd'in təcrübəsinə əsaslanacağam, eyni zamanda digər növ service mesh-lərin tətbiqindəki tanıdığım fərqlilikləri göstərəcəyəm (əgər varsa).
Tamam, indi dadlı şeylərə keçməyin vaxtıdır.
Service mesh nədir?
Bütün bu həvəsə baxmayaraq, struktural olaraq service mesh olduqca sadədir. Bu, sadəcə olaraq servislərin "yanında" yerləşdirilmiş bir dəstə userspace-proxy'dir (daha sonra "yanında" nə demək olduğunu bir az danışacağıq) və bir dəstə idarəetmə prosesidir. Proxy'lər birgə şəkildə data plane, idarəetmə prosesləri isə control planeadlanır. Data plane servislər arasında çağırışları ələ keçirir və onlarla "hansısa işlər" görür; control plane isə, müvafiq olaraq, proxy'nin davranışını əlaqələndirir və sizin, yəni operatorun API-yə girişini təmin edir, şəbəkəni manipulyasiya etməyə və onu bütöv bir bütün olaraq ölçməyə imkan tanıyır.
Bu proxy-lər nə edir? Aydın görünür ki, onlar servislərə və onlardan çağırışları proxy-ləyir (düzdür, onlar proxy və reverse proxy funksiyasını yerinə yetirir, həm gələn, həm də gedən çağırışları emal edir). Və onlar çağırışlara yönəlmiş bir sıra funksiyaları icra edirlər servislər arasında. Bu proxy-lərin servislər arasındakı trafikə fokuslanması, service mesh-proxy'lərini, məsələn, API qapıları və ingress-proxy'lardan fərqləndirir (onlar xarici dünyadan klasterə gələn çağırışlara fokuslanır). : Kubernetes üçün mövcud Ingress kontrolçularının müqayisəsi, bunlardan bir çoxu artıq qeyd olunan Envoy-dan istifadə edir, baxın Aşağıda Linkerd'də control plane və data plane-in sxemi təqdim olunur. Göründüyü kimi, control plane bir neçə fərqli komponentdən ibarətdir, bunlar arasında proxy-serverlərdən metrikləri toplayan Prometheus nümunəsi, eləcə də
destination (xidmətlərin aşkar edilməsi), identity (Qeyd. tərc.(sertifikat mərkəzi, CA) və .)
public-api
Ниже представлена схема control plane и data plane в Linkerd. Как видно, control plane включает в себя несколько различных компонентов, в том числе экземпляр Prometheus, который собирает метрики с прокси-серверов, а также другие компоненты, такие как destination (обнаружение сервисов), identity (центр сертификации, CA) и public-api (web və CLI üçün endpoint-lər). Buna nisbətən, data plane tətbiq nümunəsinin yanında sadə bir linkerd-proxy'dir. Bu, yalnız məntiqi bir sxemdir; reallıqda yerləşdirmə zamanı hər bir control plane komponentinin üç replikası və data plane-də yüzlərlə və ya minlərlə proxy ola bilər.
(Bu sxemdəki mavi düzbucaqlar Kubernetes pod’larının sərhədlərini simvolizə edir. Görünür ki, linkerd-proxy konteynerləri tətbiq konteynerləri ilə eyni pod’da yerləşir. Bu cür sxem sidecar konteyneri.)
service mesh arxitekturasının bir neçə mühüm nəticəsi var. Birincisi, proxy-nin məqsədi xidmətlər arasında çağırışları ələ keçirmək olduğuna görə, service mesh yalnız tətbiqiniz müəyyən bir xidmətlər dəstinə görə hazırlanmışsa mənalıdır. Mesh seçmək monolitlərlə istifadə oluna bilər, lakin bu, tək bir proxy üçün aydın şəkildə artıqdır, həm də onun funksiyaları böyük ehtimalla tələb olunmayacaq.
Başqa bir mühüm nəticə odur ki, service mesh böyük sayıda proxy tələb edir. Əslində, Linkerd hər xidmət nümunəsinin yanında linkerd-proxy yerləşdirir (digər tətbiqlər proxy-ləri hər bir düyünə / ev sahibinə / virtual maşına əlavə edirlər. Hər halda, bu, az deyil). Proxy-lərin bu qədər aktiv istifadəsi özlüyündə bir sıra əlavə çətinliklər gətirir:
- Data plane-dəki proxy-lər sürətliolmalıdır, çünki hər bir çağırış üçün proxy-ə iki müraciət olunur: biri müştəri tərəfində, biri isə server tərəfində.
- Eyni zamanda proxy-lər kiçik və olar.Hər birinin yaddaş və CPU resurslarını istehlak edəcək və bu istehlak tətbiq ilə xətti olaraq artacaq.
- Siz çox sayda proxy yerləşdirmək və yeniləmək üçün bir mexanizmə ehtiyacınız olacaq. Bunu əl ilə etmək seçimi yoxdur.
Ümumiyyətlə, service mesh belə görünür (ən azından quş uçuşundan): siz bir çox userspace-proxy yerləşdirirsiniz ki, onlar daxili, xidmətlərarası trafiki "nəyisə edirlər" və control plane-dən onları izləmək və idarə etmək üçün istifadə edirsiniz.
İndi "Niyə?" sualının vaxtı çatdı.
Service mesh nə üçündür?
Service mesh ideyası ilə ilk dəfə üzləşənlər üçün yüngül narahatlıq hiss etmək tamamilə başa düşüləndir. Service mesh tərtibatı deməkdir ki, o, yalnız tətbiqdakı gecikmələri artırmır, həm də resursları istehlak edir və infrastrukturda bir çox yeni mexanizmləri əlavə edir. Əvvəlcə siz service mesh quraşdırırsınız, sonra birdən-birə yüzlərlə (əgər minlərlə deyil) proxy ilə məşğul olmağın lazım olduğunu aşkar edirsiniz. Suallar yaranır, kim buna öz iradəsi ilə gedəcək?
Bu sualın cavabı iki hissədən ibarətdir. Birincisi, bu proxy-lərin yerləşdirilməsi ilə bağlı əməliyyat xərcləri ekosistem içində baş verən bir sıra dəyişikliklərlə əhəmiyyətli dərəcədə azaldıla bilər (bunun haqqında daha sonra daha ətraflı).
İkincisi, bu tür bir cihaz aslında sisteme ek mantık eklemenin mükemmel bir yoludur. Bu, yalnızca service mesh ile birçok yeni özellik eklenebilmesi nedeniyle değil, aynı zamanda bunu ekosisteme müdahale etmeden yapabilme imkanı sunduğu için de böyledir. Aslında service mesh'in tüm modeli bu ilkeye dayanmaktadır: çoklu hizmet sistemi içinde, ne olursa olsun, bireysel hizmetlerin trafik arasında ek fonksiyonalite eklemek için mükemmel bir noktadır.
Örneğin, Linkerd’de (ve çoğu mesh’de) fonksiyonellik ağırlıklı olarak HTTP çağrılarına odaklanmaktadır; bu, HTTP/2 ve gRPC’yi de kapsar. Fonksiyonellik oldukça kapsamlıdır — üç sınıfa ayrılabilir:
- İle ilgili fonksiyonlar güvenilirlik. Tekrar eden istekler, zaman aşımı, kanarya yaklaşımı (trafik ayırma/yönlendirme) vb.
- İle ilgili fonksiyonlar izleme. Başarılı oranlar, gecikmeler ve her hizmet veya belirli yönergeler için istek hacimlerinin toplanması; hizmetlerin topolojik haritalarını oluşturma vb.
- İle ilgili fonksiyonlar güvenlik. Mutual TLS, erişim kontrolü vb.
* Linkerd açısından gRPC’nin HTTP/2’den pek bir farkı yoktur: yalnızca yükte protobuf kullanılır. Geliştirici açısından bu iki şey elbette farklıdır.
Bu mekanizmaların çoğu istek düzeyinde çalışır (bu nedenle ‘L7-proxy’ olarak adlandırılır). Örneğin, Foo hizmeti Bar hizmetine bir HTTP çağrısı gönderdiğinde, Foo tarafındaki linkerd-proxy akıllı yük dengelemesi yapabilir ve gözlemlenen gecikmeye bağlı olarak Foo'dan Bar’ın örneklerine çağrılar yönlendirebilir; gerekirse isteği tekrarlayabilir (ve bu idempotent ise); yanıt kodunu ve bekleme süresini kaydedebilir vb. Benzer şekilde, Bar tarafındaki linkerd-proxy, istek izin verilmediyse veya istek sınırı aşıldıysa isteği reddedebilir; kendi tarafındaki gecikmeyi kaydedebilir vb.
Proxy'ler bağlantı düzeyinde de ‘bir şeyler yapabilir’. Örneğin, Foo tarafındaki linkerd-proxy bir TLS bağlantısı başlatırken, Bar tarafındaki linkerd-proxy bu bağlantıyı koparabilir ve her iki taraf da birbirlerinin TLS sertifikalarını kontrol edebilir*. Bu, yalnızca hizmetler arasında şifreleme sağlamakla kalmaz, aynı zamanda hizmetlerin kimliğini kriptografik olarak güvenli bir şekilde doğrulamanın bir yolunu sunar: Foo ve Bar, kendilerini tanıttıkları gibi olduklarını ‘kanıtlayabilir’ler.
* ‘Birbirini’ ifadesi, istemci sertifikasının da doğrulandığı anlamına gelir (mutual TLS). ‘Klasik’ TLS'de, örneğin, bir tarayıcı ve sunucu arasında, genellikle yalnızca bir tarafın (sunucunun) sertifikası doğrulanır.
İster istek ister bağlantı düzeyinde çalışsın, tüm service mesh fonksiyonlarının operasyonel olduğunu vurgulamak önemlidir. işletme Linkerd, yükün semantikasını dönüştürə bilmir — məsələn, JSON parçasına sahələr əlavə etmək və ya protobuf-da dəyişikliklər etmək. Bu vacib xüsusiyyəti daha sonra ESB və middleware haqqında danışarkən müzakirə edəcəyik.
Bu, service mesh-in təqdim etdiyi funksiyaların dəstidir. Suallar yaranır: niyə bunları birbaşa tətbiqdə həyata keçirməyək? Ümumiyyətlə, proxy ilə əlaqə qurmağın mənası nədir?
Niyə service mesh yaxşı bir fikirdir
Service mesh-in imkanları heyrətləndiricidir, amma onun əsas dəyəri əslində funksiyalarda deyil. Nəticədə, biz bunları birbaşa tətbiqdə reallaşdıra bilərik (daha sonra görəcəyik ki, service mesh-in meydana gəlməsi belə olub). Bu düşüncəni bir cümlə ilə ifadə etsək, service mesh-in dəyəri budur: bu, müasir server proqram təminatının işləməsi üçün kritik əhəmiyyət kəsb edən funksiyaları, bütün yığın üçün eyni və tətbiq kodundan asılı olmayaraq təmin edir..
Gəlin bu cümləni təhlil edək.
«Müasir server proqram təminatının işləməsi üçün kritik əhəmiyyət kəsb edən funksiyalar» . Əgər siz ictimai internetlə bağlı tranzaksion server tətbiqi yaradırsınız, xarici dünyadan gələn sorğuları qəbul edir və onlara qısa müddətdə cavab verirsinizsə — məsələn, veb tətbiqi, API serveri və hətta əksər müasir tətbiqlər, — və əgər siz bu tətbiqi sinxron fəaliyyət göstərən xidmətlər toplusu kimi həyata keçirirsinizsə, və əgər siz bu proqram təminatını davamlı olaraq müasirəşdirirsinizsə, yeni imkanlar əlavə edirsinizsə, və əgər siz bu sistemi modifikasiya prosesində işlək vəziyyətdə saxlamağa məcbur olursunuzsa — sizi təbrik edirəm, siz müasir server proqram təminatı yaradırsınız. Və bütün bu yuxarıda sadalanan gözəl funksiyalar sizin üçün əslində kritik əhəmiyyət kəsb edir. Tətbiq etibarlı, təhlükəsiz olmalı və sizin onun nə etdiyini izləyə bilməniz lazımdır. Belə sualları həll etməyə service mesh kömək edir.
(Tamam, əvvəlki abza mənim server proqram təminatını yaratmağın müasir yolu olduğuna dair inamımı bir daha vurğuladı. Digərləri monolitlər, "reaktiv mikrosistemlər" və yuxarıda verilmiş tərifə uyğun gəlməyən digər şeylər məşğul olmağı üstün tuturlar. Bu insanların mütləq mənim fikrimdən fərqli bir fikri var. Öz növbəmdə düşünürəm ki, onlar "haqlı deyil" — amma hər halukarda service mesh onlara çox faydalı deyil.)
«Bütün yığın üçün eyniService mesh tərəfindən təqdim olunan funksiyalar yalnız həyata keçirmək üçün kritik deyil. Bu funksiyalar, tətbiqdaxili bütün xidmətlərə tətbiq edilir, xidmətlərin hansı dildə yazılması, hansı çərçivədən istifadə edilməsi, kim tərəfindən yazıldığı, necə yerləşdirildiyi və onların inkişafı və istifadəsi ilə bağlı bütün digər incəliklərdən asılı olmayaraq.
«Tətbiq koduna müstəqildirNəhayət, service mesh yalnız bütün texnoloji yığın üçün vahid funksionallıq təqdim etmir — bunu tətbiqdən dəyişiklik tələb etmədən həyata keçirir. Service mesh-in funksionallığının fundamental əsasları, konfiqurasiya, yeniləmə, istismar, qulluq və s. kimi vəzifələr tamamilə platforma səviyyəsindədir və tətbiqdən asılı deyil. Tətbiq dəyişə bilər, lakin service mesh-ə toxunulmur. Eyni zamanda, service mesh dəyişə bilər, tətbiqdən hər hansı bir iştirak olmadan.
Qısacası, service mesh yalnız həyati funksiyaları təqdim etmir, eyni zamanda bunu qlobal, ardıcıl və tətbiqdən asılı olmadan edir. Buna görə də, service mesh-in funksionallığı xidmətin kodunda (məsələn, hər bir xidmətə daxil edilmiş bir kitabxana şəklində) həyata keçirilə bilər, lakin bu yanaşma service mesh-in dəyərli olan homogenliyi və müstəqilliyini təmin etməyəcək.
Və bunun üçün lazım olan yeganə şey — müxtəlif proksilərin əlavə edilməsidir! Size vəd edirəm, çox keçmədən bu proksilərlə bağlı əməliyyat xərclərini müzakirə edəcəyik. Amma əvvəlcə gəlin bu müstəqillik fikrinə müxtəlif baxış bucağından yanaşaq. yaxşı misal götürməsi.
Service mesh kimlərə fayda verir?
Neçə ki, bu mənfi olsa da, hər hansı bir texnologiyanın ekosisteminin vacib bir hissəsi olması üçün insanlar tərəfindən qəbul edilməlidir. Bəs service mesh-ə maraq göstərən kimdir? Onun istifadəsindən kim faydalanır?
Əgər siz müasir server proqram təminatı hazırlayırsınızsa, komandalarınızı xidməti sahiblərindən ibarət bir qrup olaraq təsəvvür edə bilərsiniz. xidmət sahibləri, biznes məntiqini birlikdə hazırlayan və tətbiq edən, və platforma sahibləri, bu xidmətlərin işlədiyi daxili platformanın hazırlanması ilə məşğuldurlar. Kiçik təşkilatlarda bu eyni insanlar ola bilər, lakin şirkət böyüdükcə bu rollar adətən daha da ifadəli olur və hətta alt rollara bölünür... (Burada devops-un dəyişən təbiəti, mikrosistemlərin təşkilati təsiri və s. haqqında çox şey danışmaq olar. Ancaq hazırda gəlin bu təsvirləri fakt olaraq qəbul edək.)
Bu baxımdan, platforma sahibləri service mesh-in açıq faydalananlarıdır. Nəticədə platforma komandalarının məqsədi, xidmət sahiblərinin biznes məntiqini həyata keçirə biləcəyi daxili bir platforma yaratmaqdır. Bu, onların sistemin qaranlıq istismar detallarından maksimum müstəqilliyin təmin edilməlidir. Service mesh yalnız bu məqsədə nail olmaq üçün kritik olaraq vacib imkanlar təqdim etmir; eyni zamanda, bunu xidmət sahiblərinə bağlılıqlar yaratmadan edir.
Xidmət sahibləri də, hərçənd, daha dolayısı ilə istifadə plot qazanırlar. Xidmət sahibinin məqsədi, iş prosesinin məntiqini həyata keçirməkdə maksimum məhsuldar olmaqdır və istismar suallarıyla daha az maraqlanmaq o qədər də yaxşıdır. Məsələn, yenidən sorğu siyasətləri və ya TLS-nın istifadəsi üzərində düşünməkdənsə, yalnız biznes məsələləri üzərində diqqətlərini cəmləyə bilərlər və platformanın qalanını həll etməsini ümid edərlər. Bu onlara böyük bir üstünlükdür.
Platforma sahibləri ilə xidmət sahibləri arasında bu cür ayrımın təşkilati dəyərini şişirtmək çətindir. Düşünürəm ki, bu value for service mesh. ana service mesh-in dəyərinə.
Bu dərsi birinci Linkerd fanatlarından biri bizə service mesh-i seçmələrinin səbəbini izah edəndə öyrəndik: çünki onlara "müzakirələri minimuma endirmək" imkanı verdi. Bir neçə detal: bir böyük şirkət komandası Kubernetes-ə platformalarını köçürdülər. Tətbiqin gizli məlumatlarla işlədiyi üçün klasterlərdə bütün əlaqələri şifrələmək istəyirdilər. Lakin vəziyyət, yüzlərlə xidmətin və yüzlərlə inkişaf etdirici komandasının olması ilə daha da çətinləşmişdi. Hamı ilə əlaqə qurub TLS-nı planlarına daxil etməyə inandırmaq perspektivi onlara xoş gəlmirdi. Linkerd-i quraşdıra bilən kimi, onlar məsuliyyəti inkişaf etdiricilərdən (onların baxımından, bu əlavə əlavə iş idi) platforma sahiblərinə köçürdülər, bu isə onlara ən yüksək prioritet idi. Başqa sözlə, Linkerd onlara yalnız texniki deyil, həm də təşkilati problemin həllini təqdim etdi.
Qısacası, service mesh əsasən texniki bir deyil, sosio-texniki problemdir. (Təşəkkürlər, bu terminlə tanış etdiyiniz üçün.)
Service mesh bütün problemlərimi həll edəcəkmi?
Bəli. Yəni, xeyr!
Üç funksionallıq sinfinə nəzər saldıqda: etibarlılıq, təhlükəsizlik və müşahidə mümkündür ki, service mesh bu problemlərin heç biri üçün tam həll deyil. Linkerd təkrar sorğular göndərə bilər (əgər onların idempotent olduğunu bilirsə), amma xidmət tamamilə qəzaya uğrayanda istifadəçiyə nə qaytaracağını qərara vermək qabiliyyətinə malik deyil — bu qərarı tətbiq etməlidir. Linkerd uğurlu sorğuların statistikalarını aparmaqda köməklik edir, lakin xidməti izləmi və onun daxili metriksini təqdim edə bilmir — belə bir alətdən istifadə tətbiqdə mövcud olmalıdır. Və baxmayaraq ki, Linkerd mTLS təşkil edə bilir, təhlükəsizliyin təmin edilməsi üçün tam həll yolları daha çoxunu tələb edir.
Service mesh tərəfindən təqdim olunan bu sahələrdəki funksiyaların bir alt qrupları platforma xüsusiyyətlərinə. Bununla mən aşağıdakı funksiyaları başa düşürəm:
- Biznes məntiqindən müstəqildir. Foo ilə Bar arasında çağrı histogramlarının qurulma üsulu tamamilə ondan asılı deyil, niyə Foo Bar-ı çağırır.
- Bunu düzgün şəkildə həyata keçirmək çətindir. Linkerd-də təkrar cəhətlər, təkrar cəhətləri parametrikləşdirmək üçün müxtəlif mürəkkəb şeylər kimi təkrar büdcələri (retry budgets), çünki bu cür şeylərin birbaşa həyata keçirilməsinə sadə yanaşma, mütləq "sorğu boğulması" adlanan problemi meydana gətirəcək (retry storm) və paylanmış sistemlərə xas digər problemlərlə nəticələnəcək.
- Eyni şəkildə tətbiq olunduqda daha effektivdir. TLS mexanizmi yalnız hər yerdə tətbiq olunduqda məna kəsb edir.
Bu funksiyalar proxy səviyyəsində həyata keçirildiyi üçün, service mesh onları platforma, deyil, tətbiq səviyyəsində təqdim edir. Beləliklə, xidmətlərin hansı dildə yazılmasından, hansı çərçivədən istifadə etməsindən, kim tərəfindən yazılmasından və niyə olduğundan asılı deyildir. Proxy bütün bu detalların xaricində işləyir və bu funksionallığın əsas prinsipləri, konfiqurasiya, yenilənmə, istismar, xidmət və s. məsələləri yalnız platforma səviyyəsində yerləşir.
Service mesh-in imkanlarına misallar
Sonuç olaraq demək istəyirəm ki, service mesh etibarlılıq, müşahidə və təhlükəsizlik təmin etmək üçün tam bir həll deyil. Bu sahələrin genişliyi xidmət sahibləri, Ops/SRE komandaları və şirkətin digər subyektlərinin mütləq iştirakını tələb edir. Service mesh yalnız bu sahələrin hər biri üçün platforma səviyyəsində "şəklini" təqdim edir.
Niyə service mesh məhz indi populyar oldu?
Ehtimal ki, hazırda soruşursunuz: yaxşı, əgər service mesh bu qədər yaxşıdırsa, niyə on illər əvvəl stack-da milyonlarla proxy yerləşdirməyə başlamadıq?
Bu suala banale bir cavab var: on il əvvəl hamı monolitlər qururdu və service mesh-in heç kəsə ehtiyacı yox idi. Bu doğrudur, lakin mənim fikrimcə, belə bir cavabda mənanın özü itib. Hətta on il əvvəl mikrosistemlərin böyük miqyaslı sistemlərin yaradılması üçün perspektivli bir yanaşma kimi müzakirə edildiyini və Twitter, Facebook, Google və Netflix kimi şirkətlərdə istifadə edildiyini bilmək vacibdir. Ümumi fikirlər — ən azından mənim əlaqə qurduğum sahələrdə — mikrosistemlərin böyük sistemlər yaratmaq üçün "doğru yol" olduğu idi, baxmayaraq ki, bu, son dərəcə çətin idi.
Əlbəttə, on il əvvəl mikrosistemləri istifadə edən şirkətlər olsa da, onlar heç də hər yerdə proksiləri yerləşdirmirdilər ki, service mesh formalaşdırsın. Lakin əslində, onlar buna bənzər bir şey edirdilər: bu şirkətlərin əksəriyyətində şəbəkə ilə qarşılıqlı əlaqə üçün xüsusi daxili kitabxananın istifadə edilməsi tələb olunurdu (bəzən "şişirdilmiş müştəri kitabxanası" adlanırdı, fat client library).
Netflix-in Hysterix'i, Google-in Stubby-si, Twitter-in Finagle kitabxanası var idi. Məsələn, Finagle Twitter-də hər bir yeni xidmət üçün məcburi idi. O, həm client, həm də server hissələrinin əlaqələrini idarə edirdi, təkrar sorğuların həyata keçirilməsinə, sorğu marşrutlaşdırılmasına, yük balanslaşdırılmasına və ölçmə sistemlərinə dəstək verirdi. Bu, Twitter-in bütün stekinin etibarlılığını və müşahidə sistemini təmin edirdi, xidmətin nə ilə məşğul olduğundan asılı olmayaraq. Əlbəttə, o yalnız JVM dilləri üçün işləyirdi və tətbiq üçün istifadə edilməli olan proqramlaşdırma modelinə əsaslanırdı. Lakin onun funksionallığı, service mesh-in funksionallığı ilə demək olar ki, eyniydi. (Əslində, Linkerd-in ilk versiyası sadəcə Finagle-in proksi formasında olan versiyası idi.)
Beləliklə, on il əvvəl yalnız mikrosistemlər yox, həm də service mesh-in indiki problemlərini həll edən xüsusi proto-service-mesh kitabxanaları var idi. Lakin service mesh-in özü yox idi. Onun meydana gəlməsi üçün bir dəyişiklik daha baş verməli idi.
Və burada, son on ildə baş vermiş digər bir dəyişiklikdə daha dərin bir cavab var: mikrosistemlərin yayım xərclərində kəskin azalma baş verdi. On il əvvəl mikrosistemlərdən istifadə edən bir çox adlardan: Twitter, Netflix, Facebook, Google — böyük miqyasda və böyük resurslara malik şirkətlər idi. Onların mikrosistemlər əsasında böyük tətbiqləri yaratmaq, yerləşdirmək və idarə etmək üçün yalnız ehtiyacı yox, həm də imkanı var idi. Twitter mühəndislərinin monolitdən mikrosistem yanaşmasına keçid üçün sərf etdiyi enerji və səylər heyrətamizdir. (Düzü, bunun başa gəlməsi də heyrətlidir.) Bu cür infrastruktur manevrləri o zaman kiçik ölçülü şirkətlər üçün mümkünsüz idi.
Gəlin indiyə köçək. Bu gün startaplar var ki, burada mikroservislərin inkişafçılara nisbəti 5:1-dir (yəni, üstəlik, ), və daha da önəmlisi, onlar uğurla bunun öhdəsindən gəlirlər! Əgər 5 nəfərdən ibarət bir startap sərhədsiz olaraq 50 mikroservisi idarə edə bilirsə, deməli, onların tətbiqinin qiyməti aydın şəkildə azalmışdır.
Monzo-da 1500 mikroservis; hər xət, trafikə icazə verən təyin edilmiş şəbəkə qaydasıdır.
Mikroservislərin istismar xərclərinin kəskin azalması bir prosesin nəticəsidir: konteynerlərin populyarlığının artması və orkestratorların. Bu, service mesh-in ortaya çıxmasına nəyi təsir etdiyinə dərin cavabdır. Eynən bu texnologiya həm service mesh, həm də mikroservisləri cəlbedici etmişdir: Kubernetes və Docker.
Niyə? Çünki, Docker bir böyük problemi həll edir - paketləmə problemini. Tətbiqi və onun (şəbəkə olmayan) çalışma asılılıqlarını konteynere paketləyərək, Docker tətbiqi mübadiləli bir vahidə çevirir ki, bu da istənilən yerdə yerləşdirilə və işə salına bilsin. Eyni zamanda, o, istismarını əhəmiyyətli dərəcədə asanlaşdırır. çoxdilli stek: konteyner bir icra vahidi olduğuna görə, yerləşdirmə və istismar məqsədləri üçün içində nə olduğu vacib deyil, fırlanan JVM, Node, Go, Python, və ya Ruby tətbiqi olsun. Sadəcə onu işə salırsan və bu qədər.
Kubernetes hər şeyi yeni bir səviyyəyə qaldırır. İndi, çoxlu "icra olunan şeylər" və onları işə salmaq üçün çoxlu maşınlar olduğuna görə, bir-biri ilə uyğunlaşdıran bir alətə ehtiyac yaranır. Ümumilikdə, siz Kubernetes-ə çoxlu konteynerlər və çoxlu maşınlar verirsiniz, o da onları biri-birinə uyğunlaşdırır (əlbəttə ki, bu dinamik və daim dəyişən bir prosesdir: yeni konteynerlər sistemdə yer dəyişdirir, maşınlar işə salınır və dayandırılır və s. Ancaq Kubernetes bunu nəzərə alır).
Kubernetes-in qurulmasından sonra, bir servisin yerləşdirilməsi və istismarında vaxt xərcləri on servisin yerləşdirilməsi və istismarından az fərqlənir (əslində, 100 servisin yerləşdirilməsi və istismarında da demək olar ki, eynidir). Bunun yanına konteynerləri paketləmə mexanizmi olaraq əlavə edin ki, bu da çoxdilli icraatı təşviq edir, və nəticədə müxtəlif dillərdə yazılmış mikroservislər şəklində çoxlu yeni tətbiqlər əldə edirsiniz - məhz service mesh-in uyğun olduğu mühit.
Beləliklə, service mesh ideyasının niyə məhz indi populyarlaşdığına cavab veririk: Kubernetesin xidmətlər üçün təmin etdiyi homojenlik, service mesh-in üzləşdiyi əməliyyat tapşırıqlarına birbaşa tətbiq olunur. Siz proksi konteynerləri yükləyirsiniz, Kubernetesə onları lazım olan yerlərə yerləşdirməyi tapşırırsınız və voilà! Nəticədə service mesh alırsınız, burada onun yerləşdirilməsi mexanikasını tamamilə Kubernetes idarə edir. (Ən azından quş baxışından. Əlbəttə, bu prosesdə bir çox incəliklər var.)
Xülasə edərək: service mesh-in məhz indi, on il əvvəl deyil, populyarlaşmasının səbəbi Kubernetes və Docker-in tətbiqləri çoxdilli mikrosistemlər toplusu kimi həyata keçirməyə tələbini yalnız artırması deyil, həm də onun istismar xərclərini ciddi şəkildə azaltmasıdır. lazım olması xarici dəstək xərcləri ilə təmin etdiyi sidecar-proksi parklarının yerləşdirilməsi və dəstəklənməsi mexanizmləri ilə.
Niyə service mesh haqqında bu qədər müzakirələr var?
Xəbərdarlıq: bu bölmədə mən istənilən fərziyyələrə, təxminlərə, fərziyyələrə və daxili məlumatlara müraciət edirəm.
«service mesh» ifadəsi ilə axtarış aparsanız, çox sayda iki dəfə istifadə edilmiş az kalorili məzmun, qəribə layihələr və əks-sədalı pozulmalarla rastlaşacaqsınız. Bu, hər yeni populyar texnologiyaya aiddir, lakin service mesh halında problem xüsusilə kəskindir. Niyə?
Əslində, bunun bir hissəsi mənim günahımdır. Mən Linkerd və service mesh’i hər fürsətdə irəlilətmək üçün əlimdən gələni etdim, sayısız blog yazıları və məqalələrlə. Ancaq mən o qədər də güclü deyiləm. Bu sualın həqiqətən cavabını tapmaq üçün ümumi vəziyyətdən danışmaq lazımdır. Və bunun haqqında danışmaq üçün bir layihəyə toxunmadan keçmək mümkün deyil: — Google, IBM və Lyft tərəfindən birgə inkişaf etdirilən açıq mənbəli service mesh.
(Bu üç şirkətin tamamilə fərqli rolları var: Lyft-in iştirakının yalnız adla məhdudlaşdığı görünür; onlar Envoy müəllifləridir, lakin Istio’yu istifadə etmir və ya onun inkişafında iştirak etmirlər. IBM Istio-nun inkişafında iştirak edir və onu istifadə edir. Google Istio-nun inkişafında fəal iştirak edir, lakin bildiyim qədər, əslində onu istifadə etmir.)
Istio layihəsi iki xüsusiyyətlə seçilir. Birincisi, Google-un, xüsusilə, onun reklamı üçün hazırda göstərdiyi böyük marketinq səyləri. Mənim hesablamalarıma görə, service mesh konsepsiyası haqqında məlumatlı olan insanların əksəriyyəti, bu fikir barədə ilkin məlumat əldə ediblər Istio sayəsində. İkinci xüsusiyyət isə Istio-nun necə zəif qarşılandığıdır. Bu məsələdə mən açıq-aşkar bir tərəfdaşam, lakin mümkün olduğu qədər obyektiv olunmağa çalışarkən, mütləq , çox da xarakterik olmayan (amma unikal olmayan: aklıma systemd gəlir, …) Open Source layihəsi üçün.
(İstioda praktikada, görünür, sadəcə mürəkkəblik və istifadəçi təcrübəsi ilə deyil, həm də performans ilə bağlı məsələlər var. Məsələn, üçün performans qiymətləndirməsi zamanı, üçüncü tərəf tərəfindən mütəxəssislər Istio-nun gecikmə boşluqlarının (tail latency) 100 dəfə Linkerd ilə müqayisədə daha yüksək olduğunu, həmçinin resurs çatışmazlığı olan vəziyyətləri aşkarladı; burada Linkerd müvəffəqiyyətlə fəaliyyətini davam etdirdi, amma Istio tamamilə dayandı.)
Mənim bu baş verməsinin səbəbləri ilə bağlı nəzəriyyələrimi bir kənara qoyaraq, xidmət mesh-ə olan gözəçarpan marağın Google-un iştirakı ilə izah olunduğunu düşünürəm. Xüsusilə, aşağıdakı üç amilin birləşməsi ilə:
- Google-un Istio-nu qəsdən təbliğ etməsi;
- layihəyə münasibətdə müvafiq mənfi, tənqidi yanaşma;
- Kubernetes-in son sürətlə artan populyarlığı, xatirələri hələ də təzədir.
Bu amillərin birləşməsi zəhərləyici, oksigensiz bir mühit yaradır ki, burada rasional düşünmə bacarığı zəifləyir və yalnız möhtəşəm bir növ .
Linkerd-nin nöqteyi-nəzərindən, bunu… mən müsbət bir gedən-boşanma təsiri kimi təsvir edərdim. Yəni, xidmət mesh-in əsas axında yer alması gözəldir — 2016-cı ildə Linkerd yeni yarananda insanları layihəyə cəlb etmək çətin idi. İndi belə bir problem yoxdur! Lakin problem odur ki, bu gün xidmət mesh vəziyyəti o qədər qarışıqdır ki, hansı layihələrin həqiqətən xidmət mesh kateqoriyasına aid olduğunu başa düşmək demək olar ki, mümkün deyil (hansı birinin konkret istifadə halları üçün daha yaxşı olduğunu anlamaqdan danışmıram). Bu, hər kəsin işini çətinləşdirir (və aydındır ki, bəzi hallarda Istio və ya digər bir layihə Linkerd-dən daha uyğun ola bilər, çünki sonuncu hələ də universal bir həll deyil).
Linkerd tərəfindən bizim strategiyamız, səs-küyü görməzlikdən gəlib, icmanın real problemlərinin həllinə diqqət yetirmək və mətn olaraq, həyəcanın azalmasını gözləmək idi. Nəticədə, bu hype sona çatacaq və biz sakitcə işləməyə davam edə biləcəyik.
Hələlik, hamımızın bir az səbr etməsi lazım olacaq.
Xidmət mesh-i mənə, müxtəsər bir software engineer-ə necə faydalıdır?
Bu suala cavab verməyə aşağıdakı sorğu kömək edəcək:
Siz yalnız biznes loqikasını həyata keçirirsiniz? Bu halda, xidmət mesh sizə lazım olmayacaq. Yəni, əlbəttə, siz bununla maraqlana bilərsiniz, lakin ideya olaraq xidmət mesh sizin mühitinizdə birbaşa təsir etməməlidir. Sizə ödənilən işlə üzləşməyə davam edin.
Siz Kubernetes istifadə edən bir şirkətdə platformanı dəstəkləyirsiniz? Bəli, bu halda service mesh sizə lazımdır (əlbəttə, əgər K8s-i sadəcə monolit və ya paket emalı üçün istifadə etmirsinizsə - amma onda K8s-in sizə nə üçün lazım olduğunu soruşmaq istərdim). Yəqin ki, müxtəlif insanlar tərəfindən yazılmış bir çox mikroservis olan bir vəziyyətdə olacaqsınız. Onlar bir-biri ilə qarşılıqlı əlaqə saxlayır və runtime-ə bağlılıq düyünündə birləşirlər, siz isə bunun öhdəsindən gəlmək üçün bir yol tapmalısınız. Kubernetes-in tətbiqi, sizə özünüzə uyğun bir service mesh seçməyə imkan tanıyır. Bunun üçün onların qabiliyyətləri və xüsusiyyətləri ilə tanış olun və sizə uyğun olan mövcud layihələrdən biri olub olmadığını düşünün (Linkerd-in araşdırılmasına başlamağı tövsiyə edirəm).
Kubernetes-i istifadə etməyən, amma mikroservislərlə işləyən bir platformanın rəhbərisiniz? Bu halda service mesh sizə faydalı olacaq, lakin onun istifadəsi sadə olmayacaq. Məsələn, təqlid edə bilərsiniz service mesh-in işini bir çox proxy yerləşdirməklə, ancaq Kubernetes-in əsas üstünlüklərindən biri dəqiqi yayım modelidir: bu proxy-ləri əl ilə saxlaymaq xeyli daha çox zaman, əmək və maliyyə sərf etməyi tələb edəcək.
Monolitlərlə işləyən bir platformanın rəhbərisiniz? Bu halda service mesh sizə, yəqin ki, lazım deyil. Monolitlərlə (və ya hətta müəyyən və az dəyişən qarşılıqlı əlaqə nümunələri olan monolit toplusu ilə) işləyirsinizsə, service mesh sizin üçün çox şey təklif etməyəcək. Beləliklə, onu sadəcə görməzlikdən gələ bilərsiniz və onun kabus kimi yox olmasını ümid edə bilərsiniz...
Nəticə
Bəlkə də service mesh-i "dünyanın ən trendli texnologiyası" adlandırmamalıyıq - bu şüpheli şərəf, ehtimal ki, bitcoinə və ya AI-ya aiddir. Ola bilsin ki, o, ilk beşliyə daxildir. Ancaq səs-küy və hay-küydən keçmək mümkün olduqda, service mesh-in Kubernetes-də tətbiq yaratmaqda əsl fayda gətirdiyini anlamaq mümkündür.
Linkerd-i sınamağı istərdim - onun Kubernetes klasterinə (və ya hətta laptopda Minikube-da) quraşdırılması çəkir və mən dediyim şeyi özünüz görə bilərsiniz.
FAQ
— Əgər service mesh-i görməzlikdən gələrsəm, o, yox olar?
— Sizə dərd verim: service mesh bizimlə uzun müddət qalacaq.
— Amma mən service mesh-i İSTƏMİRƏM!
— Yaxşı, lazım deyil! Yuxarıdakı sorğu formumu oxuyun ki, onun əsasları ilə tanış olub-olmadığını anlamalısınız.
— Bu, yenidən souslanmış köhnə ESB/middleware deyilmi?
— Service mesh əməliyyat loqikası ilə məşğuldur, mənşə ilə deyil. korporativ xidmət şinindəkiilə bağlı əsas çatışmazlıq idi. Bu ayrı-seçkiliyi saxlamaq service mesh-in eyni aqibətlə qarşılaşmasını önləməyə kömək edir.
— Service mesh API-gateway'lardan necə fərqlənir?
— Bu mövzu ilə bağlı milyonlarla məqalə var. Sadəcə axtarın.
— Envoy bir service mesh-dirmi?
— Xeyr, Envoy bir service mesh deyil, bu bir proxy-serverdir. Onu service mesh (və daha çoxu üçün — bu ümumi təyinatlı proxy-dir) təşkil etmək üçün istifadə etmək mümkündür. Ancaq özü service mesh deyil.
— Network Service Mesh bir service mesh-dir?
— Xeyr. Adına baxmayaraq, bu bir service mesh deyil (rəqəmsal marketinq möcüzələri, elə deyilmi?).
— Service mesh mənim reaktiv asinxron sistemimə kömək edəcəkmi, hansında ki, mesajlar sıraya qoyulub?
— Xeyr, service mesh sizə kömək etməyəcək.
— Hansı service mesh-i istifadə etməliyəm?
— , bu çox aydındır.
— Məqalə — qorxunc! / Müəllifi — zibilliyə!
— Zəhmət olmasa, bununla bağlı bağlantını bütün dostlarınızla paylaşın ki, onlar da bunu görə bilsinlər!
Teşekkürler
Adından da göründüyü kimi, bu məqalə Jay Kreps’in fantastik traktatından ilham alıb «». Mən Jay-i on il əvvəl Linked In-də müsahibə alarkən tanımışdım və o vaxtdan bəri mənim üçün ilham mənbəyi olub.
Hətta özümü «Linkerd proqramçısı» adlandırmağı sevirəm, amma reallıq odur ki, mən daha çox layihədə README.md faylının saxlayıcısıyam. Bugün Linkerd-də , , şəxs çalışır və bu layihə əla iştirakçıların və istifadəçilərin dəstəyi olmadan baş tutmazdı.
Və nəticə olaraq Linkerd-in qurucusu, (primus inter pares), uzun illər əvvəl mənimlə birlikdə bu service mesh məsələlərinə dərindən daxil oldu.
Kubernetes-də təhlükəsizlik: identifikasiya, icazə, audit
Blogumuzda oxuyun:
- «»;
- «»;
- «»;
- «»;
- «».
Mənbə: habr.com
