對中間層的一些淺略的思考

什麼香香脆脆我們最愛 2022-01-08 03:49:44 阅读数:649

思考

這篇文章不涉及code,勉强算是一篇觀察文

1. 何為中間層

這裏說的中間層,主要就是 橫跨在java後臺和前端的node中間層。 大概流程就是 前端向中間層發送請求,中間層轉發整合請求到java後臺。

中間層的主要工作是
① 轉發請求,順帶做一些數據處理。
② 整合多個後臺請求為一個請求,供前端試用
③ 搶幾口後臺飯碗裏面的飯(如果你願意)

2. 理論基礎

之前在查詢資料的時候,偶然發現,中間層也是一種設計模式:Facade模式(外觀模式)

圖片來源
在這裏插入圖片描述
在這裏插入圖片描述
圖片來源
在這裏插入圖片描述

3. 緣何而起

這邊,中間層項目是初期的時候我接手的。

大部分公司項目主管或技術總監一般都是後臺,而對於中間層這種類似項目架構的技術選型,前端一般沒有什麼真正的話語權。

不巧的是,公司這邊的技術總監是一個技術愛好者,愛好在項目中使用和實踐新技術(非貶義)。雖然中間層在2020年算不得什麼新技術,但是公司之前項目裏面從來沒有使用過中間層這種 (題外話:他前端,後臺乃至運維都很666)。

我記得我問過他,為什麼使用中間層,他說:“剛剛開始做這個項目的時候,和後臺對業務數據結構上有很大爭議, 所以做了個中間層緩和。再者這個項目不僅僅會調用一個java項目,也會調用其他java項目的接口。最後中間層可以移植,比如以後api換了一套,前端不用動code”。(可以看出大佬喜歡把項目主動權牢牢把握在自己手裏,即便是寫前端)。

4. 磕磕絆絆

項目剛剛接手的時候,會涉及到一些偏後臺方面的知識:比如調用mongodb的api,比如批量更新mongodb數據,比如直連ActiveMQ,比如graphql接口,比如node轉發文件流等等。所幸通過查詢資料,詢問同事,不斷實踐都一點點過來了。

5. 潤物細無聲

前端 + 中間層 + java後臺這個組合,自從2020年6月份開始。已經跌跌撞撞運行了1.5年的時間了。除了前幾次,剛剛部署到服務器上到時候出過一些問題,其他時候沒有出過什麼大問題。以至於到了被忽略的地步。

前不久,該項目相關的項目,要進行10w用戶為期2天同時在線的使用。java同事在開會的時候說中間層可能會有瓶頸。大領導說怎麼會有一個中間層,他“從來不知道”。

6. 思考

6.1 雞肋和孤兒

雖說在負責中間層項目中,受益匪淺,好處也有不少。但是個人感覺在中小公司使用這種中間層的架構確實有點雞肋(鄙人沒去過大公司)。假設把中間層從java後臺和前端直接拿開, 項目不會有較大影響。特別是對於我們公司這種一個人負責好幾個項目的開發,好處可能更多一些。

在將近1.5年的維護中 ,給我的感覺就是中間層項目,無論在上級,還是在前端同事和java同事,乃至運維同事的眼中。都是一個可有可無的孤兒。哈哈

6.2 職責不明確

中間層這塊有一點搶後臺飯碗的意思,會導致職責模糊(可能大公司中間層會有明確職責)。

舉例來說:在剛剛開始的時候,因為項目涉及到需要偶爾更新和node中間層關聯的mongodb數據庫的數據,所以我問了幾個java同事,大家都不願意負責這塊。都覺得項目既然是前端負責,那和項目有關的應該都負責。

所以會經常出現“上一秒還在寫css;下一秒就登上robot3t,update數據庫數據。”的場景。

除此之外,一些比如本地化部署的時候購買mongodb這些也需要去提醒運維,java那邊mongodb用的比較少,偶爾會“忘記”。在一些只能連vpn部署項目的機子上,export和import 數據。購買服務器後更新nginx中 node配置。調試因為node和java 在連接activemq的時候,因為協議不一樣,所以端口不一樣等等這些問題。都是需要前端負責解决的。

屬於“幹好被忽略,出現問題算bug”。並不是說這些工作前端不能做,而是術業有專攻。我自己也維護著一個小程序項目。從前到後到服務端部署,都是我一個人做的。 前端做後臺工作,最大的問題之一就是缺乏安全觀念。 比如前2年很多在線mongodb數據庫 默認27017端口,默認無密碼,被送了勒索大禮包,你說使用這些出現事故的開發者裏面沒有前端我是不相信的。再者更新數據需要提前備份這些小習慣等等。 弄不好會出現 “前端删了數據庫”

6.3 調試不方便

比如線上出現了一個接口bug,後臺是無法通過f12直接查看到真正的接口和參數的。正常的流程是前端登錄xshell,查看pm2 logs日志。找出真正的參數和接口。在postman上測試真的有問題後。再發送給後臺。

所以,每當接口報錯,後臺總是說:“讓前端先看看”。 久而久之,在某些人的概念裏面就變成了“前端問題很多了”。

且由於中間層連接了多個後臺,甚至於自己讀寫mongodb。所以前期項目出現問題的時候,需要前端根據經驗做一個錯誤分發。但是後期隨著項目越來越穩定以及經驗的增加,即使有問題也能比較快的找出根源。

6.4 後繼無人?

之前一個前端同事,接過2天這個項目,但是感覺不情不願的,哈哈。他那2天負責還只是轉發接口部分的code。

招聘的時候,發現使用node和該方面意向的也比較少,再加上又沒有專門的中間層崗比特。所以實際情况就是在負責好幾個前端項目的同時,還要負責這些。

不過後繼無人,有一種“皇上不急太監急 ”的意思,畢竟“地球離了誰都轉”, 且"跪著賺錢不寒磣"。

版权声明:本文为[什麼香香脆脆我們最愛]所创,转载请带上原文链接,感谢。 https://gsmany.com/2022/01/202201080349441835.html