View a markdown version of this page

代理程式符合多租戶 - AWS 方案指引

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

代理程式符合多租戶

很容易將代理程式視為建置區塊,其中將代理程式視為一系列的自主元件,這些元件經過組合,以支援特定網域或業務問題的需求。其中更有趣的是,當我們開始考慮供應商如何封裝和使用這些代理程式時。在許多方面,代理程式會成為企業的成本和收入來源。客服人員提供者必須考慮使用其服務的不同角色、角色的耗用設定檔,以及允許客服人員供應商建立定價和分層模型以符合消費者的獲利策略。

客服人員提供者可以支援部署其客服人員的多種模型,以滿足客戶需求。下圖顯示兩個主要代理程式部署模型的概念檢視。

代理程式部署模型的兩個範例。

圖表的左側顯示客戶專用客服人員模型。客服人員提供者會透過為每個加入的客戶部署個別的客服人員執行個體來建置客服人員。透過此方法,客服人員的功能及其取得知識的能力將僅限於特定客戶環境的範圍。這最終代表了每位客戶的體驗,繼承了支援專用客戶環境的一些複雜性和優勢。

相反地,圖表右側的圖表具有部署在提供者環境中的單一代理程式。客服人員會根據所有客戶的集體體驗,處理來自多個客戶的請求,不斷發展和學習。新增的每個新客戶只會代表客服人員的另一個有效用戶端。代理程式的運作方式就像代理程式即服務 (AaaS) 模型,使用共用建構來支援用戶端的需求。在這兩個執行個體中,客服人員取用者可以是應用程式、系統,甚至是其他客服人員。

有兩種方式可以查看 AaaS 模型。上述模型為所有客戶提供相同的體驗。這表示代理程式的內部不會包含考慮請求用戶端內容的任何專業層級。一般而言,對於此模式,假設代理程式的範圍、目標和價值本質以一組通用套用至所有用戶端的共用資源、知識和結果為中心。 

AaaS 的替代方法是用戶端內容影響客服人員的體驗和實作。下圖提供在此內容中 AaaS 代理程式使用量的概念檢視。

具有租用戶內容的 AaaS。

在此 AaaS 檢視中,傳入請求的來源和內容會大幅影響客服人員的足跡。做為代理程式基礎實作一部分的資源、動作和工具,可能會針對每個傳入租用戶請求而有所不同。代理程式的值與其使用租用戶內容來實現受租用戶狀態、知識和其他因素影響的動作和結果的能力相關聯。有些請求可能會產生唯一的租用戶結果,而其他請求則可能會產生更量身打造的每個租用戶結果。這為客服人員的學習能力新增了新的維度,其中可能包括更上下文,以及取得和套用增強目標成果的知識。

對於提供者,AaaS 模型提供許多優點。隨著多個客戶使用單一代理程式,供應商有機會實現規模經濟、提高營運效率、控制成本,並建立統一的管理體驗。這有可能提高客服人員業務的靈活性、創新和成長。

這些品質與推動軟體即服務 (SaaS) 模型採用的相同原則重疊。基本上,AaaS 模型是建置為多租戶服務,可繼承 SaaS 環境中許多相同的擴展、彈性、隔離、加入和操作屬性。在許多方面,AaaS 體驗會大量借用 SaaS 供應商使用的策略和實務,但區分這些條款是合理的。基於我們的目的,重點在於需要多租用戶支援的建置和操作代理程式所帶來的影響。

對於可以公平對待所有使用者且不需要管理持久性、敏感性或客戶特定資料的系統,租用的概念將對他們的客服人員影響最小。對於預期服務多個客戶的系統,同時保留資料隔離、自訂和內容意識,支援多個租戶可能是客服人員設計、策略和目標的重要元素。下圖顯示如何在代理程式環境中使用多租戶。

多租戶代理程式。

此圖表左側是傳統多租戶架構。它包含 Web 應用程式和一系列實作商業邏輯的微服務。多個租用戶會使用此環境的共用基礎設施,擴展以滿足租用戶人口不斷變化的工作負載。環境是透過所有租戶的單一玻璃窗格進行操作和管理。

試想這個心理模型如何映射到此圖表右側的客服人員。一個代理程式會執行由一或多個租用戶耗用的 AaaS 模型。代理程式可能來自多個供應商,其中租用戶內容在其之間流動,因為一個代理程式的單一執行個體必須處理來自多個租用戶的請求。

此圖表中間的範例是混合模型,其中客服人員是整體 SaaS 體驗的一部分。系統的某些部分是在較傳統的模型中實作,而系統的其他部分則依賴客服人員。此模式在許多 SaaS 產品中可能很常見,尤其是正在轉換為客服人員體驗的組織。此模型通常會持續存在,因為並非所有系統都以純 AaaS 形式交付。另請注意,多租用戶仍然適用於模型的代理程式。雖然代理程式可能內嵌在系統中,但仍然可以處理來自多個租用戶的請求。

詢問多租戶是否真正重要是很自然的。您可以說客服人員處理請求,因此支援租用的效果可能很小。但是,當我們深入探討多租戶代理的影響時,租用可能會直接影響代理程式如何影響工具、記憶體、資料和其他代理程式組件的存取、部署和設定方式,以支援個別租戶。租用也會影響擴展、限流、定價、分層和其他業務層面如何套用至客服人員的架構。

其中一個重點是,有代理使用案例需要多租用戶支援。挑戰是判斷多租戶如何塑造代理體驗的整體設計和架構。對於某些客服人員,多租戶支援代表差異化功能,允許客服人員將租戶特定內容套用至提供目標成果的客服人員。

在後續章節中,您將看到我們為了描述多租用戶 SaaS 架構而建立的術語和設計模式如何有用。AaaS 模型可以透過借用有用的層面來採用這些概念,在需要這些概念的地方引進新的客服人員特定概念。

身分、租戶內容和代理系統

將租戶內容新增至個別客服人員並不特別具有挑戰性。在許多執行個體中,團隊可以依賴將使用者和系統繫結到租用戶的典型機制,並將租用戶感知字符傳遞給客服人員。當我們考慮租戶內容和身分如何支援多個客服人員時,這很重要。在此模型中,租戶必須繫結至跨所有協同合作客服人員的身分。

一般而言,代理網域需要更交叉的身分模型,以符合代理系統目前和新興的需求。代理程式供應商需要支援作業系統隨附之唯一安全性、合規性和授權模型的身分機制。這在由客戶或其他客服人員組成系統的環境中特別具有挑戰性。每個加入的客服人員都必須將其身分和租戶內容連線至客服人員互動。下圖重點介紹agent-to-agent (a2a) 互動中的潛在身分和租戶內容挑戰。

身分、租戶內容和代理系統。

此圖表顯示一系列供應商建置的客服人員,與我們涵蓋的客服人員系統互動。它現在已修改為身分和租戶內容。此案例是支援多個進入點的代理系統範例。我們假設此系統中的每個代理程式都需要自己的身分驗證機制,才能將系統或使用者解析為指定的租用戶。當這些客服人員互動時,租戶內容會傳遞至 JSON Web 字符 (JWT),該字符將用於授權存取並將租戶內容注入客服人員。

在概念上,此案例的主要差異是客服人員獨立部署和操作,這表示每個客服人員都必須能夠解析其身分並授權存取。關鍵在於其身分必須具備一些分散式能力,才能處理更廣泛的代理系統的需求。客服人員共享租用戶內容的方式也必須保持一致。

將 SaaS 商業價值套用至 AaaS

一般而言,當我們查看在as-a-service模型中執行任何系統時,我們會考慮體驗的性質,以及其技術和營運足跡如何推動業務成果。例如,採用 SaaS 時,組織會使用規模經濟、營運效率、成本設定檔和敏捷性來推動成長、利潤和創新。

做為 AaaS 交付的代理程式可能以類似的業務成果為目標。透過支援多個租用戶,客服人員可以將資源消耗與租用戶活動保持一致。這會產生傳統 SaaS 環境隨附的規模經濟。AaaS 也允許組織管理、操作和部署代理程式,讓代理程式頻繁發行,並提高代理程式供應商的靈活性。關鍵在於 AaaS 模型不依賴技術。它建立並推動促進成長、簡化採用和簡化操作的業務策略。