作者：朱祺 阿裡雲全球最有價值專家
1 概述
1.1 神龍架構的特點
阿裡雲官方文檔對于神龍架構的描述如下：
保留了普通雲伺服器的資源彈性，并因嵌套虛拟化技術讓彈性裸金屬伺服器保留了實體機的體驗。
1.2 了解上的難點
同時擁有雲伺服器的資源彈性和保留了實體機體驗的特點容易讓使用者在需要深入了解神龍架構時産生一個疑問：神龍架構到底是虛的還是實的，如果虛實融合又怎麼來了解什麼是虛實融合？通過什麼手段做到的？
1.3 本文重點說明的問題
結合以上神龍架構的特點和了解上的難點，本文詳細的對于神龍架構進行研究分析，說明神龍架構是如何做到同時擁有雲伺服器的資源彈性和保留了實體機體驗的目标的。
2 為什麼需要發明神龍架構
2.1 以搬磚為例說明虛拟化技術的特點
把實體機變成虛拟機的這個技術，就是“虛拟化”。比如我家裡裝修有100塊磚需要搬運，鄰居家也在裝修同樣有100塊磚需要搬運，我們各請了50個搬運工，當勞工到達時發現鄰居家的主人在睡覺，是以他家的50個勞工隻能等他睡醒再搬磚，我家請的50個勞工則可以直接幫我開始搬磚，情況如下圖所示：
正好兩家的勞工來自于同一個公司于是包工頭過來看了一下，發現鄰居家的勞工在空閑狀态覺得效率很低。于是決定既然鄰居家的勞工目前空閑于是一起來幫我家搬磚。和我商量費用并不增加，勞工增加50個，我自然非常開心，覺得多給了我家50個勞工。于是鄰居家的勞工也過來開始幫我家搬磚如下圖所示，我們稱這個100個勞工為計算節點：
包工頭心裡在想一個事情，他馬上需要去其他工地，現在100個勞工都在幫我家搬磚，是以進度很快，但是鄰居萬一睡醒了也要開始搬磚怎麼辦，于是他抽了一個勞工甲出來看着鄰居家動靜，一旦鄰居家醒了需要開始搬磚，則把暫時幫我家搬磚的勞工還給他并且勞工數量至少50個。
于是甲離開了搬磚行動，專門看着鄰居家主人防止他突然醒過來，幫我家搬磚的勞工數目前為99個。這個負責關心鄰居家主人睡覺情況并負責後續把勞工還給他的甲，我們稱他為管理節點。
鄰居家主人睡醒了，甲于是立即從我家将50個勞工安排到鄰居家開始搬磚，同時和我商量，因為之前我家搬磚的勞動力多了一倍，是以1000塊磚被搬了隻剩50塊了，而鄰居家的磚還是1000塊，是以除了鄰居雇傭的50個勞工外能否我家隻留5個勞工，我自己雇傭的45個勞工也幫鄰居家搬磚，我欣然同意，是以兩家搬磚的勞工數再一次改變如圖所示：
這個整個過程即為彈性計算的本質，前提即是虛拟化，如果缺少了虛拟化技術，代表我和鄰居家雇傭的勞工來自于兩個公司，沒有人來統籌決定每家搬磚的勞工數，是以即使鄰居在睡覺，他雇傭的勞工空閑着也無法過來幫我搬磚，能夠做到搬磚的勞工靈活調配的前提就是将兩家人家雇傭的勞工進行統籌考慮再進行配置設定。對于使用者的好處在于，我和鄰居家都有1000塊磚要搬，但是搬磚的時間不同，我在搬磚的時候他在睡覺而他睡醒需要搬磚的時候我家的磚已經快搬完了，同樣100個勞工的勞動力在不同的時間段裡被我們用到了極緻。
2.2 虛拟化技術的瓶頸
從以上搬磚的例子中可以發現，因為勞工甲負責協調我和鄰居家搬磚的勞工安排是以他本身不再負責搬磚，也就是100個勞動力中抽調了1個勞工的勞動力來做管理工作，實際搬磚的勞動力為99個。按照原來雇傭的勞動力，我家雇傭了50個勞工，鄰居家雇傭了50個勞工，總的勞動力為100人，是以實際搬磚的勞動力少了1個，但因為我和鄰居家搬磚時間的錯開并且以我們的感受都享受到了遠大于50個勞工的勞動力（實際我家99個，鄰居醒來後他家為94個）是以滿足我們的需求，也就并不太在意100個勞工中有1個來作為協調我們兩家勞工數的管理人員。隐患在于如果我家磚搬完了，鄰居家的搬磚勞工上升到99個，他發現需要再快一點，要求100個勞工搬磚，這時候我和鄰居将同時發現勞動力因為有人去做管理工作而少了一個，我們兩家總共花了100個勞工的錢，卻總共隻能享受到99個勞工的勞動力。
事實上這1個管理人員确實是整個體系中無法解決的瓶頸，代表隻要采用虛拟化和彈性計算，就代表100個勞動力必須選擇1個管理人員，實際上隻能有99個勞動力進行搬磚。反映到雲計算上就是隻要實體伺服器采用虛拟化技術，就必須配置管理節點，是以單台實體伺服器所提供的計算力在原來的基礎上需要打折扣，造成實體伺服器基礎上采用虛拟化技術後生成的雲伺服器的計算性能必然比實體伺服器要差。雖然使用者因為雲伺服器叢集的彈性計算功能未必能感受到。
這個瓶頸原來在雲服務提供商中都存在，似乎成為了必然，因為覺得沒有辦法解決因需要管理節點而造成的總計算力損失是以也沒有雲服務商去讨論深究這個問題。而阿裡雲神龍架構即破天荒的在這個瓶頸問題上開始動刀子，想做到的目标就是既然100個勞工搬磚，就要全部搬磚，但同時也需要有手段來管理和控制我家和鄰居家不同時間搬磚的勞工數。