蘇寧影片雲高階技術經理：漫談前端系統架構的演變歷程（下）

作者：李曉健。現擔任蘇寧影片雲高階技術經理。軟體技術專業，從事java開發，擁有8年開發經驗，超過6年的專職前端開發經驗，3年以上的團隊管理經驗；目前負責蘇寧影片前端研發和架構工作，參與前端SDK元件的開發，推動蘇寧影片雲平臺的架構改進和使用者體驗，為使用者提供優質的服務。人生信條：始終相信只要有付出，就一定會有回報。

其實我們在新開一個專案的時候，在做框架的選型時也是可以根據頁面結構去做一些參考。去選擇一些適合我們頁面結構的技術去做開發，也會大大降低我們開發的複雜度，比如我們的頁面需要做成一個單頁的形式，我們就可以去選一些MVC或MVVM的架構來做。

今天我們來說一下蘇寧影片雲前端的架構的演變歷程。

第一階段的專案架構

蘇寧影片雲最開始的專案架構，最開始的時候，我們的頁面是用PHP、CSS、原生的javascript來做的。頁面用PHP是因為我們的web服務是PHP的，裡面有一些PHP的程式碼處理業務邏輯，這裡的原生的JAVASCRIPT是沒有用到任何的框架和類庫的。我們有很多的自定義的元件，這些元件也都是我們自己去編寫的。

上線的時候就是透過jenkins將程式碼進行壓縮，然後釋出到線上伺服器。我們當時的開發流程是前端工程師開發好HTML檔案，CSS樣式，頁面互動效果；再將寫好的程式碼交給PHP工程師，他們拿到了我們的HTML檔案，然後再手動轉成PHP檔案，再加入一些業務的邏輯程式碼。

最開始的時候我們的專案就是這樣，這樣看起來好像是處理一個比較初級有階段，確實，這樣看起來沒有什麼什麼架構可言，因為裡沒有用到任何的類庫和架構，整個專案都是用原生的程式碼去累起來的。

第一階段的專案架構中存在的問題

前端開發人員開發完成後，需要PHP開發人員將html轉成php

在這個過程中我們就發現問題比較多，比如說，我們前端人員將頁面開發完成後，再將程式碼交給PHP的開發人員，他們需要將我們的html程式碼再做一次轉換，並加入一些其他的邏輯。

這裡就相當於有兩套展示程式碼，有時頁面上有一些小的問題需要修改，就直接在PHP檔案上修改了，並沒有同步到HTML檔案裡，這就造成了檔案的不同步。以後再將html轉換成PHP檔案時，就會漏掉那些之前直接在PHP檔案修改過的問題，就會使老的問題重複出現。

頁面數量較多

我們的頁面個數也比較多，像我們前面看過的那個頁面結構，每一個左邊的導航都是一個新的頁面，因為頭部還有一級導航，每一個一級導航都有他自己對應的左邊導航，所以頁面就會比較多。

單個頁面請求檔案過多

那時候我們的程式碼也都是純原生的，所有的元件也都是自己開發，每一個元件既有js檔案又有css檔案。很多的元件又有依賴關係，如果一個頁面用到了幾個元件，就需要引入很多的js檔案和css檔案，一個頁面所有檔案加越來，不算圖片大概就有三四十個。

程式碼的複雜度過高，對開發人員的能力要求過高

由於我們沒有使用第三方的東西，所以程式碼量就會比較多，程式碼的複雜度也比較高。而有的很多開發人員從一開始學習就是從類庫和框架開始學起的，對原生的js瞭解的不多，所以開發起來也比較困難，如果有新的成員加入團隊，就需要很長的時候才能熟悉我們的架構，並進入開發，這就對開發人員的能力有比較高的要求。

重複的工作比較多,開發的工作量巨大

因為我們的頁面多，當時的程式碼也沒有做很好的分類，就是一味的往上堆程式碼，有新的功能，就全部用新的程式碼去堆，有很多的功能就是比較類似的，就導致了重複工作比較多，開發的工作量也比較大。

第二階段的專案架構

中間正好有一次機會，產品說要對我們的產品進行重構和調整，當然產品說的重構是指功能上的，但是由於時間問題，只能一部分一部的去做，還需要上一個部分上線之後才能去做下一個部分。

和產品溝通下來，以頁面上的主導航為一個單位進行重構和調整。基於這一點我們就對我們之前的架構進行調整。因為這個分塊進行調整的，所以我們不可能把之前的架構推翻全部重來，這樣不僅時間是不允許，也沒法做到產品要求的按功能模組進行上線。

所以我們就在原有的架構基礎上進行調整。

首先我們原生所有的元件肯定還是保留的。然後對頁面進行了重新劃分，不再是每一個每一個左邊導航一個頁面，而是分成一個大的功能模組一個頁面，左邊的導航透過前端路由去做。

這樣的話我們只需要改當前需要重構的這個功能模組就行了，其他的功能模組還是保持不變。其實這樣下來就相當於把改過的功能模組，由之前的多個頁面合成了一個頁面。

然後我們在前端直接用HTML檔案來展示頁面，直接將html檔案釋出到伺服器，不再將hrml檔案轉成php檔案。

因為我們之前的PHP檔案並不是只是用來展示頁面的，他還有一些邏輯在裡面，所以這裡我們也不能直接把PHP給去掉。然後我們就讓PHP直接轉到介面層，PHP只提供介面給我們前端，這樣的話他之前的邏輯還是可以使用和保留，也不需要太大的改動。

PHP這一層還可以幫我們做一層前端沒法做或者處理不了的問題。因為我們的系統資料有多個後臺系統提供的，PHP可以幫我們前端做資料整合，由他去呼叫其他的後臺系統，然後統一提供資料給我們前端，這樣我們前端就只需要對接PHP一層介面就行了，PHP就從前端的展示層退到了前端和後端的一箇中間層。

基於我們頁面上還有很多相同的部分或者是需要動態生成的部，然後我們又引入了前端模板，我們選用的是arttemplate。上線流程和原來的保持不變。當我們把所有的功能都重構完成以後，這樣就形成了我們的第二階段的架構。

第二階段中解決掉的問題

不需要再將HTML檔案手動轉成PHP檔案

首先最明顯的就是不需要再將HTML檔案轉成PHP檔案，而且我們前端的展示檔案程式碼只有一份，不會再出現因為檔案不同步造成的重複問題不斷出現的問題。這個也使PHP開發人員從前端中解放出來，他們可發專程的去做資料處理，不用再關心HTML、CSS、JAVASCRIPT這些東西了。

透過前端路由將多個頁面合併成一個頁面

然後我透過前端的路由獎多個頁面合成了一個頁面，減少了頁面的個數。這樣也使我們的程式碼檔案量減少了不少，頁面的體驗也得到一定程度的提升，之前每點一個連結，哪怕是一個子功能都需要重新重新整理一下頁面，而現在只有功能主功能時才會重新整理頁面，切換子功能時會動態切換頁面內容，不需要重新載入整個頁面。

使用模板大大減少了重複程式碼，降低了程式碼的邏輯

因為我們使用了前端模板，這時很多頁面相同的地方我們就可以使用同一個模板檔案，這就大大降低了重複程式碼的存在，也降低了程式碼的邏輯。

第二階段的專案架構中存在的問題

單個頁面請求檔案過多

雖然這個階段的架構比前一個階段好了很多，但是還是有少不的問題。因為我們的元件還是使用的是自己開發的元件，那些檔案檔案依然沒有減少，頁面的請求檔案數還是有很多。

單個js檔案中的程式碼較多

 因為我們把之前多個頁面合成了一個頁面，但是總功能沒有減少，而且這些功能程式碼全部都寫到了一個檔案中，所以我們的業務邏輯程式碼的js裡的程式碼量會增加。

程式碼的複雜度過高，對開發人員的能力要求過高

一個檔案裡的程式碼量增加了，他的複雜度也會增加。程式碼的複雜度上去了，自然對開發人員的能力要求要更高。在這樣的架構下，我們也開發了很長一段時間。

第三階段的專案架構

正好又有一個不錯機會可以讓我們做重構，那就是我們的網站要改版。

大家都知道，改版可是一個大的改動，這個也沒法一部分一部分的去上線，因為改完成之後，頁面的風格可能就變了，也可以讓網站以一個混搭的風格去上線。

所以需要改完整體上線。還有一點就是，對於前端開說，網站做整體改版，之前的很多程式碼可能都需要重新來寫。

所所以團隊經過商量，看看是不是可以直接放棄之前的架構，在不依賴之前架構的前提下做出來一個新的架構。這雖然會可能會增加工作量，但對於後期的開發會有很多的便利，而且網站全面改版後，測試也會全面覆蓋。所以我們就放心的去做了。

首先需要確定的是我們的頁面結構，決定依然延續二期的頁面結構，以主功能為一個頁面，左邊的導航使用前端路由來做。然後去和產品確定了一下瀏覽器的相容性，產品說，我們的客戶都是簽約客戶，使用者群體可控，相容主流瀏覽器就行，但是IE需要相容到IE9。

瀏覽器的相容性也確定了，我們決定這次引用框架來做，不再去重複造輪子。接下來就是做技術選型了。

當前比較流行的框架是REACT、VUE、ANGULR。我們也決定在這三個中去選一個，最後經過對比，以及我們專案的特點和團隊成員對這幾個框架的瞭解程度，我們選擇了REACT。既然我們依然需要使用前端路由，我們就選擇了REACT系的 react-router。

我們還決定選擇一個UI的框架，這些就可以有很多現成的元件可以用了，也會大大降低我們的開發難度和開發速度。然後我們選擇了antDesign，因為他有豐富的元件和可定製性，使用非常靈活。因為react裡有JSX語法，這種語法是無法直接在瀏覽器裡執行的，需要將JSX語法轉成js語法。

使用webpack和他的一些外掛配置一套本地的工程化流程，可以對程式碼起先編譯，合併，打包、程式碼的風格的校驗等等。

既然我們有了一套工地的工程化的東西，而react又是基於模組來開發，而ES6+也是原生支援模組的，而且他還有很多新特性可以使用，原始碼也是直接使用ES6+來進行開發的，雖然目前瀏覽器對ES6+支援的還不是很完善，透過webpack的外掛將ES6+轉成ES5的程式碼。

我們本地打包之後的程式碼再交由jenkins去上線，因為jenkins是我們公司的上線流程，我們是無法改變的，所以這一步依然保留，不過這一次交由jenkins的程式碼已經不再是我們原始碼，而是我們經過合併處理的程式碼。所以檔案資料會很少。

第三階段的好處

可以直接使用antDesign的元件

因為antDesign它有非常豐富的元件，我們可以直接拿來用，而且他的文件和也非常完善。

透過modifyVars定製主題

我們的程式碼都是基於模組公去開發的，所以程式碼的耦合度也比較低，一個元件元件就是一個檔案，程式碼的邏輯也比較簡單。程式碼的複用性也比較好。因為元件是可以做到插拔試的，需要這個元件，直接放進去就好，不需要時直接拿掉就好，不會影響到其他功能。

antDesign的所有元件都是有他自己的主題樣式的，但是他提供了定製主題，我們可以透過他他提供給我們的modifyVars的引數，將元件的樣式替換成我們想要的樣式。

透過webpack的多入口配置，大大減少一個頁面的引入的程式碼量

wepack是以js作為入口檔案的，我們透過配置他的多入口，就可以同時打包出多個頁面的檔案。

一個頁面只需要引入一個公用的css和一個自己的樣式檔案，一個公用js和自己頁面的邏輯js。

最終我們生成出來的檔案也比較少，我們在打包時把多個頁面都使用到的js和css 打包共用的js檔案和css檔案，然後再將每個頁面獨自使用的檔案打包出來，這樣我們一個頁面需要引入的檔案也比較少，也就只有公用檔案和自己頁面的檔案。所以一個頁面需要引入的檔案數也就只有4個左右。因為我們都是以元件的方式來引入檔案的，所以說基本上這個頁面引入的檔案都是我們使用過的，然後才打包到一起，所以檔案也不會太大。

元件可以在多處共用

我們的元件也是多處共用的。

第三階段我們解決掉的問題

透過babel的babel-plugin-import外掛對antDesign元件進行按需載入

我們可以透過webpack的外掛來按需載入需要我元件，也就是說，當前頁面只需要載入當前頁面的程式碼，而不說為了用一個元件把整個框架檔案全載入進來，這樣就可以減少檔案的體積，可以使用頁面更快的載入出來。

 透過webpack將公用的程式碼抽離成一個公用的檔案

透過webpack把可以把一些公用的檔案抽離出來，然後第每一個頁面再去引用這個公用的檔案，大家都知道，瀏覽器自己是有快取的，當一個檔案載入了一次後，在他的有效期內，再有請求，他就直接從快取中取，不會再去檔案伺服器上去取。所以說這個對我們公用檔案是比較好的。

頁面模組都是按元件進行開發，每個檔案裡只有當前元件的邏輯

我們自己的功能程式碼也是按元件去開發的，第個檔案裡只有當前元件的邏輯，所以邏輯也比較簡單。我們把公用的元件放到一起，一個頁面的相關元件放在一起，這樣程式碼也比較清晰簡單。程式碼的複雜度也會降低很多。

我們開發流程里加入了程式碼的風格驗證，保證一個團隊的程式碼風格是一致的。

我們的工作流程也加入了程式碼風格驗證外掛，這樣可以保證我們一個團隊不同的成員寫出來的程式碼風格是一致的。

這就是目前我們現在這個階段的架構。

未來的發展及展望

js滲透到各個領域

前面我們已經說到js已經可以做到WEB端，服務端以及客戶端，將來我話我覺得他會滲透到更多的領域。

由於硬體裝置的加強及網速的提升，H5也會有更好的發展

由於我硬體裝置和網速的提升，純屬的H5應用應該會有更好的發展，因為現在前端的東西基本都需要透過網路來傳輸，如果功能豐富的話，檔案的體積就會比較大，網路不好就會載入失敗呀，或者檔案載入比較慢，給人的體驗很不好。

現在比較熱的物聯網也會WEB化

前端可能透過網路網路協議去和硬體程式設計想結合，促進物聯網的發展，比如說我們覺的共享單車，他可以透過web端發出一個指令，就將車子解鎖，就是比較典型的物聯網應用。

由於瀏覽器效能的提升和更多介面的開放，web VR也會有很好的發展

由於瀏覽器的效能的提升和更多介面的開放，像WEB VR也會有比較好有發展。web人工智慧等都會有很好的體現。

蘇寧旗下子品牌蘇寧影片雲已累計服務客戶超過2000個；蘇寧影片雲憑藉PPTV 十年媒體技術和服務經驗，融合流媒體技術、P2P、CDN 分發、海量儲存、安全策略等構建的專注影片領域的一站式SaaS 服務平臺。蘇寧影片雲集影片雲直播、雲點播、雲上傳、雲轉碼、雲端儲存、雲統計等功能於一體，多平臺全方位支援客戶各種影片場景的業務需求。