1 dakikada 1 milyar isteğe karşı direnin! Bazı uygulamalar bunu nasıl yapıyor? | Güç Projesi
Yazar | Afan Blog
Üretildi | CSDN Blogu
Mühürlü Resim | Görsel Çin
Bazı uygulamalar dakikada 1 milyar isteği nasıl işliyor?
Mimari evrim yoluMilyon düzeyinde eşzamanlılık: Saniyede 1 milyon istek.
On milyonlarca eşzamanlı: Dakikada 600 milyon istek, neredeyse talep sınırıdır.
Mimarinin tasarımı ve mimarinin optimizasyonu gereksinimleri karşılamalıdır ve sınırlama olmaksızın optimize edilemez.
temel kavram
(1) Dağıtılmış (sistemde, farklı sunuculara birden çok modül yerleştirilmiştir)
(2) Küme (bir yazılım parçası birden fazla sunucuya yerleştirilir ve bir bütün olarak bir hizmet türü sağlar)
(3) Yüksek kullanılabilirlik (sistemdeki bazı düğümler başarısız olur, diğer düğümler çalışmaya devam etmesi veya ilgili işleme planlarına sahip olması için görevi devralabilir)
(4) Yük dengeleme (istekleri birden çok düğüme eşit olarak gönderin)
Mimari evrimi:
Bağımsız mimari
DNS sunucusu, alan adı çözümlemesi için bir sunucudur. İşlevi, www.taobao.com gibi alan adlarını DNS aracılığıyla gerçek IP adreslerine dönüştürmektir ve tarayıcı daha sonra bu IP'ye karşılık gelen tomcat'e erişecektir.
Darboğaz: kullanıcı büyümesi, tomcat ve veritabanı arasındaki kaynak rekabeti, tek makine performansı işi desteklemek için yeterli değildir.
İlk kez: Tomcat ve veritabanı ayrı olarak dağıtılır (en yaygın mimari)
Tomcat ve veritabanı, sunucu kaynaklarını ayrı ayrı işgal ederek ilgili performanslarını önemli ölçüde artırır (tomcat sunucusu büyük bir bellek bulur, DB sunucusu büyük bir sabit disk bulur, daha geniş bant genişliği).
Darboğaz: Kullanıcı sayısı artıyor ve eşzamanlı veritabanı okuma ve yazma, özellikle okuma, bir darboğaz haline geliyor.
Veritabanı kümesi tarafından çözülmeyeceğini unutmayın.
İkinci evrim: yerel önbelleğin ve hatta dağıtılmış önbelleğin tanıtımı
Tomcat sunucusuna (Java programının bulunduğu yer) bir önbellek eklemek, veritabanına erişmeden önce çoğu isteği (özellikle sorguları) yakalayabilir.
Redis, yeterli değilse Tomcat sunucusuna yerleştirilir.
Daha sonra Redis tek başına bir sunucuya yerleştirilebilir veya birkaç Redis sunucusu edinebilir ve bunları ana-bağımlı senkronizasyon olarak yapılandırabilirsiniz (kullanılabilirliği iyileştirmek için gözlemciler ekleyebilirsiniz).
Darboğaz: Kullanıcı sayısı artıyor ve eşzamanlılık baskısı esas olarak bağımsız tomcat üzerinde ve yanıt yavaş yavaş yavaşlıyor.
Üçüncü evrim: ters proxy ve yük dengelemeye giriş
Her bir Tomcat'e çok sayıda kullanıcı talebini eşit olarak dağıtmak için ters proxy kullanın (genel olarak, Tomcat 100 eşzamanlılığa karşılık gelir, nginx sunucu performansına bağlı olarak 50.000 eşzamanlılığa karşılık gelir).
Darboğaz: Uygulama sunucusunun destekleyebileceği eşzamanlılık miktarı büyük ölçüde artmıştır ve önbelleğe alma kapasitesi kolayca genişletilebilir. Eşzamanlılık miktarındaki artış, veritabanına daha fazla isteğin girmesi anlamına gelir ve bağımsız veritabanı sonunda darboğaz haline gelir.
Dördüncü evrim: veritabanı okuma ve yazma işlemlerinin ayrılması
Veritabanı bir okuma kitaplığına ve bir yazma kitaplığına bölünmüştür Birden fazla okuma kitaplığı olabilir Yazma kitaplığındaki veriler bir eşitleme mekanizması aracılığıyla okuma kitaplığıyla eşitlenir. Veritabanı ara yazılımı (Mycat), veritabanının ayrı okuma ve yazma işlemlerini organize etmek için kullanılır.
Darboğaz: İşletmeler kademeli olarak artmaktadır ve farklı işletmeler arasındaki trafik boşluğu büyüktür ve farklı işletmeler, birbirlerinin performansını etkileyen veritabanları için doğrudan rekabet etmektedir.
Beşinci evrim: veritabanı işletmeye bölünmüştür
Farklı iş verilerini farklı veritabanlarında depolayarak, işletmeler arasındaki kaynak rekabeti azaltılır ve yüksek trafiğe sahip işletmeler için daha fazla sunucu devreye alınabilir.
Darboğaz: Kullanıcı sayısı arttıkça, tek makineli yazma kitaplığı kademeli olarak performans darboğazına ulaşacaktır.
Altıncı evrim: veritabanının büyük tablosunu küçük tablolara ayırın
Diğer bağlantılar yukarıdaki ile aynıdır.
Örneğin, sipariş oluşturma için, tablolar aya veya hatta saate göre oluşturulabilir.
Bu yaklaşıma dağıtılmış veritabanı denilebilir, ancak mantıksal olarak hala bir bütün olarak tam bir veritabanıdır.Şimdi, bu tür sorunların çeşitli kullanım senaryolarını hedefleyen MPP (Massively Parallel Processing) adlı bir mimari var.
Darboğaz: Hem veritabanı hem de tomcat, yatay olarak büyük ölçekte ölçeklenebilir ve sonunda bağımsız nginx, darboğaz haline gelecektir.
Yedinci evrim: birden fazla Nginx yükünü dengelemek için LVS kullanmak
LVS, işletim sisteminin çekirdek modunda çalışan ve TCP isteklerini veya üst düzey ağ protokollerini iletebilen bir yazılımdır.Dağıtım performansı Nginx'inkinden çok daha yüksektir, yaklaşık 100.000'dir.
F5, LVS'nin yaptığına benzer bir donanımdır, ancak daha yüksek performans ve daha pahalıdır.
Bu sayede kullanıcılar on milyonlara veya yüz milyonlara ulaşabilir.
Darboğaz: LVS bir darboğaza ulaşır veya kullanıcılar farklı alanlara dağılır ve sunucu odasından uzaklık farklıdır, bu da farklı erişim gecikmelerine neden olur.
Sekizinci evrim: Makine odasında yük dengeleme sağlamak için DNS yoklaması
DNS'de birden çok IP'ye karşılık gelen bir alan adı yapılandırın.
Her IP adresi, farklı bir bilgisayar odasındaki sanal bir IP'ye karşılık gelir.
Bilgisayar odası seviyesinin yatay genişlemesini başarmak, halihazırda talep eşzamanlılığı, 100 milyonun üzerinde bir işleme planı ve bir veya birkaç milyar eşzamanlılık açısından, şimdilik kimsenin düşünmediği bir şey.
Darboğaz: Geri çağırma ve analiz için gittikçe daha fazla gereksinim vardır ve veritabanı tek başına çeşitli ihtiyaçları çözemez.
Dokuzuncu evrim: NoSQL veritabanlarının ve arama motorlarının tanıtımı
Veri miktarı belirli bir ölçeğe ulaştığında, ilişkisel veritabanları artık uygulanabilir değildir ve büyük miktarda veriye sahip sorgular için MySQL sonuçları çalıştıramayabilir. Büyük verilerin işlenmesi, dağıtılmış dosya sistemi HDFS aracılığıyla saklanır. Anahtar için Değer türü veriler HBase, Redis vb. Tarafından tarama sorgularında işlenir, ES vb. İle çözülebilir, çok boyutlu analiz için kylin, Druid vb. İle çözülebilir.
Daha fazla bileşenin kullanılması, kaçınılmaz olarak sistemin karmaşıklığını büyük ölçüde artıracaktır.Farklı bileşenlerin verilerinin senkronize edilmesi ve tutarlılık konularının dikkate alınması gerekir.
Onuncu evrim: büyük uygulamalar küçük uygulamalara bölünmüştür
Yapı diyagramı yukarı ve aşağı değişmeden kalır:
Bireysel uygulamaların sorumluluklarını daha net hale getirmek için uygulamaları iş segmentlerine göre bölün, bağımsız yükseltmeler ve birbirleri arasında yinelemeler ve hatta kısmi işlevler kapatılabilir.
Darboğaz: Farklı uygulamalar arasında ortak modüller vardır ve bu, ortak işlevleri içeren parçalar yükseltildiğinde ilgili tüm kodların yükseltilmesine yol açar.
Mikro hizmetlere ayrılmış on birinci evrim
Şimdi yazdığımız SpringCloud proje yapısına benzer şekilde, özellikle kullanıcılar, ödeme ve diğer işlevler birden fazla uygulamada mevcut olduğunda, bunları çıkarmak daha verimli olur.
Şimdi bu efekti elde etmek istiyorsanız, hazır bir çerçeve kullanabilirsiniz.
Daha fazla evrim, arayüz yönetimi için ESB servis veri yolu, işletim ortamı izolasyonu sağlamak için konteynerleştirme teknolojisi, büyük ölçekli sistemleri taşımak için bulut platformu
Bulut platformundaki çeşitli kavramlar:
IaaS: Donanım kaynakları için geçerli olabilecek bir hizmet olarak altyapı.
PaaS: Bulut platformlarının ortak teknik bileşenlerinin geliştirilmesini ve bakımını sağlayan bir hizmet olarak platform.
SaaS: Hizmet olarak yazılım, dağıtımdan sonra bir uygulama geliştirin, işleve veya gereksinime göre ödeme yapın.
sonuç olarak
(1) Yapısal düzenlemenin yukarıdaki yola göre gelişmesi gerekiyor mu?
Şart değil! ! ! Yukarıdakiler, mevcut evrimsel yol olan e-ticaretin yönü ile ilgilidir.
(2) Uygulanacak sistem için mimari ne ölçüde tasarlanmalıdır?
Yeter artık, neyin yeterli olduğunu açıkça sorun ve tasarım bir sonraki aşamada kullanıcı sayısı ve performans göstergelerinin gereksinimlerini karşılamalıdır.
(3) Mikro hizmet ve büyük veri mimarisi?
Bu iki mimari, aynı sistemdeki farklı bağlantıların sorunlarını çözer.
İyi ile kötüyü karşılaştırmaya ve onlarla ayrı ayrı ilgilenmeye gerek yoktur.
Telif hakkı bildirimi: Bu makale, CSDN blogger "Afan Blog" un orijinal makalesidir ve CC 4.0 BY-SA telif hakkı sözleşmesini takip eder.Lütfen orijinal kaynak bağlantısını ve yeniden basım için bu bildirimi ekleyin.
Orijinal bağlantı:
https://blog.csdn.net/qq_43107323/article/details/104919132
Sıcak makale önerisi
Yazılım sahtekarlığı sahtekarlığını ortaya çıkarmak: "günah keçisi" nasıl inşa edilir?
Eski kod kötü yazılmış, ne yapabilirim?
Python salgın sırasında küresel borsa trendini tarıyor ve gülemez ...
Programcılar kodun olmadığı bir çağda işlerini nasıl koruyabilirler?
Sıfırdan oluşturun: Yüz özelliği algılama için CNN ve TensorFlow kullanın
Başka bir ses: Konteyner gelecek mi?
Bitcoin'in benzersiz zaman zinciri, madencilik ücretleri ve tezgah üstü işlemlerin kavramlarını keşfedin
