摘要： 摘要：2017年12月20日在北京云栖大会上，阿里云高级技术专家梵叶在计算与网络分论坛上做了主题分享《双十一丝般顺滑体验背后：阿里云洛神网络虚拟化系统揭秘》。为大家介绍了洛神系统的发展过程，系统架构，高可用性设计和虚拟交换机等重要组件。
客观的说，今年双11的体验还是不错的。我自己作为例子，之前几年的双11的0点时候，我自己的购物车的一波提交，一般瞬间进入了排队状态，但今年我的体验明显不同，一波就成功了。双11的底层技术，实际上是建立在网络产品的基础之上的，接下来，我要给大家分享的主题就是，双11的这一切，我们是如何做到的。我会把阿里巴巴双11上云叫做大象在云上跳舞。为啥说是大象呢，因为双11的量是在是太大了，想要完美支持双11真的不是容易的事情，尤其是双11零点的峰值。大家都知道AWS的ELB的预热，面对这样的峰值挑战一定是无力的。
这里有几个数字分享给大家。首先是关于两个结果的，一个是100%的流量比例都是在云上的，一个是32.5万笔每秒的交易峰值。这个交易峰值是什么概念呢，大家知道么，2009年的时候第一次双11，交易峰值是200笔每秒，在这个大量的交易下，云网络稳如泰山。另外三个关于极限性能的值，一个是单一网络的ECS数量，这个是10w台。之前我刚好到深圳拜访一个客户，这个客户是自己在家里用Openstack搭云网络玩的，这个客户刚好给我吐槽，说自己搞了100个计算结点，结果控制器就跪了。另外一个是160G的负载均衡实例的带宽，我相信这个值已经超过了绝大多数的硬件负载均衡器。最后一个是10分钟扩容上千台ECS。这个举个例子，这个弹性的扩容能力在鹿晗曝光恋情的当天发挥了重要的作用。
不是所有的云计算公司都有机会承受双11的洗礼，可能除了阿里云以外的任何一个云计算厂商都没有经历过这样的体验。但尽管阿里巴巴是一个非常极致和奇葩的客户，但除了阿里巴巴之外，阿里云上面还有数以百万计的客户，满足一个客户的需求，服务一个客户也许总是容易的，可以为这个客户完全定制系统，但同时服务百万级的客户，则绝对不是一件容易的事情。
首先，云上客户最关心的一定是可用性，谁也不想上了云以后，服务一天到晚的宕机，所以可用性是云上客户的命根子。
除了可用性之外，易用性也是一个非常重要的特点。之前用户想要拉根专线，组件一张网络，要考虑机房，供电，机位，交换机路由器，网络架构，机房实施等等各种事项，但在云上组建网络，用户需要的是只需要点击一下，网络就会按照用户需要的样子创建起来；但是如果要用户点击无数下，那也许用户就要爆粗口了。
搞定了可用性，易用性，用户这个时候关心的就是弹性和性能，这两个和用户体验息息相关，也是也是用户降低成本的大杀器。这里双11就是一个很好的例子，当用户需要资源的时候，资源准备的时间，用户希望是0，当用户不需要资源的时候，资源销毁的时候，用户也希望是0。至于性能，关系到用户希望用最少的钱，达到最高的效果，这个也是非常关键的。
最后一个就是智能，这个怎么理解呢，举个例子，刚才我们提到的用户需要资源和销毁资源的过程，用户本质上是这些动作希望自动完成的，当用户线上出现问题的时候，用户希望系统本身自动处理掉。
阿里云网络产品是如何满足用户的呢，从表面来看，我们实际上就是靠一套基于API的SDN调度系统，来创建和删除资源来保证的。而这些产品的背后，就是洛神系统。洛神系统来源于中国的古典神话，我们希望我们的网络产品，和河运的槽道一样，能够通畅的连接资源。
洛神也不是一天建成的。
第一代洛神的网络是出现在2011年，这个时候，用户感知到网络的方式是通过给定的公网和私网，用户无法自己定义网络，在这个架构下面，网络实际上是不存在虚拟化的，都是物理网络的地址直通到VM里面搞定的，网络和网络之间也不存在物理的隔离，所有的地址都是一个地址平面里面，因此这个时候，网络的隔离的ACL等功能，都是在物理交换机上上线的，这个阶段，我们称为洛神的经典网络时期，这个阶段，网络基本上没有弹性。
第二代洛神的网络出现在2014年，这个时候，用户可以自定义自己的网络了，用户的拓扑，地址都完全可以自己定义，这个阶段我们叫做洛神的vpc阶段，在这个阶段里面，由于用户有了一张网络，那么一定出现了这张网络如何联通internet，联通线下IDC和联通其他网络的问题。这样这个阶段里面，洛神的产品设计得到了极大的丰富，各种不同的产品都出现了。
第三代洛神出现在2016年，其实第三代洛神是关于智能调度和用户体验的演进。当用户的网络越来越庞大的时候，用户一定需要一个更好的方式，让他云上的资源和云下的资源能够直接联通。当用户的资源原来越多的时候，用户也一定需要一个更好的方式，来管理这些资源，比如带宽，流量等等。当用户在全球部署服务的时候，用户一定希望来自全球的访问具备智能的调度和就近的接入。
当用户越来越依赖于云上，那么用户一定希望，云上的感受不是仅仅是业务的使用，而是不断提升的可视化，可运维性和不断的附加值的产生。
这个就是第三代洛神，智能洛神。
好的，接下来，我们来看下，现在的洛神架构是如何支撑这些丰富的特性的。和传统的SDN的架构一样，洛神的系统架构也做了控制和转发的分离。数据面位于左下角，在洛神的数据面里面包含了常见的计算节点上面的虚拟交换机，这个是数据包在计算结点上面的第一道关卡。除此之外的数据面的重要的角色是网关，网关在洛神中有两个主要功能，一个是承载常见的网络功能虚拟化单元，也就是我们常说的NFV。另外一个连接两张不同平面的网络，例如连接公网和线下的IDC。
数据面相当于是洛神系统里面数据包流动的载体，那么控制数据包流动的，就是控制平台。洛神的控制平台同样包含几个部分，一个是对于设备的管理，这里包含了对主要的数据面组件虚拟交换机和网关的管理，负责了配置从控制器到设备的下发。另外一个重要的组件是虚拟网络管理，负责了vpc本身的地址分配，vpc内的路由配置等等功能。除此之外了，另外两个关键的组件是本地路由控制器和全局路由控制器。当洛神不再是一个数据中心内部的网络，而是变成了一张跨机房甚至跨地域的全球网络的时候，这两个控制器就起到了关键的作用，一个负责数据中心范围内的网络互连和路由计算一个负责全球范围内的网络互连和路由计算。
洛神除了数据面和控制面之外，还有一个主要的组成部分，就是运营平面。虚拟网络的数据面和控制面在源源不断的产生数据，包括各种运行时的状态，异常的报警，日志，有效的处理和消费这些数据，是整体系统稳定的基础。因此运营平面的一个非常重要的功能。另外一个点，是网络产品的运营数据的处理，这一部分功能也是在运营平台支撑的。
整体来看，数据平台，控制平台和运营平台组成了洛神系统。当然，洛神系统也不仅仅只是支撑了阿里云的网络产品，阿里云云产品的底层网络，都是由洛神系统来提供支撑。大家可能比较清楚的是阿里云整体的虚拟化协议栈飞天系统
洛神就是其中的虚拟网络组件。
接下来我来详细给大家分享下洛神系统的主要的关键设计。我们认为，对于公共云服务的底层技术，稳定性和可用性是优先级最高的，因此我先来介绍下洛神系统在可用性方面的设计。
当阿里云的某一个数据中心云机房开始部署的时候，洛神系统作为最底层的系统，在物理设施部署完成之后会第一个进行部署。这个时候，大家看到，这个机房里面有计算集群，网关和控制平台。计算集群上面有我们的虚拟交换机组件。
在只有一个云机房的情况下，我们是没有办法做到跨机房的容灾的。但是对于数据面和控制面的关键结点都是集群部署的，单台服务结点的问题不会对用户产生任何的影响，同时vm的宿主机当出现宕机等严重问题的时候，可以在机房范围内进行迁移，迁移本身也不会对vm的网络属性和连通性产生任何的影响。
当第二个云机房，第三个云机房建设起来的时候，每个云机房里面都会部署集群的网关和控制器结点，而且随着机房的增多，会自动在云机房里面形成环形的备份关系。当一个新的机房建设起来，洛神系统部署之后，会自动加入到这个备份链里面。这样，当某一个机房的关键结点由于异常出现问题的时候，都可以自动在秒级切换到备份机房，由备份机房的洛神系统来提供服务。这个就尽可能保证了首先单台设备的故障不会引发影响，而某个机房的所有结点发生问题，也可以在很快的时间内恢复用户的业务。
洛神系统可用性的另外一个重要的设计是在于运营平面，而运营平面本身也是洛神系统智能和数据化的关键设计。大家如果把洛神系统看成一个整体的交换机，那么从特性上来看，洛神系统是一个支持流跟踪的交换机，具有各种丰富的策略。洛神系统的下面是物理网络的设备和交换机，通过洛神系统的流标记的能力和基于policy的策略，可以同时在物理网络和虚拟网络里面具备流的染色，特定报文的镜像，采样，trace等的能力，流量采集的数据等等，这些动作产生的日志，都会通过SLS采集到jstorm做实时计算，如果流量有异常，会产生报警和日志给到管理员，部分报警可以触发故障的自动处理和恢复。还有一部分数据也会离线同步到ODPS，进行更丰富的计算，进而产生数据报表和用户画像给到用户，也可以给到用户一张炫酷的大屏。这个本质上就是数据化的能力。
介绍完了可用性的关键设计，接下来我们看下数据面的虚拟交换机。做过虚拟交换机的同学都知道，虚拟交换机在云网络里面是分布最为广泛的，每台宿主机上面都有一个虚拟交换机，虚拟交换机是vm进出网络的第一道门。在洛神系统里面，虚拟交换机因为其分布式的角色，承担了大部分的复杂业务逻辑。网关作为多租户的设备，复杂业务逻辑的风险一定是更大的，所以这个是虚拟交换机的第一个关键设计。
洛神的虚拟交换机也是和普通的交换机一样，实现了快慢速的分离，这种设计会极大的提升性能。
另外一个设计是业务逻辑的抽象，在洛神虚拟交换机里面，抽象了常见的网络的处理逻辑，通过简单的使用policy的匹配-action的触发，可以配置出各种复杂的逻辑。这个意味着很多复杂的功能实现，最终是不需要修改代码的，基于policy修改配置即可。
在虚拟交换机的业务逻辑下面，是一个vswtich的baseOS层，有了这个层面，一个是可以适配不同的虚拟化技术，甚至物理机，所以大家看到，像KVM，XEN，容器，物理机等等，都是靠一套vswtich来支撑的。另外一个是适配不同的底层平台，X86,ARM,MIPS都可以运行。这个使得对于版本的管理是最为高效的，而对vswitch的规模来说，版本管理真的是要命的。
看完了vswitch我们来看下整体的数据面。洛神系统支撑的网络产品，今年发布了好几个性能的值，包括ECS性能等，都还是满高的，很多友商也紧跟着发布了类型的性能。现在来看洛神系统的数据面，其实最简单的比喻，就是洛神系统的数据面，本身就是一台巨大的交换机。
大家都知道，交换机的转发芯片对数据包的处理，都是pipeline的，硬件处理永远不会停下来，那洛神的数据面也是如此。从一个数据包进入洛神系统开始，到出去洛神系统的整个过程，经历了洛神系统里面的各个组件，都是不会被打断的，这样只处理一件事情的数据面，一定是高效的。
还有，洛神系统的网络永远不会因为维护而中断，这意味着，洛神里面的所有组件，都支持热升级。热升级对用户只有100-500ms的流量中断，基本不感知。
另外，洛神系统里面的关键组件vswitch，大家都知道这个组件的变更，由于规模问题是非常棘手的。但洛神的vswtich已经建立了完整的自动发布机制，包括了CI在里面，所以整体的效率提升是非常显著的。
回到之前的管理10w台物理机的问题上，其实洛神解决这个问题的方案也不复杂。单个网络里面放10W台虚拟机，最大的问题是虚拟机的位置表的规模的问题。很多的SDN解决方案都是将配置直接下发到vswitch的，这种解决方案当vm迁移或者新建，销毁的时候，带来的配置的变化的量是巨大的。
为了解决这个问题，我们先是设计了一个自学习的协议，用于流量产生的时候来触发对vm位置表的自学习。同时维护一张带超时的位置表。之后创建一个高速的cache，用于快速的响应学习的请求。做了这些事情之后，我们发现，现在达到10w的vm的数量的压力其实也不是太大。
