Mikroservis arxitekturası

Mikroservis axitekturası yazdığınız böyük bir proyektin hər bir modulu, submodulu və ya prosesi bir birindən əlaqəsiz işləyən kiçik servislərə ayrılmasıdır . Bu servislər bir birilə protokollar vasitəsilə əlaqə qurur. Əsasən bu protokollar http və https olsa da ümumi baxdıqda bu hər hansı açıq protokol ola bilər. Mikroservis arxitekturasında əsas vacib məsələ servislərin yazılmasından əlavə onlar arasında bağlantının düzgün qurulmasıdır. Əslində mikroservis arxitekturasını SOLİD prinsiplərinə ümumi baxsaq Single responsibility prinsipinə bənzətmək olar. Mikroservisə monolotik arxitekturadan fərqli olaraq SOA (Service oriented architecture) arxitekturasının nisbətən SOLİD prinsiplərinə uyğunlaşdırılmış halı kimi baxmaq olar.

Tutaq ki bir böyük proyektimiz var. Hər dəfə böyük proyekt deməkdə məqsədim odur ki kiçik proyektlərdə mikroservis öz əhəmiyyətini itirir. Bir proyektin 3 və ya daha çox modulu varsa ona böyük proyekt kimi baxmaq olar. Tutaq ki proyektimizdə bu modullar var.

İşçilər

İstifadəçilər

İcazə

Struktur (Departament və şöbələr)

Sifarişlər

Satınalma

Şirkət məlumatları

Təchizatçı məlumatları

və s

Tutaq ki bu proyekti klassik monolotik arxitekturada yazmışıq. Yəni bütün funksionallıqları bir servisdə yazmışıq, repository patterni istifadə etmişik, controller tərəfdə servisə çox rahat müraciət edib əməliyyatlar apara bilirik. Bəs problem nədir? niyə mikroservisə keçməliyik? və ya mikroservisə keçməliyik mi? Bu suallara cavab axtaraq. Mikroservisin əsas 2 üstünlüyünə baxaq.

1. Tutaq ki biz icazə modulunda kiçik dəyişiklik istədilər. Bu elə bir dəyişiklikdir ki bizim servisimizdə və ya əsas proyektimizdə dəyişikliklər edib yenidən deploy etməyimizə səbəb olur. Tutaq ki proyektimiz də 24 saat işləməlidir və dayanma müştərilərdə narazıçılığa səbəb olur. Ancaq əgər proyektimiz monolitik arxitekturada yazılıbsa biz proyektdə bu kiçik dəyişikliyi tətbiq etmək üçün məcburuq proyekti bütöv şəkildə deploy etməyə. Burda problemi görə bilirik. İcazə modulundakı kiçik bir dəyişiklik bizim icazəylə heç bir əlaqəsi olmayan modullarımızın da dayanmasına səbəb olur. Təbiki bu nümunə o qədər də uyğun olmaya bilər. Deyə bilərsiz ki əgər bu modulların əksəriyyəti şirkət daxilidirsə (icazə modulu kimi) proyektin az bir müddət dayanması proyektin bütün arxitekturasının yenidən qurulmasına səbəb olmamalıdır və ya iş vaxtından sonra deploy etmək olar proyekti. Hardasa məntiqli ola bilər. Ancaq tutaq ki şirkətin məhsulları və ya hər hansı başqa xidmətləri var və 24 saat online xidmət göstərir. Belə bir sistemdə çox kiçik dayanmalar belə müştəri məmnuniyyətsizliyinə səbəb ola bilər. Ancaq biz mikroservis arxitekturasında yazsaq yuxarıdakı hər bir modulu və ya alt modulu hər birini ayrı bir servis kimi yazarıq. Əgər icazə modulunda dəyişiklik tələb olunarsa sadəcə bu servisdə dəyişikliyimizi edib sadəcə bu modulu deploy edəcəyik. İcazə modulunda çox kiçik dayanma oduğu halda proyektimizin digər modulları normal şəkildə işləməyə davam edəcək. Xüsusilə proyektimizdə çox tez tez dəyişiklik tələb olunursa mikroservis arxitekturasına keçmək çox faydalı olacaq.
2. Monolotik arxitekturada proyekti hansı texnologiya ilə yazmışıqsa o texnologiya ilə də yazmağa davam etməliyik. Burada monolotik arxitektura deyəndə servis tərəfimiz nəzərdə tutulur. Yəni əslində proyektimizi 2 texnologiya ilə yaza bilərik amma yalnız 2 daha çox yox.Məsələn Proyekt ola bilər asp.net core servis ola bilər python flaskda. Amma yenə təkrarlayım monolotik deyəndə servis tərəfi nəzərdə tutulduğu üçün monolitik arxitekturada sadəcə bir proqramlaşdırma dilində yazmağa məcburuq demək doğrudur. Mikroservis arxitekturasında isə servislərimiz hər birini fərqli dillərdə yaza bilərik. Məsələn bir servisimiz ola bilər Asp.Core web api, bir servisimiz ola bilər python flask, bir servisimiz ola bilər node.js express frameworklə yazılmış api, bir servisimiz ola bilər java spring frameworkdə yazılmış restful servis və s. Bundan başqa böyük datalarda axtarış ayrıca bir mikroservis kimi yazıb axtarışı sürətləndirmək üçün relational database yerinə elasticsearch istifadə etmək olar. Yaxud proyektinizin forum və ya portal hissəsi varsa yazılan kommentləri və yaxud müştərilərin saytda hərəkət loglarını saytın hansı hissələrində nə qədər vaxt keçirdiklərini və s mongodb-də saxlaya bilərik və bu məlumatları bizə gətirən mikroservisimiz mongodb-yə bağlanıb oradan məlumat çəkəcək. Yaxud proyektimizin datası bir hissəsi sql serverdədir bir hissəsi də tutaq ki oracleda ortaq başqa proyektlərlə birlikdə istifadə olunur. Mikroservislə bizə rahat bir şəkildə hər iki verilənlər bazasından məlumatları gətirməkdə kömək edəcək. Bu məsələyə digər tərəfdən yanaşsaq tutaq ki proyektiniz proyektiniz asp.net mvc dədir siz şirkət olaraq qərara aldınız ki bundan sonra pythondan istifadə edək. Proyekti başdan sona qədər pythona keçirməmiş deploy etmək imkansızdır. Hələ proyektin bu yeni texnologiyaya keçmə mərhələsində proyektdə çoxlu yeni dəyişiklər istənirsə bu keçmə mərhələsi uzandıqca uzanır. Ancaq mikroservis arxitekturasında rahat bir şəkildə hissə-hissə istədiyimiz texnologiyaya keçə bilərik.Bu proyekti hissə hissə fərqli dillərdə yaza bilmək bizə əlavə olaraq bu üstünlükəri də verir. Şirkətlərin bir texnologiyada işləməyə məcbur qalmır və proqramçı tapmaq asanlaşır. Proqramçılar da rahat şəkildə daha yaxşı bildiyi texnologiya ilə kod yaza bilir.

Mikroservisin bu üstünlüklərindən başqa zəif tərəfləri də var. Əslində zəiflik deyil sadəcə işi biraz çətinləşdirdiyi hissələri var.

1. Transactionları idarə etmək. Bəli prosesləri kiçik hissələrə ayrırıq. Birdən çox verilənlər bazası istifadə edirik. Təbi ki transactionların idarə edilməsi xeyli çətinləşir. Mikorservis arxitekturasında bəzən hər servis üçün ayrıca bir verilənlər bazası yaradılması qeyd edilir. Amma bu tam olaraq düzgün yanaşma deyil. Ən azından verilənlər bazası sayını mümkün qədər az tutmaqla transaction idarə edilməsini asanlaşdırmaq olar. Bəlkə də 24 saat çalışmalı olan xidmətləri ayrıca bir verilənlər bazasında saxlamaq məqsədə uyğun ola bilər. Ancaq always-on texnologiyaları ilə bu məsələni də həll etmək olar.
2. Biz dedik ki mikroservis arxitekturasında proyekti hissə hissə deploy edə bilirik. Ancaq bizim kiçik onlarca bəlkədə yüzlərcə kiçik servislərimiz olacaq. Bunları serverdə idarə etmək çətinləşir. Hətta manual olaraq bunları serverə qurmaq və nəzarət etmək mümkünsüz ola bilir. Bir servisimiz çalışmır və proyektdə problem yaranır çalışmayan bu servisi tapmaq çox vaxt aparan məsələ ola bilər. Bunun üçün IAC (Infrastructure as code) və ya programmable infrastructure anlayışı yaradılmışdır. IAC sistemin əlavə konfiqurasiyalarının idarə edilməsi və proyektin işləyəbiləcəyi mühitin avtomatik yaradılması üçün yazılan kod deməkdir. IAC normal şəkildə tətbiq edilməsi devopsda daha rahat mümkün olur. Bundan əlavə CI(Continuous integration) və CD(Continuous delivery) anlayışlarını bilmək və tətbiq etmək vacib məsələdir. Yəni devops mühitində işləmirsizsə və IAC,CI və ya CD anlayışlarını yaxşı şəkildə tətbiq edən mütəxəssisiniz yoxdursa mikroservisə keçməkdə yaxşı eliyirsiz amma düz eləmirsiz :)

Front end tərəfdə mikroservis arxitekturasına bənzər mikro front-end arxitekturası var. Mikroservisə keçəndə elə front tərəfi də mikro front-end arxitekturasına keçirmək haqqında düşünə bilərsiz. Əslində Front tərəfdə buna ehtiyac yoxdur.

Son olaraq mikroservis arxitekturasının tətbiqi üçün müxtəlif patternlər var. Maraqlanıb araşdırmaq istəyən olar deyə burda adlarını yazıram.

Integration Patternləri

-API Gateway Pattern

-Aggregator Pattern

-Client-Side UI Composition Pattern

Database Patternləri

-Database per Service

-Shared Database per Service

-Command Query Responsibility Segregation (CQRS)

-Saga Pattern

Observability Patternləri

-Log Aggregation

-Performance Metrics

-Distributed Tracing

-Health Check

Cross-Cutting Concern Patternləri

-External Configuration

-Service Discovery Pattern

-Circuit Breaker Pattern

-Blue-Green Deployment Pattern

Decomposition Patternləri

-Decompose by Business Capability

-Decompose by Subdomain

-Strangler Pattern