關于軟硬件誰為主導這個話題，套用一句諺語就是三十年河東三十年河西，風水輪流轉。軟件和硬件一定是相互促進、相互拆臺又相互搭臺的。一些之前被詬病的上層架構，或許若干年之后會被發現成了最合適的選擇，而再過若干年，又會變得不合適。軟件定義亦或是硬件定義，同樣也是這樣，硬件定義的結果是性能夠強但是不靈活，此時軟件定義便會開始醞釀翻盤，但是任何事情都有慣性，軟件“過度”定義之后，會發現很多事情搞不定，還得靠硬件來加速一下，此時開始進入硬件定義周期，然后循環往復。我們可以用幾個例子來窺探一下這種規律。
CPU和OS
一對不離不棄的夫妻，陰抱陽，陽抱陰。一開始沒有所謂中斷，更沒有所謂OS，只有順序執行指令計算機和被寫死的程序，很不靈活。后來才有了OS，CPU先執行OS這個大循環程序，然后載入所需要執行的用戶程序執行，執行完退出，可以繼續載入其他程序執行。哪怕最簡單的OS要想玩轉，CPU起碼也得至少提供IO和時鐘中斷機制。OS呱呱墜地，就得不斷長大，不斷地進化，單任務不靈活，就得多任務分時執行，所有任務共享內存空間，導致了安全性問題，這就不得不引入虛擬內存技術，所以軟件越來越復雜，性能逐漸就不行了。此時CPU出來說話了，我來搞定虛擬內存，提供頁表極致，提供專用的控制寄存器，并提供專用的查表加速硬件部件。多任務分時OS的生產力被初步釋放，但是性能還是較差，還得依靠CPU搞定。CPU繼續發力，引入超線程技術，讓多個線程的代碼可以并發執行，這得益于流水線的設計;為了能夠更好的實現線程并發執行，后來繼續出現多核心多CPU的SMP技術， OS不得不做出改動。但是多CPU/核心并不是任何時候都很高效地并發多線程的，隨著軟件復雜度提升，線程同步、緩存一致性等問題導致需要大量狀態和數據同步，傳統的共享式的前端總線效率太低，所以不得不改為交換式Fabric比如IntelQPI，訪問內存經過太多跳器件效率上不去，所以也改為直連CPU分布式共享架構，這也是當今的形態。再往后會怎么發展，應該可以順著慣性往前推導一下，交換式Fabric的出現，意味著CPU和CPU之間可以離得越來越遠，只要有足夠高速的鏈路連接，這一形態其實就是大型NUMA計算機的形態了。這一形態的輪回意味著軟件架構的變化，傳統領域需要高性能的場景不得不使用大型機、小型機，但它們是極其昂貴的——就是因為不開放，而且又不可能像互聯網領域一樣投入開發資源在分布式系統上定制化自己的應用。而開放式大型NUMA系統出現之后，可能之前的被“過度”定義了的分布式系統生態又會沉寂下來，這個循環進入新的周期紀元，在這個紀元里，曾經光鮮的分布式系統可能會被新生代工程師/架構師認為是一種很不可思議的“野路子”：“你看，以前這種架構，好坑爹啊!”。這就像我們現在回頭看之前的有些設計一樣，也會感覺到不可思議，那時候的人都這么“腦殘”么？恩，如果換了你回到那個時代，或許更腦殘：)。不管誰腦殘，一個事實是始終不變的，那就是硬件性能的絕對值是一直直線上升的，不管分布式還是集中式。
CPU和VMM
VMM能發展到今天這個地步是無人始料的，一開始就是玩玩，沒想到玩了個大的出來。有不少人持有上述觀點，其實這個觀點只是表象。虛擬機技術起源于大型機，中小型機上早已也使用了多年，所以VMM可并不是玩玩。大機小機都是封閉市場，技術也確實牛。開放市場領域很多技術其實都是源自大型機小型機。虛擬機顯然是單機性能過剩，而多機整體資源又無法得到全局細粒度池化分配時代的產物。VMM虛擬CPU，虛擬IO設備，虛擬內存，一開始全用軟件實現，每一條指令解釋執行，后來優化了設計，但最終還是要監控和截獲+虛擬那些敏感和特權指令，每個進程還要虛擬出額外頁表從而虛擬內存，IO需要經歷重重內存拷貝才能發出去一個包，要想商用的話，軟件各方面開銷實在是搞不定了，此時還得硬件出馬，在CPU層面提供硬件輔助，IO設備也開始有了SRIOV/MRIOV的方案，我總感覺這次硬件反而有點“過度”定義了，被軟件騙了一回。為什么呢？就因為硬件資源不能做到池化和細粒度切分，才會產生VMM這個尷尬的東西，而此時硬件仿佛走火入魔了，弄出一系列復雜的技術來支撐VMM。其實硬件還有另一條路可以走，同樣可以實現VMM類似的效果，那就是讓硬件變得可以切分，而不是用軟件去切分。這條路在小機系統上曾經有人嘗試過，采用總線級別的隔離開關來切分不同的CPU和內存以及IO槽位。要實現細粒度切分的前提是必須把硬件最小切分粒度降下來，單CPU使勁增加性能其實已經不是一條比較明智的路線了。近幾年眾核CPU不斷冒出頭來，單CPU128個核心已經不是什么驚訝之事了，但是由于生態尚未成熟，它們目前仍被局限在并行度高耦合度低的處理場景比如網絡包處理等。另一個跡象就是ARM生態的崛起，種種跡象表明這很有可能是一條光明大道。但是如何將傳統生態導向這個道路上就不那么簡單了。我們看到Intel正在搞SiPh硅光方案，其致力于硬件資源的靈活拼搭，如果粒度足夠細，VMM其實就可以退出舞臺了，這將又是一場硬件拆臺軟件的血腥戰斗。
虛擬機和云計算
虛擬機的發展催生硬件加速方案，也正是因為硬加速，又使得虛擬機可以大范圍應用，也正是如此，才將云計算的概念帶了出來，也就是硬件又反過來加速了軟件的變革。而隨著量的上升，會影響質變，人們會發現其實VM這種東西是非常低效的虛擬化，VMM個人理解其實是一股具有邪性的陽氣，他看似光鮮實則非常損耗陰實的，體現為過多不必要的操作系統實例。操作系統本來就是利用線程/進程來虛擬化多任務多用戶的運行，每一次系統調用的開銷是非常高的，讓一個CPU同時運行多個操作系統實例，無疑是極大的浪費，上文提到過這種模式是單機性能過剩而整體資源又無法得到池化時代的產物。而云計算架構的出現，會打破這個矛盾。云計算可能初生的時候就是一個全局虛擬機資源調度管理軟件框架，但是一個事物畢竟是不斷在成長進化的，云計算會最終找到它的使命，那就是大范圍全局資源的池化、分配調度管理監控，也就是數據中心級的OS，做的事情與單機OS如出一轍。既然如此，那么AAAS(ApplicationAs a Service)應該是云計算最終要實現的狀態，這就相當于打開屏幕，就出現一堆應用圖標，點進去完成你要的功能，退出，結束。既然用戶不需要IAAS，不需要直接面對操作系統，那么搞那么多VM實例其實就是沒有必要的，空耗資源。云計算需要實現一個全局的應用進程級別的調度中樞，而不是調度VM。再來思考一下大機為什么需要VM？因為大機那個時代并沒有現在這種云計算的概念，xAAS這個思維，你可以說那時候人腦殘，那時候軟件技術是很封閉而且不發達的，所以進行資源細粒度切分，用VM也算是快刀斬亂麻的方案。我們也看到進程級虛擬機(比如LinuxContainer)業逐漸在受到關注。這些都是云計算這個軟件框架、這個宏觀的OS的定義，那么這種定義會對硬件有什么影響？我想那一定會催生兩個硬件形態的變革，一個就是上面所說的單點的性能要足夠低，力度要足夠細，單點性能“足夠低”，這可能讓人大跌眼鏡，不過將來可真說不定啊，眾核CPU就是個很好的胚子;另一個是局部多層高速Fabric核間通信，由于CPU/核心可以任意切分和組合，他們之間一定需要一個高速總線相互連接，目前存在多種Fabric方案和產品，這塊雖然比較低調冷門但是也還算成熟，加上硅光等技術會將Fabric隱身至機架外，這就為大范圍池化提供了支撐。而這次硬件的變革很可能又會影響軟件的架構，使得大規模并行計算不再需要MPI等遠程消息傳遞機制，消息傳遞直接使用Fabric硬件加速的隊列FIFO，會大大簡化編程，有利于HPC的模式最終可以全面得到普及。
云計算，宏觀操作系統，數據中心級的NUMA機，一切皆有可能。
京公網安備 11010502049343號