Mikroservis Arxitekturası və Service Mesh (Istio): Böyük Miqyaslı Sistemlərdə Trafik İdarəetməsi, Təhlükəsizlik və Müşahidəolunma (Observability)

Müasir proqram təminatı mühəndisliyində monolit tətbiqlərdən mikroservis arxitekturasına keçid artıq bir seçim deyil, böyük miqyaslı, yüksək yüklü və davamlı sistemlər qurmaq üçün zərurətə çevrilmişdir. Lakin monolit arxitekturanın gətirdiyi daxili mürəkkəblikləri aradan qaldırarkən, mikroservislər özləri ilə birlikdə tamamilə fərqli problemlər gətirir: şəbəkə gecikmələri, xidmətlərarası təhlükəsizlik, mürəkkəb marşrutlaşdırma (routing) və sistemin ümumi vəziyyətinin izlənilməsi (observability).

Paylanmış sistemlərin (distributed systems) ən böyük səhvlərindən biri şəbəkənin etibarlı olduğunu düşünməkdir. Real dünyada isə şəbəkə qeyri-sabitdir, gecikmələr qaçılmazdır və təhlükəsizlik hər an təhdid altındadır. Məhz bu nöqtədə Service Mesh (Xidmət Şəbəkəsi) konsepsiyası və onun ən populyar tətbiqi olan Istio köməyə çatır. Bu məqalədə mikroservislər arasındakı əlaqəni kod səviyyəsində deyil, infrastruktur səviyyəsində idarə etməyin yollarını, Istio-nun memarlıq strukturunu, trafik idarəetməsi, təhlükəsizlik və observability imkanlarını dərindən analiz edəcəyik.

---

Mikroservis Arxitekturasının Gizli Ağrıları: Niyə Service Mesh-ə Ehtiyacımız Var?#

Monolit tətbiqdə funksiyalar və modullar eyni yaddaş sahəsində (in-memory) bir-biri ilə birbaşa əlaqə saxlayır. Mikroservislərdə isə hər bir xidmət müstəqil işləyir və bir-biri ilə şəbəkə (HTTP, gRPC, TCP) vasitəsilə ünsiyyət qurur. Bu keçid proqramçılara sərbəstlik versə də, sistem idarəçiləri və DevOps mühəndisləri üçün ciddi çətinliklər yaradır.

Şəbəkə Gecikmələri və Etibarsızlıq

Bir istifadəçi sorğusu arxa fonda onlarla mikroservisin bir-birini zəncirvari şəkildə çağırmasına səbəb ola bilər. Bu zəncirdəki hər hansı bir xidmətin gecikməsi və ya çökməsi bütün sistemin dayanmasına (cascading failure) gətirib çıxarır. Kod daxilində hər bir xidmət üçün fərdi olaraq "retry" (yenidən cəhd), "timeout" (vaxt aşımı) və "circuit breaker" (zəncirvari qırıcı) məntiqlərini yazmaq həm vaxt aparır, həm də fərqli proqramlaşdırma dillərində yazılmış xidmətlər arasında standartlaşdırmanı qeyri-mümkün edir.

Xidmətlərarası Təhlükəsizlik (mTLS) Problemi

Ənənəvi şəbəkə təhlükəsizliyi yalnız perimetr (firewall) səviyyəsində qorunurdu. Lakin daxili şəbəkəyə sızan bir təcavüzkar bütün mikroservislər arasındakı trafiki açıq şəkildə oxuya bilərdi. Hər bir mikroservisin öz daxilində TLS sertifikatlarını idarə etməsi, onları yeniləməsi və qarşılıqlı autentifikasiyanı (mTLS) təmin etməsi böyük bir əməliyyat yüküdür.

Müşahidəolunma (Observability) Çətinlikləri

Sistemdə bir xəta baş verdikdə, sorğunun hansı xidmətdə ilişdiyini, harada gecikmə yarandığını tapmaq samanlıqda iynə axtarmağa bənzəyir. Hər bir xidmətin fərqli formatda loq yazması və mərkəzi izləmə (distributed tracing) sisteminin olmaması diaqnostika müddətini (MTTR - Mean Time To Resolution) kəskin şəkildə uzadır.

"Service Mesh, tətbiq koduna toxunmadan, xidmətlərarası əlaqəni idarə edən, təhlükəsizləşdirən və izləyən xüsusi bir infrastruktur layıdır."

---

Service Mesh Nədir? Memarlıq Quruluşu (Data Plane vs. Control Plane)#

Service Mesh, tətbiqinizin biznes məntiqindən şəbəkə idarəetməsini tamamilə ayırır. O, əsasən iki əsas komponentdən ibarətdir: Data Plane (Verilənlər Layı) və Control Plane (İdarəetmə Layı).

+-------------------------------------------------------+
|                     CONTROL PLANE                     |
|                        (Istiod)                       |
+---------------------------+---------------------------+
                            | (Konfiqurasiya və Sertifikatlar)
                            v
+-------------------------------------------------------+
|                      DATA PLANE                       |
|                                                       |
|  +------------------+           +------------------+  |
|  |   Microservice   |           |   Microservice   |  |
|  |      (App A)     |           |      (App B)     |  |
|  +--------^---------+           +--------^---------+  |
|           | (localhost)                  | (localhost) |
|  +--------v---------+    mTLS   +--------v---------+  |
|  |   Envoy Proxy    |<=========>|   Envoy Proxy    |  |
|  |    (Sidecar)     |           |    (Sidecar)     |  |
|  +------------------+           +------------------+  |
+-------------------------------------------------------+

Data Plane (Envoy Proxy)

Data Plane, mikroservislərin yanında işləyən yüksək performanslı proksilərdən (proxies) ibarətdir. Istio-da bu rol üçün Envoy Proxy istifadə olunur. Hər bir mikroservis pod-una (Kubernetes mühitində) bir Envoy proksisi əlavə edilir (buna Sidecar pattern deyilir).

Xidmətə gələn və gedən bütün şəbəkə trafiki bu proksi vasitəsilə yönləndirilir. Mikroservis özü birbaşa şəbəkəyə çıxmır, yalnız lokal hostda (localhost) olan öz proksisi ilə danışır. Envoy proksiləri aşağıdakı funksiyaları yerinə yetirir:

• Dinamik xidmət kəşfi (Service Discovery)
• Yükün paylanması (Load Balancing)
• Trafik marşrutlaşdırılması (Routing)
• Şifrələmə və mTLS
• Metriklərin və loqların toplanması

Control Plane (Istiod)

Control Plane, bütün bu proksiləri mərkəzdən idarə edən beyindir. Istio-da bu funksiyanı Istiod adlı tək bir monolit (lakin daxilən modulyar) komponent yerinə yetirir. Istiod proqramçıların və ya DevOps mühəndislərinin yazdığı YAML konfiqurasiyalarını oxuyur, onları Envoy proksilərinin başa düşəcəyi formata çevirir və real zamanlı olaraq bütün proksilərə paylayır. Həmçinin, daxili Sertifikat Təchizatçısı (CA) kimi çıxış edərək mTLS üçün təhlükəsiz sertifikatlar yaradır və paylayır.

---

Istio Service Mesh ilə Trafik İdarəetməsi və Dayanıqlılıq Strategiyaları#

Istio-nun ən güclü tərəflərindən biri tətbiq kodunu dəyişmədən mürəkkəb trafik idarəetmə ssenarilərini həyata keçirmək imkanıdır.

Traffic Splitting (Canary Deployments)

Yeni bir proqram versiyasını (məsələn, v2) istehsalata (production) buraxarkən, bütün trafiki birdən-birə yeni versiyaya yönləndirmək böyük riskdir. Istio vasitəsilə trafiki faizlə bölmək mümkündür. Məsələn, sorğuların 90%-ni köhnə stabil versiyaya (v1), 10%-ni isə yeni versiyaya (v2) yönləndirərək real istifadəçi davranışını və xətaları izləyə bilərsiniz. Əgər hər şey qaydasındadırsa, bu nisbəti tədricən 100%-ə çatdıra bilərsiniz.

Circuit Breaking (Zəncirvari Qəzaların Qarşısının Alınması)

Əgər bir mikroservis həddindən artıq yüklənibsə və ya xətalar verirsə, digər xidmətlər ona sorğu göndərməyə davam etməməlidir. Circuit Breaker mexanizmi müəyyən bir xəta limitini keçən xidməti müvəqqəti olaraq dövriyyədən çıxarır (trip edir). Bu, həmin xidmətə özünü bərpa etmək üçün vaxt qazandırır və bütün sistemin çökməsinin qarşısını alır.

Retries və Timeouts

Şəbəkədəki müvəqqəti (transient) xətalar zamanı Istio avtomatik olaraq sorğunu yenidən cəhd edə bilər. Məsələn, bir HTTP 503 xətası alındıqda, Istio tətbiqə hiss etdirmədən sorğunu 3 dəfə təkrar edə bilər. Həmçinin, cavab verməyən xidmətlər üçün sərt vaxt məhdudiyyətləri (timeouts) təyin edilərək resursların boş yerə gözlədilməsinin qarşısı alınır.

---

Müqayisəli Analiz: Istio, Linkerd və Consul#

Service Mesh dünyasında fərqli alətlər mövcuddur. Layihənizin ehtiyaclarına uyğun olanı seçmək üçün onların müqayisəsini bilmək vacibdir.

---

Istio-nun Praktiki Tətbiqi: Kubernetes-də VirtualService və DestinationRule Konfiqurasiyası#

Istio-da trafiki idarə etmək üçün iki əsas Kubernetes Custom Resource Definition (CRD) istifadə olunur: VirtualService və DestinationRule.

• VirtualService: Sorğuların şəbəkədə necə marşrutlaşdırılacağını (routing) təyin edir.
• DestinationRule: Marşrutlaşdırmadan sonra hədəf xidmətin daxilindəki alt qruplara (subsets) və yük paylanması (load balancing) siyasətinə nəzarət edir.

Aşağıdakı nümunədə, payment-service adlı xidmət üçün gələn trafiki 80% nisbətində v1 (stabil) versiyasına və 20% nisbətində v2 (canary) versiyasına yönləndirən real YAML konfiqurasiyasını görə bilərsiniz.

# 1. VirtualService Konfiqurasiyası
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: payment-service-route
  namespace: production
spec:
  hosts:
  - payment-service # Bu xidmətə gələn sorğuları hədəfləyirik
  http:
  - route:
    - destination:
        host: payment-service
        subset: v1 # Trafikin 80%-i v1 subsetinə gedir
      weight: 80
    - destination:
        host: payment-service
        subset: v2 # Trafikin 20%-i v2 subsetinə gedir
      weight: 20
    headers:
      request:
        set:
          x-routed-by: "istio-mesh" # Analitika üçün başlıq əlavə edirik

---
# 2. DestinationRule Konfiqurasiyası
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: payment-service-destination
  namespace: production
spec:
  host: payment-service
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN # Yükün paylanması alqoritmi
    connectionPool:
      tcp:
        maxConnections: 100 # Maksimum TCP bağlantı sayı
  subsets:
  - name: v1
    labels:
      version: v1 # Kubernetes pod-larındakı label ilə eşləşir
  - name: v2
    labels:
      version: v2
    trafficPolicy:
      connectionPool:
        http:
          http1MaxPendingRequests: 10 # v2 üçün növbə limitləri

Bu Konfiqurasiyanın İzahı:

1. VirtualService vasitəsilə payment-service-ə gələn HTTP sorğularını tuturuq. weight parametri ilə trafiki 80/20 nisbətində bölürük.
2. DestinationRule daxilində v1 və v2 adlı iki subset (alt qrup) təyin edirik. Bu alt qruplar Kubernetes pod-larının üzərindəki version: v1 və version: v2 etiketlərinə (labels) əsasən müəyyən edilir.
3. trafficPolicy bölməsində hər iki versiya üçün əlaqə hovuzu (connection pool) limitlərini təyin edərək sistemin həddindən artıq yüklənməsinin qarşısını alırıq.

---

Service Mesh-də Təhlükəsizlik: Zero-Trust Şəbəkə və mTLS#

Müasir kibertəhlükəsizlik yanaşmasında "heç vaxt etibar etmə, həmişə yoxla" (Zero-Trust) prinsipi əsas götürülür. Istio, daxili şəbəkədəki bütün kommunikasiyanı avtomatik olaraq şifrələyərək Zero-Trust arxitekturasını qurmağı asanlaşdırır.

Mutual TLS (mTLS) Necə İşləyir?

Ənənəvi TLS-də yalnız müştəri (client) serverin kimliyini yoxlayır (məsələn, brauzerin veb saytın sertifikatını yoxlaması). Mutual TLS (mTLS)-də isə həm müştəri, həm də server bir-birinin kimliyini qarşılıqlı olaraq yoxlayır.

Istio-da bu proses tamamilə avtomatlaşdırılıb:

1. Sertifikat Təminatı: Istiod hər bir pod-dakı Envoy proksisinə avtomatik olaraq qısaömürlü xidmət sertifikatları göndərir.
2. Sertifikat Rotasiyası: Sertifikatlar vaxtaşırı olaraq (məsələn, hər 12 saatdan bir) heç bir kəsinti olmadan yenilənir.
3. Şifrəli Kanal: İki mikroservis bir-biri ilə danışmaq istədikdə, Envoy proksiləri öz aralarında mTLS əlaqəsi qurur, trafiki şifrələyir və yalnız bundan sonra məlumat ötürülür.

PeerAuthentication Siyasəti

Istio-da mTLS-i məcburi etmək üçün aşağıdakı kimi bir təhlükəsizlik siyasəti (Policy) tətbiq edilə bilər:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT # Şifrəsiz (plain-text) bütün daxili trafiki bloklayır

STRICT rejimi təyin edildikdə, şəbəkədə mTLS dəstəkləməyən hər hansı bir xidmətin digər xidmətlərlə əlaqə qurması dərhal bloklanır, bu isə daxili şəbəkə təhlükəsizliyini maksimum səviyyəyə qaldırır.

---

Müşahidəolunma (Observability): Prometheus, Grafana və Jaeger İnteqrasiyası#

Paylanmış sistemlərin ən böyük problemi kor nöqtələrin (blind spots) olmasıdır. Istio, bütün şəbəkə trafikini idarə etdiyi üçün, tətbiqinizdən müstəqil olaraq inanılmaz dərəcədə zəngin telemetriya məlumatları toplaya bilir.

Üç Sütunlu Observability

1. Metriklər (Metrics): Envoy proksiləri hər bir sorğunun cavab kodunu (200, 404, 500), gecikmə müddətini (latency) və ötürülən məlumatın həcmini ölçür. Bu məlumatlar Prometheus tərəfindən toplanır və Grafana panellərində vizuallaşdırılır.
2. Paylanmış İzləmə (Distributed Tracing): Bir istifadəçi sorğusunun bütün mikroservislər boyunca keçdiyi yolu izləmək üçün Istio Jaeger və ya Zipkin ilə inteqrasiya olunur. Hər bir sorğuya unikal bir X-Request-ID və ya traceparent başlığı əlavə edilir, beləliklə, zəncirvari zənglərin xəritəsi çıxarılır.
3. Loqlar (Logs): Hər bir HTTP sorğusunun ətraflı loqu (access logs) standart formatda mərkəzi loq sisteminə (məsələn, Elasticsearch, Fluentd, Kibana - EFK stack) göndərilir.

"Istio və Kiali inteqrasiyası sayəsində real zamanlı olaraq hansı mikroservisin hansı xidmətlə danışdığını, saniyədə neçə sorğu (RPS) ötürüldüyünü və xəta dərəcələrini vizual xəritə üzərində görmək mümkündür."

---

Nəticə və Gələcəyə Dair Tövsiyələr#

Mikroservis arxitekturasına keçid sistemlərin miqyaslanmasını təmin etsə də, şəbəkə idarəetməsini çətinləşdirir. Service Mesh (Istio), bu mürəkkəbliyi proqramçıların üzərindən götürərək infrastruktur səviyyəsinə daşıyır.

Istio tətbiq edərkən aşağıdakı strateji addımları atmağınız tövsiyə olunur:

• Tədricən Keçid: Istio-nu birbaşa bütün sistemdə deyil, əvvəlcə qeyri-kritik xidmətlərdə tətbiq edin. mTLS rejimini əvvəlcə PERMISSIVE (həm şifrəli, həm şifrəsiz qəbul edən) rejimdə saxlayın, hər şeyin stabil işlədiyindən əmin olduqdan sonra STRICT rejiminə keçin.
• Resurs Planlaması: Envoy proksilərinin hər pod üçün əlavə yaddaş (RAM) və CPU istehlak edəcəyini unutmayın. Kubernetes klasterinizdə resurs limitlərini (Limits/Requests) düzgün tənzimləyin.
• GitOps İnteqrasiyası: Istio konfiqurasiyalarını (VirtualService, DestinationRule) əl ilə deyil, ArgoCD və ya Flux kimi GitOps alətləri vasitəsilə avtomatlaşdırılmış şəkildə idarə edin.

Nəticə etibarilə, Istio müasir bulud-yerli (cloud-native) tətbiqlərin idarə olunmasında, təhlükəsizliyinin təmin edilməsində və şəffaflığının artırılmasında əvəzedilməz bir alətdir. Düzgün konfiqurasiya edilmiş Service Mesh infrastrukturu, layihənizin gələcək böyümə templərinə tam hazır olmasını təmin edəcəkdir.