阿里巴巴網(wǎng)站技術(shù)介紹

網(wǎng)站鏡像和同步技術(shù)

綱要一、前言二、網(wǎng)站部署的三個階段三、新的挑戰(zhàn)四、總結(jié)阿里巴巴（A）是一個服務(wù)于全球企業(yè)的（B2B）電子商務(wù)平臺。用戶遍布中國以及世界各地，為了更好的為這上千萬的用戶提供網(wǎng)絡(luò)服務(wù)，我們建立了多個站點去為用戶提供應(yīng)用.總體而言,我們的站點發(fā)展經(jīng)歷了以下三個階段：單站點雙站點多站點前言網(wǎng)站部署的三個階段應(yīng)用都是無狀態(tài)的狀態(tài)數(shù)據(jù)都保存在以下的設(shè)備中數(shù)據(jù)庫存儲第一階段-單站點狀態(tài)數(shù)據(jù)都保存在數(shù)據(jù)庫和存儲，由數(shù)據(jù)庫和存儲提供分布式以及HA的解決方案。應(yīng)用都是無狀態(tài)的（盡量用Cookie解決session的問題），非常便于擴展。描述缺點

部分地區(qū)用戶的使用體驗不佳系統(tǒng)性能和擴展性不好第一階段-單站點DNS負載均衡(IDC之間的負載均衡)數(shù)據(jù)同步解決方案應(yīng)用拆分＆鏡像需要解決的問題第二階段-雙站點DNS負載均衡第二階段-雙站點數(shù)據(jù)同步1.0-方案選型數(shù)據(jù)庫提供的方式專業(yè)工具,例如shareplex自主開發(fā)同步效率中高中雙向同步不支持支持支持關(guān)聯(lián)的文件同步不支持不支持支持異構(gòu)數(shù)據(jù)庫不支持不支持支持沖突檢測邏輯不支持不支持支持第二階段-雙站點第二階段-雙站點數(shù)據(jù)同步1.0-缺點數(shù)據(jù)同步1.0-優(yōu)點CAP原理寫應(yīng)用:符合Consistency&Availability讀應(yīng)用:符合Partitiontolerance&Availability,

結(jié)論:讀應(yīng)用更容易實現(xiàn)跨IDC的部署問題數(shù)據(jù)同步會放大數(shù)據(jù)不一致&數(shù)據(jù)不完整的情況.這會增加鏡像站點應(yīng)用的復雜性.應(yīng)用拆分-分析第二階段-雙站點應(yīng)用拆分-注意事項第二階段-雙站點被鏡像的讀應(yīng)用需要從設(shè)計上避免數(shù)據(jù)完整性的問題.設(shè)計業(yè)務(wù)流程的時候需要避免跨IDC的WebFlow.部署結(jié)果第二階段-雙站點解決了大多數(shù)讀應(yīng)用和少量寫應(yīng)用的用戶體驗問題.實現(xiàn)了讀應(yīng)用的跨站點的HA.提高了讀應(yīng)用以及網(wǎng)站的整體可用性.讀應(yīng)用的數(shù)據(jù)源盡量遷移到了Searchengine和cache上為其性能和可擴展性帶來了很大的收益.收益第二階段-雙站點不完全的鏡像同步的延遲到導致應(yīng)用之間數(shù)據(jù)不一致的問題，尤其在不同IDC之間存在應(yīng)用的依賴時，這個問題會被放大。數(shù)據(jù)的雙向同步帶來了一些不能解決的數(shù)據(jù)沖突，需要在設(shè)計的時候進行規(guī)避。缺陷第二階段-雙站點起因第三階段-多站點Disaster…目標第三階段-多站點挑戰(zhàn)第三階段-多站點多個IDC之間的數(shù)據(jù)同步數(shù)據(jù)同步的吞吐量以及數(shù)據(jù)一致性的問題.

寫應(yīng)用的鏡像&數(shù)據(jù)拆分數(shù)據(jù)同步的瓶頸并不在于網(wǎng)絡(luò)數(shù)據(jù)同步的瓶頸最終受制于為了滿足數(shù)據(jù)一致性而對寫入操作進行的排序數(shù)據(jù)同步瓶頸分析第三階段-多站點在數(shù)據(jù)庫層面記錄數(shù)據(jù)變更基于Base原則消息驅(qū)動并行所有可以并行的內(nèi)容.有選擇的侵入業(yè)務(wù)簡單的處理沖突的邏輯Merge操作數(shù)據(jù)同步2.0設(shè)計原則第三階段-多站點提高對數(shù)據(jù)不一致窗口的容忍程度．數(shù)據(jù)庫記錄中的文件路徑的問題.降低多點更新數(shù)據(jù)的沖突可能性引用計數(shù)的問題應(yīng)用的注意事項&案例第三階段-多站點IDC之間的數(shù)據(jù)不能遵循ACID,只遵循Base的原則.下面兩個問題是提高用戶體驗的關(guān)鍵.提高同步性能，縮小數(shù)據(jù)不一致性窗口盡量保證目的端數(shù)據(jù)庫的數(shù)據(jù)完整性.單個IDC內(nèi)部的數(shù)據(jù)一致性優(yōu)于跨IDC的數(shù)據(jù)環(huán)境.所以。盡量把單個用戶的操作行為限制在單個IDC中.總結(jié)第三階段-多站點綱要一、前言二、網(wǎng)站部署的三個階段三、新的挑戰(zhàn)四、階段性總結(jié)集中的持久化技術(shù)已經(jīng)不足以支撐應(yīng)用的寫入的吞吐量，其他的持久化技術(shù)開始引入分布式數(shù)據(jù)庫其他分布式持久化方案的引入:KV-Engine,DFS..分布式事務(wù).一、應(yīng)用架構(gòu)發(fā)展的需要新的挑戰(zhàn)新的挑戰(zhàn)數(shù)據(jù)復制的節(jié)點增加.硬件成本隨之增大一些特殊應(yīng)用對同步實時性的要求提高.隨著分布式持久化技術(shù)的引入.單個IDC的數(shù)據(jù)持久化能力得到極大的提升.但數(shù)據(jù)同步技術(shù)因為受制于數(shù)據(jù)一致性

的問題,逐漸成為了瓶頸.設(shè)備數(shù)量的增長對自動化管理提出了新的要求.多站點的發(fā)布,自動化測試以及應(yīng)用監(jiān)控.跨站點的動態(tài)負載均衡問題新的挑戰(zhàn)數(shù)據(jù)同步方案的優(yōu)化有效地控制數(shù)據(jù)備份的數(shù)量.在合適的場景下使用反向代理技術(shù).水平拆分優(yōu)于垂直拆分.應(yīng)用監(jiān)控平臺自動化發(fā)布和部署的平臺.解決方案新的挑戰(zhàn)優(yōu)化數(shù)據(jù)變更的采集方式根據(jù)數(shù)據(jù)的類型設(shè)定不同的通道和策略.解決各種分布式數(shù)據(jù)源的數(shù)據(jù)一致性的問題.(分布式事務(wù)的場景)紀錄和嘗試解決數(shù)據(jù)沖突的問題.數(shù)據(jù)同步3.0新的挑戰(zhàn)適用范圍數(shù)據(jù)總量比較大,訪問相對集中的靜態(tài)資源;例如圖片信息.訪問量比較小的一些動態(tài)應(yīng)用.效果降低同步數(shù)據(jù)量降低存儲設(shè)備的投入減少因為同步延遲而造成的數(shù)據(jù)不一致.反向代理新的挑戰(zhàn)綱要一、前言二、網(wǎng)站部署的三個階段三、新的挑戰(zhàn)四、階段性總結(jié)鏡像的關(guān)鍵是數(shù)據(jù)同步的問題.根據(jù)D&Q的原則.將中心最小化.采用異步或者事后補償?shù)臋C制降低中心應(yīng)用對其他應(yīng)用的可用性的影