1960'lı ve 1970'li yıllarda, Monolitik mimari sınırlı bilişim kaynakları nedeniyle uygulama geliştirmede tercih ediliyordu; tüm işlevler tek bir bütünleşik yapıda bir araya getirilmek zorundaydı.
Ta ki 90'ların sonları ve 2000'lere kadar. Bu dönemde monolitik yapı, özellikle internetin ve dağıtık sistemlerin yükselişiyle birlikte sürekli büyüyen ve karmaşıklaşan uygulamalar için yetersiz kalmaya başladı.
Bu durum, daha modüler yaklaşımların geliştirilmesine zemin hazırladı: servis odaklı mimari (SOA) ve, daha sonra, mikro hizmet mimarisi (MSA)bu yaklaşımlar 2010'ların başında yaygınlık kazandı.
Bununla birlikte, bu yalnızca mikro hizmetlerin temel kavramına ve kullanımına kısa bir giriş niteliğindedir. Şimdi mikro hizmetlerin monolitik mimarinin yerini nasıl aldığını, nasıl çalıştığını ve bazı örneklerini ele alalım. Ardından mikro hizmet dağıtımının temel yönlerini ve mikro hizmet dağıtmak istiyorsanız ne yapmanız gerektiğini tartışacağız.
Mikro Hizmetler Nedir? Nasıl Çalışır?
Daha önce de belirttiğim gibi, mikro hizmetler artan uygulama karmaşıklığı ve boyutuna bir çözüm olarak ortaya çıktı; şirketlerin işlevleri bağımsız olarak dağıtılabilir servislere bölmesine olanak tanıdı.
"Mikro hizmetler" terimi, Martin Fowler ve James Lewis gibi sektör uzmanları tarafından popülerleştirildi. Bu isimler, kavramı 2014 yılında yayımladıkları bir blog yazısında resmi olarak tanıttı. Çalışmaları; bağımsız dağıtılabilir servisler, merkezi olmayan veri yönetimi ve teknoloji bağımsızlığı gibi temel ilke ve özellikleri tanımladı.
O günden bu yana mikro hizmetler, ana akım bir mimari tercih hâline geldi. Docker gibi konteynerleştirme teknolojileri, Kubernetes gibi orkestrasyon araçları ve sunucusuz bilişim platformlarındaki gelişmeler bu dönüşümü destekledi. Peki mikro hizmetler nasıl çalışır?
Mikro Hizmetler Nasıl Çalışır?
Mikro hizmet mimarisinin özünde, büyük bir uygulamayı her biri belirli bir iş işlevinden sorumlu olan daha küçük ve bağımsız servislere bölmek yatar. Bu servisler birbirleriyle ağ üzerinden iletişim kurar; bunun için genellikle REST API'ler, gRPC ya da RabbitMQ veya Apache Kafka gibi mesaj aracıları kullanılır.
Martin Fowler ve James Lewis'in tanımına göre, mikro hizmetlerin dört temel özelliği vardır:
- Tek Sorumluluk: Her mikro hizmet, belirli bir görevi veya işlevi yerine getirmek üzere tasarlanır; bu sayede uzmanlaşma sağlanır ve karmaşıklık azalır.
- Bağımsızlık: Mikro hizmetler birbirinden bağımsız olarak geliştirilebilir, dağıtılabilir ve ölçeklendirilebilir; bu da esneklik ve dayanıklılık sağlar.
- Merkezi Olmayan Veri Yönetimi: Mikroservisler genellikle kendi veritabanlarına sahiptir; tek bir merkezi veritabanına ihtiyaç duyulmaz.
- Teknoloji Tarafsızlığı: Ekipler, diğer servislerin teknoloji tercihlerine bağlı kalmadan her servis için en uygun teknolojiyi seçebilir.
Bu yaklaşım, tüm uygulama bileşenlerinin tek ve bütünleşik bir yapı içinde sıkıca birbirine bağlandığı geleneksel monolitik mimariden ayrışır.
Mikroservis Dağıtımının Temel Aşamaları
Mikroservis mimarisi yüksek ölçeklenebilirlik, esneklik, verimlilik ve hata yalıtımı gibi pek çok avantaj sunsa da başarılı bir dağıtım için mikroservislerin nasıl etkin biçimde kullanılacağını bilmek ve kapsamlı bir planlama yapmak gerekir.
Bu nedenle, başarılı bir mikroservis mimarisi için temel kavramları, aşamaları ve en iyi uygulamaları iyi kavramak şarttır. Mikroservis dağıtımının temel aşamalarını ve her aşamanın neleri kapsadığını birlikte inceleyelim.
Mikroservis Dağıtımını Planlama ve Hazırlık
Her başarılı süreç gibi mikroservis dağıtımı da dikkatli bir planlama ve sabır ister. Bu yüzden en iyi uygulamaları takip etmek ve dağıtım sürecinde ihtiyaç duyulan her şeyi önceden planlamak büyük önem taşır.
Daha önce belirttiğim gibi, mikroservislerin temel ilkelerinden biri Tek Sorumluluk İlkesi'dir. Her mikroservisin yalnızca tek bir işleve ve sorumluluğa odaklandığından emin olarak bu ilkeye sadık kalmak, ekibinizin servisleri bağımsız olarak geliştirmesine, dağıtmasına ve ölçeklendirmesine olanak tanır.
Bu ilkenin bir alt kategorisi ise gevşek bağlantı tasarım ilkesi'dir. Bu ilkeye göre her servis iletişim açısından bağımsız çalışabilir ve diğer servislere olan bağımlılığı en aza indirilmiştir. Böylece bir serviste yapılan değişiklik veya güncelleme diğer servisleri etkilemez ve servisler birbirinden bağımsız olarak ölçeklendirilebilir.
Bu yapı, sistemin bir bölümündeki sorunun zincirleme arızalara yol açarak tüm sistemi çökertme riskini azaltır.
Önemli bir mikroservis uygulaması olarak, gevşek bağlantı tasarım ilkesinin bir uzantısı şeklinde her servis için ayrı veri depolama alanı kullanmak, çakışmaları önler ve servis ölçeklendirmeyi kolaylaştırır.
Bunun yanı sıra, her servisin doğrudan bağımlılık olmaksızın iletişim kurabilmesi için mesaj aracıları gibi asenkron mikroservis iletişim kalıplarına ihtiyaç duyulur.
Planlamanın son halkası ise mikroservisler için Sürekli Entegrasyon ve Sürekli Teslimat (CI/CD) pipeline'larını hayata geçirmektir. Bu pipeline'lar ekiplerin yeni özellik veya düzeltmeleri şu yollarla dağıtmasını sağlar: CI/CD araçları Jenkins ve GitLab gibi seçenekler aracılığıyla, kuruluşlar sistem kararlılığını korurken yeni özellikleri düzenli olarak yayına alabilir.
Mikroservis dağıtımı için gerekli planlama ve hazırlık sürecine genel bir bakış attığımıza göre, şimdi dağıtım stratejilerinden söz edelim.
Mikroservis Dağıtım Stratejileri
Mikroservis dağıtımında strateji seçimi; servis işlevi, trafik yükü, altyapı yapılandırması, ekip uzmanlığı ve maliyet gibi faktörlere göre değişir. Yaygın olarak kullanılan mikroservis dağıtım stratejileri şunlardır:
- Container Başına Bir Servis Örneği: Bu yaklaşımda her mikroservis kendi container'ında çalışır. Böylece çok örnekli host modeline kıyasla daha iyi yalıtım sağlanır. Container'lar ölçeklendirmeyi kolaylaştırır ve kaynak tahsisini iyileştirir.
- Sanal Makine Başına Servis Örneği: Her servis ayrı bir sanal makinede (VM) çalışır; bu, container'lara kıyasla çok daha güçlü bir izolasyon sağlar. Güvenlik ve kararlılık açısından avantajlı olsa da genellikle daha fazla kaynak tüketimine yol açar.
- Aşamalı Yayınlar: Bu yaklaşımda, bir mikroservis sürümü tam dağıtımdan önce küçük bir kullanıcı grubuna sunulur ve kararlılığı test edilir. Olası sorunların etkisini en aza indirir ve sistem bütünlüğünü korumak için hızlı geri alma işlemine olanak tanır.
- Mavi-Yeşil Dağıtım: Bu yöntemde iki özdeş üretim ortamı kullanılır: biri canlı trafiği karşılarken diğeri bir sonraki sürümün testine ayrılır. Blue-green deployment, trafik iki ortam arasında kolayca geçiş yapılabildiğinden sıfır kesinti süresiyle güncelleme ve hızlı geri alma imkânı sunar.
- Aşamalı Yayınlar: Bu stratejide güncellemeler, farklı kullanıcı segmentlerine veya ortamlara kademeli olarak sunulur. Genellikle iç ortamlardan başlayıp üretim ortamına ulaşır; böylece olası sorunların etkisi sınırlandırılır ve ekipler sorunları aşama aşama çözebilir.
- Sunucusuz Dağıtım: Bu yaklaşım, altyapı yönetimini otomatikleştiren AWS Fargate ve Google Cloud Run gibi sunucusuz platformları kullanır; ölçeklendirme ve kaynak tahsisini platform üstlenir. Sunucusuz deployment ile alttaki sunucuları yönetme ihtiyacı ortadan kalkar ve odağınızı tamamen mikroservislerinize verebilirsiniz.
Yukarıdaki mikroservis deployment stratejilerinden birini seçtikten sonra bir mikroservis orkestrasyon aracına ihtiyaç duyacaksınız.
Mikrohizmetler Orkestrasyonu
Birçok mikroservis deployment stratejisi arasından birini seçtikten sonra, mikroservis orkestrasyonu için bir yönlendirici araca ihtiyacınız olacak. Aşağıdakiler gibi mikroservis orkestrasyon araçları Kubernetes, mikroservislerin deployment, ölçeklendirme, izleme ve container tabanlı yönetim süreçlerini otomatikleştirir.
Örneğin Airbnb, Kubernetes kullanarak mühendislerinin mikroservislerinde manuel denetim olmaksızın yüzlerce değişikliği yayına almasını sağlar. Kubernetes gibi mikroservis orkestrasyon araçlarının önemli bir özelliği de yerleşik yük dengeleme kapasitesidir.
Yük dengeleme özelliği, gelen trafiği bir mikroservisin birden fazla örneği arasında dağıtır. Bu sayede hiçbir örnek darboğaza dönüşmez ve sistem ani trafik artışlarını daha iyi karşılayabilir.
Kubernetes, başarısız container'ları otomatik olarak yeniden başlatıp değiştiren kendi kendini iyileştirme özellikleriyle mikroservis yönetiminde kritik bir rol oynar. New York Times, kullanıcı deneyimini etkilemeden ve kesinti yaşamadan mikroservislerini bu özellik sayesinde ayakta tutar.
Bunun yanı sıra Kubernetes, ConfigMaps ve Secrets aracılığıyla veritabanı kimlik bilgileri veya API anahtarları gibi yapılandırma bilgilerini ve sırları yöneterek mikroservis güvenliğini de artırır. Bu, Uber gibi hassas müşteri ve kullanıcı verisiyle çalışan şirketler için özellikle önemlidir.
Son olarak Kubernetes gibi mikroservis orkestrasyon araçları, kademeli sürümler gibi rolling update ve geri alma içeren stratejiler için özellikle değerlidir. Rolling update'ler, eski sürümün bazı örneklerini çalışır tutarak yeni mikroservis sürümlerinin servis kesintisi olmadan yayına alınmasını sağlar.
Mikroservis orkestrasyon aracınızı kurduktan sonra, mikroservis deployment için CI/CD boru hatları oluşturmanız ve otomatize etmeniz gerekecek.
Mikroservis Deployment için CI/CD Pipeline'ları
Daha önce de belirttiğimiz gibi, mikroservisler için Continuous Integration ve Continuous Delivery pipeline'ları, mikroservis deployment sürecinin temel bileşenleridir. CI/CD pipeline'larındaki CD aşaması, kod değişikliklerinin test ve entegrasyon aşamalarını geçer geçmez otomatik olarak üretime alınmasından sorumludur.
CI/CD pipeline'larının CD kısmı devreye girdiğinde, test ve entegrasyon aşamalarını geçen kod değişiklikleri otomatik olarak bir Kubernetes cluster'ı gibi mikroservis orkestrasyon aracına deploy edilir.
Ayrıca birim testleri, entegrasyon testleri ve uçtan uca testler pipeline'a dahil edildiğinden, test ve entegrasyon aşamalarının tamamı CI/CD pipeline'ları tarafından otomatik olarak yürütülür.
Bu, ekiplerin her aşamada güncellemeleri doğrularken sistem kararlılığını korumasına olanak tanır. Çeşitli testlere rağmen kod değişikliklerinde sorun çıkarsa, otomatik geri alma işlemleri önceki kararlı sürüme dönmeyi sağlar.
Mikroservis en iyi uygulamalarına uygun CI/CD pipeline'ları uygulamak, kuruluşların geliştirme süreçlerini hızlandırmasına, manuel hataları azaltmasına ve yüksek kalite standartlarını korumasına yardımcı olur.
Spotify, Expedia, iRobot, Lufthansa, Pandora gibi birçok şirket, deployment süreçlerini otomatize etmek, tutarlı kod kalitesi sağlamak ve sistem kararlılığını korurken yeni özellikleri hızla yayına almak için CircleCI, AWS CodePipeline ve GitLab gibi araçlarla mikroservislerine CI/CD pipeline'ları uygular.
Mikroservis İletişim Kalıpları
Mikroservislerin birbirleriyle nasıl iletişim kurduğu; işlevin, genel mimarinin, istenen ölçeklenebilirliğin ve mikroservislerin güvenilirliğinin doğrudan bir sonucudur. Genel olarak iki ana mikroservis iletişim kalıbı kullanılır: senkron ve asenkron mikroservis iletişim kalıpları.
Eşzamanlı mikroservis iletişim kalıplarında servisler gerçek zamanlı olarak etkileşime girer; yani bir servis istek gönderir ve devam etmeden önce yanıt bekler. En yaygın kullanılan eşzamanlı mikroservis iletişim kalıpları şunlardır: REST (Temsili Durum Aktarımı) API'leri, gRPC (Google Uzak Prosedür Çağrısı)ve GraphQL.
Bu tür mikroservis iletişim kalıpları genellikle gerçek zamanlı veri işleme ve anlık yanıt gerektiren sektörlerde ve şirketlerde tercih edilir. Finans, sağlık ve e-ticaret gibi sektörler; işlemlerin, veri alımının veya etkileşimlerin anında gerçekleşmesini sağlamak ve kullanıcıya akıcı, duyarlı bir deneyim sunmak için eşzamanlı iletişim kalıplarına başvurur.
Bununla birlikte, eşzamanlı mikroservis iletişim kalıpları gerçek zamanlı yanıt ve sadelik gibi avantajlar sunarken; sıkı bağlılıktan kaynaklanan olası darboğazlar, yüksek yük altında düşen ölçeklenebilirlik, yavaş yanıt süreleri ve yoğun trafik anlarında artan gecikme gibi dezavantajları da beraberinde getirir.
Öte yandan, eşzamansız mikroservis iletişim kalıpları, daha önce ele aldığımız Gevşek Bağlılık ilkesine dayandığından genellikle mikroservisler için daha uygun bir seçenektir.
Bu mikroservis iletişim kalıbı türü, servislerin Kafka veya RabbitMQ gibi bir broker aracılığıyla mesaj gönderip almasına olanak tanıyarak servisleri birbirinden ayırır. Servisler, tampon görevi gören bir kuyruğa mesaj göndererek eşzamanlı iletişimde olduğu gibi yanıt beklemek yerine birbirinden bağımsız biçimde iletişim kurar. Bu tampon sayesinde diğer servisler mesajları kendi hızlarında işleyebilir; gönderen servis ise alıcıyı beklemeksizin çalışmaya devam eder.
Eşzamansız mikroservis iletişim kalıbı, mikroservis dağıtımı için ayrık bir yapı sunmanın yanı sıra eşzamanlı mikroservis iletişim kalıplarının sağladığı gerçek zamanlı yanıt kapasitesini de destekler.
Bunun nedeni, eşzamansız olay güdümlü mikroservis iletişim kalıplarının olay güdümlü mimarisine dayanmasıdır. Bu mimaride servisler, belirli bir eylem gerçekleştiğinde olay yayarak iletişim kurar. Diğer servisler bu olaylara abone olarak uygun şekilde tepki verebilir. Bu sayede servisler arasında doğrudan bir bağlılık olmaksızın gerçek zamanlı değişikliklere hızla yanıt veren sistemler oluşturulabilir.
Ayrıca, asenkron içinde Yayın-Abone Ol (Pub/Sub) mikroservis iletişim kalıplarında servisler (yayıncılar) bir konuya mesaj gönderir, diğer servisler (aboneler) ise güncellemeleri almak için o konuyu dinler. Bu model birden fazla aboneyi destekler ve mesajları aynı anda birçok servise yayınlar.
Son olarak, olay güdümlü kalıplara benzer biçimde, eşzamansız koreografi tabanlı saga mikroservis iletişim kalıpları da birbirleriyle iletişim kurmak için olayları kullanır; ancak bu kalıpta belirli bir sıra söz konusudur; yani olaylar bir sonraki adımı ve devreye girecek servisi tetikler.
Buradaki fark şudur: olay güdümlü kalıplarda belirli bir sıra veya iş akışı yoktur ve birden fazla servis aynı olaya tepki verebilir. Koreografi tabanlı saga kalıbında ise belirli bir süreç ve sıra zorunludur.
Hangi eşzamansız mikroservis iletişim kalıbını kullanacağınız, mikroservislerinizin görevine ve genel işlevine bağlıdır. RabbitMQ ve Amazon SQS gibi mesaj kuyrukları genellikle görev zamanlama, iş yükü dağıtımı ve e-ticarette sipariş işleme ile bildirim sistemleri için tercih edilir.
Apache Kafka ve AWS EventBridge gibi olay güdümlü mesaj broker'ları, finansal hizmetler ve AWS ortamları gibi alanlarda gerçek zamanlı büyük ölçekli olay akışlarını işlemek ve mikroservisler arasında olay yönlendirmek amacıyla yaygın olarak kullanılır.
Google Cloud Pub/Sub ve Redis Streams gibi Publish-Subscribe (Pub/Sub) mesaj broker'larına gelince, bu broker'lar dağıtık sistemlerde gerçek zamanlı analitik, olay alımı ile gerçek zamanlı bildirimler ve sohbet uygulamaları için ölçeklenebilir mesajlaşma çözümleri olarak kullanılır.
Koreografi tabanlı saga mesaj broker'ları ise ağırlıklı olarak e-ticaret sipariş işleme, seyahat rezervasyon sistemleri ve merkezi bir kontrol olmaksızın birden fazla servis genelinde karmaşık, çok adımlı işlemlerin koordine edilmesi gereken senaryolar için tercih edilir.
Mikroservis Keşfi
İhtiyaçlarınıza uygun bir iletişim kalıbı kurup uyguladıktan sonra, servislerin öncelikle birbirini bulabildiğinden emin olmanız gerekir. Daha önce de belirttiğim gibi, Kubernetes gibi mikroservis orkestrasyon araçları mikroservis keşfinde kritik bir rol üstlenir.
Bu, Kubernetes DNS tarafından sağlanan yerleşik servis keşfi aracılığıyla gerçekleştirilir; servisler ölçeklendiğinde veya küme içinde konum değiştirdiğinde IP adresleri ve DNS kayıtları dinamik olarak güncellenir.
Bu mikroservis keşfi yöntemine sunucu taraflı keşif denir; çünkü yönlendirme sorumluluğu bir yük dengeleyiciye devredilir ve yük dengeleyici kayıt defterini sorgulayarak trafiği uygun örneğe yönlendirir.
Öte yandan, istemci taraflı keşif yöntemi de vardır; bu yöntemde servis veya API ağ geçidi, mevcut örnekleri bulmak için Consul veya Eureka gibi bir servis kaydını sorgular.
Hangi servis keşfi yönteminin mikroservis dağıtımınıza daha uygun olduğu, sistemin gereksinimlerine ve ölçeğine bağlıdır.
İstemci taraflı mikroservis keşfinde istemci, hangi örnekle iletişim kuracağı üzerinde tam denetime sahiptir. Bu, daha fazla özelleştirmeye olanak tanımasının yanı sıra merkezi bir keşif servisine gerek kalmadığından karmaşıklığı da azaltır.
Örneğin Netflix'in mikroservis dağıtımı, yük dengeleme için Eureka ve Ribbon ile istemci taraflı mikroservis keşfini kullanır; bu sayede istemci, gecikme ve sunucu yükü gibi kriterlere göre en uygun örneği seçebilir.
Ancak sunucu taraflı mikroservis keşfi, daha büyük ortamlar için daha uygundur; merkezi bir servis keşfi, verimliliği artırabilir ve dağıtık bir sistem genelinde tutarlı yük dengeleme sağlayabilir.
Kubernetes, AWS Elastic Load Balancing ve API Gateway'ler (Kong, NGINX vb.) gibi sunucu taraflı mikroservis keşfi çözümleri, trafiği verimli biçimde yönlendirmeye ve yüksek erişilebilirliği korumaya yardımcı olur; Airbnb, Pinterest, Expedia ve Lyft gibi şirketler tarafından kullanılmaktadır.
Mikrohizmet Güvenliği
Monolitik mimari çoğu açıdan MSA'nın gerisinde kalsa da güvenlik konusunda bir avantajı vardı. Mikroservisler, Gevşek Bağlantı ilkesi üzerine inşa edildiğinden ve dağıtık bir yapıya sahip olduğundan, tekil ve genel bir güvenlik önlemi uygulanamaz.
Her servisin bağımsız olarak güvence altına alınması gerektiğinden, mikroservislerde saldırı yüzeyi çok daha geniş olduğu için ek önlemler zorunludur. Bu amaçla, tahmin edebileceğiniz gibi kimlik doğrulama ve yetkilendirme için OAuth2 ve JSON Web Tokens (JWT) gibi standartlar yaygın olarak kullanılır.
Bunun yanı sıra, bir API ağ geçidi de genellikle giriş noktasında kimlik doğrulamayı ve yetkilendirmeyi zorunlu kılarak mikroservisler genelinde güvenliği yönetmek için kullanılır. Ağ geçidi API'leri ayrıca hız sınırlama, loglama ve izleme özelliklerini de hayata geçirebilir; bu da mikroservis güvenliğine ek katmanlar ekler.
Bu önlemler ana giriş noktasını güvence altına alsa da servisler arası iletişimi kapsayabilmek için daha fazla mikroservis güvenlik tedbirine ihtiyaç duyulur.
Servis mesh'leri tam da bu noktada devreye girer; servisler arasındaki trafiğe bir ağ güvenlik katmanı ekler, trafiği şifreler ve karşılıklı TLS gibi politikaları uygular. Bu servis mesh'leri, mikroservis güvenliğini önemli ölçüde artıran kapsamlı bir uçtan uca şifreleme altyapısı kurar.
Mikro Hizmet Ölçeklendirmesi
MSA'nın en büyük avantajlarından biri ve monolitik mimarinin yerini almak üzere geliştirilmesinin temel nedeni, yüksek ölçeklenebilirliğidir. Mikroservis ölçeklendirmesi genel olarak iki şekilde gerçekleşir: dikey ve yatay.
Dikey mikroservis ölçeklendirme (yukarı ölçekleme), mevcut bir örneğe CPU veya bellek gibi daha fazla kaynak eklemektir. Yatay mikroservis ölçeklendirme (dışa ölçekleme) ise yükü dağıtır ve kapasiteyi artırır.
Uygulama açısından dikey mikroservis ölçeklendirme daha kolaydır; tek yapmanız gereken, daha büyük bir sunucuya geçiş yaparak, bulut örneğinde bellek veya işlem gücünü artırarak ya da depolama ekleyerek tek bir örneği güncellemektir.
Bu ölçeklendirme türü genellikle RAM veya CPU gücünü artırmanın sorgu performansını ve veri işlemeyi iyileştirebildiği durumlarda kullanılır; bellek içi önbelleklemeyle sorumlu servisler buna örnek gösterilebilir.
Bununla birlikte, dikey mikroservis ölçeklendirme daha kolay olup anlık bir performans artışı sağlasa da bazı dezavantajları vardır. Dikey ölçeklendirme, sunucunun donanım kapasitesiyle sınırlıdır; dolayısıyla belirli bir noktada dikey ölçeklendirmeye devam edebilmek için yatay ölçeklendirmeye geçmeniz gerekir.
Ayrıca donanım ve daha büyük örnekler genellikle yüksek maliyetli olduğundan dikey ölçeklendirme maliyeti de yüksektir. Son olarak, ölçeklendirilen örnek çökerse, yükü karşılayacak başka örnek olmadığından servis tamamen durur.
Yatay mikroservis ölçeklendirmede, tek bir örneğin kaynaklarını artırmak yerine o servisin yeni örneklerini dağıtırsınız. Bu örnekler bağımsız çalışsa da aynı servisi ve aynı iş yükünün bölümlerini üstlenir.
Dikey ölçeklendirmenin aksine, yatay mikroservis ölçeklendirmesinin bir sınırı yoktur; artan iş yükleri ve trafik artışlarını karşılamak için istediğiniz kadar örnek ekleyebilirsiniz. Bu da daha yüksek bir ölçeklenebilirlik sunar.
Üstelik birden fazla örneğiniz olduğundan, biri çökerse tüm yükü tek bir sepete koymamış olursunuz; diğer örnekler istekleri karşılamayı sürdürür. Son olarak, daha güvenilir ve daha güçlü bir performans elde etmek için birden fazla küçük ve uygun maliyetli örnek kullanabildiğinizden yatay ölçeklendirme uzun vadede çok daha ekonomiktir.
Bununla birlikte, yatay ölçeklendirme ve daha fazla örnek eklemek; daha fazla yük dengeleyici, mikroservis keşfi mekanizması ve mikroservis orkestrasyon aracı gerektirdiğinden mikroservis mimarinizi çok daha karmaşık hale getirir.
Yatay ölçeklendirme, değişken trafik ve yüksek hacimli isteklerle sık karşılaşan e-ticaret veya sosyal medya platformları gibi web servislerine ve uygulamalarına daha uygundur.
Bununla birlikte, bu iki yaklaşım aslında birbirinin alternatifi değildir; her iki ölçeklendirme türü de mikroservislerde desteklenir ve pek çok durumda birlikte kullanılması gerekir. Genellikle küçük ölçekli organizasyonlar, uygulamak ve yönetmek daha basit olduğu için dikey ölçeklendirmeyi tercih eder; ancak uygulama büyüdükçe artan talebi karşılamak için yatay ölçeklendirme de devreye alınır.
Son olarak, bulut platformları gerçek zamanlı talebe göre otomatik olarak örnek ekleyip kaldıran otomatik ölçeklendirme hizmetleri sunar; bu da kuruluşların dikey ve yatay ölçeklendirmeyi dengelemesine önemli ölçüde yardımcı olur.
Mikroservice İzleme
Bu aşamada mikroservis dağıtımınızı büyük ölçüde tamamlamış olursunuz; geriye kalan tek şey, her şeyin tutarlı ve güvenilir biçimde çalıştığından emin olmaktır. İşte bu noktada Prometheus ve Grafana adım at.
Bu araçlar, servis metrikleri hakkında gerçek zamanlı bilgi sunarak ekiplerin kaynak kullanımını, gecikmeyi ve hata oranlarını takip etmesini sağlar. Bunun yanı sıra, servisler arasındaki istek akışlarını görselleştirmeye yardımcı olan ve sorunların teşhisinde son derece işe yarayan dağıtık izleme desteği de sunar (Jaeger, Zipkin, vb.).
Son olarak, mikroservislerin dağıtık yapısı nedeniyle hatalar servisler arasında zincirleme yayılabilir; bu yüzden log toplama, mikroservis izlemenin kritik bir parçasıdır. Logları merkezi bir platformda toplayıp gerçek zamanlı uyarılar kurarak sorunların her zaman önünde olabilir ve kullanıcıları etkilemeden önce proaktif biçimde müdahale edebilirsiniz.
Son Düşünceler
Mikroservisler başlangıçta karmaşık görünse de temel kavramları ve dağıtım sürecinin ana aşamalarını kavramak her şeyi çok daha kolay hale getirir. Üstelik her geçen yıl daha fazla özellik sunan yeni araçlar ortaya çıktıkça mikroservis dağıtımı giderek daha da kolaylaşmaktadır.
SSS
Mikroservisler için yaygın olarak kullanılan dağıtım stratejileri nelerdir?
Mikroservis dağıtımında pek çok farklı strateji bulunmakla birlikte, en yaygın kullanılanlar arasında konteyner başına servis örneği, aşamalı sürüm yayınlama, mavi-yeşil dağıtım ve sunucusuz dağıtım yer alır. Her biri farklı düzeylerde izolasyon, esneklik ve ölçeklenebilirlik sunar.
Kubernetes mikroservislerin orkestrasyon sürecinde nasıl bir rol oynar?
Mikroservisler, konteynerize servislerin dağıtımını, ölçeklendirmesini ve yönetimini otomatikleştirmek için Kubernetes gibi orkestrasyon araçlarına ihtiyaç duyar. Kubernetes; yük dengeleme, otomatik ölçeklendirme ve kendini onarma özellikleriyle mikroservislerin dayanıklı ve verimli çalışmasını sağlar.
Mikroservis ortamında güvenliği nasıl sağlayabilirim?
Dağıtık yapıları nedeniyle mikroservislerde güvenlik, monolitik mimariye kıyasla çok daha karmaşıktır. Mikroservis güvenliği; isteklerin kimlik doğrulaması ve yetkilendirmesi, servisler arası iletişimin şifrelenmesi ve merkezi güvenlik yönetimi için API geçitleri ile Istio gibi servis mesh çözümlerinin uygulanmasını kapsar.
