應用性能優化記錄之一——應用往雲上遷移所帶來的新挑戰

        年前接手了一個項目，因爲剛接手，業務熟悉等花去了必定的時間。因此很長時間沒有寫

博客了。又是一年大促季，再加上公司新建機房，應用往雲上遷移的時機已經來了。從4月中開

始，就開始了這苦逼的填坑生活。 這其中遇到了不少問題，所以把這些填坑方法記錄下來，分

享給你們。

         該系統是一個網絡IO開銷類型的應用。日訪問量較高。最開始的請求應答架構示意圖以下：

 

       

 

       分析一下這個請求--應答過程。首先一個請求過來，前端CDN會擋住一部分流量。若是離用

戶最近的CDN有數據，由CDN直接返回數據。CDN做爲系統的第一層公用緩存來使用。

       假如CDN沒有數據。那麼CDN將回源站獲取數據。在應用和CDN之間，咱們搭建了一層私

有緩存層來減輕後端應用的壓力。這一層的方案採用nginx+lua來實現。同時在這些前置機上自

建redis。 爲何要在本機建redis呢？ lua讀取redis的時候，由於redis在本機，這樣作會減小網

絡IO開銷。提高吞吐量。當請求過來的時候，CDN沒有，回源到前置機，若是前置機lua讀取本

機redis有數據，那麼就直接返回數據，請求將再也不繼續往下走到應用服務器。這一層，做爲整

個應用的第二層緩存來存在。

       那麼假如第二層緩存依然沒有數據，怎麼辦呢？？

       這個時候，請求會繼續回源到應用服務器，由應用層響應該請求。同時在前置機的redis把

最新的響應結果寫入進去，有效期默認設置爲10分鐘。10分鐘緩存的設置，是由於假如後端數

據有變更的話，須要回到應用層拿到最新的數據。10分鐘的緩存，在咱們的可接受範圍以內。

       這就是以前的整個訪問架構。該套系統日處理PV可達億級。能應對較大的風險。但在接手

系統以後，就遇到了一個棘手的問題：根據公司須要，應用所有往私有云上遷移。

       首先是基礎服務的遷移。其實這些都還好。由於是有專業的運維人員，因此像用到的

mysql、jimdb等都順利遷移。等到應用往雲上遷移的時候，問題來了。前置機上的nginx+lua環

境部署好了。redis也搞好了。可是整個系統測試發現，因爲docker容器的不穩定，致使常常lua

讀取不到數據，異常。一時間你們都傻眼了。由於以前是性能槓槓的物理機，這套系統也好好

的沒有出什麼錯。沒想到一往雲上遷移，就出問題了。

       好吧，遇到問題也沒轍，聯繫docker、雲專家等反饋問題。獲得的答覆就是：不要在容器

上本身裝redis使用。這樣的話，就意味着系統架構要發生變更。

      這TM簡直是晴天霹靂好嗎？怎麼辦呢？請聽下回分解