İstemci-sunucu mimarisi

1.1 Uygulama mimarisi

Bu kurs yeni başlayanlar için tasarlanmıştır çünkü ciddi bir uygulamanın mimarisini uzun süre tasarlamayacaksınız. Ancak endişelenmeyin, iyi mimari kuraldan çok istisnadır. Uygulamayı oluşturmadan önce doğru uygulama mimarisini seçmek çok zordur .

Büyük sunucu uygulamaları için popüler mimari örnekleri:

• Katmanlı mimari (Katmanlı Mimari).
• Katmanlı Mimari.
• Hizmet Odaklı Mimari (SOA).
• Mikro hizmet mimarisi (Mikro hizmet Mimarisi).

Her birinin artıları ve eksileri vardır. Ancak onları incelemek size hiçbir şey kazandırmaz. Mimarlık , "sistem içindeki binlerce nesnenin etkileşimi nasıl düzenlenir" sorusunun cevabıdır . Ve sorunun tüm karmaşıklığını deneyimleyene kadar, çözümün çok yönlülüğünü tam olarak anlayamayacaksınız.

Tüm uygulamalar bir tür mimari kullanır veya en azından kullanıyormuş gibi yapar. Bu nedenle, uygulama tasarımına yönelik popüler yaklaşımlar hakkında bilgi sahibi olmak, uygulamanın nasıl çalıştığını hızlı ve daha iyi anlamanıza olanak tanır. Ve bu, tam olarak ihtiyaç duyduğunuz yerde değişiklik yapmak anlamına gelir.

"Gerektiğinde değişiklik yapmak" ne anlama geliyor? Değişiklik yapmanız gerekmeyen yerler var mı? Kesinlikle.

Açık olmak gerekirse, orta düzeyde bir arka uç projesi üzerinde çalıştığınızı varsayalım . 5 yıldır 20 kişilik bir ekip tarafından yazılmıştır. Proje 100 adam-yıl sürdü ve yaklaşık 100 bin satır kod içeriyor. Toplamda, farklı boyutlarda 10 modüle bölünmüş iki bin sınıftan oluşur.

Ve sert bir gerçeklik ekleyin. Bazı görevlerin mantığı birkaç modüle yayılmıştır. Ayrıca, iş mantığı ön uçta (JavaScript ile yazılmış) olabilir ve/veya doğrudan veritabanında saklı bir prosedür olarak yazılabilir. Değişiklikleri tam olarak nerede yapacağınızı hemen belirleyebileceğinizden hâlâ emin misiniz ?

Bu seni korkutmak için uydurduğum bir kabus değil. Bu tipik bir projedir. Daha da kötüsü olur. Bu neden oluyor? Herhangi bir sayıda neden olabilir, ancak neredeyse her zaman bunlar vardır:

• Projede pek çok insan çalışıyor - her biri onu biraz farklı görüyor.
• 5 yıldır projede 10 kişi değişti yeni gelenler pek anlamadı.
• Yazılım oluşturmak, sürekli olarak her şeyi değiştiren değişiklikler yapmaktır.
• Beş yıl önce mimariye karar verdiğimizde proje fikri biraz farklıydı.

Ancak asıl önemli olan, projenin mimarisi ne olursa olsun, üzerinde çalışan tüm programcıların bu projenin nasıl çalıştığı konusunda aynı anlayışa bağlı kalmasıdır. En basit konsept olan istemci-sunucu mimarisiyle başlayalım.

1.2 İstemci-sunucu etkileşimi kavramı

Şimdi istemci-sunucu mimarisinin altında yatan konsepti anlayacağız ve milyonlarca programın İnternet üzerindeki etkileşiminin nasıl organize edildiğini daha iyi anlamanıza izin vereceğiz.

Adından da anlaşılacağı gibi, bu kavram iki tarafı içerir: istemci ve sunucu . Burada her şey hayattaki gibidir: müşteri şu veya bu hizmetin müşterisidir ve sunucu, hizmet sağlayıcıdır. İstemci ve sunucu fiziksel olarak programlardır , örneğin tipik bir istemci bir tarayıcıdır .

Sunucu olarak şu örnekler verilebilir:

• Tomcat gibi web sunucuları.
• MySQL gibi veritabanı sunucuları.
• Stripe gibi ödeme ağ geçitleri.

İstemci ve sunucu genellikle İnternet üzerinden iletişim kurar (ancak aynı yerel alan ağında ve genel olarak diğer herhangi bir ağ türünde çalışabilirler). İletişim, HTTP, FTP gibi standart protokoller veya TCP veya UDP gibi daha düşük seviyeli protokoller üzerinden gerçekleşir.

Protokol genellikle sunucuların sağladığı hizmet türüne göre seçilir. Örneğin, bu bir görüntülü görüşme ise, genellikle UDP kullanılır.

Tomcat ve servlet'lerinin nasıl çalıştığını hatırlıyor musunuz? Sunucu bir HTTP mesajı alır, paketini açar, oradan gerekli tüm bilgileri çıkarır ve işlenmek üzere sunucu uygulamasına iletir. Ardından, işleme sonucu bir HTTP yanıtı olarak paketlenir ve istemciye gönderilir.

Bu, tipik istemci-sunucu etkileşimidir. Tarayıcı, web istemcisidir ve Tomcat, web sunucusudur. Tomcat'e web sunucusu bile denir.

Ama düşünürseniz, önemli olan isim değil, öz - rollerin programlar arasında dağılımı. Bir HTML sayfasında çalışan JS betiğinize pekala bir istemci ve servlet'inize bir sunucu denilebilir . Sonuçta, istemci-sunucu konsepti çerçevesinde çiftler halinde çalışırlar .

1.3 Önemli bir nüans

İstemci-sunucu etkileşiminin, bu tür etkileşimin istemci tarafından başlatılması ilkesine dayandığını da belirtmekte fayda var : sunucu yalnızca istemciye yanıt verir ve istemciye hizmeti sağlayıp sağlayamayacağını ve eğer öyleyse, hangi koşullar altında olduğunu bildirir. .

İstemcinin fiziksel olarak nerede olduğu ve sunucunun nerede olduğu önemli değildir. İstemci yazılımı ve sunucu yazılımı genellikle farklı makinelere kurulur, ancak aynı bilgisayarda da çalışabilirler.

Bu konsept, karmaşık bir sistemi basitleştirmeye yönelik ilk adım olarak geliştirildi. Şu güçlü yönlere sahiptir:

• Mantık basitleştirme : sunucu, istemci ve gelecekte verilerini nasıl kullanacağı hakkında hiçbir şey bilmiyor.
• Zayıf istemciler olabilir : yoğun kaynak kullanan tüm görevler sunucuya aktarılabilir.
• İstemci kodunun ve sunucu kodunun bağımsız gelişimi.
• Pek çok farklı istemci, örneğin Tomcat ve farklı tarayıcılar.

İstemci ve sunucu arasındaki etkileşimin en temel versiyonu resimde gösterilmektedir:

Burada iki ayrıntıya dikkat etmek önemlidir. İlk olarak, resim birçok istemcinin bir sunucuya erişebileceğini göstermektedir. İkincisi, aynı anda erişebilirler. Bu aynı zamanda sunucunun önemli bir parçasıdır.

Bir müşteri genellikle bir kullanıcıyla etkileşime girer, bu nedenle çoğu zaman orada yetkilendirme bile gerekmez. Ancak, sunucu binlerce istemciden gelen istekleri işler ve bunun için kod geliştirirken, yetkilendirme ile kimlik doğrulamayı ayırt edebilmeniz gerekir.

Sunucunun binlerce isteği paralel olarak işlemesi de önemlidir. Ve bu, arka uç kodunu geliştirirken, kaynaklara eşzamanlı erişim görevini sürekli olarak düşünmeniz gerekeceği anlamına gelir. Ayrıca, sunucu kodunun çok yüksek bir yarış durumu (thread yarışı), kilitlenme (thread'lerin karşılıklı bloke edilmesi) olasılığı vardır.

Önemli nesnelerin yaşam döngüsü izlenmelidir:

aracılığıyla sunucuda yeni bir iş parçacığı başlatamazsınız new Thread().start(). Bunun yerine, tüm hizmet iş parçacıkları arasında paylaşım yapacak bir ThreadPool'a sahip olmanız gerekir.

Ayrıca, eşzamansız bir görevi öylece başlatamazsınız çünkü bunlar aynı zamanda ayrı iş parçacıklarında yürütülür. Böyle bir görev oluştururken, hangi iş parçacığı havuzunun onu yürüttüğünü ve böyle bir havuz taşarsa ne olacağını her zaman bilmelisiniz.

Dosyalar ve dizinlerle yapılan tüm çalışmalar, kaynaklarla denenerek yapılmalıdır. Normal bir uygulamada bir akışı veya dosyayı kapatmayı unuttuysanız, bu bir sorun mudur? Programdan çıktığınızda kendini kapatacaktır. Ancak, sunucudaki bir dosyayı kodun herhangi bir yerinde kapatmayı unuttuysanız ve sunucunuz aylardır çalışıyorsa ... Yakında, bu tür kapatılmamış binlerce dosya birikecek ve işletim sistemi okumak için yeni dosyaları açmayı durduracak (dosyalarla çalışın) işletim sistemi tarafından kontrol edilir). Teamlead kafanıza vurmayacak...

1.4 İstemci-sunucu mimarisi

bir diğer önemli nokta. İstemci-sunucu mimarisi, bilgisayarlar arasındaki etkileşimin yalnızca genel ilkelerini tanımlar , etkileşimin ayrıntıları çeşitli protokoller tarafından belirlenir.

Bu kavram (istemci-sunucu) bize, ağdaki makineleri her zaman bir şeye ihtiyaç duyan istemci makineler ve ihtiyaç duyduklarını veren sunucu makineler olarak ayırmamız gerektiğini söyler. Bu durumda, müşteri her zaman etkileşimi başlatır ve etkileşimin meydana geldiği kurallar protokol tarafından tanımlanır.

İki tür istemci-sunucu etkileşim mimarisi vardır: birincisi iki katmanlı istemci-sunucu mimarisi olarak adlandırılır, ikincisi çok katmanlı istemci-sunucu mimarisidir (bazen üç katmanlı mimari veya üç katmanlı mimari olarak adlandırılır, ama bu özel bir durum).

İstemci-sunucu etkileşiminin iki katmanlı mimarisinin çalışma prensibi, bir talebin işlenmesinin, bu işleme sürecinde diğer sunuculara atıfta bulunulmadan bir sunucuda gerçekleşmesidir.

İki katmanlı istemci-sunucu etkileşim modeli basit bir diyagram olarak çizilebilir.

Burada birinci seviyenin müşteriyi ilgilendiren her şey olduğunu ve ikinci seviyenin sunucuyu ilgilendiren her şey olduğunu görebilirsiniz.