多租用戶解決方案中控制平面的架構方法
控制平面是軟體即服務(SaaS)和多租用戶解決方案的重要組成部分,特別是為了協助大規模管理解決方案。 一般而言,有兩個主要元件組成控制平面:
- 租用戶目錄,其會儲存租用戶的相關重要資訊,例如:
- 租用戶設定。
- 針對租用戶資源部署的 SKU。
- 要 配置租使用者的部署戳記 。
- 管理環境變更的程式,這些變更是由租使用者 生命週期事件所觸發。 例如,租用戶上線、租使用者下架,以及任何必要的定期維護。
控制平面本身是應用程式。 您需要仔細考慮您的控制平面,並使用相同的嚴謹設計,並小心您搭配解決方案的任何其他部分使用。 如需控制平面為何、為何應該使用它以及設計控件平面考慮的詳細資訊,請參閱 多租使用者控制平面的考慮。
本文說明您可以考慮設計及建立控制平面的一些方法。 此處所述的方法清單並不全面。 雖然這些方法都是有效的,但還有其他有效的架構。
要考慮的方法和模式
下表摘要說明您可以考慮用於控制平面的一些方法之間的差異。 比較手動、低程式代碼和自定義方法。
考量事項 | 手動 | 低程式碼 | 自訂 |
---|---|---|---|
作業額外負荷 | 高 | 中低 | 低 |
方法適合的生命週期事件頻率 | 罕見 | 偶爾經常 | 經常 |
實作的時間和複雜度 | 低 | 中 | 高 |
控制平面維護責任 | 低 | 中 | 高 |
可測試性 | 低 | 中 | 高 |
不一致的風險 | 高 | 中低 | 低 |
手動程序
建置完全自動化的控制平面並不一定很重要,尤其是在您開始使用且只有少數租用戶時。
您可以將租用戶目錄保留在中央位置,例如 Excel 活頁簿或儲存在小組可存取位置的 JSON 檔案。 不論格式為何,最好以結構化方式儲存資訊,以便您輕鬆地以程序設計方式使用數據。
注意
手動控制平面是開始管理多租使用者應用程式的絕佳方式,但僅適用於少數租使用者(小於 5-10)。 系統管理額外負荷和不一致的風險會隨著您手動上線的每個租使用者而增加。 如果您只有少數租使用者,而且不需要自動化或自助上線,您應該只使用此方法。
針對租用戶上線和維護活動等程式:
- 盡可能建立腳本或自動化管線,即使您手動執行腳本也一樣。 藉由使用腳本或管線,您可以確定每個租使用者的步驟會一致地執行。
- 對於一開始無法編寫腳本的工作,請完整且明確地記錄程式。 記錄如何及原因。 如果有人將來最終自動化工作,他們應該對兩者都有很好的瞭解。
下圖說明一種方式,以針對初始控制平面使用手動程式:
手動方法的優點
- 輕量型:文件、腳本和管線很容易開發和修改。 這可讓您在找出程式時適當,因為您可以快速逐一查看並加以發展。
- 低成本:維護和執行手動方法成本低廉。
- 驗證您的程式:即使您最終想要使用更自動化的方法,從手動方法開始做為概念證明是在您投資開發更強固自動化之前驗證維護策略的好方法。
手動方法的缺點
- 缺乏控制:這種方法依賴參與執行正確動作的每個人。 有人可能會不小心或故意偏離規定的程式。 程式中的每個變化都會增加環境中不一致的風險,這使得持續管理更加困難。
- 訪問控制挑戰:當您使用此方法時,通常需要授與廣泛範圍、高度寬鬆的存取權給任何操作解決方案的人員,這很難遵循存取分割的最佳做法。
- 延展性:執行手動程式所需的工作會隨著您需要管理的租用戶數目進行調整。
- 可測試性:手動程式難以驗證和測試。
何時考慮離開手動方法
- 當小組無法跟上維護應用程式所需的工作量時。 例如,當您的租用戶數目超過關鍵點時,大部分小組的租用戶數目介於 5 到 10 個租用戶之間。
- 當您預期租使用者成長超過重要數目的租使用者時,您必須為管理該租用戶數目所涉及的工作做好準備。
- 當您需要減輕不一致的風險時。 例如,您可能會發現發生一些錯誤,因為有人未正確追蹤程式,或因為程式中存在太多模棱兩可。 不一致的風險通常會隨著更多租使用者手動上線而增加,而且隨著您的小組成長而成長。
低程式代碼控制平面
低程式代碼或無程式代碼控制平面建置在專為自動化商務程式及追蹤資訊而設計的平臺上。 有許多平臺可讓您執行這些工作,而不需要撰寫自定義程序代碼。
Microsoft Power Platform 是其中一個平台的範例。 如果您使用 Power Platform,您可以將租使用者目錄保留在 Dynamics 365、Dataverse 或 Microsoft 365 中。 如果您不想完全認可一開始自動執行所有專案,您也可以考慮保留用於手動程式的相同租用戶目錄。
針對租用戶上線和維護,您可以使用Power Automate來執行執行租使用者管理的工作流程、設定租使用者、觸發管線或API呼叫等等。 您可以使用Power Automate 來監看租使用者目錄的變更,如果Power Automate可存取資料的地方。 如果您使用手動租用戶目錄,也可以手動觸發 Power Automate 工作流程。 如果您需要小組中的某人驗證某些專案,或執行無法完全自動化的其他步驟,您可能會決定在工作流程中包含手動核准步驟。
這種方法也可讓您藉由允許 Web 應用程式直接將記錄新增至租用戶目錄,而不需人為介入,來為客戶提供自助式註冊。
下圖說明如何使用 Microsoft Power Platform 建立具有自助式註冊的控制平面:
低程式代碼方法的優點
- 輕量型:建立一組低程序代碼工作流程並將它們連線到周圍的系統通常既快速又便宜。
- 使用平臺工具:您可以使用原生平臺功能來儲存數據、建立系統管理入口網站以供小組使用,並在工作流程執行時監視工作流程。 藉由使用原生平臺功能,您可以避免自行建置許多元件。
- 可自定義:如果您需要更多自定義,您通常可以使用自定義程式碼和程式來增強工作流程。 例如,您可以使用 Power Automate 來觸發 GitHub Actions 中的部署工作流程,或者您可以叫用 Azure Functions 來執行自己的程式代碼。 這也有助於促進漸進式實作。
- 低負荷:低程式代碼服務通常完全受控,因此您不需要管理基礎結構。
低程式代碼方法的缺點
- 必要專業知識:若要使用低程式代碼平臺來建立程式,並有效地使用這些平臺,您通常需要專屬的知識。 許多組織已經使用這些工具,因此您的小組可能已經有必要的專業知識,但可能沒有。 您應該考慮是否需要訓練小組,才能有效地使用這些平臺。
- 管理:處理大量低程式代碼組態的管理可能會很困難。
- 可測試性:請考慮如何測試及提升控制平面的變更。 在受控平臺中,建立一般的 DevOps 程式來測試和升級變更會比較困難,因為變更通常是透過組態進行,而不是透過程式代碼進行。
- 設計:仔細思考如何符合安全性和可靠性等非功能性需求。 這些需求通常會在低程式碼平臺上為您管理。
何時考慮遠離低程序代碼方法
- 最後,您的需求可能會變得如此複雜,因此您無法在低程式程式碼解決方案中明智地將其納入其中。 當您需要解決工具限制以符合您的需求時,從受控解決方案轉向自定義控制平面可能很合理。
自定義控制平面
您也可以考慮建立自己的完全自定義控制平面。 此選項提供最大的彈性和能力,但也需要最多的工作。 租用戶目錄通常會儲存在資料庫中。 在此情況下,您不會直接使用目錄,而是透過系統管理介面加以管理,這可能是自定義應用程式或您組織客戶關係管理 (CRM) 應用程式之類的系統。
您通常會建立一組控制平面元件,這些元件是針對所有租用戶系統管理功能所設計。 這些元件可能包含系統管理入口網站或其他使用者介面、API 和背景處理元件。 如果您需要在發生租使用者生命週期事件時執行部署程式碼或基礎結構之類的動作,部署管線也可能構成控制平面。
請確定任何長時間執行的處理都會使用適當的工具。 例如,您可以將 Durable Functions 或 Azure Logic Apps 用於協調租使用者上線或部署的元件,或用於需要與外部系統通訊的元件。
如同低程式代碼方法,此方法可讓您藉由允許 Web 應用程式直接將記錄新增至租用戶目錄,而不需人為介入,來為客戶提供自助式註冊。
下圖顯示建立提供自助式註冊之基本自定義控制平面的一種方式:
自定義方法的優點
- 完全彈性和可自定義性:您可以完全控制控制控制平面的用途,並在需求變更時加以變更。
- 可測試性:您可以針對控制平面應用程式使用標準軟體開發生命週期 (SDLC),並實作測試與部署的一般方法,就像針對主要應用程式一樣。
自定義方法的缺點
- 維護責任:這種方法需要更多的維護額外負荷,因為您需要自行建立所有專案。 控制平面和應用程式的任何其他部分一樣重要。 您必須非常小心開發、測試及操作控制平面,以確保其可靠且安全。
混合式方法
您也可以考慮使用混合式方法。 您可以使用手動和自動化系統的組合,或是使用像是 Microsoft Power Platform 等受管理平臺,並使用自定義應用程式加以擴充。 如果您需要自定義控制平面的自定義性,但不一定想要建置和維護完全自定義的系統,請考慮實作混合式方法。 請記住,在某些時候,您對手動程式或受控平臺的自動化自定義可能會變得與完全自定義的系統一樣複雜。 每個組織的秘訣點都不同,但如果混合式方法難以維護,您應該考慮移至完全自定義的系統。
漸進式實作
即使您知道您最終想要將控制平面自動化,您也不一定需要從該方法開始。 在建立應用程式的初始階段,常見的方法是從手動控制平面開始。 當您的應用程式進行並上線更多租使用者時,您應該開始找出瓶頸區域,並視需要將其自動化,並移至混合式方法。 當您進行更多自動化時,最終可能會有完全自動化的控制平面。
要避免的反模式
- 依賴手動程式太久。 雖然當您開始或擁有少量租使用者且需要相當輕量型的管理時,使用手動程式是合理的,但您需要規劃如何隨著成長而調整為自動化解決方案。 如果您需要聘請其他小組成員來跟上手動程式的需求,這表示您應該開始將控制平面的元件自動化。
- 針對長時間執行的工作流程使用不適當的工具。 例如,請避免使用標準 Azure 函式、同步 API 呼叫或其他有運行時間限制的工具來執行長時間執行的作業,例如 Azure Resource Manager 部署或多步驟協調流程。 請改用 Azure Logic Apps、 Durable Functions 和其他可執行長時間執行工作流程或作業順序的工具。 如需詳細資訊,請參閱 Azure Functions 效能和可靠性 與 異步要求-回復模式。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主要作者:
- John Downs |首席軟體工程師
- 蘭登·皮爾斯 |客戶工程師
其他投稿人:
- 米克·阿爾伯特 |技術寫入器
- Bohdan Cherchyk |資深客戶工程師
- 阿森·弗拉基米爾斯基 | 首席客戶工程師