2018年去哪兒網+Node.js+實踐及性能監控方案.pdf

《2018年去哪兒網+Node.js+實踐及性能監控方案.pdf》由會員分享，可在線閱讀，更多相關《2018年去哪兒網+Node.js+實踐及性能監控方案.pdf（40頁珍藏版）》請在三個皮匠報告上搜索。

1、去哪兒網 Node.js 實踐及性能監控方案2018.06去哪兒網前后端分離方案和靜態資源離線包Node.js 和 React SSR 實踐應用和性能監控方案1.項目分離，頁面分離發布系統前端js/css后端vm2.項目分離，部分頁面分離發布系統前端js/css/vm后端3.Node.js 作為頁面渲染層靜態資源離線包方案（qp）項目中如何使用 qp 包在項目根目錄中，新建 index.yaml 配置文件唯一id針對的 iOS 和 Android 版本打包內容忽略內容使用打包平臺發布，無需人工干預用戶對離線包完全透明，且無感知。需要考慮的問題保證資源的安全性，不被中間人惡意篡改傳輸安全和存儲安

2、全，使用 RSA 加密快速回滾原來假回滾（重新發版）-真回滾下線和強制更新下線：針對當前包強制更新：將要下載的包提高更新率減少 qp 包的大小使用 HTTP2 協議使用差分包而不是全量包http:/ 2 小時內達到 90%離線包更新率效果（強制更新）普通更新通常7，8個小時后才能穩定在75%左右離線包更新率效果（普通更新）第一部分總結去哪兒網三種前后端分離方案，以及各種方案的優缺點和適用情況簡要介紹靜態資源離線包實現方式和部分細節Node.js 和 React SSR 實踐去哪兒網前后端分離方案和靜態資源離線包應用和性能監控方案為什么沒有大規模使用？一些前端開發，只關注瀏覽器端，服務器端開發關

3、注很少，或者根本就不關注;認為 Node.js 只適合開發一些工具類的功能，對于后端開發是個玩具;Node.js 的生態不如其他后端語言生態健全;涉及到后端開發的知識面比較廣，在沒有這些基礎知識或者經驗積累的基礎上，考慮問題比較片面，最終做出的系統問題比較多，容易被后端鄙視;對于 Node.js 開發后端，對項目負責人要求比較高（項目的目錄規范，開發規范，系統的安全性，穩定性，可靠性，擴展性，維護成本等）;以往前端不需要 7 x 24 保持待命狀態，但是接觸后端后，需要接收報警短信，有時出現問題還需要馬上隨時隨地解決;提高開發效率（不用 Nginx，代理工具等等）降低溝通成本（除接口格式外，不

4、需要和后端交互）前后端職責更新清晰-后端生產數據，前端消費數據可以使用 React SSR 技術-首屏渲染、SEO 等RESTful API-自身使用或對外提供，不依賴后端Node.js 能解決哪些問題和痛點？1.如何確定項目目錄劃分的規范，命名規范（view or views）2.確定規范后，如何保證大家都認可，并且嚴格遵守3.如何保證系統的安全性，穩定性，可擴展性4.守護進程程序的選擇（pm2 or supervisor）5.多環境運行規則（local/beta/prod）6.如何利用系統 cpu 多核，以及多進程之間的通信三年前所用框架的問題（基于express）重新選擇框架Or在文檔說

5、明、框架擴展、插件數量、部署流暢性以及開發體驗上，最終選擇的是 Egg.js。插件開發egg-qversionegg-qconfigegg-qwatcheregg-accesslogegg-healthcheckegg-checkurlegg-swift1.不能利用發布系統中相應的端口和目錄字段，只能在 qunar_xx 服務中寫死，不友好2.不能區分多環境策略。比如：beta 環境和 prod 環境配置規則不一樣3.啟動過程中出現錯誤，不方便定位問題，需要到機器上排查4.寫系統服務需要了解 shell 命令和系統服務格式，對于前端開發同學，成本稍高5.除了端口、項目路徑、運行環境，node.

6、js 啟動方式外，處理邏輯相似原來部署流程（service 方式）問題改進后的部署方式在項目中建立 deploy_scripts 目錄，新增 start.sh（名稱可以隨便命名）在 start.sh 中填入 Node.js 啟動邏輯，比如 node index.js(之前是 N 行，如今最多兩行)在發布系統選擇 node 發布方式，填入端口號，發布路徑，以及啟動腳本名稱（start.sh），停止腳本填入發布系統內置的 stop.sh（按照端口殺掉進程）start.sh 樣例React SSR 實踐Action 寫法reactRender 方法視圖（xx.ejs）前端（xx.js）CASE1 共

7、享代碼如何處理請求React SSR 遇到的問題 CASE2 共享代碼如何處理錯誤React SSR 遇到的問題CASE3 后端代碼獲得設備信息React SSR 遇到的問題第二部分總結簡要分析 Node.js 沒有被廣泛使用的原因Node.js 解決了哪些問題和痛點出于什么考慮選擇 Egg.js 以及開發一系列比較實用的插件Node.js 發布方式的演進，大家可以借鑒借鑒React SSR 實踐思路，以及一些比較典型的問題應用和性能監控方案去哪兒網前后端分離方案和靜態資源離線包Node.js 和 React SSR 實踐性能監控 對框架本身沒有做太多，因為 eggjs 本身已經經歷過淘寶雙十一的洗禮，相信在阿里內部對這塊已經做的不少優化，所以簡單使用的是公司級別的機器監控。0102應錯誤數、接消耗時長，接異常信息、accesslog 等應用程序級別腳本全局錯誤、靜態資源件加載錯誤、異步接錯誤、頁渲染時長等前端頁面級別應用監控應用監控egg-accesslogegg-qwatcheregg-qconfigegg-checkurl 框架（egg.js）業務邏輯機器Watcher日志系統（kibana）Watcher 系統日志系統舉個栗子（3臺4C-8G虛機）舉個栗子（3臺4C-8G虛機）舉個栗子（3臺4C-8G虛機）舉個栗子（3臺4C-8G虛機）