Aracılığıyla paylaş

Çok kiracılı çözümlerde mesajlaşma için mimari yaklaşımlar

  • Makale

Zaman uyumsuz mesajlaşma ve olay odaklı iletişim, çeşitli iç ve dış hizmetlerden oluşan dağıtılmış bir uygulama oluştururken kritik varlıklardır. Çok kiracılı bir çözüm tasarlarken, farklı kiracılarla ilgili iletilerin nasıl paylaşılacağını veya bölümlendiğini tanımlamak için bir ön analiz yürütmek çok önemlidir.

Aynı mesajlaşma sistemini veya olay akışı hizmetini paylaşmak işletim maliyetini ve yönetim karmaşıklığını önemli ölçüde azaltabilir. Ancak, her kiracı için ayrılmış bir mesajlaşma sistemi kullanmak daha iyi veri yalıtımı sağlar, veri sızıntısı riskini azaltır, Gürültülü Komşu sorununu ortadan kaldırır ve kiracılara Azure maliyetlerini kolayca geri ödemeye olanak tanır.

Bu makalede, iletiler ve olaylar arasında bir ayrım bulabilir ve çok kiracılı bir çözümde mesajlaşma veya olay altyapısı için hangi yaklaşımın kullanılacağına karar verirken çözüm mimarlarının uygulayabileceği yönergeleri bulacaksınız.

İletiler, veri noktaları ve ayrık olaylar

Tüm mesajlaşma sistemleri benzer işlevlere, aktarım protokollerine ve kullanım senaryolarına sahiptir. Örneğin, modern mesajlaşma sistemlerinin çoğu geçici veya kalıcı kuyruklar, AMQP ve HTTPS aktarım protokolleri, en az bir kez teslim vb. kullanan zaman uyumsuz iletişimleri destekler. Ancak, yayımlanan bilgilerin türüne ve verilerin istemci uygulamaları tarafından nasıl tüketilip işlendiğine daha yakından bakarak farklı ileti ve olay türlerini ayırt edebiliriz. Olay teslim eden hizmetlerle ileti gönderen sistemler arasında önemli bir fark vardır. Daha fazla bilgi edinmek için aşağıdaki kaynaklara bakın:

Ekinlikler

Olay, bir koşulun veya durum değişikliğinin basit bir bildirimidir. Olaylar, ayrık birimler veya bir dizinin parçası olabilir. Olaylar, genellikle bir yayımcının amacını bilgilendirme dışında iletmeyen iletilerdir. Olay bir olgu yakalar ve bunu diğer hizmetlere veya bileşenlere iletir. Olayın tüketicisi olayı istediği gibi işleyebilir ve yayımcının sahip olduğu belirli beklentileri karşılamaz. Olayları iki ana kategoride sınıflandırabiliriz:

  • Ayrık olaylar , yayımlama uygulamasının gerçekleştirdiği belirli eylemler hakkında bilgi içerir. Zaman uyumsuz olay odaklı iletişim kullanılırken, bir uygulama etki alanı içinde bir şey olduğunda bir bildirim olayı yayımlar. Bir veya daha fazla tüketen uygulamanın, ürün kataloğu uygulamasındaki fiyat değişikliği gibi bu durum değişikliğinin farkında olması gerekir. Tüketiciler zaman uyumsuz olarak almak için olaylara abone olur. Belirli bir olay gerçekleştiğinde, tüketen uygulamalar etki alanı varlıklarını güncelleştirebilir ve bu da daha fazla tümleştirme olayının yayımlanmasına neden olabilir.
  • Seri olayları , analiz için cihazlardan alınan sıcaklık okumaları veya bir tıklama analizi çözümündeki kullanıcı eylemleri gibi bilgilendirici veri noktalarını, sürekli bir akıştaki öğeler olarak taşır. Olay akışı, alan cihazı tarafından bildirilen sıcaklık veya nem gibi belirli bir bağlamla ilgilidir. Aynı bağlamla ilgili tüm olaylar, bu olayları bir olay akışı işleme altyapısıyla işlerken önemli olan katı bir zamana bağlı düzene sahiptir. Veri noktaları taşıyan olayların akışlarını analiz etmek için bu olayların istenen zaman penceresine yayılan bir arabellekte biriktirilmesi gerekir. Alternatif olarak, neredeyse gerçek zamanlı bir çözüm veya makine tarafından eğitilmiş bir algoritma kullanarak seçili sayıda öğede olabilir ve bu olaylar işlenebilir. Bir dizi olayın analizi, eşiği aşan bir zaman aralığı üzerinden ölçülen bir değerin ortalaması gibi sinyaller verebilir. Bu sinyaller daha sonra ayrık, eyleme dönüştürülebilir olaylar olarak yükseltilebilir.

Ayrık olaylar rapor durumu değişiklikleri ve eyleme dönüştürülebilir. Olay yükünde ne olduğu hakkında bilgiler bulunur, ancak genel olarak olayı tetikleyen verilerin tamamına sahip değildir. Örneğin, bir olay tüketicilere raporlama uygulamasının depolama hesabında yeni bir dosya oluşturduğunu bildirir. Olay yükü dosya hakkında genel bilgilere sahip olabilir, ancak dosyanın kendisine sahip değildir. Ayrık olaylar, ölçeklendirilmesi gereken sunucusuz çözümler için idealdir.

Seri olaylar bir koşulu bildirir ve çözümlenebilir. Ayrık olaylar zaman sıralı ve birbiriyle ilişkilidir. Bazı bağlamlarda, tüketicinin ne olduğunu analiz etmek ve gerekli eylemi yapmak için olayların tam sırasını alması gerekir.

İletiler

İletiler, bir hizmet tarafından tüketilecek veya başka bir yerde depolanacak şekilde üretilen ham verileri içerir. İletiler genellikle alıcı hizmetin bir iş akışında veya işleme zincirinde adımları yürütmesi için gerekli bilgileri taşır. Bu tür bir iletişim örneği, Komut düzenidir. Yayımcı ayrıca bir iletinin alıcılarının bir dizi eylem yürütmesini ve zaman uyumsuz bir iletiyle bunların işlenmesinin sonucunu geri raporlamasını bekleyebilir. İleti yayımcısı ile ileti alıcıları arasında bir sözleşme vardır. Örneğin, yayımcı bazı ham verilerle bir ileti gönderir ve tüketicinin bu verilerden bir dosya oluşturmasını ve bittiğinde bir yanıt iletisi göndermesini bekler. Diğer durumlarda, gönderen işlemi başka bir hizmetten belirli bir işlemi gerçekleştirmesini istemek için zaman uyumsuz, tek yönlü bir ileti gönderebilir, ancak bu iletiden onay veya yanıt iletisini geri alma beklentisi yoktur.

Bu tür bir sözleşmeye dayalı ileti işleme, bu bildirimleri nasıl işleyeceklerine dair belirli bir beklenti olmadan, ayrık olayları tüketici aracılarının hedef kitlesine yayımlayan bir yayıncıdan oldukça farklıdır.

Örnek senaryolar

İletiler, veri noktaları ve ayrık olaylar için birkaç örnek çok kiracılı senaryonun listesi aşağıda verilmiştir:

  • Ayrık olaylar:
    • Müzik paylaşım platformu, belirli bir kiracıdaki belirli bir kullanıcının belirli bir müzik parçasını dinlediği gerçeğini izler.
    • Çevrimiçi mağaza web uygulamasında katalog uygulaması, bir öğe fiyatının değiştiğini bildirmek için Publisher-Abone desenini kullanan bir olayı diğer uygulamalara gönderir.
    • Üretim şirketi ekipman bakımı, sistem durumu ve sözleşme güncelleştirmeleri hakkında müşterilere ve üçüncü taraflara gerçek zamanlı bilgiler göndermektedir.
  • Veri noktaları:
    • Bina kontrol sistemi, birden çok müşteriye ait algılayıcılardan sıcaklık veya nem okumaları gibi telemetri olayları alır.
    • Olay odaklı bir izleme sistemi, tanılama günlüklerini web sunucuları gibi birden çok hizmetten neredeyse gerçek zamanlı bir şekilde alır ve işler.
    • Web sayfasındaki istemci tarafı betiği kullanıcı eylemlerini toplar ve bunları bir tıklama analizi çözümüne gönderir.
  • Ileti:
    • B2B finans uygulaması, kiracının bankacılık kayıtlarını işlemeye başlamak için bir ileti alır.
    • Uzun süre çalışan bir iş akışı, sonraki adımın yürütülmesini tetikleyen bir ileti alır.
    • Çevrimiçi mağaza uygulamasının sepet uygulaması, sipariş uygulamasına zaman uyumsuz, kalıcı bir ileti kullanarak createOrder komutu gönderir.

Önemli noktalar ve gereksinimler

Çözümünüz için seçtiğiniz dağıtım ve kiracı modeli, güvenlik, performans, veri yalıtımı, yönetim ve kiracılara kaynak maliyetlerini çapraz ücretlendirme olanağı üzerinde derin bir etkiye sahiptir. Bu analiz, mesajlaşma ve olay altyapısı için seçtiğiniz modeli içerir. Bu bölümde, çok kiracılı çözümünüzde bir mesajlaşma sistemi planlarken yapmanız gereken bazı önemli kararları gözden geçireceğiz.

Ölçek

Kiracı sayısı, ileti akışlarının ve olay akışlarının karmaşıklığı, iletilerin hacmi, beklenen trafik profili ve yalıtım düzeyi, bir mesajlaşma veya olay altyapısı planlarken kararları yönlendirmelidir.

İlk adım, düzenli veya yoğun trafik altında beklenen ileti hacmini düzgün bir şekilde işlemek için aktarım hızı açısından bir mesajlaşma sistemi için gerekli maksimum kapasiteyi oluşturmak ve kapsamlı kapasite planlaması gerçekleştirmektir.

Azure Service Bus Premium katmanı gibi bazı hizmet teklifleri, her müşteri iş yükünün yalıtılmış olarak çalışması için CPU ve bellek düzeyinde kaynak yalıtımı sağlar. Bu kaynak kapsayıcısı mesajlaşma birimi olarak adlandırılır. Her premium ad alanı, en az bir mesajlaşma birimi için ayrılmıştır. Her Service Bus Premium ad alanı için 1, 2, 4, 8 veya 16 mesajlaşma birimleri satın alabilirsiniz. Tek bir iş yükü veya varlık birden çok mesajlaşma birimine yayılabilir ve mesajlaşma birimi sayısını gerektiği gibi değiştirebilirsiniz. Sonuç, Service Bus tabanlı çözümünüz için tahmin edilebilir ve yinelenebilir bir performanstır. Daha fazla bilgi için bkz . Service Bus Premium ve Standart mesajlaşma katmanları. Benzer şekilde, Azure Event Hubs fiyatlandırma katmanları da ad alanını beklenen gelen ve giden olay hacmine göre boyutlandırmanıza olanak sağlar. Örneğin Premium teklif, temel alınan altyapıdaki yalıtılmış kaynakların (CPU, bellek ve depolama) paylaşımına karşılık gelen işlem birimleri (PU) tarafından faturalandırılır. PU başına etkili alma ve akış aktarım hızı aşağıdaki faktörlere bağlıdır:

  • Üretici ve tüketici sayısı
  • Yük boyutu
  • Bölüm sayısı
  • Çıkış isteği oranı
  • Event Hubs Yakalama, Şema Kayıt Defteri ve diğer gelişmiş özelliklerin kullanımı

Daha fazla bilgi için bkz . Event Hubs Premium'a genel bakış.

Çözümünüz çok sayıda kiracıyı işlediğinde ve her kiracı için ayrı bir mesajlaşma sistemi benimsemeye karar verdiyseniz, her bir altyapının dağıtımını, izlemesini, uyarısını ve ölçeklendirmesini birbirinden ayrı olarak otomatikleştirmek için tutarlı bir stratejiniz olması gerekir.

Örneğin, terraform, Bicep veya Azure Resource Manager (ARM) JSON şablonları gibi bir kod olarak altyapı (IaC) aracı ve Azure DevOps veya GitHub Actions gibi bir DevOps sistemi kullanılarak, belirli bir kiracı için mesajlaşma sistemi sağlama işlemi sırasında dağıtılabilir. Daha fazla bilgi için bkz . Çok kiracılı çözümlerin dağıtımı ve yapılandırması için mimari yaklaşımlar.

Mesajlaşma sistemi, iletilerde zaman birimi başına maksimum aktarım hızıyla boyutlandırılabilir. Sistem dinamik otomatik ölçeklendirmeyi destekliyorsa, beklenen hizmet düzeyi sözleşmesini karşılamaya yönelik trafik koşullarına ve ölçümlere göre kapasitesi otomatik olarak artırılabilir veya azaltılabilir.

Performans öngörülebilirliği ve güvenilirliği

Sınırlı sayıda kiracı için bir mesajlaşma sistemi tasarlayıp oluştururken tek bir mesajlaşma sistemi kullanmak, işleme hızı açısından işlevsel gereksinimleri karşılamak için mükemmel bir çözüm olabilir ve toplam sahip olma maliyetini azaltabilir. Çok kiracılı bir uygulama, kuyruklar ve konular gibi aynı mesajlaşma varlıklarını birden çok müşteri arasında paylaşabilir. Kiracı yalıtımını artırmak için her biri için ayrılmış bir bileşen kümesi de kullanabilirler. Öte yandan, aynı mesajlaşma altyapısını birden çok kiracıda paylaşmak, tüm çözümü Gürültülü Komşu sorununa maruz bırakabilir. Bir kiracının etkinliği, performans ve çalışabilirlik açısından diğer kiracılara zarar verebilir.

Bu durumda, mesajlaşma sistemi beklenen trafik yükünü en yoğun zamanda sürdürecek şekilde düzgün boyutlandırılmalıdır. İdeal olarak, otomatik ölçeklendirmeyi desteklemelidir. Mesajlaşma sistemi, trafik arttığında dinamik olarak ölçeği genişletmeli ve trafik azaldığında ölçeği daraltmalıdır. Her kiracı için ayrılmış bir mesajlaşma sistemi Gürültülü Komşu riskini de azaltabilir, ancak çok sayıda mesajlaşma sisteminin yönetilmesi çözümün karmaşıklığını artırabilir.

Çok kiracılı bir uygulama, çekirdek hizmetlerin iç, zaman uyumsuz iletişimler uygulamak için tek bir paylaşılan mesajlaşma sisteminde aynı kuyruk ve konu kümesini kullandığı karma bir yaklaşımı benimseyebilir. Buna karşılık, diğer hizmetler her kiracının Gürültülü Komşu sorununu hafifletmek ve veri yalıtımını garanti etmek için ayrılmış bir grup mesajlaşma varlıklarını ve hatta ayrılmış bir mesajlaşma sistemini benimseyebilir.

Sanal makinelere bir mesajlaşma sistemi dağıtırken, ağ gecikme süresini azaltmak için bu sanal makineleri işlem kaynaklarıyla birlikte bulmanız gerekir. Mesajlaşma altyapısının CPU, bellek ve ağ bant genişliği gibi sistem kaynaklarıyla diğer sistemlerle rekabet etmemesi için bu sanal makineler diğer hizmetler veya uygulamalarla paylaşılmamalıdır. Sanal makineler, mesajlaşma sistemleri de dahil olmak üzere iş açısından kritik iş yüklerinin bölge içi dayanıklılığını ve güvenilirliğini artırmak için kullanılabilirlik alanlarına da yayılabilir. RabbitMQ veya Apache ActiveMQ gibi bir mesajlaşma sistemini sanal makinelerde barındırmaya karar verin. Bu durumda, bunu bir sanal makine ölçek kümesine dağıtmanızı ve CPU veya bellek gibi ölçümlere göre otomatik ölçeklendirme için yapılandırmanızı öneririz. Bu şekilde, mesajlaşma sistemini barındıran aracı düğümlerinin sayısı, trafik koşullarına bağlı olarak ölçeği düzgün bir şekilde genişletecek ve ölçeği daraltacaktır. Daha fazla bilgi için bkz . Azure sanal makine ölçek kümeleri ile otomatik ölçeklendirmeye genel bakış.

Benzer şekilde, mesajlaşma sisteminizi bir Kubernetes kümesinde barındırırken, Gürültülü Komşu sorununu önlemek için düğüm seçicileri ve renk tonlarını kullanarak podlarının yürütülmesini diğer iş yükleriyle paylaşılmayan ayrılmış bir düğüm havuzunda zamanlayabilirsiniz. Bir mesajlaşma sistemini alanlar arası yedekli AKS kümesine dağıtırken podların AKS kümenizde bölgeler, kullanılabilirlik alanları ve düğümler gibi hata etki alanları arasında nasıl dağıtıldığını denetlemek için Pod topolojisi yayma kısıtlamalarını kullanın. AKS'de üçüncü taraf mesajlaşma sistemi barındırırken, trafik arttığında çalışan düğümlerinin sayısını dinamik olarak genişletmek için Kubernetes otomatik ölçeklendirmesini kullanın. Yatay Pod Otomatik Ölçeklendiricisi ve AKS kümesi otomatik ölçeklendiricisi ile düğüm ve pod birimleri, trafik durumuyla eşleşecek ve kapasite sorunlarından kaynaklanan kapalı kalma sürelerini önlemek için gerçek zamanlı olarak dinamik olarak ayarlanır. Daha fazla bilgi için bkz . Azure Kubernetes Service (AKS) üzerindeki uygulama taleplerini karşılamak için kümeyi otomatik olarak ölçeklendirme. RabbitMQ veya Apache ActiveMQ gibi Kubernetes tarafından barındırılan bir mesajlaşma sisteminin pod sayısını belirli bir kuyruğun uzunluğuna göre genişletmek istiyorsanız Kubernetes Çift Yönlü Otomatik Ölçeklendirme (KEDA) kullanmayı göz önünde bulundurun. KEDA ile Kubernetes'teki herhangi bir kapsayıcının ölçeğini, işlenmesi gereken olay sayısına göre yönlendirebilirsiniz. Örneğin, uygulamaları Azure Service Bus kuyruğunun uzunluğuna, RabbitMQ kuyruğuna veya ActiveMQ kuyruğuna göre ölçeklendirmek için KEDA kullanabilirsiniz. KEDA hakkında daha fazla bilgi için bkz . Kubernetes Event-driven Autoscaling.

Yalıtım

Mesajlaşma sistemini çok kiracılı bir çözüm için tasarlarken, farklı uygulama türlerinin kiracıların performans, gizlilik ve denetim gereksinimlerini temel alan farklı bir yalıtım türü gerektirdiğini göz önünde bulundurmalısınız.

  • Birden çok kiracı aynı mesajlaşma sisteminde kuyruklar, konular ve abonelikler gibi aynı mesajlaşma varlıklarını paylaşabilir. Örneğin, çok kiracılı bir uygulama tek bir Azure Service Bus kuyruğundan birden çok kiracı için veri taşıyan iletiler alabilir. Bu çözüm performans ve ölçeklenebilirlik sorunlarına yol açabilir. Kiracılardan bazıları diğerlerinden daha büyük miktarda sipariş oluşturuyorsa, bu durum iletilerin bir kapsamına neden olabilir. Gürültülü Komşu sorunu olarak da bilinen bu sorun, bazı kiracıların gecikme süresi açısından hizmet düzeyi sözleşmesini düşürebilir. Tüketici uygulaması kuyruktaki iletileri tek tek, katı bir kronolojik sırayla okur ve işlerse ve bir iletiyi işlemek için gereken süre yükteki öğelerin sayısına bağlıysa sorun daha belirgindir. Birden çok kiracıda bir veya daha fazla kuyruk kaynağı paylaşırken, mesajlaşma altyapısı ve işleme sistemleri ölçek ve aktarım hızı gereksinimleri tabanlı beklenen trafiği karşılayabilmelidir. Bu mimari yaklaşım, çok kiracılı bir çözümün tüm kiracılar için ileti almak, işlemek ve göndermek için tek bir çalışan işlemleri havuzunu benimsediği senaryolarda uygundur.
  • Birden çok kiracı aynı mesajlaşma sistemini paylaşır ancak farklı konu veya kuyruk kaynakları kullanır. Sistem yöneticilerinin daha fazla sayıda kuyruk kaynağı sağlaması, izlemesi ve sürdürmesi gerektiğinden bu yaklaşım daha yüksek maliyetle daha iyi yalıtım ve veri koruması, daha yüksek operasyonel karmaşıklık ve daha düşük çeviklik sağlar. Bu çözüm, herhangi bir kiracının diğer kiracıları etkileyebilecek bir performans sorunu oluşturmasını engellediğinden, performans ve hizmet düzeyi sözleşmeleri açısından tüm kiracılar için tutarlı ve öngörülebilir bir deneyim sağlar.
  • Her kiracı için ayrı ve ayrılmış bir mesajlaşma sistemi kullanılır. Örneğin, çok kiracılı bir çözüm her kiracı için ayrı bir Azure Service Bus ad alanı kullanabilir. Bu çözüm, daha yüksek bir karmaşıklık ve operasyonel maliyetle maksimum yalıtım derecesini sağlar. Bu yaklaşım tutarlı performansı garanti eder ve belirli kiracı gereksinimlerine göre mesajlaşma sisteminde ince ayar yapılmasını sağlar. Yeni bir kiracı eklendiğinde, tamamen ayrılmış bir mesajlaşma sistemine ek olarak, sağlama uygulamasının yeni oluşturulan ad alanına erişmek için uygun RBAC izinlerine sahip ayrı bir yönetilen kimlik veya hizmet sorumlusu da oluşturması gerekebilir. Örneğin, bir Kubernetes kümesi aynı SaaS uygulamasının her kiracı için bir tane olmak üzere birden çok örneği tarafından paylaşıldığında ve her biri ayrı bir ad alanında çalıştırıldığında, her uygulama örneği ayrılmış bir mesajlaşma sistemine erişmek için farklı bir hizmet sorumlusu veya yönetilen kimlik kullanabilir. Bu bağlamda mesajlaşma sistemi, Azure Service Bus ad alanı gibi tam olarak yönetilen bir PaaS hizmeti veya RabbitMQ gibi Kubernetes tarafından barındırılan bir mesajlaşma sistemi olabilir. Bir kiracıyı sistemden silerken, uygulamanın daha önce kiracı için oluşturulmuş olan mesajlaşma sistemini ve ayrılmış kaynakları kaldırması gerekir. Bu yaklaşımın temel dezavantajı, özellikle kiracı sayısı zaman içinde arttığında operasyonel karmaşıklığı artırması ve çevikliği azaltmasıdır.

Aşağıdaki ek konuları ve gözlemleri gözden geçirin:

  • Kiracıların iletileri şifrelemek ve şifresini çözmek için kendi anahtarlarını kullanması gerekiyorsa, çok kiracılı bir çözüm her kiracı için ayrı bir Azure Service Bus Premium ad alanı benimseme seçeneği sağlamalıdır. Daha fazla bilgi için bkz . Bekleyen Azure Service Bus verilerini şifrelemek için müşteri tarafından yönetilen anahtarları yapılandırma.
  • Kiracılar yüksek düzeyde dayanıklılık ve iş sürekliliğine ihtiyaç duyuyorsa, çok kiracılı bir çözüm coğrafi olağanüstü durum kurtarma ve kullanılabilirlik alanları etkinleştirilmiş bir Service Bus Premium ad alanı sağlama olanağı sağlamalıdır. Daha fazla bilgi için bkz . Azure Service Bus Coğrafi olağanüstü durum kurtarma.
  • Her kiracı için ayrı kuyruk kaynakları veya ayrılmış bir mesajlaşma sistemi kullanılırken, her biri için veri yalıtım düzeyini artırmak ve birden çok mesajlaşma varlığıyla ilgilenme karmaşıklığını azaltmak için ayrı bir çalışan işlemleri havuzu benimsemek mantıklıdır. İşleme sisteminin her örneği, ayrılmış mesajlaşma sistemine erişmek için bağlantı dizesi, hizmet sorumlusu veya yönetilen kimlik gibi farklı kimlik bilgilerini benimseyebilir. Bu yaklaşım kiracılar arasında daha iyi bir güvenlik düzeyi ve yalıtım sağlar, ancak kimlik yönetiminde karmaşıklığın artırılmasını gerektirir.

Benzer şekilde, olay temelli bir uygulama farklı yalıtım düzeyleri sağlayabilir:

  • Olay odaklı bir uygulama, tek bir paylaşılan Azure Event Hubs örneği aracılığıyla birden çok kiracıdan olay alır. Bu çözüm yüksek düzeyde çeviklik sağlar, çünkü yeni bir kiracının eklenmesi ayrılmış bir olay alma kaynağı oluşturmayı gerektirmez, ancak aynı veri yapısındaki birden çok kiracıdan gelen iletileri birbirine karıştırdığından düşük bir veri koruma düzeyi sağlar.
  • Kiracılar, Gürültülü Komşu sorunundan kaçınmak ve güvenlik ve veri koruması için olayların diğer kiracıların kiracılarıyla birlikte karıştırılmaması gerektiğinde veri yalıtımı gereksinimlerini karşılamak için ayrılmış bir olay hub'ı veya Kafka konusunu tercih edebilir.
  • Kiracılar yüksek düzeyde dayanıklılık ve iş sürekliliğine ihtiyaç duyuyorsa, çok kiracılı coğrafi olağanüstü durum kurtarma ve kullanılabilirlik alanları etkinleştirilmiş bir Event Hubs Premium ad alanı sağlama olanağı sağlamalıdır. Daha fazla bilgi için bkz . Azure Event Hubs - Coğrafi olağanüstü durum kurtarma.
  • Event Hubs Yakalama özelliği etkin olan Ayrılmış Event Hubs, mevzuat uyumluluğu nedenleriyle ve yükümlülükleriyle olayları azure Depolama hesabında arşivlemesi gereken müşteriler için oluşturulmalıdır. Daha fazla bilgi için bkz. Azure Blob Depolama'da Azure Event Hubs aracılığıyla olayları yakalama veya Azure Data Lake Depolama.
  • Tek bir çok kiracılı uygulama, Azure Event Grid kullanarak birden çok iç ve dış sistemlere bildirim gönderebilir. Bu durumda, her tüketici uygulaması için ayrı bir Event Grid aboneliği oluşturulmalıdır. Uygulamanız çok sayıda dış kuruluşa bildirim göndermek için birden çok Event Grid örneğini kullanıyorsa, bir uygulamanın her kiracı için bir tane gibi binlerce konuya olay yayımlamasına olanak tanıyan olay etki alanlarını kullanmayı göz önünde bulundurun. Daha fazla bilgi için bkz . Event Grid konularını yönetmek için olay etki alanlarını anlama.

Uygulamanın karmaşıklığı

Çok kiracılı bir çözüm tasarlarken, çözümün bir kısmını veya tamamını yeniden tasarlamak gerekinceye kadar karmaşıklığının zaman içinde büyümesini önlemek için sistemin orta ila uzun vadede nasıl gelişeceğini göz önünde bulundurmak önemlidir. Bu yeniden tasarım, artan sayıda kiracıyla başa çıkmanıza yardımcı olacaktır. Mesajlaşma sistemi tasarlarken, önümüzdeki birkaç yıl içinde ileti birimlerinde ve kiracılarda beklenen büyümeyi göz önünde bulundurmanız ve ardından tahmin edilen trafiğe ayak uydurmak ve sağlama, izleme ve bakım gibi işlemlerin karmaşıklığını azaltmak için ölçeği genişletebilen bir sistem oluşturmanız gerekir.

Bir kiracı uygulaması sağlandığında veya sağlamaları kaldırıldığında, el ile işlemlere gerek kalmadan çözümün gerekli mesajlaşma varlıklarını otomatik olarak oluşturması veya silmesi gerekir.

Çok kiracılı veri çözümleri için özel bir endişe, desteklediğiniz özelleştirme düzeyidir. Tüm özelleştirmeler, tek kiracılı veya çok kiracılı bir uygulama dağıtıldığında bir dizi ilk parametreyi temel alan uygulama sağlama sistemi (DevOps sistemi gibi) tarafından otomatik olarak yapılandırılıp uygulanmalıdır.

Yönetim ve işlemlerin karmaşıklığı

Mesajlaşma ve olay altyapınızı çalıştırmayı, izlemeyi ve bakımını yapmayı ve çok kiracılı yaklaşımınızın operasyonlarınızı ve süreçlerinizi nasıl etkileyeceğini baştan planlayın. Örneğin, aşağıdaki olasılıkları göz önünde bulundurun:

  • Uygulamanız tarafından kullanılan mesajlaşma sistemini her kiracı için bir tane olmak üzere ayrılmış bir sanal makine kümesinde barındırmayı planlayabilirsiniz. Öyleyse, bu sistemleri dağıtmayı, yükseltmeyi, izlemeyi ve ölçeği genişletmeyi nasıl planlıyorsunuz?
  • Benzer şekilde, mesajlaşma sisteminizi kapsayıcılı hale getirmek ve paylaşılan bir Kubernetes kümesinde barındırmak istiyorsanız, tek tek mesajlaşma sistemlerini dağıtmayı, yükseltmeyi, izlemeyi ve ölçeğini genişletmeyi nasıl planlıyorsunuz?
  • Bir mesajlaşma sistemini birden çok kiracıda paylaştığınızı varsayalım. Çözümünüz kiracı başına kullanım ölçümlerini nasıl toplayıp raporlayabilir ya da her kiracının gönderebileceği veya alabileceği ileti sayısını nasıl kısıtlayabilir?
  • Mesajlaşma sisteminiz Azure Service Bus gibi bir PaaS hizmetinden yararlandığında aşağıdaki soruyu sormalısınız:
    • Kiracı tarafından istenen özelliklere ve yalıtım düzeyine (paylaşılan veya ayrılmış) göre her kiracı için fiyatlandırma katmanını nasıl özelleştirebilirsiniz?
    • Kiracının erişebileceği kuyruklar, konular ve abonelikler gibi yalnızca mesajlaşma varlıklarına uygun izinleri atamak için kiracı başına yönetim kimliği ve Azure rol ataması nasıl oluşturabilirsiniz? Daha fazla bilgi için bkz . Azure Service Bus kaynaklarına erişmek için Microsoft Entra Id ile yönetilen kimliğin kimliğini doğrulama.
  • Farklı bir mesajlaşma hizmetine, farklı bir dağıtıma veya başka bir bölgeye geçmeleri gerekiyorsa kiracıları nasıl geçirirsiniz?

Maliyet

Genellikle, kiracıların dağıtım altyapınızdaki yoğunluğu ne kadar yüksek olursa, bu altyapıyı sağlama maliyeti de o kadar düşük olur. Ancak, paylaşılan altyapı Gürültülü Komşu sorunu gibi sorunların olasılığını artırır, bu nedenle dengeleri dikkatli bir şekilde göz önünde bulundurun.

Dikkate alınacak yaklaşımlar ve desenler

Azure Mimari Merkezi'nden çeşitli Bulut Tasarımı Desenleri çok kiracılı bir mesajlaşma sistemine uygulanabilir. Bir veya daha fazla deseni tutarlı bir şekilde izlemeyi seçebilir veya gereksinimlerinize göre desenleri karıştırmayı ve eşleştirmeyi düşünebilirsiniz. Örneğin, kiracılarınızın çoğu için çok kiracılı bir Service Bus ad alanı kullanabilirsiniz, ancak daha fazla ödeme yapan veya gereksinimleri daha yüksek olan kiracılar için ayrılmış, tek kiracılı bir Service Bus ad alanı dağıtabilirsiniz. Benzer şekilde, çok kiracılı bir Service Bus ad alanı veya damga içinde ayrılmış ad alanları kullandığınızda bile dağıtım damgalarını kullanarak ölçeklendirmek genellikle iyi bir uygulamadır.

Dağıtım DamgaLarı düzeni

Dağıtım Damga Damgaları düzeni ve çok kiracılılık hakkında daha fazla bilgi için, Çok kiracılılık için mimari yaklaşımların Dağıtım DamgaLarı deseni bölümüne bakın. Kiracı modelleri hakkında daha fazla bilgi için bkz . Çok kiracılı bir çözüm için dikkate alınacak kiracı modelleri.

Paylaşılan mesajlaşma sistemi

Azure Service Bus gibi paylaşılan bir mesajlaşma sistemini dağıtmayı ve tüm kiracılarınızda paylaşmayı düşünebilirsiniz.

Tüm kiracılar için tek bir paylaşılan çok kiracılı mesajlaşma sistemini gösteren diyagram.

Bu yaklaşım, altyapıya en yüksek kiracı yoğunluğu sağlar, bu nedenle toplam sahip olma maliyetini azaltır. Ayrıca, yönetilip güvenli duruma getirmek için tek bir mesajlaşma sistemi veya kaynak olduğundan genellikle yönetim ek yükünü azaltır.

Ancak, birden çok kiracıda bir kaynağı veya altyapının tamamını paylaştığınızda aşağıdaki uyarıları göz önünde bulundurun:

  • Söz konusu kaynağın kısıtlamalarını, ölçeklendirme özelliklerini, kotalarını ve sınırlarını her zaman aklınızda bulundurun. Örneğin, bir Azure aboneliğindeki en fazla Service Bus ad alanı sayısı, tek bir ad alanındaki en fazla Event Hub sayısı veya en yüksek aktarım hızı sınırları, mimariniz daha fazla kiracıyı destekleyecek şekilde büyürse ve arttığında sabit bir engelleyici haline gelebilir. Tek Azure aboneliği başına ad alanı sayısı veya tek bir ad alanı başına kuyruk sayısı açısından elde etmeniz gereken en yüksek ölçeği dikkatle göz önünde bulundurun. Ardından, bu düzeni seçmeden önce mevcut ve gelecekteki tahminlerinizi tercih ettiğiniz mesajlaşma sisteminin mevcut kotalarıyla ve sınırlarıyla karşılaştırın.
  • Yukarıdaki bölümlerde belirtildiği gibi, özellikle bazıları meşgulse veya diğerlerinden daha yüksek trafik oluşturuyorsa, birden çok kiracıda bir kaynağı paylaştığınızda Gürültülü Komşu sorunu bir faktör haline gelebilir. Bu durumda, bu etkileri azaltmak için Azaltma desenini veya Hız Sınırlama desenini uygulamayı göz önünde bulundurun. Örneğin, tek bir kiracının zaman biriminde gönderebileceği veya alabileceği en fazla ileti sayısını sınırlayabilirsiniz.
  • Etkinliği izlemekte ve tek bir kiracı için kaynak tüketimini ölçmekte zorluk yaşayabilirsiniz. Azure Service Bus gibi bazı hizmetler, mesajlaşma işlemleri için ücretlendirilir. Bu nedenle, bir ad alanını birden çok kiracı arasında paylaştığınızda, uygulamanız her kiracı adına yapılan mesajlaşma işlemlerinin sayısını ve bunlara yönelik geri ödeme maliyetlerini izleyebilmelidir. Diğer hizmetler aynı ayrıntı düzeyini sağlamaz.

Kiracıların güvenlik, bölge içi dayanıklılık, olağanüstü durum kurtarma veya konum için farklı gereksinimleri olabilir. Bunlar mesajlaşma sistemi yapılandırmanızla eşleşmiyorsa, bunları yalnızca tek bir kaynakla barındıramayabilirsiniz.

Parçalama düzeni

Parçalama düzeni, kuyruklar ve konular gibi bir veya daha fazla kiracının mesajlaşma varlıklarını içeren parçalar olarak adlandırılan birden çok mesajlaşma sistemi dağıtmayı içerir. Dağıtım damgalarından farklı olarak parçalar, altyapının tamamının çoğaltıldığı anlamına gelmez. Ayrıca çözümünüzdeki diğer altyapıyı çoğaltmadan veya parçalamadan mesajlaşma sistemlerini parçalayabilirsiniz.

Parçalı mesajlaşma sistemini gösteren diyagram. Bir mesajlaşma sistemi A ve B kiracıları için kuyrukları, diğeri de C kiracısının kuyruklarını içerir.

Her mesajlaşma sistemi veya parçası güvenilirlik, SKU ve konum açısından farklı özelliklere sahip olabilir. Örneğin, kiracılarınızı performans, güvenilirlik, veri koruması veya iş sürekliliği açısından konumlarına veya ihtiyaçlarına göre farklı özelliklere sahip birden çok mesajlaşma sistemi arasında parçalayabilirsiniz.

Parçalama düzenini kullanırken, belirli bir kiracıyı kuyruklarını içeren mesajlaşma sistemiyle eşlemek için bir parçalama stratejisi kullanmanız gerekir. Arama stratejisi , kiracı adına veya kimliğine göre hedef mesajlaşma sistemini canlandırmak için bir harita kullanır. Birden çok kiracı aynı parçaya sahip olabilir, ancak tek bir kiracı tarafından kullanılan mesajlaşma varlıkları birden çok parçaya yayılmaz. Harita, kiracının adını hedef mesajlaşma sisteminin adı veya başvurusuyla eşleyen tek bir sözlükle uygulanabilir. Harita, çok kiracılı bir uygulamanın tüm örnekleri tarafından erişilebilen dağıtılmış bir önbellekte veya ilişkisel veritabanındaki tablo veya depolama hesabındaki bir tablo gibi kalıcı bir depoda depolanabilir.

Parçalama düzeni çok fazla sayıda kiracıya ölçeklendirilebilir. Ayrıca, iş yükünüz bağlı olarak, maliyetlerin cazip olabilmesi için parçalar için yüksek kiracı yoğunluğu elde edebilirsiniz. Parçalama düzeni, Azure aboneliğini ve hizmet kotalarını, sınırlarını ve kısıtlamalarını ele almak için de kullanılabilir.

Her kiracı için ayrılmış mesajlaşma sistemine sahip çok kiracılı uygulama

Bir diğer yaygın yaklaşım, her kiracı için ayrılmış mesajlaşma sistemleriyle tek bir çok kiracılı uygulama dağıtmaktır. Bu kiracı modelinde bilgi işlem kaynakları gibi bazı paylaşılan bileşenleriniz vardır; diğer hizmetler ise tek kiracılı, ayrılmış dağıtım yaklaşımı kullanılarak sağlanır ve yönetilir. Örneğin, aşağıdaki çizimde gösterildiği gibi tek bir uygulama katmanı oluşturabilir ve ardından her kiracı için ayrı mesajlaşma sistemleri dağıtabilirsiniz.

Her kiracı için farklı mesajlaşma sistemlerini gösteren diyagram.

Yatay olarak bölümlenmiş dağıtımlar, sisteminizdeki yükün çoğunun her kiracı için ayrı olarak dağıtabileceğiniz belirli bileşenlerden kaynaklandığını belirlediyseniz gürültülü komşu sorununu azaltmanıza yardımcı olabilir. Örneğin, tek bir örnek birden çok kiracı tarafından oluşturulan trafiğe ayak uydurmak için yeterli olmadığından her kiracı için ayrı bir mesajlaşma veya olay akış sistemi kullanmanız gerekebilir. Her kiracı için ayrılmış bir mesajlaşma sistemi kullanılırken, tek bir kiracı büyük miktarda iletiye veya olaya neden oluyorsa, bu paylaşılan bileşenleri etkileyebilir ancak diğer kiracıların mesajlaşma sistemlerini etkilemez.

Her kiracı için ayrılmış kaynaklar sağladığınız için, bu yaklaşımın maliyeti paylaşılan bir barındırma modelinden daha yüksek olabilir. Öte yandan, bu kiracı modelini benimserken ayrılmış bir sistemin kaynak maliyetlerini kullanan benzersiz kiracıya geri almak daha kolaydır. Bu yaklaşım, bilgi işlem kaynakları gibi diğer hizmetler için yüksek yoğunluk elde etmenizi sağlar ve bu bileşenlerin maliyetlerini azaltır.

Yatay olarak bölümlenmiş bir dağıtımda, özellikle tek bir kiracı tarafından kullanılanlar olmak üzere çok kiracılı bir uygulamanın hizmetlerini dağıtmak ve yönetmek için otomatik bir işlemi benimsemeniz gerekir.

Coğrafi bölge deseni

Geode düzeni, bir arka uç hizmetleri koleksiyonunu bir coğrafi düğüm kümesine dağıtmayı içerir. Her biri, herhangi bir bölgedeki herhangi bir istemci için herhangi bir isteğe hizmet verebilir. Bu düzen, istek işlemeyi dünya çapında dağıtarak gecikme süresini artıran ve kullanılabilirliği artıran etkin-etkin bir stilde istek sunmanızı sağlar.

Birlikte eşitlenen birden çok bölgede dağıtılan mesajlaşma sistemlerinin yer alan Geode desenini gösteren diyagram.

Azure Service Bus ve Azure Event Hubs , en iyi bölge içi dayanıklılık desteği sağlamak için birincil ve ikincil olağanüstü durum kurtarma ad alanlarında ve ayrı bölgelerde ve kullanılabilirlik alanlarında meta veri olağanüstü durum kurtarmayı destekler. Ayrıca, Azure Service Bus ve Azure Event Hubs aynı mantıksal konuyu, kuyruğu veya olay hub'ını birden çok ad alanında kullanılabilir olacak şekilde etkin bir şekilde çoğaltan ve sonunda farklı bölgelerde bulunan bir federasyon desenleri kümesi uygular. Daha fazla bilgi edinmek için aşağıdaki kaynaklara bakın:

Katkıda Bulunanlar

Bu makale Microsoft tarafından yönetilir. Başlangıçta aşağıdaki katkıda bulunanlar tarafından yazılmıştır.

Asıl yazar:

Diğer katkıda bulunanlar:

Sonraki adımlar

Mesajlaşma tasarım desenleri hakkında daha fazla bilgi için aşağıdaki kaynaklara bakın: