作者 | 馬超
出品 | CSDN（ID：CSDNnews）
當鴻蒙OS宣佈開源的時候，各種空洞的炒作，幾乎把國產操作系統的技術本質掩蓋了，雖然筆者沒親眼見過鴻蒙的代碼，也沒用方舟成功編譯什麼程序，不過當華為官宣鴻蒙將使用微內核的時候其實這款OS的風格就已經確定了，因為這就是內核的價值和意義。
記得十幾年前筆者剛剛畢業，初次進入嵌入式開發的圈子，那時總感覺操作系統距離我很遠，甚至有些高不可攀。
當時看到CSDN論壇上各種有關WINCE、MINIGUI等嵌入式OS的發貼時，那些生硬的代碼真是給我當時還年輕的心靈留下了巨大的陰影，不過這十年來雖然工作和嵌入式漸行漸遠，但是不斷總結經驗回頭來看，感覺操作內核的設計並不是一個純數學或者技術的建模過程，甚至還反應了我們日常生活中的很多道理。
在科技界有一句名言“如果你無法簡潔的表達你的想法，那隻說明你還不夠了解它”，所以經過了這些年的沉澱，筆者嘗試使用最通俗的語言來向大家解釋，什麼是內核、什麼又是微內核，閱讀本文不需要讀者具備什麼操作系統的知識。
宏內核vs微內核的基礎邏輯
上世紀90年代，微內核操作Minix的作者Tanenbaum與微內核操作系統Linux的作者Linus，曾經有一段非常著名的論戰，(具體鏈接: https://www.oreilly.com/openbook/opensources/book/appa.html)，這裡筆者無意全文翻譯，只是想說即便是Linus這樣的大神級人物也難免會陷入誰優誰劣的口水仗之中，而普通人士可能更難免俗，所以我們先擱置優劣的爭議，先直觀來感受宏內核與微內核的架構圖是什麼樣子的。
宏內核架構圖
微內核架構圖
簡單的講宏內核就是操作系統是個大管家，幾乎包辦一切，用戶應用程序的需求直接向內核提出就行；微內核更像一個代理人，幾乎所有的驅動、文件系統全部運行在與用戶應用程序平級的用戶模式下。
內核類型的簡單類比
為了讓讀者理解起來更方便，接下來讓我們做一個比較簡單的類比，如果把操作系統看成一家公司，而宏內核的特點是用戶請求直達內核，內核統一安排執行，這代表此公司使用扁平化的管理架構，而微內核的操作系統中則需要設立很多如驅動，文件系統等部門，這顯示公司使用制度化、等級化的管理架構。
簡而之宏內核代表的是層次簡單的扁平化管理風格，微內核則代表多部門的制度化管理風格。
基礎概念釋義
上下文及上下文切換：這個名詞經常出現在各類操作系統的書籍當中，還是以公司為例，上下文就代表了處理一個項目所需要的相關材料、文件，而上下文切換則代表這些材料文件在不同部門（進程）或者領導（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就提出了用戶協議棧的概念，其本質邏輯就是成立一個直屬某一總經理的特別行動小組，這一小組的所有任務全部在此總經理的領導下進行，從而避免跨總經理間的上下文切換以提高效率，其實這種方案也有一定侷限性，比如出現單個總經理根本管不過來特別組的情況，該如何優化其實還是有待探索。
後記
其實本文應該是國慶當天完成的，只是筆者又花了一天時間，讓妻子來讀此文指出晦澀難懂的地方，修改後才最終完成的。所以自我感覺本文通俗性應該還好，如果有問題想提歡迎在文後留言。
前段時間鴻蒙剛出的時候引發各方論戰，支持華為的說鴻蒙是創世之舉，反對的則稱此為PPT開源。
而筆者認為口水戰是沒有意義的，正如此文所言，微內核和宏內核其實各有應用場景，各有優劣，誰也碾壓不了誰。
可能很多人覺得首先要把方向搞對，以免後面直接被淘汰。不過這些年來堪稱被淘汰的技術大多是如Silver light、XNA等應用層的開發框架，而底層的操作系統內核真是應了那句“太陽底下沒什麼新鮮事”的諺語，幾乎不會存在出現什麼新理念能直接把之前的設計完全乾趴的可能。
其實華為的鴻蒙LITEOS早已被放到Github上（https://github.com/Awesome-HarmonyOS/HarmonyOS）了，那麼LiteOS的哪些代碼是屬於符合鴻蒙OS的設計理念可能會被照搬，哪些不符合需要重寫，就做為思考題留給各位讀者吧。
今天恰是筆者擔任CSDN嵌入式大區版主的十週年紀念日，所以不再秀什麼代碼了，只是單純向大家打開心扉，談一下做為一個用慣純C的嵌入式老兵，對於操作系統內核的一點思考，希望能給各位讀者尤其是那些對於操作系統不甚瞭解的讀者以更多收穫。
【END】
CSDN 博客誠邀入駐啦！
本著共享、協作、開源、技術之路我們共同進步的準則，
只要你技術夠乾貨，內容夠紮實，分享夠積極，
歡迎加入 CSDN 大家庭！
掃描下方二維碼，即刻加入吧！
閱讀更多 CSDN 的文章
