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

     穩定性的極致要求

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

    2. 業務降級、限流預案

    3. 全鏈路壓測
 

天貓篇

（1）雙11的前端實踐

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

    2. 全站採用統一的kissy,MUI,通過配置檔案按需載入元件，並且前後端自動實現一致的依賴關係等。
 

    3. 淘寶的左側工具欄採用了外掛機制，分開的原始碼管理，可以單獨部署，並且支援熱插拔
 

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

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

    6. 實時到秒的釋出計劃和實時釋出。 另外，對於有些秒級業務，提前釋出，後端程式碼判斷時間來切換顯示。前端還需要通過js程式碼判斷時間重新整理，後端程式碼和前端js都需要去伺服器校對時間

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

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

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

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

     3.  統一快取接入，解決單機快取受記憶體大小制約

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

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

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

支付寶篇

（1）支付寶的架構變遷

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

     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，已開源