belestr
İş akışına göre değişir.
1- 1. servis işlemini tamamladı.
2- 2. servis işlemini tamamladı.
3- 3. servis işlemeni tamamladı.
4 . serviste bir sorun çıktı.
Bu senaryoda servisler birbiri ile nasıl haberleşiyor?
RabbitMQ, Kafka gibi bir queue üzerinden mi? Rest api ile mi? Hepsinde farklı yöntem izlemek lazım.
Güzel bilgi: Queue üzerinden ilerlendiği zaman buna asenkron rest üzerinden ilerlendiği zaman da senkron iletişim deniyor.
Mesela rest api kullanıyorsak şöyle bir yol izlenebilir, @mgsmus un dediğine benzer şekilde sıra ile hepsi birbirini çağırır. 1.Servis transactionu başlatır ve 2.servise istek atar, 2.si transaction u başlatır ve 3.ye istek atar. 3.sü transactionu başlatır ve 4.ye istek atar. 4.sü transactionu başlatır. 4.sü başarılı olursa 3.ye başarılı diye response dönmeden önce commit eder. 3.sü cevap başarılı geldiği için commit edip 2.ye başarılı cevabı döner, 2.si de başarılı cevap aldığı için commit edip 1.ye başarılı cevabı döner, 1.si de başarılı cevabı alıp commit eder ve iş biter.
Herhangi bir yerde aksama olursa aksama yapan servis kendisi rollback yaptıktan sonra geriye hatalı cevap döner. İlerisine zaten gidilmemiştir. Böylece geriye doğru bir rollback zinciri oluşturulur ve en son ilk servis de rollback yapar ve tüm servisler her şeyi geri almış olur.
Amaaaa gel gör ki queue üzerinden gidiyorsak böyle bir şansımız yok. Asenkron adı zaten. Bu durumda her servis için bir de rollback yapan bir listener lazım. 1.si işini yapıp commit edip 2.nin dinlediği kuyruğa işi yazar. Cevap beklemediği için artık ileride ne olduğundan haberi olmayacaktır. Bu durumda farz-ı misal 3.serviste bir hata oldu ve 3.sü işini bitiremedi. O zaman bu 3.sü 2.nin dinlediği rollback listener ına şu şu bilgilerle yaptığın işi geri al diye mesaj atar. 2.si de aaa benim iş iptal olmuş diyip 1.nin rollback yapan listener ına mesaj atar. böyle böyle geriye doğru işlem yapmak gerekir. Zahmetli iş yani.
Bir de hibrit mimari kullanılabilir. Bu işleri biraz kolaylaştırıyor. Yani hem queue hem rest kullanırız. Normal işlerimizi queue ile yazarız. Ama 1 den 4 e doğru giderken 3 te hata olursa rollback listener ına hata yazmak yerine rest api ile 3 ten 2 ye request yaparız, 2. den 1 e falan en son hepsi geri 3 e döner. Son bitirici vuruşu 3 yapmış olur. Bu biraz daha karmaşık görünen ama pratikte daha kolay bir yol.
Queue kullanırsak avantajlar daha fazla, bir işlemi başarılı olana kadar kuyrukta tutmak rest e göre daha kolay. Diğer servisleri bekleme modunda tutmamak adına da kuyruk kullanmak mantıklı. Artısı eksisinden fazla. Tercih sebebi.
Mikroservis mimarisinde çok kaliteli bir loglama altyapısı gerekir. Sadece loglar üzerinden rollback bile yapılabilir iyi bir loglama yapısı varsa. Graylog gibi bir loglama yapısı kullanırsanız servisler arasındaki iletişimi takip edebilirseniz işler kolaylaşır.
Bir kaç gün önce @deathisonitsway ile konuşmuştum KongHQ yu kullanıyor musun abi demiştim üstüne bu konu geldi. Kong'da rollback prosedürlerini konfigüre edebildiğimizi hatırlıyorum ama yanlış da olabilir kirli bilgi vermeyeyim ama bu tür API gateway araçlarında var böyle çözümler. Hem loglama hem de rollback işlemleri için yani.
Mesela Kong'da correlation ID var. https://docs.konghq.com/hub/kong-inc/correlation-id/
Bir request o servis senin bu servis benim dolaşırken hep aynı correlation ID'ye sahip olur. Böylece o requestin nerelerde gezdiğini real time takip bile edebilirsiniz. Bu correlation ID ile şöyle bişey yapılabilir. Herhangi bir serviste sıkıntı olunca tek bir servis işleri geri almakla görevli olur ve biz bu correlation ID'yi veririz. O zamana kadar yapılmış işleri de payload olarak taşırsak servisler arasında tadından yenmez. Bunları da araştırmak lazım.
Bu korelasyon muhabbetini Kong kullanmadan da yapabilirsiniz. Loglamada da işe yarar hangi request hangi aşamada patlamış manuel takip edebilmek için.
Daha ne anlatayım bilemedim.
Bol şans. 😃