忙碌的日子總是過得特別快，回頭一看，我已經做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 限流小計，雖然沒有體現出極致性能，但還是可以看得出一些效果的。
路漫漫其修遠兮，吾將上下而求索
原鏈接：https://github.com/coolliyong/coolliyong.github.io
閱讀更多 Echa攻城獅 的文章
