首先不是所有的項目都需要重構，就項目本身而言重構并不是一件很好的事情，不但不會帶來很明顯的效益，相反可能會對當前系統產生一定的風險。然而當你發現的你的系統已經不能支持快速發展的業務需求，QPS越來越高，數據庫壓力越來越大，很難在現有的系統中展開新的業務時，你就不得不考慮一下重構。

重構就像醫生給病人做手術，根據病人病情來決定是否動手術，如果小手術就能解決的問題，就沒必要進行大的操刀，系統也一樣，越是底層的，框架級的越不要輕易重構；一旦傷筋動骨帶來的影響就是毀滅性的。

比如只是某個WEB頁面響應時間過長，一般在應用層就可以解決，不涉及到架構或是框架層面，方法一般是先檢查頁面是渲染時間過長還是服務端響應過慢；如果是前者，可以考慮調整靜態資源的加載順序，減少無關的JS代碼，延遲無需同步加載的JS，Img等。如果是后者，可以考慮前端是否可以異步調用后端請求，或者合并API減少調用次數，降低服務端響應時間，這里可以考慮優化API確定時間是消耗在復雜邏輯計算上，或是DB的數據查詢上，還是網絡間的通信上，對癥下藥。

優化代碼邏輯，減少不必要的冗余計算，或者減少DB查詢次數，增加緩存，同步轉異步等都是優化方向，根據不同業務需求選擇不同的優化方向。

當你發現上述小的改動做完之后，服務器壓力依然很大，CPU負載還是很高，DB壓力依舊很大，單表數據還是猛增，這時候你該考慮做個大手術了?？梢詮南到y架構入手。

拆分

除了增加服務器外，垂直拆分也是不錯的選擇，將服務器模塊化，根據業務將不同的請求分發在不同的服務器上，不但可以降低單臺服務器的訪問壓力，還可以降低風險等級，即使某個服務器宕了，也不會對其他服務器造成致命的影響

SOA

服務化可以讓業務調用更加清晰，不但可以讓復雜的業務碎片化，也可以更快的定位解決線上問題

?緩存

因為DB的資源是極其寶貴的，降低DB壓力必不可少，對于實時性能不高的響應，

緩存絕對是不二的選擇。本地緩存，Memcache，Redis 等都是目前不錯的方式。

讀寫分離，分庫分表

當對DB的操作大部分都是read 或者write 操作時，可采用讀寫分離，這里需要考慮數據同步的問題，是否寫操作需要實時顯示。當寫操作非常頻繁或者隨著時間的推移單表數據已經過于龐大達到千萬級別時，需要考慮分庫分表，提高單表的查詢效率。

由于篇幅所限，這里只做了概括性的描述，不能一一展開了。提醒一點很重要：一定要在保證系統的穩定性的前提下才能重構，萬不能為了重構而重構，本末倒置得不償失。

本文由點融黑幫 @吳松 原創發布于人人都是產品經理?，未經許可，禁止轉載。