Koreografi düzeni

İş akışı mantığını merkezi olmayan hale getirin ve sorumlulukları sistemdeki diğer bileşenlere dağıtın.

Bağlam ve sorun

Bulut tabanlı bir uygulama genellikle bir iş işlemini uçtan uca işlemek için birlikte çalışan birkaç küçük hizmete ayrılır. Tek bir işlem (işlem içinde) bile tüm hizmetler arasında birden çok noktadan noktaya çağrıya neden olabilir. İdeal olarak, bu hizmetlerin gevşek bir şekilde birbirine bağlı olması gerekir. Genellikle 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 devrederken düzenleyici üzerinden akar. Her hizmet yalnızca sorumluluklarını tamamlar ve genel iş akışının farkında değildir.

Düzenleyici düzeni genellikle özel yazılım olarak uygulanır ve bu hizmetlerin sorumlulukları hakkında etki alanı bilgisine sahiptir. Bunun bir avantajı, düzenleyicinin aşağı akış hizmetleri tarafından gerçekleştirilen tek tek işlemlerin sonuçlarına göre bir işlemin durumunu birleştirmesidir.

Ancak bazı dezavantajları vardır. İ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. Düzenleyicinin iş yükünün güvenilirliği üzerinde olumsuz bir etkisi olabilir. Yük altında performans sorununa neden olabilir ve tek hata noktası olabilir. Ayrıca aşağı akış hizmetlerinde basamaklı hatalara neden olabilir.

Çözüm

hizmetler arasında işlem işleme mantığını temsilci olarak belirleyin. Her hizmetin bir iş operasyonu için iletişim iş akışına karar vermesine ve bu iş akışına katılmasına izin verin.

Desen, iletişim iş akışını merkezileştiren özel yazılımlara bağımlılığı en aza indirmenin bir yoludur. Bileşenler, birbirleriyle doğrudan iletişim kurmadan iş akışını kendi aralarında koreografi yaparken ortak mantık uygular.

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

1. İstemci istekleri, ileti aracısında ileti olarak kuyruğa alınır.

2. Hizmetler veya abone, bu iletiyi uygulanan iş mantığına göre işleyebileceklerini belirlemek için aracıyı yoklar. Aracı, bu iletiyle ilgilenen abonelere de ileti gönderebilir.

3. Abone olunan her hizmet, ileti tarafından belirtilen şekilde işlemlerini yapar ve aracıya işlemin başarılı veya başarısız olmasıyla yanıt verir.

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

Düzenleyiciyi merkezi olmayan hale getirme, iş akışını yönetirken sorunlara neden olabilir.

• Teslim hataları zor olabilir. Bir uygulamadaki bileşenler atomik görevler gerçekleştirebilir ancak yine de bir bağımlılık düzeyine sahip olabilirler. 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 telafi işlemleri uygulamak karmaşıklığa neden olabilir. Telafi işlemleri gibi hata işleme mantığı da hatalara açıktır.

  

• Desen, bağımsız iş işlemlerinin paralel olarak işlendiği bir iş akışı için 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.

  

• Hizmet sayısı hızla artarsa desen bir zorluk haline gelir. Yüksek sayıda bağımsız hareketli parça göz önünde bulundurulduğunda, hizmetler arasındaki iş akışı karmaşık olma eğilimindedir. Ayrıca, dağıtılmış izleme zorlaşır.

• Düzenleyici liderliğindeki bir tasarımda merkezi bileşen, dayanıklılık mantığına kısmen katılabilir ve dayanıklılık mantığını geçici, geçici olmayan ve zaman aşımı hatalarını sürekli olarak yeniden denenen başka bir bileşene devredebilir. Koreografi düzeninde düzenleyicinin çözülmesiyle, aşağı akış bileşenleri bu dayanıklılık görevlerini almamalıdır. Bunlar yine de dayanıklılık işleyicisi tarafından işlenmelidir. Ancak artık aşağı akış bileşenlerinin dayanıklılık işleyicisi ile doğrudan iletişim kurarak noktadan noktaya iletişimi artırması gerekir.

Bu düzenin kullanılacağı durumlar

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

• Aşağı akış bileşenleri atomik işlemleri bağımsız olarak işler. Bunu bir 'ateş ve unut' mekanizması olarak düşün. Bileşen, etkin olarak yönetilmesi gerekmeyen bir görevden sorumludur. Görev tamamlandığında, diğer bileşenlere bildirim gönderir.

• Bileşenlerin sık sık güncelleştirilip değiştirilmesi beklenir. Desen, uygulamanın daha az çaba ve mevcut hizmetlerde en az kesintiyle değiştirilmesini sağlar.

• Desen, basit iş akışları için uygun sunucusuz mimariler için doğal bir uyumdur. Bileşenler kısa süreli ve olay odaklı olabilir. Bir olay oluştuğunda, bileşenler açılır, görevlerini gerçekleştirir ve görev tamamlandıktan sonra kaldırılır.

• Bu düzen, sınırlanmış bağlamlar arasındaki iletişimler için iyi bir seçim olabilir. Tek bir sınırlanmış bağlam içindeki iletişimler için bir düzenleyici düzeni göz önünde bulundurulabilir.

• Merkezi düzenleyici tarafından ortaya çıkan performans sorunu var.

Bu düzen aşağıdaki durumlarda kullanışlı 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şimin kaçınılmaz olduğu durumlar vardır.

• İş mantığını kullanarak aşağı akış bileşenleri tarafından işlenen tüm işlemleri birleştirmeniz gerekir.

İş yükü tasarımı

Bir mimar, Azure İyi Tasarlanmış Çerçeve yapılarında ele alınan hedefleri ve ilkeleri ele almak için koreografi 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

Bu örnek, mikro hizmetlerle birlikte çalışan bir olay odaklı, bulutta yerel iş yükü çalıştıran bir iş yükü oluşturarak koreografi desenini gösterir. İstemci bir paketin gönderilmesini istediğinde iş yükü bir insansız hava aracı atar. Paket, planlanan insansız hava aracı tarafından teslim almaya hazır olduğunda teslimat işlemi başlar. Aktarım sırasında iş yükü teslim durumunu kazanana kadar teslimi işler.

Bu örnek, Orchestrator desenini Koreografi düzeniyle değiştiren İnsansız Hava Aracı Ile Teslimat uygulamasının yeniden düzenlenmesidir.

Alma hizmeti, istemci isteklerini işler ve teslim ayrıntıları da dahil olmak üzere iletilere dönüştürür. İş işlemleri, bu yeni iletiler tüketildikten sonra başlatılır.

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

1. Paket oluşturma veya güncelleştirme
2. Paketi teslim etmek için bir insansız hava aracı atama
3. Teslimat sırasında kontrol ve sonunda farkındalığı artırmadan oluşan teslimi ele alın.

İş işlemeyi üç mikro hizmet gerçekleştirir: Paket, İnsansız Hava Aracı Zamanlayıcı ve Teslimat hizmetleri. Merkezi bir düzenleyici yerine, hizmetler kendi aralarında iletişim kurmak için mesajlaşmayı kullanır. Her hizmet, iş akışını merkezi olmayan bir şekilde koordine eden bir protokolü önceden uygulamakla sorumlu olacaktır.

Tasarlama

İş işlemi birden çok atlama aracılığıyla bir sırayla işlenir. Her atlama, tüm iş hizmetleri arasında tek bir ileti veri yolu paylaşıyor.

İstemci bir HTTP uç noktası üzerinden bir teslim isteği gönderdiğinde, alma hizmeti bunu alır, bu isteği bir iletiye dönüştürür ve ardından iletiyi paylaşılan ileti veri yolu için yayımlar. Abone olunan iş hizmetleri, otobüse eklenen yeni iletileri tüketecek. İletiyi aldıktan sonra, iş hizmetleri işlemi başarılı, başarısız bir şekilde tamamlayabilir veya istek zaman aşımına uğradı. Başarılı olursa, hizmetler veri yoluna Tamam durum koduyla yanıt verir, yeni bir işlem iletisi oluşturur ve ileti veri yoluna gönderir. Bir hata veya zaman aşımı varsa, hizmet neden kodunu ileti veri yolu'na göndererek hata bildirir. Ayrıca, ileti bir teslim edilemeyen ileti kuyruğuna eklenir. Makul ve uygun bir süre içinde alınamayan veya işlenemeyen iletiler de DLQ'ya taşınır.

Tasarım, iş işleminin tamamını işlemek için birden çok ileti veri yolları kullanır. Microsoft Azure Service Bus ve Microsoft Azure Event Grid , bu tasarım için mesajlaşma hizmeti platformu sağlamak üzere oluşturulur. İş yükü, alım için Azure İşlevleri barındıran Azure Container Apps'e ve iş mantığını yürüten olay temelli işlemeyi işleyen uygulamalara dağıtılır.

Tasarım, koreografinin bir sırayla gerçekleşmesini sağlar. Tek bir Azure Service Bus ad alanı, iki aboneliği ve oturum kullanan kuyruğu olan bir konu içerir. Alma hizmeti konu başlığına ileti yayımlar. Paket hizmeti ve İnsansız Hava Aracı Zamanlayıcı hizmeti konuya abone olur ve başarıyı kuyruğa ileden iletileri yayımlar. Teslim tanımlayıcısı ile ilişkilendirilmiş bir GUID'nin ortak bir oturum tanımlayıcısı dahil edilmesi, ilişkili iletilerin ilişkisiz dizilerinin sıralı olarak işlenmesini sağlar. Teslim hizmeti, işlem başına iki ilgili ileti bekler. İlk ileti paketin gönderilmeye hazır olduğunu, ikinci mesaj ise bir insansız hava aracının zamanlandığını belirtir.

Bu tasarım, tüm teslim işlemi sırasında kaybolamaz veya çoğaltılmayan yüksek değerli iletileri işlemek için Azure Service Bus kullanır. Paket gönderildiğinde, Azure Event Grid'de durum değişikliği de yayımlanır. Bu tasarımda, olay gönderenin durum değişikliğinin nasıl işlendiğinden hiçbir beklentisi yoktur. Bu tasarımın parçası olmayan aşağı akış kuruluş hizmetleri bu olay türünü dinliyor ve belirli bir iş amacı mantığını yürütmeye tepki gösteriyor olabilir (yani, gönderilen sipariş durumunu kullanıcıya e-postayla gönderebilirsiniz).

Bunu AKS pub-sub desen uygulaması gibi başka bir işlem hizmetine dağıtmayı planlıyorsanız, aynı podda iki kapsayıcı ile ortak uygulama uygulanabilir. Kapsayıcılardan biri tercih edilen ileti veri yolunuzla etkileşim kuran büyükelçiyi çalıştırırken diğeri iş mantığını yürütür. Aynı poddaki iki kapsayıcıya yönelik yaklaşım, performansı ve ölçeklenebilirliği artırır. Büyükelçi ve iş hizmeti aynı ağı paylaşarak düşük gecikme süresi ve yüksek aktarım hızı sağlar.

Birden çok çabaya yol açabilecek art arda yeniden deneme işlemlerini önlemek için, iş hizmetlerinin kabul edilemez iletilere hemen bayrak eklemesi gerekir. İyi bilinen neden kodları veya tanımlı bir uygulama kodu kullanarak bu tür iletileri zenginleştirmek mümkündür, böylece bir teslim edilemeyen ileti kuyruğuna (DLQ) taşınabilir. Aşağı akış hizmetlerinden Saga'nın uygulanmasıyla ilgili tutarlılık sorunlarını yönetmeyi göz önünde bulundurun. Örneğin, başka bir hizmet düzeltme amacıyla yalnızca bir ücretlendirme, rety veya özet işlem yürüterek ölü harfli iletileri işleyebilir.

yeniden deneme işlemlerinin yinelenen kaynaklara neden olmadığından emin olmak için iş hizmetleri bir kez etkili olur. Örneğin, Paket hizmeti veri deposuna veri eklemek için upsert işlemlerini kullanır.

İlgili kaynaklar

Koreografi tasarımınızda bu desenleri göz önünde bulundurun.

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

• İş yükünün ani artışlarını işlemek için kuyruk tabanlı yük dengeleme düzeni uygulayın.

• Yayımcı-abone deseni aracılığıyla zaman uyumsuz dağıtılmış mesajlaşma kullanın.

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

• İleti altyapısında ileti aracısı kullanma hakkında bilgi için bkz . Azure'da zaman uyumsuz mesajlaşma seçenekleri.

• Azure mesajlaşma hizmetleri arasında seçim yapma