Mikroservis Mimarisi Nedir? Monolitten Dağıtık Sistemlere

Mikroservis mimarisi, bir uygulamayı tek ve bütün bir parça olarak değil, birbirinden bağımsız çalışan küçük servislerin bir araya gelmesiyle kuran bir yazılım tasarım yaklaşımıdır. Her servis belirli bir iş yeteneğinden sorumludur, kendi başına geliştirilip dağıtılabilir ve diğerleriyle ağ üzerinden (genellikle API'ler aracılığıyla) haberleşir. Bu yaklaşım, büyük ve karmaşık sistemlerde esneklik ve ölçeklenebilirlik kazanmak için öne çıktı.

Mikroservisi anlamak için karşıtı olan monolit (monolith) mimariyi bilmek gerekir.

Monolit ve mikroservis

Monolit mimaride uygulamanın tüm işlevleri — kullanıcı yönetimi, ödeme, bildirim, raporlama — tek bir kod tabanında ve tek bir dağıtılabilir birimde toplanır. Bu, küçük uygulamalar için basit ve verimlidir. Ancak uygulama ve ekip büyüdükçe sorunlar başlar: Küçük bir değişiklik için tüm uygulamayı yeniden yayınlamak gerekir, bir bileşenin hatası tüm sistemi çökertebilir ve yalnızca bir kısmı yoğunlaştığında bile her şeyi birlikte ölçeklemek zorunda kalırsınız.

Mikroservis mimaride her iş yeteneği ayrı bir servise bölünür. Ödeme servisi çökse bile ürün listeleme çalışmaya devam edebilir; yalnızca yük altındaki servisi büyütebilirsiniz; her ekip kendi servisini bağımsızca geliştirip yayınlayabilir.

Temel ilkeler

• Tek sorumluluk: Her servis iyi tanımlı tek bir işe odaklanır.
• Bağımsız dağıtım: Bir servis, diğerlerini etkilemeden ayrı ayrı yayınlanabilir ve güncellenebilir.
• Merkezi olmayan veri: İdeal olarak her servisin kendi veritabanı vardır; servisler birbirinin verisine doğrudan değil, API üzerinden erişir. Bu, servislerin gerçekten bağımsız kalmasını sağlar.
• Ağ üzerinden iletişim: Servisler birbirleriyle genellikle HTTP/REST, gRPC ya da mesaj kuyrukları aracılığıyla konuşur.
• Teknoloji özgürlüğü: Her servis farklı bir programlama dili ya da veritabanı kullanabilir; önemli olan dışarıya sunduğu arayüzdür.

Bedeli: Dağıtık sistem karmaşıklığı

Mikroservisler sihirli bir çözüm değildir; bir karmaşıklık türünü başka bir türle değiştirir. Tek uygulamanın iç karmaşıklığını azaltırken, yerine dağıtık sistem karmaşıklığını getirir:

• Servisler arası ağ iletişimi yavaş olabilir ve başarısız olabilir; buna karşı dayanıklılık (retry, timeout, devre kesici) tasarlanmalıdır.
• Bir isteğin onlarca servis arasında nasıl dolaştığını izlemek (distributed tracing) ve hata ayıklamak zorlaşır.
• Birden fazla veritabanı arasında veri tutarlılığını sağlamak, tek veritabanına göre çok daha karmaşıktır.
• Dağıtım, izleme ve altyapı yönetimi için genellikle konteynerler ve Kubernetes gibi orkestrasyon araçları gerekir.

Ne zaman mikroservis, ne zaman monolit?

Yaygın ve sağlam bir tavsiye şudur: Çoğu proje monolit olarak başlamalıdır. Küçük bir ekip ve belirsiz gereksinimlerle işe mikroservislerle başlamak, henüz var olmayan bir ölçek sorununa erken ve pahalı bir çözümdür. Uygulama ve ekip gerçekten büyüdüğünde, sınırları netleşen parçalar tek tek servislere ayrılabilir.

Mikroservisler şu durumlarda değer kazanır: Büyük ve bağımsız ekipler, çok farklı ölçeklenme ihtiyaçları olan bileşenler ve yüksek erişilebilirlik gerektiren olgun sistemler.

Nereden öğrenmeli?

Kavramın en etkili kaynaklarından biri Martin Fowler'ın mikroservisler üzerine yazılarıdır; bu yazılar mimarinin tanımını, ilkelerini ve ödünleşimlerini net biçimde ortaya koyar. Amazon ve Microsoft gibi bulut sağlayıcılarının mimari rehberleri de dayanıklılık, iletişim desenleri ve veri yönetimi gibi pratik konularda somut örnekler sunar. En sağlıklı yol, önce monolit ve mikroservis ödünleşimlerini kavramak, ardından küçük bir sistemi parçalara ayırarak dağıtık iletişimi uygulamalı deneyimlemektir.