Yazılım uygulamaları büyüdükçe yeni özelliklerin geliştirilmesi, mevcut kodların güncellenmesi ve sistemin yüksek trafik altında çalıştırılması daha karmaşık hâle gelebilir. Tek bir uygulama içerisindeki küçük bir değişiklik, sistemin diğer bölümlerini etkileyebilir ve uygulamanın tamamının yeniden yayımlanmasını gerektirebilir.

Bu sorunları azaltmak amacıyla kullanılan yazılım geliştirme yaklaşımlarından biri microservice mimarisidir.

Microservice mimarisi, büyük bir yazılım uygulamasının belirli iş yeteneklerine odaklanan küçük, bağımsız ve birbiriyle iletişim kurabilen servislere ayrılmasıdır.

Türkçede bu kavram:

Mikroservis mimarisi
Microservices mimarisi
Mikro hizmet mimarisi

şeklinde kullanılabilir.

Microservice mimarisinde bir e-ticaret uygulaması tek parça olarak geliştirilmek yerine şu servislere ayrılabilir:

Kullanıcı servisi
Ürün servisi
Stok servisi
Sepet servisi
Sipariş servisi
Ödeme servisi
Kargo servisi
Bildirim servisi

Her servis kendi sorumluluk alanına odaklanır. Gerektiğinde bağımsız olarak geliştirilebilir, test edilebilir, yayımlanabilir ve ölçeklendirilebilir.

Ancak bir uygulamayı çok sayıda küçük parçaya ayırmak, tek başına başarılı bir microservice mimarisi oluşturmaz. Servis sınırlarının doğru belirlenmesi, iletişimin güvenli kurulması, verilerin yönetilmesi ve sistemin merkezi biçimde izlenebilmesi gerekir.

Microservice mimarisi özellikle hızlı büyüyen, yüksek trafik alan ve farklı ekipler tarafından geliştirilen uygulamalarda değerlendirilebilir. Küçük ve basit projelerde ise gereksiz teknik ve operasyonel karmaşıklık oluşturabilir.

Dijital sistemlerin işletme süreçlerine nasıl entegre edildiğini anlamak için dijital dönüşüm yaklaşımı incelenebilir.

Microservice Mimarisi Nedir?

Microservice mimarisi, bir uygulamanın bağımsız işlevlere sahip küçük servislerden oluşacak biçimde tasarlandığı yazılım mimarisi yaklaşımıdır.

Her mikroservis:

Belirli bir iş yeteneğini yerine getirir.
Kendi kod tabanına sahip olabilir.
Bağımsız olarak çalışabilir.
Ayrı biçimde yayımlanabilir.
Gerektiğinde bağımsız ölçeklendirilebilir.
Diğer servislerle API veya mesajlaşma sistemi üzerinden iletişim kurabilir.
Kendi verilerini yönetebilir.
Farklı programlama dili veya veri tabanı kullanabilir.

Örneğin bir sipariş servisi yalnızca sipariş oluşturma, sipariş durumunu takip etme ve sipariş bilgilerini yönetme görevlerinden sorumlu olabilir.

Ödeme işlemleri ise ayrı bir ödeme servisi tarafından yürütülebilir. Ödeme servisinde yapılan bir güncelleme, doğru tasarlanmış bir yapıda ürün veya kullanıcı servisinin yeniden yayımlanmasını gerektirmeyebilir.

Microservice Ne Demek?

“Microservice” kelimesi Türkçeye mikroservis veya mikro hizmet olarak çevrilebilir.

Buradaki “micro” ifadesi servisin mutlaka çok az kod içermesi gerektiği anlamına gelmez. Servisin sınırı, kod satırı sayısından çok yerine getirdiği iş sorumluluğuna göre belirlenir.

Bir mikroservis:

Tek bir ekip tarafından yönetilebilmeli
Belirli bir iş alanına odaklanmalı
Bağımsız biçimde geliştirilebilmeli
Diğer servislerden mümkün olduğunca az etkilenmeli
Açık bir arayüz üzerinden iletişim kurmalıdır

Servisleri gereğinden fazla küçültmek de iyi bir yaklaşım değildir. Çok küçük ve birbirine yoğun biçimde bağımlı servisler, dağıtık monolit olarak adlandırılabilecek karmaşık bir yapı oluşturabilir.

Microservice Mimarisinin Temel Özellikleri

Tek Bir İş Yeteneğine Odaklanma

Her mikroservis belirli bir iş yeteneğini yerine getirmelidir.

Örnekler:

Kimlik doğrulama
Ürün yönetimi
Ödeme
Sipariş
Kargo
Bildirim
Raporlama

Bir servisin birbiriyle ilgisiz çok sayıda görevi üstlenmesi servis sınırlarının doğru belirlenmediğini gösterebilir.

Bağımsız Dağıtım

Mikroservislerin önemli özelliklerinden biri, diğer servisler yeniden yayımlanmadan bağımsız biçimde dağıtılabilmeleridir.

Örneğin bildirim servisindeki e-posta şablonu değiştirildiğinde uygulamanın ödeme ve sipariş servislerinin yeniden yayımlanması gerekmeyebilir.

Bağımsız Ölçeklendirme

Her servis aynı miktarda kaynak tüketmez.

Bir e-ticaret uygulamasında kampanya döneminde:

Ürün servisi
Arama servisi
Sepet servisi

yoğun trafik alabilir.

Muhasebe veya raporlama servisi ise daha düşük trafikle çalışabilir.

Microservice yapısında yalnızca yoğun kullanılan servisler ölçeklendirilebilir. Böylece bütün uygulama için aynı miktarda sunucu kaynağı ayırmak gerekmeyebilir.

Servislerin Kendi Verisini Yönetmesi

Microservice mimarisinde genel yaklaşım, her servisin kendi veri alanından sorumlu olmasıdır.

Örneğin:

Kullanıcı servisi kullanıcı verilerini
Ürün servisi ürün verilerini
Sipariş servisi sipariş verilerini
Ödeme servisi ödeme verilerini

yönetebilir.

Bir servisin başka servisin veri tabanına doğrudan erişmesi sıkı bağımlılık oluşturabilir. Bunun yerine servisler API veya olaylar üzerinden bilgi paylaşabilir.

Teknoloji Bağımsızlığı

Her servis aynı programlama dili veya veri tabanı teknolojisini kullanmak zorunda değildir.

Örneğin:

Kullanıcı servisi ilişkisel veri tabanı
Arama servisi arama motoru tabanlı veri deposu
Önbellek servisi bellek içi veri sistemi
Analitik servisi sütun tabanlı veri tabanı

kullanabilir.

Bu yaklaşım polyglot programming ve polyglot persistence kavramlarıyla açıklanır.

Ancak her servis için farklı teknoloji seçmek bakım, eğitim ve güvenlik maliyetini artırabilir. Teknoloji çeşitliliği yalnızca gerçek bir teknik ihtiyaç bulunduğunda kullanılmalıdır.

Hata Yalıtımı

Bir mikroserviste oluşan hata, doğru tasarlanmış bir sistemde uygulamanın tamamını durdurmamalıdır.

Örneğin tavsiye servisi geçici olarak çalışmıyorsa kullanıcılar ürünleri görüntülemeye ve sipariş vermeye devam edebilmelidir.

Bu durum için:

Zaman aşımı
Yeniden deneme
Circuit breaker
Yedek cevap
Kuyruklama
Hata sınırlandırma

gibi yöntemler kullanılabilir.

Monolitik Mimari Nedir?

Monolitik mimari, bir uygulamanın kullanıcı arayüzü, iş mantığı ve veri erişimi gibi temel bölümlerinin tek bir uygulama paketi içerisinde geliştirildiği yapıdır.

Bir monolitik e-ticaret uygulamasında:

Kullanıcılar
Ürünler
Siparişler
Ödemeler
Kargo
Bildirimler

aynı kod tabanında bulunabilir.

Uygulamanın tamamı tek bir birim olarak:

Geliştirilir
Test edilir
Yayımlanır
Ölçeklendirilir

Monolitik mimari her zaman kötü veya eski bir yaklaşım değildir. Küçük ekipler ve sınırlı kapsamlı projeler için daha kolay geliştirilebilir ve yönetilebilir.

Microservice ve Monolitik Mimari Arasındaki Fark

Kriter	Monolitik mimari	Microservice mimarisi
Uygulama yapısı	Tek uygulama	Bağımsız servisler
Kod tabanı	Genellikle ortak	Servis bazında ayrılabilir
Dağıtım	Uygulamanın tamamı	Her servis bağımsız
Ölçeklendirme	Bütün uygulama	İhtiyaç duyulan servis
Veri yönetimi	Ortak veri tabanı olabilir	Servis bazlı veri yönetimi
Teknoloji seçimi	Ortak teknoloji yığını	Servise göre değişebilir
Başlangıç kolaylığı	Daha kolay	Daha karmaşık
Operasyon	Görece sade	Dağıtık sistem yönetimi gerekir
Hata etkisi	Uygulamanın tamamına yayılabilir	Servis düzeyinde sınırlandırılabilir
Ekip yapısı	Merkezi ekip	Servis veya alan ekipleri
Test	Tek uygulama üzerinden	Servis ve entegrasyon testleri
İletişim gecikmesi	Süreç içi çağrılar	Ağ üzerinden çağrılar

Monolitik Yapının Avantajları

Başlangıçta daha kolay geliştirilebilir.
Yerel ortamda çalıştırılması daha kolaydır.
Servisler arası ağ iletişimi gerekmez.
Dağıtım süreci daha sade olabilir.
Dağıtık izleme altyapısı gerektirmez.
Küçük ekipler için daha düşük operasyon yükü oluşturabilir.
Veri tutarlılığı daha kolay yönetilebilir.

Monolitik Yapının Dezavantajları

Uygulama büyüdükçe:

Kod tabanı karmaşıklaşabilir.
Yeni geliştiricilerin projeye alışması zorlaşabilir.
Küçük değişiklikler bütün uygulamanın yayımlanmasını gerektirebilir.
Uygulamanın tamamı ölçeklendirilmek zorunda kalabilir.
Teknoloji yenilemesi zorlaşabilir.
Ekipler birbirinin çalışmalarını bekleyebilir.
Tek bir hata bütün sistemi etkileyebilir.

Microservice Mimarisi Nasıl Çalışır?

Microservice mimarisinde kullanıcı doğrudan bütün servislere bağlanmak yerine çoğunlukla ortak bir giriş noktası üzerinden sisteme ulaşır.

Basitleştirilmiş akış şu şekilde olabilir:

Kullanıcı
   |
API Gateway
   |
-----------------------------------------
|       |        |        |             |
Ürün   Sepet   Sipariş   Ödeme       Kullanıcı
Servisi Servisi Servisi  Servisi      Servisi

Kullanıcı bir sipariş oluşturduğunda:

API Gateway isteği karşılar.
Kimlik bilgileri doğrulanır.
Sipariş servisi sepet bilgilerini alır.
Stok servisi ürün uygunluğunu kontrol eder.
Ödeme servisi ödemeyi işler.
Sipariş kaydı oluşturulur.
Kargo servisine olay gönderilir.
Bildirim servisi müşteriye mesaj iletir.

Bu işlemler senkron veya asenkron iletişim yöntemleriyle yürütülebilir.

Microservice Mimarisinin Temel Bileşenleri

Mikroservisler

Sistemin belirli iş yeteneklerini yerine getiren bağımsız uygulamalardır.

Her servis için:

Sorumluluk
API sözleşmesi
Veri alanı
Ekip sahibi
Dağıtım süreci
İzleme metrikleri

açıkça belirlenmelidir.

API Gateway

API Gateway, kullanıcılar ile mikroservisler arasında ortak giriş noktası oluşturan bileşendir.

API Gateway şu işlemleri gerçekleştirebilir:

İstek yönlendirme
Kimlik doğrulama
Yetkilendirme
Trafik sınırlama
Yük dengeleme
Önbellekleme
Loglama
API sürüm yönetimi
Yanıt birleştirme

Kullanıcıların her servisin adresini ayrı ayrı bilmesi gerekmez.

API Gateway kullanılmadığında istemci uygulamalar çok sayıda servisle doğrudan bağlantı kurmak zorunda kalabilir. Bu durum güvenlik ve bağımlılık sorunları oluşturabilir.

Service Discovery

Microservice ortamlarında servislerin adresleri sabit olmayabilir. Servis örnekleri yük durumuna göre oluşturulabilir veya kaldırılabilir.

Service discovery, bir servisin iletişim kuracağı diğer servisin güncel ağ adresini bulmasını sağlar.

İki temel yöntem bulunur:

İstemci taraflı keşif
Sunucu taraflı keşif

Container orkestrasyon platformları servis keşfi özelliğini yerleşik olarak sunabilir.

Load Balancer

Load balancer, gelen trafiği aynı servisin farklı örnekleri arasında dağıtır.

Örneğin ürün servisinin beş örneği çalışıyorsa talepler bu örnekler arasında paylaştırılabilir.

Yük dengeleme:

Tek sunucuya aşırı yük binmesini önleyebilir.
Kullanılabilirliği artırabilir.
Servislerin yatay ölçeklenmesini destekleyebilir.
Hatalı örneklerin trafikten çıkarılmasını sağlayabilir.

Mesaj Kuyruğu ve Event Bus

Servislerin her zaman birbirine doğrudan ve eş zamanlı istek göndermesi gerekmez.

Mesaj kuyruğu veya event bus üzerinden olay tabanlı iletişim kurulabilir.

Örneğin sipariş tamamlandığında:

Sipariş oluşturuldu

olayı yayınlanabilir.

Bu olayı:

Stok servisi
Kargo servisi
Bildirim servisi
Analitik servisi

ayrı ayrı dinleyebilir.

Sipariş servisi bütün servislerin işlemi tamamlamasını beklemek zorunda kalmayabilir.

Veri Tabanları

Her mikroservis kendi veri tabanına veya veri şemasına sahip olabilir.

Kullanılabilecek sistemler:

İlişkisel veri tabanı
Belge tabanlı veri tabanı
Anahtar-değer deposu
Grafik veri tabanı
Arama motoru
Zaman serisi veri tabanı

olabilir.

Seçim servisin veri yapısına ve sorgu ihtiyacına göre yapılmalıdır.

Merkezi Yapılandırma

Servislerin:

Veri tabanı adresleri
API anahtarları
Ortam değişkenleri
Özellik bayrakları
Servis adresleri

kod içerisine sabit biçimde yazılmamalıdır.

Merkezi yapılandırma sistemi, geliştirme, test ve üretim ortamlarındaki ayarların daha güvenli yönetilmesini sağlar.

Loglama ve İzleme

Dağıtık sistemlerde bir kullanıcı isteği birden fazla servisten geçebilir.

Sorun oluştuğunda:

Hangi serviste hata meydana geldiği
İsteğin hangi servislerden geçtiği
Hangi işlemin geciktiği
Hangi veriyle çalışıldığı

belirlenmelidir.

Bu nedenle:

Merkezi loglama
Metrik toplama
Distributed tracing
Alarm sistemleri
Sağlık kontrolleri

kurulmalıdır.

Container Orkestrasyonu

Container sayısı arttığında bunların manuel olarak yönetilmesi zorlaşır.

Orkestrasyon platformları:

Container dağıtımı
Otomatik yeniden başlatma
Yatay ölçeklendirme
Servis keşfi
Yük dengeleme
Güncelleme
Gizli bilgi yönetimi

gibi görevleri yerine getirebilir.

CI/CD Sistemi

CI/CD, kod değişikliklerinin otomatik test, paketleme ve dağıtım süreçlerinden geçirilmesini sağlar.

Microservice mimarisinde her servisin bağımsız dağıtım hattına sahip olması değerlendirilebilir.

CI/CD süreci:

Kod kontrolü
Birim testleri
Güvenlik taraması
Container oluşturma
Entegrasyon testleri
Test ortamına dağıtım
Üretime dağıtım

aşamalarından oluşabilir.

Service Mesh

Service mesh, servisler arasındaki ağ iletişimini yöneten altyapı katmanıdır.

Service mesh:

Trafik yönetimi
Karşılıklı kimlik doğrulama
Şifreleme
Yeniden deneme
Zaman aşımı
Gözlemlenebilirlik
Canary dağıtımı

gibi yetenekler sunabilir.

Küçük sistemlerde service mesh gereksiz karmaşıklık oluşturabilir. Servis ve trafik sayısı arttığında değerlendirilmelidir.

Microservice İletişim Yöntemleri

Mikroservisler iki temel yöntemle iletişim kurabilir:

Senkron iletişim
Asenkron iletişim

Senkron İletişim

Senkron iletişimde servis bir istek gönderir ve yanıt gelmesini bekler.

Kullanılabilecek yöntemler:

REST API
gRPC
GraphQL
HTTP
WebSocket

olabilir.

Örnek:

Sipariş servisi, ürünün stokta bulunup bulunmadığını öğrenmek için stok servisine istek gönderir ve yanıt bekler.

Senkron İletişimin Avantajları

Uygulaması ve anlaşılması daha kolay olabilir.
İşlem sonucu anında alınabilir.
Basit sorgular için uygundur.
Hata yanıtı doğrudan döndürülebilir.

Senkron İletişimin Dezavantajları

Servisler birbirine bağımlı hâle gelebilir.
Zincirleme çağrılar gecikmeyi artırabilir.
Bir servisin çökmesi diğer işlemleri durdurabilir.
Trafik yoğunluğunda darboğaz oluşabilir.

Asenkron İletişim

Asenkron iletişimde servis bir mesaj veya olay gönderir ancak işlemin tamamlanmasını beklemek zorunda değildir.

Örnek:

Sipariş servisi, sipariş tamamlandığında bir olay yayınlar. Bildirim servisi bu olayı daha sonra işleyerek müşteriye e-posta gönderir.

Asenkron İletişimin Avantajları

Servisler arasındaki bağımlılığı azaltabilir.
Yoğun trafik kuyrukta bekletilebilir.
Sistem dayanıklılığını artırabilir.
Uzun süren işlemler arka planda yürütülebilir.
Bir olayı birden fazla servis tüketebilir.

Asenkron İletişimin Dezavantajları

Hata takibi zorlaşabilir.
Mesajların sırası önem kazanabilir.
Aynı mesaj birden fazla kez işlenebilir.
Nihai tutarlılık yaklaşımı gerekebilir.
Test ve hata ayıklama karmaşıklaşabilir.

Senkron ve Asenkron İletişim Karşılaştırması

Kriter	Senkron iletişim	Asenkron iletişim
Yanıt	Anında beklenir	Daha sonra işlenebilir
Bağımlılık	Daha yüksek olabilir	Daha düşüktür
Gecikme	Zincirleme çağrılarda artabilir	Kuyruk üzerinden yönetilebilir
Hata yönetimi	Doğrudan yanıt alınır	Ayrı hata ve tekrar sistemi gerekir
Kullanım	Anlık sorgular	Olaylar ve arka plan işlemleri
Örnek	Stok sorgulama	Bildirim gönderme

REST API ve gRPC Arasındaki Fark

Kriter	REST API	gRPC
Protokol	Genellikle HTTP/HTTPS	HTTP/2
Veri biçimi	Çoğunlukla JSON	Protocol Buffers
Okunabilirlik	İnsan tarafından daha kolay okunur	İkili format kullanabilir
Performans	Genel web API’leri için uygundur	Servisler arası iletişimde yüksek performans sunabilir
Tarayıcı desteği	Yaygındır	Ek çözümler gerekebilir
Sözleşme	OpenAPI kullanılabilir	Güçlü şema tanımı vardır
Akış desteği	Sınırlı olabilir	İki yönlü akış desteği bulunur

Teknoloji seçimi ekip deneyimi, performans ihtiyacı ve istemci türüne göre yapılmalıdır.

Microservice Mimarisinde Veri Yönetimi

Microservice mimarisinin en zor konularından biri dağıtık veri yönetimidir.

Monolitik sistemlerde birden fazla tablo tek işlem içerisinde güncellenebilir. Mikroservislerde ise veriler farklı servislerde bulunabilir.

Örneğin sipariş oluştururken:

Sipariş kaydı
Stok düşümü
Ödeme
Kargo kaydı

farklı servislerde gerçekleşebilir.

Bu işlemlerden biri başarısız olduğunda sistemin tutarlı durumda kalması gerekir.

Database per Service Yaklaşımı

Database per service, her mikroservisin kendi veri deposuna sahip olmasıdır.

Avantajları:

Veri bağımsızlığı sağlar.
Şema değişiklikleri diğer servisleri daha az etkiler.
Servise uygun veri tabanı seçilebilir.
Bağımsız ölçeklendirme kolaylaşabilir.

Dezavantajları:

Servisler arası raporlama zorlaşabilir.
Dağıtık işlemler karmaşıklaşır.
Veri tekrarları oluşabilir.
Tutarlılık yönetimi gerekir.

Ortak Veri Tabanı Kullanımı

Bütün servislerin aynı veri tabanını paylaşması başlangıçta daha kolay görünebilir.

Ancak servislerin birbirinin tablolarına doğrudan erişmesi:

Sıkı bağımlılık
Şema değişikliği riski
Bağımsız dağıtımın bozulması
Veri sahipliği belirsizliği
Performans sorunları

oluşturabilir.

Geçiş döneminde ortak veri tabanı kullanılabilir ancak uzun vadeli hedef ve sınırlar açıkça belirlenmelidir.

Saga Pattern Nedir?

Saga pattern, birden fazla mikroservisi kapsayan iş süreçlerinin küçük ve yerel işlemler hâlinde yürütülmesini sağlar.

Her adım başarılı olduğunda sonraki işleme geçilir. Bir adım başarısız olursa önceki işlemleri geri alan telafi adımları çalıştırılabilir.

Örnek sipariş süreci:

Sipariş oluşturulur.
Stok ayrılır.
Ödeme alınır.
Kargo kaydı açılır.

Ödeme başarısız olursa:

Ayrılan stok geri bırakılır.
Sipariş iptal edilir.
Kullanıcı bilgilendirilir.

Saga iki yöntemle uygulanabilir:

Koreografi
Orkestrasyon

CQRS Nedir?

CQRS, veriyi değiştiren komutlarla veriyi okuyan sorguların ayrılmasını ifade eden mimari yaklaşımdır.

Sistemde:

Yazma işlemleri ayrı model
Okuma işlemleri ayrı model

üzerinden yönetilebilir.

CQRS:

Karmaşık iş kurallarında
Okuma ve yazma yükünün farklı olduğu sistemlerde
Olay tabanlı yapılarda
Yüksek ölçek ihtiyacında

kullanılabilir.

Basit uygulamalarda CQRS gereksiz karmaşıklık oluşturabilir.

Event Sourcing Nedir?

Event sourcing, sistemin güncel durumunu doğrudan saklamak yerine meydana gelen olayları kaydeden yaklaşımdır.

Örneğin hesap bakiyesi yalnızca son tutar olarak değil:

Hesap açıldı
Para yatırıldı
Ödeme yapıldı
İade gerçekleşti

olayları şeklinde saklanabilir.

Bu olaylar yeniden işlenerek güncel durum oluşturulabilir.

Avantajları:

Ayrıntılı işlem geçmişi
Denetlenebilirlik
Geçmiş durumu yeniden oluşturma
Olay tabanlı entegrasyon

sağlayabilir.

Dezavantajları:

Veri modeli karmaşıklaşabilir.
Olay sürümleme gerekebilir.
Hata düzeltme zorlaşabilir.
Depolama ihtiyacı artabilir.

Nihai Tutarlılık Nedir?

Microservice mimarisinde bütün servislerin aynı anda tamamen güncel olması her zaman mümkün olmayabilir.

Nihai tutarlılık, sistemdeki verilerin belirli bir süre sonra tutarlı hâle gelmesini ifade eder.

Örneğin sipariş tamamlandığı anda:

Sipariş servisi durumu kaydedebilir.
Analitik raporu birkaç saniye sonra güncellenebilir.
Bildirim servisi daha sonra e-posta gönderebilir.

Her işlem için güçlü tutarlılık gerekmez. Finansal ve kritik işlemlerde ise daha sıkı kurallar uygulanmalıdır.

Container Nedir?

Container, bir uygulamanın kodunu ve bağımlılıklarını taşınabilir bir paket içerisinde çalıştırmayı sağlayan teknolojidir.

Container içerisinde:

Uygulama kodu
Çalışma zamanı
Kütüphaneler
Yapılandırma bağımlılıkları

bulunabilir.

Container sayesinde uygulama geliştirme, test ve üretim ortamlarında daha tutarlı biçimde çalıştırılabilir.

Microservice ile Container Aynı Şey mi?

Hayır. Microservice bir yazılım mimarisi, container ise uygulamaları paketleme ve çalıştırma yöntemidir.

Kriter	Microservice	Container
Türü	Mimari yaklaşım	Çalıştırma teknolojisi
Amacı	Uygulamayı bağımsız servislere ayırmak	Uygulamayı taşınabilir paket hâline getirmek
Zorunluluk	Container olmadan kullanılabilir	Monolitik uygulama da çalıştırabilir
Odak	İş yetenekleri ve servis sınırları	Çalışma ortamı ve bağımlılıklar

Mikroservisler:

Container
Sanal makine
Fiziksel sunucu
Serverless platform

üzerinde çalıştırılabilir.

Container kullanımı yaygındır ancak microservice mimarisi için zorunlu değildir.

Uygulamaların barındırıldığı altyapının temel yapısını öğrenmek için hosting nedir rehberi incelenebilir.

Kubernetes Nedir?

Kubernetes, container tabanlı uygulamaların dağıtılması, ölçeklendirilmesi ve yönetilmesi için kullanılan orkestrasyon platformudur.

Kubernetes:

Container’ları çalıştırabilir.
Hatalı container’ları yeniden başlatabilir.
Trafiği dağıtabilir.
Servis keşfi sağlayabilir.
Otomatik ölçeklendirme yapabilir.
Güncellemeleri aşamalı gerçekleştirebilir.
Gizli bilgileri yönetebilir.

Kubernetes kullanmak bir uygulamayı otomatik olarak microservice yapmaz. Monolitik uygulamalar da Kubernetes üzerinde çalıştırılabilir.

Küçük projelerde Kubernetes’in operasyon maliyeti sağladığı faydadan daha yüksek olabilir.

Serverless ile Microservice Arasındaki Fark

Serverless, geliştiricinin doğrudan sunucu yönetmeden fonksiyon veya uygulama çalıştırmasını sağlayan bulut hizmet modelidir.

Microservice bir mimari yaklaşım, serverless ise çalıştırma modelidir.

Mikroservisler serverless fonksiyonlar olarak uygulanabilir.

Kriter	Microservice	Serverless
Tanım	Servis tabanlı mimari	Altyapı yönetimini sağlayıcıya bırakan model
Çalıştırma	Container, VM veya serverless	Yönetilen platform
Ölçeklendirme	Platforma göre yönetilir	Genellikle otomatik
Ücretlendirme	Ayrılan kaynağa göre olabilir	Kullanım veya çağrı bazlı olabilir
Kontrol	Daha yüksek olabilir	Platform sınırlamaları bulunabilir

SOA ile Microservice Arasındaki Fark

SOA, yani servis odaklı mimari, uygulama yeteneklerinin yeniden kullanılabilir servisler olarak sunulmasını amaçlar.

Microservice mimarisi, SOA ile benzer ilkeler taşısa da daha küçük, bağımsız ve merkezi olmayan servis yapısına odaklanır.

Kriter	SOA	Microservice
Servis boyutu	Daha geniş olabilir	Belirli iş yeteneğine odaklanır
İletişim	Merkezi servis veri yolu kullanılabilir	Hafif API ve mesajlaşma
Veri yönetimi	Ortak veri modeli olabilir	Servis bazlı veri sahipliği
Dağıtım	Birbirine bağlı olabilir	Bağımsız dağıtım hedeflenir
Yönetim	Merkezi yaklaşım	Merkezi olmayan ekipler
Teknoloji	Kurumsal standartlar baskın olabilir	Servis bazlı seçim yapılabilir

Microservice Mimarisinin Avantajları

Bağımsız Geliştirme

Farklı ekipler ayrı servisler üzerinde çalışabilir.

Örneğin:

Ödeme ekibi ödeme servisini
Sipariş ekibi sipariş servisini
Arama ekibi arama servisini

geliştirebilir.

Hızlı Dağıtım

Küçük değişiklikler uygulamanın tamamı yerine yalnızca ilgili servis üzerinden yayımlanabilir.

Bu durum dağıtım süresini kısaltabilir ve değişiklik riskini azaltabilir.

Esnek Ölçeklendirme

Yoğun kullanılan servisler bağımsız ölçeklendirilebilir.

Kaynakların bütün uygulamaya eşit dağıtılması gerekmez.

Teknoloji Esnekliği

Her iş alanı için uygun programlama dili, framework veya veri tabanı kullanılabilir.

Ancak teknoloji çeşitliliğinin ekip kapasitesiyle uyumlu olması gerekir.

Hata Yalıtımı

Bir servisteki hata, doğru dayanıklılık tasarımıyla diğer servislerden izole edilebilir.

Ekip Bağımsızlığı

Ekipler kendi servislerinin:

Kodundan
Testlerinden
Dağıtımından
İzlenmesinden
Operasyonundan

sorumlu olabilir.

Büyük Uygulamaların Yönetimi

İş alanlarına göre ayrılan servisler, büyük uygulamaların daha anlaşılır bölümlere ayrılmasını sağlayabilir.

Microservice Mimarisinin Dezavantajları

Dağıtık Sistem Karmaşıklığı

Tek uygulama yerine çok sayıda ağ bağlantılı servis yönetilir.

Aşağıdaki sorunlar ortaya çıkabilir:

Ağ gecikmesi
Paket kaybı
Servis kesintisi
Zaman aşımı
Mesaj tekrarı
Veri tutarsızlığı

Operasyon Maliyeti

Her servis için:

Dağıtım
İzleme
Loglama
Güvenlik
Sürüm
Altyapı

yönetimi gerekebilir.

Veri Tutarlılığı

Farklı veri tabanlarındaki işlemlerin aynı anda tutarlı tutulması monolitik sisteme göre daha zordur.

Test Karmaşıklığı

Bir servisin tek başına çalışması yeterli değildir. Servisler arasındaki sözleşmeler ve entegrasyonlar da test edilmelidir.

Hata Ayıklama

Bir kullanıcı işlemi çok sayıda servisten geçtiğinde hatanın kaynağını bulmak zorlaşabilir.

Ağ Maliyeti

Monolitik uygulamadaki süreç içi fonksiyon çağrıları, microservice sisteminde ağ çağrılarına dönüşür.

Bu durum:

Gecikme
Bant genişliği
Güvenlik
Hata yönetimi

gereksinimlerini artırır.

Nitelikli Ekip İhtiyacı

Microservice mimarisi:

DevOps
Bulut
Container
Dağıtık sistem
Güvenlik
Gözlemlenebilirlik

konularında yetkinlik gerektirir.

Microservice Mimarisi Ne Zaman Kullanılmalıdır?

Microservice yaklaşımı şu durumlarda değerlendirilebilir:

Uygulama kapsamı büyükse
Birden fazla bağımsız ekip çalışıyorsa
Servislerin trafik ihtiyaçları farklıysa
Sık ve bağımsız dağıtım gerekiyorsa
Yüksek erişilebilirlik önemliyse
İş alanları açık biçimde ayrılabiliyorsa
Güçlü DevOps altyapısı bulunuyorsa
Uygulama uzun vadede büyüyecekse
Farklı teknoloji ihtiyaçları bulunuyorsa

Microservice Mimarisi Ne Zaman Kullanılmamalıdır?

Aşağıdaki durumlarda monolitik veya modüler monolit daha uygun olabilir:

Proje küçükse
Ürün fikri henüz doğrulanmamışsa
Ekip birkaç kişiden oluşuyorsa
İş alanı sınırları belirgin değilse
DevOps deneyimi bulunmuyorsa
Trafik ve ölçek ihtiyacı düşükse
Uygulama kısa süreli kullanılacaksa
Operasyon bütçesi sınırlıysa

Başlangıçta microservice kullanmak her zaman geleceğe yatırım anlamına gelmez. Gereksiz dağıtık sistem karmaşıklığı ürün geliştirme hızını azaltabilir.

Modüler Monolit Nedir?

Modüler monolit, tek bir uygulama olarak dağıtılan ancak kod içerisinde iş alanlarına göre güçlü modüllere ayrılan mimaridir.

Örneğin:

Kullanıcı modülü
Ürün modülü
Sipariş modülü
Ödeme modülü

aynı uygulama içerisinde bulunur ancak birbirinden açık sınırlarla ayrılır.

Modüler monolit:

Microservice’e göre daha kolay işletilebilir.
Tek dağıtım birimine sahiptir.
Servisler arası ağ gecikmesi oluşturmaz.
Gelecekte microservice’e ayrılmayı kolaylaştırabilir.

Birçok yeni proje için önce modüler monolit tasarlamak, sistem büyüdükçe gerekli modülleri servislere ayırmak daha dengeli bir yaklaşım olabilir.

Microservice Mimarisinde Servis Sınırları Nasıl Belirlenir?

Servis sınırlarının doğru belirlenmesi mimarinin başarısını doğrudan etkiler.

Servisler:

Teknik katmanlara göre değil
İş yeteneklerine göre

ayrılmalıdır.

Zayıf ayrım örneği:

Veri tabanı servisi
İş mantığı servisi
Doğrulama servisi

Bu servisler her işlemde birbirine bağımlı olabilir.

Daha uygun ayrım:

Sipariş yönetimi
Ödeme yönetimi
Stok yönetimi
Kargo yönetimi

Her servis uçtan uca belirli bir iş yeteneğini yerine getirir.

Domain-Driven Design ve Bounded Context

Domain-Driven Design, karmaşık iş alanlarının iş kuralları ve kavramlar üzerinden modellenmesini sağlayan yaklaşımdır.

Bounded context, belirli bir iş modelinin ve kavramların geçerli olduğu açık sınırı ifade eder.

Örneğin “müşteri” kavramı:

Satış sisteminde potansiyel alıcı
Faturalama sisteminde borçlu
Destek sisteminde talep sahibi

anlamına gelebilir.

Her alan kendi müşteri modelini kullanabilir.

Servis sınırlarını bounded context’lere göre belirlemek, gereksiz bağımlılıkları azaltabilir.

Microservice Mimarisinde Güvenlik

Microservice yapısında güvenlik yalnızca dışarıdan gelen trafiği korumakla sınırlı değildir. Servisler arası iletişim de güvenli olmalıdır.

Kontrol edilmesi gerekenler:

Kimlik doğrulama
Yetkilendirme
API güvenliği
Servisler arası şifreleme
Gizli bilgi yönetimi
Trafik sınırlama
Güvenlik duvarı
Loglama
Veri şifreleme
Güvenlik güncellemeleri
Container imaj taraması
Bağımlılık kontrolleri

Zero Trust Yaklaşımı

Zero Trust yaklaşımında hiçbir kullanıcı, cihaz veya servis yalnızca ağ içerisinde bulunduğu için güvenilir kabul edilmez.

Her istek için:

Kimlik
Yetki
Cihaz
Bağlam
Erişim kapsamı

kontrol edilebilir.

Servisler arası karşılıklı TLS kullanılarak her iki tarafın kimliği doğrulanabilir.

API Güvenliği

API’lerde şu önlemler alınabilir:

Token tabanlı kimlik doğrulama
Yetki kapsamları
Rate limiting
Giriş doğrulama
İstek boyutu sınırı
Güvenli hata mesajları
API sürümleme
Şüpheli trafik tespiti

API Gateway ortak güvenlik politikalarının uygulanmasını kolaylaştırabilir.

Microservice Mimarisinde Test Türleri

Birim Testleri

Servis içerisindeki fonksiyon ve sınıfları izole biçimde test eder.

Entegrasyon Testleri

Servisin:

Veri tabanı
Mesaj kuyruğu
Harici API
Önbellek

gibi bileşenlerle çalışmasını kontrol eder.

Contract Testleri

Servislerin birbirinden beklediği API sözleşmelerini test eder.

Bir servis yanıt biçimini değiştirdiğinde tüketici servislerin bozulup bozulmayacağı belirlenebilir.

Uçtan Uca Testler

Kullanıcı işleminin bütün servisler üzerinden doğru ilerleyip ilerlemediğini kontrol eder.

Uçtan uca testler değerlidir ancak yavaş ve kırılgan olabilir. Bütün test stratejisi yalnızca uçtan uca testlere dayandırılmamalıdır.

Yük Testleri

Servislerin yüksek trafik altındaki:

Yanıt süresi
Kaynak tüketimi
Hata oranı
Ölçeklenme davranışı

ölçülür.

Dayanıklılık Testleri

Servis kesintisi, ağ gecikmesi veya veri tabanı hatası gibi durumlarda sistemin davranışı test edilir.

Microservice Mimarisinde Gözlemlenebilirlik

Observability, sistemin dış çıktılarından iç durumunun anlaşılabilmesini ifade eder.

Üç temel bileşeni bulunur:

Loglar
Metrikler
İzler

Loglar

Serviste gerçekleşen olayların ayrıntılarını gösterir.

Metrikler

Sayısal performans verileridir:

İstek sayısı
Hata oranı
Yanıt süresi
CPU kullanımı
Bellek kullanımı
Kuyruk uzunluğu

Distributed Tracing

Bir isteğin farklı servislerden geçişini takip eder.

Her isteğe benzersiz bir kimlik verilerek zincirin hangi bölümünde gecikme veya hata oluştuğu belirlenebilir.

Microservice Mimarisinde Performans

Microservice mimarisi otomatik olarak daha hızlı bir uygulama oluşturmaz.

Servisler arasındaki ağ çağrıları gecikme ekleyebilir.

Performansı geliştirmek için:

Gereksiz servis çağrıları azaltılmalı
Uygun önbellek kullanılmalı
Yanıt boyutları küçültülmeli
Asenkron işlemler tercih edilmeli
Veri sorguları optimize edilmeli
Timeout değerleri belirlenmeli
Yoğun servisler ayrı ölçeklendirilmeli
API Gateway darboğazı izlenmelidir

Web uygulamasının kullanıcıya yansıyan hızını ölçmek için Google PageSpeed Insights kullanılabilir.

Microservice Mimarisinin SEO’ya Etkisi

Microservice mimarisi doğrudan bir arama motoru sıralama faktörü değildir.

Ancak uygulamanın:

Sayfa hızı
Kullanılabilirliği
Kesinti oranı
Sunucu yanıt süresi
HTML oluşturma biçimi
URL yapısı
JavaScript işleme süreci

üzerinde etkili olabilir.

SEO açısından dikkat edilmesi gerekenler:

Arama motorlarına eksiksiz HTML sunulması
Sayfaların hızlı açılması
URL’lerin tutarlı kalması
Yönlendirmelerin doğru yapılması
Canonical etiketlerinin korunması
Hata durumlarında doğru HTTP kodlarının dönmesi
Site haritalarının güncel tutulması
JavaScript bağımlılığının kontrol edilmesi

Microservice’e geçiş sırasında URL’lerin veya sayfa oluşturma sisteminin değişmesi organik performansı etkileyebilir.

Bu nedenle mimari değişikliklerde teknik SEO gereksinimleri geliştirme sürecine dâhil edilmelidir.

E-Ticaret Microservice Örneği

Bir e-ticaret sistemi şu mikroservislerden oluşabilir:

Servis	Sorumluluk
Kullanıcı servisi	Üyelik ve kullanıcı bilgileri
Kimlik servisi	Giriş ve yetkilendirme
Ürün servisi	Ürün bilgileri
Arama servisi	Ürün arama ve filtreleme
Stok servisi	Stok miktarları
Sepet servisi	Kullanıcı sepetleri
Sipariş servisi	Sipariş oluşturma ve durum
Ödeme servisi	Tahsilat ve iade
Kargo servisi	Gönderi ve takip
Bildirim servisi	E-posta ve SMS
Kampanya servisi	Kupon ve indirim
Analitik servisi	Raporlama ve olay analizi

Kullanıcı sipariş verdiğinde farklı servisler ortak bir iş akışı içerisinde çalışır.

E-ticaret uygulamasının kullanıcı arayüzü ve satış altyapısı planlanırken e-ticaret web sitesi nasıl kurulur rehberinden yararlanılabilir.

Microservice Mimarisi Geçiş Süreci

Monolitik bir uygulamanın tek seferde tamamen microservice’e dönüştürülmesi yüksek risk oluşturabilir.

Aşamalı geçiş daha kontrollü olabilir.

Mevcut Sistemi Analiz Edin

Kod bağımlılıkları
Veri tabanı tabloları
İş alanları
Trafik yoğunluğu
Sık değişen bölümler
Hata kaynakları
Ekip sorumlulukları

incelenmelidir.

İş Alanlarını Belirleyin

Uygulama teknik katmanlara değil, iş yeteneklerine göre bölümlere ayrılmalıdır.

Öncelikli Servisi Seçin

İlk ayrılacak servis:

Sınırları açık
Diğer alanlardan görece bağımsız
Sık değişen
Ayrı ölçek ihtiyacı bulunan

bir bölüm olabilir.

Strangler Pattern Uygulayın

Strangler pattern, monolitik uygulamanın belirli özelliklerinin aşamalı biçimde yeni servislere taşınmasını ifade eder.

Yeni istekler yönlendirme katmanı üzerinden ilgili microservice’e gönderilir. Eski monolit zaman içinde küçültülür.

Veri Sahipliğini Ayırın

Yeni servisin hangi verilerden sorumlu olduğu belirlenir.

Doğrudan ortak tablo kullanımından servis kontrollü veri erişimine aşamalı geçiş yapılabilir.

İzleme Altyapısını Kurun

Servis sayısı artmadan önce:

Merkezi log
Metrik
İzleme
Alarm
Dağıtık tracing

altyapısı hazırlanmalıdır.

CI/CD Oluşturun

Her servisin güvenli ve tekrar edilebilir biçimde yayımlanması sağlanmalıdır.

Geçiş Sonuçlarını Ölçün

Geçişin:

Dağıtım sıklığı
Hata oranı
Yanıt süresi
Geliştirme süresi
Altyapı maliyeti
Ekip verimliliği

üzerindeki etkisi ölçülmelidir.

Microservice Geçiş Yol Haritası

Aşama	Yapılması gereken
Analiz	Monolitik sistemin bağımlılıklarını belirlemek
Alan modelleme	İş yeteneklerini ve sınırları tanımlamak
Öncelik	İlk ayrılacak servisi seçmek
API tasarımı	Servis sözleşmelerini hazırlamak
Veri ayrımı	Veri sahipliğini belirlemek
Altyapı	CI/CD, loglama ve izleme kurmak
Pilot	İlk servisi üretime almak
Ölçüm	Teknik ve operasyonel sonuçları takip etmek
Yaygınlaştırma	Uygun modülleri aşamalı ayırmak

Microservice Mimarisinde Yapılan Hatalar

Küçük projeyi gereksiz yere servislere bölmek
Servis sınırlarını teknik katmanlara göre belirlemek
Çok fazla küçük servis oluşturmak
Bütün servislerin aynı veri tabanını doğrudan kullanması
Her işlemde uzun senkron çağrı zinciri kurmak
API sözleşmelerini sürümlememek
Merkezi loglama oluşturmamak
Distributed tracing kullanmamak
Hata senaryolarını test etmemek
Timeout belirlememek
Sınırsız yeniden deneme yapmak
Güvenliği yalnızca API Gateway’e bırakmak
Her servis için farklı teknoloji seçmek
CI/CD olmadan servis sayısını artırmak
Ekip sorumluluklarını belirlememek
Monolitik uygulamayı tek seferde dönüştürmek
Operasyon maliyetini hesaplamamak
Container kullanmayı microservice sanmak
Kubernetes’i her proje için zorunlu görmek
Kullanıcı deneyimi ve SEO etkisini değerlendirmemek

Microservice ve Monolitik Mimari Seçim Tablosu

Proje durumu	Önerilebilecek yaklaşım
Yeni ve küçük ürün	Monolitik veya modüler monolit
Ürün fikri henüz doğrulanmadı	Basit monolit
Küçük geliştirme ekibi	Modüler monolit
Birden fazla bağımsız ekip	Microservice değerlendirilebilir
Servislerin trafik ihtiyacı farklı	Microservice avantaj sağlayabilir
Sık bağımsız dağıtım gerekiyor	Microservice uygun olabilir
DevOps altyapısı bulunmuyor	Önce operasyon kabiliyeti geliştirilmelidir
Büyük ve karmaşık iş alanı	Domain analiziyle microservice değerlendirilebilir
Düşük trafik ve sabit ürün	Monolitik yapı yeterli olabilir

Microservice Mimarisi Kontrol Listesi

Mimari Tasarım

Uygulamanın iş alanları belirlendi mi?
Servis sınırları açık mı?
Her servis tek bir iş yeteneğine odaklanıyor mu?
Servislerin bağımsız dağıtılması mümkün mü?
Servis sahipleri belirlendi mi?
API sözleşmeleri hazır mı?
Sürümleme stratejisi oluşturuldu mu?
Senkron ve asenkron iletişim ayrıldı mı?
Hata senaryoları tasarlandı mı?
Dağıtık monolit riski değerlendirildi mi?

Veri Yönetimi

Her verinin sahibi olan servis belli mi?
Servisler birbirinin veri tabanına doğrudan erişiyor mu?
Veri tutarlılığı gereksinimleri belirlendi mi?
Dağıtık işlemler planlandı mı?
Saga gerekli mi?
Veri tekrarları yönetiliyor mu?
Raporlama yapısı hazır mı?
Yedekleme planı oluşturuldu mu?
Veri geçişi test edildi mi?

Altyapı ve Dağıtım

Her servis için CI/CD bulunuyor mu?
Container kullanımı gerekli mi?
Orkestrasyon platformu belirlendi mi?
Service discovery çalışıyor mu?
Load balancing hazır mı?
Yapılandırmalar dışarıdan yönetiliyor mu?
Gizli bilgiler güvenli saklanıyor mu?
Otomatik ölçeklendirme kuralları hazır mı?
Geri alma planı bulunuyor mu?
Canary veya blue-green dağıtım değerlendirildi mi?

Dayanıklılık

Timeout değerleri belirlendi mi?
Yeniden deneme kuralları sınırlı mı?
Circuit breaker kullanılıyor mu?
İdempotent işlemler tasarlandı mı?
Mesaj tekrarları yönetiliyor mu?
Servis kesintisi senaryoları test edildi mi?
Kritik olmayan servisler için yedek cevap var mı?
Kuyruk dolulukları izleniyor mu?
Hatalı mesaj kuyruğu bulunuyor mu?

Güvenlik

Kimlik doğrulama merkezi mi?
Yetkilendirme servis bazında uygulanıyor mu?
Servisler arası trafik şifreli mi?
API rate limiting bulunuyor mu?
Gizli bilgiler koddan ayrıldı mı?
Container imajları taranıyor mu?
Bağımlılıklar güncel mi?
Güvenlik olayları loglanıyor mu?
En az yetki ilkesi uygulanıyor mu?

İzleme ve Operasyon

Merkezi loglama çalışıyor mu?
Metrikler toplanıyor mu?
Distributed tracing aktif mi?
Servis sağlık kontrolleri bulunuyor mu?
Hata oranları izleniyor mu?
Yanıt süreleri takip ediliyor mu?
Alarmlar tanımlandı mı?
Olay müdahale planı hazır mı?
Servis sahipleri belli mi?
Altyapı maliyetleri ölçülüyor mu?

Microservice Mimarisi Hakkında Sıkça Sorulan Sorular

Microservice mimarisi nedir?

Büyük bir uygulamanın belirli iş yeteneklerine odaklanan küçük ve bağımsız servislere ayrıldığı yazılım mimarisidir.

Mikroservis ne işe yarar?

Uygulamanın farklı bölümlerinin bağımsız geliştirilmesini, dağıtılmasını ve ölçeklendirilmesini sağlayabilir.

Monolitik mimari nedir?

Uygulamanın temel bileşenlerinin tek bir uygulama paketi içerisinde geliştirildiği mimaridir.

Microservice ile monolitik mimari arasındaki fark nedir?

Monolitik uygulama tek birim olarak dağıtılır. Microservice yapısında servisler bağımsız olarak dağıtılabilir.

Microservice mimarisi her proje için uygun mudur?

Hayır. Küçük projelerde ve sınırlı ekiplerde gereksiz teknik ve operasyonel karmaşıklık oluşturabilir.

Microservice için container zorunlu mu?

Hayır. Container kullanımı yaygındır ancak mikroservisler sanal makine, fiziksel sunucu veya serverless platformlarda da çalışabilir.

Docker ile microservice aynı şey mi?

Hayır. Docker bir container teknolojisidir; microservice ise yazılım mimarisi yaklaşımıdır.

Kubernetes microservice midir?

Hayır. Kubernetes container uygulamalarını yöneten orkestrasyon platformudur.

Microservice mimarisinde her servisin ayrı veri tabanı mı olmalıdır?

Genel yaklaşım her servisin kendi verisinden sorumlu olmasıdır. Fiziksel olarak tamamen ayrı veri tabanı zorunluluğu proje koşullarına göre değerlendirilebilir.

Servisler birbiriyle nasıl iletişim kurar?

REST, gRPC, mesaj kuyruğu veya olay tabanlı sistemler üzerinden iletişim kurabilir.

API Gateway ne işe yarar?

İstemciler için ortak giriş noktası oluşturur; yönlendirme, güvenlik ve trafik yönetimi yapabilir.

Service discovery nedir?

Servislerin iletişim kuracağı diğer servislerin güncel ağ adreslerini bulmasını sağlayan mekanizmadır.

Service mesh nedir?

Servisler arası ağ iletişimini güvenlik, izleme ve trafik yönetimi açısından yöneten altyapı katmanıdır.

Saga pattern nedir?

Birden fazla servisi kapsayan işlemleri yerel adımlara ve gerektiğinde telafi işlemlerine ayıran tasarım yaklaşımıdır.

CQRS nedir?

Veriyi değiştiren komutlarla veriyi okuyan sorguların ayrı modellerde yönetilmesini sağlayan yaklaşımdır.

Event sourcing nedir?

Sistemin durumunu yalnızca son değer olarak değil, gerçekleşen olayların sırası şeklinde saklayan yöntemdir.

Nihai tutarlılık nedir?

Dağıtık verilerin anında değil, belirli bir süre sonunda tutarlı hâle gelmesidir.

Microservice mimarisi daha hızlı mıdır?

Otomatik olarak daha hızlı değildir. Ağ çağrıları gecikme oluşturabilir. Doğru ölçeklendirme ve optimizasyonla performans avantajı sağlanabilir.

Microservice mimarisi daha güvenli midir?

Doğru tasarlanırsa güvenlik sınırları oluşturabilir. Ancak servis ve API sayısının artması saldırı yüzeyini de genişletebilir.

Microservice mimarisi maliyetli midir?

Altyapı, izleme, DevOps ve operasyon gereksinimleri nedeniyle başlangıç ve işletme maliyeti monolitik yapıya göre daha yüksek olabilir.

Microservice SEO’yu etkiler mi?

Doğrudan sıralama faktörü değildir. Sayfa hızı, kesintiler, URL yapısı ve HTML oluşturma süreçleri üzerinden dolaylı etki oluşturabilir.

Microservice’e nasıl geçilir?

Mevcut sistem analiz edilir, iş alanları belirlenir ve uygun modüller aşamalı olarak bağımsız servislere taşınır.

Strangler pattern nedir?

Monolitik uygulamanın özelliklerinin aşamalı olarak yeni servislere taşındığı geçiş yöntemidir.

Modüler monolit nedir?

Tek uygulama olarak dağıtılan ancak kod içerisinde bağımsız iş modüllerine ayrılan mimaridir.

Microservice ile SOA aynı mı?

Hayır. Benzer servis ilkeleri taşısalar da microservice daha bağımsız, küçük ve merkezi olmayan servis yapısına odaklanır.

Microservice ekipleri nasıl çalışmalıdır?

Her ekip sorumlu olduğu servisin geliştirme, test, dağıtım ve operasyon süreçlerini uçtan uca yönetebilir.

Microservice mimarisi hangi uygulamalarda kullanılır?

E-ticaret, finans, medya, lojistik, SaaS, haberleşme ve yüksek ölçekli kurumsal uygulamalarda kullanılabilir.

Doğru Mimariyi Projenin Gerçek İhtiyaçlarına Göre Belirleyin

Microservice mimarisi, büyük ve karmaşık yazılım sistemlerinin bağımsız iş yeteneklerine odaklanan servislere ayrılmasını sağlayan güçlü bir mimari yaklaşımdır.

Bu yapının temel özellikleri:

Bağımsız servisler
Ayrı dağıtım süreçleri
Servis bazlı ölçeklendirme
API ve olay tabanlı iletişim
Servis kontrollü veri yönetimi
Ekip bağımsızlığı
Hata yalıtımı

olarak sıralanabilir.

Microservice mimarisi doğru uygulandığında:

Geliştirme ekiplerinin daha bağımsız çalışmasını
Yeni sürümlerin daha hızlı yayımlanmasını
Yoğun servislerin ayrı ölçeklendirilmesini
Farklı teknolojilerin ihtiyaç doğrultusunda kullanılmasını
Hataların belirli servislerde sınırlandırılmasını

sağlayabilir.

Bununla birlikte bu yaklaşım:

Dağıtık veri yönetimi
Ağ gecikmeleri
Servis güvenliği
Merkezi loglama
Dağıtık izleme
CI/CD
DevOps
Container orkestrasyonu

gibi ek gereksinimler oluşturur.

Bu nedenle microservice mimarisi yalnızca popüler olduğu için tercih edilmemelidir.

Küçük bir ekip tarafından geliştirilen, düşük trafik alan ve iş sınırları henüz net olmayan bir uygulamada modüler monolit daha verimli olabilir. Uygulama ve ekip büyüdükçe ihtiyaç duyulan modüller aşamalı olarak bağımsız servislere ayrılabilir.

Mimari karar verilirken şu sorular cevaplanmalıdır:

Uygulama gerçekten bağımsız ölçeklendirmeye ihtiyaç duyuyor mu?
Servis sınırları açık biçimde belirlenebiliyor mu?
Ekipler bağımsız çalışabilecek büyüklükte mi?
CI/CD ve izleme altyapısı bulunuyor mu?
Dağıtık sistemlerin operasyon maliyeti karşılanabilir mi?
Microservice yaklaşımı ölçülebilir bir iş faydası sağlayacak mı?

En iyi mimari en fazla teknoloji içeren yapı değildir. Projenin büyüklüğüne, ekip kapasitesine, trafik ihtiyacına ve ticari hedeflerine en uygun yapıdır.

Kullanıcıların farklı cihazlardan erişebileceği modern uygulama arayüzleri oluşturmak için responsive web tasarım ilkeleri uygulanabilir.

Web uygulaması, yazılım altyapısı ve kullanıcı deneyiminin birlikte planlanması için profesyonel web tasarım çalışmaları yürütülebilir.