重構系統的套路-明確重構目的

重構系統的套路系列：

• 重構系統的套路-寫有組織的代碼
• 重構系統的套路-提升併發能力
• 重構系統的套路-微服務化

本篇說下重構系統的套路中的，明確重構的目的。

咱們進行系統重構會抱着不一樣的目的，好比爲了系統穩定性，爲了系統中某些功能負載能力更強，爲了系統更便於維護，或是爲了系統更便於持續集成提高RD和QA的人效。

不一樣的重構目的會有不一樣的重構方式和不一樣的執行標準。

好比爲了系統穩定性的重構，咱們更須要關心的是系統穩定性指標，咱們須要在整個服務鏈路上進行梳理，梳理出核心鏈路，核心鏈路的耗時控制及QPS，若是不能在整個鏈路上下游達成統一，每每會形成一些未知且不可控的問題。

好比若是某個服務進行穩定性重構，專斷專行的設置了對下游服務的耗時，上線後，整個服務雖然穩定性提高，可是下游服務因爲不合理的超時時間形成數據落庫失敗，在整個鏈路上看其實這個請求也是失敗的，形成的結果就是一個服務的可用性和穩定性上來了，可是整個鏈路的可用性卻下降了，貿然全量這樣一個重構，必然產生一個很是大的事故。 若是直接把一個500ms設置成100ms，結果沒有在乎到這個500ms是一個數據上報功能，其實對核心業務不影響，可是由於下降了400ms形成上報數據系統超時，最終統計數據有誤，形成金融結算金額錯誤，因此一個小小的修改超時時間形成了一個如此大的問題。

若是重構的目的是爲了負載能力，好比爲了半年整個訂單量翻一倍，QPS提高三倍，咱們首先須要對現有系統進行壓測，發現系統瓶頸，經過完善的監控系統進行耗時穩定代碼和邏輯評估，針對性優化。 同時須要對整個重構服務所依賴的緩存，持久化存儲，redis，mq等系統容量進行評估，系統中線程池進行評估，而全部的評估都是創建在對對應中間件所服務目的來實現的。

好比咱們用redis集羣作冪等服務，由於多服務同步之間經過定時任務觸發，定時任務觸發後可能由於大數據量形成請求擠壓，高峯期擠壓處理在2～5h不等，因此這個redis的key的超時時間須要覆蓋到5h，梳理了程序代碼邏輯就ok了嗎？

結果服務上線後，整個代碼邏輯跑起來沒問題，能夠高峯期間發現異常日誌和錯誤數據統計不停上升，結果發現是沒有正確評估系統QPS，同時沒有梳理好redis的key大小，5h的超時時間使得整個key的存儲瞬間達到20G+，而某個集羣容量可能已經滿了，而DBA來不及進行集羣擴容，集羣自身觸發緩存清除策略，大量的key刪除形成集羣數據的rebalance，形成網絡抖動，結果形成高峯期間集羣可用性下降，當redis集羣可用性下降到必定閾值以後，系統邏輯降級讀db，形成了雪崩，整個數據庫集羣也被壓倒，形成了一個重大事故。

上面這個雖然是我本身在系統梳理過程當中意淫出來的場景，但我不得再也不我進行相似系統重構以前，在代碼邏輯角度，功能業務角度，緩存集羣，mq集羣，DB集羣等角度考慮，我此次重構可能形成的問題，只有咱們在系統重構之間可以想的比黑天鵝來的更快咱們才能對系統作更多的保護，固然這一切不能交給QA同窗，須要有經驗的架構師有全局的視野和掌控。

若是系統重構的目的在於可維護性，和上面兩點的區別在於，週期不可操之過急。 咱們須要在整個業務角度去理解系統，同時對將來系統所承接的業務有所評估，這樣咱們才能設計出一個面向將來的系統。 編寫可維護的代碼和可維護的系統其實很是的難，微服務的流行和DDD的流行其實也很難根本上解決這個問題，終極的解決方案仍是在將RD培養成領域專家，在領域角度去抽象和理解業務，編寫領域驅動的代碼，而不是簡單的認爲分層和多模塊的搞就能夠了。

若是系統重構的目標在於持續集成和發佈，提高RD和QA的人效，則須要在工程和流程及文化三個角度去作。 工程上提供便於管理的git系統，全鏈路壓測系統，集成測試環境，多泳道支撐，一鍵資源申請，完善的上線發版流程及快速回滾方案，QA同窗具有正常的http抓包分析能力，測試代碼編寫能力，基本linux的shell編寫能力。 RD編寫測試用例，完善技術文檔，覆蓋功能修改點，配合qa同窗觀察耗時，鏈接創建，磁盤IO，機器load，cpu等多指標。 控制發版時間和發版粒度，指定安全發版策略等。

基於以上四點不一樣的重構需求，咱們採起的方案和執行的角度徹底不一樣，系統變大了以後，穩定第一。