<\/div>\n

Merhaba,<\/p>\n

Biliyorsunuz ki, yaz\u0131l\u0131msal operasyonlarda belirli senaryolarla ba\u015f edebilmek i\u00e7in tecr\u00fcbevi birikim olarak yaz\u0131l\u0131mc\u0131lar taraf\u0131ndan tatiksel tan\u0131mlanm\u0131\u015f design pattern stratejilerinden istifade etmekteyiz. Design pattern uyarl\u0131l\u0131\u011f\u0131 microservice yap\u0131lanmalar\u0131nda da varl\u0131\u011f\u0131n\u0131 g\u00f6stermekte ve ya\u015fan\u0131lan problemlerde \u00e7\u00f6z\u00fcm olarak imdad\u0131m\u0131za yeti\u015fmektedir. Bu i\u00e7eri\u011fimizde, microservice yap\u0131lanmalar\u0131nda en kritik konulardan birisi olan distributed transaction senaryolar\u0131nda servisler aras\u0131 veri tutarl\u0131l\u0131\u011f\u0131n\u0131 sa\u011flamam\u0131za imkan veren Saga Pattern<\/strong><\/em> \u00fczerine konu\u015fuyor olaca\u011f\u0131z. Tabi makale seyri boyunca acele etmeyecek ve Saga Pattern nedir? Ne \u015fekilde uygulanmaktad\u0131r?<\/span> gibi sorular\u0131 cevapland\u0131rmaya ba\u015flamadan \u00f6nce pergeli do\u011fru noktaya koyarak transaction kavram\u0131 \u00fczerinden s\u0131n\u0131rlar\u0131m\u0131z\u0131 \u00e7izmeye ba\u015flayaca\u011f\u0131z. Ard\u0131ndan distributed transaction kavram\u0131n\u0131 anlayabilmek i\u00e7in \u00f6ncelikle servis ba\u015f\u0131na veritaban\u0131 prensibi \u00fczerinde isti\u015farede bulunaca\u011f\u0131z. Devam\u0131nda ise verisel a\u00e7\u0131dan yap\u0131lan de\u011fi\u015fikliklerin veritabanlar\u0131 \u00fczerinde hangi prensipler do\u011frultusunda uygulanaca\u011f\u0131n\u0131(ACID) a\u00e7t\u0131ktan sonra art\u0131k neden Saga Pattern’a ihtiyac\u0131m\u0131z oldu\u011funu netle\u015ftirmi\u015f olaca\u011f\u0131z. Nihayetinde as\u0131l konumuz olan Saga Pattern’\u0131n detaylar\u0131na girecek ve kavramsal olarak nelerden olu\u015ftu\u011funu inceledikten sonra teknik a\u00e7\u0131dan anotomisini inceleyece\u011fiz. Yani anlayaca\u011f\u0131n\u0131z, uzun ama bir o kadar da \u00f6\u011fretici bir i\u00e7erik bizi bekliyor olacak \ud83d\ude42 Eee o zaman hi\u00e7 vakit kaybetmeden buyrun ba\u015flayal\u0131m…<\/p>\n

Bu Makalenin Konusu Nedir?<\/h5>\n
Her \u015feyden \u00f6nce bu i\u00e7erikte neyin anlat\u0131lmaya \u00e7al\u0131\u015f\u0131ld\u0131\u011f\u0131n\u0131 anlayarak ba\u015flayal\u0131m. Biliyorsunuz ki, microservice mimarilerinde ideal olarak her bir servisin kendine ait bir veritaban\u0131 olmas\u0131 gerekmektedir.(E\u011fer bilmiyorsan\u0131z art\u0131k \u00f6\u011frenmi\u015f oldunuz \ud83d\ude42 Ger\u00e7i aceleci davranmaya gerek yok. Bu ideal karar\u0131 birazdan ayr\u0131 bir ba\u015fl\u0131k alt\u0131nda e\u011frisi ve do\u011frusuyla de\u011ferlendiriyor olaca\u011f\u0131z.)<\/span> \u0130\u015fte bu birden fazla servise da\u011f\u0131t\u0131lm\u0131\u015f veritaban\u0131 sistemi distributed transaction<\/em> olarak nitelendirilmektedir. (Keza bu kavram\u0131 da ayr\u0131 ba\u015fl\u0131k alt\u0131nda daha da detayland\u0131r\u0131yor olaca\u011f\u0131z.)<\/span> Her servisin kendine ait bir veritaban\u0131 olmas\u0131 dolay\u0131s\u0131yla bu veritabanlar\u0131n aras\u0131nda yap\u0131lan i\u015fe\/hizmete g\u00f6re b\u00fct\u00fcnsel bir veri tutarl\u0131l\u0131\u011f\u0131n\u0131n sa\u011flanmas\u0131n\u0131 gerektirmektedir. Ee haliyle bu durumda gayet do\u011fald\u0131r, \u00f6yle de\u011fil mi? Yani bir yaz\u0131l\u0131m projesinde birden fazla veritaban\u0131 kullan\u0131l\u0131yorsa e\u011fer bu veritabanlar\u0131ndaki verilerin b\u00fct\u00fcnsel a\u00e7\u0131dan tutarl\u0131 olmas\u0131n\u0131 beklemek i\u015fin do\u011fas\u0131nda vard\u0131r.<\/p>\n
Bu durumu \u015f\u00f6yle bir \u00f6rnekle zihinlerimizde tahayy\u00fcl edelim; farz edelim ki bir e-ticaret yaz\u0131l\u0131m\u0131 geli\u015ftiriyoruz. Bu yaz\u0131l\u0131m\u0131n sipari\u015f alma i\u015flemlerini ‘Order’, sipari\u015ften sonra stok i\u015flemlerini ‘Stock’ ve son olarak da \u00f6deme i\u015flemlerini ‘Payment’ servislerinde yapt\u0131\u011f\u0131m\u0131z\u0131 d\u00fc\u015f\u00fcnelim. Tabi ki de t\u00fcm bu servisin yukar\u0131 paragraflarda hafiften \u00e7\u0131tlatt\u0131\u011f\u0131m\u0131z gibi kendilerine ait veritabanlar\u0131 oldu\u011funu d\u00fc\u015f\u00fcnelim ve senaryotik a\u00e7\u0131dan i\u015flemlerin \u015fu \u015fekilde seyr etti\u011fini farz edelim :<\/p>\n
Kullan\u0131c\u0131 herhangi bir \u00fcr\u00fcne dair sipari\u015f verdi\u011finde ‘Order’ servisi bu i\u015flemi ger\u00e7ekle\u015ftirecek ve kendi veritaban\u0131na ekleyecektir. ‘Payment’ servisi ise \u00f6demeyi sa\u011flayacak ve \u00f6deme ba\u015far\u0131l\u0131ysa ‘Stock’ servisinde ki ilgili \u00fcr\u00fcne kar\u015f\u0131l\u0131k gelen stok miktar\u0131n\u0131 d\u00fc\u015f\u00fcrecektir.<\/em><\/div>\n
\u015eimdi bu i\u015flem seyrinde, ‘Order’ servisi gelen sipari\u015fi olu\u015fturduktan sonra ‘Payment’ servisi o sipari\u015fe dair \u00f6demeyi ba\u015far\u0131l\u0131 ger\u00e7ekle\u015ftirirse e\u011fer ‘Stock’ servisinde sipari\u015fteki ilgili \u00fcr\u00fcne dair stok adedinin d\u00fc\u015f\u00fcr\u00fclmesi gerekmektedir. Aksi taktirde bir tutars\u0131zl\u0131k meydana gelecektir. D\u00fc\u015f\u00fcnsenize, sipari\u015f verilip \u00f6deme yap\u0131ld\u0131ktan sonra hala stok miktar\u0131 ayn\u0131 kalmaktad\u0131r. Bu durumun yaz\u0131l\u0131mdaki verisel istatistiklere ve o yaz\u0131l\u0131m\u0131 kullanan i\u015fletmeye verdi\u011fi zarar\u0131 d\u00fc\u015f\u00fcn\u00fcn!<\/p>\n
\u0130\u015fte bizim birden fazla serviste birden fazla veritaban\u0131yla \u00e7al\u0131\u015f\u0131lmas\u0131(distributed transaction) durumlar\u0131nda veri tutarl\u0131l\u0131\u011f\u0131ndan kast\u0131m\u0131z budur. Haliyle bu i\u00e7eri\u011fimizde distributed transaction senaryolar\u0131nda bu bahsedilen veri tutarl\u0131l\u0131\u011f\u0131n\u0131n sa\u011flanabilmesi i\u00e7in \u00f6nerilen \u00e7\u00f6z\u00fcmlerden biri olan Saga pattern’\u0131n\u0131n\u0131 inceliyor olaca\u011f\u0131z.<\/p>\n
Transaction, Distributed Transaction ve Compensable Transactions Nedir?<\/h5>\n
Evet, \u015fimdi teorik olarak bu makaleyi daha da iyi anlayabilmek i\u00e7in gerekli olan temel kavramlar\u0131 inceleyebiliriz. \u0130lk olarak transaction kavram\u0131na de\u011finerek ba\u015flayaca\u011f\u0131z.<\/p>\n
\n
Transaction<\/em><\/strong>
\nTransaction, bilindi\u011fi \u00fczere veritaban\u0131 \u00fczerinde yap\u0131lan t\u00fcm i\u015flemlere verilen genel isimdir. Bu duruma genellikle banka sistemleri \u00fczerinden \u00f6rneklendirme yap\u0131lmakla beraber ben deniz sizlerin konuya vak\u0131f oldu\u011funuzu d\u00fc\u015f\u00fcnerek bo\u011fmamaks\u0131z\u0131n detayland\u0131rmay\u0131 es ge\u00e7mekteyim. Yine de transaction’a dair herhangi bir fikri olmayanlar tee zaman\u0131nda yazd\u0131\u011f\u0131m Transact Sql-Transaction<\/a> ba\u015fl\u0131kl\u0131 makalemi okuyabilirler. Aradan y\u0131llar ge\u00e7mesine ra\u011fmen transaction’a dair pek bi\u015fey de\u011fi\u015fmemi\u015f diyebilmekteyiz.\n<\/li>\n
Distributed Transaction<\/em><\/strong>
\nDistributed Transaction’a gelirsek e\u011fer bu bizim i\u00e7in \u00f6nemlidir. Birden fazla farkl\u0131 veritaban\u0131n\u0131n bir b\u00fct\u00fcn olarak \u00e7al\u0131\u015ft\u0131\u011f\u0131 durumu ifade eden bu terim ad\u0131 \u00fczerinde da\u011f\u0131t\u0131lm\u0131\u015f veritaban\u0131 sistemleri i\u00e7in kullan\u0131lmaktad\u0131r. Genellikle microservice gibi yakla\u015f\u0131mlarda her bir servisin kendi veritaban\u0131n\u0131 ta\u015f\u0131mas\u0131 distributed transaction olarak nitelendirilir.\n<\/li>\n
Compensable Transaction<\/em><\/strong>
\nCompensable Transaction ise, bir transaction’\u0131n yapm\u0131\u015f oldu\u011fu i\u015flemin tersini almakt\u0131r. Yani commit edilen bir i\u015flemin geriye d\u00f6n\u00fckl\u00fc\u011f\u00fc bu saatten sonra ancak telafi ile m\u00fcmk\u00fcnd\u00fcr. \u0130\u015fte bu geri d\u00f6n\u00fck telafi i\u015flemine compensable transactions denmektedir. Misal olarak; ‘A’ servisi yapm\u0131\u015f oldu\u011fu bir i\u015flemi ‘B’ servisindeki duruma g\u00f6re iptal etmek zorundaysa ‘A’ servisi bunu ancak yap\u0131lan i\u015fin tam tersini alarak ger\u00e7ekle\u015ftirebilmektedir. \u00d6rne\u011fin, 100 de\u011ferine +10 eklendiyse, bu i\u015flemin iptali -10 eklenmesidir. Bu kavram\u0131n teknik olarak Saga pattern’\u0131n da \u00e7ok kullan\u0131ld\u0131\u011f\u0131n\u0131 g\u00f6receksiniz.<\/p>\n
$\"Microservice$ <\/a>
\u00d6rnek bir Compensable Transaction \u015femas\u0131.<\/p><\/div>Yukar\u0131daki \u015fema \u00fczerinden compensable transaction’\u0131 yorumlarsak e\u011fer; g\u00f6r\u00fcld\u00fc\u011f\u00fc \u00fczere ‘customer’ yapt\u0131\u011f\u0131 al\u0131\u015fveri\u015f neticesinde n<\/em> liral\u0131k \u00f6deme talimat\u0131n\u0131 ‘issuing bank’a vermekte ve ilgili bankadan ‘acquiring bank’a belirtilen miktarda para g\u00f6nderilmektedir. Haliyle ilk etapta ‘issuing bank’tan -n<\/em> lira eksilirken akabinde herhangi bir s\u0131k\u0131nt\u0131 s\u00f6z konusu de\u011filse ‘acquiring bank’a n<\/em> lira + olarak yans\u0131yacakt\u0131r. E\u011fer s\u0131k\u0131nt\u0131 s\u00f6z konusu olursa yap\u0131lan i\u015flemler geri al\u0131nacak ve ‘issuing bank’tan al\u0131nan n<\/em> lira + olarak geri y\u00fcklenecektir. Benzer mant\u0131kta g\u00f6nderilen para ‘merchant’a eri\u015fim g\u00f6steriyorsa aradaki t\u00fcm servislerin transaction’lar\u0131 do\u011frulanacak aksi taktirde ya\u015fanacak herhangi bir aksi durumda t\u00fcm servislerdeki transaction’lar da yap\u0131lan t\u00fcm i\u015flemlerin tersi al\u0131narak telafi sa\u011flanm\u0131\u015f olacakt\u0131r. \u0130\u015fte burada her olumsuz duruma istinaden t\u00fcm servislerdeki yap\u0131lan \u00e7al\u0131\u015fmalar\u0131n geri al\u0131nmas\u0131 compensable transaction’d\u0131r.\n<\/li>\n<\/ul>\n
Microservice Yap\u0131lanmas\u0131nda Veritabanlar\u0131 Nas\u0131l Tasarlanmal\u0131d\u0131r?<\/h5>\n
\u015eimdi s\u0131ra microservice yap\u0131lanmalar\u0131nda tasar\u0131msal a\u00e7\u0131dan veritabanlar\u0131n\u0131 nas\u0131l yap\u0131land\u0131raca\u011f\u0131m\u0131z\u0131 konu\u015fmaya geldi. Bu sorunun cevab\u0131n\u0131 do\u011fru \u015fekilde verebilmek Saga pattern’\u0131n\u0131n temel gereksiniminin anla\u015f\u0131lmas\u0131nda yard\u0131mc\u0131 olaca\u011f\u0131 kanaatinde oldu\u011fumdan dolay\u0131 gelin detayl\u0131ca isti\u015fare eyleyelim.<\/p>\n
Microservice yakla\u015f\u0131m\u0131nda her bir servisin ba\u011f\u0131ms\u0131z olarak geli\u015ftirilebilmesi, deploy edilebilmesi ve \u00f6l\u00e7eklendirilebilmesi i\u00e7in kendine ait, \u00f6zel ve direkt eri\u015filebilir veritabanlar\u0131na ihtiyac\u0131 vard\u0131r. Tabi ki de birden fazla servis ayn\u0131 veritaban\u0131n\u0131 kullanabilir ama bu durum pek ideal de\u011fildir. Servisler kendilerine ait veritabanlar\u0131na sahip olarak esas\u0131nda kendi aralar\u0131nda gev\u015fek bir ba\u011f\u0131ml\u0131l\u0131k sergileyebilme \u00f6zelli\u011fi kazanabilmektedirler. B\u00f6ylece her servis ihtiyac\u0131na uygun veritaban\u0131 se\u00e7ebilme h\u00fcvviyetine sahip olacakt\u0131r. \u00d6rne\u011fin; metin aramas\u0131 yapan bir servis Elasticsearch’\u00fc kullan\u0131rken, bu metinlerle ilgili farkl\u0131 bir i\u015flev yapan ba\u015fka bir servis NoSQL yakla\u015f\u0131m\u0131 olan MongoDB’yi kullanabilir.<\/p>\n
Her bir servisin kendi veritaban\u0131n\u0131 kullanmas\u0131n\u0131n elbette ki dezavantajlar\u0131 da mevcuttur. Bunlardan en \u00f6nemlisi diyebilece\u011fimiz, veritabanlar\u0131 aras\u0131nda verileri birle\u015ftirerek(join) sorgulamak ve b\u00fct\u00fcnsel istatiksel sonu\u00e7lar \u00fcretebilmek olduk\u00e7a zor ve zahmetlidir bir i\u015flevdir.<\/p>\n
De\u011fi\u015fiklikler Veritabanlar\u0131na Nas\u0131l Uygulanmal\u0131d\u0131r?
\n(ACID Prensipleri)<\/h5>\n
Veritabanlar\u0131n\u0131n nas\u0131l tasarlanaca\u011f\u0131ndan sonra da\u011f\u0131t\u0131lm\u0131\u015f veritabanlar\u0131nda yap\u0131lan verisel de\u011fi\u015fikliklerin nas\u0131l uygulanaca\u011f\u0131n\u0131 da konu\u015fmakta fayda vard\u0131r. Muhtemelen bu ba\u015fl\u0131\u011f\u0131 g\u00f6rd\u00fc\u011f\u00fcn\u00fczde la hoca veritabanlar\u0131ndaki de\u011fi\u015fikli\u011fi uygulamakta ne var la allahisen! alt taraf\u0131 insert, update, delete i\u015fte!<\/em> diyenleriniz olacakt\u0131r. Haliyle i\u015fi g\u00fcc\u00fc b\u0131rak\u0131p gelip size bu de\u011fi\u015fikliklerin teknik olarak nas\u0131l uygulanmas\u0131 gerekti\u011fini anlatma gibi gereksiz bir vizyona sahip oldu\u011fumu d\u00fc\u015f\u00fcnmenizi istemem \ud83d\ude42 Burada veritabanlar\u0131na yap\u0131lacak verisel de\u011fi\u015fiklerin hangi “prensipler” \u00e7er\u00e7evesinde uygulanmas\u0131 gerekti\u011fi \u00fczerine isti\u015fare eyliyor olaca\u011f\u0131z. Yani konumuz ilkeler \ud83d\ude09<\/p>\n
Bir yaz\u0131l\u0131m\u0131n da\u011f\u0131t\u0131lm\u0131\u015f veritabanlar\u0131 \u00fczerinde bulundu\u011fu verisel herhangi bir m\u00fcdahale neticesinde bu i\u015flemin nas\u0131l uygulanaca\u011f\u0131n\u0131 belli ba\u015fl\u0131 prensipler do\u011frultusunda de\u011ferlendirmekteyiz. Bu prensipler sayesinde veritabanlar\u0131 \u00fczerinde veri tutarl\u0131l\u0131\u011f\u0131na dair tatminkarl\u0131k seviyemizi \u00f6l\u00e7ebilir ve \u00e7\u0131k\u0131lan yolda akl\u0131n ne kadar \u00fct\u00fcde kalmas\u0131 gerekti\u011fine dair bir nebze karar verebiliriz.<\/p>\n
Da\u011f\u0131t\u0131lm\u0131\u015f veritabanlar\u0131nda yap\u0131lan de\u011fi\u015fiklerin nas\u0131l uygulanaca\u011f\u0131n\u0131 ifade eden prensipler ba\u015f harflerinden meydana gelen ACID Prensipleri<\/strong><\/em> olarak nitelendirilmektedir. ACID Prensipleri; Atomicity, Consistency, Isolation ve Durability olmak \u00fczere d\u00f6rt tanedir.<\/p>\n
\n
Atomicity<\/em><\/strong>
\nAtomicity, veritabanlar\u0131 \u00fczerinde yap\u0131lan de\u011fi\u015fiklik s\u00fcrecinde t\u00fcm transaction’lar\u0131n ba\u015far\u0131l\u0131 olmas\u0131 gerekti\u011fini ifade eder. Yani bu prensip, servisler aras\u0131nda yap\u0131lan bir verisel m\u00fcdahele neticesinde t\u00fcm veritabanlar\u0131ndaki transaction’\u0131n ba\u015far\u0131l\u0131 bir \u015fekilde neticelenmesini aksi taktirde herhangi birinde ba\u015far\u0131s\u0131zl\u0131k olursa t\u00fcm transaction’lar\u0131n geri al\u0131nmas\u0131 gerekti\u011fini savunur. \u0130nternetten bir ka\u00e7 makaleye g\u00f6z atarsan\u0131z `ya hep, ya hi\u00e7!<\/code> slogan\u0131yla tan\u0131nan bir prensip oldu\u011funu g\u00f6receksiniz.\n<\/li>\n`
Consistency<\/em><\/strong> \nConsistency, verilerin tutarl\u0131 olmas\u0131 gerekti\u011fini savunur. Yani servislerdeki veritabanlar\u0131 b\u00fct\u00fcnsel a\u00e7\u0131dan anlaml\u0131 ve tutarl\u0131 olmal\u0131d\u0131r. Misal olarak; ‘X’ servisindeki ‘a’ kayd\u0131na kar\u015f\u0131l\u0131k ‘Y’ servisinde ‘b’ kayd\u0131n\u0131n olmas\u0131 durumunda rahat olabilirsiniz. Lakin ‘X’ servisinde herhangi bir kar\u015f\u0131l\u0131\u011f\u0131 olmaks\u0131z\u0131n ‘Y’ servisinde bir verinin olmas\u0131 durumu s\u00f6z konusu olursa bi nooluyo demenizde fayda var. Nihayetinde veritabanlar\u0131 aras\u0131ndaki tutars\u0131zl\u0131k netice olarak b\u00fct\u00fcnsel a\u00e7\u0131dan istatistiki tutars\u0131zl\u0131\u011fa varacakt\u0131r. Haliyle consistency da\u011f\u0131t\u0131lm\u0131\u015f veritabanlar\u0131 s\u00f6z konusu oldu\u011funda g\u00f6z \u00f6n\u00fcnde tutulmas\u0131 gereken bir prensiptir.\n<\/li>\n
`Isolation<\/em><\/strong> \nIsolation ise transaction’lar\u0131n kendi aralar\u0131ndaki izalasyona odaklanmam\u0131z\u0131 \u00f6neren bir prensiptir. Yani t\u00fcm servislerdeki transaction’lar bir di\u011ferinden ba\u011f\u0131ms\u0131zd\u0131r ve yap\u0131sal olarak ard\u0131\u015f\u0131l servislerde birindeki i\u015flem bitmeksizin di\u011ferinin ba\u015flamamas\u0131 gerekmektedir. Ba\u015fl\u0131yorsa, uykunuzdan al\u0131p o i\u015fe vermenizde fayda var \ud83d\ude42\n<\/li>\n`
Durability<\/em><\/strong> \nDurability ise verilerin g\u00fcvenli ortamda saklanmas\u0131n\u0131 savunur. La hoca demesen gidip CD ya da diskette verileri saklayacakt\u0131k!<\/em> dedi\u011finizi duyar gibiyim. Evet, bu tepkinize kat\u0131l\u0131yorum. Bu biraz l\u00fczumsuz bir ikaz olmu\u015f olabilir. Amma velakin durability verilerin kararl\u0131, dayan\u0131kl\u0131 ve s\u00fcreklili\u011fi garanti edilmi\u015f bir ortamda (sabit disk gibi) saklanmas\u0131 gerekti\u011fini s\u00f6yl\u00fcyor i\u015fte… Ben napiiim \ud83d\ude42 Yine de kula\u011f\u0131n\u0131za k\u00fcpe olsun \u015feklinde yorumlay\u0131p, \u00f6yle in-memory vs. gibi gece uykunuzu ka\u00e7\u0131racak noktalarda verileri tutmaman\u0131z gerekti\u011fine dair kendinize bir ilke edinmenizde fayda olacakt\u0131r.\n<\/li>\n<\/ul>\n
Saga Nedir?<\/h5>\n
Saga, farkl\u0131 ve ba\u011f\u0131ms\u0131z servisler \u00fczerinde birden fazla transaction’\u0131n sistematik bir \u015fekilde i\u015flenerek veri tutarl\u0131l\u0131\u011f\u0131n\u0131n sa\u011flanmas\u0131n\u0131 ifade eden ve ilk olarak 1987 y\u0131l\u0131nda akademik bir makalede(bknz : SAGAS<\/a>) yer edinen bir design pattern’d\u0131r. Bu pattern’\u0131n i\u015flevsel mant\u0131\u011f\u0131 ilk transaction d\u0131\u015f bir etki ile(\u00f6rne\u011fin kullan\u0131c\u0131 taraf\u0131ndan butona t\u0131klama) tetiklendikten sonra, bir \u00f6nceki servisteki transaction’\u0131n ba\u015far\u0131l\u0131 olmas\u0131 durumuna g\u00f6re bir sonraki servisteki transaction’\u0131n tetiklenmesi ve bir silsile halinde bu \u015fekilde di\u011fer servisler \u00fczerinde tetiklenmenin devam etmesi \u00fczerinedir. B\u00f6ylece geli\u015ftirilen proje her ne kadar microservice yakla\u015f\u0131m\u0131n\u0131 benimsemi\u015f olsa da yap\u0131lan bir operasyon neticesinde t\u00fcm servislerdeki datalar tutarl\u0131 bir \u015fekilde i\u015flenmi\u015f olacakt\u0131r.<\/p>\n
Tabi s\u00fcre\u00e7te transaction’lardan herhangi birinde olu\u015fabilecek bir hata veya i\u015f mant\u0131\u011f\u0131 gere\u011fi iptal edilmesi gereken bir ad\u0131m s\u00f6z konusu olursa t\u00fcm s\u00fcre\u00e7 iptal edilecek ve i\u015flenen transaction’lar t\u00fcm servislerde geri al\u0131nacakt\u0131r(Compensable Transaction) B\u00f6ylece Atomicity prensibi desteklenmi\u015f olacakt\u0131r. <\/p>\n
Saga, microservice’ler aras\u0131nda do\u011fru transaction y\u00f6netimi ve veri tutarl\u0131l\u0131\u011f\u0131 sa\u011flayan bir design pattern’d\u0131r.<\/em><\/p><\/blockquote>\n
Saga’n\u0131n uygulanmas\u0131 i\u00e7in teknik olarak Events\/Choreography<\/strong> ve Command\/Orchestration<\/strong> isminde iki farkl\u0131 implemantasyon geli\u015ftirilmi\u015ftir. \u015eimdi gelin bu implemantasyonlar\u0131 teorik olarak detayl\u0131ca inceleyelim.<\/p>\n
Saga – Events\/Choreography Implemantasyonu<\/h6>\n $\"Microservice$ <\/a>Bu implemantasyonda microservice’ler aras\u0131 merkezi bir denetim ve haberle\u015fme noktas\u0131 olmaks\u0131z\u0131n birbirleriyle eventler arac\u0131l\u0131\u011f\u0131yla haberle\u015filmesi esast\u0131r. Yani servisler aras\u0131 ileti\u015fimin asenkron olarak tasarlanmas\u0131 gerekti\u011fini savunmaktad\u0131r. <\/p>\n
Genellikle bu ileti\u015fimin message broker ile ger\u00e7ekle\u015ftirilmesi tercih edilir. Ama bu senkron bir ileti\u015fiminde kesin olamayaca\u011f\u0131 anlam\u0131na gelmemekte sadece ideal olarak eventler sayesinde asenkron tercih edilmektedir.<\/p>\n
Taktiksel olarak Choreography’u incelersek e\u011fer, ilk serviste ba\u015flayan transaction i\u015flevini bitirdikten sonra sonraki servise haber g\u00f6nderebilmek i\u00e7in message broker \u00fczerinden bir event f\u0131rlatacakt\u0131r. Ard\u0131ndan bu servisteki transaction i\u015flevini bitirdikten sonra kendisinden sonraki servisi tetikleyebilmek i\u00e7in yine bir event f\u0131rlatacakt\u0131r. Ve bu s\u00fcre\u00e7 client’\u0131n istedi\u011fi i\u015flem bitene kadar silsile halinde i\u015flevdeki son servise kadar devam edecektir. Buradan anlayaca\u011f\u0131m\u0131z her bir servisin kendisinden sonraki servisin tetiklenip tetiklenmeyece\u011fine dair karar\u0131 verdi\u011fini g\u00f6rmekteyiz. Her bir servis yap\u0131lan i\u015flev neticesinde kendi s\u00fcrecine ba\u011fl\u0131 bir \u015fekilde ba\u015far\u0131l\u0131 ya da ba\u015far\u0131s\u0131z bir karar vermekte ve bu neticeye g\u00f6re ya kendisinden sonraki servisteki transaction’\u0131n ba\u015flamas\u0131n\u0131 sa\u011flayabilmekte ya da t\u00fcm transaction’lar\u0131 geri alabilmektedir. Yani her bir servis bizzat karar verici konumundad\u0131r.<\/p>\n
Choreography implemantasyonu, distributed transaction’a kat\u0131lacak olan microservice say\u0131s\u0131n\u0131n 2<\/u> ile 4<\/u> aras\u0131nda oldu\u011fu durumlarda tercih edilir. 4’ten fazla servis durumunda yaz\u0131m\u0131z\u0131n devam\u0131nda inceleyece\u011fimiz Orchestration implemantasyonunu uygulamak daha uygundur..<\/em><\/p><\/blockquote>\n
Choreography’de her bir servis kuyru\u011fu dinler. Dinledi\u011fi event message t\u00fcr\u00fcne g\u00f6re gelen bir message s\u00f6z konusuysa gerekli i\u015flemlerini ger\u00e7ekle\u015ftirir ve sonu\u00e7 olarak muhakkak durumu bildiren ba\u015far\u0131l\u0131 yahut ba\u015far\u0131s\u0131z bilgisini kuyru\u011fa event olarak ekler. Ard\u0131ndan di\u011fer servisler bu event’e g\u00f6re ya i\u015flevlerine devam edecektirler ya da t\u00fcm transaction’lar geri al\u0131n\u0131p veri tutarl\u0131l\u0131\u011f\u0131n\u0131 sa\u011flayacakt\u0131rlar.<\/p>\n
\u00d6rnek olarak a\u015fa\u011f\u0131daki g\u00f6rseli incelersek e\u011fer bir e-ticaret uygulamas\u0131nda Choreography implemantasyonuyla olu\u015fturulan sipari\u015fi g\u00f6rmekteyiz. $\"Microservice$ <\/a>Bu uygulamada bir sipari\u015fi olu\u015fturabilmek i\u00e7in;<\/p>\n
\n
Order<\/em><\/strong> serviste al\u0131nan POST iste\u011fi neticesinde sipari\u015f olu\u015fturulur.<\/li>\n
Order events channel<\/em> kuyru\u011funa ‘OrderCreated’ misali bir event g\u00f6nderilir.<\/li>\n
Customer<\/em><\/strong> servisi ise Order events channel<\/em>‘da ki ‘OrderCreated’ event’\u0131na subscribe olmaktad\u0131r. Haliyle ilgili kuyru\u011fa beklenen t\u00fcrde bir event gelirse Customer<\/em><\/strong> servis tetiklenecektir.<\/li>\n
Customer<\/em><\/strong> servis m\u00fc\u015fteriye dair gerekli t\u00fcm i\u015flemleri yapt\u0131ktan sonra e\u011fer i\u015flemler ba\u015far\u0131l\u0131ysa ‘OrderSucceded’ isminde yok e\u011fer de\u011filse ‘CreditLimitExceeded’ isminde Customer evens channel<\/em> kuyru\u011funa bir event yayar.<\/li>\n
Haliyle ilgili kuyru\u011fu dinleyen(subscribe) Order<\/em><\/strong> servis gelen event’\u0131n t\u00fcr\u00fcne g\u00f6re ya sipari\u015fi onaylar ya da reddeder.<\/li>\n<\/ol>\n
G\u00f6r\u00fcld\u00fc\u011f\u00fc \u00fczere servisler aras\u0131 u\u00e7tan uca(point to point) bir ileti\u015fim olmad\u0131\u011f\u0131 i\u00e7in coupling azalacakt\u0131r. Ayr\u0131ca transaction y\u00f6netimi merkezi olmad\u0131\u011f\u0131 i\u00e7in performance bottleneck azalacakt\u0131r..<\/p>\n
Ayr\u0131ca Choreography y\u00f6ntemi, sorumluluklar\u0131 Saga kat\u0131l\u0131mc\u0131 servisleri aras\u0131nda da\u011f\u0131tt\u0131\u011f\u0131ndan dolay\u0131 tek bir hata noktas\u0131 olmayacakt\u0131r. Bundan dolay\u0131 da ekstra bak\u0131m gerekmemektedir.<\/p>\n
\u015eimdi Choreography implemantasyonuna daha efektif bir \u00f6rnek vererek ilerleyelim. \u00d6rne\u011fimiz yine bir e-ticaret yaz\u0131l\u0131m\u0131n\u0131n sipari\u015f s\u00fcrecindeki detaylar\u0131n\u0131 yans\u0131tacakt\u0131r;
\n $\"Microservice$ <\/a><\/p>\n
\n
1. Ad\u0131m<\/em><\/strong>
\nKullan\u0131c\u0131dan gelen yeni sipari\u015f iste\u011fi neticesinde Order Service<\/em> bu sipari\u015fi durum bilgisi Suspend<\/em> olacak \u015fekilde kaydeder. Ard\u0131ndan \u00f6deme i\u015flemlerinin ger\u00e7ekle\u015ftirilebilmesi i\u00e7in ORDER_CREATED_EVENT<\/em> isimli event’i f\u0131rlat\u0131r.<\/li>\n
2. Ad\u0131m<\/em><\/strong>
\nORDER_CREATED_EVENT<\/em>‘ine subscribe olan Payment Service<\/em> gerekli \u00f6deme i\u015flemlerini ger\u00e7ekle\u015ftirir ve art\u0131k al\u0131nan \u00fcr\u00fcnlerin stok bilgilerini g\u00fcncellemek i\u00e7in BILLED_ORDER_EVENT<\/em> isimli event’i f\u0131rlat\u0131r.\n<\/li>\n
3. Ad\u0131m<\/em><\/strong>
\nBILLED_ORDER_EVENT<\/em>‘ine subscribe olan Stock Service<\/em> bu event f\u0131rlat\u0131ld\u0131\u011f\u0131nda devreye girer ve gerekli stok ayarlamalar\u0131n\u0131 ger\u00e7ekle\u015ftirir. Art\u0131k herhangi bir problem olmad\u0131\u011f\u0131 taktirde \u00fcr\u00fcnlerin teslimat\u0131 i\u00e7in ORDER_PREPARED_EVENT<\/em> isimli event’i f\u0131rlat\u0131r.<\/li>\n
4. Ad\u0131m<\/em><\/strong>
\nORDER_PREPARED_EVENT<\/em>‘ine subscribe olan Order Service<\/em> art\u0131k bu sipari\u015fin ba\u015far\u0131yla tamamland\u0131\u011f\u0131na kanaat getirmi\u015f olarak sipari\u015fin durumunu Completed<\/em> olarak g\u00fcnceller.<\/li>\n<\/ul>\n
Yukar\u0131daki ad\u0131mlardan herhangi bir durumda hata meydana geldi\u011fi taktirde t\u00fcm i\u015flemlerin geri al\u0131nmas\u0131 gerekmektedir. \u0130\u015fte bu durumda a\u015fa\u011f\u0131daki senaryo devreye girecektir;<\/p>\n
$\"Microservice$ <\/a>Distributed transaction s\u00fcre\u00e7lerinde bir i\u015flemi geri almak demek esas\u0131nda o i\u015flemi telafi etmek ya da tam tersini uygulamak i\u00e7in ba\u015fka bir i\u015flem yap\u0131lmas\u0131 demektir(Compensable Transaction) Dolay\u0131s\u0131yla yandaki g\u00f6rselden yola \u00e7\u0131karak \u00fcstteki i\u015flem ak\u0131\u015f\u0131n\u0131n yetersiz stok miktar\u0131ndan dolay\u0131 Stock Service<\/em>‘de ba\u015far\u0131s\u0131zl\u0131\u011fa u\u011frad\u0131\u011f\u0131n\u0131 varsayarak s\u00fcrecin nas\u0131l i\u015fledi\u011fini sim\u00fcle edelim…<\/p>\n
\n
1. Ad\u0131m<\/em><\/strong>
\n\u00d6deme i\u015fleminden sonra Stock Service<\/em>‘te yeterli stok olmad\u0131\u011f\u0131 anla\u015f\u0131ld\u0131\u011f\u0131 taktirde PRODUCT_OUT_OF_STOCK_EVENT<\/em> isimli event f\u0131rlat\u0131l\u0131r.\n<\/li>\n
2. Ad\u0131m<\/em><\/strong>
\nPRODUCT_OUT_OF_STOCK_EVENT<\/em>‘ine subscribe olan Payment Service<\/em> ve Order Service<\/em>‘lerde \u00f6nceki yap\u0131lan t\u00fcm i\u015flemlerin tersi uygulan\u0131r. Nedir bu tersine i\u015flemler diye sorarsan\u0131z e\u011fer; Payment Service<\/em>‘te al\u0131nan \u00f6deme kullan\u0131c\u0131ya tekrar geri yap\u0131l\u0131r ve Order Service<\/em>‘te ise sipari\u015f durumu Fail<\/em> olarak g\u00fcncellenir.\n<\/li>\n<\/ul>\nSaga – Events\/Choreography Implemantasyonunun Dezavantajlar\u0131 Nelerdir?<\/h6>\n
\n
Hangi servisin hangi kuyru\u011fu dinledi\u011fini takip etmek zorla\u015f\u0131r. Yeni servis eklemek zor ve kafa kar\u0131\u015ft\u0131r\u0131c\u0131 olabilmektedir.<\/li>\n
Birbirlerinin kuyruklar\u0131n\u0131 t\u00fckettikleri i\u00e7in servisler aras\u0131 d\u00f6ng\u00fcsel bir ba\u011f\u0131ml\u0131l\u0131k riski vard\u0131r.<\/li>\n
Bir i\u015flemi sim\u00fcle etmek i\u00e7in t\u00fcm servislerin \u00e7al\u0131\u015f\u0131yor olmas\u0131 gerekti\u011finden entegrasyon testi zordur.<\/li>\n<\/ul>\n
Saga – Command\/Orchestration Implemantasyonu<\/h6>\n
$\"Microservice$ <\/a>Bu yakla\u015f\u0131mda servisler aras\u0131 distributed transaction merkezi bir denetleyici ile koordine edilir. Bu denetleyiciye Saga State Machine<\/em> ya da bir ba\u015fka isim olarak Saga Orchestrator<\/em> denmektedir. Saga Orchestrator<\/em>, servisler aras\u0131ndaki t\u00fcm i\u015flemleri y\u00f6netir ve olaylara g\u00f6re hangi i\u015flemin ger\u00e7ekle\u015ftirilece\u011fini s\u00f6yler.<\/p>\n
Saga Orchestrator<\/em>, di\u011fer ismi olan Saga State Machine<\/em> ad\u0131ndan da anla\u015f\u0131ld\u0131\u011f\u0131 \u00fczere her kullan\u0131c\u0131dan gelen iste\u011fe dair uygulama state’ini(durum) tutmakta, yorumlamakta ve gerekti\u011finde telafi edici i\u015flemleri uygulamaktad\u0131r.
\n $\"Microservice$ <\/a>Misal olarak yanda \u015fematize edilmi\u015f e-ticaret senaryosunu ele al\u0131rsak e\u011fer;<\/p>\n
\n
Order Service<\/em> sipari\u015f iste\u011fini al\u0131r ve durumunu Suspend<\/em> olarak kaydeder. Ard\u0131ndan bu sipari\u015fe dair geri kalan i\u015flemleri ba\u015flatmak i\u00e7in Saga Orchestrator<\/em>‘a ORDER_CREATED<\/em> t\u00fcr\u00fcnden komut g\u00f6ndererek sipari\u015f olu\u015fturma transaction’\u0131n\u0131 ba\u015flat\u0131r.<\/li>\n
Saga Orchestrator<\/em>, EXECUTE_PAYMENT<\/em> komutunu Payment Service<\/em>‘e g\u00f6nderir. \u0130lgili servis \u00f6deme al\u0131nd\u0131\u011f\u0131na dair ba\u015far\u0131l\u0131 ya da ba\u015far\u0131s\u0131z bilgiyi tekrar Saga Orchestrator<\/em>‘a d\u00f6nd\u00fcr\u00fcr.<\/li>\n
Saga Orchestrator<\/em>, UPDATE_STOCK<\/em> t\u00fcr\u00fcnden komutu Stock Service<\/em>‘e g\u00f6nderir ve ilgili servis stok bilgisinin g\u00fcncellenmesini ger\u00e7ekle\u015ftirir. Yine nihai durum ba\u015far\u0131l\u0131 ya da ba\u015far\u0131s\u0131z olarak orchestrator’a d\u00f6nd\u00fcr\u00fcl\u00fcr.<\/li>\n
Orchestrator, ORDER_DELIVER<\/em> komutunu Delivery Service<\/em>‘e g\u00f6nderir ve ilgili servis sipari\u015fin kargoland\u0131\u011f\u0131 bilgisini ba\u015far\u0131l\u0131 yahut ba\u015far\u0131s\u0131z olarak d\u00f6nd\u00fcr\u00fcr.<\/li>\n
Ve en nihayetinde sipari\u015f durumu *Completed<\/em> olarak g\u00fcncellenir.<\/li>\n<\/ul>\n**Saga Orchestration implemantasyonunda Saga Choreography’de oldu\u011fu gibi asynchronous messaging pattern tercih edilmektedir.<\/em><\/p><\/blockquote>\n*
Yukar\u0131daki senaryoda servislerden herhangi birinde olas\u0131 bir hata meydana geldi\u011fi taktirde a\u015fa\u011f\u0131daki gibi hareket edilmelidir. Bu \u00f6rnekte hata ‘Stock Service’ \u00fczerinden misallendirilmektedir;
\n $\"Microservice$ <\/a><\/p>\n
\n
Stock Service<\/em>‘de sipari\u015f edilen \u00fcr\u00fcn adedi stok miktar\u0131ndan fazla ise orchestrator’a OUT_OF_STOCK<\/em> komutu g\u00f6nderilmektedir.<\/li>\n
Ard\u0131ndan orchestrator i\u015flem s\u00fcrecinde ba\u015far\u0131s\u0131zl\u0131k oldu\u011fu bilgisini al\u0131p rollback i\u015flemlerini ba\u015flat\u0131r(Compensable Transaction)<\/li>\n<\/ul>\n
Her i\u015flem i\u00e7in Saga \u00fczerinde state bilgisi tutmak hangi ad\u0131mda s\u00fcreci yanl\u0131\u015f y\u00f6netti\u011finizi g\u00f6rmeyi kolayla\u015ft\u0131racakt\u0131r.<\/em><\/p><\/blockquote>\n
Orchestration implemantasyonunun faydalar\u0131na gelirsek e\u011fer;<\/p>\n
\n
Bir\u00e7ok servisin bulundu\u011fu ve zaman i\u00e7inde servislerin eklendi\u011fi karma\u015f\u0131k i\u015f ak\u0131\u015flar\u0131 i\u00e7in idealdir. Burada alt e\u015fik 4 adet servistir. 4’\u00fcn \u00fczerinde servis s\u00f6z konusuysa e\u011fer orchestration implemantasyonu tercih edilir.<\/li>\n
Her servisin ve bu servislerin faaliyetlerinin \u00fczerinde merkezi kontrol sa\u011flar.<\/li>\n
Orchestration implemantasyonu, tek tarafl\u0131 olarak Saga kat\u0131l\u0131mc\u0131lar\u0131na(servisler) ba\u011fl\u0131 oldu\u011fundan dolay\u0131 d\u00f6ng\u00fcsel ba\u011f\u0131ml\u0131l\u0131klar s\u00f6z konusu de\u011fildir.<\/li>\n
Her bir servisin di\u011fer servisle ilgili bilmesi gereken herhangi bir \u015feye ihtiyac\u0131 yoktur! Haliyle b\u00f6ylece Separation of Concerns<\/em> s\u00f6z konusudur.<\/li>\n
Uygulamas\u0131 ve test etmesi choreography implemantasyonuna nazaran daha kolayd\u0131r.<\/li>\n
Yap\u0131lan i\u015fler do\u011frusal kalaca\u011f\u0131ndan dolay\u0131 geri alma yahut telafi y\u00f6netimleri daha kolayd\u0131r.<\/li>\n<\/ul>\n
Orchestration implemantasyonunun tek dezavantaj\u0131 t\u00fcm i\u015f ak\u0131\u015f\u0131n\u0131n y\u00f6netiminin Saga Orchestrator<\/em> taraf\u0131ndan ger\u00e7ekle\u015ftiriliyor olmas\u0131d\u0131r diyebiliriz.<\/p>\n
Nihai Olarak Saga<\/h6>\n
Art\u0131k i\u00e7eri\u011fimizi noktalamadan \u00f6nce Saga’ya dair nihai olarak yorumlar\u0131m\u0131z\u0131 yaparak genel mahiyette fikrimizi ortaya koyal\u0131m..<\/p>\n
\n
G\u00f6r\u00fcld\u00fc\u011f\u00fc \u00fczere Saga’da ister choreography olsun isterse de orchestration olsun hangi implemantasyon kullan\u0131l\u0131yorsa kullan\u0131ls\u0131n servis say\u0131s\u0131 nicelik olarak artt\u0131k\u00e7a karma\u015f\u0131kl\u0131k artmaktad\u0131r.<\/li>\n
Saga’da hata ay\u0131klama(debugging) olduk\u00e7a zor bir operasyondur.<\/li>\n
Saga’da ki servislerin local veritabanlar\u0131nda yap\u0131lan herhangi bir de\u011fi\u015fiklik geri al\u0131namaz!<\/li>\n
Bir Saga, bir ba\u015fka Saga’n\u0131n yapt\u0131\u011f\u0131 de\u011fi\u015fiklikleri okumadan veri i\u015fliyorsa Kay\u0131p G\u00fcncellemeler<\/u><\/em> s\u00f6z konusu olabilir.<\/li>\n
Ya da bir servis g\u00fcncellemeleri hen\u00fcz tamamlamadan bir ba\u015fka servis taraf\u0131ndan yap\u0131lan g\u00fcncellemeleri okudu\u011funda Kirli Okumalar<\/u><\/em> s\u00f6z konusu olabilmektedir.<\/li>\n
Hatta servislerin data okumalar\u0131 aras\u0131nda bir veri g\u00fcncellemesi meydana geldi\u011finde farkl\u0131 verilerin okunup Bulan\u0131k Okumalara<\/u><\/em> mahal verilebilmektedir.<\/li>\n<\/ul>\n
\u0130\u015fte bu ve bunlara benzer durumlardan dolay\u0131 Saga pattern’\u0131n\u0131n kullan\u0131m\u0131 net \u00f6zen gerektirmektedir. <\/p>\n
Saga Orchestrator, subscribe olan t\u00fcm servisleri \u00e7a\u011f\u0131rabilir ancak servisler orchestrator’\u00fc \u00e7a\u011f\u0131ramaz, \u00e7a\u011f\u0131rmamal\u0131d\u0131r!<\/em><\/p><\/blockquote>\n
Evet.. Konuyu teorik olarak inceledi\u011fimiz bir i\u00e7eri\u011fimizin daha sonuna gelmi\u015f bulunuyoruz. Bundan sonraki i\u00e7eriklerimizde bu teorinin \u00fczerine s\u0131ras\u0131yla choreography ve orchestration implemantasyonlar\u0131na dair pratiksel detaylar bar\u0131nd\u0131ran esas operasyonel i\u00e7eriklerimizi klavyeye al\u0131yor olaca\u011f\u0131z. Dolay\u0131s\u0131yla sizler bu makaleyi okurken ben deniz de sonraki makalelerin altyap\u0131lar\u0131n\u0131 atmaya gidiyor, kolayl\u0131klar diliyorum \ud83d\ude42<\/p>\n
Okudu\u011funuz ve e\u015flik etti\u011finiz i\u00e7in te\u015fekk\u00fcr ederim…<\/p>\n
\u0130lgilenenlerin faydalanmas\u0131 dile\u011fiyle…
\nSonraki yaz\u0131lar\u0131mda g\u00f6r\u00fc\u015fmek \u00fczere…
\n\u0130yi \u00e7al\u0131\u015fmalar…<\/p>\n
Kaynak\u00e7a<\/strong><\/p>\n
\nhttps:\/\/microservices.io\/patterns\/data\/saga.html
\nhttps:\/\/medium.com\/devopsturkiye\/microservice-mimarilerde-transaction-y%C3%B6netimi-nas%C4%B1l-yap%C4%B1l%C4%B1r-228317e248ed
\nhttps:\/\/docs.microsoft.com\/tr-tr\/azure\/architecture\/reference-architectures\/saga\/saga
\nhttps:\/\/sefikcankanber.medium.com\/saga-pattern-nedir-e4a447bef361\n<\/div>\n","protected":false},"excerpt":{"rendered":"
Merhaba, Biliyorsunuz ki, yaz\u0131l\u0131msal operasyonlarda belirli senaryolarla ba\u015f edebilmek i\u00e7in tecr\u00fcbevi birikim olarak yaz\u0131l\u0131mc\u0131lar taraf\u0131ndan tatiksel tan\u0131mlanm\u0131\u015f design pattern stratejilerinden istifade etmekteyiz. Design pattern uyarl\u0131l\u0131\u011f\u0131 microservice yap\u0131lanmalar\u0131nda da varl\u0131\u011f\u0131n\u0131 g\u00f6stermekte ve ya\u015fan\u0131lan problemlerde \u00e7\u00f6z\u00fcm...<\/p>\n","protected":false},"author":1,"featured_media":22329,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2739,153,3573],"tags":[4365,4362,4363,4359,4361,4366,4357,4355,4368,4371,4370,4358,4369,4367,4364,4372,4374,4356,4373,4149,126,4360],"class_list":["post-22251","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-net-core","category-design-pattern","category-microservices","tag-acid-prensipleri","tag-compensable-transaction","tag-compensable-transaction-nedir","tag-distributed-transaction","tag-distributed-transaction-nedir","tag-events-choreography","tag-microservice-saga-pattern","tag-saga","tag-saga-choreography","tag-saga-command","tag-saga-command-orchestration","tag-saga-design-pattern","tag-saga-event","tag-saga-events-choreography","tag-saga-nedir","tag-saga-orchestration","tag-saga-orchestrator","tag-saga-pattern","tag-saga-state-machine","tag-separation-of-concerns","tag-transaction","tag-transaction-nedir"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/22251","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/comments?post=22251"}],"version-history":[{"count":131,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/22251\/revisions"}],"predecessor-version":[{"id":22392,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/22251\/revisions\/22392"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/media\/22329"}],"wp:attachment":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/media?parent=22251"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/categories?post=22251"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/tags?post=22251"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}