1. 程式人生 > >作業系統微核心和Dubbo微核心,有何不同?

作業系統微核心和Dubbo微核心,有何不同?

你好,我是 yes。 在之前的文章已經提到了 RPC 的核心,想必一個 RPC 通訊大致的流程和基本原理已經清晰了。 這篇文章藉著 Dubbo 來說說微核心這種設計思想,不會扯到 Dubbo 某個具體細節實現上,和 Dubbo 強相關的內容會在之後的文章寫到。 所以今天的重點在**微核心**,而這個概念我最早是從作業系統那裡得知,不過作業系統的微核心和 Dubbo 相關的微核心又不太一樣。 **Dubbo 的微核心廣義上的微核心,而作業系統只是針對核心實現。** 這麼說你肯定不清楚,別急,聽我慢慢道來。 我們先看看作業系統的微核心。 ![](https://img-blog.csdnimg.cn/img_convert/b20583a9d282767089bf280256690ee0.png) ## 作業系統中的微核心 在維基百科上搜索微核心出現的就是: > 在電腦科學中,微核心(英語:Microkernel,μ-kernel),是一種核心的設計架構,由儘可能精簡的程式所組成,以實現一個作業系統所需要的最基本功能,包括了底層的定址空間管理、執行緒管理、與程序間通訊。 這個詞條歸類在作業系統技術下,所以這裡的微核心指的就是作業系統的核心設計,與之對應的是巨集核心架構。 Linux 就是巨集核心架構。 作業系統我們都知道它是一箇中間層,為我們管理底層的硬體資源,為上層服務提供介面。 提供程序管理、記憶體管理、檔案系統、程序通訊等功能。 像 Linux 這樣的巨集核心設計是把這些功能都作為核心來實現,而**微核心則僅保留最基礎的功能。** 比如就留下程序的管理、記憶體管理等,把檔案管理等功能剝離出去,變成使用者空間的獨立程序來提供服務。 來看下這個維基百科上的這個圖應該就很清晰了。 ![](https://img-blog.csdnimg.cn/img_convert/ab31c98f9b7de08c9a208428ca22b07c.png) 巨集核心中的一些功能在微核心架構上都被獨立到使用者態中,這樣核心程式碼量就少了,程式碼少了潛在的 bug 就少,出了問題也更容易排查。 **系統也就更加穩定,不易奔潰**,因為那些服務從核心中移除,在使用者空間執行著,如果出了故障,核心重啟這個服務就好了,不會像之前那樣整個核心 GG。 拿顯示卡驅動來說,出問題就藍屏,這要是微核心設計就可以重啟顯示卡驅動。 聽起來好像微核心很好啊?並不是,接下來就說說微核心的缺點。 首先是**效能問題**,因為很多功能作為獨立程序放到使用者空間運行了,所以巨集核心時的函式呼叫就變成了程序間呼叫,涉及程序間的通訊,還會伴隨著核心態和使用者態的來回切換,我們知道這種上下文切換時比較耗時的。 這效能的問題就有點大了。 然後微核心設計沒那麼簡單,想要靈巧、減少耦合、提高可移植性就需要好好的設計,按照林納斯的話來說:“如果 GNU 核心(微核心架構)早在去年春天完成了,我壓根不會開始我的專案(Lniux)。” > GNU Hurd 採用微核心架構,設計過於精巧,研發速度緩慢,效能長期無法提升。 當年林納斯還和 Minix 的作者安德魯,對作業系統的巨集核心和微核心的好壞進行了一波網路口水戰。 我們來回顧一下那段歷史,挺有意思的。 因為 AT&T 把 Unix 商業化了,大學不能免費使用 Unix,身為大學教授的安德魯為了教學自己搞了個作業系統,即 Minix。 ![安德魯](https://img-blog.csdnimg.cn/img_convert/d53f854489b4ac936c605b2e29d195df.png) 當時的學術風潮是微核心架構,把核心功能模組化,劃分為幾個獨立的程序,執行在不同的地址空間提高了程式碼的可移植和系統的安全性。 所以 Minix 就是按微核心架構編寫的,當然還有上述提到的 GNU Hurd。 而林納斯那時候讀大學,他祖父送了他一臺 Intel 80386,林納斯也看到了安德魯的教科書,根據書上的內容寫出了 Linux。 ![林納斯](https://img-blog.csdnimg.cn/img_convert/32cb14f242eeea1977230d6b54455693.png) 不過沒有按照微核心的設計,而是跟 Unix 一樣採用了巨集核心架構。 安德魯教授看到了 Linux ,然後在 comp.os.Minix 上批評道:巨集核心的設計有害的,Linux 核心耦合度太高,完全是為了 Intel 80386 而設計的,處理器架構進化很快的,作業系統應該都具備可移植性。 安德魯還提到:都1991年了還用巨集核心來設計作業系統,這是一種巨大的退步。 林納斯在一天之後進行了反擊,他說 Minix 設計上有缺陷,從哲學和美學角度來看微核心確實好,但是你看 GUN Hurd 到現在還沒開發出來。 然後作業系統本來就依靠硬體的特性,所以核心本身不需要過度具備可移植性,應用程式的可移植性才重要,Linux 比 Minix 好移植多了。 而且 Linux 本來就是為我自己做的,所以契合 80386,如果要移植到別的平臺,程式碼都是開源的(Minix 原始碼當時得買),想要的人自己做咯。 安德魯也做了一波迴應:Minix 有侷限性是因為我是教授,因為大部分學生都只能在低配的機器上使用,所以系統的硬體需求得足夠低,雖然你 Linux 是免費的,但是需要的硬體貴呀。 其實可以看到,兩者並沒有對巨集核心和微核心的技術細節的進行深入探討,而是抓住對方的:你這 Minix 程式碼還要收費,你這 Linux 需要的硬體這麼貴來進行“攻擊”,所以稱之為口水戰。 反正口水戰之後雙方都沒有改變各自的設計,不過林納斯有引進微核心的思想來改進程式碼,也改善了可移植性。 微核心市面上設計成功的有 QNX,黑莓手機就是用這個作業系統,車用市場也幾乎都用 QNX 系統。 ![黑莓手機](https://img-blog.csdnimg.cn/img_convert/ef1cfe9f6fec379181a32c91596ca73c.png) 這手機很多年前我用過,當時覺得有點東西的。 巨集核心的話就提個 Linux ,足夠了。 兩個架構都有成功的產品,所以還是取捨的問題,也沒有誰完全壓著誰。 再具體的就不深入了,今天的主角其實是廣義上的微核心。 ## Dubbo 中的微核心 Dubbo 的微核心是廣義上的,它的思想是:核心系統+外掛。 ![](https://img-blog.csdnimg.cn/img_convert/7f209d7955c45caf5a13e6ea1843b2cf.png) 這個微核心說白了就是把不變的功能抽象出來稱為核心,把變動的功能作為外掛來擴充套件,符合開閉原則,更容易擴充套件、維護。 小霸王遊戲機大家都應該玩過,就長這樣的,它的設計就可以認為是個微核心設計。 ![](https://img-blog.csdnimg.cn/img_convert/383b214a99a6dab4ac67c1a0b38f891f.png) 機體本身作為核心系統,遊戲片就是外掛。 我們想玩哪個遊戲就插哪個遊戲片,簡單便捷,不影響機體本身。 假設不把遊戲片抽象成外掛式,那是不是就難搞了?換個遊戲就成為難題了。 所以**微核心架構的本質就是將變化的部分抽象成外掛,使得可以快速簡便地滿足各種需求又不影響整體的穩定性。** 這就是微核心架構的精髓。 這裡再扣個細節,較個真(就是我個人的一點想法)。 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 裡面有個「坤坤鼓勵師」外掛,預設你程式碼寫一小時之後蔡徐坤來給你跳雞你太美,讓你休息休息...... ![](https://img-blog.csdnimg.cn/img_convert/86eb99749e5addcbdcea95e10df615e5.png) 來感受一下? ![](https://img-blog.csdnimg.cn/img_convert/616799c84d299d71050bb625a274ca58.png) 所以做一個框架或者軟體,想要讓更多人使用,不僅自身提供的功能要全、效能要好、使用要簡單,**讓使用者 DIY,做各種定製化也非常的關鍵!** Dubbo 的成功其實就離不開它的**微核心設計**,定製化開發在很多場景都要用到,畢竟都得稍加改造一番來滿足自己公司的一些特殊需求。 ## 當然也不是什麼都要微核心 微核心看起來是很方便,但是設計起來就不方便了。 需要精心的設計,抽象出各種擴充套件點。 除了本身的功能還需要管理外掛的生命週期、外掛如何連線、如何通訊等。 有些還需要做沙箱隔離,防止外掛汙染整個系統等等,本來的內部函式呼叫變成了外掛間的通訊,反正設計起來是複雜了。 一般微核心適合用在框架的設計上,或者一些規則引擎的設計,只有複雜的會有很多變化的需求場景才需要用到微核心。 像一般簡單的專案,本來就一條直道走到底的那種就算了,**不要瞎操作,等下秀折了腿。** ## 最後 微核心其實就是一種架構思想,可以是框架層面的,也可以細化到某個模組的設計。 歸根結底就是把變化封裝成外掛,可插拔,擁抱變化。 當然今天也提到了作業系統的微核心,這個和廣義上的微核心還是不太一樣的。 至於 Dubbo 的微核心就離不開它的 SPI,之後文章會深入寫一波​,等我哈。​ > 更多文章可看我的文章彙總:[https://github.com/yessimida/yes](https://github.com/yessimida/yes) 歡迎 star ! ![](https://img2020.cnblogs.com/blog/2083803/202012/2083803-20201228002335322-1514371639.png) --- **我是 yes,從一點點到億點點,歡迎在看、轉發、留言,我們下篇見。** ## 巨人的肩膀 *https://en.wikipedia.org/wiki/Microkernel* *https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate* *《Software Architecture Patte