🥇Mikroservislər: ölçü əhəmiyyətlidir, hətta Kubernetesiniz olsa belə

19 sentyabr Moskvada baş verdi birinci tematik mitap HUG (Highload++ User Group), mikrosistemlərə həsr olunmuşdur. Orada «Mikrosistemlərin istismarı: ölçü əhəmiyyətlidir, hətta sizdə Kubernetes olsa belə» adlı müzakirə təqdim olundu, burada «Flant» şirkətinin mikrosistem arxitekturası ilə bağlı layihələrin istismarı ilə bağlı geniş təcrübəsini paylaşdıq. Bu, ilk növbədə, mövcud və ya gələcək layihələrində bu yanaşmanın tətbiqi haqqında düşünən bütün proqramçılar üçün faydalı olacaq.

Təqdim edirik məruzənin video çəkilişi 50 dəqiqə, məqalədən daha ətraflıdır), eləcə də onun əsas xülasəsini mətndə.

Qeyd: Video və təqdimat bu dərcin sonunda da mövcuddur.

Giriş

Adətən yaxşı bir hekayənin başlanğıcı, əsas süjeti və nəticəsi olur. Bu müzakirə daha çox tragik bir başlanğıca bənzəyir. Eyni zamanda, mikrosistemlərə yanaşmanın tərəfdən təqdim olunduğunu qeyd etmək vacibdir. istismar etmə imkanını istisna etmir..

Belə bir qrafiklə başlayacağam, müəllifi (2015-ci ildə) oldu Martin Fowler:

Burada görünür ki, monolit tətbiqi müəyyən bir ölçüyə çatdıqda məhsuldarlıq aşağı düşməyə başlayır. Mikrosistemlərdə isə ilkin məhsuldarlıq aşağıdır, lakin mürəkkəbləşdikcə effektivliyin azalması bu qədər görünmür.

Bu qrafiki Kubernetes istifadəsi halına əlavə edəcəyəm:

Mikrosistemlərin tətbiqi niyə daha yaxşı oldu? Çünki bu arxitektura ciddi tələblər irəli sürür ki, bu da Kubernetes imkanları ilə mükəmməl yerinə yetirilir. Digər tərəfdən, bu funksionallığın bir hissəsi monolit üçün də faydalı olacaq, xüsusən də, bugünkü tipik monolit - tam monolit deyil (ətraflı məlumat daha sonra müzakirədə olacaq).

Göründüyü kimi, son qrafik (həm monolit, həm də mikrosistem tətbiqinin Kubernetes infrastrukturasında) əvvəlkindən çox da fərqlənmir. Daha sonra Kubernetes-dən istifadə edərək istismar edilən tətbiqlərdən danışılacaq.

Faydalı və zərərli mikrosistemlik

Burada əsas fikir:

Nədir normal mikrosistem arxitekturası? Bu, sizə real fayda gətirməlidir, iş səmərəliliyini artırmalıdır. Qrafikə qayıdaraq, belədir:

Əgər bunu faydalıadlandırsaq, qrafikin digər tərəfində isə zərərli mikrosistemlik (işə mane olur):

Əsas fikrə qayıdaraq: mənim təcrübəmə etibar etməyə dəyərmi? Bu ilin başlanğıcından bəri mən 85 layihə baxdım. Bütün bunlar mikroservis mimarisine sahip olmasa da (yaklaşık üçte biri ile yarısı arasında bir orana sahipler), yine de büyük bir sayı. Biz (Flant şirketi) dış kaynak kullanıcısı olarak, hem küçük şirketlerde (5 geliştirici ile) hem de büyük işletmelerde (~500 geliştirici) geliştirilen geniş bir uygulama yelpazesini görebiliyoruz. Ek bir avantaj ise, bu uygulamaların yıllar içinde nasıl yaşayıp geliştiğini izleyebiliyor olmamız.

Mikroservisler neden?

Mikroservislerin faydalarıyla ilgili soruya kesin bir cevap var söz konusu olan Martin Fowler'dan:

modülerlikte kesin sınırlar;
bağımsız dağıtım;
teknolojilerde özgürlük.

Yazılım mimarları ve geliştiricilerle çokça konuşup, onlara mikroservisleri neden tercih ettiklerini sordum. Beklentilerini listeledim. İşte çıkan sonuçlar:

Belirli noktaları "duygusal olarak" tanımlarsak:

modüllerde kesin sınırlar: işte korkunç bir monolitimiz var, şimdi her şey Git depolarına düzgün bir şekilde yerleştirilecek, her şey "raf raf" olacak, sıcak ile yumuşak birbirine karışmadan;
dağıtım bağımsızlığı: hizmetleri bağımsız olarak dağıtabileceğiz, böylece geliştirme süreçleri daha hızlı ilerleyecek (paralel olarak yeni özellikler yayımlayabileceğiz);
geliştirme bağımsızlığı: bu mikroservisi şu ekibe/geliştiriciye verebiliriz, o da bir diğerini başka birine vererek hızlı bir geliştirme süreci sağlayabiliriz;
" müzakirəlidir, buna görə açarla iş üçün 3 dəqiqəlik vaxt ayırmağa qərar verildi.dırdaha yüksek güvenilirlik: eğer kısmi bir degradasyon olursa (20 mikroservisten biri çökse), sadece bir buton çalışmayacak, ama sistem kendisi devam edecek.

Tipik (zararlı) mikroservis mimarisi

Gerçekte beklediğimiz gibi olmadığına dair açıklama yapmak için, toplulaştırılmış mikroservis mimarisi örneği sunacağım, birçok farklı projeden deneyimlerime dayanarak.

Örnek olarak Amazon veya en azından OZON ile rekabet etmeyi planlayan soyut bir internet mağazası alacağız. Onun mikroservis mimarisi şöyle görünüyor:

Birçok nedenden ötürü, bu mikroservisler farklı platformlarda yazılmıştır:

Her mikroservisin bağımsızlığa sahip olması gerektiğinden, çoğu kendi veritabanı ve önbelleğe ihtiyaç duyar. Nihai mimari şu şekildedir:

Sonuçları nelerdir?

Fowler’ın bu konuda bir makalesi vardır mikroservislerin kullanımının "bedeli" hakkında:

Biz de, beklentilerimizin karşılanıp karşılanmadığına bakalım.

Modüllerde kesin sınırlar…

Amma gerçekten kaç mikroservisi düzeltmemiz gerekiyor, değişikliği yayımlamak için? Her şeyin nasıl çalıştığını, dağıtılmış izleyici olmadan anlayabilir miyiz (çünkü her istek yarım mikroservis tarafından işleniyor)?

Büyük bir "yer yığını" deseni var.большой комок грязи», burada hətta paylanmış çirkli top meydana gəlib. Buna sübut olaraq — sorğuların necə getdiyinə dair təxmini bir illüstrasiya:

İnkişafın müstəqilliyi...

Texniki olaraq bu əldə edilib: hər mikrositimi ayrıca yayımlaya bilərik. Ancaq praktiki olaraq, hər zaman bir çox mikrositimi, onların yayılma sırasını nəzərə alaraq düşünmək lazımdır. Xeyir, mütləq ayrı bir mühitdə, buraxılışın düzgün sırada olub olmadığını sınaqdan keçirmək lazım.Texnologiya seçimi azadlığı...

Var. Ancaq yadınızda saxlayın ki, bu azadlıq bəzən qaçılmaz xaosla üzləşir. Burada yalnız "oyun" məqsədilə texnologiya seçməmək çox vacibdir.

İnkişafın müstəqilliyi...

Bütün tətbiq üçün test mühitini necə qurmaq olar (bu qədər komponentdən)? Hələ də onu aktual saxlamaq lazımdır. Bütün bunlar onu gətirir ki,

əslində tutula biləcəyimiz test mühitlərinin sayı minimum olur.Bunu yerli olaraq yayımlamaq mümkündür?.. Beləliklə, çox vaxt inkişafçı işini müstəqil edir, ancaq "tahminən", çünki test mühiti üçün sərbəst vaxt gözləməli olur. Ayırıcı miqyaslanma....

Bəli, amma istifadə olunan DBM-lərdə məhduddur. Verilmiş arxitektura nümunəsində Cassandra-da problem olmayacaq, amma MySQL və PostgreSQL-də olacaq.

B

öyük etibarlılıq...

Bir mikrositimin uğursuzluğunun faktiki olaraq bütün sistemin düzgün işləməsini pozduğuna əlavə olaraq, hələ bir yeni problem var:dırhər mikrositimi mübahisəsiz etibarlı etmək çox çətindir.

Çünki mikrositlərdə müxtəlif texnologiyalar (memcache, Redis və s.) istifadə olunur, hər biri üçün hər şeyi düşünmək və həyata keçirmək lazımdır ki, bu da əlbəttə mümkündür, lakin böyük resurslar tələb edir. Yükün ölçülməsi...Bu, əslində, yaxşıdır.

Mikrositlərin "yüngüllüyü"...

Böyük şəbəkə xərcləri

(DNS sorğularının artması və s.) meydana gəldi, lakin bir çox alt sorğular səbəbindən məlumatları

təkrarlamağa (cache-ləri saxlamaq), bu da saxlama tutumunu artırdı. Və gözləntilərimizə uyğun olaraq nəticə budur: Amma bu hələ də bitmir! Çünki:

Bəlkə də mesajlar avtobusu tələb olunacaq.

Müvafiq an üçün konsistent ehtiyat nüsxəsini necə yaratmaq olar? Tək

realdır

variant — trafikini dayandırmaqdır. Ancaq bunu istehsalda necə etmək olar?
Bir neçə bölgənin dəstəklənməsindən danışırıqsa, hər birində dayanıqlığı təşkil etmək çox işlək bir işdir. Mərkəzləşdirilmiş dəyişiklikləri tətbiq etmə problemi yaranır. Məsələn, əgər PHP versiyasını yeniləmək lazım olsa, hər bir repo (onlar onlarla) üçün kommit etmək lazım olacaq. вариант — выключить трафик для этого. Но как это сделать на production?
Если идёт речь о поддержке нескольких регионов, то организовать устойчивость в каждом из них — очень трудоёмкая задача.
Появляется проблема внесения централизованных изменений. Например, если нам нужно обновить версию PHP, то потребуется сделать коммит в каждый репозиторий (а их — десятки).
İşlem xətalarının artması görünən şəkildə exponensialdır.

Bununla nə etmək lazımdır?

Monolit tətbiqindən başlayın. Fowler'ın təcrübəsi deyir ki, demək olar ki, bütün müvəffəqiyyətli mikrosistem tətbiqləri ilk olaraq böyük bir monolitdən başlayıb, sonra parçalanıb. Eyni zamanda, ilk andan mikrosistem kimi qurulan demək olar ki, bütün sistemlər gec-tez ciddi problemlərlə qarşılaşmışdır.

Başqa bir dəyərli fikir - mikrosistem arxitekturasının müvəffəqiyyətli olması üçün sizin həm sahəni, həm də mikrosistemləri necə edəcəyinizi çox yaxşı bilməlisiniz.Ən yaxşı yolu sahəni öyrənmək - monolit yaratmaqdır.

Amma artıq belə bir vəziyyətdə isek, nə etməliyik?

Hər hansı bir problemin həllinə ilk addım - onunla razılaşmaq və bunun bir problem olduğunu başa düşməkdir, artıq əzab çəkmək istəmirik.

Əgər genişlənmiş bir monolitlə (resurs alıb artırma imkanımız bitdiyində) onu kəssək, bu vəziyyətdə əksinə bir şəkil olur: həddən artıq mikrosistemlik artıq kömək etmirsə, mane olur - lazımsız olanları kəsin və genişləndirin!

Məsələn, yuxarıda müzakirə olunan toplayıcı nümunə üçün...

Ən şübhəli mikrosistemlərdən xilas olun:

Frontend yaratmaqdan məsul bütün mikrosistemləri birləşdirin:

... bir mikrosistemə, bir (müasir və normal, özünüz necə hesab edirsinizsə) dil/frameworkdə yazın:

Onun bir ORM (bir DBMS) olacaq və əvvəlcə bir neçə tətbiq:

... əslində daha çoxunu oraya köçürmək mümkündür, belə bir nəticə əldə edərək:

Kubernetes-də bunu ayrı nümunələr kimi işə salırıq, deməli, hələ də yükü ölçə bilir və onları ayrıca miqyaslandıra bilirik.

Xülasə olaraq

Bütün şəklə daha geniş baxın. Bu mikrosistemlərlə bağlı problemlərin çoxu kimsə öz işini götürəndə, amma "mikrosistemlərlə oynamaq" istəyən kimsə səbəbindən yaranır.

Mikrosistemlər sözündəki "mikro" artıqdır. Onlar yalnız böyük monolitdən daha kiçikdirlər. Amma onları kiçik bir şey kimi düşünməməlisiniz.

Və son düşüncə üçün ilkin qrafikə qayıdaq:

Ona əlavə edilmiş qeydlər (sağ üst küncdə) bunun göstərdiyi budur ki, sizin layihənizi hazırlayan komandanın bacarıqları həmişə birincildir - onlar sizin mikrosistemlər və monolit arasındakı seçiminizdə əsas rol oynayacaqlar. Əgər komandada bacarıqlar çatışmırsa, amma mikrosistemlər hazırlamağa başlayırsa, bu tarixi mütləq fəlakətli olacaq.

Video və slaydlar

Tədbirdən video (~50 dəqiqə; təəssüf ki, bu, iştirakçıların sayəsində meydana gələn çoxsaylı emosiyaları çatdıra bilmir, bu isə təqdimatın ruhunu müəyyənləşdirirdi, amma olduğu kimi):