This document discusses microservices, distributed computing, and the CAP theorem. It provides motivation for scaling applications using microservices and distributed systems by discussing increasing internet traffic over time. It introduces concepts of vertical and horizontal scaling. It discusses distributed system fundamentals of consistency, availability, and partition tolerance. It explains the CAP theorem and tradeoffs between consistency, availability and partition tolerance. It discusses data management approaches of ACID and BASE and types of consistency like strong, weak and eventual consistency.
11. HOW TO HANDLE MORE TRAFFIC?
● SCALING
○ SCALE UP - VERTICAL SCALING
○ SCALE OUT - HORIZONTAL SCALING
12. VERTICAL SCALING
● Adding more resources to the server
● Advantages
○ No extra development
○ Less Networking
○ Better for process intensive apps
● Disadvantages
○ Extra Cost
○ Risky
13. HORIZONTAL SCALING
● Adding more servers w/ less capacity.
● Advantages
○ $ $ $ CHEAPER $ $ $
○ More fault tolerant
○ Better for enterprise apps
● Disadvantages
○ Complex design
○ More Networking
26. FUNDAMENTALS - CONSISTENCY
● Every read receives the most recent write or an
error.
● ex. If I get my cart on my shopping site, it must
contain all the previously added items.
27. FUNDAMENTALS - AVAILABILITY
● Every request receives a (non-error) response –
without guarantee that it contains the most recent
write
● ex. I will eventually Access my shopping cart.
28. FUNDAMENTALS - PARTITION TOLERANCE
● The system continues to operate even if there is a
partition / communication break
● ex. I should go shopping on my shopping site in a
partition.
29. CAP THEOREM
● “Of three properties of shared-data
systems (Consistency, Availability and
tolerance to network Partitions) only two
can be achieved at any given moment in
time.”
● 2000: Eric Brewer, PODC conference
keynote
33. AP - BEST EFFORT CONSISTENCY
● Relax consistency in order to achieve
full availability.
● Optimistic locking
● Hazelcast, CouchBase, Cassandra
34.
35. DATA MANAGEMENT - ACRONYMS
● ACID
○ Traditional monolith systems
○ RDBMS
● BASE
○ Distributed Systems
36. ACID
● ATOMIC
○ each transaction be "all or nothing"
● CONSISTENT
○ any transaction will bring the database from one valid state to another
● ISOLATED
○ transactions doesn’t interfere / concurrency
● DURABLE
○ once a transaction has been committed, it will remain so
37. BASE
● BASICALLY AVAILABLE
○ System mostly available and there might be subsystems temporarily
unavailable
● SOFT STATE
○ The state of system could change over time, even without any input.
● EVENTUAL CONSISTENT
○ Eventually all accesses will return the last updated value
38. CONSISTENCY TYPES
● STRONG CONSISTENCY
○ All subsequent accesses return the updated value after the update.
● WEAK CONSISTENCY
○ Subsequent accesses might not always be returning the updated value.
● EVENTUAL CONSISTENCY
○ Given, if no new updates to a data item, eventually all accesses to that
item will return the last updated value
39. EVENTUAL CONSISTENCY - EXAMPLES
● ALIEXPRESS
○ Payment
● INSTAGRAM
○ New follower
● SHAKE SHACK
○ Shaking Control
-BİLGİSAYAR MÜH
-7 YILDIR BİLİŞİM SEKTÖRÜNDE ÇALIŞIYORUM
-5 YILDAN BERİ MİKROSERVİS MİMARİLERİ TASARLIYORUM
VE AKTİF OLARAK BU MİMARİLERDE ÇALIŞIYORUM
-3 YILDAN BERI KLOIA’DA MÜŞTERİLERİMİZE YAZILIM MİMARİLERİ,
TEST VE DEVOPS SÜREÇLERİNİN OTOMASYONU KONULARINDA DANIŞMANLIK YAPIYORUM
-MIKROSERVIS SEBEP
-SCL- ÖLÇEKLEME
-DAĞITIK HESAPLAMA TEMEL
- CAP THEOREM
-DATA MNG ACRONY / VERİ YNTM KISALTMA
-CONSISTENCY / TUTARLILIK
-NİHAİ TUTAR
-APPLICATION LOGIC APPTA
-TÜM DATA DB’de
- YEKPARE
→ÖRN TOMCATTE KOŞAN UYGULAM
→ARKADA MYSQL
→BASİT BİR WEB APP
→DEVELOP+TEST+DEBUG+YEDEK
***APPLICATION COMPLEXITY
*** HANDLING LOAD
PEKİ BİZİM BU UYGULAMAMIZ
→NASIL TRAFİĞİ & YÜKÜ KALDIRACAK?
PEKİ NE YAPIYORUZ?
→UYGULAMALARIMIZI SCALE EDİYORUZ
→SCALING DE DİKEY VE YATAY OLARAK 2
→VAR OLAN SİSTEM/UYG EXTRA KAYNAK
→CPU MEMORY
→BİZE SAĞLADIĞI
→DEZAVANTAJI NEDİR?
→COST INEFECTIVE
→RİSKLİ
→SINGLE POINT OF FAİLURE
STND KAPST YENİ SİST/UYG EK
UPGRADE YERİNE YENİ SİSTEM
DATA CENTER’ İHTİYAC YOK
CLOUD
BETTER FOR ENTERPRİSE
PEKİ HANGİSİNİ TERCİH ETMELİYİZ??
→HORIZONTAL SCALING
DAHA COST EFECTIVE
→SON YILLARDAKİ CLOUD TRENDİ ile beraber
→ NO COST FOR DATA CENTERS etc.
OK ÇOK GÜZEL
→HORIZONTAL AMA NASIL?
BİRAZ HORİZONTAL SCALING
METODOLOJİLERİNİ ÜZERİNE
ÇALIŞMAMIZ LAZIM
-MİCHAEL FİSHER → THE ART OF SCALABİLİTY
-3 BOYUTLU BİR SCALABİLİTY MODEL
-MODELİMİZİN ADI SCALE CUBE
-YATAY SCALE TEKN TEMSİL EDİYOR
-3D UZAYDAKİ X,Y,Z EKSEN BENZETİYOR
-ORİJİN NOKTASI → MONOLITH SAĞ ÜST KÖŞE → MAKSIMUM SCALE
-→SO → x,y,z tek başına değil →HEPSİ BİR ARADA DA OLABİLİR
→YATAY KLONLAMA
+ LB ARKSINDA N TANE KLONLA
+ HER BİR KLON 1/N LOAD
+ EN YAYGINI BU, BASİT AMA
- BÜTÜN KLONLAR AYNI DB ERİŞ
- HALA KOMPLEX MONOLITH UYG
+ X YERINE→ANLAMSAL&FONK DEĞER
+ HER SERVİS BİR GÖREV ÜSTLEN
+ PARÇALAMA→NOUNve VERB
+ POLYGLOT PER → ÇOK DİLLİ
+ BEST PRACTİCE ENTİTY CAPABİL
MULTI RESOURCE DATA MGMT
NETWORKING
+ X YERINE→ANLAMSAL&FONK DEĞER
+ HER SERVİS BİR GÖREV ÜSTLEN
+ PARÇALAMA→NOUNve VERB
+ POLYGLOT PER → ÇOK DİLLİ
+ BEST PRACTİCE ENTİTY CAPABİL
MULTI RESOURCE DATA MGMT
NETWORKING
+ X YERINE→ANLAMSAL&FONK DEĞER
+ HER SERVİS BİR GÖREV ÜSTLEN
+ PARÇALAMA→NOUNve VERB
+ POLYGLOT PER → ÇOK DİLLİ
+ BEST PRACTİCE ENTİTY CAPABİL
MULTI RESOURCE DATA MGMT
NETWORKING
+ X GİBİ →AYNI UYG KLONLUYOR
+ HER KLON → FARKLI DATA ALTKÜME
+ SHARDED DATABASES
+ ROUTING KRİTERLERİ (van)
+ FARKLI UYG. AYNI DATA ERŞ. YOK
YİNE HİGH APP COMPLEX
DB PARTITIONING SCHEMA LAZIM
SCALE CUBE DE DE GÖRDÜ GİBİ
→SADECETEK YÖN ZORUNLU DEİL
→ÖRNEĞİN BURDA MİKROSERVİS
→VE HER BİR SERVİS X AXİS SCALING
HANGİ METODU KULLANIRSAK KULL
İHTİYACIMIZ
NETWORK ÜZERİNDE PAYLAŞILAN RESOURCE
NETWORK PROGRAMLAMA
THAT REQUIRES DISTRIBUTED COMPUTING
HANGİ METODU KULLANIRSAK KULL
İHTİYACIMIZ
NETWORK ÜZERİNDE PAYLAŞILAN RESOURCE
NETWORK PROGRAMLAMA
THAT REQUIRES DISTRIBUTED COMPUTING
CONSİSTENCY
→TUTARLILIK
→ TEK BİR KOPYA GİBİ GÖZÜKMESİ
→HER KOPYADA AYNI DURUMDA OLMA
TEML ÖZELK→BİR ENTITY için HER ZMN EN GÜNCEL DEĞERİ OKU
CART→GÜNCEL, Önceki TÜM EKLEDİK
STOK→STOK İLE 2 KİŞİ İŞLEM YAPIYORS DEĞİŞTİĞİNDE→DİĞERİ DE İŞLEM
CONSISTENCY → HEP İSTERİZ ?????
İSMİNDEN DE ANLAŞILDIĞI ÜZERE
SİSTEMİMİZİN HER ZAMAN MEVCUDİYET/MÜSAİT/HAZIR
→Yazmak istiyorsam yazmalıyım
→Okumak istiyorsam okumalıyım
→Sistemim HİÇ → System Unavailable
CART→önceki ekledikle olsada olmasada
STOK→Eksik de olsa fazla da olsa
AVALABILITY OLMALI MI??
SPLİT BRAİN
KORPUS KALLOSUM BEYNİN 2LOB ARSIN NETWORK MADDE
KORPUS KALLOSUM’un kopması PARTİTİON
ORACLE PARTITION
SINCE DISTR→Som tims Seperated
Any Network Breaking might cause Components cant talk
Hayati işlemlerine devam edebilmesi
Fault tolerance → hataya dayanıklılık, doğru senaryo, uç senaryo
FAULT TOLERANCE INEVITABLE
TEMEL ÖZELLİKLERDEN
HEPSİ GÜZEL HEPSİNİ İSTİYORUZ
SİSTEMİMİZDEAMA İMKANSIZ
ERİC BREWER’a göre
Distributed bir sistemde aynı anda
→Hem Consistency
…
→SAĞLANAMAZ
→ NOSQL veritabanları da burdan başlıyor
→CAP ÜÇGENE BENZETİRSEK
→DİSTRİBUTED MAX. 1 KENARDA OLA
→MERKEZDE OLAMAZ
→Her Bir KENARI İNCELEYELİM
** SCALING→ P SEÇENEK DEİL, İHTİYAÇ
** ASLINDA SEÇİM C ve A arasında
** Ve genelde A > C
→CP→STRONG CONS W P
→TAMAMEN UNAVAİLBALE DEĞİL
→P OLDUĞUNDA C İÇİN UNAVAİLABLE
→GENELDE PESİMİLOCK BİLEN ????
→CRİTİCAL SECTİON VS.
→ÇOK COLLİSİON BEKLERSEK İYİ
→HEP İNCONSİSTENT DEĞİL
→ HATALAR DÜZELTİLİR AMA ZAMAN/KAÇAN GERİ GELMEZ
→OPTİMİSTİC LOCK ?? ATOMİC CAS
READ EDRKN GET VERSİON, TİME, HASH
YAZARKEN KARŞILAŞTIR
→LESS COLLUSIONS(less write more read)
→ CACHE, HAZELCAST, SPLİT BRAİN
-ÇEŞİTLİ NOSQL DB’LERİN CAP ÜÇGENİNDE NEREYE TEKABÜL ETTİĞİ
DATA MGMT AKRONİM ÖNCESİ
-SİSTEMİN HER PARÇASI AYNI METODU ZORUNDA DEĞİL
-ÖRN. FİNANSAL İŞLEMLERDE, TUTARLILIK ÖNEMLİ FAVOR CP
-ÖRN. ALIŞVERİŞ UYGULAMAMDA ÜRÜN SAYFASI, FAVOR AP
-İKİSİ DE ÖNEMLİ AMA SCALİNG ÖNEMLİ DEĞİL, FAVOR CA
MULTI RESOURCE DATA YÖNETEN SİST
ÖZELLİKLERİNİ BELİRETN KISALTMALAR
→Eskiden sadece ACID vardı
→CAP Theorem ve Dists System Yayg
→DİSTRİBUTED ACID imkansız olunca
→BASE ortaya atıldı
→BASE gerekli oldu özellikle NOSQL
A→TRANSACTION/İŞLEM SİLSİLESİ, ya hep ya hiç
C→** CAP→HER KOPYADA AYNI DEĞER, TEKMİŞ GİBİ DAVRAN
** TUTARSIZLIK OLMAMASI. ÖRN. USER.AGE NEGATIVE
I→Transactionlar’ın birbiri ile çakışmaması
Aynı entityde 1den fazla trans yok
D→txn bittiğinde, hatırlanma, persistence ELEKTRİK FİŞİ
ACID Alternatifi
BA→OLABİLDİĞİNCE MEVCUT/AVAILABLE olacak
** Bazen unavailable olabilir
S→Eventual C. Dolayı Sistemin State’i
Dışarıdan yeni input olmadan da değş
EC→Yeni bir update gelmezse bir dataya
Nihai olarak o data consistent bir state
→BEFORE EVENTUAL EXAMPLE
STRONG→CURRENT ONE
** TWITTER every F5 → previously added
WEAK→ NOT ALWAYS but
EVENTUAL CONSIS→Special form
** TWIT BOMBARDIMANI OLMADIĞI SÜRECE
** GUARANTEED
** STOP UPDATE → Consistent
ŞİMDİYE KADAR
SCALING BASICS
DISTRIBUTED SYS PITFALLS
CAP THEOREM
ACID BASE
MICROSERVIS YONETMEK
BIRBIRI ILETISIM
ŞİMDİYE KADAR
SCALING BASICS
DISTRIBUTED SYS PITFALLS
CAP THEOREM
ACID BASE
MICROSERVIS YONETMEK
BIRBIRI ILETISIM