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

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

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

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

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

目前在業內有這幾種方式可以實現微前端：

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

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

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

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

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

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

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

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