Eclipse Jetty, hızlı ve gömülebilir yapısıyla Java mikroservislerinde kullanılan bir HTTP sunucusu ve Servlet runtime’ıdır. Uygulamanın içine dahil edilebildiği için ayrı bir application server kurulumunun gereksiz olduğu servislerde operasyonu sadeleştirebilir.
Mono’da kullanım alanları
- Mikroservis Java uygulamalarının runtime’ı
- WebSocket ve HTTP/2 destekli servisler
- Eclipse ekosistemi entegrasyonu
Mono’nun yaklaşımı
Jetty servisleri için JVM kaynak limitleri, thread pool, HTTP/2/WebSocket bağlantıları ve graceful shutdown birlikte ele alınır. Dış trafik çoğunlukla TLS, rate limit ve erişim politikalarını yöneten bir reverse proxy üzerinden geçirilir. Her sürüm geçişi gerçek bağlantı profiliyle staging ortamında doğrulanır.
Gömülü Jetty ile bağımsız sunucu arasındaki fark
Gömülü kullanımda HTTP sunucusunun yaşam döngüsü uygulamanın yaşam döngüsüne bağlanır. Connector, handler ve thread pool ayarları uygulamanın dağıtılan sürümünün parçasıdır. Bu, tekrarlanabilir paketleme sağlar; karşılığında Jetty güvenlik güncellemesinin de uygulama bağımlılığı güncellenerek yayınlanması gerekir. Sunucuda ayrı bir sistem paketini yükseltmek, uygulamanın içine gömülü kütüphaneyi değiştirmez.
Bağımsız dağıtımda ise uygulama ile sunucu yapılandırması ayrı yönetilebilir. Seçim, sadece bellek tüketimine göre değil; sürüm sorumluluğu, deploy sıklığı ve ekibin olay müdahale yöntemine göre yapılmalıdır. Tomcat de gömülü kullanılabilir; bu nedenle iki ürün arasındaki farkı yalnızca “biri gömülü, diğeri bağımsız” olarak açıklamak eksik kalır.
| Değerlendirme | Sorulması gereken soru |
|---|---|
| Framework desteği | Kullanılan framework hangi Jetty ve Servlet sürümünü destekliyor? |
| Uzun bağlantılar | WebSocket ve streaming bağlantıları deploy sırasında nasıl kapanacak? |
| Kaynak yönetimi | İstek işleme ve arka plan işleri aynı havuzu mu tüketiyor? |
| Bakım modeli | Runtime güncellemesi hangi pipeline üzerinden yayınlanacak? |
WebSocket ve HTTP/2 kapasitesini doğru ölçmek
WebSocket bağlantısı kurulmuş olması, uygulamanın veri üretmeye devam edebildiğini göstermez. Bağlantı sayısı, mesaj gecikmesi, istemci kopmaları ve yeniden bağlanma yoğunluğu birlikte izlenmelidir. Bir node’un yeniden başlaması çok sayıda istemcinin aynı anda bağlanmasına neden olabilir; bu dalga hem kimlik doğrulama servisini hem de backend’i etkiler.
HTTP/2 tarafında tek bağlantı üzerinden birden fazla akış taşınabilir. Bu nedenle yalnızca TCP bağlantı sayısıyla kapasite kararı verilmez. Akış sınırları, istek boyutu, idle timeout ve uygulamanın bloklayan işlemleri test edilir. Proxy ile Jetty arasında timeout uyumsuzluğu varsa bir taraf bağlantıyı sağlıklı kabul ederken diğer taraf kapatabilir.
Mono ile işletim kapsamını belirlemek
İlk adım, uygulamanın Jetty’yi nasıl başlattığını ve hangi bağımlılık sürümünü paketlediğini belirlemektir. Sonrasında erişim logları, JVM metrikleri ve uygulama hataları ortak istek kimliğiyle ilişkilendirilir. Sağlık kontrolü yalnızca sunucunun açıldığını değil, isteğe hizmet verebildiğini göstermelidir.
Üretime geçiş ölçütleri; kabul edilebilir gecikme, kontrollü bağlantı kapatma ve sorunlu sürümü geri alma süresini kapsar. Böylece runtime tercihi bir ürün adı olmaktan çıkar, ekibin yönetebileceği açık bir işletim modeline dönüşür.
