在產險作為主要開發人員一共做了4個專案，分別是兩個 node.js 後臺服務、一個 react 移動端專案、一個 vue 移動端專案。其中兩個 node.js 服務都是隻有我一個人開發，移動端專案是有5個人的前端團隊協作開發。 第一個 node.js 服務是一個車型查詢服務，主要目標是把服務升級到新的版本，因為原有的服務依賴的 node.js 和依賴庫版本都非常老了，已經不合時宜了，我們領導決定讓我用最新版本的 node.js 把這個服務的邏輯重新實現一遍，所以這個專案的主要任務是搞清老的服務邏輯，然後部署到新的伺服器上。 老的服務邏輯並不複雜，主要是用一個分詞模組把車型資訊的主要資料進行分詞存入 mongodb 資料庫，然後通過和使用者輸入的查詢資訊的分詞資料進行對比來獲得使用者可能想要查詢到的車型資訊。這個專案讓我收穫最大的不是對老的邏輯的分析和實現，而是對 linux 系統的學習和操作。這個專案需要通過跳板機部署到內部的雲伺服器上，一開始，我是把專案程式碼先壓縮，使用 scp 傳送到跳板機上，然後再一個一個的傳送到4臺生產機上。這樣搞起來流程比較繁瑣，而且總是會讓人擔心是不是有一個伺服器忘記重新部署了。於是，我通過搜尋，發現可以使用 expect 這個 linux 下的工具實現自動登入伺服器並且傳送檔案、執行部署命令，於是，通過幾天的學習和實驗，我用 expect 成功的實現了半自動化的專案重新部署方案，和前手工操作相比起來，用的時間更短，部署準確度更高。這個算是這個專案的一個亮點。我想，這應該也算是我自己性格和思維的一個亮點吧。我在生活中，不喜歡繁瑣重複的事情，如果有這樣的事情，我就會抱怨，就會想辦法把這個事情做成能夠自動化完成的事情。 第二個 node.js 服務是一個比較複雜的服務，我們稱之為 padweb ，是線銷C端門戶系統的一個元件，現在已經包括車險PC官網介面、車險前端頁面錯誤統計服務、車險前端頁面媒體來源統計、員工賬號登入服務接入、城市名稱和程式碼搜尋查詢等功能。 這個專案不僅是要做一些業務的實現，同時也是為了在車險沉澱出一個功能完備的 node.js 開發框架。上一個車型服務專案使用的的 express， 在開發 padweb 之前我們的架構師組織開了一個架構討論會議，分析對比了 express、koa、egg 等開源框架的優缺點，最終選擇了用 [email protected] 作為基礎框架，由我對它進行擴充套件開發，最終形成一個既適合於進行企業級開發，又不會像 egg 那麼厚重並且受制於人的一個內部基礎框架。egg 被否定原因是因為架構師擔心 egg 後期不再有人維護，現在看來還遠遠沒有到不再維護的時候。而且自從那次開會之後，架構組的人就再也沒有誰關心過我們的架構是什麼情況了，可見被稱為架構師的同事也未必都是可靠的。 架構師不管了，我自己不能不做，雖然從前也從來沒有做過架構開發方面的工作，但是從其他框架學習一點經驗，模仿著做一個也就是了。於是，參考著 《Nodejs：擺脫黑工坊發展出一款基礎企業級框架》這篇文章，先寫出了一個框架的雛形，實現了文章中提到的 controller 和 service 的自動注入，route 的強制約定，另外把前一個專案的根據環境自動配置 config 檔案的功能也複製了過來，之後的就要靠我自己去擴充套件了。首先做一些常規操作，添加了 404 和 500 的處理，使用 log4js 添加了日誌記錄，使用 k-cors 解決非生產環境跨域問題，使用 helmet 新增安全方面的 http header（為此還簡單翻譯了一下 helmet 的文件）。然後就是開始開發業務，在業務中發現問題，解決問題了。 第一個開發的業務城市名稱和編碼服務，這個就發現了問題。首先，我不再能登入生產伺服器，其次也不想再手動開啟城市資料同步方法，於是經過一段時間的思考和嘗試，最終使用《

多個獨立程序架構下的單程序資料庫同步方案》中的方案解決了這個問題。解決了這個同步資料的問題之後，很快又出現了問題，有個介面的返回資料量有二百多K，結果資料傳輸非常慢，在測試環境要幾秒時間。於是，首先去掉了前端不需要的資料，減少到一百多k，然後使用 compress 壓縮，最終減少到十幾k，最後再加上服務端快取，最終介面返回時間縮減到了幾毫秒。