共用方式為


混合式應用程式設計考慮

Microsoft Azure 是唯一一致的混合式雲端。 它可讓您重複使用開發投資,並啟用可跨全球 Azure、主權 Azure 雲端和 Azure Stack 的應用程式,這是數據中心內 Azure 的延伸模組。 跨雲端應用程式也稱為 混合式應用程式

Azure 應用程式架構指南 說明設計可調整、復原和高可用性之應用程式的結構化方法。 Azure 應用程式架構指南中所述的考慮, 同樣適用於針對單一雲端和跨雲端的應用程式所設計的應用程式。

本文 將增強 Azure 應用程式架構指南中所討論的軟體 品質要素, 特別著重於設計混合式應用程式。 此外,我們會新增 放置 支柱,因為混合式應用程式並非專屬於一個雲端或一個內部部署數據中心。

混合式案例因開發可用的資源而有很大的差異,以及地理、安全性、因特網存取和其他考慮等跨度考慮。 雖然本指南無法列舉您的特定考慮,但它可以提供一些重要的指導方針和最佳做法,讓您遵循。 成功設計、設定、部署和維護混合式應用程式架構牽涉到許多設計考慮,您可能不知道這些考慮。

本檔旨在匯總實作混合式應用程式時可能發生的問題,並提供考慮(這些要素)和最佳做法來處理它們。 藉由在設計階段解決這些問題,您將避免在生產環境中造成的問題。

基本上,在建立混合式應用程式之前,您需要考慮這些問題。 若要開始使用,您需要執行下列動作:

  • 識別和評估應用程式元件。
  • 根據要素評估應用程式元件。

評估應用程式元件

應用程式的每個元件在較大的應用程式內都有自己的特定角色,而且應該檢閱所有設計考慮。 每個元件的需求和功能都應該對應至這些考慮,以協助判斷應用程式架構。

藉由研究應用程式的架構並判斷其組成內容,將您的應用程式分解成其元件。 元件也可以包含應用程式與其互動的其他應用程式。 當您識別元件時,請詢問下列問題,根據其特性評估您預期的混合式作業:

  • 元件的用途為何?
  • 元件之間的相依性為何?

例如,應用程式可以有定義為兩個元件的前端和後端。 在混合式案例中,前端位於一個雲端中,而後端則位於另一個雲端中。 應用程式提供前端與使用者之間的通道,以及前端與後端之間的通道。

應用程式元件是由許多表單和案例所定義。 最重要的工作是識別它們及其雲端或內部部署位置。

要包含在清查中的常見應用程式元件會列在表 1 中。

表格 1. 一般應用程式元件

元件 混合式應用程式指引
用戶端連線 您的應用程式(在任何裝置上)都可以從單一進入點以各種方式存取使用者,包括下列方式:
- 用戶端伺服器模型,需要使用者安裝用戶端才能使用應用程式。 從瀏覽器存取的伺服器型應用程式。
- 用戶端連線可包含連線中斷時的通知,或漫遊費用可能適用時的警示。
認證 線上到應用程式的使用者,或從連線到另一個元件的元件,可能需要驗證。
蜜蜂屬 您可以透過 API 集合和類別庫,提供開發人員以程式設計方式存取您的應用程式,並提供以因特網標準為基礎的連接介面。 您也可以使用 API 將應用程式分解成獨立運作的邏輯單元。
服務業 您可以使用簡潔的服務來提供應用程式的功能。 服務可以是應用程式執行的引擎。
佇列 您可以使用佇列來組織應用程式元件生命週期的狀態和狀態。 這些佇列可以提供傳訊、通知和緩衝功能給訂閱者。
數據記憶體 應用程式可以是無狀態或具狀態。 具狀態應用程式需要可透過多種格式和磁碟區符合的數據記憶體。
數據快取 您設計中的數據快取元件可以策略性地解決延遲問題,並扮演觸發雲端高載的角色。
數據擷取 數據可以透過多種方式提交至應用程式,範圍從 Web 窗體中的使用者送出值到持續大量的數據流。
數據處理 數據處理工作(例如報表、分析、批次匯出和數據轉換)可以在來源處理,或使用數據復本在個別元件上卸除。

評估要素的應用程式元件

針對每個元件,評估其每個要素的特性。 當您使用所有要素評估每個元件時,您可能尚未考慮的問題可能會讓您知道會影響混合式應用程式的設計。 在這些考慮上採取行動可能會增加優化應用程式的價值。 表 2 提供每個要素的描述,因為它與混合式應用程式相關。

表 2. 支柱

描述
放置 混合式應用程式中元件的戰略定位。
延展性 系統處理增加負載的能力。
可用性 混合式應用程式正常運作及運作的時間比例。
彈性 混合式應用程式復原的能力。
管理性 讓系統持續在生產環境中執行的作業程式。
安全 保護混合式應用程式和數據免於威脅。

放置

混合式應用程式原本就具有放置考慮,例如數據中心。

放置是定位元件的重要工作,讓它們能夠最好地服務混合式應用程式。 根據定義,混合式應用程式跨越位置,例如從內部部署到雲端,以及不同雲端之間的位置。 您可以透過兩種方式將應用程式的元件放在雲端上:

  • 垂直混合式應用程式
    應用程式元件會分散到各個位置。 每個個別元件只能有多個實例位於單一位置。

  • 水準混合式應用程式
    應用程式元件會分散到各個位置。 每個個別元件可以有多個跨越多個位置的實例。

    有些元件可以留意其位置,而有些元件則不知道其位置和位置。 這種良性性可以使用抽象層來達成。 此層具有微服務等新式應用程式架構,可以定義應用程式如何透過在雲端的節點上運作的應用程式元件來提供服務。

放置檢查清單

確認必要位置。 請確定應用程式或其任何元件都必須運作,或需要特定雲端的認證。 這可以包含貴公司的主權需求,或依法律規定。 此外,判斷特定位置或地區設定是否需要任何內部部署作業。

確定連線相依性。 必要的位置和其他因素可以決定元件之間的連線相依性。 當您放置元件時,請判斷其中通訊的最佳連線和安全性。 選擇包括 VPNExpressRoute混合式連線

評估平臺功能。 針對每個應用程式元件,請參閱雲端上是否提供應用程式元件所需的資源提供者,以及頻寬是否可以容納預期的輸送量和延遲需求。

規劃可移植性。 使用新式應用程式架構,例如容器或微服務,規劃移動作業並防止服務相依性。

判斷數據主權需求。 混合式應用程式適用於容納數據隔離,例如在本機數據中心。 檢閱資源的位置,以優化成功以容納此需求。

規劃延遲。 雲端間作業可能會帶來應用程式元件之間的實體距離。 確定容納任何延遲的需求。

控制流量。 在公用雲端中由前端存取時,處理尖峰使用方式和適當且安全的個人標識資訊數據通訊。

延展性

延展性是系統處理應用程式負載增加的能力,隨著其他因素和強制影響物件大小,以及應用程式的大小和範圍,可能會隨著時間而有所不同。

如需此要素的核心討論,請參閱架構卓越五大要素中的 延展性

混合式應用程式的水準調整方法可讓您新增更多實例以符合需求,然後在更安靜期間停用它們。

在混合式案例中,當元件分散到雲端時,相應放大個別元件需要額外的考慮。 調整應用程式的某個部分可能需要調整另一個部分。 例如,如果用戶端連線數目增加,但應用程式 Web 服務未適當相應放大,則資料庫上的負載可能會使應用程式飽和。

有些應用程式元件可以線性地相應放大,而另一些應用程式元件則具有縮放相依性,而且可能受限於其可調整的程度。 例如,為應用程式元件位置提供混合式連線的 VPN 通道具有可調整的頻寬和延遲限制。 如何調整應用程式的元件,以確保符合這些需求?

延展性檢查清單

確定調整臨界值。 若要處理應用程式中的各種相依性,請判斷不同雲端中的應用程式元件可以彼此獨立調整的程度,同時仍符合執行應用程式的需求。 混合式應用程式通常需要調整應用程式中的特定區域,以在互動並影響應用程式的其餘部分時處理功能。 例如,超過一些前端實例可能需要調整後端。

定義調整排程。 大部分的應用程式都有忙碌的期間,因此您必須將其尖峰時間匯總到排程中,以協調最佳調整。

使用集中式監視系統。 平台監視功能可以提供自動調整功能,但混合式應用程式需要匯總系統健全狀況和負載的集中式監視系統。 集中式監視系統可以在某個位置起始調整資源,並根據另一個位置的資源進行調整。 此外,中央監視系統可以追蹤哪些雲端自動調整資源,以及哪些雲端沒有。

利用自動調整功能(可用)。 如果自動調整功能是架構的一部分,您可以藉由設定閾值來實作自動調整,以定義何時需要相應增加、相應放大、縮小或縮小應用程式元件。 自動調整的範例是一個用戶端連線,其會在一個雲端中自動調整以處理增加的容量,但會導致應用程式的其他相依性分散到不同的雲端,也會調整規模。 必須確定這些相依元件的自動調整功能。

如果無法使用自動調整功能,請考慮實作腳本和其他資源以配合手動調整,由集中式監視系統中的臨界值觸發。

依位置判斷預期的負載。 處理用戶端要求的混合式應用程式可能主要依賴單一位置。 當用戶端要求的負載超過臨界值時,可以在不同的位置新增其他資源,以分散輸入要求的負載。 請確定客戶端連線可以處理增加的負載,並判斷用戶端連線處理負載的任何自動化程式。

可用性

可用性是系統運作和運作的時間。 可用性是以運行時間百分比來測量。 應用程式錯誤、基礎結構問題和系統負載都可以降低可用性。

如需此要素的核心討論,請參閱架構卓越五大要素中的 可用性

可用性檢查清單

提供連線的備援。 混合式應用程式需要應用程式分散在雲端之間的連線能力。 您可以選擇混合式連線技術,因此除了主要技術選擇之外,請使用另一種技術來提供具有自動化故障轉移功能的備援,如果主要技術失敗。

分類容錯網域。 容錯應用程式需要多個容錯網域。 容錯網域有助於隔離失敗點,例如,如果單一硬碟在內部部署失敗、機架頂端交換器關閉,或完整數據中心無法使用時。 在混合式應用程式中,位置可以分類為容錯網域。 有了更多的可用性需求,您需要評估如何分類單一容錯網域。

分類升級網域。 升級網域可用來確保應用程式元件的實例可供使用,而相同元件的其他實例則會使用更新或功能升級來提供服務。 和容錯網域一樣,升級網域可以依其在不同位置的位置進行分類。 您必須判斷應用程式元件是否可以容納在某個位置升級之前升級到另一個位置,或是否需要其他網域設定。 單一位置本身可以有多個升級網域。

追蹤實例和可用性。 高可用性應用程式元件可透過負載平衡和同步數據複寫來取得。 在服務中斷之前,您必須判斷可以離線的實例數目。

實作自我修復。 如果問題造成應用程式可用性中斷,監視系統的偵測可能會起始應用程式的自我修復活動,例如清空失敗的實例並重新部署它。 這最有可能需要集中監視解決方案,並與混合式持續整合和持續傳遞 (CI/CD) 管線整合。 應用程式會與監視系統整合,以識別可能需要重新部署應用程式元件的問題。 監視系統也可以觸發混合式 CI/CD 來重新部署應用程式元件,以及可能位於相同或其他位置的任何其他相依元件。

維護服務等級協定 (SLA)。 可用性對於任何合約而言都很重要,可維持您與客戶所擁有的服務和應用程式的連線能力。 混合式應用程式所依賴的每個位置可能會有自己的 SLA。 這些不同的 SLA 可能會影響混合式應用程式的整體 SLA。

彈性

復原功能是混合式應用程式和系統從失敗中復原並繼續運作的能力。 復原的目標是在發生失敗之後,將應用程式傳回完全正常運作的狀態。 復原策略包括備份、復寫和災害復原等解決方案。

如需此要素的核心討論,請參閱架構卓越五大要素中的 復原

復原檢查清單

找出災害復原相依性。 某個雲端中的災害復原可能需要變更另一個雲端中的應用程式元件。 如果一個雲端中的一或多個元件故障轉移至另一個位置,不論是在相同的雲端或另一個雲端中,相依元件都必須注意這些變更。 這也包含連線相依性。 復原需要針對每個雲端進行完整測試的應用程式復原方案。

建立復原流程。 有效的復原流程設計已評估應用程式元件,使其能夠容納緩衝區、重試、重試失敗的數據傳輸,並在必要時回復至不同的服務或工作流程。 您必須判斷要使用的備份機制、其還原程式牽涉到什麼,以及其測試的頻率。 您也應該判斷增量和完整備份的頻率。

測試部分復原。 部分應用程式的部分復原可以提供用戶無法取得的保證。 計劃的這個部分應該確保部分還原沒有任何副作用,例如與應用程式互動的備份和還原服務,以在進行備份之前正常關閉它。

判斷災害復原煽動者並指派責任。 除了可以備份和還原哪些動作之外,復原方案應該描述誰以及哪些角色可以起始備份和復原動作。

比較自我修復閾值與災害復原。 判斷應用程式的自我修復功能以進行自動復原起始,以及應用程式自我修復視為失敗或成功所需的時間。 判斷每個雲端的臨界值。

確認復原功能的可用性。 判斷每個位置的復原功能可用性。 如果位置未提供必要功能,請考慮將該位置整合到提供復原功能的集中式服務。

判斷停機時間。 判斷因整體應用程式維護以及應用程式元件所造成的預期停機時間。

記載疑難解答程式。 定義重新部署資源和應用程式元件的疑難解答程式。

管理性

管理混合式應用程式的考慮,對於設計架構而言非常重要。 妥善管理的混合式應用程式提供基礎結構即程序代碼,可讓您在一般開發管線中整合一致的應用程式程序代碼。 藉由實作對基礎結構變更的一致全系統與個別測試,您可以在變更通過測試時確保整合式部署,讓他們能夠合併到原始程式碼中。

如需此要素的核心討論,請參閱架構卓越五大要素中的 DevOps

管理性檢查清單

實作監視。 使用分散在雲端的應用程式元件的集中式監視系統,提供其健康情況和效能的匯總檢視。 此系統包含監視應用程式元件和相關平臺功能。

判斷需要監視的應用程式部分。

協調原則。 混合式應用程式跨越的每個位置都可以有自己的原則,涵蓋允許的資源類型、命名慣例、標籤和其他準則。

定義和使用角色。 身為資料庫管理員,您必須判斷需要存取應用程式資源的不同角色所需的許可權(例如應用程式擁有者、資料庫管理員和使用者)。 這些許可權必須在資源和應用程式內設定。 角色型訪問控制 (RBAC) 系統可讓您在應用程式資源上設定這些許可權。 當所有資源都部署在單一雲端時,這些訪問許可權非常困難,但在資源分散到雲端時,需要更加注意。 在一個雲端中設定的資源許可權不適用於另一個雲端中設定的資源。

使用 CI/CD 管線。 持續整合和持續開發 (CI/CD) 管線可以提供一致的程式,以撰寫和部署跨雲端的應用程式,並提供基礎結構和應用程式的質量保證。 此管線可讓基礎結構和應用程式在一個雲端上進行測試,並部署在另一個雲端上。 管線甚至可讓您將混合式應用程式的某些元件部署到一個雲端,並將其他元件部署到另一個雲端,基本上形成混合式應用程式部署的基礎。 CI/CD 系統對於處理安裝期間彼此相依性應用程式元件而言非常重要,例如需要資料庫連接字串的 Web 應用程式。

管理生命週期。 因為混合式應用程式的資源可以跨越位置,因此每個單一位置的生命週期管理功能都必須匯總成單一生命週期管理單位。 請考慮如何建立、更新和刪除它們。

檢查疑難解答策略。 針對混合式應用程式進行疑難解答,涉及的應用程式元件比在單一雲端中執行的相同應用程式更多。 除了雲端之間的連線之外,應用程式會在兩個平台上執行,而不是一個。 針對混合式應用程式進行疑難解答的重要工作是檢查應用程式元件的匯總健康情況和效能監視。

安全

安全性是任何雲端應用程式的主要考慮之一,對於混合式雲端應用程式而言,安全性會變得更加重要。

如需此要素的核心討論,請參閱架構卓越五大要素中的 安全性

安全性檢查清單

假設有缺口。 如果應用程式的某個部分遭到入侵,請確定有解決方案可將缺口的散佈降到最低,不僅在同一個位置內,而且會跨位置。

監視允許的網路存取。 判斷應用程式的網路存取原則,例如只從特定子網存取應用程式,並且只允許應用程式正常運作所需的元件之間的最小埠和通訊協定。

採用強固的驗證。 健全的驗證配置對於應用程式的安全性至關重要。 請考慮使用提供單一登錄功能的同盟識別提供者,並採用下列一或多個配置:用戶名稱和密碼登入、公開和私鑰、雙因素或多重要素驗證,以及受信任的安全組。 判斷除了憑證類型及其需求之外,還要為應用程式驗證儲存敏感數據和其他秘密的適當資源。

使用加密。 識別應用程式使用加密的區域,例如用於資料儲存或用戶端通訊和存取。

使用安全通道。 跨雲端的安全通道對於跨雲端提供安全性和驗證檢查、即時保護、隔離和其他服務至關重要。

定義和使用角色。 針對跨雲端的資源設定和單一身分識別存取實作角色。 判斷應用程式及其平台資源的角色型訪問控制 (RBAC) 需求。

稽核您的系統。 系統監視可以從應用程式元件和相關雲端平臺作業記錄和匯總數據。

總結

本文提供在撰寫和設計混合式應用程式期間,請務必考慮的專案檢查清單。 在部署應用程式之前先檢閱這些要素,可防止您在生產中斷中發生這些問題,並可能需要重新流覽您的設計。

這似乎是一項耗時的工作,但如果您根據這些要素設計應用程式,您可以輕鬆地獲得投資報酬率。

後續步驟

如需詳細資訊,請參閱下列資源: