Hüseyin Hocam kanalınızı yaklaşık 2 ay öncesinden keşfettim. Muadili olmayan içerikleri kendinize has tavrınızla, herkesin anlayabileceği şekilde anlatıyorsunuz. İngilizce olarak resource çok ve güzel içerikler sunan arkadaşlar var fakat Türkçe de siz bence bestsiniz. Çok büyük bir nimetten yararlanmamıza olanak sağlıyorsunuz. Çok teşekkür ediyorum. Sizden ufak bir ricam olacak eğer mümkünse : Yaklaşık 5-6 aydır Spring ve Microservisler ile uğraşan. Kanalınızda bu konular ile alakalı içeriklerin %80'inden fazlasını izleyen birisi olarak bir microservis projesi yapmak istiyorum. Fakat zorlandığım nokta projeye başlamadan önce mimarisini çizemiyor olmam. Örneğin bir food delivery projesini ele almaya karar verdim ama burda benim servisleri ve domain modellerimi nasıl ayırmam gerektiği ve iş akışını tam olarak bilmediğim için nasıl bir process olması gerektiğini gerçeğe yakın bir şekilde ele alamıyorum. Eğer vaktiniz musait ise sadece mimariyi çizip, gerçeğe ufakta olsa yakın bir design sunmayı düşünür müsünüz ? Şimdiden teşekkürler.
6 месяцев назад+1
Selamlar, oncelikle tesekkur ederim. Notumu aldim, ilk firsatta bununla ilgili birseyler anlatmaya calisirim.
Selamlar, Öncelikle içerik için teşekkürler hocam güzel bir seri hazırlamışsınız. Konudan biraz farklı bir sorum olacak:) intellij idea da kullandığınız plugin leri anlatan video veya bir yazı var mı?
Год назад
Şöyle bir tweetseli var x.com/huseyinbabal/status/1701147895943077939?s=46&t=Jw9e8SsLtJQX9-PjhSXC6g
Hocam elinize saglık cok güzel bir içerik olmuş. Ben bir şey sorucaktım. Order mikroservisi hem produce ediyor hem de consume ediyor. Consume işlemi için herhangi bir deserializer ayarı yapmamanıza rağmen nasıl çalıştı ? Produce işlemi için serializer ayarı yaptınız ama consume işlemi için herhangi bir şey yazmadınız diye gördüm. Cevap için teşekkürler.
Год назад+1
Order consume ettiği yere bakarsan abi, consume ettiği veri tipi String , yani herhangi bir deserialization ihtiyacı yok. Produce ettiği yerde komplex event kullanmıştım o yüzden serializer yazdım, ama String için gerek yok.
Hocam teşekkürler. Benim sormak istediğim şu: placeOrder yaparken önce db'ye kaydediyoruz, sonra kafkaya gönderirken hata alırsa db'de rollback edebiliyoruz burada sorun yok. Peki shipping-group ile consume ederken mesajı okuduktan sonra process ederken bir hata alırsak ne yapmalıyız? Bu durumda prod.orders.placed'den bu mesajı consume etmiş olduk, ama process edemedik, ne yapmalıyız? Diyelim ki sadece spesifik bir order'da hata alınıyor, bu durumda bu order prod.order.placed'de kalmaya devam etsin ve daha sonra tekrar denesin ama bu topicteki diğer mesajlar da hata alan mesajı beklemeden işlenmeye devam etsin gibi bir şeyi nasıl yapabiliriz? Veya burada farklı bir yaklaşım mı izlemek gerekir? Son olarak da, araştırdığımda dead letter queue yaklaşımı görüyorum ama orada da aklıma takılan şu: ya dead letter queu'ya atarken de sorun çıkarsa ne olacak? Yani topicteki mesajın kesinlikle ve kesinlikle kaybolmasını engellemenin bir yolu var mıdır? Teşekkürler.
Год назад
Selam Serkan, shipping kısmında hata aldığında yapleceğin 2 şey var 1. Eğer retry edilebilir bir hata ise, tekrar dene 2, Geri dönülemez bir hata ise, o zaman shipping failed diye mesaj gönder. Order service, bu order i failed olarak sonlandirir, be error reason olarak shipping i set eder. Umarım anlaşılır olmuştur 🙂
@ teşekkürler açıklayıcı oldu. Fakat diyelim ki geri dönülemez bir hataydı ve 2. seçeneği yaptık, orada da shipping failed mesajı gönderirken fail oldu. Demek istediğim bu fail olma durumunu kaçıncı seviyeye kadar düşüneceğiz, böyle düşününce de gitgide işin içinden çıkılmaz hale geliyor :) Sanki daha ilk aşamada, ilk mesajı process edemediysek queue'da commit etmeme ve mesajı tekrar okuma ve daha sonra tekrar deneme yoluna gitmeliyiz diye düşünüyorum ama bunu nasıl yapabiliriz ve bu doğru bir yaklaşım mıdır?
Год назад
@@loltr452 Eger hata olayi mesaj gonderirken oluyorsa orda bir problem var demektir. MEsela Kafka kullaniyorsan, kafka zaten durable bir sistemdir, cok az hata aliyor olman lazim. Ama hata alsan bile kullandigin client, retry etmeye hazir belirli bir sure retry eder. Mesaj okuma kisminda haklisin, commit olayi basarili durumda set edilmeli, ama mesaji gonderirken problem varsa, orda artik client retry olayina guvenmelisin. Ben bu gibi durumlar icin, uygulama loglarini ship ettigim icin log uzerinde alarm kuruyorum yani bana bir sekilde bildiriliyor. Bir de kafka metriklerini takip ediyorum, lag factor gibi
eline sağlık :) publish edilen mesajın farklı instancelarda dinlemesinde mesajın duplike olmamasına değindiniz mi? Kaçıncı dakikada paylaşabilir misiniz?
Год назад
Dakikasını hatırlamıyorum ama muhtemelen bahsetmemişimdir, çünkü kafka kullanıyorsan, farklı instance lardan bile okusan, duplicated data almazsın. One Time Message Delivery garantisi var
![[TR] Spring Boot Microservices - CI/CD with Github Actions](http://i.ytimg.com/vi/eMrOMD6HgDg/mqdefault.jpg)
![[TR] Spring Boot Microservices - CI/CD with Github Actions](/img/tr.png)
![[TR] Reading Microservices Patterns | Business Capabilities](http://i.ytimg.com/vi/8XiggQ1f2pY/mqdefault.jpg)
Hüseyin Hocam kanalınızı yaklaşık 2 ay öncesinden keşfettim. Muadili olmayan içerikleri kendinize has tavrınızla, herkesin anlayabileceği şekilde anlatıyorsunuz. İngilizce olarak resource çok ve güzel içerikler sunan arkadaşlar var fakat Türkçe de siz bence bestsiniz. Çok büyük bir nimetten yararlanmamıza olanak sağlıyorsunuz. Çok teşekkür ediyorum. Sizden ufak bir ricam olacak eğer mümkünse :
Yaklaşık 5-6 aydır Spring ve Microservisler ile uğraşan. Kanalınızda bu konular ile alakalı içeriklerin %80'inden fazlasını izleyen birisi olarak bir microservis projesi yapmak istiyorum. Fakat zorlandığım nokta projeye başlamadan önce mimarisini çizemiyor olmam. Örneğin bir food delivery projesini ele almaya karar verdim ama burda benim servisleri ve domain modellerimi nasıl ayırmam gerektiği ve iş akışını tam olarak bilmediğim için nasıl bir process olması gerektiğini gerçeğe yakın bir şekilde ele alamıyorum. Eğer vaktiniz musait ise sadece mimariyi çizip, gerçeğe ufakta olsa yakın bir design sunmayı düşünür müsünüz ? Şimdiden teşekkürler.
Selamlar, oncelikle tesekkur ederim. Notumu aldim, ilk firsatta bununla ilgili birseyler anlatmaya calisirim.
Altın değerinde bir video teşekkürler 🙏🏻
watching from Poland, thanks for video
Thank you 🙂 so did you managed to see english subtitles ?
@ haha yes :D but not everything was correct
@@lukasz-cpu2416 appreciate your interest :)
Selamlar hocam. Video için teşekkürlər. Intelij idea nın kodu tamamlamasını nasıl aktif ede bilirim?
Selamlar, Github Copilot plugin kullanmanız gerekiyor
Hocam elinize emeğinize sağlık.
Selamlar, Öncelikle içerik için teşekkürler hocam güzel bir seri hazırlamışsınız. Konudan biraz farklı bir sorum olacak:) intellij idea da kullandığınız plugin leri anlatan video veya bir yazı var mı?
Şöyle bir tweetseli var x.com/huseyinbabal/status/1701147895943077939?s=46&t=Jw9e8SsLtJQX9-PjhSXC6g
@ Teşekkürler hocam
Çok güzel ve eğitici bir yayın olmuş hocam ellerinize sağlık 🙌
Hocam elinize saglık cok güzel bir içerik olmuş. Ben bir şey sorucaktım. Order mikroservisi hem produce ediyor hem de consume ediyor. Consume işlemi için herhangi bir deserializer ayarı yapmamanıza rağmen nasıl çalıştı ? Produce işlemi için serializer ayarı yaptınız ama consume işlemi için herhangi bir şey yazmadınız diye gördüm. Cevap için teşekkürler.
Order consume ettiği yere bakarsan abi, consume ettiği veri tipi String , yani herhangi bir deserialization ihtiyacı yok. Produce ettiği yerde komplex event kullanmıştım o yüzden serializer yazdım, ama String için gerek yok.
@ anladım teşekkürler. Ben String deserializer gibi bişeye ihtiyaç var sanmıştım.
hocam cok tesekkürler video icin , debezium ile change data capture konularina deginecek misiniz? yada önerdiginiz kitap kaynak var midir?
Yapılmışı var ruclips.net/video/D6sIzOt7ONA/видео.html 🙂
@ cok tesekkurler :)
Bilgilisin ama anlatamıyorsun abi. Sağlık olsun emeğine saygılıyım.
Hocam teşekkürler. Benim sormak istediğim şu: placeOrder yaparken önce db'ye kaydediyoruz, sonra kafkaya gönderirken hata alırsa db'de rollback edebiliyoruz burada sorun yok.
Peki shipping-group ile consume ederken mesajı okuduktan sonra process ederken bir hata alırsak ne yapmalıyız? Bu durumda prod.orders.placed'den bu mesajı consume etmiş olduk, ama process edemedik, ne yapmalıyız? Diyelim ki sadece spesifik bir order'da hata alınıyor, bu durumda bu order prod.order.placed'de kalmaya devam etsin ve daha sonra tekrar denesin ama bu topicteki diğer mesajlar da hata alan mesajı beklemeden işlenmeye devam etsin gibi bir şeyi nasıl yapabiliriz? Veya burada farklı bir yaklaşım mı izlemek gerekir?
Son olarak da, araştırdığımda dead letter queue yaklaşımı görüyorum ama orada da aklıma takılan şu: ya dead letter queu'ya atarken de sorun çıkarsa ne olacak? Yani topicteki mesajın kesinlikle ve kesinlikle kaybolmasını engellemenin bir yolu var mıdır?
Teşekkürler.
Selam Serkan, shipping kısmında hata aldığında yapleceğin 2 şey var
1. Eğer retry edilebilir bir hata ise, tekrar dene
2, Geri dönülemez bir hata ise, o zaman shipping failed diye mesaj gönder. Order service, bu order i failed olarak sonlandirir, be error reason olarak shipping i set eder.
Umarım anlaşılır olmuştur 🙂
@ teşekkürler açıklayıcı oldu. Fakat diyelim ki geri dönülemez bir hataydı ve 2. seçeneği yaptık, orada da shipping failed mesajı gönderirken fail oldu. Demek istediğim bu fail olma durumunu kaçıncı seviyeye kadar düşüneceğiz, böyle düşününce de gitgide işin içinden çıkılmaz hale geliyor :) Sanki daha ilk aşamada, ilk mesajı process edemediysek queue'da commit etmeme ve mesajı tekrar okuma ve daha sonra tekrar deneme yoluna gitmeliyiz diye düşünüyorum ama bunu nasıl yapabiliriz ve bu doğru bir yaklaşım mıdır?
@@loltr452 Eger hata olayi mesaj gonderirken oluyorsa orda bir problem var demektir. MEsela Kafka kullaniyorsan, kafka zaten durable bir sistemdir, cok az hata aliyor olman lazim. Ama hata alsan bile kullandigin client, retry etmeye hazir belirli bir sure retry eder. Mesaj okuma kisminda haklisin, commit olayi basarili durumda set edilmeli, ama mesaji gonderirken problem varsa, orda artik client retry olayina guvenmelisin. Ben bu gibi durumlar icin, uygulama loglarini ship ettigim icin log uzerinde alarm kuruyorum yani bana bir sekilde bildiriliyor. Bir de kafka metriklerini takip ediyorum, lag factor gibi
Çok güzel anlatmışsınız hocam. Ellerinize sağlık . Kafka Cluster ile ilgili video gelse çok güzel olur
umarim ileride o da olur :) Ama kanalda Debezium diye aratirsaniz Kafka ile ilgili icerik bulursunuz
@ onu da izlerim. teşekkürler
eline sağlık :) publish edilen mesajın farklı instancelarda dinlemesinde mesajın duplike olmamasına değindiniz mi? Kaçıncı dakikada paylaşabilir misiniz?
Dakikasını hatırlamıyorum ama muhtemelen bahsetmemişimdir, çünkü kafka kullanıyorsan, farklı instance lardan bile okusan, duplicated data almazsın. One Time Message Delivery garantisi var