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个工人搬砖，就要全部搬砖，但同时也需要有手段来管理和控制我家和邻居家不同时间搬砖的工人数。

原文链接
本文为阿里云原创内容，未经允许不得转载。