摘要：微內(nèi)核架構(gòu)在大型前端系統(tǒng)中的應(yīng)用只討論架構(gòu)，不討論框架名詞解釋由一群盡可能將數(shù)量最小化的軟件程序組成，他們負(fù)責(zé)提供實現(xiàn)一個操作系統(tǒng)所需要的各種機(jī)制和功能。而微內(nèi)核架構(gòu)已經(jīng)在操作系統(tǒng)和很多的產(chǎn)品的后端服務(wù)及前端中經(jīng)過了很多的實踐。

只討論架構(gòu)，不討論框架

由一群盡可能將數(shù)量最小化的軟件程序組成，他們負(fù)責(zé)提供、實現(xiàn)一個操作系統(tǒng)所需要的各種機(jī)制和功能。這些最基礎(chǔ)的機(jī)制，包括了底層地址空間管理，線程管理，與進(jìn)程間通訊。

將系統(tǒng)的實現(xiàn)，與系統(tǒng)的基本操作規(guī)則區(qū)分開來。它實現(xiàn)的方式是將核心功能模塊化，劃分成幾個獨立的進(jìn)程，各自運行，這些進(jìn)程被稱為服務(wù)。所有的服務(wù)進(jìn)程，都運行在不同的地址空間。

讓服務(wù)各自獨立，可以減少系統(tǒng)之間的耦合度，易于實現(xiàn)與除錯，也可以增進(jìn)可移植性。它可以避免單一組件失效，而造成整個系統(tǒng)崩潰，內(nèi)核只需要重啟這個組件，不至于影響其他服務(wù)器的功能，使系統(tǒng)穩(wěn)定度增加。同時業(yè)務(wù)功能可以視需要，抽換或新增某些服務(wù)進(jìn)程，使功能更有彈性。

就代碼數(shù)量來看，一般來說，因為功能簡化，核心系統(tǒng)使用的代碼比集成式系統(tǒng)更少。更少的代碼意味更少的潛藏程序bug。

微內(nèi)核架構(gòu)在使用時主要考慮兩個方面『核心系統(tǒng)』和『插件模塊』。應(yīng)用邏輯被劃分為獨立的『核心系統(tǒng)』和『插件模塊』，這樣就提供了良好的可擴(kuò)展性與靈活性，應(yīng)用的新特性和基礎(chǔ)業(yè)務(wù)邏輯也會被隔離。

核心系統(tǒng)通常是一個可以獨立運行的最小化模塊，操作系統(tǒng)（Windows NT、Mac OS X）就是這么實現(xiàn)的。從商業(yè)應(yīng)用的角度來看，核心系統(tǒng)為那些特定的場景、規(guī)則、復(fù)雜的條件判斷提供了通用的業(yè)務(wù)邏輯，而插件模塊則提供了更為具體的業(yè)務(wù)邏輯?？梢栽黾踊驍U(kuò)展核心系統(tǒng)以達(dá)到產(chǎn)生附加的業(yè)務(wù)邏輯的能力。

插件模塊通常是一個專業(yè)處理額外特性的獨立組件。通常，插件模塊之間是沒有依賴的，當(dāng)然你也可以創(chuàng)建一個依賴其他插件模塊的插件，但不管怎么樣，讓插件模塊之間可以彼此通訊又不產(chǎn)生依賴是一個很重要的問題。

核心系統(tǒng)需要知道每個插件的可用性并且知道如何獲取它們，一個通常的實現(xiàn)方式是使用一組注冊表。注冊表包括了每個插件的基本信息，包括名稱、數(shù)據(jù)規(guī)范、遠(yuǎn)程訪問協(xié)議（取決于插件模塊如何和核心系統(tǒng)進(jìn)行連接）以及其他自定義數(shù)據(jù)。比如百度網(wǎng)盤中用于上傳文件的上傳插件提供了插件名稱、數(shù)據(jù)規(guī)范（輸入、輸出數(shù)據(jù)）、數(shù)據(jù)格式（json、xml），如果這個插件是通過異步進(jìn)行加載的，那么還會有一個具體遠(yuǎn)程HTTP訪問協(xié)議地址。

插件模塊可以通過多種方式連接到核心系統(tǒng)，包括OSGI（open service gateway initiative）、消息機(jī)制、web服務(wù)以及點對點的綁定（對象實例化，既依賴注入）。使用何種方式主要取決于具體的應(yīng)用場景和特殊需求（單機(jī)部署、分布式部署），微內(nèi)核架構(gòu)默認(rèn)沒有要求具體的實現(xiàn)方式，但是必須保證插件模塊之間不能產(chǎn)生任何依賴。

插件模塊和核心系統(tǒng)之間的通信規(guī)范分為標(biāo)準(zhǔn)規(guī)范和自定義規(guī)范，自定義規(guī)范通常是指某個插件模塊是由第三方服務(wù)開發(fā)的。這種情況下，就需要在自定義規(guī)范和標(biāo)準(zhǔn)規(guī)范之間提供一個Adapter，這樣核心系統(tǒng)就不需要關(guān)心每個插件模塊的具體實現(xiàn)。在設(shè)計標(biāo)準(zhǔn)規(guī)范之前制定一個版本策略很重要。

核心系統(tǒng)提供了多種事件模式，主要包括常用的點對點模式、發(fā)布訂閱模式。同時，事件的類型分為全局（系統(tǒng)級）事件、系統(tǒng)內(nèi)部事件以及插件模塊內(nèi)部事件。由于點對點模式中發(fā)送者和接收者之間沒有依賴關(guān)系并且一條消息只對應(yīng)一個接收者，所以可以用作廣播全局（系統(tǒng)級）事件，比如調(diào)起某個插件模塊。而發(fā)布訂閱模式中訂閱者和發(fā)布者之間存在時間上的依賴性，可以用于系統(tǒng)內(nèi)部事件和插件模塊的內(nèi)部事件。此外，核心模塊也可以通過發(fā)布訂閱模式向外發(fā)布某些屬于業(yè)務(wù)基本操作規(guī)則的事件。

當(dāng)插件模塊注冊到核心系統(tǒng)之后，通過系統(tǒng)級事件可以調(diào)起具體的某插件模塊。此時就需要核心模塊提供屬于基本操作規(guī)則的接口供插件模塊使用，同樣的，插件模塊也必須按照通信規(guī)范提供運行入口(類似于java的Main方法)和數(shù)據(jù)規(guī)范(參數(shù)格式，返回的數(shù)據(jù)格式)，以此保障插件模塊可以在核心系統(tǒng)上正確運行。插件模塊是獨立于核心系統(tǒng)之外的，但是根據(jù)具體的需求（提供單純的數(shù)據(jù)服務(wù)、處理系統(tǒng)數(shù)據(jù)和信息）可能會需要操作核心模塊的系統(tǒng)服務(wù)做一些定制化功能，此時核心系統(tǒng)需要提供一個上下文對象（Context），且插件模塊與外部進(jìn)行交互只能通過此上下文對象。上下文對象提供了基礎(chǔ)操作（調(diào)起其他插件模塊、調(diào)起系統(tǒng)服務(wù)、獲取系統(tǒng)信息）的API和事件。

把前端系統(tǒng)當(dāng)成一個操作系統(tǒng)，業(yè)務(wù)基本操作的業(yè)務(wù)邏輯抽象成一個可以獨立運作的系統(tǒng)內(nèi)核，而不屬于業(yè)務(wù)基本操作的業(yè)務(wù)邏輯都當(dāng)成一個應(yīng)用程序，完成安裝、卸載、禁用、調(diào)用以及開機(jī)啟動等功能。

在功能越來越多，依賴越來越負(fù)責(zé)的大型前端系統(tǒng)中，如果在項目初期沒有很好地考慮后期兼容的靈活性、擴(kuò)展性以及彈性，很容易出現(xiàn)項目難以維護(hù)或者誰都不想碰的尷尬場面，所以初期的設(shè)計很重要。

目前的大型前端單頁面系統(tǒng)使用的都是根據(jù)業(yè)務(wù)劃分獨立組件，進(jìn)行解耦和復(fù)用，最后通過組件進(jìn)行堆疊、編譯、上線。這樣雖然完成依賴良好的組件化設(shè)計考慮到了系統(tǒng)的擴(kuò)展性和靈活性以及彈性，但是整個系統(tǒng)還是緊緊綁在一起的，并沒有根據(jù)基礎(chǔ)業(yè)務(wù)和附加業(yè)務(wù)進(jìn)行很好的拆分。當(dāng)然很多優(yōu)秀的前端工程師也考慮到了這一方面，提出來微前端的概念。不過微前端還是一個比較新的技術(shù)概念，沒有經(jīng)過很多大型前端系統(tǒng)的實踐。而微內(nèi)核架構(gòu)已經(jīng)在操作系統(tǒng)和很多的產(chǎn)品的后端服務(wù)及前端APP中經(jīng)過了很多的實踐。

上面提到核心模塊是一個可以獨立運行起來，包含系統(tǒng)基本操作規(guī)則的最小化模塊。沒有任何插件模塊依然可以正常運行并處理基本的業(yè)務(wù)邏輯，所以在大型前端系統(tǒng)中將基礎(chǔ)頁面以及基礎(chǔ)功能多帶帶包裝起來，組成一個最小化的模塊，稱之為core system。而這個core system可以通過包方式在多個系統(tǒng)間進(jìn)行復(fù)用(NPM、bower、bundle、js chunk)。同時，將那些和業(yè)務(wù)相關(guān)的操作按照類型和場景封裝為多個系統(tǒng)服務(wù)，并掛載（依賴注入）到核心系統(tǒng)中，稱之為system service。需要注意的是core system可操作system service，而system service不可操作core system。

此外，core system根據(jù)具體的模塊規(guī)范（AMD、CMD、CommonJS、ESM、SystemJS、UMD）向外部暴露了可交互的API和事件，稱之為標(biāo)準(zhǔn)接口。后續(xù)在編寫插件模塊時要嚴(yán)格按照標(biāo)準(zhǔn)接口進(jìn)行開發(fā)。

插件模塊是一個獨立于核心系統(tǒng)的專業(yè)處理不屬于系統(tǒng)基本操作的業(yè)務(wù)的模塊（組件），比如網(wǎng)盤中的上傳、下載、分享等功能。每個插件模塊必須遵照定義好的標(biāo)準(zhǔn)接口和通信規(guī)范進(jìn)行開發(fā)，而且每個插件模塊都是相互獨立的，所以沒有對每個插件的實現(xiàn)細(xì)節(jié)做過多要求，如A插件模塊使用React開發(fā)，B插件模塊使用Vue開發(fā)，C模塊使用jQuery開發(fā)。

每個插件模塊都應(yīng)該提供一個包含本插件模塊簽名信息（Mainfest）的JSON文件，簽名信息包括了這個插件的名稱、數(shù)據(jù)規(guī)范、依賴、遠(yuǎn)程訪問地址（異步加載的js下載地址）和其他自定義字段。在前端加載核心系統(tǒng)時將該Mainfest文件注冊進(jìn)去，完成核心系統(tǒng)和插件模塊的連接。

每個插件模塊都應(yīng)該提供一個統(tǒng)一名稱的運行入口，比如start方法。也可以按照標(biāo)準(zhǔn)接口提供插件的生命周期事件，方便更細(xì)粒度的控制。

每個插件都提供了各自的Mainfest簽名文件和可執(zhí)行文件（JS文件、CSS文件）。所以當(dāng)服務(wù)器接收到瀏覽器請求時可以將所要求的插件Manifest進(jìn)行merge，合并成一個大的JSON結(jié)構(gòu)，然后返回給瀏覽器。瀏覽器接收后，執(zhí)行核心系統(tǒng)并注冊Manfiest信息，然后啟動。在注冊過程中可以按照需求完成開機(jī)啟動（默認(rèn)執(zhí)行）、預(yù)加載以及后臺運行等不同類型的操作。

在業(yè)務(wù)邏輯和插件內(nèi)部邏輯中可以能存在調(diào)起其他插件模塊的需求，由于插件模塊之間不產(chǎn)生依賴并且獨立于核心系統(tǒng)，所以無法直接進(jìn)行調(diào)起。不過由于注冊表和點對點事件模式的存在，可以通過核心系統(tǒng)向外暴露的API傳入插件名稱和組、插件模塊ID等信息進(jìn)行調(diào)起。在調(diào)起之前先判斷該插件在是否已注冊，是否已加載（同步加載、異步加載），是否為單例和互斥，參數(shù)信息和數(shù)據(jù)格式，保證它可以正確的調(diào)起。

在插件運行過程中出現(xiàn)異常時，通過系統(tǒng)級事件通知核心模塊。核心模塊根據(jù)簽名信息中的標(biāo)識選擇重啟或關(guān)閉該插件模塊。

在復(fù)雜的前端系統(tǒng)中同一個功能可能會存在過個入口的情況，比如上傳、下載、分享等功能都是通過不同位置的按鈕點擊進(jìn)行調(diào)起。通常，將具體功能（插件模塊）和插件模塊入口的UI展示進(jìn)行隔離。首先，在基礎(chǔ)頁面結(jié)構(gòu)中按照需求進(jìn)行分塊，分成不同的功能塊，如菜單欄、右鍵菜單、列表項、右側(cè)區(qū)域、左側(cè)區(qū)域，并為這些區(qū)域定義唯一的名稱和ID。在需要進(jìn)行入口展示的插件模塊的Manifest中，標(biāo)識入口的區(qū)域和展示方式（按鈕、圖片、引導(dǎo)塊、菜單項、下拉菜單）。

核心系統(tǒng)在注冊表注冊完畢后，解析那些需要展示入口的的字段并交給專門渲染插件模塊入口的系統(tǒng)服務(wù)，這樣就通過配置完成了多入口的管理，在后續(xù)需求變動和修改時，只需要更改Manifest文件即可，更加完善了系統(tǒng)的擴(kuò)展性、靈活性、彈性。

架構(gòu)是獨立于框架和類庫的存在。

微內(nèi)核架構(gòu)的核心就是使業(yè)務(wù)的基本操作和專業(yè)處理額外特性的操作相隔離，提高系統(tǒng)的擴(kuò)展性、靈活性和彈性。所以在技術(shù)選型時我們需要考慮三個方面：核心系統(tǒng)、系統(tǒng)服務(wù)、插件模塊。

核心系統(tǒng)通常包含一個項目所需要的基本功能，包括基本的展示頁面、交互操作、業(yè)務(wù)處理，代碼量通常很少；系統(tǒng)服務(wù)提供業(yè)務(wù)處理的通用功能，比如列表操作、彈框、提示、異步化接口處理等，通常將系統(tǒng)中通用的需求抽象到這一層中；所以，這兩個方面可以使用目前常見的react或vue通過webpack工具進(jìn)行規(guī)范化開發(fā)，但如何向外部暴露核心系統(tǒng)的API和事件給插件模塊調(diào)用是一個十分重要的問題。

插件模塊更傾向于一個專業(yè)處理額外特性的lib庫，所以推薦使用rollup或者webpack的lib模式進(jìn)行開發(fā)和打包，產(chǎn)出一個『干凈』的bundle（也可以發(fā)布到NPM中，實現(xiàn)獨立發(fā)布和維護(hù)）。需要注意的是，如果這個bundle按照定義好的標(biāo)準(zhǔn)規(guī)范進(jìn)行開發(fā)，那么它可以在任意一個微內(nèi)核架構(gòu)下運行，達(dá)到跨系統(tǒng)的能力。就像按照X86規(guī)范編寫的程序可以在任意一個X86架構(gòu)的系統(tǒng)上運行一樣。

一、插件模塊開發(fā)階段

方案一：source code
插件模塊的代碼放置在一個根文件夾中，通過源代碼進(jìn)行開發(fā)和編譯。每次更改后通過rollup或webpack產(chǎn)出一個bundle與Manifest文件，然后將它們上線更新即可。

這種模式下，插件模塊的代碼更新后，對應(yīng)的Manifest文件也會更新，所以核心系統(tǒng)加載到插件模塊也會被更新，不需要基礎(chǔ)業(yè)務(wù)邏輯執(zhí)行任何操作。
優(yōu)點：不需要更新并上線基礎(chǔ)業(yè)務(wù)代碼。
缺點：沒有版本號的管理功能以及不方便測試。

方案二：npm install
插件模塊發(fā)布到github、gitlab等其他托管平臺中，通過npm進(jìn)行安裝到基礎(chǔ)業(yè)務(wù)邏輯中。插件模塊每次更改后需要重新發(fā)布到托管平臺，并在需要在業(yè)務(wù)邏輯中更新版本號重新執(zhí)行npm install xxx，然后重新編譯業(yè)務(wù)代碼進(jìn)行上線。

插件模塊更新后，不需要像方案一那樣上線插件模塊。而是更新業(yè)務(wù)邏輯的依賴，安裝最新版本的插件模塊。
優(yōu)點：可以通過版本號加載不同的階段的插件模塊以及方便測試。
缺點：更改后需要重新安裝插件模塊，并對依賴此插件模塊的業(yè)務(wù)邏輯重新進(jìn)行編譯和上線。回歸成本大，除了回歸插件模塊還要回歸其他基礎(chǔ)業(yè)務(wù)邏輯（當(dāng)然也可以像方案一那樣做，但是這樣就拋棄了npm的最大優(yōu)點 -> 版本號管理）。

二、獲取插件模塊的Manifest簽名信息

方案一：服務(wù)器渲染直出到HTML中
服務(wù)器收到瀏覽器的頁面請求時，將該頁面需要的插件模塊的Manifest簽名文件進(jìn)行Merge操作，然后統(tǒng)一輸出到HTML中并返回給瀏覽器。

方案二：通過異步化獲取
通過script標(biāo)簽的async和defer功能或AJAX，異步從服務(wù)器獲取Merge之后的Manifest簽名信息集合。

三、遠(yuǎn)程訪問協(xié)議

核心系統(tǒng)調(diào)起插件模塊時，可以通過插件聲明的遠(yuǎn)程訪問協(xié)議的HTTP地址，進(jìn)行異步加載。

方案一：Manifest簽名文件
在Manifest簽名信息中放置插件模塊的遠(yuǎn)程訪問協(xié)議，比如上傳插件模塊的簽名示例：

{
    // 插件名稱
    "name": "upload",
    // 組
    "group": "com.xxx.xxx",
    // 預(yù)加載插件模塊資源
    "preload": true,
    // 數(shù)據(jù)規(guī)范，要求輸入的參數(shù)
    "arguments": {
        // 核心系統(tǒng)提供的上下文對象
        "ctx": {
            "type": "Object",
            "required": true
        },
        // 需要上傳的文件信息
        "file": {
            "type": "Object",
            "required": false
        }
    },
    // 遠(yuǎn)程訪問協(xié)議
    "entrance": "http://www.a.com/static/plugin-bundles/upload-0.0.1.min.js"
}

方案二：異步化接口 + import()

該方案是系統(tǒng)插件模塊的遠(yuǎn)程訪問協(xié)議不放置在插件模塊的Manifest中，而是額外通過異步化接口請求得到遠(yuǎn)程訪問協(xié)議。然后通過webpack提供的require.ensure()或esm的import()加載插件資源。

// ctx為核心系統(tǒng)上下文對象
ctx.loadPlugInAdapter = (pluginName, group) => {
    // 通過接口請求上傳插件模塊的遠(yuǎn)程訪問協(xié)議
    fetchEntrance(pluginName, group).then(url => {
        // 核心系統(tǒng)執(zhí)行插件模塊
        ctx.invoke(pluginName, url);
    });
}

// 調(diào)起插件模塊
ctx.loadPlugInAdapter("upload", "com.xxx.xxx");

架構(gòu)和框架是獨立的，本文僅僅是提出一種架構(gòu)思路，而且這個架構(gòu)也在百度的某款用戶量很大的復(fù)雜前端產(chǎn)品中得以應(yīng)用?；谶@一套彈性架構(gòu)并結(jié)合Vue/React的現(xiàn)代化開發(fā)理念，可以很好的完成高復(fù)雜度的前端系統(tǒng)。希望本文可以給你們提供了除微前端之外的構(gòu)建高彈性前端系統(tǒng)的另外一種思路。