當接到node開發node api的時候，我就想用docker來部署，眾所周知，node的版本更新叠代很快。很多以前需要babel後才能采用的方法正在不斷被node 原生的支持。如果隨便更換生產服務器的node版本，可能對以前的服務產生一定程度的沖擊。我想用docker就是想單純固定住node版本。關於docker的基本用法，其實網上有很多，自己不想贅述，提供鏈接一篇，其中我的實現基本參照於此 https://segmentfault.com/a/1190000010541792。然而想法是好的，我興沖沖的去創建dockerhub賬號，將自己的鏡像上傳，等著運維pull的時候，他們說他們暫時不想采用docker，理由是為了統一，據理力爭不得，只能按照普通方式來部署，不過我有自己的服務器，部署到自己的服務器簡直迅速又完美。

　　采用普通方式來部署，不過是執行入口文件，然後用pm2來守護這個進程，看起來還是蠻不錯的。但是運行了一段時間，發現有的時候接口返回的數據好大，固定幾秒如果接口的數據沒有 content download 完畢，接口就會報錯誤，類似err_content_length_mismatch,解決方法代碼層面 https://github.com/expressjs/express/issues/3392，在這期間我發現我對請求的每個時間點好像不是特別清楚，於是又發現好文章一篇 network http請求時間分析 https://www.cnblogs.com/zhenwen/p/5827925.html，其中ttfb(瀏覽器發送請求到服務器返回第一個字節所用的時間)，還有其他的什麽dns解析的時間和tcp三次握手的時間，不得不說chrome對於前端開發工程師真是太友好了。不過這些東西跟接口返回大數據的處理沒有多大關系，主要原因是response 太大了，導致contentdownload時間過長。怎麽才能減少接口返回的數據的大小呢，肯定是壓縮，於是想到gzip.怎麽才能用上gzip.我想到的是nginx,可能node存在類似的中間件來實現，但是即使存在，也不能比nginx來的成熟。

,

為了配置gzip接口采用的反向代理， 上圖分別是虛擬主機和gzip的配置

可以看到response的server nginx , gzip已經開啟，完美！

部署node api的二三事