Ey Habr!

Coronavirüs nedeniyle yaşanan güncel olaylar ışığında, bir dizi İnternet hizmeti artan yük almaya başladı. Örneğin, Birleşik Krallık'taki perakende zincirlerinden biri çevrimiçi sipariş sitesini durdurdu.Çünkü yeterli kapasite yoktu. Ve bir sunucuyu yalnızca daha güçlü ekipman ekleyerek hızlandırmak her zaman mümkün değildir, ancak müşteri isteklerinin işlenmesi gerekir (aksi takdirde rakiplere giderler).

Bu yazımda hızlı ve hataya dayanıklı bir hizmet oluşturmanızı sağlayacak popüler uygulamalardan kısaca bahsedeceğim. Ancak olası geliştirme planlarından yalnızca şu anda mevcut olanları seçtim. kullanımı kolay. Her öğe için ya hazır kütüphaneleriniz var ya da sorunu bir bulut platformu kullanarak çözme olanağınız var.

Yatay ölçeklendirme

En basit ve en bilinen nokta. Geleneksel olarak en yaygın iki yük dağıtım şeması yatay ve dikey ölçeklendirmedir. İlk durumda Hizmetlerin paralel çalışmasına izin vererek yükü aralarında dağıtırsınız. Ikinci sırada daha güçlü sunucular sipariş edersiniz veya kodu optimize edersiniz.

Örneğin, soyut bulut dosya depolama alanını, yani OwnCloud, OneDrive vb.'nin bir analogunu alacağım.

Böyle bir devrenin standart bir resmi aşağıdadır, ancak bu yalnızca sistemin karmaşıklığını gösterir. Sonuçta hizmetleri bir şekilde senkronize etmemiz gerekiyor. Kullanıcı bir dosyayı tabletinden kaydederse ve daha sonra bunu telefondan görüntülemek isterse ne olur?

Yaklaşımlar arasındaki fark: Dikey ölçeklendirmede düğümlerin gücünü artırmaya hazırız, yatay ölçeklendirmede ise yükü dağıtmak için yeni düğümler eklemeye hazırız.

CQRS

Komut Sorgu Sorumluluğu Ayrımı Oldukça önemli bir model çünkü farklı istemcilerin yalnızca farklı hizmetlere bağlanmasına değil, aynı olay akışlarını almasına da olanak tanıyor. Faydaları basit bir uygulama için çok açık değildir ancak yoğun bir hizmet için son derece önemlidir (ve basittir). Özü: Gelen ve giden veri akışları kesişmemelidir. Yani bir istek gönderip yanıt bekleyemezsiniz; bunun yerine A hizmetine istek gönderirsiniz ancak B hizmetinden yanıt alırsınız.

Bu yaklaşımın ilk avantajı, uzun bir isteği yerine getirirken bağlantıyı (kelimenin geniş anlamıyla) koparabilme yeteneğidir. Örneğin, aşağı yukarı standart bir diziyi ele alalım:

1. İstemci sunucuya bir istek gönderdi.
2. Sunucu uzun bir işlem süresine başladı.
3. Sunucu istemciye sonuçla yanıt verdi.

2. noktada bağlantının kesildiğini (veya ağın yeniden bağlandığını veya kullanıcının başka bir sayfaya giderek bağlantıyı kestiğini) hayal edelim. Bu durumda sunucunun kullanıcıya tam olarak neyin işlendiğine dair bilgi içeren bir yanıt göndermesi zor olacaktır. CQRS kullanıldığında sıra biraz farklı olacaktır:

1. İstemci güncellemelere abone oldu.
2. İstemci sunucuya bir istek gönderdi.
3. Sunucu "istek kabul edildi" yanıtını verdi.
4. Sunucu, “1” noktasından itibaren kanal aracılığıyla sonuçla yanıt verdi.

Gördüğünüz gibi şema biraz daha karmaşık. Üstelik sezgisel istek-yanıt yaklaşımı burada eksik. Ancak gördüğünüz gibi bir isteği işlerken bağlantının kopması hataya yol açmayacaktır. Ayrıca, kullanıcı hizmete birkaç cihazdan (örneğin cep telefonundan ve tabletten) bağlıysa, yanıtın her iki cihaza da geldiğinden emin olabilirsiniz.

İlginç bir şekilde, gelen mesajları işlemeye yönelik kod, hem müşterinin kendisinden etkilenen olaylar için hem de diğer istemcilerden gelenler de dahil olmak üzere diğer olaylar için aynı (% 100 değil) hale gelir.

Ancak gerçekte, tek yönlü akışın işlevsel bir tarzda (RX ve benzeri kullanılarak) ele alınabilmesi nedeniyle ek bir avantaj elde ederiz. Ve bu zaten ciddi bir artı, çünkü özünde uygulama tamamen reaktif ve aynı zamanda işlevsel bir yaklaşım kullanılarak yapılabiliyor. Yağ programları için bu, geliştirme ve destek kaynaklarından önemli ölçüde tasarruf sağlayabilir.

Bu yaklaşımı yatay ölçeklendirmeyle birleştirirsek, bonus olarak bir sunucuya istek gönderip diğerinden yanıt alma olanağına sahip oluruz. Böylece müşteri kendisi için uygun olan hizmeti seçebilecek ve içerideki sistem yine de olayları doğru bir şekilde işleyebilecektir.

Etkinlik Kaynağı

Bildiğiniz gibi dağıtılmış bir sistemin temel özelliklerinden biri ortak bir zamanın, ortak bir kritik bölümün bulunmamasıdır. Bir işlem için, bu kodu başka kimsenin yürütmediğinden emin olduğunuz bir senkronizasyon (aynı mutekslerde) yapabilirsiniz. Ancak bu, dağıtılmış bir sistem için tehlikelidir, çünkü ek yük gerektirecektir ve aynı zamanda ölçeklendirmenin tüm güzelliğini de ortadan kaldıracaktır - tüm bileşenler yine de bir tanesini bekleyecektir.

Buradan önemli bir gerçeği anlıyoruz: Hızlı dağıtılmış bir sistem senkronize edilemez çünkü o zaman performansı düşürürüz. Öte yandan çoğu zaman bileşenler arasında belirli bir tutarlılığa ihtiyaç duyarız. Ve bunun için yaklaşımı kullanabilirsiniz. nihai tutarlılık, son güncellemeden sonra belirli bir süre boyunca ("sonunda") herhangi bir veri değişikliği olmazsa, tüm sorguların son güncellenen değeri döndüreceği garanti edilir.

Klasik veritabanları için oldukça sık kullanıldığını anlamak önemlidir. güçlü tutarlılık, her düğümün aynı bilgiye sahip olduğu (bu genellikle işlemin yalnızca ikinci sunucu yanıt verdikten sonra kurulduğu kabul edildiğinde elde edilir). Burada izolasyon seviyeleri nedeniyle bazı rahatlamalar var, ancak genel fikir aynı kalıyor; tamamen uyumlu bir dünyada yaşayabilirsiniz.

Ancak asıl göreve dönelim. Sistemin bir kısmı ile inşa edilebilirse nihai tutarlılık, o zaman aşağıdaki diyagramı oluşturabiliriz.

Bu yaklaşımın önemli özellikleri:

• Gelen her istek bir sıraya yerleştirilir.
• Hizmet, bir isteği işlerken görevleri başka kuyruklara da yerleştirebilir.
• Gelen her olayın bir tanımlayıcısı vardır (bu, tekilleştirme için gereklidir).
• Kuyruk ideolojik olarak "yalnızca ekleme" şemasına göre çalışır. Öğeleri ondan kaldıramaz veya yeniden düzenleyemezsiniz.
• Sıra FIFO şemasına göre çalışıyor (totoloji için özür dilerim). Paralel yürütme yapmanız gerekiyorsa, bir aşamada nesneleri farklı kuyruklara taşımalısınız.

Çevrimiçi dosya depolama konusunu düşündüğümüzü hatırlatmama izin verin. Bu durumda sistem şöyle görünecektir:

Diyagramdaki hizmetlerin mutlaka ayrı bir sunucu anlamına gelmemesi önemlidir. Süreç bile aynı olabilir. Bir şey daha önemli: İdeolojik olarak bunlar yatay ölçeklendirmenin rahatlıkla uygulanabileceği şekilde ayrılmış durumda.

Ve iki kullanıcı için diyagram şu şekilde görünecektir (farklı kullanıcılara yönelik hizmetler farklı renklerle belirtilmiştir):

Böyle bir kombinasyonun bonusları:

• Bilgi işlem hizmetleri ayrılmıştır. Kuyruklar da ayrılıyor. Sistem verimini artırmamız gerekiyorsa, daha fazla sunucuda daha fazla hizmet başlatmamız yeterlidir.
• Bir kullanıcıdan bilgi aldığımızda, verilerin tamamen kaydedilmesini beklememize gerek yoktur. Tam tersine sadece “tamam” yanıtını vermemiz ve ardından yavaş yavaş çalışmaya başlamamız gerekiyor. Aynı zamanda, yeni bir nesnenin eklenmesi hızlı bir şekilde gerçekleştiğinden ve kullanıcının tüm döngü boyunca tam bir geçişi beklemek zorunda olmadığından, kuyruk zirveleri yumuşatır.
• Örnek olarak, aynı dosyaları birleştirmeye çalışan bir veri tekilleştirme hizmeti ekledim. Vakaların %1'inde uzun süre çalışıyorsa, müşteri bunu neredeyse hiç fark etmeyecektir (yukarıya bakın), bu büyük bir artı çünkü artık %XNUMX hızlı ve güvenilir olmamıza gerek yok.

Ancak dezavantajları hemen fark edilir:

• Sistemimiz katı tutarlılığını kaybetti. Bu, örneğin farklı hizmetlere abone olursanız teorik olarak farklı bir durum elde edebileceğiniz anlamına gelir (çünkü hizmetlerden birinin dahili kuyruktan bildirim alacak zamanı olmayabilir). Diğer bir sonuç olarak sistemin artık ortak zamanı yoktur. Yani, örneğin tüm olayları yalnızca varış zamanına göre sıralamak imkansızdır çünkü sunucular arasındaki saatler senkronize olmayabilir (dahası, iki sunucuda aynı saatin olması bir ütopyadır).
• Artık hiçbir olay basitçe geri alınamaz (bir veritabanında yapılabileceği gibi). Bunun yerine yeni bir etkinlik eklemeniz gerekir – telafi olayı, son durumu gereken duruma değiştirecektir. Benzer bir alandan örnek olarak: geçmişi yeniden yazmadan (ki bu bazı durumlarda kötüdür), git'te bir işlemi geri alamazsınız, ancak özel bir işlem yapabilirsiniz. geri alma taahhüdü, aslında sadece eski durumu döndürür. Ancak hem hatalı taahhüt hem de geri alma geçmişte kalacaktır.
• Veri şeması yayından yayına değişebilir, ancak eski olaylar artık yeni standarda güncellenemeyecek (çünkü olaylar prensip olarak değiştirilemiyor).

Gördüğünüz gibi Event Sourcing, CQRS ile iyi çalışıyor. Üstelik, verimli ve kullanışlı kuyruklara sahip, ancak veri akışlarını ayırmadan bir sistem uygulamak zaten başlı başına zordur çünkü kuyrukların tüm olumlu etkisini etkisiz hale getirecek senkronizasyon noktaları eklemeniz gerekecektir. Her iki yaklaşımın aynı anda uygulanması, program kodunun biraz ayarlanmasını gerektirir. Bizim durumumuzda, sunucuya bir dosya gönderilirken yanıt yalnızca "tamam" olarak gelir, bu yalnızca "dosya ekleme işleminin kaydedildiği" anlamına gelir. Resmi olarak bu, verilerin diğer cihazlarda zaten mevcut olduğu anlamına gelmez (örneğin, veri tekilleştirme hizmeti dizini yeniden oluşturabilir). Ancak bir süre sonra istemci "X dosyası kaydedildi" tarzında bir bildirim alacaktır.

Sonuç olarak:

• Dosya gönderme durumlarının sayısı artıyor: Klasik "dosya gönderildi" yerine iki tane alıyoruz: "dosya sunucudaki kuyruğa eklendi" ve "dosya depoya kaydedildi." İkincisi, diğer cihazların dosyayı almaya başlayabileceği anlamına gelir (kuyrukların farklı hızlarda çalışması gerçeğine göre ayarlanmıştır).
• Gönderim bilgileri artık farklı kanallardan geldiği için dosyanın işlenme durumunu alabilmek için çözümler üretmemiz gerekiyor. Bunun bir sonucu olarak: klasik istek-cevaptan farklı olarak, istemci dosyayı işlerken yeniden başlatılabilir, ancak bu işlemin durumu doğru olacaktır. Üstelik bu öğe aslında kutudan çıktığı gibi çalışır. Sonuç olarak: Artık başarısızlıklara karşı daha hoşgörülüyüz.

Sharding

Yukarıda açıklandığı gibi, olay kaynak bulma sistemleri katı bir tutarlılıktan yoksundur. Bu, aralarında herhangi bir senkronizasyon olmadan birden fazla depolamayı kullanabileceğimiz anlamına gelir. Sorunumuza yaklaşarak şunları yapabiliriz:

• Dosyaları türüne göre ayırın. Örneğin, resimlerin/videoların kodu çözülebilir ve daha verimli bir format seçilebilir.
• Hesapları ülkeye göre ayırın. Pek çok yasa nedeniyle bu gerekli olabilir ancak bu mimari şeması otomatik olarak böyle bir fırsat sağlıyor

Verileri bir depolama biriminden diğerine aktarmak istiyorsanız artık standart araçlar yeterli değildir. Ne yazık ki bu durumda kuyruğu durdurmanız, taşıma işlemini gerçekleştirmeniz ve ardından başlatmanız gerekir. Genel durumda, veriler "anında" aktarılamaz, ancak olay kuyruğu tamamen depolanmışsa ve önceki depolama durumlarının anlık görüntülerine sahipseniz, olayları aşağıdaki gibi yeniden oynatabiliriz:

• Olay Kaynağında her olayın kendi tanımlayıcısı vardır (ideal olarak azalmayan). Bu, depolamaya bir alan (en son işlenen öğenin kimliği) ekleyebileceğimiz anlamına gelir.
• Tüm olayların birkaç bağımsız depolama için işlenebilmesi için kuyruğu kopyalıyoruz (ilki, verilerin zaten depolandığı depo, ikincisi ise yeni ama yine de boş). Tabii ki ikinci sıra henüz işlenmiyor.
• İkinci kuyruğu başlatıyoruz (yani olayları tekrar oynatmaya başlıyoruz).
• Yeni kuyruk nispeten boş olduğunda (yani, bir öğenin eklenmesi ile öğenin alınması arasındaki ortalama zaman farkı kabul edilebilir olduğunda), okuyucuları yeni depolama birimine geçirmeye başlayabilirsiniz.

Gördüğünüz gibi sistemimizde katı bir tutarlılık yoktu ve hâlâ da yok. Yalnızca nihai tutarlılık vardır, yani olayların aynı sırada (ancak muhtemelen farklı gecikmelerle) işlendiğinin garantisi vardır. Ve bunu kullanarak, sistemi durdurmadan dünyanın diğer tarafına nispeten kolay bir şekilde veri aktarabiliyoruz.

Dolayısıyla, dosyalar için çevrimiçi depolamayla ilgili örneğimize devam edersek, böyle bir mimari bize zaten bir dizi bonus sağlıyor:

• Nesneleri dinamik bir şekilde kullanıcılara yaklaştırabiliyoruz. Bu sayede hizmet kalitenizi artırabilirsiniz.
• Bazı verileri şirketler bünyesinde saklayabiliriz. Örneğin, Kurumsal kullanıcılar genellikle verilerinin kontrollü veri merkezlerinde saklanmasını gerektirir (veri sızıntılarını önlemek için). Parçalama yoluyla bunu kolayca destekleyebiliriz. Müşterinin uyumlu bir bulutu varsa (örneğin, Azure kendi kendine barındırılıyor).
• Ve en önemli şey bunu yapmak zorunda olmamamızdır. Sonuçta, başlangıçta tüm hesaplar için tek bir depolama alanından oldukça memnun oluruz (hızlı bir şekilde çalışmaya başlamak için). Ve bu sistemin en önemli özelliği genişletilebilir olmasına rağmen ilk aşamada oldukça basit olmasıdır. Milyonlarca ayrı bağımsız kuyruk vb. ile çalışan kodu hemen yazmanıza gerek yok. Gerekirse bu gelecekte yapılabilir.

Statik İçerik Barındırma

Bu nokta oldukça açık görünebilir, ancak az çok standart yüklü bir uygulama için yine de gereklidir. Özü basittir: tüm statik içerik, uygulamanın bulunduğu sunucudan değil, özellikle bu göreve adanmış özel sunuculardan dağıtılır. Sonuç olarak, bu işlemler daha hızlı gerçekleştirilir (koşullu nginx, dosyaları bir Java sunucusundan daha hızlı ve daha ucuza sunar). Ayrıca CDN mimarisi (İçerik Dağıtım Ağı) dosyalarımızı son kullanıcılara daha yakın bulmamızı sağlar ve bu da hizmetle çalışmanın rahatlığı üzerinde olumlu bir etkiye sahiptir.

Statik içeriğin en basit ve en standart örneği, bir web sitesi için bir dizi komut dosyası ve görseldir. Onlarla her şey basit - önceden biliniyorlar, ardından arşiv CDN sunucularına yükleniyor ve oradan son kullanıcılara dağıtılıyor.

Ancak gerçekte statik içerik için lambda mimarisine benzer bir yaklaşım kullanabilirsiniz. Dosyaları kullanıcılara dağıtmamız gereken görevimize (çevrimiçi dosya depolama) dönelim. En basit çözüm, her kullanıcı isteği için gerekli tüm kontrolleri (yetkilendirme vb.) yapan ve ardından dosyayı doğrudan depomuzdan indiren bir hizmet oluşturmaktır. Bu yaklaşımın temel dezavantajı, statik içeriğin (ve belirli bir revizyona sahip bir dosyanın aslında statik içeriktir) iş mantığını içeren aynı sunucu tarafından dağıtılmasıdır. Bunun yerine aşağıdaki diyagramı yapabilirsiniz:

• Sunucu bir indirme URL'si sağlar. Dosya_id + anahtar biçiminde olabilir; burada anahtar, önümüzdeki XNUMX saat boyunca kaynağa erişim hakkı veren mini dijital bir imzadır.
• Dosya basit nginx ile aşağıdaki seçeneklerle dağıtılır:
  • İçerik önbelleğe alma. Bu hizmet ayrı bir sunucuda bulunabildiğinden, en son indirilen tüm dosyaları diskte saklama olanağıyla kendimize geleceğe yönelik bir rezerv bıraktık.
  • Bağlantı oluşturma sırasında anahtarın kontrol edilmesi
• İsteğe bağlı: akış içeriği işleme. Örneğin, hizmetteki tüm dosyaları sıkıştırırsak, zip açma işlemini doğrudan bu modülde yapabiliriz. Sonuç olarak: IO işlemleri ait oldukları yerde yapılır. Java'daki bir arşivleyici kolayca çok fazla ekstra bellek ayıracaktır, ancak bir hizmeti iş mantığıyla Rust/C++ koşullarına yeniden yazmak da etkisiz olabilir. Bizim durumumuzda farklı süreçler (hatta hizmetler) kullanılıyor ve bu nedenle iş mantığı ile IO işlemlerini oldukça etkili bir şekilde ayırabiliyoruz.

Bu şema statik içeriğin dağıtımına pek benzemez (çünkü statik paketin tamamını bir yere yüklemeyiz), ancak gerçekte bu yaklaşım tam olarak değişmez verilerin dağıtımıyla ilgilidir. Üstelik bu şema, içeriğin yalnızca statik olmadığı, değişmez ve silinemez bloklar kümesi olarak temsil edilebildiği (eklenebilmelerine rağmen) diğer durumlara da genelleştirilebilir.

Başka bir örnek olarak (güçlendirme amacıyla): Jenkins/TeamCity ile çalıştıysanız, her iki çözümün de Java ile yazıldığını biliyorsunuzdur. Her ikisi de hem yapı orkestrasyonunu hem de içerik yönetimini yöneten bir Java işlemidir. Özellikle her ikisinin de “sunucudan dosya/klasör aktarma” gibi görevleri var. Örnek olarak: yapıların yayınlanması, kaynak kodunun aktarılması (aracı kodu doğrudan depodan indirmediğinde, ancak sunucu bunu onun için yaptığında), günlüklere erişim. Tüm bu görevler IO yüklerine göre farklılık gösterir. Yani, karmaşık iş mantığından sorumlu sunucunun aynı zamanda büyük veri akışlarını kendi içinden etkili bir şekilde aktarabilmesi gerektiği ortaya çıktı. Ve en ilginç olanı, böyle bir işlemin tamamen aynı şemaya göre aynı nginx'e devredilebilmesidir (isteğe veri anahtarının eklenmesi dışında).

Ancak sistemimize dönersek benzer bir diyagramla karşılaşırız:

Gördüğünüz gibi sistem radikal biçimde daha karmaşık hale geldi. Artık dosyaları yerel olarak depolayan yalnızca bir mini işlem değil. Artık gerekli olan en basit destek, API sürüm kontrolü vb. değildir. Bu nedenle tüm diyagramlar çizildikten sonra genişletilebilirliğin maliyete değip değmeyeceğini ayrıntılı olarak değerlendirmek en doğrusudur. Ancak sistemi genişletmek istiyorsanız (daha da fazla sayıda kullanıcıyla çalışmak dahil), o zaman benzer çözümlere gitmeniz gerekecektir. Ancak sonuç olarak sistem mimari olarak artan yüke hazırdır (neredeyse her bileşen yatay ölçeklendirme için klonlanabilir). Sistem durdurulmadan güncellenebilir (yalnızca bazı işlemler biraz yavaşlayacaktır).

En başta da söylediğim gibi, artık bazı İnternet hizmetleri artan yük almaya başladı. Ve bazıları düzgün çalışmayı bırakmaya başladı. Aslında sistemler tam da işin para kazanması gerektiği anda başarısız oldu. Yani, teslimatı ertelemek yerine, müşterilere "gelecek aylar için teslimatınızı planlayın" önermek yerine sistem basitçe "rakiplerinize gidin" dedi. Aslında bu, düşük verimliliğin bedelidir: Kayıplar, tam da kârın en yüksek olduğu anda ortaya çıkar.

Sonuç

Bütün bu yaklaşımlar daha önce biliniyordu. Aynı VK, görüntüleri görüntülemek için uzun süredir Statik İçerik Barındırma fikrini kullanıyor. Pek çok çevrimiçi oyun, oyuncuları bölgelere bölmek veya oyun konumlarını (eğer dünyanın kendisi bir ise) ayırmak için Parçalama şemasını kullanır. E-postada Event Sourcing yaklaşımı aktif olarak kullanılmaktadır. Verilerin sürekli olarak alındığı çoğu alım satım uygulaması, aslında alınan verileri filtreleyebilmek için bir CQRS yaklaşımı üzerine kurulmuştur. Yatay ölçeklendirme birçok hizmette uzun süredir kullanılıyor.

Ancak en önemlisi, tüm bu kalıpların modern uygulamalarda (tabii ki uygunsa) uygulanması çok kolay hale geldi. Bulutlar, Parçalama ve yatay ölçeklendirmeyi hemen sunar; bu, farklı veri merkezlerinde farklı özel sunucuları kendiniz sipariş etmekten çok daha kolaydır. CQRS, RX gibi kütüphanelerin gelişmesi nedeniyle de olsa çok daha kolay hale geldi. Yaklaşık 10 yıl önce nadir bir web sitesi bunu destekleyebilirdi. Apache Kafka'ya sahip hazır kapsayıcılar sayesinde Event Sourcing'in kurulumu da inanılmaz derecede kolaydır. 10 yıl önce bu bir yenilik olurdu, şimdi sıradanlaştı. Statik İçerik Barındırma konusunda da durum aynıdır: Daha kullanışlı teknolojiler sayesinde (ayrıntılı dokümantasyon ve geniş bir yanıt veri tabanının bulunması dahil), bu yaklaşım daha da basit hale geldi.

Sonuç olarak, oldukça karmaşık bir dizi mimari modelin uygulanması artık çok daha basit hale geldi, bu da ona önceden daha yakından bakmanın daha iyi olduğu anlamına geliyor. On yıllık bir uygulamada, yüksek uygulama ve işletme maliyeti nedeniyle yukarıdaki çözümlerden biri terk edilmişse, şimdi yeni bir uygulamada veya yeniden düzenleme sonrasında, zaten mimari olarak hem genişletilebilir hem de genişletilebilir bir hizmet oluşturabilirsiniz ( performans açısından) ve müşterilerden gelen yeni taleplere hazır (örneğin, kişisel verileri yerelleştirmek için).

Ve en önemlisi: Basit bir uygulamanız varsa lütfen bu yaklaşımları kullanmayın. Evet, güzel ve ilginçler, ancak 100 kişinin yoğun ziyaret ettiği bir site için, genellikle klasik bir monolitle idare edebilirsiniz (en azından dışarıdan, içerideki her şey modüllere vb. ayrılabilir).

Kaynak: habr.com