Telafi İşlemi düzeni

Son tutarlı bir işlemde bir veya daha fazla adım başarısız olduğunda çalışmayı geri almak için bu düzeni kullanın. Karmaşık iş süreçleri ve iş akışları uygulayan bulutta barındırılan uygulamalar genellikle nihai tutarlılık modelini izleyen işlemleri kullanır.

Bağlam ve sorun

Bulut uygulamaları genellikle farklı coğrafi konumlardaki çeşitli veri kaynaklarına yayılan verileri değiştirir. Dağıtılmış bir ortamda çakışmayı önlemek ve performansı geliştirmek için uygulamaların güçlü işlem tutarlılığı yerine nihai tutarlılık uygulaması gerekir. Nihai tutarlılık modelinde tipik bir iş işlemi bir dizi ayrı adımdan oluşur. Bu adımlar sırasında sistem durumunun genel görünümü tutarsız olabilir. Ancak tüm adımlar tamamlandığında sistem yeniden tutarlı hale gelmelidir.

Adım hatalarını işlemek, nihai tutarlılık modelinde önemli bir zorluk sunar. Bir hatadan sonra tamamlanan işlem adımlarından çalışmayı geri almanız gerekebilir. Ancak, diğer eşzamanlı uygulama örnekleri verileri değiştirebileceğinden verileri her zaman geri alamazsınız. Eşzamanlı örnekler verileri değiştirmese bile, bir adımı geri almak, özgün durumu geri yüklemekten daha karmaşık olabilir. İşletmeye özgü kurallar uygulamanız gerekebilir. Bir örnek için seyahat web sitesi örneğine bakın.

Son tutarlılık uygulayan bir işlem birden çok veri deposuna yayıldığında, değişiklikleri geri almak için her veri deposuna erişmeniz gerekir. Sistemin tutarsız kalmasını önlemek için, her veri deposundaki çalışmayı güvenilir bir şekilde geri almalısınız.

Nihai tutarlılık uygulayan bir işlem, etkilenen verilerini her zaman veritabanında depolamaz. Örneğin, hizmet odaklı mimari (SOA) ortamında, bir işlem bir hizmette bir eylem çağırabilir ve hizmetin sahip olduğu durumu değiştirebilir. İşlemi geri almak için bu durum değişikliğini de geri almalısınız. Bu değişiklik, ilk eylemin etkilerini tersine çevirmek için hizmeti yeniden çağırmayı içerebilir.

Çözüm

Özgün işlemdeki tamamlanmış adımların etkilerini geri alan bir telafi işlemi uygulayın. Sistemi yalnızca özgün durumuna geri yükleyebileceğinizi düşünebilirsiniz, ancak bu yaklaşım diğer eşzamanlı uygulama örneklerindeki değişikliklerin üzerine yazabilir. Bunun yerine, telafi işleminin eşzamanlı çalışmayı akıllı bir şekilde hesaba aktarması gerekir. Bu işlem genellikle uygulamaya özgüdür ve özgün işleme bağlıdır.

Telafi gerektiren nihai tutarlı işlemi uygulamak için bir iş akışı kullanabilirsiniz. Özgün işlem çalıştırılırken, sistem her adımla ilgili bilgileri ve bunların nasıl geri alınacağını kaydeder. İşlem başarısız olursa, iş akışı tamamlanan adımlar boyunca geri sarılarak her adımı tersine çevirir.

İleri adımları ve telafi eylemlerini içeren bir iş akışını gösteren diyagram. Kullanıcı 1. adım, 2. adım ve 3. adımı sıralı olarak çalıştıran bir işlem başlatır. Tüm adımlar başarılı olursa işlem tamamlar. Herhangi bir adımdan sonra bir hata oluşursa, tamamlanan işi geri almak için telafi eylemleri ters sırada çalışır ve iş, telafi edilmiş bir duruma getirilir.

Her adım ayrı bir eylem olsa da, birlikte sonunda tutarlı bir işlem oluşturur. Sistemin her adım için adımları ve buna karşılık gelen geri alma işlemlerini gerçekleştirmesi gerekir. Müşteri iptal ederse, bu geri alma işlemleri telafi işlemi olarak çalıştırılabilir.

Tek adımlı bir hata, telafi işlemi kullanarak her zaman sistemin tamamını geri almanızı gerektirmez. Örneğin, bir seyahat web sitesi senaryosunda müşteri F1, F2 ve F3 uçuşlarını rezerve eder ancak H1 otelinde bir oda ayıramazsınız. Müşteriye farklı bir otelde oda sunmak, uçuşları iptal etmeye tercih edilir. Müşteri yine de iptal etmeyi seçebilir ve bu da uçuş rezervasyonlarını geri almak için telafi işlemini tetikler. Ancak bu kararı sistem değil müşteri vermelidir. Kararlar yüksek etkiye sahip olduğunda veya güvenilir bir şekilde otomatikleştirilmesi zor olduğunda, karar alma sürecine bir insanı dahil edin.

Şu önemli noktaları göz önünde bulundurun:

• Telafi işleminin, orijinal operasyonun tam ters sırasıyla işi geri alması gerekmeyebilir.

• Bazı geri alma adımlarını paralel olarak gerçekleştirebilirsiniz.

• İşletmeye özgü kurallar uygulamanız gerekebilir. Örneğin, bir uçuş rezervasyonunu iptal etmek müşteriye tam para iadesi hakkı vermeyebilir.

Bu yaklaşım , Saga dağıtılmış işlemler düzenine benzer.

Telafi işlemleri, sonunda tutarlı hale gelebilen işlemler olup başarısız olabilir. Sistemin hata noktasından telafi işlemini sürdürebilmesi için ilerleme durumunu kaydetmesi gerekir. Bir adım yeniden denendiğinde birçok kez çalıştırılabileceğinden, her adımı bir idempotent komut olarak tasarlayın.

Bazen başarısız bir adımdan kurtulmanın tek yolu el ile müdahaledir. Bu gibi durumlarda sistem, hatanın nedeni hakkında ayrıntılı bilgi içeren bir uyarı göndermelidir.

Sorunlar ve dikkat edilmesi gerekenler

Bu düzenin nasıl uygulaneceğine karar velarken aşağıdaki noktaları göz önünde bulundurun:

• Son tutarlılığı uygulayan bir işlemdeki bir adımın ne zaman başarısız olduğunu belirlemek kolay olmayabilir. Bir adım hemen başarısız olmayabilir, bunun yerine engellenebilir. Zaman aşımı mekanizması uygulamanız gerekebilir.

• Telafi mantığını genelleştirmek kolay değildir. Telafi işlemi uygulamaya özgüdür. Uygulamanın başarısız bir işlemdeki her adımın etkilerini geri almak için yeterli bilgiye sahip olmasını sağlar.

• Telafi işlemleri her zaman işe yaramaz. Telafi işlemindeki adımları, telafi işlemi başarısız olursa bunları tekrarlayabilmeniz için idempotent komutlar (tekrarlanabilir komutlar) olarak tanımlayın.

• Adımları işleyen altyapı aşağıdaki ölçütleri karşılamalıdır:

  • Hem özgün işlemde hem de telafi işleminde dayanıklıdır.

  • Başarısız bir adımı telafi etmek için gereken bilgileri kaybetmez.

  • Telafi mantığının ilerleme durumunu güvenilir bir şekilde izler. Telafi işlemleri, özgün işlemler onaylandıktan sonra çalıştırılır ve diğer işlemler ara durumları değiştirebilir. Bu nedenle, hem özgün işlemi hem de telafisini uçtan uca ilişkilendirebildiğinize ve denetleyebildiğinize emin olun.

• Telafi işlemi, sistem verilerini özgün işlemin başlangıcındaki durumuna döndürmez. Bunun yerine, işlem, başarısız olmadan önce işlemin başarıyla tamamladığı çalışmayı telafi eder.

• Telafi işlemi adımları her zaman özgün işlemi tam ters sırada tersine çevirmez. Örneğin, bir veri deposu tutarsızlıklara karşı diğerinden daha hassassa, önce bu depodaki değişiklikleri geri alın.

• Bazı ölçüler başarı oranlarını artırmanıza yardımcı olabilir. bir işlemi tamamlamak için gereken her kaynağa zaman aşımı ile kısa vadeli bir kilit yerleştirebilirsiniz. Bu kaynakları önceden alabilir ve ardından yalnızca tüm kaynakları aldıktan sonra iş gerçekleştirebilirsiniz. Kilitlerin süresi dolmadan önce tüm eylemleri sonlandırın.

• Daha fazla hatayı geçici olarak değerlendiren yeniden deneme mantığı, telafi işlemini tetikleyen hataları en aza indirmeye yardımcı olabilir. Son tutarlılığı uygulayan bir işlemdeki bir adım başarısız olduğunda, bunu geçici bir özel durum olarak işleyin ve adımı yeniden deneyin. Adım tekrar tekrar başarısız olursa ya da kurtarma olanağınız yoksa, yalnızca işlemi durdurun ve tazminat sürecini başlatın. Yeniden deneme stratejileri hakkında daha fazla bilgi için bkz. Geçici hata işleme.

• Telafi işlemi uyguladığınızda, nihai tutarlılığı uygulamaya benzer birçok zorlukla karşılaşırsınız. Daha fazla bilgi için bkz. Koordinasyonu en aza indirme.

• Dönüşsüz ve geri alınamaz adımların net noktalarını tanımlayın. Karmaşık iş akışlarında, dış yan etkiler veya yasal olarak bağlayıcı eylemler gibi bazı işlemleri güvenli veya anlamlı bir şekilde geri alamazsınız. Telafi edilebilir ve geri alınamaz adımları belirleyin. İş akışını, geri alınamayan adımların yalnızca tüm kritik doğrulamalar başarılı olduktan sonra gerçekleşmesini sağlayın.

Bu desen ne zaman kullanılır?

Bu düzeni aşağıdaki durumlarda kullanın:

• Bir işletme operasyonu, birden çok adıma, hizmete veya veri deposuna yayılır ve sonraki bir adım başarısız olursa geri döndürülmelidir. Bu senaryo genellikle nihai tutarlılık modelini izleyen ve atomik işlemlere güvenemeyen uzun süre çalışan iş akışlarında sıklıkla meydana gelir.

• Hata kurtarma genellikle basit bir veri geri alma işlemi yerine etki alanına özgü mantık gerektirir. İşi geri alırken telafi eylemlerini kullanmak için rezervasyonları iptal etme veya kısmi para iadesi verme gibi iş kurallarını uygulamanız gerekir.

Bu düzen aşağıdaki durumlarda uygun olmayabilir:

• İşlemler güvenli bir şekilde yeniden denenebilir ve çoğu hata geçicidir. Bu durumlarda yalnızca yeniden deneme mantığı genellikle yeterlidir ve telafi işlemleri gereksiz karmaşıklık ekler.

• Sistem geçici tutarsızlığı tolere edemez veya telafi geçerli bir durumu güvenilir bir şekilde geri yükleyemez. Bunun yerine tüm adımlarda güçlü tutarlılık mekanizmaları veya atomik işlemler kullanın.

İş yükü tasarımı

Azure Well-Architected Framework sütunları kapsamındaki hedefleri ve ilkeleri ele almak için bir iş yükünün tasarımında Telafi İşlemi'nin nasıl kullanılacağını değerlendirin. Aşağıdaki tabloda, bu desenin her bir sütunun hedeflerini nasıl desteklediği hakkında rehberlik sağlanmaktadır.

Ana Direk	Bu desen sütun hedeflerini nasıl destekler?
Güvenilirlik tasarımı kararları, iş yükünüzün hatalı çalışmaya dayanıklı olmasına ve bir hata oluştuktan sonra tamamen çalışır duruma geldiğinden emin olmasına yardımcı olur.	Telafi eylemleri, veri değişikliklerini doğrudan geri alma, işlem kilitlerini bozma ve hatta etkiyi tersine çevirmek için yerel sistem davranışını çalıştırma gibi işlemleri kullanarak kritik iş yükü yollarındaki arızaları giderir. - RE:02 Kritik akışlar - RE:09 Olağanüstü durum kurtarma

Bu model bir sütun içinde dengeleri ortaya çıkartıyorsa, bunları diğer sütunların hedeflerine karşı değerlendirin.

Example

Aşağıdaki diyagramda Telafi İşlemi deseninin pratik Azure uygulaması gösterilmektedir. Diğer uygulamalar da iş yükü gereksinimleriniz için işe yarayabilir. Azure Container Apps içinde çalışan bir düzenleyici, Azure Service Bus aracılığıyla komutlar göndererek uzun süre çalışan bir iş akışının her adımını koordine eder. Her ileri adım başarılı olduktan sonra düzenleyici, iş akışının sürdürülebilmesi, bağıntılı hale getirilmesi ve denetlenebilmesi için hem yürütme durumunu hem de buna karşılık gelen telafi eylemini Azure Cosmos DB kaydeder.

Azure Container Apps bir ortamda iş akışını gösteren diyagram. İstemci, Hizmet A ve Hizmet B'yi koordine eden ve işlemleri kaydeden bir orchestrator kapsayıcısına istek gönderir. 1. adım ve 2. adım iletileri Service Bus üzerinden akar. Bir adım başarısız olursa telafi eylemleri ters sırada çalışır. Hatalı iletiler bir ölü harf kuyruğuna taşınır. Ortam, kimlik doğrulama için Microsoft Entra ID ve gözlemlenebilirlik için Application Insights ile Azure İzleyici ile tümleştirilir.

Bu model, ilerlemeyi korumak için öncelikle yeniden denemeleri kullanır. Bir adım başarısız olursa, düzenleyici geçici hatalar için yeniden deneme mantığını uygular ve özgün işleme devam etmeye çalışır. Telafi mekanizması yalnızca, yeniden denemelerin bitmesi veya başarısızlığın geçici olmayan olarak sınıflandırılması gibi ilerlemenin imkansız hale gelmesi durumunda çağrılır.

İşletmeye özgü kurallar, anında telafi yerine ileriye dönük ilerlemeyi de tercih edebilir. Bir adım başarısız olursa, düzenleyici iş akışını geri döndürmek yerine eşdeğer bir hizmet veya geri dönüş seçeneğini değiştirme gibi alternatif bir yol seçebilir. Yüksek etkili veya belirsiz durumlarda, alternatif bir yolda devam etmeye veya telafi mekanizmasını başlatmaya karar vermeden önce insan incelemesi için iş akışını duraklatabilirsiniz. Bu yaklaşım, telafiyi son çare olarak ele alır ve etki alanı kurallarının kurtarma kararlarını yönlendirmelerine olanak tanır.

Normal bir sırayla, orkestratör Service Bus aracılığıyla (1. ve 2. adımlar) adım iletileri gönderir, başarılı sonuçlar alır ve ileri ve telafi meta verilerini Azure Cosmos DB'de depolar.

Telafiyi iki yolla tetikleyebilirsiniz:

• Aynı iş yükündeki sonraki bir adım başarısız olduğunda ve daha önce başarılı olan adımları geri almalısınız. Bu telafi, bir adım kural geçerliliği hatası gibi bir hata döndürdüğünde veya teknik yeniden denemeler tükendikten sonra mesaj ölü-mektup kuyruğuna taşındığında hemen gerçekleşebilir.

• Sonraki bir istemci açıkça tamamlanmış bir işlemi iptal etmek istediğinde.

Her iki durumda da düzenleyici depolanan dengeleme kayıtlarını okur ve karşılık gelen hizmete telafi komutları gönderir. Bir telafi adımı geçici olarak başarısız olursa, Service Bus yeniden denemeleri, sorunu büyütmeden bu adımı tamamlayabilir.

Yinelenen yeniden denemeler yine başarısız olursa Service Bus iletiyi ölü harf kuyruğuna taşır ve hata detaylarını muhafaza eder. Orkestratör veya özel bir dead-letter işlemcisi, Azure İzleyici ve Log Analytics'e iletilen, hata nedeni ve bağıntı kimliklerini de içeren yapılandırılmış telemetriyi yayar ve Application Insights'ta görüntülenebilir bir uyarı oluşturur. Bu işlem yolu ekiplerin hataları tanılamalarına, el ile müdahale gereksinimini belirlemelerine ve hem özgün hem de telafi akışlarında izlenebilirliği korumalarına yardımcı olur.

İş akışı net, düşük riskli koşullar için otomatik olarak telafi başlatabilir veya durum belirsiz, yüksek etkiye sahip olduğunda veya el ile bir karar gerektirdiğinde insan incelemesi için duraklayabilir.

Paylaşılan sırları önlemek ve en az ayrıcalıklı erişimi uygulamak için bileşenler arasında yönetilen kimlikleri ve Microsoft Entra ID tabanlı yetkilendirmeyi kullanın. Basitleştirilmiş bir başvuru diyagramı oluşturduğunuzda, bu kimlik ve yetkilendirme denetimlerini açık akış adımları yerine temel uygulama endişeleri olarak değerlendirin. Diyagramı orkestrasyon, yeniden deneme, telafi ve hata işlemeye odaklanarak tutun.

İlgili kaynaklar

• Mikro hizmetler için verilerle ilgili dikkat edilmesi gerekenler: Dağıtılmış sistemlerde nihai tutarlılık ve kısmi hatanın neden doğal olduğunu öğrenin. Telafi İşlemi düzeni, işlemler birden çok hizmete yayıldığında bu hataları işlemek için somut bir mekanizma sağlar.

• Azure Cosmos DB ile Transactional Outbox Deseni: Telafi işlemlerinin olayları veya komutları güvenilir bir şekilde yayımlaması gerektiğinde bu deseni kullanın. Durum değişikliklerinin ve iletilerin atomik olarak kaydedilmesine yardımcı olur ve bu da ileti kaybını önler.

• Kendi kendini düzeltme tasarımı: Uygulamalarınız için kendi kendini iyileştiren bir yaklaşımın parçası olarak telafi işlemlerini kullanın.

• Scheduler Agent Supervisor paterni: Dağıtılmış hizmetler ve kaynaklar arasında iş süreçlerini gerçekleştiren dayanıklı sistemler uygulamak için bu paterni kullanın. Bu sistemlerin bazen işi geri almak için telafi işlemlerine ihtiyacı vardır.

• Yeniden deneme düzeni: Geçici hataları işlemek ve telafi işlemleri gereksinimini en aza indirmek için bu düzeni kullanın.

• Saga dağıtılmış işlemler düzeni: Dağıtılmış işlemlerde mikro hizmetler arasında veri tutarlılığını yönetmek için bu düzeni kullanın. Saga, hata kurtarma için telafi işlemlerini kullanır.

• Kanallar ve Filtreler deseni: Karmaşık görevleri yeniden kullanılabilir adımlara ayırdığınızda dağıtılmış işlemlere alternatif olarak Telafi İşlemi düzeniyle bu düzeni kullanın.