Azure Depolama için Gridwich işlemleri

Azure Storage

Gridwich Azure Depolama Hizmeti, Gridwich.SagaParticipants.Storage.AzureStorage, Gridwich için yapılandırılan Azure Depolama Hesapları için blob ve kapsayıcı işlemleri sağlar. Örnek depolama işlemleri blob oluşturma, Kapsayıcı silme, Blobu kopyalama veya Depolama katmanını değiştirme işlemleridir.

Gridwich, depolama mekanizmalarının hem Azure Depolama blok blobları hem de kapsayıcılar için çalışmasını gerektirir. Bloblar ve kapsayıcılar için ayrı sınıflar ve Depolama Hizmeti işlemleriyle, belirli bir depolama işleminin blobla mı yoksa kapsayıcıyla mı ilgili olduğu konusunda bir belirsizlik yoktur. Bu makale, not edilen durumlar dışında hem bloblar hem de kapsayıcılar için geçerlidir.

Gridwich, depolama işlemlerinin çoğunu saga katılımcısı içindeki dış sistemlere Storage.AzureStorage sunar. Diğer saga katılımcıları, kodlama iş akışlarını ayarlarken farklı kapsayıcılar veya hesaplar arasında blob kopyalama gibi görevler için depolama hizmetini kullanır.

Bu makalede Gridwich Azure Depolama Hizmeti'nin çözüm gereksinimlerini nasıl karşıladığını ve olay işleyicileri gibi mekanizmalarla nasıl tümleştirdiği açıklanmaktadır. Bağlantılar, kapsayıcılar, sınıflar ve mekanizmalar hakkında daha kapsamlı açıklama içeren ilgili kaynak koduna işaret eder.

Azure Depolama SDK'sı

Gridwich, REST isteklerini el ile kullanmak yerine Azure Depolama ile etkileşimde bulunmak için Azure Depolama SDK'sından sınıflar kullanır. Depolama sağlayıcısında SDK BlobBaseClient ve BlobContainerClient sınıfları depolama isteklerini yönetir.

Bu SDK istemci sınıfları şu anda, işlem bağlamı ve ETag nesne sürümü için Gridwich'in işlemesi x-ms-client-request-id gereken iki HTTP üst bilgisine yalnızca dolaylı erişime izin verir.

Gridwich'te, sağlayıcı sınıfları çifti BlobBaseClientProvider ve BlobContainerClientProvider işlevlerini sleeves olarak adlandırılan birimler halinde dağıtır. Kılıflar hakkında ayrıntılı bilgi için bkz . Depolama kılıfları.

Aşağıdaki diyagramda SDK ve Gridwich sınıflarının yapısı ve örneklerin birbirleriyle ilişkisi gösterilmektedir. Oklar "bir başvuruya sahip" ifadesini gösterir.

Depolama SDK'sı sınıfları arasındaki istemci nesne örneği ilişkilerini gösteren diyagram.

İşlem hattı ilkesi

İstemci örneğini oluştururken HTTP üst bilgilerini işlem hattı ilkesi örneği olarak işlemek için kancayı ayarlarsınız. Bu ilkeyi yalnızca istemci örneği oluşturma zamanında ayarlayabilirsiniz ve ilkeyi değiştiremezsiniz. İstemciyi kullanan depolama sağlayıcısı kodunun yürütme sırasında üst bilgi değerlerini işleyebilmesi gerekir. Zorluk, depolama sağlayıcısının ve işlem hattının temiz bir şekilde etkileşim kurmasını sağlamaktır.

Gridwich işlem hattı ilkesi için bkz . BlobClientPipelinePolicy sınıfı.

Depolama Hizmeti önbelleğe alma

BIR SDK istemci nesnesi örneği Azure Depolama'ya ilk isteğini gönderdiğinde TCP bağlantısı oluşturma ve kimlik doğrulaması ek yük oluşturur. Dış sistem isteğinde aynı bloba yapılan birden çok çağrı, örneğin Meta Verileri Al, ardından Blobu Sil gibi ek yükü bir hale getirir.

Ek yükü azaltmak için Gridwich, işlem bağlamının kullandığı SDK sınıflarına bağlı olarak her depolama blobu veya kapsayıcısı için bir istemci örneğinin önbelleğini tutar. Gridwich bu istemci örneğini korur ve dış sistem isteği süresi boyunca aynı bloba veya kapsayıcıya karşı birden çok Azure Depolama işlemi için örneği kullanabilir.

Azure SDK tarafından sağlanan istemci sınıfları, SDK istemci nesnesi örneklerinin oluşturma zamanında tek bir bloba veya kapsayıcıya özgü olmasını gerektirir. Örneklerin aynı anda farklı iş parçacıklarında kullanılması da garanti değildir. İşlem bağlamı tek bir isteği temsil ettiğinden Gridwich, önbelleğe almayı blob veya kapsayıcı adı ile işlem bağlamı birleşimine dayandırır.

Azure Depolama SDK'sı istemci yapısıyla birlikte bu örneğin yeniden kullanılması, verimliliği ve kod netliğini dengelemek için ek destek kodu gerektirir.

Bağlam bağımsız değişkeni

Neredeyse tüm Gridwich Depolama Hizmeti işlemleri StorageClientProviderContext türünde özel bir bağlam bağımsız değişkeni gerektirir. Bu bağlam bağımsız değişkeni aşağıdaki gereksinimleri karşılar:

  • Dış sisteme, Gridwich isteğinde belirtilen istek başına benzersiz JSON tabanlı işlem bağlamı değerini içeren yanıtlar sağlar. Daha fazla bilgi için bkz . İşlem bağlamı.

  • Gridwich olay işleyicileri gibi Depolama Hizmeti çağıranların dış sistemde hangi yanıtların görünür olduğunu denetlemesine izin verir. Bu denetim, hizmetin dış sistemi ilgisiz bildirim olaylarıyla dolup taşmasını önler. Daha fazla bilgi için bkz . Bağlam sessize alma.

  • Paralel okuyucuların ve yazıcıların bir karışımına olanak tanıyan bir ortamda tutarlı istekler ve yanıtlar sağlamak için Azure Depolama kurallarıyla uyumludur. Örneğin, ETag izlemeyi destekler. Daha fazla bilgi için bkz . ETag'ler.

Depolama bağlamı

Hem blob hem de kapsayıcı depolama türlerinin bağlamı StorageClientProviderContext'tir ve şöyle görünür:

    string  ClientRequestID { get; }
    JObject ClientRequestIdAsJObject { get; }
    bool    IsMuted { get; set; }
    string  ETag { get; set; }
    bool    TrackingETag { get; set; }

İlk iki özellik, StorageClientProviderContext örneğini başlatmak için kullanılan işlem bağlamının farklı gösterimleridir. sınıfı, bir kopya oluşturucu da dahil olmak üzere çeşitli oluşturuculara sahiptir. Ek yöntemler arasında ResetToyerinde durum yinelemesine izin vermek için ve sorunlu başlatmaların özel durumlar oluşturmamasını sağlamak için statik CreateSafe bir yöntem bulunur.

sınıfı ayrıca GUID'leri ve boş dizeleri temel alan bağlamlar oluşturmak için özel işleme içerir. Dış aracılardan kaynaklanan bildirimleri de işleyen Oluşturulan ve Silinen blob için Azure Depolama Bildirimi işleyicileri GUID formunu gerektirir.

Bağlam sessize alır

özelliği, IsMuted uygulamanın sonuçta elde edilen bildirimleri çağırana (örneğin dış sisteme) yayımlamasını bekleyip beklemediğini denetler. Sessize alınan bir işlemde hizmet, sonuçta elde edilen olayları yayımlamaz.

Kodlayıcının Azure Depolama'daki blobları bir kodlama görevine giriş olarak düzenlemek için yürüttüğü blob kopyaları buna örnek olarak verilmiştir. Dış sistem bu ayrıntılarla değil, yalnızca kodlama işinin durumuyla ve kodlanmış çıkışları nereden alabildiğiyle ilgilidir. Bu endişeleri yansıtmak için kodlayıcı:

  1. İstek işlemi bağlamını temel alan, örneğin ctxNotMuted, sessiz olmayan bir depolama bağlamı oluşturur.

  2. Bağlam sınıfı kopya oluşturucuyu kullanarak veya yeni bir örnek oluşturarak, örneğinctxMuted, sessize alınan bir depolama bağlamı oluşturur. her iki seçenek de aynı işlem bağlam değerine sahip olur.

  3. ctxMuted Kodlama kurulumunda yer alan depolama işlemlerini belirtir. Dış sistem bu işlemlerin gerçekleştiğine dair herhangi bir gösterge görmez.

  4. Bir çıkış dosyasını hedef kapsayıcıya ctxNotMuted kopyalama gibi kodlama tamamlanmasını yansıtan depolama işlemlerinin bağlamını belirtir. Gridwich işleyicileri, elde edilen Azure Depolama bildirim olaylarını dış sistemde yayımlar.

Çağıran, işlemlerin nihai görünürlüğünü denetler. Hem sessize alınan hem de kapatılmayan işlemler eşdeğer operationContext bir değere dayanır. Bağlam kapatmanın amacı, işlem sessize alınma durumundan bağımsız olarak bir istekle ilgili depolama işlemlerini görmek mümkün olduğundan olay izleme günlüklerinden sorun tanılama gerçekleştirmeyi kolaylaştırmaktır.

ResponseBaseDTO bir boole özelliğine sahiptir. Bu özellik, olay dağıtma işleminin yayımlamak isteyip istemediğinize ilişkin son kararı dikte etmek için kullandığı özelliktirDoNotPublish. Olay gönderimi de özelliği bağlamın özelliğine IsMuted göre ayarlarDoNotPublish.

Hizmet, sessize alma ayarını Azure Depolama'ya iletir ve ardından sunduğu depolama bildirim olaylarında öğesini Oluşturulan ve Silinen adlı iki Gridwich işleyicisine ayarlarclientRequestId. Bu iki işleyici çağıran tarafından istenen sesi kapatmayı yansıtacak şekilde ayarlanır DoNotPublish .

Hedef tutarlılığı için ETag'ler

Azure Depolama, hedef tutarlılığı olması gereken istek dizileri için HTTP ETag üst bilgisini kullanır. Bir blob'un Meta Verileri Alma ve Meta Verileri Güncelleştirme depolama işlemleri arasında değişmediğinden emin olmak örnektir.

Standart HTTP kullanımıyla uyumlu hale getirmek için, bu üst bilgi, yorumunun üst bilgi değeri değişirse temel alınan nesnenin de değiştirildiği opak bir değere sahiptir. İstek nesne için geçerli ETag değerini gönderirse ve geçerli Depolama Hizmeti ETag değeriyle eşleşmiyorsa istek hemen başarısız olur. İstek bir ETag değer içermiyorsa Azure Depolama bu denetimi atlar ve isteği engellemez.

Depolama Hizmeti'ndeki ETag'ler

Gridwich için, ETag Gridwich Depolama Hizmeti ile Azure Depolama arasındaki iç ayrıntılardır. başka hiçbir kodun ETagfarkında olması gerekmez. Depolama Hizmeti, bir BlobDelete Event isteği işlemek için Blob Meta Verilerini Al, Blobu Sil işlemleri gibi diziler için öğesini kullanırETag. komutunun ETag kullanılması, Blobu Sil işleminin Blobu Al işlemiyle tam olarak aynı sürümü hedeflediğinden emin olur .

Yukarıdaki örnekte kullanmak ETag için:

  1. Meta Veri Al isteğini boş ETagbir ile gönderin.
  2. Yanıttan ETag değeri kaydedin.
  3. Kaydedilen ETag değeri Blobu Sil isteğine ekleyin.

İki ETag değer farklıysa silme işlemi başarısız olur. Hata, 2. ve 3. adımlar arasında başka bir işlemin blobu değiştirdiğini gösterir. 1. adımdaki işlemi yineleyin.

ETag, oluşturucuların parametresi ve StorageClientProviderContext sınıfının dize özelliğidir. Yalnızca Gridwich'e özgü BlobClientPipelinePolicy değeri işler ETag .

ETag kullanımını denetleme

özelliği, TrackingETag değerin bir sonraki istekte ETag gönderilip gönderilmeymeyeceğini denetler. Değer true , hizmetin varsa bir ETag gönderdiği anlamına gelir.

Konu blobu veya kapsayıcısı ile eşleşmeyen bir değere sahip bir ETag Azure Depolama isteği işlemin başarısız olmasıyla sonuçlanmaktadır. Bu hata tasarım gereğidir, çünkü ETag "isteğin hedeflediği tam sürüm" ifadesinin standart HTTP yoludur. İstekler, değerinin TrackingETag eşleşmesi gerektiğini belirten ETags özelliğini içerebilir veya değerlerin TrackingETag önemli olmadığını belirtmek ETag için özelliğini içeremez.

İşlem hattı, bu REST yanıtında varsa her zaman bir Azure Depolama işleminden bir ETag değer alır. İşlem hattı, mümkünse bağlam özelliğini her zaman son işlemden itibaren güncelleştirir ETag . Bayrağı TrackingETag yalnızca aynı istemci örneğinden gelen sonraki isteğin özelliğin değerini gönderip göndermediğini ETag denetler. ETag Değer null veya boşsa, geçerli istek değeri ne olursa olsun HTTP ETag değeri belirlemezTrackingETag.

Depolama kılıfları

Gridwich, depolama mekanizmalarının hem Azure Depolama blok blobları hem de kapsayıcılar için çalışmasını gerektirir. Bloblar ve kapsayıcılar için ayrı sınıflar ve Depolama Hizmeti işlemleri vardır, bu nedenle belirli bir depolama işleminin blobla mı yoksa kapsayıcıyla mı ilgili olduğu konusunda bir belirsizlik yoktur.

Biri bloblar, diğeri kapsayıcılar için olmak üzere bir çift sağlayıcı sınıfı, iki işlev kümesini kollar olarak adlandırılan birimler halinde dağıtır. Sleeves, Azure SDK'nın parçası olan depolama yardımcı sınıflarının örneklerini içerir. Depolama Hizmeti'nin başlatılması sağlayıcıları oluşturur ve depolama hizmeti yöntemleri için doğrudan kullanılabilir hale getirir.

Manşon yapısı

Kılıf, SDK İstemcisi nesne örneği için bir kapsayıcı ve bir depolama bağlamıdır. Depolama sağlayıcısı işlevleri, iki özellik Client ve Contextaracılığıyla kovana başvurur. Bloblar için bir kovan türü, kapsayıcılar için ise sırasıyla veBlobContainerClient türünde BlobBaseClientözelliklere sahip Client başka bir tür vardır.

Bloblar için genel manşon yapısı şöyle görünür:

BlobBaseClient Client { get; }
BlobServiceClient Service { get; }
StorageClientProviderContext Context { get; }

Manşon Service üzerindeki özellik kolaylık sağlar. SDK BlobServiceClient sınıfını kullanan kodlayıcıyla ilgili son işlemlerden bazıları Depolama Hesabı kimlik bilgileri gerektirir. Bu gereksinim, ayrı bir sağlayıcı oluşturmak yerine mevcut iki kılıf türüne bir Hizmet istemci örneği eklenmesini sağladı.

Manşon kullanımı

İstemci depolama sağlayıcıları kovan örneklerini dağıtır. Depolama hizmeti kodu aşağıdaki açıklamalı kod dizisine benzer ve türler netlik için yazıldı:

public bool DeleteBlob(Uri sourceUri, StorageClientProviderContext context)
{
    . . .
    StorageBlobClientSleeve sleeve = _blobBaseClientProvider.GetBlobBaseClientForUri(sourceUri, context); // Line A
    BlobProperties propsIncludingMetadata = sleeve.Client.GetProperties(); // Line B
    sleeve.Context.TrackingETag = true;   // Send ETag from GetProperties()
    var wasDeleted = sleeve.Client.DeleteBlob(); // Line C
    sleeve.Context.TrackingETag = false;
    var someResult = sleeve.Client.AnotherOperation(); // Line D
    . . .
}
  1. Gridwich, işlem bağlamını A satırındaki manşon bağlamında otomatik olarak doldurur. TrackingETag varsayılan değeri false olarak ayarlanır.
  2. Satır B'den sonra, sleeve.Context A satırından ETag değerini içerir ve aynı ClientRequestID değeri korur.
  3. C satırı hem B Satırından ETag hem de değerinden ClientRequestIddeğeri gönderir.
  4. C. Satırdan sonra, yanıtta Delete() döndürülen bağlamın yeni ETag bir değeri vardır.
  5. D satırı isteğinde AnotherOperation()bir ETag değer göndermez.
  6. D. Satırdan sonra, yanıtta döndürülen bağlam yeni ETag bir değere AnotherOperation() sahiptir.

Depolama Hizmeti şu anda bağımlılık ekleme yapılandırmasında olduğu gibi Transient ayarlanmıştır ve bu da kovan tabanlı önbelleğe almanın istek başına temel aldığı anlamına gelir. Daha fazla bilgi için bkz . Depolama Hizmeti ve bağımlılık ekleme .

Depolama Hizmeti alternatifleri

Aşağıdaki bölümlerde geçerli Gridwich depolama çözümünün parçası olmayan alternatif yaklaşımlar açıklanmaktadır.

Alt sınıflama yoluyla işlem hattı ilkesini gizleme

SDK istemci türlerinin alt sınıflanması, işlem hattı ilkesiyle etkileşimi tamamen gizlemek için istemciye her HTTP üst bilgi değeri için bir tane olmak üzere iki basit özellik ekler. Ancak derin bir Moq hatası nedeniyle, bu türetilmiş türler için aracılığıyla mock birim testleri oluşturmak mümkün değildir. Gridwich Moq kullandığı için bu alt sınıflama yaklaşımını kullanmadı.

Moq hatası, iç kapsam sanal işlevlerinin varlığında çapraz bütünleştirilmiş kod alt sınıflamanın yanlış işlenmesiyle ilgilidir. SDK istemci sınıfları, normal dış kullanıcılar tarafından görülemeyen iç kapsam türlerini içeren iç kapsam sanal işlevlerini kullanır. Moq, Gridwich derlemelerinden birinde yer alan alt sınıftan birini mock oluşturmaya çalıştığında, Gridwich sınıflarının türetildiği SDK istemci sınıflarında iç kapsam sanallarını bulamadığından test yürütme zamanında başarısız olur. Moq Castle proxy oluşturmada değişiklikler olmadan geçici çözüm yoktur.

Depolama Hizmeti ve bağımlılık ekleme

Gridwich şu anda Depolama Hizmeti'ni bağımlılık ekleme hizmeti olarak Transient kaydeder. Diğer bir ifadeyle, bağımlılık ekleme hizmeti her istenişinde yeni bir örnek oluşturur. Kayıt olarak değişirse Scoped, geçerli kod da doğru şekilde çalışmalıdır; örneğin dış sistemin isteği gibi istek başına bir örnek anlamına geliyor.

Ancak kayıt, Gridwich İşlevi uygulaması genelinde bir örnek olarak Singletondeğişirse sorunlar olacaktır. Bu durumda manşonlar ve veri bayt aralıkları için Gridwich önbelleğe alma mekanizması farklı istekler arasında ayrım yapmaz. Ayrıca önbellek modeli kullanıma alma modeli olmadığından Gridwich kullanımdayken örneği önbellekten kaldırmaz. SDK istemci sınıflarının iş parçacığı açısından güvenli olması garanti edilmediğinden, koordinasyon için birçok değişiklik yapılması gerekir.

Bu nedenlerden dolayı, Gridwich Depolama Hizmeti'ni olduğu gibi bağımlılık ekleme kaydı olarak Singleton değiştirmeyin. Gridwich, bağımlılık ekleme kaydında bu kuralı izler ve zorlamak için CheckThatStorageServiceIsNotASingleton adlı bir birim testi içerir.

Sonraki adımlar

Ürün belgeleri:

Microsoft Learn modülleri: