g u t x .com.tr İpek yolu - Çin'i anlamaya götürürüm

Sunucu tarafı yüksek eş zamanlı dağıtılmış mimarinin evrimi

1 Genel Bakış

Bu makale, sunucu mimarisinin evrim sürecini yüz eşzamanlılıktan on milyonlarca eşzamanlılığa tanıtmak için bir örnek olarak Taobao kullanıyor.Aynı zamanda, her bir evrim aşamasında karşılaşılacak ilgili teknolojileri listeliyor, böylece herkes mimarinin evrimine genel bir bakışa sahip olacak. Bilişsel, makale sonunda mimari tasarımın bazı ilkelerini özetlemektedir.

2. Temel kavramlar

Mimariyi tanıtmadan önce, bazı okuyucuların mimari tasarımdaki bazı kavramları anlamasını önlemek için, en temel kavramlardan bazıları şunlardır:

dağıtılmış
Sistemdeki birden fazla modül, dağıtılmış bir sistem olarak adlandırılabilecek farklı sunucularda konuşlandırılır.Örneğin, Tomcat ve veritabanı farklı sunucularda konuşlandırılır veya aynı işleve sahip iki Tomcat farklı sunucularda konuşlandırılır.
Yüksek kullanılabilirlik
Sistemdeki bazı düğümler başarısız olduğunda, diğer düğümler onu devralabilir ve hizmet vermeye devam edebilir, bu durumda sistemin yüksek kullanılabilirlikli olduğu düşünülebilir.
Küme
Belirli bir yazılım alanı birden fazla sunucuya yerleştirilir ve bir bütün olarak bir hizmet sınıfı sağlar ve bu bütüne küme denir. Örneğin, Zookeeper'daki Master ve Slave, birden çok sunucuda ayrı ayrı konuşlandırılır ve merkezi konfigürasyon hizmetleri sağlamak için bir bütün oluşturur. Ortak bir kümede, istemci hizmetleri almak için genellikle herhangi bir düğüme bağlanabilir ve kümedeki bir düğüm çevrimdışı olduğunda, diğer düğümler otomatik olarak yönetimi devralabilir ve hizmetleri sağlamaya devam edebilir. Bu, kümenin yüksek oranda kullanılabilir olduğunu gösterir.
Yük dengeleme
Sisteme bir istek gönderildiğinde, istek bir şekilde birden fazla düğüme eşit olarak dağıtılır, böylece sistemdeki her düğüm istek yükünü eşit şekilde işleyebilir, bu durumda sistemin yük dengelenmiş olduğu düşünülebilir.
Proxy ilet ve ters proxy
Sistem harici ağa erişmek istediğinde, istek bir proxy sunucu aracılığıyla iletilir. Harici ağ açısından, proxy sunucusu tarafından başlatılan erişimdir.Şu anda, proxy sunucusu bir ileri proxy uygular; sisteme harici bir istek girdiğinde, proxy sunucusu İstek, sistemdeki belirli bir sunucuya iletilir ve harici istekler için yalnızca proxy sunucusu onunla etkileşime girer.Şu anda proxy sunucusu bir ters proxy uygular. Basitçe ifade etmek gerekirse, ileri proxy, bir proxy sunucunun harici ağa erişmek için sistemin içini değiştirdiği bir süreçtir ve ters proxy, sisteme erişim için harici isteklerin proxy sunucusu aracılığıyla dahili sunucuya iletildiği bir işlemdir.

3. Mimari evrimi

3.1 Bağımsız mimari

Taobao'yu örnek olarak alın. Web sitesinin başlangıcında uygulama sayısı ve kullanıcı sayısı azdır ve Tomcat ve veritabanı aynı sunucu üzerinde konuşlandırılabilir. Tarayıcı www.taobao.com'a bir istek başlattığında, önce DNS sunucusu (alan adı sistemi) aracılığıyla alan adını gerçek IP adresi 10.102.4.1'e dönüştürür ve ardından tarayıcı IP'ye karşılık gelen Tomcat'i ziyaret eder.

Kullanıcı sayısı arttıkça, Tomcat ve veritabanı kaynaklar için rekabet eder ve tek bir makinenin performansı işi desteklemek için yeterli değildir

3.2 İlk evrim: Tomcat ve veritabanı ayrı ayrı dağıtılır

Tomcat ve veritabanı, sunucu kaynaklarını ayrı ayrı işgal ederek ilgili performanslarını önemli ölçüde artırır.

Kullanıcı sayısı arttıkça, veritabanının eşzamanlı olarak okunması ve yazılması bir darboğaz haline gelir

3.3 İkinci evrim: yerel önbelleğin ve dağıtılmış önbelleğin tanıtımı

Aynı Tomcat sunucusuna veya aynı JVM'ye yerel bir önbellek ekleyin ve popüler ürün bilgilerini veya popüler ürün html sayfalarını vb. Önbelleğe almak için harici olarak dağıtılmış bir önbellek ekleyin. Önbelleğe alma yoluyla, çoğu istek veritabanını okumadan ve veritabanına yazmadan önce durdurulabilir ve veritabanı baskısı büyük ölçüde azaltılır. İlgili teknolojiler şunları içerir: memcached'i yerel bir önbellek olarak kullanmak, Redis'i dağıtılmış bir önbellek olarak kullanmak ve önbellek tutarlılığı, önbellek penetrasyonu / bozulması, önbellek çığı ve sıcak verilerin merkezi olarak geçersiz kılınması gibi sorunlar.

Önbellek erişim isteklerinin çoğuna direndi. Kullanıcı sayısı arttıkça, eşzamanlılık baskısı esas olarak bağımsız Tomcat'in üzerine düştü ve yanıt yavaş yavaş yavaşladı.

3.4 Üçüncü evrim: yük dengelemeyi sağlamak için ters proxy'yi sunmak

Tomcat'i birden fazla sunucuya ayrı ayrı dağıtın ve istekleri her Tomcat'e eşit olarak dağıtmak için ters proxy yazılımı (Nginx) kullanın. Burada Tomcat'in 100'e kadar eşzamanlılığı ve Nginx'in 50.000'e kadar eşzamanlılığı desteklediği varsayılmaktadır Teorik olarak, Nginx istekleri 500 Tomcat'e dağıtır ve 50.000 eşzamanlılığa direnebilir. İlgili teknolojiler şunları içerir: Nginx ve HAProxy, her ikisi de ağın yedinci katmanında çalışan, esas olarak http protokolünü destekleyen ve aynı zamanda oturum paylaşımı, dosya yükleme ve indirme sorunlarını içeren ters proxy yazılımıdır.

Ters proxy, uygulama sunucusunun destekleyebileceği eşzamanlılık miktarını büyük ölçüde artırır, ancak eşzamanlılık miktarındaki artış aynı zamanda veritabanına daha fazla isteğin girmesi ve bağımsız veritabanının sonunda darboğaz haline gelmesi anlamına gelir.

3.5 Dördüncü Evrim: Veritabanı Okuma ve Yazmanın 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, eşitleme mekanizması aracılığıyla okuma kitaplığıyla eşitlenir. En son yazılan verileri sorgulaması gereken senaryolar için, önbelleğe bir kopya daha yazabilirsiniz. Önbellekten en son verileri alın. İlgili teknolojiler şunları içerir: Veritabanının ayrılabildiği, okunabildiği ve yazılabildiği bir veritabanı ara yazılımı olan Mycat ve alt veritabanı alt tablosu Müşteri bunu alt düzey veritabanına erişmek için kullanır ve ayrıca veri senkronizasyonu ve veri tutarlılığı sorunlarını içerir. .

İşletmeler kademeli olarak büyüyor ve farklı işletmeler arasındaki trafikte büyük bir boşluk var. Farklı işletmeler, birbirlerinin performansını etkileyen veritabanları için doğrudan rekabet ediyor

3.6 Beşinci evrim: veritabanı işletmeye göre bölünmüştür

İşletmeler arasındaki kaynak rekabetini azaltmak için farklı işletmelerin verilerini farklı veritabanlarında saklayın.Çok sayıda ziyarete sahip işletmeler için, onları desteklemek için daha fazla sunucu dağıtılabilir. Aynı zamanda, çapraz iş tabloları doğrudan analizle ilişkilendirilemez ve başka yollarla çözülmesi gerekir, ancak bu makalenin odak noktası bu değildir ve ilgilenenler kendi başlarına çözüm arayabilirler.

Kullanıcı sayısı arttıkça, tek makineli yazma kitaplığı kademeli olarak performans darboğazına ulaşacaktır.

3.7 Altıncı evrim: büyük masayı küçük masalara ayırın

Örneğin, verileri gözden geçirmek için, ürün kimliğine göre karma oluşturabilir ve depolama için ilgili tabloya yönlendirebilirsiniz; ödeme kayıtları için, saate göre bir tablo oluşturabilirsiniz ve her saat tablosu küçük tablolara bölünmeye devam eder ve verileri yönlendirmek için kullanıcı kimliği veya kayıt numarası kullanılır. . Gerçek zamanlı işlemler için tablo verisi miktarı yeterince küçük olduğu ve istekler birden çok sunucuda küçük tablolara eşit olarak dağıtılabildiği sürece, veritabanı yatay genişletme yoluyla performansı artırabilir. Daha önce bahsedilen Mycat, büyük tabloların küçük tablolara bölünmesi durumunda erişim kontrolünü de destekler.

Bu yaklaşım, veritabanı çalıştırma ve bakımının zorluğunu ve DBA için daha yüksek gereksinimleri önemli ölçüde artırır. Veritabanı bu yapıya göre tasarlandığında, zaten dağıtılmış bir veritabanı olarak adlandırılabilir, ancak bu sadece bir bütün olarak mantıksal bir veritabanıdır.Veritabanındaki farklı bileşenler, alt veritabanı ve alt tablonun yönetimi ve talebi gibi farklı bileşenler tarafından gerçekleştirilir. Dağıtım, Mycat tarafından gerçekleştirilir.SQL analizi, bağımsız bir veritabanı tarafından gerçekleştirilir.Okuma-yazma ayrımı, ağ geçitleri ve mesaj kuyrukları tarafından uygulanabilir. Sorgu sonuçlarının özeti, veritabanı arayüz katmanı tarafından uygulanabilir. Bu mimari aslında MPP'dir (büyük ölçekli Paralel işleme) mimarisi.

Şu anda, hem açık kaynak hem de ticari kullanım için birçok MPP veritabanı vardır. Daha popüler açık kaynaklar arasında Greenplum, TiDB, Postgresql XC, HAWQ vb., Nantah General GBase, Ruifan Technologynin Snowball DB, Huaweis LibrA, vb. Gibi ticari olanlar vardır. Farklı MPP veritabanlarının farklı odak noktaları vardır. Örneğin, TiDB daha çok dağıtılmış OLTP senaryolarına odaklanır ve Greenplum daha çok dağıtılmış OLAP senaryolarına odaklanır. Bu MPP veritabanları temelde Postgresql, Oracle ve MySQL gibi SQL standart destek yetenekleri sağlar. Bir sorgu, dağıtılmış bir yürütme planına ayrıştırılabilir ve paralel yürütme için her makineye dağıtılabilir ve son olarak veriler, veritabanının kendisi tarafından özetlenir ve geri döndürülür.Ayrıca izin yönetimi, alt veritabanı alt tablosu, işlem, veri kopyalama vb. Gibi yetenekler sağlar. 100'den fazla düğüme sahip kümeleri destekleyebilir, bu da veritabanı çalıştırma ve bakım maliyetini büyük ölçüde azaltır ve veritabanının yatay genişlemeye ulaşmasını sağlar.

Hem veritabanı hem de Tomcat yatay olarak ölçeklenebilir ve desteklenebilir eşzamanlılık büyük ölçüde iyileştirilir.Kullanıcı sayısı arttıkça, tek makineli Nginx sonunda bir darboğaz haline gelecektir.

3.8 Yedinci evrim: Birden çok Nginx yükünü dengelemek için LVS veya F5 kullanın

Darboğaz Nginx'te olduğundan, iki Nginx katmanı aracılığıyla birden çok Nginx'in yük dengelemesini sağlamak imkansızdır. Şekildeki LVS ve F5, ağın dördüncü katmanında çalışan yük dengeleme çözümleridir.LVS, işletim sisteminin çekirdek durumunda çalışan bir yazılımdır ve TCP isteklerini veya daha üst düzey ağ protokollerini iletebilir, bu nedenle desteklenen protokoller daha fazladır Zengin ve performans Nginx'ten çok daha yüksek, tek bir makine LVS'nin yüz binlerce eşzamanlı istek iletimini destekleyebileceği varsayılabilir; F5, LVS tarafından sağlanan yeteneklere benzer, LVS'den daha yüksek performansa sahip ancak pahalı bir yük dengeleme donanımıdır . LVS, yazılımın bağımsız bir sürümü olduğundan, LVS'nin bulunduğu sunucu arızalanırsa, tüm arka uç sistemine erişilemez, bu nedenle yedek bir düğüm gerekir. Canlı bir yazılımı sanal bir IP'yi simüle etmek için kullanabilir ve ardından sanal IP'yi birden fazla LVS sunucusuna bağlayabilirsiniz. Tarayıcı sanal IP'ye eriştiğinde, yönlendirici tarafından gerçek LVS sunucusuna yönlendirilir. Ana LVS sunucusu çalışmadığında, canlı kalan yazılım Yönlendiricideki yönlendirme tablosunu otomatik olarak güncelleyin ve LVS sunucusunun yüksek kullanılabilirliğinin etkisini elde etmek için sanal IP'yi başka bir normal LVS sunucusuna yeniden yönlendirin.

Yukarıdaki şekilde Nginx katmanından Tomcat katmanına yapılan çizimin, tüm Nginx'in istekleri tüm Tomcats'a ilettiği anlamına gelmediği burada belirtilmelidir. Gerçek kullanımda, Tomcat'in bir bölümüne bağlı birkaç Nginx olabilir. Bu Nginx Keepalived ile yüksek kullanılabilirlik elde edilir ve diğer Nginx başka bir Tomcat'e bağlanır, böylece erişilebilir Tomcats sayısı iki katına çıkarılabilir.

LVS aynı zamanda bağımsız bir makine olduğundan, eşzamanlılık sayısı yüzbinlere çıktıkça, LVS sunucusu sonunda bir darboğaza ulaşacaktır. Şu anda, kullanıcı sayısı on milyonlara hatta yüz milyonlara ulaşır. Kullanıcılar farklı bölgelere dağılmıştır ve sunucu odasına olan uzaklık farklıdır. Erişim gecikmesi önemli ölçüde farklı olacaktır

3.9 Sekizinci evrim: DNS yoklaması aracılığıyla makine odasında yük dengeleme

DNS sunucusunda bir alan adı, birden çok IP adresine karşılık gelecek şekilde yapılandırılabilir ve her IP adresi, farklı bir bilgisayar odasındaki sanal bir IP'ye karşılık gelir. Bir kullanıcı www.taobao.com'u ziyaret ettiğinde, DNS sunucusu, kullanıcının ziyaret etmesi için bir IP seçmek üzere bir yoklama stratejisi veya başka stratejiler kullanacaktır. Bu yöntem, bilgisayar odasının yük dengesini gerçekleştirebilir.Şimdiye kadar sistem bilgisayar odası seviyesinin yatay genişlemesini sağlayabilir.On milyonlardan yüz milyonlara kadar eşzamanlılık, bilgisayar odası eklenerek çözülebilir.Sistemin girişindeki talep eşzamanlılığı artık sorun değil. .

Verilerin zenginliği ve işin gelişmesiyle birlikte, erişim ve analiz gereksinimleri gittikçe daha fazla hale geliyor ve veritabanı tek başına bu kadar zengin gereksinimleri çözemiyor.

3.10 Dokuzuncu Evrim: NoSQL veritabanları ve arama motorları gibi teknolojilerin tanıtımı

Veritabanındaki veriler belirli bir ölçeğe ulaştığında, veritabanı karmaşık sorgular için uygun değildir ve sadece sıradan sorguların senaryolarını karşılayabilir. İstatistiksel rapor senaryoları için, veri miktarı büyük olduğunda sonuçlar çalıştırılamayabilir ve karmaşık sorgular çalıştırılırken diğer sorgular yavaşlayacaktır.Tam metin alma ve değişken veri yapısı gibi senaryolar için, veritabanı doğal olarak uygun değildir. Bu nedenle, belirli senaryolar için uygun çözümlerin tanıtılması gerekmektedir. Örneğin, yığın dosya depolama için dağıtılmış dosya sistemi HDFS ile çözülebilir.Anahtar değer verileri için HBase ve Redis ile çözülebilir.Tam metin alma senaryoları için ElasticSearch gibi arama motorları tarafından çözülebilir.Çok boyutlu analiz senaryoları için çözülebilir. Kylin veya Druid gibi çözümlerle çözün.

Elbette, daha fazla bileşenin kullanılması, sistemin karmaşıklığını da artıracaktır.Farklı bileşenler tarafından kaydedilen verilerin senkronize edilmesi, tutarlılık konularının dikkate alınması ve bu bileşenleri yönetmek için daha fazla işletim ve bakım yöntemine ihtiyaç vardır.

Çok sayıda ihtiyacı çözmek için daha fazla bileşen eklendiğinde, iş boyutu büyük ölçüde genişletilebilir ve ardından bir uygulama çok fazla işletme kodu içerir, işletme yükseltme yinelemesi zorlaşır

3.11 Onuncu Evrim: Büyük Uygulamaları Küçük Uygulamalara Dönüştürme

Uygulama kodunu iş sektörlerine göre bölün, böylece tek bir uygulamanın sorumlulukları daha net olur ve bağımsız olarak yükseltilebilirler. Şu anda, uygulamalar arasında, dağıtılmış yapılandırma merkezi Zookeeper tarafından çözülebilecek bazı ortak yapılandırmalar söz konusu olabilir.

Farklı uygulamalar arasında paylaşılan modüller vardır ve uygulama tarafından yapılan ayrı yönetim, aynı kodun birden çok kopyasına neden olacak ve genel işlevler yükseltildiğinde tüm uygulama kodlarının yükseltilmesine neden olacaktır.

3.12 On Birinci Evrim: Yeniden kullanım işlevi mikro hizmetlere ayrılmıştır

Kullanıcı yönetimi, sipariş, ödeme, kimlik doğrulama ve diğer işlevler birden fazla uygulamada mevcutsa, bu işlevlerin kodları, yönetim için tek bir hizmet oluşturmak üzere ayrı ayrı çıkarılabilir.Bu tür hizmetler mikro hizmetler, uygulamalar ve hizmetler olarak adlandırılır. Genel hizmetlere HTTP, TCP veya RPC istekleri gibi birden çok yöntemle erişilir ve her bir hizmet ayrı bir ekip tarafından yönetilebilir. Ek olarak, hizmetlerin kararlılığını ve kullanılabilirliğini iyileştirmek için, hizmet yönetimi, mevcut sınırlama, birleştirme ve sınıflandırma gibi işlevler Dubbo ve SpringCloud gibi çerçeveler aracılığıyla uygulanabilir.

Farklı hizmetlerin farklı arayüz erişim yöntemleri vardır.Uygulama kodunun, hizmetleri kullanmak için birden fazla erişim yöntemine uyarlanması gerekir.Ayrıca, uygulamalar erişim hizmetlerine ve hizmetlere de erişebilir.Çağrı zinciri çok karmaşık hale gelecek ve mantık kaotik hale gelecektir.

3.13 Onikinci Evrim: Hizmet arabirimlerinin erişim farklılıklarını korumak için Kurumsal Hizmet Veriyolu ESB'nin tanıtımı

ESB birleşik erişim protokolü dönüşümü aracılığıyla, arka uç hizmetlere, hizmetlere ve hizmetlere erişmek için ESB aracılığıyla birleştirilen uygulama, ESB aracılığıyla da birbirini arar ve böylece sistem birleştirme derecesini azaltır. Bu tek uygulama birden fazla uygulamaya bölünmüştür, genel hizmetler yönetim için ayrı ayrı çıkarılır ve kurumsal mesaj veriyolu, hizmetler arasındaki bağlantı sorununu çözmek için kullanılır.Bu, mikro hizmetlere benzer, SOA (hizmet odaklı) olarak adlandırılan mimaridir. Sunum çok benzer olduğu için mimarinin karıştırılması kolaydır. Kişisel anlayış, mikro hizmet mimarisi, işletim ve bakım yönetimi için kamu hizmetlerini sistemden ayrı ayrı çıkarma fikrini ifade ederken, SOA mimarisi hizmetleri bölen ve hizmet arabirimi erişimini birleştirilmiş hale getiren mimari bir fikri ifade eder. Mikro hizmetler fikrini içerir.

İşin sürekli gelişmesiyle birlikte, uygulama ve hizmetlerin sayısı artmaya devam edecek ve uygulamaların ve hizmetlerin dağıtımı daha karmaşık hale gelecektir.Aynı sunucuda birden çok hizmetin dağıtılması, işletim ortamı çakışmaları sorununu çözmelidir.Ayrıca, büyük promosyonlar için dinamik genişleme ve daralma gereklidir. Servis performansının yatay olarak genişletilmesi gereken senaryoda, işletim ortamının hazırlanması ve servisin yeni eklenen servis üzerine konuşlandırılması gerekir ve işletme ve bakım çok zorlaşır.

3.14 On Üçüncü Evrim: İşletim ortamının izolasyonunu ve dinamik hizmet yönetimini gerçekleştirmek için kapsayıcı teknolojisine giriş

Şu anda en popüler konteynerleştirme teknolojisi Docker'dır ve en popüler konteyner yönetimi hizmeti Kubernetes'tir (K8S). Uygulamalar / hizmetler Docker görüntüleri olarak paketlenebilir ve görüntüler K8S aracılığıyla dinamik olarak dağıtılabilir ve dağıtılabilir. Docker görüntüsü, uygulamanın / hizmetin çalışan kodunu içeren ve işletim ortamının gerçek ihtiyaçlara göre ayarlandığı uygulamanızı / hizmetinizi çalıştırabilen minimal bir işletim sistemi olarak anlaşılabilir. Tüm "işletim sistemi" bir görüntü olarak paketlendikten sonra, ilgili hizmetleri dağıtması gereken makinelere dağıtılabilir ve hizmet doğrudan Docker görüntüsünü başlatarak başlatılabilir, bu da hizmetin dağıtımını ve çalışmasını kolaylaştırır.

Büyük promosyondan önce, hizmet performansını artırmak için Docker aynalamasını başlatmak için sunucular mevcut makine kümesinde bölümlere ayrılabilir.Büyük promosyondan sonra, ayna makinedeki diğer hizmetleri etkilemeden kapatılabilir (bölüm 3.14'ten önce, Yeni bir makinede çalışan hizmetin, hizmete uyum sağlamak için sistem yapılandırmasını değiştirmesi gerekir; bu, makinedeki diğer hizmetlerin işletim ortamının yok olmasına neden olur).

Konteynırlaştırma teknolojisinin kullanımından sonra, hizmet dinamik genişleme ve daralma sorunu çözülür, ancak makinenin yine de şirketin kendisi tarafından yönetilmesi gerekir.Büyük bir promosyon olmadığında, büyük promosyon, makinenin maliyeti ve işletme ve bakım maliyetiyle başa çıkmak için büyük miktarda makine kaynağının hala boşta olması gerekir. Son derece yüksek ve kaynak kullanımı düşük

3.15 On Dördüncü Evrim: Bulut Platformunda Taşıma Sistemi

Sistem, dinamik donanım kaynakları sorununu çözmek için genel bulutun devasa makine kaynaklarını kullanarak genel bulut üzerinde dağıtılabilir. Büyük promosyon döneminde, bulut platformunda daha fazla kaynak için geçici olarak başvurun ve hizmetleri hızlı bir şekilde dağıtmak için Docker ile K8S'yi birleştirin , Büyük promosyonun bitiminden sonra kaynakları serbest bırakın, gerçekten talep üzerine ödeme yapın, kaynak kullanımını büyük ölçüde iyileştirin ve işletme ve bakım maliyetlerini büyük ölçüde azaltın.

Sözde bulut platformu, talep üzerine donanım kaynakları (CPU, bellek, ağ vb. Gibi) için dinamik olarak uygulayabileceği birleşik kaynak yönetimi aracılığıyla büyük miktarda makine kaynağını bütün bir kaynağa ayırmak ve üzerinde genel işlemler sağlamaktır. Sistem, kullanıcıların kullanması için ortak teknik bileşenler (Hadoop teknoloji yığını, MPP veritabanı vb.) Sağlar ve hatta gelişmiş uygulamalar sağlar.Kullanıcılar ihtiyaçlarını çözebilirler (uygulama içinde hangi teknolojinin kullanıldığıyla uğraşmak zorunda kalmadan ses ve video kod dönüştürme hizmetleri gibi) , Posta hizmeti, kişisel blog vb.). Bulut platformuna aşağıdaki kavramlar dahildir:

IaaS: Hizmet olarak altyapı. Yukarıda belirtilen makine kaynaklarına karşılık gelen bir bütün olarak bir kaynak olarak birleştirilir ve donanım kaynakları için dinamik olarak uygulanabilir;
PaaS: Hizmet olarak platform. Yukarıda bahsedilenlere karşılık olarak, sistem geliştirme ve bakımını kolaylaştırmak için ortak teknik bileşenlerin sağlanması;
SaaS: Hizmet olarak yazılım. Yukarıda belirtilen iyi geliştirilmiş uygulamalar veya hizmetler sağlamaya karşılık olarak, işlev veya performans gereksinimlerine göre ödeme yapın.

Bu noktada yukarıda bahsedilen sorunların yüksek eşzamanlı erişim probleminden servis mimarisi ve sistem uygulama seviyesine kadar kendi çözümleri vardır, ancak aynı zamanda yukarıdaki girişte aslında kasıtlı olarak çapraz geçiş gibi göz ardı edildiği anlaşılmalıdır. Bilgisayar odasında veri senkronizasyonunun pratik sorunları, dağıtılmış işlemlerin uygulanması vb. Bu konular, bir şans olduğunda gelecekte ayrı ayrı tartışılacaktır.

4. Mimari Tasarımın Özeti

Yapının ayarlanması yukarıda belirtilen evrim yolunu izlemeli mi?
Hayır, yukarıda bahsedilen mimari evrim dizisi, belirli bir yön için sadece tek bir iyileştirmedir.Gerçek senaryolarda, aynı anda çözülmesi gereken birkaç sorun olabilir veya önce başka bir açıdan darboğaza ulaşılabilir. Gerçek sorunlara göre çözülmelidir. Örneğin, devlet kategorisindeki eşzamanlılık miktarının büyük olmayabileceği ancak işin çok zengin olabileceği bir senaryoda, yüksek eşzamanlılık çözülmesi gereken anahtar bir sorun değil, şu anda ilk öncelik zengin gereksinimleri olan bir çözüm olabilir.
Sistemin uygulanabilmesi için mimari ne ölçüde tasarlanmalıdır?
Net performans göstergelerine sahip tek uygulamalı bir sistem için, mimarinin sistemin performans göstergesi gereksinimlerini destekleyecek şekilde tasarlanmış olması yeterlidir, ancak mimariyi ihtiyaç duyulmayacak şekilde genişletmek için bir arayüz olması gerekir. E-ticaret platformu gibi gelişen sistem için, kullanıcı hacmi ve performans göstergelerinin bir sonraki aşamasının gereksinimlerini karşılayacak şekilde tasarlanmalı ve daha yüksek eşzamanlılığı ve daha zengin işletmeyi desteklemek için işletmenin büyümesine göre mimariyi yinelemeli olarak yükseltmelidir. .
Sunucu tarafı mimarisi ile büyük veri mimarisi arasındaki fark nedir?
Sözde "büyük veri" aslında toplu veri toplama, temizleme ve dönüştürme, veri depolama, veri analizi ve veri hizmetleri gibi sahne çözümleri için genel bir terimdir.Her sahne, Flume ile veri toplama gibi çeşitli isteğe bağlı teknolojileri içerir, Sqoop, Kettle, vb., Veri depolama, dağıtılmış dosya sistemleri HDFS, FastDFS, NoSQL veritabanları HBase, MongoDB vb. İçerir; veri analizi, Spark teknolojisi yığınını, makine öğrenme algoritmalarını vb. İçerir. Genel olarak büyük veri mimarisi, iş ihtiyaçlarına göre çeşitli büyük veri bileşenlerini entegre eden bir mimaridir.Genellikle dağıtılmış depolama, dağıtılmış hesaplama, çok boyutlu analiz, veri ambarı, makine öğrenimi algoritmaları ve diğer yetenekler sağlar. Sunucu tarafı mimarisi daha çok uygulama organizasyon seviyesi mimarisine atıfta bulunur ve temeldeki yetenekler genellikle büyük veri mimarisi tarafından sağlanır.
Mimari tasarımın herhangi bir ilkesi var mı?

N + 1 tasarımı. Sistemdeki her bileşenin tek bir hata noktası olmamalıdır;
Tasarımı geri alın. Sistemin ileriye dönük uyumlu olduğundan emin olun ve sistem yükseltildiğinde sürümü geri almanın bir yolu olmalıdır;
Tasarımı devre dışı bırakın. Belirli işlevlerin mevcut olup olmadığını kontrol eden ve sistem arızalandığında hızla çevrimdışı olabilen bir yapılandırma sağlamalıdır;
İzleme tasarımı. Tasarım aşamasında izleme araçları dikkate alınmalıdır;
Çoklu canlı veri merkezi tasarımı. Sistem son derece yüksek kullanılabilirlik gerektiriyorsa, birden çok veri merkezinde birden çok etkinlik gerçekleştirmeyi düşünün; sistem en az bir bilgisayar odasının gücü kesildiğinde bile kullanılabilir durumda olur;
Olgun teknolojiyi kullanın. Yeni geliştirilen veya açık kaynak teknolojiler genellikle birçok gizli hataya sahiptir.Eğer ticari desteksiz bir sorun varsa bu bir felaket olabilir;
Kaynak izolasyon tasarımı. Tek bir işletme tüm kaynakları kullanmaktan kaçınmalıdır;
Mimari yatay olarak ölçeklenebilmelidir. Darboğaz sorunu ancak sistem yatay olarak genişletilebildiği zaman etkili bir şekilde önlenebilir;
Çekirdeksiz satın alın. Temel olmayan işlevler çözülmesi için çok sayıda Ar-Ge kaynağı gerektiriyorsa, olgun ürünler satın almayı düşünün;
Emtia donanımı kullanın. Ticari donanım, donanım arızası olasılığını etkili bir şekilde azaltabilir;
Hızlıca yineleyin. Sistem, hızlı bir şekilde küçük işlevsel modüller geliştirmeli, doğrulama için mümkün olan en kısa sürede çevrimiçi olmalı ve sorunları mümkün olan en kısa sürede keşfetmeli ve sistem teslim riskini büyük ölçüde azaltmalıdır;
Vatansız tasarım. Hizmet arabirimi durum bilgisiz hale getirilmelidir ve mevcut arabirime erişim, en son erişilen arabirimin durumuna bağlı değildir.