• 02-04-2024, 00:47:59
    #1
    Inchels.com
    Merhaba arkadaşlar,

    Daha önce belirli başlı konularla ilgili paylaşımlarda bulundum. Bunları konunun devamına ekleyeceğim. Bu tarz konular açarak, ileri seviye konulara değinmek istiyorum sürekli. Umarım keyifli bir yazı olur ve bilgilendirme sağlamış olabilirim.




    Mikroservis Mimarisi Nedir ?

    Önceden yazılım deyince akla tek bir title gelirken, şimdi onlarca farklı title ortaya çıkıyor. Projelerin büyümeleriyle beraber, farklı alanlarda yoğunlaşan insanlar ortaya çıkmaya başladı. Önceden Webmaster varken, şimdi Testerların bile onlarca farklı title'ı var. Bizde bu büyümeden doğru oranda etkilendik. Konuya neden buradan girdim bilmiyorum

    Önceden Back-End ve Front-End iç içe yazarken, uzun bir süre önce hayatımıza API'lar girdi. API'lar ile beraber büyüme ve gelişme devam etti. Mikroservislerde bu noktada devreye girdi. Mikroservis ile ilgili en basit tanımı yapmak istiyorum:

    "Diğer sistemlerle bağlantılı olmadan, kendi başına işlem sağlayan, işlemci kümesi" demek. Yani: diğer servislere bağlı olmadan, kendi başına işlemlerini gerçekleştirebilen, kendi DB'si olan işlemci. Somut bir örnek vermek gerekirse:

    Bir kitap paylaşım sitemiz olsun. İnsanlar burada okudukları kitapların özetlerini ve değerlendirmelerini paylaşsın. Takipçi sistemi, yorum sistemi gibi şeyleri de dahil edelim. Baktığınızda hepsi bir API gibi gözükse de, mikroservis mimarisinde durum böyle değil. Mikroservislerde her şeyi ayırmanız gerekir. Kullanıcıların işlemlerini farklı bir servis içine alıyoruz. Bunu DB'si de ayrılıyor. Aynı şekilde "kitap paylaşımları" servisini de ayırıyoruz. Yorumlar, takipçiler gibi servisleri de ayırıyoruz.



    Kullanıcı servisine A, paylaşımlara da B servisi diyelim.

    A servisi route olarak /users olsun. B servisi de route olarak /books olsun. Bunların DB'leri mikroservis içerisinde ayrılmalıdır. Yani A servisi ile B servisinin işlem olarak birbirleriyle alakalı bir bağlantısı olmamalı. Bir servis ayağa kalkarken, diğer servis bundan etkilenmemeli. Bu yüzden DB dahil olmak üzere tüm bağımlılıklarını ayırıyoruz. Mikroservislerin basit anlamda çalışması bu şekildedir. Yani sistemi ufak parçalara ayırıp, daha ufak parçalara odaklanıyoruz. Bu da geliştirme süreçlerini zorlaştırsa da performansı üste çıkarıyor. Peki performans nasıl artıyor ? Bunu sağlayan konteynır sistemleri. Örneğin: Docker.

    Bu servisleri açtıktan sonra takiplerini gerçekleştiriyoruz. Örneğin A servisinde projede çok fazla yüklenme oluyor. Veya günün belirli saatinde çok fazla yüklenme oluyor. Docker gibi sistemler kullanarak replikalar üretiyoruz. Bu replikalar sayesinde aynı servisi birden fazla hale getiriyoruz. Birden fazla servis olduğu için iş yükü ikiye bölünüyor. Nasıl yani ?

    Bir servisimiz saniyede maksimum 100 istek alabiliyor olsun. Biz buna 200 istek atarsak yavaşlamalar olur veya sistem kilitlenir. Bunu engellemek içinde replika üreterek mevcuttaki 100 istek gücümüzü 200 isteğe çıkartabiliyoruz. Böylede yığılmaları büyük ölçekli sistemlerde kontrol altına alıyoruz. Sistemlerin büyümesinde 2 farklı büyüme mevcut. Dikey ve yatay büyüme. Dikey büyüme eskiden çok fazla kullanılıyordu. Ancak maliyet bakımından ciddi masraflı. Şimdi yapılan yatay sistemler ile maliyetler düşürülüyor. Hem de sunuculardan üst düzey performans alınıyor. Bu büyümeye de yazılımda "scaling" denir. Genel olarak trafik dengelemeye ise "load balancing" denir.



    Peki bizim 100 tane servisimiz oldu. Bunları nasıl yönlendireceğiz ?

    Burada ise yardımımıza Gateway sistemleri yetişiyor. Sistemleri gateway ile yönlendirerek, kontrollerimizi sağlayabiliyoruz. Gateway ile ölçümlemeler gerçekleştirebiliyoruz. Tek bir alan üzerinden akışları kontrol edip, hem düzenli olmasını hem de balancing işlemlerini gerçekleştirebiliyoruz. Gatewayları da yine replika üzerine alıp, doğru bir şekilde yük dengeleme sağlayabiliyoruz.

    A servisi B servisi ile haberleşmesi gerekirse ne yapacak ?

    Mikroservisler birbirinden bağımsız olacak demiştik. Ancak bu demek değil ki servisler birbiriyle haberleşmeyecek. Burada haberleşmenin olması şart. Örneğin A servisi(kullanıcılar), paylaşımlara ihtiyaç duyuyor. Bunu nasıl sağlayacağız ? Burada farklı iletişim yöntemleri var ancak önce çıkan bazı iletişim protokolleri var. Bunların başında Restful geliyor. Restful ile iletişimler gerçekleştirilebiliyor. Bunun yanında 2 farklı iletişim biçimi de mevcut.



    Restful

    Klasik HTTP 1.X haberleşmesinde kullanılır. En çok tercih edilen yöntemlerden bir tanesidir ve çokça kullanılır. Klasik API mantığında, HTTP protokollerini kullanarak, haberleşmeler sağlanır. gRPC'ye göre geliştirmesi ve okunabilirliği kolaydır ancak performansı daha düşüktür.



    gRPC

    Google tarafından üretilen iletişim protokolü ile HTTP 2.X üzerinden haberleşirsiniz. Mesajları buffer ile ilettiğinden dolayı, performansı yüksektir. Performansın yüksek olması gerektiği sistemlerde kullanılmalıdır. Yazımı ve okunabilirliği zordur ancak performansı yüksektir. En büyük avantajı ise dilden bağımsız olarak çalışabilmesidir. Yani A servisinde C# kullanırken, B servisinde Python kullanıp, haberleşmesini sağlayabilirsiniz.



    Message Broker

    Bu protokol, diğer sistemlere göre farklıdır. Tek taraflı iletişim gerçekleşir. Gönderilen mesajlar, consumer'lara ulaşır ve işlenir. İstemciye geri dönüş gerçekleşmez. Buna örnek olarak RabbitMQ projesi olabilir. Bununla ilgili detaylı anlatım gerçekleştirdim. Konunun bitişindeki linklerden ulaşabilirsiniz.

    Mikroservis Mimarisinin Avantajları

    Büyük trafiğin olduğu sistemlerde şarttır.
    Performans odaklı sistemlerde kullanılmalıdır ve performansı arttırır.
    Yoğunluklarda anlık müdahale edilebilir ve sistemin performansı arttırılabilir.
    Bakımlarda veya güncellemelerde sisteminizi tamamen kapatmanız gerekmez. Replikalara sırayla dağıtarak, trafiğinizi aktif tutabilirsiniz.

    Mikroservis Mimarisinin Dezavantajları
    Çok bir dezavantajı bulunmamakla birlikte yönetim biraz daha zorlaşır. Servisler çok fazla olduğu için takip gerektirir.

    Mikroservis mimarisini böyle bodoslama anlatmak istedim. Daha değinecek çok şey var ama bir yerde noktalamak iyi olacaktır. Genel terimlere değindim ve mimariyi anlatmak istedim. İçerisine girdiğinizde sizde biliyorsunuz ki yazılım dipsiz bir kuyu. Umarım size bir şeyler katabilmişimdir. Sonraki yazılarımda görüşmek üzere, seviliyorsunuz

    Daha önceki konular:
    https://www.r10.net/webmaster-genel-...-128187-a.html
    https://www.r10.net/webmaster-genel-...9965039-a.html
    https://www.r10.net/webmaster-genel-...elistirme.html
    https://www.r10.net/webmaster-genel-...-128187-a.html
    https://www.r10.net/webmaster-genel-...-128680-a.html

    DİPNOT: Bu tarz paylaşımlara devam edeceğim. Talep derseniz etiketleme listesi oluşturabilirim yeni konu paylaştığımda. Etiketlenmek istenen kullanıcılar bunu belirtebilirler.
  • 02-04-2024, 01:14:18
    #2
    Elinize sağlık güzel paylaşım. Sonrakinde etiketlerseniz sevinirim
  • 02-04-2024, 02:06:31
    #3
    Hocam paylaşımınız çok güzel ve şunu deyinmek isterim ki genelde bir çok microservis altyapıları json(public ve local) formatı ile haberleşme sağlamaktadır json genel programlama dillerinde destek sağlandığı için (yanlışım varsa düzenlemem için yazarsanız sevinirim bende bilgi sahibi olurum)



    İyi forumlar değerli hocalarım
  • 02-04-2024, 02:25:50
    #4
    Inchels.com
    koksalkesici adlı üyeden alıntı: mesajı görüntüle
    Hocam paylaşımınız çok güzel ve şunu deyinmek isterim ki genelde bir çok microservis altyapıları json(public ve local) formatı ile haberleşme sağlamaktadır json genel programlama dillerinde destek sağlandığı için (yanlışım varsa düzenlemem için yazarsanız sevinirim bende bilgi sahibi olurum)



    İyi forumlar değerli hocalarım
    JSON hem okunabilirlik hem de kullanılabilirlik bakımından en çok kullanılan veri şeması. Eğer bahsettiğiniz servisler arası haberleşme ise JSON sadece bir veri şemasıdır. İletişim biçimi değildir. Eğer veri şeması olduğunu kastediyorsanız dedikleriniz doğru ancak farklı yapıları kullanan sistemler mevcut. Konuda da belirttiğim gRPC protokolü, buffer kullanarak verileri aktarıyor. Hala daha SOAP, XML, Text-Based gibi dönüşler yapan sistemler mevcut. Ayak uydurmak lazım yeni teknolojilere. Artık DB'ler bile JSON'u kaydediyor ve query alabiliyor bunun üzerinden.
  • 02-04-2024, 02:32:08
    #5
    Developer adlı üyeden alıntı: mesajı görüntüle
    JSON hem okunabilirlik hem de kullanılabilirlik bakımından en çok kullanılan veri şeması. Eğer bahsettiğiniz servisler arası haberleşme ise JSON sadece bir veri şemasıdır. İletişim biçimi değildir. Eğer veri şeması olduğunu kastediyorsanız dedikleriniz doğru ancak farklı yapıları kullanan sistemler mevcut. Konuda da belirttiğim gRPC protokolü, buffer kullanarak verileri aktarıyor. Hala daha SOAP, XML, Text-Based gibi dönüşler yapan sistemler mevcut. Ayak uydurmak lazım yeni teknolojilere. Artık DB'ler bile JSON'u kaydediyor ve query alabiliyor bunun üzerinden.
    Hocam veri şeması olarak değindim şuanda güncel mongodb ve diğer database yazilimlari zaten json çıktı almayı desteklemektedir daha farklı veri dönüş yapan mevcut sistemler mevcuttur ama en çok tercihen gözlemlediğim json veri tipi dönüş olmasıdır okunuşu ve kullanabilirik açısından konunuzda görmeyince değinmek istedim
  • 02-04-2024, 02:33:17
    #6
    Inchels.com
    koksalkesici adlı üyeden alıntı: mesajı görüntüle
    Hocam veri şeması olarak değindim şuanda güncel mongodb ve diğer database yazilimlari zaten json çıktı almayı desteklemektedir daha farklı veri dönüş yapan mevcut sistemler mevcuttur ama en çok tercihen gözlemlediğim json veri tipi dönüş olmasıdır okunuşu ve kullanabilirik açısından
    Aynen öyle çok doğru. JSON hem kullanılabilirliği hem de okunabilirliği ile en üst sırada.