普元雲計算-聊聊前端工程化的實踐與將來

轉載本文需註明出處：微信公衆號EAWorld，違者必究。

 

 

目錄：

 

1、前端過去一年的發展

2、工程化是前端實現的核心

3、EOS8前端工程化設計實踐分析

4、總結與展望

 

1、前端過去一年的發展

 

2017年的前端發生了很是多的事情。快速的技術進步，彷佛已經使前端工程師目不暇接，咱們來一塊兒看下去年發生了哪些事件：

 

 

• React16發佈前夕，React license風波發展到頂峯，多家公司宣佈將不在使用react做爲其產品的前端框架。網上對Facebook的聲討也達到了頂點。隨後Facebook不得不將React license更改成MIT。這件事情極大的影響了React在你們心中的定位，人們紛紛將目光投向Vue。

   

   

• 去年，Angular一口氣發佈了兩個版本，Angular4以及Angular5。這樣的變化彷佛在乎料之中，又在乎料以外。根據官方文檔說明，從Angular4以後，每一年只會發佈一個大版本。然而在剛剛進入18年的時候，Angular 6.0.0 Beta版本發佈，讓前端開發者不得不感慨，前端之路太心酸了。

   

• 2017年是Vue飛速發展的一年，除了學習曲線平緩，Api簡單易用以外等諸多緣由外，離不開React和Angular的種種「不友好」的行爲。

   

• PWA（漸進式網頁應用）愈來愈被你們所關注，也愈來愈被應用。也許這個技術並非咱們一直在尋找的使用網頁技術完美支持其它客戶端的方法，但PWA使用現代的瀏覽器技術使得訪問網頁應用的體驗和原生移動應用同樣。而且在性能上有了大幅度的提高，並且支持離線訪問，像推送通知這樣原生APP纔有的功能也支持了。

   

• WebAssembly(wasm)已經開始被全部主流瀏覽器支持。也許WebAssembly將會開創Web的VR/AR新時代。

   

• 2017年Serverless應用持續增熱，這是一種新的能夠提升性能又減小資源耗費的架構。你的客戶端徹底從服務器從分離出來，這樣就能夠只關注應用自己而不是架構。一個常見的實現方法是用AWS API Gateway和AWS Lambda函數做爲後臺服務。

   

• GraphQL日趨火爆，有賽過REST之勢。Samer Buna甚至宣傳REST已死。GraphQL容許客戶端自定義數據，而後一次獲取。而REST方案須要維護獲取不少無效數據。Github的新版API已被GraphQL重寫。

在變化飛快的前端發展中，前端究竟應該如何開發，究竟應該用什麼框架，前端代碼如何部署，如何進行先後端分離成爲人們爭論的焦點。

 

 

2、工程化是前端實現的核心

 

在將來，前端工程化成爲工程師關注的核心問題。 而工程化的幾個重要方面，就是路由的實現方式，組件模塊化，構建自動化。

 

 

• 路由實現方式。先後端分離，前端路由顯得尤其重要。除了多層級的設置，還要考慮路由實現方式。

   

• 因爲前端模塊化，各個組件各個模塊如何相互通訊，則尤其重要。必須統一進行管理，不然在多人同時開發，且頁面不斷增長的狀況下，前端代碼會愈來愈難以維護。

   

• 開發的過程當中，要考慮到部署方式。儘可能使用一套可以知足全部部署方案的方法進行開發，減小部署工做量。

 

1.路由實現方式

 

最經常使用的路由分爲Hash路由及History路由。

 

 

• Hash路由：（例http://primeton.com/#/login.html）經過改變地址後面的hash來改變瀏覽器歷史記錄，Hash部分不會發至服務端，框架自己根據url來生成相應的模塊

• History路由：（例http://primeton.com/login.html）使用HTML5的History API，提供pushState(),replaceState()等方法。路由請求會發至後端服務器。

 

通常主流作法推薦使用History路由。

 

使用History路由的好處在於兩點，其一是頁面url比較美觀，其二是能夠複用瀏覽器自身的前進後退特性，但在SPA（單頁面應用）狀況下支持history模式須要後端的支持。

 

因爲普元微服務治理平臺並不但願路由變化時，瀏覽器發請求到後端，故使用Hash路由。這樣作的好處是經過前端控制用戶權限，必定程度上方便後期對系統的擴展。這主要跟總體平臺架構的設計有關。

 

2.靈活部署，解決先後端通訊

 

先後端分離模式的開發模式下，一般有兩種部署方式來解決與後端進行ajax通訊的問題。一種是Nginx做爲部署容器，一種在構建工具中將請求轉發。

 

 

1. Nginx做爲部署方式，須要啓動一個Nginx服務，經過配置config文件，將請求轉發到不一樣的地址。

2. 若以構建工具的方式，則是經過構建工具啓動的server自帶的proxy將請求轉發出去。

 

接下來詳細介紹使用構建工具轉發請求的方式。

 

以Webpack爲例，經過proxy，Webpack server會過濾請求，將帶有配置的路徑的請求，轉發到須要轉發的服務器。

 

當代碼須要部署在tomcat中時，因爲不一樣項目在Webapp中的前端文件名稱可能不一樣，每當Webapp中的應用更更名稱，前端都須要更改ajax的路徑，很是麻煩。

 

有一種方法能夠一勞永逸的解決這個問題。使用NPM build以前，在你的package.json文件中，加上homepage變量來寫明你的服務的絕對路徑。

 

npm在build的過程當中，默認前端代碼就在服務的根路徑下，想要重寫這個路徑，能夠在package.json中加入上面的homepage，即可重寫。若不想設置固定的路徑，則能夠用下圖實例：

 

3、EOS8前端工程化設計實踐分析

 

以咱們的技術團隊目前正在研發的EOS8的前端設計爲例，講一講前端工程化的實踐。

 

EOS8平臺的目標是提供一整套微服務應用平臺與應用全生命週期管理平臺，可以提供企業快速構建數字化需求交付的能力。

 

EOS8與咱們正在研發的另外一款產品DevOps都遵循先後端分離、前端模塊化的開發方式進行開發。這樣作的好處是可以方便多地同事同時進行開發，減小溝通維護成本，同時保證後期的可擴展性。另外，先後端分離，也是微服務系統比較好的實踐。

 

拋開框架之爭，結合EOS8的前端設計，來分析從開發到部署的整個生命週期過程，主要從如下三點來考慮：

 

1）須要根據需求，考慮清楚頁面的路由實現方式，同時從功能角度具體分類各個功能模塊。

 

2）因爲平臺功能的可添加性很是強，故頁面設計須要符合模塊化設計，方便後期添加新的功能模塊，同時在開發的過程當中，須要將ui組件公共化，標準化，方便後期開發。

 

3）前端代碼的架構要考慮最終上線的部署方式，同時也要方便開發人員進行開發。

 

1.模塊化開發

 

首先，前端工程化的第一步，要先劃分清楚前端的功能模塊。功能模塊之間不能耦合。這樣的好處是，不一樣團隊能夠同時進行開發，最終將各自開發的模塊合入便可。模塊的開發遵循統一的開發標準。數據能夠經過flux來管理。

 

 

咱們做了以下的模塊劃分：

 

• 平臺狀態監控。

• 用戶認證，組織機構管理等。

• 應用節點配置進行更改，並進行灰度發佈等。

• 應用下各個狀態的監控。

• 不一樣應用進行統一管理的能力。

• 對應用提供Api Gateway。

 

 

 

2.模塊化路由及頁面設置

在這裏，模塊化主要從路由模塊化和頁面模塊化兩個方面來設計。

路由模塊化，能夠解決父子模塊嵌套問題，在單向數據流的框架中，這一點尤其重要。同時，經過路由嵌套，規範頁面URL，使整個前端路由清晰，具備方便跳轉、傳參等優點。

頁面模塊化則能夠提升頁面組件的複用率，減小重複的代碼。

• 路由模塊化：整個平臺能夠分爲6大模塊，每一個模塊分配一個路由地址，經過路由地址找到不一樣的模塊。圖中展現的是一級路由地址，以下圖所示：

 

• 頁面模塊化：就單個頁面而言，頁面須要按照組件的方式組成。爲了可以減小組件的複雜性，，能夠劃分爲Container Components以及Presentation Components。

 

1. Container Components主要用於承載各個不一樣的公共組件，起到必定佈局的功能。同時，他負責與服務端進行通訊，獲取頁面所需的數據，傳給Presentation Components。

2. Presentation Components主要用於具體的功能組件。它通常不參與數據的交互，只負責展現Container傳給他的數據。這樣能夠達到最大的複用這個組件

 

如圖所示，頁面由Header，SideBar，Content三個組件組成，而每一個組件，可由多個小的公共組件組成，以下圖所示：

 

3.部署實踐

 

在這裏，模塊化主要從路由模塊化和頁面模塊化兩個方面來設計。

 

路由模塊化，能夠解決父子模塊嵌套問題，在單向數據流的框架中，這一點尤其重要。同時，經過路由嵌套，規範頁面URL，使整個前端路由清晰，具備方便跳轉、傳參等優點。

 

頁面模塊化則能夠提升頁面組件的複用率，減小重複的代碼。

 

路由模塊化：整個平臺能夠分爲6大模塊，每一個模塊分配一個路由地址，經過路由地址找到不一樣的模塊。圖中展現的是一級路由地址，以下圖所示：

 

前端部署的方案有兩種：

 

• 先後端分離方式，經過nginx轉到後臺。這種方式不須要關注前端文件的路徑問題。

   

• 混合模式下，前端代碼會放到tomcat中，Ajax以及靜態資源須要關注路徑問題。

圖中左側爲先後端分離的簡易方案。具體部署時，經過nginx，能夠進行負載均衡，同時能夠部署多臺nginx服務器。若是性能仍舊沒法知足，則可使用LVS+F5/LVS+Nginx等多種方式進行負載均衡。

 

圖中右側爲最傳統的部署方式，將前端編譯工具打包出來的文件，放入tomcat中便可。

 

不一樣應用場景下，負載均衡的方案有不少，要根據實際的應用場景來選擇適合本身的方案。這裏咱們的前端架構，只要在打包時，根據不一樣的部署方案，將前端文件的路徑問題、ajax路徑問題解決便可。

 

4、展望與總結

• 展望

   

微前端這個術語，最初來源於ThoughtWorks公司的技術雷達。傳統的微服務架構下的前端：

 

微前端的核心思想如圖所示（圖片來源於網絡）

 

微前端的理念，是將一個網站當成一個組件的合成體，每一個組件由一個獨立的團隊負責。帶來的好處是每個團隊在選擇和升級他們的技術棧時，並不須要與其餘團隊進行統一，同時代碼不依賴於共享狀態和全局的變量。

 

這聽起來很美好，不過目前微前端大致上還停留在概念的階段，具體實施起來困難重重，光是框架之間的壁壘，就難以突破。

 

也許在某天，技術大牛們終將打破技術的壁壘，實現微前端，讓咱們拭目以待。

 

• 總結

 

經過前端的展望，能夠看出來，在將來，框架將再也不限制前端架構，再也不制約前端開發人員。人們能夠根據本身的業務，選擇不一樣的框架，最後將各個業務模塊組合起來。人們須要關注的核心，是如何將前端工程化，如何合理的將業務模塊化、如何合理的分配路由，如何更快的進行開發等。

 

不管採用哪一種前端框架，前端開發的本質思路是同樣的。學習前端，搭建前端項目，不該只關注具體的框架，更多要從前端工程化的角度出發去實現項目。這樣才能使前端項目擁有更短的開發週期，更好的用戶體驗，更絢麗的頁面效果。

 

關於做者：王若林，普元SOA&雲計算部門高級前端工程師，曾在Tibco以及海航科技擔任前端工程師，參與開發Tibco Api Gateway、海航商店、海航IAM等項目。現主要從事普元EOS微服務管理平臺開發設計工做。

 

關於EAWorld：微服務，DevOps，數據治理，移動架構原創技術分享，長按二維碼關注