在本文中，我們將設計一個Google Drive服務！！ (類似百度網盤,所以標題取百度網盤應該沒毛病，事實上不可能這么簡單，有時間可以討論以下百度網盤的網路架構)

系統設計是軟體工程中最重要和最令人擔憂的方面之一，很難理解軟體體系結構書籍中使用的術語，并且沒有明確的分步指南， 每個人似乎都有不同的方法， 當然，還有一個心理障礙是這些可能本來就很難理解， 因此，我根據自己學習架構課程的經驗著手設計一個系統，讓我們設計一種云檔案存盤服務，Google Drive，它是一個檔案存盤和同步服務，使用戶可以將其資料存盤在遠程服務器上，

現在，那些已經使用過Google Drive的人知道我們可以從任何設備上傳任何大小的檔案，并且可以在我們的手機，筆記本電腦，個人計算機等設備上找到這些檔案，我們很多人想知道該系統如何處理如此大量的檔案，

★系統定義

我們需要澄清系統的目標， 系統設計是一個巨大的話題，如果我們不將其范圍縮小到特定目的，那么設計系統就會變得復雜，尤其是對于新手，

用戶應該能夠從任何設備上載和下載檔案/照片，并且檔案將在用戶登錄的所有設備中同步，

如果考慮到服務中有1000萬用戶，每天有1億個請求，那么寫入和讀取操作的數量將是巨大的，為簡化起見，我們僅設計Google云端硬碟存盤空間，換句話說，用戶可以上傳和下載檔案，從而有效地將它們存盤在云中，

★系統要求

在這一部分中，我們決定系統的功能，我們可以將這些要求分為兩部分：

• 功能要求：

  用戶應該能夠從任何設備上載和下載檔案，并且檔案將在用戶登錄的所有設備中同步，
  這些是系統的主要目標，這是系統必須交付的要求，

• 非功能需求NFR：

  現在分析的更關鍵的要求，讓我們定義我們的NFR：

  用戶可以從任何設備上載和下載檔案，該服務應支持存盤最大1 GB的單個大檔案，服務應在設備之間自動同步；如果一個檔案是從設備上傳的，則應在用戶登錄的所有設備上同步該檔案，

★服務器端組件設計

對于系統設計的新手，請記住：“如果您對從哪里開始系統設計感到困惑，請嘗試從資料流開始，”

我們在該系統中的用戶可以上傳和下載檔案，用戶從客戶端應用程式/瀏覽器上載檔案，服務器將存盤它們，用戶可以從服務器下載更新的檔案，因此，讓我們看看我們如何為如此大量的用戶處理檔案的上傳和下載，

上傳/下載檔案：

從圖中可以看到，如果我們上傳完整大小的檔案，則會浪費我們的存盤和帶寬，而且，延遲會增加以完成上載或下載，

圖：完整檔案傳輸需要更多時間，存盤空間和帶寬，

高效處理檔案傳輸：

我們可以將每個檔案分成較小的塊，然后，我們只能更改資料的小片段，而不是整個檔案，萬一資料上傳失敗，該策略也將有所幫助，我們需要將每個檔案劃分為固定大小，例如2 MB，

圖：將檔案分成較小的塊以優化存盤利用率和帶寬

我們的塊大小需要更小，這將有助于優化空間利用率，而網路帶寬是做出決定時的另一個考慮因素，元資料應包括每個檔案的塊資訊的記錄，

我們可以假設檔案需要存盤在2 MB的小塊中，如果行程失敗，則在檔案較小的部分重試操作的情況下，我們也會受益， 如果未上傳檔案，則僅重試失敗的塊，

客戶端和云存盤之間較少的資料傳輸量將幫助我們獲得更好的回應時間，不用發送整個檔案，我們只需要發送檔案的修改后的塊，

圖：僅傳輸更新的塊

在這種情況下，檔案的更新部分將被傳輸，我們將把檔案分成2MB的塊，并僅傳輸檔案的修改部分，如下圖所示，
從上圖可以看到，我們沒有更新整個10 MB的檔案，而是更新了檔案的修改后的2MB部分，它將為用戶減少帶寬消耗和云存盤，最重要的是，回應時間將更快，

客戶端離線時會發生什么？

客戶端組件Watcher將觀察客戶端檔案夾，如果用戶發生任何更改，它將通知索引控制器（Index Controller，另一個客戶端組件）有關用戶操作的資訊，它還將監視其他客戶端（設備）是否發生任何更改，這些更改由Notification Server廣播，

當元資料服務收到更新/上傳請求時，它需要檢查元資料資料庫的一致性，然后繼續進行更新， 之后，將向所有訂閱的設備發送通知以報告檔案更新，

元資料資料庫：

我們需要一個負責保存有關檔案，用戶等資訊的資料庫，它可以是關系資料庫，例如MySQL或NoSQL，例如MongoDB，我們需要將資料塊，檔案，用戶資訊等保存在資料庫中，

眾所周知， 我們必須在兩種型別的資料庫（SQL或NoSQL）之間進行選擇，無論我們選擇什么，我們都需要確保資料的一致性，

使用SQL資料庫可以為我們提供同步實作的好處，因為它們支持ACID屬性，

NoSQL資料庫不支持ACID屬性，但是它們提供了對可伸縮性和性能的支持，因此，我們需要在Metadata Server的邏輯中以編程方式為此類資料庫提供對ACID屬性的支持，

同步：
現在，客戶端從設備更新檔案，需要有一個組件來處理更新并將更改應用到其他設備，它需要同步客戶端的本地資料庫和遠程元資料資料庫，MetaData服務器可以執行這項作業來管理元資料并同步用戶的檔案，

訊息佇列：
現在考慮一下；如此大量的用戶正在同時上傳檔案，服務器如何處理如此大量的請求，為了能夠處理如此大量的請求，我們可能在客戶端和服務器之間使用訊息佇列，

圖：訊息傳遞佇列提供可伸縮的請求排隊和更改通知，以使用pull或push策略支持大量客戶端，

當目標程式忙或未連接時，訊息佇列提供臨時訊息存盤，它提供了異步通信協議，它 是一種將訊息放入佇列并且不需要立即回應即可繼續處理的系統，RabbitMQ，Apache Kafka等是訊息傳遞佇列的一些示例，

如果是訊息佇列，則一旦客戶端接收到訊息，就會從佇列中洗掉訊息，因此，我們需要為客戶端的每個訂閱的設備創建幾個回應佇列，

圖：每種設備型別的回應訊息佇列

對于大量用戶，我們需要一個可伸縮的訊息佇列，該佇列支持客戶端和同步服務之間基于異步訊息的通信，該服務應該能夠在高度可用，可靠和可伸縮的佇列中有效地存盤任意數量的訊息，例如：apache Kafka，rabbitMQ等，

云儲存：

如今，有許多平臺和作業系統，例如智能手機，筆記本電腦，個人計算機等，它們可隨時隨地提供移動訪問，

如果您將檔案保存在筆記本電腦的本地存盤中，并且出門在外但想在手機上使用它，那么如何獲取資料？這就是為什么我們需要云存盤作為解決方案，

它存盤用戶上傳的檔案（塊），客戶端可以通過檔案處理服務器與存盤進行互動，以從存盤發送和接收物件，它只保存檔案；元資料DB保留塊大小和檔案編號的資料，

檔案處理作業流程：

客戶端A將塊上傳到云存盤，客戶端A使用元資料服務器更新元資料并提交對MetadataDB的更改，客戶端得到確認，并將通知發送到同一用戶的其他設備，其他設備接收元資料更改并從云存盤下載更新的塊，

圖：客戶端A的檔案處理作業流程

★可擴展性

我們需要對元資料資料庫進行磁區，以便可以存盤約100萬用戶和數十億個檔案/塊的資訊，我們可以對資料進行磁區，以在服務器上分配讀寫請求，

元資料磁區：

1. 我們可以基于檔案路徑的首字母將檔案塊存盤在磁區中，例如，我們將所有以字母“ A”開頭的檔案保留在一個磁區中，并將所有以字母“ B”開頭的檔案保留在另一個磁區中，依此類推，這稱為基于范圍的磁區，不太頻繁出現的字母（例如“ Z”或“ Y”），我們可以將它們組合成一個磁區，
   主要問題是，某些字母在首字母的情況下很常見，例如，如果我們將所有以字母“ A”開頭的檔案放入一個資料庫磁區中，而我們有太多以字母“ A”開頭的檔案，那么我們就無法將它們放入一個資料庫磁區中，
2. 我們也可以基于檔案’fileId’的哈希值進行磁區，我們的哈希函式將隨機生成一個服務器號，并將檔案存盤在該服務器中， 但是我們可能需要要求所有服務器找到串列，然后將它們合并在一起以得到結果，因此，回應時間延遲可能會增加，
   如果我們使用這種方法，它仍然會導致磁區過載，這可以通過使用“一致性哈希”來解決，

快取：

眾所周知，快取是提高性能的常用技術，這對于降低延遲非常有幫助，服務器可以在訪問資料庫之前檢查快取服務器，以查看搜索串列是否已在快取中，我們不能將所有資料都保存在快取中，

當快取已滿時，我們需要用一個更新的塊替換一個塊，Least Recently Used（LRU）可以用于此系統，在這種方法中，首先從高速快取中洗掉最近最少使用的塊，

★安全性：

在檔案共享服務中，用戶資料的私密性和安全性至關重要，為了解決這個問題，我們可以將每個檔案的權限存盤在元資料資料庫中，哪些檔案可由哪個用戶查看或修改，

★客戶端：

客戶端應用程式（Web或移動設備）傳輸用戶上傳到云存盤中的所有檔案，該應用程式將上傳，下載或修改檔案到云存盤，客戶端可以更新元資料，例如重命名檔案名，編輯檔案等，

客戶端應用程式功能包括上傳，下載檔案，如上所述，我們將每個檔案分成2MB的較小塊，以便僅傳輸修改后的塊，而不傳輸整個檔案，

如果由于用戶的離線狀態而引起任何沖突，則應用需要對其進行處理，現在，我們可以在客戶端保留元資料的本地副本，以使我們能夠進行脫機更新，

客戶端應用程式需要檢測客戶端檔案夾中的檔案是否已更改，我們可能有一個組件Watcher，它將檢查客戶端是否發生任何檔案更改，

★客戶如何知道云存盤已完成更改？

客戶端可以定期與服務器核對是否有任何更改，這是一項手動策略，但是，如果客戶端經常檢查服務器的更改，則會給服務器帶來壓力，使服務器繁忙，

我們可以使用HTTP 長時間輪詢 技術， 在這種技術中，服務器不會立即回應客戶端請求，服務器不發送空回應，而是使請求保持打開狀態， 一旦準備好新資訊，服務器就會向客戶端發送回應，

圖：客戶端應用程式向元資料服務器請求更新元資料資訊

我們可以將客戶端應用程式分為以下幾部分：

1. 本地資料庫將跟蹤客戶端系統中的所有檔案，塊，目錄路徑等，
2. 塊控制器會將檔案分割成較小的部分，它還將負責從其塊中重建整個檔案，這部分將有助于確定檔案的最新修改塊，而且僅將檔案的已修改塊發送到服務器，這將節省帶寬和服務器計算時間，
3. 守望者會觀察客戶端檔案夾，如果用戶發生任何變化，它會通知索引控制器對用戶的作用，它還將監視由同步服務廣播的其他客戶端（設備）上是否發生了任何更改，
4. 索引控制器將處理從觀察程式收到的事件，并更新有關已修改檔案塊資訊的本地資料庫，它將與元資料服務通信，以將更改傳送到其他設備并更新元資料資料庫，該請求將通過訊息請求佇列發送到元資料服務，
   下面是系統的完整圖：
   

圖：Google驅動器的系統設計

★結論：

在此系統中，我們未考慮UI部分，系統中也未考慮更新和脫機編輯的歷史記錄，移動客戶端可以按需同步以節省用戶的帶寬和空間，在這里，我們沒有使用其他服務器進行同步，元資料服務器正在執行該任務，

我們決定將檔案分成較小的塊，以節省存盤空間，帶寬使用并減少延遲， 我們添加了Loadbalancer，以在后端服務器之間平均分配傳入請求，如果服務器停止作業了，則LB將停止向其發送任何請求，

在云架構中，用戶資料的隱私和安全性至關重要，我們可以將每個檔案的權限存盤在元資料資料庫中，以檢查哪些檔案對哪個用戶可見或可以修改，

參見原文.

Charles @ Shenzhen,

2020-sep-23