重構這件小事
服務端的技術重構,對於很多開發人員來說並不陌生。這裡,我們稱大的技改叫做重構。自加入我站以來,也是主導或經歷過比較大的技術重構,簡單說有兩類:
- 從php到golang的重構
- 兩年累積的golang程式碼的重構
其實重構的動機無非就這麼兩類
- 語言棧的遷移或統一 算是重寫了
- 因業務發展,老的架構不滿足了,包括穩定性、效能上的、擴充套件性上的等等
那麼,到底我們的專案,是否需要重構了呢?
重構本身屬於技改,一般情況下產品和老闆不一定是非常關心的,甚至有時候是“反對”的。短期來看,重構對業務迭代速度的影響、重構中或者重構後系統的穩定性也未知。那麼,我們要不要重構呢?
我們要會算賬!重構的收益是什麼?成本是什麼?風險是什麼?想清楚這3個問題再決定!
*收益能否量化! 比如效能資料提升多少?耗時的減少是直接改善使用者體驗的。頻寬是否減少百分多少?頻寬的成本往往是技術成本大頭。還有如CPU的優化,對於大的業務叢集也是可觀的收益。
*成本和風險 成本和風險往往是相關的。這裡主要指技改的額外開發成本對業務迭代的風險影響 ,以及過程中的對系統穩定性 的風險影響。
其實,還有很多隱形收益是特別需要開發人員關注的 ,如程式碼規範和質量的優化 對後期開發效率和易維護性的影響,平臺化改造 使得整個系統的擴充套件性、業務解耦的改善,等等。那麼我簡單舉例下近期推進的go業務系統改造。
兩個月前我開始制定評論等社群系統的重構roadmap。這些系統在兩年前是從我站的大雜燴系統拆分出來的,經歷了非常多的功能堆積、多業務方接入,存在非常多的系統性問題。方案包括核心幾點:
- 服務拆分 比如單體拆成閘道器和service服務。閘道器邏輯包括對外介面、埋點上報、防刷限流、資料聚合、業務配置等,無狀態。service服務側重基礎功能邏輯、DB和快取操作,基本上做到和功能迭代、業務方解耦。這樣閘道器的頻繁發版帶來的心智負擔就很少了。
- 平臺化改造 比如系統不斷接入了很多業務方,那麼我們要支援平臺功能的配置化。 同時,要儘量和業務方邏輯解耦。
- 效能優化 這點不細說了,基本上做核心介面效能分析 就好了,見golang下的併發、並行優化
- 穩定性 穩定性的影響因素很多,架構的合理、容災容錯方案、依賴方系統的穩定性等等。
- 通用邏輯規範寫法 基礎庫越強大,業務程式碼越簡單。還有比如job常用的記憶體merge、並行呼叫框架等等......
- 編碼質量和UT覆蓋 高內聚、低耦合,比如api協議和interface的設計啊、類的設計啊、函式的設計啊、命名啊、狀態屬性的寫收斂、太多地方了
重構也許很累,但是本身是思考的過程和提升的過程,重構的方案也特別重要。敢於重構,勇於突破。
最後拋一個我們重構過程中的小技巧,新老系統怎麼切換?我們會同時並行請求新老介面,並做結果diff。當結果完全一致才考慮返回新介面資料。