1. Mimarlık nedir ve özü

Yazılım endüstrisinde, mimarinin ne olduğu hakkında birçok tartışma vardır ve herkesin kendi anlayışı vardır. Bu kralın söylediği yapı ile onun anladığı yapı ille de aynı değildir. Bu nedenle mimariyi tartışmadan önce öncelikle mimarinin kavramsal tanımını tartışıyoruz.Kavram insanların dünyayı ve iletişim araçlarını anlamalarının temelidir.Mimarlık kavramının anlaşılması farklıysa iletişim doğal olarak sorunsuz olmayacaktır.

Linux'un bir mimarisi, MySQL'in bir mimarisi ve JVM'nin de bir mimarisi var.Java geliştirme, MySQL depolama kullanan ve Linux üzerinde çalışan iş sistemlerinin de mimarileri var. Hangisine dikkat etmeliyim? Yukarıdaki sorunları açıklığa kavuşturmak için, birkaç ilgili ve benzer kavramı sıralamanız gerekir: sistem ve alt sistemler, modüller ve bileşenler, çerçeve ve mimari:

1.1. Sistem ve Alt Sistem

Sistem: Bir grup ilgili kişiden oluşan, belirli kurallara göre çalışan ve tek tek bileşenlerin bağımsız olarak tamamlayamayacağı görevleri tamamlayabilen bir grubu ifade eder.

Alt sistem: Aynı zamanda, çoğunlukla daha büyük bir sistemin parçası olan bir grup ilgili kişiden oluşan bir sistemdir.

1.2. Modüller ve bileşenler

Bunların hepsi, sistemi farklı açılardan ayıran sistemin bir parçasıdır. Modüller mantıksal birimlerdir ve bileşenler fiziksel birimlerdir.

Modül, sistemi mantıksal olarak ayrıştırmak, yani karmaşık sorunları basitleştirmek, bölmek ve ele geçirmektir. Modülün ayrıntı düzeyi büyük veya küçük olabilir ve bir sistem, birkaç alt sistem, belirli bir hizmet, işlev, sınıf, yöntem, işlev bloğu vb. Olabilir.

Bileşenler, uygulama hizmetlerini, veritabanlarını, ağları, fiziksel makineleri ve MQ, kapsayıcılar ve Nginx gibi teknik bileşenleri içerebilir.

1.3. Çerçeve ve mimari

Çerçeve, bileşen uygulamasının belirtimidir, örneğin: MVC, MVP, MVVM, vb., Açık kaynak çerçeveler gibi temel işlevleri sağlayan ürünlerdir: Ruby on Rails, Spring, Laravel, Django, vb. Doğrudan veya buna dayalı olarak kullanılabilir. İkincil gelişme.

Çerçeve normdur ve mimari yapıdır.

Burada mimariyi yeniden tanımlıyorum: yazılım mimarisi, bir yazılım sisteminin en üst düzey yapısını ifade eder.

Mimari, sistematik düşünme, artıları ve eksileri tartma ve nihai net sistem iskeletinden sonra mevcut kaynakların kısıtlamaları altındaki en makul karardır: alt sistemler, modüller, bileşenler. İşbirliği ilişkileri, kısıtlama özellikleri ve yol gösterici ilkelerin yanı sıra. Takımdaki herkese ideolojik düzeyde fikir birliğine varmaları için rehberlik edecek. Dört husus söz konusudur:

Sistematik düşünceye dayalı makul kararlar: teknoloji seçimi, çözümler vb.

Açık sistem iskeleti: Sistemin bileşenlerini açıkça tanımlayın.

Sistem işbirliği ilişkisi: çeşitli bileşenlerin iş taleplerini karşılamak için nasıl işbirliği yaptığı.

Kısıtlama normları ve yol gösterici ilkeler: sistemin düzenli, verimli ve istikrarlı çalışmasını sağlamak.

Bu nedenle, mimarın şunları yapma yeteneği vardır: İşletmeyi anlayın, genel durumu kontrol edin, uygun teknolojileri seçin, temel sorunları çözün ve Ar-Ge'nin uygulanmasına rehberlik edin .

Mimarinin özü, sistemi düzenli bir şekilde yeniden yapılandırarak, mevcut iş gelişimine uyum sağlamak ve hızla genişleyebilmektir.

Öyleyse mimari tasarım için ne tür bir sistem düşünülmelidir Teknoloji sebepsiz yere geliştirilmeyecek ve yönlendirilmeyecektir.Mimarlığın gelişimi ve talebi iş tarafından yönlendirilir.

Mimari tasarım tamamen iş amaçlıdır,

Gereksinimler nispeten karmaşıktır.

İşlevsel olmayan gereksinimler tüm sistemde önemli bir yere sahiptir.

Sistemin uzun bir yaşam döngüsü vardır ve ölçeklenebilirliğe ihtiyaç duyar.

Sistem, bileşen veya entegrasyon ihtiyaçlarına dayanmaktadır.

İş süreçlerinin yeniden yapılandırılmasına duyulan ihtiyaç.

2. Mimari katmanlama ve sınıflandırma

Mimari sınıflandırma, iş mimarisi, uygulama mimarisi, teknik mimari, kod mimarisi, dağıtım mimarisi olarak alt gruplara ayrılabilir

İş mimarisi stratejidir, uygulama mimarisi taktiktir ve teknik mimari ekipmandır. Bunların arasında uygulama mimarisi geçmişi birbirine bağlar, bir yandan iş mimarisinin uygulamasını üstlenir, diğer yandan teknoloji seçimini etkiler.

İşe aşina olun, bir iş mimarisi oluşturun, iş mimarisine dayalı uygun bir uygulama mimarisi oluşturun ve son olarak teknik mimariyi uygulayın.

Mevcut ihtiyaçlara uygun bir uygulama mimarisinin nasıl seçileceği ve mimarinin sorunsuz bir geçişini sağlamak için geleceğe nasıl bakılacağı, yazılım geliştiricilerin, özellikle mimarların derinlemesine düşünmesi gereken bir sorudur.

2.1. İşletme mimarisi (genel bakış mimarisi) :

İş planlaması, iş modülleri, iş süreçleri, tüm sistemin işini bölme, etki alanı modelini tasarlama ve gerçek işi soyut nesnelere dönüştürme dahil.

Optimal mimari yoktur, yalnızca en uygun mimari vardır.Tüm sistem tasarım ilkeleri, nihai hedef olarak iş problemlerini çözmeye dayanmalıdır. Asıl işin dışında kalan teknik duyarlılık mimarisi, çoğu zaman sistemi büyük bir deliğe getirir. İş kaprisli olmayan herhangi bir mimari Hepsi holigan.

Tüm sorunların ön koşulu, bugün karşı karşıya olduğumuz iş hacminin ne kadar büyük olduğunu, büyüme eğiliminin ne olduğunu ve yüksek eşzamanlılığı çözme sürecinin adım adım bir süreç olması gerektiğini bulmaktır. Makul bir yapı, iş gelişimini 1 ila 2 yıl önceden tahmin edebilir. Bu şekilde, teknolojiye öncülük eden iş büyümesinin etkisi karşılığında makul bir fiyat ödenebilir.

Jingdong iş yapısına bir göz atın (çevrimiçi paylaşım şeması):

2.2. Uygulama mimarisi (profil mimarisi, mantıksal mimari diyagramı da denir) :

Soyutlama katmanı ve programlama arayüzü dahil olmak üzere donanımdan uygulamaya soyutlama. Uygulama mimarisi ve iş mimarisi birbirini tamamlayan bir ilişki içindedir. İşletme mimarisinin her parçası bir uygulama mimarisine sahiptir.

benzer:

Uygulama mimarisi: Bağımsız bir konuşlandırılabilir birim olarak bir uygulama, sistem işlevi organizasyonunu, kod geliştirmeyi, dağıtımı ve işletim ve bakımı derinden etkileyen net bir sınır tanımlar.Uygulama mimarisi, sistemin hangi uygulamalara sahip olduğunu ve uygulamaların nasıl bölündüğünü tanımlar. Ve işbirliği. Buradaki sözde uygulama, her mantık modülü veya alt sistemidir.

Uygulama mimarisi şemasında iki temel nokta vardır:

. Sorumluluklar Bölümü: Uygulamaların sınırlarını tanımlayın (her mantıksal modül veya alt sistem)

• Mantıksal katmanlama
• Alt sistem ve modül tanımı.
• Anahtar kategori.

. Sorumluluklar arasında işbirliği:

• Arayüz protokolü: Uygulamanın harici çıkışı için arayüz.
• İşbirliği ilişkisi: uygulamalar arasındaki çağrı ilişkisi.

Katmanlama uygulamanın iki yolu vardır:

• Birincisi, uygulamaları iş derinliğinin bir bölümü olan web ön uç / ara hizmetler / arka uç görevlerine bölmek gibi uygulamaları işlevsel işlem sırasına göre bölen yatay bölümdür (yatay).
• Diğeri, uygulamaları farklı iş türlerine göre bölen dikey bölümdür (dikey) Örneğin, faturalama sistemi, iş genişliği için bir bölüm olan üç bağımsız uygulamaya bölünebilir.

Uygulamaların kombinasyonu, uygulamaların karmaşık iş durumlarını tamamlamak için nasıl birlikte çalıştığını yansıtır; bu, esas olarak uygulamalar arasındaki iletişim mekanizması ve veri biçiminde yansıtılır. İletişim mekanizması eşzamanlı çağrı / eşzamansız mesaj / paylaşılan DB erişimi vb. Olabilir. Veri biçimi metin olabilir / XML / JSON / Binary vb.

Uygulamanın bölünmesi işletmeye dönüktür ve iş mimarisini yansıtır ve uygulamanın önyargısı teknik mimariyi etkileyen teknolojiye yöneliktir. Bölünme iş karmaşıklığını azaltır, sistem daha düzenli hale gelir ve teknik karmaşıklık artar ve sistem daha düzensizdir.

Uygulama mimarisinin özü, sistem bölünmesi yoluyla iş ve teknolojinin karmaşıklığını dengelemek ve sistemin dağınık olmamasını sağlamaktır.

Sistemin benimsediği ne tür bir uygulama mimarisi, kurumsal geliştirme aşaması ve iş özellikleri de dahil olmak üzere iş karmaşıklığından etkilenir; aynı zamanda, BT teknolojisi geliştirme aşaması ve dahili teknik personel seviyesi dahil olmak üzere teknik karmaşıklıktan etkilenir. İş karmaşıklığı (büyük iş hacmi dahil) kaçınılmaz olarak teknik karmaşıklığa yol açacaktır Uygulama mimarisinin amacı, teknik karmaşıklıktan kaçınırken ve iş mimarisinin uygulanmasını sağlarken iş karmaşıklığını çözmektir.

2.3. Veri Mimarisi

Veri mimarisi, veritabanının tasarımına rehberlik eder.Sadece geliştirmeye dahil olan veritabanı ve varlık modelini değil, aynı zamanda fiziksel mimaride veri depolamanın tasarımını da dikkate almak gerekir.

2.4. Kod mimarisi (geliştirme mimarisi olarak da adlandırılır) :

Alt sistem kod mimarisi esas olarak geliştiriciler için pratik rehberlik sağlar.Kod mimarisi yeterince tasarlanmamışsa, genel mimari tasarımını etkileyecektir. Örneğin, şirketteki farklı geliştirme ekipleri farklı teknoloji yığınları veya bileşenleri kullanır ve sonuç olarak şirketin genel mimari tasarımı kontrolden çıkacaktır.

Kod mimarisinin ana tanımı:

. Kod birimi:

• Konfigürasyon tasarımı
• Çerçeve, sınıf kitaplığı.

. Kod birimi organizasyonu:

• Kodlama standartları, kodlama kuralları.
• Proje modülü bölümü
• Mvc tasarımı gibi üst dosya yapısı tasarımı.
• Bağımlılık

2.5. Teknik Mimari

Teknik mimari: Uygulama sistemini oluşturan gerçek işletim bileşenlerini (lvs, nginx, tomcat, php-fpm, vb.), Bu işletim bileşenleri arasındaki ilişkiyi ve donanıma dağıtım stratejisini belirleyin.

Teknik mimari, esas olarak sistemin işlevsel olmayan özelliklerini dikkate alır ve sistemin yüksek kullanılabilirliği, yüksek performansı, genişlemesi, güvenliği, ölçeklenebilirliği ve basitliği hakkında sistem düzeyinde bir kavrayışa sahiptir.

Sistem mimarisinin tasarımı, mimarın yazılım ve donanımın işlevleri ve performansı hakkında mükemmel bilgiye sahip olmasını gerektirir ki bu aynı zamanda mimari tasarım çalışmasındaki en zor görevdir.

2.6. Dağıtım topolojisi mimari diyagramı (gerçek fiziksel mimari diyagramı) :

Birkaç düğümün konuşlandırılması, düğümler arasındaki ilişki, sunucuların yüksek kullanılabilirliği, ağ arayüzleri ve protokoller vb. Dahil olmak üzere topoloji, uygulamanın nasıl çalıştığını, operasyonun performansını, sürdürülebilirliği ve ölçeklenebilirliği belirler. Yapı temeli. Bu şema esas olarak işletme ve bakım mühendislerinin hedefidir.

Fiziksel mimari, temel olarak donanım seçimi ve topolojiyi, yazılımın donanımla eşleştirilmesini ve yazılım ile donanımın karşılıklı etkisini dikkate alır.

3. Mimari seviyesi

Göstermek için piramidin mimari seviyesini kullanıyoruz, üst seviye alt seviyeyi içeriyor:

• Sistem seviyesi : Tüm sistemin çeşitli bölümleri arasındaki ilişki ve nasıl yönetileceği: katmanlama
• Uygulama seviyesi : Yani tek bir uygulamanın genel mimarisi ve sistemdeki tek bir uygulama ile ilişkisi.
• Modül seviyesi : Kodun modülerleştirilmesi, verilerin ve durumun yönetimi gibi uygulama içerisindeki modül mimarisidir.
• Kod seviyesi : Yani, kod seviyesi güvence mimarisi uygulamasından.

Stratejik tasarım ve taktik tasarım

Mimari piramidine dayanarak, sistem mimarisinin stratejik tasarımı ve taktik tasarımının mükemmel kombinasyonuna sahibiz:

• Stratejik tasarım : İş mimarisi, mimarlara sistem mimarisinin nasıl tasarlanacağı konusunda rehberlik etmek için kullanılır.
• Taktik tasarım : Uygulama mimarisi iş mimarisine göre tasarlanmalıdır.
• Taktik uygulama : Uygulama mimarisi belirlendikten sonra teknoloji seçimidir.

4. Uygulama mimarisi gelişimi

İş mimarisi verimliliktir, uygulama mimarisi üretim ilişkileridir ve teknik mimari üretim araçlarıdır. İş mimarisi, uygulama mimarisini belirler ve uygulama mimarisinin iş mimarisine uyarlanması gerekir ve iş mimarisinin sürekli gelişimiyle, uygulama mimarisi sonunda teknik mimarinin temeline oturur.

Mimarinin evrimi: tek uygulama dağıtılmış uygulama hizmeti mikro hizmet

4.1. Tek uygulama

İşletmenin başında iş görece basittir.Sadece basit bir senaryo uygulanır.Uygulama hizmeti veri ekleme, silme, değiştirme ve basit mantığı destekler.Tek bir uygulama gereksinimleri karşılayabilir.

Tipik bir üç seviyeli mimari, ön uç (Web / mobil terminal) + ara iş mantığı katmanı + veritabanı katmanı. Bu, tipik bir Java Spring MVC veya Python Django çerçeve uygulamasıdır. Mimari diyagram aşağıdaki gibidir:

Monolitik uygulamalar için, fonksiyonel olmayan gereksinimler:

Performans gereksinimleri: performansı artırmak için önbellek kullanın

Eşzamanlılık gereksinimleri: eşzamanlılığı iyileştirmek için kümeleri kullanın

Okuma ve yazma ayrımı: veritabanı okuma ve yazma ayrımı

Ters proxy ve CDN hızlandırması kullanın

Dağıtılmış dosyaları ve dağıtılmış veritabanlarını kullanın

Monolitik uygulamaların devreye alınması ve test edilmesi daha kolaydır.Projenin ilk aşamalarında, monolitik uygulamalar iyi çalışabilir. Bununla birlikte, talep artmaya devam ettikçe, geliştirme ekibine giderek daha fazla insan katılıyor ve kod tabanı hızla genişliyor. Yavaş yavaş, tekli uygulamalar gittikçe daha fazla şişirilir, sürdürülebilirlik ve esneklik kademeli olarak azalır ve bakım maliyetleri gitgide yükselir. Monolitik uygulamaların bazı dezavantajları şunlardır:

• Yüksek karmaşıklık : Örnek olarak bir milyon satırlık tek bir uygulamayı ele alalım Projenin tamamı çok sayıda modül içeriyor, modüllerin sınırları bulanık, bağımlılıklar net değil, kod kalitesi düzensiz ve düzensiz bir şekilde yığılmış. Tüm projenin çok karmaşık olduğu düşünülebilir. Kodu her değiştirdiğinizde korkarsınız, basit bir işlev eklemek veya bir hatayı değiştirmek bile gizli kusurlar getirecektir.
• Teknik borç : Zamanın geçmesi, ihtiyaçların değişmesi ve personel devir hızı ile uygulamanın teknik borcu kademeli olarak oluşacak ve birikecektir. "Hasar yok, onarım yok", bu yazılım geliştirmede çok yaygındır ve bu fikir monolitik uygulamalarda daha da kötüdür. Kullanılan sistem tasarımının veya kodunun değiştirilmesi zordur çünkü uygulamadaki diğer modüller onu beklenmedik şekillerde kullanabilir.
• Düşük dağıtım sıklığı : Kod arttıkça, oluşturma ve dağıtma süresi de artacaktır. Monolitik bir uygulamada, her bir işlev değişikliği veya kusur onarımı, tüm uygulamayı yeniden dağıtma ihtiyacıyla sonuçlanacaktır. Tam dağıtım yöntemi uzun zaman alır, geniş bir etki aralığına sahiptir ve yüksek riskleri vardır, bu da tek bir uygulama projesinin çevrimiçi dağıtım sıklığını düşürür. Düşük dağıtım frekansı, iki sürüm arasında çok sayıda özellik değişikliğine ve kusur onarımına yol açmıştır ve hata oranı nispeten yüksektir.
• Kötü güvenilirlik Sonsuz döngü, bellek taşması vb. Gibi belirli bir uygulama hatası, tüm uygulamanın çökmesine neden olabilir.
• Sınırlı ölçeklenebilirlik : Tek bir uygulama ancak bir bütün olarak genişletilebilir ve iş modüllerinin ihtiyaçlarına göre ölçeklenemez. Örneğin, uygulamadaki bazı modüller hesaplama açısından yoğundur ve güçlü bir CPU gerektirir; bazı modüller IO yoğunlukludur ve daha fazla bellek gerektirir. Bu modüller birlikte konuşlandırıldığından, donanım seçiminde taviz verilmelidir.
• Teknolojik yeniliği engelleyin : Monolitik uygulamalar genellikle tüm sorunları çözmek için birleşik bir teknoloji platformu veya çözümü kullanır.Takımın her üyesi aynı geliştirme dilini ve çerçevesini kullanmalıdır.Yeni bir çerçeve veya yeni bir teknoloji platformu tanıtmak çok zordur.

4.2. Dağıtılmış

İşin derinleşmesiyle birlikte, işletme giderek daha fazla ürün işlevine ihtiyaç duyuyor ve her bir iş modülünün mantığı daha karmaşık hale geldi ve işin derinliği ve genişliği artarak tek uygulamayı daha fazla şişirilmiş, sürdürülebilir ve Esneklik kademeli olarak azaltılır, yeni işlevler ekleme geliştirme döngüsü uzar ve uzar ve bakım maliyeti giderek yükselir.

Şu anda, sistemin iş fonksiyonu modüllerine göre bölünmesi gerekir ve her bir modüle dağıtılmış bir sisteme servis verilir. İş modülleri farklı sunuculara yerleştirilir ve her bir iş modülü, arabirimler aracılığıyla veri alışverişi yapar.

Monolitik mimari ile karşılaştırıldığında, bu mimari yük dengeleme yetenekleri sağlar, sistem yük kapasitesini büyük ölçüde geliştirir ve web sitesinin yüksek eşzamanlılık gereksinimlerini çözer. Aşağıdaki özellikler de vardır:

• Azaltılmış kaplin : Modülleri ayırın ve modüller arasındaki bağlantıyı azaltmak için arayüz iletişimini kullanın.
• Açık sorumluluk : Projeyi birkaç alt projeye ayırın ve farklı ekipler farklı alt projelerden sorumludur.
• Genişletmesi kolay : Bir fonksiyon eklerken, sadece başka bir alt öğe eklemeniz ve diğer sistemlerin arayüzünü çağırmanız gerekir.
• Dağıtımı kolay : Dağıtılmış dağıtım esnek bir şekilde gerçekleştirilebilir.
• Kodun yeniden kullanılabilirliğini iyileştirin : Örneğin, Servis katmanı Dağıtılmış dinlenme servisi mimarisi benimsenmezse, cep telefonu Wap alışveriş merkezi, WeChat alışveriş merkezi, PC, Android ve iOS'un her bir ucuna bir Servis katmanı mantığı yazılacaktır.Geliştirme miktarı büyüktür ve birlikte sürdürmek ve yükseltmek zordur. O zaman, bir hizmet katmanını paylaşan dağıtılmış bir dinlenme hizmeti yöntemi kullanılabilir.
• Dezavantaj : Sistemler arasındaki etkileşim uzaktan iletişimi kullanmalıdır Arabirim geliştirme iş yükünü artırır, ancak avantajları dezavantajlardan ağır basar.

4.3. Mikro Hizmetler

İş modeli gittikçe daha karmaşık hale geldikten hemen sonra, üyelik seviyelerinin fiyat sınıflandırması, erişim kanalları (uygulama veya PC), satış yöntemleri (grup satın alma veya sıradan) vb. Gibi siparişler, ürünler, envanter ve fiyatlar gibi çeşitli modüller derinlemesine idi ve çok sayıda Fiyat promosyonu, bu kurallar karmaşıktır ve birbiriyle çatışması kolaydır.Her işletmeye dağılmış olan fiyat mantığının tek tip yönetilmesi ve şeffaf bir şekilde temel fiyat hizmetleri şeklinde üst düzey uygulamalara sunulması ve mikro çekirdek hizmet mimarisi yani mikro çekirdek haline getirilmesi gerekmektedir. hizmet.

Mikro hizmetlerin özellikleri:

• Geliştirilmesi ve bakımı kolay : Bir mikro hizmet yalnızca belirli bir iş işlevine odaklanır, bu nedenle net bir iş ve daha az kod içerir. Tek bir mikro hizmet geliştirmek ve sürdürmek nispeten basittir. Tüm uygulama birkaç mikro hizmet tarafından oluşturulmuştur, bu nedenle uygulamanın tamamı da kontrol edilebilir bir durumda korunacaktır.
• Tek bir mikro hizmet daha hızlı başlar : Tek bir mikro hizmet az miktarda kod içerir, bu nedenle başlatma daha hızlı olur.
• Kısmi değişikliklerin dağıtılması kolaydır : Tek uygulama değiştirildiği sürece, tüm uygulama yeniden konuşlandırılmalıdır.Microservices bu sorunu çözer. Genel olarak konuşursak, bir mikro hizmeti değiştirmek için yalnızca hizmeti yeniden dağıtmanız gerekir.
• Sınırsız teknoloji yığını : Mikro hizmet mimarisinde, teknoloji yığını proje işinin ve ekibinin özelliklerine göre makul bir şekilde seçilebilir. Örneğin, bazı hizmetler MySQL ilişkisel veritabanını kullanabilir; bazı mikro hizmetlerin grafik hesaplama gereksinimleri vardır ve Neo4j kullanılabilir; gerektiğinde bile bazı mikro hizmetler Java kullanılarak geliştirilebilir ve bazı mikro hizmetler Node.js kullanılarak geliştirilebilir.

Mikro hizmetlerin pek çok çekici yeri olmasına rağmen, ücretsiz bir öğle yemeği değildir ve kullanmanın bir bedeli vardır. Mikro hizmet mimarisini kullanmanın zorlukları.

• Daha yüksek işletim ve bakım gereksinimleri : Daha fazla hizmet, işletim ve bakıma daha fazla yatırım anlamına gelir. Monolitik bir mimaride, yalnızca bir uygulamanın normal çalışmasının garanti edilmesi gerekir. Mikro hizmetlerde düzinelerce hatta yüzlerce hizmetin normal çalışmasını ve işbirliğini sağlamak gerekir ki bu da işletim ve bakım için büyük zorluklar getirir.
• Dağıtılmış doğal karmaşıklık : Dağıtılmış bir sistem oluşturmak için mikro hizmetlerin kullanılması. Dağıtılmış bir sistem için, sistem hata toleransı, ağ gecikmesi, dağıtılmış işlemler vb. Büyük zorluklar getirecektir.
• Yüksek arayüz ayarlama maliyeti : Mikro hizmetler arayüzler aracılığıyla iletişim kurar. Belirli bir mikro hizmetin API'sini değiştirirseniz, arabirimi kullanan tüm mikro hizmetlerin ayarlanması gerekebilir.
• tekrarlayan iş : Birçok hizmet aynı işlevi kullanabilir, ancak bu işlev bir mikro hizmete ayrıştırma düzeyine ulaşmamıştır. Şu anda, her hizmet bu işlevi geliştirebilir ve bu da kod yinelemesine yol açar. Bu sorunu çözmek için paylaşılan kitaplıkları kullanabilseniz de (örneğin, bu işlevi ortak bir bileşende kapsülleyebilirsiniz ve bu işleve ihtiyaç duyan mikro hizmetler bileşene başvurur), paylaşılan kitaplık çok dilli bir ortamda çalışmayabilir.

V. Yapının rasyonalitesini ölçün

Mimari işletmeye hizmet eder.Optimum mimari yoktur, yalnızca en uygun mimari vardır.Mimari, rasyonalitesini ölçmek için her zaman verimliliği, kararlılığı ve güvenliği hedef alır.

Makul mimari tasarım:

5.1. İş perspektifi ihtiyacı

• Mevcut iş ihtiyaçlarını ve sorunlarını çözebilir
• İş ihtiyaçlarını verimli bir şekilde tamamlayın: mevcut tüm iş sorunlarını zarif ve yeniden kullanılabilir bir şekilde çözebilir
• İleriye dönük tasarım: Gelecekte belirli bir süre için işi ikinci şekilde karşılayabilir, böylece iş her geliştiğinde mimari büyük ölçüde değişmez.

5.2. İş dışı ihtiyaçlar perspektifi

. Kararlılık. dizin:

• Yüksek kullanılabilirlik : Yazılımın kullanılabilirliğini olabildiğince iyileştirmek için, her operatörün işinin normal bir şekilde yapılamayacağını görmek istemediğini düşünüyorum. Kara kutu ve beyaz kutu testi, birim testi, otomatik test, hata enjeksiyon testi, test kapsamının iyileştirilmesi vb. Adım adım uygulanmaktadır.

. Yüksek verimlilik endeksi:

• Belgelenmiş : İster tüm yaşam döngüsünün tamamı ister bir parçası olsun, iyi bir şekilde belgelendirilmelidir Değişiklik kaynakları, bunlarla sınırlı olmamak üzere BUG ve gereksinimleri içerir.
• Ölçeklenebilir : Yazılımın tasarımı, makul yerlerde soyutlamaya dikkat ederek, düşük bağlantı konseptine bağlıdır. Fonksiyon değişikliklerinin, eklemelerin ve uygulama teknolojilerinin yinelemesini kolaylaştırır ve mimarinin doğru zamanda yeniden yapılandırılmasını destekler.
• Yüksek yeniden kullanım : İşin tekrarlanmasını önlemek ve maliyetleri düşürmek için önceki kodu ve önceki tasarımı yeniden kullanmayı umuyoruz. Bu, mimari ortama en çok bağımlı olanıdır.

. Güvenlik indeksi

• Emniyet : Organizasyonun işleyişi sırasında üretilen veriler ticari değeri vardır ve verilerin güvenliğinin sağlanması da acil bir kısımdır. XX kapı gibi skandallardan kaçınmak için. Şifreleme, https vb. Yaygın yöntemlerdir

6. Yaygın mimari hatalar

Yukarı çık ve aşağı in

• Eksik kritik kısıtlamalar ve işlevsel olmayan gereksinimler
• Geleceğin boşluğunu ödemek için aşırı tasarım
• Kritik kararları çok erken verin
• Müşterilerin söyledikleri, söyledikleri
• Sıkı çalışırken öngörü eksikliği
• Mimari tasarım aynı zamanda sistem test edilebilirliğini de dikkate alır
• Mimari tasarımı tek adımda tamamlamaya çalışmayın

Yaygın hatalar

• Yanlış anlama 1 - mimari özel olarak mimar tarafından yapılır, iş geliştiricilerin dikkat etmesine gerek yoktur : Mimari ne kadar iyi olursa olsun, eninde sonunda iniş için kod gerektirecek ve organizasyon ne kadar büyükse inmesi o kadar zor olacaktır. Sadece sistem mimarisi değil, her çözüm ve her projenin de katmanlama, tasarım kalıpları gibi kendi mimarisi vardır. Her tuğla yeterince güçlü değilse, tüm sistem hala çökme riski altındadır. Sözde "bin millik dolgu bir karınca yuvasında çöktü".
• Yanlış anlama 2-Görev, mimar mimari planını belirledikten sonra biter : Mimarlık "gökyüzündeki bir kule" değildir ve sonunda inecektir, ancak mimarlar cepheye hiç gitmezlerse "zemin" in nerede olduğunu nasıl bilebilirler? Nasıl güvenli bir şekilde düşebilir?
• Yanlış anlama 3-Kusursuz bir mimari tasarım yapmayın, başlama : Dünyadaki en iyi yapı yoktur, sadece en uygun yapı yoktur, tek adımda doğru yapmaya çalışmayın. İhtiyacımız olan tek seferde bir araba yapmak değil, tek tekerlekli bisiklet bisiklet motosikletten ve nihayet bir arabaya yapmaktır. Sadece 2 yılda yapılabilecek bir ürün düşünün, pazar hala var mıydı?
• Yanlış anlama 4-Nihilist bir gelecek için ödeme yapmak için aşırı tasarım : Bir girişimin erken aşamasında, iş senaryolarını ve talep sınırlarını kavramak zordur.Ürünlerin hızlı bir şekilde yinelenmesi ve gerçekleştirilmesi gerekir ve gereksinimler sık sık güncellenir.Şu anda ihtiyaç duyulan şey hızlı uygulama. Gelecekteki genişleme hakkında çok fazla düşünmeyin, belki işlev bitmiştir, etki iyi değilse işe yaramaz. İş modeli ve uygulama senaryosu sınırları zaten nispeten netse, gelecekteki ölçeklenebilirlik tasarımına uygun şekilde dikkat edilmelidir.
• Yanlış anlama 5-büyük şirketlerin çözümlerini körü körüne takip edin Büyük şirketlerin devasa başarısının hale etkisi ve büyük şirketlerden kazanılan teknik uzmanların etkisiyle, web sitesinde mimari kararları tartışırken en ikna edici cümle "Taobao'nun yaptığı şey budur" veya " Tencent böyle yapar. " Büyük şirketlerin deneyimi ve başarılı modelleri önemli ve öğrenilmeye değer, ancak körü körüne uyumlu hale gelirlerse, kendilerine bağlı kalma cesaretlerini kaybedecekler ve er ya da geç yapısal evrim yolunda kaybolacaklar.
• Teknoloji için 6 teknolojiyi yanlış anlama : Teknoloji iş için vardır, aksi takdirde anlamsızdır. Teknoloji seçimi ve mimari tasarımda, web sitesi iş geliştirme gerçekliğinden ayrı olarak, modaya uygun yeni teknolojileri körü körüne takip etmek, teknoloji gelişimini engebeli yollara sokabilir ve mimariye giden yol gittikçe daha zor hale gelir. Uygulama maliyeti, zaman ve personel gibi tüm yönler kapsamlı bir şekilde ele alınmalı ve idealler ve gerçeklikten taviz verilmelidir.

7. Mimari bilgi sistemi

7.1. Mimari evrimi

• İlk aşama: LAMP, bir sunucuya yerleştirildi
• Uygulama sunucusu ve veri sunucusu ayrımı
• Performansı artırmak için önbellek kullanın
• Eşzamanlılığı iyileştirmek için kümeleri kullanın
• Veritabanı okuma ve yazma ayrımı
• Ters proxy ve CDN hızlandırması kullanın
• Dağıtılmış dosyaları ve dağıtılmış veritabanlarını kullanın
• İş bölümü
• Dağıtılmış hizmet

7.2. Mimari desen

Katmanlama: yatay katmanlama: uygulama katmanı, hizmet katmanı, veri katmanı

Bölme: Dikey bölme: Bölme işlevleri ve hizmetleri

dağıtılmış

• Dağıtılmış uygulamalar ve hizmetler
• Dağıtılmış statik kaynaklar
• Dağıtılmış veriler ve depolama
• Dağıtık Hesaplama

Küme: Eşzamanlılığı ve kullanılabilirliği iyileştirin

Önbelleğe alma: Sistem performansını optimize edin

• cdn
• Kaynaklara erişmek için temsilciye
• Yerel önbellek
• Dağıtılmış önbellek

Asenkron: sistemin bağlantısını azaltın

• Sistem kullanılabilirliğini sağlayın
• Yanıtı hızlandırın

Yedeklilik: Sistem kullanılabilirliğini sağlamak için soğuk bekleme ve çalışırken bekleme

Otomasyon: yayın, test, dağıtım, izleme, alarm, yük devretme, arıza kurtarma

Emniyet:

7.3. Mimarinin temel unsurları

Yüksek performans: web sitesinin ruhu

• Performans testi
• Ön uç optimizasyonu
• Uygulama optimizasyonu
• Veritabanı optimizasyonu

Kullanılabilirlik: Sunucunun kapanmamasını sağlamak için, genellikle yedekleme sunucularının yedekli dağıtımıyla gerçekleştirilir.

• Yük dengeleme
• veri yedekleme
• Otomatik bırakma
• Gri tonlamalı yayın
• İzleme alarmı

Ölçeklenebilirlik: İster bir küme oluşturun, ister trafikteki büyük ölçekli artışa hızlı bir şekilde yanıt verin, yeni makineler eklemek kolaydır

Küme

• Yük dengeleme
• Önbellek yük dengeleme

Ölçeklenebilirlik: Esas olarak işlevsel gereksinimlere odaklanın, iş genişlemesine yanıt verin ve iş değişikliklerine hızla yanıt verin. Açma ve kapama prensibinin takip edilip edilmeyeceği, sistem kuplajına bağlıdır

• Dağıtılmış mesajlaşma
• Servis

Güvenlik: Web sitesinde, çeşitli güvenlik açıklarının engellenip engellenmediğine, yapının mevcut sınırlamaya ulaşıp ulaşamayacağına ve ddos saldırılarını önleyip engellemediğine bakılmaksızın çeşitli saldırılar.

• xss saldırısı
• sql enjeksiyonu
• csr saldırısı
• web güvenlik duvarı güvenlik açığı
• Güvenlik ihlali
• ssl

8. Önerilen Mimari Kitaplar

1. "Büyük Web Sitelerinin Teknik Mimarisi: Temel İlkeler ve Örnek Olaylar"

Bu, büyük web sitelerinin teknik mimarisini sistematik olarak tanıtan eski bir kitaptır.Anlaşılması kolaydır ve bilgelikle doludur.Daha önce web sitesi geliştirme ile hiç temas kurmamış olsanız bile, ortak web sitesi teknik mimarisini ve uygulamalarını ilk birkaç bölümü okuyarak hızlı bir şekilde edinebilirsiniz. Sahneler. Bu harika.

2. "Milyar düzeyinde trafik web sitesi mimarisinin temel teknolojisi"

"Büyük ölçekli web sitesi teknolojisi mimarisi" ile karşılaştırıldığında, Kaitao'nun "Yüz Milyon Trafik Web Sitesi Mimarisinin Temel Teknolojisi" ayrıntıları uygular. Web sitesi mimarisinde yaygın olarak kullanılan önbelleğe alma, kuyruklar, iş parçacığı havuzları, aracılar gibi çeşitli teknolojiler ... , Hepsi hakkında konuşuldu ve temel kod ile. Nginx yapılandırması bile var!

Yüksek trafikli web sitelerini uygularken referans teknolojiler ve kodlar bulmak istiyorsanız, bu kitap en uygun olanıdır.

3. "Mimarlık Gelecektir"

Bu, belirli teknik düzeyin ötesine geçen, mimari sorunların temel nedenlerini analiz etmeye odaklanan ve ekipleri nasıl yöneteceğimizi, yöneteceğimizi, organize edeceğimizi ve görevlendireceğimizi anlamamıza yardımcı olan "kutsal bir kitaptır".

4. "Dağıtılmış Hizmet Mimarisi: İlke, Tasarım ve Gerçek Savaş"

Bu kitap, dağıtılmış hizmet mimarisinin ilkelerini ve tasarımını kapsamlı bir şekilde tanıtır ve yazarın mikro hizmet mimarisini uygulama sürecindeki pratik deneyimiyle birleştirir, çevrimiçi hizmetlerin sağlığını ve güvenilirliğini sağlamak için en iyi çözümü özetler. Mimari düzeyinde, pratiktir. Ağır iş türü.

5. "Konuşma Mimarisi"

Bu, mimarlık üzerine ilahi bir kitap olarak değerlendirilebilir ... Mimarinin başlangıcından, işin ayrılığından, mimarinin amacından, mimarın rolünden ve mimarın mimariyi nasıl uyguladığından bahseder ... Şiddetle tavsiye edilir.

Bununla birlikte, mimaride pratik deneyimi olmayanlar için, bu kitap bu kitabın birçok kavram ve birkaç gerçek savaşla nispeten hayal ürünü olduğunu düşünebilir. Ancak bir veya iki proje mimarisi deneyiminiz varsa, kitapta tartışılan mimarlık felsefesine derinden katılacaksınız.

6. "Yazılım Mimarları için 12 Uygulama"

Çoğu zaman sözde "teknik cam tavan" aslında yumuşak becerilerin eksikliğidir. Bu beceriler öğrenilebilir ve bilgi eksikliği, değişmeye karar verme çabalarıyla giderilebilir.

Yazar: hız düzenlemesi

Orijinal: https://blog.csdn.net/hguisu/article/details/78258430

Bugünün manşet röportaj sorusu: 500 milyon büyük dosya nasıl sıralanır?

Alibaba'nın son röportaj paylaşımı: Java sanal makinesi + veritabanı + Spring + multithreading + mikro hizmetler

Redis böyle mi kullanılır? Bakalım kimin potu

Bu ne tür bir peri belgesi: Spring Boot'un tüm gerçek işlemlerinin panoramik bir görünümü

Kod okunabilirliği veya basitliği için hangisi önemlidir? Aksi takdirde değiştirme yöntemine bakın

En son programcı maaşı Mart ayında açıklanıyor, hangi aşamadasınız?

Bir programcı hayalini gerçekleştirir ve yarım yıldan fazla bir süredir röportajlara hazırlık deneyimini paylaşır

Birinci sınıf öğrencileri Google için Ali ve Toutiao'dan vazgeçti ve sonunda yıllık maaşı bir milyon olan bir teklif kazandı.

Yu'e Bao'nun eve olan ilgisinin yanı sıra Yu'e Bao ile bir video röportaj bile aldım.

Programcılar, iş aramak için akademik niteliklerini tahrif ediyorlar ve sonunda bir teklif alıyorlar. İK bunu öğrendikten sonra, çevrimiçi yardım isteme şansı vermek ister misiniz?

Hala TCP zaman aşımını ve yeniden iletimini anlamıyor musunuz? Bu uzun makaleyi okumaktan çok yararlanacaksınız

Uluslararası öğrenciler, 500.000 sağlık kiti ve 11 milyon maske yolda