Olay odaklı mimari, olay akışı oluşturan olay üreticilerinden, bu olayları dinleyen olay tüketicilerinden ve üreticilerden tüketicilere olay aktaran olay kanallarından 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.
Birçok olay temelli mimaride iki birincil topoloji vardır:
Aracı topolojisi. Bileşenler oluşumları tüm sisteme olay olarak yayınlar ve diğer bileşenler olay üzerinde işlem görür veya yalnızca 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 çok dinamik olabilir. Bu topoloji, ölçeklenebilirlik, yanıt verme hızı ve bileşen hataya dayanıklılık sağlamaya yardımcı olan yüksek oranda ayrılmıştır. Hiçbir bileşen, çok adımlı bir iş işleminin durumunun sahibi değildir veya bu durumun farkında değildir ve eylemler zaman uyumsuz olarak gerçekleştirilemez. Daha sonra, yeniden başlatılacak veya yeniden yürütülecek yerel bir araç olmadığından dağıtılmış işlemler risklidir. Bu topoloji bir veri tutarsızlığı kaynağı olabileceğinden hata işleme ve el ile müdahale stratejilerinin dikkatli bir şekilde dikkate alınması 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ı topolojisi aksine, bileşenler oluşumları komut olarak yayınlar ve genellikle ileti kuyrukları olmak üzere yalnızca belirlenen kanallara yayınlar. Bu komutların tüketicileri tarafından yoksayılması beklenmiyor. Bu topoloji daha fazla denetim, daha iyi dağıtılmış hata işleme ve potansiyel olarak daha iyi veri tutarlılığı sunar. Bu topoloji bileşenler arasında daha fazla kavramaya neden olur ve olay aracısı bir performans sorununa veya güvenilirlik sorununa neden olabilir.
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, esnek 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.
Hata işleme.
Olay odaklı mimaride çoğunlukla zaman uyumsuz iletişim kullanılır. Zaman uyumsuz iletişimle ilgili bir zorluk, hata işlemedir. Bu sorunu gidermenin bir yolu ayrı bir hata işleyici işlemci kullanmaktır. Bu nedenle, olay tüketicisi bir hatayla karşılaştığında hemen ve zaman uyumsuz olarak hatalı olayı hata işleyici işlemcisine gönderir ve devam eder. Hata işleyici işlemcisi hatayı düzeltmeye çalışır ve olayı özgün alma kanalına geri gönderir. Ancak hata işleyici işlemcisi başarısız olursa, hatalı olayı daha fazla inceleme için bir yöneticiye gönderebilir. Hata işleyicisi işlemcisi kullanırsanız, hatalı olaylar yeniden gönderildiklerinde sıra dışı olarak işlenir.
Veri kaybı.
Zaman uyumsuz iletişimin bir diğer zorluğu da veri kaybıdır. Bileşenlerden herhangi biri başarıyla işlenmeden ve olayı sonraki bileşenine teslim etmeden önce kilitlenirse, olay bırakılır ve hiçbir zaman son hedefe yapmaz. Veri kaybı olasılığını en aza indirmek için, aktarım içi olayları kalıcı hale getirmek ve yalnızca bir sonraki bileşen olayın alındığını onayladığında olayları kaldırın veya sırasını kaldırın. Bu özellikler genellikle istemci onay modu ve son katılımcı desteği olarak bilinir.
Geleneksel bir istek-yanıt deseni uygulama.
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ı mimaride, istek-yanıt mesajlaşması aracılığıyla zaman uyumlu iletişim elde edilebilir.
Bu düzen genellikle birden çok kuyruk kullanılarak uygulanır: istek kuyruğu ve yanıt kuyruğu. Olay üreticisi bir istek kuyruğuna zaman uyumsuz istek gönderir, bu görevdeki diğer işlemleri duraklatır ve yanıt kuyruğunda bir yanıt bekler; bunu etkili bir şekilde zaman uyumlu bir işleme dönüştürüyor. 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 üst bilgisinde veya karşılıklı olarak üzerinde anlaşmaya varılan başka bir özel öznitelikte yanıt kuyruğunun adını (kısa ömürlü olabilir) de belirtebilir.
Uygun olay sayısını koruma.
Aşırı sayıda ayrıntılı olay oluşturmak sistemi doyurabilir ve bunaltabilir, böylece olayların genel akışını etkili bir şekilde analiz etmek zorlaşır. Değişikliklerin geri alınması gerektiğinde bu sorun daha da şiddetlenir. Buna karşılık, olayları fazla birleştirmek de sorunlara neden olabilir 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, bir uyumluluk denetimi bileşeniniz varsa, yalnızca iki tür olay yayımlamak yeterli olabilir: uyumlu ve uyumsuz. Bu yaklaşım, her olayın yalnızca ilgili tüketiciler tarafından işlenmesini sağlar ve gereksiz işlemeyi önler.
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.
- Birçok uygulama birincil mimari olarak olay odaklı mimari kullanır; ancak bu yaklaşım diğer mimari stilleriyle birleştirilerek karma mimariler elde edilebilir. Yaygın birleşimler mikro hizmetler, kanallar ve filtrelerdir. Olay odaklı mimarinin tümleştirilmesi, performans sorunlarını ortadan kaldırarak ve yüksek istek hacimleri sırasında geri baskı sağlayarak sistem performansını artırır.
- 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.