你好，我是 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，之後文章會深入寫一波，等我哈。
更多文章可看我的文章彙總：https://github.com/yessimida/yes 歡迎 star !
我是 yes，從一點點到億點點，歡迎在看、轉發、留言，我們下篇見。
巨人的肩膀
https://en.wikipedia.org/wiki/Microkernel
https://en.wikipedia.org/wiki/Tanenbaum–Torvalds_debate
《Software Architecture Patterns》