Mikroservis Mimarisi ve Cloud-Native Uygulama Geliştirme

Monolitik uygulamanızı mikroservislere dönüştürün! Ölçeklenebilir, esnek, bağımsız deploy edilebilen mikroservis mimarisi ile modern yazılım geliştirme. API Gateway, Service Mesh, Event-Driven Architecture ve Container Orchestration.

Mikroservis Mimarisi Nedir?

Mikroservis mimarisi, büyük bir uygulamayı birbirinden bağımsız, küçük servislere bölerek geliştirme yaklaşımıdır. Her servis kendi veritabanına sahip, bağımsız deploy edilebilir ve farklı teknolojilerle yazılabilir.

🎯 Monolitik vs Mikroservis

Monolitik Mimari:

┌─────────────────────────────────────────┐
│                                         │
│         TEK BÜYÜK UYGULAMA              │
│                                         │
│  ┌────────┬────────┬────────┬────────┐ │
│  │ User   │Product │ Order  │Payment │ │
│  │Service │Service │Service │Service │ │
│  └────────┴────────┴────────┴────────┘ │
│                                         │
│          Tek Veritabanı                 │
│         ┌─────────────┐                 │
│         │  Database   │                 │
│         └─────────────┘                 │
└─────────────────────────────────────────┘

Sorunlar:
❌ Tek bir hata tüm sistemi düşürür
❌ Scaling zor (tümünü scale etmek gerek)
❌ Deploy riski yüksek (tümü birlikte)
❌ Teknoloji stack değişimi zor
❌ Ekip iş birliği zorlaşır (aynı kod)

Mikroservis Mimarisi:

┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐
│  User    │  │ Product  │  │  Order   │  │ Payment  │
│ Service  │  │ Service  │  │ Service  │  │ Service  │
│          │  │          │  │          │  │          │
│ Node.js  │  │  Python  │  │   Java   │  │    Go    │
│          │  │          │  │          │  │          │
│ ┌──────┐ │  │ ┌──────┐ │  │ ┌──────┐ │  │ ┌──────┐ │
│ │UserDB│ │  │ │ProdDB│ │  │ │OrdDB │ │  │ │PayDB │ │
│ └──────┘ │  │ └──────┘ │  │ └──────┘ │  │ └──────┘ │
└──────────┘  └──────────┘  └──────────┘  └──────────┘
      ↓             ↓             ↓             ↓
    ┌───────────────────────────────────────────────┐
    │          API Gateway / Service Mesh           │
    └───────────────────────────────────────────────┘

Avantajlar:
✅ Bağımsız deploy (User servis güncellenirken diğerleri etkilenmez)
✅ Teknoloji özgürlüğü (Her servis farklı dil)
✅ Kolay scaling (Sadece Order servisini 10x scale et)
✅ Fault isolation (Payment çökse diğerleri çalışır)
✅ Ekip otonomisi (Her ekip kendi servisi)

💡 Mikroservis Ne Zaman?

Mikroservise Geçiş İçin:

• 📈 Büyük Ekip: 20+ developer
• 🚀 Hızlı Büyüme: Sık özellik ekleniyor
• 📊 Farklı Scaling: Bazı modüller çok yük alıyor
• 🔄 Sık Deploy: Günde 10+ deployment
• 👥 Çoklu Ekip: Bağımsız çalışan ekipler

Monolitik Devam İçin:

• 👶 Startup/MVP: Hızlı geliştirme öncelik
• 👤 Küçük Ekip: < 10 developer
• 📉 Stabil Yük: Değişken trafik yok
• 🐌 Nadir Deploy: Ayda 1-2 deployment

Mikroservis Bileşenleri

🚪 API Gateway

Tek Giriş Noktası

API Gateway Görevleri

Client Request
    ↓
┌───────────────────────────────────────┐
│         API GATEWAY                   │
│                                       │
│  🔐 Authentication                    │
│  🎫 Authorization                     │
│  ⚖️  Load Balancing                   │
│  🔄 Request Routing                   │
│  🚦 Rate Limiting                     │
│  📊 Logging & Monitoring              │
│  🔀 Request/Response Transformation   │
│  🔌 Circuit Breaker                   │
└───────────────────────────────────────┘
    ↓         ↓         ↓         ↓
[User Svc] [Prod Svc] [Order] [Payment]

Popüler API Gateway’ler:

• 🦍 Kong: Open source, plugin sistemi
• 🌐 AWS API Gateway: Serverless
• 🔷 Azure API Management
• 🟠 Nginx: Reverse proxy + API gateway
• ⚡ Traefik: Cloud-native, Kubernetes friendly

Kong Örneği:

# Kong route config
services:
  - name: user-service
    url: http://user-service:3000
    routes:
      - name: user-route
        paths:
          - /api/users
    plugins:
      - name: rate-limiting
        config:
          minute: 100
      - name: jwt

🕸️ Service Mesh

Servisler Arası İletişim Yönetimi

Service Mesh Nedir?

Without Service Mesh:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Service A → Service B
Her serviste:
• Retry logic
• Circuit breaker
• Load balancing
• Security
→ Kod karmaşası, tekrar eden mantık

With Service Mesh (Istio):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Service A → [Sidecar Proxy] → [Sidecar Proxy] → Service B

Sidecar Proxy (Envoy):
• Otomatik retry
• Circuit breaking
• mTLS encryption
• Observability
→ Servis kodu temiz, logic dışarıda

Popüler Service Mesh:

• ⛵ Istio: En popüler, feature-rich
• 🔗 Linkerd: Hafif, Kubernetes native
• 🌐 Consul Connect: HashiCorp

📨 Event-Driven Architecture

Asenkron İletişim

Message Queue ile İletişim

Synchronous (REST API):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Order Service → (HTTP) → Payment Service → (HTTP) → Notification
                ⏱️ Bekle   ⏱️ Bekle             ⏱️ Bekle

Sorun: Payment servis çökerse Order takılır


Asynchronous (Event-Driven):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Order Service → [Event: OrderCreated] → Message Queue
                                              ↓
                                        [Payment Service]
                                        [Notification Service]
                                        [Inventory Service]

Avantaj: Order servis event'i gönderip devam eder
         Payment çökse bile event kuyrukta bekler

Message Queue Teknolojileri:

• 🐰 RabbitMQ: AMQP protokol, güvenilir
• 🔴 Redis Pub/Sub: Hızlı, hafif
• ⚡ Apache Kafka: High-throughput, big data
• ☁️ AWS SQS/SNS: Managed queue
• 🔵 Azure Service Bus

Kafka Örneği:

// Producer (Order Service)
const kafka = require('kafkajs');

async function createOrder(orderData) {
  // Order oluştur
  const order = await db.orders.create(orderData);

  // Event gönder
  await producer.send({
    topic: 'order-created',
    messages: [{
      key: order.id,
      value: JSON.stringify({
        orderId: order.id,
        userId: order.userId,
        amount: order.amount
      })
    }]
  });

  return order;
}

// Consumer (Payment Service)
await consumer.subscribe({ topic: 'order-created' });

await consumer.run({
  eachMessage: async ({ message }) => {
    const order = JSON.parse(message.value);
    await processPayment(order);
  }
});

🔄 Saga Pattern

Distributed Transaction Yönetimi

Saga Pattern Nedir?

Problem: Mikroservislerde transaction yönetimi
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
E-Ticaret Sipariş:
1. Order Service: Sipariş oluştur
2. Payment Service: Ödeme al
3. Inventory Service: Stoktan düş
4. Shipping Service: Kargo oluştur

Sorun: Payment başarısız olursa?
       Order'ı nasıl geri alacağız?

Çözüm: Saga Pattern
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Choreography Saga:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. Order Service: OrderCreated event
   ↓
2. Payment Service: PaymentProcessed event
   ↓ (HATA!)
   PaymentFailed event
   ↓
3. Order Service: CancelOrder (compensate)

📦 Service Discovery

Servis Keşfi

Service Registry

Problem: Payment Service nerede?
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Kubernetes ortamında:
• Pod'lar dinamik IP alır
• Scale edilince yeni pod'lar
• Fail olan pod silinir

Çözüm: Service Discovery
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Service Registry (Consul, Eureka, K8s Service):

┌────────────────┐
│ Service        │
│ Registry       │
│                │
│ payment-svc:   │
│ - 10.0.1.5:8080│
│ - 10.0.1.8:8080│
└────────────────┘
      ↑    ↓
   Register Query
      ↓    ↑
┌──────────┐  ┌──────────┐
│ Payment  │  │  Order   │
│ Service  │  │ Service  │
└──────────┘  └──────────┘

Mikroservis Teknolojileri

🐳 Docker ve Kubernetes

Container Orchestration

Kubernetes ile Mikroservis

# User Service Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: user-service
  template:
    metadata:
      labels:
        app: user-service
    spec:
      containers:
      - name: user-service
        image: myapp/user-service:v1.2.0
        ports:
        - containerPort: 3000
        env:
        - name: DB_HOST
          valueFrom:
            configMapKeyRef:
              name: user-config
              key: db-host
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 30
          periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: user-service
spec:
  selector:
    app: user-service
  ports:
  - port: 80
    targetPort: 3000
  type: ClusterIP

🔍 Observability (Gözlemlenebilirlik)

3 Pillars of Observability

1. Logs

Centralized Logging (ELK Stack):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Microservices → Fluentd/Logstash → Elasticsearch → Kibana

Örnek Log:
{
  "timestamp": "2025-01-14T10:30:45Z",
  "service": "order-service",
  "level": "ERROR",
  "message": "Payment failed",
  "orderId": "ORD-12345",
  "userId": "USR-789",
  "errorCode": "INSUFFICIENT_FUNDS"
}

2. Metrics

Prometheus + Grafana:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Metrics:
• Request rate (requests/sec)
• Error rate (errors/sec)
• Duration (p50, p95, p99)
• Saturation (CPU, Memory)

Örnek Query (PromQL):
rate(http_requests_total[5m])  # Son 5 dk request rate
histogram_quantile(0.95, http_request_duration_seconds)  # p95 latency

3. Tracing

Distributed Tracing (Jaeger):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Request Flow:
API Gateway → User Service → Order Service → Payment Service
   [10ms]        [50ms]         [120ms]         [300ms]

Trace ID: 1234-5678-9abc
Total: 480ms

Her serviste span:
• Span ID
• Parent span ID
• Service name
• Duration
• Tags, logs

Mikroservis Best Practices

✅ Design Principles

1. Single Responsibility

❌ Kötü: User-Order-Payment Service (çok görev)
✅ İyi:  User Service
        Order Service
        Payment Service

2. Database per Service

❌ Kötü: Tüm servisler aynı DB
✅ İyi:  Her servisin kendi DB'si

3. API Versioning

❌ Kötü: /api/users (değişirse eski clientlar bozulur)
✅ İyi:  /api/v1/users
        /api/v2/users

4. Circuit Breaker

// Payment servis çöktüğünde
const circuitBreaker = require('opossum');

const options = {
  timeout: 3000, // 3sn timeout
  errorThresholdPercentage: 50, // %50 fail olursa aç
  resetTimeout: 30000 // 30sn sonra tekrar dene
};

const breaker = circuitBreaker(callPaymentService, options);

breaker.fire(orderId)
  .then(result => console.log(result))
  .catch(err => {
    // Fallback: Ödemeyi kuyrukta beklet
    console.log('Circuit open, queueing payment');
    queuePayment(orderId);
  });

5. Retry with Exponential Backoff

async function retryWithBackoff(fn, maxRetries = 3) {
  for (let i = 0; i < maxRetries; i++) {
    try {
      return await fn();
    } catch (err) {
      if (i === maxRetries - 1) throw err;
      const delay = Math.pow(2, i) * 1000; // 1s, 2s, 4s
      await sleep(delay);
    }
  }
}

Başarı Hikayesi

🚀 E-Ticaret Platformu

Durum (Monolitik):

• 50+ developer, tek codebase
• Deploy: Haftada 1 (riskli)
• Downtime: Ayda 2-3 kez
• Scaling: Tüm uygulamayı scale etmek gerek

Çözüm (Mikroservis):

• 15 mikroservis
• Kubernetes (AWS EKS)
• API Gateway (Kong)
• Event-driven (Kafka)
• Service Mesh (Istio)

Sonuçlar (1 Yıl):

• ✅ Deploy: Günde 20+ (bağımsız)
• ✅ Downtime: %99.99 uptime
• ✅ Scaling: Product servis 10x, Order 3x (bağımsız)
• ✅ Geliştirme Hızı: %300 artış
• ✅ Ekip Memnuniyeti: Yüksek (otonom ekipler)

Hemen Başlayın

Monolitik uygulamanızı mikroservislere dönüştürün. Ölçeklenebilir, esnek, cloud-native mimari ile modern yazılım geliştirin.

Mikroservis Hizmetlerimiz:

• ✅ Mikroservis mimari tasarımı
• ✅ Monolitten mikroservise migration
• ✅ API Gateway implementasyonu
• ✅ Service Mesh (Istio, Linkerd)
• ✅ Event-driven architecture
• ✅ Kubernetes deployment
• ✅ CI/CD pipeline
• ✅ Observability (Logs, Metrics, Tracing)
• ✅ DevOps ve SRE

Ücretsiz Mikroservis Analizi | Mimari Danışmanlığı

---

İlgili Çözümler:

• API Geliştirme ve Entegrasyon
• Cloud Sunucu ve DevOps
• Kubernetes Yönetimi
• Mobil Uygulama Backend
• Sistem Entegrasyonu

Popüler Aramalar: mikroservis mimarisi, microservices, api gateway, service mesh, kubernetes microservices, event driven architecture, distributed systems, cloud native