Micro servisler için Asynchronous iletişim kullanırken, bir ileti aracısı kullanmak yaygındır. Bir aracı, farklı mikro hizmetler arasındaki iletişimin güvenilir ve kararlı olmasını, iletilerin sistem içinde yönetilmesini ve izlenmesini ve iletilerin kaybolmamasını sağlar. Ölçek ve veri yeteneklerine göre değişen, aralarından seçim yapabileceğiniz birkaç mesaj aracısı vardır. En popüler üç brokeri karşılaştıracağız: RabbitMQ, Kafka ve Redis.
Ama önce Microservices iletişimi hakkında bilgi edinelim.
Microservices Communication: Synchronous and Asynchronous (Zaman Uyumlu ve Zaman Uyumsuz)
Micro servislerin birbirleriyle iletişim kurmasının iki yaygın yolu vardır: synchronous ve asynchronous’dur. Synchronous bir iletişimde, istek bir sonraki iletiyi göndermeden önce bir yanıt bekler ve HTTP’nin üstünde bir REST protokolü olarak çalışır. Aksine, asynchronus bir iletişimde iletiler yanıt beklenmeden gönderilir. Bu, dağıtılmış sistemler için uygundur ve genellikle iletileri yönetmek için bir ileti aracısı gerektirir.
Seçtiğiniz iletişim türü, Micro servis nasıl yapılandırabileceğiniz, hangi altyapıya sahip olduğunuz, gecikme süresi, ölçek, bağımlılıklar ve iletişimin amacı gibi farklı parametreleri göz önünde bulundurmalıdır. Asynchronous iletişim kurmak daha karmaşık olabilir ve yığına daha fazla bileşen eklemeyi gerektirir, ancak Micro servisler için asynchronous iletişim kullanmanın avantajları eksilerden daha ağır basar.
Asynchronous İletişim Avantajları
Her şeyden önce, asynchronous iletişim tanım gereği engellenmez. Ayrıca Synchronous işlemlerinden daha iyi ölçeklendirme destekler. Üçüncü olarak, Micro servis çöker durumda, Asynchronous iletişim mekanizmaları çeşitli kurtarma teknikleri sağlar ve genellikle kilitlenmeyle ilgili hataları işlemede daha iyidir. Buna ek olarak, BIR REST protokolü yerine aracıları kullanırken, iletişim alan hizmetlerin birbirini gerçekten tanıması gerekmez. Eski bir hizmet uzun süre çalıştıktan sonra yeni bir hizmet bile sunılabilir, yani daha iyi ayırma hizmetleri.
Son olarak, Asynchronous işlemleri seçerken, gelecekte merkezi bir bulma, izleme, yük dengeleme ve hatta ilke zorlayıcı oluşturma yeteneğinizi artırırsınız. Bu, kod ve sistem geliştirmenizde esneklik, ölçeklenebilirlik ve daha fazla yetenek için yetenekler sağlayacaktır.
Doğru İleti Aracısını Seçme
Asynchronous iletişim genellikle bir ileti aracısı aracılığıyla yönetilir. Aysncio gibi başka yollar da var, ancak daha az ve sınırlılar.
Asynchronous işlemlerinizi yürütmek için bir broker seçerken, birkaç şeyi göz önünde bulundurmalısınız:
- Broker Ölçeği – Sistemde saniyede gönderilen mesaj sayısı.
- Veri Kalıcılığı – İletileri kurtarma yeteneği.
- Tüketici Kapasitesi – Komisyoncunun one to one ve/veya one to many tüketicileri yönetip yönetemeyeceği.
one to one
Bu üç kategoride hangi sağlayıcının en güçlü olduğunu bulmak için en son ve en iyi hizmetleri kontrol ettik.
Farklı İleti Aracılarını Karşılaştırma
RabbitMQ (AMQP)
Ölçek: yapılandırmaya ve kaynaklara göre, buradaki top sahası saniyede yaklaşık 50K msg’dir.
Kalıcılık: hem kalıcı hem de geçici iletiler desteklenir.
One-to-one ve one-to-many tüketici: her ikisi de.
RabbitMQ 2007 yılında piyasaya sürüldü ve oluşturulan ilk ortak mesaj aracılarından biridir. Gelişmiş Message Queuing Protokolleri (AMQP) uygulayarak iletileri hem noktadan noktaya hem de pub-sub yöntemleri aracılığıyla teslim eden açık bir kaynaktır. Karmaşık yönlendirme mantığını desteklemek için tasarlanmıştır.
SaaS olarak kullanmanıza izin veren bazı yönetilen hizmetler vardır, ancak yerel büyük bulut sağlayıcısı yığınının bir parçası değildir. RabbitMQ, Python, Java, .NET, PHP, Ruby, JavaScript, Go, Swift ve daha fazlası dahil olmak üzere tüm ana dilleri destekler.
Kalıcı moddayken bazı performans sorunları bekleyin.
Kafka
Ölçek: saniyede en fazla milyonlarca mesaj gönderebilir.
Sebat: Evet.
One-to-one vs one-to-many tüketiciler: sadece bire çok (ilk bakışta garip görünüyor, değil mi?!).
Kafka, Linkedin tarafından 2011 yılında yüksek verim, düşük gecikme süresi işlemeyi işlemek için kuruldu. Dağıtılmış bir akış platformu olarak Kafka, yayımlama abone olma hizmetini çoğaltır. Veri kalıcılığı sağlar ve kaliteli ileti alışverişi yapabilen kayıt akışlarını depolar.
Kafka, Azure, AWS ve Confluent’te SaaS’ı yönetti. Hepsi Kafka projesinin yaratıcıları ve ana katılımcılarıdır. Kafka, Python, Java, C/C++, Clojure, .NET, PHP, Ruby, JavaScript, Go, Swift ve daha fazlası dahil olmak üzere tüm ana dilleri destekler.
Redis
Ölçek: saniyede bir milyona kadar ileti gönderebilir.
Kalıcılık: temelde, hayır – bellek içi bir veri deposu.
One-to-one vs one-to-many tüketici: her ikisi de.
Redis diğer mesaj aracılarından biraz farklıdır. Özünde, Redis, yüksek performanslı anahtar değeri deposu veya ileti aracısı olarak kullanılabilen bir bellek içi veri deposudur. Başka bir fark, Redis’in kalıcılığı olmaması, bunun yerine belleğini bir Disk/VERITABANı’ya dökmesidir. Ayrıca gerçek zamanlı veri işleme için de mükemmeldir.
Başlangıçta, Redis bire bir ve bire bir değildi. Ancak, Redis 5.0 pub-sub’u tanıttığından beri, yetenekler artırıldı ve bire çok gerçek bir seçenek haline geldi.
Kullanım Örneği Başına İleti Aracıları
RabbitMQ, Kafka ve Redis’in bazı özelliklerini ele aldık. Üçü de kendi kategorilerinde canavarlardır, ancak açıklandığı gibi, oldukça farklı çalışırlar. İşte farklı kullanım durumlarına göre kullanmak için doğru mesaj komisyoncusu için önerimiz.
Kısa Ömürlü Mesajlar: Redis
Redis’in bellek içi veritabanı, kalıcılığın gerekli olmadığı kısa ömürlü iletilere sahip kullanım durumları için neredeyse mükemmel bir uyum sağlar. Son derece hızlı hizmet ve bellek içi yetenekler sağladığından, Redis kalıcılığın çok önemli olmadığı ve bazı kayıpları tolere edebileceğiniz kısa saklama mesajları için mükemmel bir adaydır. Redis akışlarının 5.0’da piyasaya sürülmesiyle, sınırlamalar ve eski pub-sub yetenekleri nedeniyle kesinlikle gerekli olan bire çok kullanım örnekleri için de bir adaydır.
Kullanım Örneği Başına İleti Aracıları
RabbitMQ, Kafka ve Redis’in bazı özelliklerini ele aldık. Üçü de kendi kategorilerinde canavarlardır, ancak açıklandığı gibi, oldukça farklı çalışırlar. İşte farklı kullanım durumlarına göre kullanmak için doğru mesaj komisyoncusu için önerimiz.
Kısa Ömürlü Mesajlar: Redis
Redis’in bellek içi veritabanı, kalıcılığın gerekli olmadığı kısa ömürlü iletilere sahip kullanım durumları için neredeyse mükemmel bir uyum sağlar. Son derece hızlı hizmet ve bellek içi yetenekler sağladığından, Redis kalıcılığın çok önemli olmadığı ve bazı kayıpları tolere edebileceğiniz kısa saklama mesajları için mükemmel bir adaydır. Redis akışlarının 5.0’da piyasaya sürülmesiyle, sınırlamalar ve eski pub-sub yetenekleri nedeniyle kesinlikle gerekli olan bire çok kullanım örnekleri için de bir adaydır.