上一篇文章提到了我們專案中使用了Node，有興趣的可以看下
背景
隨著前端元件化方案的落地，整體的前端效率得到了充分的提高，並且當前是有一層Node在做代理層的狀態下，研發的瓶頸逐漸轉移到php這一端。表現出來的是：
迭代速度慢
遇到問題無法快速定位和排查
穩定性受到質疑，經常出現查詢不動，或者整個服務宕機的情況
大量重複的領域在跑
資料量大，匯入資料時鎖表
人員的素質不能跟得上業務的迭代速度
具體怎麼做的先賣個關子，先說說我們在工具這一側是怎麼做的。
Node。js框架
框架選用的是express，在這個基礎上結合當前的業務現狀出來的一整套框架，給一張圖。當然畫圖不是我擅長的點，所以湊合看吧。。。
框架基本結構
日誌：
應用日誌是透過log4j來收集的，按照天寫成檔案，儲存在到本地磁碟。一個http請求進入到服務後，會有一個唯一的key會貫穿整個http請求的生命週期，如下圖：
最終在寫入每一條日誌時，都是會帶有該標記。目的是如果當前系統有一個異常操作，可以快速鎖定整個流程。
config：
config包含3個配置項 環境相關、應用啟動、nginx配置。
應用啟動配置項會選擇當前的環境變數，根據不同的環境變數啟動不同的環境變數配置。
nginx配置就是一個單純的nginx配置檔案，不同環境唯一的差異就是靜態資源快取和ssl的配置。
環境配置包含埠（建立專案時自動生成）、第三方服務的配置、資料庫相關配置、一些應用相關的配置。
ORM
ORM是一個自研發的東西，主要支援的是mysql、redis。功能包含透過sql的方式增刪改查、事物、分庫分表支援、批次插入/更新最佳化、sql安全的處理等功能。
路由
路由透過資料夾自動生產，更好維護和管理。
其他
Node相關的包真的不靠譜，團隊已經大面積重構，比如用的最多的excel包
框架
除了上面說的這些集中在框架中，還有就是對Api和controller進行了封裝，規定了業務邏輯的寫作區域，防止記憶體釋放有問題，導致的記憶體洩露。
業務梳理
從當前業務的入口入手，展開來看當前的業務情況，這裡找到其中一個專案的一張圖
業務梳理圖
到這裡其實很容易看到當前專案的一個業務模型
業務模型圖
這樣整個服務設計其實非常容易達成了。而且指標計算的服務可以抽象成一些通用的服務，所有的專案都基於這些服務來完成。
還有部分節假日相關的資料，有獨立的服務透過crontab來定時抓取，補充資料來源。
整體的架構大概就是這個樣子，這裡有一張之前分享的圖，直接拿來用
服務架構圖
所有的服務都是透過內網來交換資料，來減少頻寬層面的消耗。
資料整合
早期的資料庫是多個團隊同時設計和維護的，所以其中各個方面差異性非常大，而且不是每一個團隊都適合做這樣的事情，畢竟術業有專攻。我接手後大概有下面這些問題：
資料膨脹比較快，需要分庫分表和索引最佳化。
配置遷移出去減少維護成本
增加指標相關的配置邏輯
表設計不合理的問題，最後解決，依賴太多
當前專案已經存在一段時間，單表的資料量有到幾億行，當前這個節點下如何快速的入手解決查詢慢，寫入也慢的問題，這是最關鍵的，所以我們著手的第一件事就是先拆開，這樣能把單庫資料量降下來。
分庫分表
分庫分表業內其實有很多成熟的中介軟體可以用，但是目前為止以當前團隊的精力和對中介軟體的理解貿然上一個中介軟體帶來的問題可能也不在少數，所以設計了2張路由表來做簡單的對映，透過對映關係，應用服務來做服務的動態切換。
分庫是透過酒店來拆分資料不同的庫。ps：沒有那麼極端到每一個酒店一個庫。
配置類資料遷移
總體來看資料分為2類使用者產生的和業務資料，業務資料可以根據分庫分表的邏輯來拆分，但是使用者資料應該單獨儲存，這樣後期遷移的時候不需要擔心傷害到使用者資料。
表設計不合理
表設計的問題，短時間內可能無法做太多改動，因為除了應用層，模型和ETL團隊也依賴一部分資料，這塊是沒有完全做到隔離的。
能做的只是索引和sql調整，讓查詢和寫入的效率提升。
日誌採集
整個應用日誌會被定時拉走進入到日誌服務，日誌服務根據分析拿到相應的異常日誌，按照我們預設的關鍵點，來透過預警服務傳送報警到相關的人，報警分2部分微信和郵件。
體會
服務端和客戶端最大的差別在於一個是穩定另一個是體驗，所以服務端還是要在運維層面做工作，來保證服務的穩定性。
