淘寶可伸縮高效能網際網路架構: 果然每一項都很關鍵

一 應用無狀態(淘寶session框架)

假如在session中儲存了大量與客戶端的狀態資訊，儲存狀態資訊的server當機時

　　通常通過叢集解決，不僅有負載均衡，更重要的是要有失效恢復failover

　　tomcat用叢集節點廣播複製，jboss用配對複製等session狀態複製策略，但嚴重影響系統的伸縮性，不能通過增加更多的機器達到良好的水平伸縮

　　因為叢集節點間session通訊隨著節點的增多而開銷增大，因此要想做到應用本身的伸縮性，要保證應用無狀態，這樣叢集中的各個節點來說都是相同的，使系統更好的水平伸縮

　　淘寶的session框架用clientcookie實現，將狀態儲存到cookie裡，使應用節點本身不要儲存狀態資訊，這樣在系統使用者變多的時候，就可以通過增加更多的應用節點來達到水平擴充套件的目的

　　但有限制，比如每個cookie一般不能超過4K的大小，很多瀏覽器都限制一個站點最多儲存20個cookie

　　淘寶cookie框架是“多值cookie”，一個組合鍵對應多個cookie的值，可以防止cookie數量超過20，還節省了cookie儲存有效資訊的空間

　　除了淘寶目前的session框架的實現方式以外，其實集中式session管理來完成，說具體點就是多個無狀態的應用節點連線一個session 伺服器，session伺服器將session保 存到快取中，session伺服器後端再配有底層永續性資料來源，比如資料庫，檔案系統等等。

　　二 有效使用快取(Tair)

　　瀏覽器快取，反向代理快取，頁面快取，區域性頁面快取，物件快取等等

　　大部分情況都是讀快取,讀寫比不高，對資料安全性需求不高的資料，將其快取，減少對資料庫訪問

　　店鋪系統，如店鋪介紹，店鋪服務條款，寶貝詳情,適合放到快取中，減少DB的負載

　　三 應用拆分(HSF)

　　拆分(也算是一種解耦)，將原來的系統根據一定的標準，比如業務相關性等分為不同的子系統，提高系統擴充套件性和可維護性，系統的水平伸縮性提升，可以有針對性的對壓力大的子系統進行水平擴充套件而不影響到其它的子系統

　　子系統之間的耦合減低了，當某個子系統暫時不可用的時候，整體系統還是可用的，從而整體系統的可用性也大大增強了

　　拆分也給系統帶來了問題，子系統之間如何通訊

　　一般有同步通訊和非同步通訊，這個時候高效能的遠端呼叫框架就顯得非常總要

　　四 資料庫拆分(TDDL)

　　應用除了應用級別的拆分以外，另外一個很重要的層面就是儲存如何拆分,通常就是所說的RDBMS進行拆分

　　資料庫讀取壓力太大，就是到了讀寫分離的時候，配置一個server為master節點，然後配幾個salve節點，通過讀寫分離，使得讀取資料的壓力分攤到了不同的salve節點上面，系統恢復正常

　　到了master負載太高時就要垂直分割槽了(就是所謂的分庫)

　　比如將商品資訊，使用者資訊，交易資訊分別儲存到不同資料庫，同時還可以針對商品資訊的庫採用master，salve模式，

　　分庫後，各個按照功能拆分的資料庫寫壓力被分擔到了不同的server上面，資料庫的壓力終又恢復到正常狀態

　　使用者量的不斷增加，系統中某些表異常龐大，比如好友關係表，店鋪引數配置表等，這個時候無論是寫入還是讀取這些表的資料，對資料庫來說都是一個很耗費精力的事情，此時就要進行“水平分割槽”了(俗話說的分表，或者說sharding)

　　資料庫是系統中最不容易scale out的一層

　　大型的應用必然會經過一個從單一DB server,到Master/salve,再到垂直分割槽(分 庫)，然後再到水平分割槽(分表，sharding)的過程，而在這個過程中，Master/salve 以 及垂直分割槽相對比較容易，對應用的影響也不是很大，但是分表會引起一些棘手的問題，比如不能跨越多個分割槽join查 詢資料，如何平衡各個shards的 負載等等，這個時候就需要一個通用的DAL框架來遮蔽底層資料儲存對應用邏輯的影響，使得底層資料的訪問對應用透明化

　　從昂貴的高階儲存(小型機+ORACLE)切換到MYSQL後，勢必會遇到垂直分割槽(分庫)以及水平分割槽(Sharding)的問題，淘寶根據其業務特點開發了自己的TDDL框架，解決分庫分表對應用的透明化以及異構資料庫之間的資料複製

　　五 非同步通訊(Notify)

　　訊息中介軟體登場,採用非同步通訊關係到系統的伸縮性,以及最大化的對各個子系統進行解耦

　　非同步一定是根據業務特點來的，一定是針對業務的非同步，通常適合非同步的場合是一些鬆耦合的通訊場合，而對於本身業務上關聯度比較大的業務系統之間，還是要採用同步通訊比較靠譜

　　六 非結構化資料儲存 ( TFS,NOSQL)

　　不是所有的資料都是結構化的

　　比如一些配置檔案，使用者對應的動態，一次交易的快照等，一般不適合儲存到RDBMS，更符合一種Key-value的結構

　　另一類資料，資料量非常大，但實時性要求不高，此時這些資料也需要通過另外的一種儲存方式進行儲存

　　一些靜態檔案，比如各個商品的圖片，商品描述等資訊，這些資訊因為比較大，放入RDBMS會引起讀取效能問題，影響其它資料讀取效能，也要和其它資訊分開儲存，一般的選擇分散式檔案系統，

　　隨 著網際網路的發展，業界從08年 下半年開始逐漸流行了一個概念就是NOSQL。我們都知道根據CAP理論，一致性，可用性和分割槽容錯性3者 不能同時滿足，最多隻能同時滿足兩個

　　傳統關係資料採用ACID事務策略，更加講究高一致性而降低了可用性的需求，但是網際網路應用往往對可用性的要求要略高於一致性的需求，這時候就要避免採用資料的ACID事務策略，轉而採用BASE(基本可用性，事務軟狀態以及最終一致性)事務策略

　　通過最終一致性提升系統可用性，這也是目前很多NOSQL產品所採用的策略，包括facebook 的cassandra,apache hbase,google bigtable等，非常適合一些非結構化的資料，如key-value形式資料儲存，並且這些產品有個很好的優點就是水平伸縮性

　　七 監控、預警系統

　　大型分散式系統涉及各種裝置，比如網路交換機，普通PC機，各種型號的網路卡，硬碟，記憶體等等，在數量非常多的時候，出現錯誤的概率也會變大，因此要時刻監控系統狀態

　　監控有粒度的粗細之分

　　粒度粗一點，對整個應用系統進行監控，網路流量，記憶體利用率，IO，CPU負載，服務訪問壓力，服務的響應時間

　　細粒度一點，對應用中的某個功能，某個URL訪問量，每個頁面的PV，頁面每天佔用的頻寬是多少，頁面渲染時間，靜態資源比如圖片每天佔用的頻寬

　　有了監控系統以後，更重要的是要和預警系統結合起來，比如當某個頁面訪問量增多的時候，系統能自動預警，某臺Server的CPU和記憶體佔用率突然變大的時候，系統也能自動預警，當併發請求丟失嚴重的時候，系統也能自動預警等等，通過監控系統和預警系統的結合可以使得能快速響應系統出現的問題，提高系統的穩定性和可用性