Modern İşlemsel Yığın

İşlemsel veritabanları, uzun süredir uygulama tasarımının en kritik bileşeni olmuştur. Neden? Çünkü kararlı bir veritabanı genellikle dağınık, dağıtılmış bir dünyada doğruluk için nihai uygulama noktasıdır. Onlar olmadan fazla öder ve eksik ücret alırdık. Havaalanından eve gitmeye çalışan yolcuları kaybederdik ve alışveriş sepetlerimizdeki ürünleri kaybederdik. Çevrimiçi hesaplarımız kaybolabilir, kopyalanabilir veya bozulabilir ve çalışamaz hale gelebilir. 

Aslında, işlem veritabanı (genellikle OLTP olarak adlandırılır - çevrimiçi işlem işlemenin kısaltması - veritabanı), uygulama geliştirmede o kadar merkezi olmuştur ki, zamanla daha fazla uygulama işlevselliği tüketmiştir. Bununla birlikte, mikro hizmetler ve diğer modern uygulama mimarileri, uygulama tasarımına yeni karmaşıklıklar getirdi: Geliştiricilerin farklı hizmetler genelinde verileri yönetmesi ve bunlar arasında tutarlılığı sağlaması gerekiyordu, bu da onları şirket içinde karmaşık veri senkronizasyonu ve işleme mekanizmaları oluşturmaya zorladı. 

Ve böylece, bir endüstri olarak, geleneksel modelin dışında işlem garantilerine ihtiyaç duyulduğuna dair farkındalığın arttığını görüyoruz. biz görüyoruz güçlü işlemsel garantileri veritabanının ötesine, dağıtılmış uygulamaların kendisine genişleten sistemlerin ortaya çıkışı. 

Son birkaç yıldır bu çözümleri takip ediyoruz. Genel olarak, ölçeklendirme zorlukları yaratmadan ve modern bir programlama ortamı sağlarken, büyük bir dağıtılmış uygulamada durumun işlemsel yönetimine izin vermeye çalışırlar. 

Bu çözümlerin kabaca iki kategoriye ayrıldığını görüyoruz. Bir kategori iş akışı orkestrasyonu. Bu temel olarak bir kod bloğunun başarısızlıkla karşılaşsa bile sonuna kadar çalışacağını garanti eder. Bu nedenle, dağıtılmış bir durum makinesini kaza yapmadan deterministik olarak yönetmek amacıyla kullanılabilir. İkinci kategori ise veritabanı + iş akışı, geleneksel OLTP veritabanı tasarımını genişleterek, aynı amaç için isteğe bağlı kodun yürütülmesine izin verir. 

Bu hala çok gelişmekte olan bir alandır ve terminoloji, her bir aracın pratikte nasıl kullanıldığı ve bunları kimin kullanması gerektiği konusunda çok fazla kafa karışıklığı vardır. Daha iyi anlaşılmasına yardımcı olmak için, önde gelen mühendislik kuruluşlarından uygulayıcılara işlemsel yığınlarını ve işlemsel iş yükleri için üç temel kavram hakkında ne düşündüklerini sorduk: uygulama durumu, iş mantığı ve iş verileri. 

Yine de, bu yeni yığınları incelemeden önce, buraya nasıl geldiğimizi anlamanıza yardımcı olacak hızlı bir yarı teknik inceleme yapalım.

İşlemler, garantiler ve modern uygulamalar 

En kaba versiyonu şudur: Tamamını yapmak ya da hiçbirini yapmak istemediğiniz bir dizi görev - işlemler - vardır. Aradaki herhangi bir şey (kısmen yapılmış olması) bozuk bir durumda sona erecektir. Garanti etmek zor bir şey dağıtılmış bir sistemde, ancak veritabanları bunu işlemlerle iyi yapar. Bu nedenle, birçok sistemde garantileri ele almanın en kolay yolu, çoğu şeyi yalnızca yapmak ve bunları veritabanının halletmesine izin vermektir.

Modern uygulamalar, birçok kullanıcının birçok şey yaptığı büyük dağıtılmış sistemlerdir. Dolayısıyla, uygulama durumunu tutarlı tutmak bile (farklı kullanıcıların çıkış akışında nerede olduklarını izlemek gibi) dağıtılmış bir işlem sorununa dönüşür. Geleneksel yekpare mimarilerde, bir OLTP veritabanıyla SQL kullanarak işlemleri yönetmek bir ölçüde etkiliydi. Ancak, üst düzey API'ler (örn. REST veya gRPC) aracılığıyla etkileşime giren mikro hizmetlerin yeni, karmaşık dünyasında, işlemsel ihtiyaçlar doğası gereği dağıtılmış hale geldi. 

Ancak, mikro hizmet yolculuğuna çıkan birçok şirket, güçlü işlem garantilerini veritabanının ötesine taşımak için pek bir şey yapmadı. Ve pratikte, bu neredeyse her zaman TAMAM. Ancak uygulamalar ölçeklendikçe, verilerdeki tutarsızlıklar ve bunun sonucunda iş verilerinde hatalar ve uzlaştırılmamış hatalar artar. Bu, elbette, oldukça sorunlu olabilir. Bu, uygulama geliştiricilerini çok çeşitli başarısızlık senaryoları ve çatışma çözme stratejileriyle uğraşmaya ve farklı mimari modeller aracılığıyla kendi stratejilerini geliştirerek durum tutarlılığını sağlamaya zorlar.

Tanımlar İş verileri (“veriler”) kalıcılık ve işleme için bir OLTP veritabanında geleneksel olarak saklanan iş açısından kritik verileri ifade eder (örneğin, ad, adres, kredi puanı, vb. gibi kullanıcı profili bilgileri). Uygulama durumu sistemin mevcut durumunu ifade eder; uygulama durumu, bir veri depolama sisteminde saklanan bir değere ve sonlu durum makinesinde programın yürütülmesinin hangi adımında olduğuna göre belirlenir (örneğin, "sipariş alındı", "stok kontrol edildi", "kredi kontrol edildi" gibi bir siparişin durumu) "," sevk edildi, "iade edildi"). İş mantığı programın yürütme ayrıntıları yerine uygulamanın gerçekte nasıl çalıştığı veya ne yaptığıyla ilgilenen kısmını ifade eder (örn. "kullanıcı_geliri > $100K ve kredi_skoru >650 ⇒ ipotek_onaylı = DOĞRU").

Bu tartışmanın amaçları doğrultusunda, uygulama durumu ile iş verilerini birbirinden ayırmak önemlidir. Örneğin bir müşterinin kredi kartını girdiğini ancak çıkış yapmadığını bilmek başvuru durumudur. Kredi kartı ve başvuru sepetindeki ürünlere ilişkin veriler iş verileridir. 

Tipik bir akışta, ön uçtan bir istek gelir, kimliği doğrulanır ve ardından bir API ağ geçidi veya GraphQL aracılığıyla ilgili uç noktaya yönlendirilir. 

Bu tek API uç noktasının artık ticari işlemi son müşteriye ulaştırmak için onlarca veya yüzlerce mikro hizmeti düzenlemesi gerekiyor. Bu, geliştiricilerin tipik olarak her şeyi iş mantığı damlalarına topladığı ve ardından verileri veritabanına almak için kuyrukların, önbelleklerin ve elle kodlanmış yeniden deneme mekanizmalarının bir kombinasyonunu kullandığı yerdir - umarız tam bir işlem olarak işlenir.

Uygulamanın ölçeği arttıkça, kuyrukları ve önbellekleri yönetmenin karmaşıklığının yanı sıra sorunlar ortaya çıktığında mutabakat mantığındaki keskin kenarların sayısı da artar. 

İş akışı merkezli ve veritabanı merkezli işlem yığınlarının yükselişi

Tamam, yani işlemler önemlidir. Bir veritabanındaki LAMP, ölçek için yeterli değildi. Ve devasa bir kuyruk ve yeniden deneme mantığı çok kırılgan. Bununla başa çıkmak için, son birkaç yıldır işlem mantığına akıl sağlığını geri getiren yeni çözümlerin ortaya çıktığını gördük. Kabaca iş akışı merkezli yaklaşımlar veya veritabanı merkezli yaklaşımlar olarak kategorize edilebilirler.

Bugüne kadar iş akışı motorları, iş verilerinden ziyade öncelikli olarak uygulama durumu üzerinde çalışıyor ve geleneksel veritabanlarıyla entegre olurken genellikle biraz karmaşıklık gerektiriyor. Veritabanı merkezli yaklaşımlar, iş verilerinin yanı sıra uygulama mantığını da ekler, ancak henüz iş akışı motorlarının kod yürütme karmaşıklığına sahip değildir. 

Aşağıdaki diyagram, her ikisinin de kullanımda olduğu varsayılarak, bir Javascript/TypeScript uygulamasında iş akışı ve/veya veritabanı merkezli yaklaşımların nasıl kullanıldığının kabaca bir taslağını sunar. Bugün bu mimarinin farklı parçaları olsalar da, veritabanlarının iş akışı özelliklerini birleştirdiği ve iş akışlarının dayanıklı depolamayı benimsemeye başladığı bir eğilimin ilk işaretlerini gördük. Yeteneklerin bu birleşmesi, modern mimarilerde iki yaklaşım arasındaki çizgilerin bulanıklaştığını ve daha az belirgin hale geldiğini gösteriyor. 

Ayrıntılı olarak iş akışı merkezli yaklaşımlar 

Bir iş akışı, uygulama durumu makinesini geliştiren olaylara veya zamanlayıcılara dayalı olarak yürütülen basit kod bloklarıdır. İşlemsel iş akışı, uygulamadaki kısmi veya istenmeyen durumları önleyerek güçlü garantilerle kod yürütülmesini sağlar. Geliştiriciler mantığı yazar ve iş akışı motoru işlemleri, mutasyonları ve bağımsızlığı işler. Farklı iş akışı motorları, işlem ayrıntılarının ne kadarının geliştiricilere açıklandığı konusunda farklı ödünler verir. 

Örnek olarak, aşağıda Orkes (Conductor) üzerinde çalışan bir teslim alma iş akışının görsel bir temsili verilmiştir: 

Var iki kaba yaklaşım hangi iş akışı motorları çekiş kazanır. Birinde (Temporal.io tarafından tipiktir), geliştiriciler standart arka uç programlama dillerini (örn. Go veya Java) ve sistem, kodun sonuna kadar çalışmasını sağlayacaktır, bir arıza sırasında bile. Bu modelde, kod bir engelleme çağrısının tamamlanmasını beklese bile (örn. okuma veya yazma) program çağrısı yığını korunur. Bunu yapmak için, hatalar sırasında kısmi kod yürütülmesini önlemek için dil çalışma zamanı değiştirilir. Bu yaklaşımın avantajı, geliştiricilerin tanıdık dillerde yazabilmeleri ve korunan bir çağrı yığınıyla kolayca hata ayıklayabilmeleridir. Bu yaklaşımın en çok büyük, gelişmiş uygulamalarla uğraşan arka uç ekipleri arasında popüler olduğunu görüyoruz. 

Dezavantajı, uygulama geliştiricilere yararlı ve güvenli arabirimler sunmak için genellikle çok fazla entegrasyon çalışması ve sarmalayıcı kod gerektirmesidir. Diğer bir dezavantajı, çıplak dil yerine özel bir yürütme katmanına dayanmasıdır ve yürütmenin yerel dil çalışma zamanından farklı olacağı uç durumlar vardır. Bu nedenle, geliştiriciler aşina oldukları dilleri kullanabilirken, yine de temeldeki sistemin nasıl çalıştığını anlamaları gerekir.  

Uygulama geliştiricileri (özellikle TypeScript/Javascript) arasında daha popüler olan diğer yaklaşım, iş akışı motorunun zaman uyumsuz işlevlerin düzenleyicisi olarak hizmet eder (örn. Inngest, Erteleme ve Tetikleme). Bu modelde, üçüncü taraf olaylar veya işlevler, iş akışı motoruna yönlendirilir; bu motor daha sonra, başka bir zaman uyumsuz işlevi engelleme ihtiyacı ortaya çıktığında kontrolü geri vermesi gereken uygulama programcıları tarafından kaydedilen mantığı gönderir. İşin iyi tarafı, bunun bir programa entegre etmek için çok daha hafif bir yöntem olmasıdır. Ayrıca kod üzerinde, üzerinde çalışan ekibin daha kolay anlayabilmesi için yeterli yapıyı zorlar. Ancak, bu yaklaşımın araç desteği olmadan hata ayıklaması daha zor olabilir, bu nedenle hata ayıklama platforma özgü olma eğilimindedir.

İş akışı motorları, mevcut uygulamalar tarafından kademeli olarak benimsenmesine izin vermeleri açısından özellikle güçlüdür. Minimum ayak izi ile belirli iş akışlarına parça parça uygulanabilirler. Bununla birlikte, iş akışı motorlarının en büyük iki eksikliği, veritabanına yayılmamalarından kaynaklanmaktadır. Sonuç olarak, uygulama durumu ve iş verileri arasında sorgulanabilir tek bir doğruluk kaynağı yoktur. Ayrıca, işlem semantiği genellikle veritabanı semantiğinden farklıdır ve uygulama geliştiricilerin uç koşulları işlemesini gerektirir. 

Bugün norm olmasa da, iş akışlarının birçok durumda nasıl kalıcı veri depoları olarak kullanılabileceğinin kavramsal mimarilerini göstermek istiyoruz:

Ayrıntılı olarak veritabanı merkezli yaklaşımlar 

Veritabanı merkezli yaklaşımlar bir veritabanıyla başlar, ancak veri yönetiminin yanı sıra iş akışlarına izin vermek için rastgele kod yürütmeyi destekleyecek şekilde genişletir. Bunu, normal kod blokları için mutasyonlar, işlemler ve yetersizlik hakkında açık kararlar alabilmeleri için programcılara kontrol vererek yaparlar - esasen doğrudan OLTP semantiğini açığa çıkararak. Programcı, iş mantığını ve iş verilerini uygulama durumundan ayrı tutmaktan sorumludur. 

Aslında, saf veritabanı görünümü, uygulama durumunun her zaman iş verilerinden türetilebileceğidir. Bu genellikle, uygulama durumunu veritabanındaki iş verilerini değiştiren bir dizi işlem olarak depolayarak yapılır. Bunu, yukarıda açıklanan iş akışı sistemleriyle aynı güçlü garantilerle kod bloklarını çalıştırabilen bir veritabanı olarak düşünmek en kolay yoldur. 

Dahili olarak, buna uygulama mantığı işlem platformu (ALTP) çünkü sonuçta OLTP işlemlerini uygulamaya genişletir. Ancak ALTP'yi gerçekten karakterize eden şey, sıfırdan uygulama uygulamaları için, uygulama geliştiricilerin arka uç altyapısını doğrudan yönetme ihtiyacını tamamen ortadan kaldırabilmesidir.  

ALTP merceğinden, en sık kullanılan yaklaşım Firebase ile başladı. tam hizmet "arka uç deneyimi" kimlik doğrulama, veri deposu, veritabanları ve daha fazlası dahil. Firebase ve Supabase gibi daha yeni girenler, sıfırdan alan projeleri için çok popüler platformlar olmaya devam ediyor. OLTP köklerine sadık kalma eğiliminde olsalar da - ve bu nedenle işlemsel arka uç işlevleri için rastgele kod yürütmeyi desteklemeseler de - Supabase şimdiden iş akışları için destek eklemeye başlıyor.

Bununla birlikte, yeni nesil ALTP teklifleri Convex gibi, veritabanının yanında bir işlem olarak rasgele kodun yürütülmesine izin verir. Bu teklifler, tek bir kod bloğunun hem uygulama durumu hem de iş verileri olmak üzere verileri okuyabildiği, yazabildiği ve değiştirebildiği normal bir dilde (örn. Javascript/TypeScript) tamamen işlemsel olarak uyumlu kod yazılmasına olanak tanır. Bir anlamda, geliştiricilere tek bir sorgulanabilir gerçek kaynağı verir ve abonelikler gibi iş akışı ilkellerini sağlar. 

ALTP, iş akışı motorlarının veritabanından ayrılması sorununu çözer, ancak sonuç olarak, kullanıcıların avantajlardan yararlanmak için standart bir OLTP yerine veritabanı tekliflerine güvenmelerini gerektirir. Sonuç olarak, ekiplerin ALTP'yi mevcut, karmaşık arka uçlara entegre etmek yerine öncelikle sıfırdan alan uygulamaları için benimsediğini görüyoruz.

Yukarıdaki diyagram, konuştuğumuz birçok operatörün bir karışımıdır. Bazıları sadece bir iş akışı motoru kullanacak. Bazıları sadece veritabanı merkezli bir yaklaşım kullanacak. Ancak birçoğu, özellikle iş akışlarını yeni benimsemeye başladıklarında her ikisini de kullanacak. Günümüzde iş akışı motorlarının kullanıcıları, büyük, karmaşık uygulamalarla uğraşan arka uç ekipleri olma eğilimindedir, ancak birçok tam yığın ekibin bunları benimsediğini de gördük. Hizmet olarak arka uç çözümleri, daha uygulama geliştirici dostu olma eğilimindedir ve uygulama, teknoloji seçimini yönlendirdiğinde daha yaygın olarak kullanılır. 

yakınsama

İş akışı merkezli yaklaşımlar ile veri tabanı merkezli yaklaşımların bir çarpışma rotasında olduğu giderek netleşiyor. Bunun birincil nedeni, uygulama durumu ve veritabanı durumu mantıksal olarak farklı olsa da birbirlerine bağımlı olmaları ve her ikisini de kapsamayan bir sistemin doğru anlaşılması ve hata ayıklamasının karmaşık olmasıdır.  

Örnek olarak, bir kullanıcının ödeme işlemi için durum makinesini izlemek üzere kullanılan bir iş akışı motorunu ve bu kullanıcının sepete bir öğe eklediğini düşünün. Tipik olarak, iş akışı motorları, bir hata durumunda bile bir kod adımının çalışmasını sağlar. Ancak, adımın tam olarak tamamlanıp tamamlanmadığından tam olarak emin olmadığı için motorun bir arıza sırasında belirli bir adımı yeniden çalıştırması gereken durumlar olabilir. Bu adım, iş verilerinin geleneksel bir veritabanına (bu durumda, sepetteki öğe) yazılmasını içeriyorsa ve veritabanı yinelenen yeniden denemenin farkında değilse, yinelenen bir girişle sonuçlanır. 

Bununla başa çıkmanın iki yolu var. Bunun bir yolu, sorunu yalnızca bir öğenin yazılmasını sağlamak için iş akışı sistemi tarafından sağlanan nonce'ı kullanacak olan uygulama geliştiricisine iletmektir. Ancak bu, geliştiricinin, doğru olması herkesin bildiği gibi zor olan boşta kalmayı anladığını varsayar ve bu, bir iş akışı sistemine sahip olmanın birçok büyüsünü ortadan kaldırır. Diğer yol ise, iş akışı motorunu iş akışı işlem semantiğinin farkında olan bir veritabanına bağlamaktır. Bu henüz tam olarak gerçekleşmedi, ancak olacağına inanmak zor değil. 

Öte yandan, veritabanı merkezli yaklaşımlar, genel iş akışının uygulama geliştiriciler için gerçekten yararlı olduğunun farkına varır. Ve böylece sorgular, mutasyonlar, dizinler vb. gibi geleneksel veritabanı işlevlerini destekleyen veritabanlarının (Convex gibi) zamanlama ve abonelikler gibi işlevleri uyguladığını görmeye başlıyoruz. Bunlar, iş akışı motorları olarak kullanılmalarına izin verir. Yani, güçlü garantilerle keyfi kod bloklarının yürütülmesine izin verirler. 

Ian Livingstone'un (bu parça hakkında geri bildirim sağlayan) belirttiği gibi, “Klasik 'Uygulama mantığını veritabanına mı getiriyorsunuz yoksa veritabanını uygulama mantığına mı getiriyorsunuz?' tekrar oynamak ... bu sefer monolitin kırılmasıyla ortaya çıktı. On yıllardır bu ikilemi yaşadıktan sonra, her iki modelin de kısa vadede devam edeceği açık. Uzun vadede durumun böyle kalacağı çok daha az açık. 

Charly Poly (Defer), Dan Farrelly (Inngest), David Khourshid (Stately), Ian Livingstone (Cape Security), Enes Akar (Upstash), James Cowling (Convex), Jamie Turner (Convex), Paul Copplestone (Supabase)'a özel teşekkürler ), Sam Lambert (PlanetScale), Tony Holdstock-Brown (Inngest), Matt Aitken (Trigger) bu gönderiyi inceleyip geri bildirimde bulundukları için. Ayrıca Benjamin Hindman (Yeniden Başlatma), Fredrik Björk (Grafbase), Glauber Costa (Chiselstrike), Guillaume Salles (Liveblocks), Maxim Fateev (Temporal), Steven Fabre (Liveblocks) ve Viren Baraiya'ya (Orkes) bize yardımcı oldukları için teşekkürler. Araştırma.

• SEO Destekli İçerik ve Halkla İlişkiler Dağıtımı. Bugün Gücünüzü Artırın.
• Plato blok zinciri. Web3 Metaverse Zekası. Bilgi Güçlendirildi. Buradan Erişin.
• Adryenn Ashley ile Geleceği Basmak. Buradan Erişin.
• Kaynak: https://a16z.com/2023/04/14/the-modern-transactional-stack/