大型 Web 項目分層設計：典型案例剖析

一、典型的項目架構模式

MVC 架構

  1. 模型 (Model) 層

負責業務對象與數據庫層之間的交互, 包含業務模型、數據訪問層、數據庫等。主要作用是完成業務邏輯和數據訪問。

// 用戶模型
type User struct {
    ID int
    Name string 
    Age int
}
// 用戶數據訪問層
func GetUser(id int) (User, error) {
    // 連接數據庫讀取用戶數據
    var u User 
    return u, nil
}
  1. 視圖 (View) 層

負責視覺展示, 包含前端頁面、界面元素等。主要作用是將模型中的數據展示給用戶。

<!-- 用戶信息頁面 -->
<html>
<body>
    <div>用戶姓名: {{.Name}}</div> 
    <div>用戶年齡: {{.Age}}</div>
</body>
</html>
  1. 控制器 (Controller) 層

負責連接模型和視圖, 處理用戶交互請求。包含路由解析、業務邏輯等。主要作用是控制流程, 處理邏輯。

// 用戶控制器
func UserHandler(w http.ResponseWriter, r *http.Request) {
    // 獲取用戶ID
    id := parseId(r)  
    // 獲取用戶數據
    u := GetUser(id) 
    // 展示用戶信息頁面 
    render(w, u)
}

MVC 架構通過分離模型、視圖、控制器, 實現職責清晰, 利於並行開發。但層與層之間依賴嚴重, 不易擴展維護。

三層架構

  1. 展示層 (Web 層)

包含前端頁面、界面等展示內容。負責與最終用戶打交道, 接收用戶輸入並顯示結果。

  1. 業務邏輯層 (Service 層)

核心業務代碼和處理流程, 實現真正的業務需求。

  1. 數據訪問層 (DAO 層)

與數據庫進行交互, 實現對數據的存取操作。屏蔽上層與數據源之間的交互細節。

// Web層  
func showProducts(w http.ResponseWriter, r *http.Request) {
    // 調用Service層處理邏輯
    ps := ProductService.GetProducts()
    // 渲染頁面顯示
    render(w, ps)  
}
// Service層
type ProductService struct {
}
func (s *ProductService) GetProducts() []Product {
    // 調用DAO層獲取數據庫數據
    return ProductDAO.SelectAll()
}
// DAO層 
type ProductDAO struct {
}
func (d *ProductDAO) SelectAll() []Product {
    // 連接數據庫查詢產品數據
    var ps []Product
    return ps
}

三層架構通過分離關注點實現低耦合, 其中 Service 層爲核心, 較易測試和擴展。但依然存在層與層之間的強耦合。

SOA 架構

SOA 架構是新型的分佈式架構模式。按照職責將系統拆分爲服務層、表現層等, 服務間基於接口通信。

  1. 表現層 (表示層)

包含用戶界面和瀏覽器, 負責與用戶進行交互。

  1. 業務流程層 (orchestration 層)

處理業務流程邏輯, 組織調用各業務服務。

  3. 服務層 (services 層)

不同服務間基於接口規範進行交互, 實現系統業務能力。

  4. 數據層

包含數據庫和文件系統, 負責數據存儲。

表現層調用業務流程層, 業務流程層組織調用服務層提供的服務, 服務層與數據層交互, 完成最終業務。這種鬆散耦合的模式使架構更加靈活、複用性高。

微服務架構

微服務架構是 SOA 架構的升級版, 用細粒度、自治的服務拆分應用。服務獨立部署, 基於 HTTP 接口通信。

其優點在於服務邊界清晰, 容易維護; 技術棧靈活, 容易擴展。但分佈式系統管理複雜, 測試部署有難度。

二、項目分層常見模式

從代碼組織方式看, 常見兩種分層策略:

功能型分層

按照業務功能將系統分割, 每層爲一個業務模塊。

├── dao 層
├── service 層 
├── web 層
├── product 層
├── order 層
└── user 層

待型分層

按照開發職責劃分層, 如表現層、業務層、數據層等。每層可再細分子模塊。

├── api 接口層  
├── web 展示層
├── service 業務層 
    ├── product
    ├── order
    └── user
└── dao 數據層

三、分層模式的優缺點分析

優點

  1. 低耦合

不同層通過接口約束獨立開發, 降低耦合。

   2. 職責清晰

每層負責專一領域, 層與層交互簡單清晰。

   3. 易擴展性

新增業務只改對應層, 不影響其他層。

缺點

  1. 增加複雜度

多層之間交互協調複雜, 開發難度大。

  2. 部署依賴

層與層之間存在依賴, 部署順序敏感。

四、分層實踐指南

業務複雜度決定分層粒度

業務複雜則細分, 簡單則粗放分割。不可片面追求分層數。

高內聚低耦合原則

每層內部相關性強、與其他層依賴儘量少。

職責明確邊界清晰

每層有明確定義的職責, 接口嚴格約束邊界。

常見分層參考

表現層、業務層、邏輯層 (流程控制)、接口層 (信息傳遞)、數據層 (數據庫)、緩存層等。

五、分層實踐案例

分層項目簡介

從實際項目入手, 說明大型 Web 項目是如何分層的。該項目是一個旅遊預定平臺, 主要模塊包括:

  •  用戶模塊: 包含用戶登錄、註冊、個人中心等功能。

  • 產品模塊: 管理各類旅遊產品, 實現產品的上架和維護。

  • 交易模塊: 包含訂單、支付、售後等交易流程。

  • 內容模塊: 涉及遊記、攻略等旅遊內容體系。

技術選型與基礎設施

技術棧採用主流的前後端分離開發模式。前端使用 Vue.js 框架, 後端使用 Golang 語言開發。打通前後端技術選型爲 RESTful 風格的 HTTP API 接口。以下爲關鍵技術棧與庫:

  • 前端: Vue、Vue Router、Vuex、Element UI、Axios

  • 後端: Gin Web 框架、GORM 數據庫 ORM 庫、JWT 認證、Cobra 命令行

  • 基礎: MySQL、Redis、Elasticsearch

平臺前後端分離部署, 並使用 Docker 微服務隔離。通過 Kubernetes 實現自動擴容和故障轉移。

分層架構設計

根據技術選型和業務需求, 該平臺採用了分層架構。主要劃分爲 Web、Service、RPC 和 Data 層:

├── Web 表現層  
│   ├── api 接口                   // 提供RESTful API服務
│   └── admin 後臺管理系統        // 基於Vue.js 
├── Service 業務層        
│   ├── product 產品服務        
│   ├── order 訂單服務  
│   ├── pay 支付服務
│   └── content 內容服務
├── RPC 遠程調用層       
│   ├── user 用戶RPC        
│   ├── goods 商品RPC
│   └── inventory 庫存RPC
└── Data 數據層
      ├── mysql
      └── redis

實現分層與交互流程

從一個主流的場景入手, 說明分層架構的實際運作流程。假設一個用戶下單購買產品的流程:

  1. 用戶訪問 Web 層的訂單頁面, 傳入產品 ID 參數

  2. Web 層調用 Service 層的訂單服務接口

  3. 訂單服務從 RPC 層中獲取用戶、商品、庫存數據

  4. 訂單服務組裝訂單, 返回訂單確認信息

  5. Web 層獲得訂單確認結果, 展示訂單頁面

在整個流程中, 各層通過 RESTful API 進行交互, 並在 Kubernetes 的調度協調下實現水平擴展。

六、總結

通過本文的分析講解, 相信讀者已經掌握了大型 Web 項目的常見分層模式, 以及實際場景下的實現流程。總的來說, 選擇合適的分層策略, 對大型 Web 項目來說至關重要。最後做一個簡單總結:

  • 分層理論並無定論, 根據業務需求適當進行。靈活運用是關鍵。

  • 分離核心業務, 增強內聚性。減少層耦合, 提供擴展性。

  • 採用現代化架構與技術棧, 助力分層設計。如微服務、雲原生等。

  •    不追求層數多寡, 業務爲王。讓架構爲業務服務, 而不是相反。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/6JHT8_2U9wFM6R_rd91Brg

猜你喜歡