一、性能

性能就是核心要素之一，不然我為什麼架構設計？隨隨便便一個lowlow的系統上線就好了。所以性能優化是很多小公司賣不去過的坎。這麼說吧，當然優化網站性能的手段也非常多：

（1）web前端性能優化：

1. 瀏覽器訪問優化（瀏覽器緩存、頁面壓縮傳輸、合理佈局頁面、減少Cookie傳輸）

• 減少http請求。避免建立太多通訊鏈路。將js、css、圖片文件儘可能合併。避免太多請求。同時，對於系統的後端請求也儘可能進行合理的設計，來避免出現太多交互。
• 使用瀏覽器的緩存。http頭設置Cache-Control和Expires.js文件名比如可以帶時間戳。一旦有更新則更新時間戳，否則緩存；同時儘量避免同一時間更新大量靜態資源。
• 對靜態資源進行壓縮。
• 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.分佈式緩存（網站性能優化的第一定律：優先考慮使用緩存優化性能）

1. 一般來說，存入cache的數據的讀寫比在2:1以上；且應該是熱點數據。
2. 需要考慮如果採用緩存則可能帶來的數據短期內的不一致，或者如果實時更新緩存可能帶來的性能和資源開銷。
3. 需要考慮cache一旦失效，大量請求直接命中DB可能帶來的服務性能雪崩。所以可以對cache採用集群化部署，以此避免丟失過多數據造成服務壓力陡增。
4. 對於熱點數據考慮進行緩存的預熱加載。比如高峰期來臨前，先將熱點數據提前存入緩存。以此提高高峰期的服務性能。
5. 為了避免惡意攻擊，一直query不存在的數據，導致cache無法命中而頻繁訪問DB，可以將不存在的數據也進行緩存並定期清理。同時有機制對惡意請求進行識別和封禁。
6. 分佈式緩存應該去中心化並集中管理。通過不同實例間的互不通信和同構來保證可擴展性，並降低系統複雜度。

2.異步化（任何可以晚點做的事情都應該晚點再做，感覺像懶加載）

通過分佈式消息隊列來實現削峰的目的。通過業務配合技術來解決問題。比如12306的排隊。

3.集群

採用集群也是服務虛擬化的一個體現。用以避免單點問題，同時提供更加高可用，高性能的服務。

4.代碼優化

1. 多線程中，如果是密集型計算，線程數不宜超過CPU核數。如果是IO處理，則線程數=[任務執行時間/(任務執行時間-IO等待時間)] * CPU核數。除此之外，我們應該將對象設計成無狀態對象，多采用局部對象，適當將鎖細化。
2. 進行資源複用。比如採用單例模式，比如採用連接池。
3. 合理設置JVM參數，以最大程度避免不合理的full gc。

5.存儲性能優化

關係型數據庫的索引採用B+樹進行實現。而很多的nosql數據庫則採用了LSM樹進行存儲。LSM在內存中保留最新增刪改查的數據，直到內存無法放下，則與磁盤的下一級LSM樹進行merge。所以對於寫操作較多，而讀操作更多的是查詢最近寫入數據的場景，其性能遠高於b+樹；採用HDFS結合map reduce進行海量數據存儲和分析。其能自動進行併發訪問和冗餘備份，具有很高的可靠性。其等於是實現了RAID的功能。

（3）數據庫層優化：

1. 數據庫層其實是最脆弱的一層，一般在應用設計時在上游就需要把請求攔截掉，數據庫層只承擔“能力範圍內”的訪問請求，所以，我們通過在服務層引入隊列和緩存，讓最底層的數據庫高枕無憂。但是如果請求激增,還是有大量的查詢壓力到MySQL,這個時候就要想辦法解決MySQL的瓶頸了，這時候可用使用索引、緩存、SQL性能優化等手段，還可以使用NoSQL數據庫來優化數據模型、存儲結構等。詳細內容可關注後查看我的【mysql優化專題】，共12篇，已完結。

（4）衡量網站性能的指標（重要的有響應時間、TPS、系統性能計數器等，通過這些指標以確定系統設計是否達到目標）

1. 響應時間。
2. 併發數。如果暫時沒有對應的準確監控，針對不同業務模型，可以有不一樣的併發數的預估。我們的系統進行峰值併發數預估的話，有一種比較粗略的計算方式，即全天請求平均每秒併發數 * 3。但也需要case by case。
3. 吞吐量。比較常見的有QPS（每秒查詢數）、HPS（每秒http請求數）以及TPS（每秒處理事務數）。
4. 性能計數器。包括系統負載、線程數、cpu、內存使用情況等。可以用top、free、cat /proc/cpuinfo等命令來查看。系統負載的定義為當前被CPU執行的線程數/等待被CPU執行的總線程數。當其值與邏輯cpu個數相同時是最佳狀態，其代表所有的資源都被最大限度地被利用。但也有人認為當負載為0.7倍邏輯CPU數時最佳。

（5）高可用：包括高可用的應用、高可用的服務、高可用的數據和服務於高可用的監控等，關於高可用，我還是決定開個單章講解

二、安全性

互聯網是開放的，任何人在任何地方都可以訪問網站。網站的安全架構就是保護網站不受惡意訪問和攻擊，保護網站的重要數據不被竊取。

安全的5個要素：機密性、完整性、可用性、可控性和可審查性。

1、安全系統架構

1）安全服務是指計算機網絡提供的安全防護措施，包括認證服務、訪問控制、數據機密性服務、數據完整性服務和不可否認服務。

2）特定的安全機制是用來實施安全服務的機制，包括加密機制、數據簽名機制、訪問控制機制、數據完整性機制、認證交換機制、流量填充機制、路由控制機制和公證機制。

3）普遍性的安全機制不是為任何特定的服務而特設的，屬於安全管理方面，分為可信功能度、安全標記、事件檢測、安全審計跟蹤和安全恢復。

2、安全保護等級

1）用戶自主保護級

2）系統審計保護級

3）安全標記保護級

4）結構化保護級

5）訪問驗證保護級

衡量網站安全架構的標準就是針對現存和潛在的各種攻擊和竊密手段，

是否有可靠的應對策略。

三、可用性

衡量一個系統架構設計是否滿足高可用的目標，就是假設系統中任何一臺或者多臺服務器宕機時，以及出現各種不可預期的問題時，系統整體是否依然可用。

一般就三個手段、冗餘、集群化、分佈式。

網站高可用的主要手段就是冗餘，應用部署在多臺服務器上同時提供服務，數據存儲在多臺服務器上相互備份，任何一臺服務器都不會影響應用的整體可以，通常的實現手段即把多臺服務器通過負載均衡設備組成一個集群。

四、擴展性

擴展性（Extensibility）指對現有系統影響最小的情況下，系統功能可持續擴展或提升的能力。表現在系統基礎設施穩定不需要經常變更，應用之間較少依賴和耦合，當系統增加新功能時，不需要對現有系統的結構和代碼進行修改。這個沒啥好說。擴展性依賴於前期良好的架構設計。合理業務邏輯抽象，水平/垂直切割分佈式化等等。

網站可擴展架構的主要手段是事件驅動架構和分佈式服務。

事件驅動通常利用消息隊列實現，通過這種方式將消息生產和處理邏輯分隔開。

服務器服務則是將業務和可複用服務分離開來，通過分佈式服務框架調用。新增加產品可用通過調用可複用的服務來實現自身的業務邏輯，而對現有產品沒有任何影響。

對此，《可擴展的藝術》一書提出了一個更加系統的可擴展模型—— AKF可擴展立方 （Scalability Cube）。這個立方體中沿著三個座標軸設置分別為：X、Y、Z。

• X軸擴展 —— 關注水平的數據和服務克隆，也就是前文提到的“加機器解決問題”
• Y軸擴展 —— 關注應用中職責的劃分，比如數據類型，交易執行類型的劃分
• Z軸擴展 —— 關注服務和數據的優先級劃分，如分地域劃分

整個擴展模型，用下圖來表示，其中原點代表完全無擴展的狀態。

五、伸縮性

服務儘量同構。DB、cache在考慮分佈式時儘量提前設計好擴展方案。也可以採用一些主流的對水平伸縮支持較好的nosql、memcached、hbase等。

（1）橫向分離：將不同的業務模塊分離部署，實現系統的伸縮性；

（2）縱向分離：將業務處理流程上得不同部分分離部署，實現系統的伸縮性；

寫在最後：檸檬為大家準備了一些適合於1－5年以上開發經驗的java程序員面試涉及到的絕大部分面試題及答案做成了文檔和學習筆記文件以及架構視頻資料免費分享給大家（包括Dubbo、Redis、Netty、zookeeper、Spring cloud、分佈式、高併發等架構技術資料），希望可以幫助到大家。

獲取方式：請大家關注並私信小編關鍵詞：“資料”即可獲取你需要的各類資料。