兔展雷宗民：小團隊的基礎設施建設之路
本文根據雷宗民在2018年10月19日【第十屆中國系統架構師大會(SACC)】現場演講內容整理而成。
講師簡介：
雷宗民：現任兔展前端架構師，從零構建兔展一視的技術架構，並參與兔展整站重構。專註於Node.js開發，熱衷於開源，發布過多款NPM模塊，如xss和@leizm/web，GitHub：leizongmin
摘要：
對於大多數初創公司的小團隊而言，面臨的問題包括初級技術水平的成員佔比較高，基礎設施不完善，但是卻要求用更短的時間和更少的資源來完成任務。為了解決代碼、文檔統一的問題;實現自動生成Mock數據和測試代碼功能使得前後端更順暢地並行開發;為了解決團隊項目部署許可權混亂的問題，以及使用Sinopia作為私有NPM倉庫時，由於某段時間服務不穩定導致構建失敗率劇增等問題。
分享大綱：
1. 自研Web框架實現代碼+文檔+Mock+測試同步
2. 前端項目的構建和部署工具實踐
3. 私有NPM倉庫踩坑記
4. 高並發WebSocket項目實踐
正文：
自研Web框架實現代碼+文檔+Mock+測試同步
上圖是項目開發的一般流程，先對項目進行需求分析，根據需求設計數據模型、設計並編寫文檔，之後前後端一起開發。項目多數是比較典型前後端分離的模式，後端提供前端介面，前端作為界面調用後端介面，介面聯調成功再發布上線。我們做的項目大部分是數字營銷相關的，比如朋友圈轉發的H5活動頁面，有抽獎、集贊和各種熱點內容，項目開發時間一般是比較短的，從設計稿成型到開發完成的周期短時間是三五天，長時間也就一周兩周。
基於開發團隊的很多成員是一年左右的工作經驗，每個成員在代碼規範上的習慣也不一樣，這就很容易導致團隊開發效率不高。另一方面，在完成需求開發後就直接進入前後端的運行開發，在介面方面的約定單純依靠前後端的口頭交流和約定，導致代碼質量和運行效果都不是那麼好。在理想情況下是需要做單元測試的，但由於開發時間太緊就省略了測試環節，在驗收時發現問題就進行調節，沒有發現問題這個項目就算完成了。項目上線周期也是比較短的，也不會有長期的運營時間去發現存在的問題。
但隨著公司業務的發展，做的項目越來越複雜，運行的時間越長，項目難度也隨之增加了，在這個過程中團隊發現之前的方式已經不可行了。所以開始思考在不減輕開發的工作量的情況下，把編寫文檔和設計完成，驗收階段加上測試部分，會不會比現在的情況好?
考慮到這個因素，後端團隊設計模型和註冊介面的時候，嘗試用代碼描述這個介面來生成介面文檔，後端開發採用Nodejs，寫完部分代碼就可以生成參數檢查，將單元測試和介面文檔交給前端開發，後端就可以進入真正業務代碼的編寫過程。
上圖是代碼描述介面的具體細節：要設計一個介面，首先定義構思方法，通過什麼路徑、命名這個介面、有什麼參數、返回的是什麼類型的東西，從而形成一個具體業務邏輯。
在業務代碼沒完成的情況下，先通過代碼定義好介面，並生成介面文檔，文檔裡面就能夠顯示我們通過什麼樣的參數去調用這個介面，這個介面會返回什麼樣的信息，這時候前端就可以按照這份介面文檔進行開發。
為項目編寫單元測試也變得十分方便，只需要自動把介面按一定的規則映射成一個函數，單元測試時只需要並調用對應介面的函數，構造相應的參數然後檢查返回結果就可以了。
前端需要手動調試的情況很常見，這時候可以根據介面生成一個用於Swagger調試的配置文件進行調試，另外前端使用typescript編寫代碼，還可以根據介面描述生成對應的typings定義文件，所以在編寫代碼的時候，除了編寫比較方便、寫得比較少之外，還可以利用編輯器的代碼提示。
2. 前端項目的構建和部署工具實踐
下面是具體實施過程，首先是定一個標杆項目，根據項目的特點做模版，通過Yeoman工具生成代碼，另外項目包括前面定義的框架，我們不是通過NPM模塊的方式去引用的，而直接就把它放在項目代碼裡面。在第一個版本的時候加了一些功能，隨後的測試中發現問題再逐漸的修改，慢慢開發成下一個版本，因為項目數量比較多，這個項目改變了點，把代碼直接放到項目，下一個項目直接把它拿出來再改改，再放到裡面也不影響。比如說版本升級，前面項目已經做好了，儘管它是有點不完善的，但是大多數時候不需要後期去維護的。另外為了跟業務代碼做一個隔離，這個項目自動生成的代碼，需要單獨的放到一個目錄里。
通過前面的框架，解決了開發效率和規範質量的問題。通過改革後的前端的發布流程如上圖所示，首先通過Webpack做構建，之後將靜態資源上傳到CDN上，通過FTP將靜態文件上傳。
數字營銷相關的項目大多數規模都是比較小的，都是一個前端一個後端的組合，可能同時有好幾個項目在運行，每個項目的前端做完了就把文件打包發布上去，另外一個項目做完了也打包發上去，這個時候會涉及到許可權管理的問題，所有人都要在伺服器上面做一個發布，如果中間有人操作錯了怎麼辦?所有人都拿同一個賬號的操作，也沒有記錄查詢，這個時候開始考慮優化前端發布的流程。
上圖是改革後的流程：首先完成Webpack構建，通過zip把前端的代碼打包起來，提交到發布管理平台，由管理平台上傳到對應的伺服器上，通過平台就可以通過賬號查詢對應的項目關係，因為不是直接去操作伺服器的，可以避免文件被更改的後果。
上圖左邊是之前的分散式管理，分散式就是所有人都可以操作，經過改造後變成集中式管理，直接把文件提交前端發布系統，再由前端發布系統上傳到對應的地方。實際上在前端發布系統還做了些擴展，在新建一個項目時可以在界面上手動操作，在裡面配置項目用的域名是什麼、放在哪個路徑下、CDN對應的是哪裡，後面把構建跟上傳結合在一起，相當於做了一個小的雲平台。
3. 私有NPM倉庫踩坑記
一般項目都會有搭建NPM庫的需求，團隊最開始用的是簡單的Sinopia，公司還有另外一個前端團隊，他們在前端的構建不是按照改革後方式來去做一個發布的，是直接把前端跟後端的構建打包在一個文件里，之前已經做好了整個構建的腳本，突然發現構建失敗了，查詢失敗原因是安裝NPM包出錯，當構建流程定下來之後，怎麼單獨的跳過NPM的安裝把它構建出來呢? Sinopia是我搭建出來的，自然就把這個問題轉到我這裡來了，但是當時我用的是第三方工具搭建的私有NPM，它出問題了，我這邊也頂多只能重啟。
基於這件事我對NPM的實現原理做了一個研究， NPM在安裝的時候，為什麼會出錯?主要是因為網路的問題， Sinopia實現方式是直接做反向代理，在安裝模塊的時候，有一部分是私有模塊，但是大部分是NPM上原有的模塊，如果是NPM上原有的模塊可以通過302重定向來減少網路出錯導致的故障。另外新版本的NPM命令上面可以配置自己私有的scope的源地址，除了這個特定scope之外的模塊不會請求到私有NPM源，也就減少了這個問題。
實現一個私有NPM庫主要是三部分，第一部分是登錄授權，登錄授權有固定介面，提交密碼返回一個token，拿token上去就可以了。另外是發布模塊，將把整個模塊打包，再加一個介面就搞定了。另外是查詢模塊，它有固定的URL地址格式，通過請求下載這個文件， NPM的安裝就完成了，所以不一定要自己開發私有NPM，只需要一個靜態的文件服務，按照格式把包傳上去就可以了。
4. 高並發WebSocket項目實踐
下面的是項目的經歷，今年上半年有個直播答題活動，產品經理要求它要有5萬並發，就是同時在線有5萬人的直播答題。團隊之前從來沒有做過這樣的項目，要在短短的半個月內完成，首先第一是伺服器怎麼去支持大量的並發，在做並發的時候， Nodejs性能怎麼樣?Nodejs是單進程的，如果通過多進程去部署的話，如何實現共享?WebSocket怎麼測試?怎麼知道項目它就能夠支持5萬的並發呢?
團隊研究發現要使得系統支持大量並發，只要調一下Linux系統的參數就可以支持大的連接數，另外是進程狀態的共享，最簡單是通過Redis的發布訂閱模式去共享多進程的狀態，另外一個是數據序列化，測試第一版的時候，就能夠達到5萬的並發的連接了，但當項目完成真正去跑的時候，實際上在1萬的時候就掛掉了。排查原因發現是測試方法有問題。服務端支持這麼大的並發連接是沒問題的，但是只是保持這麼多個連接，它並不包含活動中的發消息的操作，直播答題中每5秒鐘這5萬人不斷地要去給服務端發信息，服務端還得返回結果，在操作的時候卡了一兩秒再給他返回信息就達不到直播的效果了。
首先對發消息的數據序列化做了一個改進，最開始是通過JSON去做一個序列化，直接返回一個對象，把各種信息統統都塞進去，這個對象裡面的key都很長的，之後需要優化這個發送數據的長度，讓前端後端的通訊數據格式上就儘可能的精簡了。
在完成優化後，如何測試呢?現有工具對WebSocket的測試基本上只是發連接，然後測試這個並發連接的性能。所以手動通過uws模塊手寫測試代碼，不僅僅對鏈接做測試，也加入了整個業務的流程，測試的客戶端它會連接上去，會自動去答題，答完了下一題還會繼續的答。
在經歷了一年的開發和部署的改進，從最開始的很原始方式到現在，團隊開發效率提高了，代碼也更加規範了，生產質量也有所提升。今天的分享就到這裡，謝謝大家!
TAG:IT168企業級 |