作業系統微內核和Dubbo微內核，有何不同？
你好，我是 yes。
在之前的文章已經提到了 RPC 的核心，想必一個 RPC 通訊大致的流程和基本原理已經清晰了。
這篇文章借著 Dubbo 來說說微內核這種設計思想，不會扯到 Dubbo 某個具體細節實現上，和 Dubbo 強相關的內容會在之後的文章寫到。
所以今天的重點在微內核，而這個概念我最早是從作業系統那裡得知，不過作業系統的微內核和 Dubbo 相關的微內核又不太一樣。
Dubbo 的微內核廣義上的微內核，而作業系統只是針對內核實現。
這麼說你肯定不清楚，別急，聽我慢慢道來。
我們先看看作業系統的微內核。
作業系統中的微內核
在維基百科上搜索微內核出現的就是：
在電腦科學中，微內核（英語：Microkernel，μ-kernel），是一種內核的設計架構，由儘可能精簡的程式所組成，以實現一個作業系統所需要的最基本功能，包括了底層的定址空間管理、執行緒管理、與進程間通訊。
這個詞條歸類在作業系統技術下，所以這裡的微內核指的就是作業系統的內核設計，與之對應的是宏內核架構。
Linux 就是宏內核架構。
作業系統我們都知道它是一個中間層，為我們管理底層的硬體資源，為上層服務提供介面。
提供進程管理、記憶體管理、文件系統、進程通訊等功能。
像 Linux 這樣的宏內核設計是把這些功能都作為內核來實現，而微內核則僅保留最基礎的功能。
比如就留下進程的管理、記憶體管理等，把文件管理等功能剝離出去，變成用戶空間的獨立進程來提供服務。
來看下這個維基百科上的這個圖應該就很清晰了。
宏內核中的一些功能在微內核架構上都被獨立到用戶態中，這樣內核程式碼量就少了，程式碼少了潛在的 bug 就少，出了問題也更容易排查。
系統也就更加穩定，不易奔潰，因為那些服務從內核中移除，在用戶空間運行著，如果出了故障，內核重啟這個服務就好了，不會像之前那樣整個內核 GG。
拿顯示卡驅動來說，出問題就藍屏，這要是微內核設計就可以重啟顯示卡驅動。
聽起來好像微內核很好啊？並不是，接下來就說說微內核的缺點。
首先是性能問題，因為很多功能作為獨立進程放到用戶空間運行了，所以宏內核時的函數調用就變成了進程間調用，涉及進程間的通訊，還會伴隨著內核態和用戶態的來回切換，我們知道這種上下文切換時比較耗時的。
這性能的問題就有點大了。
然後微內核設計沒那麼簡單，想要靈巧、減少耦合、提高可移植性就需要好好的設計，按照林納斯的話來說：「如果 GNU 內核(微內核架構)早在去年春天完成了，我壓根不會開始我的項目(Lniux)。」
GNU Hurd 採用微內核架構，設計過於精巧，研發速度緩慢，性能長期無法提升。
當年林納斯還和 Minix 的作者安德魯，對作業系統的宏內核和微內核的好壞進行了一波網路口水戰。
我們來回顧一下那段歷史，挺有意思的。
因為 AT&T 把 Unix 商業化了，大學不能免費使用 Unix，身為大學教授的安德魯為了教學自己搞了個作業系統，即 Minix。
當時的學術風潮是微內核架構，把核心功能模組化，劃分為幾個獨立的進程，運行在不同的地址空間提高了程式碼的可移植和系統的安全性。
所以 Minix 就是按微內核架構編寫的，當然還有上述提到的 GNU Hurd。
而林納斯那時候讀大學，他祖父送了他一台 Intel 80386，林納斯也看到了安德魯的教科書，根據書上的內容寫出了 Linux。
不過沒有按照微內核的設計，而是跟 Unix 一樣採用了宏內核架構。
安德魯教授看到了 Linux ，然後在 comp.os.Minix 上批評道：宏內核的設計有害的，Linux 內核耦合度太高，完全是為了 Intel 80386 而設計的，處理器架構進化很快的，作業系統應該都具備可移植性。
安德魯還提到：都1991年了還用宏內核來設計作業系統，這是一種巨大的退步。
林納斯在一天之後進行了反擊，他說 Minix 設計上有缺陷，從哲學和美學角度來看微內核確實好，但是你看 GUN Hurd 到現在還沒開發出來。
然後作業系統本來就依靠硬體的特性，所以內核本身不需要過度具備可移植性，應用程式的可移植性才重要，Linux 比 Minix 好移植多了。
而且 Linux 本來就是為我自己做的，所以契合 80386，如果要移植到別的平台，程式碼都是開源的(Minix 源碼當時得買)，想要的人自己做咯。
安德魯也做了一波回應：Minix 有局限性是因為我是教授，因為大部分學生都只能在低配的機器上使用，所以系統的硬體需求得足夠低，雖然你 Linux 是免費的，但是需要的硬體貴呀。
其實可以看到，兩者並沒有對宏內核和微內核的技術細節的進行深入探討，而是抓住對方的：你這 Minix 程式碼還要收費，你這 Linux 需要的硬體這麼貴來進行「攻擊」，所以稱之為口水戰。
反正口水戰之後雙方都沒有改變各自的設計，不過林納斯有引進微內核的思想來改進程式碼，也改善了可移植性。
微內核市面上設計成功的有 QNX，黑莓手機就是用這個作業系統，車用市場也幾乎都用 QNX 系統。
這手機很多年前我用過，當時覺得有點東西的。
宏內核的話就提個 Linux ，足夠了。
兩個架構都有成功的產品，所以還是取捨的問題，也沒有誰完全壓著誰。
再具體的就不深入了，今天的主角其實是廣義上的微內核。
Dubbo 中的微內核
Dubbo 的微內核是廣義上的，它的思想是：核心系統+插件。
這個微內核說白了就是把不變的功能抽象出來稱為核心，把變動的功能作為插件來擴展，符合開閉原則，更容易擴展、維護。
小霸王遊戲機大家都應該玩過，就長這樣的，它的設計就可以認為是個微內核設計。
機體本身作為核心系統，遊戲片就是插件。
我們想玩哪個遊戲就插哪個遊戲片，簡單便捷，不影響機體本身。
假設不把遊戲片抽象成插件式，那是不是就難搞了？換個遊戲就成為難題了。
所以微內核架構的本質就是將變化的部分抽象成插件，使得可以快速簡便地滿足各種需求又不影響整體的穩定性。
這就是微內核架構的精髓。
這裡再扣個細節，較個真（就是我個人的一點想法）。
Mark Richards 在 《Software Architecture Patterns》的微內核章節裡面提到
The core system of the microkernel architecture pattern traditionally contains only the minimal functionality required to make the system operational.
從字面意義來看，Mark 認為核心系統指的是可以獨立運行且提供基本功能的最小模組。
例如 vscode、idea、chrome 等設計就符合 Mark 認為的核心設計，核心系統提供基礎必備的功能，可以獨立運行。
像 vscode 核心就是編輯器，沒有插件也可以獨立運行，然後又有豐富的插件，來滿足一些特殊需求，擴展核心系統的功能。
這裡可能會讓人產生誤導，認為核心必須是能讓系統運行的最小功能模組。
我認為核心不一定需要獨立運行且提供基礎功能，能讓系統運行的最小組織模組也是核心。
兩個說法的差別在於：只有核心的話系統能否正常的運行。
vscode 沒有插件照樣能運行，能提供基本功能，而小霸王遊戲機沒有遊戲片那運行個寂寞，玩個球。
但是小霸王這種難道就不算微內核了嘛？
就我個人而言，把變與不變區分出來，把變化封裝成插件就稱為微內核設計。
像 Dubbo 能支援很多協議、各種負載均衡的擴展、集群的擴展等等，它自身的一些功能也是通過擴展點實現的，沒有插件也跑不了。
這樣的內核就像膠水，把各個插件結合起來最終提供服務，沒有插件這個系統就沒什麼意義。
所以我認為核心系統不一定需要能獨立運行，能讓系統運行的最小組織模組也是核心。。
因此我覺得 Mark 說的不太準確，容易產生誤導。
當然這是文字上面的摳細節，核心概念都是一致的：抽象出核心，剝離變化為插件。
微內核設計的好處
這裡的微內核指的是廣義的微內核。
作為一個框架或者軟體，擴展性非常的重要。
因為一個框架、一個軟體的使用者千千萬，不同的人有不同的需求。
身為框架的維護者、軟體的開發者你有精力和能力滿足所有用戶的需求？
做夢，不存在的。
有些 idea 你想都想不到。
比如我之前看到的 vscode 裡面有個「坤坤鼓勵師」插件，默認你程式碼寫一小時之後蔡徐坤來給你跳雞你太美，讓你休息休息……
來感受一下？
所以做一個框架或者軟體，想要讓更多人使用，不僅自身提供的功能要全、性能要好、使用要簡單，讓用戶 DIY，做各種訂製化也非常的關鍵！
Dubbo 的成功其實就離不開它的微內核設計，訂製化開發在很多場景都要用到，畢竟都得稍加改造一番來滿足自己公司的一些特殊需求。
當然也不是什麼都要微內核
微內核看起來是很方便，但是設計起來就不方便了。
需要精心的設計，抽象出各種擴展點。
除了本身的功能還需要管理插件的生命周期、插件如何連接、如何通訊等。
有些還需要做沙箱隔離，防止插件污染整個系統等等，本來的內部函數調用變成了插件間的通訊，反正設計起來是複雜了。
一般微內核適合用在框架的設計上，或者一些規則引擎的設計，只有複雜的會有很多變化的需求場景才需要用到微內核。
像一般簡單的項目，本來就一條直道走到底的那種就算了，不要瞎操作，等下秀折了腿。
最後
微內核其實就是一種架構思想，可以是框架層面的，也可以細化到某個模組的設計。
歸根結底就是把變化封裝成插件，可插拔，擁抱變化。
當然今天也提到了作業系統的微內核，這個和廣義上的微內核還是不太一樣的。
至於 Dubbo 的微內核就離不開它的 SPI，之後文章會深入寫一波，等我哈。
更多文章可看我的文章匯總：//github.com/yessimida/yes 歡迎 star !
我是 yes，從一點點到億點點，歡迎在看、轉發、留言，我們下篇見。
巨人的肩膀
//en.wikipedia.org/wiki/Microkernel
//en.wikipedia.org/wiki/Tanenbaum–Torvalds_debate
《Software Architecture Patterns》
