MessageQueue kullanmayan uygulamalar ve servisler arası iletişimlerde genel olarak iki component birbirine tightly coupled olarak bağlıdır. Bir servis bir diğerine mesajını gönderir ve cevap bekler. Hatta diğer servis down vaziyette ise ya işlemler durur, ya patlar ya da servis tekrar tekrar bu mesajı göndermeye çalışır. Ancak queue mekanizmalarında servisler queue’ya ilgili mesajını ilettikten sonra yapması gereken işlemleri kaldığı yerden yapmaya devam eder. Yani async bir yapısı vardır. Bu da genel yapıyı decoupled bir hale getirir.
Decoupled Sistemler Oluşturma
Queue mekanizması ile kurgulanan dağıtık bir yapıda, servisler tamamen loose coupling olarak kurgulanmıştır. Bir servis diğer servisin varlığından haberdar bile değildir. Yalnızca event router rabbitmq için Exchange, queuenın varlığından haberdardırlar.
Referencially Decoupled Sistemler Oluşturma
Event based mimari ile kurgulanan dağıtık yapılar bir önceki maddede de bahsettiğim gibi, birbirlerinden değil yalnızca merkezde bulunan queuedan haberdardırlar dolayısıyla birbirleriyle ilgili bir referans end point vs bilgisine ihtiyaç duymazlar. Bu sebeple referencially decoupled yapıdadır diyebiliriz.
Temporally Decoupled Sistemler Oluşturma
Aslında temporally coupling kavramı bir derece fault tolerance ile ilişkilidir. Event based mimarilerde consumer servis bir sebepten down olduğunda, consume etmesi gereken event queueda bekler. Ne zaman ki down olan servis tekrar ayağa kalkar, event consume edilebilir. Dolayısıyla event base kurgulanan mimari için temporally decoupled diyebiliriz.
Scalable Sistemler Oluşturma
RabbitMq üzerinden gidecek olursak, rabbitmq ile oluşturduğunuz sistemlerde, sistem ağır yük altındaysa bunu 2 şekidle scale edebilirsiniz. Birincisi scale in yaparak yani mevcut makinanın donanımını (CPU,Ram vs) güçlendirerek. İkincisi ise consumer’ı ölçekleyerek. Bunu da bir örnekle açıklayacak olursak, diyelim ki checkout ve inventory adında iki servisimiz olsun ve bu servisler messagequeue üzerinden iletişim kursunlar ve bir anlığına üretilen checkout sayısının arttığını varsayalım. Bu durumda queue dolmaya başlar. Burada normal request based iletişime kıyasla farklı olarak, clientımızı yani inventory servisi scale edip queuedan çok daha hızlı ve fazla message consume etmesini sağlayabilirz ki bu da bizim sistemimizi çok daha scalable yapar.
Performans
Queuelar kendi makinalarında durur. Bu da web applicationun yapacağı iş yükünün bir kısmının devredilmesini sağlar.
Reliabliity
RabbitMQ persistence, delivery acknowledgements, publisher confirms, vehigh availability dahil olmak üzere, performansı değiş tokuş etmenize izin veren çeşitli özellikler sunar.
Exchange Type’lar
RabbitMq içerdiği exchange typelar ile mesajın iletilmesinde büyük esneklikler sağlar.
High Availibility
Rabbitmq mirroring queue özelliği sayesinde cluster içerisinde queuelarınızın mirror queuelarını oluşturarak herhangi bir failure durumda dahi mesajınızın güvende olmasını sağlar.
Fault Tolerance System Oluşturma
Temporally coupling konseptinde de bahsettiğim gibi, eğer servislerden biri down olursa eventler queueda durmaya devam eder ve her nezaman down olan servis ayağa kalkar sistem kaldığı yerden işlemeye devam eder.
Çoklu Dil Desteği
Message queue ile geliştirdiğiniz projeleriniz bir çok dil ile entegre olabilir dolayısıyla consumer’larınız farklı farklı dillerden olabilir.
Latency
Event based mimariler asenktron yapıda olduklarından, event fırlatıldığı ya da consume edildiği sırada latency yoktur.
Bunlar dışında rabbitmq bize düşük network trafiği network trafiği user friendly bir management UI, message tracing ve çeşitli plug-inler ile bir çok özellik sunar.