node.js BFF開發8個月的心路歷程

忙碌的日子老是過得特別快，回頭一看，我已經作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腳本部署，因爲之前沒有接觸過這兩個東西，因此都是現學現用。

第一個版本上線的時候也踩了很多坑，由於一些Docker相關的服務轉發和對容器不是很熟的緣由，總體來講上線還算OK。

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 限流小計，雖然沒有體現出極致性能，但仍是能夠看得出一些效果的。

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

---

其餘連接：

github博客：歡迎star，一塊兒學習，一塊兒成長

KOA 中間件機制和實現

Nodejs 操做 RabbitMq 快速上手