Apache Tomcat, Servlet/JSP tabanlı Java uygulamaları için olgun ve yaygın bir runtime’dır. Üretimde genellikle TLS terminasyonu, erişim kontrolü ve yük dağıtımı Nginx veya HAProxy’de; uygulama yaşam döngüsü Tomcat’te yönetilir.
Mono’da kullanım alanları
- Java enterprise uygulama dağıtımı
- Tomcat cluster ve oturum replikasyonu
- JDBC bağlantı havuzu ve performans iyileştirme
Üretim yaklaşımı
Tomcat kurulumlarında Java sürümü, JVM kaynak sınırları, connector thread pool, datasource pool, health endpoint’i ve graceful shutdown birlikte ele alınır. Her instance aynı konfigürasyonun izlenebilir bir sürümünden üretilir. Böylece bir node’u bakım için çıkarmak, kullanıcı trafiğini kesmeden yapılabilir.
Tomcat mi Jetty mi, tam uygulama sunucusu mu?
Tomcat bir Servlet konteyneridir; bütün Jakarta EE özelliklerini sağlayan tam bir uygulama sunucusuyla eş tutulmamalıdır. Uygulamanın kullandığı API’ler ve framework, hangi runtime’ın uygun olduğunu belirler. Mevcut bir WAR paketinin çalışması, onun yeni bir ana sürüme değişiklik yapılmadan taşınabileceğini garanti etmez.
| Senaryo | Karar noktası |
|---|---|
| Mevcut WAR dağıtımı | Servlet sürümü, Java gereksinimi ve kullanılan kütüphaneler kontrol edilir. |
| Gömülü HTTP sunucusu | Framework’ün Tomcat ve Jetty desteği, paketleme modeliyle birlikte değerlendirilir. |
| Tam Jakarta EE servisleri | Gerekli API’lerin uygulama tarafından mı, sunucu tarafından mı sağlandığı belirlenir. |
| Birden fazla uygulama | Ortak runtime tasarrufu ile ayrı süreçlerin hata izolasyonu karşılaştırılır. |
Özellikle javax.* ile jakarta.* paket adları arasındaki geçiş, yalnızca sunucu paketini güncellemekten ibaret değildir. Uygulama bağımlılıkları, filtreler ve üçüncü taraf entegrasyonları birlikte test edilmelidir. Java ve Tomcat sürümlerinin destek yaşam döngüsü ayrıca izlenir.
Kapasite: daha fazla thread her zaman daha hızlı değildir
Bir istek thread’i veritabanı bağlantısı bekliyorsa thread sayısını artırmak veritabanına daha fazla eşzamanlı yük gönderebilir. Connector sınırları, JDBC havuzu ve veritabanının kabul edebileceği bağlantı sayısı ortak bir kapasite planına dayanmalıdır. CPU kullanımı düşükken yanıt süreleri yükseliyorsa bağlantı bekleme, dış servis gecikmesi veya kilitlenme araştırılır.
JVM heap boyutunun yanında garbage collection duraklamaları, native bellek ve konteyner bellek sınırı da önemlidir. Yalnızca ortalama yanıt süresine bakılmaz; p95/p99 gecikmesi, hata oranı ve istek kuyruğunun nasıl büyüdüğü izlenir. Thread dump ve heap dump dosyaları hassas uygulama verisi içerebileceğinden erişimleri kontrollü tutulur.
Oturum kaybı olmadan sürüm geçişi nasıl planlanır?
Yük dengeleyicide bir node’a yeni trafik durdurulur, devam eden istekler için boşaltma süresi tanınır ve yeni sürüm hazır olduğunda readiness kontrolüyle tekrar havuza alınır. Cookie tabanlı yönlendirme tek başına yedeklilik sağlamaz: oturum yalnızca arızalanan node’un belleğindeyse kullanıcı yeniden giriş yapmak zorunda kalabilir.
Paylaşılan oturum deposu veya replikasyon seçimi; veri hacmi, serileştirme uyumluluğu ve sürümler arası geçişle birlikte değerlendirilir. Veritabanı şeması değişiklikleri eski sürümle uyumlu değilse uygulama rollback’i de yeterli olmaz. Mono’nun yaklaşımı, runtime güncellemesini uygulama ve veri katmanı için tanımlanmış geri dönüş koşullarıyla birlikte yürütmektir.
