當鴻蒙OS宣布開源的時候，各種空洞的炒作，幾乎把國產操作系統的技術本質掩蓋了，雖然筆者沒親眼見過鴻蒙的代碼，也沒用方舟成功編譯什么程序，不過當華為官宣鴻蒙將使用微內核的時候其實這款OS的風格就已經確定了，因為這就是內核的價值和意義。
記得十幾年前筆者剛剛畢業，初次進入嵌入式開發的圈子，那時總感覺操作系統距離我很遠，甚至有些高不可攀。當時看到CSDN論壇上各種有關WINCE、MINIGUI等嵌入式OS的發貼時，那些生硬的代碼真是給我當時還年輕的心靈留下了巨大的陰影，不過這十年來雖然工作和嵌入式漸行漸遠，但是不斷總結經驗回頭來看，感覺操作內核的設計并不是一個純數學或者技術的建模過程，甚至還反應了我們日常生活中的很多道理。
在科技界有一句名言“如果你無法簡潔的表達你的想法，那只說明你還不夠了解它”，所以經過了這些年的沉淀，筆者嘗試使用最通俗的語言來向大家解釋，什么是內核、什么又是微內核，閱讀本文不需要讀者具備什么操作系統的知識。
宏內核vs微內核的基礎邏輯
上世紀90年代，微內核操作Minix的作者Tanenbaum與微內核操作系統Linux的作者Linus，曾經有一段非常著名的論戰，(具體鏈接:https://www.oreilly.com/openbook/opensources/book/appa.html),這里筆者無意全文翻譯，只是想說即便是Linus這樣的大神級人物也難免會陷入誰優誰劣的口水仗之中，而普通人士可能更難免俗，所以我們先擱置優劣的爭議，先直觀來感受宏內核與微內核的架構圖是什么樣子的。

圖1.宏內核架構圖

圖1.微內核架構圖
簡單的講宏內核就是操作系統是個大管家，幾乎包辦一切，用戶應用程序的需求直接向內核提出就行；微內核更向一個代理人，幾乎所有的驅動、文件系統全部運行在與用戶應用程序平級的用戶模式下。
內核類型的簡單類比
為了讓讀者理解起來更方便，接下來讓我們做一個比較簡單的類比，如果把操作系統看成一家公司，而宏內核的特點是用戶請求直達內核，內核統一安排執行，這代表此公司使用扁平化的管理架構，而微內核的操作系統中則需要設立很多如驅動，文件系統等部門，這顯示公司使用制度化、等級化的管理架構。
簡而之宏內核代表的是層次簡單的扁平化管理風格，微內核則代表多部門的制度化管理風格。
基礎概念釋義
上下文及上下文切換：這個名詞經常出現在各類操作系統的書籍當中，還是以公司為例，上下文就代表了處理一個項目所需要的相關材料、文件，而上下文切換則代表這些材料文件在不同部門（進程）或者領導（CPU）之間的流轉。
狀態保持（快照）及恢復：假設這樣一種場景，我正在領導的辦公室中匯報工作，此時外面另一個人有更重要的事情向領導匯報，由于涉及權限問題需要我先退出他的辦公室，那么我在退出前需要做一次狀態快照，以便領導處理完緊急事務后可以繼續處理我的工作。這就是計算機中狀態保持與恢復的過程。
基本推論
運行效率宏內核更優：相信大家都有過跑部門跑公章的經歷，很多時間、精力都浪費在了部門（進程）之間的上下文切換(上文已經釋義)中了，微內核在效率方面肯定是處于劣勢的，所以目前的主流操作系統如Linux和Windows本質上使用的都是宏內核，當然有讀者可能會提出Windows使用的是混合內核，不過這種混合內核也是以效率優先的扁平化架構，本質上還是宏內核。
宏內核vs微內核誰更安全
有關安全性的比較，其實僅憑直覺就能得到正確結論。正如各位日常所見，正規軍隊采用的都是“下級服從上級、命令絕對執行”的管理方式，而只有游擊隊才搞會扁平化管理的。其中邏輯也不難理解，扁平化雖然能有比較高的效率，但是難免會在身份鑒別、數據傳遞的過程中出現紕漏，從而給入侵者可稱之機。
而目前已有部分宏內核如sel4（Github地址：https://github.com/seL4/seL4）已經被形式化證明無誤（論文地址：http://ts.data61.csiro.au/publications/nicta_full_text/955.pdf），
對于sel4的形式化證明筆者在這里多聊幾句，從本質上來說sel4的內核代碼只有1萬行左右，而linux的內核代碼已經突破了2000萬行，所以微內核的sel4由于其代碼數量較小，所以研究人員干脆將其內核抽象成一個有限狀態機，進而證明在狀態遷移與躍遷的過程中都不會發生會被惡意利用的漏洞，從而保證整個體系的安全。當然這個安全也有前提：
一、不有有內鬼：即生成內核的編譯器、鏈接器與操作運行的硬件環境如DMA等設備不能被提前惡意植入后門。
二、不能有密碼泄露：形式化驗證只能保證制度體系本身不出問題，如果用戶將自身密碼泄露那系統是無法防范的。
不過我們也知道宏內核的操作系統尤其是Windows，經常會暴出安全漏洞，用戶在沒有泄露密碼且沒使用問題硬件的情況下，還是會遭到被黑客入侵。所以在安全性對比上微內核可謂優勢明顯。
宏內核vs微內核誰實時性強
這個問題的答案可能與讀者的第一反應不同，效率更優的宏內核在實時性方面的表現其實不如微內核。那些對于實時性要求極高的軍用操作系統（如vxWorks等）使用的都是微內核架構。
請想象這樣一個場景，假如我是公司的銷售部負責人，正在向總經理匯報明年的銷售計劃，這時總經理狀態一般辦公室屏蔽來訪，手機屏蔽來電，專門處理我的匯報，恰在此時讀者做為戰略部負責人帶著阿里即將收購公司的消息，來到總經理辦公室門口，請求匯報。假設此時有關阿里收購匯報的優先級是高于其它所有工作的優先級，所以總經理會把我匯報的內容做一下狀態保持（快照），盡快安排戰略部負責人進來匯報。
由于宏內核的扁平化架構，幾乎所有請求都是直達總經理的，所以總經理對于來訪及來電的屏蔽時間就會變得不可控，而反觀微內核此時多部門的制度化架構優勢開始顯現，因為總經理一般只要核對一下其它部門的處理過程是否合規，然后簽名即可，因此微內核的最長屏蔽時間是可預期的。
So當我們在向下思考一層就會發現，制度化、流程化的微信核更能保證決策層在最短時間內就給最重要的任務予以響應。
宏內核vs微內核誰更適合多核處理器
其實目前微內核的回歸正好說明了微內核與多處理器的硬件平臺配合會更好。請想象這樣的場景,假如我是一家餐廳的外賣小哥，我向內核發送了回單位取餐的請求，這是內核會把這個請求拆解為兩個，一是我到達單位，狀態改為空閑的通知，二是幫我準備指定的菜品，如果這家餐廳規模很小只有一個總經理當然沒有任何問題，不過如果餐廳有兩個決策人（雙核），那么我到達的通知可能先發給了總經理1，而為我準備菜品時總經理1（核心1）有其它任務了，所以需要總經理2（核心2）來安排協調了，這時就需要在總經理1和總經理2進行上下文切換才可以滿足我的需求了。而微內核在內核下面設計有部門（服務進程）的架構，就幾乎不存在宏內核在核心間調研上下文切換的問題。所以在總體來說，宏內核會在CPU核心間不斷進行上下文切換，而微內核則不斷在部門（進程）間進行上下文切換。
當然了宏內核針對多處理器時代也不是完全束手無策，比如Linux就提出了用戶協議棧的概念，其本質邏輯就是成立一個直屬某一總經理的特別行動小組，這一小組的所有任務全部在此總經理的領導下進行，從而避免跨總經理間的上下文切換以提高效率，其實這種方案也有一定局限性，比如出現單個總經理根本管不過來特別組的情況，該如何優化其實還是有待探索。