神龍架構沒那麼難理解—圖解世界領先的阿里雲神龍架構（二）神龍出世

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中獲得瞭解決。

---

本文做者：朱祺

閱讀原文

本文爲阿里雲內容，未經容許不得轉載。