Mikroservis Deployment Pattern

1.568

Merhaba arkadaşlar,

Önceki yazımızda sizlere mikroservislerin ne olduğundan bahsetmiştik. Bu yazımızda ise sizlere mikroservislerin farklı deployment pattern tiplerinden bahsedeceğim. Aslında mikroservisler ile alakalı bir çok kalıp var. Servis iletişimleri, UI Pattern gibi gibi… Ama onlara daha sonraki yazımızda değineceğiz.

Mikroservisler öncelikle teorik olarak iyi anlaşılması gereken bir konudur. Çünkü hangi mimari yapıyı nasıl ve nerede kullanmanız gerektiğini bilmezseniz ileride başınıza büyük bela olacak bir yapı ile karşı karşıya kalabilirsiniz. Bundan dolayıdır ki mikroservislerde direkt olarak example, demo proje ile başlamak bir hata olacaktır. Zaten ilerledikçe sizinle beraber bir takım örnekler de gerçekleştireceğiz. Yolumuz uzun nasıl olsa 🙂

Deployment Pattern geçmeden önce her bir pattern’i anlatırken önceki yazımdaki örneği kullanmak faydalı olacaktır.

Dilerseniz şimdi pattern tiplerine bakalım;

1)Multiple Service Instance Per Host

Mikroservisler için hazırlanan her bir hostta için birden fazla servisin barındırıldığı kalıplardır. Burada Driver Web UI ile Passenger Web UI’ın Tomcat ve Jetty olarak farklı 2 server’da bulunduğunu varsayalım. Bu iki servisin aynı hostta 2 farklı JVM işlemi şeklinde davrandığı kalıplardır. Ya da OSGI Bundle gibi aynı JVM üzerindeki farklı servis instance gibi davrandığı kalıplardır.

2)Service Instance Per Host

Burda ise her servis için bir host ayrılır. Yukarıdaki her bir servis için server açtığımızı düşünelim. Durumuna göre değişebilir fakat maliyetli bir mimari. (Oracle EXADATA sadece DB için kullanılan bir hosttur ve buna örnek gösterilebilir.)

3)Service Instance Per VM

Her bir servis bir VM image şeklinde saklanır ve kullanılır. Bu şekilde bir nevi yatay olarak genişleyen bir yapı elde edilmiş olur. Multiple Service Instance Per Host ile karıştırılmaması gerekir çünkü onda aynı host üzerinde birden fazla JVM işlemi çalışıyor. Bunda ise aynı hostta olsa dahi her servis hosttan bağımsız bir şekilde kendi VM üzerinde çalışıyor. Mesela yukarıdaki her bir servisi Amazon üzerinde bir EC2’da tanımladığımızı düşünelim. O zaman her servisi kendi VM üzerinden sağlamış oluruz.

4)Service Instance Per Container

Docker yazılarımızla ilerleyen zamanlarda kesişecek olan bu kalıp her servisin bir container ile sağlandığı bir yapıdır. Container yapısının getirdiği avantajlar ile en ideal mikroservis kalıplarındandır.

5)Serverless

Altyapısı bir bulut sağlayıcısı tarafından sağlanan bir mikroservis kalıbıdır. Kullanıcı hangi kalıbı kullanacağını düşünmez. Bulut sağlayıcısı servisleri izole etmek için kendisi bir kalıp mimarisi oluşturur fakat bu bilgileri kullanıcıdan saklar. Kullanıcı sadece koşturmak istediği kod ile ilgilenir ve kodu çalıştırır. Amazon Lambda, Google Cloud Functions bu mimariye birer örnektir. -İlerleyen yazılarımızda daha detaylı bir şekilde örneklerle inceleyeceğiz. –

6)Service Deployment Platform

Servisler için bir deployment platformu oluşturulur. Bu platform servisler için otomatik olarak altyapı oluşturur. Böylelikle servisler en uygun şekilde birbirinden soyutlanır. Bu mimariye örnek olarak Docker Swarm diyebiliriz.

Mikroservislerde deployment pattern bu şekilde sağlanmaktadır. İlerleyen yazımızda Serverless ve Service Instance per Container üzerine daha detaylı çalışmalar yapacağız. Yazımı bitirmeden önce kafalarda bir soru işareti oluşturayım diyorum 🙂 Deployment kalıplarında hep yazdığımız kodlardan bahsettik fark ettiyseniz. Fakat DB Yönetimi nasıl oluyor? Takibe devam edelim 🙂

Bir sonraki yazımızda görüşmek dileğiyle…

 

1 Comment
  1. sefa cihangir says

    Teşekkürler Hocam mikroservis yazılarınızı okuyorum, hepsi çok faydalı, çok açıklayıcı ağzınıza sağlık.

Yorum yaz

Email adresiniz yayınlanmayacaktır.