忙碌的日子總是過得特別快，回頭一看，我已經做node.js BFF開發8個月了，基本上沒寫過web前端的事情，做了大半年，寫篇文章來記錄一下我這大半年的心路歷程。

初步規劃BFF

其實我剛進公司那會是做前端的，做B端前端開發，用react畫頁面，系統是一個持續做了一年多的，超過上百個模組的系統，畫了2個月，專案人員呼叫，我進入移動組，參與移動端的開發，重新開發 Hybrid App，然後當時認為還有h5，小程式，所以當時畫架構圖，我把多端也考慮進去了，當時領導提出需要做BFF接入到中臺到端，然而沒有當時預料的多端，只有越來越壯大的BFF。

初步使用node.js，BFF的起點

2019年7月，搭建了前端Vue專案，寫好了公共方法，另外的同事他們都是做IOS和Android開發的，所以沒有使用過Vue，搭好了專案庫框架，封裝了request，utils,等一些公共方法和樣式，編寫了兩個頁面，剩下的頁面就先讓他們開發。

也是在2019年7月，搭建了BFF第一個專案（已廢棄），BFF公司已經內部自封框架了，我不是公司第一個使用node.js的（但是其他人應該沒有前端和我一樣吧，連續幾個月全部是在做node.js BFF開發）。

第一個版本特別的簡單，純透傳，當時的寫法是每一個api都定義了一個router，然後 轉發到另一個服務上（暫且叫P服務，縮寫的第一個字母），資料全部來源自中臺，P系統在客戶端沒有請求後得20分鐘後Session過期，所以這裡只能把使用者密碼落入session中，透傳發生401時重新使用使用者賬號密碼解密。

編寫jenkins指令碼，編寫Docker指令碼部署，由於以前沒有接觸過這兩個東西，所以都是現學現用。

BFF拓展到了CBS層，也開始變得真正有價值，也開始有了踩坑

CBS customer business System 開會時leader們都是這麼叫的，我預計應該是這個意思

大概是10月份左右，我們接到了新的任務，接管另一套系統，融入到我們的App，從前端到後端（C服務）都要我們寫，這時候我開始看Java程式碼，用Node.js重寫後端邏輯，也開始需要有了更多的後端的東西，Mysql,服務發現,日誌，Redis快取層，BFF鑑權，還提到了cmq(訊息佇列)，這些階段我開始瘋狂的學習相關後端的東西。

BFF呼叫中臺登入，登入後的許可權，使用者資訊落入Redis，也解決分散式的許可權問題，api由原來的20個透傳，變成了60個介面左右，其中還有需要有兩個登入介面，分別登入到兩個不同的系統（P和C），把兩個系統的授權資訊全部存入Redis，可以說強行解決了使用者授權的問題，其實這裡我們意識到兩個系統不容易融合，所以一直考慮SSO單點登入的問題，花了不少的時間考慮單點登入，但是最終不是我們來做這麼事，由其它組的人開一個系統，把兩個系統的賬號密碼mapping存入他們系統，再每次登入的時候去他們的系統尋找mapping關係，如果有mapping，就自動登入另一個系統，也算強行解決了兩個系統的登入差異，這裡還設計了一張登入記錄表，每次的登入資訊存入表中。

由於對Redis，Mysql，和mq訊息佇列不太熟悉，所以在開發的時候也算苦不堪言，每天加班做業務，上下班坐地鐵，到家後就瘋狂學習相關知識，在使用Redis的時候發現自己對資料結構的了解太少了，因為自己不是計算機專業，對資料結構的知識只有JS資料型別這麼多，於是還花了時間去學習資料結構和演算法，主要是資料結構方面的東西。以前聽都沒聽過訊息佇列，即將要用了，還是要學習學習，資料庫也是接觸的少之又少的東西，從語法到B+樹，簡單的都了解了一下，語法學習了一下，資料庫還是很菜，稍微複雜一點都得查。

用了三個星期的時間，雖然對C系統的業務沒有什麼很多的了解，但是把Java語法翻譯到JS語法這個工作還是完成了。

期間部署踩了無數的坑，比如：我們的程式需要部署到多個地域，在深圳地域無法拉取到北京地域的映象，最後讓運維幫我把映象複製到深圳映象，並告知以後需要在另一個平臺去推映象。現在屬於流程不規範。還有其他一些坑，沒少麻煩架構師幫忙看問題，（也很感謝架構師

重新架構BFF層，CBS和BFF分開，開始拓展更多的業務系統

一段時間內相對平穩做迭代，這時候架構師開始對我們組進行要求，所有的日誌必須齊全，公共元件的接入也必須規範化，同時我的程式碼開始被code Review，review的時候我被吐槽的不要不要的，具體問題有：語法太過於疏散，面向過程開發，習慣了function開發方式（面向過程），需要更規範的面向物件，以及所有的非同步我基本都是使用了try catch包裹，一方面語法太難看，一方面不利於採集日誌（這裡我同架構師商量過了，也迭代了內部框架，直接呼叫，由框架進行錯誤捕捉，同時不會報出一些英文/程式碼錯誤的單詞）。

還有一個很重要的問題就是，BFF對接兩個兩個系統，以及還有對端的一些api，全都是在單體系統中，需要做架構拆分，於是架構師最後給出了一個方法，先拆成三個服務，一個是BFF代理服務，另外兩個，一個對接P服務，一個對接C服務 於是在19年年底，快放假的前兩個星期，我開始了改造之路，一邊進行改造，一邊進行迭代，組人並不多，BFF我在寫，其他同事在做微前端改造（感覺自己錯過了一個億的經驗值），於是這些事一點點積壓的非常忙，有時間就瘋狂學習，在家就瘋狂寫程式碼。

在2020 年的2月份，具體就是上個月中，這三個系統上線了，上線過程中不算順利，本來半分鐘就能啟動成功的容器，兩分鐘能切換的轉發，因為一些別的配置，上了兩個小時......

重新架構後帶來的好處

面向物件式程式設計，程式碼更簡潔易懂，也更好維護了。 100%原汁原味的Airbnb規範。 拆分成了三個服務，三個服務迭代開發互不影響，互相釋出部署也各不影響。 新框架迭代後日志更全了，rpc呼叫日誌，db操作日誌，三方呼叫日誌，api訪問日誌，對於錯誤記錄再也不用慌了。 新框架的服務發現採用中用到了多程序模式，也不會因為服務發現而影響主執行緒的邏輯處理。

重新架構後我遇到的鑑權問題

不同服務之間如何對客戶端的請求進行鑑權，比如我現在手頭又新啟了一個積分服務，這個積分服務的邏輯比較複雜，和中臺的互動較少，和資料庫的互動比較多，資料是自己存取的，所以也就是介面除了提供給App，還需要提供給B端管理平臺，這時候管理平臺的鑑權和APP的鑑權是不一樣的，需要呼叫B端系統來做管理平臺的鑑權，鑑權通過後我才能給資料，同時APP的鑑權（雖然APP的鑑權也是我寫的，可是不在這一個服務上，我還是需要呼叫另一個服務才能達到鑑權的目的），覺得有一些繁瑣，我想大廠裡成百個系統一定不可能是這麼鑑權的，對接起來會累死。這一點目前還沒有想到好的解決辦法。

node開發的優點

第一優點當然是 JS語言的優勢，語法上上手的成本非常少。 之前我們是考慮了多端的場景的，多端在這裡依然是優勢，中臺只需要給出一份資料，BFF可以根據不同端給出不同資料 適用nodejs做接入層非常合適，開發迅速，部署方便，成本極低 前端開發的時候總是要和後端溝通欄位的問題，CBS給出的介面基本上是完全對照頁面給的，跟我基本上不需要溝通欄位的問題，一方面BFF可以做介面聚合，多個介面的資料放到一個介面上，客戶端減少請求次數。 這種趨勢越來越流行，比如小程式雲開發，Serverless 超輕量級服務，在一些業務場景中還是很適用的。

槽點

Node.js的學習資源還是太少了，比如我在學習Redis的實戰教程的時候，就只能看Java版本的，學習RabbitMq的時候也是Java的。我看的資料結構和演算法教程也是Java的，當然這個可能大家都是看C的，但我不會C，就很無奈了，當然書籍有JavaScript版本的，大家感興趣可以自己看。 實戰方面的踩坑，我也踩過不少，比如使用node圖片處理，這方面我也是踩坑了兩天才上手了。node-canvas 生成營銷圖。

但是，作為一個開發工程師，除了開發的能力，還要具備工程師不折不扣的折騰主義精神。奧力給。

總結

這段時間的node.js開發，接觸到了許多前端之外的東西，藉著這段時間也把後端的一些知識簡單的學了一下，後端其實也有很多東西，遠不止我提到的這些。 對非同步程式設計的理解也更深入了，對於nodejs的了解也不是以前的demo級。 雖然有學習資源相對較少，但還是不影響node.js價效比很強的事實，記憶體使用很少，CPU佔用也很小，這一點對於企業來說也很重要，資源就是錢。

價效比體現可以看Node + MQ 限流小計，雖然沒有體現出極致效能，但還是可以看得出一些效果的。

路漫漫其修遠兮，吾將上下而求索

原連結：https://github.com/coolliyong/coolliyong.github.io