Koreografi düzeni

Sistemin her bileşeninin merkezi bir denetim noktasına güvenmek yerine bir iş işleminin iş akışıyla ilgili karar alma sürecine katılmasını sağlayın.

Bağlam ve sorun

Mikro hizmetler mimarisinde genellikle bulut tabanlı bir uygulamanın, bir iş işlemini uçtan uca işlemek için birlikte çalışan birkaç küçük hizmete bölünmesi söz konusudur. Hizmetler arasındaki eşleştirmeyi azaltmak için her hizmet tek bir iş işleminden sorumludur. Bazı avantajlar arasında daha hızlı geliştirme, daha küçük kod tabanı ve ölçeklenebilirlik bulunur. Ancak verimli ve ölçeklenebilir bir iş akışı tasarlamak zor bir iş akışıdır ve genellikle karmaşık hizmetler arası iletişim gerektirir.

Hizmetler iyi tanımlanmış API'leri kullanarak birbirleriyle iletişim kurar. Tek bir iş işlemi bile tüm hizmetler arasında birden çok noktadan noktaya çağrıya neden olabilir. İletişim için yaygın bir desen, düzenleyici işlevi gören merkezi bir hizmet kullanmaktır. Tüm gelen istekleri kabul eder ve işlemleri ilgili hizmetlere devreder. Bunu yaparken, tüm iş işleminin iş akışını da yönetir. Her hizmet yalnızca bir işlemi tamamlar ve genel iş akışının farkında değildir.

Düzenleyici düzeni, hizmetler arasındaki noktadan noktaya iletişimi azaltır, ancak düzenleyici ile iş işleminin işlenmesine katılan diğer hizmetler arasındaki sıkı bağlantı nedeniyle bazı dezavantajları vardır. Görevleri bir sırayla yürütmek için düzenleyicinin bu hizmetlerin sorumlulukları hakkında bazı etki alanı bilgilerine sahip olması gerekir. Hizmet eklemek veya kaldırmak istiyorsanız, mevcut mantık bozulacak ve iletişim yolunun bölümlerini yeniden kurmanız gerekir. İş akışını yapılandırabilir, iyi tasarlanmış bir düzenleyiciyle hizmetleri kolayca ekleyebilir veya kaldırabilirsiniz, ancak bu tür bir uygulamanın bakımı karmaşık ve zordur.

Çözüm

Merkezi bir düzenleyiciye bağlı olmak yerine bir iş işleminin ne zaman ve nasıl işleneceğini her hizmetin belirlemesine izin verin.

Koreografiyi uygulamanın bir yolu, iş operasyonlarını koordine etmek için zaman uyumsuz mesajlaşma düzenini kullanmaktır.

İstemci isteği iletileri ileti kuyruğuna yayımlar. İletiler geldikçe, bu iletiyle ilgilenen abonelere veya hizmetlere iletilir. Abone olunan her hizmet, ileti tarafından belirtilen şekilde işlemlerini yapar ve ileti kuyruğuna işlemin başarılı veya başarısız olmasıyla yanıt verir. Başarılı olması durumunda 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. Bir işlem başarısız olursa, ileti veri yolu bu işlemi yeniden deneyebilir.

Bu şekilde hizmetler, bir düzenleyiciye bağlı olmadan veya aralarında doğrudan iletişim kurmadan iş akışını kendi aralarında koreografik hale getirir.

Noktadan noktaya iletişim olmadığından, bu düzen hizmetler arasındaki bağlantıyı azaltmaya yardımcı olur. Ayrıca, tüm işlemlerle ilgilenmesi gerektiğinde düzenleyicinin neden olduğu performans sorunlarını kaldırabilir.

Bu düzenin kullanılacağı durumlar

Hizmetleri sık sık güncelleştirmeyi veya değiştirmeyi ve sonunda bazı hizmetleri eklemeyi veya kaldırmayı düşünüyorsanız koreografi desenini kullanın. Uygulamanın tamamı daha az çaba ve mevcut hizmetlerde en az kesintiyle değiştirilebilir.

Merkezi düzenleyicide performans sorunlarıyla karşılaşıyorsanız bu düzeni göz önünde bulundurun.

Bu desen, tüm hizmetlerin kısa süreli veya olay temelli olabileceği sunucusuz mimari için doğal bir modeldir. Hizmetler bir olay nedeniyle başlatılabilir, görevlerini yapabilir ve görev tamamlandığında kaldırılır.

Sorunlar ve dikkat edilmesi gerekenler

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

Bir hizmet bir iş işlemini tamamlayamazsa, bu hatadan kurtarmak zor olabilir. Bunun bir yolu, hizmetin bir olay başlatarak başarısız olduğunu belirtmesini sağlamaktır. Bu başarısız olaylara abone olan başka bir hizmet, bir istekteki başarılı işlemleri geri almak için telafi işlemleri uygulama gibi gerekli eylemleri gerçekleştirir. Başarısız olan hizmet, hata için bir olayı da tetikleyemeyebilir. Bu durumda, bu işlemi bir hata olarak tanımak için yeniden deneme ve veya zaman aşımı mekanizması kullanmayı göz önünde bulundurun. Örnek için Örnek bölümüne bakın.

Bağımsız iş işlemlerini paralel olarak işlemek istediğinizde iş akışı uygulamak kolaydır. Tek bir ileti veri yolu kullanabilirsiniz. Ancak, koreografinin bir sırada gerçekleşmesi gerektiğinde iş akışı karmaşık hale gelebilir. Örneğin, Hizmet C ancak Hizmet A ve Hizmet B işlemlerini başarıyla tamamladıktan sonra işlemini başlatabilir. Yaklaşımlardan biri, iletileri gerekli sırada alan birden çok ileti veriyye veya kuyruğa sahip olmaktır. Daha fazla bilgi için Örnek bölümüne bakın.

Hizmet sayısı hızla artarsa koreografi düzeni 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, iş akışının dayanıklılığını merkezi olarak yönetir ve tek bir hata noktası haline gelebilir. Öte yandan, koreografi için rol tüm hizmetler arasında dağıtılır ve dayanıklılık daha az sağlam hale gelir.

Her hizmet yalnızca işleminin dayanıklılığından değil, aynı zamanda iş akışından da sorumludur. Bu sorumluluk hizmet için zahmetli olabilir ve uygulanması zor olabilir. Her hizmetin geçici, geçici olmayan ve zaman aşımı hatalarını yeniden denemesi gerekir, böylece istek gerekirse düzgün bir şekilde sonlandırılır. Ayrıca, hizmetin diğer hizmetlerin uygun şekilde hareket edebilmesi için işlemin başarısını veya başarısızlığını iletme konusunda dikkatli olması 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 üç farklı iş işlemi gerekir: paket oluşturma veya güncelleştirme, paketi teslim etmek için bir insansız hava aracı atama ve sevk edildiğinde kontrol ve sonunda farkındalığı artırmadan oluşan teslimatın uygun şekilde işlenmesi. İş 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 daha sonra işlenmek üzere geçersiz olarak yazılacaktır. 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 uygulama yapılabilir. 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