Ortak web uygulaması mimarileri

İpucu

Bu içerik, .NET Docs'ta veya çevrimdışı olarak okunabilen ücretsiz indirilebilir bir PDF olarak sağlanan ASP.NET Core ve Azure ile Modern Web Uygulamaları Mimarisi adlı e-Kitap'tan bir alıntıdır.

PDF'i indirin

"İyi mimarinin pahalı olduğunu düşünüyorsanız, kötü mimariyi deneyin." - Brian Foote ve Joseph Yoder

Çoğu geleneksel .NET uygulaması, tek bir IIS uygulama etki alanı içinde çalışan bir yürütülebilir dosyaya veya tek bir web uygulamasına karşılık gelen tek birimler olarak dağıtılır. Bu yaklaşım en basit dağıtım modelidir ve birçok iç ve daha küçük genel uygulamaya çok iyi hizmet eder. Ancak, bu tek dağıtım birimi göz önünde bulundurulduğunda bile, önemsiz olmayan iş uygulamalarının çoğu birkaç katmana mantıksal ayrımdan yararlanan uygulamalardır.

Monolitik uygulama nedir?

Monolitik uygulama, davranışı açısından tamamen kendi içinde olan bir uygulamadır. İşlemleri sırasında diğer hizmetler veya veri depolarıyla etkileşime geçebilir, ancak davranışının temeli kendi işlemi içinde çalışır ve uygulamanın tamamı genellikle tek bir birim olarak dağıtılır. Böyle bir uygulamanın yatay olarak ölçeklendirilmesi gerekiyorsa, genellikle uygulamanın tamamı birden çok sunucu veya sanal makinede çoğaltılır.

Hepsi bir arada uygulamalar

Uygulama mimarisi için mümkün olan en az proje sayısı birdir. Bu mimaride, uygulamanın tüm mantığı tek bir projede yer alır, tek bir derlemede derlenmiş ve tek bir birim olarak dağıtılır.

İster Visual Studio'da ister komut satırından oluşturulan yeni bir ASP.NET Core projesi basit bir "hepsi bir arada" monolit olarak başlar. Sunu, iş ve veri erişim mantığı dahil olmak üzere uygulamanın tüm davranışlarını içerir. Şekil 5-1'de tek projeli bir uygulamanın dosya yapısı gösterilmektedir.

Şekil 5-1. Tek bir proje ASP.NET Core uygulaması.

Tek bir proje senaryosunda, klasörlerin kullanımıyla endişelerin ayrılması sağlanır. Varsayılan şablon, Modeller, Görünümler ve Denetleyiciler'in MVC desen sorumlulukları için ayrı klasörlerin yanı sıra Veri ve Hizmetler için ek klasörler içerir. Bu düzenlemede sunu ayrıntıları, Görünümler klasörüyle olabildiğince sınırlı olmalı ve veri erişimi uygulama ayrıntıları da Veri klasöründe tutulan sınıflarla sınırlandırılmalıdır. İş mantığı, Modeller klasöründeki hizmetlerde ve sınıflarda bulunmalıdır.

Basit olsa da, tek projeli monolitik çözümün bazı dezavantajları vardır. Projenin boyutu ve karmaşıklığı arttıkça dosya ve klasör sayısı da artmaya devam edecektir. Kullanıcı arabirimi (UI) ile ilgili endişeler (modeller, görünümler, denetleyiciler) alfabetik olarak birlikte gruplanmayan birden çok klasör içinde bulunur. Bu sorun yalnızca Filtreler veya ModelBinder'lar gibi ek ui düzeyi yapılar kendi klasörlerine eklendiğinde daha da kötüleşir. İş mantığı Modeller ve Hizmetler klasörleri arasında dağınıktır ve hangi klasörlerde hangi sınıfların hangilerine bağlı olması gerektiğine dair net bir gösterge yoktur. Proje düzeyinde bu organizasyon eksikliği sıklıkla spagetti koduna yol açar.

Bu sorunları çözmek için, uygulamalar genellikle her projenin uygulamanın belirli bir katmanında bulunduğu kabul edilen çok projeli çözümlere dönüşür.

Mantıksal katman nedir?

Uygulamaların karmaşıklığı arttıkça, bu karmaşıklığı yönetmenin bir yolu uygulamayı sorumluluklarına veya endişelerine göre ayırmaktır. Bu yaklaşım, endişelerin ayrımı ilkesini izler ve geliştiricilerin belirli işlevlerin nerede uygulandığını kolayca bulabilmesi için büyüyen bir kod tabanının düzenli kalmasına yardımcı olabilir. Katmanlı mimari, kod düzenlemesinin ötesinde bir dizi avantaj sunar.

Kod katmanlar halinde düzenlenerek, yaygın düşük düzeyli işlevler uygulama genelinde yeniden kullanılabilir. Bu yeniden kullanım, daha az kod yazılması gerektiği anlamına geldiği ve uygulamanın tek bir uygulama üzerinde standart hale getirilmesine izin verebildiği için, kendinizi yineleme (DRY) ilkesini izleyerek faydalıdır.

Katmanlı mimari sayesinde uygulamalar, katmanların diğer katmanlarla iletişim kurabileceği kısıtlamaları zorunlu kılabilir. Bu mimari kapsüllemenin sağlanmasına yardımcı olur. Bir katman değiştirildiğinde veya değiştirildiğinde, yalnızca bu katmanla çalışan katmanlar etkilenmelidir. Hangi katmanların diğer katmanlara bağlı olduğunu sınırlayarak, tek bir değişikliğin uygulamanın tamamını etkilememesi için değişikliklerin etkisi azaltılabilir.

Katmanlar (ve kapsülleme), uygulama içindeki işlevlerin değiştirilmesini çok daha kolay hale getirir. Örneğin, bir uygulama başlangıçta kalıcılık için kendi SQL Server veritabanını kullanabilir, ancak daha sonra bulut tabanlı kalıcılık stratejisini veya bir web API'sini kullanmayı seçebilir. Uygulama kalıcılık uygulamasını bir mantıksal katman içinde düzgün bir şekilde kapsüllediyse, SQL Server'a özgü bu katman aynı ortak arabirimi uygulayan yeni bir katmanla değiştirilebilir.

Uygulama katmanları, gelecekteki gereksinimlere yanıt olarak uygulamaları değiştirme potansiyeline ek olarak, test amacıyla uygulamaları değiştirmeyi de kolaylaştırabilir. Uygulamanın gerçek veri katmanına veya kullanıcı arabirimi katmanına göre çalışan testler yazmak zorunda kalmak yerine, bu katmanlar test zamanında isteklere bilinen yanıtlar sağlayan sahte uygulamalarla değiştirilebilir. Bu yaklaşım genellikle, testlerin uygulamanın gerçek altyapısında çalıştırılmasına kıyasla çok daha kolay ve çalıştırılmasını çok daha hızlı hale getirir.

Mantıksal katmanlama, kurumsal yazılım uygulamalarında kodun düzenlenmesini geliştirmeye yönelik yaygın bir tekniktir ve kodun katmanlar halinde düzenlenebileceği çeşitli yollar vardır.

Not

Katmanlar , uygulama içindeki mantıksal ayrımı gösterir. Uygulama mantığının ayrı sunuculara veya işlemlere fiziksel olarak dağıtıldığı durumlarda, bu ayrı fiziksel dağıtım hedefleri katman olarak adlandırılır. Tek bir katmana dağıtılan bir N Katmanı uygulamasına sahip olmak mümkündür ve oldukça yaygındır.

Geleneksel "N Katmanlı" mimari uygulamaları

Uygulama mantığının katmanlar halinde en yaygın kuruluşu Şekil 5-2'de gösterilmiştir.

Şekil 5-2. Tipik uygulama katmanları.

Bu katmanlar genellikle kullanıcı arabirimi, BLL (İş Mantığı Katmanı) ve DAL (Veri Erişim Katmanı) olarak kısaltılır. Kullanıcılar bu mimariyi kullanarak yalnızca BLL ile etkileşim kuran kullanıcı arabirimi katmanı üzerinden istekte bulunur. BLL de veri erişim istekleri için DAL'yi çağırabilir. Kullanıcı arabirimi katmanı doğrudan DAL'ye herhangi bir istekte bulunmamalı veya kalıcılık ile doğrudan başka yollarla etkileşim kurmamalıdır. Benzer şekilde, BLL yalnızca DAL'yi kullanarak kalıcılık ile etkileşim kurmalıdır. Bu şekilde her katmanın kendi iyi bilinen sorumluluğu vardır.

Bu geleneksel katmanlama yaklaşımının bir dezavantajı, derleme zamanı bağımlılıklarının yukarıdan aşağıya doğru çalışmasıdır. Yani kullanıcı arabirimi katmanı, DAL'ye bağlı olan BLL'ye bağlıdır. Bu, genellikle uygulamadaki en önemli mantığı tutan BLL'nin veri erişimi uygulama ayrıntılarına (ve genellikle bir veritabanının varlığına) bağımlı olduğu anlamına gelir. Böyle bir mimaride iş mantığının test edilmesi genellikle zordur ve test veritabanı gerektirir. Bağımlılık ters çevirme ilkesi, sonraki bölümde göreceğiniz gibi bu sorunu gidermek için kullanılabilir.

Şekil 5-3'de, uygulamayı sorumluluk (veya katman) ile üç projeye bölen örnek bir çözüm gösterilmektedir.

Şekil 5-3. Üç projeli basit bir monolitik uygulama.

Bu uygulama kuruluş amacıyla birkaç proje kullansa da, yine de tek bir birim olarak dağıtılır ve istemcileri tek bir web uygulaması olarak bu projeyle etkileşim kurar. Bu, çok basit bir dağıtım işlemine olanak tanır. Şekil 5-4'de bu tür bir uygulamanın Azure kullanılarak nasıl barındırılacağı gösterilmektedir.

Şekil 5-4. Azure Web App'in basit dağıtımı

Uygulama gereksinimleri arttıkça daha karmaşık ve güçlü dağıtım çözümleri gerekebilir. Şekil 5-5'de ek özellikleri destekleyen daha karmaşık bir dağıtım planı örneği gösterilmektedir.

Şekil 5-5. Azure Uygulaması Hizmetine web uygulaması dağıtma

Şirket içinde, bu projenin sorumluluk temelinde birden çok projeye düzenlenmesi uygulamanın sürdürülebilirliğini artırır.

Bu ünite, bulut tabanlı isteğe bağlı ölçeklenebilirlikten yararlanmak için ölçeği artırılabilir veya genişletilebilir. Ölçeği artırmak, uygulamanızı barındıran sunuculara ek CPU, bellek, disk alanı veya diğer kaynaklar eklemek anlamına gelir. Ölçeği genişletme, fiziksel sunucular, sanal makineler veya kapsayıcılar olsun, bu tür sunucuların ek örneklerinin eklenmesi anlamına gelir. Uygulamanız birden çok örnekte barındırıldığında, tek tek uygulama örneklerine istek atamak için bir yük dengeleyici kullanılır.

Azure'da bir web uygulamasını ölçeklendirmeye yönelik en basit yaklaşım, uygulamanın App Service Planı'nda ölçeklendirmeyi el ile yapılandırmaktır. Şekil 5-6'da, bir uygulamaya hizmet veren örnek sayısını yapılandırmak için uygun Azure panosu ekranı gösterilmektedir.

Şekil 5-6. Azure'da App Service Planı ölçeklendirmesi.

Temiz mimari

Bağımlılık Ters Çevirme İlkesi'ni ve Etki Alanı Odaklı Tasarım (DDD) ilkelerini izleyen uygulamalar benzer bir mimariye ulaşma eğilimindedir. Bu mimari yıllar içinde birçok adla geçti. Adlardan biri AltıGen Mimari, ardından Bağlantı Noktaları ve Bağdaştırıcılar'dı. Daha yakın zamanda, Soğan Mimarisi veya Temiz Mimari olarak belirtildi. İkinci ad olan Temiz Mimari, bu e-kitapta bu mimarinin adı olarak kullanılır.

eShopOnWeb başvuru uygulaması, kodunu projeler halinde düzenlemek için Temiz Mimari yaklaşımını kullanır. Ardalis/cleanarchitecture GitHub deposunda veya şablonu NuGet'ten yükleyerek kendi ASP.NET Core çözümleriniz için başlangıç noktası olarak kullanabileceğiniz bir çözüm şablonu bulabilirsiniz.

Temiz mimari, iş mantığını ve uygulama modelini uygulamanın merkezine yerleştirir. İş mantığının veri erişimine veya diğer altyapı endişelerine bağlı olması yerine bu bağımlılık tersine çevrilir: altyapı ve uygulama ayrıntıları Application Core'a bağlıdır. Bu işlev, Application Core'da soyutlamalar veya arabirimler tanımlanarak elde edilir ve altyapı katmanında tanımlanan türler tarafından uygulanır. Bu mimariyi görselleştirmenin yaygın bir yolu, soğana benzer bir dizi eşmerkezli daire kullanmaktır. Şekil 5-7'de bu mimari gösterim stilinin bir örneği gösterilmektedir.

Şekil 5-7. Temiz Mimari; soğan görünümü

Bu diyagramda bağımlılıklar en yakın daireye doğru akar. Application Core, adını bu diyagramın çekirdeğindeki konumundan alır. Ayrıca diyagramda Application Core'un diğer uygulama katmanlarına bağımlılığı olmadığını görebilirsiniz. Uygulamanın varlıkları ve arabirimleri tam ortadadır. Uygulama Çekirdeği'nin hemen dışında, ancak yine de, genellikle yakın çevre içinde tanımlanan arabirimleri uygulayan etki alanı hizmetleridir. Application Core'un dışında hem kullanıcı arabirimi hem de Altyapı katmanları Application Core'a bağlıdır, ancak birbirlerine bağımlı değildir (mutlaka).

Şekil 5-8'de kullanıcı arabirimi ile diğer katmanlar arasındaki bağımlılığı daha iyi yansıtan daha geleneksel bir yatay katman diyagramı gösterilmektedir.

Şekil 5-8. Temiz Mimari; yatay katman görünümü

Düz okların derleme zamanı bağımlılıklarını, kesikli ok ise yalnızca çalışma zamanı bağımlılığını temsil ettiğini unutmayın. Temiz mimariyle, ui katmanı derleme zamanında Application Core'da tanımlanan arabirimlerle çalışır ve ideal olarak Altyapı katmanında tanımlanan uygulama türlerini bilmemeli. Ancak çalışma zamanında, uygulamanın yürütülmesi için bu uygulama türleri gereklidir, bu nedenle bağımlılık ekleme yoluyla Uygulama Çekirdeği arabirimlerine bağlanmaları ve bunların mevcut olması gerekir.

Şekil 5-9'da, bu önerilere uyularak ASP.NET Core uygulamasının mimarisinin daha ayrıntılı bir görünümü gösterilmektedir.

Şekil 5-9. Temiz Mimari'nin ardından Temel mimari diyagramını ASP.NET.

Application Core Altyapı'ya bağlı olmadığından bu katman için otomatik birim testleri yazmak çok kolaydır. Şekil 5-10 ve 5-11, testlerin bu mimariye nasıl uygun olduğunu gösterir.

Şekil 5-10. Uygulama Çekirdeğini yalıtarak birim testi.

Şekil 5-11. Tümleştirme testi Dış bağımlılıklarla altyapı uygulamaları.

Ui katmanının Altyapı projesinde tanımlanan türlere doğrudan bağımlılığı olmadığından, test işlemini kolaylaştırmak veya değişen uygulama gereksinimlerine yanıt olarak uygulamaları değiştirmek de çok kolaydır. ASP.NET Core'un yerleşik bağımlılık ekleme kullanımı ve desteği, bu mimariyi önemsiz olmayan monolitik uygulamaları yapılandırmak için en uygun yol haline getirir.

Tek parçalı uygulamalar için Application Core, Altyapı ve UI projelerinin tümü tek bir uygulama olarak çalıştırılır. Çalışma zamanı uygulama mimarisi Şekil 5-12 gibi görünebilir.

Şekil 5-12. Örnek ASP.NET Core uygulamasının çalışma zamanı mimarisi.

Temiz Mimaride kod düzenleme

Temiz Mimari çözümünde her projenin net sorumlulukları vardır. Bu nedenle, belirli türler her projeye aittir ve sık sık uygun projede bu türlere karşılık gelen klasörleri bulursunuz.

Uygulama Çekirdeği

Application Core varlıklar, hizmetler ve arabirimler içeren iş modelini barındırıyor. Bu arabirimler veri erişimi, dosya sistemi erişimi, ağ çağrıları gibi Altyapı kullanılarak gerçekleştirilecek işlemlerin özetlerini içerir. Bazen bu katmanda tanımlanan hizmetlerin veya arabirimlerin kullanıcı arabirimine veya Altyapıya bağımlılığı olmayan varlık dışı türlerle çalışması gerekir. Bunlar basit Veri Aktarım Nesneleri (DTO' lar) olarak tanımlanabilir.

Application Core türleri

• Varlıklar (kalıcı iş modeli sınıfları)
• Toplamalar (varlık grupları)
• Arabirimler
• Etki Alanı Hizmetleri
• Belirtimler
• Özel Özel Durumlar ve Koruma Yan Tümceleri
• Etki Alanı Olayları ve İşleyicileri

Altyapı

Altyapı projesi genellikle veri erişim uygulamalarını içerir. Tipik bir ASP.NET Core web uygulamasında, bu uygulamalar Entity Framework (EF) DbContext, tanımlanmış tüm EF Core Migration nesneleri ve veri erişimi uygulama sınıflarını içerir. Veri erişimi uygulama kodunu soyutlamanın en yaygın yolu, Depo tasarım deseninin kullanılmasıdır.

Altyapı projesi, veri erişim uygulamalarına ek olarak altyapı endişeleriyle etkileşim kurması gereken hizmetlerin uygulamalarını da içermelidir. Bu hizmetler Application Core'da tanımlanan arabirimleri uygulamalıdır ve bu nedenle Altyapı'nın Application Core projesine bir başvurusu olmalıdır.

Altyapı türleri

• EF Core türleri (DbContext, Migration)
• Veri erişimi uygulama türleri (Depolar)
• Altyapıya özgü hizmetler (örneğin, FileLogger veya SmtpNotifier)

KULLANıCı Arabirimi Katmanı

ASP.NET Core MVC uygulamasındaki kullanıcı arabirimi katmanı, uygulamanın giriş noktasıdır. Bu proje Application Core projesine başvurmalı ve türleri, Application Core'da tanımlanan arabirimler aracılığıyla altyapıyla kesinlikle etkileşime geçmelidir. Kullanıcı arabirimi katmanında Altyapı katmanı türlerine yönelik veya statik çağrıların doğrudan örneklenmesine izin verilmemelidir.

UI Katmanı türleri

• Denetleyiciler
• Özel Filtreler
• Özel Ara Yazılım
• Görünümler
• Görünüm Modelleri
• Başlangıç

Startup Sınıfı veya Program.cs dosyası, uygulamayı yapılandırmak ve uygulama türlerini arabirimlere bağlamakla sorumludur. Bu mantığın gerçekleştirildiği yer, uygulamanın oluşturma kökü olarak bilinir ve bağımlılık ekleme işleminin çalışma zamanında düzgün çalışmasını sağlayan yerdir.

Not

Uygulama başlatma sırasında bağımlılık ekleme işleminin kablolanması için kullanıcı arabirimi katmanı projesinin Altyapı projesine başvurması gerekebilir. Bu bağımlılık, derlemelerden yükleme türleri için yerleşik desteğe sahip özel bir DI kapsayıcısı kullanılarak kolayca ortadan kaldırılabilir. Bu örneğin amaçları doğrultusunda en basit yaklaşım, kullanıcı arabirimi projesinin Altyapı projesine başvurmasına izin vermektir (ancak geliştiriciler, Altyapı projesindeki türlerdeki gerçek başvuruları uygulamanın oluşturma köküyle sınırlandırmalıdır).

Monolitik uygulamalar ve kapsayıcılar

Tek ve monolitik dağıtım tabanlı bir Web Uygulaması veya Hizmeti derleyebilir ve kapsayıcı olarak dağıtabilirsiniz. Uygulama içinde monolitik olmayabilir, ancak çeşitli kitaplıklar, bileşenler veya katmanlar halinde düzenlenmiş olabilir. Harici olarak, tek bir işlem, tek bir web uygulaması veya tek bir hizmete sahip tek bir kapsayıcıdır.

Bu modeli yönetmek için uygulamayı temsil eden tek bir kapsayıcı dağıtırsınız. Ölçeklendirmek için, önünde yük dengeleyici bulunan ek kopyalar eklemeniz gerekir. Basitlik, tek bir kapsayıcıda veya VM'de tek bir dağıtımı yönetmekten gelir.

Şekil 5-13'te gösterildiği gibi, her kapsayıcıya birden çok bileşen/kitaplık veya iç katman ekleyebilirsiniz. Ancak kapsayıcının "kapsayıcı tek bir şey yapar ve tek bir işlemde yapar" kapsayıcı ilkesine göre monolitik desen bir çakışma olabilir.

Bu yaklaşımın dezavantajı, uygulama büyürse/büyüdüğünde ve ölçeklendirilmesini gerektirdiğinde ortaya çıkar. Uygulamanın tamamı ölçeklendirilirse, bu gerçekten bir sorun değildir. Ancak çoğu durumda uygulamanın birkaç bölümü ölçeklendirme gerektiren boğulma noktalarıdır, diğer bileşenler ise daha az kullanılır.

Tipik e-ticaret örneğini kullanarak, ölçeklendirmeniz gereken şey ürün bilgileri bileşenidir. Satın almaktan çok daha fazla müşteri ürünlere göz atar. Ödeme işlem hattını kullanmaktan daha fazla müşteri sepetini kullanır. Daha az müşteri yorum ekler veya satın alma geçmişini görüntüler. Ayrıca büyük olasılıkla tek bir bölgede içerik ve pazarlama kampanyalarını yönetmesi gereken yalnızca birkaç çalışanınız vardır. Monolitik tasarımı ölçeklendirerek, tüm kod birden çok kez dağıtılır.

"Her şeyi ölçeklendir" sorununa ek olarak, tek bir bileşende yapılan değişiklikler için uygulamanın tamamının yeniden test edilmesi ve tüm örneklerin tamamen yeniden dağıtılması gerekir.

Monolitik yaklaşım yaygındır ve birçok kuruluş bu mimari yaklaşımla gelişmektedir. Birçok kişi yeterince iyi sonuçlara sahipken, diğerleri sınırlara ulaştı. Araçlar ve altyapının hizmet odaklı mimariler (SOA) oluşturması çok zor olduğundan ve uygulama büyüyene kadar gereksinimi göremediklerinden, birçoğu uygulamalarını bu modelde tasarladı. Monolitik yaklaşımın sınırlarına yaklaştığınızı fark ederseniz uygulamayı ayırarak kapsayıcılardan ve mikro hizmetlerden daha iyi yararlanmasını sağlamak bir sonraki mantıksal adım olabilir.

Microsoft Azure'da monolitik uygulamalar dağıtmak, her örnek için ayrılmış VM'ler kullanılarak elde edilebilir. Azure Sanal Makine Ölçek Kümeleri kullanarak VM'leri kolayca ölçeklendikleyebilirsiniz. Azure Uygulaması Hizmetleri tek parçalı uygulamalar çalıştırabilir ve vm'leri yönetmek zorunda kalmadan örnekleri kolayca ölçeklendirebilir. Azure Uygulaması Hizmetleri, docker kapsayıcılarının tek örneklerini çalıştırarak dağıtımı basitleştirebilir. Docker'ı kullanarak tek bir VM'yi Docker konağı olarak dağıtabilir ve birden çok örnek çalıştırabilirsiniz. Şekil 5-14'te gösterildiği gibi Azure dengeleyiciyi kullanarak ölçeklendirmeyi yönetebilirsiniz.

Çeşitli konaklara dağıtım, geleneksel dağıtım teknikleri ile yönetilebilir. Docker konakları, el ile gerçekleştirilen docker çalıştırması gibi komutlarla veya Sürekli Teslim (CD) işlem hatları gibi otomasyon aracılığıyla yönetilebilir.

Kapsayıcı olarak dağıtılan monolitik uygulama

Tek parça uygulama dağıtımlarını yönetmek için kapsayıcıları kullanmanın avantajları vardır. Kapsayıcı örneklerini ölçeklendirmek, ek VM'leri dağıtmaktan çok daha hızlı ve kolaydır. VM'leri ölçeklendirmek için sanal makine ölçek kümeleri kullanılırken bile, bunların oluşturulması zaman alır. Uygulama örnekleri olarak dağıtıldığında, uygulamanın yapılandırması VM'nin bir parçası olarak yönetilir.

Docker görüntüleri olarak güncelleştirmeleri dağıtmak çok daha hızlı ve ağ verimlidir. Docker Görüntüleri genellikle saniyeler içinde başlar ve dağıtımları hızlandırır. Docker örneğini yok etmek, genellikle bir saniyeden kısa sürede tamamlayan bir docker stop komut verme kadar kolaydır.

Kapsayıcılar doğası gereği tasarım gereği sabit olduğundan, bozuk VM'ler konusunda endişelenmenize gerek yoktur, ancak güncelleştirme betikleri diskte belirli bir yapılandırmayı veya dosyayı hesaba katmak isteyebilir.

Daha basit web uygulamalarının monolitik dağıtımı için Docker kapsayıcılarını kullanabilirsiniz. Bu yaklaşım sürekli tümleştirmeyi ve sürekli dağıtım işlem hatlarını geliştirir ve dağıtımdan üretime başarıya ulaşmaya yardımcı olur. Artık "Makinemde çalışıyor, neden üretimde çalışmıyor?"

Mikro hizmet tabanlı mimarinin birçok avantajı vardır, ancak bu avantajlar karmaşıklığın artmasına neden olur. Bazı durumlarda maliyetler avantajlardan daha ağır bastığından, tek bir kapsayıcıda veya yalnızca birkaç kapsayıcıda çalışan monolitik bir dağıtım uygulaması daha iyi bir seçenektir.

Monolitik bir uygulama, iyi ayrılmış mikro hizmetlere kolayca ayrıştırılamayabilir. Mikro hizmetler, daha dayanıklı bir uygulama sağlamak için birbirinden bağımsız olarak çalışmalıdır. Uygulamanın bağımsız özellik dilimlerini sunamıyorsanız, bunu ayırmak yalnızca karmaşıklığı artırır.

Bir uygulamanın özellikleri bağımsız olarak ölçeklendirmesi gerekmeyebilir. Birçok uygulama, tek bir örneğin ötesine ölçeklendirilmesi gerektiğinde, bunu tüm örneği kopyalama işlemiyle gerçekleştirebilir. Uygulamayı ayrı hizmetlere ayırmaya yönelik ek çalışmalar, uygulamanın tam örneklerini ölçeklendirmek basit ve uygun maliyetli olduğunda en düşük düzeyde fayda sağlar.

Bir uygulamanın geliştirilmesinin ilk aşamalarında doğal işlevsel sınırların nerede olduğu hakkında net bir fikriniz olmayabilir. En düşük uygulanabilir ürünü geliştirirken doğal ayrım henüz ortaya çıkmamış olabilir. Bu koşullardan bazıları geçici olabilir. Monolitik bir uygulama oluşturarak başlayabilir ve daha sonra geliştirilecek ve mikro hizmet olarak dağıtılacak bazı özellikleri ayırabilirsiniz. Diğer koşullar uygulamanın sorun alanı için önemli olabilir, yani uygulama hiçbir zaman birden çok mikro hizmete bölünmeyebilir.

Bir uygulamayı birçok ayrı işleme ayırmak da ek yük getirir. Özellikleri farklı süreçlere ayırmanın karmaşıklığı daha fazladır. İletişim protokolleri daha karmaşık hale gelir. Yöntem çağrıları yerine hizmetler arasında zaman uyumsuz iletişimler kullanmanız gerekir. Bir mikro hizmet mimarisine geçtikçe, eShopOnContainers uygulamasının mikro hizmetler sürümünde uygulanan yapı taşlarının çoğunu eklemeniz gerekir: olay veri yolu işleme, ileti dayanıklılığı ve yeniden denemeler, nihai tutarlılık ve daha fazlası.

Çok daha basit eShopOnWeb başvuru uygulaması tek kapsayıcılı monolitik kapsayıcı kullanımını destekler. Uygulama, geleneksel MVC görünümlerini, web API'lerini ve Razor Sayfalarını içeren bir web uygulaması içerir. İsteğe bağlı olarak, uygulamanın ayrı bir API projesinin de çalıştırılmasını gerektiren Blazor tabanlı yönetici bileşenini çalıştırabilirsiniz.

Uygulama, ve docker-compose up komutları kullanılarak docker-compose build çözüm kökünden başlatılabilir. Bu komut, web projesinin kökünde bulunan öğesini kullanarak Dockerfile web örneği için bir kapsayıcı yapılandırır ve kapsayıcıyı belirtilen bir bağlantı noktasında çalıştırır. Bu uygulamanın kaynağını GitHub'dan indirebilir ve yerel olarak çalıştırabilirsiniz. Bu monolitik uygulama bile kapsayıcı ortamında dağıtılmasından yararlanır.

Kapsayıcılı dağıtım, uygulamanın her örneğinin aynı ortamda çalıştığı anlamına gelir. Bu yaklaşım, erken test ve geliştirmenin gerçekleştiği geliştirici ortamını içerir. Geliştirme ekibi, uygulamayı üretim ortamıyla eşleşen kapsayıcılı bir ortamda çalıştırabilir.

Ayrıca kapsayıcılı uygulamalar daha düşük maliyetle ölçeği genişletebilir. Kapsayıcı ortamı kullanmak, geleneksel VM ortamlarından daha fazla kaynak paylaşımı sağlar.

Son olarak, uygulamayı kapsayıcılı hale getirme, iş mantığı ile depolama sunucusu arasında bir ayrım gerçekleştirmeye zorlar. Uygulama ölçeği genişletildikçe, birden çok kapsayıcının tümü tek bir fiziksel depolama ortamına dayanır. Bu depolama ortamı genellikle SQL Server veritabanı çalıştıran yüksek kullanılabilirlikli bir sunucu olur.

Docker desteği

Proje eShopOnWeb .NET üzerinde çalışır. Bu nedenle, Linux tabanlı veya Windows tabanlı kapsayıcılarda çalıştırılabilir. Docker dağıtımı için SQL Server için aynı konak türünü kullanmak istediğinizi unutmayın. Linux tabanlı kapsayıcılar daha küçük bir ayak izi sağlar ve tercih edilir.

Çözüm Gezgini'da bir projeye sağ tıklayıp Docker Desteği Ekle'yi>seçerek mevcut bir uygulamaya Docker desteği eklemek için Visual Studio 2017 veya sonraki bir sürümünü kullanabilirsiniz. Bu adım, gerekli dosyaları ekler ve bunları kullanmak için projeyi değiştirir. Geçerli eShopOnWeb örnekte bu dosyalar zaten var.

Çözüm düzeyindeki docker-compose.yml dosya, hangi görüntülerin derlenip hangi kapsayıcıların başlatıldığı hakkında bilgi içerir. Dosya, aynı anda birden çok uygulamayı başlatmak için komutunu kullanmanıza docker-compose olanak tanır. Bu durumda, yalnızca Web projesini başlatır. Ayrıca, ayrı bir veritabanı kapsayıcısı gibi bağımlılıkları yapılandırmak için de kullanabilirsiniz.

version: '3'

services:
  eshopwebmvc:
    image: eshopwebmvc
    build:
      context: .
      dockerfile: src/Web/Dockerfile
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
    ports:
      - "5106:5106"

networks:
  default:
    external:
      name: nat

Dosya, docker-compose.yml projedeki öğesine Dockerfile başvurur Web . Dockerfile, hangi temel kapsayıcının kullanılacağını ve uygulamanın üzerinde nasıl yapılandırılacağını belirtmek için kullanılır. ' Web: Dockerfile

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /app

COPY *.sln .
COPY . .
WORKDIR /app/src/Web
RUN dotnet restore

RUN dotnet publish -c Release -o out

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS runtime
WORKDIR /app
COPY --from=build /app/src/Web/out ./

ENTRYPOINT ["dotnet", "Web.dll"]

Docker sorunlarını giderme

Kapsayıcılı uygulamayı çalıştırdıktan sonra siz durdurana kadar çalışmaya devam eder. komutuyla docker ps hangi kapsayıcıların çalıştığını görüntüleyebilirsiniz. komutunu kullanarak docker stop ve kapsayıcı kimliğini belirterek çalışan bir kapsayıcıyı durdurabilirsiniz.

Docker kapsayıcılarını çalıştırmanın, geliştirme ortamınızda kullanmayı deneyebileceğiniz bağlantı noktalarına bağlı olabileceğini unutmayın. Çalışan bir Docker kapsayıcısı ile aynı bağlantı noktasını kullanarak bir uygulamayı çalıştırmaya veya hata ayıklamaya çalışırsanız, sunucunun bu bağlantı noktasına bağlanamadığını belirten bir hata alırsınız. Kapsayıcının durdurulması sorunu bir kez daha çözecektir.

Visual Studio kullanarak uygulamanıza Docker desteği eklemek istiyorsanız, bunu yaptığınızda Docker Desktop'ın çalıştığından emin olun. Sihirbazı başlattığınızda Docker Desktop çalışmıyorsa sihirbaz düzgün çalışmaz. Ayrıca sihirbaz, doğru Docker desteğini eklemek için geçerli kapsayıcı seçiminizi inceler. Windows Kapsayıcıları için destek eklemek istiyorsanız, Windows Kapsayıcıları ile çalışan Docker Desktop'ı yapılandırırken sihirbazı çalıştırmanız gerekir. Linux kapsayıcıları için destek eklemek istiyorsanız, Linux kapsayıcılarıyla çalışan Docker'ı yapılandırırken sihirbazı çalıştırın.

Diğer web uygulaması mimari stilleri

• Web Kuyruğu Çalışanı: Bu mimarinin temel bileşenleri, istemci isteklerine hizmet veren bir web ön ucu ve yoğun kaynak kullanan görevler, uzun süre çalışan iş akışları veya toplu işler gerçekleştiren bir çalışandır. Web ön ucu, çalışanla bir ileti kuyruğu üzerinden iletişim kurar.
• N katmanı: N katmanlı mimari, bir uygulamayı mantıksal katmanlara ve fiziksel katmanlara böler.
• Mikro hizmet: Mikro hizmetler mimarisi, küçük, otonom hizmetlerden oluşan bir koleksiyondan oluşur. Her hizmet kendi içindedir ve sınırlanmış bir bağlam içinde tek bir iş özelliği uygulamalıdır.

Başvurular – Yaygın web mimarileri

• Temiz Mimari
  https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
• Soğan Mimarisi
  https://jeffreypalermo.com/blog/the-onion-architecture-part-1/
• Depo Düzeni
  https://deviq.com/repository-pattern/
• Temiz Mimari Çözüm Şablonu
  https://github.com/ardalis/cleanarchitecture
• Mikro hizmetler e-kitabının mimarisini oluşturma
  https://aka.ms/MicroservicesEbook
• DDD (Etki Alanı Odaklı Tasarım)
  https://learn.microsoft.com/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/

Geriİleri