什麼是多層式架構？
多層式架構會將應用程式分成邏輯層和實體層。 多代表將應用程式分隔成多少個實體層，通常與層次數相互關聯。 我們可以有兩層式架構 (用戶端-伺服器)，或甚至是五層式架構，雖然五層相當常見，但通常最好是將層數維持在四層以內。
讓我們來談談層次和階層的構成要素。
什麼是層次？
層次會以邏輯方式分隔構成應用程式的應用程式程式碼。 每一層次都有特定的職責，例如處理來自使用者的要求、執行商務邏輯，或是處理資料的儲存。
藉由將應用程式分隔成這些邏輯層，我們便可獨立對待每個層次。 此分隔會使得應用程式的元件模組化，並讓我們更容易維護應用程式。 我們可以針對每項負責的作業將應用程式最佳化。 處理 Web 要求的層次會將焦點放在其主要工作：處理 Web 要求。 這和資料的儲存或商務邏輯的執行不相關。 相反地，資料存取層會專注於最佳化和資料存放區的通訊，而不管有關如何向使用者呈現資料方面的細節。 這個將焦點限制在特定功能的概念稱為「關注點分離」。
以下是一個顯示常見多層式架構中層次的圖表。 每個層次都處理應用程式的一個層面。 商務層負責管理使用者介面層與資料存取層之間的通訊。
什麼是階層？
階層代表個別電腦資源上您應用程式組件的實體分隔。 一般而言，每個實體階層會執行一個應用程式邏輯層次。
將架構分隔成實體層可帶來多個好處：
- 可藉由在每個階層新增資源來調整應用程式元件規模。
- 可藉由新增負載平衡來偵測失敗的資源並要求重新導向到狀況良好的系統，讓應用程式更有彈性。
- 可藉由限制階層間的網路通訊和僅允許必要的存取，讓應用程式更加安全。
此結構要求階層之間的通訊應以由上而下的方式進行。 每個階層皆可與其下一層通訊，但通常不得略過階層。 此設計會限制階層的公開介面區，因此可提升安全性。
三層式架構
在所有多層式架構中，三層式架構是最常見的架構。 每個層次和階層的職責與名稱會依據應用程式和業務而有所不同，但典型的三層式應用程式會有：展示層、應用程式層或中介層，以及資料層。 此結構是最常見的多層式架構 (N-Tier) 樣式。 針對本課程模組的其餘部分，我們將參考三層式模型，其中每個階層都執行一個應用程式層次，並將它們都以同義方式稱為階層。
展示層
展示層通常會協助處理使用者要求。 這些要求可能是使用者存取網頁，或是透過公開的 API 對應用程式進行公用存取。 本階層的焦點在於使用者體驗。 提供直覺式介面並確保使用者與應用程式間的通訊安全。
在此階層，您關注的不是資料本身，而是向使用者呈現資料的方式。 通常在本階層並不會進行任何資料處理或資料存取。 這是較低階層的職責。
應用程式層
應用程式層 (通常也稱為中介層) 通常將焦點放在處理應用程式的商務邏輯。 這可能是處理客戶訂單、追蹤出貨，或是根據收到的物料更新庫存。 本層也負責執行對資料層的建立、讀取、更新、刪除 (CRUD) 活動。 這也是對相依服務 (例如外部 API) 發出呼叫的好位置。
本階層的重點並不在於如何向使用者回呈資訊，也不在於如何儲存和擷取資料。 焦點在於完成應用程式所收到之要求所需的商務邏輯。
資料層
本階層的重點在於資料儲存。 本層負責將資料儲存在資料表、檔案或其他媒體中。 本層會提供可存取資料的介面 (例如 T-SQL)。 在三層式架構中，資料層次會為應用程式層提供資料存取權。
本階層的焦點不在於如何向使用者呈現資料，也不在於資料相關的任何邏輯。 預存程序的使用可以放在本階層，但大多數與資料本身相關的邏輯則應該在更高的階層中處理。
使用多層式架構的時機
既然我們已經談論了什麼是多層式架構 (N-Tier)，現在讓我們說明何時可能會使用此樣式的結構。 針對下列情況，請考慮使用多層式架構：
- 小型至中型 Web 應用程式。
- 運用最低限度的重構將內部部署應用程式移轉至 Azure。
- 利用內部部署開發人員的技能、功能和經驗。
Web 應用程式是此樣式架構的理想使用案例。 由於此架構樣式可降低複雜性，且 Web 應用程式職責間通常會自然區分，因此多層式架構可以良好地運作。 這些應用程式可能是對外公開的，或組織在內部使用的企業營運系統應用程式。 針對較小型或較不複雜的應用程式，兩層式 (用戶端/伺服器) 架構可能就已足夠，其中展示層和應用程式層會合併而不分開。
多層式架構在傳統內部部署應用程式中相當常見，因此，它自然很適合用來將現有的工作負載移轉至 Azure。 採用此樣式的應用程式通常只需最低限度的重構或修改即可移轉至 Azure，簡化了初始的移轉程序。 使用 Azure，您便可利用「平台即服務」(PaaS) 服務來進一步改善您的應用程式。
由於這是常見的架構樣式，因此工程師通常對此架構樣式會較有經驗也較熟悉。 藉由選擇這個架構，您便可以運用現有技能來部署應用程式，而無須費力於了解新架構模式。