2017 年總結——工程之美

02-17

想看英文的戳這裡：Summary of 2017?—?The beauty of enginerring
主要為了個人總結，歡迎友善的探討。

今年由於沒有產出，被公司優化了，在這總結一下今年的工作，希望對大家有所啟發。

一、前端開發容器化

來公司做的第一個非業務項目是和清v 大佬兩個人嘗試將前端開發與容器化結合。利用 k8s 實現了前端開發環境的雲端共享，從而減少對開發機的性能需求，並且可以在極短的時間內在各個項目間切換（不用每次等待 webpack 的首次編譯）。

這個項目，主要有三個部分要實現。

服務端：主要用來調用 k8s 的 API，實現 Deployment 的創建銷毀，以及通過 Service 和 Nginx 實現服務發現，為每一個項目分配域名。而且，由於域名的存在，前端開發階段可以更快的和後端、測試進行溝通交流，且不再受到跨域的限制（因為在同一個二級域名下）
Agent：需要在每一個 Pod 中安裝一個 Agent 來與伺服器進行交互（安裝到初始的 Image 中），比如通過這個 Agent 我們可以進行埠掃描，從而發現用戶真正使用的埠，並進行註冊。此外，在這一層，還可以做諸如許可權驗證、系統監控等工作，但由於我們面對的前端開發環境，所以並未深究。
客戶端：在客戶端我們實現了一個一個命令行工具，它可以通過與服務端的交互去創建新的 Deployment，之後等待 Pod 創建成功後，利用 rsync 行文件同步，並通過保持 SSH 連接使得客戶端可以隨時與 Pod 進行通信，包括命令執行和信息返回等。

還有一些其他的小的細節。比如，我們會利用 lock 文件將本項目的 node_modules 進行壓縮存儲，再配合持久化存儲中的 node_modules 共享，使得一個已有項目創建新的 Deployment 變得及其迅速（加快了 node_modules 安裝，畢竟是直接本地 Disk 讀寫）。通過利用 nginx 配置文件模板，動態生成 nginx 項目，隨後 reload nginx，實現了一項目一域名，並且配合 ssl 證書，使得需要利用 https 才能使用的地理信息的 API 得以使用。

雖然，這個項目最終由於 k8s 的部分限制，以及種種原因難以推廣，但是如果有小夥伴想要繼續深入這個工程的可以和我私信交流。理論上，這個項目做大後，可以顯著的減少前端開發者對自己機器的性能需求，並且可以實現環境的一致性和穩定性。通過多人協作的模式甚至可以實現同一項目的多人遠程協作開發。

這個項目後來，通過類似 ngrok 的技術，淪落成一個為大家提供轉發的工具。很多時候大家只是需要一個指向本機的域名，如果公司的 DNS 維護人員能夠提供某種工具讓大家註冊一個指向自己機子的域名，可能更好解決這個問題，但是利用 DNS 難以解決跨網路的訪問，因此還是需要一個工具來打洞進行連接。

二、前端監控

之後，我到另一個組開始對公司現有的前端監控進行了改造（現在他們開始了新一輪的改造，概念更為先進）。在我來的時候公司已經有一套相對完善的前端監控系統（包含 Web、Weex），基本上在所有的前端項目中都接入了，因此擁有大量的數據基礎。

從功能來看，前端監控主要做的是兩個部分，一個是性能監控，一個是報錯反饋。我主要是進行了 SDK 的重構以及前端管理頁面的升級換代（雖然現在因為架構變動又被升級換代了）。

作為一個前端監控的 SDK，首先自身不能影響業務的運行，即 SDK 要足夠健壯，不會因為自身的錯誤導致業務頁面無法運行。此外，為了儘可能的收集到所有信息，SDK 應該儘早引入，這也就意味著，SDK 的啟動要足夠快，否則會影響到整體頁面的載入速度。而且，由於我們有動態修改 SDK 上報信息的需求，還需要注意信息發送的時序問題。

對於性能數據，更多的是利用 Performance API 來獲取信息，這個相對來說較為容易，只需要清楚每個欄位的含義進行處理即可。而對於報錯反饋，最主要的步驟是對報錯信息進行解析，主要是調用棧信息以及報錯歸類等，我一開始接手這個 SDK 的時候較為簡陋，做的比較好的如 raven.js 會根據不同瀏覽器將錯誤進行針對性處理（建議想做前端監控的都去學習一下 Sentry ），之後，我還做了動態變更監聽器、請求合併等改造。

在這個項目中，有一大部分改造是針對項目開發工具的改造，包括利用 rollup 打包 sdk，以及更換管理頁面的 webpack 配置等，基本上都是重新做了一遍，希望後來維護的人能不再那麼痛苦（我接手的時候，連 dev 都是手動刷刷刷）。

而對於監控的後端實現，由於我不是實現者，就不進行細談了。

如果一個公司的前端想做大做強，監控是必不可少的一環節，所以，這塊的深入研究也值得投入大量的人力，而且看著這些數據，會讓你感受到數字的魅力。

三、前端發布

後來，我回到了自己真正所屬的組裡，進行前端發布系統的維護開發，這套系統也引發了我對前端自動化工程的興趣。

一個前端發布系統主要包含三個部分：源碼管理、CI/CD、資源發布。

源碼管理一般是依賴各種相關的 Git 服務，比如 Github、Gitlab 等，在這一步我們需要做的是對不同平台的 webhook 進行處理，進行鑒權、統一成我們需要的項目信息等操作，相對來說，只要根據各家的 API 文檔即可完成，並無大坑。這裡有一點可以極大降低用戶使用成本的操作是學習 http://drone.io，通過調用 API 的方式，自動的將項目的 webhook 配置好，從而可以將自己的發布系統和源碼管理快速打通。

CI/CD 在當前使用最多的是通過 Jenkins 執行 CI，在這一層的實現就是個公司各憑本事了。簡單來說，就是通過讀取倉庫中的配置文件進行一系列流水線操作。當然，也可以利用 Jenkins 的 Pipeline 快速實現一套自己的發布流程。這裡面涉及到自定義鏡像、注入環境變數等操作由於設計公司其他技術要點，就不細講了。CD 主要是要對各個環境進行劃分，並可以對每次交付產物進行有效的管理，實現各個版本的快速回滾、版本備份等。

最後一個步驟是資源發布，這一步主要是將交付產物上傳至用戶可以訪問到的地方，可能是具體的資源機，或者利用 CDN + OSS 實現更為有效無痛的資源管理。

四、組件庫

其餘時間做的一些時間主要是幫其他組打雜，或者維護一下開源的組件庫、實現一個移動版的新的組件庫（主要做了腳手架）。不得不說，維護一個開源項目是極其累的（雖然不是主職，由衷佩服其他幾位大佬）。當一個組件庫走向成熟，許多問題並不僅僅依靠對源碼的熟悉就能解決，還需要你對所用框架進行更深一步的研究，這裡就不得不佩服發我組長，我看一天的問題，他一會兒就搞定了。整體來說，組件庫這種東西對於一個前端來說相比上面三個更像本職工作，所以在這就不細說了，諸位看官應當有比我有更深的了解體會。

五、總結

不得不說，我所在的團隊、部門都是極其優秀的，被優化我無話可說，但我希望之後的職業生涯不會再有這種情況的發生。今年大概有一半時間都在與後端、運維等相關內容打交道，也體會到了工程的魅力，也算是沒白乾一年。之後的時間，可能會向開源社區反饋一些有別於公司已有項目（防止侵權問題）的其他的一些技術實現。

如果你對前端的各個基礎設施的建設感興趣，可以與我進行交流（雖然不能保證全部回復）。

感謝閱讀。