Category: Software Architecture


Event-based Mimari ve Node.js

November 13th, 2013 — 4:38am

3-4 yıl önce “C# ve Java’dan sonra daha başka programlama dili çıkmaz herhâlde” diye düşündüğümü hatırlıyorum. Şu anda bir daha düşündüğümüzde ne kadar komik bir yorummuş :) Ortalık dilden geçilmiyor resmen, (scala, closure, node.js(javascript), ruby, erlang, objective c) kariyerine yeni başlayan biri için seçim yapmak zor gözüküyor, bizim zamanımızda seçenek daha azdı…

Nodejs’i kurcalamaya başladım ve web development sevdiğimden sanırım yazılımda anadilim c#’dan javascript’e geçiyor. “Event driven” programlamayla ilgili biraz yazmak istiyorum.

“blocking”, “nonblocking”, “event-based”, “thread-based” nedir, farkları neler halk dilinde anlatmak istiyorum.

Konuyu anlatmak için kullanılan en klasik metafor, bir doktorun muayenehanesinde resepsiyon görevlisi ile görüşebilmek için sırada beklemek. Bizde bu örneği kullanalım.

Geleneksel thread-based sistemde,  resepsiyon görevlisinin yanına gittiğinizde işleminiz tamamlanana kadar resepsiyonda ayakta beklersiniz. Eğer 3 form doldurmanız gerekiyorsa, bunları o anda resepsiyonda ayakta doldurursunuz, resepsiyon görevlisi de siz formları doldurana kadar bekler. Bu şekilde, resepsiyon görevlisini bloke ederek (blocking) diğer müşterilere hizmet vermesini engellemiş olursunuz. (tabi bu sizin suçunuz değil, sistemi tasarlayanların ayıbı :) )

Thread-based bir sistemi ölçeklendirmenin (scale) tek gerçek yolu, daha fazla resepsiyon görevlisi çalıştırmaktır. Tabii ki daha fazla insana para ödemek durumunda kaldığınız için bunun mali getirileri ve ekstra resepsiyon görevlilerine yer açmanız gerektiği için de fiziksel getirileri vardır.

Event-based sistemde ise, resepsiyona gidip doldurmanız gereken ekstra formlar olduğunu öğrendiğinizde, resepsiyon görevlisi size doldurmanız gereken formları ve bir kalem vererek formları doldurduktan sonra resepsiyona tekrar geri gelmenizi söyler. Siz formları doldurmak için bir yere gidip oturduğunuzda, resepsiyon görevlisi sıradaki diğer kişi ile ilgilenir. Bu şekilde, resepsiyon görevlisini diğerlerine hizmet etme konusunda bloke etmemiş olursunuz. (non-blocking)

Non-blocking / event-based sistemin ölçeklenebilirliği oldukça yüksek (highly scalable). Tabiki bekleme sırası uzayıp gidiyorsa, yeni bir resepsiyon görevlisini sisteme dahil etmeniz gerekecektir ancak bunu thread-based sistemdeki kadar erken yapmak zorunda değilsiniz. Daha düşük maliyetle daha uzun süre idare edebilirsiniz.

Bu aynı zamanda, bir fast-food restoranında sipariş vermeye de benziyor. Thread-based sistemde, sıra size geldiğinde siparişinizi verirsiniz ve siparişiniz hazırlanıp size verilene kadar orada beklersiniz. Siz siparişinizi alıp sıradan çıkana kadar kasiyer sırada bekleyen bir sonraki kişiye yardımcı olamaz. Daha fazla müşteriye hizmet vermek istiyorsanız, daha fazla kasiyerin olması gerekiyor.

Bazı fast-food restoranlarının bu şekilde işlemediğini biliyoruz. Kasiyerlerden mümkün olan en fazla verimi alabilmek için event-driven sisteme göre işliyorlar. Siparişinizi verdiğiniz anda, kasiyer ödemenizi alırken sipariş hazırlanması için başka bir kişiye iletilir. Ödemenizi yapıp sıradan çıktıktan sonra, kasiyer sıradaki diğer müşterilerle ilgilenir. Hatta bazı restoranlarda, siparişiniz hazır olduğunda gidip almanız için yanıp sönen ve titreyen bir pager bile verebilirler. Burdaki asıl nokta, yeni siparişlerin alınmasını bloke etmiyor (non-blocking) oluşunuzdur.

Siparişiniz hazır olduğunda, kasiyer (ya da başkası) isminizi, sipariş numaranızı söyleyerek ya da pager’ınıza mesaj göndererek bunu size bildirir. Siparişinizin hazır olması olayı, bu kişinin bazı fonksiyonları/eylemleri yerine getirmesini sağlar. (Programlama dilinde buna “callback” denir).

Geleneksel tarzda web serverlar thread-based modelindeydiler. Apache ya da diğer bir web serverı çalıştırırsınız ve bağlantıları almaya başlar. Server’a bir bağlantı iletildiğinde, server o sayfa ya da diğer işlemle ilgili talebi gerçekleştirene kadar bağlantıyı açık tutar. Eğer bir sayfayı diskten çekip almak ya da sonuçları bir veritabanına yazmak birkaç mikro saniye sürüyorsa, web server bu input/output operasyonları için o süre boyunca bloke edilir (blocking) (bu işlem “blocking I/O” olarak adlandırılır). Bu türdeki bir web server’ı ölçeklendirebilmek için, ekstra server kopyaları çalıştırmanız gerekir (kopyalar ekstra bir işletim sistemi thread’i gerektirdiği için “thread-based” olarak nitelendirilir).

Node.js ise, event-driven modeli kullanır. Buna göre, web server gelen talepleri kabul eder, talebi yerine getirilmesi için ilgili yere gönderir ve bir sonraki web talebi için hizmet vermeye devam eder. İlk talep tamamlandıktan sonra, tekrar işlem sırasına geri döner ve sıra ona geldiğinde sonuçlar geri gönderilir (ya da bir sonraki adım ne ise o gerçekleşir). Bu model, oldukça etkin ve ölçeklenebilir (scaleable) bir modeldir çünkü web server herhangi bir okuma-yazma (read or write) operasyonu için beklemediğinden sürekli talepleri kabul eder bu “non blocking I/O” ya da “event-driven I/O” olarak adlandırılır.

Konuyu biraz daha somut anlatmak gerekirse:

  1. Node.js web server’ından “/about.html” talep edersiniz.
  2. Node.js server’ı talebinizi kabul eder ve o dosyayı diskten çekebilmek için bir fonksiyonu devreye sokar.
  3. Node.j server’ı dosyanın çekilmesini beklerken, bir sonraki web talebine hizmet vermeye devam eder.
  4. Dosya diskten alındığında, callback fonksiyonu çağırılır.
  5. Node.js server’ı bu callback ile “/about.html” sayfasını web browser’ınıza gönderir.

 

Aslında böyle bir işlemi gerçekleştirmek mikrosaniyeler alıyor; ancak her mikro saniye değerlidir! Eğer söz konusu olan ölçeklenebilirliği yüksek (highly-scaleable) web serverlar ise. (birkaç milyon üyeniz var ve anlık yüzbinlerce ziyaretçi sisteminizi kullanıyor ise mikro saniye önemli)

Aslında .net framework 4.5 ile gelen yeniliklerden olan async / await de buna benzer bir işleyiş. Ancak bu mimariyi Node.js ile uyguladığınızda oldukça yaygın olan JavaScript dilini kullanıyorsunuz. Web geliştiren birinin JavaScript’e dokunmamış olması çok zor. Yazılımcıların daha önceden az birazda olsa bildikleri bir dil olduğundan, sanılandan çok daha düşük bir alışma/öğrenme zamanı ile çok hızlı ve ölçeklenebilir serverlar kurmak mümkün.

Comments Off on Event-based Mimari ve Node.js | Software Architecture

REST ya da SOAP Web Servisleri

January 3rd, 2013 — 12:32am

Bu yazıda kısaca web servisler ile ilgili görüşlerimi belirticem.

Bugün uygulamalarımızdaki servisler çoğunlukla HTTP üzerinden konuşuyor.
Ve bu HTTP servisler için SOAP ve REST olarak 2 farklı yöntemle geliştirme yapabiliyoruz.

Aslında hangisi ile daha rahatsak onu seçerek geliştirebiliriz.
Biraz google’ladığımızda REST mimarisini tercih etmekle ilgili oldukça fazla marketing olduğunu görebiliriz.
Bende bugün yeni bir projeye başlayacak olsam REST servisler ile geliştirmeyi seçerim.

REST, SOAP’a göre daha hızlı ve hafif bir yöntem, çünkü REST’de ekstradan XML tanımları yok…
REST bir servise erişmek nispeten daha basit. Sadece browser dan çağırdığınızda bile tam sonucu alabilirsiniz.

REST mimaride “Caching” HTTP üzerinden uygulanabildiğinden daha verimli…
Sonucun değişip değişmediğini “ETag” (“Cache-Control”, “Last-Modified”) üzerinden sorgulayıp gereksiz network trafiğini de engelleyebiliyoruz.

SOAP için de caching yapabiliriz tabiki ancak HTTP nin zaten yapmış olduğu bir güzelliği kullanamamış oluyoruz.
Hatta Google’ın SOAP apisini kapatmasının ardında Caching implementasyonundaki gereksiz taklalar olduğunu düşünüyorum.
Ve tabiki dağıtık bir mimaride REST service ile çalışmak daha rahattır…

Microsoft ortamında geliştirme yapan arkadaşlar genelde SOAP servislerine (.asmx) alışıktır ve pek çoğuna REST ile bir servis hazırlamak zor gözükebilir…
Aslında REST servis geliştirmek de basit, hele HTTP de neler olup bitiyoru biraz farketmeye başlamışsak.
Web ortamına dokunan bir şeyler geliştiriyorsak, HTTP de neler olup bitiyor bilmemek ayıp değil ama öğrenmemek ayıp.

Güvenlik açısından 2 servisi incelediğimizde iki yöntemi de aynı seviyede güvensizler, iki yöntemde de en azından SSL kullanmamız gerekiyor…

Sonuç olarak eğer uygulamamızı web için geliştiriyorsak ve farklı uygulamalarla entegre olacaksak REST mimariyi tercih edip servislerimizi geliştirmemiz daha verimli olacaktır. Bugün bir web projesi yapıp da mobil uygulaması olmayacağını düşünmek de mümkün değil. Web ve mobil clientların aynı REST API sinden beslenmesi her açıdan en düşük maliyetli olanı.

Comments Off on REST ya da SOAP Web Servisleri | Software Architecture


Back to top