背景

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

客戶需求

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

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

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

然而還是太年輕，把問題想得太理想。

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

首先，要把這個(gè)分布式數(shù)據(jù)庫塞到筆記本里顯然不現(xiàn)實(shí)，同時(shí)了解到Web應(yīng)用中的一些統(tǒng)計(jì)功能需要進(jìn)行全表查詢計(jì)算，即使我能把數(shù)據(jù)庫塞進(jìn)筆記本，幾個(gè)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的整個(gè)交互流程。下圖是目前客戶整個(gè)web應(yīng)用示意圖：

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

拉取靜態(tài)頁面

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

瀏覽器解析階段

瀏覽器解析html頁面，并執(zhí)行相應(yīng)的JS代碼，JS代碼中會(huì)包含相應(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ù)器會(huì)向數(shù)據(jù)庫查詢商品列表信息，將組織好的數(shù)據(jù)包裝成Json等格式作為請求的響應(yīng)返回給瀏覽器

異步刷新頁面

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

結(jié)束

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

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

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

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

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

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

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

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

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

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

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

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

舉個(gè)例子，之前某個(gè)前端請求對應(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;

}

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

直到臨走時(shí)小編也沒想明白，既然只是要求幾個(gè)按鈕的功能能正常展示頁面，為何不截個(gè)圖或者錄個(gè)視頻放到筆記本里？不過小編還是忍住了沒問，因?yàn)閱柫擞帜苋绾危?/p>

后記

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

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