Qeyd. tərcümə.: Xidmət şəbəkəsi hələ rus dilinə sabit tərcüməsi olmayan bir fenomendir (2 ildən çox əvvəl biz "xidmətlər üçün mesh" seçimini təklif etdik və bir az sonra bəzi həmkarlar "xidmət ələk" birləşməsini fəal şəkildə təbliğ etməyə başladılar) . Bu texnologiya haqqında daimi söhbət marketinq və texniki komponentlərin həddən artıq sıx əlaqəli olduğu bir vəziyyətə gətirib çıxardı. Orijinal terminin müəlliflərindən birinin bu gözəl materialı təkcə mühəndislərə deyil, həm də mühəndislərə aydınlıq gətirmək məqsədi daşıyır.
Komik
Giriş
Əgər siz arxa sistemlər sahəsində bir yerdə işləyən bir proqram mühəndisisinizsə, "xidmət şəbəkəsi" termini yəqin ki, son bir neçə il ərzində beyninizdə möhkəm şəkildə yerləşmişdir. Qəribə bir təsadüf sayəsində bu ifadə sənayeni getdikcə daha çox zəbt edir və şırınga və əlaqəli tanıtım təklifləri qartopu kimi böyüyür, təpədən aşağı uçur və heç bir yavaşlama əlaməti göstərmir.
Xidmət şəbəkəsi bulud yerli ekosisteminin bulanıq, meylli sularında doğuldu. Təəssüf ki, bu o deməkdir ki, onu əhatə edən mübahisələrin çoxu “aşağı kalorili söhbət”dən tutmuş texniki termindən istifadə etmək üçün açıq-aşkar boşboğazlığa qədərdir. Ancaq bütün səs-küyü süzsəniz, xidmət şəbəkəsinin çox real, müəyyən və vacib bir funksiyaya sahib olduğunu görə bilərsiniz.
Bu yazıda mən bunu etməyə çalışacağam: xidmət şəbəkəsinə dürüst, dərin, mühəndis yönümlü bələdçi təqdim edin. Mən sadəcə sualdan daha çox cavab verəcəyəm: "Bu nədir?", - həm də "Niyə?"Və "Niyə indi?". Nəhayət, bu xüsusi texnologiyanın (mənim fikrimcə) niyə belə bir dəlilik yaratdığını izah etməyə çalışacağam ki, bu da özlüyündə maraqlı bir hekayədir.
Mən kiməm
Hamıya salam! Mənim adım . Yaradanlardan biri də mənəm - ilk xidmət şəbəkəsi layihəsi və terminin yaranmasında günahkar olan layihə xidmət mesh kimi (bağışlayın uşaqlar!). (Qeyd tərcümə.: Yeri gəlmişkən, bu terminin ortaya çıxdığı vaxtda, 2,5 ildən çox əvvəl, biz artıq eyni müəllifin "" adlı ilk materialını tərcümə etmişik.".) mən də rəhbərlik edirəm Linkerd və kimi gözəl xidmət şəbəkələri quran bir başlanğıcdır .
Yəqin təxmin edə bilərsiniz ki, mənim bu məsələdə çox qərəzli və subyektiv fikrim var. Bununla belə, mən qərəzliyi minimuma endirməyə çalışacağam (bir bölmə istisna olmaqla: "Niyə xidmət şəbəkəsi haqqında bu qədər çox danışılır?", - bununla belə, mən əvvəlcədən düşünülmüş fikirlərimi bölüşəcəyəm). Mən də bu təlimatı mümkün qədər obyektiv etmək üçün əlimdən gələni edəcəyəm. Konkret misallarda, digər növ xidmət şəbəkələrinin həyata keçirilməsində bildiyim fərqləri (əgər varsa) qeyd edərkən, əsasən Linkerd-in təcrübəsinə istinad edəcəyəm.
Yaxşı, yeməklərə keçməyin vaxtı gəldi.
Xidmət şəbəkəsi nədir?
Bütün şırıngalara baxmayaraq, xidmət şəbəkəsi struktur olaraq olduqca sadədir. Bu, sadəcə olaraq, xidmətlərin "yanında" yerləşən bir dəstə istifadəçi sahəsinin proksisidir (bir az sonra "yaxınlıqda" danışacağıq), üstəlik bir sıra idarəetmə prosesləri. Proksilər birlikdə çağırılır məlumat müstəvisi, və nəzarət prosesləri adlanır idarəetmə təyyarəsi. Məlumat təyyarəsi xidmətlər arasında zəngləri kəsir və onlarla "fərqli hər şeyi" edir; idarəetmə təyyarəsi, müvafiq olaraq, proxy-nin davranışını əlaqələndirir və sizin üçün girişi təmin edir, yəni. operator, API-yə, şəbəkənin bütövlükdə idarə edilməsinə və ölçülməsinə imkan verir.
Bu proksi nədir? Bu, "Layer 7-dən xəbərdar" kateqoriyasının TCP proksisidir (yəni OSI modelinin 7-ci qatını "nəzərə alaraq") HAProxy və NGINX kimi. Zövqünüzə uyğun bir proxy seçə bilərsiniz; Linkerd sadə adlandırılmış Rust proxy-dən istifadə edir . Biz onu xüsusi olaraq xidmət şəbəkəsi üçün tərtib etdik. Digər meshlər digər proksilərə üstünlük verir (Elçi ümumi seçimdir). Bununla belə, proxy seçmək sadəcə icra məsələsidir.
Bu proxy serverlər nə edir? Aydındır ki, onlar xidmətlərə və xidmətlərdən gələn zəngləri proksiləşdirirlər (doğru desək, onlar həm daxil olan, həm də gedən zəngləri idarə edən etibarnamə və əks etibarnamə kimi çıxış edirlər). Və zənglərə diqqət yetirən bir xüsusiyyət dəsti həyata keçirirlər arasında xidmətlər. Xidmətlər arasında trafikə bu diqqət xidmət şəbəkəsi proksisini, məsələn, API şlüzlərindən və ya daxil olma proksilərindən (sonuncu, xarici dünyadan klasterə daxil olan zənglərə diqqət yetirir) fərqləndirən şeydir. (Qeyd. tərcümə.: Bir çoxu artıq qeyd olunan Elçidən istifadə edən mövcud Kubernetes Ingress kontrollerlərinin müqayisəsi üçün baxın. .)
Beləliklə, məlumat müstəvisini tapdıq. İdarəetmə müstəvisi daha sadədir: bu, məlumat müstəvisinin koordinasiyalı şəkildə işləməsi üçün lazım olan bütün mexanikanı təmin edən komponentlər toplusudur, o cümlədən xidmət kəşfi, TLS sertifikatının verilməsi, metriklərin yığılması və s. Məlumat müstəvisi idarəetmə müstəvisinə məlumat verir. onun davranışı; öz növbəsində idarəetmə təyyarəsi bütövlükdə məlumat müstəvisinin davranışını dəyişməyə və izləməyə imkan verən API təmin edir.
Aşağıda Linkerd-də idarəetmə təyyarəsi və məlumat müstəvisinin diaqramı verilmişdir. Gördüyünüz kimi, idarəetmə müstəvisinə bir neçə fərqli komponent daxildir, o cümlədən proksi serverlərdən ölçüləri toplayan Prometheus nümunəsi, həmçinin digər komponentlər, məsələn destination (xidmət kəşfi), identity (sertifikat orqanı, CA) və public-api (veb və CLI üçün son nöqtələr). Bunun əksinə olaraq, məlumat müstəvisi tətbiq nümunəsinin yanında sadə bir linkerd-proksidir. Bu sadəcə məntiq diaqramıdır; real dünyada yerləşdirmədə hər bir idarəetmə təyyarəsi komponentinin üç nüsxəsi və məlumat müstəvisində yüzlərlə və ya minlərlə proksi ola bilər.
(Bu diaqramdakı mavi qutular Kubernetes podlarının sərhədlərini təmsil edir. Siz linkerd-proksi ilə konteynerlərin tətbiq konteynerləri ilə eyni podda olduğunu görə bilərsiniz. Bu sxem kimi tanınır. yan qutu.)
Xidmət mesh arxitekturasının bir neçə mühüm təsiri var. Birincisi, proksinin işi xidmətlər arasında zəngləri ələ keçirmək olduğundan, xidmət şəbəkəsi yalnız tətbiqiniz bir sıra xidmətlər üçün qurulduqda məna kəsb edir. mesh olar monolitlərlə istifadə edin, lakin bu, tək bir proksi üçün lazımsızdır və onun funksionallığına tələbat olması ehtimalı azdır.
Digər mühüm nəticə ondan ibarətdir ki, xidmət şəbəkəsi tələb olunur böyük proksilərin sayı. Əslində, Linkerd hər bir xidmət nümunəsi üçün linkerd-proksi zəncirləyir (digər tətbiqlər hər host/host/VM-ə proksi əlavə edir. Bu, hər halda çoxdur). Proksinin belə aktiv istifadəsi özlüyündə bir sıra əlavə fəsadlar yaradır:
- Məlumat müstəvisində proxylər olmalıdır sürətli, çünki hər zəng üçün proxy-yə bir neçə zəng olur: biri müştəri tərəfində, biri server tərəfində.
- Həmçinin, etibarnamələr olmalıdır kiçik и yüngül. Hər biri yaddaş və CPU resurslarını istehlak edəcək və bu istehlak tətbiq ilə xətti olaraq artacaq.
- Çox sayda proksiləri yerləşdirmək və yeniləmək üçün sizə mexanizm lazımdır. Bunu əl ilə etmək bir seçim deyil.
Ümumiyyətlə, xidmət şəbəkəsi belə görünür (heç olmasa quş baxışı ilə): siz daxili, xidmətlərarası trafiklə "nəsə görən" bir qrup istifadəçi proksisini yerləşdirirsiniz və onlara nəzarət etmək və idarə etmək üçün idarəetmə müstəvisindən istifadə edirsiniz.
“Niyə?” sualının vaxtıdır.
Xidmət şəbəkəsi nə üçündür?
Bir xidmət şəbəkəsi ideyası ilə ilk dəfə qarşılaşanlar üçün bir az qorxu içində olmaq bağışlana bilər. Xidmət şəbəkəsinin dizaynı o deməkdir ki, o, nəinki tətbiqin gecikməsini artıracaq, həm də istehlak etmək resursları və əlavə edəcək infrastrukturda bir sıra yeni mexanizmlər. Əvvəlcə bir xidmət şəbəkəsi qurdunuz və sonra birdən yüzlərlə (minlərlə olmasa da) proksilərə xidmət etmək ehtiyacı hiss etdiniz. Sual olunur ki, bunun üçün kim könüllü olacaq?
Bu sualın cavabı iki hissədən ibarətdir. Birincisi, bu proksilərin yerləşdirilməsi ilə bağlı əməliyyat xərcləri ekosistemdə baş verən bəzi dəyişikliklər səbəbindən əhəmiyyətli dərəcədə azaldıla bilər (bu barədə daha sonra).
İkincisi, belə bir cihaz əslində sistemə əlavə məntiq təqdim etmək üçün əla bir yoldur. Və təkcə ona görə deyil ki, xidmət şəbəkəsindən istifadə edərək bir çox yeni funksiyalar əlavə oluna bilər, həm də ekosistemə müdaxilə etmədən edilə bilər. Əslində, bütün xidmət şəbəkəsi modeli bu postulata əsaslanır: nə olursa olsun, multiservis sistemində etmək fərdi xidmətlər, trafik onların arasında funksionallıq əlavə etmək üçün ideal nöqtədir.
Məsələn, Linkerd-də (əksər meshlərdə olduğu kimi) funksionallıq əsasən HTTP/2 və gRPC* daxil olmaqla HTTP zənglərinə fokuslanır. Funksionallıq olduqca zəngindir - onu üç sinfə bölmək olar:
- Əlaqədar xüsusiyyətlər etibarlılıq. Yenidən cəhd sorğuları, fasilələr, kanarya yanaşması (trafikin bölünməsi/yönləndirmə) və s.
- Əlaqədar xüsusiyyətlər monitorinq. Hər bir xidmət və ya ayrı-ayrı istiqamətlər üzrə müvəffəqiyyət dərəcələrinin, gecikmələrin və sorğu həcmlərinin ümumiləşdirilməsi; xidmətlərin topoloji xəritələrinin qurulması və s.
- Əlaqədar xüsusiyyətlər təhlükəsizlik. Qarşılıqlı TLS, giriş nəzarəti və s.
* Linkerdin nöqteyi-nəzərindən, gRPC praktiki olaraq HTTP/2-dən heç bir fərqi yoxdur: o, sadəcə faydalı yükdə protobufdan istifadə edir. Tərtibatçı baxımından bu iki şey, əlbəttə ki, fərqlidir.
Bu mexanizmlərin çoxu sorğu səviyyəsində işləyir (buna görə də "L7 proxy"). Məsələn, Foo xidməti xidmət Barına HTTP zəngi edirsə, Foo tərəfindəki linkerd-proksi müşahidə olunan gecikmə əsasında ağıllı şəkildə yük balansını təyin edə və zəngləri Foo-dan Bar nümunələrinə yönləndirə bilər; zəruri hallarda sorğunu təkrar edə bilər (və idempotentdirsə); o, cavab kodunu və fasiləni qeyd edə bilər və s. Eynilə, Bar tərəfindəki linkerd-proxy sorğuya icazə verilmədikdə və ya sorğu limiti keçdikdə onu rədd edə bilər; öz hissəsində gecikməni düzəldə bilər və s.
Proksilər əlaqə səviyyəsində də "bir şey edə" bilər. Məsələn, Foo tərəfindəki linkerd-proksi TLS bağlantısını başlada bilər və Bar tərəfindəki linkerd-proksi onu dayandıra bilər və hər iki tərəf bir-birinin TLS sertifikatlarını yoxlaya bilər*. Bu, təkcə xidmətlər arasında şifrələməni deyil, həm də xidmətləri müəyyən etmək üçün kriptoqrafik cəhətdən təhlükəsiz bir üsul təqdim edir: Foo və Bar onların dedikləri kimi olduqlarını "sübut edə" bilərlər.
* "Dostun dostu" o deməkdir ki, müştərinin sertifikatı da yoxlanılır (qarşılıqlı TLS). "Klassik" TLS-də, məsələn, brauzer və server arasında adətən yalnız bir tərəfin (serverin) sertifikatı yoxlanılır.
İstər tələb, istərsə də əlaqə səviyyəsində fəaliyyət göstərməsindən asılı olmayaraq, bütün xidmət şəbəkəsi xüsusiyyətlərinin olduğunu vurğulamaq vacibdir əməliyyat xarakter. Linkerd JSON fraqmentinə sahələr əlavə etmək və ya protobufa dəyişikliklər etmək kimi faydalı yükün semantikasını çevirə bilmir. Bu vacib xüsusiyyət haqqında daha sonra ESB və ara proqram haqqında danışarkən danışacağıq.
Bu, xidmət şəbəkəsinin təklif etdiyi xüsusiyyətlər dəstidir. Sual yaranır: niyə onları birbaşa tətbiqdə tətbiq etmirsiniz? Və niyə ümumiyyətlə bir proxy ilə qarışmaq lazımdır?
Niyə bir xidmət şəbəkəsi yaxşı bir fikirdir
Xidmət şəbəkəsinin imkanları cəlbedici olsa da, onun əsas dəyəri həqiqətən xüsusiyyətlərdə deyil. Sonda biz Bacarmaq onları birbaşa tətbiqdə həyata keçirin (daha sonra bunun xidmət şəbəkəsinin mənşəyi olduğunu görəcəyik). Bunu bir cümlə ilə ifadə etsək, xidmət şəbəkəsinin dəyəri belədir: müasir server proqram təminatının ardıcıl, stack-geniş, proqram kodu-aqnostik şəkildə işlədilməsi üçün vacib olan funksionallığı təmin edir..
Gəlin bu təklifi təhlil edək.
«Müasir Server Proqramını İşlətmək üçün Kritik Funksiyalar". Əgər siz xarici dünyadan gələn sorğuları qəbul edən və onlara qısa müddət ərzində cavab verən ictimai internetə qoşulmuş əməliyyat server proqramı qurursunuzsa - məsələn, veb tətbiqi, API serveri və digər müasir proqramların böyük əksəriyyəti - və əgər siz onu bir-biri ilə sinxron əlaqədə olan xidmətlər toplusu kimi həyata keçirirsinizsə və bu proqram təminatını daim təkmilləşdirirsinizsə, yeni funksiyalar əlavə edirsinizsə və modifikasiya prosesi zamanı bu sistemi işlək vəziyyətdə saxlamaq məcburiyyətində qalırsınızsa - bu halda, Təbrik edirik, müasir server proqram təminatı yaradırsınız. Və yuxarıda sadalanan bütün bu əla xüsusiyyətlər əslində sizin üçün kritikdir. Tətbiq etibarlı, təhlükəsiz olmalıdır və siz onun nə etdiyini görə bilməlisiniz. Məhz bu sualları xidmət şəbəkəsi həll etməyə kömək edir.
(Yaxşı, bu yanaşmanın server proqram təminatını qurmağın müasir üsulu olduğuna əminliyim əvvəlki paraqrafa daxil oldu. Digərləri monolitlər, "reaktiv mikroservislər" və yuxarıda verilən tərifə uyğun olmayan digər şeyləri inkişaf etdirməyə üstünlük verirlər. Bu insanlar yəqin ki, mənimkindən fərqlənən fikir və öz növbəsində onların "yanlış" olduğuna inanıram - baxmayaraq ki, hər halda, xidmət şəbəkəsi onlar üçün çox faydalı deyil).
«Bütün yığın üçün uniforma". Xidmət şəbəkəsinin təmin etdiyi xüsusiyyətlər təkcə kritik deyil. Onlar hansı dildə yazılmasından, hansı çərçivədən istifadə etməsindən, kimin yazdığından, necə yerləşdirilməsindən və inkişaf və istifadənin bütün digər incəliklərindən asılı olmayaraq tətbiqdəki bütün xidmətlərə şamil edilir.
«Tətbiq kodu müstəqil". Nəhayət, xidmət şəbəkəsi təkcə bütün yığında ardıcıl funksionallığı təmin etmir, həm də bunu proqramın redaktə edilməsini tələb etməyən şəkildə edir. Konfiqurasiya, yenilənmə, istismar, texniki xidmət və s. tapşırıqları daxil olmaqla, xidmət şəbəkəsinin funksionallığının fundamental əsası sırf platforma səviyyəsindədir və tətbiqdən asılı deyil. Tətbiq xidmət şəbəkəsinə təsir etmədən dəyişə bilər. Öz növbəsində, xidmət şəbəkəsi heç bir tətbiq müdaxiləsi olmadan dəyişə bilər.
Bir sözlə, xidmət şəbəkəsi təkcə həyati funksionallığı təmin etmir, həm də bunu qlobal, vahid və tətbiqdən asılı olmayan şəkildə edir. Və beləliklə, xidmət şəbəkəsinin funksionallığı xidmətin kodunda (məsələn, hər bir xidmətə daxil olan kitabxana kimi) həyata keçirilə bilsə də, bu yanaşma bir xidmət şəbəkəsində o qədər də dəyərli olan vahidliyi və müstəqilliyi təmin etməyəcək. xidmət şəbəkəsi.
Və sizə lazım olan tək şey bir dəstə proksi əlavə etməkdir! Söz verirəm ki, tezliklə bu proksilərin əlavə edilməsi ilə bağlı əməliyyat xərclərinə baxacağıq. Ancaq əvvəlcə dayanaq və bu müstəqillik ideyasına müxtəlif nöqteyi-nəzərdən baxaq xalq.
Xidmət şəbəkəsi kimə kömək edir?
Nə qədər əlverişsiz olsa da, bir texnologiyanın ekosistemin vacib bir hissəsinə çevrilməsi üçün insanlar tərəfindən qəbul edilməlidir. Beləliklə, xidmət şəbəkəsi ilə kim maraqlanır? Onun istifadəsindən kim faydalanır?
Müasir server proqram təminatını inkişaf etdirsəniz, komandanızı təxminən bir qrup kimi təsəvvür edə bilərsiniz xidmət sahibləribirlikdə biznes məntiqini inkişaf etdirən və həyata keçirən və platforma sahibləribu xidmətlərin işlədiyi daxili platformanın hazırlanmasında iştirak edir. Kiçik təşkilatlarda bunlar eyni insanlar ola bilər, lakin şirkət böyüdükcə bu rollar daha qabarıq şəkildə özünü büruzə verir və hətta alt-rollara bölünür... (Burada devopların dəyişən təbiəti haqqında deyiləcək çox şey var, mikroservislərin təşkilati təsiri və s.) n.Ancaq hələlik bu təsvirləri təbii qəbul edək).
Bu baxımdan, xidmət şəbəkəsinin aydın benefisiarları platformanın sahibləridir. Axı, platforma komandasının son məqsədi xidmət sahiblərinin biznes məntiqini həyata keçirə biləcəkləri daxili platforma yaratmaq və bunu onların fəaliyyətinin qaranlıq detallarından maksimum müstəqilliyə zəmanət verəcək şəkildə etməkdir. Xidmət şəbəkəsi təkcə bu məqsədə çatmaq üçün vacib olan imkanları təqdim etmir, həm də bunu elə edir ki, öz növbəsində xidmət sahiblərinə heç bir asılılıq qoymur.
Xidmət sahibləri də daha dolayı yolla da olsa faydalanır. Xidmət sahibinin məqsədi biznes prosesinin məntiqini həyata keçirməkdə mümkün qədər məhsuldar olmaqdır və o, əməliyyat məsələləri ilə bağlı nə qədər az narahat olsa, bir o qədər yaxşıdır. Yenidən cəhd siyasətlərini və ya TLS-ni tətbiq etmək əvəzinə, onlar yalnız biznesə fokuslana bilərlər və platformanın qalan işləri görəcəyinə ümid edə bilərlər. Onlar üçün bu, böyük üstünlükdür.
Platformaların və xidmətlərin sahibləri arasında belə bir bölünmənin təşkilati dəyəri çox qiymətləndirilə bilməz. Düşünürəm ki, o, töhfə verir əsasdır xidmət şəbəkəsinin dəyərinə töhfə.
Erkən bir Linkerd pərəstişkarı bizə niyə xidmət şəbəkəsini seçdiklərini söylədikdə bu dərsi öyrəndik: çünki bu, onlara "minimum danışmağa" imkan verdi. Budur bəzi təfərrüatlar: böyük bir şirkətdən olan uşaqlar platformalarını Kubernetes-ə köçürdülər. Tətbiq həssas məlumatlarla işlədiyi üçün onlar klasterlərdəki bütün kommunikasiyaları şifrələmək istəyirdilər. Bununla belə, vəziyyət yüzlərlə xidmətin və yüzlərlə inkişaf qrupunun olması ilə çətinləşdi. Hər kəslə əlaqə saxlamaq və onları TLS dəstəyini planlarına daxil etməyə inandırmaq perspektivi onları heç də sevindirmədi. Linkerd-i quraşdırmaqla onlar köç etdilər məsuliyyət tərtibatçılardan (nöqteyi-nəzərindən bu, lazımsız problem idi) bu, yüksək səviyyəli prioritet olan platformaçılara qədər. Başqa sözlə, Linkerd onlar üçün təşkilati problemdən çox texniki problemi həll edirdi.
Bir sözlə, xidmət şəbəkəsi, daha doğrusu, texniki bir həll deyil, amma sosial-texniki Problemlər. (Çox sağ ol bu termini təqdim etdiyinə görə.
Xidmət şəbəkəsi bütün problemlərimi həll edəcəkmi?
Bəli. Demək istəyirəm ki, yox!
Yuxarıda qeyd olunan xüsusiyyətlərin üç sinfinə - etibarlılıq, təhlükəsizlik və müşahidə edilə bilənliyə nəzər saldıqda aydın olur ki, xidmət şəbəkəsi bu problemlərin heç birinin tam həlli deyil. Linkerd təkrar sorğular göndərə bilsə də (əgər o, onların idempotent olduğunu bilirsə), xidmət nəhayət sıradan çıxdıqda istifadəçiyə nə qaytarılacağına dair qərar qəbul etmək iqtidarında deyil - belə qərarlar tətbiq tərəfindən verilməlidir. Linkerd uğurlu sorğuların statistikasını saxlaya bilər, lakin o, xidmətə baxmaq və onun daxili ölçülərini təqdim etmək iqtidarında deyil - tətbiqdə belə alətlər dəsti olmalıdır. Linkerd mTLS-i yerləşdirməyə qadir olsa da, tam hüquqlu təhlükəsizlik həlləri daha çox şey tələb edir.
Xidmət şəbəkəsinin təklif etdiyi bu sahələrdə xüsusiyyətlərin bir hissəsi ilə əlaqədardır platforma xüsusiyyətləri. Bununla mən funksiyaları nəzərdə tuturam:
- Biznes məntiqindən asılı olmayaraq. Çağırış histoqramlarının Foo və Bar arasında qurulma üsulu, olub-olmamasından tamamilə müstəqildir niyə Foo Bara zəng edir.
- Düzgün həyata keçirmək çətindir. Linkerd-də təkrar cəhdlər, təkrar cəhd büdcələri kimi hər cür zərif şeylərlə parametrləşdirilir. (büdcələri yenidən sınayın), çünki belə şeylərin həyata keçirilməsinə sadə düşüncəli yanaşma, şübhəsiz ki, "istəklər uçqunu" deyilən şeyin ortaya çıxmasına səbəb olacaqdır. (fırtına təkrar cəhd) və paylanmış sistemlərə xas olan digər problemlər.
- Davamlı tətbiq edildikdə ən təsirli olur. TLS mexanizmi yalnız hər yerdə tətbiq edildikdə məna kəsb edir.
Bu xüsusiyyətlər proksi səviyyəsində (tətbiq səviyyəsində deyil) həyata keçirildiyindən, xidmət şəbəkəsi onları ekranda ifşa edir. platformalar, proqramlar deyil. Beləliklə, xidmətlərin hansı dildə yazıldığını, hansı çərçivədən istifadə etdiyini, kimin və niyə yazdığının əhəmiyyəti yoxdur. Proksilər bütün bu təfərrüatlardan kənarda işləyir və konfiqurasiya, yenilənmə, əməliyyat, texniki xidmət və s. tapşırıqları da daxil olmaqla, bu funksionallığın əsas əsası yalnız platforma səviyyəsindədir.
Xidmət mesh imkanlarının nümunələri
Xülasə, xidmət şəbəkəsi etibarlılıq, müşahidə oluna bilənlik və ya təhlükəsizlik üçün tam həll yolu deyil. Bu sahələrin əhatə dairəsi xidmət sahiblərinin, Ops/SRE komandalarının və digər şirkət maraqlı tərəflərinin məcburi iştirakını nəzərdə tutur. Xidmət şəbəkəsi yalnız bu sahələrin hər biri üçün platforma səviyyəsində "dilim" təmin edir.
Niyə xidmət şəbəkəsi hazırda populyarlaşıb?
Yəqin ki, hazırda maraqlanırsınız: OK, əgər xidmət şəbəkəsi bu qədər yaxşıdırsa, niyə on il bundan əvvəl biz milyonlarla proksi-nüsxəni yığında yerləşdirməyə başlamadıq?
Bu sualın banal cavabı var: on il əvvəl hamı monolitlər qurdu və heç kimə xidmət şəbəkəsi lazım deyildi. Bu doğrudur, amma mənim fikrimcə, bu cavab nöqtəni qaçırır. Hələ on il əvvəl mikroservislərin geniş miqyaslı sistemlərin yaradılmasının perspektivli üsulu kimi konsepsiyası Twitter, Facebook, Google və Netflix kimi şirkətlərdə geniş müzakirə edilmiş və tətbiq edilmişdir. Ümumi qavrayış - ən azı sənayenin mənim təmasda olduğum hissələrində - mikroservislərin böyük sistemlər qurmaq üçün "düzgün yol" olduğu, hətta çətin olsa da, belə idi.
Əlbətdə ki, on il əvvəl mikroservislərdən istifadə edən şirkətlər olsa da, xidmət şəbəkəsi yaratmaq üçün proksiləri hər yerə yapışdırmırdılar. Bununla belə, diqqətlə baxsanız, oxşar bir şey etdilər: bu şirkətlərin bir çoxu şəbəkə üçün xüsusi daxili kitabxanadan (bəzən yağlı müştəri kitabxanası adlanır) istifadə etməyi məcbur etdi. yağlı müştəri kitabxanası).
Netflix-də Hysterix, Google-da Stubby, Twitter-də Finagle kitabxanası var idi. Məsələn, Finagle Twitter-də hər yeni xidmət üçün məcburi olub. O, əlaqələrin həm müştəri, həm də server tərəfini idarə edir, təkrar sorğulara icazə verir, sorğunun yönləndirilməsini, yük balansını və ölçməni dəstəkləyirdi. Xidmətin nə etməsindən asılı olmayaraq, bütün Twitter yığını boyunca ardıcıl etibarlılıq və müşahidə oluna bilən təbəqə təmin etdi. Əlbəttə ki, o, yalnız JVM dilləri üçün işləyirdi və bütün proqram üçün istifadə edilməli olan proqramlaşdırma modelinə əsaslanırdı. Bununla belə, onun funksionallığı xidmət şəbəkəsi ilə demək olar ki, eyni idi. (Əslində, Linkerd-in ilk versiyası proxy formada bükülmüş Finagle idi.)
Beləliklə, on il əvvəl təkcə mikroservislər deyil, həm də xidmət şəbəkəsinin bu gün həll etdiyi eyni problemləri həll edən xüsusi proto-servis-mesh kitabxanaları var idi. Ancaq o zaman xidmət şəbəkəsinin özü yox idi. O görünməzdən əvvəl başqa bir dəyişiklik olmalı idi.
Və burada daha dərin cavab son 10 il ərzində baş verən başqa bir dəyişiklikdə gizlənir: mikroservislərin yerləşdirilməsi qiymətində kəskin azalma baş verib. On il əvvəl mikroservislərdən istifadə edən yuxarıda qeyd olunan şirkətlər - Twitter, Netflix, Facebook, Google - böyük miqyaslı və böyük resurslara malik şirkətlər idi. Onların nəinki ehtiyacları var idi, həm də mikroservislərə əsaslanan böyük proqramları qurmaq, yerləşdirmək və idarə etmək bacarığı var idi. Twitter mühəndislərinin monolit yanaşmadan mikroservis yanaşmasına keçmək üçün sərf etdikləri enerji və səy heyrətamizdir. (Düzünü desəm, işlədiyi kimi.) Bu cür infrastruktur manevrləri o zaman kiçik şirkətlər üçün qeyri-mümkün idi.
İndiki vaxta keçək. Bu gün elə startaplar var ki, orada mikroservislərin tərtibatçılara nisbəti 5:1 (və ya hətta ) və üstəlik, onların öhdəsindən uğurla gəlirlər! Əgər 5 nəfərdən ibarət startap 50 mikroxidməti gərginləşdirmədən idarə edə bilirsə, onda nə isə onların həyata keçirilməsinin dəyərini açıq şəkildə azaldıb.
Monzoda 1500 mikroservis; hər bir xətt trafikə icazə verən müəyyən edilmiş şəbəkə qaydasıdır
Əməliyyat mikroxidmətlərinin dəyərinin kəskin azalması bir prosesin nəticəsidir: konteynerlərin artan populyarlığı и orkestrlər. Bu, xidmət şəbəkəsinin yaranmasına nə kömək etdiyi sualına dəqiq cavabdır. Eyni texnologiya həm xidmət şəbəkəsini, həm də mikroservisləri cəlbedici etdi: Kubernetes və Docker.
Niyə? Yaxşı, Docker bir böyük problemi - qablaşdırma problemini həll edir. Tətbiqi və onun (şəbəkədənkənar) iş vaxtından asılılıqlarını konteynerdə qablaşdırmaqla, Docker proqramı hər yerdə yerləşdirilə və işlədilə bilən fungiable vahidə çevirir. Eyni zamanda, əməliyyatı xeyli asanlaşdırır. çoxdilli yığın: Konteyner atomik icra vahidi olduğundan, yerləşdirmə və əməliyyat məqsədləri üçün JVM, Node, Go, Python və ya Ruby tətbiqi olmasının fərqi yoxdur. Siz sadəcə onu idarə edirsiniz və budur.
Kubernetes hər şeyi növbəti səviyyəyə aparır. İndi bir dəstə "icra edilə bilən şeylər" və onları işlətmək üçün bir çox maşın var, onları bir-birinə uyğunlaşdıra biləcək bir alətə ehtiyac var. Geniş mənada siz Kubernetes-ə çoxlu konteynerlər və çoxlu maşınlar verirsiniz və bu, onları bir-birinə uyğunlaşdırır (əlbəttə ki, bu dinamik və daim dəyişən prosesdir: sistem ətrafında yeni konteynerlər hərəkət edir, maşınlar işə başlayır və dayanır və s. Lakin, Kubernetes bütün bunları nəzərə alır).
Kubernetes qurulduqdan sonra bir xidməti yerləşdirmək və idarə etmək üçün tələb olunan vaxt on xidməti yerləşdirmək və idarə etmək üçün xərclərdən çox da fərqlənmir (əslində, 100 xidmət üçün demək olar ki, eynidir). Bu konteynerlərə çoxdilli tətbiqi təşviq edən qablaşdırma mexanizmi kimi əlavə edin və bir çox dildə yazılmış mikroservislər kimi həyata keçirilən bir ton yeni tətbiqiniz var, xidmət şəbəkəsinin çox uyğun olduğu mühit.
Beləliklə, xidmət şəbəkəsi ideyasının niyə indi populyarlaşdığı sualına cavab tapırıq: Kubernetes-in xidmətlər üçün təmin etdiyi vahidlik birbaşa xidmət şəbəkəsinin qarşısında duran əməliyyat tapşırıqlarına aiddir. Siz proksiləri konteynerlərə yığırsınız, Kubernetes-ə onları mümkün olan yerə yapışdırmaq tapşırığını verirsiniz və voila! Nəticədə, bir xidmət şəbəkəsi əldə edirsiniz, Kubernetes isə onun yerləşdirilməsinin bütün mexanikasına nəzarət edir. (Ən azı quş baxışı ilə. Təbii ki, bu prosesin bir çox nüansları var).
Xülasə: xidmət şəbəkəsinin on il əvvəl deyil, indi populyarlaşmasının səbəbi Kubernetes və Dockerin nəinki əhəmiyyətli dərəcədə artmasıdır ehtiyac çoxdilli mikroservislər dəsti kimi tətbiqlərin həyata keçirilməsini sadələşdirir, həm də əhəmiyyətli dərəcədə azaldılır xərclər yan vaqon proksi parklarının yerləşdirilməsi və saxlanması mexanizmlərini təmin etməklə onun fəaliyyəti üçün.
Xidmət şəbəkəsi haqqında niyə bu qədər danışılır?
Xəbərdar: Bu bölmədə mən hər cür fərziyyələrə, fərziyyələrə, uydurmalara və daxili məlumatlara müraciət edirəm.
"Xidmət şəbəkəsi" üçün axtarış bir çox təkrar emal edilmiş, aşağı kalorili məzmun, qəribə layihələr və əks-səda kamerasına layiq bir təhrif kaleydoskopunu tapacaq. Hər hansı bir moda yeni texnologiya buna malikdir, lakin xidmət şəbəkəsi vəziyyətində problem xüsusilə kəskindir. Niyə?
Yaxşı, bu qismən mənim günahımdır. Mən bu kimi saysız-hesabsız blog yazıları və məqalələr vasitəsilə hər fürsətdə Linkerd və xidmət şəbəkəsini tanıtmaq üçün əlimdən gələni etmişəm. Amma mən o qədər də güclü deyiləm. Bu suala həqiqətən cavab vermək üçün ümumi vəziyyət haqqında bir az danışmaq lazımdır. Və bir layihəni qeyd etmədən bu barədə danışmaq mümkün deyil: Google, IBM və Lyft tərəfindən birgə hazırlanmış açıq mənbəli xidmət şəbəkəsidir.
(Həmin üç şirkətin çox fərqli rolları var: Lyft-in iştirakı yalnız adla məhdudlaşır; onlar Elçi müəllifidir, lakin İstio-nun inkişafında istifadə etmirlər və ya iştirak etmirlər. IBM Istio-nun inkişafında iştirak edir və ondan istifadə edir. Google Istio-nun inkişafında iştirak edir, amma deyə bilərəm ki, əslində ondan istifadə etmir.)
Istio layihəsi iki şeyə görə diqqət çəkir. Birincisi, bu, xüsusən də Google-un təşviqatına qoyduğu böyük marketinq səyləridir. Hesab edirəm ki, hazırda xidmət şəbəkəsi konsepsiyasından xəbərdar olan insanların çoxu ilk dəfə Istio sayəsində bu barədə öyrəniblər. İkinci xüsusiyyət İstionun nə qədər pis qarşılandığıdır. Bu məsələdə mən, təbii ki, maraqlı tərəfəm, lakin mümkün qədər obyektiv olmağa çalışıram, yenə də kömək edə bilmirəm. , çox spesifik deyil (unikal olmasa da: ağlıma systemd gəlir, ...) Açıq Mənbə layihəsi üçün.
(Praktikada Istio-nun təkcə mürəkkəblik və UX ilə deyil, həm də performansla bağlı problemləri var. Məsələn, müddət ərzində üçüncü tərəf tərəfindən aparılan ekspertlər, Istio-nun quyruq gecikməsinin Linkerd-dən 100 dəfə yüksək olduğu vəziyyətləri, həmçinin Linkerdin müvəffəqiyyətlə işləməyə davam etdiyi və Istio-nun fəaliyyətini tamamilə dayandırdığı zaman resurs çatışmazlığı ilə əlaqəli vəziyyətləri tapdılar.)
Bunun niyə baş verdiyinə dair nəzəriyyələrimi bir kənara qoyaraq, hesab edirəm ki, xidmət şəbəkəsi ətrafında miqyasdan kənar şırınga Google-un iştirakı ilə bağlıdır. Məhz, aşağıdakı üç amilin birləşməsi:
- Google tərəfindən Istio-nun obsesif təşviqi;
- layihəyə uyğun olmayan, tənqidi münasibət;
- yaddaşı hələ də təzə olan Kubernetes-in son zamanlarda artan populyarlığı.
Bu amillər birlikdə rasional mühakimə qabiliyyətinin zəiflədiyi və yalnız gözəl müxtəlifliyin qaldığı bir növ məstedici, anoksik mühitə çevrilir. .
Linkerdin nöqteyi-nəzərindən, bu... Mən bunu qarışıq nemət kimi təsvir edərdim. Demək istədiyim odur ki, xidmət şəbəkəsinin əsas şəbəkəyə daxil olması əladır - Linkerd ilk dəfə 2016-cı ildə ortaya çıxanda belə deyildi və insanların diqqətini layihəyə cəlb etmək həqiqətən çətin idi. İndi belə bir problem yoxdur! Ancaq pis xəbər budur ki, xidmət şəbəkəsi vəziyyəti bu gün o qədər çaşqındır ki, həqiqətən hansı layihələrin xidmət şəbəkəsinə aid olduğunu anlamaq demək olar ki, mümkün deyil (hansısının xüsusi istifadə üçün ən yaxşı olduğunu anlamaq bir yana). Bu, şübhəsiz ki, hər kəsin yoluna mane olur (və mütləq bəzi hallarda Istio və ya başqa bir layihə Linkerddən daha yaxşıdır, çünki sonuncu hamıya uyğun bir həll deyil).
Linkerd tərəfindən bizim strategiyamız səs-küyə məhəl qoymamaq, diqqəti cəmiyyətdəki real problemlərin həllinə yönəltmək və mahiyyətcə şırınganın sönməsini gözləmək olub. Nəhayət, şırınga səngiəcək və biz sülh şəraitində işləməyə davam edə bilərik.
O vaxta qədər hamımız səbirli olmalıyıq.
Təvazökar bir proqram mühəndisi olan xidmət şəbəkəsi mənim üçün faydalı olacaqmı?
Aşağıdakı anket bu suala cavab verməyə kömək edəcək:
Siz eksklüziv olaraq biznes məntiqinin həyata keçirilməsi ilə məşğul olursunuz? Bu halda, xidmət şəbəkəsi sizin üçün faydalı olmayacaq. Yəni, əlbəttə ki, bununla maraqlana bilərsiniz, amma ideal olaraq, xidmət şəbəkəsi ətrafınızdakı heç bir şeyə birbaşa təsir etməməlidir. Ödəniş aldığınız şey üzərində işləməyə davam edin.
Kubernetes istifadə edən bir şirkətdə platforma saxlayırsınız? Bəli, bu halda sizə xidmət şəbəkəsinə ehtiyacınız var (əlbəttə ki, əgər siz K8-lərdən yalnız monolit və ya toplu emal etmək üçün istifadə etmirsinizsə - amma sonra K8-lərə niyə ehtiyacınız olduğunu soruşmaq istərdim). Çox güman ki, özünüzü müxtəlif insanlar tərəfindən yazılmış bir çox mikroservis ilə bir vəziyyətdə tapacaqsınız. Onların hamısı bir-biri ilə qarşılıqlı əlaqədə olur və iş vaxtından asılılıqların qarmaqarışıqlığına bağlıdır və bütün bunlarla məşğul olmağın bir yolunu tapmalısınız. Kubernetes-in istifadəsi "özünüz üçün" bir xidmət şəbəkəsi seçməyə imkan verir. Bunu etmək üçün onların imkanları və xüsusiyyətləri ilə tanış olun və mövcud layihələrdən hər hansı birinin sizə ümumiyyətlə uyğun olub-olmaması sualına cavab verin (tədqiqatınıza Linkerd ilə başlamağı tövsiyə edirəm).
Kubernetesdən istifadə etməyən, lakin mikroservislərdən istifadə edən bir şirkət üçün platforma işlədirsiniz? Bu halda, xidmət şəbəkəsi sizin üçün faydalı olacaq, lakin onun istifadəsi qeyri-ciddi olacaqdır. Əlbəttə edə bilərsən təqlid etmək bir dəstə proksi yerləşdirməklə xidmət şəbəkəsi, lakin Kubernetes-in mühüm üstünlüyü məhz yerləşdirmə modelidir: bu proksiləri əl ilə saxlamaq daha çox vaxt, səy və xərc tələb edəcəkdir.
Monolitlərlə işləyən bir şirkətdə platformaya cavabdehsiniz? Bu halda, yəqin ki, xidmət şəbəkəsinə ehtiyacınız olmayacaq. Əgər siz dəqiq müəyyən edilmiş və nadir hallarda dəyişən qarşılıqlı əlaqə nümunələrinə malik monolitlərlə (və ya hətta monolit dəstləri ilə) işləyirsinizsə, onda xidmət şəbəkəsinin sizə təklif edəcəyi çox az şey var. Beləliklə, sadəcə ona məhəl qoymayaraq, pis bir yuxu kimi yox olacağını ümid edə bilərsiniz...
Nəticə
Yəqin ki, xidmət şəbəkəsini hələ də "dünyanın ən qızğın texnologiyası" adlandırmaq olmaz - bu şübhəli şərəf, çox güman ki, bitcoin və ya AI-yə aiddir. Ola bilsin ki, o, ilk beşliyə daxildir. Ancaq səs-küy və səs-küy qatlarını aşsanız, xidmət şəbəkəsinin Kubernetes-də tətbiqlər yaradanlara real faydalar gətirdiyi aydın olur.
Linkerd-i sınamağınızı istərdim - onu Kubernetes klasterində quraşdırın (və ya hətta noutbukda Minikube) və mənim nə danışdığımı özünüz görə bilərsiniz.
FAQ
- Xidmət şəbəkəsinə məhəl qoymasam, o yox olacaq?
- Mən sizi məyus etməliyəm: xidmət şəbəkəsi uzun müddətdir bizimlədir.
— Amma xidmət şəbəkəsindən istifadə etmək İSTƏMİRƏM!
- Yaxşı, lazım deyil! Ən azı onun əsasları ilə tanış olmağın lazım olub olmadığını görmək üçün yuxarıdakı anketimi oxuyun.
— Yeni souslu köhnə ESB/middleware deyilmi?
- Xidmət şəbəkəsi semantik deyil, əməliyyat məntiqi ilə məşğul olur. müəssisə xidməti avtobusu (). Bu ayrılığın saxlanması xidmət şəbəkəsinin eyni aqibətdən qaçmasına kömək edir.
- Xidmət şəbəkəsi API şlüzlərindən nə ilə fərqlənir?
Bu mövzuda milyonlarla məqalə var. Sadəcə google.
Elçi xidmət şəbəkəsidir?
- Xeyr, Envoy xidmət şəbəkəsi deyil, proksi serverdir. O, xidmət şəbəkəsini təşkil etmək üçün istifadə edilə bilər (və daha çox - bu, ümumi təyinatlı bir proxydir). Ancaq özlüyündə bu, xidmət şəbəkəsi deyil.
- Şəbəkə Xidməti Mesh - bu xidmət şəbəkəsidir?
- Yox. Adına baxmayaraq, bu xidmət şəbəkəsi deyil (marketinqin möcüzələrini necə bəyənirsiniz?).
- Xidmət şəbəkəsi mesaj növbəsinə əsaslanan reaktiv asinxron sistemimə kömək edəcəkmi?
- Xeyr, xidmət şəbəkəsi sizə kömək etməyəcək.
- Hansı xidmət şəbəkəsindən istifadə etməliyəm?
- , ağıl yoxdur.
- Məqalə pisdir! / Müəllif - sabun üzərində!
— Lütfən, onun linkini bütün dostlarınızla paylaşın ki, onlar buna əmin olsunlar!
Təşəkkürlər
Başlıqdan təxmin etdiyiniz kimi, bu məqalə Jay Krepsin fantastik traktatından ilhamlanıb "". Mən Jay ilə on il əvvəl Linked In-də müsahibə verərkən tanış oldum və o vaxtdan bəri mənə ilham verdi.
Mən özümü "Linkerd developer" adlandırmağı xoşlasam da, reallıq ondan ibarətdir ki, mən daha çox layihədə README.md faylının baxıcısıyam. Bu gün Linkerd üzərində işləyir , , insanlar və bu layihə ianəçilər və istifadəçilərin heyrətamiz icması olmadan mümkün olmazdı.
Və nəhayət, Linkerdin yaradıcısına xüsusi təşəkkürlər, (primus inter pares)uzun illər əvvəl mənimlə birlikdə xidmət şəbəkəsi ilə bütün bu təlaşa baş-başa dalmış olan .
Tərcüməçidən PS
Bloqumuzda da oxuyun:
- «";
- «";
- «";
- «";
- «.
Mənbə: www.habr.com