首先不是所有的項(xiàng)目都需要重構(gòu)，就項(xiàng)目本身而言重構(gòu)并不是一件很好的事情，不但不會帶來很明顯的效益，相反可能會對當(dāng)前系統(tǒng)產(chǎn)生一定的風(fēng)險。然而當(dāng)你發(fā)現(xiàn)的你的系統(tǒng)已經(jīng)不能支持快速發(fā)展的業(yè)務(wù)需求，QPS越來越高，數(shù)據(jù)庫壓力越來越大，很難在現(xiàn)有的系統(tǒng)中展開新的業(yè)務(wù)時，你就不得不考慮一下重構(gòu)。

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

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

優(yōu)化代碼邏輯，減少不必要的冗余計算，或者減少DB查詢次數(shù)，增加緩存，同步轉(zhuǎn)異步等都是優(yōu)化方向，根據(jù)不同業(yè)務(wù)需求選擇不同的優(yōu)化方向。

當(dāng)你發(fā)現(xiàn)上述小的改動做完之后，服務(wù)器壓力依然很大，CPU負(fù)載還是很高，DB壓力依舊很大，單表數(shù)據(jù)還是猛增，這時候你該考慮做個大手術(shù)了?？梢詮南到y(tǒng)架構(gòu)入手。

拆分

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

SOA

服務(wù)化可以讓業(yè)務(wù)調(diào)用更加清晰，不但可以讓復(fù)雜的業(yè)務(wù)碎片化，也可以更快的定位解決線上問題

?緩存

因?yàn)镈B的資源是極其寶貴的，降低DB壓力必不可少，對于實(shí)時性能不高的響應(yīng)，

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

讀寫分離，分庫分表

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

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

本文由點(diǎn)融黑幫 @吳松 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理?，未經(jīng)許可，禁止轉(zhuǎn)載。