#### 由巨核心和微核心之爭聯想到的

前篇我們聊到了分散式系統及分散式資料庫的定義，其中也談到分散式系統定義中的一個很重要的概念：

- 訊息傳遞

這不由的讓我想起了歷史上一場著名的爭論：巨核心和微核心。關於這場爭論，感興趣的可以讀下當時的郵件討論（https://yarchive.net/comp/microkernels.html ） 。

這裡我想引用Linus在1999年發表的一篇文章《The Linux Edge》（https://www.oreilly.com/openbook/opensources/book/linus.html ）中的關於微核心的一段論述，雖然時隔20多年，還是非常值得我們借鑑和思考的：
> #### Microkernels
> When I began to write the Linux kernel, there was an accepted school of thought about how to write a portable system. The conventional wisdom was that you had to use a microkernel-style architecture.
當我開始編寫Linux核心時，學術界對和如何編寫可移植系統有一個共識，他們通常認為明智的選擇就是必須用微核心的架構。

> With a monolithic kernel such as the Linux kernel, memory is divided into user space and kernel space. Kernel space is where the actual kernel code is loaded, and where memory is allocated for kernel-level operations. Kernel operations include scheduling, process management, signaling, device I/O, paging, and swapping: the core operations that other programs rely on to be taken care of. Because the kernel code includes low-level interaction with the hardware, monolithic kernels appear to be specific to a particular architecture.
在如Llnu調核心這樣的巨核心 中，記憶體被分為使用者空間和核心空間。核心空間是用以存放核心程式碼以及核心級別操作的記憶體。核心操作包括排程、程式管理、訊號、裝置輸入／輸出、分頁和轉換等。這些都是其他程式賴以執行的關鍵操作。由於核心程式碼含有與低層硬體的互動作用功能， 所以巨核心看起來似乎只能侷限於某一特定的體系。

> A microkernel performs a much smaller set of operations, and in more limited form: interprocess communication, limited process management and scheduling, and some low-level I/O. Microkernels appear to be less hardware-specific because many of the system specifics are pushed into user space. A microkernel architecture is basically a way of abstracting the details of process control, memory allocation, and resource allocation so that a port to another chipset would require minimal changes.
微核心是隻在較有限的形式下完成較少操作的一個集合，如程式間通訊、有限的程式管理與排程，以及一些低階別的輸入／輸出等。由於許多系統特性被劃分給了使用者空間，因此微核心似乎與硬體關係不大。微核心體系基本上只是對程式控制、記憶體分配、資源分配等細節的一種抽象方式，要將它移入另一類晶片只需做 很小的改動。

> So at the time I started work on Linux in 1991, people assumed portability would come from a microkernel approach. You see, this was sort of the research darling at the time for computer scientists. However, I am a pragmatic person, and at the time I felt that microkernels (a) were experimental, (b) were obviously more complex than monolithic Kernels, and (c) executed notably slower than monolithic kernels. Speed matters a lot in a real-world operating system, and so a lot of the research dollars at the time were spent on examining optimization for microkernels to make it so they could run as fast as a normal kernel. The funny thing is if you actually read those papers, you find that, while the researchers were applying their optimizational tricks on a microkernel, in fact those same tricks could just as easily be applied to traditional kernels to accelerate their execution.
因此,1991年當我開始編寫Linux時，人們都認為只有微核心方法可以解決可移植性。因為它在當時是電腦科學家研究的寵兒。 然而，我是個固執、講求實際的人，當時我對微核心的看法是： 
1．仍處於實驗階段； 
2．比巨核心複雜得多； 
3．執行速度明顯地比巨核心慢。 
由於運算速度對於現實世界中的作業系統意味著一切，所以，當時許許多多的科研經費都花在了對微核心的最最佳化檢測上，看它是否執行得如同正常核心一樣快。令人好笑的是，如果你真正讀一讀那些論文的話，你就會發現，研究人員應用在微核心上的最最佳化技巧，事實上可以很容易地應用到傳統核心上以加快其執行速度。

> In fact, this made me think that the microkernel approach was essentially a dishonest approach aimed at receiving more dollars for research. I don't necessarily think these researchers were knowingly dishonest. Perhaps they were simply stupid. Or deluded. I mean this in a very real sense. The dishonesty comes from the intense pressure in the research community at that time to pursue the microkernel topic. In a computer science research lab, you were studying microkernels or you weren't studying kernels at all. So everyone was pressured into this dishonesty, even the people designing Windows NT. While the NT team knew the final result wouldn't approach a microkernel, they knew they had to pay lip service to the idea.
實際上，這使我覺得微核心方案就像是一個自欺欺人的方案，目的是獲取更多的研究經費。我並不是說這些研究人員誠心要欺騙，也許他們只是愚昧，或者是搞錯了。我說的這些都是我的真實感受。這種不誠實來自了當時籠罩在研究領域的強大壓力，迫使人們致力於微核心方面的研究。在電腦科學實驗室裡，你要麼在研究微核心，要麼就根本不是在研究核心。所以大家都在被迫表現出這種不誠實，甚至包括設計Windows NT的人們。即使NT工作小組的人員知道最終的結果不是採用微核心方案，他們也不得不迎合這一思想。

> Fortunately I never felt much pressure to pursue microkernels. The University of Helsinki had been doing operating system research from the late 60s on, and people there didn't see the operating system kernel as much of a research topic anymore. In a way they were right: the basics of operating systems, and by extension the Linux kernel, were well understood by the early 70s; anything after that has been to some degree an exercise in self-gratification.
值得慶幸的是，我沒有受到追隨微核心的壓力。芬蘭赫爾辛基大學從60年代未起一直從事作業系統的研究，他們不再把作業系統核心視為一個研究焦點。從某些方面說這是正確的。作業系統的基礎，也就是Linux核心的擴充套件的基礎。早在70年代初就已被人們瞭解得很清楚，這之後的任何事都是某種程度上的自我滿足的練習。

> If you want code to be portable, you shouldn't necessarily create an abstraction layer to achieve portability. Instead you should just program intelligently. Essentially, trying to make microkernels portable is a waste of time. It's like building an exceptionally fast car and putting square tires on it. The idea of abstracting away the one thing that must be blindingly fast--the kernel--is inherently counter-productive.
如果你想編寫出具有可移植性的程式碼，那麼你不必非要靠建立一個抽象層才能實現程式碼的可移植。相反，你只需要程式設計時聰明一點就可以到達目的。基本上可以這樣說，想方設法使微核心可移植是浪費時間。這好比使用方型輪胎來研製一種超高速的汽車。一味地將核心中的一件事單獨提取出來，盲目地追求其速度，其相應的效果只能是適得其反。

> Of course there's a bit more to microkernel research than that. But a big part of the problem is a difference in goals. The aim of much of the microkernel research was to design for a theoretical ideal, to come up with a design that would be as portable as possible across any conceivable architecture. With Linux I didn't have to aim for such a lofty goal. I was interested in portability between real world systems, not theoretical systems.
當然，微核心的研究並不侷限於上述努力，但問題的大部分就是目的上的不同。很多微核心研究的目的是針對某個理想化的理論而設計的，以求這種設計能夠跨躍任何可能的體系，從而實現可移植性。我井沒有想在Linux上實現這麼虛幻的目標。我感興趣的是在現實的系統上實現可移植性，而不是在理論的系統上。

從現實結果來看，巨核心架構的Linux/Unix已經支配了世界。當然，Linux/Unix也並不是固執己見，一成不變，其也借鑑了一些微核心的理念，但是是在一些特定的認為適合使用的場合。

以史為鑑，一味的鼓吹分散式資料庫是否真的恰當？我不否認分散式資料庫的好處，但是需要有場景。根據分散式的理論，我認為分散式資料庫是為解決全球部署，或者多地部署（不是對裸光纖距離有嚴格限制的偽多地）而生的，脫離這個前提，而大談特談分散式資料庫，就有點耍流氓的味道了。

資料庫雜談（3）

相關文章