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