在傳統上，開發應用程序是分層的，MVC這種是常常被用到的。這里的N層體系結構更關注的服務之間的層次結構，而不是單應用內部的。和微服務不同的是，微服務之間的關系是平等的，而N層體系結構中的層與層之間有前后關系。這種體系結構，在實踐中非常廣泛，在微服務的設計中，某些微服務就具有這樣的特性，只能在某個層提供服務。

微軟把這種體系結構拿出來，我認為是可取的，讓我們對程序之間的調用模式，有了更豐富的理論體系支撐。

歡迎關注我。

N 層體系結構將應用程序分成邏輯層和物理層。

層是分離職責和管理依賴關系的方式。 每個層都有特定的責任。 較高層可使用較低層中的服務，反之則不行。

層在物理上是分隔開的，在不同的計算機上運行。 一個層可直接調用另一個層，或使用異步消息傳遞（消息隊列）。 雖然每個層可能托管在自己的層中，但這并不是必需的。 多個層可能托管在同一層上。 在物理上分隔層可以提高可伸縮性和復原能力，但因額外的網絡通信也增加了延遲。

傳統的三層應用程序有表示層、中間層和數據庫層。 中間層是可選的。 更復雜的應用程序可以多于三層。 上圖顯示具有兩個中間層，且封裝了不同功能區域的應用程序。

N 層應用程序可以有封閉的層體系結構或開放的層體系結構：

• 在封閉的層體系結構中，層只能調用緊鄰的下一層。
• 在開放的層體系結構中，層可以調用它下面的任何層。

封閉的層體系結構限制層之間的依賴關系。 但是，如果一個層僅將請求傳遞到下一層，可能會產生不必要的流量。

何時使用此架構

N 層體系結構通常作為服務架構 (IaaS) 應用程序實現，每個層都在獨立的 VM 集中運行。 然而，N 層應用程序不需要只是 IaaS。 通常，對體系結構的某些部分使用托管服務是有利的，特別是緩存、消息傳遞和數據存儲。

請考慮將 N 層體系結構用于：

• 簡單的 Web 應用程序。
• 將本地應用程序遷移到 Azure 并進行最小的重構。
• 統一開發本地和云應用程序。

N 層體系結構在傳統的本地應用程序中很常見，因此將現有工作負載遷移到 Azure 是很適合的。

優點

• 云與本地之間，云平臺之間具有可移植性。
• 對于大多數開發者來說，學習曲線較少。
• 從傳統應用程序模型自然演變。
• 對異構環境 (windows/linux) 開放

挑戰

• 很容易最終得到一個只在數據庫上執行CRUD操作的中間層，在不做任何有用工作的情況下增加額外的延遲。
• 單一式設計阻止了獨立部署各項功能。
• 管理 IaaS 應用程序的工作量要大于管理只使用托管服務的應用程序。
• 管理大型系統中的網絡安全比較困難。

最佳做法

• 使用自動縮放處理負載中的更改。
• 使用異步消息傳遞來分離層。
• 緩存 semistatic 數據。
• 配置高可用性，如使用的解決方案的數據庫層SQL Server Always On 可用性組。
• 在前端和 Internet 之間放置 Web 應用程序防火墻 (WAF)。
• 將每個層放置在自己的子網中，并將子網用作安全邊界。
• 通過僅允許來自中間層的請求，限制對數據層的訪問。

轉自：https://docs.microsoft.com/zh-cn/azure/architecture/guide/architecture-styles/n-tier