接上一篇文章《為什麼測試要了解系統架構》的內容，這篇聊聊如何掌握基礎的系統架構知識。
從我個人的角度來說，所謂的系統架構，就是對軟體系統整體結構的抽象設計。如何理解這句話呢？舉個生活中常見的例子：如何蓋一座房子？
正常的做法是先勘探地質，然後對房子進行設計(房屋大小朝向、門窗尺寸用料、預算多少)，最後才是制定對應的施工方案，開工建設。軟體的系統架構也可以用類似的角度理解。
換個角度理解，企業為了達成某個商業目標(願景)，提出了要建設一個軟體系統(達成方式)，因此才有了各種各樣的業務需求(達成過程的細節)。
軟體系統是業務需求實現的載體，系統架構是對業務的抽象理解和實現設計，是對軟體產品進行分解再組合的過程。透過將軟體產品分解為不同的元件、模組，重新組織他們的互動邏輯和鏈路，最終形成一個軟體產品。
從軟體研發測試流程的角度來看，業務提出訴求，產品設計需求，研發用技術實現，測試針對系統各功能模組進行驗證，最後驗收透過釋出上線，這個過程和系統架構設計是緊密相關的。
不同的業務需求有不同的分類，比如營銷、訂單、支付、庫存。遇到這些業務需求時，首先要對需求進行識別拆分，即將不同的需求分組到對應的業務模組(誰來負責技術實現)。
其次技術實現要考慮實現的難易成本和業務情況(影響技術選型)，比如初創企業業務量小，需要快速迭代，往往選擇LNMP全家桶。如果是業務複雜且業務量較大，這個時候選擇Java全家桶就比較多。
技術實現過程中，要考慮資料儲存、程式碼管理、服務部署和釋出，與之對應的就是資料庫選型、程式碼倉庫選型、釋出系統(或持續整合流水線)構建。
到了測試環節，會用到各種測試方法和工具，這個時候諸如Postman、JMeter就開始登上舞臺。不同業務模組對應的應用服務之前也會有依賴關係，服務之間的請求互動需要考慮通訊協議，於是HTTP、RPC框架就要發揮作用了。
為了服務釋出上線後更穩定的執行，同時統計各種業務和技術指標，需要完善的監控工具來及時跟蹤和發現問題，這個時候諸如Cat、Jaeger、SkyWalking等工具元件就開始工作。
還有其他基礎的技術平臺如運維平臺，程式碼倉庫和需求管理平臺等，這些都是系統架構設計中需要考慮到的。
如上圖所示，其中包含了我們常見的系統架構設計中常見的技術元件和工具。
當然，系統架構設計不僅僅是這些，還有設計模式(如單例模式、工廠模式)，所謂的設計模式其實是一種系統架構設計的指導思想和方法論。
從本質上來說，架構是一種決策，即軟體系統如何成型，至於採用何種設計模式指導，選擇哪些技術元件則是設計領域。
如上圖中的程式語言選擇、框架選擇、各種中介軟體和基礎服務選擇，都是設計的一部分。
軟體系統架構設計，很重要的一點是搞清楚哪些部分最重要，以及這些重要部分如何實現。
這篇文章是對系統架構基礎知識的一個羅列說明，下篇文章，聊聊技術同學如何由點及面的瞭解並掌握這些知識。