神龙架构没那么难理解—图解世界领先的阿里云神龙架构（二）神龙出世

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

---

本文做者：朱祺

阅读原文

本文为阿里云内容，未经容许不得转载。