System Design

Geleneksel monolitik uygulamalarda, birden fazla varlık arasında veri tutarlılığının sağlanması basittir. İlişkisel veritabanı motorları, yerel SQL işlemlerine sarılmış ACID (Atomiklik, Tutarlılık, Yalıtım, Dayanıklılık) garantileri sağlar. Bir sipariş verme, ödeme kesintisi veya stok ayırma işlemi yarı yolda başarısız olursa ROLLBACK çağrısı, her veritabanı değişikliğini anında geri döndürür. Ancak modern bir Mikro Hizmet Mimarisine geçiş yapıldığında veri yönetimi temelden değişir. Etki alanı özerkliğini ve bağımsız ölçeklenebilirliği sağlamak için her mikro hizmet kendi özel veritabanına sahiptir. Bir e-ticaret ödemesinin işlenmesi gibi tek bir iş operasyonu artık birden fazla hizmet sınırını ve veritabanı motorunu (ör. Siparişler için PostgreSQL, Ödemeler için DynamoDB, Envanter için Redis) kapsıyor.

Modern olaya dayalı mikroservis mimarilerinde (Event-Driven Architecture), servisler durum değişikliklerini bildirmek için sürekli olarak OrderCreated veya PaymentProcessed gibi olaylar yayınlar. Ancak olay yayınlamayı %100 güvenilir hale getirmek ciddi bir mimari zorluktur: Veritabanı güncellemesi ile olay yayınlamanın aynı anda başarılı olmasını veya birlikte iptal edilmesini nasıl sağlarsınız? Bir mikroservis yerel veritabanını (PostgreSQL, MySQL) güncelledikten sonra ağ üzerinden mesaj kuyruğuna (Apache Kafka, RabbitMQ) mesaj göndermeye çalıştığında, ağ kesintileri veri tutarsızlığına yol açabilir.

Mikro hizmet mimarisinde hizmetler, dağıtılmış ağ aramalarından oluşan bir ağ oluşturur. Bu, ekiplerin hizmetleri bağımsız olarak oluşturmasına ve ölçeklendirmesine olanak tanırken, aynı zamanda sisteminizin genel güvenilirliğinin yalnızca en zayıf halkası kadar güçlü olduğu anlamına da gelir. Kritik bir hizmet çökerse veya yanıt vermez hale gelirse, tüm uygulamayı kesintiye uğratan basamaklı bir arızayı tetikleyebilir.

Mikro hizmet mimarisinde hizmetler, bellek içi çağrılar yerine ağ üzerinden iletişim kurar. Bu ayırma, büyük yatay ölçeklendirmeye ve bağımsız dağıtımlara olanak tanırken aynı zamanda büyük bir güvenlik açığını da beraberinde getirir: ağ güvenilmezdir. Herhangi bir anda, bir aşağı akış hizmetinde kısa bir ağ arızası, geçici bir CPU artışı, hızlı bir veritabanı kilit çekişmesi veya güncellemenin sürekli olarak yeniden başlatılması yaşanabilir. Bu geçici arızalar geçici arızalar olarak bilinir.

Mikro hizmet mimarisinde, tek bir uygulama düzinelerce veya yüzlerce bağımsız, işbirliği yapan hizmete bölünür. Bu tasarım modülerliği ve ölçeklenebilirliği geliştirirken aynı zamanda büyük bir riski de beraberinde getirir: bir hizmette meydana gelen bir arıza, tüm sistemi basamaklandırabilir ve çökertebilir. Bir aşağı akış hizmeti yavaşlar veya yanıt vermez hale gelirse, yukarı akış hizmetlerinize gelen istekler birikmeye başlar. Hepsi aynı belleği, CPU’yu veya iş parçacığı havuzunu paylaşıyorsa, yavaş bir bağımlılık mevcut tüm kaynakları hızla tüketebilir ve tüm uygulamanızın çökmesine neden olabilir.

Modern bulut tabanlı sistemlerde mikro hizmetlerin iş mantığını çalıştırmaktan çok daha fazlasını yapması beklenir. Günlüğe kaydetmeyi yönetmeli, SSL/TLS sertifikalarını yönetmeli, ölçümleri toplamalı, yeniden deneme mekanizmalarını uygulamalı ve diğer hizmetlerle güvenli iletişimi koordine etmelidirler. Tüm bu kesişen işlevleri doğrudan her uygulamanın kod tabanına yerleştirirsek, kod şişkinliği, sıkı bağlantı ve dil kilitlenmesiyle sonuçlanırız. Sidecar Pattern tam da bu noktada devreye giriyor. Bu kılavuzda Sidecar modelinin ne olduğunu, modern mikro hizmet mimarileri için neden önemli olduğunu ve basit benzetmeler ve Kubernetes yapılandırma örneklerini kullanarak nasıl çalıştığını açıklayacağız.

Modern yazılım mühendisliğinde eski monolitik uygulamalar yaygın bir zorluktur. Başarılı bir kod tabanı zamanla o kadar büyür ve birbirine bağlanır ki, basit değişiklikler yapmak riskli hale gelir, dağıtımlar saatler alır ve bireysel özellikleri ölçeklendirmek neredeyse imkansızdır. Ekipler mikro hizmetlere geçerek sistemlerini modernleştirmeye karar verdiğinde önemli bir soruyla karşı karşıya kalırlar: Mevcut işimizi bozmadan sistemi nasıl yeniden yazabiliriz?

Mikro hizmet mimarisinde sistemlerimiz Kullanıcı Hizmeti, Sipariş Hizmeti ve Ürün Hizmeti gibi düzinelerce küçük, odaklanmış hizmete bölünmüştür. Ancak iş bu bilgiyi kullanıcılarınıza göstermeye gelince, farklı cihazların çok farklı ihtiyaçları vardır. Yüksek hızlı bir masaüstü bilgisayardaki bir web tarayıcısı; tablolar, kenar çubukları ve grafiklerle dolu zengin bir kontrol paneli ister. Yavaş bir hücresel ağdaki mobil uygulama, bant genişliğinden ve pilden tasarruf etmek için basit, hafif bir düzen istiyor. Bir akıllı saat uygulaması yalnızca tek satırlık bir metne ihtiyaç duyabilir.

Tek, yekpare bir uygulamadan mikro hizmet mimarisine geçiş birçok sorunu çözer. Ekiplerin bağımsız çalışmasına, hizmetleri ayrı ayrı dağıtmasına ve sistemin parçalarını gerektiği gibi ölçeklendirmesine olanak tanır. Ancak bu aynı zamanda yeni bir zorluğu da beraberinde getiriyor: Müşteriler tüm bu bağımsız hizmetlerle nasıl etkileşime giriyor? On, elli veya yüzlerce küçük mikro hizmetiniz varsa, bir mobil uygulama veya web sayfası bunların her birine doğrudan bağlanmalı mı?

Kuruluşlar monolitik bir mimariden mikro hizmetlere geçiş yaptıklarında kritik ve önemli bir soruyla karşı karşıya kalırlar: Hizmetlerimizin sınırlarını nasıl çizeriz? Teorik olarak mikro hizmetler, bağımsız olarak geliştirilebilen, dağıtılabilen ve ölçeklendirilebilen gevşek, ayrılmış birimler olmalıdır. Ancak pratikte pek çok ekip sonunda dağıtılmış bir monolit inşa ediyor; bu sistem, hizmetlerin çok sıkı bir şekilde birbirine bağlandığı, tek bir iş değişikliğinin birden fazla hizmetin aynı anda değiştirilmesini ve dağıtılmasını gerektirdiği, ağ gecikmesini ve dağıtım sorunlarını bir araya getiren bir sistem.