如何熟悉一個系統?（內含知識大圖）

作者 | 唐志龍（鯤龍）  阿里巴巴高階開發工程師

導讀：本文總結了熟悉系統主要分三部分：業務學習、技術學習、實戰。每部分會梳理一些在學習過程中需要解答的問題，這些問題隨著經驗的積累需要逐步補充完善。

前言

開發人員經常會面臨下面一些場景：

• 新人入職，需要學習已有系統，作為 landing 的一部分，如何學習？

• 被拉過去參與一個陌生系統的迭代開發或者系統維護（bugfix），如何快速上手？

• 同事離職或轉崗，需要把系統交接給你，怎麼去接？ 內心 os：這是一口鍋嗎？

這樣的場景多了，就需要去梳理常見問題以及應對方法，方便後續遇到類似場景可以快速應對。

業務學習

業務學習就是從業務角度去學習系統，我們需要了解系統的客戶是誰、使用人是誰、帶來了什麼價值，系統提供了哪些功能等。

不清楚業務，就等於不知道系統在幹什麼。技術是為業務落地而服務，清楚了業務才知道怎樣用技術更好地服務業務，所以業務學習是熟悉一個系統的首要任務。這塊主要的學習方式有跟產品、運營、開發溝通，學習產品設計文件文件、PRD、自己使用系統，還有一些常見圖，如產品功能架構圖、業務流程圖、功能樹，用例圖等。

常見問題：

• 系統所在行業的情況是怎樣？

• 系統的目標使用者是誰？比如是給公司高層做決策用？給運營或客服用？還是網際網路使用者用？

• 平均有多少人在使用？高峰期有多少人在用？

• 系統有什麼業務價值？有哪些指標可以衡量系統業務價值？

• 系統有哪些功能模組？

• 系統有哪些領域概念？梳理下系統的領域模型；

• 系統的關鍵業務流程有哪些？關鍵業務流程是怎樣？

• 系統的非功能性需求有哪些？如效能、質量、擴充套件性、安全性等；

• 系統未來的發展規劃是怎樣？

技術學習

技術學習主要學習系統的架構、如何實現、系統的運維等。描述一個系統的架構有五檢視方法論。

五檢視分別是：

• 邏輯架構

• 開發架構

• 執行架構

• 物理架構

• 資料架構

1. 邏輯架構

邏輯架構著重考慮功能需求，系統應當向使用者提供什麼樣的服務，關注點主要是行為或職責的劃分。

常用表達圖形，靜態圖有包圖、類圖、物件圖；動態圖有序列圖、協作圖、狀態圖、活動圖。邏輯架構的核心設計任務是模組劃分、介面定義、領域模型細化。

常見問題：

• 有哪些子系統或模組？系統之間是什麼樣的關係？

• 對外上下游介面有哪些？對接人是誰？

• 關鍵業務流程怎麼實現的？用類圖、序列圖等方式表達出來。

2. 開發架構

開發架構關主要關注系統原始碼、第三方 SDK、使用的框架、中介軟體、工具包。

常見問題：

• 程式碼在哪？

• 包怎麼劃分的？怎麼分層？如 mvc、controller-service-dao；

• 用了什麼框架，如 ssh、dubbo；

• 用了哪些工具包？如 apache commons、guava；

• 用了哪些中介軟體？如 metaq、tair、schedulerX、Diamond；

• 依賴哪些平臺？如許可權平臺、流程引擎等。

3. 執行架構

執行架構的著重考慮執行期質量屬性，關注點是系統的併發、同步、通訊等問題，這勢必涉及到程式、執行緒、物件等執行時概念，以及相關的併發、同步、通訊等。

常見問題：

• 系統能支撐多少 qps？峰值 qps 多少？

• 與上下游系統怎麼互動的？rpc？http？同步還是非同步？

4. 物理架構

物理架構的設計著重考慮安裝和部署需求，關注點是目標程式及其依賴的執行庫和系統軟體最終如何安裝或部署到物理機器，以及如何部署機器和網路來配合軟體系統的可靠性、可伸縮性、持續可用性、效能和安全性等要求。

常見問題：

• 系統如何釋出部署？有哪些部署環境？

• 系統有多少臺機器？

• 系統部署怎麼部署的？關注接入層，部署方式，如叢集部署、分散式部署等

• 有沒有容器化？

• 有沒有多機房部署？

5. 資料架構

資料架構的設計著重考慮資料需求，關注點是持久化資料的儲存方案，不僅包括實體及實體關係資料儲存格式，還可能包括資料傳遞、資料複製、資料同步等策略。

常見問題：

• 資料儲存在哪？用了什麼資料庫，如 oracle、mysql；

• 梳理 E-R 圖；

• 資料量有多少？是否有分庫分表？

• 用了哪些 nosql 庫？

• 有哪些資料同步任務？

• 大資料框架的使用情況如何？

6. 系統運維

系統運維重點關注什麼時候會出問題，出了問題怎麼解決。

常見問題：

• 什麼時間容易出問題？比如電商 雙11，對系統的壓力很大，這時候很容易出問題；

• 對關鍵功能是否有監控？需要看系統有配置了哪些報警項，監控了哪些方面；

• 出了問題怎麼解決？日誌在哪？是否有全鏈路跟蹤？是否有一些緊急操作，比如開關配置、降級、限流配置；

• 系統有哪些坑？找開發同學回顧歷史問題，以免踩坑。透過同事總結的 case，或者與負責的產品、運營、技術與瞭解。系統總會有一些坑，需要把這些坑填上。歷史程式碼經過多次迭代總會導致複雜度高（分支、巢狀、迴圈很多），存在設計漏洞，效能隱患等，很難維護，這些就需要我們去重構了。記住有一句話：填的坑越大，能力越大；

• 運營、客服反饋的常見問題有哪些？

實踐

熟悉了系統的業務和技術後，就要實戰了，透過實戰進一步加深對系統的熟悉程度。實踐可以透過做需求、修 bug、重構等方式，親自動手編碼、除錯、測試、上線。

總結

已有系統通常經歷了從 0 到 N 的建設過程，熟悉系統其實是一個逆向推導過程，也是一個學習架構、閱讀原始碼的過程。

在學習的過程中最好能帶上思考，比如為什麼要這麼設計？為什麼要用這個中介軟體？是否有更好的編碼方式？哪些地方可以最佳化等，以此達到一個深入熟悉的過程。

附：總結圖