.NET Microservices 3D logosu yanında üç bağlantılı .NET mikroservis düğümü bembeyaz arka planda premium kompozisyon

.NET Microservices eğitimi, "her servis ayrı" demeden önce sınırı çizmeyi öğreten bir programdır. Monolith'ten microservice'e geçiş kararı DDD bağlamından verilir; bounded context ile servis sınırı netleştirilir. gRPC, REST ve message queue arasında servisten servise iletişim seçimi somut karar matrisleriyle yapılır.

Eğitim sonunda katılımcı, Saga ve Outbox pattern ile distributed transaction yönetir; Istio veya Linkerd ile service mesh, observability ve mTLS kurar. Ocelot veya YARP ile API gateway tasarlama ve Kubernetes manifestleri ile Helm chart paketleme eğitimin uygulama tarafıdır. Eğitim sırasında .NET microservices mimarisi temel referans olarak kullanılır.

Katılımcı Profili

Bu eğitim, .NET tarafında microservice geçişini DDD bağlamında yapmak isteyen rollere yöneliktir:

  • .NET Geliştiriciler: Monolith'i microservice mimarisine dönüştüren mühendisler
  • Solution Architect'ler: Distributed sistem tasarımı yapan roller
  • DevOps Mühendisleri: .NET container ve Kubernetes deploy süreçlerini yönetenler
  • API Geliştiricileri: gRPC ve REST gateway tasarlayan roller
  • SRE'ler: Resilience ve observability hattını kuran ekipler

Ön Gereklilikler

Bu eğitime katılım için aşağıdaki ön bilgiler önerilir:

  • ASP.NET Core ile temel servis geliştirme deneyimi
  • C# dili ve modern özelliklerine (async/await, LINQ) rahatlık
  • Docker konteyner ve image kavramlarına giriş seviyesi aşinalık
  • Message queue (RabbitMQ, Kafka) kavramlarına temel aşinalık
  • Git ile branch, PR ve merge workflow'una rahatlık

Süresi ve Tarihi

Süre: 4 gün. Bu süre standart program içindir; ek modüllere ve hedefe göre süre özelleştirilebilir.
Eğitim tarihleri ve saatleri, ekibinizin uygunluğuna göre birlikte planlanır.

Kazanımlar

Eğitimin sonunda katılımcı, .NET tarafında "her servis ayrı"yı söylemeden önce sınırı çizmeyi öğrenir:

  • Monolith'ten microservice'e geçiş kararını DDD bağlamında verir
  • gRPC, REST ve message queue arasında servisten servise iletişim seçer
  • Bounded context ile servis sınırını netleştirir
  • Saga ve Outbox pattern ile distributed transaction yönetir
  • Istio veya Linkerd ile service mesh, observability ve mTLS kurar
  • Ocelot veya YARP ile API gateway tasarlar
  • Kubernetes manifest yazar; Helm chart ile paketler

.NET Microservices Eğitimi Konuları

1. Microservices Felsefesi ve Monolith'ten Geçiş

  • Monolith ve modular monolith ne zaman yeterli
  • Microservice'in maliyeti ve "distributed monolith" tuzağı
  • Conway's Law ve ekip topolojisi
  • Strangler Fig pattern ile aşamalı geçiş

2. Domain-Driven Design (DDD) Temelleri

  • Ubiquitous Language ve domain modeli
  • Entity, Value Object, Aggregate ayrımı
  • Domain Event ve repository pattern
  • Anti-Corruption Layer ile legacy köprü

3. Bounded Context ve Servis Sınırları

  • Context map ve servis sınırlarını çizme
  • Event Storming workshop yaklaşımı
  • Shared kernel ve customer-supplier ilişkileri
  • "Sharing model is a bug" prensibi

4. Servis İletişimi - REST, gRPC, Messaging

  • Sync REST: HTTP API ve OpenAPI sözleşmesi
  • gRPC: tip güvenli, yüksek performans
  • Async messaging: queue, pub/sub farkı
  • İletişim seçim matrisi: latency, coupling, scalability

5. API Gateway ve YARP

  • API Gateway pattern: tek giriş noktası
  • YARP (Yet Another Reverse Proxy) yapılandırması
  • Routing, load balancing, rate limiting
  • Backend-for-Frontend (BFF) yaklaşımı

6. Service Discovery ve Konfigürasyon

  • Service registry: Consul, Eureka
  • Client-side ve server-side discovery
  • Centralized configuration: Azure App Configuration, HashiCorp Vault
  • Feature flag ile aşamalı yayın

7. Resilience - Polly ile Circuit Breaker

  • Retry, Timeout, Circuit Breaker policy'leri
  • Bulkhead ve fallback pattern
  • Polly v8 resilience pipeline yapısı
  • HttpClient ile entegrasyon

8. Saga Pattern ve Distributed Transaction

  • Two-phase commit (2PC) sınırları
  • Choreography vs orchestration saga
  • Compensating transaction tasarımı
  • State machine ile saga durumu yönetimi

9. Event-Driven Architecture

  • Event Notification ve Event-Carried State Transfer
  • Eventual consistency ve trade-off
  • Event versioning ve schema evolution
  • Outbox pattern ile güvenilir event yayını

10. CQRS ve Event Sourcing

  • Command Query Responsibility Segregation
  • Read model ve write model ayrımı
  • Event Sourcing: state'i event stream'den türetme
  • Snapshot ve projection pattern

11. Message Broker - RabbitMQ, Kafka

  • RabbitMQ: exchange, queue, routing key
  • Kafka: topic, partition, consumer group
  • Delivery guarantee: at-most-once, at-least-once, exactly-once
  • Dead Letter Queue (DLQ) yönetimi

12. MassTransit ile Service Bus

  • MassTransit kurulumu ve consumer tanımı
  • Sagas ve state machine
  • Request/Response, publish/subscribe pattern
  • Transport seçimi: RabbitMQ, Azure Service Bus, AmazonSQS

13. Distributed Caching - Redis

  • Cache-aside ve write-through pattern
  • StackExchange.Redis kullanımı
  • Cache invalidation stratejileri
  • HybridCache ve in-memory + distributed katman

14. Outbox Pattern ve Idempotency

  • Outbox pattern: DB ve message broker tutarlılığı
  • Inbox pattern ile consumer idempotency
  • Idempotency key ve duplicate detection
  • Exactly-once illüzyonu ve gerçekçi yaklaşım

15. Authentication - IdentityServer ve OpenID

  • OAuth 2.0 ve OpenID Connect akışları
  • Duende IdentityServer ile auth server
  • JWT token üretimi ve doğrulama
  • API-to-API auth: client credentials flow

16. Observability - OpenTelemetry

  • Three pillars: metrics, logs, traces
  • OpenTelemetry ile vendor-neutral instrumentation
  • Distributed tracing ve correlation
  • Jaeger, Tempo, Application Insights backends

17. Container ile Microservice

  • Dockerfile multi-stage build (.NET için)
  • chiseled Ubuntu ve minimal base image
  • Container registry ve image tagging
  • Native AOT ile küçük ve hızlı container

18. Kubernetes Deploy

  • Deployment, Service, Ingress, ConfigMap, Secret
  • Helm chart ile templating
  • Health probe: liveness, readiness, startup
  • Horizontal Pod Autoscaler (HPA)
  • Service mesh giriş: Istio, Linkerd

19. .NET Aspire ile Modern Microservice

  • .NET Aspire orchestration ve dashboard
  • Local development ve service composition
  • Built-in observability ve resource visualization
  • Cloud-ready deploy manifest üretimi

20. Testing - Contract Test ve Pact

  • Microservice test piramidi farkı
  • Contract test ile consumer-driven sözleşme
  • Pact, PactNet ile entegrasyon
  • Chaos engineering: Simmy ve fault injection

.NET MICROSERVICES EĞİTİMİ ile İlgili
Sıkça Sorulan Sorular ve Cevapları


Monolith'ten microservice'e geçiş kararı nasıl verilir?

Microservice ölçek ve takım otonomisi için araç — küçük takımda monolith neredeyse her zaman daha verimli. Karar kriterleri: ekip sayısı (Conway's law), bağımsız deploy ihtiyacı, farklı teknoloji stack'i gereksinimi, ölçeklendirme asimetrisi. Strangler Fig pattern ile aşamalı geçiş risk azaltır.

gRPC ile REST arasında servisten servise iletişim?

gRPC HTTP/2 üzerinde Protocol Buffers ile binary serialization — düşük latency, type-safe sözleşme ve streaming desteği. REST JSON ile insan-okunur, debug kolay, browser uyumlu. Service-to-service iç iletişim için gRPC; public veya browser-facing API için REST tercih edilir.

Saga ve Outbox pattern hangi senaryoyu çözer?

Distributed transaction'da 2-Phase Commit ölçeklenmez. Saga uzun süren işi compensating action'larla yönetir (örn. ödeme alındı, stok düştü, başarısızsa geri al). Outbox event'i veritabanı işlemi içinde aynı transaction'da yazar; ayrı worker bunu message broker'a publish eder — at-least-once delivery garantisi.

Service mesh (Istio, Linkerd) ne zaman gerekli olur?

Servis sayısı arttıkça (10+) servisten servise mTLS, retry, circuit breaker, observability tek tek implement etmek operasyonel yük yaratır. Service mesh sidecar proxy ile bu concern'leri uygulama kodundan ayırır. Küçük microservice sayısında overhead'i değmeyebilir; karar ölçek ve kurum disiplinine bağlı.

API Gateway için Ocelot ve YARP karşılaştırması?

Ocelot olgun, configuration-driven .NET gateway; mature ama performans modern alternatif kadar yüksek değil. YARP (Yet Another Reverse Proxy) Microsoft'un yeni nesil reverse proxy'si — daha yüksek throughput, daha esnek extensibility. Yeni projeler YARP'a yöneliyor; Ocelot legacy uyumda kalıyor.

OpenTelemetry microservice'lerde neyi gösterir?

Trace correlation ID ile bir request'in tüm servisler üzerindeki yolculuğunu izler; latency dağılımı gösterir. Metric Prometheus uyumlu sayaç/histogram. Log structured biçimde trace ID ile bağlanır. Jaeger veya Tempo trace, Grafana metric, Loki log — birleştirilmiş observability stack kurulur.