資料通常被視為解決方案中最有價值的部分，因為它代表您和您的客戶的寶貴商務資訊。 因此，請務必仔細管理您的資料。 規劃多租使用者系統的儲存體或資料元件時，您必須決定共用或隔離租使用者資料的方法。
在本文中，我們會提供在決定在多租使用者系統中儲存資料的方法時，解決方案架構設計人員不可或缺的重要考慮和需求指引。 然後，建議您使用一些常見的模式，將多租使用者套用至儲存體和資料服務，以及一些可避免的反模式。 最後，我們會針對某些特定情況提供針對性指引。
重要考慮和需求
請務必從許多觀點考慮您用於儲存體和資料服務的方法，這大致符合 Azure 良好架構 架構的 要素。
縮放規模
當您使用儲存資料的服務時，您應該考慮您擁有的租使用者數目，以及您儲存的資料量。 如果您有少量的租使用者（例如五個或更少），而且您要為每個租使用者儲存少量的資料，則規劃高度可調整的資料儲存方法，或建立完全自動化的方法來管理您的資料資源，可能是浪費精力。 但是，隨著您成長，您越來越受益于有一個明確的策略來調整您的資料和儲存體資源，以及將自動化套用至其管理。 當您有 50 個租使用者或更多租使用者，或打算達到該規模層級時，設計資料與儲存體方法特別重要，並調整為重要考慮。
請考慮您打算調整的範圍，並清楚規劃資料儲存體架構方法，以符合該級別層級。
效能可預測性
多租使用者資料和儲存體服務特別容易受到 Noisy 芳鄰問題的影響 。 請務必考慮您的租使用者是否可能會影響彼此的效能。 例如，您的租使用者在一段時間內的使用模式中是否有重迭的尖峰？ 您的所有客戶每天都會同時使用您的解決方案，還是平均散發要求？ 這些因素會影響您需要設計的隔離等級、布建所需的資源數量，以及可在租使用者之間共用資源的程度。
請務必將 Azure 的資源和要求配額 視為此決策的一部分。 例如，假設您部署單一儲存體帳戶來包含您所有租使用者的資料。 如果您超過每秒特定數量的儲存體作業，Azure 儲存體將會拒絕應用程式的要求，而且所有租使用者都會受到影響。 這稱為 節流 行為。 請務必監視節流要求。 如需詳細資訊，請參閱 Azure 服務的 重試指引。
資料隔離
設計包含多租使用者資料服務的解決方案時，通常會有不同的選項和資料隔離層級，每個解決方案都有各自的優點和取捨。 例如：
- 使用 Azure Cosmos DB 時，您可以為每個租使用者部署個別的容器，而且您可以在多個租使用者之間共用資料庫和帳戶。 或者，您可以根據所需的隔離等級，考慮為每個租使用者部署不同的資料庫，甚至是帳戶。
- 針對 Blob 資料使用Azure 儲存體時，您可以為每個租使用者部署個別的 Blob 容器，也可以部署個別的儲存體帳戶。
- 使用 Azure SQL 時，您可以在共用資料庫中使用不同的資料表，也可以為每個租使用者部署個別的資料庫或伺服器。
- 在所有 Azure 服務中，您可以考慮在單一共用 Azure 訂用帳戶內部署資源，也可以使用多個 Azure 訂用帳戶，甚至每個租使用者一個。
沒有適用于所有情況的單一解決方案。 您選擇的選項取決於您的一些因素和租使用者的需求。 例如，如果您的租使用者需要符合特定合規性或法規標準，您可能需要套用較高層級的隔離。 同樣地，您可能有實際隔離客戶資料的商業需求，或者您可能需要強制執行隔離以避免 Noisy Neighbor 問題 。 此外，如果租使用者需要使用自己的加密金鑰，他們具有個別的備份和還原原則，或需要將資料儲存在不同的地理位置，您可能需要將它們與其他租使用者隔離，或將它們與具有類似原則的租使用者分組。
實作的複雜度
請務必考慮實作的複雜性。 最好盡可能讓架構保持簡單，同時仍符合您的需求。 避免認可隨著規模調整而變得越來越複雜的架構，或您沒有開發和維護資源或專業知識的架構。
同樣地，如果您的解決方案不需要調整為大量的租使用者，或您對於效能或資料隔離沒有顧慮，則最好保持解決方案簡單，並避免增加不必要的複雜度。
多租使用者資料解決方案的一個特別考慮是您支援的自訂層級。 例如，租使用者可以擴充您的資料模型或套用自訂資料規則嗎？ 請確定您事先針對此需求進行設計。 避免為個別租使用者提供分叉或提供自訂基礎結構。 自訂基礎結構會抑制調整、測試解決方案，以及部署更新的能力。 相反地，請考慮使用 功能旗標 和其他形式的租使用者設定。
管理和作業的複雜性
請考慮您打算如何操作解決方案，以及您的多租使用者方法如何影響您的作業和程式。 例如：
- 管理： 請考慮跨租使用者管理作業，例如定期維護活動。 如果您使用多個帳戶、伺服器或資料庫，您要如何起始和監視每個租使用者的作業？
- 監視和計量： 如果您監視或計量租使用者，請考慮您的解決方案如何報告計量，以及它們是否可以輕易地連結到觸發要求的租使用者。
- 報告： 報告來自隔離租使用者的資料可能需要每個租使用者將資料發佈至集中式資料倉儲，而不是個別執行每個資料庫的查詢，然後匯總結果。
- 架構更新： 如果您使用強制執行架構的資料庫，請規劃如何在資產中部署架構更新。 請考慮您的應用程式如何知道要用於特定租使用者資料庫查詢的架構版本。
- 需求： 請考慮租使用者的高可用性需求（例如執行時間服務等級協定或 SLA）和災害復原需求（例如復原時間目標或 RTO，以及復原點目標或 RPO）。 如果租使用者有不同的期望，您是否能夠符合每個租使用者的需求？
- 移轉： 如果您需要移至不同類型的服務、不同的部署或其他區域，您要如何移轉租使用者？
成本
一般而言，租使用者對部署基礎結構的密度越高，布建該基礎結構的成本就越低。 不過，共用基礎結構會增加像 Noisy Neighbor 問題這類 問題 的可能性，因此請仔細考慮取捨。
要考慮的方法和模式
來自 Azure 架構中心的數個設計模式與多租使用者儲存體和資料服務相關。 您可以選擇一致地遵循一個模式。 或者，您可以考慮混合和比對模式。 例如，您可能會針對大部分租使用者使用多租使用者資料庫，但為支付更多費用或有不同需求之租使用者的租使用者部署單一租使用者戳記。 同樣地，使用部署戳記來調整通常是很好的做法，即使您在戳記內使用多租使用者資料庫或分區化資料庫也一樣。
部署戳記模式
如需如何使用 部署戳記模式 來支援多租使用者解決方案的詳細資訊，請參閱 概觀 。
共用多租使用者資料庫和檔案存放區
您可以考慮部署共用多租使用者資料庫、儲存體帳戶或檔案共用，並在所有租使用者之間共用。
此方法提供基礎結構的租使用者密度最高，因此通常會以任何方法的最低成本來提供。 它也會降低管理額外負荷，因為有單一資料庫或資源可管理、備份及保護。
不過，當您使用共用基礎結構時，有幾個注意事項需要考慮：
- 調整限制： 當您依賴單一資源時，請考慮該資源支援的縮放比例和限制。 例如，如果您的架構依賴單一資料庫，則一個資料庫或檔案存放區的大小上限或最大輸送量限制最終會變成硬式封鎖程式。 在選取此模式之前，請仔細考慮您需要達到的最大規模，並將其與目前和未來的限制進行比較。
- 嘈雜的鄰居： Noisy 芳鄰問題 可能會成為一個因素，特別是如果您有特別忙碌或產生比其他人更高的工作負載的租使用者。 請考慮套用 節流模式 或 速率限制模式 來減輕這些影響。
- 監視每個租使用者： 您可能難以監視活動，並 測量單一租使用者的耗用量 。 某些服務，例如 Azure Cosmos DB，會針對每個要求提供資源使用量的報告，因此可以追蹤此資訊來測量每個租使用者的耗用量。 其他服務不提供相同層級的詳細資料。 例如，檔案容量的Azure 檔案儲存體計量僅適用于每個檔案共用維度，只有在您使用進階共用時。 不過，標準層只會在儲存體帳戶層級提供計量。
- 租使用者需求： 租使用者對於安全性、備份、可用性或儲存體位置可能有不同的需求。 如果這些不符合單一資源的組態，您可能無法容納它們。
- 架構自訂： 當您使用關係資料庫，或資料架構很重要的另一種情況時，租使用者層級架構自訂會很困難。
分區化模式
分區化模式 牽涉到部署多個稱為 分區 的個別資料庫，每個資料庫都包含一或多個租使用者的資料。 不同于部署戳記，分區並不表示整個基礎結構重複。 您可以分區資料庫，而不用在解決方案中複製或分區化其他基礎結構。
分區化與資料分割 密切相關 ，而且詞彙通常會交替使用。 請考慮水準、垂直和功能性資料分割指引 。
分區化模式可以調整為非常大量的租使用者。 此外，視您的工作負載而定，您可能能夠達到分區的高密度租使用者，因此成本可能很有吸引力。 分區化模式也可用來解決 Azure 訂用帳戶和服務配額、限制和服務限制 。
某些資料存放區，例如 Azure Cosmos DB，提供分區化或分割的原生支援。 當您使用 Azure SQL 等其他解決方案時，針對指定的租使用者，建置分區化基礎結構並將要求路由傳送至正確的分區可能更為複雜。
分區化也使得難以支援租使用者層級的組態差異，並讓客戶提供自己的加密金鑰。
具有每個租使用者專用資料庫的多租使用者應用程式
另一個常見的方法是部署單一多租使用者應用程式，每個租使用者都有專用的資料庫。
在此模型中，每個租使用者的資料會與其他租使用者隔離，而且您可以支援每個租使用者的某種程度的自訂。
因為您為每個租使用者布建專用的資料資源，因此這種方法的成本可能高於共用主控模型。 不過，Azure 提供數個選項供您考慮，以共用跨多個租使用者裝載個別資料資源的成本。 例如，當您使用 Azure SQL 時，可以考慮 彈性集區 。 針對 Azure Cosmos DB，您可以 布建資料庫的 輸送量，而且輸送量會在該資料庫中的容器之間共用，不過當您需要保證每個容器的效能時，此方法並不適用。
在此方法中，因為只有資料元件會針對每個租使用者個別部署，因此您可能會為解決方案中的其他元件達到高密度，並降低這些元件的成本。
當您為每個租使用者布建資料庫時，請務必使用自動化部署方法。
地理區域模式
Geode 模式 專為地理位置分散的解決方案所設計，包括多租使用者解決方案。 它支援高負載和高層級的復原能力。 如果您實作 Geode 模式，資料層必須能夠跨地理區域複寫資料，而且應該支援多地理位置寫入。
Azure Cosmos DB 提供 多宿主寫入 來支援此模式，而 Cassandra 支援多重區域叢集。 其他資料服務通常無法支援此模式，而不需要大量自訂。
要避免的反模式
當您建立多租使用者資料服務時，請務必避免阻礙調整能力的情況。
對於關係資料庫，這些包括：
- 資料表型隔離。 當您在單一資料庫內工作時，請避免為每個租使用者建立個別資料表。 當您使用此方法時，單一資料庫將無法支援非常大量的租使用者，而且查詢、管理和更新資料變得越來越困難。 相反地，請考慮使用一組具有租使用者識別碼資料行的多租使用者資料表。 或者，您可以使用上述其中一種模式，為每個租使用者部署個別的資料庫。
- 資料行層級租使用者自訂。 避免套用僅套用至單一租使用者的架構更新。 例如，假設您有單一多租使用者資料庫。 請避免新增資料行以符合特定租使用者的需求。 少數自訂專案可能可以接受，但當您有大量自訂專案需要考慮時，這很快就會變得無法管理。 相反地，請考慮修改您的資料模型，以追蹤專用資料表中每個租使用者的自訂資料。
- 手動變更架構。 請避免手動更新資料庫架構，即使您只有單一共用資料庫也一樣。 很容易無法追蹤您已套用的更新，而且如果您需要向外延展至更多資料庫，則很難識別要套用的正確架構。 相反地，請建置自動化管線來部署架構變更，並一致地使用它。 追蹤專用資料庫或查閱表格中每個租使用者的架構版本。
- 版本相依性。 避免讓應用程式相依于單一版本的資料庫架構。 當您調整規模時，可能需要在不同的時間為不同的租使用者套用架構更新。 相反地，請確定您的應用程式版本與至少一個架構版本回溯相容，並避免破壞性的架構更新。
資料庫
有一些功能可用於多租使用者。 不過，這些不適用於所有資料庫服務。 當您決定要用於案例的服務時，請考慮您是否需要這些專案：
- 資料列層級安全性 可為共用多租使用者資料庫中的特定租使用者資料提供安全性隔離。 此功能可在 Azure SQL 和 Postgres Flex 中使用，但不適用於 MySQL 或 Azure Cosmos DB 等其他資料庫。
- 可能需要租使用者層級加密 ，以支援為其資料提供自己加密金鑰的租使用者。 這項功能可在 Azure SQL 中作為 Always Encrypted 的 一部分使用。 Azure Cosmos DB 會在帳戶層級提供 客戶自控金鑰，也 支援 Always Encrypted 。
- 資源分享 可讓您在多個資料庫或容器之間共用資源和成本。 這項功能適用于 Azure SQL 的 彈性集 區和 受控實例 ，以及 Azure Cosmos DB 資料庫輸送量 ，不過每個選項都有您應該注意的限制。
- 分區化和資料分割 在某些服務中具有比其他服務更強大的原生支援。 此功能可在 Azure Cosmos DB 中使用其 邏輯和實體分割 ，以及在 PostgreSQL 超大規模 資料庫中取得。 雖然 Azure SQL 原生不支援分區化，但它會提供 分區化工具來 支援這種類型的架構。
此外，當您使用關係資料庫或其他架構型資料庫時，請考慮當您維護資料庫群時，應該觸發架構升級程式的位置。 在小型資料庫中，您可能會考慮使用部署管線來部署架構變更。 隨著您成長，應用層可能會更適合偵測特定資料庫的架構版本，並起始升級程式。
檔案和 Blob 儲存體
請考慮您用來隔離儲存體帳戶內資料的方法。 例如，您可以為每個租使用者部署個別的儲存體帳戶，也可以共用儲存體帳戶並部署個別的容器。 或者，您可以建立共用 Blob 容器，然後使用 Blob 路徑來分隔每個租使用者的資料。 請考慮 Azure 訂用帳戶限制和配額 ，並仔細規劃您的成長，以確保您的 Azure 資源可調整規模以支援您未來的需求。
如果您使用共用容器，請仔細規劃您的驗證和授權策略，以確保租使用者無法存取彼此的資料。 當您提供用戶端存取Azure 儲存體資源時，請考慮代客金鑰模式 。
成本配置
請考慮如何 測量耗用量，並將成本配置給租使用者 ，以使用共用資料服務。 盡可能使用內建計量，而不是計算您自己的計量。 不過，使用共用基礎結構時，很難分割個別租使用者的遙測，而您應該考慮應用層級自訂計量。
一般而言，雲端原生服務，例如 Azure Cosmos DB 和 Azure Blob 儲存體，提供更細微的計量來追蹤和建立特定租使用者的使用量模型。 例如，Azure Cosmos DB 會針對每個要求和回應提供已取用的輸送量。
投稿人
本文由 Microsoft 維護。 原始投稿人如下。
主體作者：
- John Downs |適用于 Azure 的主要客戶工程師 FastTrack
其他投稿人：
- 保羅·伯波 |適用于 Azure 的主要客戶工程師 FastTrack
- 丹尼爾·斯科特-倫斯福德 |合作夥伴技術策略師
- 阿森·弗拉基米爾斯基 | 適用于 Azure 的主要客戶工程師 FastTrack
若要查看非公用LinkedIn設定檔，請登入 LinkedIn。
下一步
如需多租使用者和特定 Azure 服務的詳細資訊，請參閱：