摘要：使用反向代理和加速網站響應在性能權威指南中有講到，網站性能的瓶頸，大部分時間都浪費在的握手和傳輸上。因此可以通過和反向代理的方式來加快響應。分布式數(shù)據(jù)庫是數(shù)據(jù)庫拆分的最后手段，只用在單表數(shù)據(jù)規(guī)模特別龐大的時候才使用。

前幾天跟一個朋友聊了一些關于網站緩存分布式的一些東西，發(fā)現(xiàn)自己的知識還是太過貧瘠。理論+協(xié)議，這是現(xiàn)在我亟待加強的。這個周末買了兩本關于分布式網站的書，本著好記性不如爛筆頭，便有了這樣一系列的文章。希望一同分享，也請多指教。

code less, play more!

這個世界上沒有哪個網站從誕生起就是大型網站；也沒有哪個網站第一次發(fā)布的時候就擁有龐大的用戶，高并發(fā)的訪問，海量的數(shù)據(jù)；大型網站都是從小型網站發(fā)展而來。網站的價值在于它能給用戶提供什么家宅，在于網站能做什么，而不在于它是怎么做的，所以網站在小的時候就去追求網站的架構是舍本逐末，得不償失的。小型網站最需要做的就是為用戶提供更好的服務來創(chuàng)造價值，得到用戶認可，活下去，野蠻生長。

高并發(fā)，大流量

高可用

海量數(shù)據(jù)

用戶分布廣泛，網絡情況復雜

安全環(huán)境惡劣

需求快速變更，發(fā)布平頻繁

漸進式發(fā)展

初始階段的網站架構

最開始沒有多少人訪問，所以應用程序，數(shù)據(jù)庫，文件都在同一臺機器上。

應用服務器和數(shù)據(jù)服務分離

應用和數(shù)據(jù)分離之后，一般需要三臺服務器。應用服務器，文件服務器和數(shù)據(jù)庫服務器，這三種服務器對于硬件要求各不相同。

應用服務器：更強大的CPU

數(shù)據(jù)庫服務器：更快速的磁盤和更大的內存

文件服務器：容量更大的硬盤

使用緩存改善性能

網站的訪問也遵循二八定律：80%的業(yè)務集中在20%的數(shù)據(jù)上。因此可以把這一小部分數(shù)據(jù)緩存在內存中，減少數(shù)據(jù)庫的訪問壓力。

網站的緩存可以分為兩種：

本地緩存：緩存在應用服務器上。本地緩存訪問速度快，但是受制于內存限制，緩存數(shù)量有限，而且也會出現(xiàn)和應用程序爭搶內存的情況。

遠程分布式緩存：以集群的方式，緩存在大內存的專用緩存服務器?？梢栽诶碚撋献龅讲皇軆却嫒萘肯拗?。

使用應用服務器集群提高并發(fā)能力

當一臺服務器的處理能力和存儲空間不足的時候，不要企圖更換更強大的服務器。對于大型網站來說，不管多么強大的服務器，都滿足不了網站持續(xù)增長的業(yè)務需求。此時就可以考慮集群的方式，通過負載均衡調度服務器，可以將來自用戶的請求分發(fā)到應用服務器集群中的任何一臺服務器上。

數(shù)據(jù)庫讀寫分離

使用緩存后，大部分的數(shù)據(jù)讀操作訪問都可以不通過數(shù)據(jù)庫完成，但是仍有部分讀操作（如緩存過期，緩存不命中）和全部的寫操作需要訪問數(shù)據(jù)庫。

目前大部分數(shù)據(jù)庫都提供主從熱備的功能，在寫數(shù)據(jù)的時候，訪問主庫，主庫通過主從復制機制將數(shù)據(jù)更新同步至從數(shù)據(jù)庫，在讀的時候就可以通過從數(shù)據(jù)庫獲取數(shù)據(jù)。

使用反向代理和CDN加速網站響應

在《web性能權威指南》中有講到，網站性能的瓶頸，大部分時間都浪費在TCP的握手和傳輸上。因此可以通過CDN和反向代理的方式來加快響應。

CDN和反向代理的本質都是通過緩存，不同的主要是：

CDN部署在服務器器上的機房，用戶在請求時，從距離自己最近的機房獲取數(shù)據(jù)。

反向代理是部署在中心機房，用戶請求到達中心機房之后，首先訪問的服務器是反向代理的拂去其，如果反向代理服務器中緩存著用戶請求的額資源，就將其返回給用戶。

使用分布式文件系統(tǒng)和分布式數(shù)據(jù)庫系統(tǒng)

隨著業(yè)務的發(fā)展，依舊不能滿足的時候，就采用分布式的文件和分布式的數(shù)據(jù)庫系統(tǒng)。

分布式數(shù)據(jù)庫是數(shù)據(jù)庫拆分的最后手段，只用在單表數(shù)據(jù)規(guī)模特別龐大的時候才使用。更常用的拆分手段是業(yè)務分庫，將不同的業(yè)務數(shù)據(jù)存儲在不同的數(shù)據(jù)庫中。

使用NoSQL和搜索引擎

對數(shù)據(jù)檢索和存儲越來越復雜的時候，就可以采用一些非關系型數(shù)據(jù)庫如HBase和非數(shù)據(jù)庫查詢技術如ElasticSearch等等

業(yè)務拆分

業(yè)務場景復雜的時候，一般講整個網站業(yè)務分為不同的產品線，如首頁，訂單，買家，賣家等等。

技術上也會根據(jù)產品線劃分，將一個網站分為許多不同的應用，每個應用獨立部署維護，應用之間可以通過一個超鏈接建立聯(lián)系，也可以通過消息隊列進行數(shù)據(jù)分發(fā)，當然最多的還是通過訪問同一個數(shù)據(jù)存儲系統(tǒng)來構成一個關聯(lián)的完整系統(tǒng)。

分布式服務

隨著業(yè)務越拆越小，存儲越來越大，維護越來越困難。此時就可以將相同業(yè)務操作的提取出來，獨立部署。應用系統(tǒng)只需要管理用戶界面，通過分布式服務調用共同的業(yè)務服務完成具體的業(yè)務操作。也就是最近概念越來越火的——微服務。

云計算

大型網站架構解決了海量數(shù)據(jù)庫管理和高并發(fā)事務處理，可以將這些解決方案應用到網站自身以外的業(yè)務上。現(xiàn)在像阿里云，亞馬遜等云計算平臺，將計算作為一種基礎資源出售，中小網站不需要關系技術架構等問題，只需要按需付費，就可以使網站隨著業(yè)務的增長獲得更大的存儲和計算資源。

未來

未來還能變成什么樣子，我也不清楚，也許以后都不是開發(fā)人員來維護了，所有的這些都是AI來完成，程序員要做的就是如何完善AI。也許AI發(fā)展到最后，人類都不需要存在了吧。

網站的技術是為業(yè)務而存在的，除此以外毫無意義。在技術選型和架構設計中，脫離業(yè)務發(fā)展實際，一味的追求新技術，可能會把技術發(fā)展引入一個歪路。

技術是用來解決業(yè)務的問題，而技術不可能將所有問題都解決掉，涉及業(yè)務自身的問題，還是要通過業(yè)務手段去解決。