偏愛MySQL，Wix使用4個Web Server支撐5400萬個使用者網站

【編者按】Wix運營網站已經有很長一段時間，而在基於HTML5的WYSIWYG網頁製作平臺推出後，使用者在該公司建立的網站已超過5400萬個，同時其中大部分網站的日PV都不到100。 鑒於每個網頁的PV都很低，因此傳統的緩存策略並不適用。 然而即使是這樣，該公司也只使用了4個Web Server就完成了這些工作。 近日，Wix首席後端工程師Aviran Mordo在「 Wix Architecture at Scale」的演講中分享了他們的策略，下面我們一起看High Scalability創始人Todd Hoff的總結：

以下為譯文

Wix圍繞擴充性上的努力可以用「定制化」三個字來總結——在仔細地審視了系統之後，以高可用和高性能為目標對系統進行了改善。

Wix使用了多資料中心和雲服務，這在通常情況下非常少見，他們將資料同時複製到Google Compute Engine和AWS。 對於容錯移轉，他們有專門的應對策略。

從始至終，Wix都沒有使用事務。 取而代之，所有資料都是不可變的，他們為用例使用了一個非常簡單的最終一致性策略。 Wix並不是緩存策略愛好者，簡而言之他們並沒有打造一個非常高端的緩存層。 取而代之，他們將大部分的精力放在了路徑渲染優化上，讓每個頁面的顯示時間不超過100毫秒。

Wix開始于一個非常小的系統，使用了單片架構；而在業務發展過程中，他們很自然地過渡到一個面向服務的架構。 在整個架構中，他們使用了一個非常成熟的服務識別策略，從而可以很輕易的將所有精力都集中到一個事件上來。

系統統計

5400個網站，每個月都會新增100萬個 800+TB的靜態資料，每天1.5TB的新檔 3個資料中心+兩個雲服務（谷歌和亞馬遜） 300個伺服器 每天7億個HTTP請求 總計600員工，200人的研發團隊 系統內服務數量達50個 4個公共Web Server來支撐4500萬個網站

系統元件

MySQL Google和Amazon雲服務 CDN（內容分發網路） Chef

系統衍變

1. 系統始于簡單的單片架構，開始時只有一個應用伺服器，對於任何人來說，這都是最簡單的初始策略，非常靈活且易於更新。

Tomcat、Hibernate、定制網路框架。 使用有狀態的登錄。 無視任何性能和擴充性相關。

2. 兩年後。

仍然使用單片伺服器支撐所有事情。 擁有了一定規模的開發團隊，且需要支撐一定規模的使用者。 依賴性產生的問題。 某點的改變通常會造成整個系統的變更，無關領域的故障通常會造成整個系統大範圍崩潰。

3. 系統拆分的時候到了。

到面向服務的架構轉變，但是這並不是件容易的事情。 比如，你如何將某個功能分離到兩個服務中？ 聚焦使用者在系統中的行為，並將之主要歸結為3類：修改網站、查看Wix建立的網站以及媒體服務。 網站更新包括伺服器資料的資料有效性、安全和驗證、資料一致性以及大量的資料修改操作。 一旦某個網站建立完成，使用者就會進行查看。 因此，對於整個系統來說，訪客的數量十倍于修改者。 因此關注點會轉換為：

高可用性。 因為使用者業務行為，HA成為系統最大的特性。 高性能。 高流量值。 長尾問題。 平臺上已經有了大量的網站，但是它們通常都非常小。 單獨看某個網站，每天可能只有10或100個PV。 鑒於這種特性，緩存對於系統擴展來說並不會起到太大的作用。 因此，緩存變得非常低效。

媒體支撐是第二大服務，包括HTML、javascript、css及images。 他們需要一個途徑來支撐800TB資料上的大量請求，其中緩存靜態內容成為制勝的關鍵。 新系統看起來像一個網路層，網站被切分為3個部分服務：修改部分（任何對資料產生修改的操作），媒體部分（支撐靜態內容，唯讀），公共部分（一個檔被訪問的首部分，唯讀）。

服務打造的指導方針

每個服務都有自己獨立的資料庫，每個資料庫只能一個被一個服務寫入。 資料庫只能被服務的API訪問，這樣可以將關注點分離，並將資料模型對其他服務透明。 鑒於性能原因，其他服務只被賦予資料庫的唯讀許可權，一個資料庫只能被一個服務寫入。 服務都是無狀態的，這讓水準擴展非常便捷，業務的增長只需要添加更多伺服器就可以支撐。 不使用事務。 除下billing/financial 事務以外，所有其他服務都不使用事務，這裡的理念是避免資料庫事務所帶來的開銷，從而提升性能。 鑒於不使用事務，開發者必須考慮設計合適的資料模型來完成事務邏輯特性，從而避免不一致狀態。 在新服務設計時，緩存並不是所需要考慮的因素。 首先，盡可能的考慮服務性能，然後快速的部署到生產環境，查看服務的運行情況。 只有在代碼無法優化的情況下，才使用緩存來解決性能問題。

更新服務

更新服務必須處理大量的檔。 資料被使用不可變的JSON pages在MySQL中存儲，每天大約250萬個。 MySQL是個非常棒的鍵值存儲。 鍵的設定基於檔的雜湊函數，因此鍵是不可變的，通過主鍵來訪問MySQL可以獲得非常理想的性能。 可接受的擴充性。 在擴充性方面，Wix又做了什麼樣的權衡？ Wix之所以不使用NoSQL的原因是NoSQL往往會犧牲一致性，而通常開發者並不具備處理這種情況的能力，所以堅持MySQL也並非不可。 動態資料庫。 為了給那些經常訪問的網站讓路，所有網站的冷資料（通常是建立時間超過3個月以上的資料）都會被轉移到其他的資料庫，這些資料庫的性能往往會非常低，但是容量很高。 給使用者增長留有容量空間。 大型檔案資料庫是非常緩慢的，但是鑒於資料使用的頻率這不會出現任何問題。 但是一旦這個資料被訪問，在下次訪問之前這個資料就會被轉移到活躍資料庫。

打造更新服務的高可用性

大資料體積達到一定程度時，任何事情的高可用都是難以保證的。 因此，著眼關鍵路徑，在網站領域無疑就是網站的內容。 如果網站的一個裝飾部分問題，它對網站的可用性不會造成任何致命影響。 因此對一個網站來說，關鍵路徑才是唯一關注點。 防止資料庫崩潰。 如果你想盡可能快的完成容錯移轉，務必做好資料庫的備份，並在故障恢復時快速切換到從資料庫。 資料完整性保護。 這裡並不一定是惡意破壞，一個bug可能就會對資料存儲產生影響。 所有資料都是不可變的，為任何資料保存校訂版本。 最壞的情況下，即使資料被破壞到無法修復，我們也可以將之恢復到修訂版本。 阻止不可用情況發生。 區別于桌面應用程式，網站必須可以被隨時隨地地訪問。 因此，在不同地理位置的資料中心，不同雲環境中對資料進行備份非常重要，這將賦予系統足夠的彈性。

在一個網站上點擊「保存」按鈕，修改會話會給修改伺服器發送一個JSON檔。 伺服器會給活躍MySQL伺服器發送頁面，同時它會在另一個資料中心進行備份。 當資料在本地修改後，一個非同步進程會將修改上傳到一個靜態網格，也就是所謂的媒體部分。 當資料被傳輸到靜態網格後，一個通知會發送給保存在Google Compute Engine上的存檔服務。 存檔服務會連接到這個靜態網格，下載這個修改頁面，並將之保存在谷歌雲服務中。 然後，一個通知會發送到修改器，告知頁面已經存儲到GCE。 同時，系統會根據GCE的資料在Amazon中保存另一個副本。 當最後一個通知收到後，這意味著這個資料已經保存了3個副本：一個資料庫，一個靜態網格以及一個GCE。 對於新版本來說是3個副本，而對於舊版本來說則會存在兩個副本。 這個過程具備自我修復的特性。 如果這裡存在一個錯誤，當使用者下一次更新其網站內容時，所有未完成的修改會被重新上傳。 停用檔會做垃圾收集處理。 使用無資料庫事務方式給資料建模

對於服務擁有者來說，他們從來都不期望發生這樣的情況：使用者同時對兩個頁面進行修改，結果只有一個頁面被存儲到了資料庫中，這就造成了不一致狀態。 取得所有JSON檔，隨後按照順序將他們保存到資料庫。 當所有資料被保存後，一個命令會被發佈，它包含了上傳到這個靜態伺服器上所有被保存頁面的ID清單（靜態伺服器中檔案名稱的雜湊值）。

媒體部分

存儲了大量檔。 800TB的使用者媒體檔案，平均每天300萬個檔，5億條元記錄。 對圖像進行修改。 它們會針對不同設備和螢幕對圖像進行修改。 在這裡，可以根據需求插入浮水印，同時還可以對音訊格式進行轉換。 建立一個一致性分散式檔案系統，使用多資料中心備份模式，並且實現跨資料中心的故障恢復。 運行的痛苦。 32個伺服器，每9個月翻一倍。 計畫遷移到雲中以獲得更好的擴充性。 讓供應商鎖定見鬼。 因為都使用了API，只需要改變實現方式就可以在數周內跨雲服務供應商進行遷移。 在Google Compute Engine中遭遇失敗。 當他們從資料中心遷移到GCE時，很快就受到了谷歌雲服務的限制。 而在谷歌做出了一些改變後，系統得以正常運行。 資料是不可變的，因此非常有利於緩存。 圖像請求會首先發送到CDN。 如果所請求的圖像在CDN中並不存在，請求會被直接傳遞給他們奧斯丁的主資料中心。 如果在主資料中心也沒有發現這個圖像，隨後尋找的地點就是谷歌雲服務。 如果谷歌雲服務中仍然未發現所請求的圖像，那麼下一個尋找地點則是坦帕市的資料中心。

公用部分

解析URL（在4500萬網站中），並將之分配給指定的渲染程式，然後轉換成HTML、sitemap XML或者robots TXT等。 公用的SLA，峰值時回應時間低於100毫秒。 網站必須是高可用的，同時也需要非常高的性能，但是緩存卻並不能發揮作用。 當一個使用者修改某個頁面並進行發佈後，包括這個頁面元素的清單會被推送到公用環境，同時推送的還有路由表。 最小化宕機情況。 解析一次路由需要促發一個資料庫調用。 將請求分配個渲染器需要1次RPC調用。 獲得網站清單也需要一次資料庫調用。 查詢表會在記憶體中進行緩存，每5分鐘修改一次。 因為需要傳送給編輯器，資料不可能保存為同一種格式。 資料使用非正常化格式進行存儲，通過主鍵進行優化，所有需求的內容都會在單一請求中返回。 最小化業務邏輯。 資料是非正常化的，並且進行預計算。 大規模場景下，每秒內發生的每個操作都會乘以4500萬次，因此發生在公共伺服器上的每個操作都需要被調整。 頁面渲染

由公共伺服器返回的html是 bootstrap html類型的，它使用了一個JavaScript Shell，並包含了所有網站清單和動態資料相關的JSON資料。 渲染會被放在用戶端進行。 當下，筆記本電腦和行動裝置已經擁有了很強大的性能，它們完全可以從事這個工作。 之所以選擇JSON，因為解析和壓縮都非常方便。 用戶端上的bug非常容易修補。 修補用戶端bug只需要重新部署一個用戶端代碼，如果在伺服器端進行渲染，html則會被緩存，因此修補一個bug需要重新渲染上千萬個網站。

公用部分的高可用性

雖然目標是一直可用，但是總會發生一些意外情況 通常情況下：請求由瀏覽器發出，隨之會被傳輸到一個資料中心，通過一個負載等化器，它將會給發送到一個公共伺服器，解析路由，傳送給渲染器，隨後返回到瀏覽器， 並使用瀏覽器運行javascript。 隨後，瀏覽器會對檔案服務發送請求，檔案服務會做與瀏覽器相同的操作，然後將資料儲存到緩存。 資料中心丟失發生的情況：這時候，所有UPS都會掛掉，資料中心也會丟失。 所有DNS都會被改變，請求會發送給次資料中心。 公用部分丟失的情況：當負載等化器配置只進行一半發生這個問題時，所有公共伺服器都會丟失。 或者當部署錯誤版本時，伺服器則會拋出故障。 Wix通過定制負載等化器代碼來解決這個問題，在公共伺服器丟失時，他們會將檔案伺服器路由到快取記憶體，即使系統在警報後已經進行故障恢復。 在網路連通性很爛的情況：請求由瀏覽器發出，隨之會被傳輸到一個資料中心，通過一個負載等化器，並返回對應的html。 現在JavaScript代碼必須取回所有的JSON資料和頁面。 隨後進入內容分發網路，發送到靜態網格，並獲得所有的檔進行網站渲染。 在網路很卡的情況下，檔返回可能無法進行。 JavaScript則會做出選擇：如果主要位置無法獲得檔，代碼則會在檔案服務中獲取。

學到的知識

識別業務的關鍵路勁和關注點，仔細瞭解產品運行的方式，開發使用場景，盡力讓你工作物有所值。 使用多雲和多資料中心。 為了更好的可用性，在關鍵路徑上建立冗余。 對資料進行轉換，最小化進程外跳，一切只為了性能。 預計算並做一切可以做的事情來減少網路抖動。 利用好用戶端的CPU，為可用性建立關鍵路徑上的冗余。 從小做起，先跑起來，然後尋找下一個決策。 從始至終，Wix首要解決的都是如何才能讓服務可以良好運行的工作，然後有條不紊的轉移到面向服務的架構。 長尾需要不同的途徑進行解決。 取代緩存一切，Wix通過優化渲染途徑來提升服務，並將資料在活躍和檔案資料庫中同時進行備份。 使用不可變的方式。 不可變會對服務的架構產生深遠影響，覆蓋後端到用戶端的所有處理，對於許多問題來說，這都是個優雅的解決方案。 供應商鎖定根本不存在。 所有功能都通過API實現，只需要修改實現就可以在數周內完成不同雲供應商的遷移。 最大的瓶頸來自資料。 在不同雲環境中轉移大量資料異常困難。

原文連結： Nifty Architecture Tricks From Wix - Building A Publishing Platform At Scale（翻譯/童陽 責編/仲浩）

CSDN誠邀您參加中國大資料有獎大調查活動，只需回答23個問題就有機會獲得最高價值2700元的大獎（共10個）， 速度參與進來吧！

全國大資料創新專案評選活動目前也在如火如荼進行中，詳情點擊這裡。

2014中國大資料技術大會（Big Data Technology Conference 2014，BDTC 2014）將于2014年12月12日-14日在北京新雲南皇冠假日酒店召開。 傳承自2008年，歷經七屆沉澱，「中國大資料技術大會」是目前國內最具影響、規模最大的大資料領域技術盛會。 本屆會議，你不僅可以瞭解到Apache Hadoop提交者Uma Maheswara Rao G（兼專案管理委員會成員）、Yi Liu，以及Apache Hadoop和Tez專案管理委員會成員Bikas Saha等分享的通用大資料開源專案的最新成果和發展趨勢，還將斬獲來自騰訊、阿裡、Cloudera、LinkedIn、網易等機構的數十場乾貨分享。 當下門票團購還有些許優惠， 預購從速。

免費訂閱「CSDN大資料」微信公眾號，即時瞭解最新的大資料進展！

CSDN大資料，專注大資料資訊、技術和經驗的分享和討論，提供Hadoop、Spark、Impala、Storm、HBase、MongoDB、Solr、機器學習、智慧演算法等相關大資料觀點，大資料技術，大資料平臺，大資料實踐 ，大資料產業資訊等服務。