各位it168的听友，大家晚上好，很高兴大家能够抽出时间参与这次讨论，今天我将会围绕京东基础网络在618期间的保障工作来和大家做一次分享，希望能给大家提供参考。众所周知，在刚过去的618促销中京东取得了非常大的成功，京东今天的成功除了离不开物流体系、营销体系、仓储体系的建设外，更离不开强大的技术保障体系，为了保障京东618成功，我们后台有一个庞大的it系统在支撑，比如说有秒杀系统、价格系统、负载均衡系统、分布式数据库系统、私有云、公有云系统，以及各种各样的中间件的系统等。作为我而言主要是参与京东基础网络的it系统建设，具体来讲主要是参与京东基础网络自动化平台的相关的建设，这里我给大家发了一张图片，这个图片是我们互联网公司的机房。作为互联网公司而言由于其it设施非常多，所以我们都有专门的数据中心，以京东为例，我们在国内多地以及国外的很多地方都有自己的机房，在每个机房里面有密密麻麻的机柜，每个机柜上面都有一个上联的交换机我们称之为tor交换机，所有的tor交换机最终都会汇集到我们的核心交换机上，下面两张图是核心交换机的图片，大家可以看到所有的tor都是通过密密麻麻的光纤连接上来，我发这个图片的目的是希望能够给大家一个视觉上的认识，对于互联网公司的机房而言，不单有数量庞大的x86服务器，也有数量庞大的网络设备。
从图中大家可以看到我们网络设备的数量非常多，同时网络设备上的端口的数量更是达到了一个非常恐怖的程度，我们日常的很多工作都是针对网络设备，以及设备端口来进行操作的。这里我把我曾经历过的几个痛点案例来分享一下，我们曾经有一个机房的名字发生了更改，其中一千多台交换机需要逐个修正hostname，大家想想，如果这一千多台交换机的hostname需要人手工去修改，这个工作量有多大？而且这项工作自身没有任何的高价值，只是重复劳动而已。另外一个例子是我们的运维同事经历过的，我们的大数据部门有很多服务器，集群内带宽要求比较高，为了保证这么大的带宽我们一般要对服务器网卡打bond，这么大的操作量曾经花费了我们网络运维的同事一个多月的时间来连续进行夜间操作，我们网络运维同事的心理阴影面积大家可以计算一下，非常的大。另外第三个案例是我最近负责的案例，公有云用户专线接入的时候，要求实时的接通，并且路由也必须是实时的发布，这里我特意把静态路由加粗了，是因为动态路由实时交换很容易，而静态是需要我们手工操作的，大家也可以体会高频度发布的话没有自动化也是不现实的。
从刚才的几个痛点案例当中大家可以感受到当我们的网络设备的数量达到一定的程度以后，对人力成本的消耗是多么的恐怖。对于任何事物，其规模比较小的时候，我们不管是通过人力的方式还是什么其它方式都可以非常容易地把控，但是当其规模达到一定的程度的时候，管理会变得非常困难，而且从我们的数据中来看人为的参与反而会引起更多的问题。刚才有一个网友提出什么叫对网卡打bond，这个术语是指将服务器的两块网卡或者是多个网卡打成一个逻辑上的网卡，比如说我的服务器需要40g的带宽，但是我每个网卡只有10g的带宽，我就可以把这4个网卡打成逻辑的一块40g的网卡。
通过刚才的痛点分析大家可以感受到京东这种体量的互联网公司，在这么多的设备，以及几十万的端口需要管理的情况下，可想而知我们网络运维同事的工作量有多大。在网络规模经历一个爆发式增长的过程中，我们经历了一系列的痛点，痛定思痛我们考虑不能这样持续下去，如果按照京东目前这样的发展速度一直持续下去的话，将来的基础网络的工作量对我们网络运维而言将是不可胜任的，所以我们的自动化变得非常迫切。这个问题我相信不但是京东，bat也面临过相同的问题，我之前跟业界的同事交流意见的时候，大家也都反映目前没有找到一个非常完善的方案。
▲
接下来我们来花点时间讨论一下我们业界的解决方案有哪些，对于基础网络而言他跟我们虚拟机中的软件网络不一样的：是我们的软件网络中，所有的东西基于软件实施，他的增加删除非常容易，可以低成本完成整个网络的切换，而硬件网络关联大量的硬件it基础设施，这些硬件是不能随便更换的。并且这些硬件面临着一个非常大的挑战，就是厂商的设备之间有非常大的差异性，比如说华为、思科、华三的设备有很多的特性是不一样的，有的网友问我们不是有rfc网络标准吗，但是各个厂商也是部分兼容，有很多是不一直的实现，对于基础网络而言我们要实现自动化，首先要解决的问题是如何要把硬件设备的差异性想办法屏蔽掉，我们可以有几个层次进行切入，首先来讲是我们可以通过设备本身进行切入，这主要是通过设备的os进行切入，在业界有几种方案，比如说移动有一种方案是在我们的传统交换机上增加一个翻译层，可以将最近比较流行的openflow协议翻译为传统交换机所支持的各种表项。
还有一些其它的有实力的大公司，比如说微软，谷歌或者是百度，这些公司靠自己的实力从头开发自己的交换机操作系统，比如微软发起了一个sonic开源项目，这个项目是微软基于debian系统定制的交换机os，另外在bat内部也有一些交换机的项目，我个人理解百度是走的靠前一些。除了操作系统的对接，另一种方案是在设备的外部进行对接，操作系统的对接难度是比较大的，需要是具备非常专业的人才储备才可以，就目前京东而言我们还不具备这个实力，京东目前采用的方式是设备协议性对接，我们不修改设备自身的属性，利用设备支持的协议来对接。目前我们的网络设备都支持很多协议，比如说snmp协议，简单网络管理协议，以及我们人在登录时使用的ssh协议。除了设备的协议性对接，很多厂商也看到了网络设备的智能化趋势，比如说思科和华为目前开发了控制器，也可以跟厂商的控制器对接，接下来我们看一下对比一下，我们网络设备支持的协议性对接，这些协议之间的异同点主要是什么。
首先我们来看netconf协议，基于xml的数据交互的协议，xml是结构良好并且可以自我表达的数据，程序进行解析的时候，他是一种最好的协议，但是缺点是netconf协议相对要新一点，很多老设备不支持，并且新型号设备如果操作系统版本跟不上也不行，我们曾经遇到的一些操作，在2.1版本的时候不支持，到2.2版本的时候支持，仅仅0.1个版本，这个协议的支持受网络设备操作系统的版本的关连性是比较多的。
我们看一下第二种协议，就是ssh协议，这种方式实际上是我们用程序模拟人工的操作，理论上这种方式可以对交换机进行所有的配置，但是有一个问题，ssh是面向人的而不是面向程序的，他的展现形式比较漂亮，但是不够严谨，我们解析的时候需要花费大量的精力进行解析，并且ssh的方式命令经常是交互式的，比如说网络设备会问你yes/no，这种情况对我们的程序处理也是非常大的挑战。
还有一种协议是snmp协议，也是我们基础网络设备管理中常用的协议，比如说我们抓交换机端口的流量以及基本信息的时候，我们可以基于snmp协议进行抓取，他的返回数据格式也是比较统一的，程序解析的难度也比较低，大多数交换机支持比较好，但是其问题是对抓取类操作支持相对要好一点，对设置类操作支持有限，并且如果是高密度执行snmp操作话会容易引起cpu的彪高，另外我们使用这个协议的时候，发现其数据不够稳定。
给大家举个例子，我们抓取一个端口的流量的时候，大多数情况下这个端口的流量是在一百兆左右，比如说是96，97，98兆，突然出现一个十万兆，又会降下来，这个十万的数字肯定是假数字，我们实际的抓取的过程当中发现很多设备经常会出现snmp跳变的问题，所以这个协议的数据精度是不够的。
我们刚才讲snmp协议的时候还说过其会引起cpu彪高的问题，这里我们简单的做一个交换机的小科普，刚才发的图片是一个交换机的基本的内部结构，在交换机的内部有两个非常重要的芯片，一个是cpu芯片，另外一个是交换芯片，对于数据包的转发而言是基于低功耗的交换芯片来实现的，一般情况下是尽量不会上cpu的，我们知道x86的执行效率是非常低的，指令集功耗高，如果我们对于设备的请求要大量通过上升到cpu处理的话，就会影响数量包的转发。除了刚才的三种方式以外我们还希望网络设备能够以api的形式进行交互，api的交互方式比较友好，并且可定制性比较强，缺点是目前只有少数的厂家来提供，华为、思科还有这种大厂支持的比较少，我们期望未来的api的方式可以成为主流的方式。
刚才我们讨论的内容没有实际关连到京东自动化的项目，但是刚才花时间讲解的东西，都是我们在设计京东网络自动化项目过程中进行的考量，接下来我来给大家介绍一下京东的自动化项目，从2017年的一月份我们京东基础网络组正式起动了代号为joypaw网络设备自动化项目，joypaw是我们的内部代号小名叫“狗爪”，之所以是叫这个项目名，是因为我们还有一个监控项目joyeye，小名叫“狗眼”，joypaw这个项目截止到今年的第一季度已经完成了对tor交换机的常规适配，包括vlan、bond等操作。第二季度中期的时候我们开始对618的备战提供网络操作支持，由于开发的时间只有一个季度多一点，所以我们第一阶段提供的支持主要是以命令行的支持，在618的前期主要是从五月下旬到六月上旬，我们的api被调用超过五万次，提供了超过一万多次的设置，应该来讲节省的人力成本还是很显著的，大家可以想象一下一万多次的设置如果是靠我们的运维同事手工设置的话将是多大的人力损耗。
对于joypaw的实现，毋庸置疑所面临的挑战跟我们前面所述的挑战是一样的，关键点是如何屏蔽设备的差异性，首先是我们面临的品牌差异性，比如说京东主要的网络设备的供货商是华为、华三、思科，每个厂商的设备差异性都不低，其次还涉及型号和os版本的差异性，这些差异性的组合可以达到60多个。
这样就导致我们大量的时间跟精力对设备的返回结果去解析。我们将设备的操作抽象为统一的api接口，从示意类图可以看出一个api对应一个handler，每个handler调用communicator接口与设备通信，joypaw通过两种方式与设备通信：netconf与ssh，最后设备返回的内容通过parser接口下的子类进行解析，这个接口下面大家可以看到有很多的子类，这些子类是负责对不同的返回结果进行解析，最终是以结构化的形式返回给我们的调用方。对于需要向设备发送的命令，我们都以配置的形式进行管理，而不是在程序里，这样的好处是我们当要增加一条操作设备的命令的时候，我们只需要在数据库里增加就可以了，不需要重新编译代码。有过软件开发经验的同学应该都知道，我们的软件系统即便修改一行代码也要进行重新编译，而这个部属还要占据一定的时间，另外我们即便是改一行代码也是需要进行大量的测试，很多时候重要的漏洞都是由一行代码引起的。另外，我们设计架构时力图精简，京东是一个互联网公司，他的软件系统非常庞大，如果不注意就很容易使用消息队列、分布式db。使用大架构设计，虽然也可以工作，但是部属和推广会非常麻烦，将来如果我们想往开源社区捐献的话也会非常麻烦，所以从设计的开始我们就坚持了一个精简的设计原则，用最简单的方式解决复杂的问题。
正是因为我的api层把设备的差异性全部屏蔽了，所以有了上层app的开发基础，在joypaw体系示意图里面大家可以看到我们的系统的是分层的，对于上层的app而言他是我们主要的开发部分。
目前已经有的应用是我们的命令行app，有过网络操作经验的同学，可能会想操作网络设备的时候也是用命令行操作，既然都是命令行，我为什么要用你的命令行来进行操作呢？joypaw命令行的好处是可以在一个窗口之内对进行任意的设备来进行发送命令，不用反复登录设备，并且每一次的设置操作我们都会额外附加查询的操作来进行有效性验证，很多时候我们向设备发送命令虽然反回成功了，但并不一定在设备上真的体现了。另外我们的命令行可以让我们的网络工程师方便的与shell进行结合，实现灵活的命令编排，同时还支持以模板的形式进行批量配置，比如说有些时候一条命令搞不定需要几条命令搞定，这时候允许我们的网络工程师通过excel来把所有的方式配置完后，来进行批量的处理。
除了我们的命令行以外，我们已经开发的另外一个app是tor交换机下联主机探测程序，大家知道作为基础网络组而言我们管理着京东大量的基础网络设备，但是服务器设备并不是在我们这进行管理的，这时候我们如果想知道交换机下联服务器的情况，通过跨部门协作的话，数据交互效率是比较低的。如果我们可以通过网络自身的学习表项来动态分析的话，我们就可以基本掌握下层服务器的入网情况，当机房服务器ip变动的时候，我们也是会进行准时的感知，这个也是我们重要的应用之一，大家可以看到自动化的方式对效率的提升是多么的显著。
除了我们刚才...