Micro Servisler Arası Senkron Ve Asenkron İletişim

 Servisler kendi aralarında aşağıdaki şekillerde haberleşir.

• Synchronous  Request/Response-based Communication Mechanisms (HTTP-Based REST, gRPC)
• Asynchronous Message-Based Communication Mechanisms(AMQP, STOMP)RabbitMQ,Kafka 

İnteraction Styles

One-to-one : Requestin  sade ve sadece bir tane service tarafında işlenmesi

Ono-to-many : Requestin birden çok servis tarafından işlenmesi

Synchronous : Client servisten yanıt dönene kadar bekler ve requeste cevap dönene kadar Clientın yaptığı işlem  bloklanır.

Asynchronous  : Client requestin yanıtını beklemez ve bloklanmaz.

SENKRON HABERLEŞME

REST Mimari

- REST mimaride resource kavramı vardır. Bu resource arka tarafta bir business objete karşılık gelir

- Bir resource almak için bir request göndeririz ve bu requeste karşılık istek yapılan yerden bize  resource döner. Birden fazla resourceye ihtiyacımız olursa ne olacak ? Bu durum genelde microsevisler arası iletişimde REST mimariyi kullandığımızda dezavantaj olarak ortaya çıkar.

- REST ile http isteği attığımızda resource api çalışmadığı zaman o request boşa gider. Kaybolur.

- Clientlar resourceye ait URLleri bilmek zorundadır.

gRPC

gRPC, RPC(Remote Procedure Call) nin bir alt kolu gibi düşünebiliriz. A noktası ile B noktası arasında bir iletişim varsa bir request gönderiyoruz demektir. Bu iki nokta arasında haberleşme olabilmesi için aralarında ortak bir dil olmak zorundadır ve aynı zamanda bir mesajllaşma formatı olmalıdır. Default olarak gRPC'de HTTP/2 kullanılır. Message formatı olarakda Protol Bufferı kullanılır. Buda bir binary formattır. Ayrıca gRPC de tagleme formatı vardır. Bu tagleme formatıda şu anlama geliyor. Proto dosyasının içine baktığımızda fieldın adını, numarasını ve veri tipini falan anında görebiliyoruz. Buradaki fieldları bir, iki vs. diyerek tagliyoruz. Bu tagleme işleminin de mantığı veri kablo üzerinde giderken bize yardımcı oluyor.

Yukarıdaki REST ve gRPC gibi http requesti atılan bir resourse api servisi down olduğu durumda bu request kaybolur. Bu tarz durumlarla başa çıkabilmek için microservis mimarimizin resiliency(Dayanıklılık, Esneklik) yüksek olmalıdır.

ASENKRON HABERLEŞME

- Genelde bir message brrokera ihtiyaç duyulur. Client bu brokere isteği gönderir ve daha sonradan bunun cevabının kendine gönderileceğini bilir. Bu iletişimde mesajlar ve kanallar vardır. Gönderici mesajı kanal üzerinden gönderir daha sonra bu mesajı alan karşı taraf belli bir işlemi yaptıktan sonra Client tarafına bildirimde bulunmaya çalışır.

- Mesaj: Bir header ve datanın kendisin olduğu bodyden oluşur.

- Mesaj kuyruğu sayesinde, Consumer servis bir sebepten ötürü erişilemez durumdayken veri kuyrukta kalır ve tekrar erişilebilir olunca data kaybı yaşamadan kuyruğu tüketmeye devam eder.