# Wix 的 Nifty Architecture 技巧-大規模構建發布平臺 > 原文： [http://highscalability.com/blog/2014/11/10/nifty-architecture-tricks-from-wix-building-a-publishing-pla.html](http://highscalability.com/blog/2014/11/10/nifty-architecture-tricks-from-wix-building-a-publishing-pla.html)  [Wix](http://www.wix.com/) 長期運營網站。 作為基于 HTML5 的所見即所得（WYSIWYG）網絡發布平臺，他們已經創建了超過 5400 萬個網站，其中大多數網站每天的網頁瀏覽量不到 100。 因此，傳統的緩存策略不適用，但僅需四個 Web 服務器即可處理所有流量。 這需要一些聰明的工作。 [Wix 后端工程負責人 Aviran Mordo](https://twitter.com/aviranm) 在精彩的演講中描述了他們的解決方案：[規模](http://www.infoq.com/presentations/wix-architecture)的 Wix 體系結構。 他們開發的最佳傳統就是專業化。 他們仔細分析了他們的系統，并弄清楚了如何以一些最有趣的方式實現其積極的高可用性和高性能目標。 Wix 使用**多個數據中心和云**。 我之前從未見過的是它們將數據復制到多個數據中心，Google Compute Engine 和 Amazon。 并且在失敗的情況下它們之間具有備用策略。 Wix **不使用交易**。 相反，所有數據都是不可變的，并且它們使用簡單的最終一致性策略來完美匹配其用例。 Wix **不緩存**（就像在大緩存層中一樣）。 取而代之的是，他們非常注意優化渲染路徑，以便每個頁面的顯示時間均不到 100ms。 Wix 從一開始就具有單一的體系結構，并有意識地**遷移到了服務體系結構**，該過程使用了一種非常刻意的過程來識別服務，該服務可以幫助任何考慮同一步驟的人。 這不是您的傳統 LAMP 堆棧或本機云。 Wix 有點不同，您可以在這里學到一些東西。 讓我們看看他們是如何做到的... ## 統計信息 * 54 個以上的網站，每月有 100 萬個新網站。 * 超過 800 TB 的靜態數據，每天有 1.5 TB 的新文件 * 3 個數據中心+ 2 個云（Google，Amazon） * 300 臺服務器 * 每天有 7 億個 HTTP 請求 * 共 600 人，R 區& D 共 200 人 * 約有 50 個服務。 * 需要 4 個公共服務器才能為 4500 萬個網站提供服務 ## 平臺 [ * MySQL * Google 和亞馬遜云 * CDN * 廚師 ## 進化 [ * 簡單的初始整體架構。 從一臺應用服務器啟動。 這是最簡單的入門方法。 進行快速更改并部署。 它使您到達特定的位置。 * Tomcat，Hibernate，自定義 Web 框架 * 使用的狀態登錄。 * 忽略了性能和擴展性的任何概念。 * 快進了兩年。 * 仍然是一臺完成所有任務的單片服務器。 * 在一定規模的開發人員和客戶眼中，它們阻礙了他們的發展。 * 功能之間的依存關系問題。 一處的更改導致整個系統的部署。 不相關區域的故障導致整個系統停機。 * 是時候把系統分開了。 * 采用了一種服務方法，但這并不容易。 您如何將功能分解為服務？ * 查看了用戶在系統中的工作，并確定了三個主要部分：編輯網站，查看由 Wix 創建的網站，提供媒體。 * 編輯網站包括服務器中數據的數據驗證，安全性和身份驗證，數據一致性以及許多數據修改請求。 * 網站制作完成后，用戶將對其進行查看。 觀看者比編輯者多 10 倍。 所以現在的問題是： * 高可用性。 高可用性是最重要的功能，因為它是用戶的業務。 * 高性能 * 高流量 * 長尾巴。 有很多網站，但是它們很小。 每個站點每天可能會獲得 10 或 100 個頁面瀏覽量。 長長的尾巴使緩存不適合可伸縮性策略。 緩存變得非常低效。 * 媒體服務是下一個重要服務。 包括 HTML，javascript，css，圖像。 需要一種在大量請求下為文件提供 800TB 數據的方法。 勝利是靜態內容是高度可緩存的。 * 新系統**看起來像**，位于三個網段服務下面的網絡層：編輯器網段（任何編輯數據的文件），媒體網段（處理靜態文件，只讀），公共網段（文件的第一位是 已查看，只讀）。 ## 如何構建服務的準則 [ * 每個服務都有自己的數據庫，只有一個服務可以寫入數據庫。 * 僅通過服務 API 訪問數據庫。 這支持將關注點分離并從其他服務隱藏數據模型。 * 出于性能原因，授予其他服務只讀訪問權限，但只能寫入一個服務。 （是的，這與之前所說的相矛盾） * **服務是無狀態的**。 這使得水平縮放變得容易。 只需添加更多服務器。 * **沒有交易**。 除帳單/金融交易外，所有其他服務均不使用交易。 這個想法是通過消除事務開銷來提高數據庫性能。 這使您考慮如何在不使用數據庫事務的情況下將數據建模為具有邏輯事務，避免出現不一致的狀態。 * 設計新服務**時，緩存不屬于體系結構**。 首先，使服務盡可能地具有性能，然后部署到生產環境，看看其性能，然后，如果存在性能問題，并且您無法優化代碼（或其他層），則只能添加緩存。 ## 編輯器細分 * 編輯器服務器必須處理大量文件。 * 在 MySQL 中存儲為不可變 JSON 頁（每天約 250 萬個）的數據。 * **MySQL 是一個很棒的鍵值存儲**。 密鑰基于文件的哈希函數，因此密鑰是不可變的。 通過主鍵訪問 MySQL 非常快速高效。 * **可伸縮性與權衡**有關。 我們要進行哪些權衡？ 不想使用 NoSQL，因為它們會犧牲一致性，并且大多數開發人員都不知道該如何處理。 因此，請堅持使用 MySQL。 * **活動數據庫**。 網站建成后發現，只有 6％的網站仍在更新中。 這樣，這些活動站點就可以存儲在一個真正快速且存儲量相對較小（2TB）的數據庫中。 * **存檔數據庫**。 對于不經常訪問的站點，所有過時的站點數據都移至相對較慢但具有大量存儲空間的另一個數據庫中。 三個月后，數據被推送到該數據庫，因為訪問率低。 （可能會說這是一種隱式緩存策略）。 * 為呼吸提供了很大的成長空間。 大型歸檔數據庫的速度很慢，但這沒關系，因為數據使用的頻率不高。 首次訪問時，數據來自存檔數據庫，但是隨后將其移至活動數據庫，因此以后的訪問速度很快。 ## 編輯器細分市場的高可用性 * 擁有大量數據，很難為所有內容提供高可用性。 因此，**查看關鍵路徑**，對于網站而言，該路徑就是網站的內容。 如果小部件出現問題，則大多數網站仍將正常工作。 在保護關鍵路徑上投入了大量資金。 * 防止數據庫崩潰。 想要快速恢復。 復制數據庫并將故障轉移到輔助數據庫。 * **防止數據損壞和數據中毒**。 不必一定是惡意的，一個漏洞足以破壞槍管。 所有數據都是不可變的。 修訂存儲了所有內容。 如果無法修復損壞，最壞的情況是還原到數據可以正常使用的版本。 * 防止不可用。 網站必須一直工作。 這推動了**在不同地理位置和多個云**之間復制數據的投資。 這使得系統非常有彈性。 * 在網站編輯會話上單擊保存會將 JSON 文件發送到編輯器服務器。 * 服務器將頁面發送到活動 MySQL 服務器，該服務器已復制到另一個數據中心。 * 將頁面保存到本地后，將啟動一個異步過程，將數據上傳到靜態網格（即媒體段）。 * 將數據上傳到靜態網格后，系統會將通知發送到在 Google Compute Engine 上運行的存檔服務。 存檔會轉到網格，下載頁面，然后將副本存儲在 Google 云中。 * 然后，通知會發送回編輯器，說明頁面已保存到 GCE。 * 另一個副本已從 GCE 保存到 Amazon。 * 收到最后一條通知，這表示當前數據修訂版有三份副本：一份在數據庫，靜態網格中，以及在 GCE 上。 * 當前版本有 3 個副本。 對于舊版本，有兩個版本（靜態網格，GCE）。 * 該過程是自修復的。 如果失敗，則下次用戶更新其網站時，所有未上傳的內容都會重新上傳。 * 孤立文件被垃圾回收。 ## 沒有數據庫事務的數據建模 * 不想出現這樣的情況，即用戶編輯了兩個頁面，而數據庫中只保存了一個頁面，這是一種不一致的狀態。 * 獲取所有 JSON 文件，并將它們一個接一個地粘貼在數據庫中。 保存所有文件后，將發出另一個保存命令，其中**包含上載到的已保存頁面的所有 ID** （這是內容的哈希，是靜態服務器上的文件名）的清單。 靜態服務器。 ## 媒體段 [ * 存儲大量文件。 800TB 的用戶媒體文件，每天上傳的 3M 文件和 500M 的元數據記錄。 * 圖像被修改。 它們針對不同的設備調整了大小并進行了銳化。 可以插入水印，還可以進行音頻格式轉換。 * 構建了一個最終一致的分布式文件系統，該系統具有多數據中心感知能力，并且可以跨 DC 自動回退。 這是在亞馬遜之前。 * 難以忍受。 32 臺服務器，每 9 個月翻一番。 * 計劃將內容推送到云以幫助擴展。 * **供應商鎖定是一個神話**。 全部都是 API。 只需更改實施，您就可以在幾周內遷移到不同的云。 * **真正使您失望的是數據**。 將 800TB 的數據轉移到另一個云上真的很困難。 * **當他們將所有數據移至 GCE 時，他們破壞了 Google Compute Engine** 。 他們達到了 Google 云的極限。 經過 Google 的一些更改后，它現在可以使用了。 * 文件是不可變的，因此高度可緩存。 * 圖像請求首先進入 CDN。 如果映像不在 CDN 中，則請求將轉到其位于奧斯丁的主數據中心。 如果圖片不在 Austin 中，則請求轉到 Google Cloud。 如果不在 Google 云中，它將轉到坦帕的數據中心。 ## 公共細分 * 解析 URL（其中的 4500 萬個），分派到適當的渲染器，然后渲染為 HTML，站點地圖 XML 或機械手 TXT 等。 * **公共 SLA 是在高峰流量**時，響應時間為< 100ms。 網站必須可用，而且速度也要很快。 記住，不要緩存。 * 當用戶在編輯頁面后單擊“發布”時，包含對頁面的引用的清單將被推送到“公共”。 路由表也已發布。 * **最小化服務中斷跳**。 需要 1 個數據庫調用才能解析路由。 1 RPC 調用，將請求分派到渲染器。 1 個數據庫調用以獲取站點清單。 * 查找表緩存在內存中，每 5 分鐘更新一次。 * 數據存儲的格式與編輯器使用的格式不同。 **以非規范化格式**存儲，已針對主鍵讀取進行了優化。 所需的所有內容都在單個請求中返回。 * **最小化業務邏輯**。 數據將被規格化和預先計算。 當您大規模處理每項操作時，每增加一毫秒，這就是 4,500 萬次，因此必須證明在公共服務器上發生的每項操作都是合理的。 * 頁面渲染。 * 公用服務器返回的 html 是 **bootstrap html** 。 這是一個包含 JavaScript 導入和 JSON 數據（引用網站清單和動態數據）的外殼。 * **渲染已卸載到客戶端**。 筆記本電腦和移動設備非常快，可以處理渲染。 * 選擇 JSON 是因為它易于解析和可壓縮。 * **更容易修復客戶端**上的錯誤。 只需重新部署新的客戶端代碼。 在服務器上完成渲染后，將緩存 html，因此，修復錯誤需要**再次重新渲染數百萬**個網站。 ## 公共段的高可用性 * 目標是永遠可用，但事情還是會發生。 * **在**美好的一天：瀏覽器發出請求，該請求通過負載平衡器到達數據中心，到達公共服務器，解析路由，到達渲染器，html 返回到 瀏覽器，然后瀏覽器運行 javascript。 javascript 會獲取所有媒體文件和 JSON 數據，并呈現一個非常漂亮的網站。 然后，瀏覽器向存檔服務發出請求。 存檔服務以與瀏覽器相同的方式重放請求，并將數據存儲在緩存中。 * 在糟糕的日子**，數據中心丟失**，這確實發生了。 所有不間斷電源系統都死了，數據中心關閉了。 DNS 已更改，然后所有請求都轉到了輔助數據中心。 * 在糟糕的日子**公眾失去了**。 當負載均衡器獲得一半配置，因此所有公共服務器都消失了時，就會發生這種情況。 或者可以部署一個錯誤版本，該版本開始返回錯誤。 如果公共服務器不可用，負載平衡器中的自定義代碼通過路由到存檔服務以獲取緩存的緩存來解決此問題。 這種方法意味著即使 Public 崩潰，客戶也不會受到影響，即使當時系統正在響起警報。 * 糟糕的一天**，互聯網糟透了**。 瀏覽器發出請求，轉到數據中心，轉到負載平衡器，獲取 html。 現在，JavaScript 代碼必須獲取所有頁面和 JSON 數據。 轉到 CDN，轉到靜態網格并獲取所有 JSON 文件以呈現站點。 在這些過程中，Internet 問題可能會阻止文件被返回。 JavaScript 中的代碼表示如果您無法到達主要位置，請嘗試從存檔服務獲取它，如果失敗，請嘗試編輯器數據庫。 ## 吸取的教訓 [ * **確定您的關鍵路徑和關注點**。 想一想您的產品如何運作。 制定使用方案。 將精力集中在這些方面，因為它們可以帶來最大的收益。 * **轉到多數據中心和多云。** 在關鍵路徑上構建冗余（以提高可用性）。 * **對數據進行非規范化并最小化進程外跳數（以提高性能）**。 進行預校正并盡一切可能使網絡顫動最小化。 * **利用客戶端的 CPU 能力**。 這樣可以節省服務器數量，并且更容易修復客戶端中的錯誤。 * **從小處著手，完成任務，然后找出下一步**的去向。 Wix 做了他們需要做的事情，以使其產品正常工作。 然后，他們有條不紊地遷移到復雜的服務體系結構。 * **長尾巴需要其他方法**。 Wix 不會緩存所有東西，而是選擇優化渲染路徑之外的內容，并將數據保留在活動數據庫和存檔數據庫中。 * **變為不可變**。 不變性對體系結構具有深遠的影響。 它影響從客戶端到后端的所有內容。 這是解決許多問題的理想解決方案。 * **供應商鎖定是一個神話**。 全部都是 API。 只需更改實施，您就可以在幾周內遷移到不同的云。 * **真正使您失望的是數據**。 將大量數據轉移到不同的云真的很困難。 有一個問題：每天的流量如何達到 700 M？ StackExchange 每天有 1.5 億，而 Alexa 評級更高。