Olay güdümlü mimari stili

Olay odaklı mimari, bir olay akışı oluşturan olay üreticilerinden , bu olayları dinleyen olay tüketicilerinden ve olayları üreticilerden tüketicilere aktaran olay kanallarından (genellikle olay aracısı veya alım hizmeti olarak uygulanır) oluşur.

Architecture

Olay temelli mimari stilini gösteren diyagram.

Olaylar gerçek zamanlıya yakın bir şekilde teslim edilir, böylece tüketiciler olaylar gerçekleşirken olaylara hemen yanıt verebilir. Üreticiler tüketicilerden ayrılmıştır, bu da bir üreticinin hangi tüketicilerin dinlediğini bilmediği anlamına gelir. Tüketiciler de birbirinden ayrılmıştır ve yayımlama-abone olma modelinde her tüketici tüm olayları görür.

Bu işlem Rakip Tüketiciler deseninden farklıdır. Rakip Tüketiciler paterninde tüketiciler kuyruktan mesaj çeker. Hata olmadığı varsayılarak her ileti yalnızca bir kez işlenir. Azure IoT gibi bazı sistemlerde olayların yüksek hacimlerde alınması gerekir.

Olay odaklı mimari , yayımlama-abone olma modeli veya olay akışı modeli kullanabilir.

  • Yayımla-abone ol: Yayımla-abone ol mesajlaşma altyapısı abonelikleri izler. Bir olay yayımlandığında olayı her aboneye gönderir. Olay alındıktan sonra dayanıklı bir günlükte depolanmaz, bu nedenle yeni aboneler geçmiş olayları görmez. Yayımlama-abone olma senaryoları için Azure Event Grid kullanmanızı öneririz.

  • Olay akışı: Olaylar bir günlüğe yazılır. Olaylar kesinlikle bir parça içinde sıralanır ve kalıcıdır. İstemciler akışa abone olmuyor. Bunun yerine, bir istemci akışın herhangi bir bölümünden okuyabilir. İstemci, akıştaki konumunun ilerletilmesinden sorumludur; bu da bir istemcinin istediği zaman katılabileceği veya olayları yeniden oynatabileceği anlamına gelir. Bu yeniden yürütülebilirlik kurtarma senaryolarını, geç gelen tüketicileri ve bir hata düzeltmesi sonrasında yeniden işlemeyi destekler. Azure Event Hubs yüksek aktarım hızına sahip olay akışı için tasarlanmıştır.

Tüketici tarafında bazı yaygın varyasyonlar vardır:

  • Basit olay işleme: Olay, tüketicide bir eylemi hemen tetikler. Örneğin, Azure İşlevleriEvent Grid tetikleyicisi veya Azure Service Bus tetikleyicisi kullanarak kodunuzun bir ileti yayımlandığında çalıştırılmasını sağlayabilirsiniz.

  • Temel olay bağıntısı: Tüketici birkaç ayrı iş olayını işler, bunları bir tanımlayıcıyla ilişkilendirer ve daha sonraki olayları işlerken kullanmak üzere önceki olaylardan bilgileri kalıcı hale getirmektedir. NServiceBus ve MassTransit gibi kitaplıklar bu düzeni destekler.

  • Complex olay işleme: Tüketici, bir dizi olayı analiz etmek ve olay verilerindeki desenleri tanımlamak için Azure Stream Analytics gibi bir teknoloji kullanır. Örneğin, eklenmiş bir cihazdan okumaları bir zaman aralığı içinde toplayabilir ve hareketli ortalama belirli bir eşiği aşarsa bir bildirim oluşturabilirsiniz.

  • Event akış işleme: Veri akışı platformu olarak, olayları almak ve akış işlemcilerine beslemek için bir işlem hattı şeklinde Azure IoT Hub, Event Hubs veya Event Hubs for Apache Kafka gibi platformları kullanın. Akış işlemcileri akışı işlemek veya dönüştürmek için hareket eder. Uygulamanın farklı alt sistemleri için birden çok akış işlemcisi olabilir. Bu yaklaşım, IoT iş yükleri için uygundur.

Olayların kaynağı, IoT çözümündeki fiziksel cihazlar gibi sistemin dışında olabilir. Bu durumda sistemin, veri kaynağının gerektirdiği birim ve aktarım hızındaki verileri alabilmesi gerekir.

Olay yüklerini yapılandırmak için iki birincil yaklaşım vardır. Olay tüketicileriniz üzerinde denetim sahibi olduğunuzda, her tüketici için yük yapısına karar vekleyebilirsiniz. Bu strateji, tek bir iş yükünde gerektiğinde yaklaşımları karıştırmanıza olanak tanır.

  • Yüke tüm gerekli öznitelikleri ekleyin: Tüketicilerin dış veri kaynağını sorgulamaya gerek kalmadan tüm kullanılabilir bilgilere sahip olmasını istediğinizde bu yaklaşımı kullanın. Daha büyük yükler aktarım maliyetini ve bant genişliği tüketimini artırır ve özellikle güncelleştirmelerden sonra birden çok kayıt sistemi nedeniyle veri tutarlılığı sorunlarına yol açabilir. Sözleşme yönetimi ve sürüm oluşturma da karmaşık hale gelebilir.

  • Yüke yalnızca anahtarları dahil et: Bu yaklaşımda tüketiciler, kalan verilere bir veri kaynağından bağımsız bir şekilde erişebilmek için birincil anahtar gibi gerekli öznitelikleri alır. Bu yöntem, tek bir kayıt sistemine sahip olduğundan daha iyi veri tutarlılığı sağlar. Ancak, tüketicilerin veri kaynağını sık sık sorgulaması gerektiğinden ilk yaklaşımdan daha kötü performansa sahip olabilir. Daha küçük olaylar ve daha basit sözleşmeler karmaşıklığı azalttığı için bağlama, bant genişliği, sözleşme yönetimi veya sürüm oluşturma ile ilgili daha az endişeniz vardır. Daha fazla bilgi için bkz. Etkinliklerinizi bir diyete ekleme.

Yukarıdaki diyagramda, her tüketici türü tek bir kutu olarak gösterilir. Tüketicinin sistemde tek bir hata noktası haline gelmesini önlemek için, bir tüketicinin birden çok örneğine sahip olmak normaldir. Olayların hacmini ve sıklığını işlemek için birden çok örnek de gerekebilir. Tek bir tüketici birden çok iş parçacığındaki olayları işleyebilir. Bu kurulum, olayların sırayla işlenmesi veya tam olarak bir kez semantik gerektirmesi durumunda güçlükler oluşturabilir. Daha fazla bilgi için bkz. Koordinasyonu en aza indirme.

Olay temelli mimarilerde iki birincil topoloji vardır:

  • Aracı topolojisi: Bileşenler, olayları sistemin tamamına yayınlar. Diğer bileşenler olaya tepki verir veya olayı yoksayar. Olay işleme akışı görece basit olduğunda bu topoloji kullanışlıdır. Merkezi koordinasyon veya düzenleme olmadığından bu topoloji dinamik olabilir.

    Bu topoloji, ölçeklenebilirlik, cevap verebilirlik ve bileşen hatalarına karşı dayanıklılık sağlamaya yardımcı olan yüksek seviyede ayrıştırılmıştır. Hiçbir bileşen, çok adımlı bir iş işleminin durumunun sahibi değildir ve bu durumun farkında değildir ve eylemler zaman uyumsuz olarak gerçekleştirilir. Sonuç olarak dağıtılmış işlemler risklidir çünkü bunları yeniden başlatmak veya yeniden oynatmak için yerleşik bir mekanizma yoktur. Bu topoloji bir veri tutarsızlığı kaynağı olabileceğinden hata işlemeyi ve el ile müdahale stratejilerini dikkatle değerlendirmeniz gerekir.

  • Mediator topolojisi: Bu topoloji aracı topolojisinin bazı eksikliklerini giderir. Olayların akışını yöneten ve denetleen bir olay aracı vardır. Olay aracı durumu korur ve hata işleme ve yeniden başlatma özelliklerini yönetir. Aracı topolojisinin aksine, aracı komutları sistemin tamamına yayınlamak yerine belirlenen kanallara gönderir. Bu kanallar genellikle ileti kuyruklarıdır. Tüketicilerin bu komutları işlemesi beklenir.

    Bu topoloji daha fazla denetim, daha iyi dağıtılmış hata işleme ve potansiyel olarak daha iyi veri tutarlılığı sağlar. Bununla birlikte, bu topoloji bileşenler arasında artan bağlantı sağlar ve olay aracısı bir tıkanma noktasına veya güvenilirlik sorununa dönüşebilir.

Bu mimari ne zaman kullanılır?

Aşağıdaki koşullar doğru olduğunda bu mimariyi kullanmalısınız:

  • Birden çok alt sistemin aynı olayları işlemesi gerekir.

  • Minimum zaman gecikmesi ile gerçek zamanlı işleme gereklidir.

  • Zaman pencereleri içinde desen eşleştirme veya toplama gibi karmaşık olay işleme gereklidir.

  • IoT gibi yüksek hacimli ve yüksek hızda veriler gereklidir.

  • Bağımsız ölçeklenebilirlik ve güvenilirlik hedefleri için üreticileri ve tüketicileri ayırmanız gerekir.

Bu mimari aşağıdaki durumlarda uygun olmayabilir:

  • İş yükü, eşzamanlı çağrıların gecikme süresi ve aktarım hızı gereksinimlerinizi karşıladığı basit istek-yanıt iş akışlarına sahiptir. Olay aracılarının işletimsel yükü, zaman uyumsuz hata işleme ve nihai tutarlılık basit etkileşimler için haklı değildir.

  • İş işlemleri, hizmetler arasında güçlü tutarlılık gerektirir. Sistemin farklı bölümlerinin geçerli durum konusunda anlaşamadığı pencereleri tolere edemiyorsanız, olay odaklı mimarinin (EDA) tanıttığı nihai tutarlılık size karşı işe yarar.

  • Ekibinizin dağıtılmış zaman uyumsuz sistemleri çalıştırma deneyimi yok. EDA'nın taleplediği hata ayıklama, izleme ve hata kurtarma desenleri, zaman uyumlu mimarilerdekilerden anlamlı olarak farklıdır ve öğrenme eğrisi teslim zaman çizelgelerini etkiler.

Fayda -ları

Bu mimari aşağıdaki avantajları sağlar:

  • Üreticiler ve tüketiciler birbirinden ayrılmıştır.
  • Noktadan noktaya tümleştirme yoktur. Yeni tüketiciler, üreticileri veya diğer tüketicileri değiştirmeden eklenebilir.
  • Tüketiciler olaylara anında yanıt verebilir.
  • Yüksek oranda ölçeklenebilir, esnek ve dağıtılmıştır.
  • Alt sistemler, olay akışının bağımsız görünümlerine sahiptir.

Zorluklar

  • Garantili teslimat

    Bazı sistemlerde, özellikle IoT senaryolarında olayların teslim edildiklerinden emin olmak çok önemlidir.

  • Nihai tutarlılık

    Üreticiler ve tüketiciler zaman uyumsuz olay kanalları aracılığıyla ayrıştırıldığı için, bir olay yayımlandıktan sonra hizmetler arası veriler hemen tutarlı olmaz. Tüketiciler olayları kendi hızlarında işler ve üreticinin durum değişikliğini yaydığı süre ile tüm tüketicilerin bu değişikliği yansıtması arasında ölçülebilir bir gecikme olabilir. Bu pencere sırasında, sistemin farklı bölümleri geçerli durumun farklı bir görünümüne sahiptir.

    Bu davranış, kasıtlı bir mimari tavizdir. Birçok olay odaklı tasarımda, mimarlar belirli iş akışları için kullanılabilirliği ve bölüm toleransı tercih ederek nihai tutarlılığı bir denge olarak kabul ederken, diğer iş akışları daha güçlü tutarlılığı önceliklendirmeye devam edebilir. Mimarlar, sonuçta tutarlılığın etkin olduğu durumlarda sistemleri ve son kullanıcı okuma işlemlerini, eski veya kısmen güncellenmiş veriyi tolere edecek şekilde tasarlamalıdır. Daha fazla bilgi için bkz. Koordinasyonu en aza indirme.

  • Olayları sırayla veya yalnızca bir kez işleme

    Dayanıklılık ve ölçeklenebilirlik için her tüketici türü genellikle birden çok örnekte çalışır. Olayların bir tüketici türü içinde sırasıyla işlenmesi gerekiyorsa veya bir idempotent mesaj işleme mantığı uygulanmadıysa, birden çok örneğin çalıştırılması zor olabilir.

  • Hizmetler arasında ileti koordinasyonu

    İş süreçlerinde genellikle iş yükünün tamamında tutarlı bir sonuç elde etmek için iletileri yayımlayan ve iletilere abone olan birden çok hizmet bulunur. Çeşitli hizmetlerde ileti akışlarını güvenilir bir şekilde yönetmek için Koreografi ve Saga Orchestration gibi iş akışı desenlerini kullanabilirsiniz.

  • Hata yönetimi

    Olay odaklı mimari öncelikle zaman uyumsuz iletişime dayanır. Zaman uyumsuz iletişimin sunduğu yaygın bir zorluk, hata işlemedir. Bu sorunu çözmenin bir yolu, ayrılmış bir hata işleyici işlemci kullanmaktır.

    Bir olay tüketicisi bir hatayla karşılaştığında, hemen ve zaman uyumsuz olarak sorunlu olayı hata işleyici işlemcisine gönderir ve diğer olayları işlemeye devam eder. Hata işleyici işlemcisi sorunu çözmeye çalışır. Başarılı olursa, hata işleyicisi işlemci olayı özgün alma kanalına yeniden gönderir. Başarısız olursa, işlemci olayı yönetici denetimi için bir ölü harf kuyruğuna (DLQ) gönderebilir. Hata işleyicisi işlemcisi kullandığınızda, tekrar gönderilen olaylar sırasız işlenir.

    Bir iş süreci birden çok hizmete yayıldığında, sonraki bir adım başarısız olursa tamamlanmış adımları mantıksal olarak tersine çevirmek için Telafi İşlemi kullanmayı göz önünde bulundurun.

  • Veri kaybı

    Zaman uyumsuz iletişimin ortaya koyduğunu bir diğer zorluk da veri kaybıdır. Herhangi bir bileşen, olayı başarıyla işleyip bir sonraki bileşene aktarmadan önce kilitlenirse, olay bırakılır ve asla son hedefe ulaşmaz. Veri kaybı olasılığını en aza indirmek için, aktarım aşamasındaki olayları saklayın ve yalnızca bir sonraki bileşen olayın alındığını onayladığında olayları kaldırın veya sıradan çıkarın. Bu özellikler istemci onay modu ve son katılımcı desteği olarak bilinir.

  • Ayrılmış bileşenler arasında gözlemlenebilirlik

    Zaman uyumlu mimarilerde, çağrı yığını aracılığıyla bir isteği izleyebilirsiniz. Olay temelli mimarilerde tek bir iş işlemi, bağımsız ve zaman uyumsuz olarak çalışan birden çok üreticiye, kanala ve tüketiciye yayılabilir. Bir şey başarısız olduğunda veya beklenmedik şekilde davrandığında, paylaşılan çağrı bağlamı olmadığından hangi bileşenin yanlış davrandığını ve neden daha zor olduğunu belirleyin.

    Görünürlüğü korumak için, tüm ardıl tüketicilerin ve günlük sistemlerinin ilgili işlemleri tek bir izleme izi içinde bağlayabilmesi için her olaya bir korelasyon kimliği ekleyin. Bu enstrümantasyonu tasarımın başından itibaren planlayın, çünkü gözlemlenebilirliği bağımsız bir sisteme sonradan uyarlamak, bunu başlangıçta entegre etmekten çok daha zordur.

    Bu karmaşıklık testi de etkiler. Zaman uyumsuz, ayrılmış bileşenler arasında uçtan uca davranışı doğrulamak için zaman uyumlu çağrı zincirlerinden daha kasıtlı test stratejileri gerekir.

  • Geleneksel istek-yanıt deseninin uygulanması

    Bazen olay üreticisi, siparişe devam etmeden önce müşteri uygunluğu elde etmek gibi olay tüketicisinden hemen yanıt almayı gerektirir. Olay odaklı bir mimaride, istek-yanıt mesajlaşması kullanarak zaman uyumlu iletişim elde edebilirsiniz.

    Bu düzen bir istek kuyruğu ve yanıt kuyruğu ile uygulanır. Olay üreticisi, bir istek kuyruğuna asenkron bir istek gönderir, bu görevdeki diğer işlemleri duraklatır ve yanıt kuyruğundan bir yanıt beklentisiyle bekler. Bu yaklaşım, bu düzeni etkili bir şekilde zaman uyumlu bir işleme dönüştürür. Olay tüketicileri daha sonra isteği işler ve yanıtı bir yanıt kuyruğu üzerinden geri gönderir. Bu yaklaşım genellikle izleme için bir oturum kimliği kullanır, böylece olay üreticisi yanıt kuyruğundaki hangi iletinin belirli istekle ilişkili olduğunu bilir. Özgün istek, yanıt kuyruğunun adını (kısa ömürlü olabilir), bir yanıt üst bilgisinde veya karşılıklı olarak üzerinde anlaşmaya varılan başka bir özel öznitelikte de belirtebilir.

  • Uygun olay sayısının bakımı

    Aşırı sayıda ayrıntılı olay oluşturmak sistemi doyurabilir ve bunaltabilir. Aşırı hacimli olaylar, olayların genel akışını etkili bir şekilde çözümlemeyi zorlaştırır. Değişikliklerin geri alınması gerektiğinde bu sorun daha da şiddetlenir. Buna karşılık, olayları fazla birleştirmek de sorun oluşturabilir ve bu da gereksiz işleme ve olay tüketicilerinden gelen yanıtlarla sonuçlanabilir.

    Doğru dengeyi elde etmek için olayların sonuçlarını ve tüketicilerin yanıtlarını belirlemek için olay yüklerini denetlemesi gerekip gerekmediğini göz önünde bulundurun. Örneğin, uyumluluk denetimi bileşeniniz varsa, yalnızca iki tür olay yayımlamak yeterli olabilir: uyumlu ve uyumsuz. Bu yaklaşım, her olayı yalnızca ilgili tüketicilerin işlemesini sağlamaya yardımcı olur ve bu da gereksiz işlemeyi önler.

  • Olay şemasının evrimi

    Üreticiler ve tüketiciler bağımsız olarak dağıtılır, bu nedenle tümünü aynı anda güncelleştiremezsiniz. Üretici bir olayın yapısını değiştirdiğinde, henüz yeni şemayı anlamayan tüketiciler sorun yaşayabilir. Başlangıçta bir şema sürümleme stratejisi belirleyin ve tüketicileri tanımadıkları olay sürümlerini işleyecek şekilde tasarlayın.

Dikkat edilecek diğer noktalar

  • İstek yalnızca istek işleme bileşeni tarafından görülebilir. Ancak bu bileşenler bunları kullanmasa veya kullanma amacı taşımasa bile olaylar genellikle bir iş yükündeki birden çok bileşen tarafından görülebilir. "İhlal varsay" zihniyetiyle çalışmak için, istenmeyen bilgilerin açığa çıkmasını önlemek için olaylara hangi bilgileri dahil ettiğinize dikkat edin.

  • Birçok uygulama birincil mimari olarak olay odaklı mimari kullanır. Karma mimari oluşturmak için bu yaklaşımı diğer mimari stilleriyle birleştirebilirsiniz. Tipik birleşimler mikro hizmetleri, kanalları ve filtreleri veolay kaynağını belirlemeyi içerir. Yüksek istek hacimleri sırasında darboğazları ortadan kaldırmak ve geri baskı sağlamak için, sistem performansını artıracak olay bazlı bir mimariyi entegre edin.

  • Belirli etki alanları genellikle birden çok olay üreticisine, tüketiciye veya olay kanalına yayılabilir. Belirli bir etki alanındaki değişiklikler birçok bileşeni etkileyebilir.

Sonraki adım

Zaman uyumsuz mesajlaşma seçenekleri

  • Last updated on