Fevralın 26-da açıq mənbə layihəsinə töhfə verənlərin çıxış etdiyi Apache Ignite GreenSource görüşünü keçirdik. . Bu icmanın həyatında mühüm hadisə komponentin yenidən qurulması oldu , bu, xüsusi mikroservisləri birbaşa Ignite klasterinə yerləşdirməyə imkan verir. O, görüşdə bu çətin prosesdən danışıb , proqram mühəndisi və iki ildən artıq Apache Ignite ianəçisi.
Ümumilikdə Apache Ignite-in nə olduğundan başlayaq. Bu, SQL, əməliyyat və keşləmə dəstəyi ilə paylanmış Açar/Dəyər yaddaşı olan verilənlər bazasıdır. Bundan əlavə, Ignite xüsusi xidmətləri birbaşa Ignite klasterinə yerləşdirməyə imkan verir. Tərtibatçı Ignite-in təmin etdiyi bütün alətlərə - paylanmış məlumat strukturlarına, Mesajlaşma, Axın, Hesablama və Məlumat Şəbəkəsinə çıxışı var. Məsələn, Data Grid-dən istifadə edərkən məlumatların saxlanması üçün ayrıca infrastrukturun idarə edilməsi problemi və nəticədə yaranan əlavə xərclər aradan qalxır.
Service Grid API-dən istifadə edərək siz sadəcə yerləşdirmə sxemini və müvafiq olaraq konfiqurasiyada xidmətin özünü göstərərək xidməti yerləşdirə bilərsiniz.
Tipik olaraq, yerləşdirmə sxemi klaster qovşaqlarında yerləşdirilməli olan nümunələrin sayının göstəricisidir. İki tipik yerləşdirmə sxemi var. Birincisi, Cluster Singleton-dur: istənilən vaxt istifadəçi xidmətinin bir nümunəsinin klasterdə mövcud olmasına zəmanət verilir. İkincisi Node Singleton-dur: xidmətin bir nümunəsi hər klaster qovşağında yerləşdirilir.
İstifadəçi həmçinin bütün klasterdə xidmət nümunələrinin sayını təyin edə və uyğun qovşaqların filtrlənməsi üçün predikat təyin edə bilər. Bu ssenaridə Service Grid özü xidmətlərin yerləşdirilməsi üçün optimal paylanmanı hesablayacaq.
Bundan əlavə, Affinity Service kimi bir xüsusiyyət var. Yaxınlıq, açarların bölmələrə münasibətini və topologiyada tərəflərin qovşaqlara münasibətini təyin edən funksiyadır. Açardan istifadə edərək, məlumatların saxlandığı əsas nodu təyin edə bilərsiniz. Bu yolla siz öz xidmətinizi açar və yaxınlıq funksiyası keşi ilə əlaqələndirə bilərsiniz. Yaxınlıq funksiyası dəyişərsə, avtomatik yenidən yerləşdirmə baş verəcək. Beləliklə, xidmət həmişə manipulyasiya etmək üçün lazım olan məlumatlara yaxın yerləşəcək və müvafiq olaraq, məlumat əldə etmək üçün əlavə xərcləri azaldacaqdır. Bu sxemi bir növ collocated hesablama adlandırmaq olar.
İndi Service Grid-in gözəlliyinin nə olduğunu anladıqdan sonra onun inkişaf tarixindən danışaq.
Daha əvvəl nə olub
Service Grid-in əvvəlki tətbiqi Ignite-in tranzaksiya təkrarlanan sistem keşinə əsaslanırdı. Ignite-dəki "keş" sözü yaddaşa aiddir. Yəni bu, düşündüyünüz kimi müvəqqəti bir şey deyil. Keşin təkrarlanmasına və hər bir node bütün məlumat dəstini ehtiva etməsinə baxmayaraq, keşin içərisində onun bölünmüş təsviri var. Bu, yaddaşın optimallaşdırılması ilə bağlıdır.
İstifadəçi xidməti yerləşdirmək istəyəndə nə baş verdi?
- Klasterdəki bütün qovşaqlar daxili Davamlı Sorğu mexanizmindən istifadə edərək yaddaşdakı məlumatları yeniləməyə abunə oldu.
- Oxunmuş əməliyyat altında başlanğıc node, seriallaşdırılmış nümunə də daxil olmaqla xidmət konfiqurasiyasını ehtiva edən verilənlər bazasında qeyd etdi.
- Yeni giriş barədə məlumat verildikdə, koordinator konfiqurasiya əsasında paylanmanı hesabladı. Yaranan obyekt yenidən verilənlər bazasına yazılır.
- Əgər qovşaq paylanmanın bir hissəsidirsə, koordinator onu yerləşdirməli idi.
Bizə nə yaraşmadı
Bir anda belə bir nəticəyə gəldik: xidmətlərlə işləmək belə deyil. Bunun bir neçə səbəbi var idi.
Əgər yerləşdirmə zamanı hansısa xəta baş veribsə, o zaman bunu yalnız hər şeyin baş verdiyi node qeydlərindən öyrənmək olar. Yalnız asinxron yerləşdirmə var idi, ona görə də yerləşdirmə metodundan idarəetməni istifadəçiyə qaytardıqdan sonra xidməti işə salmaq üçün bir qədər əlavə vaxt lazım oldu - və bu müddət ərzində istifadəçi heç nəyə nəzarət edə bilmədi. Xidmət Şəbəkəsini daha da inkişaf etdirmək, yeni funksiyalar yaratmaq, yeni istifadəçiləri cəlb etmək və hər kəsin həyatını asanlaşdırmaq üçün nəyisə dəyişmək lazımdır.
Yeni Xidmət Şəbəkəsini tərtib edərkən biz ilk növbədə sinxron yerləşdirmə zəmanətini təmin etmək istədik: istifadəçi API-dən idarəetməni qaytaran kimi dərhal xidmətlərdən istifadə edə bildi. Mən də təşəbbüskara yerləşdirmə səhvlərini idarə etmək bacarığı vermək istədim.
Bundan əlavə, həyata keçirilməsini sadələşdirmək, yəni əməliyyatlardan və balanslaşdırmadan uzaqlaşmaq istədim. Keşin təkrarlanmasına və balanslaşdırmanın olmamasına baxmayaraq, bir çox qovşaqla böyük bir yerləşdirmə zamanı problemlər yarandı. Topologiya dəyişdikdə, qovşaqların məlumat mübadiləsinə ehtiyacı var və böyük bir yerləşdirmə ilə bu məlumatlar çox çəkə bilər.
Topologiya qeyri-sabit olduqda, koordinator xidmətlərin paylanmasını yenidən hesablamalı oldu. Və ümumiyyətlə, qeyri-sabit topologiyada əməliyyatlarla işləməli olduğunuz zaman bu, proqnozlaşdırmaq çətin olan səhvlərə səbəb ola bilər.
Problemləri
Müşayiət edən problemlər olmadan qlobal dəyişikliklər hansılardır? Bunlardan birincisi topologiyanın dəyişməsi idi. Siz başa düşməlisiniz ki, istənilən an, hətta xidmətin yerləşdirilməsi anında belə, bir qovşaq klasterə daxil ola və ya onu tərk edə bilər. Üstəlik, yerləşdirmə zamanı qovşaq klasterə qoşularsa, xidmətlər haqqında bütün məlumatları ardıcıl olaraq yeni node-ə ötürmək lazımdır. Və biz təkcə artıq yerləşdirilənlərdən deyil, həm də cari və gələcək yerləşdirmələrdən danışırıq.
Bu, ayrı bir siyahıda toplana bilən problemlərdən yalnız biridir:
- Node başlanğıcında statik konfiqurasiya edilmiş xidmətləri necə yerləşdirmək olar?
- Klasterdən bir qovşağı tərk etmək - node xidmətlərə sahibdirsə nə etməli?
- Koordinator dəyişibsə nə etməli?
- Müştəri klasterə yenidən qoşularsa nə etməli?
- Aktivləşdirmə/deaktivasiya sorğuları emal edilməlidirmi və necə?
- Əgər onlar önbelleği məhv etməyə çağırsalar və bizdə onunla əlaqəli yaxınlıq xidmətləri varsa?
Və bu hamısı deyil.
qərar
Hədəf olaraq, mesajlardan istifadə edərək proses kommunikasiyasının həyata keçirilməsi ilə Hadisəyə əsaslanan yanaşmanı seçdik. Ignite artıq qovşaqların öz aralarında mesaj ötürməsinə imkan verən iki komponenti tətbiq edir - rabitə-spi və kəşf-spi.
Communication-spi qovşaqlara birbaşa əlaqə saxlamağa və mesajları ötürməyə imkan verir. Böyük miqdarda məlumat göndərmək üçün yaxşı uyğun gəlir. Discovery-spi klasterdəki bütün qovşaqlara mesaj göndərməyə imkan verir. Standart icrada bu, halqa topologiyasından istifadə etməklə həyata keçirilir. Zookeeper ilə inteqrasiya da var, bu halda ulduz topologiyası istifadə olunur. Diqqət yetirməyə dəyər başqa bir vacib məqam odur ki, discovery-spi mesajın mütləq bütün qovşaqlara düzgün qaydada çatdırılacağına zəmanət verir.
Yerləşdirmə protokoluna baxaq. Yerləşdirmə və yerləşdirmə üçün bütün istifadəçi sorğuları Discovery-spi vasitəsilə göndərilir. Bu aşağıdakıları verir zəmanət verir:
- Sorğu klasterdəki bütün qovşaqlar tərəfindən qəbul ediləcək. Bu, koordinator dəyişdikdə sorğunun işlənməsini davam etdirməyə imkan verəcək. Bu həm də o deməkdir ki, bir mesajda hər bir node xidmət konfiqurasiyası və onun seriallaşdırılmış nümunəsi kimi bütün lazımi metadataya malik olacaqdır.
- Mesajın çatdırılmasının ciddi qaydası konfiqurasiya münaqişələrini və rəqabətli sorğuları həll etməyə kömək edir.
- Düyünün topologiyaya daxil olması Discovery-spi vasitəsilə də işləndiyi üçün yeni node xidmətlərlə işləmək üçün lazım olan bütün məlumatları alacaq.
Sorğu qəbul edildikdə, klasterdəki qovşaqlar onu təsdiqləyir və emal tapşırıqları yaradır. Bu tapşırıqlar növbəyə qoyulur və daha sonra ayrı işçi tərəfindən başqa bir başlıqda işlənir. Bu, bu şəkildə həyata keçirilir, çünki yerləşdirmə xeyli vaxt apara bilər və bahalı kəşf axını dözülməz şəkildə gecikdirə bilər.
Növbədən gələn bütün sorğular yerləşdirmə meneceri tərəfindən işlənir. Bu növbədən tapşırığı çıxaran və yerləşdirməyə başlamaq üçün onu işə salan xüsusi işçisi var. Bundan sonra aşağıdakı hərəkətlər baş verir:
- Hər bir qovşaq yeni deterministik təyinat funksiyası sayəsində paylanmanı müstəqil hesablayır.
- Düyünlər yerləşdirmənin nəticələri ilə bir mesaj yaradır və koordinatora göndərir.
- Koordinator bütün mesajları birləşdirir və kəşfiyyat-spi vasitəsilə klasterdəki bütün qovşaqlara göndərilən bütün yerləşdirmə prosesinin nəticəsini yaradır.
- Nəticə alındıqda, yerləşdirmə prosesi başa çatır, bundan sonra tapşırıq növbədən çıxarılır.
Hadisəyə əsaslanan yeni dizayn: org.apache.ignite.internal.processors.service.IgniteServiceProcessor.java
Yerləşdirmə zamanı xəta baş verərsə, qovşaq dərhal bu xətanı koordinatora göndərdiyi mesaja daxil edir. Mesajın toplanmasından sonra koordinator yerləşdirmə zamanı bütün səhvlər haqqında məlumat əldə edəcək və bu mesajı discovery-spi vasitəsilə göndərəcək. Xəta məlumatı klasterdəki istənilən qovşaqda mövcud olacaq.
Xidmət Şəbəkəsindəki bütün vacib hadisələr bu əməliyyat alqoritmi ilə işlənir. Məsələn, topologiyanın dəyişdirilməsi də Discovery-spi vasitəsilə verilən mesajdır. Və ümumiyyətlə, əvvəlki ilə müqayisədə protokol olduqca yüngül və etibarlı oldu. Yerləşdirmə zamanı istənilən vəziyyəti idarə etmək üçün kifayətdir.
Növbəti nə olacaq?
İndi planlar haqqında. Ignite layihəsinə edilən hər hansı əsas dəyişiklik IEP adlanan Ignite təkmilləşdirmə təşəbbüsü kimi tamamlanır. Xidmət Şəbəkəsinin yenidən dizaynında həmçinin IEP var - istehza başlığı ilə “Xidmət şəbəkəsində yağ dəyişikliyi”. Əslində, biz mühərrik yağını deyil, bütün mühərriki dəyişdirdik.
BEP-də tapşırıqları 2 mərhələyə ayırdıq. Birincisi, yerləşdirmə protokolunun yenidən işlənməsindən ibarət olan əsas mərhələdir. O, artıq master-a daxil edilib, siz 2.8 versiyasında görünəcək yeni Service Grid-i sınaya bilərsiniz. İkinci mərhələ bir çox digər tapşırıqları əhatə edir:
- İsti yenidən yerləşdirmə
- Xidmət versiyası
- Artan xəta tolerantlığı
- Arıq müştəri
- Müxtəlif ölçüləri izləmək və hesablamaq üçün alətlər
Nəhayət, biz sizə xətaya dözümlü, yüksək əlçatan sistemlər qurmaq üçün Service Grid haqqında məsləhət verə bilərik. Sizi də bizi ziyarət etməyə dəvət edirik и təcrübənizi bölüşün. Təcrübəniz cəmiyyət üçün həqiqətən vacibdir; o, növbəti hara keçəcəyinizi, gələcəkdə komponenti necə inkişaf etdirəcəyinizi anlamağa kömək edəcək.
Mənbə: www.habr.com