Microservice Interview Soru ve Cevaplari

Microservice Interview Soru ve Cevaplari

Herkese Merhaba,

Software Backend Developer olarak girdigimiz is gorusmelerinin buyuk cogunlugunda Microservice ile ilgili birkac soru geliyor. Bu yazimda sizlerle is gorusmelerinde benim karsilastigim sorulardan bazilarini paylasmak istedim. Sorular dogrudan “Mikroservislerin avantajlari nelerdir?” seklinde gelmeyebilir, bazen bir ornek mimari anlatip o mimariye dayanarak birkac soru sorabilirler, gelen mimari sorusuna gore cikarimda bulunarak cevap vermek gerekebilir, yani sizden asil beklenen cevap aslinda Mikroservisin avantajlarindan bahsetmeniz olabilir veya Monolith ve Microservis arasindaki farklardan bahsetmeniz beklenebilir gibi… Yazimda Microservice nasil calisir, nasil implement edilir gibi detaylara deginmeden, kendi tecrubelerime gore sorularin cevaplarini paylasacagim. Keyifli okumalar…

1. Microservice avantajlari nelerdir?

Mikroservislerin temel ilkesi basitliktir. Uygulamalar daha kucuk ve birlikte calisabilir parcalara bolunduklerinde maintain edilmesi ve kodun yonetilmesi daha az zahmetli hale gelir. Uygulamada yer alan servislerin hepsini kucuk kucuk parcalara bolerek ayristirmak, servislerin birbirleriyle olan bagimliligini azaltmis olur. Bu uygulamaya independent deployment, development ve yonetim avantaji saglamis olur. Her kucuk servis kendi ana tasklarindan sorumludur, ornegin User servisi user create/update/delete islemlerinden sorumlu iken, Product servisi sadece product create/update/delete islemlerinen sorumlu olmalidir. Bu uygulamaya yeni feature eklemeyi kolaylastirir ve bu sayede kodlarin karmasikligi azaltilmis olur. Microservis kullanarak servislerinizi ihtiyaciniza gore daha kolay olceklendirebilirsiniz(scale up/down). Hangi servisin daha cok buyumeye veya kuculmeye ihtiyaci var ise sadece bu servis icin yeni instance’lar ekleyebilir veya cikarabilirsiniz. Mikroservislerin bir diger onemli avantaji, her microservis farkli bir programlama dilinde yazilabilir yani bir servis Java’da kodlanmis, digeri .Net ile kodlanmis olabilir. Birbirinden farkli dillerin birbiriyle haberlesmesine ve esnek bir yapiya olanak saglar. Genis olcekli uygulamalarda microservis kullanilmasinin en buyuk avantaji, farkli takimlarda calisan developerlarin birbirinden bagimsiz kod gelistirebilmesi, birbirlerini etkilemeden yeni eklentileri microservislere dahil edebilmesi ve bunu deploy edebilmesidir.

2. Monolith ve Microservice mimarisi arasindaki farklar nelerdir?

Monolith mimari, ayni bellek alanini paylasan butunlesik bir birim olarak birlikte calismak uzerine tasarlanmis bir mimaridir. Yani tight couple iliskiye sahip, dependent bir mimari secenegidir. Ornegin User ve Product olan bir uygulamaniz var. Her iki servisin butun fonksiyonlari tek bir ana cati altinda toplanmistir. Ayni memory, ayni DB ve ayni programlama dilini kullanarak calisir. Farzedelimki Product servisim giderek buyuyor ve benim bu servis icin yeni source’lar eklemem gerek, fakat User’im ayni, hatta daha az source ile de calisabilir durumda. Mimari yapim Monolotih oldugu icin tum projemi birden scale up yapmam gerekecek. Bu da maaliyetli bir cozum doguracak. Veya Product icin artik farkli bir database yapisina gecmem gerekli ise yine butun projenin DB yapisini degistirmek zorunda kalacagim. Cok buyuk olmayan ve cok dinamik olmayan projeler icin Monolith tercih edilebilir. Cunku microservis her ne kadar avantajlari yuksek bir mimari olsa da, loglarin izlenmesi, kodun debug edilmesi, deployment sureclerinin takibi icin cok iyi bir management surecine sahip olunmali ve bu sureclerin surekliligi icin maliyet de goz onunde bulundurulmalidir.

User ve Product’dan olusan projem Microservis ile yazilmis bir proje olsaydi, sadece Product servisim icin yeni resource’lar ayirip, User servisimi scale down yapabilirdim. Yine ayni sekilde DB’yi diger kucuk servisleri etkilemeden sadece ihtiyacim olan servis icin degistirebilirdim. Yani elimde light couple iliskiye sahip, independent calisan, flexible ve cross-functional calismaya uyumlu bir mimari olacakti. Microservisleri buyuk projelerde, developer sayisinin fazla oldugu durumlarda kullanmak projeye ve calisan developerin verimliligine buyuk katki saglayacaktir.

3. Hangi mimaride (Monolith | Microservice) integration test yazmak daha kolaydir?

Monolith mimaride cok daha kolaydir. 5 farkli microservice oldugunu ve bu microservislerin birbirlerini cagirdigini dusunelim. Her bir microservisin kendine ozel bir kod base’i, bagimliligi ve database semasi var. Integration test ile her mikroservis arasindaki iletisimi ve etkilesimi, istenilen amaca hizmet ediyor mu diye test etmek gerekir.

Oncelikle lokalde uctan uca test yapabilmek icin her mikroservisin up-to-date hali lokalde olmali, hepsinin calisir durumda oldugundan emin olmak gerekir, eger ozel bir DB konfigurasyonu veya DB migrate etmek gerekiyorsa her biri icin bunlar yapilmali ki uctan uca test yapilabilsin. Bu sebeple microservislerde integration test man-day anlaminda maliyetli bir testtir, ayni zamanda efective bir integration test yazabilmek icin tum microservisler hakkinda yeterli bilgiye sahip olmak gerekir. Integration test microservisin dezavantajlarindan birisidir. Pratikte kolay hale getirmek icin onerilen bazi yontemler vardir. Ornegin her API’in kendine ait bir dokumantasyonu olur ve bu API uzerinde calisan herkes degisiklikten once ilk olarak dokumantasyonu gunceller. AWS(Amazon Web Service) test stratejisi kullanilabilir.

4. Bir projeye hangi mimari ile baslanmali, neden?

Monolith ve Microservis mimari secimi projenin buyuklugune, ihtiyaclara, sirket kulturune, onceliklere gore degisir.

Eger proje cok kapsamli degilse ve calisan developer sayisi cok azsa Monolith mimari ile ilerlenir. Yeni bir projeye baslarken her zaman Monolith ile ilerlemek en guvenli yoldur. Cunku monolith daha az maliyet, daha az efor gerektirir, devops cozumlerine ihtiyac duymadan da deployment management yapilabilir.

Proje kapsami buyudukce, ihtiyaclar artar, projenin scale edilmesi gerekir, de-couple servislere ihtiyac duyulabilir yada buyuyen development ekibi bolunerek farkli takimlar kurulabilir. Iste bu durumda uygulamayi Microservice mimarisine gecirmek dogru bir karar olacaktir.

5. Microservisce dezavantajlari nelerdir?

Microservislerin avantajlarinin yani sira dezavantajlari da vardir. Fakat buna ragmen artilari daha efektif goruldugunden bu dezavantajlar goze alinir.

Microservisler kucuk kucuk cok sayida servislerden olusabilecegi icin uygulamanin karmasikligini arttirabilir, bu sebeple cok iyi bir API dokumantasyonuna ihtiyac vardir.

Deploy management zorlasabilir cunku cok sayida kucuk mikroservis yonetimi zordur.

Her mikroservisin ayri test edilmesi gerekir, bu sebeple test daha cok efor gerektirir ve monolith’e gore daha zordur.

Resource kullanimi, farkli database konfigurasyonlari gibi sebeplerle monolith mimariye gore daha pahali bir mimaridir

Loglama ve debug etme monolith mimariye gore daha zordur. Bunun icin log centrealized edilmeli ve dashboard tool’lari kullanilmalidir.

6. Microservice’ler birbiriyle nasil haberlesir?

1.Synchronous Iletisim

RestTemplate — Mikroservislerin HTTP protokol uzerinden haberlesmesini saglar. Servisler arasinda senkron iletisim vardir ve RestTemplate en basit microservis iletisim yoludur. Bir client REST call yaparak server’a request yollar ve response’unu bekler. Netflix’in sagladigi cozumler kullanilarak Rest-based Feign Client da mikroservisler arasi iletisim icin kullanilabilir. Senkron ve one-to-one mikroservis iletisiminde, microservise yeni bir instance eklenmek istenirse, Netflix tarafindan sunulan Ribbon proxy eklenebilir. Netflix Ribbon, client-side load balancing ozelligi saglar. Rest template ile yapilan microservisler arasindaki iliskide Tight-couple iliski vardir.

2. Asynchronous Iletisim

Message Broker — Asenkron iletisim icin kullanilan message broker protokollerinden en bilineni RabbitMQ ve Kafkadir. HTTP protokolu yerine iletisim queue uzerinden AMQP(Advanced Message Queuing Protocol) ile saglanir. Iletisim client ve server arasinda dogrudan saglanmaz, bir servis mesaji push eder, subscribe olan servis mesaji alir. Asenkron iletisim oldugu icin iletisim daha hizlidir. Provider mesaji kime gonderdigini bilmez sadece mesajini Queue’ya atar ve subscribe olan servis mesajini ceker, bu sebeple mesage broker ile iletisim kurmak guvenlik acisindan daha avantajlidir.

7. Microservice’lerde DB entegrasyonu nasil yapilmalidir?

Microservis mimarisinin kullanmanin en buyuk avantajlarindan birisi light couple ve independent servisler elde edebilmektir. Bu avantaja sadik kalabilmek icin her microservis kendi DB’sine baglanti kurmalidir. Ornegin User ve Product microservisleri icin User DB’si ve Product DB’si ayri ayri microservislerde yer almalidir. Ortak DB kullanilmasi maliyet acisindan daha avantajli gorunse dahi microservislerin arasinda guclu baglanti kilacagindan tercih edilmemelidir. Microservislerin ortak DB kullanmalari durumunda, ornegin sadece User microservisini ilgilendiren bir tabloda sorun yasanirsa diger butun microservisler de fail edecektir veya bir tabloda degisiklik yapilmasi gerektigi durumda yine diger servisler de bundan etkilenecektir. Bu sebeple pratikte her microservisin kendi DB semasi olmasi beklenir. Fakat cok sayida microservisiniz varsa her birine DB tanimlamak cok maliyetli bir cozum olacagindan, business ihtiyaclarina gore shared DB cozumlerinden bazilari kullanilabilir.

8. Tüm mikro servislerin aynı fiziksel bilgisayarda mı çalışması gerekir?

A: Yapabilirler. Ancak, mikroservisleri ayırdığımız için, bir mikroservis mimarisini makineler arasında dağıtmak mümkündür. 

MSA’lar genellikle birden fazla fiziksel makinenin kümelerinde çalıştırılır. Büyük ve karmaşık sistemler bile ucuz, düşük güçlü bilgisayarlara dağıtılabilir. Küçük sanal makineleri veya bir bulut sağlayıcısından örnekleri kullanmak yaygındır.

Bir proje büyüdükçe, yatay ölçekleme olarak bilinen örnekleri eklemek kolaydır. Tek bir makine kullanılıyorsa, o zaman dikey ölçekleme gerekli olur. Dikey ölçekleme, o tek makinenin daha büyük bir makineyle yükseltilmesini gerektirebilir ve bu da yatay ölçeklemeden çok daha pahalıdır. 

MSA’nın bir avantajı yatay ölçeklemenin mümkün olmasıdır. Monolitte yalnızca dikey ölçekleme mevcuttur.

9: Mikroservisleri tasarlarken neleri düşünmeliyiz?

A: Mikroservisler son derece uyumlu olmalı, her servis yalnızca bir şey yapmalıdır. 

Bir geliştirici, mikroservisler arasında az sayıda bağımlılık bulunan, gevşek bağlı mikroservisler oluşturmak isteyecektir.

10: REST nedir?

A: REST, bir API oluşturmak için standart HTTP yapılarını kullanma tekniğidir. REST, iş verileri için temsiller kullanır. Genellikle bu bir JSON dosyasıdır, ancak XML de olabilir. GET, POST, UPDATE, DELETE gibi standart HTTP fiillerini kullanır. Ayrıca 200 ve 404 gibi standart HTTP dönüş kodlarını kullanır.

11: Mikroservis iletişimi için REST kullanımına alternatifler var mı?

C: Evet, bunun yerine mesaj odaklı davranışı kullanabilirsiniz.

12: Mesajların avantajları nelerdir?

A: Mesaj odaklı davranış REST’ten daha gevşek bir şekilde bağlıdır. Bir mikro servis, bir eylemin gerçekleştiğini söylemek için bir konuya mesaj gönderebilir. Mikro servisin bu mesajı kimin alacağı hakkında hiçbir bilgiye ihtiyacı olmadığından, bu konuya herhangi bir etki olmadan abone ekleyebilir veya kaldırabiliriz.

13: Mesajların dezavantajları nelerdir?

A: Neden ve sonuç zincirini görmek daha karmaşık ve zordur. Ayrıca, yalnızca asenkron durumlarda kullanılabilir.

Yararlı bir MSA hem mesajları hem de REST’i kullanır.

14: Sigortalar nelerdir ve neden gereklidir?

A: Bir devre kesici(Circuit breaker), belirli bir mikro servisin çok sık arızalanıp arızalanmadığını tespit eden bir bileşendir. Devre kesici etkinleşirse, o mikro servise yapılan tüm çağrılar kısa bir süreliğine sonlandırılır. Amaç, mikro servisin iyileşmesi için zaman tanımaktır. Devre kesicilerin kullanımı, ardışık arıza olasılığını önler.

15: Devre kesicilerin (Circuit breaker) bazı uygulamaları nelerdir?

A: Hystrix , Netflix’in çok popüler bir devre kesicisiydi, ancak artık aktif olarak geliştirilmiyor. Artık servis ağlarına yerleştirilmiş devre kesici özelliklerini kullanmak daha yaygın.

16: Mikroservis mimarileri oluşturmada kullanılan bazı yaygın araçları adlandırın.

A: Sayısız araç mevcuttur, ancak en yaygın olanlardan bazılarının listesi şöyledir:

• Docker: Mikro hizmetleri dağıtmak için kullanılan bir konteyner çerçevesi
• Kubernetes: Docker konteynerlerinizi yönetmek için kullanılan bir düzenleme çerçevesi
• Spring Boot: Mikroservisler için hızlı bir geliştirme çerçevesi sağlar
• Istio: Mikro hizmetler arasındaki etkileşimlerin ayrıntılı izlenmesini sağlamak için Kubernetes ile kullanılan bir hizmet ağı
• Prometheus: Bir kümeden ölçümleri toplayan bir izleme sistemi
• Grafana: Metrikleri grafik biçiminde görüntüleyen bir grafik aracı
• ElasticSearch: Kümelerde günlükleri toplamak için kullanılan bir arama motoru
• Kibana : Günlükleri incelemek için bir kullanıcı arayüzü

17: Bir mikro servis mimarisinin izlenmesi neden bu kadar önemlidir?

A: Sisteminizin bir bileşeni arızalanırsa, uzun süre tespit edilemeyebilir. Bir izleme sistemiyle, sistemin sorunsuz bir şekilde çalıştığından görsel olarak emin olabilirsiniz.

Bir bileşen arızası durumunda ekibinizin haberdar olması için bir uyarı sistemi de önemlidir. Tipik uyarı sistemleri SMS veya PagerDuty gibi hizmetlerdir. 

18: Sürekli dağıtım nedir?

A: Sürekli dağıtım (CD), bir kod deposuna yapılan her gönderimin bir derlemenin tetiklenmesiyle sonuçlanmasıdır. Derleme otomatik testler çalıştırır. Testler geçerse, yazılım paketleri bir görüntü olarak. Ardından, yeni mikro hizmet üretim ortamına dağıtılır.

19: Mikroservis kullanmanın başlıca avantajları nelerdir?Cevabı Gizle

Mikroservis kullanmanın başlıca avantajları şunlardır:

Ölçeklenebilirlik : Mikroservisler, kaynak kullanımını optimize eden talebe göre bireysel bileşenlerin bağımsız olarak ölçeklenmesine olanak tanır.

Esneklik : Geliştiriciler her mikro servis için farklı programlama dilleri, veritabanları ve teknolojiler kullanabilirler, böylece her görev için en iyi aracın kullanılması sağlanır.

Sürekli teslimat : Mikro hizmetler daha hızlı geliştirme ve dağıtım döngülerini teşvik ederek şunları sağlar:sürekli entegrasyon ve dağıtım (CI/CD) uygulamaları.

Hata izolasyonu : Bir mikro servisteki sorunlar tüm uygulamayı etkilemez, bu da hata izolasyonunu ve sistem dayanıklılığını artırır.

Ekip özerkliği : Mikroservisler, birden fazla ekibin farklı servisler üzerinde bağımsız olarak çalışmasını sağlar; bu da geliştirme hızını artırır ve inovasyonu teşvik eder.

20: What are the main components of Microservices?(Mikroservislerin temel bileşenleri nelerdir? )

Microservices consists of:

• Containers, Clustering, and Orchestration
• IaC [Infrastructure as Code Conception]
• Cloud Infrastructure
• API Gateway
• Enterprise Service Bus
• Service Delivery

21: İyi tasarlanmış bir mikro servis mimarisinin özelliklerini açıklayın.

İyi tasarlanmış bir mikro servis mimarisi genellikle aşağıdaki özellikleri sergiler:

Tek sorumluluk ilkesi : Her mikroservis belirli bir iş yeteneğine odaklanır, onu küçük ve iyi tanımlanmış tutar.

Gevşek bağlantı : Mikro hizmetler, bileşenler arasındaki bağımlılıkları azaltarak iyi tanımlanmış API’ler aracılığıyla iletişim kurar.

Bağımsız dağıtım : Her mikro servis bağımsız olarak dağıtılabilir, böylece daha hızlı güncellemeler sağlanır ve sistem genelinde arıza riski azaltılır.

Dayanıklılık : Mimari, arızaları zarif bir şekilde ele almak ve tüm sistemi etkilemeden hatalardan kurtulmak için mekanizmalar içerir.

Ölçeklenebilirlik : Mikroservisler, bireysel bileşenlerin yatay olarak ölçeklenmesine olanak tanır ve kaynakların verimli kullanılmasını sağlar.

Çok dilli kalıcılık : Farklı mikroservisler kendi veritabanlarını kullanabilir ve ihtiyaçlarına en uygun veri depolama alanını seçebilirler.

İzleme ve gözlemlenebilirlik : Mimari, hata ayıklamayı ve performans optimizasyonunu kolaylaştırmak için sağlam izleme ve günlük kaydı yeteneklerini içerir.

22: Mikroservis mimarisi sürekli entegrasyonu ve sürekli dağıtımı (CI/CD) nasıl destekler?

Mikroservis mimarisi, her bir servisin bağımsız geliştirilmesini ve dağıtımını kolaylaştırarak CI/CD’yi destekler. Mikroservisler gevşek bir şekilde bağlı olduğundan, ekipler bunlar üzerinde bağımsız olarak çalışabilir. Bu, tüm sistemi etkilemeden yeni özellikler eklemeyi, hataları düzeltmeyi ve güncellemeler yapmayı kolaylaştırır.

CI/CD pipelines bireysel mikro hizmetler için ayarlanabilir, otomatik test, entegrasyon ve dağıtıma izin verir. Daha küçük kod tabanları ve hizmetler arasındaki iyi tanımlanmış sınırlarla, üretime değişiklikleri teslim etmek daha hızlı ve daha güvenli hale gelir. Bu yaklaşım ayrıca sık sürümleri destekler ve geliştiriciler için hızlı geri bildirim döngüleri sağlayarak yeni özellikleri ve iyileştirmeleri pazara sunma süresini azaltır.

23: Monolitik mimariden mikroservislere geçişte karşılaşılan temel zorluklar nelerdir?

Monolitik bir mimariden mikro hizmetlere geçiş, aşağıdaki temel faktörler nedeniyle zorlu olabilir:

Ayrıştırma karmaşıklığı : Doğru hizmet sınırlarını belirlemek ve bir monoliti tutarlı mikro hizmetlere ayırmak dikkatli bir analiz ve planlama gerektirir.

Veri yönetimi : Dağıtılmış bir ortamda verilerin işlenmesi, işlemlerin birden fazla mikro hizmeti kapsaması nedeniyle daha karmaşık hale gelir.

Hizmetler arası iletişim : Performans darboğazlarını ve arıza zincirlerini önlemek için mikro hizmetler arasında verimli ve güvenilir iletişimin sağlanması hayati önem taşır.

İşletimsel yük : Birden fazla hizmeti yönetmek, izlemek ve günlüğe kaydetmek, sağlam bir yönetim gerektiren operasyonel karmaşıklığı artırabilir.DevOps uygulamaları.

Test : Test stratejilerinin, birden fazla hizmet genelinde entegrasyon testi, sözleşme testi ve uçtan uca testi ele alacak şekilde gelişmesi gerekiyor.

Tutarlılık (Consistency): Özellikle veri güncellemeleri sırasında mikroservisler arasında tutarlılığı sağlamak zorlu bir iştir.

24: Mikroservisleri kullanırken karşılaştığınız zorluklardan bahseder misiniz?

* Servisler Arası İletişim ve Entegrasyon Zorlukları

• Ağ Tabanlı İletişim: Mikroservisler bağımsız bir şekilde çalıştığından, servisler arası iletişim için genellikle HTTP, gRPC veya mesaj kuyrukları gibi ağ tabanlı protokoller kullanılır. Bu da gecikmeleri artırabilir, bağlantı sorunları ortaya çıkarabilir ve hata yönetimini karmaşıklaştırabilir.
• Veri Tutarlılığı: Her mikroservis kendi veritabanına sahip olduğunda, verilerin tutarlı ve senkronize olması zor olabilir. ACID özellikleri (özellikle transaction yönetimi) büyük bir zorluk oluşturur.

* Dağıtık Sistemlerin Yönetimi

• Dağıtık İzleme ve Hata Ayıklama: Mikroservisler birçok farklı servis tarafından yönetildiğinden, bir hata veya performans sorunu tespit etmek karmaşık hale gelir. İyi bir dağıtık izleme ve logging çözümü gereklidir. Ancak, bu sistemlerin kurulması ve yönetilmesi de zordur.
• Hata Yönetimi ve Tolerans: Mikroservislerin birbirinden bağımsız çalışması, bir servisin çökmesi durumunda tüm sistemin etkilenmesini engellemek için sağlam hata toleransı ve geri dönüş mekanizmaları gerektirir. Bu, özellikle bir servisin arızalanması durumunda bütün sistemi etkilemeden çözüm bulmayı zorlaştırabilir.

* Veritabanı Yönetimi

• Çoklu Veritabanı Yönetimi: Her mikroservisin kendi veritabanına sahip olması gerektiğinde, veritabanı yönetimi karmaşıklaşır. Veritabanları arasındaki tutarlılığı sağlamak ve farklı veri yönetimi ihtiyaçlarına uygun çözümler geliştirmek gereklidir.
• Veri Dağıtımı ve Senkronizasyonu: Mikroservislerin farklı veritabanlarına sahip olması, veri paylaşımını ve senkronizasyonunu zorlaştırabilir. Veriler arasındaki ilişkilerde zorluklar yaşanabilir.

* Dağıtık İşlem Yönetimi ve Transaction Yönetimi

• Mikroservislerin çoğu bağımsız çalıştığından, birden fazla servisin aynı işlem içinde yer alması gerekebilir. Geleneksel monolitik uygulamalarda ACID (Atomicity, Consistency, Isolation, Durability) garantileri sağlanırken, mikroservislerde bu tür garantileri sağlamak çok daha zordur. Bunun yerine eventual consistency gibi gevşek tutarlılık modeline geçiş yapılabilir, ancak bu da veri tutarsızlıklarına yol açabilir.
• SAGA Pattern gibi deseni kullanmak bu zorlukları aşmak için bir çözüm olabilir, ancak uygulamak karmaşık olabilir.

* Servislerin Yönetimi ve Dağıtımı

• Servis Kapsayıcıları ve Orkestrasyon: Her mikroservis bağımsız olarak çalıştığından, bu servislerin kapsayıcılar (Docker) ve orkestrasyon sistemleri (Kubernetes) ile yönetilmesi gerekir. Bu da yönetimi karmaşıklaştırabilir ve doğru yapılandırma yapılmazsa sorunlar çıkabilir.
• Servis Keşfi (Service Discovery): Mikroservislerin her biri farklı bir sunucuda çalıştığında, servislerin birbirlerini bulması için bir keşif mekanizmasına ihtiyaç duyulur. Bu da kendi başına bir zorluk oluşturur.
• Versiyon Yönetimi: Her mikroservisin kendi bağımsız versiyonuna sahip olması, versiyon uyumsuzluklarına yol açabilir. Geriye dönük uyumluluğun sağlanması gerekebilir.

* Yüksek İletişim Maliyeti ve Karmaşıklık

• Mikroservislerin çoğu genellikle API üzerinden iletişim kurar. Bu, özellikle her mikroservisin dış dünya ile iletişim kurmak için HTTP istekleri göndermesi durumunda önemli bir performans maliyeti oluşturabilir.
• Yüksek Ağ İletişim Maliyeti: Servisler arasındaki ağ trafiği, mikroservislerin performansını olumsuz etkileyebilir. Bu da veri iletimi sırasında latency ve throughput sorunlarına yol açabilir.

* Geliştirici ve Ekip İlişkileri

• Mikroservislerin Karmaşıklığı: Mikroservislerin sayısı arttıkça, her bir servisin geliştirilmesi ve bakımı daha karmaşık hale gelir. Her mikroservis için ayrı test, deploy ve güncelleme süreçleri gereklidir.
• Ekip Koordinasyonu: Mikroservisler farklı ekipler tarafından geliştirildiği için, ekipler arasındaki koordinasyon ve işbirliği çok önemlidir. Mikroservislerin birbirleriyle doğru şekilde entegre olması, sürekli bir iletişim gerektirir.
• Teknolojik Zorluklar ve Çeşitlilik: Farklı mikroservislerin farklı teknolojilerle yazılabilmesi, ekiplerin çeşitli teknolojiler üzerinde çalışmasını gerektirir. Bu durum, öğrenme eğrisini artırabilir ve yönetim açısından zorluklar oluşturabilir.

. Güvenlik ve Yetkilendirme

• Servisler Arası Güvenlik: Mikroservisler arasındaki iletişim şifreli olmalıdır ve her bir mikroservis kendi güvenlik politikalarına sahip olmalıdır. Bu, merkezi güvenlik çözümlerinin yönetilmesini zorlaştırabilir.
• Kimlik Doğrulama ve Yetkilendirme: Mikroservislerde kimlik doğrulama ve yetkilendirme, her bir servisin bağımsız olarak güvenlik önlemleri almasını gerektirir. Merkezi bir güvenlik çözümü oluşturmak, güvenlik açıklarının önlenmesinde önemli bir rol oynar.

* Test Etme ve Sürekli Entegrasyon (CI/CD)

• Mikroservislerin entegrasyon testi, bütünsel testler ve son kullanıcı testleri yapmak zordur. Bir mikroservisin değişiklikleri diğer mikroservislerle uyumlu olmalıdır, ancak her bir servisin bağımsız olarak test edilmesi gerekebilir.
• CI/CD Süreçleri: Mikroservislerin sürekli entegrasyonu ve dağıtımı, çok sayıda servisin bağımsız olarak güncellenmesini, test edilmesini ve dağıtılmasını gerektirir. Bu, otomasyon araçlarının ve süreçlerinin doğru şekilde yapılandırılmasını gerektirir.

* Ekiplerin Dağıtılması ve İzolasyon

• Mikroservisler, farklı mikroservislere sahip olabilecek farklı ekiplerle çalışmayı gerektirir. Bu, ekipler arasında bilgi paylaşımının ve koordinasyonunun zorlaşmasına yol açabilir.
• Mikroservislerin bağımsızlığı, bazı durumlarda servisler arasındaki kopuklukları ve bağımsızlıkları artırabilir, bu da organizasyonel zorluklar doğurabilir.

---

Özet:

Mikroservis mimarisi, yüksek esneklik ve ölçeklenebilirlik sağlasa da, dağıtık sistemlerin yönetimi, servisler arası iletişim, veri tutarlılığı, güvenlik, test etme ve sürekli entegrasyon gibi birçok zorlukla birlikte gelir. Bu zorlukların üstesinden gelmek için uygun altyapı, araçlar ve iyi bir organizasyonel yapı gereklidir.

25 Mikroservislerde API ağ geçidinin amacı nedir?( API gateway)

Mikroservislerdeki bir API ağ geçidi, istemci isteklerini işleyen ve ardından bunları uygun mikroservislere yönlendiren merkezi bir giriş noktası görevi görür. Birkaç amaca hizmet eder:

Toplama : API ağ geçidi, bir istemci isteğini karşılamak için birden fazla arka uç mikro hizmetinin yanıtlarını tek bir tutarlı yanıtta birleştirebilir. Bu, gidiş-dönüşleri azaltır.

Yük dengeleme : Ağ geçidi, optimum kaynak kullanımı ve yüksek kullanılabilirlik sağlamak için gelen istekleri aynı mikro hizmetin birden fazla örneği arasında dağıtabilir.

Kimlik doğrulama ve yetkilendirme: İstemcileri kimlik doğrulaması yaparak ve belirli mikro hizmetlere erişimi yetkilendirerek güvenlikle ilgili endişeleri giderebilir.

Önbelleğe Alma : API ağ geçidi, performansı artırmak ve gereksiz istekleri azaltmak için mikro hizmetlerden gelen yanıtları önbelleğe alabilir.

Protokol çevirisi: İstemci isteklerini bir protokolden (örneğin HTTP/REST) ​​altta yatan mikro hizmetler tarafından kullanılan uygun protokole çevirebilir.

26: Mikroservislerin temel özelliklerini listeleyin

Mikroservislerin bazı temel özellikleri şunlardır:

• Ayrıştırma (Decoupling) : Hizmetler genellikle bir sistem içinde birbirinden ayrılır. Sonuç olarak, uygulama bir bütün olarak basitçe oluşturulabilir, değiştirilebilir ve ölçeklenebilir.
• Bileşenleştirme  (Componentization): Mikroservisler, kolayca değiştirilebilen veya geliştirilebilen ayrı bileşenler olarak kabul edilir.
• İş Yetenekleri (Business Capabilities) : Mikroservisler küçüktür ve tek bir servise odaklanır.
• Ekip özerkliği : Her geliştirici özerk olarak çalışır, bu da proje zaman diliminin kısalmasını sağlar.
• Sürekli Teslimat (Continuous Delivery) : Yazılımın geliştirilmesini, test edilmesini ve onaylanmasını otomatikleştirerek sık sık yazılım sürümü yayınlanmasını sağlar.
• Sorumluluk (Responsibility): Mikroservisler, uygulamalara odaklandıkları kadar projelere odaklanmazlar. Bunun yerine, uygulamaları kendilerinin sorumlu olduğu ürünler olarak görürler.
• Merkezi Olmayan Yönetim : Amaç, iş için uygun aracı seçmektir. Geliştiriciler, sorunlarını çözmek için en iyi araçları seçme seçeneğine sahiptir.
• Çeviklik : Mikroservisler daha çevik geliştirmeye olanak tanır. Yeni özellikleri hızla eklemek ve sonra istediğiniz zaman kaldırmak kolaydır.

 .

Mikroservisler dağıtılmış sistemlerde hata toleransını ve dayanıklılığı nasıl sağlar?Cevabı Gizle

Mikroservisler, çeşitli teknikler aracılığıyla hata toleransını ve dayanıklılığı artırır:

Yedeklilik : Mikro hizmetlerin birden fazla örneğe ve muhtemelen farklı veri merkezlerine kopyalanmasıyla, bazı örnekler başarısız olsa bile sistem çalışmaya devam edebilir.

Devre kesici deseni (Circuit breaker pattern) : Mikroservisler, ardışık arızaları önlemek için devre kesicileri uygular. Bir mikroservis sorun yaşarsa, devre kesici daha fazla isteği durdurur ve bir geri dönüş yanıtı veya hata mesajı sağlar.

Bulkhead’ler : Mikroservisler birbirinden izole edilmiştir. Bir servisteki arızalar diğerlerini etkilemez ve potansiyel hasara neden olur.

Zarif bozulma : Hizmet bozulması veya kullanılamaması durumunda, mikro hizmetler işlevselliğini zarif bir şekilde bozabilir veya sınırlı ancak gerekli özellikler sağlayabilir.

Zaman Aşımları : Mikroservisler arasındaki iletişim için uygun zaman aşımlarının ayarlanması, kaynakların sonsuza kadar beklemesini önler.

27: Kohezyon ve Bağlantı hakkında ne anlıyorsunuz?

Bağlantı/Coupling

Bağlantı, A ve B yazılım modülleri arasındaki ilişki ve bir modülün diğerine ne kadar bağımlı veya bağımlı olduğudur. Bağlantılar üç gruba ayrılır. Çok bağlı (yüksek derecede bağımlı) modüller, zayıf bağlı modüller ve bağlantısız modüller var olabilir. Arayüzler aracılığıyla gerçekleştirilen gevşek bağlantı, en iyi bağlantı türüdür.

Tutarlılık/Cohesion

Bağlantı, bir modülün aynı işlevi gören iki veya daha fazla parçası/öğesi arasındaki bağlantıdır. Genel olarak, güçlü bir bağlantıya sahip bir modül, diğer modüllerle herhangi bir bağlantı gerektirmeden belirli bir işlevi etkili bir şekilde yürütebilir. Modülün işlevselliği, yüksek bağlantısıyla geliştirilir.

28 : Mikroservis iletişiminin temel bileşenleri nelerdir?

Mikroservis iletişiminin temel bileşenleri şunlardır:

API’ler (Uygulama Programlama Arayüzleri) : Mikroservisler, iyi tanımlanmış API’ler aracılığıyla birbirleriyle iletişim kurarak gevşek bağlantı ve birlikte çalışabilirliği mümkün kılar.

Mesaj aracıları (Message brokers): Asenkron iletişimde, mesaj aracıları (örneğin, RabbitMQ, Apache Kafka) mikroservisler arasında mesajların iletilmesini kolaylaştırır.

REST (temsili durum aktarımı) : RESTful API’ler, hizmetlerin standart HTTP yöntemleri üzerinden veri alışverişinde bulunmasına olanak tanıyan, eşzamanlı iletişim için yaygın olarak kullanılır.

Hizmet keşfi (Service discovery): Mikro hizmetlerin, değişen bir ortamda birbirlerini dinamik olarak keşfetmeleri için bir mekanizmaya ihtiyaçları vardır. Consul veya Eureka gibi araçlar, hizmet kaydı ve keşfinde yardımcı olur.

Olay akışı (Event streaming) : Gerçek zamanlı veri işleme ve olay odaklı mimariler için, mikroservisler arasında olay akışı sağlamak amacıyla Kafka veya Apache Pulsar gibi araçlar kullanılır.