# 系統架構設計實踐

> 讓你的產品支棱起來



大家好，我是魚皮。這篇文章我們來聊一個聽起來很高大上、實則並不難的知識 —— **架構設計**。這是技術方向的朋友們必須要 **重點掌握** 的內容，也是做產品時在前期準備階段必須要做的核心工作！

這篇文章中，我會結合自己做產品的實踐經驗，依次給大家分享：什麼是架構設計？為什麼要做架構設計？怎麼做好架構設計？

無論你是用 Vibe Coding 做個人項目，還是想做一款真正的產品，掌握架構設計的方法都能讓你的系統更穩定、更易擴展。



## 一、什麼是架構設計？

想像一下，如果現在我們要蓋一座摩天大樓，需要做哪些事？

是直接讓工人去搬磚、疊磚麼？還是讓挖掘機來挖呀挖呀挖？

當然不是！

在蓋樓之前，肯定會有一名建築師，根據大樓的實際用途、地理位置、入駐需求等信息來繪製一份藍圖，藍圖上會規劃大樓的外形、內部佈局、結構細節等。

繪製好藍圖後，建築師還要確定每層樓房的框架和支撐結構，確保它們足夠穩定，不會說風一吹就塌了。

之後，建築師還要根據大樓的實際用途和需求來規劃每個樓層的用途，比如 B1 層賣小吃、1 層賣服裝奢侈品等等。這些都是在大樓動工前確認好的，不會說等工人已經搬好磚後，上面臨時決定 “這一層我們不蓋了！”。

做軟件（網站）開發也是一樣，在我們 “碼農” 實際動手寫代碼前，往往會有一個經驗豐富的架構師，先繪製一份 **架構設計圖** ，規劃好整個系統的全貌、系統規模、系統的結構。

架構師還要將系統按照功能和需求劃分為各個模塊，比如商城系統劃分為用戶模塊、商品模塊、訂單模塊等。並且確定各個模塊的作用和交互協作方式，保證整個系統能夠正常運作。不會出現一個功能故障，整個系統全部癱瘓的情況。

有朋友可能會問了，那架構設計和之前講過的技術選型有什麼區別呢？

還是拿蓋樓來舉例，其實很好區分。架構設計是規劃如何蓋樓、每層樓怎麼安排；而技術選型是在完成架構設計之後，選擇具體用什麼材料、工具或方法來完成蓋樓。二者是相輔相成的。

用一句話來概括， **架構設計是構建穩固、可靠和可擴展系統的過程** 。

而我們熟知的崗位 “架構師”，就是負責完成系統架構設計，確保系統穩固、可靠、可擴展的人。

在大家的印象裡，可能覺得架構師是很高大上的角色。但我個人認為，只要你能夠獨立完成一個系統的架構設計，能夠把複雜的系統拆分為模塊化、可擴展的組件，你就已經是架構師了。

> 所以 97 年就成為架構師還是有一定合理性的。



## 二、為什麼要做架構設計？

其實從上面蓋樓的例子中，相信大家已經能大致感受到架構設計的重要性了。

如果在蓋樓前，不先設計好大樓的結構，那麼就難以保證大樓的安全和穩定性，風一吹整層樓就塌了。同理，在開發網站前，如果不先設計好網站的整體架構（比如不添加防火牆），後面可能一遇到網絡攻擊，整個系統就都無法訪問了。這是架構設計的核心目標：保證系統地 **穩定性、可靠性和可用性** 。換句話說，起碼要讓系統能跑。

> 不過沒關係，系統和人只要有一個能跑就行。

進行架構設計的另一個重要原因，是系統的 **可擴展性** 。打個比方，建好的商場大樓非常受歡迎，我們想在蓋好的大樓上再增加幾層樓，那麼必須在最初就確保大樓的結構可以支撐額外的重量、能夠線性地往上疊加。而不是像下圖一樣：

![](https://pic.yupi.icu/1/image-20230711174331231.png)

同理，如果想要網站能夠應對日益增長的用戶量和新業務功能，也必須有一個良好的架構設計來支持。不要出現網站用戶數增多後，網站無法訪問的情況。

此外，好的架構設計也能夠提升系統的性能和用戶體驗。比如在商場內，合理安排電梯數和電梯的位置，就能幫助用戶快速到達想去的店鋪；而網站的架構設計如果合理，比如用更少的分層完成同樣的功能，那麼就能更快地響應用戶的操作。

總之，想要讓網站像摩天大樓一樣支棱起來，前期的架構設計是必要的！



## 三、怎麼做好架構設計？

“能完成架構設計” 和 “能做好架構設計” 還是有很大的區別的，下面我會結合自己多年的學習經驗、以及魚聰明 AI 的架構設計，分享一些我認為的做好架構設計的關鍵。



### 掌握方法論

做好架構設計的前提是具備一定的理論知識。所謂方法論，是指前人通過總結和歸納形成的一套 **特定問題的解決方案** 。就像我們做數學題的時候知道套用公式來解題一樣。

有很多對架構設計有幫助的方法論。比如初學編程時接觸到的面向對象設計，軟件開發基本原則、23 種經典設計模式、SOA 面向服務架構、DDD 領域驅動設計等等。掌握這些方法論背後的思想，是做好架構設計的 **前提** 。

舉個例子，面向對象設計的五個基本原則 SOLID 中，有一點是 **單一職責原則** ，是指：一個類或模塊應該有且只有一個單一的責任，每個類或模塊應該只關注於一個特定的功能或職責。換句話說，每個模塊應該只做好自己的事。

我們在進行魚聰明 AI 網站的架構設計時，首先就遵循了單一職責原則，將系統 **按照功能拆分** 為用戶模塊、助手模塊、對話模塊、繪畫模塊、支付模塊等。這樣一來，當我們想要擴展對話相關的功能時，就不用改動助手模塊的代碼。也可以將不同的模塊交給團隊中不同的同學進行開發。

![](https://pic.yupi.icu/1/image-20230711192728792.png)



### 學習經典架構

前人栽樹，後人乘涼。在我們沒有能力自主設計一套架構前，不妨站在巨人的肩膀上，學習一些前人總結和實踐過的經典架構。

簡單舉幾個例子：



#### 1）分層架構

首先是最經典的分層架構，把系統分為多個不同的層，每一層都有特定的功能和職責，且只和自己的直接上層與直接下層 “打交道”。

比如開發 Java 企業級後端項目時常用的三層架構，將系統分為表示層、業務邏輯層、數據訪問層。

表示層負責接受用戶請求，把用戶輸入的參數傳遞給業務邏輯層進行處理，並返回數據、頁面等內容給用戶。

業務邏輯層負責處理複雜的業務邏輯，比如調用 AI 能力完成智能對話、再進行加工處理、調用數據訪問層將結果存到數據庫中，也是我們做系統主要開發的部分。

數據訪問層負責操作底層的數據源，比如對數據庫、文件、緩存等進行增刪改查。

![](https://pic.yupi.icu/1/image-20230711194035810.png)

分層架構的適用性非常廣泛，絕大多數企業級系統都可以把分層架構作為基礎的架構設計。

計算機網絡也是採用了經典的分層架構，OSI 七層參考模型中，把計算機網絡自底向上分為了物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層和應用層。每個層只處理特定的功能，比如數據傳輸、數據的路由；層與層之間通過接口（或者叫協議）進行通信。

我們的魚聰明 AI 後端也是使用了分層架構，只不過在原有的三層架構基礎上，在業務邏輯層和數據訪問層之間又增加了 Manager 層（通用邏輯層），將業務邏輯層經常調用的 **公共邏輯** 提取出來，便於複用。



#### 2）微服務架構

微服務的 “微” 是相對於 “單體” 項目的概念。微服務架構是指將完整的大型系統拆分為多個微小的、自治的服務，每個服務都能獨立部署、獨立擴展和維護、互不影響，服務之間通過網絡通信進行協作，從而實現原本大型系統的完整功能。

我們的魚聰明 AI 就用到了微服務架構。前面也提到了，我們首先將系統按照功能劃分為了多個模塊。

但如果我們只是按邏輯劃分出了這些模塊，實際上所有的代碼仍然部署在同一個項目中，打包後仍然是一個可執行文件。那麼所有模塊要麼都在運行、要麼都在宕機，本質上還是單體項目。一個服務崩了，可能導致整個項目都無法運行！

![](https://pic.yupi.icu/1/image-20230711200006355.png)

所以我們將部分重要模塊（比如支付模塊）的代碼從原本項目中抽離，單獨作為了一個服務，並且還啟動了備份，從而保證了支付業務的穩定性。說什麼也不能影響收入對不對~

![](https://pic.yupi.icu/1/image-20230711200339275.png)

能夠實現微服務設計的框架也很多，比如 Java 的 Spring Cloud、Apache Dubbo 等。但是學習微服務更重要的是思想，即 **如何合理地拆分服務** 。

並不是所有的項目都要把所有功能都拆分成子服務的，像我們的魚聰明 AI，也沒有把用戶模塊和助手模塊進行分離，原因是這兩個模塊的業務都不複雜、並且存在緊密的依賴，拆分後反而不利於維護了。



#### 3）事件驅動架構

在事件驅動架構中，各模塊之間是通過事件（或者消息）的 **發布訂閱模型** 進行通信的。

舉個最簡單的例子，有兩個模塊：支付模塊和會員模塊，當用戶支付成功後，支付模塊會給會員模塊發送一個 “XX 用戶支付成功” 的事件，會員模塊收到這個時間後，給對應的用戶開通會員即可。

![](https://pic.yupi.icu/1/image-20230711202025430.png)

但實際運用時，事件驅動架構往往會引入一個 **事件總線** ，相當於一個中介，負責集中收集和下發事件。

比如魚聰明 AI 的對話功能和繪畫功能就採用了事件驅動架構。當上游返回 AI 回復的消息或生成的圖片後，會發送 “成功” 消息到事件總線，然後事件總線再將這些消息分別轉發給對應的模塊去處理。如下圖：

![](https://pic.yupi.icu/1/image-20230711201650066.png)

這樣一來，各模塊之間就實現了解耦（互不影響）。假如後續我想新增多個對話模塊，只要將該模塊和事件總線建立連接即可，不會影響到其他模塊的運行。



### 關注需求和痛點

我們在學習過程中接觸到的項目，幾乎都可以套用上述幾種主流的架構。但具體應該如何做好架構設計，一定是要結合實際的需求和要解決的痛點去分析。

以魚聰明 AI 為例，前面也提到了，我們首先就按照需求（功能）將系統拆分為了多個模塊，然後將部分模塊單獨封裝為服務進行獨立部署。

但架構設計並沒有到此結束，接下來分析下我們這個網站的痛點，主要是 “安全性” 和 “訪問互通性” 這兩個方面。



#### 安全性

根據我之前的翻車經歷，網站上線後一定會遭受各種攻擊！所以，我們在原有的分層架構基礎上進行擴展，在表示層前增加高防服務器和 Nginx 防火牆，在表示層後增加了分佈式限流和權限校驗處理。

> 在表示層前添加集中的分佈式限流和權限校驗處理也是合理的，以實際需求為主。

改進過後的架構如圖：

![](https://pic.yupi.icu/1/image-20230711203808233.png)

如果用戶在短時間內用不法手段頻繁向系統發送請求，那麼在限流層就會被攔截，不會進行後續的業務邏輯處理。



#### 訪問互通性

我們的 AI 繪畫模塊需要依賴第三方服務來完成部分功能，但是第三方服務並不支持訪問跨地區訪問，網絡無法互通，怎麼辦呢？

這時，我們有 2 個方案可選：

1）把整個系統都放到第三方服務所在地區去部署。如下圖：

![](https://pic.yupi.icu/1/image-20230711205545871.png)

2）在 AI 繪畫模塊和第三方服務之間搭建一個代理，讓代理幫忙發送和響應請求。如下圖：

![](https://pic.yupi.icu/1/image-20230711210049633.png)

如果是你的話，會選擇哪個呢？

方案 1 的好處是方便，但缺點也很明顯，整個系統都移到其他地區，也就意味著原本地區的用戶訪問系統的所有功能，速度都會變慢。

方案 2 的好處是只需要改變 AI 繪畫模塊發送的請求地址信息，而系統的其他功能（比如查詢用戶信息）性能完全不變；缺點就是要搭建額外的服務、增加了實現成本。

最終，我們選擇了方案 2 並改進了架構設計，增加一點實現成本來換取更好的用戶體驗。

通過這個例子，我想告訴大家的是：**沒有絕對完美的架構設計** 。和技術選型一樣，我們做架構設計的目標是尋找實際情況下的最優解。



### 超前思考

我們在做架構設計時，要養成超前思考的習慣，不能只針對現狀，而是要提前預見系統未來可能的發展，預留足夠的 **可擴展** 空間。

比如我們的魚聰明 AI，雖然在最開始只有 100 個內測用戶，但我們會按照 1 萬個、甚至 10 萬個用戶的標準去設計系統，所以使用了分佈式存儲中間件而不是本地服務器來存儲用戶登錄 Session；雖然早期歷史對話消息數只積累了 5 萬條，但我們提前設計了消息過期淘汰機制、並且將消息模塊解耦，防止消息數達到百萬、千萬時影響系統的查詢性能。

當然，超前思考也要有個度。要避免過度設計，不要提前去考慮絕對不可能發生的事情、不要提前去消耗遠超增長的成本。



---



最後，要注意的是，**架構設計是一個持續的過程**，要根據業務的實際情況不斷優化迭代。比如發現業務收益不高時，通過簡化架構來降低成本；業務高速發展時，及時擴容服務來應對增長。



## 寫在最後

架構設計是做好產品的重要基礎。好的架構設計可以讓系統更穩定、更易擴展、性能更好。

記住這幾個關鍵點：

1. 架構設計要掌握基本的方法論和設計模式
2. 要學習經典架構，站在巨人的肩膀上
3. 要關注實際需求和痛點，而不是為了設計而設計
4. 要有超前思考的意識，預留擴展空間
5. 架構設計是持續優化的過程

在 Vibe Coding 時代，AI 可以幫你快速生成代碼，但是系統的整體架構設計，仍然需要你自己的思考和規劃。只要有架構設計的意識和足夠的積累，人人都能成為架構師！




## 推薦資源

1）魚皮 AI 導航網站：[AI 資源大全、最新 AI 資訊、免費 AI 教程](https://ai.codefather.cn)

2）編程導航學習圈：[學習路線、編程教程、實戰項目、求職寶典、交流答疑](https://www.codefather.cn)

3）程序員面試八股文：[實習/校招/社招高頻考點、企業真題解析](https://www.mianshiya.com)

4）程序員寫簡歷神器：[專業模板、豐富例句、直通面試](https://www.laoyujianli.com)

5）1 對 1 模擬面試：[實習/校招/社招面試拿 Offer 必備](https://ai.mianshiya.com)