混合式應用程式設計考量
Microsoft Azure 是唯一的一致性混合式雲端。 它可讓您重複使用您的開發投資，並啟用可跨越全球 Azure、主權 Azure 雲端和 Azure Stack 的應用程式，這是您資料中心內的 Azure 擴充功能。 跨雲端的應用程式也稱為混合式 應用程式。
Azure 應用程式架構指南說明設計可調整、具彈性且高度可用的應用程式的結構化方法。 Azure 應用程式架構指南中所述的考慮同樣適用于針對單一雲端和跨雲端的應用程式所設計的應用程式。
本文將增強Azure 應用程式架構指南中所討論之軟體品質的要素，特別著重在設計混合式應用程式。 此外，我們新增了 放置 要件，因為混合式應用程式不是一個雲端或一個內部部署資料中心專屬的。
混合式案例與可用於開發的資源有很大的差異，並涵蓋地理位置、安全性、網際網路存取和其他考慮等考慮。 雖然本指南無法列舉您的特定考慮，但它可以提供一些重要的指導方針和最佳作法讓您遵循。 成功設計、設定、部署和維護混合式應用程式架構，牽涉到許多您可能不知道的設計考慮。
本檔的目標是要匯總在執行混合式應用程式時可能發生的問題，並提供 (這些要素的考慮，以及使用這些要素) 和最佳作法。 藉由在設計階段解決這些問題，您可以避免它們在生產環境中可能造成的問題。
基本上，您必須先考慮這些問題，再建立混合式應用程式。 若要開始使用，您需要執行下列動作：
- 識別並評估應用程式元件。
- 針對支柱評估應用程式元件。
評估應用程式元件
應用程式的每個元件在較大的應用程式內都有自己的特定角色，並應考慮所有設計考慮。 每個元件的需求和功能都應該對應至這些考慮，以協助判斷應用程式架構。
藉由研究您的應用程式架構，並判斷其包含的內容，將您的應用程式分解成其元件。 元件也可以包含與您的應用程式互動的其他應用程式。 當您識別出元件時，請詢問下列問題，根據其特性評估您想要的混合式作業：
- 元件的用途為何？
- 元件之間有哪些相互依存性？
例如，應用程式可以將前端和後端定義為兩個元件。 在混合式案例中，前端是在一個雲端，而後端位於另一個雲端。 應用程式會在前端與使用者之間，以及前端和後端之間提供通道。
應用程式元件是由許多表單和案例所定義。 最重要的工作是識別元件及其雲端或內部部署位置。
要包含在清查中的一般應用程式元件列在 [表 1] 中。
表 1. 常見應用程式元件
| 元件 | 混合式應用程式指引 |
|---|---|
| 用戶端連接 | 在任何) 裝置上 (您的應用程式可以透過各種方式從單一進入點存取使用者，包括下列方式： -要求使用者安裝用戶端以使用應用程式的用戶端-伺服器模型。 以伺服器為基礎的應用程式，可從瀏覽器存取。 -用戶端連線可以包含連線中斷時的通知，或可能適用漫遊費用時的警示。 |
| 驗證 | 連線到應用程式的使用者，或連接到另一個元件的某個元件，都可能需要進行驗證。 |
| API | 您可以讓開發人員以程式設計方式存取應用程式，並使用 API 集合和類別庫，並根據網際網路標準提供連接介面。 您也可以使用 Api 將應用程式分解成獨立操作的邏輯單元。 |
| 服務 | 您可以使用簡潔的服務來提供應用程式的功能。 服務可以是應用程式執行所在的引擎。 |
| 佇列 | 您可以使用佇列來組織生命週期的狀態，以及應用程式元件的狀態。 這些佇列可為訂閱者提供傳訊、通知和緩衝處理功能。 |
| 資料儲存體 | 應用程式可以是無狀態或具狀態。 具狀態應用程式需要有許多格式和磁片區可符合的資料儲存體。 |
| 資料快取 | 設計中的資料快取元件可以策略性地解決延遲問題，並扮演觸發雲端負載平衡的角色。 |
| 資料擷取 | 您可以透過許多方式將資料提交給應用程式，範圍從使用者在 web 表單中提交的值到持續大量的資料流程。 |
| 資料處理 | 您的資料處理工作 (例如報表、分析、批次匯出和資料轉換) 可以在來源處理，或使用資料複本在個別元件上卸載。 |
評估應用程式元件的要素
針對每個元件，請評估其每個要素的特性。 當您評估每個元件的所有要素時，您可能未考慮到的問題可能會影響混合式應用程式的設計。 基於這些考慮，可能會增加應用程式優化的價值。 [表 2] 提供每個要件與混合式應用程式相關的描述。
表 2. 要素
| 要素 | 描述 |
|---|---|
| 放置 | 混合式應用程式中元件的策略性定位。 |
| 延展性 | 系統處理負載增加的能力。 |
| 可用性 | 混合式應用程式運作和運作的時間比例。 |
| 災害復原 | 混合式應用程式的復原能力。 |
| 管理能力 | 讓系統在生產環境中順利運作的作業流程。 |
| 安全性 | 保護混合式應用程式和資料免于遭受威脅。 |
放置
混合式應用程式原本就有位置考慮，例如資料中心。
放置是放置元件的重要工作，讓它們可以為混合式應用程式提供最大的服務。 根據定義，混合式應用程式會跨越位置，例如從內部部署到雲端，以及不同的雲端。 您可以透過兩種方式將應用程式的元件放置在雲端：
垂直混合式應用程式
應用程式元件會分散到不同的位置。 每個個別元件可以有多個位於單一位置的執行個體。水準混合式應用程式
應用程式元件會分散到不同的位置。 每個個別元件可以有多個跨多個位置的執行個體。某些元件可能會知道其位置，而其他元件則不知道其位置和位置。 這種辨識力可透過抽象層來達成。 這一層的新式應用程式架構（例如微服務）可以定義應用程式的服務方式，讓應用程式元件在跨雲端的節點上運作。
放置檢查清單
確認必要的位置。 請確定應用程式或其任何元件都必須在特定雲端上運作，或需要特定雲端的認證。 這可能包括您的公司或法律規定的主權需求。 此外，請確認特定位置或地區設定是否需要任何內部部署作業。
確定連線相依性。 必要的位置和其他因素可能會決定元件之間的連線相依性。 在放置元件時，請確認其間的通訊具有最佳連線能力和安全性。 選項包括 VPN、ExpressRoute 和混合式連線。
評估平台功能。 針對每個應用程式元件，請查看雲端上的應用程式元件所需的資源提供者是否可用，以及頻寬是否可以容納預期的輸送量和延遲需求。
進行可攜性規劃。 使用新式應用程式架構（例如容器或微服務）來規劃移動作業，以及防止服務相依性。
判斷資料主權需求。 混合式應用程式適合用來容納資料隔離，例如在本機資料中心。 請檢查您的資源放置方式，以對此需求提供最高的支援性。
進行延遲規劃。 雲端間作業可能會導致應用程式元件之間的實體距離。 請確定因應任何延遲的需求。
控制流量流程。 在公用雲端中的前端存取個人識別資訊資料時，請控制尖峰使用量，並確保該資料的傳輸方式適當且安全無虞。
延展性
擴充性是系統處理應用程式負載增加的能力，這會隨著時間而改變，因為其他因素和影響物件大小，除了應用程式的大小和範圍之外。
如需此要件的核心討論，請參閱適用于架構卓越的五個要素中的擴充 性 。
混合式應用程式的水準調整方法可讓您新增更多實例來滿足需求，然後在不到的期間停用它們。
在混合式案例中，當元件分散於各雲端時，要相應放大個別元件必須先做額外的考量。 調整應用程式的一個部分可能需要調整另一個部分。 例如，如果用戶端連接數目增加，但應用程式的 web 服務未適當相應放大，則資料庫上的負載可能會讓應用程式變得飽和。
某些應用程式元件可以線性方式相應放大，而其他元件則會調整相依性，而且可能會受限於可調整的範圍。 例如，為應用程式元件位置提供混合式連線能力的 VPN 通道，其頻寬和延遲可調整的限制。 如何調整應用程式的元件，以確保符合這些需求？
延展性檢查清單
確定調整臨界值。 若要處理您應用程式中的各種相依性，請判斷不同雲端中的應用程式元件可以獨立調整的範圍，同時仍符合執行應用程式的需求。 混合式應用程式通常需要調整應用程式中的特定區域，以處理功能，因為它會互動並影響應用程式的其餘部分。 例如，超過一些前端實例可能需要調整後端。
定義調整排程。 大部分的應用程式都有忙碌的時間，因此您需要將其尖峰時間匯總成排程，以協調最佳調整。
使用集中式監視系統。 平臺監視功能可以提供自動調整，但混合式應用程式需要可匯總系統健康情況和負載的集中監視系統。 集中式監視系統可以根據另一個位置中的資源，在一個位置和調整規模起始調整資源。 此外，中央監視系統可以追蹤哪些雲端自動調整資源，以及哪些雲端不提供。
利用自動調整功能 (如果適用)。 如果自動調整功能是您架構的一部分，您可以設定臨界值來執行自動調整，以定義應用程式元件何時需要相應增加、相應放大、相應減少或縮小。 自動調整的範例是在一個雲端中自動調整的用戶端連線，以處理增加的容量，但會導致應用程式的其他相依性分散至不同的雲端，也會進行調整。 您必須確認這些相依元件是否有自動調整功能。
如果無法使用自動調整，請考慮執行腳本和其他資源以配合手動調整，並由集中式監視系統中的臨界值觸發。
依位置判斷預期的負載。 處理用戶端要求的混合式應用程式主要可能依賴單一位置。 當用戶端要求的負載超過閾值時，其他資源可以新增至不同的位置，以散發輸入要求的負載。 請確定用戶端連線可以處理增加的負載，並確認是否有任何自動化程序可供用戶端連線處理負載。
可用性
可用性是指系統正常運作並執行作業的時間。 可用性會以運作時間百分比來測量。 應用程式錯誤、基礎結構問題和系統負載都可降低可用性。
如需此要件的核心討論，請參閱「卓越架構」的五個要素中的 可用性 。
可用性檢查清單
提供備援連線能力。 混合式應用程式需要在應用程式分散的雲端之間進行連線。 您可以選擇混合式連線的技術，因此除了您選擇的主要技術外，您也可以使用另一項技術來提供備援能力，以便在主要技術失敗時進行自動化容錯移轉。
分類容錯網域。 容錯應用程式需要多個容錯網域。 容錯網域有助於找出失敗點，例如，是內部部署的單一硬碟故障、機架頂端交換器中斷，還是整個資料中心都無法使用。 在混合式應用程式中，位置可以分類為容錯網域。 可用性需求愈高，就愈有必要評估單一容錯網域的分類方式。
分類升級網域。 升級網域是用來確保應用程式元件的實例可供使用，而相同元件的其他實例則由更新或功能更新服務。 和容錯網域一樣，升級網域也可依其放置位置來分類。 您必須判斷應用程式元件是否可以在升級到另一個位置之前，在某個位置進行升級，或需要其他網域設定。 單一位置本身可以有多個升級網域。
追蹤執行個體和可用性。 高可用性應用程式元件可透過負載平衡和同步資料複寫來使用。 您必須確認在服務中斷之前最多可以有多少個離線的執行個體。
實作自我修復。 如果問題導致應用程式可用性中斷，監視系統的偵測可能會起始對應用程式的自我修復活動，例如清空失敗的實例並重新部署。 這很可能需要中央監視解決方案，並且整合混合式持續整合和持續傳遞 (CI/CD) 管線。 應用程式與監視系統整合，以找出可能需要重新部署應用程式元件的問題。 監視系統也會觸發混合式 CI/CD，以重新部署應用程式元件，以及可能在相同或其他位置中的任何其他相依元件。
維護服務等級協定 (SLA)。 對於維護與客戶的服務和應用程式連線能力的任何合約而言，可用性是不可或缺的。 混合式應用程式所依賴的每個位置都可能有自己的 SLA。 這些不同的 Sla 可能會影響您混合式應用程式的整體 SLA。
災害復原
復原是指混合式應用程式和系統從失敗中復原並繼續運作的能力。 復原的目標是在發生失敗後，將應用程式恢復為功能完整的狀態。 復原策略包括備份、複寫和災害復原等解決方案。
如需此要件的核心討論，請參閱卓越架構的五個要素中的 復原能力 。
復原檢查清單
找出災害復原相依性。 一個雲端中的嚴重損壞修復可能需要變更另一個雲端中的應用程式元件。 如果某個雲端中的一或多個元件容錯移轉到另一個位置（不論是在相同的雲端或另一個雲端），則必須將相依元件感知這些變更。 其中也包括連線相依性。 復原需要針對每個雲端經過完整測試的應用程式復原方案。
建立復原流程。 有效的復原流程設計已評估應用程式元件的能力，以容納緩衝區、重試、重試失敗的資料傳輸，並視需要切換回不同的服務或工作流程。 您必須決定要使用的備份機制、其還原程式牽涉到的內容，以及測試的頻率。 您也應決定增量和完整備份的頻率。
測試部分復原。 部分應用程式的部分復原可以提供再次保證給所有無法使用的使用者。 這部分的計畫應該確保部分還原沒有任何副作用，例如備份和還原服務會與應用程式互動，以在進行備份之前正常地將它關閉。
決定災害復原調查人員並指派職責。 復原計畫應在可備份和還原的項目以外，連帶說明哪些人和哪些角色可起始備份和復原動作。
比較自我修復臨界值與災害復原。 判斷自動復原初始的應用程式自我修復功能，以及將應用程式自我修復視為失敗或成功所需的時間。 請決定每個雲端的臨界值。
確認復原功能的可用性。 對每個位置確認復原功能和能力的可用性。 如果某個位置未提供必要的功能，請考慮將該位置整合至提供復原功能的集中式服務。
確認停機時間。 判斷因應用程式整體維護和應用程式元件所造成的預期停機時間。
記錄疑難排解程序。 定義重新部署資源和應用程式元件的疑難排解程式。
管理能力
您管理混合式應用程式的考慮，對於設計架構而言很重要。 妥善管理的混合式應用程式會提供基礎結構即程式碼，讓您能夠在常見的開發管線中整合一致的應用程式程式碼。 藉由對基礎結構執行一致的全系統測試和個別測試，您可以在變更通過測試時，確保整合的部署，讓它們可以合併到原始程式碼中。
如需此要件的核心討論，請參閱這五個卓越的架構要素中的DevOps 。
管理性檢查清單
實作監視。 使用分散在雲端的應用程式元件集中監視系統，以提供其健康情況和效能的匯總觀點。 此系統包括監視應用程式元件和相關的平臺功能。
判斷需要監視之應用程式的元件。
協調原則。 混合式應用程式跨越的每個位置都可以有自己的原則，其中涵蓋允許的資源類型、命名慣例、標記和其他準則。
定義和使用角色。 如果您是資料庫管理員，您必須決定不同的角色所需的許可權 (例如應用程式擁有者、資料庫管理員，以及需要存取應用程式資源的使用者) 。 這些許可權必須在資源和應用程式內設定。 以角色為基礎的存取控制 (RBAC) 系統可讓您在應用程式資源上設定這些許可權。 當所有資源都部署在單一雲端時，這些存取權限會很難處理，但在資源分散於不同的雲端時將更需多加留意。 在一個雲端中設定的資源許可權不會套用到另一個雲端中設定的資源。
使用 CI/CD 管線。 持續整合和持續開發 (CI/CD) 管線可提供一致的程式，讓您撰寫和部署跨雲端的應用程式，並為其基礎結構和應用程式提供品質保證。 此管線可讓基礎結構和應用程式在一個雲端上進行測試，並部署在另一個雲端上。 此管線甚至還可讓您將混合式應用程式的某些元件部署至另一個雲端，而將其他元件部署到另一個雲端，基本上是形成混合式應用程式部署的基礎。 CI/CD 系統對於處理相依性的應用程式元件在安裝期間是不可或缺的，例如需要將連接字串連接至資料庫的 web 應用程式。
管理生命週期。 因為混合式應用程式的資源可以跨越位置，所以每個單一位置的生命週期管理功能都必須匯總成單一生命週期管理單位。 請考慮它們的建立、更新和刪除方式。
檢查疑難排解策略。 混合式應用程式的疑難排解牽涉到比在單一雲端中執行的應用程式更多的應用程式元件。 除了雲端之間的連線，應用程式會在兩個平臺上執行，而不是在一個平臺上執行。 疑難排解混合式應用程式的一項重要工作，就是檢查應用程式元件的匯總健康情況和效能監視。
安全性
安全性是任何雲端應用程式的主要考慮之一，對於混合式雲端應用程式來說，它變得更重要。
如需此要件的核心討論，請參閱「卓越架構」的五個要素中的 安全性 。
安全性檢查清單
假設缺口。 如果應用程式的其中一個部分遭到入侵，請確定有現成的解決方案可將缺口擴散降至最低，而不只是在相同的位置，而且在不同的位置。
監視允許的網路存取。 判斷應用程式的網路存取原則，例如只從特定子網存取應用程式，並且只允許應用程式所需元件之間的最低埠和通訊協定正常運作。
採用健全的驗證。 健全的驗證配置對您應用程式的安全性很重要。 請考慮使用可提供單一登入功能的同盟識別提供者，並採用下列一或多項配置：使用者名稱和密碼登入、公開和私密金鑰、雙因素或多重要素驗證，以及信任的安全性群組。 除了憑證類型及其需求之外，請決定儲存機密資料的適當資源，以及應用程式驗證的其他秘密。
使用加密。 識別應用程式的哪些區域使用加密，例如資料儲存或用戶端通訊和存取。
使用安全通道。 雲端間必須要有安全通道，才能提供安全性和驗證檢查、即時保護、隔離，和其他跨雲端的服務。
定義和使用角色。 對雲端間的資源設定和單一身分識別存取實作適當角色。 判斷角色型存取控制 (RBAC) 應用程式及其平臺資源的需求。
稽核您的系統。 系統監視可以記錄和匯總來自應用程式元件和相關雲端平臺作業的資料。
總結
本文提供在撰寫和設計混合式應用程式期間必須考慮的專案檢查清單。 在您部署應用程式之前，請先檢查這些要素，以避免在生產環境中斷時遇到這些問題，而且可能需要您重新流覽您的設計。
這似乎是相當耗時的工作，但如果您根據這些要素來設計您的應用程式，則可以輕鬆地獲得投資報酬率。
後續步驟
如需詳細資訊，請參閱下列資源：