前端微服務-面向web平臺級應用的設計

從去年開始，前端領域就出現了一個‘微應用’的名詞，說的是前端架構的一種設計思路，業內都把它和後端的微服務進行類比，當時忙於公司的項目。沒有靜下心來好好了解，如今項目結束，再加上最近看的幾篇關於前端微服務的文章，（特別討厭有些文章說的天花亂墜，引用各類高大上的名字，一篇通讀下來什麼也沒有得到）回頭一想，咱們作的這個架構設計不就是 ‘微服務’嗎？

首先說一下前端微服務。

我以爲這是一種架構設計，不是什麼新技術，而是多種技術結合的產物，既然是架構設計那麼它就得有使用場景，不然那是空談，而它的使用場景則是面對平臺級的產品解決方案，能夠支撐許多web應用，各個應用之間相互獨立解耦，又能夠不斷擴展，不只易於老代碼，老業務的維護，並且開發項目也是遊刃有餘的。對於開發人員來講，這樣的架構設計也是獨立的，完徹底全能夠負責單獨的web應用，而不須要和別的團隊交叉式協做，因此我以爲若是產品是平臺級的，作的是解決方案的東西，長期支撐公司發展的，那它的一種設計思路不妨一試，但若是就是幾個獨立的web應用，好比說公司官網，後臺系統，支付系統，這幾個一點關聯都沒有的項目，沒有必要來這樣作，反而會增長項目自己的難度。

它的出現我以爲很大程度上是因爲spa單頁面應用的出現，組件化的出現，讓一個完整的頁面從幾個標籤的組合，到模塊功能的組合，再到應用的組合，一步步過渡，最初一個頁面由幾個標籤加點文字或者圖片組成，主要用來向消費者輸出信息，到後來ajax出現，局部刷新人機交互，頁面成了按照功能模塊來劃分，再到如今單頁面應用，直接按照應用來劃分，每個應用有本身的一套數據，交互，邏輯，業務等等，頁面成了一個容器，或者說是一張幕布，它所作的就是有一個加載機制，更夠不少好地處理各個應用的關係和數據通訊，因此一步步走過來，有各大瀏覽器廠商對引擎的升級換代，有硬件的迭代，還有大量交互數據的出現，體驗的升級等等因素，這些訴求讓前端領域再也不是展現內容那麼簡單，須要不斷突破自我，架構設計應運而生。

微服務裏面容器或者稱爲平臺該怎麼搭建，怎麼加載不一樣的web應用，應用之間如何數據通訊，應用怎麼擴展定義，那些平臺級核心方法如何處理等等，帶着這些問題，結合我司的項目談談個人見解及設計思路。

首先有一個最基本的容器

因爲項目的複雜特色和背景，咱們使用的是jq，別以爲low，用小米加步槍能戰勝敵人更是說明策略用得好，容器呢則是iframe，應用之間數據通訊呢，則是掛載了window這個大對象。

加載機制

那麼如何去加載不一樣的應用呢，有的作法是將全部的應用js文件在首次全加入進來，每個應用都是一個獨立的大對象，根據地址欄的url組成，得到其中的hash名，這個名字能夠是應用的名字，去實例化特定的應用。

或者學習一下vue-router，利用hash更名字，頁面不刷新的特色，去按需加載特定的應用js文件。

在或者直接以整個web組件的形式，經過document.append的方式直接插入進來。

我司採用的是第二種，這樣的方式可控，加載機制能夠自定義處理。畢加索的名言，‘優秀的藝術家抄襲創意，傑出的藝術家剽竊靈感’。

而後各個應用該如何處理呢，怎麼才能作到應用獨立擴展，而又沒有重複代碼呢？

按照現在一切js文件皆模塊的原則，每一個應用的數據，交互邏輯，都是獨立的類，或者獨立的模塊，這個每次擴展就是一個獨立的類，包含着新業務的特定數據和邏輯，相互之間使用import進行引用，不會出現代碼愈來愈多，慘不忍睹的狀況，而每個應用它都有一個index.js文件，在每次啓動應用的時候去加載這個index文件。

而那些平臺級基礎層的組件如何操做呢

繼承，因爲是平臺級的基礎層，每一個應用都會使用，因此在每一個應用的邏輯處理時，都須要經過繼承來使用平臺級的方法，固然每一個應用都不同，平臺級的工具要作到‘拿來即用’，應用能夠結合本身的數據自由組合這些工具，搭建本身的應用，軟件行業裏面有句名言，‘架構設計中,沒有一個問題是不能經過一層抽象層來解決,若是有,那就是兩層’。

注意後期維護

若是不明白這個架構思路，當有新人接收項目，或者出現新的業務的時候，很容易將這個架構打破，可能仍是會按照程序員他本身原來的思路去往上堆，若是是個高手他可能會看明白，可是個初中級的段位呢？對吧，最明顯的例子就是你可能僅僅加一個小功能，想固然地直接插入進去，雖然成功了，結果很容易忽視它是一個平臺級的仍是應用級的方法，甚至可能會由於命名而致使你其餘應用的部分功能很差使，因此架構規則很重要，同時也會發現，當你只是要添加一個小功能的時候，基於這是一個平臺級的應用，合理地增長新功能是一件不容易的事，你可能會質疑它，但隨着你的不斷深刻，抽絲剝繭，你最終會發現，這一切都是有緣由可言的。

關於後臺通訊

因爲將項目全部的重心放在了前端，因此弱化了後端的功能，只須要提供最基本的數據增刪改查便可。

關於構建部署

如何前端構建部署都是基於webpack工具來操做，平臺級的部署也可以體現微服務的特色，獨立部署，獨立構建，因此在須要結合項目去自定義腳手架，在我司項目中，自定義npm命令，以web應用名來定義，而在webpack文件夾下，目錄結構大概是這樣：

和其餘腳手架相似，有一個最基本的base文件，來作平臺級的構建優化，好比壓縮靜態資源，babel轉編譯，打包編譯，開發環境和構建環境的差別化部署等等，來覆蓋整個應用，而後各個應用有本身獨立的webpack文件，對webpack有必定了解的人都知道，在應用中繼承或者使用baseJS文件，直接require進來便可，因爲webpack的幾大要素都是經過對象屬性來構成的，因此想二次加工這baseJS文件，能夠直接修改這些屬性便可，如此，便創建了應用本身的構建部署，

在package.json文件中根據命令定義好了特定web應用的webpack文件

而在cmd命令中，只需輸入命令npm run XXX，則會在package.json命令中自動加載特定webpack文件

快速理解

項目特別複雜，你又想特別快入手，明白它的架構設計，我以爲抓住兩點很重要，第一是數據流，你得注意它的數據結構和流向，從上到下（父子組件，應用之間），從左到右（兄弟組件，應用之間），數據又是如何展現到各個應用的，有一個總體概念，第二，事件機制，其實就是數據處理的交互，每一部分的數據都如何產生的，邏輯處理是怎樣的，再深刻到具體的應用中，去分析它的業務便可，這也是爲何大學裏面計算機專業的課程很大一部分是在教授數據結構和算法，而不教你一大堆主流框架，各類java，R，go，javascript編程語言的緣由，說到底，我認爲，一個應用就是由數據結構，算法，以及自己的業務數據構成的，而那些vue或者react只不過是一種工具，讓你更好地實現你的idea。

寫着寫着，其實發現這個vue的設計思想特別像，我以爲vue的組件化設計其實就是面向對象思路，react更多的是函數式編程，一切js皆文件，以一種web組件的形式來集成應用，不管是哪種主流框架結構，更多的理解框架自己的設計思路，並融會到本身的項目中，也算是一種借鑑和突破，我認爲不必定非得用主流框架，使用一大堆API就是新技術，借鑑思想，修煉js內功，結合業務突破瓶頸，纔是最根本的。

其餘方面的有時間再完善。