Mikroservis + RabbitMQ uygulaması - 1

Mikroservisler dünyasına spring cloud ile giriş yapan bir uygulamayı ilk yazı dizisinde yazmış ve detaylarını anlatmıştım. Bu yazı dizisine başlamadan önce ilkinin üzerinden geçmeniz gerekecek çünkü hal-ü hazırda yaptığım mikroservis mimaririsinin üzerine RabbitMQ ile message queue yapısını getireceğim. Çünkü bir message queue aracını en etkili ve anlaşılır şekilde kullanmanın yolu genellikle mikroservis mimarisinin bir parçası olarak kullanmak oluyor. Bu yazı dizisinde RabbitMQ kullanarak sıfırdan bir mikroservis yazmayacağız. Var olan projenin üzerine nasıl entegre edilebildiğine ve bu sayede elde ettiğimiz kazanımlara bakarak analizler yapacağız. Bu yazı dizisi aşağıdaki gibi 5 parçadan oluşacak.

• Tanıtım (Bu yazı)
  • Message queue ve message broker nedir
  • Hangi aracı kullandık, nedenlerimiz nedir
  • Üzerine kurgulanan mikroservis projesi nasıldır

• RabbitMQ
  • RabbitMQ nedir, artıları ve eksileri nelerdir
  • Önemli özellikleri nedir
  • Yük dengeleme ve hata yakalama nasıl yönetilebilir
  • Exchange türleri nelerdir
  • Alternatifleri nelerdir

• Mesaj gönderici metodlar
  • Spring AMQP ile mesaj gönderimi nasıl yapılır
  • Konfigürasyonlar nasıl yapılabilir
  • RabbitMQ yönetim ekranı nasıl kullanılır

• Mesaj alıcı metodlar
  • Sisteme mail servisinin eklenmesi
  • RabbitListener ile Payload nasıl alınır
  • Deadletter queue nasıl kurgulanabilir

• Message queue yapısının analizi
  • Nasıl kullandık, nasıl kullanabilirdik
  • Olası sorun senaryoları nelerdir
  • Sorunlara karşı nasıl önlem alınabilir

Message queue ve message broker nedir

Daha önce ayağa kaldırdığım mikroservis yapısı SAGA tabanlı orkestrasyon ile çalışıyordu. Yani bir MVC uygulaması küçük servislere istekler yapıyor ve dönen cevaplara göre belli transaction 'ları yönetiyordu. Bütün bu işlemler ise senkron request ve response 'lar ile yapılıyordu. Bunun gibi sistemlerde seknron olarak cevap alınma şartı olmayan işlemler de gerçekleştirilebilmektedir. Örneğin bir e-mail veya rapor gönderme işlemleri, birçok kere çalışması gereken ve geri dönüşü beklenmeyen işlemler olabilir. Özetle bir sistemin parçaları arasında genellikle asenkron olarak yapılan etkileşimler bir mesaj yapısı ile gerçekleştirilir ve bu mesajlar bir kuyruğa atılarak sırası ile işlenebilir.

Sistemin küçük parçaları birbirlerine mesajlar gönderir veya merkezi koordinatör küçük servislerle mesajlar ile iletişim kurabilir. Hatta bu mesajların belli koşullara göre farklı alıcılara ulaşması da gerekebilir. Bütün bu parçalar arasında bağlantılar olması ve bunların bir makarna gibi bir karmaşa oluşturması yönetilebilir olmayacaktır. Bu yüzden bu mesajları gerekli yerlere iletebilen bir aracı yani message broker kullanırız. Bu aracılar ise kendilerine sürekli gelen mesajları diğerlerine iletebilmek için bunları sıraya koyar ve bazı ekstra işlemleri de yapar. Bu yapılar da queue olarak adlandırılır. Günümüzde message broker olarak çalışan araçların hepsinin temelinde bu yaklaşım bulunmakta ve üzerine ekstra yetenekler eklenmektedir.

Hangi aracı kullandık, nedenlerimiz nedir

Varolan mikroservis projesinin üzerine message broker olarak RabbitMQ entegre edeceğiz. Burada şu şekilde bir karar süreci oldu, ki bu aracı daha sonra değiştirmek son derece zor olacağı için karar aşaması epeyce önemli. Öncelikle message broker araçları alternatiflerini araştırdım. Bu konuda sadece ismen duyduğum birkaç tanesini biliyordum fakat detayları bilmeden bir karar vermek doğru olmazdı. İnternette message broker 'ların özelliklerini, güncel durumlarını ve use case 'lerini karşılaştıran bloglar veya yazılar buldum. Bu karşılaştırmalarda open source olarak en mantıklı çözüm RabbitMQ oldu.

Çünkü yaklaşık 2010 yılından beri gelişiyor ve sayıca çok çeşitli özellikleri bulunuyor. Burada not olarak belirteyim. Tek başına bir çok işin üstesinden gelebilidiği için araştırmalarımda eski kaynaklarda farklı kullanımlarını da gördüm. Bu da kafa karıştırıcı oluyor. Tabi ki güncel dökümantasyona da göz atınca karmaşa biraz azaldı. Fark ettim ki zaman içerisinde spring cloud ve miroservislerin gelişmesi ile beraber load balance, resiliency ve fault tolerance gibi kavramlar için de özellikler eklenmiş. Bu noktada bir message broker aracını bilinçli kullanmak ve hangi özelliklerini nasıl kullanacağımı bilmeden kullanmamak gerektiğini fark ettim. Aksi takdirde sistemin tam ortasında kendi başına birşeyleri yapan koca bir işlev çorbasına dönebilir. Bu message broker aynı zamanda kendi yeteneklerine göre belli roller alabileceği için yaptığınız seçim de sisteminizin yeteneklerini etkileyecektir. Sistemi karmaşıklaştırmamak adına message broker aracının rolünü iyi belirlemek gerekiyor.

Karşılaştırmaya geri döneyim. Bu yazdığım blog yazısında kullanılabilecek 3 adet güzel alternatif bulunuyor. RabbitMQ, ActiveMQ ve Kafka. Bu üç aracın karşılaştırması stackshare 'da mevcut. Buradan ulaşabilirsiniz. Sonunda rabbitmq tercih etmemin sebebi biraz kolay olması idi. Kafka biraz daha profesyonel görünüyordu. Activemq ise dökümantasyonu ve community desteği daha kısıtlı görünüyordu. İkisinin ortasında message broker mantığını anlayacak kadar ve kullanması çok zor olmayan rabbitmq oturuyor. Birçok programlama dilinde desteği ve dökümantasyonu da bulunuyor. Sorunlarla karşılaştığınızda çözümleri internette bulabiliyorsunuz. Eğer meraklı iseniz büyük abilerin alternatifleri de bulunuyor tabi ki. Azure, Amazon, IBM ve Google da message broker araçlarını geliştirmiş durumda.

Üzerine kurgulanan mikroservis projesi nasıldır

Eğer mikroservisler ve spring cloud ile ilgili orta veya ileri seviye bilginiz varsa, önceki yazı dizisinde yaptığım projeye github adresinden ulaşabilir ve lokalinizde çalıştmaya çalışabilirsiniz. Projeyi çalıştırmak için bu yazımdan yardım alabilirsiniz. Bu proje hayali bir biletleme uygulaması idi ve kullanıcılar giriş yapıp belli etkinlikler için biletler alıyordu. Bu projede 3 küçük servis bulunuyor ve MVC uygulaması ile koordinasyon gerçekleştiriliyordu. Bu projenin üstüne message broker yapısını satışlarda ve etkinlik iptallerinde e-mail gönderimi için kullanıyor gibi göstereceğim. Onlarca maili boşuna atmak mantıklı olmayacağı için prototip kodlar olacak tabi :) Bu işlemler kuyrukta bekleyecek mailler sıra ile gönderilecek. RabbitMQ sistemin neresinde oturacak derseniz her yazıda bulunacak olan şemayı da buraya koyayım.

Şemada da gördüğünüz gibi mikroservis sistemi çalışırken MVC uygulamasından bazı istekler RabbitMQ 'ya gönderiliyor. Message broker 'ımız da içerisindeki yönlendirme mantığına göre mail servisine mesajları yönlendiriyor. Sisteme mail servisini ekleyeceğiz. İletilemeyen mesajlarımız ise deadletter kuyruğunda kalacak. Her ne kadar rabbitmq basic işlevler için kullanılmış olsa da sistemin önemli bir parçası olacak. Broker ile ilgili aldığımız kararlar sonuçta MVC uygulaması ile mail servisi arasındaki iletişimi ve hatta yazılacak kodları belirleyecek. Bu sistemin detaylarını bu yazı dizisinde inceleyeceğiz.

Dilerseniz bu projenin son halini de github repository 'den indirip çalıştırmayı deneyebilirsiniz. Çalıştırmanız için rabbitmq kurup çalıştırmış olmanız da gerekir. Config repository 'yi klonlamanız gerekecektir. Daha kalıcı öğrenilmesi için yazı dizisi ile beraber gitmenizi tavsiye ediyorum. Durumu özetlersem: Mikroservis mimarisi üzerinde asenkron işlemleri gerçekleştirebilmek için message broker kullanacağız. Bu aracı sistemimizde e-mail gönderimi için kullanacağız. Çeşitli alternatifleri araştırdık ve RabbitMQ kullanmaya karar verdik. Broker 'ı sistemin dışında konumlandırdık ve mail servisine mesaj iletmesi rolünü verdik. Bu yazıda ise en önemli olan ilk adımı atmış olduk. Sırada RabbitMQ ile ilgili detaylar gelecek. Bir sonraki yazıda görüşmek üzere :)