Reactive Programlama ile ilgili hiçbir ön bilgiye sahip değilseniz ya da makale serisine devamlılık ve hatırlama açısından Reactive Programlama Nedir? isimli makalemize lütfen bir göz atmayı ihmal etmeyiniz.
Bu yazı dizisinde konuşacaklarımız tüm programlama dillerine uyarlanabilir. Herhangi bir dil üzerinden ya da salt herhangi bir dili baz alarak ilerlemeyeceğiz.
Çok değil 10 yıl önce uygulamalar ve uygulama mimarileri keskin sınırlara sahiptiler. Evet, herkes ya da tüm uygulamalar kendilerine göre ve kendi içlerinde esnek ya da dinamik olduklarını iddia etseler de belirli bir çerçeve içerisindeydiler. Bu çerçeve mimariler Server – Client düzleminde yer almaktaydı. Bir yerde bir sunucu ailesi bulunur. Bu sunucu ailesine 100’lerce bazen 100.000’lerce client bağlanır ve veri alış verişi sağlanırdı.
Son 10 yılda yaşanan bulut mimari ve mobil devrim ile birlikte IoT gibi sektörel sıçramalar sonucunda ne kadar esnek ya da dinamik olduğumuzu / olabileceğimizi sorgular duruma geldik.
Mobil kategorisindeki yani hareket edilebilen kategorisindeki tüm dijital cihazların, gözlük, saat, araba gibi. Ya da ev ve iş yerlerimizde sabit olsalar da dijital dünyaya tamamen bağlanmış ya da bağlanması hedeflenen cihazların (IoT) olduğu bir dünya da esnekliği nasıl tanımalayabiliriz ki? Zamanla konunun derinliklerine indiğimizde burada sıralananların bile yetersiz olduğunu sadece özet olduğunu hep birlikte göreceğiz. Hatta bu manifestonun bile ötesine geçeceğimizi düşünüyorum.
Geldiğimiz noktada uçtan uca sorun ya da işlemlere çözüm üreten mimarilerin (client-server transaction’ları) yetersiz kaldığını ve kalacağını söylemeye bile gerek yok sanırım. Öyle bir noktadayız ki iki makine senkronize halde bir işlemi yaparken üçüncü bir işlemi yapma ihtiyacı ortaya çıkmakta ya da üçüncü bir makine diğer iki makineyi buna zorlamaktadır. – Reactive Programlama Nedir? makalemizdeki Kahveci – Kahve Alan – Tweet Atma örneği gibi –
Bu durumda klasik mimarilere yeni çözümler eklenmeli yeni yükseltmeler yapılmalıdır. Yani sonradan ortaya çıkabilecek ya da gündeme gelebilecek her değişikliğe hazır olmalıyız. Yani Reactive Programlama yeteneklerimizi geliştirmeliyiz. İlk olarak reaktif programalama ile neyi hedeflediğimize kısaca bir göz atalım.
update-güncelleme, upgrade-yükseltme olarak ele almayı tercih ediyorum.
Reactive Manifesto
Reaktif olarak geliştirilen sistemler daha esnek, gevşek bağlı ve ölçeklenebilir olmaktadır. Böylece uygulamaların daha kolay geliştirilebilir ve değişime açık olmasını sağlanmaktadır. Bu sistemler arızalara karşı çok daha toleranslı olmakla beraber arıza oluştuğunda felakete dönüşmesini önleyecek ve kullanıcılar ile etkileşim verimini maksimum düzeyde tutacak şekilde tasarlanırlar. Yani side effect’leri yönetme konusunda başarılıdırlar. Reactive Manifesto, uygulamaları aşağıdaki başlıklar altında inceleyerek uygulama kalitesini belirlemekte ve reaktifliğini ölçmektedir.
Reactive mimariye sahip uygulamalar ya da sistemler Responsive, Resillent, Elastic ve Message Driven olmalıdır.
Responsive
Reaktif sistem mümkün olan en anlamlı sürede yanıt vermelidir. Responsive, işe yarar ve kullanışlı bir sistem demektir. Ancak hataların hızlı tespit edilmesi ve çözüm üretilmesi ise sistemin responsivitesinde daha belirleyicidir. Responsive aslında hızlı, güvenli ve istikrarlı çözümlere verilmiş bir isimdir. Yani uygulama çalışma ortamında oluşabilecek iyi / kötü her duruma karşı ne kadar çok toleranslı ise o kadar iyidir ve kullanıcıya o kadar güven verir.
Resillent
Reaktif sistem hata anındada responsive’dir. Dirençli olma sistemin replikasyonu, kapsamı, izolasyonu ve delegasyonu ile sağlanır. Sistem bileşenlerinin birbirlerinden izole edilmesi; sistemin tamamını etkilemeden sadece arızalanan bileşenlerin onarılmasını sağlar. Her bileşenin onarımı başka bir (dışarıdan) bileşene havale edilmiştir ve gerektiğinde yüksek erişilebilirlik replikasyon ile sağlanır.
Günümüzde sadece Mission-Critic uygulamaların değil tüm uygulamaların hata durumlarına karşı toleranslı geliştirilmesi gerekiyor. Örneğin bir sunucu kapandığında ya da veri tabanı çöktüğünde sistem durdu diyemezsiniz. Muhakkak bir yedek planınız bir replikasyonunuz olmalıdır.
Elastic
Reaktif sistemler, gerektiğinde kaynakları artırarak ya da azaltarak uygulamadaki hareketliliği yönetecek şekilde tasarlanırlar. Örneğin X ,Y, Z servislerinden sadece Z’ye gelen yük artıyor ise bu yük dağılımını yöntecek bir tasarıma sahip olmalıyız. (Acaba bir microservice mi yazsak) Sunucu teknolojileri ya da bulut sistemler bu yük dağılımını otomatik yapsa da uygulama bunu tolere edebilecek Esnekliğe sahip olmalıdır. Ve bu esneklik herkesin ulaşabileceği maliyetlerde olmalıdır.
Message Driven
Reaktif sistemler, gerek uygulama bileşenleri arasında gerekse hata mesajları için Asenkron mesaj iletim yöntemini kullanmaktadır. Böylece mesaj kuyrukları olarak adlandırabileceğim arka arkaya üretilen mesajlar efektif bir şekilde yönetilir. Yani gerektiğinde yük yönetimi yapılarak mesajların doğru zamanda doğru yerde olması sağlanır. Aksi durumda uygulamada dar boğazlar oluşacak bazı işlemler block’lanacaktır. Kullanıcıların yalnızca etkin olduklarında kaynaklara erişmesine izin verilerek sistemin tıkanmasına engel olunur ve efektik kaynak tüketimi sağlanır.
Asenkron mesajlar için ActiveMQ, RabbitMQ gibi sistemler bulunmaktadır. Asenkron mekanizmalar hakkında ön bilgi sahibi olmak isteyenler bir göz atabilirler.
Unutumamak gerekir ki büyük sistemler küçük uygulamalardan oluşur. Bu nedenle küçük küçük yaratılan uygulamalar ne kadar Reactive yazılırsa büyük sistemler de o kadar Reactive olacaktır.
Yazı serimizde kısa zaman içerisinde reactive sistemlere canlı örneklerle adım adım derinlemesine dalacağız. Birkaç makale daha tanımlamalara devam edelim. Sanıyorum bundan sonraki makalede Functional Reactive Programming konusunu ele alacağız. Merakı olanların fonksiyonel programlamaya göz atmasında yarar var.
Kaynaklar: Reactive Manifesto