Mikroservis Yazı Serisi 5 - Centralizing Access

     Selamün Aleyküm Arkadaşlar,
    Serinin beşinci yazısı olan merkezi erişim konusuna başlıyoruz. Burada ele alacağımız 3 kavram olan gateway, reverse proxy, load balancer konuları olacak. Hepsi gelen trafiği ilk karşılayıp gerekli servislere yönlendiren yapılar olmasına rağmen birbirlerinden farklılaştığı noktalar mevcut. Ayrıca böyle bir kurgunun ne gibi bir işlevi var, ne tür avantajlar sağlar, hangi işlemleri burada yapmalıyız gibi konulara da değinmeye çalışacağız. Hazırsak başlayalım.

    Genel yapı itibariyle dışarıdan gelen istekleri hepsini en önde karşılayan kale kapısı olarak düşünebilirsiniz. Bu kapılardan içeri girmeyen kimse kale içine de giremez. Öncelikle buralardan içeri giriş yapılmalı. İçeriye de rastgele gidilmiyor tabii ki. Gelen isteğin nereye gideceğini sorguluyor ve ona göre en uygun yere yönlendiriyor. Load balancer için kullanılan bazı yöntemler şunlardır:

• Round Robin: Sunuculara sırasıyla yönlendirme yapar.
• Least Connections: Aktif bağlantısı sayısı en az olan sunucuya yönlendirme yapılır.
• IP Hash: IP Hashlenerek aynı istemciden gelen tüm istekler buraya yönlendirir.
• Random: Gelen yükü sunuculara rastgele dağıtır.
• Path-based Routing: Url tabanlı yönlendirme yapar. Mikroservis kurgusu için uygundur.
• Geographical Routing: Coğrafi konuma göre en yakın sunucuya yönlendirir.
• Content-based Routing: İsteğin türüne göre yönlendirme yapılır. Web veya mobil olarak ayrılabilir.

    Her bir yöntem farklı ihtiyaçlar için kullanılabilir. Gelen isteklerin tek bir yerden geçerek dağıtılmasının birçok avantajı olabilir. Yukarıda da bahsettiğimiz gibi gelen bütün trafiği yönetir. Yetkilendirme işlemleri yapılabilir. Rate limiter kullanılarak gelen riskler azaltılabilir. Gelen giden tüm istekler loglanabilir. Bu ve benzeri işleri her bir servis için ayrı ayrı yapmaktansa tek bir yerden yönetebiliyoruz. 

    Birçok avantajı olsa da bazı dezavantajları da yok değil. Bu öndeki kapı düştüğünde bütün maçı kaybetmiş sayılabiliriz (Single Point of Failure). Projenin yumuşak karnı gibi düşünebiliriz (Bu durumda  birden fazla kapı kurarak, biri düşse dahi sistemin devamlılığını sağlamak lazım). Karmaşıklığı artırır ve dolayısıyla performans kaybı da yaşanır (sisteme göre tolere edilebilir veya en azından iyi gözlem yapılması gerekir).

    Şimdi de yazının başındaki birbirlerine benzeyen 3 yapıya değinelim.

• Api Gateway: Api çağrıları için özel olarak tasarlanmıştır. (Ocelot, Kong, Tyk)
• Load Balancer: Sunucuya gelen yükleri dağıtmak için tasalanmıştır. (Nginx, HAProxy)
• Reverse Proxy: İstekleri yönlendirmek için tasarlanmıştır. (Yarp, Caddy)

    https://medium.com/codenx/load-balancer-vs-reverse-proxy-vs-api-gateway-fcb79912abbf

    Yukarıdaki resimdeki bazı kavramları kısaca açıklamak gerekirse;

• Authorization: Gelen kullanıcının yetkisinin kontrol edilmesidir.
• Rate Limiting: Gelen istek sayısını sınırlamasıdır. Böylece sistemin çökmesi engellenebilir.
• Caching: Sık kullanılan verilerin depolanması ve böylece yanıt süreleri kısaltılır.
• Composition: Birden çok servisten gelen cevapların birleştirerek tek bir cevap olarak iletilmesi
• Circuit breaker: Sistem aşırı yük aldığında, yük alan servisin istekleri geçici olarak durdurulması
• Retry: Hatalı bir istek olduğunda bunun tekrar olarak gönderilmesi
• Url Rewrite: Gelen url'lerin düzeltilerek istenilen formata getirilerek ilerletilmesi
• Failover: Arıza durumunda yedek sunucuya otomatik geçişi sağlanır.

    Özetle bahsedilen 3 kavram aynı işlemleri yapıyor gibi görünse de aslında birbirlerinden ciddi farkları olduğunu görmüş olduk. Projemizin ihtiyaçlarına göre en doğru yapmamız gerekir.

    Yazıyı birer ayet-i kerime ve hadis-i şerif ile sonlandıralım.

"Ey iman edenler! Mallarınızı aranızda haksız yere yediğiniz ve insanları yoldan çıkarmak için aldatıcı yollarla, aranızda birbirinizin malını yemeyin..." (Bakara Suresi, 2:188)

"Birinizin diğerini yönlendirmesi, ona yardımcı olması, doğru yolu göstermesi, onunla işbirliği yapması hayırlıdır." (Buhârî, İlim, 30)