Olay denetimli mimari, bir olay akışı oluşturan olay üreticilerinden ve olayları dinleyen olay tüketicilerinden oluşur.
Olaylar gerçek zamanlıya yakın şekilde sunulur; böylece tüketiciler, olaylar gerçekleştiği anda bunları yanıtlayabilir. Üreticiler tüketicilerden ayrılmıştır; üretici hangi tüketicilerin dinlediğini bilmez. Tüketiciler aynı zamanda birbirinden de ayrılmıştır ve her tüketici, olayların tümünü görür. Bu, tüketicilerin bir kuyruktan ileti çektiği ve bir iletinin (hata olmadığı kabul edilerek) yalnızca bir kez işlendiği Rakip Tüketiciler düzeninden farklıdır. IoT gibi bazı sistemlerde olayların çok yüksek hacimlerde alınması gerekir.
Olay odaklı mimari yayımlama/abone olma (pub/sub olarak da adlandırılır) modeli veya olay akışı modeli kullanabilir.
Yayımlama/abonelik: Mesajlaşma altyapısı, abonelikleri takip eder. Bir olay yayımlandığında her aboneye gönderilir. Bir olay alındıktan sonra yeniden oynatılamaz ve yeni aboneler olayı görmez.
Olay akışı: Olaylar bir günlüğe yazılır. Olaylar tamamen sıralı (bir bölümün içinde) ve süreklidir. İstemciler akışa abone olmaz, bunun yerine akışın herhangi bir kısmını okuyabilir. İstemci, akıştaki konumunu ilerletmekten sorumludur. Bu, istemcinin herhangi bir noktada akışa katılıp olayları yeniden yürütebileceği anlamına gelir.
Tüketici tarafında sıklıkla karşılaşılan bazı değişkenlikler söz konusudur:
Basit olay işleme. Bir olay, tüketicide hemen bir eylemi tetikler. Örneğin, bir işlevin, Service Bus konu başlığında gerçekleşen her ileti yayımlanma işleminde yürütülmesi için bir Service Bus tetikleyicisi ile Azure İşlevleri’ni kullanabilirsiniz.
Temel olay bağıntısı. Tüketicinin, genellikle bazı tanımlayıcılar ile bağıntılı olan ve daha sonraki olayları işlerken kullanmak üzere önceki olaylardan bazı bilgileri kalıcı hale getirerek az sayıda ayrık iş olayını işlemesi gerekir. Bu desen NServiceBus ve MassTransit gibi kitaplıklar tarafından desteklenir.
Karmaşık olay işleme. Tüketici, Azure Stream Analytics gibi bir teknoloji kullanarak olay verilerindeki desenleri arayan bir dizi olayı işler. Örneğin, bir zaman penceresi üzerinde tümleşik bir cihazdan okumaları toplayabilir ve hareketli ortalamanın belirli bir eşiği aşması durumunda bildirim oluşturabilirsiniz.
Olay akışı işleme. Olayları alıp akış işlemcilerine sağlamak için ardışık düzen olarak Azure IoT Hub veya Apache Kafka gibi bir veri akışı platformu kullanın. Akış işlemcileri akışı işleme veya dönüştürme işlevi görür. Uygulamanın farklı alt sistemlerine yönelik birden çok akış işlemcisi olabilir. Bu yaklaşım, IoT iş yüklerine uygundur.
Olayların kaynağı, bir IoT çözümündeki fiziksel cihazlar gibi sistemin dışında olabilir. Bu durumda sistemin, verileri veri kaynağı için gereken hacimde ve aktarım hızında alabilmesi gerekir.
Yukarıdaki mantıksal diyagramda her bir tüketici türü tek bir kutu olarak gösterilir. Tüketicinin sistemdeki tek hata noktası haline gelmesini önlemek için bir tüketicinin birden çok örneğini bulundurmak sıklıkla uygulanan bir yöntemdir. Olayların hacminin ve sıklığının işlenmesi için de birden çok örnek gerekebilir. Ayrıca tek bir tüketici de birden çok iş parçacığında olayları işleyebilir. Bu, olayların sırayla işlenmesi veya tam olarak bir kez semantik gerektirmesi durumunda zorluklara neden olabilir. Bkz. Koordinasyon Gereksinimini Olabildiğince Azaltma.
Bu mimarinin kullanılacağı durumlar
- Aynı olayları birden çok alt sistemin işlemesi gerekir.
- En az zaman gecikmesi ile gerçek zamanlı işleme.
- Zaman pencereleri üzerinde düzen eşleştirme veya toplama gibi karmaşık olay işleme.
- IoT gibi yüksek hacimli ve yüksek hızlı veriler.
Sosyal haklar
- Üreticiler ve tüketiciler birbirinden ayrılmıştır.
- Noktadan noktaya tümleştirme yok. Sisteme yeni tüketici eklemek kolaydır.
- Tüketiciler, olaylar ulaştığı anda bunları yanıtlayabilir.
- Yüksek oranda ölçeklenebilir ve dağıtılmış.
- Alt sistemler, olay akışının bağımsız görünümlerine sahiptir.
Zorluklar
- Garantili teslim. IoT senaryoları başta olmak üzere bazı sistemlerde olayların teslim edileceğinin garanti altına alınması kritik önem taşır.
- Olayları sıralı olarak veya kesinlikle bir kerelik işleme. Her bir tüketici türü, esneklik ve ölçeklenebilirlik için genellikle birden çok örnek üzerinde çalışır. Olayların sırayla işlenmesi gerekiyorsa (bir tüketici türü içinde) veya bir kez etkili ileti işleme mantığı uygulanmadıysa bu bir zorluk oluşturabilir.
- Hizmetler arasında iletileri koordine etme. İş süreçleri genellikle tüm iş yükünde tutarlı bir sonuç elde etmek için birden çok hizmetin iletilere yayımlanmasını ve abone olmasını içerir. Koreografi deseni ve Saga Orchestration gibi iş akışı desenleri, çeşitli hizmetlerde ileti akışlarını güvenilir bir şekilde yönetmek için kullanılabilir.
Dikkat edilecek diğer noktalar
- Bir olaya dahil edilecek veri miktarı, hem performansı hem de maliyeti etkileyen önemli bir nokta olabilir. İşleme için gereken tüm bilgileri olayın kendisine yerleştirmek, işleme kodunu basitleştirebilir ve ek aramaları kaydedebilir. Bir olaya yalnızca birkaç tanımlayıcı gibi minimum miktarda bilgi eklemek aktarım süresini ve maliyetini azaltır, ancak işleme kodunun ihtiyaç duyduğu ek bilgileri aramasını gerektirir. Bu konuda daha fazla bilgi için bu blog gönderisini inceleyin.
- İstek yalnızca istek işleme bileşeni tarafından görünür olsa da, bu bileşenler bunları kullanmasa veya kullanmasa bile olaylar genellikle iş yükündeki birden çok bileşene görünür. "İhlal varsay" zihniyetiyle çalışırken, istenmeyen bilgilerin açığa çıkmasını önlemek için olaylara hangi bilgileri dahil ettiğinize dikkat edin.