作業系統微核心和Dubbo微核心各自優缺點！

這篇文章藉著 Dubbo 來說說微核心這種設計思想，不會扯到 Dubbo 某個具體細節實現上，和 Dubbo 強相關的內容會在之後的文章寫到。所以今天的重點在微核心，而這個概念我最早是從作業系統那裡得知，不過作業系統的微核心和 Dubbo 相關的微核心又不太一樣。

Dubbo 的微核心廣義上的微核心，而作業系統只是針對核心實現。

我們先看看作業系統的微核心。

在維基百科上搜尋微核心出現的就是：

在電腦科學中，微核心(英語：Microkernel，μ-kernel)，是一種核心的設計架構，由儘可能精簡的程式所組成，以實現一個作業系統所需要的最基本功能，包括了底層的定址空間管理、執行緒管理、與程式間通訊。

這個詞條歸類在作業系統技術下，所以這裡的微核心指的就是作業系統的核心設計，與之對應的是單核心架構。

 就是單核心架構。

作業系統我們都知道它是一箇中間層，為我們管理底層的硬體資源，為上層服務提供介面。

提供程式管理、記憶體管理、檔案系統、程式通訊等功能。

像 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 的微核心是廣義上的，它的思想是：核心系統+外掛。

這個微核心說白了就是把不變的功能抽象出來稱為核心，把變動的功能作為外掛來擴充套件，符合開閉原則，更容易擴充套件、維護。

小霸王遊戲機大家都應該玩過，它的設計就可以認為是個微核心設計。

 

機體本身作為核心系統，遊戲片就是外掛。

我們想玩哪個遊戲就插哪個遊戲片，簡單便捷，不影響機體本身。

假設不把遊戲片抽象成外掛式，那是不是就難搞了?換個遊戲就成為難題了。

所以微核心架構的本質就是將變化的部分抽象成外掛，使得可以快速簡便地滿足各種需求又不影響整體的穩定性。

這就是微核心架構的精髓。

這裡再扣個細節，較個真(就是我個人的一點想法)。

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 說的不太準確，容易產生誤導。

當然這是文字上面的摳細節，核心概念都是一致的：抽象出核心，剝離變化為外掛。

這裡的微核心指的是廣義的微核心。

作為一個框架或者軟體，擴充套件性非常的重要。

因為一個框架、一個軟體的使用者千千萬，不同的人有不同的需求。

身為框架的維護者、軟體的開發者你有精力和能力滿足所有使用者的需求?

做夢，不存在的。

來感受一下?

所以做一個框架或者軟體，想要讓更多人使用，不僅自身提供的功能要全、效能要好、使用要簡單，讓使用者 DIY，做各種定製化也非常的關鍵!

Dubbo 的成功其實就離不開它的微核心設計，定製化開發在很多場景都要用到，畢竟都得稍加改造一番來滿足自己公司的一些特殊需求。

微核心看起來是很方便，但是設計起來就不方便了。

需要精心的設計，抽象出各種擴充套件點。

除了本身的功能還需要管理外掛的生命週期、外掛如何連線、如何通訊等。

有些還需要做沙箱隔離，防止外掛汙染整個系統等等，本來的內部函式呼叫變成了外掛間的通訊，反正設計起來是複雜了。

一般微核心適合用在框架的設計上，或者一些規則引擎的設計，只有複雜的會有很多變化的需求場景才需要用到微核心。

像一般簡單的專案，本來就一條直道走到底的那種就算了，不要瞎操作，等下秀折了腿。

微核心其實就是一種架構思想，可以是框架層面的，也可以細化到某個模組的設計。

歸根結底就是把變化封裝成外掛，可插拔，擁抱變化。

當然今天也提到了作業系統的微核心，這個和廣義上的微核心還是不太一樣的。

至於 Dubbo 的微核心就離不開它的 SPI，之後文章會深入寫一波，等我哈。