log4js pac 獨立 route 其他 執行 搜索 沈澱 htm

在產險作為主要開發人員一共做了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 等開源框架的優缺點，最終選擇了用 koa@2 作為基礎框架，由我對它進行擴展開發，最終形成一個既適合於進行企業級開發，又不會像 egg 那麽厚重並且受制於人的一個內部基礎框架。egg 被否定原因是因為架構師擔心 egg 後期不再有人維護，現在看來還遠遠沒有到不再維護的時候。而且自從那次開會之後，架構組的人就再也沒有誰關心過我們的架構是什麽情況了，可見被稱為架構師的同事也未必都是可靠的。架構師不管了，我自己不能不做，雖然從前也從來沒有做過架構開發方面的工作，但是從其他框架學習一點經驗，模仿著做一個也就是了。於是，參考著《Nodejs：擺脫黑工坊發展出一款基礎企業級框架》這篇文章，先寫出了一個框架的雛形，實現了文章中提到的 controller 和 service 的自動註入，route 的強制約定，另外把前一個項目的根據環境自動配置 config 文件的功能也復制了過來，之後的就要靠我自己去擴展了。首先做一些常規操作，添加了 404 和 500 的處理，使用 log4js 添加了日誌記錄，使用 k-cors 解決非生產環境跨域問題，使用 helmet 添加安全方面的 http header（為此還簡單翻譯了一下 helmet 的文檔）。然後就是開始開發業務，在業務中發現問題，解決問題了。第一個開發的業務城市名稱和編碼服務，這個就發現了問題。首先，我不再能登錄生產服務器，其次也不想再手動開啟城市數據同步方法，於是經過一段時間的思考和嘗試，最終使用《多個獨立進程架構下的單進程數據庫同步方案》中的方案解決了這個問題。解決了這個同步數據的問題之後，很快又出現了問題，有個接口的返回數據量有二百多K，結果數據傳輸非常慢，在測試環境要幾秒時間。於是，首先去掉了前端不需要的數據，減少到一百多k，然後使用 compress 壓縮，最終減少到十幾k，最後再加上服務端緩存，最終接口返回時間縮減到了幾毫秒。

平安產險項目記錄（一）