文章目錄
- 業務知識
- 技術知識
- 邏輯部分
- 開發部分
- 系統運行
- 物理架構
- 資料模型
- 系統維護
- 上手實戰
- 小結
大家或多或少都有接觸一個已存在的系統，面對不是自己做的東西都有覺得上手有些困難，筆者想從自身的經驗去談談如何快速上手一個陌生的系統， 打算從以下幾個維度去分析落地：
業務知識
從業務角度去學習系統，說白了就是從客戶視角看系統提供了什么功能，一定是人能理解的維度，這樣也方便你去理解系統，從業務下手則你需要去找設計 產品 運營等相關領域的人去了解，也有些對外的產品檔案，方便用戶熟悉系統的，都可以入手去學習，
業務知識可以按如下分類：
- 市場定位如何？哪些用戶
- 競爭產品有哪些，有些公司同樣在做？
- 主要特性有哪些？解決啥問題？
- 未來發展方向是啥樣的？
技術知識
技術知識主要是深入了解系統的實作了，你去熟悉系統就避免不了去熟悉系統的架構、實作、運維等，建議可以從：邏輯架構、物理架構、資料架構入手，這幾個層面了解了你對系統有了從表面到內部的了解，
邏輯部分
邏輯架構著重考慮功能需求，系統應當向用戶提供什么樣的服務，關注點主要是行為或職責的劃分，這里搞清楚各個模塊的對應的角色以及功能、職責就OK了，邏輯架構的核心設計任務是模塊劃分、介面定義、領域模型細化，
關注點：
- 有哪些子系統或模塊？系統之間是什么樣的關系？
- 對外上下游介面有哪些？對接人是誰？
- 關鍵業務流程怎么實作的？用類圖、序列圖等方式表達出來，
開發部分
主要是代碼架構，主要關注系統源代碼、SDK、框架、中間件、工具包，
主要關注：- 開發工具，以及代碼git路徑？
- 產品包如何編包，各部分如何劃分，例如MVC架構
- 用了哪些工具包？如apache commons、guava
- 用了哪些中間件？如messagequeue,struts spring
- 依賴哪些平臺?如中間件 flink 等
系統運行
運行架構的著重考慮運行期質量屬性，關注點是系統的并發、同步、通信等問題，這勢必涉及到行程、執行緒、物件等運行時概念，以及相關的并發、同步、通信等，
主要關注：
- 系統能支撐多少qps？峰值qps多少？
- 與上下游系統怎么互動的？rpc？http？同步還是異步？
物理架構
物理架構的設計著重考慮安裝和部署需求，關注點是目標程式及其依賴的運行庫和系統軟體最終如何安裝或部署到物理機器，以及如何部署機器和網路來配合軟體系統的可靠性、可伸縮性、持續可用性、性能和安全性等要求，
主要關注：
- 系統如何發布部署？有哪些部署環境？
- 系統有多少臺機器？
- 系統部署怎么部署的？關注接入層，部署方式，如集群部署、分布式部署等
- 有沒有容器化？
- 有沒有多機房部署？
資料模型
程式就是資料+演算法，所以資料對理解系統很重要，你把資料模型理清楚了，就知道系統圍繞資料如何做運轉，包括資料表，快取資料，資料存盤方式等，
主要關注：
- 資料存盤在哪？用了什么資料庫，如oracle、mysql，
- 資料之間依賴關系
- 資料是否涉及大表分庫分表等？
- 用了哪些nosql庫，如kv存盤？
- 有哪些資料同步任務？
- 大資料框架的使用情況如何？
系統維護
系統運維重點關注什么時候會出問題，出了問題怎么解決，
主要關注：
- 會出現什么嚴重問題，怎么止血？對系統的壓力很大，這時候很容易出問題，
- 對關鍵功能是否有監控？需要看系統有配置了哪些報警項，監控了哪些方面，
- 出了問題怎么解決？日志在哪？是否有全鏈路跟蹤？是否有一些緊急操作，比如開關配置、降級、限流配置，
- 系統有哪些坑？找開發同學回顧歷史問題，以免踩坑，通過同事總結的case，或者與負責的產品、運營、技術與了解，系統總會有一些坑，需要把這些坑填上，歷史代碼經過多次迭代總會導致復雜度高（分支、嵌套、回圈很多），存在設計漏洞，性能隱患等，很難維護，這些就需要我們去重構了，記住有一句話：填的坑越大，能力越大，
- 運營、客服反饋的主要關注有哪些？
上手實戰
熟悉了系統的業務和技術后，就要實戰了，通過實戰進一步加深對系統的熟悉程度，實戰最好的方式是定位問題，通過問題端到端定位，你會了解各個子系統，能把整個流程關聯起來，其他如需求、bug等寫代碼的活動也會對系統熟悉起到很大作用，測驗、上線等活動會讓你對用戶場景的功能部分做深入的了解，
以筆者經歷的幾個大廠的專案為例，具體講講如何上手實踐，僅供參考：
專案1：
在阿里內部有很多的資料平臺，其中有很多的大資料平臺，有個內部平臺叫 blink 在開源社區叫 flink，blink作為一個大資料通用平臺，是提供了標準的API，你呼叫API去提交一個job 會給你回傳一個唯一的jobId，這個jobId在blink 內部是嚴格唯一的（后續大資料分析都會依賴這個jobId），有個這個jobId你就可以到內部的kepler平臺去根據JobId 找對應的計算任務，計算任務會被拆分很多算子，每個算子 串聯起來就是整個job流，計算任務里面有程序日志，也有例外日志，如果你感覺計算job沒有輸出，則你應該先看例外日志，是否有exception，如果無例外則你看整個流程里面各個算子是否有輸入輸出流量，如果串行流的輸入輸出對不上，可能是你的算子條件不對把流量全部過濾掉了，還有重可能就是計算任務堆積了，這個時候你要到job的統計資訊看是否有時延，，，，
通過這個我想表達的時候，只有通過實踐你才知道整個業務流程是什么樣，以資料為載體整個流動原理是什么，
專案2：
再舉個例子，筆者曾經搞過分布式存盤系統，在HW以及阿里都搞過，分布式存盤系統里面有很多系統節點： 比如 Ngix 業務系統 資料存盤引擎 硬體存盤等，如果看到的時候客戶端時延很大，你該如何去分析？搞清楚這個問題首先就是要定界，資料流經這么多系統，到底是哪個環節出問題，怎么定界？可以用網路抓包啊 這些系統基本都是跨網卡的，你就可以用 wireshark 去在各個系統節點去抓包，通過對同一個報文的輸入輸出看時延 來確定系統是否有問題，但是一般來講 網卡不是瓶頸，磁盤才是短板（這個就是經驗問題了），舉個筆者曾經的問題定位案例：客戶上傳一個大檔案，很卡，首先看盤的iostat統計發現不高，說明服務端的硬碟不是瓶頸，接著看服務端的網卡流量，利用率也不高，基本認為就是客戶端問題，再看客戶端的上傳帶寬發現確實只有xM，而客戶說以前是xxxM，再看客戶的SDK的呼叫，發現大檔案他呼叫的介面用錯了，不是并發上傳的介面，是個單執行緒介面，問題很快定位，
通過這個問題想表達的是，通過實踐增強定位問題的能力的關鍵是問題范圍縮小，把可能性給縮小直到找到問題
小結
筆者認為，首先心態上不要刻意去在意這是別人寫的代碼，我熟悉很困難，就權且認為是自己很早之前寫的代碼，現在要重新把這個代碼撿起來，需要回憶去恢復記憶，這個程序中可能就需要一些活動去輔助：比如問題定位，比如需求開發，比如代碼重構等，在這個程序中需要不斷畫系統全景圖，逐步把整個系統掌握了，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/304322.html
標籤：java