多租使用者 SaaS 應用程式和 Azure AI 搜尋的設計模式
多租使用者應用程式是一個，可為任何無法查看或共用任何其他租用戶數據的租使用者提供相同的服務和功能。 本文討論使用 Azure AI 搜尋建置的多租使用者應用程式租用戶隔離策略。
Azure AI 搜尋概念
Azure AI 搜尋服務是搜尋即服務解決方案，可讓開發人員在不管理任何基礎結構或成為資訊擷取專家的情況下，將豐富的搜尋體驗新增至應用程式。 數據會上傳至服務，然後儲存在雲端中。 接著可以使用對 Azure AI 搜尋 API 的簡單要求來修改和搜尋數據。
搜尋服務、索引、欄位和檔
在討論設計模式之前，請務必瞭解一些基本概念。
使用 Azure AI 搜尋時，有一個 訂閱搜尋服務。 當數據上傳至 Azure AI 搜尋服務時，其會儲存在 搜尋服務內的索引 中。 單一服務內可以有數個索引。 若要使用熟悉的資料庫概念，搜尋服務可以比作資料庫，而服務內的索引可以比作資料庫內的數據表。
搜尋服務中的每個索引都有自己的架構，由許多可 自定義的欄位定義。 數據會以個別 檔的形式新增至 Azure AI 搜尋服務索引。 每個文件都必須上傳至特定索引，而且必須符合該索引的架構。 使用 Azure AI 搜尋來搜尋數據時，會針對特定索引發出全文搜索查詢。 若要比較這些概念與資料庫的概念，欄位可以比對數據表中的數據行，而檔可以比對數據列。
延展性
標準定價層中的任何 Azure AI 搜尋服務 都可以調整兩個維度：記憶體和可用性。
- 您可以新增數據 分割，以增加搜尋服務的儲存空間。
- 復本可以新增至服務，以增加搜尋服務可以處理的要求輸送量。
在 中新增和移除分割區和複本，可讓搜尋服務的容量隨著應用程式所需的數據和流量而成長。 為了讓搜尋服務達到讀取 SLA，它需要兩個複本。 為了讓服務達到讀寫 SLA，它需要三個複本。
Azure AI 搜尋中的服務和索引限制
Azure AI 搜尋中有一些不同的 定價層 ，每個層都有不同的 限制和配額。 其中有些限制位於服務層級，有些則位於索引層級，有些則位於數據分割層級。
S3 高密度
在 Azure AI 搜尋的 S3 定價層中，有專為多租使用者案例設計的高密度 （HD） 模式選項。 在許多情況下，必須在單一服務下支援大量較小的租使用者，以達到簡單和成本效益的優點。
S3 HD 允許將許多小型索引封裝在單一搜尋服務的管理之下，藉由交易使用分割區相應放大索引的能力，以在單一服務中裝載更多索引。
S3 服務的設計目的是裝載固定數目的索引（最大 200 個），並允許隨著新分割區新增至服務，以水準方式調整每個索引的大小。 將分割區新增至 S3 HD 服務會增加服務可裝載的索引數目上限。 個別 S3HD 索引的理想大小上限約為 50 - 80 GB，不過系統所強加的每個索引沒有硬式大小限制。
多租使用者應用程式的考慮
多租使用者應用程式必須在租用戶之間有效地分散資源，同時保留各種租用戶之間的某種層級隱私權。 設計這類應用程式的架構時，有幾個考慮：
租使用者隔離： 應用程式開發人員必須採取適當措施，以確保沒有租使用者未經授權或垃圾存取其他租用戶的數據。 除了數據隱私權的觀點之外，租用戶隔離策略還需要有效管理共享資源，並保護來自嘈雜的鄰居。
雲端資源成本： 如同任何其他應用程式，軟體解決方案必須保持成本競爭力，做為多租使用者應用程式的元件。
輕鬆操作： 開發多租用戶架構時，對應用程式作業和複雜度的影響是一個重要考慮。 Azure AI 搜尋服務具有 99.9% SLA。
全域使用量： 多租使用者應用程式通常需要為分散在世界各地的租使用者提供服務。
延展性： 應用程式開發人員需要考慮它們如何協調維護足夠低層級的應用程式複雜性，以及設計應用程式，以隨著租用戶數目和租用戶數據和工作負載的大小進行調整。
Azure AI 搜尋提供幾個界限，可用來隔離租用戶的數據和工作負載。
使用 Azure AI 搜尋將多租使用者模型化
在多租使用者案例的情況下，應用程式開發人員會取用一或多個搜尋服務，並在服務、索引或兩者之間分割其租使用者。 在模型化多租使用者案例時，Azure AI 搜尋有一些常見的模式：
每個租使用者一個索引： 每個租使用者在與其他租用戶共用的搜尋服務中都有自己的索引。
每個租使用者一個服務：每個租使用者都有自己的專用 Azure AI 搜尋服務，提供最高層級的數據和工作負載區隔。
兩者混合： 較大型、更主動的租用戶會獲指派專用服務，而較小的租使用者則會在共用服務內指派個別索引。
模型 1：每個租使用者一個索引
在每一租使用者的索引模型中，多個租用戶佔據單一 Azure AI 搜尋服務，其中每個租使用者都有自己的索引。
租用戶可達成數據隔離，因為所有搜尋要求和文件作業都會在 Azure AI 搜尋服務中的索引層級發出。 在應用層中，需要感知將各種租使用者的流量導向適當的索引，同時管理所有租用戶服務層級的資源。
每個租使用者模型的索引索引屬性是應用程式開發人員在應用程式租用戶之間過度訂閱搜尋服務的容量的能力。 如果租使用者工作負載分佈不平均，則租使用者的最佳組合可以分散到搜尋服務的索引，以容納許多高度作用中、資源密集的租用戶，同時為較不活躍的租使用者提供長尾。 取捨是模型無法處理每個租用戶同時高度主動的情況。
每個租使用者的索引模型提供可變成本模型的基礎，其中整個 Azure AI 搜尋服務 會預先購買，然後接著填入租使用者。 這允許針對試用版和免費帳戶指定未使用的容量。
對於具有全域使用量的應用程式，每個租使用者的索引模型可能不是最有效率的。 如果應用程式的租使用者分散在世界各地，則每個區域可能需要個別的服務，並複製每個區域的成本。
Azure AI 搜尋可讓您調整個別索引和要成長的索引總數。 如果選擇適當的定價層，當服務內的個別索引在記憶體或流量方面成長太大時，可以將分割區和複本新增至整個搜尋服務。
如果單一服務的索引總數增加太大，則必須布建另一個服務以容納新的租使用者。 如果索引必須在新增服務時在搜尋服務之間移動，則索引中的數據必須手動從一個索引複製到另一個索引，因為 Azure AI 搜尋不允許移動索引。
模型 2：每個租使用者一個服務
在每一租用戶的服務架構中，每個租使用者都有自己的搜尋服務。
在此模型中，應用程式會達到其租使用者的最大隔離等級。 每個服務都有用於處理搜尋要求的專用記憶體和輸送量。 每個租使用者都有 API 金鑰的個別擁有權。
對於每個租使用者有大量使用量的應用程式，或工作負載在租用戶之間幾乎沒有變化，則每個租用戶的服務模型是有效的選擇，因為資源不會在各種租使用者的工作負載之間共用。
每個租使用者模型的服務也提供可預測的固定成本模型的優點。 在租使用者填滿整個搜尋服務之前，不會對整個搜尋服務進行預先投資，不過每個租使用者的成本高於每一租使用者索引模型。
每個租用戶的服務模型是具有全域使用量的應用程式有效率的選擇。 使用地理位置分散的租使用者，即可輕鬆地在適當的區域中擁有每個租用戶的服務。
當個別租用戶成長其服務時，調整此模式的挑戰就會發生。 Azure AI 搜尋服務目前不支援升級搜尋服務的定價層，因此所有數據都必須手動複製到新的服務。
模型 3：混合式
模型化多租使用者的另一個模式是混合每個租使用者索引和服務個別租使用者策略。
藉由混合這兩種模式，應用程式最大的租使用者可以佔用專用服務，而較不活躍的長尾，較小的租用戶可以在共用服務中佔用索引。 此模型可確保最大的租用戶在協助保護較小的租使用者免於任何嘈雜的鄰居時，從服務持續高效能。
不過，實作此策略需仰賴遠見，以預測哪些租使用者需要專用服務，而不是共用服務中的索引。 應用程式複雜性隨著管理這兩個多租使用者模型的需求而增加。
達到更精細的數據粒度
在 Azure AI 搜尋服務中建立多租使用者案例模型的上述設計模式會假設一個統一範圍，其中每個租使用者都是應用程式的完整實例。 不過，應用程式有時可以處理許多較小的範圍。
如果每個租用戶的服務與每個租使用者索引模型不夠小的範圍，就可以建立索引模型，以達到更精細的粒度。
若要讓單一索引對不同的用戶端端點有不同的行為，可以將欄位新增至索引，以指定每個可能用戶端的特定值。 每次用戶端呼叫 Azure AI 搜尋來查詢或修改索引時，用戶端應用程式中的程式代碼都會使用 Azure AI 搜尋的 篩選 功能，為該字段指定適當的值。
這個方法可以用來達到個別用戶帳戶、個別許可權等級，甚至是完全分開的應用程式的功能。
注意
使用上述方法來設定單一索引來為多個租使用者提供服務，會影響搜尋結果的相關性。 搜尋相關性分數是在索引層級範圍計算，而不是租用戶層級範圍，因此所有租用戶的數據都會納入相關性分數的基礎統計數據，例如字詞頻率。
下一步
Azure AI 搜尋是許多應用程式令人信服的選擇。 在評估多租使用者應用程式的各種設計模式時，請考慮 各種定價層 和個別 的服務限制 ，以針對各種大小的應用程式工作負載和架構進行調整。