Mikroservisler ve Dağınık Mimari üzerine şirket içi vermiş olduğum eğitim. Eğitim videosu: https://youtu.be/bYeF7aClyoQ Bahsettiğim konular: - Mikroservisler - Servis sınırları belirleme (Domain-driven design ve Bounded Context) - Asenkron ve olay tabanlı iletişim (event-driven architecture) - Veri birleştirme - CAP teoremi - Dağınık mimari hakkında yanılgılar - Diğer (Distributed lock, leader election, service discovery, event sourcing, change-data capture, Outbox pattern, Conflict-free Replicated Data Type, Service Mesh)

1. MIKROSERVISLER VE
DAĞINIK MIMARI
Armağan Ergon

2. BAŞLIKLAR
Mikroservisler
Servis sınırlarını belirleme
Asenkron ve olay tabanlı iletişim
Veri birleştirme
CAP teoremi
Dağınık mimari hakkında yanılgılar
Diğer
ARMAĞAN ERGON

3. MIKROSERVIS
Mikroservisler:
Birbirinden bağımsız
çalışabilen, herbiri tek bir işe
veya özelliğe odaklanmış ve
toplamda bir bütünü
oluşturan, olabilecek en ufak
boyutlarda servislerdir.
ARMAĞAN ERGON

4. MIKROSERVIS
Artıları:
Projeyi sorumlulukları daha net
olan parçalara bölmek
ARMAĞAN ERGON

5. MIKROSERVIS
Artıları:
Projeyi sorumlulukları daha net
olan parçalara bölmek
Boyut ve kapsam ufaklılığı
sayesinde geliştirme, bakımı ve
sürüm atımını kolaylaştırmak, bu
sayede uzun vadede geliştirmeyi
hızlandırmak
ARMAĞAN ERGON

6. MIKROSERVIS
Artıları:
Projeyi sorumlulukları daha net
olan parçalara bölmek
Boyut ve kapsam ufaklılığı
sayesinde geliştirme, bakımı ve
sürüm atımını kolaylaştırmak, bu
sayede uzun vadede geliştirmeyi
hızlandırmak
Farklı servislerde farklı
ölçeklendirme yapabilmek
ARMAĞAN ERGON

7. MIKROSERVIS
Artıları:
Projeyi sorumlulukları daha net
olan parçalara bölmek
Boyut ve kapsam ufaklılığı
sayesinde geliştirme, bakımı ve
sürüm atımını kolaylaştırmak, bu
sayede uzun vadede geliştirmeyi
hızlandırmak
Farklı servislerde farklı
ölçeklendirme yapabilmek
Sorunların daha izole hale
gelmesi.
ARMAĞAN ERGON

8. MIKROSERVIS
Artıları:
Projeyi sorumlulukları daha net
olan parçalara bölmek
Boyut ve kapsam ufaklılığı
sayesinde geliştirme, bakımı ve
sürüm atımını kolaylaştırmak, bu
sayede uzun vadede geliştirmeyi
hızlandırmak
Farklı servislerde farklı
ölçeklendirme yapabilmek
Sorunların daha izole hale
gelmesi.
Farklı servislerde farklı
teknolojilerin kullanılabilmesi
ARMAĞAN ERGON

9. MIKROSERVIS
Eksileri
Operasyonel kompleksite
ARMAĞAN ERGON

10. MIKROSERVIS
Eksileri
Operasyonel kompleksite
Yavaşlık (servis sınırları iyi
belirlenemezse)
ARMAĞAN ERGON

11. MIKROSERVIS
Eksileri
Operasyonel kompleksite
Yavaşlık (servis sınırları iyi
belirlenemezse)
Geliştirme ve test güçlükleri
(servis sınırları iyi
belirlenemezse)
ARMAĞAN ERGON

12. MIKROSERVIS
Eksileri
Operasyonel kompleksite
Yavaşlık (servis sınırları iyi
belirlenemezse)
Geliştirme ve test güçlükleri
(servis sınırları iyi
belirlenemezse)
Debug/Tracing güçlükleri
ARMAĞAN ERGON

13. MIKROSERVIS
Eksileri
Operasyonel kompleksite
Yavaşlık (servis sınırları iyi
belirlenemezse)
Geliştirme ve test güçlükleri
(servis sınırları iyi
belirlenemezse)
Debug/Tracing güçlükleri
Servisler arası transaction
kullanımının zor olması
veya hiç olamaması
ARMAĞAN ERGON

14. MIKROSERVIS
Eksileri
Operasyonel kompleksite
Yavaşlık (servis sınırları iyi
belirlenemezse)
Geliştirme ve test güçlükleri
(servis sınırları iyi
belirlenemezse)
Debug/Tracing güçlükleri
Servisler arası transaction
kullanımının zor olması veya
hiç olamaması
Foreign key olmaması
ARMAĞAN ERGON

15. MIKROSERVIS
Eksileri
Operasyonel kompleksite
Yavaşlık (servis sınırları iyi
belirlenemezse)
Geliştirme ve test güçlükleri
(servis sınırları iyi
belirlenemezse)
Debug/Tracing güçlükleri
Servisler arası transaction
kullanımının zor olması veya
hiç olamaması
Foreign key olmaması
Veri birleştirme güçlükleri
ARMAĞAN ERGON

16. MIKROSERVIS
Hedefler:
ARMAĞAN ERGON

17. MIKROSERVIS
Hedefler:
Dayanıklılık
Hatalarda sistemin güvenli bir şekilde çalışmaya devam etmesi
ARMAĞAN ERGON

18. MIKROSERVIS
Hedefler:
Dayanıklılık
Hatalarda sistemin güvenli bir şekilde çalışmaya devam etmesi
Ölçeklendirme
Hızlı cevap verebilen ve ihtiyaca göre kaynak arttırımı kolayca yapılabilecek
ARMAĞAN ERGON

19. MIKROSERVIS
Hedefler:
Dayanıklılık
Hatalarda sistemin güvenli bir şekilde çalışmaya devam etmesi
Ölçeklendirme
Hızlı cevap verebilen ve ihtiyaca göre kaynak arttırımı kolayca yapılabilecek
Bakımı kolay
Sürüm atımı, güncellemesi ve yönetimi kolay
ARMAĞAN ERGON

20. MIKROSERVIS
Peki Nasıl?
Bağımsızlık/otonomi (loosely
coupled) ve aitlik (high
cohesion)
ARMAĞAN ERGON

21. MIKROSERVIS
Bağımsızlık/otonomi (loosely
coupled):
Servislerin, modülerin ve
componentlerin birbirine minimum
bağımlılığa sahip olacak şekilde
tasarlanmasıdır.
ARMAĞAN ERGON

22. MIKROSERVIS
Bağımsızlık/otonomi (loosely
coupled):
Servislerin, modülerin ve
componentlerin birbirine minimum
bağımlılığa sahip olacak şekilde
tasarlanmasıdır.
Aitlik (high cohesion):
Belli bir amaca yönelik bütün
işlevselliğin bir arada bulunması ve
çalışması.
ARMAĞAN ERGON

23. MIKROSERVIS
Bağımsızlık/otonomi (loosely
coupled) ve aitliğin (high cohesion)
faydaları:
Esneklik
ARMAĞAN ERGON

24. MIKROSERVIS
Bağımsızlık/otonomi (loosely
coupled) ve aitliğin (high cohesion)
faydaları:
Esneklik
İzolasyon
ARMAĞAN ERGON

25. MIKROSERVIS
Bağımsızlık/otonomi (loosely
coupled) ve aitliğin (high cohesion)
faydaları:
Esneklik
İzolasyon
Modülerlik
ARMAĞAN ERGON

26. MIKROSERVIS
Bağımsızlık/otonomi (loosely
coupled) ve aitliğin (high cohesion)
faydaları:
Esneklik
İzolasyon
Modülerlik
Güncelleme kolaylığı
ARMAĞAN ERGON

27. MIKROSERVIS
Bağımsızlık/otonomi (loosely
coupled) ve aitliğin (high cohesion)
faydaları:
Esneklik
İzolasyon
Modülerlik
Güncelleme kolaylığı
Ölçeklendime kolaylığı
ARMAĞAN ERGON

28. MIKROSERVIS
Bağımsızlık/otonomi (loosely
coupled) ve aitliğin (high cohesion)
faydaları:
Esneklik
İzolasyon
Modülerlik
Güncelleme kolaylığı
Ölçeklendime kolaylığı
Test kolaylığı
ARMAĞAN ERGON

29. MIKROSERVIS
Mikroservis mimarisinin başarılı olabilmesi dikkat edilmesi gereken noktalar:
ARMAĞAN ERGON

30. MIKROSERVIS
Mikroservis mimarisinin başarılı olabilmesi dikkat edilmesi gereken noktalar:
Mantıksal sınırlar iyi belirlenip servis otonomisi sağlanmalı.
ARMAĞAN ERGON

31. MIKROSERVIS
Mikroservis mimarisinin başarılı olabilmesi dikkat edilmesi gereken noktalar:
Mantıksal sınırlar iyi belirlenip servis otonomisi sağlanmalı.
Her servisin verileri kendi şemasında olmalı ve veritabanları arasında işlem
yapılamamalı.
ARMAĞAN ERGON

32. MIKROSERVIS
Mikroservis mimarisinin başarılı olabilmesi dikkat edilmesi gereken noktalar:
Mantıksal sınırlar iyi belirlenip servis otonomisi sağlanmalı.
Her servisin verileri kendi şemasında olmalı ve veritabanları arasında işlem
yapılamamalı.
Bu ikisini sağlamak için beraber olması gereken kod ve veriler aynı servise alınmalı.
ARMAĞAN ERGON

33. MIKROSERVIS
Mikroservis mimarisinin başarılı olabilmesi dikkat edilmesi gereken noktalar:
Mantıksal sınırlar iyi belirlenip servis otonomisi sağlanmalı.
Her servisin verileri kendi şemasında olmalı ve veritabanları arasında işlem
yapılamamalı.
Bu ikisini sağlamak için beraber olması gereken kod ve veriler aynı servise alınmalı.
Servisler oluşturulurken nesnelere göre değil işlere göre oluşturulmalı
ARMAĞAN ERGON

34. MIKROSERVIS
Mikroservis mimarisinin başarılı olabilmesi dikkat edilmesi gereken noktalar:
Mantıksal sınırlar iyi belirlenip servis otonomisi sağlanmalı.
Her servisin verileri kendi şemasında olmalı ve veritabanları arasında işlem
yapılamamalı.
Bu ikisini sağlamak için beraber olması gereken kod ve veriler aynı servise alınmalı.
Servisler oluşturulurken nesnelere göre değil işlere göre oluşturulmalı
Servisler arası kod paylaşımı olmamalı
ARMAĞAN ERGON

35. MIKROSERVIS
Mikroservis mimarisinin başarılı olabilmesi dikkat edilmesi gereken noktalar:
Mantıksal sınırlar iyi belirlenip servis otonomisi sağlanmalı.
Her servisin verileri kendi şemasında olmalı ve veritabanları arasında işlem
yapılamamalı.
Bu ikisini sağlamak için beraber olması gereken kod ve veriler aynı servise alınmalı.
Servisler oluşturulurken nesnelere göre değil işlere göre oluşturulmalı
Servisler arası kod paylaşımı olmamalı
İletişim mümkün olduğunca asenkron olmalı
ARMAĞAN ERGON

36. MIKROSERVIS
Mikroservis mimarisinin başarılı olabilmesi dikkat edilmesi gereken noktalar:
Mantıksal sınırlar iyi belirlenip servis otonomisi sağlanmalı.
Her servisin verileri kendi şemasında olmalı ve veritabanları arasında işlem
yapılamamalı.
Bu ikisini sağlamak için beraber olması gereken kod ve veriler aynı servise alınmalı.
Servisler oluşturulurken nesnelere göre değil işlere göre oluşturulmalı
Servisler arası kod paylaşımı olmamalı
İletişim mümkün olduğunca asenkron olmalı
Başka servisleri sorgulama ve servisler arası veri paylaşımı olmamalı veya minimuma
indirilmeli.
ARMAĞAN ERGON

37. MIKROSERVIS
Mikroservis mimarisinin başarılı olabilmesi dikkat edilmesi gereken noktalar:
Mantıksal sınırlar iyi belirlenip servis otonomisi sağlanmalı.
Her servisin verileri kendi şemasında olmalı ve veritabanları arasında işlem
yapılamamalı.
Bu ikisini sağlamak için beraber olması gereken kod ve veriler aynı servise alınmalı.
Servisler oluşturulurken nesnelere göre değil işlere göre oluşturulmalı
Servisler arası kod paylaşımı olmamalı
İletişim mümkün olduğunca asenkron olmalı
Başka servisleri sorgulama ve servisler arası veri paylaşımı olmamalı veya minimuma
indirilmeli.
Servisin sahipliği net tanımlanmalı (tavsiye edilen 1 servis/1 takım)
ARMAĞAN ERGON

38. MIKROSERVIS
Mikroservis mimarisinin başarılı olabilmesi dikkat edilmesi gereken noktalar:
Mantıksal sınırlar iyi belirlenip servis otonomisi sağlanmalı.
Her servisin verileri kendi şemasında olmalı ve veritabanları arasında işlem
yapılamamalı.
Bu ikisini sağlamak için beraber olması gereken kod ve veriler aynı servise alınmalı.
Servisler oluşturulurken nesnelere göre değil işlere göre oluşturulmalı
Servisler arası kod paylaşımı olmamalı
İletişim mümkün olduğunca asenkron olmalı
Başka servisleri sorgulama ve servisler arası veri paylaşımı olmamalı veya minimuma
indirilmeli.
Servisin sahipliği net tanımlanmalı (tavsiye edilen 1 servis/1 takım)
Aksi taktirde olan şey distributed monolith haline gelir. Bu da kod geliştirmesi, çalışma
hızı, bakımı ve operasyonal kompleksitesi normal bir monolith’ten daha kötü bir
sisteme yol açar.
Yeterince bağımsızlık sağlanamazsa monolith’e devam edilmeli ARMAĞAN ERGON

39. MIKROSERVIS
Peki neden bağımsızlık ve aitlik bu kadar önemli?
ARMAĞAN ERGON

40. MIKROSERVIS
Peki neden bağımsızlık ve aitlik bu kadar önemli?
Aynı monolith’te çalışan veya birbirine çok bağımlı mikroservislerin
ekiplerinin yaşadıklarına birkaç örnek:
Sürüm atamıyoruz X ekibinin güncelleme yapması gerekiyor
ARMAĞAN ERGON

41. MIKROSERVIS
Peki neden bağımsızlık ve aitlik bu kadar önemli?
Aynı monolith’te çalışan veya birbirine çok bağımlı mikroservislerin
ekiplerinin yaşadıklarına birkaç örnek:
Sürüm atamıyoruz X ekibinin güncelleme yapması gerekiyor
Sürüm attık meğerse Y ekibi bizim servisi kullanıyormuş, güncelleme henüz
yapmadıkları için geri almak zorunda kaldık
ARMAĞAN ERGON

42. MIKROSERVIS
Peki neden bağımsızlık ve aitlik bu kadar önemli?
Aynı monolith’te çalışan veya birbirine çok bağımlı mikroservislerin
ekiplerinin yaşadıklarına birkaç örnek:
Sürüm atamıyoruz X ekibinin güncelleme yapması gerekiyor
Sürüm attık meğerse Y ekibi bizim servisi kullanıyormuş, güncelleme henüz
yapmadıkları için geri almak zorunda kaldık
Veritabanı şemasını/veriyi değiştiremiyoruz diğer servisler bu veriyi
kullanıyor
ARMAĞAN ERGON

43. MIKROSERVIS
Peki neden bağımsızlık ve aitlik bu kadar önemli?
Aynı monolith’te çalışan veya birbirine çok bağımlı mikroservislerin
ekiplerinin yaşadıklarına birkaç örnek:
Sürüm atamıyoruz X ekibinin güncelleme yapması gerekiyor
Sürüm attık meğerse Y ekibi bizim servisi kullanıyormuş, güncelleme henüz
yapmadıkları için geri almak zorunda kaldık
Veritabanı şemasını/veriyi değiştiremiyoruz diğer servisler bu veriyi
kullanıyor
API’yi güncelleyemiyoruz diğer ekipler bu servisi kullanıyor
ARMAĞAN ERGON

44. MIKROSERVIS
Peki neden bağımsızlık ve aitlik bu kadar önemli?
Aynı monolith’te çalışan veya birbirine çok bağımlı mikroservislerin
ekiplerinin yaşadıklarına birkaç örnek:
Sürüm atamıyoruz X ekibinin güncelleme yapması gerekiyor
Sürüm attık meğerse Y ekibi bizim servisi kullanıyormuş, güncelleme henüz
yapmadıkları için geri almak zorunda kaldık
Veritabanı şemasını/veriyi değiştiremiyoruz diğer servisler bu veriyi
kullanıyor
API’yi güncelleyemiyoruz diğer ekipler bu servisi kullanıyor
Z servisinin API’sini kullanıyorduk, Z servisi çöktü biz de isteklere cevap
veremez hale geldik
ARMAĞAN ERGON

45. MIKROSERVIS
Sonuç olarak bağımsız servisler :
Kod geliştirmeyi kolaylaştırır ve
hızlandırır.
Sistemin optimum hızda
çalışmasını sağlar
Çıkan sorunlara karşı sistemin
(nispeten) çalışmaya devam
edebilmesini sağlar
ARMAĞAN ERGON

46. MIKROSERVIS
Aksi taktirde:
ARMAĞAN ERGON

47. SERVIS SINIRLARI
Servislerde maksimum bağımsızlık ve otonomi sağlamak ve sınırları
iyi belirlemek için neler yapabiliriz?
ARMAĞAN ERGON

48. SERVIS SINIRLARI
Domain-driven design:
Gerçek dünyada var olan işleri yazılım ortamına aktararak iş
geliştirme sürecidir.
ARMAĞAN ERGON

49. SERVIS SINIRLARI
Domain-driven design:
Gerçek dünyada var olan işleri yazılım ortamına aktararak iş
geliştirme sürecidir.
Domain: var olan bir iş.
ARMAĞAN ERGON

50. SERVIS SINIRLARI
Domain-driven design örnek:
SİPARİŞ
KATALOG
DEPO
KARGO
ÖDEME
KULLANIC
I
ARMAĞAN ERGON

51. SERVIS SINIRLARI
Domain-driven design örnek:
SİPARİŞ
KATALOG
DEPO
KARGO
ÖDEME
KULLANIC
I
SİPARİŞ VERME SİPARİŞ İPTAL SİPARİŞ TAKİP
ÜRÜN LİSTELEME ÜRÜN DETAYI
STOK TAKİBİ STOK YENİLEME
KARGOYA VERME KARGO TAKİBİ
KULLANICI
YÖNETİMİ
KULLANICI ADRES
YÖNETİMİ
ÜRÜN FİYAT
YÖNETİMİ
ÖDEME ALMA
ARMAĞAN ERGON

52. SERVIS SINIRLARI
Bounded Context
Bir işi:
 daha ufak, idare etmesi daha
kolay
 sınırları belli
 birbirinden nispeten bağımsız
 sistemin geri kalanı olmasa da
bir noktaya kadar kendini ifade
edebilecek
 belli bir işe odaklı
daha ufak yapılandırmalara
bölmedir. ARMAĞAN ERGON
https://martinfowler.com/bliki/BoundedContext.html

53. SERVIS SINIRLARI
Bounded Context
Belirlemede teknik sınırlara
değil mantıksal sınırlara
bakılır.
Mantıksal sınırlarla kastedilen
modüller, servisler,
componentlerdir.
Aynı fiziksel sınır içerisinde
farklı mantıksal sınırlar
olabilir.
ARMAĞAN ERGON

54. SERVIS SINIRLARI
Bounded Context
Belirleme yöntemleri:
Eğer var olan bir monolith
bölünüyorsa var olan
takımlardan yola
çıkılabilinir.
ARMAĞAN ERGON

55. SERVIS SINIRLARI
Bounded Context
Belirleme yöntemleri:
Sıfırdan proje oluşturulurken
veya monolith takım
projelerine bölündükten sonra
ARMAĞAN ERGON

56. SERVIS SINIRLARI
Bounded Context
Belirleme yöntemleri:
Sıfırdan proje oluşturulurken
veya monolith takım
projelerine bölündükten sonra
Biz ne işler yaparız
SİPARİŞ
KATALOG
DEPO
KARGO
ÖDEME
KULLANIC
I
ARMAĞAN ERGON

57. SERVIS SINIRLARI
Bounded Context
Belirleme yöntemleri:
Sıfırdan proje oluşturulurken
veya monolith takım
projelerine bölündükten sonra
Biz ne işler yaparız
Bu işlerin içerisinde ne gibi
süreçler var
SİPARİŞ
KATALOG
DEPO
KARGO
ÖDEME
KULLANIC
I
SİPARİŞ VERME SİPARİŞ İPTAL SİPARİŞ TAKİP
ÜRÜN LİSTELEME ÜRÜN DETAYI
STOK TAKİBİ STOK YENİLEME
KARGOYA VERME KARGO TAKİBİ
KULLANICI
YÖNETİMİ
KULLANICI ADRES
YÖNETİMİ
ÜRÜN FİYAT
YÖNETİMİ
ÖDEME ALMA
ARMAĞAN ERGON

58. SERVIS SINIRLARI
Bounded Context
Belirleme yöntemleri:
Sıfırdan proje oluşturulurken
veya monolith takım
projelerine bölündükten sonra
Biz ne işler yaparız
Bu işlerin içerisinde ne gibi
süreçler var
Bu süreçlerden hangileri
diğerlerine olabildiğince az
bağımlı ve diğerlerine minimum
bağımlılıkla çalışabilir
SİPARİŞ
KATALOG
DEPO
KARGO
ÖDEME
KULLANIC
I
SİPARİŞ VERME SİPARİŞ İPTAL SİPARİŞ TAKİP
ÜRÜN LİSTELEME ÜRÜN DETAYI
STOK TAKİBİ STOK YENİLEME
KARGOYA VERME KARGO TAKİBİ
KULLANICI
YÖNETİMİ
KULLANICI ADRES
YÖNETİMİ
ÜRÜN FİYAT
YÖNETİMİ
ÖDEME ALMA
ARMAĞAN ERGON

59. ASENKRON VE OLAY TABANLI
ILETIŞIM
Asenkron iletişim
Event-driven mimari
ARMAĞAN ERGON

60. ASENKRON VE OLAY TABANLI
ILETIŞIM
Asenkron iletişim
Senkron iletişim bir istemcinin
RPC (remote procedure call)
yöntemi ile bir uzak noktadaki
metodu direkt çağırmasıdır.
ARMAĞAN ERGON

61. ASENKRON VE OLAY TABANLI
ILETIŞIM
Asenkron iletişim
Senkron iletişimdeki
sorunlardan biri:
Service 3 ile Service 4 arasında
iletişim sorunu olursa ne
olacak?
ARMAĞAN ERGON

62. ASENKRON VE OLAY TABANLI
ILETIŞIM
Asenkron iletişim
Servislerin birbirlerini
HTTP+JSON, gRPC, GraphQL,
WebSocket gibi RPC metodları ile
direkt olarak çağırması yerine bir
message broker aracılığıyla
mesaj iletilmesidir.
ARMAĞAN ERGON

63. ASENKRON VE OLAY TABANLI
ILETIŞIM
Asenkron iletişim
Nasıl çalışır:
Servisler ilgilendikleri mesaj tipleri
için merkezi bir message
broker’daki queue’lara abone
olurlar.
Gönderilen mesajlar message
broker’daki bu queue’lara
gönderilir, message broker
mesajları o mesaj tipiyle
ilgilendiğini belirtmiş olan
abone(ler)e iletir.
ARMAĞAN ERGON

64. ASENKRON VE OLAY TABANLI
ILETIŞIM
Asenkron iletişim
Faydaları:
ARMAĞAN ERGON

65. ASENKRON VE OLAY TABANLI
ILETIŞIM
Asenkron iletişim
Faydaları:
Servisler arası bağımsızlık
ARMAĞAN ERGON

66. ASENKRON VE OLAY TABANLI
ILETIŞIM
Asenkron iletişim
Faydaları:
Servisler arası bağımsızlık
Farklı servisleri farklı ihtiyaçlara göre
ölçeklendirme
ARMAĞAN ERGON

67. ASENKRON VE OLAY TABANLI
ILETIŞIM
Asenkron iletişim
Faydaları:
Servisler arası bağımsızlık
Farklı servisleri farklı ihtiyaçlara göre
ölçeklendirme
Dayanıklılık
• Mesaj kaybının önüne geçme
• Tekrar deneyebilme
ARMAĞAN ERGON

68. ASENKRON VE OLAY TABANLI
ILETIŞIM
Asenkron iletişim
Faydaları:
Servisler arası bağımsızlık
Farklı servisleri farklı ihtiyaçlara göre
ölçeklendirme
Dayanıklılık
• Mesaj kaybının önüne geçme
• Tekrar deneyebilme
Performans arttırma potansiyeli
 Non-blocking
 Düşük GC
 Anlık işlem (throughput)
ARMAĞAN ERGON

69. ASENKRON VE OLAY TABANLI
ILETIŞIM
Olay tabanlı mimari (event-driven
architecture)
ARMAĞAN ERGON

70. ASENKRON VE OLAY TABANLI
ILETIŞIM
Olay tabanlı mimari (event-driven
architecture)
Servislerin diğer servisleri direkt iletişim
kurarak çağırmaları yerine olay mesajları ile
haberleştikleri mimarı tasarımdır.
ARMAĞAN ERGON

71. ASENKRON VE OLAY TABANLI
ILETIŞIM
Olay tabanlı mimari (event-driven
architecture)
Servislerin diğer servisleri direkt iletişim
kurarak çağırmaları yerine olay mesajları ile
haberleştikleri mimarı tasarımdır.
Olay: sistemde gerçekleşmiş "bir şey".
ARMAĞAN ERGON

72. ASENKRON VE OLAY TABANLI
ILETIŞIM
Olay tabanlı mimari (event-driven
architecture)
Senkron çalışan alışveriş sitesinde sipariş:
1. Kullanıcı satın alır
2. Sipariş servisi ödeme isteği oluşturur
3. Ödeme servisi kargo gönderme isteği oluşturur
4. Kargo servisi bildirim gönderme isteği oluşturur
ARMAĞAN ERGON

73. ASENKRON VE OLAY TABANLI
ILETIŞIM
Olay tabanlı mimari (event-driven
architecture)
Olay tabanlı çalışan alışveriş sitesinde
sipariş:
1. Kullanıcı satın alır
2. Sipariş servisi "Sipariş Alındı" mesajı yayınlar
3. Ödeme servisi "Sipariş Alındı" alındı mesajını
yakalar ve ödemeyi alır
4. Ödeme servisi "Ödeme Tamamlandı" mesajı
yayınlar
5. Kargo servisi "Ödeme Tamamlandı" mesajını
yakalar ve kargo işlemini tamamlar
6. Kargo servisi "Kargoya Verildi" mesajı yayınlar
7. Bildirim servisi "Kargoya Verildi" mesajını yayınlar ARMAĞAN ERGON

74. ASENKRON VE OLAY TABANLI
ILETIŞIM
Olay tabanlı mimari (event-driven
architecture)
Faydaları:
ARMAĞAN ERGON
https://www.reactivemanifesto.org/

75. ASENKRON VE OLAY TABANLI
ILETIŞIM
Olay tabanlı mimari (event-driven
architecture)
Faydaları:
 Servisler arası bağımsızlık.
ARMAĞAN ERGON
https://www.reactivemanifesto.org/

76. ASENKRON VE OLAY TABANLI
ILETIŞIM
Olay tabanlı mimari (event-driven
architecture)
Faydaları:
 Servisler arası bağımsızlık.
 Farklı işlemleri farklı ihtiyaçlara göre
ölçeklendirme.
ARMAĞAN ERGON
https://www.reactivemanifesto.org/

77. ASENKRON VE OLAY TABANLI
ILETIŞIM
Olay tabanlı mimari (event-driven
architecture)
Faydaları:
 Servisler arası bağımsızlık.
 Farklı işlemleri farklı ihtiyaçlara göre
ölçeklendirme.
 Servis yapısında esneklik.
ARMAĞAN ERGON
https://www.reactivemanifesto.org/

78. ASENKRON VE OLAY TABANLI
ILETIŞIM
Olay tabanlı mimari (event-driven
architecture)
Faydaları:
 Servisler arası bağımsızlık.
 Farklı işlemleri farklı ihtiyaçlara göre
ölçeklendirme.
 Servis yapısında esneklik.
 Dayanıklılık
ARMAĞAN ERGON
https://www.reactivemanifesto.org/

79. ASENKRON VE OLAY TABANLI
ILETIŞIM
Olay tabanlı mimari (event-driven
architecture)
Faydaları:
 Servisler arası bağımsızlık.
 Farklı işlemleri farklı ihtiyaçlara göre
ölçeklendirme.
 Servis yapısında esneklik.
 Dayanıklılık
 Asenkron yapı
ARMAĞAN ERGON
https://www.reactivemanifesto.org/

80. ASENKRON VE OLAY TABANLI
ILETIŞIM
Olay tabanlı mimari (event-driven
architecture)
Diğer örnek kullanım alanları:
ARMAĞAN ERGON

81. ASENKRON VE OLAY TABANLI
ILETIŞIM
Olay tabanlı mimari (event-driven
architecture)
Diğer örnek kullanım alanları:
İş akışları
ARMAĞAN ERGON

82. ASENKRON VE OLAY TABANLI
ILETIŞIM
Olay tabanlı mimari (event-driven
architecture)
Diğer örnek kullanım alanları:
İş akışları
Üçüncü parti entegrasyonları
ARMAĞAN ERGON

83. ASENKRON VE OLAY TABANLI
ILETIŞIM
Olay tabanlı mimari (event-driven
architecture)
Diğer örnek kullanım alanları:
İş akışları
Üçüncü parti entegrasyonları
Veri paylaşımı
ARMAĞAN ERGON

84. ASENKRON VE OLAY TABANLI
ILETIŞIM
Zorlukları:
ARMAĞAN ERGON

85. ASENKRON VE OLAY TABANLI
ILETIŞIM
Zorlukları:
Operasyonel kompleksite
ARMAĞAN ERGON

86. ASENKRON VE OLAY TABANLI
ILETIŞIM
Zorlukları:
Operasyonel kompleksite
Debug/tracing/monitoring zorlukları
ARMAĞAN ERGON

87. ASENKRON VE OLAY TABANLI
ILETIŞIM
Zorlukları:
Operasyonel kompleksite
Debug/tracing/monitoring zorlukları
Performans (latency/overhead)
ARMAĞAN ERGON

88. ASENKRON VE OLAY TABANLI
ILETIŞIM
Zorlukları:
Operasyonel kompleksite
Debug/tracing/monitoring zorlukları
Performans (latency/overhead)
Test etme
ARMAĞAN ERGON

89. ASENKRON VE OLAY TABANLI
ILETIŞIM
Zorlukları:
Operasyonel kompleksite
Debug/tracing/monitoring zorlukları
Performans (latency/overhead)
Test etme
Güvenlik
ARMAĞAN ERGON

90. ASENKRON VE OLAY TABANLI
ILETIŞIM
Zorlukları:
Operasyonel kompleksite
Debug/tracing/monitoring zorlukları
Performans (latency/overhead)
Test etme
Güvenlik
Tamamen farklı bir düşünce yapısı
gerektirmesi
ARMAĞAN ERGON

91. TRANSACTION VE EVENTUAL
CONSISTENCY
ARMAĞAN ERGON

92. TRANSACTION VE EVENTUAL
CONSISTENCY
ACID
ARMAĞAN ERGON

93. TRANSACTION VE EVENTUAL
CONSISTENCY
ACID
Atomicity: Ya hepsi gerçekleşir ya da hiçbiri
ARMAĞAN ERGON

94. TRANSACTION VE EVENTUAL
CONSISTENCY
ACID
Atomicity: Ya hepsi gerçekleşir ya da hiçbiri
Consistency: Sistem istek öncesi, sırasında ve
sonrasında kararlı durumdadır
ARMAĞAN ERGON

95. TRANSACTION VE EVENTUAL
CONSISTENCY
ACID
Atomicity: Ya hepsi gerçekleşir ya da hiçbiri
Consistency: Sistem istek öncesi, sırasında ve
sonrasında kararlı durumdadır
Isolation: İstek işlemleri sistemin geri
kalanından izole durumdadır
ARMAĞAN ERGON

96. TRANSACTION VE EVENTUAL
CONSISTENCY
ACID
Atomicity: Ya hepsi gerçekleşir ya da hiçbiri
Consistency: Sistem istek öncesi, sırasında ve
sonrasında kararlı durumdadır
Isolation: İstek işlemleri sistemin geri
kalanından izole durumdadır
Durability: İstek sırasındaki bir sorun sistemi
kararsız halde bırakmaz
ARMAĞAN ERGON

97. TRANSACTION VE EVENTUAL
CONSISTENCY
Dağınık mimaride ACID
ARMAĞAN ERGON

98. TRANSACTION VE EVENTUAL
CONSISTENCY
Dağınık mimaride ACID
Atomicity: İstekler ayrı ayrı gerçekleşir
ARMAĞAN ERGON

99. TRANSACTION VE EVENTUAL
CONSISTENCY
Dağınık mimaride ACID
Atomicity: İstekler ayrı ayrı gerçekleşir
Consistency: İsteğin farklı anlarında sistem
kararsız durumda olabilir
ARMAĞAN ERGON

100. TRANSACTION VE EVENTUAL
CONSISTENCY
Dağınık mimaride ACID
Atomicity: İstekler ayrı ayrı gerçekleşir
Consistency: İsteğin farklı anlarında sistem
kararsız durumda olabilir
Isolation: İsteğin farklı noktalarında veri
kısmen okunabilir
ARMAĞAN ERGON

101. TRANSACTION VE EVENTUAL
CONSISTENCY
Dağınık mimaride ACID
Atomicity: İstekler ayrı ayrı gerçekleşir
Consistency: İsteğin farklı anlarında sistem
kararsız durumda olabilir
Isolation: İsteğin farklı noktalarında veri
kısmen okunabilir
Durability: İstek yarıda bırakacak hatalara
karşı korumazdır
ARMAĞAN ERGON

102. TRANSACTION VE EVENTUAL
CONSISTENCY
Transaction
Veritabanları ayrılığı nedeniyle standart transaction mümkün değil.
ARMAĞAN ERGON

103. TRANSACTION VE EVENTUAL
CONSISTENCY
Transaction
Veritabanları ayrılığı nedeniyle standart transaction mümkün değil.
Distributed transaction (2pc, XA) çözümleri var ancak kompleks ve
hantal.
ARMAĞAN ERGON

104. TRANSACTION VE EVENTUAL
CONSISTENCY
Transaction
Veritabanları ayrılığı nedeniyle standart transaction mümkün değil.
Distributed transaction (2pc, XA) çözümleri var ancak kompleks ve
hantal.
Geri alınması işlevselliği zorunlu durumlarda Saga Pattern
kullanılabilir.
ARMAĞAN ERGON

105. TRANSACTION VE EVENTUAL
CONSISTENCY
Transaction
Veritabanları ayrılığı nedeniyle standart transaction mümkün değil.
Distributed transaction (2pc, XA) çözümleri var ancak kompleks ve
hantal.
Geri alınması işlevselliği zorunlu durumlarda Saga Pattern
kullanılabilir.
En iyi yöntem transaction gereken verinin aynı serviste bir arada
bulunması.
ARMAĞAN ERGON

106. TRANSACTION VE EVENTUAL
CONSISTENCY
Dağınık Mimaride Tutarlılık (consistency)
Dağınık mimarideki tüm nodların veri isteklerine aynı cevabı ve
güncel veriyi dönüp dönmeyeceğidir.
ARMAĞAN ERGON

107. TRANSACTION VE EVENTUAL
CONSISTENCY
Dağınık Mimaride Tutarlılık (consistency)
Strong Consistency
Bir okuma isteği sistemdeki hangi sunucuya gönderilirse gönderilsin hep en
son yazma işleminde yazılmış güncel veriyi döner.
ARMAĞAN ERGON

108. TRANSACTION VE EVENTUAL
CONSISTENCY
Dağınık Mimaride Tutarlılık (consistency)
Eventual Consistency
Bir sunucuda gerçekleşmiş olan yazma isteğinin diğer sunuculara anında
değil bir süre sonra yansımasıdır.
ARMAĞAN ERGON

109. TRANSACTION VE EVENTUAL
CONSISTENCY
BASE
ARMAĞAN ERGON

110. TRANSACTION VE EVENTUAL
CONSISTENCY
BASE
Basic availability: Consistency yerine
availability’ye öncelik verme
ARMAĞAN ERGON

111. TRANSACTION VE EVENTUAL
CONSISTENCY
BASE
Basic availability: Consistency yerine
availability’ye öncelik verme
Soft-state: Sistem her anında tutarlı olma
sözü vermez
ARMAĞAN ERGON

112. TRANSACTION VE EVENTUAL
CONSISTENCY
BASE
Basic availability: Consistency yerine
availability’ye öncelik verme
Soft-state: Sistem her anında tutarlı olma
sözü vermez
Eventual consistency: Sistem yeterli süre
geçtiğinde tutarlı hale gelir
ARMAĞAN ERGON

113. VERİ BİRLEŞTİRME
ARMAĞAN ERGON

114. VERİ BİRLEŞTİRME
Her mikroservisin kendisine ait ayrı bir veritabanı veya şeması olması ve
servisler arası veri paylaşımı ya hiç ya da minimum olmalı.
Neden:
ARMAĞAN ERGON

115. VERİ BİRLEŞTİRME
Her mikroservisin kendisine ait ayrı bir veritabanı veya şeması olması ve
servisler arası veri paylaşımı ya hiç ya da minimum olmalı.
Neden:
Verinin sahipliği değişiyor
ARMAĞAN ERGON

116. VERİ BİRLEŞTİRME
Her mikroservisin kendisine ait ayrı bir veritabanı veya şeması olması ve
servisler arası veri paylaşımı ya hiç ya da minimum olmalı.
Neden:
Verinin sahipliği değişiyor
Bağlılık oluşuyor
ARMAĞAN ERGON

117. VERİ BİRLEŞTİRME
Her mikroservisin kendisine ait ayrı bir veritabanı veya şeması olması ve
servisler arası veri paylaşımı ya hiç ya da minimum olmalı.
Neden:
Verinin sahipliği değişiyor
Bağlılık oluşuyor
Bağımsızlık ve otonomi kaybediliyor
ARMAĞAN ERGON

118. VERİ BİRLEŞTİRME
Her mikroservisin kendisine ait ayrı bir veritabanı veya şeması olması ve
servisler arası veri paylaşımı ya hiç ya da minimum olmalı.
Neden:
Verinin sahipliği değişiyor
Bağlılık oluşuyor
Bağımsızlık ve otonomi kaybediliyor
Hangi servisteki hangi veri en güncel?
ARMAĞAN ERGON

119. VERİ BİRLEŞTİRME
Her mikroservisin kendisine ait ayrı bir veritabanı veya şeması olması ve
servisler arası veri paylaşımı ya hiç ya da minimum olmalı.
Neden:
Verinin sahipliği değişiyor
Bağlılık oluşuyor
Bağımsızlık ve otonomi kaybediliyor
Hangi servisteki hangi veri en güncel?
Veri yanlışsa?
ARMAĞAN ERGON

120. VERİ BİRLEŞTİRME
Ayrılan veriyi birleştirmek gerekebilecek yerler:
Arabirim
Veri birleştirme
Arama
ARMAĞAN ERGON

121. VERİ BİRLEŞTİRME
Arabirim
ARMAĞAN ERGON

122. VERİ BİRLEŞTİRME
Arabirim
Yöntem 1: API Gateway
ARMAĞAN ERGON

123. VERİ BİRLEŞTİRME
ARMAĞAN ERGON
Arabirim
Yöntem 2: Microfrontends

124. VERİ BİRLEŞTİRME
ARMAĞAN ERGON
Arabirim
Yöntem 3: ViewModel Composition

125. VERİ BİRLEŞTİRME
ARMAĞAN ERGON
Arabirim
Yöntem 3.5: Service Composition
BFF’in sadece model composition
işlevi gördüğü birleştirme yöntemi.

126. VERİ BİRLEŞTİRME
ARMAĞAN ERGON
Arabirim
Yöntem 3.5: Service Composition
1. Servisler ilgili modeller için paylaşıma açık
kod hazırlarlar
Örn: Stock.ViewModelComposition.Product

127. VERİ BİRLEŞTİRME
ARMAĞAN ERGON
Arabirim
Yöntem 3.5: Service Composition
1. Servisler ilgili modeller için paylaşıma açık
kod hazırlarlar
Örn: Stock.ViewModelComposition.Product
2. BFF’e servislere ait DLL referansları eklenir

128. VERİ BİRLEŞTİRME
ARMAĞAN ERGON
Arabirim
Yöntem 3.5: Service Composition
1. Servisler ilgili modeller için paylaşıma açık
kod hazırlarlar
Örn: Stock.ViewModelComposition.Product
2. BFF’e servislere ait DLL referansları eklenir
3. Servis açılışında registration’ların listesi
oluşturulur

129. VERİ BİRLEŞTİRME
ARMAĞAN ERGON
Arabirim
Yöntem 3.5: Service Composition
1. Servisler ilgili modeller için paylaşıma açık
kod hazırlarlar
Örn: Stock.ViewModelComposition.Product
2. BFF’e servislere ait DLL referansları eklenir
3. Servis açılışında registration’ların listesi
oluşturulur
4. İlgili sayfa isteğinde registration’lar gezilip
ilgili servisler belirlenir
http://.../product/123

130. VERİ BİRLEŞTİRME
ARMAĞAN ERGON
Arabirim
Yöntem 3.5: Service Composition
1. Servisler ilgili modeller için paylaşıma açık
kod hazırlarlar
Örn: Stock.ViewModelComposition.Product
2. BFF’e servislere ait DLL referansları eklenir
3. Servis açılışında registration’ların listesi
oluşturulur
4. İlgili sayfa isteğinde registration’lar gezilip
ilgili servisler belirlenir
5. Servisler çağırılıp modelde kendilerine ait
değerleri doldurmaları sağlanır
http://.../product/123

131. VERİ BİRLEŞTİRME
ARMAĞAN ERGON
Arama
Verisi farklı servislerde bulunan veri için arama veya raporlama nasıl
gerçekleştirilir?

132. VERİ BİRLEŞTİRME
ARMAĞAN ERGON
Arama
Yöntem 1: Bir servisten verileri çekip geri kalanları diğer servislerden
tamamlamak.
N+1 sorununa yol açar.

133. VERİ BİRLEŞTİRME
ARMAĞAN ERGON
Arama
Yöntem 2: Her servisin aramaya katılması
Generic arama servisi.
Her servis kendi sahip olduğu veri üzerinde otonom karar vermiş olur.
Yavaş olacaktır.

134. VERİ BİRLEŞTİRME
ARMAĞAN ERGON
Arama
Yöntem 3: Arama modeli
Denormalize edilmiş veri.
Otonomi için servisler aramaya filtre seviyesinde dahil olabilir.
Veriyi olay tabanlı mimari ile güncel tutmak gerekir.

135. CAP TEOREMİ
ARMAĞAN ERGON
https://en.wikipedia.org/wiki/CAP_theorem

136. CAP TEOREMİ
"Consistency, availability, partition
tolerance,
pick two"
- Eric Brewer
ARMAĞAN ERGON
https://en.wikipedia.org/wiki/CAP_theorem

137. CAP TEOREMİ
Consistency (tutarlılık): Her sunucuya yapılan
her istek en son ve güncel veriyi alır.
ARMAĞAN ERGON
https://en.wikipedia.org/wiki/CAP_theorem

138. CAP TEOREMİ
Availability (erişilebilirlik): Her isteğe hata
olmayan bir sonuç dönülmesi.
ARMAĞAN ERGON
https://en.wikipedia.org/wiki/CAP_theorem

139. CAP TEOREMİ
Partition tolerance (bölünme toleransı):
Sunucuların bir kısmının cevap verememesi
durumunda bile isteklere cevap verebilme.
ARMAĞAN ERGON
https://en.wikipedia.org/wiki/CAP_theorem

140. CAP TEOREMİ
A + P : Partition olduğu zaman bile isteklere
cevap verebilme ancak veri tutarlı olmayabilir.
ARMAĞAN ERGON
https://en.wikipedia.org/wiki/CAP_theorem

141. CAP TEOREMİ
C + P : Sunucular arası iletişim olduğu sürece
isteklere tutarlı cevap verebilme ancak
partition olduğu zaman tutarlılığı korumak için
isteklere cevap vermeyi durdurma.
ARMAĞAN ERGON
https://en.wikipedia.org/wiki/CAP_theorem

142. CAP TEOREMİ
C + A : Sistemin partition olmadığı sürece her
zaman tutarlı bir şekilde cevap verebilmesi.
ARMAĞAN ERGON
https://en.wikipedia.org/wiki/CAP_theorem

143. CAP TEOREMİ
C + A : Sistemin partition olmadığı sürece her
zaman tutarlı bir şekilde cevap verebilmesi.
Partition olduğunda ne olacak?
ARMAĞAN ERGON
https://en.wikipedia.org/wiki/CAP_theorem

144. CAP TEOREMİ
C+A mümkün değil o nedenle "pick two" yerine
şu şekilde düşünülmeli:
Partition olduğunda Consistency (C+P) veya
Availability (A+P) arasında seçim yapmak.
ARMAĞAN ERGON
https://en.wikipedia.org/wiki/CAP_theorem

145. DAĞINIK MİMARİ HAKKINDAKİ
YANILGILAR
ARMAĞAN ERGON

146. DAĞINIK MİMARİ HAKKINDAKİ
YANILGILAR
ARMAĞAN ERGON
1. Ağ sağlamdır

147. DAĞINIK MİMARİ HAKKINDAKİ
YANILGILAR
ARMAĞAN ERGON
1. Ağ sağlamdır
2. Ağ güvenlidir

148. DAĞINIK MİMARİ HAKKINDAKİ
YANILGILAR
ARMAĞAN ERGON
1. Ağ sağlamdır
2. Ağ güvenlidir
3. Gecikme yoktur

149. DAĞINIK MİMARİ HAKKINDAKİ
YANILGILAR
ARMAĞAN ERGON
1. Ağ sağlamdır
2. Ağ güvenlidir
3. Gecikme yoktur
4. Bant genişliği sınırsızdır

150. DAĞINIK MİMARİ HAKKINDAKİ
YANILGILAR
ARMAĞAN ERGON
1. Ağ sağlamdır
2. Ağ güvenlidir
3. Gecikme yoktur
4. Bant genişliği sınırsızdır
5. Bant genişliği ücretsizdir

151. DAĞINIK MİMARİ HAKKINDAKİ
YANILGILAR
ARMAĞAN ERGON
1. Ağ sağlamdır
2. Ağ güvenlidir
3. Gecikme yoktur
4. Bant genişliği sınırsızdır
5. Bant genişliği ücretsizdir
6. Ağ topolojisi değişmez

152. DAĞINIK MİMARİ HAKKINDAKİ
YANILGILAR
ARMAĞAN ERGON
1. Ağ sağlamdır
2. Ağ güvenlidir
3. Gecikme yoktur
4. Bant genişliği sınırsızdır
5. Bant genişliği ücretsizdir
6. Ağ topolojisi değişmez
7. Tek bir yönetici vardır

153. DAĞINIK MİMARİ HAKKINDAKİ
YANILGILAR
ARMAĞAN ERGON
1. Ağ sağlamdır
2. Ağ güvenlidir
3. Gecikme yoktur
4. Bant genişliği sınırsızdır
5. Bant genişliği ücretsizdir
6. Ağ topolojisi değişmez
7. Tek bir yönetici vardır
8. Ağ homojendir

154. DİĞER
ARMAĞAN ERGON

155. DİĞER
ARMAĞAN ERGON
Distributed Lock
Sunucular arasında kaynak erişimi
koordinasyonu için.
Örnek uygulamalar: Redis, ZooKeeper, Dapr
Örnek kullanım alanları: Dağınık
konfigürasyon, rate limiting, dağınık kaynak
erişimi
https://davidecerbo.medium.com/everything-i-know-about-distributed-locks-2bf

156. DİĞER
ARMAĞAN ERGON
Leader Election
Çoklu nod içeren sistemlerde
ana/koordinatör nodun hangisi olduğuna
karar verme.
Örnek algoritmalar: Paxos, Raft
Örnek uygulamalar: Veritabanları, RabbitMQ
(Quorum Queue), dağınık konfigürasyon
https://www.geeksforgeeks.org/raft-consensus-algorithm/

157. DİĞER
ARMAĞAN ERGON
Service discovery
Birden fazla sunucuya sahip
servislerde çağırılan servis
URL’inin hangi sunucuya
gideceğinin belirlenmesi.
Örnek uygulamalar: HashiCorp
Consul, Netflix Eureka, etcd
https://www.nginx.com/blog/service-discovery-in-a-microservices-architectur

158. DİĞER
ARMAĞAN ERGON
Event sourcing
Veri değişikliklerinin olaylar
zinciri olarak tutulmasıdır.
https://www.confluent.io/blog/event-sourcing-outgrows-the-database/

159. DİĞER
ARMAĞAN ERGON
Change-data Capture
Veritabanında olana değişikliklerin
yakalanıp başka bir sisteme
bildirilmesidir.
Örnek uygulama: Debezium
https://www.confluent.io/learn/change-data-capture/

160. DİĞER
ARMAĞAN ERGON
Outbox pattern
Servisler arası mesajların
direkt gönderilmek yerine
bir aracı yardımıyla
gönderilmesi.
https://microservices.io/patterns/data/transactional-outbox.html

161. DİĞER
ARMAĞAN ERGON
Conflict-free Replicated Data Type
(CRDT)
Çoklu kullanıcı ve çoklu nodlu
ortamlardaki aynı anda yapılan
değişikliklerin çakışmadan tüm
nodlarda nasıl uygulanacağını
belirleyen veri tipidir.
Örnek kullanım alanı: Google Docs
https://www.semanticscholar.org/paper/Partial-Replication-of-Conflict-Free-Replicated-Guerreiro-Hugo/6f8f3cbfb85e3aa7673714

162. DİĞER
ARMAĞAN ERGON
Service mesh
Çoklu sunucu mimarisinde sunucular
arası iletişim ve işlemleri
kolaylaştıracak altyapı sunan
uygalamalardır.
Örnek kullanım alanları: Service
discovery, load balancing,
monitoring, TLS, authN, authZ
Örnek uygulama: Istio, Linkerd,
Consul, Traefik Mesh
https://istio.io/latest/docs/ops/deployment/architecture/

163. ARMAĞAN ERGON
Teşekkürler