Üç Katmanlı Mimari Diyagramı: Sunum, Uygulama ve Veri

Üç katmanlı mimari, çoğu web uygulamasının hâlâ kaputun altında taşıdığı biçimdir: kullanıcı arayüzünü sunan bir şey, iş mantığını çalıştıran bir şey ve veriyi saklayan bir şey. Eskidir, sıkıcıdır ve çoğu sistem için doğru başlangıç noktasıdır, çünkü her katman kendi başına ölçeklenebilir ve güvenceye alınabilir.

Bu yazı üç katmanı açıklıyor, alt ağlar ve güvenlik gruplarıyla bir bulut ağına nasıl eşlendiklerini gösteriyor ve iki erişilebilirlik alanına (availability zone) yayılmış tipik bir AWS kurulumunu çiziyor. Aynı yapı her bulutta işe yarar.

Üç katman

Bunu üç kutudan öte bir mimari yapan kural: her katman yalnızca komşusuyla konuşur. Tarayıcı asla veritabanına ulaşmaz, sunum katmanı da asla SQL çalıştırmaz.

AWS bu deseni üç katmanlı mimari genel bakışında anlatıyor; buna uygulama sunucularının yerini fonksiyonların aldığı serverless varyantlar da dahil.

Katmanları ağa eşlemek

Katmanlar, farklı rotalara sahip farklı alt ağlarda yaşadıklarında gerçek sınırlara dönüşür:

• Genel alt ağlar yalnızca internetten erişilebilir olması gerekenleri tutar: yük dengeleyiciyi ve NAT ağ geçitlerini.
• Özel uygulama alt ağları uygulama sunucularını tutar. Bunlar güncellemeler ve API'ler için NAT üzerinden internete çıkabilir, ama dışarıdan onlara yük dengeleyici dışında hiçbir şey ulaşamaz.
• Özel veri alt ağları veritabanlarını ve önbellekleri tutar; internete hiçbir rotaları yoktur.

Ardından güvenlik grupları yalnızca komşunun trafiğine izin verir: veritabanı 5432 numaralı portu bir IP aralığından değil, yalnızca uygulama katmanının güvenlik grubundan kabul eder. Adresler yerine gruplara referans vermek, örnekler gelip gittikçe kuralların doğru kalmasını sağlar.

Alanlar arasında yüksek erişilebilirlik

Her katmanı en az iki erişilebilirlik alanında çalıştırın:

• Yük dengeleyici tasarımı gereği alanlara yayılır.
• Uygulama sunucuları, her alanda örnekleri olan bir otomatik ölçekleme grubunda çalışır. Bir alan çökerse diğerleri trafiği üstlenir ve grup kapasiteyi yerine koyar.
• Veritabanı, başka bir alanda senkron bir yedekle çalışır. Amazon RDS Multi-AZ ile yedeğe geçiş otomatiktir ve uç nokta adı aynı kalır.

Uygulama katmanını durumsuz tutun ki her örnek her isteği karşılayabilsin: oturumlar ortak bir önbelleğe ya da veritabanına, yüklenen dosyalar nesne depolamaya gider ve bir örneğin diskinde önemli hiçbir şey yaşamaz. Bunu mesai saatlerinde rastgele bir uygulama sunucusunu sonlandırarak test edin; kullanıcılar fark ediyorsa, bir durum hâlâ örneklerde saklanıyordur.

Her katmanı ölçeklemek

Katmanlar farklı biçimlerde ölçeklenir; onları ayrı tutmanın nedeni de budur:

• Sunum: statik trafiğin çoğunu bir CDN emer. Ne kadarını emeceğine cache header'ları karar verir.
• Uygulama: örnek ekleyin. İstek sayısına ya da CPU'ya göre ölçekleyin ve örneklerin hızlı açılmasını sağlayın.
• Veri: en zoru. Önce dikey ölçekleyin, okuma ağırlıklı yük için okuma replikaları, sıcak anahtarlar için bir önbellek ekleyin ve sharding'i son çare olarak görün.

Katmanlardan geçen bir istek

Sipariş geçmişini açan bir kullanıcıyı takip edin:

1. DNS, CDN'in adresini döndürür. Tarayıcı sayfayı ister; HTML, betikler ve görseller CDN'in önbelleğinden ya da arkasındaki statik bucket'tan gelir.
2. Sayfa GET /api/orders çağrısını yapar. CDN dinamik yolları yük dengeleyiciye iletir; o da TLS'i sonlandırır ve iki alandan birindeki sağlıklı bir uygulama sunucusunu seçer.
3. Uygulama sunucusu oturumu önbellekten okur, kullanıcının giriş yaptığını kontrol eder ve siparişler için birincil veritabanını sorgular.
4. Yanıt yük dengeleyici ve CDN üzerinden geri döner; yanıt özel olduğu için CDN onu önbelleğe almaz.

Her adım tek bir katman sınırını geçer ve her sınırın izin verilen tam olarak bir giriş noktası vardır. Tasarımı anlamayı ve güvenceye almayı kolaylaştıran da budur.

Maliyetler ve doğru boyutlandırma

Faturanın büyük kısmını genellikle veri katmanı oluşturur ve sonradan küçültülmesi en zor olan da odur; bu yüzden onu tahminlere değil ölçümlere göre boyutlandırın. Uygulama katmanını ayarlamak en kolayıdır: küçük başlayın, gerçek yüke göre ölçekleyin ve zirveleri otomatik ölçeklemeye bırakın. İnsanları şaşırtan kalemler NAT ağ geçitleri ve alanlar arası trafiktir; yapabildiğiniz yerde yoğun konuşan trafiği tek bir alanda tutun ve nesne depolama için VPC uç noktaları kullanın ki uygulama sunucuları her yükleme için NAT ücreti ödemesin.

Mimari diyagram

Nasıl okunur:

• Üst: kullanıcılar DNS'i çözer ve statik dosyaları bir bucket'tan sunan, dinamik istekleri ileten CDN'e bağlanır.
• Sunum katmanı: uygulama yük dengeleyicisi, genel alt ağlardaki tek bileşendir.
• Uygulama katmanı: A ve B alanlarındaki uygulama sunucuları özel alt ağlarda durur ve yalnızca yük dengeleyiciden trafik alır.
• Veri katmanı: A alanındaki birincil veritabanı, B alanındaki bir yedeğe senkron olarak replike olur; uygulama sunucuları bir oturum önbelleği de kullanır. Bu katmanın internete rotası yoktur.
• Markdown bloğu, katmanları gerçekte uygulayan güvenlik grubu kurallarını listeler.

Sık yapılan hatalar

• Genel alt ağlardaki veritabanları, bir dizüstü bilgisayardan hızlı bir sorgu için "geçici olarak". Bunun yerine bir bastion ya da yönetilen bir oturum aracı kullanın.
• Katmanlar arasında bütün bir CIDR aralığına izin veren güvenlik grupları, komşunun grubuna referans vermek yerine.
• Uygulama sunucularında durum: bellekte oturumlar, yerel diskte yüklenen dosyalar. Otomatik ölçekleme ve yedeğe geçiş bu durumda veri kaybettirir.
• Para tasarrufu için veritabanında tek bir erişilebilirlik alanı, uygulama katmanı üç alana yayılmışken.
• CDN'i atlayıp her görseli uygulama sunucularından sunmak.
• Uygulama sunucularında sağlık kontrolü yolu olmaması; böylece yük dengeleyici, veritabanına ulaşamayan örneklere trafik göndermeye devam eder.

Üç katman yetmediğinde

Üç katman tek bir uygulamayı tanımlar. Sistem birkaç servise doğru büyüdükçe her servis çoğu zaman kendi üç katmanlı biçimini korur ve diyagram, servislerin birbiriyle nasıl konuştuğunu göstermek için bir seviye yukarı çıkar. Mikroservis mimari diyagramı bu adımı ele alıyor. Ağ ayrıntıları için AWS VPC diyagramına, birden fazla bölge için de AWS çok bölgeli mimari diyagramına bakın.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. C4 Modeli paketinden bir Kişi, Ağ paketinden bir DNS, Bulut paketinden de bir CDN ve bir Nesne depolama düğümü ekleyin.
3. Ağ paketinden bir VPC ekleyin ve içine, her katman için bir tane olmak üzere Temel paketinden üç Çerçeve düğümü koyun.
4. Sunum katmanına bir Bulut yük dengeleyici, uygulama katmanına iki Hesaplama düğümü, veri katmanına da iki Yönetilen veritabanı düğümü ile Veri paketinden Redis ekleyin.
5. Her katmanı yalnızca komşusuna bağlayın ve güvenlik grubu kurallarını içeren, Temel paketinden bir Markdown bloğu ekleyin. Kurulumunuz zaten Terraform olarak varsa, Terraform'dan diyagrama aracı size ilk taslağı verir.

Örnek 15 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor.

SSS

Üç katmanlı mimarideki üç katman nedir? Sunum (kullanıcı arayüzü ve giriş noktası), uygulama (iş mantığı ve API'ler) ve veri (veritabanları, önbellekler ve depolama).

Üç katmanlı mimari modası geçmiş mi? Hayır. Web uygulamaları için varsayılan biçimdir. Mikroservis ve serverless sistemler de aynı üç sorumluluğu, çoğu zaman servis başına, barındırır.

Three-tier ile three-layer mimari arasındaki fark nedir? Layer'lar kodun içindeki mantıksal bir ayrımdır; tier'lar ise aralarında ağ sınırları bulunan ayrı makinelere ya da servislere yayılan fiziksel bir ayrımdır.

Veritabanı genel bir alt ağda olmalı mı? Hayır. Onu internete rotası olmayan özel alt ağlarda tutun; yalnızca uygulama katmanının güvenlik grubundan erişilebilir olsun.

Üç katmanlı bir uygulamayı nasıl yüksek erişilebilir yaparım? Her katmanı en az iki erişilebilirlik alanında çalıştırın, uygulama sunucularını durumsuz tutun ve başka bir alanda otomatik yedeği olan bir veritabanı kullanın.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.