項目架構&架構部署&網站分析&網站優化

1、架構演變

一個項目至少由三層內容組成：web訪問層、數據庫層、存儲層

 

初級階段

單體階段　　　　　　　　　　　　　　　　　　　　

常見場景：項目初期

部署特色：全部應用服務都在一臺主機

應用特色：開發簡單

 

 

 

 

 

應用/數據分離階段　　　　　　　　　　　　　　　　

常見場景：項目初期，用戶訪問數據庫有壓力

部署特色：應用和數據庫單獨部署

應用特色：開發簡單

 

 

  

頁面動靜分離階段

常見場景：項目初期，用戶訪問頁面有壓力

部署特色：剝離用戶讀請求和寫請求操做

應用特色：開發簡單

 

   

頁面/數據緩存階段

常見場景：項目初期，用戶訪問有壓力

部署特色：代理和數據庫前面增長緩存組件

應用特色：開發簡單

 

 

中期階段

應用服務集羣階段

常見場景：項目初期，用戶訪問有壓力

部署特色：應用服務所在主機作集羣負載均衡

應用特色：業務中等

 

 

數據庫讀寫分離化

常見場景：項目初期，用戶訪問數據有壓力

部署特色：對數據庫集羣作讀寫分離，靜態文件作共享存儲

應用特色：業務中等

 

 

 

存儲分佈式

常見場景：項目中期，數據存儲有壓力

部署特色：對數據庫分庫/分表擴展，數據文件使用分佈式存儲

應用特色：業務中等

 

 

 

 

業務應用拆分

常見場景：項目中期，業務訪問/團隊管理有壓力

部署特色：項目應用進行拆分

應用特色：業務複雜

 

 

 

 

中後期階段

業務拆分

常見場景：項目中後期，業務處理有壓力

部署特色：全部功能以服務形式單獨部署，引入配置管理管理中心、消息中間件，搜索引擎等功能

應用特色：業務複雜

 

微服務階段

常見場景：項目後期，精益求精

部署特色：全部服務均可以自由部署

應用特色：業務複雜

 

 　　　　

 

 

 

2、架構部署

通用架構

 

一級定位：核心組成部分

　　web 、數據庫、存儲層

二級定位：功能加強部分

　　web緩存、代理、數據庫緩存

 

部署項目

部署項目時，遵循主次原則：

• 架構層中的一級角色，部署原則是：站在用戶訪問資源角度，從後向前依次部署。
• 架構層中的二級角色，部署原則是：站在用戶訪問資源壓力角度，須要部署哪裏，就部署哪裏，注意先後的信息交流。

 

 

3、網站分析

IP: 獨立IP數，指一天內使用不一樣IP地址的用戶訪問網站的數量。

　　特色：同一個IP不管訪問多少網頁，獨立IP數均爲1

PV：Page view頁面瀏覽量，指一天內網站的瀏覽次數，它是衡量網站用戶訪問頁面的數量。

　　特色：用戶每打開一個頁面就記錄一次，就算訪問同一頁面屢次，就記錄屢次

UV：Unique Visitor 訪問網站的用戶，指一天內訪問某站點的人數，以cookie/客戶端爲依據

　　特色：一天內，同一訪問用戶的屢次訪問只記錄1次

VV：Visit View 用戶訪問網站次數，指一天內某個用戶訪問了多少次網站

　　特色：打開網頁A，瀏覽完畢後關閉該頁面，表示一次訪問

BR：Bounce Rate 跳出率，指一天內訪問用戶中，用戶打開網站後沒有作任何事情，一會就離開了的比例

　　特色：若是跳出率很高，說明咱們的網頁沒有什麼吸引力，網頁設計效果不怎麼好

CR：Conversion Rate 轉化率，指一天內訪問用戶中，打開網站後，繼續瀏覽該網站其餘頁面的比例

　　特色：轉化率通常體如今項目的關鍵流程的部分，而它對網站的某些關鍵流程優化是一個很重要的直播

 

常見分析工具：服務器服務日誌、公司內部監控平臺、互聯網網站分析工具包括站長工具、百度統計、雲平臺監控等

 

 

 

4、網站優化

緩存層方面

問題描述：

怎麼在現有的主機資源狀況下，花最小的代價抗住大量的用戶訪問量？

解決思路：

最多見的是自建Web緩存，或者購買CDN，將用戶常常訪問的、更新頻率低的資源存放起來，這樣用戶再次請求相同資源的時候，就不會對後端的服務形成影響。若要防止互聯網上的惡意訪問/爬蟲，應該作好相應的安全措施。緩存之類的措施必定要適合公司的當前業務，若是是項目的靜態資源不少，只要購買的CDN足夠好，就能抗住足夠的用戶訪問量。

 

代理層方面

問題描述：

如何提升用戶高質量的請求分發。

解決思路：

以Nginx代理爲例，提升用戶高質量的請求分發，最好的方法就是基於請求的關鍵字進行合理的分流。

基於請求的IP地址信息，封閉惡意IP訪問，提升正常IP用戶訪問效率

基於請求的瀏覽器信息，分發到相應的後端應用，

基於請求的協議方法，作好讀寫分離業務的精確分流，

基於請求的路徑信息，作好指定業務的精確分流，

 

問題描述：

對於前端使用nginx進行代理的項目，會隨着功能的層層迭代逐漸增長數十個upstream，location規則的數量有可能達到數百個，這個時候偶爾有些 URL 會出現 404 的問題，對於這種狀況怎麼辦？

解決思路：

1 按照功能描述，將upstream拆分到不一樣的功能目錄中

2 對location的匹配規則儘可能描述清楚，特別是匹配的location_match，最好使用^/$來錨定首尾字母

 

項目後端web訪問

問題描述：

關於動態web請求過多，壓力有些大，常見的解決方法有哪些？

解決思路：

首先分析動態的web請求主要的瓶頸點在哪裏，是請求量大，仍是數據訪問大

請求量大：Web緩存/CDN，或者動態web集羣能夠考慮一下

數據庫操做多：分析請求內容是否頻繁/集中，是，頁面靜態化考慮一下；否，參看數據庫的演變思路

 

如何提升靜態web資源的訪問質量？結合前段緩存的功能，在代碼或者代理部分設置合理的資源緩存過時時間，定時/實時推送相關信息到前段的緩存層。

 

數據層方面

問題描述：

用戶訪問數據有壓力

解決思路：

對於熱點數據讀取頻繁的話，能夠考慮前端數據緩存、分部數據緩存、優化查詢搜索等方法

對於數據頻繁寫入壓力的話，能夠考慮數據庫集羣、讀寫分離、分庫分表、增長數據管理層等方法

開發角度：關注數據庫表的設計，表的索引合理、查詢的時候，儘可能使用條件查詢

 

存儲層方面：

問題描述：

如何保證咱們數據存儲的質量

解決思路：

存儲設備的購買質量、分佈式存儲、備份策略