當鴻蒙OS宣布開源的時候，各種空洞的炒作，幾乎把國產(chǎn)操作系統(tǒng)的技術(shù)本質(zhì)掩蓋了，雖然筆者沒親眼見過鴻蒙的代碼，也沒用方舟成功編譯什么程序，不過當華為官宣鴻蒙將使用微內(nèi)核的時候其實這款OS的風格就已經(jīng)確定了，因為這就是內(nèi)核的價值和意義。

記得十幾年前筆者剛剛畢業(yè)，初次進入嵌入式開發(fā)的圈子，那時總感覺操作系統(tǒng)距離我很遠，甚至有些高不可攀。當時看到CSDN論壇上各種有關(guān)WINCE、MINIGUI等嵌入式OS的發(fā)貼時，那些生硬的代碼真是給我當時還年輕的心靈留下了巨大的陰影，不過這十年來雖然工作和嵌入式漸行漸遠，但是不斷總結(jié)經(jīng)驗回頭來看，感覺操作內(nèi)核的設(shè)計并不是一個純數(shù)學或者技術(shù)的建模過程，甚至還反應(yīng)了我們?nèi)粘Ｉ钪械暮芏嗟览怼?/p>

在科技界有一句名言“如果你無法簡潔的表達你的想法，那只說明你還不夠了解它”，所以經(jīng)過了這些年的沉淀，筆者嘗試使用最通俗的語言來向大家解釋，什么是內(nèi)核、什么又是微內(nèi)核，閱讀本文不需要讀者具備什么操作系統(tǒng)的知識。

宏內(nèi)核vs微內(nèi)核的基礎(chǔ)邏輯

上世紀90年代，微內(nèi)核操作Minix的作者Tanenbaum與微內(nèi)核操作系統(tǒng)Linux的作者Linus，曾經(jīng)有一段非常著名的論戰(zhàn)，(具體鏈接: https://www.oreilly.com/openbook/opensources/book/appa.html),這里筆者無意全文翻譯，只是想說即便是Linus這樣的大神級人物也難免會陷入誰優(yōu)誰劣的口水仗之中，而普通人士可能更難免俗，所以我們先擱置優(yōu)劣的爭議，先直觀來感受宏內(nèi)核與微內(nèi)核的架構(gòu)圖是什么樣子的。

圖1. 宏內(nèi)核架構(gòu)圖

圖1. 微內(nèi)核架構(gòu)圖

簡單的講宏內(nèi)核就是操作系統(tǒng)是個大管家，幾乎包辦一切，用戶應(yīng)用程序的需求直接向內(nèi)核提出就行；微內(nèi)核更向一個代理人，幾乎所有的驅(qū)動、文件系統(tǒng)全部運行在與用戶應(yīng)用程序平級的用戶模式下。

內(nèi)核類型的簡單類比

為了讓讀者理解起來更方便，接下來讓我們做一個比較簡單的類比，如果把操作系統(tǒng)看成一家公司，而宏內(nèi)核的特點是用戶請求直達內(nèi)核，內(nèi)核統(tǒng)一安排執(zhí)行，這代表此公司使用扁平化的管理架構(gòu)，而微內(nèi)核的操作系統(tǒng)中則需要設(shè)立很多如驅(qū)動，文件系統(tǒng)等部門，這顯示公司使用制度化、等級化的管理架構(gòu)。

簡而之宏內(nèi)核代表的是層次簡單的扁平化管理風格，微內(nèi)核則代表多部門的制度化管理風格。

基礎(chǔ)概念釋義

上下文及上下文切換：這個名詞經(jīng)常出現(xiàn)在各類操作系統(tǒng)的書籍當中，還是以公司為例，上下文就代表了處理一個項目所需要的相關(guān)材料、文件，而上下文切換則代表這些材料文件在不同部門（進程）或者領(lǐng)導（CPU）之間的流轉(zhuǎn)。

狀態(tài)保持（快照）及恢復：假設(shè)這樣一種場景，我正在領(lǐng)導的辦公室中匯報工作，此時外面另一個人有更重要的事情向領(lǐng)導匯報，由于涉及權(quán)限問題需要我先退出他的辦公室，那么我在退出前需要做一次狀態(tài)快照，以便領(lǐng)導處理完緊急事務(wù)后可以繼續(xù)處理我的工作。這就是計算機中狀態(tài)保持與恢復的過程。

基本推論

運行效率宏內(nèi)核更優(yōu)：相信大家都有過跑部門跑公章的經(jīng)歷，很多時間、精力都浪費在了部門（進程）之間的上下文切換(上文已經(jīng)釋義)中了，微內(nèi)核在效率方面肯定是處于劣勢的，所以目前的主流操作系統(tǒng)如Linux和Windows本質(zhì)上使用的都是宏內(nèi)核，當然有讀者可能會提出Windows使用的是混合內(nèi)核，不過這種混合內(nèi)核也是以效率優(yōu)先的扁平化架構(gòu)，本質(zhì)上還是宏內(nèi)核。

宏內(nèi)核vs微內(nèi)核 誰更安全

有關(guān)安全性的比較，其實僅憑直覺就能得到正確結(jié)論。正如各位日常所見，正規(guī)軍隊采用的都是“下級服從上級、命令絕對執(zhí)行”的管理方式，而只有游擊隊才搞會扁平化管理的。其中邏輯也不難理解，扁平化雖然能有比較高的效率，但是難免會在身份鑒別、數(shù)據(jù)傳遞的過程中出現(xiàn)紕漏，從而給入侵者可稱之機。

而目前已有部分宏內(nèi)核如sel4（Github地址：https://github.com/seL4/seL4）已經(jīng)被形式化證明無誤（論文地址：http://ts.data61.csiro.au/publications/nicta_full_text/955.pdf），

對于sel4的形式化證明筆者在這里多聊幾句，從本質(zhì)上來說sel4的內(nèi)核代碼只有1萬行左右，而linux的內(nèi)核代碼已經(jīng)突破了2000萬行，所以微內(nèi)核的sel4由于其代碼數(shù)量較小，所以研究人員干脆將其內(nèi)核抽象成一個有限狀態(tài)機，進而證明在狀態(tài)遷移與躍遷的過程中都不會發(fā)生會被惡意利用的漏洞，從而保證整個體系的安全。當然這個安全也有前提：

一、不有有內(nèi)鬼：即生成內(nèi)核的編譯器、鏈接器與操作運行的硬件環(huán)境如DMA等設(shè)備不能被提前惡意植入后門。

二、不能有密碼泄露：形式化驗證只能保證制度體系本身不出問題，如果用戶將自身密碼泄露那系統(tǒng)是無法防范的。

不過我們也知道宏內(nèi)核的操作系統(tǒng)尤其是Windows，經(jīng)常會暴出安全漏洞，用戶在沒有泄露密碼且沒使用問題硬件的情況下，還是會遭到被黑客入侵。所以在安全性對比上微內(nèi)核可謂優(yōu)勢明顯。

宏內(nèi)核vs微內(nèi)核 誰實時性強

這個問題的答案可能與讀者的第一反應(yīng)不同，效率更優(yōu)的宏內(nèi)核在實時性方面的表現(xiàn)其實不如微內(nèi)核。那些對于實時性要求極高的軍用操作系統(tǒng)（如vxWorks等）使用的都是微內(nèi)核架構(gòu)。

請想象這樣一個場景，假如我是公司的銷售部負責人，正在向總經(jīng)理匯報明年的銷售計劃，這時總經(jīng)理狀態(tài)一般辦公室屏蔽來訪，手機屏蔽來電，專門處理我的匯報，恰在此時讀者做為戰(zhàn)略部負責人帶著阿里即將收購公司的消息，來到總經(jīng)理辦公室門口，請求匯報。假設(shè)此時有關(guān)阿里收購匯報的優(yōu)先級是高于其它所有工作的優(yōu)先級，所以總經(jīng)理會把我匯報的內(nèi)容做一下狀態(tài)保持（快照），盡快安排戰(zhàn)略部負責人進來匯報。

由于宏內(nèi)核的扁平化架構(gòu)，幾乎所有請求都是直達總經(jīng)理的，所以總經(jīng)理對于來訪及來電的屏蔽時間就會變得不可控，而反觀微內(nèi)核此時多部門的制度化架構(gòu)優(yōu)勢開始顯現(xiàn)，因為總經(jīng)理一般只要核對一下其它部門的處理過程是否合規(guī)，然后簽名即可，因此微內(nèi)核的最長屏蔽時間是可預期的。

So當我們在向下思考一層就會發(fā)現(xiàn)，制度化、流程化的微信核更能保證決策層在最短時間內(nèi)就給最重要的任務(wù)予以響應(yīng)。

宏內(nèi)核vs微內(nèi)核 誰更適合多核處理器

其實目前微內(nèi)核的回歸正好說明了微內(nèi)核與多處理器的硬件平臺配合會更好。請想象這樣的場景,假如我是一家餐廳的外賣小哥，我向內(nèi)核發(fā)送了回單位取餐的請求，這是內(nèi)核會把這個請求拆解為兩個，一是我到達單位，狀態(tài)改為空閑的通知，二是幫我準備指定的菜品，如果這家餐廳規(guī)模很小只有一個總經(jīng)理當然沒有任何問題，不過如果餐廳有兩個決策人（雙核），那么我到達的通知可能先發(fā)給了總經(jīng)理1，而為我準備菜品時總經(jīng)理1（核心1）有其它任務(wù)了，所以需要總經(jīng)理2（核心2）來安排協(xié)調(diào)了，這時就需要在總經(jīng)理1和總經(jīng)理2進行上下文切換才可以滿足我的需求了。而微內(nèi)核在內(nèi)核下面設(shè)計有部門（服務(wù)進程）的架構(gòu)，就幾乎不存在宏內(nèi)核在核心間調(diào)研上下文切換的問題。所以在總體來說，宏內(nèi)核會在CPU核心間不斷進行上下文切換，而微內(nèi)核則不斷在部門（進程）間進行上下文切換。

當然了宏內(nèi)核針對多處理器時代也不是完全束手無策，比如Linux就提出了用戶協(xié)議棧的概念，其本質(zhì)邏輯就是成立一個直屬某一總經(jīng)理的特別行動小組，這一小組的所有任務(wù)全部在此總經(jīng)理的領(lǐng)導下進行，從而避免跨總經(jīng)理間的上下文切換以提高效率，其實這種方案也有一定局限性，比如出現(xiàn)單個總經(jīng)理根本管不過來特別組的情況，該如何優(yōu)化其實還是有待探索。

編輯：hfy