WEB架構中五個重要的核心指標，分別是性能、可用性、伸縮性、擴展性和安全性這5個架構指標；css
1、性能
性能就是核心要素之一，否則我爲何架構設計？隨隨便便一個lowlow的系統上線就行了。因此性能優化是不少小公司賣不去過的坎。這麼說吧，固然優化網站性能的手段也很是多：前端
（1）web前端性能優化：
瀏覽器訪問優化（瀏覽器緩存、頁面壓縮傳輸、合理佈局頁面、減小Cookie傳輸）mysql
減小http請求。避免創建太多通信鏈路。將js、css、圖片文件儘量合併。避免太多請求。同時，對於系統的後端請求也儘量進行合理的設計，來避免出現太多交互。nginx
使用瀏覽器的緩存。http頭設置Cache-Control和Expires.js文件名好比能夠帶時間戳。一旦有更新則更新時間戳，不然緩存；同時儘可能避免同一時間更新大量靜態資源。web
對靜態資源進行壓縮。sql
css放置在頁面最上方，js放下最下面。以提早進行css渲染。同時避免js帶來的頁面阻塞。但須要case by case。好比頁面dom節點須要依賴js生成，則可視狀況改變文件位置。數據庫
減小cookie傳輸。同時讓靜態資源有獨立域名，發送靜態資源請求時候不發送cookie。以此減小傳輸代價。cookie能夠經過document.cookie獲取。後端
2.CDN加速瀏覽器
緩存圖片、文件、CSS以及script腳本。可是pc上的CDN加速效果要好於移動端。通過調研發現，last-mile的延遲越高，CDN的相對有效性越差（具體見文章爲何CDN對移動客戶端加速「沒有」效果）。緩存
3.反向代理
能夠提供七層負載均衡（http請求進行均衡策略），而且能夠提供靜態資源的緩存，請求轉發，防止網絡攻擊等。比較流行的有nginx。
（2）應用服務器性能優化：
若是請求靜態界面不卡了,可是動態數據仍是卡,說明MySQL處理的請求太多了,可使用服務器本地緩存和分佈式緩存，也能夠經過異步操做方式來加快響應，在高併發請求的狀況下，能夠將多臺應用服務器組成一個集羣共同對外服務，提升總體處理能力，改善性能，具體以下：
1.分佈式緩存（網站性能優化的第必定律：優先考慮使用緩存優化性能）
通常來講，存入cache的數據的讀寫比在2:1以上；且應該是熱點數據。
須要考慮若是採用緩存則可能帶來的數據短時間內的不一致，或者若是實時更新緩存可能帶來的性能和資源開銷。
須要考慮cache一旦失效，大量請求直接命中DB可能帶來的服務性能雪崩。因此能夠對cache採用集羣化部署，以此避免丟失過多數據形成服務壓力陡增。
對於熱點數據考慮進行緩存的預熱加載。好比高峯期來臨前，先將熱點數據提早存入緩存。以此提升高峯期的服務性能。
爲了不惡意攻擊，一直query不存在的數據，致使cache沒法命中而頻繁訪問DB，能夠將不存在的數據也進行緩存並按期清理。同時有機制對惡意請求進行識別和封禁。
分佈式緩存應該去中心化並集中管理。經過不一樣實例間的互不通訊和同構來保證可擴展性，並下降系統複雜度。
2.異步化（任何能夠晚點作的事情都應該晚點再作，感受像懶加載）
經過分佈式消息隊列來實現削峯的目的。經過業務配合技術來解決問題。好比12306的排隊。
3.集羣
採用集羣也是服務虛擬化的一個體現。用以免單點問題，同時提供更加高可用，高性能的服務。
4.代碼優化
多線程中，若是是密集型計算，線程數不宜超過CPU核數。若是是IO處理，則線程數=[任務執行時間/(任務執行時間-IO等待時間)] * CPU核數。除此以外，咱們應該將對象設計成無狀態對象，多采用局部對象，適當將鎖細化。
進行資源複用。好比採用單例模式，好比採用鏈接池。
合理設置JVM參數，以最大程度避免不合理的full gc。
5.存儲性能優化
關係型數據庫的索引採用B+樹進行實現。而不少的nosql數據庫則採用了LSM樹進行存儲。LSM在內存中保留最新增刪改查的數據，直到內存沒法放下，則與磁盤的下一級LSM樹進行merge。因此對於寫操做較多，而讀操做更多的是查詢最近寫入數據的場景，其性能遠高於b+樹；採用HDFS結合map reduce進行海量數據存儲和分析。其能自動進行併發訪問和冗餘備份，具備很高的可靠性。其等因而實現了RAID的功能。
（3）數據庫層優化：
數據庫層實際上是最脆弱的一層，通常在應用設計時在上游就須要把請求攔截掉，數據庫層只承擔「能力範圍內」的訪問請求，因此，咱們經過在服務層引入隊列和緩存，讓最底層的數據庫高枕無憂。可是若是請求激增,仍是有大量的查詢壓力到MySQL,這個時候就要想辦法解決MySQL的瓶頸了，這時候可用使用索引、緩存、SQL性能優化等手段，還可使用NoSQL數據庫來優化數據模型、存儲結構等。詳細內容可關注後查看個人【mysql優化專題】，共12篇，已完結。
（4）衡量網站性能的指標（重要的有響應時間、TPS、系統性能計數器等，經過這些指標以肯定系統設計是否達到目標）
響應時間。
併發數。若是暫時沒有對應的準確監控，針對不一樣業務模型，能夠有不同的併發數的預估。咱們的系統進行峯值併發數預估的話，有一種比較粗略的計算方式，即全天請求平均每秒併發數 * 3。但也須要case by case。
吞吐量。比較常見的有QPS（每秒查詢數）、HPS（每秒http請求數）以及TPS（每秒處理事務數）。
性能計數器。包括系統負載、線程數、cpu、內存使用狀況等。能夠用top、free、cat /proc/cpuinfo等命令來查看。系統負載的定義爲當前被CPU執行的線程數/等待被CPU執行的總線程數。當其值與邏輯cpu個數相同時是最佳狀態，其表明全部的資源都被最大限度地被利用。但也有人認爲當負載爲0.7倍邏輯CPU數時最佳。
（5）高可用：包括高可用的應用、高可用的服務、高可用的數據和服務於高可用的監控等;
2、安全性
互聯網是開放的，任何人在任何地方均可以訪問網站。網站的安全架構就是保護網站不受惡意訪問和攻擊，保護網站的重要數據不被竊取。
安全的5個要素：機密性、完整性、可用性、可控性和可審查性。
1.安全系統架構
安全服務是指計算機網絡提供的安全防禦措施，包括認證服務、訪問控制、數據機密性服務、數據完整性服務和不能否認服務。
特定的安全機制是用來實施安全服務的機制，包括加密機制、數據簽名機制、訪問控制機制、數據完整性機制、認證交換機制、流量填充機制、路由控制機制和公證機制。
廣泛性的安全機制不是爲任何特定的服務而特設的，屬於安全管理方面，分爲可信功能度、安全標記、事件檢測、安全審計跟蹤和安全恢復。
2.安全保護等級
用戶自主保護級
系統審計保護級
安全標記保護級
結構化保護級
訪問驗證保護級
衡量網站安全架構的標準就是針對現存和潛在的各類攻擊和竊密手段，是否有可靠的應對策略。
3、可用性
衡量一個系統架構設計是否知足高可用的目標，就是假設系統中任何一臺或者多臺服務器宕機時，以及出現各類不可預期的問題時，系統總體是否依然可用。
通常就三個手段、冗餘、集羣化、分佈式。
網站高可用的主要手段就是冗餘，應用部署在多臺服務器上同時提供服務，數據存儲在多臺服務器上相互備份，任何一臺服務器都不會影響應用的總體能夠，一般的實現手段即把多臺服務器經過負載均衡設備組成一個集羣。
4、可擴性
擴展性（Extensibility）指對現有系統影響最小的狀況下，系統功能可持續擴展或提高的能力。表如今系統基礎設施穩定不須要常常變動，應用之間較少依賴和耦合，當系統增長新功能時，不須要對現有系統的結構和代碼進行修改。這個沒啥好說。擴展性依賴於前期良好的架構設計。合理業務邏輯抽象，水平/垂直切割分佈式化等等，推薦K8S、微服務架構設計。
網站可擴展架構的主要手段是事件驅動架構和分佈式服務。
事件驅動一般利用消息隊列實現，經過這種方式將消息生產和處理邏輯分隔開。
服務器服務則是將業務和可複用服務分離開來，經過分佈式服務框架調用。新增長產品可用經過調用可複用的服務來實現自身的業務邏輯，而對現有產品沒有任何影響。
對此，《可擴展的藝術》一書提出了一個更加系統的可擴展模型—— AKF可擴展立方 （Scalability Cube）。這個立方體中沿着三個座標軸設置分別爲：X、Y、Z。
X軸擴展 —— 關注水平的數據和服務克隆，也就是前文提到的「加機器解決問題」
Y軸擴展 —— 關注應用中職責的劃分，好比數據類型，交易執行類型的劃分
Z軸擴展 —— 關注服務和數據的優先級劃分，如分地域劃分
整個擴展模型，用下圖來表示，其中原點表明徹底無擴展的狀態。
5、伸縮性
服務儘可能同構。DB、cache在考慮分佈式時儘可能提早設計好擴展方案。也能夠採用一些主流的對水平伸縮支持較好的Nosql、memcached、hbase等。
（1）橫向分離：將不一樣的業務模塊分離部署，實現系統的伸縮性；
（2）縱向分離：將業務處理流程上得不一樣部分分離部署，實現系統的伸縮性；
最後附<WEB架構設計5個核心要素>思惟導圖一張：在公衆號後臺回覆「web」獲取；
原文連接：
https://blog.csdn.net/guolong1983811/article/details/78636443
K8S培訓推薦
Kubernetes線下實戰培訓，採用3+1新的培訓模式（3天線下實戰培訓，1年內可免費再次參加），資深一線講師，實操環境實踐，現場答疑互動，培訓內容覆蓋：Docker方面：Docker架構、鏡像、數據存儲、網絡、以及最佳實踐。Kubernetes實戰內容，Kubernetes設計、Pod、經常使用對象操做，Kuberentes調度系統、QoS、Helm、網絡、存儲、CI/CD、日誌監控等。<瞭解更多詳情>
本文分享自微信公衆號 - K8S中文社區（k8schina）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。