Zamanlayıcı Aracısı Gözetmeni düzeni

Bir dizi dağıtılmış eylemi tek bir işlem olarak koordine edin. Eylemlerden herhangi birini başarısız olursa, hataları şeffaf bir şekilde ele almayı deneyin veya tümün işlemin bütünüyle başarılı ya da başarısız olması için gerçekleştirilen işi geri alın. Bunun yapılması; geçici özel durumlar, uzun süreli arızalar ve işlem hataları nedeniyle başarısız olan eylemleri kurtarmayı ve yeniden denemeyi sağlayarak dağıtılmış bir sisteme dayanıklılık katabilir.

Bağlam ve sorun

Bir uygulama, bazıları uzak hizmetleri çağırabilen veya uzak kaynaklara erişebilen birkaç adımlı görevler gerçekleştirir. Her bir adım birbirinden bağımsız olabilir, ancak görevi uygulayan bir uygulama mantığı tarafından düzenlenirler.

Mümkün olduğunda, uygulama görevin tamamlanana kadar çalışmasını sağlamalı ve uzak hizmetlere ya da kaynaklara erişirken oluşabilecek her türlü hatayı çözümlemelidir. Hatalar çeşitli nedenlerle ortaya çıkabilir. Örneğin, ağ arızalı olabilir, iletişim kesintiye uğramış olabilir, uzak bir hizmet yanıt vermiyor veya kararsız bir durumda olabilir ya da uzak bir kaynağa, belki de kaynak kısıtlamaları nedeniyle, geçici olarak erişilemiyor olabilir. Çoğu durumda hatalar geçicidir ve Yeniden deneme düzeni kullanılarak ele alınabilir.

Uygulama kolayca kurtaramayacağı daha kalıcı bir hata algılarsa, sistemi tutarlı bir duruma geri yükleyebilmesi ve tüm işlemin bütünlüğünü sağlayabilmesi gerekir.

Çözüm

Zamanlayıcı Aracısı Gözetmeni düzeni aşağıdaki aktörleri tanımlar. Bu aktörler genel görevinin bir parçası olarak gerçekleştirilecek adımları düzenlerler.

• Zamanlayıcı, yürütülecek görevi oluşturan adımları ve işleyişlerini düzenler. Bu adımlar bir işlem hattı veya iş akışı içinde birleştirilebilir. Zamanlayıcı bu iş akışındaki adımların doğru sırayla gerçekleştirilmesinden sorumludur. Her adım gerçekleştirilirken Zamanlayıcı iş akışının durumunu kaydeder( örneğin, "adım henüz başlatılmadı", "adım çalışıyor" veya "adım tamamlandı." Durum bilgileri, adımın tamamlanması için izin verilen sürenin bir üst sınırını (tamamlanma zamanı olarak adlandırılır) da içermelidir. Bir adım, uzak bir hizmete veya kaynağa erişim gerektiriyorsa Zamanlayıcı uygun Aracıyı çağırır ve gerçekleştirilecek işin ayrıntılarını iletir. Zamanlayıcı genellikle zaman uyumsuz istek/yanıt iletisi kullanarak bir Aracı ile iletişim kurar. Bu özellik, diğer dağıtılmış mesajlaşma teknolojilerinin de kullanılabilmesine rağmen kuyruklar kullanılarak uygulanır.

  Zamanlayıcı, İşlem Yöneticisi düzeninde İşlem Yöneticisi’ne benzer bir işlev gerçekleştirir. Gerçek iş akışı genellikle Zamanlayıcı ile denetlenen bir iş akışı altyapısı tarafından tanımlanıp uygulanır. Bu yaklaşım, iş akışındaki iş mantığını Zamanlayıcı’dan ayırır.

• Aracı, bir uzak hizmete çağrıyı veya bir görevin adımı tarafından başvurulan uzak kaynağa erişimi kapsayan mantığı içerir. Her Aracı genellikle çağrıları tek bir hizmet ya da kaynağa sarmalar ve uygun hata işleme ile yeniden deneme mantığını uygular (daha sonra açıklanacak bir zaman aşımı kısıtlamasına tabidir). Yeniden deneme mantığını uygularken, uzak hizmetin sahip olabileceği yinelenenleri kaldırma mantığı için kullanabilmesi için tüm yeniden deneme girişimleri arasında kararlı bir tanımlayıcı geçirin. Zamanlayıcı çalıştırılmakta olan iş akışındaki adımlar, farklı adımlarda birkaç hizmet ve kaynak kullanır ve her adım farklı bir Aracıya başvurabilir (bu, düzenin uygulama ayrıntısıdır).

• Gözetmen, Zamanlayıcı tarafından gerçekleştirilen görevdeki adımların durumunu izler. Düzenli aralıklarla çalışır (sıklık sisteme özgü olacaktır) ve Zamanlayıcı tarafından tutulan adımların durumunu inceler. Zaman aşımına uğramış veya başarısız olmuş bir adım algılarsa, adımı kurtarmak veya uygun düzeltici işlemi yürütmek (bunun için adım durumunun değiştirilmesi gerekebilir) üzere uygun Aracıyı ayarlar. Kurtarma veya düzeltici işlemler Zamanlayıcı ve Aracılar tarafından uygulanır. Gözetmen bu eylemlerin gerçekleştirilmesini istemelidir.

Zamanlayıcı, Aracı ve Gözetmen mantıksal bileşenlerdir ve fiziksel uygulaması, kullanılan teknolojiye bağlıdır. Örneğin, tek bir web hizmetinin parçası olarak birkaç mantıksal aracı uygulanabilir.

Zamanlayıcı, görevin ilerleme durumuna ve her bir adımın durumunda ilişkin bilgileri, durum deposu adlı dayanıklı bir veri deposunda tutar. Gözetmen, bir adımın başarısız olup olmadığını belirlemek üzere bu bilgileri kullanabilir. Şekilde Zamanlayıcı, Aracılar, Gözetmen ve durum deposu arasındaki ilişki gösterilmektedir.

Uygulama bir görevi çalıştırmaya hazır olduğunda Zamanlayıcı’ya bir istek gönderir. Zamanlayıcı, görevle ilgili başlangıç durumu bilgilerini (örneğin, adım henüz başlatılmadı) durum deposuna kaydeder ve sonra iş akışı tarafından tanımlanmış işlemleri gerçekleştirmeye başlar. Zamanlayıcı bir adımı başlattığında, durum deposunda bu adımın durum bilgilerini günceller (örneğin, adım çalışıyor).

Bir adım uzak bir hizmet ya da kaynağa başvuruyorsa Zamanlayıcı uygun Aracıya bir ileti gönderir. İleti, Aracının hizmete geçirmesi veya kaynağa erişmesi için gereken bilgilerin yanı sıra işlemin son tamamlanma saatini içerir. Aracı, işlemini başarıyla tamamlarsa Zamanlayıcı’ya bir yanıt döndürür. Bundan sonra Zamanlayıcı, durum deposundaki durum bilgilerini güncelleyebilir (örneğin, adım tamamlandı) ve sonraki adımı gerçekleştirebilir. Bu işlem tüm görev tamamlanana kadar devam eder.

Bir Aracı, işini gerçekleştirmek için gerekli olan herhangi bir yeniden deneme mantığını uygulayabilir. Ancak, Aracı son tamamlanma süresi dolmadan önce işini tamamlamazsa, Zamanlayıcı işlemin başarısız olduğunu varsayar. Bu durumda, Aracı işini durdurmalı Zamanlayıcı’ya herhangi bir şey döndürmeyi (hata iletisi bile) veya herhangi bir kurtarma biçimini denememelidir. Bu kısıtlamanın nedeni, bir adım zaman aşımına uğradıktan veya başarısız olduktan sonra başka bir Aracı örneğinin başarısız adımı çalıştıracak şekilde zamanlanmış olabilmesidir (bu işlem daha sonra açıklanacaktır).

Aracı başarısız olursa Zamanlayıcı bir yanıt almaz. Düzen, zaman aşımına uğramış bir adım ile gerçekten başarısız olmuş bir adımı birbirinden ayırt edemez.

Bir adım zaman aşımına uğrar veya başarısız olursa, durum deposu adımın çalıştırıldığını belirten bir kayıt içerir ancak son tamamlanma saati geçmiş olur. Gözetmen buna benzer adımları arar ve kurtarmayı dener. Olası stratejilerden biri, Gözetmen'in adımı tamamlamak için kullanılabilir süreyi uzatmak için complete-by değerini güncelleştirmesi ve zaman aşımına uğradı adımı tanımlayan zamanlayıcıya bir ileti göndermesidir. Zamanlayıcı daha sonra bu adımı yinelemeyi deneyebilir. Ancak, bu tasarım görevlerin bir kez etkili olmasını gerektirir. Sistem tutarlılığı korumak için altyapı içermelidir. Daha fazla bilgi için bkz . Yinelenebilir Altyapı, Dayanıklılık ve kullanılabilirlik için Azure uygulamalarının mimarisini oluşturma ve Kaynak tutarlılığı karar kılavuzu.

Gözetmen sürekli başarısız olursa veya zaman aşımına uğradıysa aynı adımın yeniden denenmesini engellemesi gerekebilir. Bunu yapmak için Gözetmen, durum deposundaki durum bilgileriyle birlikte her adım için yeniden deneme sayısını koruyabilir. Bu sayısı önceden tanımlı bir eşiği aşarsa Gözetmen, arızanın bu süre boyunca çözümlenebileceği beklentisiyle, Zamanlayıcı’ya adımı yeniden denemesi gerektiğini bildirmeden önce uzun bir süre bekleme stratejisini benimseyebilir. Alternatif olarak, Gözetmen bir Telafi İşlemi düzeni uygulanarak tüm görevin geri alınmasını istemek üzere Zamanlayıcı’ya bir ileti gönderebilir. Bu yaklaşım, Zamanlayıcı ve Aracıların başarıyla tamamlanan her adım için telafi işlemleri uygulamak üzere gerekli bilgileri sağlamasına bağlıdır.

Zamanlayıcı ve Aracıların izlenmesi ve başarısız olmaları durumunda yeniden başlatılması Gözetmenin amacı değildir. Sistemin bu özelliği, bu bileşenlerin çalıştığı altyapı tarafından kullanılmalıdır. Benzer şekilde, Gözetmen gerçek iş işlemleri hakkında Zamanlayıcı tarafından gerçekleştirilmekte olan görevlerin çalıştığını (bu görevlerin başarısız olması durumunda nasıl telafi edileceği de dahil olmak üzere) bilmemelidir. Zamanlayıcı tarafından uygulanan iş akışı mantığı bunu amaçlar. Gözetmenin tek sorumluluğu bir adımın başarısız olup olmadığını belirlemek ve yinelenmesini ya da başarısız adımı içeren tüm görevin geri alınmasını ayarlamaktır.

Zamanlayıcı bir hatadan sonra yeniden başlatılırsa veya Zamanlayıcı tarafından gerçekleştirilen iş akışı beklenmedik şekilde sonlandırılırsa, Zamanlayıcı başarısız olduğunda gerçekleştirmekte olduğu tüm devam eden görevlerin durumunu belirleyebilmeli ve bu görevi o noktadan itibaren sürdürmeye hazır olmalıdır. Bu işlemin uygulama ayrıntıları sisteme özgü olabilir. Görev kurtarılamıyorsa, görev tarafından zaten gerçekleştirilmiş işin geri alınması gerekebilir. Bunun için bir telafi işlemi uygulanması da gerekebilir.

Bu düzenin temel avantajı, sistemin beklenmeyen geçici veya kurtarılamaz hatalar durumunda dayanıklı olmasıdır. Sistem kendi kendini iyileştirici olacak şekilde oluşturulabilir. Örneğin, bir Aracı ya da Zamanlayıcı başarısız olursa yeni bir tane başlatılabilir ve Gözetmen bir görevin sürdürülmesini ayarlayabilir. Gözetmen başarısız olursa başka bir örnek başlatılabilir ve hatanın gerçekleştiği noktadan itibaren görevi üstlenebilir. Gözetmen düzenli aralıklarla çalışacak şekilde zamanlanmışsa, önceden tanımlı bir aralıktan sonra otomatik olarak yeni bir örnek başlatılabilir. Durum deposu çok daha yüksek bir dayanıklılık derecesine ulaşmak üzere çoğaltılabilir.

Sorunlar ve dikkat edilmesi gerekenler

Bu düzeni nasıl uygulayacağınıza karar verirken aşağıdaki noktaları dikkate almalısınız:

• Bu düzenin uygulanması zor olabilir ve sistemin her olası hata modunun kapsamlı bir şekilde test edilmesini gerektirir.

• Zamanlayıcı tarafından uygulanan kurtarma/yeniden deneme mantığı karmaşıktır ve durum deposunda saklanan durum bilgilerine bağlıdır. Bir telafi işlemini uygulamak için gereken bilgilerin dayanıklı bir veri deposuna kaydedilmesi de gerekebilir. Telafi işlemi de başarısız olabilir.

• Gözetmenin ne sıklıkta çalıştığı önemlidir. Başarısız adımların bir uygulamayı uzun bir süre boyunca engellemesini önleyecek sıklıkta çalışmalı, ancak ek yük haline geleceği sıklıkta çalışmamalıdır.

• Bir Aracı tarafından gerçekleştirilen adımlar birden çok kez çalıştırılabilir. Bu adımları uygulayan mantık bir kez etkili olmalıdır.

Bu düzenin kullanılacağı durumlar

Bulut gibi dağıtılmış bir ortamda çalışan bir işlemin iletişim hatasına ve/veya işlem hatasına karşı dayanıklı olması gerektiğinde bu düzeni kullanın.

Bu düzen, uzak hizmetleri çağırmayan veya uzak kaynaklara erişmeyen görevler için uygun olmayabilir.

İş yükü tasarımı

Bir mimar, Azure İyi Tasarlanmış Çerçeve yapılarında ele alınan hedefleri ve ilkeleri ele almak için Scheduler Aracı Gözetmeni deseninin iş yükünün tasarımında nasıl kullanılabileceğini değerlendirmelidir. Örneğin:

Herhangi bir tasarım kararında olduğu gibi, bu desenle ortaya konulabilecek diğer sütunların hedeflerine karşı herhangi bir dengeyi göz önünde bulundurun.

Örnek

Microsoft Azure’da, e-ticaret sistemi uygulayan bir web uygulaması dağıtılmıştır. Kullanıcılar bu uygulamayı çalıştırarak kullanılabilir ürünlere göz atabilir ve sipariş verebilir. Kullanıcı arabirimi bir web rolü olarak çalışır ve uygulamanın sipariş işleme öğeleri, bir çalışan rolleri kümesi olarak uygulanır. Sipariş işleme mantığının bir kısmı uzak bir hizmete erişim gerektirir ve sistemin bu yönü, geçici ya da daha uzun süreli arızalara yatkın olabilir. Bu nedenle tasarımcılar, sistemin sipariş işleme öğelerini uygulamak için Zamanlayıcı Aracısı Gözetmeni düzenini kullanmıştır.

Bir müşteri sipariş verdiğinde, uygulama siparişi açıklayan bir ileti oluşturur ve bu iletiyi bir kuyruğa gönderir. Bir çalışan rolü içinde çalışan ayrı bir gönderme işlemi ise iletiyi alır, sipariş ayrıntılarını sipariş veritabanına ekler ve durum deposunda sipariş işleminin bir kaydını oluşturur. Sipariş veritabanı ve durum deposu içindeki eklemelerin aynı işlem kapsamında gerçekleştirildiğini unutmayın. Gönderme işlemi her iki eklemenin de birlikte tamamlanmasını sağlayacak şekilde tasarlanmıştır.

Gönderme işleminin sipariş için oluşturduğu durum bilgileri şunlardır:

• OrderID. Sipariş veritabanındaki sipariş kimliği.

• LockedBy. Siparişi işleyen çalışan rolünün örnek kimliği. Zamanlayıcı tarafından çalıştırılan çalışan rolünün birden fazla geçerli örneği olabilir, ancak her sipariş yalnızca tek bir örnek tarafından işlenmelidir.

• CompleteBy. Siparişin işlenmesi gereken en son zaman.

• ProcessState. Siparişi işleyen görevin geçerli durumu. Olası durumlar şunlardır:

  • Beklemede. Sipariş oluşturuldu ancak işleme henüz başlamadı.
  • İşleniyor. Sipariş şu anda işleniyor.
  • İşlendi. Sipariş başarıyla işlendi.
  • Hata. Sipariş işleme başarısız oldu.

• FailureCount. Sipariş için işlemenin denenme sayısı.

Bu durum bilgilerinde OrderID alaı, yeni siparişin sipariş kimliğinden kopyalanır. LockedBy ve CompleteBy alanları null, ProcessState alanı Pending ve FailureCount alanı 0 olarak ayarlanır.

Zamanlayıcı ayrıca bir çalışan rolünün parçası olarak çalışır ve siparişi işleyen iş mantığını uygular. Zamanlayıcı’nın yeni siparişleri yoklayan bir örneği, LockedBy alanının null ve ProcessState alanının beklemede olduğu kayıtlar için durum deposunu inceler. Zamanlayıcı yeni bir sipariş bulduğunda LockedBy alanını kendi örnek kimliği ile hemen doldurur, CompleteBy alanını uygun bir saate ayarlar ve ProcessState alanını işleniyor olarak ayarlar. Kod, iki zamanlı Zamanlayıcı örneğinin aynı siparişi aynı anda işlemeye çalışamadığından emin olmak için özel ve atomik olacak şekilde tasarlanmıştır.

Zamanlayıcı daha sonra siparişi zaman uyumsuz olarak işlemek için iş akışını çalıştırır ve durum deposunun OrderID alanındaki değerini geçirir. Siparişi işleyen iş akışı, sipariş veritabanından siparişin ayrıntılarını alır ve kendi işini gerçekleştirir. Sipariş işleme iş akışındaki bir adımın uzak hizmeti çağırması gerekirse Aracıyı kullanır. İş akışı adımı, istek/yanıt kanalı gibi davranan bir çift Azure Service Bus ileti kuyruğunu kullanarak Aracı ile iletişim kurar. Şekilde, çözümün üst düzey bir görünümü gösterilir.

Bir iş akışı adımından Aracıya gönderilen ileti, siparişi açıklar ve son tamamlanma saatini içerir. Aracı son tamamlanma saati dolmadan önce uzak hizmetten bir yanıt alırsa, iş akışının dinlediği Service Bus kuyruğuna bir yanıt iletisi gönderir. İş akışı adımı geçerli yanıt iletisini aldığında, işlemeyi tamamlar ve Zamanlayıcı sipariş durumunun alanını işlenmek üzere ayarlar ProcessState . Bu noktada, sipariş işleme başarıyla tamamlanmıştır.

Aracı uzak hizmetten bir yanıt almadan önce son tamamlanma saati dolarsa, Aracı işlemeyi durdurur ve siparişi işlemeyi sonlandırır. Benzer şekilde, siparişi işleyen iş akışı son tamamlanma saatini aşarsa o da sonlandırılır. Her iki durumda da siparişin durum deposundaki durumu işleniyor olarak kalır; ancak son tamamlanma saati, siparişi işleme saatinin geçtiğini gösterir ve işlemin başarısız olduğu kabul edilir. Uzak hizmete erişen Aracının veya siparişi işleyen iş akışının (ya da her ikisinin) beklenmedik şekilde sonlandırılması durumunda, durum deposundaki bilgilerin işleniyor olarak kalacağını ve son tamamlanma saatinin dolacağını unutmayın.

Aracı uzak hizmet ile iletişim kurmaya çalışırken kurtarılamaz ve geçici olmayan bir arıza algılarsa, iş akışına bir hata yanıtı gönderir. Zamanlayıcı, siparişin durumunu hata olarak ayarlayabilir ve operatörü uyaran bir olay tetikleyebilir. Operatör bundan sonra hatanın nedenini el ile çözümlemeyi ve başarısız işleme adımını yeniden göndermeyi deneyebilir.

Gözetmen, son tamamlanma saati dolmuş siparişleri aramak için durum deposunu düzenli aralıklarla inceler. Gözetmen bir kayıt bulursa FailureCount alanını artırır. Hata sayısı değeri belirtilen bir eşik değerinin altındaysa, Gözetmen LockedBy alanını null olarak sıfırlar, CompleteBy alanını yeni bir sona erme saati ile güncelleştirir ve ProcessState alanını bekliyor olarak ayarlar. Bir Zamanlayıcı örneği bu siparişi alıp daha önceki gibi işleyebilir. Hata sayısı değeri belirtilen bir eşiği aşarsa, başarısızlık nedeninin geçici olmadığı varsayılır. Gözetmen, siparişin durumunu hata olarak ayarlayabilir ve operatörü uyaran bir olay tetikleyebilir.

Bu örnekte Gözetmen ayrı bir çalışan rolünde uygulanmıştır. Gözetmen görevinin çalıştırılması için, Azure Scheduler hizmeti gibi (bu düzendeki Zamanlayıcı bileşeni ile karıştırılmamalıdır) çeşitli stratejiler kullanabilirsiniz. Azure Scheduler hizmeti hakkında daha fazla bilgi için Scheduler sayfasını ziyaret edin.

Bu örnekte gösterilmemesine karşın, Zamanlayıcının siparişi gönderen uygulamayı siparişin ilerlemesi ve durumu hakkında bilgilendirmesi gerekebilir. Uygulama ve Zamanlayıcı, aralarındaki bağımlılıkları ortadan kaldırmak için birbirinden yalıtılmıştır. Uygulama, hangi Zamanlayıcı örneğinin sipariş işlediğini bilmez, Zamanlayıcı ise hangi uygulama örneğinin siparişi gönderdiğinin bilincinde değildir.

Sipariş durumunun bildirilmesine izin vermek için uygulama kendi özel yanıt kuyruğunu kullanabilir. Bu yanıt kuyruğunun ayrıntıları, gönderme işlemine gönderilen isteğe ve durum deposuna eklenir. Zamanlayıcı daha sonra siparişin durumunu gösteren bu kuyruğa iletiler gönderir (istek alındı, sipariş tamamlandı, sipariş başarısız oldu gibi). Uygulama tarafından özgün istekle ilişkilendirilebilmesi için bu iletilere sipariş kimliği eklenmelidir.

Sonraki adımlar

Bu düzeni uygularken aşağıdaki yönergeler de yararlı olabilir:

• Zaman Uyumsuz Mesajlaşma Temel Bilgileri. Zamanlayıcı Aracısı Gözetmeni düzenindeki bileşenler genellikle birbirinden ayrılmış olarak çalıştırılır ve zaman uyumsuz olarak iletişim kurar. İleti kuyruklarını temel alarak zaman uyumsuz iletişim uygulamak için kullanılabilen yaklaşımlardan bazılarını açıklar.

• Başvuru 6: Efsaneler Üzerinde Efsane. CQRS düzeninin bir işlem yöneticisini nasıl kullandığını gösteren örnek (CQRS Yolculuğu kılavuzunda).

• Microsoft Azure Scheduler

İlgili kaynaklar

Bu desen uygulanırken aşağıdaki desenler de uygun olabilir:

• Yeniden deneme düzeni. Aracı, daha önce başarısız olmuş uzak bir hizmete veya kaynağa erişen bir işlemi şeffaf bir şekilde yeniden denemek için bu düzeni kullanabilir. Hata nedeninin geçici olduğu ve düzeltilebileceği beklendiğinde kullanın.

• Devre Kesici düzeni. Aracı, uzak hizmete veya kaynağa bağlanırken değişken bir süre boyunca devam eden arızları düzeltmek için bu düzeni kullanabilir.

• Telafi İşlemi düzeni. Bir Zamanlayıcı tarafından gerçekleştirilmekte olan iş akışı başarıyla tamamlanamıyorsa, daha önce gerçekleştirilen işlerin geri alınması gerekebilir. Telafi İşlemi düzeni, son tutarlılık modelini izleyen işlemler için bunun nasıl gerçekleştirilebileceğini açıklar. Bu tür işlemler genellikle karmaşık iş süreçleri ve iş akışları uygulayan bir Zamanlayıcı tarafından uygulanır.

• Öncü Seçimi düzeni. Aynı başarısız işlemi kurtarmayı denemelerini önlemek için, bir Gözetmenin birden fazla örneğinin eylemlerini koordine etmek gerekli olabilir. Öncü Seçimi düzeni bunun nasıl yapılacağını açıklar.

• Bulut Mimarisi: Clemens Vasters blogundaki Scheduler-Agent-Supervisor deseni

• İşlem Yöneticisi düzeni