Mikro Hizmetlerde API Ağ Geçidi Kalıbını Anlamak: Basit Bir Kılavuz

Mikro Hizmetlerde API Ağ Geçidi Kalıbını Anlamak: Basit Bir Kılavuz

Tek, yekpare bir uygulamadan mikro hizmet mimarisine geçiş birçok sorunu çözer. Ekiplerin bağımsız çalışmasına, hizmetleri ayrı ayrı dağıtmasına ve sistemin parçalarını gerektiği gibi ölçeklendirmesine olanak tanır. Ancak bu aynı zamanda yeni bir zorluğu da beraberinde getiriyor: Müşteriler tüm bu bağımsız hizmetlerle nasıl etkileşime giriyor?

On, elli veya yüzlerce küçük mikro hizmetiniz varsa, bir mobil uygulama veya web sayfası bunların her birine doğrudan bağlanmalı mı?

API Ağ Geçidi Modeli tam da bu noktada devreye giriyor. Bu kılavuzda, API Ağ Geçidinin ne olduğunu, ona neden ihtiyaç duyduğunuzu ve basit kelimeler ve gerçek dünya benzetmelerini kullanarak mikro hizmet sisteminizi nasıl basitleştirdiğini açıklayacağız.


Gerçek Dünya Analojisi: Otel Resepsiyonisti

Büyük ve lüks bir resort otele yerleştiğinizi hayal edin. Tesisin birçok farklı bölümü vardır:

  • Kat hizmetleri (temiz çarşaflar için)
  • Oda Servisi (yemek için)
  • Konsiyerj (tur rezervasyonu için)
  • Faturalandırma (faturayı ödemek için)

Temiz bir havlu istiyorsanız, tesis boyunca temizlik binasını bulmaya çalışmazsınız. Akşam yemeği istiyorsan mutfağın kapısını çalmayacaksın. Bunun yerine ön büro resepsiyon görevlisini ararsınız.

Resepsiyonist talebinizi dinler, hangi departmanın sorunu çözebileceğini belirler ve sizi bağlar veya sizin için halleder.

Bu senaryoda:

  • Siz Müşterisiniz (Mobil Uygulama veya Tarayıcı).
  • Resepsiyon görevlisi API Ağ Geçidi‘dir.
  • Departmanlar (Kat Hizmetleri, Oda Servisi, Faturalandırma) Mikro Hizmetler‘dir.

Sorun: İstemciden Hizmete Doğrudan İletişim

Ağ geçidinin nasıl çalıştığına bakmadan önce, eğer onu kullanmazsak ne olacağını görelim.

E-ticaret uygulamanızın üç ayrı mikro hizmete sahip olduğunu varsayalım:

  1. Kullanıcı Hizmeti (profilleri yönetir)
  2. Ürün Hizmeti (kataloğu yönetir)
  3. Sipariş Hizmeti (ödemeyi yönetir)

API Ağ Geçidi olmadan, istemci uygulamasının her hizmetin bireysel adresine (IP veya URL) doğrudan ayrı istekler göndermesi gerekir:

Yönlendirmeyi, Güvenliği ve Mikro Hizmetleri gösteren API Ağ Geçidi Mimarisi Diyagramı

Bu doğrudan bağlantı yaklaşımı birçok büyük baş ağrısına neden olur:

  • Çok Fazla Uç Nokta: İstemci uygulamasının üç ayrı URL’yi hatırlaması gerekir. Bir hizmeti bölerseniz veya adresini değiştirirseniz istemci uygulamasını güncellemeniz gerekir.
  • Güvenlik Kabusu: Her mikro hizmetin kimlik doğrulamasını (oturum açma belirteçlerini kontrol etme), SSL sertifikalarını ve güvenlik duvarı kurallarını ayrı ayrı uygulaması gerekir.
  • Ağ Ek Yükü: İstemcinin yalnızca tek bir sayfayı yüklemek için yavaş mobil ağlar üzerinden üç ayrı ağ isteğinde bulunması gerekebilir (ör. profil getir, ürün ayrıntılarını getir ve sipariş geçmişini getir).
  • Protokol Farklılıkları: İstemci uygulamanız HTTP/JSON gibi standart web protokollerini kullanmayı tercih edebilir, ancak dahili hizmetleriniz gRPC veya AMQP gibi özel protokolleri kullanarak daha hızlı iletişim kurabilir.

Çözüm: API Ağ Geçidi Modeli

API Ağ Geçidi, istemci uygulamaları ile dahili mikro hizmetler arasında yer alan bir yardımcı sunucudur. Gelen tüm talepler için tek giriş noktası görevi görür.

İstemci, üç farklı hizmeti çağırmak yerine API Ağ Geçidine tek bir çağrı yapar. Ağ geçidi daha sonra isteği doğru dahili hizmete iletir, sonuçları toplar ve bunları istemciye geri gönderir.

API Ağ Geçidinin Temel Sorumlulukları

API Ağ Geçidi doğrudan trafikten çok daha fazlasını yapar. Aksi takdirde her mikro hizmetin kod yazmak zorunda kalacağı “kesişen endişeler” ile ilgilenir:

  1. Yönlendirme: Ağ geçidi, gelen bir URL’yi (/api/v1/orders gibi) alır ve onu doğru dahili hizmet adresiyle eşleştirir.
  2. Kimlik Doğrulama ve Yetkilendirme: Ağ geçidi, giriş kapısındaki güvenlik belirteçlerini (JWT’ler gibi) doğrular. İstek geçersizse hemen reddedilir ve mikro hizmetlerinizi, kimliği doğrulanmamış isteklerle CPU döngülerini boşa harcamaktan kurtarır.
  3. Hız Sınırlama: Bir kullanıcının dakikada yapabileceği istek sayısını sınırlayarak kötü niyetli botların veya hatalı istemcilerin sisteminize spam göndermesini engeller.
  4. Yük Dengeleme: Ağ geçidi, tek bir sunucunun aşırı yüklenmesini önlemek için gelen trafiği bir mikro hizmetin birden çok örneğine eşit şekilde dağıtabilir.
  5. Protokol Çevirisi: Kullanıcının karşılaştığı JSON isteklerini yüksek performanslı dahili gRPC mesajlarına çevirerek hizmetlerin birbirleriyle tercih ettikleri dillerde konuşmasına olanak tanır.

Basit Bir Uygulama: Kod Örneği

Yönlendirmenin ne kadar kolay hale geldiğini görmek için API Ağ Geçidi kurmanın iki yaygın yoluna bakalım.

1. Bildirime Dayalı Yönlendirme (Spring Cloud Gateway YAML)

Kurumsal Java sistemlerinde yönlendirmeyi genellikle basit bir yapılandırma dosyası kullanarak yapılandırırsınız. Ağ geçidi, istekleri aşağıdaki kurallara göre otomatik olarak iletir:

spring:
  cloud:
    gateway:
      routes:
        - id: user_service_route
          uri: http://internal-user-service:8081
          predicates:
            - Path=/api/users/**
        - id: product_service_route
          uri: http://internal-product-service:8082
          predicates:
            - Path=/api/products/**

2. Programatik Yönlendirme (Node.js Ağ Geçidi Maketi)

Express’i kullanarak Javascript’te hafif bir API Ağ Geçidi oluşturmak istiyorsanız şuna benzer:

const express = require('express');
const { createProxyMiddleware } = require('http-proxy-middleware');
const app = express();
const PORT = 3000;

// 1. Simple Security/Authentication Check at the door
const authenticate = (req, res, next) => {
    const token = req.headers['authorization'];
    if (token === 'secret-handshake-token') {
        next(); // Token is valid, proceed
    } else {
        res.status(401).json({ error: 'Unauthorized Access!' });
    }
};

// Apply auth check to all incoming gateway requests
app.use(authenticate);

// 2. Route requests to correct internal microservices
app.use('/api/users', createProxyMiddleware({ target: 'http://localhost:8081', changeOrigin: true }));
app.use('/api/products', createProxyMiddleware({ target: 'http://localhost:8082', changeOrigin: true }));
app.use('/api/orders', createProxyMiddleware({ target: 'http://localhost:8083', changeOrigin: true }));

app.listen(PORT, () => {
    console.log(`API Gateway running smoothly on port ${PORT}`);
});

API Ağ Geçidi Modeli’nin Artıları ve Eksileri

Herhangi bir mimari karar gibi, API Ağ Geçidi kullanmanın da bazı ödünleri vardır:

Avantajı (Pro) Dezavantajı (Con)
Basit İstemci Arayüzü: Müşterilerin yalnızca bir alan adını bilmesi gerekir. Tek Nokta Arıza: Ağ geçidi arızalanırsa uygulamanın tamamına erişilemez hale gelir.
Merkezi Güvenlik: Giriş kontrollerini, SSL’yi ve CORS’u tek bir yerde uygulayın. Ekstra Gecikme: İsteklerin fazladan bir ağ atlama noktasından geçmesi gerektiği için istekler biraz daha uzun sürer.
Kod Tekrarının Azaltılması: Her hizmette kimlik doğrulama ve hız sınırlayıcı kodun yeniden yazılmasından kaçının. Bakım Ek Yükü: Hizmetler eklendiğinde, kaldırıldığında veya bölündüğünde ağ geçidinin güncellenmesi gerekir.

Çözüm

API Ağ Geçidi Modeli, modern mikro hizmet mimarisinin temel taşıdır. Tek, akıllı bir giriş noktası görevi görerek istemci uygulamalarını dahili hizmet kurulumlarının karmaşıklığından korur. İstemci tarafı kodunu basitleştirir, güvenliği merkezileştirir ve trafik yönetimini verimli bir şekilde yönetir.

Küçük bir ağ sıçramasına neden olsa ve üretimde yüksek kullanılabilirlik sağlayacak şekilde kurulması gerekse de, daha temiz, daha güvenli ve yönetilebilir kod tabanlarının faydaları, onu büyüyen herhangi bir dağıtılmış sistem için şiddetle tavsiye edilen bir model haline getiriyor.


Ghaznix Blogunda daha fazla yazılım geliştirme ve arka uç mühendisliği öngörülerini keşfedin →