Merhaba Turkhacks okurları. Yazılım geliştirmeye yeni başlayanların büyük bölümü projelerine tek bir uygulama olarak başlar.
Aslında bu oldukça normaldir.
Bir kullanıcı sistemi vardır, ürünler vardır, siparişler vardır ve hepsi aynı proje içerisinde çalışır.
İlk başlarda işler gayet güzel gider. Kod sayısı azdır, hata bulmak kolaydır ve yeni özellik eklemek çok fazla zaman almaz.
Fakat proje büyümeye başladığında işler değişir.
Yeni modüller eklenir, ekip büyür, trafik artar ve bir süre sonra herkes aynı kod tabanı içerisinde çalışmaya başlar.
İşte tam bu noktada monolitik yapıların sınırları görünmeye başlar.
Son yıllarda bu sorunu çözmek için en çok tercih edilen yaklaşımlardan biri mikroservis mimarisi oldu.
Özellikle Spring Boot 3 ile birlikte bu yapıyı kurmak ve yönetmek geçmişe göre çok daha kolay hale geldi.
Peki mikroservis mimarisi tam olarak nedir ve Spring Boot 3 ile nasıl uygulanır?
Örneğin bir e-ticaret sistemi düşünelim.
Monolitik yapıda:
Mikroservis yaklaşımında ise her biri ayrı servis haline gelir.
Bu servisler birbirleriyle API üzerinden haberleşir.
Küçük projelerde mikroservis bazen gereksiz karmaşıklık oluşturabilir.
Ancak kullanıcı sayısı arttığında avantajları belirgin hale gelir.
Özellikle kurumsal projelerde bu fark ciddi şekilde hissedilir.
Spring Boot 3 ile birlikte:
Bu nedenle yeni projelerin büyük bölümü artık Spring Boot 3 üzerinde geliştiriliyor.
Mikroservis Yapısında İlk Adım: Servisleri Belirlemek
Yeni başlayanların yaptığı en büyük hatalardan biri her şeyi mikroservis haline getirmeye çalışmaktır.
Aslında amaç servis sayısını artırmak değil, sorumlulukları ayırmaktır.
Örnek bir yapı:
Bu yapı başlangıç için oldukça yeterlidir.
Bunun yerine tüm istekler önce API Gateway'e gelir.
Daha sonra ilgili servise yönlendirilir.
Basit bir örnek:
Client
↓
API Gateway
↓
User Service
Bu yaklaşımın önemli avantajları vardır.
Bu durumda servisler arasında iletişim kurmak gerekir.
En yaygın yöntemler:
Küçük ve orta ölçekli projelerde REST ve OpenFeign genellikle yeterli olur.
Gateway bunların hangisine bağlanacağını nasıl bilecek?
İşte burada Service Discovery devreye girer.
En yaygın çözüm:
Diğer servisler de bu kayıt üzerinden birbirlerini bulur.
Mikroservis mimarisinde ise onlarca servis olabilir.
Bu durumda her servisin ayrı ayrı ayarlanması yönetimi zorlaştırır.
Bu sorunu çözmek için:
Böylece tüm ayarlar merkezi olarak yönetilebilir.
Genel kabul gören yaklaşım şudur:
Bu yaklaşım servis bağımsızlığını korur.
Tipik yapı şöyledir:
Kullanıcı Giriş Yapar
↓
JWT Oluşturulur
↓
Gateway Token'ı Kontrol Eder
↓
İstek İlgili Servise Yönlendirilir
Bu sayede her servisin tekrar tekrar oturum kontrolü yapmasına gerek kalmaz.
Ancak 10 farklı servisin bulunduğu bir yapıda işler değişir.
Bir hata oluştuğunda:
Bu nedenle mikroservis projelerinde loglama ve izleme sistemleri kritik öneme sahiptir.
En sık kullanılan araçlar:
Bazen karmaşıklığı artırır.
Bu nedenle başlangıçta planlamak gerekir.
Ancak başarılı bir mikroservis yapısı yalnızca servisleri ayırmaktan ibaret değildir.
Servisler arası iletişim, güvenlik, loglama, izleme ve veritabanı yönetimi gibi birçok bileşenin birlikte düşünülmesi gerekir.
Küçük projelerde monolitik yapı çoğu zaman yeterli olabilir.
Ancak sistem büyümeye başladığında ve ekipler bağımsız çalışmak istediğinde mikroservis mimarisi ciddi avantajlar sunar.
Doğru planlandığında Spring Boot 3 ile geliştirilen mikroservis yapıları hem ölçeklenebilir
hem de uzun vadede daha yönetilebilir sistemler oluşturulmasını sağlar.
Sevgili Turkhacks okurları, bu makalede yazılımın mimarisinin en önemli servi yapılarından olan Spring Boot 3'ü inceledik. Her ne kadar günümüzde yapayzeka araçlarının gelişimiyle yazılım sektöründe insan gücüne çok fazla iş kalmasa da çeşitli yz araçlarının kurduğu yazılım mimarilerini denetleyerek servis yapılarının işlevlerini kontrol etmeliyiz. Bir dahaki makaalemizde görüşene kadar mavi ekransız ve sorunsuz sistemlerle çalışmanız dileği ile hoşçakalın.
Aslında bu oldukça normaldir.
Bir kullanıcı sistemi vardır, ürünler vardır, siparişler vardır ve hepsi aynı proje içerisinde çalışır.
İlk başlarda işler gayet güzel gider. Kod sayısı azdır, hata bulmak kolaydır ve yeni özellik eklemek çok fazla zaman almaz.
Fakat proje büyümeye başladığında işler değişir.
Yeni modüller eklenir, ekip büyür, trafik artar ve bir süre sonra herkes aynı kod tabanı içerisinde çalışmaya başlar.
İşte tam bu noktada monolitik yapıların sınırları görünmeye başlar.
Son yıllarda bu sorunu çözmek için en çok tercih edilen yaklaşımlardan biri mikroservis mimarisi oldu.
Özellikle Spring Boot 3 ile birlikte bu yapıyı kurmak ve yönetmek geçmişe göre çok daha kolay hale geldi.
Peki mikroservis mimarisi tam olarak nedir ve Spring Boot 3 ile nasıl uygulanır?
Mikroservis Mimarisi Nedir?
En basit tanımıyla mikroservis mimarisi, büyük bir uygulamayı küçük ve bağımsız servislere bölme yaklaşımıdır.Örneğin bir e-ticaret sistemi düşünelim.
Monolitik yapıda:
- Kullanıcı işlemleri
- Ürün yönetimi
- Sipariş sistemi
- Ödeme işlemleri
Mikroservis yaklaşımında ise her biri ayrı servis haline gelir.
| Servis | Görevi |
|---|---|
| User Service | Kullanıcı yönetimi |
| Product Service | Ürün işlemleri |
| Order Service | Sipariş yönetimi |
| Payment Service | Ödeme işlemleri |
Neden Mikroservis Kullanılır?
Bu sorunun cevabı aslında proje büyüklüğünde saklı.Küçük projelerde mikroservis bazen gereksiz karmaşıklık oluşturabilir.
Ancak kullanıcı sayısı arttığında avantajları belirgin hale gelir.
| Monolitik Yapı | Mikroservis Yapısı |
| Tek proje | Birden fazla servis |
| Tek dağıtım | Bağımsız dağıtım |
| Ölçekleme zor | Ölçekleme kolay |
| Ekip yönetimi zorlaşabilir | Ekipler bağımsız çalışabilir |
Spring Boot 3 Neden Tercih Ediliyor?
Java dünyasında mikroservis denildiğinde akla gelen ilk teknolojilerden biri Spring Boot'tur.Spring Boot 3 ile birlikte:
- Daha iyi performans
- Güncel Jakarta EE desteği
- Native image desteği
- Modern güvenlik yapıları
Bu nedenle yeni projelerin büyük bölümü artık Spring Boot 3 üzerinde geliştiriliyor.
Mikroservis Yapısında İlk Adım: Servisleri Belirlemek
Yeni başlayanların yaptığı en büyük hatalardan biri her şeyi mikroservis haline getirmeye çalışmaktır.
Aslında amaç servis sayısını artırmak değil, sorumlulukları ayırmaktır.
Örnek bir yapı:
- api-gateway
- user-service
- product-service
- order-service
- payment-service
Bu yapı başlangıç için oldukça yeterlidir.
API Gateway Neden Gereklidir?
Mikroservis mimarisinde istemcinin her servise doğrudan bağlanması genellikle tercih edilmez.Bunun yerine tüm istekler önce API Gateway'e gelir.
Daha sonra ilgili servise yönlendirilir.
Basit bir örnek:
Client
↓
API Gateway
↓
User Service
Bu yaklaşımın önemli avantajları vardır.
- Merkezi güvenlik
- Merkezi loglama
- Yetkilendirme kontrolü
- Trafik yönetimi
Servisler Birbiriyle Nasıl Haberleşir?
Bir sipariş oluşturulduğunda çoğu zaman kullanıcı bilgisine ihtiyaç duyulur.Bu durumda servisler arasında iletişim kurmak gerekir.
En yaygın yöntemler:
| Yöntem | Kullanım |
| REST API | Çok yaygın |
| OpenFeign | Spring ekosistemi |
| Kafka | Olay tabanlı yapı |
| RabbitMQ | Mesajlaşma |
Küçük ve orta ölçekli projelerde REST ve OpenFeign genellikle yeterli olur.
Service Discovery Neden Kullanılır?
Diyelim ki User Service üç farklı sunucuda çalışıyor.Gateway bunların hangisine bağlanacağını nasıl bilecek?
İşte burada Service Discovery devreye girer.
En yaygın çözüm:
- Eureka Server
Diğer servisler de bu kayıt üzerinden birbirlerini bulur.
Merkezi Konfigürasyon Yönetimi
Monolitik projelerde yapılandırma dosyası genellikle tektir.Mikroservis mimarisinde ise onlarca servis olabilir.
Bu durumda her servisin ayrı ayrı ayarlanması yönetimi zorlaştırır.
Bu sorunu çözmek için:
- Spring Cloud Config
Böylece tüm ayarlar merkezi olarak yönetilebilir.
Veritabanı Tasarımı Nasıl Olmalı?
Mikroservis mimarisine geçen ekiplerin en çok tartıştığı konulardan biri budur.Genel kabul gören yaklaşım şudur:
Örnek:
| Servis | Veritabanı |
| User Service | User DB |
| Product Service | Product DB |
| Order Service | Order DB |
Bu yaklaşım servis bağımsızlığını korur.
Güvenlik Katmanı Nasıl Kurulur?
Modern mikroservis projelerinde en yaygın yöntem JWT tabanlı kimlik doğrulamadır.Tipik yapı şöyledir:
Kullanıcı Giriş Yapar
↓
JWT Oluşturulur
↓
Gateway Token'ı Kontrol Eder
↓
İstek İlgili Servise Yönlendirilir
Bu sayede her servisin tekrar tekrar oturum kontrolü yapmasına gerek kalmaz.
Loglama ve İzleme Neden Önemlidir?
Tek bir uygulamadan oluşan sistemlerde hata bulmak nispeten kolaydır.Ancak 10 farklı servisin bulunduğu bir yapıda işler değişir.
Bir hata oluştuğunda:
- Hangi servis hata verdi?
- Hangi istek başarısız oldu?
- Hata zinciri nerede başladı?
Bu nedenle mikroservis projelerinde loglama ve izleme sistemleri kritik öneme sahiptir.
En sık kullanılan araçlar:
| Araç | Amaç |
| ELK Stack | Log yönetimi |
| Prometheus | Metrikler |
| Grafana | Görselleştirme |
| Zipkin | Distributed tracing |
Mikroservis Kullanırken Yapılan Yaygın Hatalar
Gereğinden Fazla Servis Oluşturmak
Her modülü ayrı servis yapmak her zaman iyi bir fikir değildir.Bazen karmaşıklığı artırır.
Ortak Veritabanı Kullanmak
Birden fazla servisin aynı tabloyu yönetmesi ileride ciddi sorunlar oluşturabilir.İzleme Sistemlerini Sonradan Düşünmek
Proje büyüdükten sonra loglama ve monitoring eklemek çok daha zor hale gelir.Bu nedenle başlangıçta planlamak gerekir.
Spring Boot 3 ile mikroservis mimarisi kurmak geçmiş yıllara göre çok daha erişilebilir hale geldi.Ancak başarılı bir mikroservis yapısı yalnızca servisleri ayırmaktan ibaret değildir.
Servisler arası iletişim, güvenlik, loglama, izleme ve veritabanı yönetimi gibi birçok bileşenin birlikte düşünülmesi gerekir.
Küçük projelerde monolitik yapı çoğu zaman yeterli olabilir.
Ancak sistem büyümeye başladığında ve ekipler bağımsız çalışmak istediğinde mikroservis mimarisi ciddi avantajlar sunar.
Doğru planlandığında Spring Boot 3 ile geliştirilen mikroservis yapıları hem ölçeklenebilir
hem de uzun vadede daha yönetilebilir sistemler oluşturulmasını sağlar.
Sevgili Turkhacks okurları, bu makalede yazılımın mimarisinin en önemli servi yapılarından olan Spring Boot 3'ü inceledik. Her ne kadar günümüzde yapayzeka araçlarının gelişimiyle yazılım sektöründe insan gücüne çok fazla iş kalmasa da çeşitli yz araçlarının kurduğu yazılım mimarilerini denetleyerek servis yapılarının işlevlerini kontrol etmeliyiz. Bir dahaki makaalemizde görüşene kadar mavi ekransız ve sorunsuz sistemlerle çalışmanız dileği ile hoşçakalın.
Son düzenleme:
