RabbitMQ ne işe yarar? Nedir bu RabbitMQ?

Yazılım dünyası genişledikçe teknolojiler ve buna bağlı mimariler de artıyor. Başta her şeyin tek bir server’a sıkıştırılarak başlanılan monolitik yapılardan günümüzde popülerliğini koruyan soyutlamanın en son katmanı mikro servisleri konuşuyoruz. Herkesin idealinde olan “aslında mikro servis olarak kurgulamalıyız” düşüncesi gittikçe yaklaşmaya ve gerçekleşmeye başlıyor 🙂 Bugün hep beraber mikro servis evreni olmak üzere servisler ve sistemler arası iletişimde baş rol oynayan message broker’lardan birisi olan RabbitMQ üzerine odaklanacağız. Hadi hep beraber bakalım RabbitMQ ne işe yarar?

Nasıl başladık?

Eskilerde her şey tek bir server’daydı. Database hemen dibimizde, her şey birbiri ile sıkı sıkıya bağlıydı. İhtiyacımız olduğunda server’ı dikey olarak büyütmekten başka çaremiz yoktu. Zamanla her şeyin tek bir odaya sıkıştırılmaması gerektiği, bunların birbirinden bağımsız ve daha özgür olması gerektiğine karar verdik. Ama özgürleştirmek ve bağımsız hâle getirmek üzerine ne kadar odaklanırsak, o kadar da büyük bir iletişim ağı kurmak, iş gücü, insan kaynağı ve fiziksel kaynaklar gerekiyordu.

Network ve iletişim dediğimizde aklınıza ne gelir?

Tabii ki HTTP request’ler gelmeli. Web dünyasının baştan sona bu kadar büyümesini sağlayan en büyük faktör. Client’dan gelen isteklerin server’lara ulaşmasını, bunların belli standartlar hâlinde yürütülmesini, güvenliğinin sağlanmasını ve bağlantıların stable olmasını sağladı. Ancak konumuz server’lar arası iletişim ve bu iletişimin hızlı olmasının yanı sıra iki tarafı da meşgul etmemesi olunca alternatif arayışına girdik. Her yaptığımız HTTP request bize hand shake’ler, kontroller, güvenlik protokolleri, iki server’ın veya sistemin de meşgul olmasına neden oluyordu. Artık yük dağıtılmalı ve iletişim sırasında iki servis de meşgul olmamalıydı.

RabbitMQ Sahnede. RabbitMQ nasıl iletişimi sağlar?

İki servis üzerinden gittik hep artık bunu daha somut hâle getirmekte fayda var. İşte şimdi RabbitMQ ne işe yarar üzerine odaklanalım. Bu servislerden birinin sipariş alma servisi, diğerinin de envanter servisi olduğunu farz edelim. Sipariş alma servisi aldığı siparişleri envanter servisine devretmeli ve eğer envanter servisi bu siparişin mümkün olduğunu doğrularsa envanterdeki güncellemeleri yaptıktan sonra sipariş alma servisine bildirmeli.

Sipariş aldığımızı düşünelim. İlk başta bununla ilgilenen servisimiz kontrollerini yaptıktan sonra direkt olarak envanter servisi ile iletişim kurmak yerine “envater servisi ile bağlantılı” bir işi olduğunu beyan edercesine RabbitMQ’a mesaj gönderir. RabbitMQ bunları kendi içerisinde kuyrukta tutar. Envanter servisi de müsait olduğu anlarda RabbitMQ’a işlem alabileceğini bildirir ve kendisine gelen mesajları okur, işler ve yürütür. Ardından okunan her mesaj RabbitMQ’dan silinir.

Ne kazandık?

Dikkat ettiğiniz üzere sipariş alma servisi, kendisine gelen talebi işledikten sonra tüm yükümlülüğü RabbitMQ’ya devretti ve kendisi ile ilgili bağlantılı bir şey kalmadı. Envanter servisi, RabbitMQ ile müsait olduğu anlarda çalıştı ve ondan gelen mesajları da tek tek işledi. Böylece iki servis de birbirinden bağımsız, scale olabilecek şekilde ve özgürce hareket etti. İki servis birbirinden decouple olmuş oldu ve bunun yanında kaynaklarını da iletişimi yönetmek yerine sadece kendilerine özel işler için harcamış oldular. Artık iki servisi de birbirlerinden bağımsız şekilde yönetebiliyor, kaynaklarını istersek arttırabiliyor, istersek azaltabiliyor, istersek de iletişim sürecindeki kesintilerden etkilenmeden çalışmasını sağlıyoruz.

İyi güzel de cevap beklemem gerektiğinde ne olacak?

Bunu yazıyı baştan sonra okurken dediğinizi duyar gibiyim. Evet, en kritik nokta burası. Örneğimizden devam ederek burayı da sizlere açıklamak istiyorum. En son envanter servisi RabbitMQ’dan mesajı okuyup, işlemiş ve yürütmüştü. Ardından bunu bir şekilde sipariş alma servisine bildirmesi gerektiğini düşünelim. Tam bu evrede aslında başta yaptığımızı yapacağız. RabbitMQ’ya “sipariş alma servisi” ile ilgili olduğunu belirttiğimiz bir mesaj ileterek onun yürütmesi gereken bir iş olduğunu beyan edeceğiz. Böylece tüm iletişim süreci birbirini bloklamadan sağlıklı şekilde yürütülebilecek.

Eğer çok fazla monolitik yapılarda çalıştıysanız bu durumun sizin kafanızdaki ile farklı olması çok doğal. Tüm mimarinizin tekrardan ele alınarak iletişimin servisleri decouple, scalable ve performant hâle getirecek şekilde kurgulanmasını sağlamalıyız. Bu da tüm yapının bloklanmadan inşa edilmesi anlamına geliyor.

Yazımı okuduğunuz için teşekkür ederim. RabbitMQ ne işe yarar?, mimariyi nasıl daha scalable yaparım ve servisleri nasıl decouple ederim sorularına cevap aradık. Eviction nedir başlıklı yazıma da göz atabilirsiniz.