由一群儘可能將數量最小化的軟體程序組成，他們負責提供、實現一個作業系統所需要的各種機制和功能。這些最基礎的機制，包括了底層地址空間管理，線程管理，與進程間通訊。微內核架構在使用時主要考慮兩個方面『核心系統』和『插件模塊』。應用邏輯被劃分為獨立的『核心系統』和『插件模塊』，這樣就提供了良好的可擴展性與靈活性，應用的新特性和基礎業務邏輯也會被隔離。
一、核心系統
核心系統通常是一個可以獨立運行的最小化模塊，作業系統（Windows NT、Mac OS X）就是這麼實現的。從商業應用的角度來看，核心系統為那些特定的場景、規則、複雜的條件判斷提供了通用的業務邏輯，而插件模塊則提供了更為具體的業務邏輯。可以增加或擴展核心系統以達到產生附加的業務邏輯的能力。
二、插件模塊
插件模塊通常是一個專業處理額外特性的獨立組件。通常，插件模塊之間是沒有依賴的，當然你也可以創建一個依賴其他插件模塊的插件，但不管怎麼樣，讓插件模塊之間可以彼此通訊又不產生依賴是一個很重要的問題。
三、獲取插件模塊並判斷可用性
核心系統需要知道每個插件的可用性並且知道如何獲取它們，一個通常的實現方式是使用一組註冊表。註冊表包括了每個插件的基本信息，包括名稱、數據規範、遠程訪問協議（取決於插件模塊如何和核心系統進行連接）以及其他自定義數據。比如百度網盤中用於上傳文件的上傳插件提供了插件名稱、數據規範（輸入、輸出數據）、數據格式（json、xml），如果這個插件是通過異步進行加載的，那麼還會有一個具體遠程HTTP訪問協議地址。
四、連接到核心系統
插件模塊可以通過多種方式連接到核心系統，包括OSGI（open service gateway initiative）、消息機制、web服務以及點對點的綁定（對象實例化，既依賴注入）。使用何種方式主要取決於具體的應用場景和特殊需求（單機部署、分布式部署），微內核架構默認沒有要求具體的實現方式，但是必須保證插件模塊之間不能產生任何依賴。
五、通信規範
插件模塊和核心系統之間的通信規範分為標準規範和自定義規範，自定義規範通常是指某個插件模塊是由第三方服務開發的。這種情況下，就需要在自定義規範和標準規範之間提供一個Adapter，這樣核心系統就不需要關心每個插件模塊的具體實現。在設計標準規範之前制定一個版本策略很重要。
六、事件模式
核心系統提供了多種事件模式，主要包括常用的點對點模式、發布訂閱模式。同時，事件的類型分為全局（系統級）事件、系統內部事件以及插件模塊內部事件。由於點對點模式中發送者和接收者之間沒有依賴關係並且一條消息只對應一個接收者，所以可以用作廣播全局（系統級）事件，比如調起某個插件模塊。而發布訂閱模式中訂閱者和發布者之間存在時間上的依賴性，可以用於系統內部事件和插件模塊的內部事件。此外，核心模塊也可以通過發布訂閱模式向外發布某些屬於業務基本操作規則的事件。
七、接口設計
當插件模塊註冊到核心系統之後，通過系統級事件可以調起具體的某插件模塊。此時就需要核心模塊提供屬於基本操作規則的接口供插件模塊使用，同樣的，插件模塊也必須按照通信規範提供運行入口(類似於java的Main方法)和數據規範(參數格式，返回的數據格式)，以此保障插件模塊可以在核心系統上正確運行。插件模塊是獨立於核心系統之外的，但是根據具體的需求（提供單純的數據服務、處理系統數據和信息）可能會需要操作核心模塊的系統服務做一些定製化功能，此時核心系統需要提供一個上下文對象（Context），且插件模塊與外部進行交互只能通過此上下文對象。上下文對象提供了基礎操作（調起其他插件模塊、調起系統服務、獲取系統信息）的API和事件。
遠程訪問協議核心系統調起插件模塊時，可以通過插件聲明的遠程訪問協議的HTTP地址，進行異步加載。
方案一：Manifest籤名文件
在Manifest籤名信息中放置插件模塊的遠程訪問協議，比如上傳插件模塊的籤名示例：
方案二：異步化接口 + import()
該方案是系統插件模塊的遠程訪問協議不放置在插件模塊的Manifest中，而是額外通過異步化接口請求得到遠程訪問協議。然後通過webpack提供的require.ensure()或esm的import()加載插件資源。