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

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

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

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

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

就代碼數(shù)量來(lái)看，一般來(lái)說(shuō)，因?yàn)楣δ芎?jiǎn)化，核心系統(tǒng)使用的代碼比集成式系統(tǒng)更少。更少的代碼意味更少的潛藏程序bug。

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

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

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

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

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

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

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

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

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

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

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

上面提到核心模塊是一個(gè)可以獨(dú)立運(yùn)行起來(lái)，包含系統(tǒng)基本操作規(guī)則的最小化模塊。沒(méi)有任何插件模塊依然可以正常運(yùn)行并處理基本的業(yè)務(wù)邏輯，所以在大型前端系統(tǒng)中將基礎(chǔ)頁(yè)面以及基礎(chǔ)功能多帶帶包裝起來(lái)，組成一個(gè)最小化的模塊，稱之為core system。而這個(gè)core system可以通過(guò)包方式在多個(gè)系統(tǒng)間進(jìn)行復(fù)用(NPM、bower、bundle、js chunk)。同時(shí)，將那些和業(yè)務(wù)相關(guān)的操作按照類(lèi)型和場(chǎng)景封裝為多個(gè)系統(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ù)在編寫(xiě)插件模塊時(shí)要嚴(yán)格按照標(biāo)準(zhǔn)接口進(jìn)行開(kāi)發(fā)。

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

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

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

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

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

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

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

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

架構(gòu)是獨(dú)立于框架和類(lèi)庫(kù)的存在。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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