Koreografi düzeni

Koreografi düzeni, iş akışı mantığını merkezi olmayan hale getirir ve sorumlulukları sistemdeki diğer bileşenlere dağıtır. Merkezi bir düzenleyiciye bağlı olmak yerine, hizmetler bir iş işleminin ne zaman ve nasıl işlendiğine karar verir.

Bağlam ve sorun

Bulut tabanlı bir uygulamayı genellikle uçtan uca iş işlemlerini işlemek için birlikte çalışan birkaç küçük hizmete bölersiniz. Bir işlem içindeki tek bir işlem, tüm hizmetler arasında birden çok noktadan noktaya çağrıya neden olabilir. İdeal olarak, bu hizmetler gevşek bir şekilde birleştirilir. Karmaşık hizmetler arası iletişim içerdiği için dağıtılmış, verimli ve ölçeklenebilir bir iş akışı tasarlamak zordur.

İletişim için yaygın bir desen, merkezi bir hizmet veya düzenleyici kullanmaktır. Gelen istekler, işlemleri ilgili hizmetlere devredecek şekilde orkestratörden geçer. Her hizmet kendi sorumluluğunu tamamlar ve genel iş akışının farkında değildir.

Sol tarafta, istemci isteğini temsil eden bir ok, diyagramın ortasındaki bir istemci simgesinden düzenleyici simgesine işaret eder. Orkestratör simgesi ile sağda dikey olarak yerleştirilmiş olan hizmet A, hizmet B ve hizmet C simgeleri arasında üç çift yönlü ok bulunmaktadır. Bu oklar, düzenleyicinin hizmetlere istekleri nasıl gönderdiğini ve nasıl yanıt aldığını gösterir. Diyagram, merkezi düzenleyici bileşeninin tüm aşağı akış hizmetleriyle iletişimi nasıl koordine edip yönettiğini gösterir.

Orkestratör desenini genellikle sistem içindeki hizmetlerin sorumlulukları hakkında alan bilgisi olan özelleştirilmiş yazılım olarak uygularsınız. Bu yaklaşımın avantajlarından biri, düzenleyicinin aşağı akış hizmetlerinin yürüttüğü tek tek işlemlerin sonuçlarına göre bir işlemin durumunu birleştirebiliyor olmasıdır.

Bu yaklaşım bazı engeller de oluşturur. İletişim yolunun bölümlerini yeniden bağlamanız gerektiğinden, hizmetlerin eklenmesi veya kaldırılması mevcut mantığı bozabilir. Bu bağımlılık orchestrator uygulamasını karmaşık ve bakımı zor hale getirir. Orkestratör, yükün güvenilirliğini olumsuz etkileyebilir. Yük altında performans darboğazlarına yol açabilir ve tek hata noktası (SPoF) olabilir. Ayrıca aşağı akış hizmetlerinde basamaklı hatalara neden olabilir.

Çözüm

Hizmetler arasında işlem işleme mantığını dağıtın. Her hizmetin bir iş operasyonu için iletişim iş akışına katılmasına ve ne zaman ve nasıl işlendiğine karar vermesine izin verin.

Koreografi düzeni, iletişim iş akışını merkezileştiren özel yazılım bağımlılığını en aza indirir. Bileşenler, birbirleriyle doğrudan iletişim kurmadan iş akışını düzenlerken ortak bir mantık uygular.

Koreografiyi uygulamanın yaygın yollarından biri, istekleri alt akış bileşenleri talep edene ve işleyene kadar arabelleğe alan bir mesaj aracısı kullanmaktır. Aşağıdaki görüntüde , yayımcı-abone modeli aracılığıyla istek işleme gösterilmektedir.

Diyagramda, hizmet iletişimini koordine etmek için ileti aracısı kullanan bir koreografi deseni uygulaması gösterilmektedir. Sol tarafta, bir istemci isteği simgesinden, merkezi ileti aracısını temsil eden bir kutunun içindeki üç zarf simgesine işaret eden bir ok bulunmaktadır. İleti aracısı ve hizmetleri A, hizmet B ve hizmet C'ye bağlayan üç çift yönlü ok. Bu oklar, hizmetlerin hem aracıdan ileti aldığını hem de aracıya yanıt gönderdiğini gösterir.

1. İstemci, bir ileti aracısı içinde ileti olarak kuyruk isteğinde bulunur.

2. Hizmetler veya abone, aracıyı yoklar ve bu iletiyi uygulanan iş mantığına göre işleyip işleyemeyeceğini belirler. Aracı, bu mesajla ilgilenen abonelere de mesaj iletebilir.

3. Abone olunan her hizmet, iletinin belirttiği gibi işlemini yapar ve aracıya bir işlem başarılı veya hata iletisiyle yanıt verir.

4. İşlem başarılı olursa, hizmet bir iletiyi aynı kuyruğa veya farklı bir ileti kuyruğuna göndererek başka bir hizmetin gerekirse iş akışına devam edebilmesini sağlayabilir. İşlem başarısız olursa, ileti aracısı bu işlemi veya işlemin tamamını telafi etmek için diğer hizmetlerle birlikte çalışır.

Sorunlar ve dikkat edilmesi gerekenler

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

• Hataların işlenmesi zor olabilir. Bir uygulamadaki bileşenler atomik görevleri yönetebilir ve sistemin diğer bölümlerine bağımlı olabilir. Bir bileşendeki hata diğer bileşenleri etkileyebilir ve bu da genel isteğin tamamlanmasında gecikmelere neden olabilir.

  Hataları düzgün bir şekilde işlemek için, karmaşıklığa neden olan hata işleme mantığını uygularsınız. Telafi işlemleri gibi hata işleme mantığı da hatalara açıktır.

  

  Akış çizelgesi, sıralı hizmet bağımlılıklarına sahip bir koreografi deseninde hata işleme ve telafi mantığını gösterir. En üstte, başlangıç düğümü A hizmetini gösterir. Hizmet A, soldaki B hizmetine ve sağdaki C hizmetine işaret eden bir elmasa bağlanır. Her bir hizmetten, isteğin başarısız olup olmadığını soran bir karar elmasına oklar işaret eder. Evet olarak etiketlenmiş yol, yukarıya doğru bir döngü yaparak üç hizmeti bağlayan baklava şekline geri dallanır. Hayır etiketli yol, her iki hizmetin de başarılı olduğunu okuyan bir kutuya devam eder. Bu başarı durumundan, akış D hizmetine doğru aşağı doğru devam eder ve bu da isteğin başarısız olup olmadığını soran son karar elması bağlantısına bağlanır. Bu baklavadan gelen evet yolu, D hizmetinden önce akışa yeniden giriş yapmak için yukarı doğru geri döner ve hayır yolu da bir bitiş düğümüne doğru aşağı devam eder.

• Bu desen, bağımsız iş operasyonlarını paralel olarak işleyen bir iş akışına uygundur. Koreografinin bir sırada gerçekleşmesi gerektiğinde iş akışı karmaşık hale gelebilir. Örneğin, Hizmet D ancak Hizmet B ve Hizmet C işlemlerini başarıyla tamamladıktan sonra işlemini başlatabilir.

  

  Diyagramda, hizmetlerin işlemleri paralel ve sıralı olarak işlediği bir koreografi düzeninde ileti akışı gösterilir. En üstte yatay olarak düzenlenmiş beş bileşen bulunur: hizmet A, ileti aracısı, hizmet B, hizmet C ve hizmet D. En sol tarafta, kullanıcı A hizmetine bir istek gönderir. A Hizmeti, isteği ileti m1_a dönüştürür ve ileti aracısı için yayımlar. İleti aracısı altında, dikey bir zaman çizelgesi her hizmetin iletileri nasıl işlediğini gösterir. paralel işleme için "par" olarak etiketlenmiş gölgeli bir bölgenin içinde, mesaj aracısı m1_a'yı kesikli oklarla aynı anda hem B hizmetine hem de C hizmetine teslim eder. B hizmeti iletiyi işler ve m1_b ileti aracısına döndürür. C hizmeti iletiyi işler ve m1_c ileti aracısına döndürür. Diyagramın sağ tarafında iki küçük kutu, D hizmeti için bekleme koşullarını temsil eder. İlk koşul, m1_b ve m1_c alınana kadar bekle olarak belirtilir. Bu, D hizmetinin her iki iletiyi de alıncaya kadar ilerleyemeyeceğini gösterir. İkinci koşulda m1_b kadar bekle ifadesi yer alır. Paralel işleme tamamlandıktan ve hem hizmet B hem de hizmet C yanıtladıktan sonra, ileti aracısı D hizmetine m1_c ve ardından m1_b gönderir. Hizmet D bu iletileri işler ve m1_d ileti aracısına döndürür. Diyagramın altında, her gösterimi bir gösterge açıklar. İstek, genel uç noktaya gönderilen özgün HTTP isteğini ifade eder. M1_a, HTTP isteği iletiye dönüştürülür. M1_b, ileti işlenip B hizmetinden ileti aracısına geri gönderilir. M1_c, ileti işlenir ve C hizmetinden ileti aracısına geri gönderilir ve m1_d m1_b ve m1_c işlendiğini ve ileti aracısı için son onay olarak geri gönderildiğini gösterir. Düz oklar yayımlama iletilerini, kesikli oklar ise abone olma iletilerini gösterir.

• Bu düzen, hizmet sayısının hızla artma durumunda zorluklara neden olur. Birçok bağımsız taşıma parçası, iş akışını hizmetler arasında karmaşıklaştırır. Gözlemlenebilirliği korumak için sürekli olarak dağıtılmış izleme ve bağıntı tanımlayıcıları kullanmanız gerekir.

• Orkestratör liderliğindeki bir tasarımda, merkezi bileşen geçici, kalıcı ve zaman aşımı hataları gibi dayanıklılık sorumluluklarını, yeniden deneme işlerini içerecek şekilde, ayrılmış bir dayanıklılık işleyicisine devredebilir.

  Koreografi tabanlı bir tasarımda orkestratörü kaldırdığınızda, alt bileşenler dayanıklılık sorumluluklarını üstlenmez. Esneklik işleyicisinde merkezi olarak kalırlar. Ancak aşağı akış bileşenlerinin doğrudan bu işleyiciyle iletişim kurması gerekir ve bu da noktadan noktaya iletişimi artırır.

• Olay şemasının evrimi, zaman içinde tüketicilerde çalışmayı kesintiye uğratan değişikliklere yol açabilir. Bu düzende, birden çok bağımsız hizmet aynı olayları tüketir. Üretici bir olayın veri yapısını değiştirirse, eski şemaya bağlı olan akış tüketicilerini bölebilir. Olay sözleşmelerini yönetmek için bir şema kayıt defteri kullanın ve hizmetler bağımsız olarak geliştikçe geriye dönük uyumlu evrimi kullanın.

• Yeniden deneme girişimleri veya ölçek büyütme kapsamında olay sıralaması garanti edilmez. Yinelenen veya sıra dışı olayları işlemek için idempotans tasarlayın ve iletileri sıralı olarak yeniden yayınlayın.

• Merkezi olmayan olay topolojileri büyük ölçekte yeni bir davranış oluşturabilir. Birçok hizmet birbirinin olaylarına tepki gösteriyorsa, sistem istemeden geri bildirim döngüleri veya olay fırtınaları oluşturabilir. Küçük bir olay, aşağı akış reaksiyonlarını art arda tetikleyebilir. Döngüsel olay zincirlerini önlemek için olay filtreleme, tüketici eşzamanlılık sınırları, kısma ve açık kurallar gibi korumaları kullanın.

Bu desen ne zaman kullanılır?

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

• Aşağı akış bileşenleri atomik işlemleri bağımsız olarak işler. Bu düzeni, bir bileşenin etkin yönetim gerektirmeyen bir görev yaptığı bir ateşle ve unut mekanizması olarak düşünün. Görev tamamlandığında, bileşen diğer bileşenlere bir bildirim gönderir.

• Bileşenleri sık sık güncelleştirmeyi ve değiştirmeyi beklersiniz. Bu düzen, mevcut hizmetlerde daha az çaba ve en az kesintiyle uygulamayı değiştirmenize olanak tanır.

• Basit iş akışları için sunucusuz mimariler kullanırsınız. Bileşenler kısa süreli ve olay odaklı olabilir. Bir olay oluştuğunda, hizmet bir görevi yerine getiren bileşenler oluşturur ve hizmet bu görevi tamamladıktan sonra bileşenleri kaldırır.

• Sınırlanmış bağlamlar arasındaki iletişim, etki alanı sınırları arasında gevşek bağlantı gerektirir. Tek bir sınırlanmış bağlam içindeki iletişim için bunun yerine bir düzenleyici deseni uygulayın.

• Merkezi düzenleyici bir performans darboğazına yol açar.

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

• Uygulama karmaşıktır ve aşağı akış bileşenlerini hafif tutmak için paylaşılan mantığı işlemek için merkezi bir bileşen gerektirir.

• Bileşenler arasında noktadan noktaya iletişim kaçınılmazdır.

• Aşağı akış bileşenlerinin işlediği tüm işlemleri birleştirmek için iş mantığını kullanmanız gerekir.

İş yükü tasarımı

Azure Well-Architected Framework yapılarında ele alınan hedefleri ve ilkeleri ele almak için bir iş yükünün tasarımında Koreografi deseninin 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?
Operasyonel Mükemmellik, standartlaştırılmış süreçler ve ekip uyumu aracılığıyla iş yükü kalitesinin sunulmasına yardımcı olur.	Bu düzendeki dağıtılmış bileşenler otonom ve değiştirilebilir olacak şekilde tasarlanmıştır, böylece sistemde daha az genel değişiklikle iş yükünü değiştirebilirsiniz. - OE:04 Araçlar ve işlemler
Performans Verimliliği , ölçeklendirme, veri ve kod iyileştirmeleri aracılığıyla iş yükünüzün talepleri verimli bir şekilde karşılamasını sağlar.	Bu düzen, merkezi bir düzenleme topolojisinde performans sorunları oluştuğunda bir alternatif sağlar. - PE:02 Kapasite planlaması - PE:05 Ölçeklendirme ve bölümleme

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

Example

Bu örnekte, mikro hizmetlerle birlikte işlevler çalıştıran olay odaklı, buluta özel bir iş yükü oluşturarak Koreografi deseni gösterilmektedir. Bir İstemci bir paketi göndermeyi istediğinde, iş yükleme sistemi bir insansız hava aracı atar. Paket planlanan insansız hava aracı tarafından teslim alım için hazır olduktan sonra teslimat işlemi başlar. Paket aktarımdayken, iş yükü gönderi durumu alınana kadar teslimat sürecini yönetir.

Diyagramda Azure hizmetlerini kullanan bir insansız hava aracı teslim sistemi için olay odaklı bir koreografi uygulaması gösterilmektedir. En sol tarafta, istemci isteğini temsil eden bir ok, kullanıcı simgesinden Azure Container Apps ortamına giriş noktası olan alma etiketli kutuya işaret eder. Container Apps ortamında oklar, Azure Service Bus aracılığıyla alım hizmetini, paket mikro hizmetini, insansız hava aracı zamanlayıcısını ve teslim mikro hizmetini birbirine bağlar. Paket mikro hizmetindeki başka bir ok, Container Apps ortamının üzerinde Azure Cosmos DB etiketli bir kutuya işaret eder. Teslimat hizmetinden yukarıya doğru Azure Event Grid'e doğru akan ok, "gönderildi" olarak etiketlenmiştir. Service Bus etiketli kutunun altında, daire simgesiyle temsil edilen bir ölü harf kuyruğuna (DLQ) aşağı doğru işaret eden bir ok bulunur.

Alma hizmeti istemci isteklerini alır ve bunları teslim ayrıntılarını içeren iletilere dönüştürür. hizmetler bu yeni iletileri tükettiğinde iş işlemleri başlar.

Tek bir istemci iş işlemi için üç ayrı iş işlemi gerekir:

• Paket oluşturma veya güncelleştirme.

• Paketi teslim etmek için bir insansız hava aracı atayın.

• Teslimatı, paketin gönderildiğinde kontrol edilmesi ve bir bildirim gönderilmesi de dahil olmak üzere, işleyin.

Paket, drone zamanlayıcı ve teslimat mikro hizmetleri iş işlemeyi gerçekleştirir. Hizmetler, birbirleriyle iletişim kurmak için merkezi bir düzenleyici yerine mesajlaşmayı kullanır. Her hizmetin iş akışını merkezi olmayan bir şekilde koordine eden bir protokolü önceden uygulaması gerekir.

Design

Hizmetler, iş işlemlerini birden çok atlama aracılığıyla sırayla işler. Her atlama, tüm iş hizmetleri arasında tek bir ileti veri yolunu paylaşır.

İstemci bir HTTP uç noktası üzerinden bir teslim isteği gönderdiğinde, alma hizmeti bunu alır, bir iletiye dönüştürür ve sonra iletiyi paylaşılan ileti veri yolu için yayımlar. Abone olunan iş hizmetleri, veri yoluna eklenen yeni iletileri kullanır. Bir iş hizmeti iletiyi aldığında, işlemi başarıyla tamamlar veya istek başarısız olur ya da zaman aşımına uğrar. İstek başarılı olursa, hizmet durum koduyla Ok veri yoluna yanıt verir, yeni bir işlem iletisi oluşturur ve iletiyi mesaj veri yoluna gönderir. İstek başarısız olursa veya zaman aşımına uğrarsa, hizmet hata kodunu ileti veriyoluna göndererek başarısız olduğunu bildirir ve ardından iletiyi ölü harf kuyruğuna (DLQ) ekler. Servis ayrıca belirli bir süre içinde alınıp işlenemeyen iletileri DLQ'ya taşır.

Bu tasarım, iş işleminin tamamını işlemek için birden çok ileti veri yolları kullanır. Azure Service Bus ve Azure Event Grid , bu tasarım için mesajlaşma hizmeti platformunu sağlar. İş yükü, alma için Azure İşlevleri'ni barındıran AzureContainer Apps üzerinde çalışır. Container Apps, iş mantığını çalıştıran olay temelli işlemeyi işler.

Bu tasarım, koreografinin bir sırayla gerçekleşmesini de sağlar. Tek bir Service Bus ad alanı, iki aboneliği ve oturum duyarlı bir kuyruğu olan bir konu içerir. İçerik alma servisi başlığa mesajlar yayımlar. Paket hizmeti ve drone zamanlayıcı hizmeti, konuya abone olarak başarılı istekleri kuyruğa bildiren mesajlar yayınlar. Hizmetlerin ilişkili iletilerin ilişkisiz dizilerini sırayla işleyebilmesi için bir GUID'yi teslim tanımlayıcısıyla ilişkilendiren ortak bir oturum tanımlayıcısı ekleyin. Teslim hizmeti her işlem için iki ilgili ileti bekler. İlk ileti paketin gönderilmeye hazır olduğunu, ikinci ileti ise bir insansız hava aracının zamanlandığını belirtir.

Bu tasarımda Service Bus, tüm teslim işlemi sırasında kaybolmaması veya çoğaltılmaması gereken yüksek değerli iletileri işler. Paket geldiğinde, durum değişikliği Event Grid'de yayımlar. Olay gönderenin durum değişikliğinin nasıl işlendiğinden hiçbir beklentisi yoktur. Bu tasarımın içermediği aşağı akış kuruluş hizmetleri bu olay türünü dinleyebilir ve kullanıcıya sipariş durumu e-postası gönderme gibi belirli iş mantığını çalıştırabilir.

Bu düzeni AKS gibi başka bir işlem hizmetine dağıtırsanız, aynı poddaki iki kapsayıcıyla Publisher-Subscriber desen uygulama şablonunu uygulayabilirsiniz. Kapsayıcılardan biri seçtiğiniz ileti veri yolu ile etkileşim kuran büyükelçiyi çalıştırırken diğer kapsayıcı iş mantığını çalıştırır. Bu yaklaşım performansı ve ölçeklenebilirliği artırır. Büyükelçi ve iş hizmeti aynı ağı paylaşarak gecikme süresini azaltır ve aktarım hızını artırır.

Birden çok girişime yol açabilecek art arda yeniden deneme işlemlerini önlemek için, iş hizmetlerinin kabul edilemez iletileri hemen işaretlemesi gerekir. Hizmetlerin bunları bir DLQ'ye taşıyabilmesi için ortak neden kodları veya tanımlı bir uygulama kodu kullanarak bu iletileri zenginleştirin. Aşağı akış hizmetlerinden tutarlılık sorunlarını yönetmek için Saga desenini uygulamayı göz önünde bulundurun. Örneğin, başka bir hizmet yalnızca bir telafi, yeniden deneme veya pivot işlem çalıştırarak düzeltme amacıyla ölü harf mesajlarını işler.

Yeniden deneme işlemlerinin yinelenen kaynaklar oluşturmasını önlemek amacıyla iş hizmetleri idem-potent tasarlanmıştır. Örneğin, paket hizmeti veri deposuna veri eklemek için upsert işlemlerini kullanır.

Sonraki Adımlar

• Hizmetleriniz geliştikçe uyumluluğu korumak için Azure Event Hubs'da şema kayıt defterini kullanarak olay şeması yönetimini merkezileştirin.

• Merkezi olmayan bir iş akışı uygulamak için kullanılabilecek farklı altyapı seçenekleri hakkında bilgi edinmek için Azure'daki zaman uyumsuz mesajlaşma seçeneklerini gözden geçirin.

• Özel koreografi gereksinimleriniz için doğru Azure mesajlaşma hizmetini seçmek için farklı platformların teknik özelliklerini değerlendirin.

İlgili kaynaklar

Koreografi tasarımınızda şu desenleri göz önünde bulundurun:

• Büyükelçi desenini kullanarak iş hizmetini modüler hale alın.

• İş yükündeki ani artışları işlemek için Queue-Based Yük Dengeleme düzenini uygulayın.

• Publisher-Subscriber deseni aracılığıyla zaman uyumsuz dağıtılmış mesajlaşma kullanın.

• Bir veya daha fazla ilgili işlem başarısız olursa bir dizi başarılı işlemi geri almak için telafi işlemlerini kullanın.