《天貓2013雙十一架構》讀後筆記

網購狂歡節背後的技術閱兵

     穩定性的極致要求

    1. 容量預估、依賴治理、監控

    2. 業務降級、限流預案

    3. 全鏈路壓測
 

 

天貓篇

 

（1）雙11的前端實踐

    1. 淘寶的前臺資源採用的都是非覆蓋式發佈，經過語義化路徑定位，這樣先後臺能夠分開發布，還能獨立回滾

    2. 全站採用統一的kissy,MUI,經過配置文件按需加載組件，而且先後端自動實現一致的依賴關係等。
 

    3. 淘寶的左側工具欄採用了插件機制，分開的源代碼管理，能夠單獨部署，而且支持熱插拔
 

    4. 淘寶有降級預案和限流預案，降級預案包括前觀的頁面的一些必須的功能以及json等請求
 

    5. 自動化測試，可以自動生成測試用例，進行上線前檢測，上線後質量實時監控，貓須基於nodejs+express架構開發，支持多瀏覽器，包括phantomjs ,得益於Selenium Webdriver.

    6. 實時到秒的發佈計劃和實時發佈。 另外，對於有些秒級業務，提早發佈，後端代碼判斷時間來切換顯示。前端還須要經過js代碼判斷時間刷新，後端代碼和前端js都須要去服務器校對時間

 

（2）天貓瀏覽型應用的CDN靜態化架構演變

      1. 2012階段曾採用動態內容作CSI填充。http://www.cnblogs.com/wbinblog/archive/2012/05/16/2503528.html

          從頁面中抽取出不依賴用戶，時間，地域，cookie這些維度，而且不常常變化的部分，生成URL固定的頁面。

         好比：商品頁面，標題，商品詳情，銷售屬性組合直接緩存，優惠，庫存，物流，服務動態填充。

      2. 主動失效機制：當觸發源發生變化時，發送消息給失效服務，失效服務主動失效對應內容。這個時間用戶訪問時會發現緩存已經不存在，去主動更新緩存，確實把Java系統轉變成弱依賴。

      

 

     3.  統一緩存接入，解決單機緩存受內存大小制約

           

 

       4.最終目的，CDN靜態化。  

           將靜態頁面放在CDN上，放置在離用戶最近的節點上！流量集中區域，控制節點的數量，內部再經過一致性hash規則。

           靜態化應用對應的域名解析到CDN和統一接入層虛擬IP上，這樣CDN拿到資源後先讀取本地緩存，緩存不命中的話，去統一接入層獲取。這時候統一接入層 按照按照原有的規則（上面所描述)獲取數據，緩存不命中則回到服務器端獲取數據，這個時候統一接入層Web服務器須要可以識別用戶請求是CDN回源類型還 是正常請求，以避免重複壓縮和日誌記錄。

         

       5. 這種緩存體系緩存了靜態頁面，而且使整個架構對應用系統弱依賴。使用的tair開源地址：https://github.com/alibaba/tair

 

支付寶篇

 

（1）支付寶的架構變遷

 

   1. 支付寶除了按業務類型垂直拆分外，還應該按客戶進行了數據的水平拆分。數據在主交易數據庫集羣生成，再經過數據複製中心複製到其餘兩個數據庫集羣。另外主交易數據庫集羣包括完整的備份和failver庫。

       

     2.支付寶研發了中間件產品Zdal  https://github.com/qingyeqing/zdal

     3. 支付寶爲了保障事務的可靠性，對2pc進行了改進，基於TCC型事務，沒有了prepare階段。每一個業務都進行try操做，完成後保留現場，全部的try完成後，再找回現場commit，若有失敗找回現場進行本地cancel.

    

        4.支付寶對服務也作了依賴控制，最強，強，弱，最弱，在降級時使用。在代碼中註解來標註，而後經過zookeeper實現統一配置，配置發生變化後，會把變化的值推送給訂閱的客戶端。

配置資源包括了流量控制、應用層參數、數據節點。

       5.支付內部監控方案xflush,對監控數據作增量計算，而且對上層提供二次開發接口，而且有實時日誌分析平臺，架構圖見下圖。

       6. 一次完整的自動化調度流程見下圖。彈性平臺的分析 ，支付寶是使用groovy編寫分析腳本進行的。對於產生控制指令，對於有些狀況就中止在這一步，交給人工審覈執行。

       7.支付寶天天的發佈的流程： 集成測試環境＝》預發佈環境 ＝》 beta集羣（對於A集羣，發佈時先切1%流量，沒問題再切10%,直到切完）＝》所有沒問題再發布剩餘集羣

       8.支付寶的SOFA框架，面向模塊化和組件模型，組件直接採用spring(IOC),模塊化借鑑spring-DM，業務模塊Spring上下文隔離，不一樣模塊之間的組件(bean)不可見，減小耦合。

       9.經過擴展spring scheme extensions擴展，定義組件之間的關係。組件和組件之間的依賴經過服務發佈/引用模型，組件和組件集成關係經過擴展/擴展點模型，組件和組件發佈訂閱關係經過消息topic的發佈訂閱模型。

     10. sofainsight經過java agent技術動態掛載到應用的ivm進程上，把監控信息發送到分析平臺，客戶端經過jmx監控線程池，鏈接池等。還經過aspectjs動態搭載請求從入到出的全調用鏈路耗時。

      11.zdal的核心架構圖

 

中間件篇

 

（1）中間件技術的雙11實踐

    1. 阿里如今大量使用軟負載，經過軟件系統解決請求的均衡負載，相對於F5,LVS。軟負載特色：無中心化，成本低，效率高，功能強。

    2.ConfigServer不須要master,內部實現了節點間數據增量同步的功能。數據變化後將數據推送到訂閱客戶端 ，並且客戶端本地也作了本地容災文件，ConfigServer不可用時，會優先使用本地內存中的數據，從新啓動也可先依賴本地的容災文件。

   3.感受支付寶的Notiry也和kafka相似，都是消息先落盤,  但他也支持選擇成使用內存存儲。

   4. EagleEye鷹眼系統很牛，把調用鏈全都進行了統計分析，在進來的時候生成了一個traceid,而後跟隨整個過程，能夠用於發現問題，評估。

   5.TDDL的流程

  

  

 

 

運維保障篇

 

（1）雙11數據庫技術

1.評估：經過鷹眼系統，監控調用量關係，和數據庫的qps來估算數據庫的容量。從上而下來作。考慮Cache命中率以及須要考慮Cache宕機狀況。直接經過模擬真實業務來評估單機承載量。

2. 數據庫擴容

    第一種是讀寫分離，添加從庫  第二種是水平擴容， 利用分庫規則進行細化，將數據從新拆分到更多臺服務器上 ，阿里研發了dbree,自動化完成。

3. 預案： 降級和限流

4.阿里的mysql分支alimysql,並行複製。併發控制，自我保護。

 

---

kafka在惟品會的應用 

1 .主要用來日誌傳輸，基本保持25w/s的producer性能，consumer吞吐量  55w/s.  RabbitMQ相比這下差很遠。

2 .每一個kafka集羣有多個broker，每一個broker有多個topic，每一個topic都會有多個partition.每一個partitioin只 能被一個consumer消費，consumer消費的是topic，具體消費哪一個partition由kafka的分配算法決定，能夠多個 consumer組成consumer  group消費同一個topic，Kafka保證他們不消費同一份數據.producer在發送消息時，會負載寫到同一個topic不一樣的 partition中。

3.  Kafka server有本身的編號，【server編號】_【topic名稱】_【自增編號】組成partition編號，好比0_topic1_1表示編號爲0 的server上的topic1下面的編號爲1的partition。一個partition就是一個文件.

4. Kafka利用了磁盤的順序讀寫，磁盤的順序讀寫速度快於內存的隨機讀寫速度，並且Linux系統對磁盤讀寫作了優化和緩存，重啓後還能用，若是使用內存存儲，須要jvm作gc.

5. 每一個消息在Kafka中都有一個offset，consumer消費到了那條消息經過offset記錄，能夠配置成同步offset到zookeeper中。這樣當消費系統或者消息系統出問題時能夠找到offeset回覆，由於消息存在磁盤上也沒丟.

6. Kafka的數據壓縮和解壓是producer和consumer本身作的

7.kafka沒有ack機制，由consumer本身維護

8. Kafka經過zookeeper維護broker可用列表

9. Kafka集羣中網卡可能會先於磁盤出現瓶頸，可考慮雙網卡

10. Kafka能夠直接熱擴容，直接添加server

11. 日誌收集使用flume，他們開發了針對Kafka的插件flume-Kafka，已開源