微服務前端之微前端

分而治之是利用微件拆分來達到工程拆分治理的思路，可以解決業(yè)務快速擴張、開發(fā)維護困難等問題。對于一個完整的產(chǎn)品來說，前端可視化層、后端服務層是必備的。

在后端，我們將原來的單體式應用拆分成了不同的微服務模塊，微服務與微服務之間通過服務注冊等進行通信和調(diào)用，共同對前端提供服務。而在前端，主要是通過后端接口獲取數(shù)據(jù)，展示不同的內(nèi)容給到用戶，有web端、h5端等形式。在以前的開發(fā)方案中，web端、h5端都是由獨立開發(fā)和維護，而實際上它們的業(yè)務邏輯基本一致，只是UI風格差異比較大，那么我們是不是可以把“共用”的部分抽離出來呢，這樣可以避免重復開發(fā)與維護，極大的提高開發(fā)效率，這就是微前端的思想。

抽離出來的方案有兩種，即物理抽離、邏輯抽離。對于物理抽離來說，就是把共用的模塊放在一起，前端是通過common文件夾進行引用，后端則是通過jar包、lib庫進行引用。這會帶來一個問題是隨著業(yè)務變得越來越復雜，共用模塊內(nèi)容會越來越多，從而導致開發(fā)尋找到相應的內(nèi)容會很困難，開發(fā)速度、構(gòu)建速度、部署速度也會越來越慢，等到上線后，線上出現(xiàn)故障，排錯也比較困難。所以物理隔離不是長期方案，長期方案來說就是邏輯隔離，將整體業(yè)務進行拆分，共用（比如子業(yè)務工程之間的路由注冊、路由切換）邏輯拆離出來，子業(yè)務之間單獨成一個工程進行開發(fā)。

事實上，微前端架構(gòu)整體思路和微服務架構(gòu)演變一致。在以前的單體式前端、單體式后端應用中，前端請求的分發(fā)路由是通過框架來完成的，即框架將路由指定到對應的組件或內(nèi)部服務中，微前端就是把以前的應用內(nèi)的組件調(diào)用拆分成了更細的應用間的組件調(diào)用，通過路由來找到對應的應用，再由應用分發(fā)到對應的組件；后端請求把內(nèi)部之間的函數(shù)調(diào)用變成了遠程調(diào)用。

所以微前端不過是把用于服務器端的思想用在了瀏覽器端，將web應用由單一的單體應用拆分為多個微前端應用聚合而成的應用，應用與應用之間可以獨立開發(fā)、獨立運行、獨立部署。

目前在業(yè)內(nèi)有這幾種方式可以實現(xiàn)微前端：

1. 路由分發(fā)式，即使用http服務器的路由重定向應用；

2. Iframe式，即通過組合多個獨立應用，子應用與子應用之間設計通訊、加載機制；

3. 通用中心路由基座式，即子應用與子應用之間技術(shù)?？梢圆灰粯?，可以是Augular、React、Vue中的任何一種，完全獨立，互不依賴，子應用與子應用之間的通信由基座工程進行管理；

4. 特定中心路由基座式，即子應用與子應用之間的技術(shù)棧必須一致，子應用可以使用基座的能力進行通信。

在這些微服務前端方案中，業(yè)務可以根據(jù)自己的特點來選擇最適合的方案。目前最通用、最契合微服務思想的便是通用中心路由基座式了，我們也簡單的介紹一下這種微前端方案。在具體實現(xiàn)上一般包含四個部分：動態(tài)路由、動態(tài)配置、子應用接口設計、復用方案設計。

在動態(tài)路由方案中，一般拆分成基座路由和子應用路由，用戶請求先打到基座路由，然后加載子應用入口文件，動態(tài)注冊子工程路由即可，整個的流程如下，非常簡單。在動態(tài)配置方案中，要解決的是基座工程如何知道子應用的資源路徑，從而加載js、css資源，通過在配置文件中標識業(yè)務線的key、資源地址的value，在從基座到子應用切換時拉取配置信息即可。在子應用的接口設計中，暴露給注冊給基座應用的對象即可。在復用方案設計中，把子應用相同的依賴，如框架基本庫、業(yè)務組件等全都放在基座工程，這樣子應用的代碼中主要導入這個庫就可以了。

通過將前端應用拆分成微前端應用，整個業(yè)務的可維護性得到了提高，實現(xiàn)了關(guān)聯(lián)部分高內(nèi)聚、不關(guān)聯(lián)部分低耦合。子應用可以獨立開發(fā)、獨立部署、獨立上線，互不影響，子應用的構(gòu)建、部署速度也提高了很多，減少了等待時間，加快了上線時間，提高了開發(fā)效率。

通過本文的介紹，想必你對微服務的思想更加了解了吧？它是一種軟件架構(gòu)設計思想，存在于前端、后端服務中，結(jié)合實際業(yè)務場景，進行合理的架構(gòu)設計、服務拆分，必定會更好的提高開發(fā)效率。