目前正在參與公司一個核心大系統的重構工作。本文梳理一下大型系統重構的一些步驟和心得。
概述
隨著公司業務不斷的發展，使用者量不斷的增加，對系統的效能要求會越來越高，而原來倉促做出來的專案，其不合理性的地方就會不斷的暴露出來。大家如果接觸過非常賺錢的網際網路產品，一定會知道產品的一個小小的bug，公司就可能損失好幾百萬甚至幾個億。當產品的使用者數達到一定量的時候，對系統的各個方面的要求就越高，例如qps、cpu、容災、降級、限流、可擴充套件性、可維護性等等。系統除了要應付大量的併發請求，還必須快速支援各種業務需求，必須對系統進行大重構。
備註：
下面的一些步驟和方式是根據我自己的專案的實際列出的。
業務梳理
要弄懂原來的業務流程，如果有不合理的業務流程，必須進行業務流程優化。這種一般是公司的業務架構師來處理的。
資料庫重構
前期的專案，由於趕進度，並沒有充足的時間設計表，導致各種冗餘表、大表、大量的冗餘的欄位、擴充套件性差的表。所以重構系統的時候，可以先從表開始，通過對當前業務的梳理，重新把表整理一下。
1. 欄位太多的表，可以根據部分欄位的業務屬性，抽取成一個新表；
2. 已經不再用的表欄位，刪除掉；
3. 可以合併的欄位，儘量進行合併，例如，想表示一個商品是旅遊商品，就沒必要新增一個類似is_travel的欄位,可以直接在商品型別product_type中增加一個列舉值即可；
4. 根據當前業務，把一些表欄位下沉到其他表，從另外一個維度輸出；
5. 如果一個表的擴充套件屬性太多的話，可以另外建立一張表儲存。
等等。。。。
資料庫重構，一般由專門的資料架構師來處理。資料架構師必須和業務架構師緊密配合。
資料遷移
由於對資料庫進行了重構，那麼舊資料庫的資料必須完整的遷移過來。
- 全量遷移：需要做一個只跑一次的全量遷移程式，把舊資料庫中一次性遷移過來；
- 增量遷移：新系統上線之前，舊系統也一直在工作著，那麼新增的資料也必須通過一個增量遷移程式把資料遷移到新資料庫。這個增量程式必須一直跑，直到舊系統下線，不會產生新資料。
db資料自檢程式
為了驗證遷移程式是否正常工作，還必須寫一個自檢程式，不斷的比對新舊資料庫中的資料，看看有沒有漏遷的資料或者值不相等的資料。
業務介面設計
針對新設計的表和新梳理的業務，重新設計對外的業務介面。當然由於重新設計了介面，方法的入參、出參等都可能不一樣了。這樣的話，其他系統接入的時候，會遇到一些阻力。
業務介面自檢程式
必須通過一個業務介面自檢程式，不斷的比對新舊業務介面的輸出是否一致。這個是一個非常關鍵的程式，可以幫助檢查新資料和新介面的問題。
開發聯調
新介面釋出SDK後，其他系統可以通過SDK呼叫新介面，進行開發人員與開發人員之間進行簡單的介面聯調。這期間，如果遇到業務問題了，必須及時聯絡業務架構師和資料架構師。適當的情況下，可能業務和表得調整。
就像上文說的，由於業務介面改動比較大，其他系統接入的時候，會遇到很多阻力的。
測試人員介入
除了介面功能測試之外，必須做一個完整的效能測試和穩定性測試。同時必須搭建測試聯調環境，與其他系統的測試人員進行聯調，其他系統要接入到新介面。
這個階段，最好找靠譜的測試人員，即懂測試技術技巧又懂業務的。
接入流量
可以先切萬分之幾的流量到新介面，試試水。有問題的話，及時修改。只要有流量接入，就必須使用各種監控系統實時監控，有問題的馬上告警。另外，開發人員也必須經常檢視日誌系統，及早發現問題。一旦新介面非常穩定後，則可以將全部流量切入到新介面。
觀察系統
新介面接入所有流量後，除了監控系統監控介面之外，開發人員必須經常看日誌系統，觀察系統是否正常工作。最好定一個任務，讓開發人員輪流觀察系統。
打賞支援我寫出更多好文章，謝謝！
打賞作者
打賞支援我寫出更多好文章，謝謝！
