yupi-translate-app[bot]
15 KiB
系統架構設計實踐
讓你的產品支棱起來
大家好，我是魚皮。這篇文章我們來聊一個聽起來很高大上、實則並不難的知識 —— 架構設計。這是技術方向的朋友們必須要 重點掌握 的內容，也是做產品時在前期準備階段必須要做的核心工作！
這篇文章中，我會結合自己做產品的實踐經驗，依次給大家分享：什麼是架構設計？為什麼要做架構設計？怎麼做好架構設計？
無論你是用 Vibe Coding 做個人項目，還是想做一款真正的產品，掌握架構設計的方法都能讓你的系統更穩定、更易擴展。
一、什麼是架構設計？
想像一下，如果現在我們要蓋一座摩天大樓，需要做哪些事？
是直接讓工人去搬磚、疊磚麼？還是讓挖掘機來挖呀挖呀挖？
當然不是！
在蓋樓之前，肯定會有一名建築師，根據大樓的實際用途、地理位置、入駐需求等信息來繪製一份藍圖，藍圖上會規劃大樓的外形、內部佈局、結構細節等。
繪製好藍圖後，建築師還要確定每層樓房的框架和支撐結構，確保它們足夠穩定，不會說風一吹就塌了。
之後，建築師還要根據大樓的實際用途和需求來規劃每個樓層的用途，比如 B1 層賣小吃、1 層賣服裝奢侈品等等。這些都是在大樓動工前確認好的，不會說等工人已經搬好磚後，上面臨時決定 “這一層我們不蓋了！”。
做軟件（網站）開發也是一樣，在我們 “碼農” 實際動手寫代碼前，往往會有一個經驗豐富的架構師，先繪製一份 架構設計圖 ，規劃好整個系統的全貌、系統規模、系統的結構。
架構師還要將系統按照功能和需求劃分為各個模塊，比如商城系統劃分為用戶模塊、商品模塊、訂單模塊等。並且確定各個模塊的作用和交互協作方式，保證整個系統能夠正常運作。不會出現一個功能故障，整個系統全部癱瘓的情況。
有朋友可能會問了，那架構設計和之前講過的技術選型有什麼區別呢？
還是拿蓋樓來舉例，其實很好區分。架構設計是規劃如何蓋樓、每層樓怎麼安排；而技術選型是在完成架構設計之後，選擇具體用什麼材料、工具或方法來完成蓋樓。二者是相輔相成的。
用一句話來概括， 架構設計是構建穩固、可靠和可擴展系統的過程 。
而我們熟知的崗位 “架構師”，就是負責完成系統架構設計，確保系統穩固、可靠、可擴展的人。
在大家的印象裡，可能覺得架構師是很高大上的角色。但我個人認為，只要你能夠獨立完成一個系統的架構設計，能夠把複雜的系統拆分為模塊化、可擴展的組件，你就已經是架構師了。
所以 97 年就成為架構師還是有一定合理性的。
二、為什麼要做架構設計？
其實從上面蓋樓的例子中，相信大家已經能大致感受到架構設計的重要性了。
如果在蓋樓前，不先設計好大樓的結構，那麼就難以保證大樓的安全和穩定性，風一吹整層樓就塌了。同理，在開發網站前，如果不先設計好網站的整體架構（比如不添加防火牆），後面可能一遇到網絡攻擊，整個系統就都無法訪問了。這是架構設計的核心目標：保證系統地 穩定性、可靠性和可用性 。換句話說，起碼要讓系統能跑。
不過沒關係，系統和人只要有一個能跑就行。
進行架構設計的另一個重要原因，是系統的 可擴展性 。打個比方，建好的商場大樓非常受歡迎，我們想在蓋好的大樓上再增加幾層樓，那麼必須在最初就確保大樓的結構可以支撐額外的重量、能夠線性地往上疊加。而不是像下圖一樣：
同理，如果想要網站能夠應對日益增長的用戶量和新業務功能，也必須有一個良好的架構設計來支持。不要出現網站用戶數增多後，網站無法訪問的情況。
此外，好的架構設計也能夠提升系統的性能和用戶體驗。比如在商場內，合理安排電梯數和電梯的位置，就能幫助用戶快速到達想去的店鋪；而網站的架構設計如果合理，比如用更少的分層完成同樣的功能，那麼就能更快地響應用戶的操作。
總之，想要讓網站像摩天大樓一樣支棱起來，前期的架構設計是必要的！
三、怎麼做好架構設計？
“能完成架構設計” 和 “能做好架構設計” 還是有很大的區別的，下面我會結合自己多年的學習經驗、以及魚聰明 AI 的架構設計，分享一些我認為的做好架構設計的關鍵。
掌握方法論
做好架構設計的前提是具備一定的理論知識。所謂方法論，是指前人通過總結和歸納形成的一套 特定問題的解決方案 。就像我們做數學題的時候知道套用公式來解題一樣。
有很多對架構設計有幫助的方法論。比如初學編程時接觸到的面向對象設計，軟件開發基本原則、23 種經典設計模式、SOA 面向服務架構、DDD 領域驅動設計等等。掌握這些方法論背後的思想，是做好架構設計的 前提 。
舉個例子，面向對象設計的五個基本原則 SOLID 中，有一點是 單一職責原則 ，是指：一個類或模塊應該有且只有一個單一的責任，每個類或模塊應該只關注於一個特定的功能或職責。換句話說，每個模塊應該只做好自己的事。
我們在進行魚聰明 AI 網站的架構設計時，首先就遵循了單一職責原則，將系統 按照功能拆分 為用戶模塊、助手模塊、對話模塊、繪畫模塊、支付模塊等。這樣一來，當我們想要擴展對話相關的功能時，就不用改動助手模塊的代碼。也可以將不同的模塊交給團隊中不同的同學進行開發。
學習經典架構
前人栽樹，後人乘涼。在我們沒有能力自主設計一套架構前，不妨站在巨人的肩膀上，學習一些前人總結和實踐過的經典架構。
簡單舉幾個例子：
1）分層架構
首先是最經典的分層架構，把系統分為多個不同的層，每一層都有特定的功能和職責，且只和自己的直接上層與直接下層 “打交道”。
比如開發 Java 企業級後端項目時常用的三層架構，將系統分為表示層、業務邏輯層、數據訪問層。
表示層負責接受用戶請求，把用戶輸入的參數傳遞給業務邏輯層進行處理，並返回數據、頁面等內容給用戶。
業務邏輯層負責處理複雜的業務邏輯，比如調用 AI 能力完成智能對話、再進行加工處理、調用數據訪問層將結果存到數據庫中，也是我們做系統主要開發的部分。
數據訪問層負責操作底層的數據源，比如對數據庫、文件、緩存等進行增刪改查。
分層架構的適用性非常廣泛，絕大多數企業級系統都可以把分層架構作為基礎的架構設計。
計算機網絡也是採用了經典的分層架構，OSI 七層參考模型中，把計算機網絡自底向上分為了物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層和應用層。每個層只處理特定的功能，比如數據傳輸、數據的路由；層與層之間通過接口（或者叫協議）進行通信。
我們的魚聰明 AI 後端也是使用了分層架構，只不過在原有的三層架構基礎上，在業務邏輯層和數據訪問層之間又增加了 Manager 層（通用邏輯層），將業務邏輯層經常調用的 公共邏輯 提取出來，便於複用。
2）微服務架構
微服務的 “微” 是相對於 “單體” 項目的概念。微服務架構是指將完整的大型系統拆分為多個微小的、自治的服務，每個服務都能獨立部署、獨立擴展和維護、互不影響，服務之間通過網絡通信進行協作，從而實現原本大型系統的完整功能。
我們的魚聰明 AI 就用到了微服務架構。前面也提到了，我們首先將系統按照功能劃分為了多個模塊。
但如果我們只是按邏輯劃分出了這些模塊，實際上所有的代碼仍然部署在同一個項目中，打包後仍然是一個可執行文件。那麼所有模塊要麼都在運行、要麼都在宕機，本質上還是單體項目。一個服務崩了，可能導致整個項目都無法運行！
所以我們將部分重要模塊（比如支付模塊）的代碼從原本項目中抽離，單獨作為了一個服務，並且還啟動了備份，從而保證了支付業務的穩定性。說什麼也不能影響收入對不對~
能夠實現微服務設計的框架也很多，比如 Java 的 Spring Cloud、Apache Dubbo 等。但是學習微服務更重要的是思想，即 如何合理地拆分服務 。
並不是所有的項目都要把所有功能都拆分成子服務的，像我們的魚聰明 AI，也沒有把用戶模塊和助手模塊進行分離，原因是這兩個模塊的業務都不複雜、並且存在緊密的依賴，拆分後反而不利於維護了。
3）事件驅動架構
在事件驅動架構中，各模塊之間是通過事件（或者消息）的 發布訂閱模型 進行通信的。
舉個最簡單的例子，有兩個模塊：支付模塊和會員模塊，當用戶支付成功後，支付模塊會給會員模塊發送一個 “XX 用戶支付成功” 的事件，會員模塊收到這個時間後，給對應的用戶開通會員即可。
但實際運用時，事件驅動架構往往會引入一個 事件總線 ，相當於一個中介，負責集中收集和下發事件。
比如魚聰明 AI 的對話功能和繪畫功能就採用了事件驅動架構。當上游返回 AI 回復的消息或生成的圖片後，會發送 “成功” 消息到事件總線，然後事件總線再將這些消息分別轉發給對應的模塊去處理。如下圖：
這樣一來，各模塊之間就實現了解耦（互不影響）。假如後續我想新增多個對話模塊，只要將該模塊和事件總線建立連接即可，不會影響到其他模塊的運行。
關注需求和痛點
我們在學習過程中接觸到的項目，幾乎都可以套用上述幾種主流的架構。但具體應該如何做好架構設計，一定是要結合實際的需求和要解決的痛點去分析。
以魚聰明 AI 為例，前面也提到了，我們首先就按照需求（功能）將系統拆分為了多個模塊，然後將部分模塊單獨封裝為服務進行獨立部署。
但架構設計並沒有到此結束，接下來分析下我們這個網站的痛點，主要是 “安全性” 和 “訪問互通性” 這兩個方面。
安全性
根據我之前的翻車經歷，網站上線後一定會遭受各種攻擊！所以，我們在原有的分層架構基礎上進行擴展，在表示層前增加高防服務器和 Nginx 防火牆，在表示層後增加了分佈式限流和權限校驗處理。
在表示層前添加集中的分佈式限流和權限校驗處理也是合理的，以實際需求為主。
改進過後的架構如圖：
如果用戶在短時間內用不法手段頻繁向系統發送請求，那麼在限流層就會被攔截，不會進行後續的業務邏輯處理。
訪問互通性
我們的 AI 繪畫模塊需要依賴第三方服務來完成部分功能，但是第三方服務並不支持訪問跨地區訪問，網絡無法互通，怎麼辦呢？
這時，我們有 2 個方案可選：
1）把整個系統都放到第三方服務所在地區去部署。如下圖：
2）在 AI 繪畫模塊和第三方服務之間搭建一個代理，讓代理幫忙發送和響應請求。如下圖：
如果是你的話，會選擇哪個呢？
方案 1 的好處是方便，但缺點也很明顯，整個系統都移到其他地區，也就意味著原本地區的用戶訪問系統的所有功能，速度都會變慢。
方案 2 的好處是只需要改變 AI 繪畫模塊發送的請求地址信息，而系統的其他功能（比如查詢用戶信息）性能完全不變；缺點就是要搭建額外的服務、增加了實現成本。
最終，我們選擇了方案 2 並改進了架構設計，增加一點實現成本來換取更好的用戶體驗。
通過這個例子，我想告訴大家的是：沒有絕對完美的架構設計 。和技術選型一樣，我們做架構設計的目標是尋找實際情況下的最優解。
超前思考
我們在做架構設計時，要養成超前思考的習慣，不能只針對現狀，而是要提前預見系統未來可能的發展，預留足夠的 可擴展 空間。
比如我們的魚聰明 AI，雖然在最開始只有 100 個內測用戶，但我們會按照 1 萬個、甚至 10 萬個用戶的標準去設計系統，所以使用了分佈式存儲中間件而不是本地服務器來存儲用戶登錄 Session；雖然早期歷史對話消息數只積累了 5 萬條，但我們提前設計了消息過期淘汰機制、並且將消息模塊解耦，防止消息數達到百萬、千萬時影響系統的查詢性能。
當然，超前思考也要有個度。要避免過度設計，不要提前去考慮絕對不可能發生的事情、不要提前去消耗遠超增長的成本。
最後，要注意的是，架構設計是一個持續的過程，要根據業務的實際情況不斷優化迭代。比如發現業務收益不高時，通過簡化架構來降低成本；業務高速發展時，及時擴容服務來應對增長。
寫在最後
架構設計是做好產品的重要基礎。好的架構設計可以讓系統更穩定、更易擴展、性能更好。
記住這幾個關鍵點：
- 架構設計要掌握基本的方法論和設計模式
- 要學習經典架構，站在巨人的肩膀上
- 要關注實際需求和痛點，而不是為了設計而設計
- 要有超前思考的意識，預留擴展空間
- 架構設計是持續優化的過程
在 Vibe Coding 時代，AI 可以幫你快速生成代碼，但是系統的整體架構設計，仍然需要你自己的思考和規劃。只要有架構設計的意識和足夠的積累，人人都能成為架構師！
推薦資源
1）魚皮 AI 導航網站：AI 資源大全、最新 AI 資訊、免費 AI 教程
2）編程導航學習圈：學習路線、編程教程、實戰項目、求職寶典、交流答疑
3）程序員面試八股文：實習/校招/社招高頻考點、企業真題解析
4）程序員寫簡歷神器：專業模板、豐富例句、直通面試
5）1 對 1 模擬面試：實習/校招/社招面試拿 Offer 必備