大型系統重構的步驟簡單梳理

 

目前正在參與公司一個核心大系統的重構工做。本文梳理一下大型系統重構的一些步驟和心得。

概述

隨着公司業務不斷的發展，用戶量不斷的增長，對系統的性能要求會愈來愈高，而原來倉促作出來的項目，其不合理性的地方就會不斷的暴露出來。你們若是接觸過很是賺錢的互聯網產品，必定會知道產品的一個小小的bug，公司就可能損失好幾百萬甚至幾個億。當產品的用戶數達到必定量的時候，對系統的各個方面的要求就越高，例如qps、cpu、容災、降級、限流、可擴展性、可維護性等等。系統除了要應付大量的併發請求，還必須快速支持各類業務需求，必須對系統進行大重構。

備註：

下面的一些步驟和方式是根據我本身的項目的實際列出的。

業務梳理

要弄懂原來的業務流程，若是有不合理的業務流程，必須進行業務流程優化。這種通常是公司的業務架構師來處理的。

數據庫重構

前期的項目，因爲趕進度，並無充足的時間設計表，致使各類冗餘表、大表、大量的冗餘的字段、擴展性差的表。因此重構系統的時候，能夠先從表開始，經過對當前業務的梳理，從新把表整理一下。
1. 字段太多的表，能夠根據部分字段的業務屬性，抽取成一個新表；
2. 已經再也不用的表字段，刪除掉；
3. 能夠合併的字段，儘可能進行合併，例如，想表示一個商品是旅遊商品，就不必新增一個相似is_travel的字段,能夠直接在商品類型product_type中增長一個枚舉值便可；
4. 根據當前業務，把一些表字段下沉到其餘表，從另一個維度輸出；
5. 若是一個表的擴展屬性太多的話，能夠另外創建一張表存儲。

等等。。。。

數據庫重構，通常由專門的數據架構師來處理。數據架構師必須和業務架構師緊密配合。

數據遷移

因爲對數據庫進行了重構，那麼舊數據庫的數據必須完整的遷移過來。

1. 全量遷移：須要作一個只跑一次的全量遷移程序，把舊數據庫中一次性遷移過來；
2. 增量遷移：新系統上線以前，舊系統也一直在工做着，那麼新增的數據也必須經過一個增量遷移程序把數據遷移到新數據庫。這個增量程序必須一直跑，直到舊系統下線，不會產生新數據。

db數據自檢程序

爲了驗證遷移程序是否正常工做，還必須寫一個自檢程序，不斷的比對新舊數據庫中的數據，看看有沒有漏遷的數據或者值不相等的數據。

業務接口設計

針對新設計的表和新梳理的業務，從新設計對外的業務接口。固然因爲從新設計了接口，方法的入參、出參等均可能不同了。這樣的話，其餘系統接入的時候，會遇到一些阻力。

業務接口自檢程序

必須經過一個業務接口自檢程序，不斷的比對新舊業務接口的輸出是否一致。這個是一個很是關鍵的程序，能夠幫助檢查新數據和新接口的問題。

開發聯調

新接口發佈SDK後，其餘系統能夠經過SDK調用新接口，進行開發人員與開發人員之間進行簡單的接口聯調。這期間，若是遇到業務問題了，必須及時聯繫業務架構師和數據架構師。適當的狀況下，可能業務和表得調整。

就像上文說的，因爲業務接口改動比較大，其餘系統接入的時候，會遇到不少阻力的。

測試人員介入

除了接口功能測試以外，必須作一個完整的性能測試和穩定性測試。同時必須搭建測試聯調環境，與其餘系統的測試人員進行聯調，其餘系統要接入到新接口。

這個階段，最好找靠譜的測試人員，即懂測試技術技巧又懂業務的。

接入流量

能夠先切萬分之幾的流量到新接口，試試水。有問題的話，及時修改。只要有流量接入，就必須使用各類監控系統實時監控，有問題的立刻告警。另外，開發人員也必須常常查看日誌系統，及早發現問題。一旦新接口很是穩定後，則能夠將所有流量切入到新接口。

觀察系統

新接口接入全部流量後，除了監控系統監控接口以外，開發人員必須常常看日誌系統，觀察系統是否正常工做。最好定一個任務，讓開發人員輪流觀察系統。