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