編輯

共用方式為

多層式架構樣式

Azure 儲存體
Azure 雲端服務
Azure 虛擬機器

多層式架構會將應用程式分成邏輯層和實體層。

多層式架構樣式的邏輯圖表

層是分隔責任和管理相依性的方法。 每一層都有特定的責任。 較高層可以在較低層使用服務，但不能以另一種方式來使用服務。

層會以實體方式分隔，在個別的計算機上執行。 以合約方式，該層可以有其通訊模式是嚴格或寬鬆的。 在嚴格模型中，要求必須逐一經歷相鄰層，而且不能略過任何階層。 例如，從 Web 應用程式防火牆到 Web 層，再到仲介層 1 等等。 相反地，在寬鬆的方法中，如果有必要，要求可能會略過某些層級。 嚴格的方法會有更多的延遲和額外負荷，而寬鬆的方法有較多的結合，而且後續更難變更。 系統可以使用混合式方法：視需要同時有寬鬆和嚴格的層級。

階層可以直接呼叫另一層，或透過消息佇列使用 異步傳訊模式 。 雖然每個圖層可能裝載在其本身的階層中，但不需要。 數個層可能會裝載在同一層上。 以實體方式分隔層可改善延展性和復原性，但也會增加來自其他網路通訊的延遲。

傳統的三層式應用程式具有表示層、仲介層和資料庫層。 中間層是選擇性的。 更複雜的應用程式可以有三個以上的層級。 上圖顯示具有兩個仲介層的應用程式，封裝不同的功能區域。

多層式應用程式可以有 封閉層架構 或 開放式層架構：

  • 在封閉層架構中，圖層只能立即呼叫下一層。
  • 在開放式圖層架構中，圖層可以呼叫其下方的任何圖層。

封閉層架構會限制圖層之間的相依性。 不過，如果一層只是將要求傳遞至下一層，它可能會建立不必要的網路流量。

使用此架構的時機

多層式架構通常會實作為基礎結構即服務 （IaaS） 應用程式，每一層會在一組個別的 VM 上執行。 不過，多層式應用程式不需要是純 IaaS。 通常，最好針對架構的某些部分使用受控服務，特別是快取、傳訊和數據記憶體。

針對下列情況，請考慮使用多層式架構：

  • 簡單的 Web 應用程式。
  • 目前還不清楚架構需求時的起點。
  • 運用最低限度的重構將內部部署應用程式移轉至 Azure。
  • 內部部署和雲端應用程式的整合開發。

多層式架構在傳統內部部署應用程式中非常常見，因此它很適合將現有的工作負載移轉至 Azure。

福利

  • 雲端與內部部署之間的可移植性，以及雲端平臺之間的可移植性。
  • 大部分開發人員的學習曲線較少。
  • 不重新建置解決方案的成本相對較低
  • 傳統應用程式模型的自然演進。
  • 開啟異質環境 （Windows/Linux）

挑戰

  • 最後，中間層只會對資料庫執行 CRUD 作業，而不需要執行任何有用的工作，即可增加額外的延遲。
  • 整合型設計可防止獨立部署功能。
  • 管理 IaaS 應用程式比只使用受控服務的應用程式更有作用。
  • 在大型系統中管理網路安全性可能很困難。
  • 用戶和數據流通常會跨越多層，將複雜性新增至測試和可檢視性等考慮。

最佳作法

  • 使用自動調整來處理負載中的變更。 請參閱 自動調整最佳做法。
  • 使用 異步傳訊 來分離階層。
  • 快取半靜態數據。 請參閱 快取最佳做法。
  • 使用 SQL Server Always On 可用性群組之類的解決方案，設定高可用性的資料庫層。
  • 在前端與因特網之間放置 Web 應用程式防火牆 （WAF）。
  • 將每一層放在自己的子網中，並使用子網作為安全性界限。
  • 只允許來自中介層的要求，以限制對數據層的存取。

虛擬機上的多層式架構

本節說明在 VM 上執行的建議多層式架構。

多層式架構的實體圖表

每一層都包含兩個以上的 VM，放在可用性設定組或虛擬機擴展集中。 如果一個 VM 失敗，多個 VM 提供復原功能。 負載平衡器可用來將要求分散到階層中的 VM。 將更多 VM 新增至集區，即可水平調整階層。

每個層也會放在自己的子網內，這表示其內部IP位址落在相同的位址範圍內。 這可讓您輕鬆地將網路安全組規則和路由表套用至個別層。

Web 和商務層是無狀態的。 任何 VM 都可以處理該層的任何要求。 數據層應該包含複寫的資料庫。 針對 Windows，我們建議使用 Always On 可用性群組來取得高可用性的 SQL Server。 針對 Linux，請選擇支援複寫的資料庫，例如 Apache Cassandra。

網路安全組會限制對每一層的存取。 例如，資料庫層只允許從商務層存取。

注意

參考圖中標示為「商務層」的圖層是商業規則層的Moniker。 同樣地，我們也將表示層稱為「Web 層」。在我們的範例中，這是 Web 應用程式，不過多層式架構也可用於其他拓撲（例如傳統型應用程式）。 為您的階層命名最適合您的小組，以傳達應用程式中該邏輯和/或實體層的意圖-您甚至可以在您選擇的資源中表示該命名（例如 vmss-appName-business-layer）。

其他考量

  • 多層式架構不限於三層。 對於更複雜的應用程式，通常會有更多層。 在此情況下，請考慮使用第 7 層路由將要求路由傳送至特定層。

  • 階層是延展性、可靠性和安全性的界限。 請考慮針對這些區域中具有不同需求的服務，各有不同層級。

  • 使用虛擬機擴展集進行 自動調整。

  • 在架構中尋找您可以在不進行重大重構的情況下使用受控服務的位置。 特別是，請查看快取、傳訊、記憶體和資料庫。

  • 為了提高安全性，請將網路 DMZ 放在應用程式前面。 DMZ 包含網路虛擬設備 （NVA），可實作防火牆和封包檢查等安全性功能。 如需詳細資訊，請參閱 網路 DMZ 參考架構。

  • 若要達到高可用性，請在可用性設定組中放置兩個以上的 NVA，並使用外部負載平衡器將因特網要求分散到實例。 如需詳細資訊，請參閱 部署高可用性網路虛擬設備。

  • 不允許直接 RDP 或 SSH 存取執行應用程式程式碼的 VM。 相反地，操作員應該登入 Jumpbox，也稱為防禦主機。 這是網路上系統管理員用來連線到其他 VM 的 VM。 Jumpbox 有一個網路安全組，只允許來自已核准公用IP位址的 RDP 或 SSH。

  • 您可以使用站對站虛擬專用網 （VPN） 或 Azure ExpressRoute，將 Azure 虛擬網路延伸至內部部署網路。 如需詳細資訊，請參閱 混合式網路參考架構。

  • 如果您的組織使用 Active Directory 來管理身分識別，您可能會想要將 Active Directory 環境延伸至 Azure VNet。 如需詳細資訊，請參閱 身分識別管理參考架構。

  • 如果您需要比適用於 VM 的 Azure SLA 更高的可用性，請跨兩個區域復寫應用程式，並使用 Azure 流量管理員 進行故障轉移。 如需詳細資訊，請參閱 在多個區域中 執行 Windows VM 或 在多個區域中執行 Linux VM。