Düzenle

Aracılığıyla paylaş


Kanallar ve Filtreler düzeni

Azure Blob Storage
Azure Functions
Azure Queue Storage

Karmaşık bir işlem gerçekleştiren bir görevi yeniden kullanılabilecek bir dizi ayrı öğe şeklinde parçalara ayırın. Bunun yapılması, işlemeyi gerçekleştiren görev öğelerinin bağımsız olarak dağıtılıp ölçeklendirilmesine izin vererek ilk adımların performansını, ölçeklenebilirliğini ve yeniden kullanılabilirliğini artırabilir. Borular ve Filtreler deseni yüksek düzeyde modülerliği destekler.

Bağlam ve sorun

İşlemeniz gereken sıralı görevlerden oluşan bir işlem hattınız var. Bu uygulamayı uygulamak için basit ama esnek olmayan bir yaklaşım, bu işlemi monolitik bir modülde gerçekleştirmektir. Ancak, bu yaklaşım kodu yeniden düzenleme, iyileştirme veya aynı işlemenin parçaları uygulamanın başka bir yerinde gerekliyse yeniden kullanma fırsatlarını azaltma olasılığı yüksektir.

Aşağıdaki diyagramda, monolitik bir yaklaşım kullanarak verileri işlemeyle ilgili sorunlardan biri olan kodun birden çok işlem hattında yeniden kullanılamayabilmesi gösterilmektedir. Bu örnekte, bir uygulama iki kaynaktan veri alır ve işler. Ayrı bir modül, sonucu uygulamanın iş mantığına geçirmeden önce verileri dönüştürmek için bir dizi görev gerçekleştirerek her kaynaktan verileri işler.

Monolitik modüllerle uygulanan bir çözümü gösteren diyagram.

Monolitik modüllerin gerçekleştirdiği bazı görevler işlevsel olarak benzerdir, ancak kodun her iki modülde de tekrarlanması gerekir ve büyük olasılıkla modülü içinde sıkı bir şekilde birleştirilir. Mantığı yeniden kullanamamanın yanı sıra, bu yaklaşım gereksinimler değiştiğinde bir risk oluşturur. Her iki yerde de kodu güncelleştirmeyi unutmayın.

Birden çok işlem hattıyla veya yeniden kullanımla ilişkili olmayan monolitik bir uygulamayla ilgili başka zorluklar da vardır. Monolit ile farklı ortamlarda belirli görevleri çalıştırma veya bunları bağımsız olarak ölçeklendirme olanağınız yoktur. Bazı görevler yoğun işlem gücü kullanımlı olabilir ve güçlü donanımlarda veya birden çok örneği paralel olarak çalıştırmanın avantajına sahip olabilir. Diğer görevler aynı gereksinimlere sahip olmayabilir. Ayrıca monolitler sayesinde görevleri yeniden sıralamak veya işlem hattına yeni görevler eklemek zordur. Bu değişiklikler, işlem hattının tamamının yeniden testini gerektirir.

Çözüm

Her akış için gereken işleme faaliyetini her biri tek bir görevi gerçekleştiren bir dizi ayrı bileşene (yani filtreler) ayırın. Bileşik görevler, bir filtre yerine birden çok filtre kullanmalıdır. Filtreler, filtreler borulara bağlanarak işlem hatlarına oluşturulur. Filtreler bağımsız, bağımsız ve genellikle durum bilgisi olmayan filtrelerdir. Filtreler gelen kanaldan ileti alır ve iletileri farklı bir giden kanala yayımlar. Filtreler, koşullu mantık eklemek için iletiyi dönüştürebilir veya bir veya daha fazla ölçütle test edebilir. Kanallar yönlendirme veya başka bir mantık gerçekleştirmez. Yalnızca filtreleri bağlayarak çıkış iletisini bir filtreden diğerine giriş olarak geçirirler.

Filtreler bağımsız olarak çalışır ve diğer filtrelerin farkında değil. Yalnızca giriş ve çıkış şemalarının farkındadırlar. Bu nedenle, herhangi bir filtrenin giriş şeması önceki filtrenin çıkış şemasıyla eşleşecek şekilde filtreler herhangi bir sırada düzenlenebilir. Tüm filtreler için standartlaştırılmış bir şema kullanmak, filtreleri yeniden sıralama özelliğini geliştirir. Kanallar ve filtreler mimarisi, bileşimsel yeniden kullanımı teşvik eder.

Filtrelerin gevşek bağlaması aşağıdakileri kolaylaştırır:

  • Mevcut filtrelerden oluşan yeni işlem hatları oluşturma
  • Tek tek filtrelerde mantığı güncelleştirme veya değiştirme
  • Gerektiğinde filtreleri yeniden sırala
  • Gerektiğinde farklı donanımlarda filtre çalıştırma
  • Filtreleri paralel olarak çalıştırma

Bu diyagramda kanallar ve filtrelerle uygulanan bir çözüm gösterilir:

Kanallar ve filtrelerle uygulanan bir çözümü gösteren diyagram.

Tek bir isteği işlemek için gereken süre, işlem hattındaki en yavaş filtrelerin hızına bağlıdır. Özellikle belirli bir veri kaynağından bir akışta çok sayıda istek görünüyorsa, bir veya daha fazla filtre performans sorunlarına neden olabilir. Yavaş filtrelerin paralel örneklerini çalıştırma özelliği, sistemin yükü yayabilmesini ve aktarım hızını geliştirmesini sağlar.

Farklı işlem örneklerinde filtre çalıştırma özelliği, bunların bağımsız olarak ölçeklendirilmesini ve birçok bulut ortamı tarafından sunulan esneklik avantajından yararlanmasını sağlar. Hesaplama açısından yoğun olan bir filtre yüksek performanslı donanımlarda çalıştırılabilirken, diğer daha az zorlu filtreler daha düşük maliyetli ticari donanımlarda barındırılabilir. Filtrelerin aynı veri merkezinde veya coğrafi konumda olması bile gerekmez ve işlem hattındaki her öğenin gerekli kaynaklara yakın bir ortamda çalıştırılmasını sağlar. Bu çabalar, her borunun veya filtrenin esnekliğini en üst düzeye çıkarmak için mesajlaşma, çoklu iş parçacığı oluşturma gibi belirli tasarım tekniklerini gerektirir. Bu diyagramda, Kaynak 1'den gelen veriler için işlem hattına uygulanan bir örnek gösterilmektedir:

Kaynak 1'den gelen veriler için işlem hattına uygulanan bir örneği gösteren diyagram.

Bir filtrenin girişi ve çıkışı akış olarak yapılandırılmışsa, her filtre için işlemeyi paralel olarak gerçekleştirebilirsiniz. İşlem hattındaki ilk filtre, çalışmasını başlatabilir ve ilk filtre çalışmasını tamamlamadan önce sıradaki bir sonraki filtreye doğrudan geçirilen sonuçlarını verebilir.

Kanallar ve Filtreler desenini Telafi İşlemi düzeniyle birlikte kullanmak, dağıtılmış işlemleri uygulamak için alternatif bir yaklaşımdır. Dağıtılmış bir işlemi ayrı, telafi edilebilir görevlere bölebilirsiniz. Bunların her biri, Telafi İşlemi desenini de uygulayan bir filtre aracılığıyla uygulanabilir. Bir işlem hattındaki filtreleri, barındırdıkları verilere yakın çalışan ayrı barındırılan görevler olarak uygulayabilirsiniz.

Sorunlar ve dikkat edilmesi gerekenler

Bu deseni nasıl uygulayabileceğinize karar vermek için aşağıdaki noktaları göz önünde bulundurun:

  • Monolitik doğa. Bu desen genellikle monolitik işlem hattı olarak uygulanır, bu nedenle herhangi bir değişiklik için filtre zincirinin tamamı uçtan uca test edilmelidir. Ayrıca, tüm süreç için hataya dayanıklılık göz önünde bulundurulmalıdır; bir filtre veya kanal başarısız olursa, işlem hattının tamamı büyük olasılıkla başarısız olur.

  • Karmaşıklık. Bu düzen esnekliği artırırken, özellikle işlem hattındaki filtreler farklı sunuculara dağıtılmışsa karmaşıklığın ortaya çıkmasına da neden olabilir.

  • Güvenilirlik. Kanaldaki filtreler arasında akan verilerin kaybolmamasını sağlayan bir altyapı kullanın.

  • Tek Sefer Etkili Olma. bir ileti aldıktan sonra işlem hattındaki bir filtre başarısız olursa ve çalışma filtrenin başka bir örneğine yeniden zamanlanırsa, işin bir bölümü zaten tamamlanmış olabilir. Çalışma genel durumun bazı yönlerini güncelleştirirse (veritabanında depolanan bilgiler gibi), tek bir güncelleştirme yinelenebilir. Benzer bir sorun, bir filtrenin sonuçlarını sonraki filtreye gönderdikten sonra ancak çalışmasını başarıyla tamamladığını belirtmeden önce başarısız olması durumunda da oluşabilir. Bu gibi durumlarda, filtrenin başka bir örneği bu çalışmayı tekrarlayabilir ve aynı sonuçların iki kez gönderilmesine neden olabilir. Bu senaryo, işlem hattında aynı verilerin iki kez işlenmesine neden olan sonraki filtrelere neden olabilir. Bu nedenle, bir işlem hattındaki filtreler bir kez etkili olacak şekilde tasarlanmalıdır. Daha fazla bilgi için Jonathan Oliver'ın blogundaki Idempotency Patterns bölümüne bakın.

  • Yinelenen iletiler. İşlem hattındaki bir filtre işlem hattının sonraki aşamasına ileti gönderdikten sonra başarısız olursa, filtrenin başka bir örneği çalıştırılabilir ve aynı iletinin bir kopyasını işlem hattına gönderebilir. Bu senaryo, aynı iletinin iki örneğinin sonraki filtreye geçirilmesine neden olabilir. Bu sorunu önlemek için işlem hattının yinelenen iletileri algılaması ve ortadan kaldırması gerekir.

    Not

    İşlem hattını ileti kuyruklarını (Azure Service Bus kuyrukları gibi) kullanarak uygularsanız, ileti kuyruğa alma altyapısı otomatik yinelenen ileti algılama ve kaldırma sağlayabilir.

  • Bağlam ve durum. İşlem hattındaki her filtre temel olarak yalıtılmış bir şekilde çalışır ve nasıl çağrıldığı hakkında varsayımlarda bulunmamalıdır. Bu nedenle, her filtrenin çalışmasını gerçekleştirmek için yeterli bağlam sağlanmalıdır. Bu bağlam önemli miktarda durum bilgisi içerebilir. Filtreler bir veritabanındaki veya dış depolamadaki veriler gibi dış durumu kullanıyorsa, performans üzerindeki etkiyi göz önünde bulundurmanız gerekir. Her filtrenin bu durumu yüklemesi, çalıştırması ve kalıcı hale getirmek zorunda olması gerekir ve bu da dış durumu tek seferde yükleyen çözümlere ek yük getirir.

  • İleti toleransı. Filtreler, çalışmadıkları gelen iletideki verilere dayanıklı olmalıdır. Kendilerine ilişkin veriler üzerinde çalışır ve diğer verileri yoksayar ve çıkış iletisinde değişmeden geçirir.

  • Hata işleme - Hata durumunda ne yapılması gerektiğini her filtre belirlemelidir. Filtrenin işlem hattının başarısız olup olmadığını veya özel durumu yayıp yaymadığını belirlemesi gerekir.

Bu düzenin kullanılacağı durumlar

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

  • Uygulama için gereken işlem kolayca bir dizi bağımsız adım şeklinde ayrılabiliyor.

  • Uygulama tarafından gerçekleştirilen işleme adımlarının farklı ölçeklenebilirlik gereksinimleri var.

    Not

    Aynı işlemde birlikte ölçeklendirilmesi gereken filtreleri gruplandırabilirsiniz. Daha fazla bilgi için bkz. İşlem Kaynağı Birleştirme düzeni.

  • Uygulamanın gerçekleştirdiği işleme adımlarının yeniden sıralanması veya adım ekleme ve kaldırma özelliğine izin verme esnekliğine ihtiyacınız vardır.

  • Adımların işlenmesinin farklı sunuculara dağıtılması sisteme yarar sağlayacak.

  • Veriler işlenirken bir adımda hatanın etkilerini en aza indiren güvenilir bir çözüme ihtiyacınız vardır.

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

  • Uygulama bir istek-yanıt deseni izler.

  • Görev işleme, istek/yanıt senaryosu gibi bir ilk isteğin parçası olarak tamamlanmalıdır.

  • Bir uygulama tarafından gerçekleştirilen işleme adımları bağımsız değildir veya tek bir işlemin parçası olarak birlikte gerçekleştirilmesi gerekir.

  • Bir adımın gerektirdiği bağlam veya durum bilgisi miktarı bu yaklaşımı verimsiz hale getirir. Durum bilgilerini veritabanında kalıcı hale getirmek mümkün olabilir, ancak veritabanındaki ek yük aşırı çekişmeye neden olursa bu stratejiyi kullanmayın.

İş yükü tasarımı

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

Yapı Taşı Bu desen sütun hedeflerini nasıl destekler?
Güvenilirlik tasarımı kararları, iş yükünüzün arızaya karşı dayanıklı olmasına ve bir hata oluştuktan sonra tamamen çalışır duruma gelmesini sağlamaya yardımcı olur. Her aşamanın tek sorumluluğu odaklanmış dikkati sağlar ve toplanan veri işlemenin dikkatinin dağılmasını önler.

- RE:01 Basitlik
- RE:07 Arka plan işleri

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

İşlem hattının uygulanmasında gereken altyapıyı sağlamak için bir dizi ileti kuyruğu kullanabilirsiniz. İlk ileti kuyruğu, kanallar ve filtreler desen uygulamasının başlangıcı haline gelen işlenmemiş iletiler alır. Filtre görevi olarak uygulanan bir bileşen bu kuyruktaki bir iletiyi dinler, çalışmasını gerçekleştirir ve ardından sıradaki bir sonraki kuyruğa yeni veya dönüştürülmüş bir ileti gönderir. Başka bir filtre görevi bu kuyrukta iletileri dinleyebilir, işleyebilir, sonuçları başka bir kuyruğa gönderebilir ve bu şekilde devam edebilir. Bu işlem, kanallar ve filtreler işlemini sona erdiren son adıma kadar gerçekleştirilir. Bu diyagramda ileti kuyruklarını kullanan bir işlem hattı gösterilmektedir:

İleti kuyruklarını kullanan bir işlem hattını gösteren diyagram.

Bu desen kullanılarak bir görüntü işleme işlem hattı uygulanabilir. İş yükünüz bir görüntü alırsa, görüntü aşağıdaki gibi eylemleri gerçekleştirmek için büyük ölçüde bağımsız ve yeniden sıralanabilir bir dizi filtreden geçebilir:

  • con çadır modu ration
  • yeniden boyutlandırma
  • Filigran
  • yeniden yönlendirme
  • Exif meta verilerini kaldırma
  • İçerik teslim ağı (CDN) yayını

Bu örnekte filtreler, tek tek dağıtılan Azure İşlevleri veya her filtreyi yalıtılmış dağıtım olarak içeren tek bir Azure İşlevi uygulaması olarak uygulanabilir. Azure İşlevi tetikleyicilerinin, giriş bağlamalarının ve çıkış bağlamalarının kullanılması, filtre kodunu basitleştirebilir ve işlenmek üzere görüntüye yönelik bir talep denetimi kullanarak kuyruk tabanlı bir kanalla otomatik olarak çalışabilir.

Bir dizi Azure İşlevleri arasında Azure Kuyruk Depolama kullanan bir görüntü işleme işlem hattını gösteren diyagram.

Aşağıda, Azure İşlevi olarak uygulanan ve görüntüde denetle talebi olan bir Kuyruk Depolama kanalından tetiklenen ve başka bir Kuyruk Depolama kanalına yeni bir talep denetimi yazan bir filtrenin nasıl görünebileceğine ilişkin bir örnek verilmiştır. Kısa bir süre için uygulama yerine açıklamalarda sahte kod kullandık. Bunun gibi daha fazla kod GitHub'da bulunan Kanallar ve Filtreler deseninin tanıtımında bulunabilir.

// This is the "Resize" filter. It handles claim checks from input pipe, performs the
// resize work, and places a claim check in the next pipe for anther filter to handle.
[Function(nameof(ResizeFilter))]
[QueueOutput("pipe-fjur", Connection = "pipe")]  // Destination pipe claim check
public async Task<string> RunAsync(
  [QueueTrigger("pipe-xfty", Connection = "pipe")] string imageFilePath,  // Source pipe claim check
  [BlobInput("{QueueTrigger}", Connection = "pipe")] BlockBlobClient imageBlob)  // Image to process
{
  _logger.LogInformation("Processing image {uri} for resizing.", imageBlob.Uri);

  // Idempotency checks
  // ...

  // Download image based on claim check in queue message body
  // ...
  
  // Resize the image
  // ...

  // Write resized image back to storage
  // ...

  // Create claim check for image and place in the next pipe
  // ...
  
  _logger.LogInformation("Image resizing done or not needed. Adding image {filePath} into the next pipe.", imageFilePath);
  return imageFilePath;
}

Not

Spring Integration Framework, kanallar ve filtreler deseninin bir uygulamasına sahiptir.

Sonraki adımlar

Bu düzeni uygularken aşağıdaki kaynakları yararlı bulabilirsiniz:

Bu deseni uyguladığınızda aşağıdaki desenler de ilgili olabilir:

  • Talep-Denetim düzeni. Kuyruk kullanılarak uygulanan bir işlem hattı, filtreler aracılığıyla gönderilen gerçek öğeyi tutmayabilir, bunun yerine işlenmesi gereken verilerin işaretçisini tutabilir. Örnek, Azure Blob Depolama depolanan görüntüler için Azure Kuyruk Depolama'da bir talep denetimi kullanır.
  • Rakip Tüketiciler düzeni. Bir işlem hattı, bir veya daha fazla filtrenin birden fazla örneğini içerebilir. Bu yaklaşım, yavaş filtrelerin paralel örneklerini çalıştırmak için kullanışlıdır. Sistemin yükü yaymasına ve aktarım hızını geliştirmesine olanak tanır. Bir filtrenin her örneği diğer örneklerle giriş için rekabet eder, ancak bir filtrenin iki örneğinin aynı verileri işleyememeleri gerekir. Bu makalede yaklaşım açıklanmaktadır.
  • İşlem Kaynağı Birleştirme düzeni. Birlikte ölçeklendirilmesi gereken filtreleri tek bir işlem halinde gruplandırmak mümkün olabilir. Bu makale, bu stratejinin avantajları ve dezavantajları hakkında daha fazla bilgi sağlar.
  • Telafi İşlemi düzeni. Filtreyi tersine çevrilebilen veya bir hata olduğunda durumu önceki bir sürüme geri yükleyen telafi işlemine sahip bir işlem olarak uygulayabilirsiniz. Bu makalede, nihai tutarlılığı korumak veya elde etmek için bu düzeni nasıl uygulayabileceğiniz açıklanmaktadır.
  • Kanallar ve Filtreler - Kurumsal Tümleştirme Desenleri.