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中得到了解决。

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