Görünür, mikrosistemlərə olan həyəcan pik nöqtəsini keçib. Artıq hər həftə 'Monolitimi 150 xidmətə necə köçürdüm' başlıqlı yazıları oxumuruk. İndi daha çox məqbul fikirlər eşidirəm: 'Mən monoliti sevmirəm, sadəcə effektivliyə önəm verirəm'. Hətta bir neçə migrasiyaya da şahidlik etmişik. Bir böyük tətbiqdən bir neçə kiçik xidmətə keçərkən, bir sıra yeni problemlərlə qarşılaşacaqsınız. Onları mümkün qədər qısa şəkildə sadalayım.
Quraşdırma: əsas kimyadan kvant mexanikasına.
Əsas məlumat bazası və arxa planda proses işləməsiylə bağlı konfiqurasiya nisbətən aydın bir proses oldu. Mən GitHub-da readme-ni yayımlayıram — və tez-tez bir saat, ən çox iki saat ərzində, hər şey işləyir, mən yeni bir layihəyə başlayıram. Kodun əlavə edilməsi və işə salınması, ən azından başlanğıc mühiti üçün, ilk gündə edilir. Amma əgər mikrosistemlərə keçmək qərarına gəlsək, ilkin işə salma vaxtı göylərə yüksəlir. Bəli, indi Docker var və K8 maşın klasteri ilə orkestrasiya var, lakin başlanğıc proqramçı üçün bunlar çox daha çətindir. Bir çox junior üçün bu, əslində lazımsız bir çətinlik olan bir yük.
Sistemi başa düşmək asan deyil.
Bir anlıq bizim junior-a diqqət yetirək. Monolitik tətbiqlərdə xəta baş verdikdə, onu izləmək və dərhal debuq etməyə keçmək asan idi. İndi bizdə bir xidmət var ki, o, digər bir xidmətlə danışır, o da mesaj xətində əvvəlki xidmətə nəsə nəql edir - və burada bir xəta meydana çıxır. Biz bütün bu hissələri bir araya gətirməliyik ki, nəticədə A xidmətinin 11 versiyasında işlədiyini, amma E xidmətinin artıq 12 versiyasını gözlədiyini öyrənək. Bu, mənim standart konsolidə edilmiş jurnalımdan çox fərqlidir: prosesi addım-addım keçmək üçün interaktiv terminal/debugger istifadə etməliyik. Debuq və anlamaq əslində çətinləşdi.
Əgər debuq edə bilmiriksə, bəlkə onları test edərik.
Müntəzəm inteqrasiya və müntəzəm inkişaf artıq standart halına gəlir. Görəcəyim əksər yeni tətbiqlər hər yeni buraxılışla avtomatik olaraq testləri yaradır və işə salır, testlərin keçməsini və nəzərdən keçirilməsini tələb edir. Bu, inkar edilə bilməz bir prosesdir; onlar bir çox şirkət üçün böyük bir dəyişiklik olmuşdur. Lakin, bir xidməti həqiqətən sınamaq üçün, tətbiqimin tam işlək versiyasını qaldırmalıyıq. Həmin 150 xidmətdən ibarət K8 klasteri ilə yeni mühəndisi xatırlayırsınız? İndi biz CI sistemimizi bu bütün sistemləri qaldırmağı öyrədəcəyik ki, hər şeyin həqiqətən işlədiyini yoxlaya bilək. Ehtimal ki, bu, çox cəhd tələb edir, ona görə də biz sadəcə olaraq hər bir hissəni izolyasiya edib test edəcəyik: əminəm ki, spesifikasiyalarımız kifayət qədər yaxşıdır, API-lar təmizdir, xidmətin dayanması izolyasiyadadır və başqalarına təsir etməyəcək.
Bütün kompromislərin ciddi bir səbəbi var. Düzgün?
Mikroservislərə keçmək üçün bir çox səbəb var. Daha çox çeviklik, komandaların genişlənməsi, performans, daha yaxşı davamlılıq təmin etməsi üçün bunu etdiklərini görmüşəm. Lakin gerçəkdə, biz monolitlərin inkişafında on illərdir ki, alətlərə və təcrübələrə sərmayə qoymuşuq ki, bu da davam edir. Fərqli texnologiyalarda peşəkarlarla işləyirəm. Adətən, genişləndirmək haqqında danışırıq, çünki onlar Postgres verilənlər bazasının tək nodunu məhdudiyyətləri ilə qarşılaşırlar. Danışıqların əksəriyyəti .
amma həmişə onların arxitekturası ilə maraqlanıram. Mikroservislərə keçid prosesində hansı mərhələdilər? Daha çox mühəndisin monolit tətbiqindən razı olduğunu görmək maraqlıdır. Bir çox insana mikroservislər fayda gətirəcək, üstünlüklər miqrasiya yolundakı çətinlikləri ağırlıqla geri qoyacaq. Amma şəxsi olaraq, mənə lütfən, monolit tətbiqimi verin, çimərlikdə bir yer – o zaman tamamilə xoşbəxt olacağam.
Mənbə: habr.com
