.NET MICROSERVICES NEDİR?
Pazartesi sabahı: ürün yöneticisi ödeme akışındaki tek bir validasyon kuralının değişmesini istiyor. Kodu yazıyorsun, branch'i merge ediyorsun ve test ortamı ayağa kalkana kadar 40 dakika bekliyorsun — çünkü monolit uygulamanın tamamı yeniden derleniyor. Üretime çıkışta tüm sistem yeniden başlıyor; sepet, kullanıcı, fatura modülleri dahil. Üstelik bunun için gece yarısı bakım penceresi açmak gerekiyor. Microservices mimarisi tam olarak bu acıyı azaltmak için doğdu: küçük, bağımsız çalışan, ayrı ayrı dağıtılabilen servisler.
.NET ekosistemi 2016'daki ASP.NET Core dönüşümünden sonra mikroservis kurmak için olgun bir araç setine kavuştu — Web API, minimal API, gRPC, message broker entegrasyonları, container desteği platform içinde birinci sınıf yurttaş. Bu yazı .NET'le mikroservis kuracak veya mevcut sistemini bu yöne taşıyacak geliştiricilere genel bir harita çıkarır: mimarinin temel bileşenleri neler, .NET hangi araçları sunar, hangi durumlarda alternatif yaklaşımlar daha mantıklıdır.
Microservices Mimarisinin Özü
Microservices, tek bir büyük uygulamayı (monolit) iş yetenekleri etrafında bağımsız servislere bölme yaklaşımıdır. Her servisin kendi kod tabanı, kendi veritabanı, kendi deployment hattı vardır. Servisler birbirleriyle ağ üzerinden — HTTP, gRPC veya mesaj kuyruğuyla — konuşur.
Tanımı kısa ama içerdiği maliyet kısa değil. Tek process içinde yapılan basit bir method çağrısı artık ağ çağrısı; bellekteki tek transaction artık birden fazla servisi etkileyen distributed transaction; tek log dosyası artık merkezi log toplama altyapısı gerektiren onlarca akış. Bu nedenle microservices, popüler bir tasarım kararı olmaktan önce bir ölçek ve organizasyon kararıdır.
Bir mikroservisin sınırını çekerken kullanılan en yaygın rehber Domain-Driven Design'ın bounded context kavramıdır: "fatura", "ödeme", "katalog", "sevkiyat" gibi iş yetenekleri ayrı servisler olur. Servis sınırı bir iş kavramının içeriği değişmeden anlamlı kalabildiği bölgedir.
.NET Ekosisteminin Mikroservis Araç Seti
.NET 8 ve sonrasında, mikroservis kurmak için ihtiyaç duyulan parçaların büyük bölümü framework ile birlikte gelir. Microsoft'un yayımladığı resmi .NET mikroservis mimari kılavuzu, referans uygulamayla beraber temel desenleri detaylı şekilde belgeler. Kısa bir liste:
- ASP.NET Core Web API — RESTful HTTP servisleri için. JSON serileştirme, routing, model validation hazır gelir.
- Minimal API — Controller ihtiyacı olmayan küçük servislerde dosya başına 30-50 satırla çalışan bir HTTP servis kurabilirsiniz.
- gRPC — İçeride servisler arası yüksek performans iletişimi için. Protobuf tabanlı, JSON'a göre 3-5 kat hızlı.
- YARP — Microsoft'un kendi reverse proxy kütüphanesi. Custom API gateway veya BFF (Backend for Frontend) yazmak için kullanılır.
- MassTransit / NServiceBus — RabbitMQ, Azure Service Bus, Kafka üzerinde mesajlaşma soyutlaması.
- Polly — Retry, circuit breaker, timeout gibi resilience desenleri için standart kütüphane.
- OpenTelemetry — Distributed tracing ve metrik toplama; mikroservislerde kritik.
- .NET Aspire — .NET 8 ile gelen, çoklu servisleri lokal geliştirme ortamında orkestre eden yeni stack.
Bu listenin tek başına bir mikroservis sistemi kurmadığını hatırlatmak lazım. Liste sadece tuğlalardır; mimari tasarımı geliştirici yapar.
Tipik Bir .NET Mikroservisi Anatomisi
Minimal API ile yazılmış bir sipariş mikroservisi şu kadar yer kaplar:
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddDbContext<OrderContext>(opt =>
opt.UseNpgsql(builder.Configuration.GetConnectionString("Orders")));
builder.Services.AddScoped<IOrderRepository, OrderRepository>();
builder.Services.AddOpenTelemetry().WithTracing(t => t.AddAspNetCoreInstrumentation());
var app = builder.Build();
app.MapGet("/orders/{id:int}", async (int id, IOrderRepository repo) =>
{
var order = await repo.GetAsync(id);
return order is null ? Results.NotFound() : Results.Ok(order);
});
app.MapPost("/orders", async (CreateOrderDto dto, IOrderRepository repo) =>
{
var order = await repo.CreateAsync(dto);
return Results.Created($"/orders/{order.Id}", order);
});
app.Run();Bu kadar. Tek dosya, tek process, tek veritabanı. Production'da bunun yanına Dockerfile, appsettings.json, health check endpoint ve birim testleri eklenir. 200 satırı geçmeyen bir bağımsız servis ortaya çıkar — ki bu mikroservis felsefesinin tipik boyutudur.
Servisler Arası İletişim Modelleri
İki tür iletişim vardır: senkron (request-response) ve asenkron (message-based). İkisinin doğru yerde kullanılması mimarinin sağlığını belirler.
Senkron iletişim — HTTP ve gRPC
Çağıran servis cevabı beklerken hatta tutulur. UI tarafının bilgi sorgulaması, doğrulama gerektiren çağrılar genelde senkron yürür. HTTP/JSON dış istemciler ve dış API'lar için; gRPC iç servisler arası performans önemli yerlerde kullanılır. Senkron çağrı zincirleri uzadıkça gecikme katlanarak büyür, bu nedenle 4-5 servisi peşpeşe çağıran "senkron zincir" anti-pattern sayılır.
Asenkron iletişim — mesajlaşma
Çağıran taraf mesajı kuyruğa koyar ve devam eder. "Sipariş oluşturuldu" eventi yayınlanır; stok servisi, fatura servisi ve mail servisi bunu kendi temposunda dinler. Bu yaklaşım servisleri birbirinden gevşek bağlar; bir servis ölü olsa bile mesaj kuyruğunda birikir, geri geldiğinde işler. .NET tarafında MassTransit, kuyruk teknolojisini soyutlayarak RabbitMQ veya Azure Service Bus arasında geçişi pratikleştirir.
Kural: komut (yapılması gereken iş) senkron olabilir; event (olmuş bir gerçek) neredeyse her zaman asenkron yayınlanır.
Container ve Orkestrasyon
Mikroservisler container içinde yaşar. Bunun teknik nedeni izolasyondur; sosyal nedeni ise her servisin kendi runtime, kütüphane ve config bağımlılığını taşıyabilmesidir. .NET tarafında Docker resmi olarak desteklenir; dotnet publish komutu /p:PublishProfile=DefaultContainer bayrağıyla Dockerfile yazmadan container image üretir.
5-10 servisten fazlaya çıkıldığında container'ları elle yönetmek mümkün değil. Bu noktada Kubernetes devreye girer: hangi servisten kaç kopya çalışacak, hangisi hangisinden sonra ayağa kalkacak, biri çökerse ne olacak — hepsi declaratif manifest dosyalarıyla tanımlanır. Kubernetes ile çalışmayı yapılandırılmış biçimde ele almak isteyenler Kubernetes eğitimi'nden faydalanabilir.
Lokal geliştirmede her seferinde 8 container ayağa kaldırmak yorucu bir iştir. .NET 8 ile gelen .NET Aspire bu sorunu hedef alır: tek bir AppHost projesinden Redis, Postgres, RabbitMQ ve birden fazla servisi tek komutla ayağa kaldırır, dashboard üzerinden takip eder. Yeni bir proje tipi değil — geliştirici deneyimini düzelten bir orkestrasyon katmanı.
Microservices Her Probleme Cevap Değil
Mikroservis mimarisi 5 kişilik bir ekibin 3 aylık MVP'sinde uygulanırsa, mimari kazanç değil ek yük getirir. Martin Fowler bu durumu "monolith first" ilkesiyle özetler: önce monolit yaz, sınırları netleşince böl. Sebep basit; servis sınırlarını yanlış çizmek mikroservis kullanmamaktan daha pahalıdır. Hatalı bölünmüş bir sistem, fiziksel olarak dağıtılmış ama mantıksal olarak monolit gibi davranan — her değişiklikte üç servisi birden deploy etmek gereken — bir karmaşaya dönüşür. Buna distributed monolith denir, mikroservis dünyasının en yaygın patolojisidir.
Microservices ne zaman doğru karardır:
- Ekipler büyüdü, monolitte iki ekip aynı koda dokunmadan ilerleyemiyor.
- Uygulamanın bir parçası diğerinden çok farklı ölçek beklentisine sahip — örneğin, dakikada 10 bin istek gören öneri motoru ile saatte 50 istek gören admin paneli.
- Bağımsız teknoloji seçimi gerekiyor — bir servis Python ML modeli çağırıyor, diğeri .NET ile transactional iş yürütüyor.
- Deploy frekansı modülden modüle çok değişiyor — biri günde 5 kez, diğeri ayda bir.
Bu koşullar henüz mevcut değilse modüler monolit (iyi bölünmüş namespace'lerle tek deploy birimi) genelde daha sağlıklı bir başlangıçtır. Sistem büyüyünce sınırlar belirginleşir, o zaman aşamalı olarak mikroservislere geçilebilir. .NET'le mikroservis tarafına derinleşmek isteyenler için .NET microservices eğitimi mimari kararlardan kod örneklerine kadar tüm katmanı yapılandırılmış biçimde işler.
