背景

前幾天被派去處響應(yīng)客戶提出的需求。

客戶需求

之前公司給客戶開(kāi)發(fā)部署了一套Web應(yīng)用，是Vue+Node.js的架構(gòu)。

現(xiàn)在客戶要求把這個(gè)Web應(yīng)用放到一臺(tái)筆記本里，要求web應(yīng)用的網(wǎng)頁(yè)要能正常顯示。

小編快速思考了一下，在筆記本上搭建好Vue和Node.js的環(huán)境，將前端、后端源代碼copy到筆記本上跑起來(lái)，把數(shù)據(jù)庫(kù)一遷移不就完事了嘛，小意思。

然而還是太年輕，把問(wèn)題想得太理想。

溝通后才發(fā)現(xiàn)這個(gè)系統(tǒng)的后臺(tái)開(kāi)發(fā)數(shù)據(jù)庫(kù)是分布式數(shù)據(jù)庫(kù)，由幾十臺(tái)服務(wù)器組成，這...這還怎么玩啊！

首先，要把這個(gè)分布式數(shù)據(jù)庫(kù)塞到筆記本里顯然不現(xiàn)實(shí)，同時(shí)了解到Web應(yīng)用中的一些統(tǒng)計(jì)功能需要進(jìn)行全表查詢計(jì)算，即使我能把數(shù)據(jù)庫(kù)塞進(jìn)筆記本，幾個(gè)TB的數(shù)據(jù)庫(kù)表我也塞不進(jìn)去啊！其次客戶不允許把全量數(shù)據(jù)庫(kù)數(shù)據(jù)導(dǎo)出到筆記本，簡(jiǎn)直要哭了！

解決方案

這種情況，看來(lái)數(shù)據(jù)庫(kù)是不用想了，小編趕緊思考別的解決方案，要不然Leader所謂的小問(wèn)題都解決不了，豈不是太（fan）給（wan）公(bu)司(bao)丟臉了。小編想起Leader意味深長(zhǎng)的笑，心里早已MMP了。

既然數(shù)據(jù)庫(kù)不能遷移到筆記本，那前端所需要的數(shù)據(jù)該怎么獲取呢？

我們先來(lái)回顧web的整個(gè)交互流程。下圖是目前客戶整個(gè)web應(yīng)用示意圖：

簡(jiǎn)單來(lái)說(shuō)，一個(gè)動(dòng)態(tài)網(wǎng)頁(yè)的獲取分以下幾步：

拉取靜態(tài)頁(yè)面

當(dāng)用戶在瀏覽器輸入U(xiǎn)RL回車后，通過(guò)Http的Get請(qǐng)求向Http服務(wù)器請(qǐng)求拉取靜態(tài)html頁(yè)面以及相關(guān)的CSS、JS等資源文件

瀏覽器解析階段

瀏覽器解析html頁(yè)面，并執(zhí)行相應(yīng)的JS代碼，JS代碼中會(huì)包含相應(yīng)的異步數(shù)據(jù)請(qǐng)求。

異步數(shù)據(jù)請(qǐng)求

瀏覽器通過(guò)異步數(shù)據(jù)請(qǐng)求向Node服務(wù)器請(qǐng)求數(shù)據(jù)

后端服務(wù)器響應(yīng)

Node服務(wù)器根據(jù)的請(qǐng)求，執(zhí)行相應(yīng)功能的代碼，例如，如果是拉取商品列表的數(shù)據(jù)請(qǐng)求，Node服務(wù)器會(huì)向數(shù)據(jù)庫(kù)查詢商品列表信息，將組織好的數(shù)據(jù)包裝成Json等格式作為請(qǐng)求的響應(yīng)返回給瀏覽器

異步刷新頁(yè)面

瀏覽器端JS代碼通過(guò)異步請(qǐng)求拿到異步請(qǐng)求返回的數(shù)據(jù)，繼續(xù)執(zhí)行相關(guān)的數(shù)據(jù)組織處理的JS代碼，最終將數(shù)據(jù)異步更新到網(wǎng)頁(yè)上。

結(jié)束

至此，一個(gè)簡(jiǎn)單的瀏覽器請(qǐng)求背后的流程到此結(jié)束，用戶通過(guò)輸入U(xiǎn)RL看到了想要看到的網(wǎng)頁(yè)的內(nèi)容。

經(jīng)過(guò)對(duì)背后流程的梳理，小編已經(jīng)明確問(wèn)題出在數(shù)據(jù)庫(kù)上，并且既然數(shù)據(jù)庫(kù)不能訪問(wèn)，相應(yīng)的，后端Node服務(wù)器的存在也沒(méi)有什么意義了。

事實(shí)上，對(duì)于前后臺(tái)分離的架構(gòu)，若要保證網(wǎng)頁(yè)的正常訪問(wèn)，只要能保證前端向后臺(tái)發(fā)起的數(shù)據(jù)請(qǐng)求，能夠返回一致的數(shù)據(jù)即可。

意思是，只要能夠保證前端請(qǐng)求，有正常的響應(yīng)（數(shù)據(jù)）即可，不管是Node服務(wù)器對(duì)請(qǐng)求進(jìn)行響應(yīng)，還是誰(shuí)提供的響應(yīng)。

把后端想象成一個(gè)服務(wù)提供者，只要能提供服務(wù)，任何的解決方案都是可行的。

于是小編腦中浮現(xiàn)了一個(gè)方案：

將現(xiàn)有系統(tǒng)中每個(gè)后臺(tái)請(qǐng)求的返回的結(jié)果數(shù)據(jù)都先保存成本地文件，同時(shí)重新開(kāi)發(fā)后臺(tái)服務(wù)響應(yīng)接口，對(duì)于指定的請(qǐng)求返回之前相同接口請(qǐng)求保存的本地文件數(shù)據(jù)，整個(gè)架構(gòu)變成下圖的樣子：

這樣既達(dá)到了能夠返回實(shí)際的數(shù)據(jù)，同時(shí)前端也沒(méi)有任何感知和影響。

實(shí)際上這樣還是不能完全解決問(wèn)題。例如，如果有一下需要修改、寫入數(shù)據(jù)庫(kù)的操作，這種方式就沒(méi)有效了。

畢竟我們只是偽裝能一個(gè)能夠正常響應(yīng)查詢的假后端，并沒(méi)有實(shí)際的數(shù)據(jù)庫(kù)。

不過(guò)好在客戶說(shuō)只要滿足首頁(yè)和幾個(gè)查詢按鈕的正常展示即可。

接下來(lái)的主要工作就是梳理現(xiàn)有接口，把實(shí)際數(shù)據(jù)請(qǐng)求接口返回的數(shù)據(jù)都保存下來(lái)，并且記錄它們之間的對(duì)應(yīng)關(guān)系。然后就是重新開(kāi)發(fā)后端服務(wù)，將前端過(guò)來(lái)的請(qǐng)求，返回之前保存的對(duì)應(yīng)的文件中的數(shù)據(jù)即可。

舉個(gè)例子，之前某個(gè)前端請(qǐng)求對(duì)應(yīng)的后端處理代碼可能是這樣的：

string get_goods_list(request)

{

  //獲取request中請(qǐng)求參數(shù)

  ...

  //查詢數(shù)據(jù)庫(kù)

  ...

  //組織數(shù)據(jù)格式并返回

  return json_respone;

}

而重新開(kāi)發(fā)的后端處理代碼就變成這樣了：

string get_goods_list(request)

{

  //讀取保存到本地的數(shù)據(jù)請(qǐng)求返回的數(shù)據(jù)

  ...

  //直接將數(shù)據(jù)返回給前端

  return json_respone;

}

特別的簡(jiǎn)單粗暴，但是確實(shí)有效，當(dāng)然事情也不可能如此順利，由于這個(gè)系統(tǒng)當(dāng)時(shí)的研發(fā)人員已經(jīng)離職，小編只能靠留存的簡(jiǎn)單項(xiàng)目部署說(shuō)明，外加一點(diǎn)點(diǎn)摸索，在解決無(wú)數(shù)次error后，客戶終于在一臺(tái)筆記本上看到了預(yù)期的頁(yè)面效果。

直到臨走時(shí)小編也沒(méi)想明白，既然只是要求幾個(gè)按鈕的功能能正常展示頁(yè)面，為何不截個(gè)圖或者錄個(gè)視頻放到筆記本里？不過(guò)小編還是忍住了沒(méi)問(wèn)，因?yàn)閱?wèn)了又能如何？

后記

這次事件小編明白了兩個(gè)道理：一是客戶的需求真的可以天馬行空，二是解決問(wèn)題的能力是建立在對(duì)原理和現(xiàn)狀有清晰的基礎(chǔ)上的，只有掌握技術(shù)背后的原理，才能在應(yīng)用技術(shù)時(shí)游刃有余，有能力應(yīng)對(duì)各種需求解決各種問(wèn)題，當(dāng)然這也是一名程序員應(yīng)該具備的素質(zhì)。

看來(lái)指望客戶不提“無(wú)理”需求是不可能了，能夠做到就是提高自身能力水平