有許多方式可以考慮如何在解決方案中使用租使用者。 您所選擇的方法取決於您是否和如何在租用戶之間共享資源。 以直覺方式，您可能會想要避免共用 任何 資源，但隨著企業規模調整，這種方法會很快變得昂貴，而且您讓更多租用戶上線。
當您考慮多租用戶的各種模型時，先考慮如何為組織定義租使用者、您的業務驅動因素，以及如何規劃調整解決方案，這很有説明。 本文提供指引，協助技術決策者評估租用模型及其取捨。
定義租使用者
首先，您必須為組織定義 租 使用者。 請考慮您的客戶是誰。 換句話說，您要向誰提供服務？ 有兩種常見的模型：
- 企業對企業（B2B）。 如果您的客戶是其他組織，您可能會將租用戶對應至那些客戶。 不過，請考慮您的客戶是否有部門（小組或部門），以及他們是否在多個國家/地區中存在。 如果這些子群組有不同的需求，您可能需要將單一客戶對應至多個租使用者。 同樣地，客戶可能想要維護您服務的兩個實例，讓其開發和生產環境彼此分開。 一般而言，單一租使用者有多個使用者。 例如，客戶的所有員工都是單一租使用者內的使用者。
- 企業對消費者（B2C）。 若客戶是取用者，建立客戶、租用戶和使用者間的關聯通常會比較複雜。 在某些情況下，每個取用者可能是個別的租使用者。 不過，請考慮您的解決方案是否可供家庭、朋友群組、俱樂部、協會或其他可能需要一起存取和管理其數據群組使用。 例如，音樂串流服務可能同時支援個別使用者和家庭，而且當音樂串流服務將它們分成租使用者時，可能會以不同的方式處理這些帳戶類型。
您的租用戶定義會影響您在建構解決方案時需要考慮或強調的一些事項。 例如，請考慮下列類型的租使用者：
- 如果您的租用戶是個別人員或家庭，您可能需要特別關心如何處理個人資料，以及您服務的每個司法管轄區內關於數據主權法的資訊。
- 如果您的租用戶是企業，您可能需要留意客戶的法規合規性需求、其數據的隔離，並確保您符合指定的服務等級目標（SLO），例如運行時間或服務可用性。
如何決定要使用的模型？
選取租用模型不只是技術決策。 這也是一個商業決定。 您需要考慮如下的問題：
- 您的商務目標為何？
- 您的客戶會接受所有形式的多租使用者嗎？ 每個多租使用者模型如何影響您的合規性需求，或客戶的合規性需求？
- 單一租用戶解決方案是否會調整到您未來的成長願望？
- 您的營運小組有多大，以及您可以自動化多少基礎結構管理？
- 您的客戶期望您符合服務等級協定 （SLA），或您有您想要的 SLO 嗎？
如果您預期企業能夠擴充至大量客戶，請務必部署共用基礎結構。 否則，您必須維護大量且成長的資源實例。 除非您為每個租使用者布建和使用專用訂用帳戶，否則為每個客戶部署個別的 Azure 資源可能不可持續。 當您跨多個租用戶共用相同的 Azure 訂用帳戶時， Azure 資源配額和限制 可能會開始套用，而且部署和重新設定這些資源的營運成本會隨著每個新客戶增加。
相反地，如果您預期企業只有少數客戶，您可能想要考慮使用每個客戶專用的單一租用戶資源。 此外，如果您的客戶的隔離需求很高，即使成本更高，單一租使用者基礎結構方法可能很合適。
租使用者和部署
接下來，您必須判斷特定解決方案的租用戶意義，以及是否應該區分邏輯租使用者和部署。
例如，請考慮音樂串流服務。 一開始，您可以建置一個解決方案，輕鬆處理數千位（甚至數萬個）使用者。 不過，隨著您持續成長，您可能會發現您需要複製解決方案或其部分元件，才能調整為新的客戶需求。 這表示您必須判斷如何將特定客戶指派給解決方案的特定實例。 您可以隨機或異地指派客戶，或填滿單一實例，然後啟動另一個 （bin 封裝）。 不過，您可能需要維護客戶的記錄，以及其數據和應用程式的可用基礎結構，以便您將流量路由傳送至正確的基礎結構。 在此範例中，您可以將每個客戶表示為個別租用戶，然後將用戶對應至包含其數據的部署。 租使用者與部署之間有一對多對應，而且您可以自行自行在部署之間移動租使用者。
相反地，請考慮為法律公司建立雲端軟體的公司。 您的客戶可能會堅持有自己的專用基礎結構來維護其合規性標準。 因此，您必須準備好從頭開始部署和管理解決方案的許多不同實例。 在此範例中，部署一律包含單一租使用者，而租用戶會對應至自己的專用部署。
租使用者和部署之間的主要差異在於如何強制執行隔離。 當多個租使用者共用單一部署（一組基礎結構）時，您通常會依賴應用程式程式代碼和資料庫中的租使用者標識碼，以將每個租用戶的數據分開。 當您擁有具有自己的專用部署的租使用者時，其具有自己的基礎結構，因此您的程式代碼可能不太重要，因為它會在多租用戶環境中運作。
部署有時稱為 超租使用者 或 戳記。
當您收到特定租使用者的要求時，您必須將它對應至保留該租用戶數據的部署，如下所示：
若要深入瞭解，請參閱 將要求對應至租使用者。
租用戶隔離
設計多租用戶結構時，其中一大考量是每個租用戶所需的隔離等級。 隔離可能表示不同的事項：
- 擁有單一共享基礎結構，每個租使用者都有個別的應用程式實例和個別的資料庫。
- 共用一些常見的資源，但讓每個租使用者將其他資源分開。
- 在個別實體基礎結構上保留資料。 在雲端中，此設定可能需要每個租用戶的個別 Azure 資源。 在極端情況下，它甚至可能表示使用 專用主機來部署個別的實體基礎結構。
您應將隔離視為連續屬性，而非離散屬性。 您可以根據需求，比相同結構中的其他元件，以更隔離或更不隔離的方式部署結構元件。 下列圖表示範了隔離的連續性：
隔離等級會影響架構的許多層面，包括下列各項：
- 安全性。 如果您在多個租用戶之間共用基礎結構，當您將回應傳回給另一個租使用者時，必須特別小心不要從某個租使用者存取數據。 您需要身分識別策略的堅實基礎，而且您必須在授權程序中考慮租用戶和使用者身分識別。
- 成本。 多個租使用者可以使用共用基礎結構，因此成本較低。
- 效能： 如果您共用基礎結構，系統效能可能會因為更多客戶使用它而受到影響，因為資源可能耗用得更快。 效能問題可能會因使用模式異常的租用戶而加劇。
- 可靠性。 如果您使用單一共享基礎結構集，一個元件的問題可能會導致所有租用戶中斷。
- 回應個別租使用者需求。 當您部署專用於一個租用戶的基礎結構時，您可能能夠將資源的設定調整為該特定租使用者的需求。 您甚至可以在定價模型中考慮這項功能，讓客戶為隔離部署支付更多費用。
您的解決方案架構可能會影響您可用的隔離選項。 例如，請考慮三層式解決方案架構：
- 您的使用者介面層可能是共用多租使用者 Web 應用程式，且所有租使用者都存取單一主機名。
- 您的中介層可以是共用應用層，其中包含共用消息佇列。
- 您的數據層可以是隔離的資料庫、數據表或 Blob 容器。
您可以考慮在每個層級上使用不同等級的隔離。 您應該根據許多考慮來決定共用的內容和隔離專案，包括成本、複雜度、客戶的需求，以及可在達到 Azure 配額和限制之前部署的資源數目。
常見的租用模型
建立需求之後，請針對一些常見的租用模型和對應的部署模式進行評估。
自動化單一租使用者部署
在自動化的單一租使用者部署模型中，您會為每個租使用者部署一組專用的基礎結構，如下列範例所示：
您的應用程式負責起始和協調每個租用戶資源的部署。 一般而言，使用此模型的解決方案會使用基礎結構即程序代碼 （IaC） 或 Azure Resource Manager API。 當您需要為每個客戶布建完全獨立的基礎結構時，您可以使用此方法。 規劃部署時，請考慮使用 部署戳記模式 。
優點： 此方法的主要優點是隔離每個租用戶的數據，這可降低意外外泄的風險。 這項保護對於某些具有高法規合規性負擔的客戶而言非常重要。 此外，租使用者不太可能影響彼此的系統效能，有時稱為 嘈雜的鄰近 問題。 您可以逐步跨租使用者推出更新和變更，以降低整個系統中斷的可能性。
風險： 如果您使用這種方法，成本效益很低，因為您不會在租用戶之間共用基礎結構。 如果單一租使用者需要特定基礎結構成本，100 個租使用者可能需要 100 倍的成本。 此外，持續維護（例如套用新的設定或軟體更新）可能會很耗時。 請考慮將作業程式自動化，並考慮逐步透過環境套用變更。 您也應該考慮其他跨部署作業，例如整個車隊的報告和分析。 同樣地，請務必規劃如何跨多個部署查詢及操作數據。
完全多租使用者部署
相反的極端是，您可以考慮共用所有元件的完整多租使用者部署。 您只有一組基礎結構要部署和維護，而且所有租用戶都會使用它，如下圖所示：
優點： 此模型很有吸引力，因為操作具有共用元件的解決方案比針對每個租使用者使用個別資源便宜。 即使您需要部署較高層級的資源或 SKU 以考慮增加的負載，整體部署成本通常仍低於一組單一租用戶資源的成本。 此外，如果使用者或租使用者需要將其數據移至另一個租使用者，您或許可以更新租使用者標識碼和密鑰，而且您可能不需要在兩個不同的部署之間移轉數據。
風險：
請務必分隔每個租用戶的數據，且不會在租用戶之間洩漏數據。 您可能需要管理分區化數據。 此外，您可能需要關注個別租使用者對整體系統可能具有的影響。 例如，如果大型租用戶嘗試執行大量查詢或作業，它可能會影響其他租使用者。
如果這樣做對您很重要，請決定如何 追蹤 Azure 成本並將其與租用戶產生關聯。
單一部署的維護可能更簡單，因為您只需要更新一組資源。 不過，因為變更可能會影響整個客戶群，所以通常比較有風險。
您可能也需要考慮調整。 當您有一組共用的基礎結構時，更有可能達到 Azure 資源規模限制 。 例如，如果您使用記憶體帳戶做為解決方案的一部分，隨著規模增加，該儲存體帳戶的要求數目可能會達到記憶體帳戶可以處理的限制。 若要避免達到資源配額限制，您可以考慮部署多個資源的實例集區（例如多個 AKS 叢集或記憶體帳戶）。 您甚至可以考慮將租使用者分散到部署至多個 Azure 訂用帳戶的資源。
您可能會限制您可以調整單一部署的距離，而這樣做的成本可能會以非線性方式增加。 例如，如果您有單一共享資料庫，當您以非常高的規模執行時，可能會耗盡其輸送量，而且需要為增加的輸送量支付更多費用，以跟上您的需求。
垂直分割的部署
您不需要選擇這些縮放比例的其中一個極端。 相反地，您可以採用這種方法來考慮垂直分割租使用者：
- 使用單一租使用者和多租使用者部署的組合。 例如，您可能在多租使用者基礎結構上擁有大部分客戶的數據和應用層，但針對需要較高效能或數據隔離的客戶部署單一租使用者基礎結構。
- 在地理位置部署解決方案的多個實例，並將每個租用戶對應至特定部署。 當您在不同地理位置有租使用者時，這種方法特別有效。
以下範例說明某些租用戶的共用部署，以及另一個租使用者的單一租使用者部署：
優點： 因為您仍在共用一些基礎結構，因此您可以使用共用多租使用者部署來獲得一些成本效益。 您可以為特定客戶部署更便宜的共享資源，例如使用試用版評估服務的客戶。 您甚至可以向客戶收取較高的費率，以使用單一租使用者部署，以協助您復原部分成本。
風險： 您的程式代碼基底必須設計為同時支援多租使用者和單一租使用者部署。 如果您打算允許在部署之間移轉，則必須考慮如何將客戶從多租使用者部署移轉至自己的單一租使用者部署。 您也需要知道每個部署中有哪些租用戶，以便向相關客戶傳達系統問題或升級的相關資訊。
水準分割的部署
您也可以考慮水準分割部署。 在水準部署中，您有一些共享元件，但使用單一租使用者部署來維護其他元件。 例如，您可以建置單一應用層，然後為每個租使用者部署個別資料庫，如下圖所示：
優點： 水準分割的部署可協助您減輕嘈雜的鄰近問題：如果您識別系統上大部分負載是由特定元件所造成，則您可以為每個租使用者部署個別的元件。 例如，您的資料庫可能會吸收您系統的大部分負載，因為查詢負載很高。 如果單一租使用者將大量要求傳送至您的解決方案，資料庫效能可能會受到負面影響，但其他租用戶的資料庫（和應用程式層等共用元件）仍不會受到影響。
風險： 使用水準分割的部署，您仍然需要考慮元件的自動化部署和管理，特別是單一租使用者所使用的元件。
測試隔離模型
無論您選擇哪一個隔離模型，請務必測試您的解決方案，以確認一個租用戶的數據不會意外洩漏到另一個租使用者，而且任何 嘈雜的鄰近 影響都是可接受的。 請考慮使用 Azure Chaos Studio 來刻意引入模擬真實世界中斷的錯誤，並確認解決方案的復原能力，即使元件故障也一般。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主體作者：
- John Downs |首席軟體工程師
其他投稿人：
- 查德·基特爾 |首席軟體工程師
- Paolo Salvatori |適用於 Azure 的主要客戶工程師 FastTrack
- 阿森·弗拉基米爾斯基 | 適用於 Azure 的主要客戶工程師 FastTrack
若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。