數據通常被視為解決方案中最有價值的部分，因為它代表您和您的客戶的寶貴商務資訊。 因此，請務必仔細管理您的數據。 規劃多租使用者系統的記憶體或數據元件時，您必須決定共用或隔離租用戶數據的方法。
在本文中，我們會提供在決定在多租用戶系統中儲存數據的方法時，解決方案架構設計人員不可或缺的重要考慮和需求指引。 然後，建議您使用一些常見的模式，將多租使用者套用至記憶體和數據服務，以及一些可避免的反模式。 最後，我們會針對某些特定情況提供針對性指引。
重要考量與需求
請務必從許多觀點考慮您用於記憶體和數據服務的方法，包括 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。
當您使用數據列層級安全性時，您必須確保使用者的身分識別和租使用者身分識別會透過應用程式傳播，並使用每個查詢進入數據存放區。 這種方法在設計、實作、測試和維護方面可能十分複雜。 由於這些複雜度，許多多租用戶解決方案不會使用數據列層級安全性。
可能需要租用戶層級加密 ，以支援為其數據提供自己加密密鑰的租使用者。 這項功能可在 Azure SQL 中作為 Always Encrypted 的一部分使用。 Azure Cosmos DB 會在帳戶層級提供客戶自控密鑰，也支援 Always Encrypted。
資源分享 可讓您在多個資料庫或容器之間共用資源和成本。 這項功能適用於 Azure SQL 的 彈性集 區和 受控實例 ，以及 Azure Cosmos DB 資料庫輸送量，不過每個選項都有您應該注意的限制。
分區化和數據分割 在某些服務中具有比其他服務更強大的原生支援。 此功能可在 Azure Cosmos DB 中使用其 邏輯和實體分割。 雖然 Azure SQL 原生不支援分區化，但它會提供 分區化工具來 支援這種類型的架構。
此外，當您使用關係資料庫或其他架構型資料庫時，請考慮當您維護資料庫群時，應該觸發架構升級程式的位置。 在小型資料庫中，您可能會考慮使用部署管線來部署架構變更。 當資料庫數目增加時，應用層可能會更適合偵測特定資料庫的架構版本，以及起始升級程式。
檔案和 Blob 記憶體
請考慮您用來隔離記憶體帳戶內數據的方法。 例如，您可以為每個租使用者部署個別的記憶體帳戶，也可以共用記憶體帳戶並部署個別的容器。 或者，您可以建立共用 Blob 容器，然後使用 Blob 路徑來分隔每個租用戶的數據。 請考慮 Azure 訂用帳戶限制和配額，並仔細規劃您的成長，以確保您的 Azure 資源可調整規模以支援您未來的需求。
如果您使用共用容器，請仔細規劃您的驗證和授權策略，以確保租用戶無法存取彼此的數據。 當您提供用戶端存取 Azure 儲存體 資源時，請考慮代客密鑰模式。
成本配置
請考慮如何 測量耗用量，並將成本配置給租使用者，以使用共用數據服務。 盡可能使用內建計量，而不是計算您自己的計量。 不過，使用共用基礎結構時，很難分割個別租用戶的遙測，您可能需要考慮應用層級自定義計量。
一般而言，雲端原生服務，例如 Azure Cosmos DB 和 Azure Blob 儲存體，提供更細微的計量來追蹤和建立特定租使用者的使用量模型。 例如，Azure Cosmos DB 會針對每個要求和回應提供已取用的輸送量。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主要作者：
- John Downs | 主任軟體工程師
其他投稿人：
- Paul Burpo | 主任客戶工程師，FastTrack for Azure
- Daniel Scott-Raynsford | 合作夥伴技術策略師
- Arsen Vladimirskiy | 主任客戶工程師，FastTrack for Azure
若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。
下一步
如需多租使用者和特定 Azure 服務的詳細資訊，請參閱：