多層式架構的考量

已完成

我們已經討論了多層式架構 (N-Tier) 的構成要素,並已部署三層式架構的範例。 讓我們來探索此架構樣式的一些優點和挑戰,以及可為它進行效能和安全性最佳化的最佳做法。

福利

此架構樣式的優點在於其簡潔性。 這是一個常用且妥善定義的架構模式,同時適用於內部部署和雲端部署,而且可以與廣泛的應用程式搭配運作。

這是一個跨平台的架構,適用於部署在 Windows 或 Linux 上的應用程式。 如我們的範例環境中所示,您可以在任一層使用 PaaS 或 IaaS 服務。

在將應用程式分層的情況下,每一層都可以獨立調整規模、更新或升級。 如果網站的要求增加,我們可以在負載中新增更多 Web 伺服器,而不會影響其他階層。 同樣地,如果對我們資料層的要求增加,我們也可以調整資料庫規模,以擁有更多容量來處理這些要求。

網路分隔是此架構的自然副產品。 由於將應用程式分層,因此我們應該隔離每一階層,而只允許必要的網路存取。 展示層可以對網際網路公開,資料庫可以在多個網路層後方受到完全保護,而我們應用程式仍同樣運作。 藉由保護各層之間的網路存取,我們能縮小應用程式的受攻擊面並提升其安全性。

挑戰和考量

當您將應用程式分隔成多層時,請避免讓中介層僅執行資料庫作業。 每一層都應該附加特定價值。 額外的階層會增加複雜度、處理時間、延遲,最終導致使用者遭遇延遲。

由於每個應用程式層級網域的 API 都不會分隔成個別服務,因此它們必須一起調整。 如果某個單一應用程式方法比其他方法需要更多處理能力,或需要處理更多要求,就必須將應用程式層視為整體而不是個別服務,來相應放大規模以處理負載。

在某些情況下,您可以將應用程式開發成多層式架構,但仍以整體方式進行部署。 在完全分隔出每一層之後,您則應該獨立部署每一層。 完全分隔牽涉到移除共用相依性,以及更倚賴階層間的 API 呼叫。 正確完成時,其可確保您的應用程式部署具有彈性。

採用多層式架構的應用程式通常會部署在虛擬機器上。 這是理想的第一步,但讓您的應用程式發展成使用 PaaS 服務可提供安全性、延展性及管理方面的眾多優勢。 這個發展往往會被忽略,而導致多層式架構仍常駐在虛擬機器上。

多層式架構 (N-Tier) 是傳統架構樣式,但在許多案例中,已被其他新式設計模式 (例如微服務架構) 所取代。 通常值得投入一些時間來評估其他架構,以了解它們是否更適合您的應用程式。

多層式架構的最佳做法

為了確保多層式架構以最佳狀態執行,有幾個您應該採取的動作。 下圖以視覺方式顯示如何改進多層式架構。

Visualization of N-tier architecture.

最佳化效能

讓我們研究一下多層式架構的效能和安全性最佳化方式。

自動調整規模

在將應用程式分層的情況下,我們可以使用自動調整規模等雲端功能來因應系統負載變化。 隨著使用者或要求增加,請在多個階層使用自動調整規模功能,以新增更多資源來處理要求。 隨著要求減少,自動調整規模功能會縮減計算資源,也節省您的費用。 自動調整規模功能既能讓您輕鬆確保使用者享有最佳體驗,還能讓您保有低成本的優點。 Azure 虛擬機器擴展集可用於 VM 型負載,而許多 PaaS 服務 (例如 Azure App Service) 都有內建的自動調整規模的功能。

負載平衡

隨著您運用自動調整規模功能來相應放大應用程式規模,負載平衡的使用便成為您架構不可或缺的一部分。 在使用負載平衡的情況下,當您將更多計算資源新增到您的階層時,這些資源會新增到您的負載平衡器散發,以利用額外的處理能力。 相反地,當系統失敗時,則會從負載中將其移除,以將因效能低落或要求發生錯誤而對使用者造成的影響降到最低。 這可確保使用者要求會以狀況良好的狀態進入系統。 Azure負載平衡器是網路功能的內建功能,而「應用程式閘道」則提供功能更豐富的 HTTP 負載平衡解決方案。

傳訊

在階層之間使用傳訊服務可為效能帶來正面影響,特別是在具有非同步本質的要求上。 此服務會將訊息放入佇列中,並留在該處直到進行處理為止,以抵銷對下游負載的影響。 如果發生系統中斷,傳訊服務可確保訊息仍會進行處理。 訊息會保留在佇列中,並在系統重新上線之後進行處理。 Azure 有數個傳訊解決方案,可供您依需求選擇。 尋找訊息服務時,「Azure 服務匯流排」、「Azure 儲存體」佇列及「Azure 事件中樞」是幾個可考慮的選項。

快取資料

針對經常存取且變動率低的資料,或不需要長期保留的資料 (例如工作階段狀態),請使用快取。 快取系統位於階層之間,可針對這些類型的資料減少資料擷取次數。 「Azure Redis 快取」是一個非常適合此案例的 PaaS 服務。

安全性最佳化

將應用程式最佳化以獲取安全性,通常是個永遠不會「完成」的作業。即使將應用程式分成多個階層,仍必須將妥善規劃的安全性做法融入架構中。 新增的階層越多,需要保護的項目就越多,而帶入系統的複雜度也就越高。 為了確保架構提供安全的環境來執行應用程式,有幾個您應該採取的動作。

網路隔離

在 VM 上執行多層式架構 (N-Tier) 時,確保每一層都位於自己的子網路中。 此子網路用來作為安全性邊界,讓您能夠透過網路存取控制清單隔離連線。 此子網路也透過確保子網路中的新系統會收到相同的規則來簡化管理。 Azure 是以原生方式透過網路安全性群組 (NSG) 達成此目的。 針對 PaaS 服務應該有類似的考量,但網路整合功能會因服務而異,而應該各自評估。 最佳做法是確保每一層只能與其下一層進行通訊。 展示層應該只能與應用程式層進行通訊,而應用程式層應該只能與資料層通訊。 將此連線能力縮減到最小為網路安全性提供了一個分層方法,並改善架構的整體安全性狀態。

Web 應用程式防火牆

在子網路之間備妥安全性隔離之後,您會想要確保已公開的前端安全無虞,且只允許進行必要的存取。 您應該只向輸入網際網路流量公開您的展示層。 展示層前面的 Web 應用程式防火牆 (WAF) 技術可增強這一層的安全性。 WAF 會檢查流量是否有惡意活動、確保通訊加密,以及在有異常情況時對您發出警示。 Azure 的「應用程式閘道」是一個 HTTP 負載平衡器,具有您可啟用的內建 WAF。

檢定您的知識

1.

下列哪一種方法既可能改善多層式架構應用程式的效能,又能維持成本最佳化?

2.

下列哪一種動作可提升應用程式的安全性?