建站
咨詢
售后
建站咨詢
新聞中心
[[390852]]
前言
nodejs的出現(xiàn)為前端行業(yè)帶來了無限的可能性,讓很多原來只負責(zé)客戶端開發(fā)的同學(xué)也慢慢開始接觸和使用服務(wù)器端技術(shù).
柳江ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為成都創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18980820575（備注：SSL證書合作）期待與您的合作！
雖然nodejs帶來了很多的好處,但是它也存在自身的局限性.和那些傳統(tǒng)老牌的編程語言相比,如JAVA,PHP.nodejs并不能成為它們的替代品,而且在可預(yù)估的未來,也很難撼動那些老牌編程語言的地位.
目前nodejs主要有以下幾個應(yīng)用場景.
- 前端工程化,比如rollup,webpack在工程化方向的探索
- nodejs中間層
- 客戶端集成nodejs,比如electron
- 市面上一些不太復(fù)雜的應(yīng)用選擇nodejs作為后端編程語言
本文主要講一講nodejs作為中間層的一些實踐，查看下圖.
傳統(tǒng)的的開發(fā)模式由瀏覽器直接和Server層直接通信,中間層的加入意味著在瀏覽器和Server層之間額外添加了一層.
原來客戶端直接向Server發(fā)送請求,Server層收到請求后經(jīng)過計算處理將結(jié)果返回給瀏覽器.
如今瀏覽器將請求發(fā)送給node層,node層經(jīng)過一輪處理后再向Server層發(fā)起請求.Server層處理完畢將響應(yīng)結(jié)果返回給node層,node層最后將數(shù)據(jù)返回給瀏覽器.
因為node層的出現(xiàn),Server層可以只用關(guān)注業(yè)務(wù)本身,而不必理會前端對字段的特殊要求。
node層可以向server層獲取數(shù)據(jù),再通過對數(shù)據(jù)的計算整合轉(zhuǎn)換成符合前端UI要求的數(shù)據(jù)格式.另外整個應(yīng)用如果采用微服務(wù)架構(gòu),那么Server層會有很多臺管理單獨業(yè)務(wù)模塊的服務(wù)器,node層就很好的適配了微服務(wù)的架構(gòu),它可以向多臺服務(wù)器發(fā)起請求獲取到不同模塊的數(shù)據(jù)再整合轉(zhuǎn)化發(fā)送給前端.
下面著重介紹一下nodejs作為中間層的部分實踐.
代理轉(zhuǎn)發(fā)
代理轉(zhuǎn)發(fā)在實際中有很多廣泛的應(yīng)用.瀏覽器首先將請求發(fā)送給node服務(wù)器,請求收到后node服務(wù)器可以對請求做一些處理,比如將原來的路徑變換一下,請求頭的信息改變一下,再把修改后的請求發(fā)送給遠程真實的服務(wù)器.
遠程服務(wù)器計算出響應(yīng)結(jié)果再返回給node服務(wù)器,node服務(wù)器仍然可以對響應(yīng)做選擇性處理再分返回給瀏覽器.
代理轉(zhuǎn)發(fā)可以解決前端日常開發(fā)中經(jīng)常遇到的跨域問題,另外它還屏蔽了遠程真實服務(wù)器的細節(jié),讓瀏覽器只與node服務(wù)器通信.下面是簡單的實踐.
- const express = require('express');
- const { createProxyMiddleware } = require('http-proxy-middleware');
- const app = express();//創(chuàng)建應(yīng)用
- app.use("/api",createProxyMiddleware( //設(shè)置代理轉(zhuǎn)發(fā)
- {
- target: 'http://www.xxx.com', //舉例隨便寫的地址
- changeOrigin: true,
- pathRewrite: function (path) {
- return path.replace('/api', '/server/api');
- }
- })
- );
- app.use("*",(req,res)=>{ //不是以'/api'開頭的路由全部返回"hello world"
- res.send("hello world");
- })
- app.listen(3000);
http-proxy-middleware是一個第三方依賴包,可以非常方便設(shè)置代理轉(zhuǎn)發(fā),需要通過npm安裝.
如果當(dāng)前訪問的路徑是以/api開頭,那么該請求就會被http-proxy-middleware攔截.觀察http-proxy-middleware里面配置的參數(shù).
- target代表遠程真實服務(wù)器的地址.
- changeOrigin設(shè)置為true,表示將請求轉(zhuǎn)發(fā)到target地址上.
- pathRewrite是對請求路徑做一下處理,將/api轉(zhuǎn)換成/server/api.
上面的案例意思很明顯,假如當(dāng)前瀏覽器訪問http://localhost:3000/api/list.因為這個路徑以/api開頭所以會被攔截,從而觸發(fā)pathRewrite函數(shù)修改訪問路徑.最終訪問路徑就變成了http://www.xxx.com/server/api/list,然后就會向這個路徑發(fā)起請求,得到響應(yīng)后再返回給瀏覽器.
接口聚合
上面介紹的接口轉(zhuǎn)發(fā)在實踐中很少會單獨應(yīng)用,如果僅僅只是為了轉(zhuǎn)發(fā)一下數(shù)據(jù),那還不如直接用nginx配置一下，轉(zhuǎn)發(fā)就搞定了.
如果接口聚合和接口轉(zhuǎn)發(fā)都需要,那么從代碼層面去解決還是優(yōu)先考慮的方式.
接口聚合是什么意思呢?假設(shè)現(xiàn)在企業(yè)有兩個銷售體系,一個是線上的電商平臺銷售,另一個是線下實體店.它們分別屬于不同的團隊運營,維護著不同的數(shù)據(jù)系統(tǒng).
如果當(dāng)前請求只是想查詢一下電商平臺某款商品的信息,只需要將接口轉(zhuǎn)發(fā)給電商平臺系統(tǒng)即可.同理如果僅僅只是查詢線下實體店某一天的銷售業(yè)績,可以直接把請求轉(zhuǎn)發(fā)給線下數(shù)據(jù)系統(tǒng)查詢,再把響應(yīng)數(shù)據(jù)返回.上面介紹的插件http-proxy-middleware支持配置多個代理路徑,詳細可查詢文檔.
現(xiàn)在有這么一個需求,目標(biāo)是查詢本周某款商品在線上和線下銷售數(shù)據(jù)的對比.那么這個時候就需要node層向兩個遠程服務(wù)器發(fā)送請求分別獲取線上銷售數(shù)據(jù)和線下銷售數(shù)據(jù),將這兩部分?jǐn)?shù)據(jù)聚合處理后再返回給前端.簡單實踐如下.
- const express = require('express');
- const { createProxyMiddleware } = require('http-proxy-middleware');
- const app = express();//創(chuàng)建應(yīng)用
- //偽代碼
- app.get("/getSaleInfo",async (req,res)=>{
- const online_data = await getOnline(); //獲取線上數(shù)據(jù)
- const offline_data = await getOffline(); //獲取線下數(shù)據(jù)
- res.send(dataHanlder(online_data,offline_data)); //對數(shù)據(jù)處理后返回給前端
- })
- proxyHanlder(app);//偽代碼,將代理轉(zhuǎn)發(fā)的邏輯封裝起來
- app.use("*",(req,res)=>{
- res.send("hello world");
- })
- app.listen(3000);
/getSaleInfo代表著將兩條數(shù)據(jù)聚合的自定義路由,如果需要聚合數(shù)據(jù)的需求比較多,這塊邏輯要單獨封裝到路由模塊中管理,并且要寫在代理轉(zhuǎn)發(fā)的前面.
這樣就確保了需要轉(zhuǎn)發(fā)的接口就交給轉(zhuǎn)發(fā)的邏輯處理,需要個性化處理數(shù)據(jù)的接口就單獨編寫路由操作數(shù)據(jù).
數(shù)據(jù)緩存
緩存對于提升系統(tǒng)性能,減小數(shù)據(jù)庫壓力起到了無足輕重的作用.一般常用的緩存軟件是redis,它可以被理解成數(shù)據(jù)存儲在內(nèi)存當(dāng)中的數(shù)據(jù)庫.由于數(shù)據(jù)放在內(nèi)存中,讀寫速度非常快,能極快的響應(yīng)用戶的請求.
在node層部署redis管理緩存數(shù)據(jù),可以提升整體應(yīng)用性能.但不是什么數(shù)據(jù)都建議存放在redis中,只有那些不經(jīng)常變動的數(shù)據(jù)應(yīng)該設(shè)置成緩存.
比如商品的信息數(shù)據(jù),瀏覽器對某個商品發(fā)起請求,想查看該商品的詳情.請求第一次到達node層,redis此時是空的.那么node開始請求server層得到響應(yīng)結(jié)果,此時在將響應(yīng)結(jié)果返回給瀏覽器之前,將該次請求的訪問路徑作為key值,響應(yīng)結(jié)果作為value存儲到redis中.這樣之后再有相同的請求發(fā)來時,先查看redis有沒有緩存該請求的數(shù)據(jù),如果緩存了直接將數(shù)據(jù)返回,如果沒有緩存再去請求server層,把上述流程再走一遍.
redis還可以對緩存數(shù)據(jù)設(shè)置過期時間和清除,可以根據(jù)具體的業(yè)務(wù)操作.簡單實踐如下.
- const express = require('express');
- const app = express();//創(chuàng)建應(yīng)用
- //偽代碼
- app.use("*",(req,res,next)=>{
- const path = req.originalUrl; //獲取訪問路徑
- if(redisClient.getItem(path)){ //查看redis中有沒有緩存該條接口的數(shù)據(jù)
- res.send(redisClient.getItem(path)); // 返回緩存數(shù)據(jù)
- }else{
- next(); //不執(zhí)行任何操作,直接放行
- }
- })
- aggregate(app); //偽代碼,將接口聚合的邏輯封裝起來
- proxyHanlder(app);//偽代碼,將代理轉(zhuǎn)發(fā)的邏輯封裝起來
- app.use("*",(req,res)=>{
- res.send("hello world");
- })
- app.listen(3000);
接口限流
node做中間層可以對前端無節(jié)制的訪問做限制.比如有些惡意的腳本循環(huán)訪問接口,一秒鐘訪問幾十次增大了服務(wù)器的負載.
redis可以幫助我們實現(xiàn)這一功能.用戶第一次訪問,解析出本次請求的ip地址,將ip作為key值,value置為0存到redis中.
用戶第二次訪問,取出ip找到redis中對應(yīng)的value,然后自增1.如果是相同的人重復(fù)大量訪問,value在短期內(nèi)就自增到了很大的數(shù)字,我們可以每次獲取這個數(shù)字判端是否超過了設(shè)定的預(yù)期標(biāo)準(zhǔn),超過則拒絕本次請求.簡單實踐如下.
- const express = require('express');
- const app = express();//創(chuàng)建應(yīng)用
- //偽代碼
- app.use("*",(req,res,next)=>{
- const ip = req.ip;
- let num = 0;
- if(redisClient.getItem(ip)){ //是否緩存了當(dāng)前的ip字段
- num = redisClient.incr(ip); //每訪問一下,計數(shù)加1
- }else{
- redisClient.setItem(ip,0);
- redisClient.setExpireTime(5); //設(shè)置過期時間為5秒,5秒后再獲取該ip為空
- }
- if(num > 20){
- res.send("非法訪問");
- }else{
- next();//放行
- }
- })
- cacheData(app)//偽代碼.緩存接口數(shù)據(jù)
- aggregate(app); //偽代碼,將接口聚合的邏輯封裝起來
- proxyHanlder(app);//偽代碼,將代理轉(zhuǎn)發(fā)的邏輯封裝起來
- app.use("*",(req,res)=>{
- res.send("hello world");
- })
- app.listen(3000);
在應(yīng)用的前面設(shè)置一層限流中間件,每次訪問來臨先判端是否緩存過.第一次訪問肯定沒有緩存,就將當(dāng)前ip對應(yīng)的值設(shè)置為0并添加過期時間為5秒鐘.下一次相同的用戶再訪問時就會將value自增1.
最后的效果就達到了5秒內(nèi)調(diào)用接口的次數(shù)超過20次便拒絕訪問.
日志操作
系統(tǒng)沒有日志,相當(dāng)于人沒有雙眼.日志可以幫助我們發(fā)現(xiàn)分析定位線上系統(tǒng)出現(xiàn)的錯誤.另外通過日志數(shù)據(jù)也可以進行統(tǒng)計計算得出某些結(jié)論和趨勢.
node層能夠承擔(dān)起管理日志的功能,以接口訪問日志為例.在系統(tǒng)中新建一個日志文件夾,每次有請求訪問時,首先解析請求的路徑、當(dāng)前的訪問時間以及攜帶的參數(shù)和終端數(shù)據(jù)信息.然后在日志文件夾創(chuàng)建一個txt文件存放當(dāng)天日志情況,將上述數(shù)據(jù)和該請求的響應(yīng)結(jié)果組合成一條記錄插入txt文件中.下一次訪問繼續(xù)走上面流程往txt文件添加訪問日志.像上面介紹的代理轉(zhuǎn)發(fā),插件http-proxy-middleware支持配置如何返回響應(yīng)結(jié)果,那么在相應(yīng)的事件函數(shù)鉤子里就可以同時得到請求和響應(yīng),有了這兩塊數(shù)據(jù)就可以存放到日志中.
這里還能制定很多的配置策略.可以選擇一天一個日志文本,如果訪問量巨大也可以選擇一個小時一個日志文本,依據(jù)實際情況而定.
另外隨著時間的延長,日志文件夾的文件內(nèi)容會越來越多.這就需要編寫linux操作系統(tǒng)定時任務(wù)來遷移和備份這些日志數(shù)據(jù).
日志操作簡單實踐如下.
- //偽代碼
- app.use("/getList",async (req,res)=>{
- const list = await getProductList(); //獲取商品數(shù)據(jù)
- const { 訪問時間,訪問路徑,參數(shù) } = req;
- logger.log('info',`${訪問時間}-${訪問路徑和參數(shù)}:${list}`);//將數(shù)據(jù)存儲到日志文件中
- res.send(list);//將結(jié)果返回給客戶端
- })
結(jié)尾
中間層另外還可以做很多其他事情,比如監(jiān)控、鑒權(quán)和服務(wù)器端渲染(SSR).這部分由于內(nèi)容比較多可以單獨成章,網(wǎng)絡(luò)上也有大量如何實踐的文章,可搜索查閱學(xué)習(xí).
其實上面所談到的所有功能其他編程語言都可以做到,這也成為了很多人質(zhì)疑是否需要在架構(gòu)上額外再加一層的顧慮.
添加nodejs中間層,對于前端同學(xué)來說肯定是好消息.因為它能讓前端承擔(dān)更多的工作任務(wù),讓前端的業(yè)務(wù)比重變大.另外后端從此只需要關(guān)注自身業(yè)務(wù),前端繼續(xù)干著自己擅長的事,從整體上是能提升開發(fā)效率.
但從宏觀角度上看,架構(gòu)額外增加一層勢必會造成整個應(yīng)用性能上的損耗,另外在部署,測試層面都會增大運維成本.
當(dāng)下前后端分離已經(jīng)成為了主流的開發(fā)模式,很多類型的應(yīng)用需要seo的支持以及首屏加載速度,因此服務(wù)器端渲染不可或缺.前端項目目前大多采用react或vue框架開發(fā),如果用nodejs承擔(dān)服務(wù)器端渲染的任務(wù),那么可以確保一套代碼既可以做客戶端渲染也能支持服務(wù)器端渲染,而這些工作都可以讓前端程序員獨立來完成.服務(wù)器端渲染技術(shù)非常重要,后面會開一個小節(jié)單獨講解.
綜上來看,nodejs做中間層最有價值的功能是服務(wù)器端渲染和接口數(shù)據(jù)聚合.如果企業(yè)應(yīng)用數(shù)量較少業(yè)務(wù)簡單還沒有規(guī)?；?不建議添加中間層,那樣反而讓簡單的事情變得復(fù)雜.
文章標(biāo)題：淺談Nodejs中間層
URL標(biāo)題：http://www.dlmjj.cn/article/cddecge.html
