軟體即服務 （SaaS） 是一個複雜的主題，有許多需要考慮點。 在 Azure 上建置 SaaS 解決方案的獨立軟體供應商（ISV）需要解決問題並做出決策，例如：
- 我應該使用哪一個 租用模型 ？
- 如何? 設定身分識別解決方案以用於多租用戶架構？
- 如何? 處理新客戶的上線？
此架構旨在回答其中一些問題，並提供 SaaS 世界的起點。 此架構可調整以符合各種案例。
潛在的使用案例
以下是您可以使用此架構的一些範例使用案例：
- 將現有的應用程式現代化，以支援完整多租用戶，作為 SaaS 型商務模型轉變的一部分。
- 開發全新的 SaaS 供應專案。
- 將 SaaS 供應專案從另一個雲端服務遷移至 Azure。
架構
詞彙
下表描述本文中顯示的詞彙。
| 詞彙 | 描述 | 範例 |
|---|---|---|
| SaaS 廠商或ISV | 擁有 SaaS 應用程式和程式代碼並銷售 SaaS 產品的實體。 | Contoso Inc，銷售其 SaaS 應用程式：Contoso Tickets。 |
| 租用戶 | 從 SaaS 廠商購買 SaaS 應用程式的實例。 | 第四家咖啡店。 |
| SaaS 客戶管理員 | 人員購買或管理應用程式租用戶的人員。 | 喬，第四咖啡店的老闆。 |
| SaaS 客戶使用者 | 人員 不使用管理應用程式租使用者，且通常屬於與 SaaS 客戶管理員相同的公司或群組。 | 第四咖啡店的活動經理吉爾和第四咖啡店客戶蘇珊。 |
| 終端使用者 | SaaS 客戶管理員、SaaS 客戶使用者，或任何其他引進的用戶類型。 這是一般詞彙，用來描述登入應用程式的使用者。 | Joe、Jill 和 Susan 都是終端使用者（從 ISV 的觀點）。 |
| 前端應用程式 | 任何前端應用程式。 | 上線與系統管理應用程式和SaaS應用程式都是前端應用程式。 |
工作流程
SaaS 客戶管理員會流覽至裝載於上線與系統管理員應用程式的網站。
SaaS 客戶系統管理員會使用使用者登入工作流程登入。
SaaS 客戶管理員會完成上線流程。
SaaS 客戶管理員會流覽至上線與系統管理員應用程式上的租用戶系統管理員區域，並將 SaaS 客戶使用者新增至他們新建立的租使用者。
SaaS 客戶使用者流覽至 SaaS 應用程式，並使用 SaaS 應用程式。
使用者登入
使用者登入工作流程包含下列步驟：
用戶流覽至前端應用程式，然後選取 [登入] 按鈕。
前端應用程式會將使用者重新導向至身分識別提供者所裝載的登入頁面。
使用者輸入帳戶資訊，並將登入窗體提交至識別提供者。
身 分識別提供者發出POST要求 ，其中包含 使用者的電子郵件地址和對象識別碼，以擷取其許可權和角色。
許可權數據 API 會在權限資料記憶體中查閱使用者的資訊，並傳回指派給該使用者的許可權和角色清單。
身 分識別提供者 會將許可權和角色新增為自定義宣告至 標識符令牌，也就是 JSON Web 令牌 （JWT）。
識別 提供者 會將標識碼令牌傳回給 使用者 ，並起始重新導向至 前端應用程式。
終端使用者會重新導向至前端應用程式上的登入端點，並呈現標識碼令牌。
前端 應用程式 會驗證呈現的標識元令牌。
前端 應用程式 會傳回成功的登入頁面 ，而用戶 現在已登入。
如需此登入流程運作方式的詳細資訊，請參閱 OpenID 連線 通訊協定。
將新租用戶上線
租用戶上線工作流程包含下列步驟：
SaaS 客戶系統管理員會流覽至上線與系統管理員應用程式，並完成註冊表單。
上線與系統管理員應用程式會向租用戶數據 API 發出 POST 要求，以建立新的租使用者。
租 用戶數據 API 會在租用戶數據記憶體中建立新的租使用者。
租用戶數據 API 向許可權數據 API 發出 POST 要求，以將 SaaS 客戶管理員許可權授與新建立的租使用者。
許可權數據 API 會在權限資料記憶體中建立新的許可權記錄。
許可權數據 API 會成功傳回。
租 用戶數據 API 已成功傳回。
上架與系統管理員應用程式向電子郵件通知提供者發出POST要求，以將「租使用者已建立」的電子郵件訊息傳送給SaaS客戶管理員。
電子郵件 通知提供者 會傳送電子郵件。
電子郵件 通知提供者 會成功傳回。
上線與系統管理員應用程式會向身分識別提供者發出要求，以重新整理 SaaS 客戶管理員的標識碼令牌，使其將 JWT 宣告納入新建立的租使用者。
身分識別提供者會向 SaaS 客戶管理員的電子郵件地址和物件標識碼發出 POST 要求，以擷取其許可權和角色。
許可權數據 API 會在權限資料記憶體中查閱 SaaS 客戶管理員的資訊，並傳回指派給 SaaS 客戶管理員的許可權和角色清單。
身 分識別提供者 會將許可權和角色新增為標識元令牌的自定義宣告。
識別提供者會將標識碼令牌傳回至上線和 管理員 應用程式。
上架與系統管理應用程式會將成功訊息和新的標識元令牌傳回至 SaaS 客戶 管理員。
將使用者新增至租使用者
將使用者新增至租使用者工作流程包含下列步驟：
SaaS 客戶系統管理員會要求從上線與管理應用程式上的租使用者管理區域查看租用戶清單。
上架與系統管理員應用程式會向租用戶數據 API 發出 GET 要求，以取得 SaaS 客戶管理員的租用戶清單。
租用戶數據 API 會發出許可權數據 API 的 GET 要求，以取得 SaaS 客戶管理員有權檢視的租用戶清單。
許可權數據 API 會傳回租用戶許可權的清單。
租 用戶數據 API 會查閱租使用者數據記憶體中的租用戶資訊，並根據收到的租用戶許可權清單傳回租用戶數據清單。
上線與系統管理員應用程式會將租用戶數據清單傳回給SaaS客戶管理員。
SaaS 客戶管理員會從清單中選取租使用者，以將 SaaS 客戶使用者新增至 ，並輸入 SaaS 客戶使用者的電子郵件位址。
上架與系統管理員應用程式會向租用戶數據 API 發出 POST 要求，以新增指定租使用者上 SaaS 客戶使用者的許可權。
租 用戶數據 API 會 驗證 SaaS 客戶管理員 對指定的租使用者具有有效的 JWT 宣告，並且具有使用者的寫入許可權。
租用戶數據 API 會發出許可權數據 API 的 POST 要求，以在指定的租使用者上新增 SaaS 客戶使用者的許可權。
許可權數據 API 會發出 GET 要求給識別提供者，以透過提供的電子郵件地址來查閱 SaaS 客戶使用者。
識別 提供者 會 傳回 SaaS 客戶使用者的物件識別碼。
Permission 數據 API 會使用其物件識別碼，在指定租使用者上 SaaS 客戶使用者的權限資料記憶體中新增許可權記錄。
許可權數據 API 會成功傳回。
租 用戶數據 API 已成功傳回。
上 線與系統管理應用程式 成功傳回。
元件
此架構會使用下列 Azure 服務：
App Service 可讓您以您選擇的程式設計語言建置及裝載 Web 應用程式和 API 應用程式，而不需要管理基礎結構。
Azure Active Directory B2C 可輕鬆地為終端使用者應用程式啟用身分識別和存取管理。
Azure SQL 資料庫 是一般用途的關係資料庫受控服務，可支持關係型數據、空間數據、JSON 和 XML。
Azure Logic Apps 可讓您使用簡單的 GUI 工具快速建置功能強大的整合。
替代項目
任何替代選項的有效性都在很大程度上取決於 您想要讓 SaaS 應用程式支援的租用模型 。 以下是實作此解決方案時可遵循的替代方法範例：
目前的解決方案會使用 Azure Active Directory B2C 作為識別提供者。 您可以改用其他識別提供者，例如 Microsoft Entra ID。
針對更嚴格的安全性和合規性需求，您可以選擇實作專用網進行跨服務通訊。
您可以實 作跨服務傳訊的事件驅動架構樣式 ，而不是在服務之間使用 REST 呼叫。
考量
這些考慮會實作 Azure Well-Architected Framework 的要素，這是一組指引原則，您可以遵循這些原則來改善工作負載的品質。 如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework。
安全性
安全性可提供針對蓄意攻擊和濫用寶貴數據和系統的保證。 如需詳細資訊，請參閱 安全性要素概觀。
此解決方案依賴身分識別作為其安全性架構。 Web 應用程式和 API 的驗證和授權是由 Microsoft 身分識別平台 所控管，該 Microsoft 身分識別平台 負責發行和驗證使用者標識元令牌（JWT）。
成本最佳化
成本優化是考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱 成本優化要素概觀。
此解決方案中的元件有一些與其作業相關聯的成本，但大部分 Web 應用程式和 SaaS 解決方案的成本都不大。 此外，您可以管理下列資源設定來控制成本：
您可以調整執行應用程式的 App Service 方案，以符合您需要的輸送量。 此外，如果您需要較高的輸送量，您可以在個別方案上執行每個應用程式，但因此會產生較高的成本。 如需詳細資訊，請參閱 Azure App 服務 計劃概觀。
Azure AD B2C 提供兩個 SKU：進階版 P1 和 進階版 P2。 這兩個 SKU 都包含每月使用中用戶數目的免費額度，但您需要評估每個 SKU 提供哪些功能來判斷使用案例所需的功能。 如需詳細資訊，請參閱 Microsoft Entra 外部 ID 定價。
Azure SQL 有數種購買模型來符合各種使用案例，包括自動調整的能力。 您必須評估自己的資料庫使用量，以確保正確調整其大小。 如需詳細資訊，請參閱比較以虛擬核心和以 DTU 為基礎的 Azure 購買模型 SQL 資料庫。
效能效益
效能效率是工作負載調整的能力，以符合使用者以有效率的方式滿足其需求。 如需詳細資訊，請參閱 效能效率要素概觀。
此架構應該能夠進行調整，以輕鬆滿足大部分中型到中型大型工作負載。 由於架構大多使用 Azure 的平臺 （PaaS） 服務，因此您有許多選項可根據需求和負載來調整解決方案的規模。
部署此案例
如果您想要部署此案例，請參閱 GitHub 上的 Azure SaaS 開發工具包 。 這是此架構的可部署參考實作。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主體作者：
- 蘭登·皮爾斯 |客戶工程師
其他投稿人：
- Chris Ayers |資深客戶工程師
- John Downs |資深客戶工程師
- 拉布琳娜愛 |主要 SVC 工程經理
- Gary Moore |程式設計人員/寫入器
- 尼克·皮內羅 |資深顧問
- 威廉·薩拉扎 |資深客戶工程師
- Ali Sanjabi |資深客戶工程師
- 阿森·弗拉基米爾斯基 | 首席客戶工程師
- Jason Young |主要 SVC 工程經理
下一步
以下是在 Azure 上建置 SaaS 應用程式的一些其他建議資源：
- 在 Azure 上建構多租用戶解決方案 - 描述最佳做法。
- Azure 登陸區域的ISV考慮
- Microsoft Azure Well-Architected Framework
- Wing 提示 Tickets SaaS 應用程式 - 提供有關資料庫層內各種租用模型之間取捨的詳細數據。