云时代，本地部署的企业级软件在不扩容的情况下，能做到短期内十倍的性能提升的确是一件令人侧目的成绩。
众所周知，x86的性能已经被压榨到了极致，带着种种疑问SegmentFault思否社区采访了云杉网络研发总监向阳。访谈中，向阳详细谈了在企业数据中心网络场景下各种时序数据库的表现，并解释了云杉网络如何从工程的角度实现x86软件十倍性能的提升。
向阳：云杉网络研发总监、网络架构师。负责云杉研发团队的管理和DeepFlow的架构设计和核心功能实现。
年获清华大学计算机科学与技术博士学位，师从吴建平教授并独立实现了世界上第一个基于关联分析的BGP劫持检测系统，因此摘得InternetMeasurementConference（IMC，网络测量领域国际顶级会议）社区贡献奖。年获得清华大学博士后证书，主要研究方向为云数据中心网络架构，获得了多项网络安全、云数据中心相关专利。
思否：能否请您先介绍一下主要工作经历，专注的技术研究方向，以及目前所负责的工作。
向阳：我的工作经历其实比较简单，在加入云杉之前，我在清华大学读博。师从吴建平院士做一些包括域间路由的算法和结构、域间路由的安全等等方面的工作。毕业后，我接触到SDN的领域，也就顺理成章地加入云杉，然后一直做SDN的研发工作直到现在。现在我在公司是研发团队的负责人和DeepFlow产品线的负责人。
思否：随着业务需求的提升以及云计算等相关技术的发展，企业开始建立自己的云数据中心，其中网络是云数据中心的重要组成部分之一。您认为现代企业的云数据中心在网络架构的搭建上通常有哪些痛点？企业应当如何应对这些挑战？
向阳：我们能看到的企业在去做这一块的时候，主要的一个挑战其实可以分为两个方面，一个方面就是说怎么去建设，另外一个方面，其实还要去考虑到怎么样去维护它。
建设主要解决两个痛点：一个是网络连通性的问题，一个是网络服务化的问题。
为了支撑业务，首先要把异构的资源、混合云这些场景下做一个打通和互联；然后在此之上提供丰富的网络服务，包括像应用交付服务、安全服务等等。
与上述问题平行展开的，是复杂网络的运营维护问题。因为现在网络会相当的复杂，一般来讲IT基础设施会同时在公有云、在私有云不同的资源池上，此外还有虚拟化的一个容器资源池。在这样一套IT基础设施上要打通一个统一的网络，才能支撑业务的灵活需求。
比如说一个业务要想在容器的资源池里面去拿到几个POD，在虚拟机资源池里面拿到一些虚拟机，在裸机资源池里面拿到几个物理机来实现一个业务需求，这个时候实际上这些资源池是互相独立的，但是从网络的视角看（这个业务）是一个整体，要将上述资源池的这些网络打通、做统一的编排，这是一个挑战。
在此基础之上，如果说我们把网络做了打通，那么这个网络维护的难度也是非常高的，不可能再由人工去做维护——如果说这张网增加了10倍的复杂度，那就意味着至少要投入10倍的人力，这件事难以为继。
思否：云杉网络为了帮助企业解决网络运维管理上的挑战，早在年的时候就推出了云网分析产品DeepFlow，能否请您先介绍一下DeepFlow的核心组件、功能特点以及应用场景？
向阳：实际上我们把DeepFlow的一个解决方案划分成两个场景，一个是采集分发，另外一个是分析。那也就对应着DeepFlow的整个产品中的三个核心的组件：采集器、分析器和控制器。
从组件的角度来讲，控制器负责中央的管控和大规模（采集器）的管理，因为我们的采集器会运行在很多异构的环境里面——KVM虚拟化、VMware虚拟化、公有云的环境、私有云的环境、容器的环境、Linux的环境以及windows的环境——这时采集器的特点是运行的环境异构，另一个特点就是采集器的数量非常大。
控制器它需要做的就是一个集中的大规模的管控；而采集器需要做的就是刚才对于这些异构环境的一个全网覆盖，包括物理的、虚拟的等等，做一个全网的覆盖；以及我们需要有一个高性能的策略匹配的算法。
因为如果对所有的流量数据全部做处理，这个时候的资源开销将会非常大。有的流量我们可能只是希望看一看，有的流量我们希望把它的一些counter记录下来，还有的流量会进入它的pcap文件，进入它的一些详细的数据包，以及把一些流量直接分发出去。
不同的流量需求，我们就需要通过一个策略的体系去对它做一个相当于编排。通过匹配，把符合某意图的一些流量，给到后端对应的消费工具里面。这样的话我们在采集这一侧是需要有一个较强的策略匹配引擎，再到后面我们的流量除了去分发给第三方的分析工具，传统的NMP、DPI以外，我们还能自己做一些分析，这就是我们的分析器。
我们的分析器主要一个特点，就是通过一个分布式的时序数据库，来将网络中的所有的状态和统计数据存储下来。这相当于对网络的全景视图做一个刻画。客户再去做混合云场景下的一个网络排障的时候，能把所有的这些关联点，不同的网络、不同的层面，不同的Overlay、不同的Underlay——比如说在容器的场景下可能是双层的Overlay——把它们都联系起来。
再回到应用场景。第一个是混合云上流量的采集和分发。这种应用场景一般是针对于客户已经有了很多传统的分析设备，比如说DPI的设备、NPM设备等等，但是他们苦于无法拿到虚拟网络、容器网络里面的流量。
在虚拟网络的场景下，网络的规模非常大，现在一个服务器可以虚拟出来10个虚拟机，一个虚拟机可能又有10个POD，这个数量是非常庞大。因此在虚拟网络里你不能像传统物理网络那样通过分光、镜像直接拿流量。我们能做到全网覆盖，按需的把流量拿出来给到后端的分析工具。
另一个场景就是混合云的网络诊断，这实际上是网络分析的场景。因为我们看到现在的云的网络是充分复杂的，这里面有异构的资源池，有不同层级的Overlay，我们怎样在这样一个复杂的网络环境下去做故障的诊断定位？这需要我们有一个全网流量数据的分析能力，即网络分析。
思否：DeepFlow自5.0版本之后的每次更新都对性能进行了改善，尤其是5.5.6版本后核心组件的性能再次大幅提升，这是如何实现的？是否与编程语言和数据库有关？云杉为什么如此看重性能上的提升？
向阳：首先来谈一谈这些性能的提升是如何实现的，其实总的来讲包括几个方面。采集这一侧，我们是对于新技术有一些引入，像DPDK以及像Linux内核高版本的XDP的技术，XDP对于客户的环境的依赖是比DPDK要低，并且流量的采集性能比我们上一代的技术能有10倍的提升。
另外补充说明一下我们对新技术的引入，我们其实是走在了社区的前面，年发布的CentOS8使用的内核版本对于XDP的支持其实并不好，我们也从内核的层面对XDP的支持做了一些提升，使得我们能在低版本的Linux环境里面将我们的采集器的性能提升上来。
另外一个方面是分析侧，主要我们是基于数据结构和算法的一个优化。我们整个DeepFlow平台，绝大部分的组件都是基于Golang，稍后再讲我们为什么会去选择Go。我们对它原生的数据结构——像map这样一些数据结构——做了一些非常关键的算法和数据结构上的改变，使得其性能都提升了10倍。
这里面我们有一些专利存在，比如说我们对于Go的对象资源池、内存池的一些改进，对于map的一些改进，这是在分析侧的优化。
然后就是在存储侧的优化，我们是基于InfluxDB数据库，对它的内核做了全新的开发，实现了10倍读写性能的提升，以及具有一个水平扩展的能力，更重要的是使它更适合网络的场景。
回过头来说Golang，其实和语言的关系还不是太大，如果说我们需要去追求一个极致的性能，我们可能会去选择比如说像C这样的语言。但这里还有另外一个问题，就是我们的开发效率和适配性。如果我们用C的话，可能对于环境（比如说glibc的版本）的依赖会比较严重。
Go其实是一个云时代的语言，像Docker这样的技术，就是构建在Go之上的，其依赖是非常小。我们选择Go能够在依赖性和开发效率上获得优势，此外我们也会去克服它的缺点，像它的GC带来的缺点、它的数据结构带来的性能问题，这些方面我们都做了提升。
最后说说我们为什么如此