這些日子一直在做 Node 方面的嘗試，或多或少會(huì)收到周圍的異樣的目光甚至背后的質(zhì)疑，于是促使我好好思考為什么我在做 Node。網(wǎng)上搜下「為什么要用 Node」，找到的文章多數(shù)是介紹 Node 多么多么牛逼，無非是從 Node 本身特性來說，比如：并發(fā)、事件驅(qū)動(dòng)、非阻塞 I/O、單線程、流、社區(qū)生態(tài)…… 諸如此類，很少談業(yè)務(wù)場景。

成都創(chuàng)新互聯(lián)服務(wù)項(xiàng)目包括鄱陽網(wǎng)站建設(shè)、鄱陽網(wǎng)站制作、鄱陽網(wǎng)頁制作以及鄱陽網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，鄱陽網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到鄱陽省份的部分城市，未來相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

我是「實(shí)用主義」者，說過：脫離業(yè)務(wù)場景談架構(gòu)都是耍流氓。因?yàn)閭€(gè)人是從一線業(yè)務(wù)做起的，經(jīng)過幾年對(duì)業(yè)務(wù)的思考，我覺得可以從業(yè)務(wù)場景來說說為什么我們的業(yè)務(wù)更適合用 Node。

從業(yè)務(wù)場景說起

現(xiàn)在我們的業(yè)務(wù)模塊化越來越普遍，很少有業(yè)務(wù)比較純粹只有鏈接一個(gè)數(shù)據(jù)庫就可以搞定，往往前臺(tái)業(yè)務(wù)后面會(huì)有 N 多的 API 服務(wù)做支撐。比如：下面兩種情況在我們實(shí)際開發(fā)中經(jīng)常遇見：

1. 某個(gè)頁面需要的數(shù)據(jù)來自兩個(gè)以上接口，而兩個(gè)接口來自不同的團(tuán)隊(duì) / 部門，比如：用戶信息來自賬號(hào)部門，而 UGC 數(shù)據(jù)來自業(yè)務(wù)部門
2. 某個(gè)頁面存在接口依賴，需要先調(diào)用接口 A，然后根據(jù)接口 A 數(shù)據(jù)調(diào)取接口 B，比如：個(gè)性化推薦，往往需要根據(jù)某些維度請(qǐng)求推薦系統(tǒng)拿到推薦數(shù)據(jù)的 ID，至于內(nèi)容，需要拿 ID 根據(jù)頁面需要去獲取具體元數(shù)據(jù)

上面兩種情況，站在后臺(tái)開發(fā)的角度來看，我們業(yè)務(wù)模塊要分開要獨(dú)立，而站在前端的角度來看，這些數(shù)據(jù)都是一個(gè)頁面需要的，前端希望是一個(gè)接口給我返回。這是一個(gè)開始。。

當(dāng)然后臺(tái)開發(fā)，比如 PHP 也有并發(fā)請(qǐng)求的解決方案，好(上)心的后臺(tái)工程師，會(huì)幫助在后臺(tái)統(tǒng)一合并請(qǐng)求處理成一份數(shù)據(jù)或者接口，然后扔給頁面使用。比如在實(shí)際開發(fā)中，我們的前端會(huì)寫(并且維護(hù))一個(gè) Template.class.php(我敢說我們 80% 的后臺(tái)工程師都沒看過這個(gè)代碼。。)，在 View 層使用，然后在 Action 當(dāng)中將數(shù)據(jù)傳給 View 層做渲染，下面的代碼：

 
 
 
 
  
  
  
  
$this->render('xxx/xx.tpl', $tplData); 
 
 
 

這樣增加的溝通成本，降低了開發(fā)效率。為了一個(gè)頁面，需要前端根據(jù)頁面想要的數(shù)據(jù)，和后臺(tái)溝通頁面的數(shù)據(jù)格式，然后后臺(tái)工程師找他們后面的 API 模塊要數(shù)據(jù)、處理數(shù)據(jù)。這個(gè)過程中會(huì)有一些「灰色地帶」，不好明確誰做更合適，完全靠自覺。

往往開發(fā)的時(shí)候會(huì)想各種方法來解耦，比如：引入后臺(tái)模板(smarty 之類)，然后約定數(shù)據(jù)格式，前端根據(jù)數(shù)據(jù)格式來寫 Mock 接口，寫后臺(tái)模板的前端就叫「大前端」;再 Low 一點(diǎn)的團(tuán)隊(duì)，會(huì)采取前端做好頁面扔給后臺(tái)工程師「套頁面」，比如：PHP 代碼寫 HTML，各種 ，代碼很不友好，后臺(tái)工程師幸福感也急劇下降。

還有一種做法是，干脆后臺(tái)淪為「代理服務(wù)器」，收到請(qǐng)求我轉(zhuǎn)給后面的 API，拿到數(shù)據(jù)我返回給前端頁面，做成可以「跨域」的接口，所以就成了好多 webapp。

另外，站在后臺(tái)工程師的個(gè)人發(fā)展來看，可能他們覺得：這些「包接口」的重復(fù)性工作，跟自己的晉升和技術(shù)發(fā)展又有毛線關(guān)系呢?

說道這里，肯定有人心里在嘀咕：這是你們大公司才有的問題，我們小公司不會(huì)有這樣的問題!那我下面再從技術(shù)方面來說。

從技術(shù)方面說起

從性能優(yōu)化、工程化、解決方案這三個(gè)開發(fā)中最最常見的方面來說明為什么前端的事情前端做更合適。

性能優(yōu)化

前端頁面是重要的載體，出現(xiàn)問題或者頁面體驗(yàn)不好會(huì)對(duì)用戶造成直接的傷害(我們都是背鍋俠)。頁面性能這些問題顯然是前端的頭等大事，但是這些事情跟后臺(tái)工程師關(guān)系多大呢?當(dāng)你發(fā)現(xiàn)該優(yōu)化的項(xiàng)目都優(yōu)化完了，剩下的優(yōu)化項(xiàng)目就需要跟后臺(tái)工程師一起優(yōu)化了，而這時(shí)候再去 push 后臺(tái)工程師一起參與前端優(yōu)化項(xiàng)目。

工程化方案

除了前端頁面的性能優(yōu)化這種項(xiàng)目，還會(huì)有一些工程化的工作，幫助提高前端的開發(fā)效率和體驗(yàn)，但實(shí)際上只有前端是搞不定的，比如：

1. 根據(jù)打包工具做的 resourcemap，實(shí)現(xiàn)頁面靜態(tài)資源的 CDN 地址合并(combo)輸出和分開輸出(調(diào)試階段)
2. 擴(kuò)展 Smarty 語法，實(shí)現(xiàn)模板組件化
3. 模擬后臺(tái)數(shù)據(jù)接口，輸出假數(shù)據(jù)渲染的頁面

這些工程化的工作本身前端自己理解的很清楚，但是后臺(tái)工程師會(huì)有多少了解呢?怎么不可能讓對(duì)前端不了解的后臺(tái)工程師參與進(jìn)來呢?解釋要做什么就花費(fèi)不少時(shí)間。

解決方案

再說解決方案，簡單點(diǎn)如果我們要實(shí)現(xiàn)頁面 chunked 輸出，將動(dòng)態(tài)和靜態(tài)數(shù)據(jù)分開，不依賴接口數(shù)據(jù)的數(shù)據(jù)首先展現(xiàn)(比如首屏的 Nav)，那么也要依賴后臺(tái)工程師的代碼。再大一點(diǎn)，我們上個(gè)類似 Bigpipe 的方案，那么對(duì)后臺(tái)的依賴和改造更大。

技術(shù)這些問題怎么辦?

上面的這些訴求，有兩種方案：前端自己擼袖子來搞，他們或者是直接寫類似 PHP 來實(shí)現(xiàn)，或者是寫不倫不類的 Smarty 擴(kuò)展代碼;再者就是可以出一個(gè)「技術(shù)產(chǎn)品經(jīng)理」，專門立項(xiàng)來搞這些項(xiàng)目，由「技術(shù)產(chǎn)品經(jīng)理」來協(xié)調(diào)兩邊需求，避免「雞同鴨講」。可是業(yè)務(wù)部門項(xiàng)目壓力是非常大的，很少有這樣的項(xiàng)目，而專門做技術(shù)的團(tuán)隊(duì)呢，又很難深入業(yè)務(wù)，往往高高在上，搞出來的東西要么不合實(shí)際、要么太高新尖端，導(dǎo)致水土不服，強(qiáng)推起來，業(yè)務(wù)團(tuán)隊(duì)哀聲哉道。我也說過：脫離業(yè)務(wù)的架構(gòu)都是耍流氓。。

為什么用 Node

根據(jù)上面說的，大概得出使用 Node 有下面的好處：

1. 天然的事件驅(qū)動(dòng)可以用于處理并發(fā)
2. 降低前后端協(xié)作成本，提高開發(fā)效率
3. 職責(zé)分明，前端的問題前端 er 自己負(fù)責(zé)，自己解決
4. 前后端同構(gòu)，前端解決方案同步到 Server-side
5. 有利于前后端同學(xué)的個(gè)人發(fā)展

什么業(yè)務(wù)場景使用 Node

同時(shí)，大概得出什么樣子的業(yè)務(wù)場景使用 Node：

1. 頁面需求大，從樣式到性能都一直迭代
2. 后端接口豐富，頁面數(shù)據(jù)資源方多
3. 純渲染，對(duì)安全性要求不高，無計(jì)算能力
4. 最后，最重要的是團(tuán)隊(duì)的能力(我還說過：脫離團(tuán)隊(duì)的架構(gòu)都是耍流氓。。)

對(duì) Node 的質(zhì)疑

當(dāng)談到「我們要用 Node」，往往會(huì)遭到如下具體的質(zhì)疑(注意是具體，不是純懟)：

1. 穩(wěn)定性：主要是單線程異常處理
2. 異步回調(diào)導(dǎo)致程序復(fù)雜度提高，不利于調(diào)試
3. 和后臺(tái)接口的對(duì)接能力
4. 工作流程：代碼部署、上線
5. 運(yùn)維支持：接入、容量管理、日志、監(jiān)控等
6. Node 版本升級(jí)太快了，NPM 包靠譜嗎?

先說這些前面三個(gè)問題：?

1. 穩(wěn)定性：選擇的 Node 框架對(duì)異常處理要友好，進(jìn)程守候有 forever/pm2 這些包可以幫我們，目前已經(jīng)成熟，而且 Node 也越來越完善和穩(wěn)定
2. 調(diào)試：現(xiàn)在用前端流程的 IDE 很容易調(diào)試
3. 后臺(tái)接口通信協(xié)議如果過于復(fù)雜，可以通過 C 的 Node 模塊來解決，PHP 不也是嗎?

后面兩個(gè)問題主要是跟公司運(yùn)維能力有關(guān)系：

1. 工作流程：目前百度內(nèi)部的工作流程做的很好，從代碼提交到打包編譯和上線都是一整套解決方案，而每個(gè)環(huán)節(jié)之間只需要按照約定進(jìn)行輸入輸出即可
2. 運(yùn)維：百度內(nèi)部的 ORP 是很好的 PaaS 解決方案，提供了虛擬化的實(shí)例，Node 代碼部署在實(shí)例上，通過統(tǒng)一的 nginx 反向代理分發(fā)給不同端口號(hào)的實(shí)例處理，支持資源彈性調(diào)度，日志只需要按照約定放在某個(gè)文件夾，可以配置采集任務(wù)，進(jìn)行采集和監(jiān)控

所以我們廠子內(nèi)部已經(jīng)為 Node 大規(guī)模使用在流程和運(yùn)維方面已經(jīng)做好了準(zhǔn)備。

最后說下 Node 生態(tài)問題，Node 版本的確升級(jí)很快，但是只關(guān)注 LTS 版本，等發(fā)版一段時(shí)間之后跟進(jìn)更新即可，目前百度內(nèi)部的 Node Runtime 是 6.10 版本，聽說很快就要生 7.0 了。對(duì)于框架和業(yè)務(wù)代碼用到的 NPM 包，完全可以做版本指定，也可以做自動(dòng)測試，跑過了 case 則提交進(jìn) master，隨著下個(gè)版本回歸上線。

前端寫后臺(tái)代碼會(huì)有什么問題?

不管怎樣，我們用 Node 已經(jīng)變得順理成章，但是我們也要知道自己的不足，拓寬自己的視野。

首先是后臺(tái)思想，在前端開發(fā)中，我們的代碼是跑在每個(gè)用戶自己的瀏覽器里面，代碼之間是隔離的，所以不管你代碼寫的好壞，只要是說的過去，就不會(huì)有大的問題，比如：偶爾內(nèi)存泄漏一下，似乎也影響不大。但是 server 的代碼是長久執(zhí)行下去的，不是用戶走了就釋放的，所以一個(gè)小的內(nèi)存泄漏，長時(shí)間下去也會(huì)引起大的問題。再比如：瀏覽器的 JS 你可以偶爾使用個(gè)全局變量(少寫個(gè) var)，但是如果在 Node 的代碼，將用戶相關(guān)的個(gè)性數(shù)據(jù)放在 global，那么當(dāng)下個(gè)請(qǐng)求過來，而代碼還沒有處理完當(dāng)前請(qǐng)求，會(huì)導(dǎo)致自己用的數(shù)據(jù)不是當(dāng)前用戶的，碰到這種問題，只能把個(gè)性化的數(shù)據(jù)一層層的傳下去。還有缺乏優(yōu)化意識(shí)或者過度優(yōu)化，該用緩存的時(shí)候不用，不該用的時(shí)候亂用。

再舉個(gè) case，看下面的代碼：

 
 
 
 
  
  
  
  
module.exports = function (ip) { 
  
  
  
  
 var ipfinder = require('ipfinder'); 
  
  
  
  
 ipfinder.loadData('ip.data'); 
  
  
  
  
 return ipfinder.findSync(ip); 
  
  
  
  
} 
 
 
 

這個(gè)是數(shù)據(jù)實(shí)時(shí)分析項(xiàng)目的一段類似的代碼，ipfinder 是我寫的一個(gè) IP 查找?guī)欤?ipfinder.loadData('ip.data’);會(huì)引入一個(gè)二進(jìn)制的 ip 數(shù)據(jù)庫，這個(gè)比較消耗資源，寫在 module.exports是沒有必要的，每次執(zhí)行 module 都加載一遍，很費(fèi)資源，拿到 module.exports之外，程序的 CPU 從 99% 降到了 5%....

第二個(gè)是安全意識(shí)，之前在「Vue 項(xiàng)目重構(gòu)」中提到 proxy.js的代碼弊端，就是缺乏安全意識(shí)導(dǎo)致的。前端寫后臺(tái)程序，因?yàn)槿狈Π踩庾R(shí)，往往在接口設(shè)計(jì)、頁面片段拼接等方面犯錯(cuò)誤，比如：接口設(shè)計(jì)的過于簡單，缺乏校驗(yàn)，容易導(dǎo)致 CSRF 攻擊，如果有數(shù)據(jù)庫操作，手動(dòng)拼接 SQL 語句容易導(dǎo)致 SQL 注入。

最后是運(yùn)維知識(shí)，前端工程師寫 Node 服務(wù)，就不在簡單的對(duì)瀏覽器負(fù)責(zé)，而還應(yīng)該對(duì)服務(wù)器負(fù)責(zé)，服務(wù)器的穩(wěn)定性、各種監(jiān)控指標(biāo)都應(yīng)該有所了解，對(duì)于機(jī)房配置、資源調(diào)配、運(yùn)維架構(gòu)、服務(wù)架構(gòu)都應(yīng)該了熟于心，避免出現(xiàn)線上事故了自己還不知道從哪里排查的窘態(tài)。

當(dāng)然你可能會(huì)說，剛剛開始接觸是可以允許犯錯(cuò)的，但是要知道：技術(shù)的調(diào)整是不應(yīng)該損害產(chǎn)品服務(wù)的。以上三點(diǎn)內(nèi)容需要?jiǎng)倓傓D(zhuǎn) Node 開發(fā)的前端工程師注意加強(qiáng)學(xué)習(xí)，能力越大責(zé)任越大!開始時(shí)候可能會(huì)犯錯(cuò)和抓瞎，該請(qǐng)教就請(qǐng)教，時(shí)間長了能夠點(diǎn)亮新的技能點(diǎn)~

【本文為專欄作者“三水清”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)通過微信公眾號(hào)聯(lián)系作者獲取授權(quán)】

戳這里，看該作者更多好文

網(wǎng)頁標(biāo)題：為什么我們的業(yè)務(wù)適合用 Node？
轉(zhuǎn)載來源：http://uogjgqi.cn/article/djeecjo.html