背景
前幾天被派去處響應(yīng)客戶提出的需求。
客戶需求
之前公司給客戶開發(fā)部署了一套Web應(yīng)用,是Vue+Node.js的架構(gòu)。
現(xiàn)在客戶要求把這個Web應(yīng)用放到一臺筆記本里,要求web應(yīng)用的網(wǎng)頁要能正常顯示。
小編快速思考了一下,在筆記本上搭建好Vue和Node.js的環(huán)境,將前端、后端源代碼copy到筆記本上跑起來,把數(shù)據(jù)庫一遷移不就完事了嘛,小意思。
然而還是太年輕,把問題想得太理想。
溝通后才發(fā)現(xiàn)這個系統(tǒng)的后臺開發(fā)數(shù)據(jù)庫是分布式數(shù)據(jù)庫,由幾十臺服務(wù)器組成,這...這還怎么玩??!
首先,要把這個分布式數(shù)據(jù)庫塞到筆記本里顯然不現(xiàn)實,同時了解到Web應(yīng)用中的一些統(tǒng)計功能需要進(jìn)行全表查詢計算,即使我能把數(shù)據(jù)庫塞進(jìn)筆記本,幾個TB的數(shù)據(jù)庫表我也塞不進(jìn)去啊!其次客戶不允許把全量數(shù)據(jù)庫數(shù)據(jù)導(dǎo)出到筆記本,簡直要哭了!
解決方案
這種情況,看來數(shù)據(jù)庫是不用想了,小編趕緊思考別的解決方案,要不然Leader所謂的小問題都解決不了,豈不是太(fan)給(wan)公(bu)司(bao)丟臉了。小編想起Leader意味深長的笑,心里早已MMP了。
既然數(shù)據(jù)庫不能遷移到筆記本,那前端所需要的數(shù)據(jù)該怎么獲取呢?
我們先來回顧web的整個交互流程。下圖是目前客戶整個web應(yīng)用示意圖:
簡單來說,一個動態(tài)網(wǎng)頁的獲取分以下幾步:
拉取靜態(tài)頁面
當(dāng)用戶在瀏覽器輸入URL回車后,通過Http的Get請求向Http服務(wù)器請求拉取靜態(tài)html頁面以及相關(guān)的CSS、JS等資源文件
瀏覽器解析階段
瀏覽器解析html頁面,并執(zhí)行相應(yīng)的JS代碼,JS代碼中會包含相應(yīng)的異步數(shù)據(jù)請求。
異步數(shù)據(jù)請求
瀏覽器通過異步數(shù)據(jù)請求向Node服務(wù)器請求數(shù)據(jù)
后端服務(wù)器響應(yīng)
Node服務(wù)器根據(jù)的請求,執(zhí)行相應(yīng)功能的代碼,例如,如果是拉取商品列表的數(shù)據(jù)請求,Node服務(wù)器會向數(shù)據(jù)庫查詢商品列表信息,將組織好的數(shù)據(jù)包裝成Json等格式作為請求的響應(yīng)返回給瀏覽器
異步刷新頁面
瀏覽器端JS代碼通過異步請求拿到異步請求返回的數(shù)據(jù),繼續(xù)執(zhí)行相關(guān)的數(shù)據(jù)組織處理的JS代碼,最終將數(shù)據(jù)異步更新到網(wǎng)頁上。
結(jié)束
至此,一個簡單的瀏覽器請求背后的流程到此結(jié)束,用戶通過輸入URL看到了想要看到的網(wǎng)頁的內(nèi)容。
經(jīng)過對背后流程的梳理,小編已經(jīng)明確問題出在數(shù)據(jù)庫上,并且既然數(shù)據(jù)庫不能訪問,相應(yīng)的,后端Node服務(wù)器的存在也沒有什么意義了。
事實上,對于前后臺分離的架構(gòu),若要保證網(wǎng)頁的正常訪問,只要能保證前端向后臺發(fā)起的數(shù)據(jù)請求,能夠返回一致的數(shù)據(jù)即可。
意思是,只要能夠保證前端請求,有正常的響應(yīng)(數(shù)據(jù))即可,不管是Node服務(wù)器對請求進(jìn)行響應(yīng),還是誰提供的響應(yīng)。
把后端想象成一個服務(wù)提供者,只要能提供服務(wù),任何的解決方案都是可行的。
于是小編腦中浮現(xiàn)了一個方案:
將現(xiàn)有系統(tǒng)中每個后臺請求的返回的結(jié)果數(shù)據(jù)都先保存成本地文件,同時重新開發(fā)后臺服務(wù)響應(yīng)接口,對于指定的請求返回之前相同接口請求保存的本地文件數(shù)據(jù),整個架構(gòu)變成下圖的樣子:
這樣既達(dá)到了能夠返回實際的數(shù)據(jù),同時前端也沒有任何感知和影響。
實際上這樣還是不能完全解決問題。例如,如果有一下需要修改、寫入數(shù)據(jù)庫的操作,這種方式就沒有效了。
畢竟我們只是偽裝能一個能夠正常響應(yīng)查詢的假后端,并沒有實際的數(shù)據(jù)庫。
不過好在客戶說只要滿足首頁和幾個查詢按鈕的正常展示即可。
接下來的主要工作就是梳理現(xiàn)有接口,把實際數(shù)據(jù)請求接口返回的數(shù)據(jù)都保存下來,并且記錄它們之間的對應(yīng)關(guān)系。然后就是重新開發(fā)后端服務(wù),將前端過來的請求,返回之前保存的對應(yīng)的文件中的數(shù)據(jù)即可。
舉個例子,之前某個前端請求對應(yīng)的后端處理代碼可能是這樣的:
string get_goods_list(request)
{
//獲取request中請求參數(shù)
...
//查詢數(shù)據(jù)庫
...
//組織數(shù)據(jù)格式并返回
return json_respone;
}
而重新開發(fā)的后端處理代碼就變成這樣了:
string get_goods_list(request)
{
//讀取保存到本地的數(shù)據(jù)請求返回的數(shù)據(jù)
...
//直接將數(shù)據(jù)返回給前端
return json_respone;
}
特別的簡單粗暴,但是確實有效,當(dāng)然事情也不可能如此順利,由于這個系統(tǒng)當(dāng)時的研發(fā)人員已經(jīng)離職,小編只能靠留存的簡單項目部署說明,外加一點點摸索,在解決無數(shù)次error后,客戶終于在一臺筆記本上看到了預(yù)期的頁面效果。
直到臨走時小編也沒想明白,既然只是要求幾個按鈕的功能能正常展示頁面,為何不截個圖或者錄個視頻放到筆記本里?不過小編還是忍住了沒問,因為問了又能如何?
后記
這次事件小編明白了兩個道理:一是客戶的需求真的可以天馬行空,二是解決問題的能力是建立在對原理和現(xiàn)狀有清晰的基礎(chǔ)上的,只有掌握技術(shù)背后的原理,才能在應(yīng)用技術(shù)時游刃有余,有能力應(yīng)對各種需求解決各種問題,當(dāng)然這也是一名程序員應(yīng)該具備的素質(zhì)。
看來指望客戶不提“無理”需求是不可能了,能夠做到就是提高自身能力水平