網站架構技術

一切以解決業務目标為首要任務；

沒有以業務為目标的任何架構、技術，都是毫無意義的耍流氓；

再牛逼的架構、再牛逼的技術，不能夠解決業務的問題，你也隻能算是會架構、會技術的工匠，而不能算是真正意義上的架構師；

業務成就了技術，平台成就了人，事業成就了人，而不是相反；

純依賴RDBMS

優點：簡單、快速疊代達成業務目标；

缺點：存在單點、談不上高可用；

技術點：應用設計要保證可擴充；

有一定的業務量和使用者規模了，想提升網站速度，于是，緩存出場了

優點：簡單有效、友善維護；

技術點：用戶端（浏覽器）緩存、前端頁面緩存、頁面片段緩存、本地資料緩存/資料庫緩存、遠端緩存；

頁面緩存：用戶端緩存，減少對網站的通路；

本地緩存：通路速度快，但資料量有限，減少對DB查詢；

遠端緩存：遠端通路，可以叢集，是以容量不受限制；

使用者量每天在增長，資料庫瘋狂讀寫，逐漸發現一台伺服器快撐不住了。于是，決定把資料服務和APP做分離

優點：簡單有效、友善維護、提高不同Server對硬體資源的使用率；

技術點：檔案伺服器部署、資料庫伺服器，擴充資料通路子產品；

分離後三台 Server 對硬體資源的需求各不相同：

應用伺服器：需要更快更強大的 CPU；

資料庫伺服器：需要更快的硬碟和更大的記憶體；

檔案伺服器：需要更大的硬碟；

單台資料庫也感覺快撐不住了，一般都會嘗試做“讀寫分離”。由于大部分網際網路“讀多寫少”的特性所決定的。Salve的台數，取決于按業務評估的讀寫比例。

優點：簡單有效、降低資料庫單台壓力；

缺點：讀寫分離，增加程式難度，架構變複雜，維護難度增加；

技術點：資料庫主從同步部署，擴充資料通路子產品，實作讀寫分離；

資料庫層面是緩解了，但是應用程式層面也出現了瓶頸，由于通路量增大，加上早期程式員水準有限寫的代碼也很爛，人員流動性也大，很難去維護和優化。是以，很常用的辦法還是“堆機器”。

優點：增加伺服器和HA機制，系統性能及可用性得到保證；

缺點：應用之間緩存、Session一緻性問題；

技術點：負載均衡；

通過叢集解決高并發、海量資料問題的常用手段，實作系統的可伸縮性。通過負載均衡排程器，可将使用者通路分發到叢集中的某台 Server 上，應用伺服器的負載壓力不再成為整個網站的瓶頸。

加機器誰都會加，關鍵是加完之後得有效果，加完之後可能會引發一些問題。例如非常常見的：叢集應用之間頁面輸出緩存和本地緩存一緻性的問題，Session儲存的問題

優點：應用之間緩存、Session一緻，存儲無限制，可以擴充；

缺點：不如本地緩存通路快，緩存伺服器、Session伺服器等仍存在單點問題；

技術點：緩存伺服器部署、Session集中存儲方案；

動靜分離也是提高網站響應速度的一種常用方式。将動态請求與靜态請求分離開，盡量減少對應用伺服器的壓力。同時，可以再進一步對靜态請求，進行緩存，以加快響應速度。可以需要開發人員配合（把靜态資源放獨立站點下），也可以不需要開發人員配合（利用7層反向代理來處理，根據字尾名等資訊來判斷資源類型）。

優點：減輕應用負載壓力，針對靜态檔案緩存；

缺點：靜态檔案緩存更新失效問題；

技術點：動靜分離、靜态檔案緩存方案；

使用反向代理和CDN加速網站響應：CDN 和反向代理的基本原理都是緩存，差別在于：

CDN部署在網絡提供商的機房；

反向代理則部署在網站的中心機房；

使用 CDN 和反向代理的目的都是盡早傳回資料給使用者，一方面加快使用者通路速度，另一方面也減輕後端伺服器的負載壓力

優點：減輕應用負載壓力，異地緩存有效解決不同地方使用者通路過慢的問題；

缺點：成本大幅增加，架構進一步複雜化，也維護難度進一步增大，靜态檔案緩存更新失效問題；

技術點：CDN、反向代理方案；

基本做到了DB層面和應用層面的橫向擴充了，可以開始關注一些其它方面，例如：站内搜尋的精準度，對DB的依賴，開始引入全文索引、NoSQL。

NoSQL和搜尋引擎都是源自網際網路的技術手段，對可伸縮的分布式特性具有更好的支援。應用伺服器則通過一個統一資料通路子產品通路各種資料，減輕應用程式管理諸多資料源的麻煩。

優點：降低DB依賴；

缺點：單點問題，談不上高可用；

技術點：NoSQL、搜尋引擎、分布式；

一個能夠承載日均百萬級通路量的中型網站架構就是這樣了

檔案系統、資料庫系統叢集；

靜态内容伺服器叢集；

CDN伺服器叢集；

反向代理伺服器叢集；

負載均衡排程器叢集；

分布式NoSQL伺服器叢集；

搜尋引擎伺服器叢集；

分布式緩存伺服器叢集；

分布式Session伺服器叢集；

使用叢集備援負載 保證高可用

優點：叢集負載，保證高可用；

缺點：資料一緻性、資料有狀态問題；

技術點：負載排程器、叢集方案；

截止目前為止都不怎麼需要大面積的修改代碼。如果上面那些手段都用光了，還是支撐不住怎麼辦？不停的加機器也不是辦法啊？

業務越來越複雜，網站的功能越來越多，雖然部署層面是采用的叢集，但是應用程式架構層面還是“集中式”的，這樣會導緻很多耦合，不便于開發、維護，而且容易“一榮俱損”。是以，通常會把網站拆分出不同的子站點來單獨宿主。

通過分而治之的手段将整個網站業務分成不同的産品線，如首頁、商鋪、訂單、賣家、買家等拆分成不同的産品線，分歸不同的業務團隊負責。各個應用之間可以通過建立一個超連結建立關系，也可以通過消息隊列進行資料分發。

應用垂直拆分（分壓，解耦）

優點：降低耦合、分壓；

缺點：應用架構複雜；

技術點：業務抽取拆分；

應用都拆了，由于單個資料庫的連接配接，QPS，TPS，I/O處理能力都非常有限，DB層面也可以去做垂直分庫操作。

業務垂直分庫 分壓 解耦

優點：降低DB耦合、分壓DB；

缺點：資料通路子產品複雜；

拆分應用和DB之後，其實還是會有很多問題。不同的站點，裡面可能會有相同邏輯和功能的代碼。當然，對于一些基礎的功能我們可以封裝DLL或者Jar包去到處提供引用，但是這種強依賴也很容易造成一些問題（版本問題、依賴關系等處理起來非常麻煩）。

既然每一個應用系統都需要執行許多相通的業務操作，比如使用者管理、商品管理等，那麼可以将這些共用的業務提取出來，獨立部署。這樣，傳說中的SOA的價值就得到展現了。

面向服務的體系結構（SOA）是一個元件模型，它将應用程式的不同功能單元（稱為服務）通過這些服務之間定義良好的接口和契約聯系起來。接口是采用中立的方式進行定義的，它應該獨立于實作服務的硬體平台、作業系統和程式設計語言。這使得建構在各種這樣的系統中的服務可以以一種統一和通用的方式進行互動。

分布式服務化（解耦，去重複）

優點：服務統一管理，提供重用度；

缺點：應用架構更複雜；

技術點：業務抽取拆分、服務化技術方案；

應用、服務之間還是會出現一些依賴問題，這時候，高吞吐量的解耦利器出現了。

消息隊列（服務間異步解耦 高吞吐量）

優點：提高吞吐量、應用、服務之間解耦；

缺點：存在消息消費延遲問題；

技術點：消息隊列技術方案；

分庫分表。不是業務發展和各方面非常迫切，不要輕易走這一步。因為分庫分表誰都會幹，關鍵是拆完之後怎麼辦。目前，市面上還沒有完全開源免費的方案，能讓你一勞永逸地解決資料庫拆分問題。

分庫分表：

橫向拆分；

縱向拆分；

分布式資料庫通路層；

資料庫中間件（代理）；

大型網站架構就是在不同階段時解決不同問題的過程中慢慢演進來的。