DEV Community: Caner Patır

DDD ve Mikroservis Kavramları Üzerine— Bounded Context Mikroservis İlişkisi ve Tutarlılık

Caner Patır — Sun, 15 Mar 2020 09:56:26 +0000

DDD ve Mikroservis Kavramları Üzerine— Bounded Context Mikroservis İlişkisi ve Tutarlılık

Bir önceki yazıda bounded contextlerin domaine ait iş kurallarının mantıksal sınırları olduğundan bahsetmiştik (bkz: DDD ve Mikroservis Kavramları üzerine — Bounded Context). Yani bounded contextleri modellerken business kuralları üzerinden konuşuruz. Mikroservis için ise altyapısal gereksinimler gözetilerek oluşturulmuş teknik sınırlardır diyebiliriz. Yani, ölçeklenebilirlik, erişilebilir, yönetilebilirlik gibi mimari konular önemlidir. Buradan yola çıkarak bounded contextler ve mikroservisler arasında bire bir ilişki kurmanın anlamlı olduğunu söyleyemeyiz. Yani bir bounded context bir servistir gibi bir kural yoktur. Bir servis bir bounded context olabileceği gibi bir bounded context birden fazla servisi kapsayabilir ya da bir servis birden fazla bounded contexti kapsayabilir.

Bounded contextin ürettiği asıl değer domain in farklı mantıksal alt birimleri içerisinde ortak bir dil oluşturmak ve bu sınırlar arasındaki ilişkiyi tanımlamaktır. Teknik ihtiyaçların öncelenmesi şartı ile servis sınırlarının belirlenmesi konusunda da etkili rol oynayabilir.

Ubiquitous Language

Bir kavramın farklı bounded contextler için sağladığı anlam farklı olabilir. E-ticaret domaininden örnek verecek olursak. Ürün kavramı, katalog bilgisi yöneten ekip için müşterinin satın alma deneyimini etkileyen, renk, beden, görsel gibi temel niteliklerin yönetimine dayalı iş kurallarını barındırır. Teslimat ekibi için ise sadece teslimatı sağlanacak bir paket içeriğidir ve renk, beden gibi özellik değerleri bu ekip için bir anlam ifade etmeyebilir. Burada, paketin en hızlı ve az maliyetli şekilde müşteriye ulaştırılması için gerekli iş kuralları önceliklidir.

Peki bu farklılık teknik anlamda geleneksel bir uygulamada ne ifade eder ?

Yukarıdaki görselden de faydalanarak, ilişkisel bir veri modeli üzerinde, product ve delivery nesnelerinin birbiri ile ilişkisel cebir (relational algebra) normalizasyon kuralları ile bağıntılı olduğunu gözlemlemekteyiz. DeliveryProduct tablosunda Product ve Delivery nesneleri arasındaki many-to-many ilişki olduğunu anlayabiliriz. Peki ya Product ve Delivery biribirinden bağımsız datastorelara sahip ayrı bounded context’ler içerisinde yer alsaydı modelleri nasıl ilişkilendirecektik?

Normalizasyon, ilişkisel veri modelinde bir düzenleme tekniğidir. Tablolardaki veri tekrarlarından ve insert, update, delete işlemleri esnasındaki tutarsızlıklardan kaçınabilmek için tabloları belli sistematiklerle ayrıştıran bir yaklaşımdır.

Madem product iki farklı bounded context için farklı anlam ifade ediyor öyleyse product nesnesini iki farklı context için tekrarlamakta bir kusur yok diyebilir miyiz?

Aşağıdaki görsele göre; P_roduct_ nesnesi iki contextte de yer almaktadır. Ancak içerisinde bulundukları context için farklı iş mantığı kurallarını barındırıyor olabilirler. Örneğin; delivery context için product, kilo, adet gibi sadece teslimat kurallarına hizmet eden nitelikleri bünyesinde barındıran bir değer tipi(value object) iken, product context için kategori bazlı özellikler barındıran, göresel içerik gibi konularda kendine has iş kuralları olan, katalog içeriğini oluşturan bir bileşen olabilir.

Veri tekrarından kaçınmak için karmaşık normalizasyon kurallarına ihtiyaç duyuyorken, neden iki farklı databasede aynı veriyi tutuyoruz? Veri tekrarı tutarlılıkla ilgili problemlerle başımızı ağrıtmaz mı? Herhangi bir product nesnesinin “name’’i değiştiğinde delivery servisindeki product bu durumdan nasıl etkilenir? Örneğin sitemizin ürün detay sayfasında gördüğümüz ürün başlığı ile sipariş detay sayfasında gördüğümüz başlık arasında farklılık oluşmayacak mı? gibi bir sürü soruya gelin birlikte cevap bulmaya çalışalım.

Product ve delivery farklı servisler olarak tasarladığımızı düşünelim. Bu servisler birbirinden bağımsız databaselere sahip olabilirler. Bu durumda, iki farklı servis içerisinde yer alan product nesnelerinde yapılacak değişiklikler bir transaction olmaksızın gerçekleşecek ve veri tutarlılığı ile ilgili çözülmesi gereken yeni problemleri beraberinde gelecektir.

Tutarlılık (Consistency): Tutarlılık, sistemi bir durumdan başka bir duruma geçirirken farklı sistem birleşenlerinin o durumla ilgili referans bütünlüğü sağlamasıdır. Örneğin, bir e-ticaret sisteminde kullanıcı bir ürün için başarılı bir sipariş kaydı oluşturdu ise aynı stoğu başka bir kullanıcıya da satmamak adına, ilgili ürüne ait stok bilgisinin sipariş miktarı kadar azaltılması beklenir.

Ancak, bu iki contextin business gereksinimleri açısından birbirinden ayrı olduğuna kanaat getirdiysek, product ve delivery birbirinden servis seviyesinde ayrılmalı mıdır? Doğru cevap yine yok :) Bu durum mikroservis dünyasının getirdiği problemlerden birisidir. Ancak şunu bilmeliyiz ki bu iki contexti business ihtiyaçları doğrultusunda ayırmamız, servis seviyesinde ayırmamız zorunluluğunu doğurmaz. Eğer servis seviyesinde bir ayrıştırma düşünüyorsak önceliklendirmemiz gereken konu ölçekleme gibi teknik ihtiyaçlardır. Örneğin; müşterilerin satın almadan çok kataloğunuzu gezme eğilimi gösterdiği zamanlarda product servisinizin daha fazla trafik aldığını gözlemleriz. Bu durumda product servisini ölçekleme zorunluluğu doğar. Kampanya gibi siparişin çok daha yoğun olduğu dönemlerde teslimat servislerinin ölçeklenmesi gerekir. Bu tarzda daha esnek bir ölçeklendirilebilirlik altyapısı istersek bu iki bileşeni servis olarak ayırabiliriz. Bu durum, ACID transactionlardan vazgeçmek zorunluluğu doğurabilir. Dolayısı ile tutarlılıkla ilgili yeni yaklaşımlara açık olmak gerekir. Önce tutarlılık neydi bir hatırlayalım.

Strong Consistency?

Geleneksel yaklaşımlarda tutarlılığı (consistency) sağlamak için atomic transactionlardan bolca faydalanırız. Transaction kapsamı içerisinde yapacağımız operasyonlar farklı nesneler üzerinde olsa bile atomik bir bütünlük içerisinde ele alınır. Böylelikle, sipariş kaydı oluşturuldu -> stock bilgisi güncellendi gibi bir operasyonda, “sipariş kaydı oluşturulamazsa stock bilgisi güncellenemez, stock bilgisi güncellenemezse sipariş kaydı oluşturulamaz” önermesini sağlamış oluruz. Operasyonlar topyekün olarak gerçekleşmiş olur (commit) ya da iptal edilir (rollback). Atomic transactionlar genelde database engine içerisinde ele alındığından, transaction kapsamı doğru tanımlandığı sürece bize bütünlük garantisi verir ve developerdan soyuttur. Veri bütünlüğünü düşünmek zorunda kalmayız. Database storage engine bunu bizim yerimize halleder.

Peki ama modelimizde stock ve siparişler ayrı bounded contextlerse ve bunları ayrı servisler olarak dizayn edersek, tutarlılık konusunu nasıl ele alırdık? Aslında dağıtık sistemlerin uzun yıllardır baş etmeye çalıştığı problemlerin, mikroservislerle birlikte uygulama seviyesine kadar çıktığını görmüş olduk. Ancak, yeni olmayan bu problemlerin -bütün düşünce tarzımızı değiştirmemiz gerekse de- çözümlerinin de var olduğunu biliyoruz. Burada eventual consistency kavramı hayatımıza giriyor.

Eventual Consistency?

Yukarıdaki sipariş adımlarını sepet durumunu da işin içerisine katarak genişletecek olursak. Örneğin: Sipariş kaydı oluşturuldu -> stock bilgisi güncellendi -> kullanıcı sepet içeriği güncellendi. Bunu daha fazla detaylandırıp sürecimize daha fazla adım ekleyebiliriz hatta ödeme sürecini de buna dahil edebiliriz. Ancak transaction sınırı (transaction boundry) genişledikçe, özünde birbirinden bağımsız hareket edebilecek contextlerin bir arada yaşama zorunluluğu ortaya çıkmış olur. Bu durumun, db lock’larından kaynaklı getirmiş olduğu performans problemlerini de beraberinde getirecektir. Üstelik, ödeme gibi harici bir sistemi (banka servisleri) dahil etmemizi gerektirecek bir süreç, aynı transaction kapsamı içerisinde ele almamız mümkün olmayan adımları da işlememizi gerektirebilir. O halde, sipariş, stok, sepet ve ödeme içerisindeki iş mantıklarını birbirinden ayırma yaklaşımına gidebiliriz. Ancak, artık db level transactionları bıraktığımıza göre tutarlılığı bir şekilde sağlamamız gerekecektir. Bu durumda eventual consistent yani nihai anlamda tutarlı bir sistem dizayn etmemiz gerekir.

Nihai tutarlılık, değişen bir veri öğesinin değerinin, yeterli süre verildiğinde, tüm birimlerde aynı olacak şekilde dağıtılmasına dayalı bir tutarlılık yaklaşımıdır. Buna göre, tüm birimlerdeki değer, en son yapılan güncellemeyle tutarlı olacaktır. Öte yandan, yeterli zaman geçmeden, verinin birden fazla noktada tutarsız olacağını göz önünde bulundurmak gerekir. Bu duruma gecikme (latency) denir ve sistemin diğer aktörlerinin de (örneğin diğer mikroservislerin) bu gecikmeyi gözetecek şekilde davranmasını sağlamak gerekir. Şunu unutmamalıyız ki nihai tutarlılık nokta atış bir çözüm değildir ve uygun durumlarda tercih edilmelidir. Yani nihai tutarlılığın tercih edildiği sistemin gecikmeleri tolere edilebilecek karakteristiğe sahip olması gerekir.

Mikroservisler gibi dağıtık bilgi işlem ortamlarında, CAP teoremi tutarlılık(consistency), erişilebilirlik(availability) ve bölünebilme toleransını(partition tolerance) aynı anda garanti etmenin imkansız olduğunu ve geliştiricinin kendisi için en önemli üç taneden ikisini seçmek zorunda olduğunu varsayar. Buna göre, nihai tutarlılıkla birlikte A ve P yi tercih etmiş oluruz.

Consistency(Tutarlılık): Dağıtık bir sistemde bir bileşene bir veri yazıldıktan sonra diğer bir bileşene bu verinin değeri sorulduğunda, bu bileşenin aynı değeri sağlayabilmesidir.

Availability(Erişebilirlik): Dağıtık bir sistemde, herhangi bir istemci bir değer sorduğunda o değerin herhangi bir versiyonuna mutlaka erişebilmelidir.

Partition Tolerance (Bölünebilme Toleransı): Sistem birbirinden bağımsız çalışabilen birimlere bölünebilmeli ve bu birimlerden birine herhangi bir sebepten erişilemese bile istemci gecikmeyle de olsa cevap alabilmelidir.

Sonuç

Servislerin sadece teknik ihtiyaçlar gözetilerek oluşturulması da yanlıştır. Bu tutum business açısından zayıf servisler ortaya çıkmasına neden olabilir. Business açısından hiçbir sorunu çözmeyen ama DevOps maliyeti oluşturan servisler istemeyiz.
Consistency ve partition tolerence mikroservis gibi dağıtık mimarilerde bir ödünleşmedir (trade-off). Consistency problemleri bazen çok pahalı olabilir dolayısı ile mimari bunu tolere edebilecek bütünlükte tasarlanmalıdır.

DDD ve Mikroservis Kavramları Üzerine — Bounded Context

Caner Patır — Sun, 15 Mar 2020 09:53:43 +0000

DDD ve Mikroservis Kavramları Üzerine — Bounded Context

Geleneksel iş yapma biçimlerinin yerini, rekabetçi ve yenilikçi teknolojik çözümlere bırakması ile birlikte şirketlerin iş süreçlerinin dijitalleşmesi gerekliliği ortaya çıktı. Bununla beraber şirketlerin teknoloji departmanlarına yatırım yapması kaçınılmazdı ancak hızlı büyüyen teknoloji ekiplerinin tek merkezli ( monolith ) uygulamalar üzerindeki hakimiyeti günden güne zorlaşıyor, code-base’ler kontrolden çıkacak şekilde büyüyordu. Bu da şirketleri ölçeklenebilirlikten , test ve refactor edilebilirlikten uzaklaşmış yazılım sistemleri ile baş başa bırakmıştı. Bu durum firmaların değişen iş ihtiyaçlarına hızlı adapte olmama problemi ile yüzleşmesine neden oldu. Gelişime dirençli ve yüksek maliyetli yazılım sistemleri, firmaları rekabette epeyce geriye düşürüyordu. Bazı büyük teknoloji firmalarının önderliğinde, büyük uygulamaları farklı küçük servislere ayrıştıran service oriented architecture (SOA) yaklaşımı ortaya atıldı. Bu, büyük bir yazılım projesini daha iyi yönetilebilir küçük parçalara bölmeye dayalı mimarisel bir çözümdü. Ancak SOA, takip eden yıllarda yerini, kendi başına deploy edilebilen ( fine grained ), birbirine zayıf bağımlılıklara bağlı ( loosly coupled ) servislerden oluşan mikroservis yaklaşımına evrildi.

Bu yaklaşımla hedeflenen;

Kolay yönetilebilir (light weight) code-base’e sahip olmak
Test edilebilirliği (testibility) arttırmak,
Ölçeklenebilirliği (scalability) arttırmak,
Esnekliği (felxibility) arttırmak,
Yüksek erişilebilirliği (highly availability) sağlamak,
Yeni özellikleri hızlıca release edebilmek (time to market),
Organizasyonel yapı ile yazılım sistemi arasındaki uyumu sağlamaktı.

Mikroservis yaklaşımı ile birlikte “teoride” yüzlerce yazılım mühendisi aynı projenin farklı modüllerinde paralel olarak çalışabilir, servisler birbirinden bağımsız olarak deploy edebilebiir, uygulamaların farklı modülleri farklı stratejiler ile ölçeklendirilebilir ve yeni bir gereksinim oluştuğunda sistemin küçük bir parçasında yapılan değişiklik ile iş gereksinimleri pazara çok hızlı bir şekilde çıkabilir. Ancak, kulağa hoş gelen bu değerleri üretebilmek için büyük ekiplerin, iş kuralları ve teknolojik gereksinimleri konusunda, nasıl organize olacağına dair bir sistematiğe, fikir birliğine ve ortak bir iletişim diline sahip olması gerekir. İşte tam burada domain driven design (DDD) disiplini yazılım mühendislerine yeni yöntemler sunuyor.

Domain Driven Design (DDD)?

Bu kavramı anlamak için öncelikle “domain nedir” sorusuna güvenilebilir bir cevap vermek gerekir. Yazılımları gerçek dünya problemlerine çözüm üreten ve tekrar tekrar kullanılabilen makina prosedürleri olarak tanımlayabiliriz. Bahsettiğimiz bu “gerçek dünya problemi”’nin çözümüne dair bilgi birikimine domain yani etki alanı denir. Örneğin bir ürünün, internet üzerinden en hızlı şekilde ve en uygun fiyat ile tüketiciye ulaştırılabilmesi problemi e-ticaret domainine ait bir problemdir. DDD ise bu bilgi birikimini daha çok açığa çıkararak, karmaşık domain probleminin çözümünü belli bir sistematiğe göre yazılımsal olarak modellemeyi sağlayan bir disiplindir.

Yüksek işbirliğine ihtiyaç duyulan ve doğası gereği belli bir karmaşıklık barındıran etki alanlarına collaborative domain denmektedir. Genel olarak, DDD’nin bu karakteristiğe ait domain’ler için daha uygun bir çözüm olduğu kanısı hakimdir.

DDD’nin stratejik ve taktiksel olmak üzere iki ayrı aşaması vardır. Stratejik DDD’de, iş kurallarına bağlı kalarak sistemin büyük ölçekli modelini tanımlarız. Stratejik DDD, birbirine gevşek bağlı birimleri ( bounded context ) ve bunlar arasındaki ilişkiyi ( context map ) tasarlamayı sağlayan disiplinleri belirler. Taktik DDD, implementasyona odaklanır ve yazılımsal implementasyonu oluşturmak için kullanabileceğimiz tasarım desenlerini sağlar. Bu tasarım desenleri entity, aggregate, value object, repository ve domain service gibi kavramları içerir (ki bu yazıda taktik patternlerin detayına girmeyeceğiz — bunla ilgili başka bir post yayınlamayı düşünüyorum).

DDD’nin üretttiği en önemli değer değişen iş kuralları üzerinde ortak bir dil oluşturarak büyük teknoloji ekipleri arasındaki iş birliğini ( collobration ) arttırmaktır. DDD domaini kendine ait ortak bir dil barındıran, sınırları belirli, bağımsız bileşenlere ayıran bir yaklaşımı belirler. Oluşan bu ortak dile ubiquitous language, bağımsız birimlere ise bounded context denir. Bounded context DDD için modelleme açısından en önemli kavramlardan biridir ve DDD ile ilgili kaynaklarda sıkça karşılaşacağımız bir kavramdır. Gelin bunu detaylandıralım.

Bounded Context?

Karmaşık bir problemin çözümünden uyguladığımız yöntem, genellikle problemi daha küçük parçalara bölmek ve nispeten daha kolay olan bu küçük problemlere odaklanmaktır. Bounded context için karmaşık domain’in -kendi içinde tutarlı ve mümkün olduğunca bağımsız- daha küçük problem parçacıklarını temsil eden mantıksal sınırlardır (logical boundry) diyebiliriz. DDD’nin stratejik design başlığı altında yer alır ve bu yönüyle modelleme evresinde ortaya çıkan bir kavramdır. Contextler belirlenirken birbirine daha az bağımlı, birbirinden izole ve herbirinin otonom olması gibi değerler önceliklidir.

Bounded Context sınırlarını nasıl belirleriz?

Bounded context’lerin belirlenmesi konusu DDD’nin stratejik tasarım ( strategic design ) evresini ilgilendiren bir konudur. Stratejik tasarım evresi modelleme işnin yapıldığı süreçtir ve implementasyondan bağımsız bir konudur.

Bu süreç çoğu kaynakta context discovery olarak belirtilir. Dolayısı ile bir keşif serüvenidir diyebiliriz. Bu yönüyle baktığımızda, context boundary’lerin reçetesi veya nokta atışı bir yöntemi olduğundan bahsedemeyiz. Bu konuyla ilgili olarak çoğu DDD mecrasında heuristic ifadesini görebilirsiniz. Bu, hissiyati ya da içgüdüsel anlamına gelir. Yani bu süreç, business ihtiyaçları, modellemeyi yapan insanlar, teknik kısıtlar, ekip içi iletişim gibi bir sürü parametreye bağlıdır. Ancak, modelleme sürecinin tamamı ile belirsiz bir hal almaması için DDD dünyası bazı önemli konulara işaret eder.

Domain knowledge (Domain yetkinliği): Doğru bir model için önce problemin doğru anlaşılması ve analiz edilmesi gerekir. Ayrıca, farklı domainler kendine has iş kuralları barındırır. Bu kuralları doğru anlamak, saklı olanları da açığa çıkarabilmek için işbirliği ve iterasyon büyük önem taşır.

Collobration (İşbirliği): Doğru modeli bize hazır halde sunan bir araç olmadığına göre, bu süreç insanlar tarafından yürütülecektir. Doğru model için daha fazla domain knowledege, bunun için de farklı bakış açısı ve vizyonlar gerekir. Ancak bu durum modelleme sürecine her önümüze geleni dahil edeceğimiz anlamına gelmez. Etkili bir model için sürecin domain uzmanları ( domain expert ) tarafından yönlendirilmesi önemlidir. Domain expert kavramı bir rol ya da title değildir. Problemi çok iyi anlamış hatta o problemi yaşayan biri olabilir. Buradan yola çıkarak domain expert olarak en iyi örnek aslında müşterinin ta kendisidir diyebiliriz.

Iteration (Tekerrür): Modellemenin bir keşif serüveni olduğundan bahsettik. Ancak bu keşif mükemmeli aramak değildir. Mükemmel modeli aramaktansa, modelimizdeki eksikleri zaman içerisinde iyileştirmek, ürünün pazara daha hızlı çıkması açısından ( time to market ) akılcı bir yaklaşımdır. Gelişen pazar koşullarına bağlı iş kurallarının da sürekli değiştiğini hesaba katarsak, modelin bir kere belirlendikten sonra, bir daha asla değişmeyeceğinden bahsedemeyiz. Domain uzmanları ile iletişim içerisinde modelimizi sürekli geliştirmeliyiz. Teknik bakış açısıyla DDD’nin continuous refactoring ve continuous delivery konularına da dokunduğundan bahsedebiliriz.

Diğer bir önemli etken de organizasyondur. Sistemleri yapanlar organizasyonlardır ve iletişim alışkanlıkları yaptıkları çözüme yansır (bkz. Conway’s law). Bu duruma kanıt olarak, benzer işi yapan iki farklı şirkete baktığımızda, aynı problemi çözüyor olsalar bile yazılımsal modelin farklılıklar gösterdiğini görebiliriz.

Sonuç

DDD, kompleks domainlerde uygulandığında fayda üreten bir pratiktir.
DDD’nin strategic design evresinde domain knowledge, doğru modelleme için büyük önem taşır.
Domain knowledge açığa çıkarmak için domain expertler ile birlikte çalışmak gerekir.
DDD, collobrative bir yöntemdir domain expertler ve teknik ekipler arasında güçlü bir iletişim sağlanmalıdır.
DDD, mikroservis gibi mimarisel yaklaşımlarda yönlendirici olabilir ancak belirleyici unsur değildir. Servis sınırları teknik concernler öncelenerek oluşturulur.

Yazının devamı — DDD ve Mikroservis Kavramları Üzerine — Bounded Context Mikroservis İlişkisi ve Tutarlılık

Kotlin Coroutine — Asenkron ve Paralel Programlama

Caner Patır — Wed, 18 Sep 2019 13:42:18 +0000

Kotlin Coroutine — Asenkron ve Paralel Programlama

Asenkron ve paralel programlama farklı teknoloji ekosistemlerinde farklı anlamlar ifade ettiği için yazıya başlamadan önce bu kavramlara açıklık getirmek istiyorum.

Paralel programlama (Parallelism)

Bir görevin paralel olarak işlenebilecek daha küçük alt görevlere ayrılarak birden fazla CPU’da, threadler vasıtası ile, paralel olarak yürütülmesi anlamına gelir. Paralel işlemler gereken veri ve kaynak bakımından biribirinden bağımsızdır ve çoğunlukla senkronizasyona ihtiyaç duymazlar. Örnek verecek olursak… bir veri kaynağından (DB, filesystem vs.) idendifier’larını bildiğimiz bir veri seti okuyacaksak, bunları belli parçalara bölüp parallel bir şekilde toplayabiliriz.

Asenkron programlama (Concurrency)

Bir uygulamanın aynı anda (concurrency) birden fazla görevde ilerleme kaydettiği anlamına gelir. Ancak bu işler paralel olarak farklı thread lerde işlenmeyebilir. Uzun süren IO görevlerinin CPU’yu bloklamamsı amacıyla kullanılır (non-blocking IO). Bir threadde IO işlemi sürerken o threadin bloklanmayarak, başka görevlere tahsis edilmesi ve CPU’nun yüksek utilizasyon ile kullanılması esasına dayalı bir görevdir. Bunu context switch teknikleri kullanarak sağlar. Bu yöntemin uygulanmasındaki zorluk alt görevler arasındaki senkronizasyonu sağlamaktır. Modern programlama dilleri senkronizasyon problemine derleyici seviyesinde çözümler üretmiştir.

Kotlin programlama dili bu yöntemi sağlayabilmek için coroutine denen bir yapı sunar. Coroutine’ler alt görevleri temsil eder ve dispatcher denen bir yapı vasıtası ile görevler arasındaki senkronizasyon sağlanır. . Özetle, dispatcher threadlerin görevler arasında paylaşımı yani context switch işinden sorumludur.

Yazımın devam eden kısmında Kotlin coroutine ile nasıl asenkron programlama yapabileceğimizden bahsedeceğim.

Coroutine nedir ?

Öncelikle belirtmem gereken konu, coroutine’lerin thread olmadığıdır. Kotlin ekibi coroutine’leri “ lightweight thread ” olarak tanımlasa da bu tanım communitynin algısına girebilmek için kullanılan bir benzetmedir. Coroutinei tanımlamak istersek thread tarafından yürütülen görev parçalarıdır diyebiliriz. Başlıktaki gif’den de anlaşılabileceği gibi herhangi bir thread x anında bir coroutine’i alıp işletebilir. Ancak bu threadin ilgili coroutine’i bitene kadar bekleyeceği anlamına gelmez. Bloklayıcı bir bölüme gelindiğinde (suspension point) thread coroutine’i bırakır ve başka bir coroutine’i işletmeye başlayabilir (context switch). Suspend olan görev, işini bitirdiğinde tekrar başka bir thread tarafından işletimine devam edilebilir. Böylelikle thread’ler bloklanmadan verimli bir şekilde kullanılmış olur. Bunu CoroutineDispatcher organize eder. CoroutineDispatcher context switching için suspend keyword’ü ile etiketlenmiş özel function’ ları kullanır. Coroutine ile kod örneklerine geçmeden önce suspend functionların iyi anlaşılması gerekmektedir.

Suspend function

Coroutine’lerin belli suspension pointlerde context switche girdiğinden bahsetmiştim. Bu noktaları derleyiciye geliştirici kendi deklare etmek durumundadır. Bu deklarasyonlar ilgili methodu suspend keywordü ile etiketleyerek sağlanır.

Özetle; suspend functionlar, mevcut threadi bloke etmeden coroutinin yürütülmesini askıya alır. Böylelikle thread başka bir corutinenin işletilmesine başlar ve cpu daha verimli bir şekilde kullanılmış olur.

Suspend functionlarla ilgili bir başka bilinmesi gereken konu da sıralı işletildikleridir. Yani dönüş değeri almadan ya da kodun geri kalanını çalıştırmadan önce, çağrılan suspend functionın yürütülmesini beklememiz gerekir. Bu durum asenkron operasyonların Kotlin ile ne denli kolay olduğuna bir kanıt niteliğindedir. Özetle, asenkron kod yazımının, normal yazımdan hiçbir farkı yoktur.

operation1 done after 1 second
operation2 done after 2 seconds and result: hello

Suspend functionlar diğer dillerin asenkron yazımdan farklı olarak, geriye özel veri tipleri dönmek zorunda değillerdir.

Java — Future, Flux, Mono, Single, Observable ve binlercesi :)
Javascrip t— Promise
C# — Task

Yeni bir coroutine başlatma

Kotlin standart kütüphanesi, coroutine başlatmak için coroutine builder denen yapıları barındırır. Coroutine builder, belirli bir suspend fonksiyonu sarmalayan ve işletilmesini sağlayan fonksiyonlardır. Yani, yeni bir coroutine başlatmak için kullanırız. Bunlardan başlıcalarına göz atacak olursak.

CoroutineScope.Async

Geriye değer dönen asenkron operasyonların işletilmesi için kullanılır. Beklenen sonucu almak için Deffered dönüş tipi kullanır. Deferred, Javadaki Future veya Javascript dilindeki Promise in karşılığıdır diyebiliriz_._ Sonucu beklemek için Deffered sonucun await methodunu çağırmak gerkir. Await bir suspend functiondır.

CoroutineScope.Launch

Geriye dönüş tipi gerektirmeyen, arka planda işletilecek operasyonlar için kullanılan builder tipidir. Fire and forget mantığı ile çalışabilecek işler için uygundur.

Hello World!

Runblocking

İlgili coroutine tamamlanana kadar, mevcut threadin bloke edilmesini sağlar. Coroutine içerisinde kullanılmamalıdır. Genelde blocking tarzda yazılmış koda coroutine scope bağlamak için ya da test amaçlı kullanılır. Yani normal dünya ile suspending dünya arasında köprü görevi görür. Bütün kod bloğu uçtan uca non-blocking tarzda yazılmışsa kullanımına gerek yoktur.

Kotlin ekibi coroutine scope içerisinde thread bloklayacak yaklaşımlardan kaçınılmasını önerir. Bu sebeple, runBlocking’in coroutine içerisinde kullanmaktan kaçınmalıyız. Eğer runBlocking kullanılacaksa, hiyerarşide daima en tepede yer almalıdır.

Eşzamanlı İşletim

Coroutineler eş zamanlı işletime de olanak sağlar. Aşağıdaki kod örneğinde eş zamanlı ve sıralı işletimin karşılaştırmasını görebilirsiniz.

operation1: 247 ms
operation2: 5112 ms

Dispatcher — I/O ve CPU bağımlı işler

Kotlin coroutine altyapısında dispatcher denen nesneler vasıtasıyla senkronizasyon yaptığından bahsetmiştik. Dispatcherların reactive frameworklerdeki (örn: rxJava) scheduler nesnesine karşılık geldiğini düşünebiliriz. Corotuineler CPU açısından hiçbir anlam ifade etmeyen basit görev abstractionlarıdır. Dispatcher, coroutin yürütmesinden sorumludur t anında bir coroutine’i alıp threadpoolda bir threade atayarak işletilmesini sağlar ve gerektiğinde coroutine’i suspend ederek threadin başka bir coroutine yürütmesini sağlayabilir. Bu bağlamda, dispatcherlar coroutine’leri CPU için anlamlı hale getirmiş olur diyebiliriz.

Ancak burada dikkat edilmesi gereken nokta ilgili işin networkden ya da filesystemden okuma yazma yapan I/O ağarlıklı bir iş mi yoksa yüksek aritmetik ve mantıksal operasyon barındıran CPU intensive bir iş mi olduğudur. Kotlin coroutine bu tip operasyonları I/O ya da CPU yoğun işlere özelleşmiş thread poollarda ele alır. Kotlin’e ilgili coroutine’in hangi kapsamda ele alıncağının bildirilmesi yazılım geliştiricinin sorumluluğundadır. Bunun için Kotlin, kotlinx.coroutines paketi içerisinde aşağıdaki öntanımlı dispatcherları barındırır.

Dispatchers.Default : Herhangi bir dispatcher belirtilmemişse, tüm coroutine üreticileri tarafından kullanılan varsayılan dispatcherdır. CPU yoğun görevlerin yürütülmesi için uygun seçimdir. (RxJava’daki Schedulers.Computation)
Dispatchers.IO : I/O yoğun işlemler için kullanılır. ( RxJava’daki Schedulers.IO)

I/O yoğun işe örnek olarak databaseden yaptığımız okuma yazmaları veya http çağrılarını, CPU yoğun işe ise hash operasyonu ya da görsel işlemeyi örnek gösterebiliriz. Eğer kurumsal bir uygulama geliştiriyorsak ağırlıklı olarak databaseden okuma yazma yaparız bu da I/O yoğun bir uygulamamız olduğu anlamına gelir. Yazımın önceki bölümlerinde bir I/O işlemi sürerken, threadin bloke edilmeksizin başka kaynaklara tahsis edilebileceğinden bahsetmiştim. Coroutine ile hedeflenen tam da budur ve bu durum coroutine kullanımının kurumsal uygulamalar için oldukça mantıklı olduğu anlamına gelir.

CPU bloklayan bir IO operasyonu

Non-Blocking IO operasyonu

Özet

Asenkron işlemler günümüzde çoğu yazılım geliştiricinin bir şekilde içerisinde yer aldığı ya da farkında olmadan yer almak zorunda olduğu bir durumdur. Örneğin, bir web uygulaması geliştiriyorsak concurrency bizim için kritiktir. İstemcilere sağlıklı bir hizmet verebilmek için, uygulamamızın birim zamanda karşılayabildiği istek sayısını ( throughput ) en yüksekte tutmamız gerekir. Veya bir client uygulaması geliştiriyorsak, kullanıcı deneyimi açısından, arkaplanda yaptığımız işlemlerin kullanıcının UI üzerinde yaptığı işlemleri bloke etmemesini sağlamamız gerekir. Önceleri bu problemlerin çözümü için multi-threading tekniklerini kullansak da senkronizasyon problemi ve kullanımdaki zorluklar, yazılım endüstrisini bu konuda yeni çözümlerin arayışına itmiştir. Bu bağlamda, java ekosisteminde rxJava , Spring’de Reactor , c#’da async/awai t, Golang’da goroutine gibi daha yüksek seviye çözümler yazılım geliştiricilerin hizmetine sunuldu. Bütün bu çözümlerin ortak noktası yazılım geliştiriciyi karmaşık thread operasyonlarından soyutlayarak, önceden optimize edilmiş bir ortam sunmaktır. Kotlin ekibinin sunduğu çözüm ise coroutine olmuştur. Yazımda kotlin coroutine kullanımına ve kavramlara dair genel bilgiler vermek istedim. Kotlin coroutine’leri kullanarak, I/O ağırlıklı bir uygulamanın, aynı kaynak kullanılarak daha fazla istek karşılayabilmesini sağlayabiliriz. Bunu uygulamasını ve karşılaştırmalı yük testlerini, önümüzdeki haftalarda yeni bir medium postu ile paylaşacağım. Yeni yazımda görüşene dek şimdilik hoşçakalın :)