 |
| Message Queue |
Bu uygulamaların hepsinin ortak yönü message queue hatta biraz daha açacak olursak asenkron iletişimi desteklemesidir.
Konunun anlaşılması için asenkron iletişimin de anlaşılmasının çok önemli olduğunu düşündüğüm için konuyu anlatmaya buradan başlayacağım. Devamında ise yukarıda sıraladığım uygulamalardan biri olan RabbitMQ üzerinden Message Queue mantığını anlatmaya çalışacağım. Konuyu RabbitMQ ile anlatmak istememin en önemli nedenlerinden bir tanesi platform bağımsız olması ve hemen hemen tüm programlama dillerini desteklemesidir.
Konunun anlaşılabilmesi için diğer önemli noktalardan bir tanesi de AMQP'nin(Advanece Message Queue Protocol) anlaşılmasıdır. Bu yüzden başta söylemek istiyorum ki konu biraz uzun olacak. Bu makaleyi okurken sıkılmamanız için de bazı konularda kısaca bilgi verip konuyu detaylı anlattığım makalelere link vereceğim.
Yukarıda makaleye giriş yapma açısından ve bir anlamda makale için yol haritası da belirlerken önemli olan konulardan bir tanesi Asenkron İletişimin anlaşılmasıdır. Bunun için de senkron ve asenkron iletişi farkını açıkça ortaya koymakta fayda var.
Senkron iletişimde bir metoda parametre gönderirsiniz ve bu fonksiyon yapmalı olduğu işlemleri yapar ve size bir sonuç döndürür. Muhakkak ki sizin de şimdiye kadar yaptığınız programların çoğu bu mantıkla yazılmıştır. Tabi ki burda threadlerle farklı iş parçacığı olarak çalıştırmaktan bahsetmiyorum. Sonuçta threadlerle de çalışırken yine belirli fonksiyonlara iş yaptırmayı ve sonucu beklersiniz. Asenkron iletişim ise daha çok belirli bir işi yaparken sizden parametreleri alır ve size bu parametreleri aldığına dair bir garanti verir. Zamanı geldiğinde verileri işler ve size sonuç döndürür. Ama bu işlemleri yaparken extradan sizie bekletmez. Aslında bu işlemler için Message Patternler tasarlanmıştır ki bunlardan da en yaygın olarak kullanılanları Fire and Forget, Request Response ve Publise Subcribe'dır. Bu konuların hepsini detaylı olarak anlatacağım için burada detaylarına girmiyorum. Ama önemli olan nokta her zaman eğer bir kanal üzerinden fonksiyon içine parametre gönderiyorsak, cevabı bu kanal üzerinde değil işlem bittikten sonra oluşan yeni kanal üzerinden aktarırız. Örneğin Fire And Forget patterni için önemli olan sadece fonksiyonu tetiklemek iken, Request ve Response patterni mesajı alır, aldığına dair geri mesaj döndürür. Verileri işleyip sonuç aldıktan sonra ise sonucu ayrı ir kanalo üzerinden karşıya iletir.
Yukarıda anlattığım aslında asenkron iletişim temel taşları ve bilinmesi gereken önemli konular. Kısaca bahsettiğim message patternleri ise asenkron iletişimi uygulamak için kalıplardır. Tabi ki bu kalıplara uymak zorundasınız diye bir şey yok. Ama bu alanda yapılmış ve yılların tecrübesini barındıran bu kalıpların sizin kendi uygulamalarınıza asenkron iletişimi uygulamakta çok faydalı olacağını düşünüyorum. O yüzden bu konuları da incelemekte fayda var.
Kısaca bahsetmiş olsam da zannedersem asenkron iletişimin temel mantığını anlatabilmişimdir. Anlattığım kısmın da birazdan anlatacağım message queue mantığını anlamanız için yeterli olduğunu düşünüyorum. Ama tabi ki bu konular bu kadar anlatımla detaylandırılacak kadar kısa konular değil. O yüzden makale içerisinde verdiğim linklerde konularla alakalı detaylı bilgiler almak isterseniz daha detaylı bilgiler bulabilirsiniz.
Asenkron iletişimi anlattıktan sonra sanırım artık message queue yapısının ne olduğunu ve bu yapının asenkron iletişimle nasıl bir bağı olduğunu açıklamaya çalışalım. Message queue basitçe bir mesaj kuyruğu olduğunu ve uygulamalarınızın haberleşmesi için bir araç olarak görebilirsiniz. Bir uygulamanız bu kuyruğa mesaj yazarken diğer uygulamanız da bu kuyruktan mesajları alarak işleyebilir. Burada mesajı kuyruğa gönderene publisher denilirken, kuyruktan okuyana da consumer denilir. Message queue mantığında en önemli özellik ise bir mesajın kesinlikle kaybolmayacağını garanti etmektir. Örneğin kuyruğa bir mesaj gönderildiğinde bu mesajın gittiğinden emin olmak zorundasınız ve kuyruktan mesaj okunduğunda da bu mesajın kuyruktan kaldırıldığından emin olmak zorundasınız. Tabi ki uygulama geliştiricileri bu anlamda çok sıkıntı yaşamazlar. Ticari uygulamaların çoğunun oluşabilecek hatalar ve mesaj güvenliği için geliştirdikleri bir çok prosedür ve önlemler bulunmaktadır. Oluşabilecek hatalarla ilgili basit örnek vermek gerekirse uygulamanızın kuyurğa bir mesaj gönderdiğini düşünün. Bu mesaj kuyruğa eklenmesine rağmen, bu kuyruktan uygulamanıza ben bu mesajı aldım gibisinden bir cevap gelmese bu mesajın kuyruğa yazılıp yazılmadığından emin olamazsınız. Bu zamanda message queue mantığındaki güvenli mesajlaşma yada kaybolmayan mesaj ilkesini çiğnemiş olursunuz. Ama bu işin sadece altyapısını, yani uygulamalarınızda bunları çözmeniz beklenmez. Yukarıda sıraladığımız uygulamalar örneğin RabbitMQ, ZeroMQ ve başka uygulamaların çoğunda oluşabilecek bu gibi sıkıntıları çözme potensiyalı vardır. Tabi ki, konuyu detaylı incelediğinizde ve bu alanda yazdığım diğer makaleleri okuduğunuzda siz de göreceksiniz ki, MQ mantığının asıl mantığı uygulamalar arasında güvenli mesajlaşmayı sağlamaktır ve güvenli, garanti mesaj yapısı da kurmak o kadar basit bir iş değildir. Oluşabilecek tüm olasılıkları düşünmek bile çoğu noktada yetersiz kalabilir. Bu yüzden yılların tecrübeleriyle oluşturulmuş Message Queue dünyasına hoşgeldiniz diyorum...
Konuyu çok fazla uzatmak istemediğim için ve makale başlığındaki MQ mantığı, yani Message Queue mantığını anlamanız için makalede anlatılanların yeterli olduğunu düşünüyorum. Buradan sonra konuyla alakalı olan diğer makale linkleri de makaleleri yazdığım zaman bloğuma ekleyeceğim. Message Queue mantığında önemli olan iki nokta asenkron iletişim ve güvenli mesajlaşma konularını burada anlatmaya çalıştım. Okuyan insanları da daha fazla sıkmamak için ve fazla laf kalabalığı olmaması açısından konuyla ilgili daha spesifik makalelerle karşınızda olacağım.
Konuya alakalı sorularınız olursa lütfen sormaktan çekinmeyin. En kısa sürede yanıtlamaya çalışacağım.
Konunun anlaşılması için asenkron iletişimin de anlaşılmasının çok önemli olduğunu düşündüğüm için konuyu anlatmaya buradan başlayacağım. Devamında ise yukarıda sıraladığım uygulamalardan biri olan RabbitMQ üzerinden Message Queue mantığını anlatmaya çalışacağım. Konuyu RabbitMQ ile anlatmak istememin en önemli nedenlerinden bir tanesi platform bağımsız olması ve hemen hemen tüm programlama dillerini desteklemesidir.
Konunun anlaşılabilmesi için diğer önemli noktalardan bir tanesi de AMQP'nin(Advanece Message Queue Protocol) anlaşılmasıdır. Bu yüzden başta söylemek istiyorum ki konu biraz uzun olacak. Bu makaleyi okurken sıkılmamanız için de bazı konularda kısaca bilgi verip konuyu detaylı anlattığım makalelere link vereceğim.
Yukarıda makaleye giriş yapma açısından ve bir anlamda makale için yol haritası da belirlerken önemli olan konulardan bir tanesi Asenkron İletişimin anlaşılmasıdır. Bunun için de senkron ve asenkron iletişi farkını açıkça ortaya koymakta fayda var.
Senkron iletişimde bir metoda parametre gönderirsiniz ve bu fonksiyon yapmalı olduğu işlemleri yapar ve size bir sonuç döndürür. Muhakkak ki sizin de şimdiye kadar yaptığınız programların çoğu bu mantıkla yazılmıştır. Tabi ki burda threadlerle farklı iş parçacığı olarak çalıştırmaktan bahsetmiyorum. Sonuçta threadlerle de çalışırken yine belirli fonksiyonlara iş yaptırmayı ve sonucu beklersiniz. Asenkron iletişim ise daha çok belirli bir işi yaparken sizden parametreleri alır ve size bu parametreleri aldığına dair bir garanti verir. Zamanı geldiğinde verileri işler ve size sonuç döndürür. Ama bu işlemleri yaparken extradan sizie bekletmez. Aslında bu işlemler için Message Patternler tasarlanmıştır ki bunlardan da en yaygın olarak kullanılanları Fire and Forget, Request Response ve Publise Subcribe'dır. Bu konuların hepsini detaylı olarak anlatacağım için burada detaylarına girmiyorum. Ama önemli olan nokta her zaman eğer bir kanal üzerinden fonksiyon içine parametre gönderiyorsak, cevabı bu kanal üzerinde değil işlem bittikten sonra oluşan yeni kanal üzerinden aktarırız. Örneğin Fire And Forget patterni için önemli olan sadece fonksiyonu tetiklemek iken, Request ve Response patterni mesajı alır, aldığına dair geri mesaj döndürür. Verileri işleyip sonuç aldıktan sonra ise sonucu ayrı ir kanalo üzerinden karşıya iletir.
Yukarıda anlattığım aslında asenkron iletişim temel taşları ve bilinmesi gereken önemli konular. Kısaca bahsettiğim message patternleri ise asenkron iletişimi uygulamak için kalıplardır. Tabi ki bu kalıplara uymak zorundasınız diye bir şey yok. Ama bu alanda yapılmış ve yılların tecrübesini barındıran bu kalıpların sizin kendi uygulamalarınıza asenkron iletişimi uygulamakta çok faydalı olacağını düşünüyorum. O yüzden bu konuları da incelemekte fayda var.
Kısaca bahsetmiş olsam da zannedersem asenkron iletişimin temel mantığını anlatabilmişimdir. Anlattığım kısmın da birazdan anlatacağım message queue mantığını anlamanız için yeterli olduğunu düşünüyorum. Ama tabi ki bu konular bu kadar anlatımla detaylandırılacak kadar kısa konular değil. O yüzden makale içerisinde verdiğim linklerde konularla alakalı detaylı bilgiler almak isterseniz daha detaylı bilgiler bulabilirsiniz.
Asenkron iletişimi anlattıktan sonra sanırım artık message queue yapısının ne olduğunu ve bu yapının asenkron iletişimle nasıl bir bağı olduğunu açıklamaya çalışalım. Message queue basitçe bir mesaj kuyruğu olduğunu ve uygulamalarınızın haberleşmesi için bir araç olarak görebilirsiniz. Bir uygulamanız bu kuyruğa mesaj yazarken diğer uygulamanız da bu kuyruktan mesajları alarak işleyebilir. Burada mesajı kuyruğa gönderene publisher denilirken, kuyruktan okuyana da consumer denilir. Message queue mantığında en önemli özellik ise bir mesajın kesinlikle kaybolmayacağını garanti etmektir. Örneğin kuyruğa bir mesaj gönderildiğinde bu mesajın gittiğinden emin olmak zorundasınız ve kuyruktan mesaj okunduğunda da bu mesajın kuyruktan kaldırıldığından emin olmak zorundasınız. Tabi ki uygulama geliştiricileri bu anlamda çok sıkıntı yaşamazlar. Ticari uygulamaların çoğunun oluşabilecek hatalar ve mesaj güvenliği için geliştirdikleri bir çok prosedür ve önlemler bulunmaktadır. Oluşabilecek hatalarla ilgili basit örnek vermek gerekirse uygulamanızın kuyurğa bir mesaj gönderdiğini düşünün. Bu mesaj kuyruğa eklenmesine rağmen, bu kuyruktan uygulamanıza ben bu mesajı aldım gibisinden bir cevap gelmese bu mesajın kuyruğa yazılıp yazılmadığından emin olamazsınız. Bu zamanda message queue mantığındaki güvenli mesajlaşma yada kaybolmayan mesaj ilkesini çiğnemiş olursunuz. Ama bu işin sadece altyapısını, yani uygulamalarınızda bunları çözmeniz beklenmez. Yukarıda sıraladığımız uygulamalar örneğin RabbitMQ, ZeroMQ ve başka uygulamaların çoğunda oluşabilecek bu gibi sıkıntıları çözme potensiyalı vardır. Tabi ki, konuyu detaylı incelediğinizde ve bu alanda yazdığım diğer makaleleri okuduğunuzda siz de göreceksiniz ki, MQ mantığının asıl mantığı uygulamalar arasında güvenli mesajlaşmayı sağlamaktır ve güvenli, garanti mesaj yapısı da kurmak o kadar basit bir iş değildir. Oluşabilecek tüm olasılıkları düşünmek bile çoğu noktada yetersiz kalabilir. Bu yüzden yılların tecrübeleriyle oluşturulmuş Message Queue dünyasına hoşgeldiniz diyorum...
Konuyu çok fazla uzatmak istemediğim için ve makale başlığındaki MQ mantığı, yani Message Queue mantığını anlamanız için makalede anlatılanların yeterli olduğunu düşünüyorum. Buradan sonra konuyla alakalı olan diğer makale linkleri de makaleleri yazdığım zaman bloğuma ekleyeceğim. Message Queue mantığında önemli olan iki nokta asenkron iletişim ve güvenli mesajlaşma konularını burada anlatmaya çalıştım. Okuyan insanları da daha fazla sıkmamak için ve fazla laf kalabalığı olmaması açısından konuyla ilgili daha spesifik makalelerle karşınızda olacağım.
Konuya alakalı sorularınız olursa lütfen sormaktan çekinmeyin. En kısa sürede yanıtlamaya çalışacağım.
Yorumlar
Yorum Gönder