Koreografi düzeni

Merkezi bir düzenleyiciye bağlı olarak değil, bir iş işleminin ne zaman ve nasıl işlendiğine her hizmetin karar vermesini sağlayın. Bu yaklaşım, iş akışı mantığını merkezi olmayan hale getirir ve sorumlulukları sistemin bileşenleri arasında dağıtır.

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. Düzenleyici başarısız olduğunda veya aşırı yüklendiğinde, hata tüm bağımlı aşağı akış hizmetlerine yayılabilir.

Çö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 yayımlayabilir, böylece gerekirse başka bir hizmet iş akışına devam edebilir. İşlem başarısız olursa, hizmet bir hata iletisi yayımlar. Bu iletiye abone olan hizmetler, başarısız işlem veya işlemin tamamı için önceden tanımlanmış telafi eylemleri çalıştırabilir.

Sorunlar ve dikkat edilmesi gerekenler

Bu düzenin nasıl uygulanacağına karar verirken aşağıdaki noktaları göz önünde bulundurun:

• Karmaşıklığı işleme hatası. 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.

• Sıralı işlemler. 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.

• Büyük ölçekte gözlemlenebilirlik. 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. Tam işlem durumunu tutan merkezi bir düzenleyici olmadan, tek bir bileşenin uçuş içi iş işleminin tam görünümü yoktur. Gözlemlenebilirliği korumak için sürekli olarak dağıtılmış izleme ve bağıntı tanımlayıcıları kullanmanız gerekir.

• Dayanıklılık işleyicisi iletişimi. Orkestratör odaklı bir tasarımda merkezi bileşen, geçici, geçici olmayan ve zaman aşımı kaynaklı hatalar için yeniden deneme yönetimi gibi dayanıklılık sorumluluklarını özel bir dayanıklılık işleyicisine devredebilir.

  Koreografi tabanlı bir tasarımda orkestratörü kaldırdığınızda, alt akıştaki bileşenler dayanıklılık sorumluluğunu ü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ı evrimi. 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.

• İdempotentlik ve olay sıralaması. En az bir kez teslimat ve yeniden denemeler yinelenen mesajlar üretebilir; eşzamanlı tüketiciler de mesajları sıra dışında işleyebilir. Sabit mesaj tanımlayıcılarını izleyerek tüketicileri idempotent olacak şekilde tasarlayın. Sıralı işleme gerektiğinde, Service Bus oturumları gibi aracı özelliklerini kullanın veya tüketicilerin eski olayları reddetmesini ve boşlukları algılamasını sağlayan sıra veya sürüm verileri ekleyin.

• Atomik durum ve olay yayını. Veri deposunu güncelleştiren ve ayrı işlemlerde olay yayımlayan bir hizmet bir işlemi yürütebilirken diğeri başarısız olabilir. Durum değişikliğini ve olayı, olayın ayrı bir süreç tarafından yayımlanmasından önce birlikte kalıcı olarak kaydetmek için Transactional Outbox desenini veya eşdeğer bir atomik mekanizma kullanın.

• Ortaya çıkan davranış ve olay fırtınaları. 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 fire and forget yaklaşımıyla bağımsız olarak ele alır. Her bileşen bir görevi tamamlar ve ardından ileti aracısı aracılığıyla diğer bileşenlere tamamlanma sinyali gönderir. Başlatan hizmet, görevi gönderdikten sonra onu aktif olarak yönetmez ya da takip etmez; ancak aşağı akış hizmetleri sonuçları olaylar üzerinden bildirmeye devam eder.

• 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 sınırlanmış bağlam içindeki iletişim için karmaşıklık ve ekip tercihlerine bağlı olarak bunun yerine bir düzenleyici deseni düşünü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

Herhangi bir tasarım kararında olduğu gibi, bu desenle ortaya çıkabilecek diğer sütunların hedeflerine karşı yapılabilecek tavizleri göz önünde bulundurun.

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. Tam başvuru mimarisi için bkz. Azure Container Apps ile mikro hizmetler.

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ğradıysa, hizmet hata neden kodunu ileti veriyoluna bildirir ve Azure Service Bus aracılığıyla iletiyi geçersiz yazar. Hizmet ayrıca belirli bir süre içinde alamayacağı veya işleyebildiği iletileri de geçersiz yazar.

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ü Azure Container Apps üzerinde çalışır. Alma hizmeti Container Apps'te barındırılan bir Azure İşlevi olarak çalışırken paket, insansız hava aracı zamanlayıcı ve teslim hizmetleri aynı Container Apps ortamında mikro hizmetler olarak ç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. Teslimat hizmetinin her işlem için gereken iki iletiyi ilişkilendirebilmesi amacıyla, bir GUID’yi teslim tanımlayıcısıyla eşleştiren ortak bir oturum tanımlayıcısı ekleyin. Bir mesaj paketin hazır olduğunu doğrular, diğer mesaj ise insansız hava aracının zamanlanmış olduğunu onaylar. Bu oturum tabanlı bağıntı olmadan, hiçbir merkezi koordinatör işlem durumunu izlemediğinden, teslim hizmetinin ilişkili iletileri bağımsız atlamalar arasında ilişkilendirmesinin bir yolu yoktur. 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 deseni AKS gibi başka bir bilgi işlem hizmetinde dağıtırsanız, iş uygulamasıyla aynı pod içinde bir ambassador'ı sidecar olarak dağıtabilirsiniz. Aynı yerde konumlandırma iletişim gecikmesini en aza indirir, ancak ara sunucu işleme ve kaynak kullanımı açısından ek yük getirir ve uygulamayla birlikte ölçeklenir. Platformun sağlamadığı dilden bağımsız bağlantı endişelerine ihtiyaç duyduğunuzda bu yaklaşımı kullanın.

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ım

• 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.

İlgili kaynaklar

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

• İleti veri yolu ile iş hizmeti iletişimini modüler hale getirmek için Büyükelçi desenini kullanı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.