xhide
大型網站遇到的挑戰，主要是大量的用戶，高併發的訪問，就算一個簡單的增刪查改的功能，如果面對的是百萬、千萬甚至億級的用戶，都是一件難度很大的事情。
數據從數據庫到瀏覽器的過程：數據庫->應用數據集->內存對象->動態頁面->HTTP服務器->用戶瀏覽器。那麼我們可以把高併發的設計分成幾個層次：
前端
前端是指，用戶的請求還沒有到服務前的環節。
瀏覽器緩存
動靜分離：靜態內容部署在單獨的服務器上；
圖片服務器分離：圖片存儲在單獨的圖片服務器上；
CDN：更智能的鏡像+緩存+流量導流。
應用層/服務層
負載均衡：後臺應用部署多套，前面掛負載均衡，客戶端都直接訪問負載均衡，由它把訪問分攤到實際應用服務器上；
Session管理：需要有專門的機制去管理Session，使集群內甚至跨集群的應用服務器可以共享；
HTML靜態化：把連接後臺數據庫查詢數據的工作提前做好，生成靜態化的頁面，那麼訪問的效率一定會提高很多；
業務拆分：把一個打的業務系統，拆成多個小的業務系統；
虛擬化：將一臺物理機虛擬化成多臺虛擬機，這樣可以更高的支撐集群部署。
消息中間件：使用消息中間件，比如各種MQ，業務系統之間使用異步消息發送以達到解耦的效果。
各種緩存：一些語言框架本身就帶緩存機制，也可以使用Memcached或Redis。
存儲層
數據庫讀寫分離
分庫分表：一臺數據庫很難滿足業務上的壓力，那麼數據庫可以做分庫分表。
分佈式文件系統
非關係型數據庫
其他必備的
日誌採集系統
服務接口監控系統
用戶行為採集系統
服務器性能監控系統
系統架構大了，部署的服務器多了，很多事情不可能通過人工完成了，比如一個接口調用發生了錯誤，不可能人工登錄到服務器上去查日誌吧，所以這些東西也是必不可少的。
都是說個大概，後面有機會的話，會把每一項都展開詳細說明。
希望我的回答能夠幫助到你！
會點代碼的大叔
我們在做大型網站基礎架構的時候一般來說軟件架構需要關注性能、可用性、伸縮性、擴展性和安全性這5個架構要素。
我們通過這些架構要素來衡量我們整體系統架構設計的優劣，來判斷是否達到了我們的要求。
高性能
性能是大型網站架構設計的一個重要方面，任何軟件架構設計方案都必須考慮可能帶來的性能問題，也正因為性能問題幾乎無處不在，在請求鏈路的任何一個環節，都是我們去做極致性能優化方案中的切入點。
可用性
衡量一個系統架構設計是否滿足高可用的目標，就是假設系統中任何一臺或者多臺服務器宕機時，以及出現各種不可預期的問題時，系統整體是否依然可用。
伸縮性
網站的伸縮性是指不需要改變服務器的硬件設計，僅僅靠改變應用服務器的部署數量，就可以擴大或縮小服務器的處理能力。
擴展性
不同於其他架構要素主要關注非功能性需求，網站的擴展性架構直接關注網站的功能需求。
網站快速發展，功能不斷擴展，如何設計網站的架構使其能夠快速響應需求變化，是網站可擴展架構的主要目標。
安全性
互聯網跟傳統軟件不同，它是開放的，任何人在任何地方都可以訪問網站。網站的安全架構就是保護網站不受惡意訪問和攻擊，保護網站的重要數據不被竊取。
安全性架構，具體來說說就是保證數據的保密性、完整性、真實性、佔有性。
總結
要完全掌握大型網站的架構設計方案，或許你可以點擊我頭像，進入我的專欄"深入大型網站核心架構實戰"。
這期專欄是筆者總結了當下這些互聯網行業中相對成熟且經過大型網站檢驗的技術和方案，內容涵蓋構建大型互聯網系統服務所需的關鍵技術。
人人都是架構師
技術這玩意兒，你不深入使用它，你就不知道它有多牛，更不知道會有多難！
併發:指定時間段內的請求數！
高併發:指定時間段內的超多請求數！
比如tomcat，單機最大支持併發數為8000左右，redis理論值可達到幾萬！
那麼怎麼設計一套可支持高併發的系統呢？使用技術如下:
1，分佈式系統，微服務:使用springcloud家族包括eureka，zuul，feign，hysrix等或者dubbo搭建一套微服務框架！
2，前後端分離:使用node.js搭建前端服務系統！
3，靜態化處理:將頁面，後臺枚舉，數據庫定義表等使用靜態處理方式做處理！
4，文件服務器剝離:採用單獨的文件服務器，防止頁面加載的阻塞！
5，緩存:使用redis，memcache等將運行時數據緩存，代替頻繁的操作數據庫！
6，數據庫:讀寫分離或者分庫分表，採用druid等有性能監控系統的數據庫連接框架！
7，消息中間件:使用xxxmq，kafka等消息中間件，解耦服務，而且異步處理效率更高！
8，反向代理:使用nginx等負載均衡服務！
9，代碼層:避免大量創建對象，避免阻塞IO，避免多層for循環，避免線程死鎖，避免大量同步！
10，各種優化:包括jvm優化，表結構優化，sql優化，關鍵字段加索引（注意避免索引失效），連接池優化等等！
11，搜索引擎:sql有大量的like語句，有必要切換成solr等搜索引擎！
12，cdn:使用CDN技術將請求分發到最合適的主機上，避免網絡傳輸的延遲！
13，使用batch:增刪改能一次做的別分為兩次，但要注意batch合理設計，防止數據丟失！
14，限流，削峰！
更多解決方案和每個方案細節實施涉及到的具體問題，以後會逐一分享！敬請關注！
