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