背景

前幾天被派去處響應客戶提出的需求。

客戶需求

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

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

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

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

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

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

解決方案

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

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

我們先來回顧web的整個交互流程。下圖是目前客戶整個web應用示意圖：

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

拉取靜態(tài)頁面

當用戶在瀏覽器輸入URL回車后，通過Http的Get請求向Http服務器請求拉取靜態(tài)html頁面以及相關的CSS、JS等資源文件

瀏覽器解析階段

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

異步數(shù)據(jù)請求

瀏覽器通過異步數(shù)據(jù)請求向Node服務器請求數(shù)據(jù)

后端服務器響應

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

異步刷新頁面

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

結束

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

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

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

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

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

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

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

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

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

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

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

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

舉個例子，之前某個前端請求對應的后端處理代碼可能是這樣的：

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;

}

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

直到臨走時小編也沒想明白，既然只是要求幾個按鈕的功能能正常展示頁面，為何不截個圖或者錄個視頻放到筆記本里？不過小編還是忍住了沒問，因為問了又能如何？

后記

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

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