實例分析關于美團Node的全棧開發(fā)實踐

　前后端分離的背景
　　“前后端分離”顯然已不是什么新鮮的話題，Zakas在2013年10月份就曾發(fā)表過一篇博客《Node.js and the new web front-end》討論Node背景下新時代的前端。毫無疑問，Node的出現(xiàn)給Java語言帶來了新的生機，也使得前端開發(fā)者有了更多的可能性。
　　前后端分離表面上看似乎是一場“圈地運動”，但實質上前后端分離是為了解決以往開發(fā)模式的一些詬病和痛點，同時也是迎合大的行業(yè)趨勢的明智之舉。我所在的美團酒店事業(yè)部去年7月份成立，新的業(yè)務、新的開發(fā)團隊，這一切使得我們的前后端分離推進的很徹底。截至目前，前端承載的所有業(yè)務和線上服務都是基于Node，生產(chǎn)環(huán)境已經(jīng)有近60臺服務器。如此帶來的全新前后端協(xié)作方式能夠讓專業(yè)的人做專業(yè)的事，無論前端后端都能較之前更專注在自己擅長的方面。
　　開發(fā)模式、技術棧
　　
　　傳統(tǒng)的開發(fā)模式只需要專注在多終端的呈現(xiàn)上（瀏覽器、WebView）。而現(xiàn)在，瀏覽器只是前端的其中一環(huán)，延伸出來的還有Node端的架構、服務的運維能力等。上圖是我們目前的服務架構：Nginx位于Node服務之前，用做負載均衡、服務調度、Gzip壓縮等。之后便是Node服務，我們通過PM2.5進行Node服務的Cluster部署和負載均衡（充分利用多核優(yōu)勢），同時作為輕量的中間層，負責路由、Controllers、Views、以及視圖的渲染，數(shù)據(jù)的獲取通過RESTful的API接口使用JSON格式交互。而后端則只需要負責業(yè)務邏輯、數(shù)據(jù)存儲、Models，并為前端提供JSON數(shù)據(jù)即可。
　　這樣改變之后，Node端可以進行首屏渲染等頁面加載方面的優(yōu)化，頁面渲染出來之后后續(xù)的交互、渲染都交由瀏覽器端的Java代碼來完成，Node端的模板和瀏覽器端的模板大部分情況下都是相同的，所以我們需要考慮模板重用的問題。我們用Juicer替換了Express框架默認的模板引擎，Juicer是一個高效、輕量的前端 （Java） 模板引擎，效率和易用是它追求的目標。除此之外，它還可以運行在 Node.js 環(huán)境中。通過Juicer，可以解決Node端和瀏覽器端的模板、Helper復用問題。而且基于前后端分離的工程架構下，前端的代碼倉庫和后端隔離，前端獨立負責前端靜態(tài)資源文件、模板文件、Controller的維護和發(fā)布。
　　按照這樣重新定義前后端分工之后，前端可以做的事情較以往更多了，比如微信SDK的接入，因為微信JS SDK的使用需要在服務端進行簽名，所以現(xiàn)在我們不需要后端介入，前端完全可以獨立完成微信SDK的接入。此外像我們內部和商家端SSO登錄邏輯的接入都完全由前端獨立完成。
　　技術選型的思考
　　對于前端的技術選型，我們始終保持理性、擁抱的態(tài)度。我們不會為了盲目求新而引入新的技術，技術選型是針對我們目前大團隊的場景，為了解決以往協(xié)作過程中發(fā)現(xiàn)的一些痛點和不足。比如引入Node是為了改進前后端的工作流和效率，提升前后端的開發(fā)體驗。再比如目前我們項目中采用的Angular、React也是針對特定的業(yè)務場景，為了提升開發(fā)效率、增強代碼的可維護性。在我們的業(yè)務應用中，面向商家、后臺的一些增刪改查系統(tǒng)，Angular能夠顯著的提升開發(fā)效率，而React我們目前只是在面向用戶的PC端項目中在做一些嘗試和實踐。
　　帶來的挑戰(zhàn)
　　這樣的分工和架構模式在給前端帶來更多可能性、更多便利的同時，也帶來了不小的挑戰(zhàn)，相比傳統(tǒng)的前端角色而言，我們需要更多的關注線上服務的狀態(tài)，進程內存占用、CPU占用的詳細狀況，以及線上異常的監(jiān)控等。在我們擁抱Node的同時，對前端的能力要求是更上一階的。一段看起來正常的JS代碼，在瀏覽器端和在Node端兩種不同的運行環(huán)境下，就可能會暴露出一些以往關注不到的問題，比如內存泄露：一個閉包或者一個用于緩存數(shù)據(jù)的對象，跟瀏覽器不同，Node對內存泄露十分敏感，因為線上應用有成千上萬甚至百萬計的流量，所以哪怕是一個字節(jié)的內存泄露也會造成內存堆積，從而導致垃圾回收過程耗時增加，應用響應緩慢，知道進程內存溢出，應用重啟或崩潰。
　　內存泄露問題的定位
　　以下是我們在生產(chǎn)環(huán)境遭遇的一個案例：最近發(fā)現(xiàn)線上服務的內存占用在服務重啟后會呈線性的增長，進程啟動18小時后，內存就已經(jīng)占用接近1.6G左右，之后不久便會超過V8的內存限制導致服務重啟。從圖中可以看出，在修復之前內存使用情況一直在隨時間進行周期性的波動，波動的原因就是線上Node進程不斷的重啟導致的。
　　
　　眾所周知，在V8的垃圾回收機制下，一般的代碼很少出現(xiàn)內存泄露的情況，但是一旦出現(xiàn)內存泄露往往較難排查。但造成內存泄露的本質原因只有一個，就是應當回收的對象沒有正常被回收，變成了老生代中的常駐對象。好在借助一些常見的排查工具可以幫助我們定位內存泄露的具體原因：
　　v8-profiler
　　node-heapdump
　　node-mtrace
　　dtrace
　　node-memwatch
　　這里我們使用node-heapdump來在模擬訪問的條件下生成堆內存的snapshot，并通過Chrome的開發(fā)者調試工具對生成的snapshot文件進行分析。通過對比服務剛啟動時以及使用AB模擬并發(fā)訪問一段時間后的heapdump信息可以比較容易的定位到內存泄露的問題點：是因為Juicer默認開啟了cache，會默認對編譯后的模板進行緩存，因此隨著訪問的增長和并發(fā)請求，cache對象會持續(xù)增長且不被回收，于是關閉cache并重新部署上線后線上恢復正常。
　　由于在瀏覽器的場景中運行時間短，且運行在用戶的機器上，即便內存使用過多或者內存泄露，也只會影響到用戶的終端。而且運行時間短，隨著進程的退出，內存也會隨之釋放，幾乎沒有太多內存管理的必要。但在Node端同樣的代碼就可能會暴露出問題。
　　線上服務的運維和監(jiān)控
　　前后端分離除了意味著代碼倉庫的分離、開發(fā)協(xié)作的分離之外，還涉及到線上服務的獨立發(fā)布和單獨部署。與之俱來的當然是前端如何更好地對線上服務進行更細粒度的運維和監(jiān)控，我們的SA會更多的關注線上服務的整體指標和可用性，而前端更希望能夠細粒度的了解線上Node的進程狀態(tài)以及異常情況。
　　PM2是一款優(yōu)秀且開源的Node進程管理工具。我們在PM2的基礎上做了一些改造，同時在云端部署了數(shù)據(jù)收集、數(shù)據(jù)實時獲取的服務，從而形成了我們目前已經(jīng)應用到線上的Node部署監(jiān)控平臺PM2.5，它可以將線上Node服務進程級別的細粒度信息聚合在云端進行處理和可視化展現(xiàn)，PM2.5能夠監(jiān)控Node Server和進程的各項指標狀態(tài)，且可以配置報警并在各終端（Web、iPhone、Apple Watch）展示。