Mikroservislər nədir və mikroservis arxitekturasında proqramlaşdırma patternləri

Hamıya salam, adım İlkindir hal-hazırda PASHA Bank şirkətində proqramçı-mühəndis vəzifəsində çalışıram. Məqaləni yazmaqda məqsədim Azərbaycanda proqramlaşdırmanın inkişafına dəstək olmaqdır. Bu mövzunu seçməyimin səbəblərinə gəldikdə isə oxuyuculara dünyada sürətlə inkişaf edən arxitektura haqqında məlumatlandırmaq və real praktikada gördüyüm müsbət nəticələri sizinlə bölüşməkdir.

Əvvəlcə gəlin mikroservislərin nə olduğunu anlayaq.

Mikroservislər — kiçik, avtonom və birlikdə işləyən servislərdir. Qısaca olaraq bu arxitekturanın əsas üstünlükləri barədə danışmaq istəyirəm.

1. Texnologiyalardan asılılığı yoxdur

Yəni birlikdə işləyən bir neçə servisdən ibarət sistemə malik olaraq, onların hər birinin içində müxtəlif texnologiyalar işlətmək qərarına gəlmək olar. Bu isə öz növbəsində həyatın hər vəziyyəti üçün hər hansı bir standart yanaşma axtarmaq əvəzinə, hər bir tapşırıq üçün daha uyğun alətlər seçməyə imkan yaradır. Məsələn bizim şirkətdə back-end Java, Kotlin, Go kimi proqramlaşdırma dillərində yazılır.

2. Dayanıqlılıq

Sistemin bir komponentinin sıradan çıxması, digər bağlı servisləri sıradan çıxarmadığı üçün, problemi izolyasiya edərək bütün sistemin işlək vəziyyətini qorumaq olar. Monolit servislərdə isə bir komponentin sıradan çıxması bütün servisin işini dayandıra bilər.

3. Miqyaslama

Böyük monolit sistemlərdə hər şeyi eyni anda genişləndirmək lazım gəlir. Sistemin hər hansı bir kiçik hissəsi məhdud məhsuldarlığa malik ola bilər və böyük bir monolit tətbiqin işini yavaşlada bilər. Və buna görə də sistemi vahid bir sistem kimi genişləndirmək lazımdır. Kiçik servislərlə iş zamanı isə yalnız genişlənməyə ehtiyacı olan hissələri genişləndirmək olar. Bu da sistemin digər hissələrini daha kiçik və daha zəif avadanlıqlarda işə salmağa imkan yaradır.

4. Yerləşdirmə asanlığı

Milyonlarla kod sətirindən ibarət olan bir monolit tətbiqin bir xəttində dəyişikliklərin həyata keçirilməsi bütün tətbiqin həyata keçirilməsini tələb edir. Bu yerləşdirmə çox riskli ola bilər və son dərəcə mənfi nəticələrə səbəb ola bilər. Təcrübədə bu riskli yerləşdirmələr nadir hallarda başa düşülən narahatlıqlar səbəbindən baş verir. Təəssüf ki, bu dəyişikliklər tətbiqin yeni bir versiyası istehsalata buraxılana qədər relizlər arasında toplanır və yığılır, bu da bir çox dəyişikliklərə malikdir.

Mikroservislərdən istifadə edərkən ayrı bir mikroservisdə dəyişiklik edə bilərsiniz və sistemin qalan hissəsindən asılı olmayaraq yerləşdirə bilərsiniz. Bu, kodu daha sürətli yerləşdirməyə imkan verəcəkdir. Yaranan problem, sürətli bir dönüşü asanlaşdıran ayrı bir servis çərçivəsində tez bir zamanda təcrid edilə bilər. Bu da yeni funksionallığın müştəriyə daha sürətli çata bilməsi deməkdir. Bu cür arxitekturanın bir tətbiqi işə salmaq üçün mümkün qədər çox maneəni aradan qaldırması Amazon və Netflix kimi təşkilatların istifadə etmələrinin əsas səbəblərindən biri oldu.

5. Mövcud kodu dəyişdirmək

Şübhəsiz ki, bir çoxu təxminən 15 il əvvəl Pascalda şirkətinizdə yazılmış bir tətbiqlə tanış olmusunuz. Heç kim ona toxunmaq istəmir və şirkətiniz onsuz işləyə bilməz. Niyə heç kim bu sistemi əvəz etməyib? Bunun səbəbini bilirsiniz: bu çox həcmli və riskli bir işdir.

Ayrı-ayrı kiçik həcmli servislərdən istifadə etdikdə bu cür tətbiqləri tam aradan qaldırılmasının öhdəsindən gəlmək daha asandır.

Mikroservis arxitekturasından istifadə edən komandalar, lazım olduqda servisi tamamilə yenidən yazılmasında çətin bir şey görmürlər və hətta ehtiyac olduqda tamamilə servisi ləğv edə bilərlər.

Mikroservis arxitekturasında proqramlaşdırma patternləri

Mikroservis arxitekturasında bir çox pattern var, bəzilərini nəzərdən keçirək

1. Saga Patterni

Problem

Servislər arasında məlumat ardıcıllığını necə təmin etmək olar?

Həlli

Bir neçə servisi əhatə edən hər bir əməliyyatın bir Saga şəklində həyata keçirilməsi lazımdır.

Saga lokal tranzaksiyalar toplusudur. Hər bir lokal tranzaksiya verilənlər bazasını yeniləyir və Saga-da növbəti lokal tranzaksiya başlatmaqla bir mesaj və ya hadisə dərc edir

Saga-ları əlaqələndirməyin 2 yolu var.

1. Xoreoqrafiya(Choreography)

2. Orkestrasiya(Orchestration)

Xoreoqrafiya prinsipi

Xoreoqrafiya — hər tranzaksiya digər servislərdə tranzaksiyalara səbəb olan hadisələr dərc edir.

1. Payment Service (Ödəniş Servisi), Pendingdə (gözləmə vəziyyəti) bir Payment (Ödəniş) yaradır və Payment Created (Ödəniş Yarandı) statusunu yayımlayır
2. Сard Service (Kart Servisi) bir əməliyyat qəbul edir və ödəniş üçün məbləği saxlamağa çalışır. Sonra iki hadisədən birini nəşr edir: Amount Reserved (Məbləğ qorunur) və Amount Limit Exceeded (Məbləğ limiti aşdı)
3. Payment Service (Ödəniş Servisi) bir əməliyyat qəbul edir və ödəniş statusunu təsdiqlənmiş Approved (təsdiqlənmiş) və ya Cancelled (ləğv edilmiş) vəziyyətinə gətirir

Orkestrasiya prinsipi

Orkestrator iştirakçılara hansı əməliyyatlara başlamaq lazım olduğunu izah edir.

Bir sıra “sorğu-cavab” çağırışları ilə əlaqə yaradarkən, Kart servisi (Card Service) və E-poçt servisi (Email Service) ilə əlaqə baş verir. Gələcəkdə ödəniş servisi müstəqil olaraq bu müddətdə ödəmə mövqeyini izləyə bilər. Orkestrasiya prinsipi ilə tətbiq olunan yanaşmanın dezavantajı ödəniş servisinin lazımsız mərkəzləşdirilmiş idarəetmə səlahiyyətlərini əldə edə bilməsidir. Şəbəkənin ortasında bir node və məntiqin ortaya çıxdığı bir mərkəz nöqtəsi ola bilər. Bu yanaşma, CRUD əsasında yazılan az sayda servislərin ortaya çıxmasına səbəb olur.

Bunun əvəzinə Xoreoqrafiya prinsipindən istifadə edərkən, ödəniş servisinin ödənişin yaranması barədə xəbərdar edəcək bir hadisəni asinxron şəkildə verməyə məcbur etmək olar.

Sonra, e-poçt servisi, kart servisi bu cür hadisələrə sadəcə abunə olacaq və onlara müvafiq reaksiya verəcəkdir. Bu yanaşma daha çox parçalanma xarakteri daşıyır. Ödənişin yaranmasına başqa bir servis lazımdırsa, sadəcə hadisələrə abunə olmalı və ona lazım olan vəzifəni yerinə yetirməlidir.

2. Circuit Breaker Patterni

Circuit Breaker patterni, sorğunun uğursuz olma ehtimalı olan bir problemi, həll olmadığını bilinənə qədər vacib resurları xərcləmədən işə davam etməyinizə imkan verən bir əməliyyatı yerinə yetirməyə mane olur. Bu pattern tətbiqə problemin həll olub-olmadığını izləməyə də imkan verir.

Sevimli Spring framework-da , Hystrix adlanan kitabxananı nəzərdən keçirək.

Rəsmi dokumentsiyada deyildiyi kimi: Hystrix — yayılmış servislər arasındakı qarşılıqlı əlaqəni idarə etməyə kömək edən, gecikmə tolerantlığı və nöqsanlara qarşı dözümlülük məntiqi əlavə edən bir kitabxanadır.

Circuit Breaker tətbiqin və uzaq servis(remote service) arasında bir Proxy servis kimi çıxış edir. Proxy servis, əməliyyatın yerinə yetirilməsini və ya sadəcə bir səhvin dərhal qaytarılmasını təyin etmək üçün meydana gələn son səhvləri izləyir.

B servisində bir şey səhv olarsa, o zaman A servisinə bir səhv göndərir və səhvlərin olduğunu yadda saxlayır və sadəcə B servisinə sonrakı sorğular göndərilmir. Bu vəziyyətdə server resurslarını boş yerə sərf etmirik.

Onun 3 vəziyyəti var:

Proxy servis, əməliyyat uğursuz olarsa səhv sayğacını artırır. Müəyyən bir müddət ərzində səhvlərin sayı əvvəlcədən müəyyən edilmiş bir həddən artıqdırsa, proxy server Open vəziyyətə daxil olur və bir zaman kəsmə taymerinə başlayır. Taymerin müddəti bitdikdə, Half-Open vəziyyətə daxil olur. Taymerin məqsədi - Tətbiqin yenidən əməliyyata cəhd etməsinə icazə vermədən əvvəl servisə problemi həll etmək üçün vaxt verməsidir.

1. Closed: tətbiqdən sorğu birbaşa servisə göndərilir. Səhv sayğacı = 0 və tətbiq çalışır.
2. Open: tətbiq sorğusu dərhal səhv ilə başa çatır və istisna tətbiqə qaytarılır.
3. Half-Open: tətbiqdən məhdud sayda sorğunun servisə daxil olması üçün icazə verilir. Bu sorğular uğurlu olarsa, inanırıq ki, əvvəlki səhv düzəlmişdir və proxy servisi Closed vəziyyətə keçir (səhv sayğacı 0-a salınır). Sorğulardan hər hansı biri uğursuz olarsa, səhvin hələ də mövcud olduğu hesab olunur və proxy servisi Open vəziyyətə qayıdır və uğursuz sorğuları bərpa etmək üçün sistemə əlavə vaxt vermək səbəbi ilə taymeri yenidən işə salır. Half-Open vəziyyət servisə olan sorğularının sürətli böyüməsinin qarşısını almağa kömək edir. Servis işə başlandıqdan sonra, bir müddət tam bərpa olunana qədər məhdud sayda sorğuya cavab verə bilər.

Diqqətiniz üçün təşəkkürlər!

Mikroservislərdə digər patternlər haqqında bu link-dən oxuya bilərsiz.