Azure Service Bus: Topic Subscription

Azure üzerinde ServiceBus adında bir hizmet olduğunu duymuşunuzdur diye tahmin ediyorum. Aslında Serbice Bus oldukça geniş ve çok işlevli bir konu ben bu yazıda sadece Topic & Subscription bölümünü kısaca özetleyeceğim.

   

Bu arada service bus sadace Azure üzerinde olan bir hizmet değil, kendi on-prem serveriniz üzerine kurup kullanabilirsiniz. Private cloud kavramıyla bu konuyuda inceleyebilirsiniz. Deneme fırsatım oldu, oldukca kolay bir kurulumu var.

   

Topic Nedir?

Sonuç olarak ingilizce bir terimden bahsediyoruz ve türkçesini düşünecek olursak: "KONU".

   

Subscription Nedir?

Aynı mantık ile üyelik diye biliriz.

   

Peki nedir bunlar? Konu çok basit aslında. Bir Topic olduğunu düşünün ve adı "Günlük Haberler" olsun. Birde subscriber olsun, ve bu topic'e subscribe olsun. Yani örneğin subscriber "Günlük Haberler" topic'ine üye oldu. Bu sayede "Günlük Haberler" topic'i içine giren her mesajdan subscriber haberdar olacaktır ve topic'e konulan mesajları okuyabilecektir.

   

Bir yada birden fazla üreticimiz var, topic'lerin içerisinde BrokeredMessage koyuyorlar.

Bir yada birden fazla subscriber(üye ?)'imiz var bunlarda topic'leri takip ediyor ve topic içine konulan mesajları okuyorlar konu bukadar basit.

   

Bahsettimiz işler Queue ilede yapılabilir mi? Şimdiye kadar evet diyebiliriz. Ancak Topic & Subscription mekanizmasında Topic ve Subscriptionlar var. Topic içine konulan her mesaj, belirlenen Topic'e subscribe etmiş tüm subscriberlara iletilmeyi garantiler. Queue'da ise mesaj queue'ya girer ve ilk alan consumer'in elinde kalır, ikinci vb. consumerlar o mesaja ulaşamazlar. Ama Subscription'da Topic'e giren her mesaj tüm subscriberlara iletilmeyi garanti eder.

   

Filtre

Subscriber topic'e subscribe olurken hangi mesajları almak istediğini filtreleyebilir. Bu işi şu şekilde yaparız, gelen mesajın propertylerinden biri veya bir kaçı belirtilen değerlerde ise mesaj ulaşsın. Bu yapı için SqlFilter class'indan yaralanıyoruz.

   

Connection String (config dosyasında olmalı)

   

<ConfigurationSettings>
<Setting name="Microsoft.ServiceBus.ConnectionString" value="Endpoint=sb://[SERVICEBUSNAME].servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedSecretValue=KEY" />
</ConfigurationSettings>

   

Yeni Topic Yaratmak, C#

   

Topic'i Silmek, C#

   

Mesaj Göndermek, C#

   

Subscription Oluşturmak ve Mesajı Okumak

   

Receive methodu ile mesajları alabilirsiniz. Eğer geri dönen instance null ise topic içerisinde mesaj olmadığını anlayabilirsiniz.

   

   

   

OnMessage, C#

OnMessage() methodu ile yukarida kurduğumuz yapının otomatik olarak oluşmasını sağlayabilirsiniz ve verdiğiniz action mesaj geldiğinde çalışır. Böylece sizin while() gibi bir loop ile kontrol etmenize gerek kalmaz, mesaj geldiğinde verdiğiniz action call edilir.

   

   

   

Daha detaylı bilgi için,

   

http://azure.microsoft.com/en-us/documentation/articles/service-bus-dotnet-how-to-use-topics-subscriptions/#configuring-your-connection-string-when-using-websites-or-virtual-machines

   

http://www.4sln.com/Articles/microsoft-azure-service-bus-queue-topic-subscription

Azure Storage - Queue Nedir?

   

Azure Storage servisleri içerisinde Queue, Blob, Table, File(preview) gibi farklı depolama seçenekleri var, ben bu post'ta Queue'ya değineceğim.

Nedir bu Queue?

Queue, türkçede kuyruk.

Bilgisayar mühendisliği veya benzeri bölümler okuyan arkadaşların iyi hatırlayacağı üzere queue(kuyruk) bir abstract data type (ADT), aslında bakarsanız Azure üzerinde kuyruk kullanmak o derste öğretilen kadar zor ve karmaşık değil.

   

Yukarıdaki resim MSDN'den aldığım bir image ve bence kuyruğu en iyi ifade eden görsellerden biri.

Öncelikle bileşenleri tanıtıyım,

  • Solda görmüş olduğunuz Web Role -> bildiğiniz web sitesi
  • Orta ve aşağıdaki Windows Azure Queue -> türkçesi kuyruk, bu arkadaşın nasıl çalıştığını anlamaya çalışıyoruz.
  • Sağdaki Worker Role -> basit olarak anlatmak gerekirse sürekli çalışan bir program.

   

Yukarıdaki görselde gördüğünüz gibi kuyruğa sürekli web sitesi tarafından bir şeyler ekleniyor ve worker role bunları okuyup işliyor. Tam olarak üniversitelerde öğrenmiş olduğumuz kuyruk yapısı gibi "FIFO" first-in-first-out çalışmıyor aslına bakarsanız. Buna daha sonra değiniriz.

   

Örnek senaryo

Bir e ticaret sitemiz olduğunu düşünelim ve kullanıcı ödeme işlemenini yaptıktan sonra 3 farklı işlem yapılması gerektiğini düşünelim.

  • Satış stok takip programına işlenmeli
  • Kargo firmasının api'lari ile işlem yapılmalı
  • Kullanıcıya mail atılmalı

Bu işlemlerin hepsi kullanıcı ödemesini tamamladıktan sonra yapılmalı. Baktığımızda bu işi buton'a basıldığında yapabiliriz diye düşünebiliriz ancak gerçekte iş biraz daha karışık. Butona basıldığı anda bu kadar işi bir anda yaparsanız kullanıcı cok fazla bekler belkide request timeout olur. Bu işlemlerden bazıları o anda teknik sebeplerden ötürü yapılamaya bilir ve sizin bir retry logic kurmanız gerebilir. Bu konuların hepsinden kaçınıp kuyruk kullanarak bu senaryoyu başarabiliriz.

Nasıl yapmalıyız?

Kullanıcı ödeme işlemini tamamladığından bu satış işleminin identifier'ini web sitesi kuyruğa koyar. Worker role bu kuyruğu sürekli kontrol eder ve satış bilgisi geldiği anda yukarıdaki 3 adımı sırası ile gerçekleştirir. Eğer bir hata oluşursa otomatik olarak kuyruğa tekrar ekler ve ilerleyen zamanlarda tekrar dener.

   

Dizayn olarak bakacak olursak, bu yapıyı kullanarak sistemlerimizi birbirinden bağımsız hale getirirerek daha iyi bir mimari dizayn ortaya koyabiliriz. Örneğin bizim birden çok e ticaret sitemiz var ancak hepsi için az önce yukarıda anlattığımız senaryo aynı, bütün siteler tek depo ile çalışıyor ve aynı kargo firması ile çalışıyor. Bu durumda farklı web sitelerimiz aynı kuyruğa mesaj koyabilir ancak okuyacak worker role bunların nereden geldiğini önemsemeden alır ve işler böylece sistemimiz daha güzel bir mimariye sahip olmuş olur. Sistemin bileşenleri arasında bağımlılık en aza indirilmiş olur. Keyword: decoupling

   

Azure Queue'da mesaj aynı anda sadece bir alıcıya ulaşır. Yani eğer sizin iki tane worker role'unuz var ve aynı kuyrugu kontrol ediyorsa bunlardan biri mesajı alır ve diger alamaz. Birbirlerinden mesajları çalarak ilerlerler. Eğer sisteminizde bir worker role yetmiyorsa ikinci worker role'u eklerseniz sisteminizin çalışma hızı yaklaşık 2 ye katlanmış olur. Eğer mesajların aynı anda iki worker role'ede iletilmesini istiyorsanız Service Bus'ı kullanmayı düşünmelisiniz.