接上篇文章，這篇文章聊聊技術同學如何由點及面的瞭解並掌握系統架構知識。
大家可以先回想一下，我們入職一家新公司做技術工作，一般都是如何開展工作的。
首先，我們需要了解團隊和專案的技術規範和迭代釋出上線流程。其次，還要了解自己所在崗位負責哪些業務，對應的溝通合作物件是誰。
再次，還需要將專案程式碼下載到本地，進行程式碼走查熟悉程式碼和相關邏輯。如果是測試同學，一般會從最近幾個版本的需求和測試用例入手，對自己負責部分和模組邊界有大致的瞭解。
最後，最好是review一下最近線上出現的一些問題和歷史版本比較嚴重的線上故障，對其背後的根因和覆盤最佳化方案做進一步瞭解。
總結一下，就是從流程+業務+程式碼(用例)+線上問題四個維度，對自己即將開展的工作進行全面瞭解。換個角度，要了解並掌握系統架構知識，也可以從這幾個維度來展開。
其中研發規範和迭代釋出流程屬於通用部分，雖然在不同公司稍顯差異，但整體大差不差，這裡不展開介紹。
本文以測試崗位視角(假設入職一家新公司，主要負責訂單模組的測試工作)，為大家介紹如何從業務、技術和線上問題三個方面來了解系統架構基礎知識。
訂單業務主要包含如下幾個部分：
即正向流程(建立訂單)和逆向流程(取消訂單)，以及延伸的如訂單列表、訂單詳情。
但僅僅瞭解訂單的業務邏輯是不夠的，因為訂單業務有很多上下游依賴部分，比如營銷增長業務的優惠券和各種活動，比如訂單支付涉及到的三方支付，比如庫存和供應鏈業務的物流資訊等。
與這些依賴業務對應的，則是不同的業務服務，以及服務間的呼叫關係。如果你不瞭解這些，測試過程中遇到報錯，你都不知道問題根因是什麼，提BUG都顯得底氣不足。
再進一步，瞭解了訂單業務和其上下游依賴之外，還可以瞭解整個的業務流，即我們所說的端到端測試，如下圖。
接著從技術角度來展開分享。
如圖一所示，要對訂單應用展開介面測試，那我們勢必要了解訂單服務的介面定義，請求入參的各項Key對應的Value是什麼，分別是呼叫哪個業務應用獲取到的資料。
建立的訂單資料是否落庫(表結構/對應欄位)，是否命中快取(秒殺業務)，訂單狀態是否正確變更(支付成功)，APP是否有正常的訊息推送(呼叫push服務或者notice服務)。
除了上述內容，還要考慮使用者下單時的登入驗籤是否透過。如果訂單應用請求報500的狀態碼，就要檢查請求的URL是否正確或者服務是否啟動並註冊成功(註冊中心和配置中心)。
如果請求報錯，就要根據報錯內容判斷是否是其他依賴應用未啟動或者引數有誤(檢視日誌)。如果是很複雜的一個依賴呼叫關係，還需要藉助鏈路追蹤(Trace)來定位請求的哪個環節出了問題。
有些業務不要求資料的實時一致性，在測試時還要檢視訊息佇列，驗證訂單訊息的生成和訊息狀態。
結合業務和技術，並加以梳理和總結，就可以對系統架構有大致瞭解。如下圖所示，是一個簡易的微服務系統架構圖：
第三部分，從線上問題的角度來展開分享。
為什麼要提到線上問題呢，主要原因有這幾個方面。首先，大部分線上問題都是由於釋出和線上變更導致的。
其次，引起線上問題的因素很多，因此需要建立完善強大的線上監控體系；最後，線上問題發生後的修復和覆盤最佳化，也是深入瞭解系統架構細節很好的一個方式。
要降低線上問題出現的頻率和影響範圍，就涉及到穩定性保障領域。在穩定性保障中，比較好的技術實踐有全鏈路壓測、混沌工程，而這些技術實踐都涉及到很廣泛的業務，以及技術細節。
要快速發現並修復線上問題，需要很好的監控工具，而好的監控工具一定是以業務穩定性為出發點，並涉及到很多的技術細節，如下圖所示。
且線上問題背後隱含著一個很重要的因素，即線上的業務防資損。要做好業務防資損，同樣需要對業務有深入的理解，並且要從系統整體架構層面來進行最佳化預防。
最後總結一下，要由點及面的瞭解並掌握系統架構知識，可以從如下三個角度切入：
- 從業務角度，瞭解端到端業務流，背後的業務模組，對應的服務呼叫關係。
- 從技術角度，資料輸入輸出，依賴誰，被誰依賴，為什麼報錯，日誌排查。
- 從線上問題角度，監控體系，業務防資損，故障覆盤最佳化。
結合這幾個方面，在日常工作中多梳理總結，就可以對系統架構有基礎的瞭解和掌握。