3 神龍出世

3.1 繼續說我們的搬磚問題

第2章中指出只要采用虛擬化和彈性計算，就代表100個勞動力必須選擇1個管理人員，實際上只能有99個勞動力進行搬磚。而神龍想做到的目標就是既然100個工人搬磚，就要全部搬磚，但同時也需要有手段來管理和控制我家和鄰居家不同時間搬磚的工人數。以上圖為例就是讓黃色的那個被抽出來負責管理工作的工人回去仍然搬磚去。
包工頭看著目前的情況想，如果要維持兩家搬磚的工人彈性靈活，就需要100個工人抽1個工人做管理工作，那如果1000個工人就需要損失10個，10000個工人就需要損失100個。工程量越大則損失的勞動力就越多，當業務得到大規劃發展時這個損耗的問題如果能夠解決就可以大幅度的提升搬磚的效率。阿里云在神龍架構問世前的虛擬化損耗其實比搬磚的例子更大，平均虛擬化損耗為10%左右，代表100個工人，只有90個在搬磚，剩下的10個在做搬磚管理工作。

3.2 神龍1.0的核心理念

結合實際情況包工頭決定讓原來被抽出來做管理工作的工人甲仍然回去搬他的磚去，因為他的力氣大的特點意味著他本來就適合搬磚而不適合管理工作。而工人隊伍的管理工作采用項目經理制，即引入專業管理人員來負責工人隊伍的管理，使工人只負責搬磚，當然引入專業管理人員后，成本肯定是上升的，但是搬磚的勞動力就沒有損耗了。采用項目經理制后的情況如下圖所示：

需要重點指出的是，搬磚隊伍彈性伸縮的最小單位是1個隊伍，如果搬磚1隊忙不過來，只能要求整個搬磚2隊或者搬磚3隊整個隊伍過來幫忙，而不能說從搬磚2隊僅抽取幾個工人過來幫忙。通過這種結構確保了每隊搬磚隊伍的勞動力因為有專門的項目經理進行管理而不會有損耗。這里先不引伸到神龍架構，因為還有一個重要的問題沒有提到。

3.3 異構計算的本質是搬磚和砌墻的結合

包工頭從自身業務的發展進行分析，發現我和我的鄰居除了搬磚外還有砌墻的需求，而原先的工人全部都是擅長于搬磚而沒有擅長砌墻的泥瓦工，讓搬磚的工人去砌墻固然也是可以的，但是速度和質量顯然不及專門砌墻的泥瓦工。因此包工頭的做法是，在原來的隊伍中加上泥瓦工，這樣1支隊伍就即可以搬磚又可以砌墻了，如下圖所示：

搬磚工人和泥瓦工結合的方式就叫異構，搬磚工人在搬磚的時候泥瓦工在砌墻，就叫異構計算。

3.4 神龍1.0的特點總結

到這里為止雖然沒提過神龍，其實已經把神龍1.0的特點全部說明白了，這里把搬磚砌墻隊伍的問題和神龍1.0的特點結合起來來作為神龍1.0的特點總結。
搬磚砌墻隊伍為了解決勞動力損耗的問題搬磚的全部搬磚，砌墻的全部砌墻，管理工作由專門的項目經理負責。反映到神龍1.0中即阿里云為了解決虛擬化損耗的問題新造出一個帶有智能芯片的專用板卡負責虛擬化調度，這塊專用板卡稱為MOC卡，外觀如下圖所示：

為了解決搬磚砌墻任務而專門成立的帶項目經理的搬磚砌墻隊即是阿里云的神龍云服務器如下圖所示：

業內一般管它叫彈性裸金屬服務器。根據阿里云官方文檔：彈性裸金屬服務器（ECS Bare Metal Instance）是一種可彈性伸縮的高性能計算服務，計算性能與傳統物理機無差別，具有安全物理隔離的特點，分鐘級的交付周期將提供給您實時的業務響應能力，助力您的核心業務飛速成長。現在能夠理解了為什么計算性能與傳統物理機無差別，因為神龍云服務器就是物理機，所以當然計算性能和物理機沒有差別，此外它又可以像云服務器一樣彈性伸縮，并且交付周期為分鐘級。
一句話總結神龍1.0的特點就是，神龍云服務器兼具了物理機和云服務器優點，本質上是可以彈性伸縮的物理機并且這種物理機專門為提供云服務設計。

3.5 神龍1.0的瓶頸

回到搬磚的例子，包工頭又碰到了新問題，鄰居他自己就是一個項目經理，對于搬磚和砌墻有特殊的要求，他要求一個搬磚砌墻隊內的100個工人上午搬左邊的磚，同時砌右邊的墻；下午搬右邊的磚，同時砌左邊的墻。而目前搬磚砌墻隊的項目經理沒經歷過這種情況，不知道該怎么調配隊伍內的工人。
這就是神龍1.0的瓶頸，虛擬化其實分成兩個方向：一個方向是虛擬化組合，把一堆物理機粘成一個大的虛擬機；另一個方向是虛擬化切分，把一個物理機切成一堆小的虛擬機。神龍1.0做到了虛擬化組合，但并沒有做到虛擬化切分，在例子中即為搬磚砌墻隊的項目經理只知道在自己的隊伍不夠用時叫別的隊伍來幫忙，但是自己的隊伍內怎么去響應我鄰居家的要求，上下午通過隊內工人調配做到勞動力彈性卻沒有辦法實現。
這個問題在神龍2.0中得到了解決。

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的神龙架构没那么难理解—图解世界领先的阿里云神龙架构（二）神龙出世的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。