建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
這些日子一直在做 Node 方面的嘗試，或多或少會(huì)收到周?chē)漠悩拥哪抗馍踔帘澈蟮馁|(zhì)疑，于是促使我好好思考為什么我在做 Node。網(wǎng)上搜下「為什么要用 Node」，找到的文章多數(shù)是介紹 Node 多么多么牛逼，無(wú)非是從 Node 本身特性來(lái)說(shuō)，比如：并發(fā)、事件驅(qū)動(dòng)、非阻塞 I/O、單線(xiàn)程、流、社區(qū)生態(tài)…… 諸如此類(lèi)，很少談業(yè)務(wù)場(chǎng)景。
成都創(chuàng)新互聯(lián)服務(wù)項(xiàng)目包括鄱陽(yáng)網(wǎng)站建設(shè)、鄱陽(yáng)網(wǎng)站制作、鄱陽(yáng)網(wǎng)頁(yè)制作以及鄱陽(yáng)網(wǎng)絡(luò)營(yíng)銷(xiāo)策劃等。多年來(lái)，我們專(zhuān)注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，鄱陽(yáng)網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶(hù)以成都為中心已經(jīng)輻射到鄱陽(yáng)省份的部分城市，未來(lái)相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶(hù)的支持與信任！
我是「實(shí)用主義」者，說(shuō)過(guò)：脫離業(yè)務(wù)場(chǎng)景談架構(gòu)都是耍流氓。因?yàn)閭€(gè)人是從一線(xiàn)業(yè)務(wù)做起的，經(jīng)過(guò)幾年對(duì)業(yè)務(wù)的思考，我覺(jué)得可以從業(yè)務(wù)場(chǎng)景來(lái)說(shuō)說(shuō)為什么我們的業(yè)務(wù)更適合用 Node。
從業(yè)務(wù)場(chǎng)景說(shuō)起
現(xiàn)在我們的業(yè)務(wù)模塊化越來(lái)越普遍，很少有業(yè)務(wù)比較純粹只有鏈接一個(gè)數(shù)據(jù)庫(kù)就可以搞定，往往前臺(tái)業(yè)務(wù)后面會(huì)有 N 多的 API 服務(wù)做支撐。比如：下面兩種情況在我們實(shí)際開(kāi)發(fā)中經(jīng)常遇見(jiàn)：
- 某個(gè)頁(yè)面需要的數(shù)據(jù)來(lái)自?xún)蓚€(gè)以上接口，而兩個(gè)接口來(lái)自不同的團(tuán)隊(duì) / 部門(mén)，比如：用戶(hù)信息來(lái)自賬號(hào)部門(mén)，而 UGC 數(shù)據(jù)來(lái)自業(yè)務(wù)部門(mén)
- 某個(gè)頁(yè)面存在接口依賴(lài)，需要先調(diào)用接口 A，然后根據(jù)接口 A 數(shù)據(jù)調(diào)取接口 B，比如：個(gè)性化推薦，往往需要根據(jù)某些維度請(qǐng)求推薦系統(tǒng)拿到推薦數(shù)據(jù)的 ID，至于內(nèi)容，需要拿 ID 根據(jù)頁(yè)面需要去獲取具體元數(shù)據(jù)
上面兩種情況，站在后臺(tái)開(kāi)發(fā)的角度來(lái)看，我們業(yè)務(wù)模塊要分開(kāi)要獨(dú)立，而站在前端的角度來(lái)看，這些數(shù)據(jù)都是一個(gè)頁(yè)面需要的，前端希望是一個(gè)接口給我返回。這是一個(gè)開(kāi)始。。
當(dāng)然后臺(tái)開(kāi)發(fā)，比如 PHP 也有并發(fā)請(qǐng)求的解決方案，好(上)心的后臺(tái)工程師，會(huì)幫助在后臺(tái)統(tǒng)一合并請(qǐng)求處理成一份數(shù)據(jù)或者接口，然后扔給頁(yè)面使用。比如在實(shí)際開(kāi)發(fā)中，我們的前端會(huì)寫(xiě)(并且維護(hù))一個(gè) Template.class.php(我敢說(shuō)我們 80% 的后臺(tái)工程師都沒(méi)看過(guò)這個(gè)代碼。。)，在 View 層使用，然后在 Action 當(dāng)中將數(shù)據(jù)傳給 View 層做渲染，下面的代碼：
- $this->render('xxx/xx.tpl', $tplData);
這樣增加的溝通成本，降低了開(kāi)發(fā)效率。為了一個(gè)頁(yè)面，需要前端根據(jù)頁(yè)面想要的數(shù)據(jù)，和后臺(tái)溝通頁(yè)面的數(shù)據(jù)格式，然后后臺(tái)工程師找他們后面的 API 模塊要數(shù)據(jù)、處理數(shù)據(jù)。這個(gè)過(guò)程中會(huì)有一些「灰色地帶」，不好明確誰(shuí)做更合適，完全靠自覺(jué)。
往往開(kāi)發(fā)的時(shí)候會(huì)想各種方法來(lái)解耦，比如：引入后臺(tái)模板(smarty 之類(lèi))，然后約定數(shù)據(jù)格式，前端根據(jù)數(shù)據(jù)格式來(lái)寫(xiě) Mock 接口，寫(xiě)后臺(tái)模板的前端就叫「大前端」;再 Low 一點(diǎn)的團(tuán)隊(duì)，會(huì)采取前端做好頁(yè)面扔給后臺(tái)工程師「套頁(yè)面」，比如：PHP 代碼寫(xiě) HTML，各種 ，代碼很不友好，后臺(tái)工程師幸福感也急劇下降。
還有一種做法是，干脆后臺(tái)淪為「代理服務(wù)器」，收到請(qǐng)求我轉(zhuǎn)給后面的 API，拿到數(shù)據(jù)我返回給前端頁(yè)面，做成可以「跨域」的接口，所以就成了好多 webapp。
另外，站在后臺(tái)工程師的個(gè)人發(fā)展來(lái)看，可能他們覺(jué)得：這些「包接口」的重復(fù)性工作，跟自己的晉升和技術(shù)發(fā)展又有毛線(xiàn)關(guān)系呢?
說(shuō)道這里，肯定有人心里在嘀咕：這是你們大公司才有的問(wèn)題，我們小公司不會(huì)有這樣的問(wèn)題!那我下面再?gòu)募夹g(shù)方面來(lái)說(shuō)。
從技術(shù)方面說(shuō)起
從性能優(yōu)化、工程化、解決方案這三個(gè)開(kāi)發(fā)中最最常見(jiàn)的方面來(lái)說(shuō)明為什么前端的事情前端做更合適。
性能優(yōu)化
前端頁(yè)面是重要的載體，出現(xiàn)問(wèn)題或者頁(yè)面體驗(yàn)不好會(huì)對(duì)用戶(hù)造成直接的傷害(我們都是背鍋俠)。頁(yè)面性能這些問(wèn)題顯然是前端的頭等大事，但是這些事情跟后臺(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è)面的性能優(yōu)化這種項(xiàng)目，還會(huì)有一些工程化的工作，幫助提高前端的開(kāi)發(fā)效率和體驗(yàn)，但實(shí)際上只有前端是搞不定的，比如：
- 根據(jù)打包工具做的 resourcemap，實(shí)現(xiàn)頁(yè)面靜態(tài)資源的 CDN 地址合并(combo)輸出和分開(kāi)輸出(調(diào)試階段)
- 擴(kuò)展 Smarty 語(yǔ)法，實(shí)現(xiàn)模板組件化
- 模擬后臺(tái)數(shù)據(jù)接口，輸出假數(shù)據(jù)渲染的頁(yè)面
這些工程化的工作本身前端自己理解的很清楚，但是后臺(tái)工程師會(huì)有多少了解呢?怎么不可能讓對(duì)前端不了解的后臺(tái)工程師參與進(jìn)來(lái)呢?解釋要做什么就花費(fèi)不少時(shí)間。
解決方案
再說(shuō)解決方案，簡(jiǎn)單點(diǎn)如果我們要實(shí)現(xiàn)頁(yè)面 chunked 輸出，將動(dòng)態(tài)和靜態(tài)數(shù)據(jù)分開(kāi)，不依賴(lài)接口數(shù)據(jù)的數(shù)據(jù)首先展現(xiàn)(比如首屏的 Nav)，那么也要依賴(lài)后臺(tái)工程師的代碼。再大一點(diǎn)，我們上個(gè)類(lèi)似 Bigpipe 的方案，那么對(duì)后臺(tái)的依賴(lài)和改造更大。
技術(shù)這些問(wèn)題怎么辦?
上面的這些訴求，有兩種方案：前端自己擼袖子來(lái)搞，他們或者是直接寫(xiě)類(lèi)似 PHP 來(lái)實(shí)現(xiàn)，或者是寫(xiě)不倫不類(lèi)的 Smarty 擴(kuò)展代碼;再者就是可以出一個(gè)「技術(shù)產(chǎn)品經(jīng)理」，專(zhuān)門(mén)立項(xiàng)來(lái)搞這些項(xiàng)目，由「技術(shù)產(chǎn)品經(jīng)理」來(lái)協(xié)調(diào)兩邊需求，避免「雞同鴨講」。可是業(yè)務(wù)部門(mén)項(xiàng)目壓力是非常大的，很少有這樣的項(xiàng)目，而專(zhuān)門(mén)做技術(shù)的團(tuán)隊(duì)呢，又很難深入業(yè)務(wù)，往往高高在上，搞出來(lái)的東西要么不合實(shí)際、要么太高新尖端，導(dǎo)致水土不服，強(qiáng)推起來(lái)，業(yè)務(wù)團(tuán)隊(duì)哀聲哉道。我也說(shuō)過(guò)：脫離業(yè)務(wù)的架構(gòu)都是耍流氓。。
為什么用 Node
根據(jù)上面說(shuō)的，大概得出使用 Node 有下面的好處：
- 天然的事件驅(qū)動(dòng)可以用于處理并發(fā)
- 降低前后端協(xié)作成本，提高開(kāi)發(fā)效率
- 職責(zé)分明，前端的問(wèn)題前端 er 自己負(fù)責(zé)，自己解決
- 前后端同構(gòu)，前端解決方案同步到 Server-side
- 有利于前后端同學(xué)的個(gè)人發(fā)展
什么業(yè)務(wù)場(chǎng)景使用 Node
同時(shí)，大概得出什么樣子的業(yè)務(wù)場(chǎng)景使用 Node：
- 頁(yè)面需求大，從樣式到性能都一直迭代
- 后端接口豐富，頁(yè)面數(shù)據(jù)資源方多
- 純渲染，對(duì)安全性要求不高，無(wú)計(jì)算能力
- 最后，最重要的是團(tuán)隊(duì)的能力(我還說(shuō)過(guò)：脫離團(tuán)隊(duì)的架構(gòu)都是耍流氓。。)
對(duì) Node 的質(zhì)疑
當(dāng)談到「我們要用 Node」，往往會(huì)遭到如下具體的質(zhì)疑(注意是具體，不是純懟)：
- 穩(wěn)定性：主要是單線(xiàn)程異常處理
- 異步回調(diào)導(dǎo)致程序復(fù)雜度提高，不利于調(diào)試
- 和后臺(tái)接口的對(duì)接能力
- 工作流程：代碼部署、上線(xiàn)
- 運(yùn)維支持：接入、容量管理、日志、監(jiān)控等
- Node 版本升級(jí)太快了，NPM 包靠譜嗎?
先說(shuō)這些前面三個(gè)問(wèn)題：?
- 穩(wěn)定性：選擇的 Node 框架對(duì)異常處理要友好，進(jìn)程守候有 forever/pm2 這些包可以幫我們，目前已經(jīng)成熟，而且 Node 也越來(lái)越完善和穩(wěn)定
- 調(diào)試：現(xiàn)在用前端流程的 IDE 很容易調(diào)試
- 后臺(tái)接口通信協(xié)議如果過(guò)于復(fù)雜，可以通過(guò) C 的 Node 模塊來(lái)解決，PHP 不也是嗎?
后面兩個(gè)問(wèn)題主要是跟公司運(yùn)維能力有關(guān)系：
- 工作流程：目前百度內(nèi)部的工作流程做的很好，從代碼提交到打包編譯和上線(xiàn)都是一整套解決方案，而每個(gè)環(huán)節(jié)之間只需要按照約定進(jìn)行輸入輸出即可
- 運(yùn)維：百度內(nèi)部的 ORP 是很好的 PaaS 解決方案，提供了虛擬化的實(shí)例，Node 代碼部署在實(shí)例上，通過(guò)統(tǒng)一的 nginx 反向代理分發(fā)給不同端口號(hào)的實(shí)例處理，支持資源彈性調(diào)度，日志只需要按照約定放在某個(gè)文件夾，可以配置采集任務(wù)，進(jìn)行采集和監(jiān)控
所以我們廠(chǎng)子內(nèi)部已經(jīng)為 Node 大規(guī)模使用在流程和運(yùn)維方面已經(jīng)做好了準(zhǔn)備。
最后說(shuō)下 Node 生態(tài)問(wèn)題，Node 版本的確升級(jí)很快，但是只關(guān)注 LTS 版本，等發(fā)版一段時(shí)間之后跟進(jìn)更新即可，目前百度內(nèi)部的 Node Runtime 是 6.10 版本，聽(tīng)說(shuō)很快就要生 7.0 了。對(duì)于框架和業(yè)務(wù)代碼用到的 NPM 包，完全可以做版本指定，也可以做自動(dòng)測(cè)試，跑過(guò)了 case 則提交進(jìn) master，隨著下個(gè)版本回歸上線(xiàn)。
前端寫(xiě)后臺(tái)代碼會(huì)有什么問(wèn)題?
不管怎樣，我們用 Node 已經(jīng)變得順理成章，但是我們也要知道自己的不足，拓寬自己的視野。
首先是后臺(tái)思想，在前端開(kāi)發(fā)中，我們的代碼是跑在每個(gè)用戶(hù)自己的瀏覽器里面，代碼之間是隔離的，所以不管你代碼寫(xiě)的好壞，只要是說(shuō)的過(guò)去，就不會(huì)有大的問(wèn)題，比如：偶爾內(nèi)存泄漏一下，似乎也影響不大。但是 server 的代碼是長(zhǎng)久執(zhí)行下去的，不是用戶(hù)走了就釋放的，所以一個(gè)小的內(nèi)存泄漏，長(zhǎng)時(shí)間下去也會(huì)引起大的問(wèn)題。再比如：瀏覽器的 JS 你可以偶爾使用個(gè)全局變量(少寫(xiě)個(gè) var)，但是如果在 Node 的代碼，將用戶(hù)相關(guān)的個(gè)性數(shù)據(jù)放在 global，那么當(dāng)下個(gè)請(qǐng)求過(guò)來(lái)，而代碼還沒(méi)有處理完當(dāng)前請(qǐng)求，會(huì)導(dǎo)致自己用的數(shù)據(jù)不是當(dāng)前用戶(hù)的，碰到這種問(wèn)題，只能把個(gè)性化的數(shù)據(jù)一層層的傳下去。還有缺乏優(yōu)化意識(shí)或者過(guò)度優(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)目的一段類(lèi)似的代碼，ipfinder 是我寫(xiě)的一個(gè) IP 查找?guī)欤?ipfinder.loadData('ip.data’);會(huì)引入一個(gè)二進(jìn)制的 ip 數(shù)據(jù)庫(kù)，這個(gè)比較消耗資源，寫(xiě)在 module.exports是沒(méi)有必要的，每次執(zhí)行 module 都加載一遍，很費(fèi)資源，拿到 module.exports之外，程序的 CPU 從 99% 降到了 5%....
第二個(gè)是安全意識(shí)，之前在「Vue 項(xiàng)目重構(gòu)」中提到 proxy.js的代碼弊端，就是缺乏安全意識(shí)導(dǎo)致的。前端寫(xiě)后臺(tái)程序，因?yàn)槿狈Π踩庾R(shí)，往往在接口設(shè)計(jì)、頁(yè)面片段拼接等方面犯錯(cuò)誤，比如：接口設(shè)計(jì)的過(guò)于簡(jiǎn)單，缺乏校驗(yàn)，容易導(dǎo)致 CSRF 攻擊，如果有數(shù)據(jù)庫(kù)操作，手動(dòng)拼接 SQL 語(yǔ)句容易導(dǎo)致 SQL 注入。
最后是運(yùn)維知識(shí)，前端工程師寫(xiě) Node 服務(wù)，就不在簡(jiǎn)單的對(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)線(xiàn)上事故了自己還不知道從哪里排查的窘態(tài)。
當(dāng)然你可能會(huì)說(shuō)，剛剛開(kāi)始接觸是可以允許犯錯(cuò)的，但是要知道：技術(shù)的調(diào)整是不應(yīng)該損害產(chǎn)品服務(wù)的。以上三點(diǎn)內(nèi)容需要?jiǎng)倓傓D(zhuǎn) Node 開(kāi)發(fā)的前端工程師注意加強(qiáng)學(xué)習(xí)，能力越大責(zé)任越大!開(kāi)始時(shí)候可能會(huì)犯錯(cuò)和抓瞎，該請(qǐng)教就請(qǐng)教，時(shí)間長(zhǎng)了能夠點(diǎn)亮新的技能點(diǎn)~
【本文為專(zhuān)欄作者“三水清”的原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)通過(guò)微信公眾號(hào)聯(lián)系作者獲取授權(quán)】
戳這里，看該作者更多好文
網(wǎng)頁(yè)標(biāo)題：為什么我們的業(yè)務(wù)適合用 Node？
當(dāng)前網(wǎng)址：http://m.5511xx.com/article/djeecjo.html
