SDN实战团分享(二十七):Cisco ACI技术解析

在网络厂商的圈子里,其实SDN早就不是什么新概念了。ForCES作为“SDN上古神兽”在2004年就有了第一版RFC,2006年Juniper向IETF提交NETCONF,希望能够对各厂家设备的CLI进行标准化,同时在远端通过开放API对网络进行自动化配置与管理,至于OpenFlow其实也早在2008年就被提出了,不过当时也没有在业界引起太大的波澜。2004年到2012上半年,面对初现“狼子野心”的SDN,Cisco可谓是镇定自若,策略上也没有采取过分的打压,毕竟作为网络厂商的“大哥大”对待新技术要表现出足够包容的姿态。当然,包容的前提是SDN一直是雷声大雨点小,Cisco的利益并没有受到任何实质性的侵害.

事后来看,当时的Cisco显然没有预料到SDN近10年蓄势后的爆发力,导火索就是2012年7月Vmware对Nicira的12.6亿美元的天价收购,这宣布SDN的商用方案正式进军数据中心。上一节中讨论过,对Nicira的收购失败绝对是Cisco始料未及的,于是Cisco开始秘密孵化SDN创业公司Insieme,并派出了Cisco技术扛把子MPLS中的MPL三人帮助打造Insieme的软硬件。2013年4月,Cisco领衔各大厂商成立SDN开源项目OpenDaylight,随即6月Cisco发布ONE战略,Chambers正式公开承认SDN的未来地位。

2013年8月Google发布了基于SDN的广域网解决方案B4,2013年10月前后Awazon放弃与Cisco近10亿美元的设备订单而选择基于SDN的数据中心白盒解决方案。世界上两家Top 5的高科技公司相继投向SDN,抛开技术上的原因不谈,这明显地为市场释放了SDN将加速落地的信号。Cisco再也没办法拖下去了,2013年11月初Cisco正式收购Insieme,并高调发布其数据中心SDN解决方案ACI(Application Centric Infrastructure,以应用为中心的基础设施),围绕Cisco自己的硬件打造SDN,正式宣布与完全基于软件的NSX开战。2014年4月,Cisco部分开源了ACI的南向协议OpFlex,向OpenFlow+白盒发起冲击。

自从ACI推出以来,业界围绕着NSX和ACI的讨论和比较就从来没有停止过。NSX骨子里是更为正宗的SDN学院派,NSX-MH更是将网络设备进行了彻底的开放。而ACI其实是打了SDN的擦边球,其整体方案仍然是围绕Cisco的硬件来展开的,因此有人说ACI算不得是SDN,而是一种HDN(Hardware Defined Networking)。不过从广义SDN的角度来看,ACI仍然开放出来了一定的网络可编程能力,因此笔者认为ACI仍然属于SDN,而且其技术上还是有很多有趣的地方,这一节我们就来对ACI的实现进行探讨。

(一)ACI架构

ACI的架构并不复杂,APIC(Application Policy Infrastructure Controller,应用策略和基础设施控制器)作为控制平面,向上通过GUI/CLI/REST API/Python Scripts向管理员提供配置、管理、策略下发的接口,向下通过OpFlex协议将策略推送给ACI Leaf/vLeaf设备中的PE(Policy Element)模块,PE模块会将策略转换成设备能够理解的配置并部署到设备中。注意,APIC上的策略都将生效于ACI网络的边缘,因此APIC只会向ACI Leaf/vLeaf推送策略,而并不会向ACI Spine推送策略。另外,ACI Leaf/vLeaf/Spine的转发都不受APIC控制。

为了方便后面介绍ACI的控制平面,这里对ACI使用的南向协议OpFlex进行简单的介绍。OpFlex基于声明式(declarative)的配置管理方式,相比于CLI/OVSDB/NETCONF这类命令式(imperative)的配置管理方式,OpFlex将策略实现的的复杂性从控制器中剥离,控制器只负责管理和推送策略,策略的实现交由转发设备来完成。这种声明式的配置管理方式,在一定程度上可以减轻控制平面的压力。OpFlex的通信模型如下所示,ER(Endpoint Registry)存储这工作负载(EP)的信息并根据PR中的策略将EP分类形成EPG(EndPoint Group),PR(Policy Registry)存储着业务策略,PE(Policy Element)负责监测EP并在转发设备本地执行策略,Observer负责监测转发设备的状态信息。PE分布在各个转发设备本地,而ER、PR和Observer则是逻辑上集中的。对于ACI来说,PE分布在各个ACI Leaf/vLeaf上,ER、PR和Observer则分布在APIC集群中。

OpFlex承载与RPC之上,提供了双向的通信能力,其上图中出现的信令如下表所示,OpFlex的全部信令及其具体格式请参考https://tools.ietf.org/html/draft-smith-opflex-03。

相比于NSX,ACI并没有设计单独的管理平面。不过实际上,与其将APIC称为控制平面,倒还不如称为管理平面来的贴切,因为OpFlex擅长的是对业务策略和设备的管理,却并不具备对转发设备的转发进行直接控制的能力。“以应用为中心”听起来很client-based,但实际上这是Cisco得以继续走封闭设备路线的幌子。不过,Cisco一再强调APIC不仅仅是Super Network Management System(虽然有点欲盖弥彰),那么我们倒不妨可以把APIC看作一套开放了GUI/CLI/REST API的数据中心OSS。

(二)APIC设计

为实现“以应用为中心”,最为关键的技术就是对应用策略的自动管理和部署。APIC使用了“承诺理论”来管理、部署这些应用策略。“承诺理论”是指控制平面只维护应用策略的状态,而不去真正执行策略,策略完全由转发设备来执行,如果转发设备执行失败将会导致应用策略的部署失败。ACI中“承诺理论”的执行依赖于POM(Policy Object Model,策略对象模型)的建立,ACI中基本的POM如下图所示,EPG(Endpoint Group)代表了一组具有相同通信约束的EP,同一个EPG内的EP间可以无障碍通信,不同EGP的EP间的通信规则由合约(Contract)来进行约束。一个应用可以由多个EPG和这些EPG彼此之间的Contract构成,它们共同形成一个应用策略(Application Network Profile)。EPG的分类规则非常灵活,管理员可以根据应用策略的需要来制定EPG的分类规则,如同一VLAN、同一VxLAN Segment、甚至同一DNS后缀,等等。Contract主要包括以下几种:入向/出现ACL,QoS,重定向和服务链。基于这些多样的EPG和Contract,ACI管理员可以通过CLI/GUI/REST API/Python Scripts制定丰富的ANP,APIC维护并分发这些ANP,ANP的执行由转发设备来完成。

APIC的POM中,除了通过EPG来对EP进行应用策略级别的分类外,还可以通过Bridge Domain/Network/Tenant来对EP进行L2/L3/租户的划分。Bridge Domain的概念类似于Vmware的VDS(Virtual Distributed Switch),逻辑上是一个二层的广播域。一个Network可以包含多个Bridge Domain,逻辑上是一个L3的网络。一个Tenant包括多个Network,逻辑上是一个ACI租户的网络。同一EPG下的EP必须属于同一个Bridge Domain,但是不同EPG间的EP可以根据Contract跨越Bridge Domain/Network/Tenant进行通信,也就是说ANP的制定逻辑上是不受任何局限的。

APIC向ACI Leaf/vLeaf推送应用策略的方式有三种:(1)策略预装,即所有的应用策略都由APIC预先推送给ACI Leaf/vLeaf,策略在设备本地即刻编译,编译后在datapath上生效。这类似于OpenFlow控制器以proactive方式预置流表。(2)策略触发式推送,即EP上线时Leaf/vLeaf会通过一条Endpoint Request向APIC请求相关的策略,APIC受到请求后将策略推送给ACI Leaf/vLeaf,策略在本地即刻编译,编译后在datapath上生效。这类似于OpenFlow控制器以reactive方式对PacketIn作出反应并编辑流表。(3)策略预推送,即所有的应用策略都由APIC预先推送给ACI Leaf/vLeaf,但是策略在设备本地不会立刻进行编译,而是等到EP上线时才会开始编译并生效。(1)的优点是APIC的实时开销几乎为零,缺点是设备上的ACL太多,(2)与(1)相反,优点是设备上不存没有用的ACL,但是APIC的实时开销太大,(3)介于前两者之间是一种折中的方案,也是ACI的默认模式。

除了管理、部署应用策略以外,APIC还需要对转发设备进行管理。APIC有以下8个主要的组件:

■ Policy Manager:管理、部署应用策略,作为PR和ER通过OpFlex协议与ACI转发设备中的PE进行交互

■ Topology Manager:通过LLDP维护ACI的物理网络拓扑,通过ISIS维护ACI的L2/L3逻辑拓扑。同时维护设备清单,包括序列号/资产号/port/linecard/switch/chasis等

■ Observer:监测APIC/ACI转发设备/协议/性能等,并提供告警和日志。作为Observer通过OpFlex协议与ACI转发设备中的PE进行交互

■ Boot Director:负责APIC/ACI转发设备的启动,自动发现,IPAM和固件升级

■ Appliance Director:负责APIC Cluster的建立

■ VMM Manager:与虚拟机管理程序(Vmware vCenter/Hype-V SCVMM/libvirt)交互,维护Hypervisor上的网络资源信息,如NIC/vNIC/VM names等,能够感知虚拟机迁移。会将相关信息告知Policy Manager

■ Event Manager:记录APIC/ACI转发设备发生的事件和故障

■ Appliance Element:监控上述组件的运行状态

上述组件所涉及的数据,包括策略和设备的状态信息是十分复杂的,为了能将这些数据有效地组织起来,APIC设计了一棵MIT(Management Information Tree)。无论是北向的REST API还是南向的OpFlex,都数据进行任何的操作都必须依据MIT上的路径,因此APIC是一种数据驱动的控制器架构。OpenDaylight的MD-SAL同样采取了类似的设计。

APIC的高可用建立在APIC Cluster的基础上。APIC间的自动发现依赖于Boot Director组件完成,APIC节点间通过Appliance Director组件维护集群的状态。至少需要3个节点才能形成APIC集群,集群可以根据ACI网络规模进行动态的扩容,集群中节点数上限为31个。不过实际上,由于APIC只做策略不做转发控制,因此即使所有的APIC节点全部挂掉,整个ACI网络的L2/L3转发是不会受到任何影响的。APIC Cluster间的MIT数据管理采用shard database实现,shard database技术将MIT上的一份数据复制成多份备份到不同的Cluster节点中,数据的读写必须发生在原始的节点上,原始节点再向该数据的备份节点进行同步,以保证数据的最终一致性。APIC中需要做shard的组件有4个:Policy Manager、Topology Manager、Observer和Boot Manager,它们的数据在APIC Cluster上都存有3个备份,随机地分布在各个Controller节点中。关于shard database的详细介绍,这里不做信息介绍,感兴趣的读者可自行查阅相关资料。

由于APIC Cluster间的通信以及APIC与ACI转发设备的通信都是通过IP完成的,而ACI网络中的IP连接是不受APIC控制的,因此APIC可采用In-Band的部署在ACI网络中,而且APIC集群不必位于同一机架下。出于商业考虑,Cisco将APIC打包在其UCS刀片服务器进行部署,装有APIC的服务器建议双归到两台冗余的TOR上(N9000 Leaf)。当APIC采用Out-of-Band部署时,应通过至少1G的Ethernet的管理端口与设备进行连接,以保证控制信道足够的带宽。

(三)ACI转发设备设计

这一小节之的标题之所以没有叫做“ACI数据平面设计”是因为ACI的转发设备本地仍然保留了大部分的转发控制逻辑,因此不同于常见意义上的“SDN数据平面”,同理上一小节的标题也没有叫做“ACI控制平面设计”,因为APIC实际上并不具备对ACI转发设备上转发逻辑的控制能力。

ACI转发设备构成的网络成为ACI Fabric,Fabric内部转发设备通过ISIS进行L3互联。ACI Fabric采用leaf-spine的物理拓扑,leaf与spine间建议采用物理全互联,不允许在leaf间以及spine间进行物理直连。Cisco专门为ACI Fabric拓展了其N系列的交换机——N9K,通常以N9300系列作为ACI Leaf,用于服务器/防火墙/路由器等设备的接入,以N9500系列作为ACI Spine,为ACI Leaf间的互联提供高速、无阻塞的连接。

ACI Leaf的软件设计上,基于Nexus OS进行了裁剪,并增加了PE模块来处理OpFlex协议并APIC推送下来的处理应用策略,ACI Leaf的OS有两种工作模式可选:Standalone模式用于兼容之前的Nexus Switch,Fabric模式用于ACI Fabric。ACI Leaf的硬件设计上,要求支持二层桥接(VLAN/VxLAN/NvGRE)和三层路由(OSPF/BGP),并能够基于原始帧的目的MAC或IP封装隧道,并能够在本地执行应用策略。

ACI Spine的软件设计上,并不要求支持OpFlex。ACI Spine的硬件设计上要求提供Fabric模块的热插拔、高密度的40G以太网端口,支持大规模的MAC/IP到VTEP IP间映射的database mapping,以及VxLAN Hardware Proxy。

ACI Fabric是基于VxLAN Overlay在租户网络上进行转发的。为了更好的支持应用策略的部署,Cisco拓展了标准的VxLAN Header形成了VxLAN-GBP(VxLAN Group Based Policy),标准VxLAN Header和VxLAN-GBP Header如下所示。Flags中有两个bit标记源EPG和目的EPG策略是否已经得到了执行,Source Group记录了源EPG的ID,VNI仍然是24bit,但是VNI指代的不再仅仅是标准VxLAN中的Segment ID了,而是根据情况可以指代ACI POM中的Bridge Domain/Network/Tenant。

VxLAN-GBP Overlay上的转发是ACI最核心的技术实现,在本质上体现了Cisco对于SDN的理解。有别于其它众多的SDN控制器直接操作FIB来控制Overlay的转发,APIC只关心应用的策略而并不关心VxLAN-GBP Overlay上的转发,VxLAN-GBP Overlay上的转发完全由ACI Fabric设备来实现。这里要掰开来细说了,也方便后面对于ACI转发过程的分析。

先来看ACI的东西向通信,东西向通信包括L2桥接与L3路由。

L2桥接依赖于MAC/VTEP映射关系的学习。一般而言,实现MAC/VTEP映射关系的学习有三种思路,一种是分布式的MAC自学习(标准VxLAN),另一种是由SDN控制器直接从CMS获取映射关系(OpenStack Neutron),第三种是转发设备自学习本地的MAC地址,然后将MAC地址告诉SDN控制器,控制器整理好MAC/VTEP的映射关系再将其反射给其他的转发设备(Vmware NSX)。而ACI对于MAC/VTEP自学习的实现方式均有别于上述,不过在思路上类似于第三种,由ACI Leaf自学习本地EP的MAC地址,但是ACI Leaf不会将该信息告知APIC,而是将该信息告诉给ACI Spine,ACI Spine通过硬件的mapping database存下该(Bridge Domain + MAC)/VTEP的映射关系。

多次反复后,ACI Spine中将存有全局的(Bridge Domain + MAC)/VTEP映射关系,这样就可以将ACI Spine看做是Overlay L2逻辑上的控制平面,而且全局的映射信息将分布在各个ACI Spine中互为备份,保证了控制平面的高可用性。

同样,ACI实现Overlay L3路由也使用了上述L2桥接的控制机制,ACI Spine中的mapping database不仅仅有(Bridge Domain + MAC)/VTEP的映射关系,还有(Network + IP)/VTEP的映射关系,这样就可以将ACI Spine看做是Overlay L3逻辑上的控制平面,以集中地指导东西向L3流量在ACI Leaf上完成分布式路由。ACI Spine在这里扮演的角色,有点像LISP Map-Server。而且,根据(Network + IP)/VTEP的映射关系进行L2的转发也是没有任何问题的。由于采用了分布式路由,因此传统路由的单点瓶颈问题也得到了解决。

下面再来看ACI的南北向通信,南北向通信可分为与物理L2的对接,以及与Internet的L3对接。

由于ACI Leaf支持将任意异构的L2(VLAN、标准VxLAN、NvGRE)连接到ACI VxLAN-GBP,因此与外界的L2互通在一定程度上也可以看做是ACI的东西向流量,物理Host可以部署在任意的ACI Leaf上。与物理VLAN的对接,ACI Leaf会完成VxLAN-GBP与VLAN间的转换,另外整个ACI Fabric将以Transparent Mode接入外界VLAN的STP环境,以避免产生环路,如下图所示。

与标准VxLAN/NvGRE的对接,ACI Leaf会完成VxLAN-GBP与标准VxLAN/NvGRE间的转换,因此ACI是可以作为NSX的Underlay进行部署的。

由于ACI采用了分布式路由,因此与Internet的L3对接的关键就变成了如何将Internet路由分发给ACI Leaf。ACI对此的实现过程如下:在ACI Border Leaf与外界路由器间运行OSPF/BGP以学习Internet路由。经过路由重分布后,ACI Border Leaf将学习到的Internet路由通过MP-BGP告知ACI Spine,ACI Spine将作为BGP-RR通过MP-BGP将Internet路由反射给其它的ACI Leaf。整个过程同样没有APIC参与,完全由ACI的转发设备完成,这与NSX中VM对接Internet流量的实现是截然不同的。

由于采用了动态路由协议,因此这部分流量的高可用性可通过HSRP/VRRP以及ECMP等传统方式来实现,这里不做赘述。

当然,Cisco也支持通过Hypervisor中的vSwitch来将VM接入ACI Fabric。ACI支持的vSwitch主要有以下3种:Open vSwitch、Vmware VDS和Cisco AVS(Application Virtual Switch)。对于OVS,VM的发现是由OpenStack直接告知APIC的。而对于VDS,VM发现是通过在ACI Leaf和VDS之间运行扩展的LLDP协议来实现的,ACI Leaf发现VM后通过OpFlex通知APIC新的EP上线并请求应用策略的下发。下面分别给出了APIC/ACI Fabric和OVS/VDS的整个交互流程,表述的非常清晰这里就不再逐步骤解释了。

对于AVS,因为这是Cisco自家的产品,可以支持OpFlex,所以APIC可以通过OpFlex探测到VM的上线,当然由于APIC和AVS通常属于不同的blade/host,因此中间要经过ACI Leaf做一次中继。

vSwith上的转发模式有以下3种可选:FEX模式,vSwitch收到的流所有量都通过ACI Leaf处理,即使源和目的在同一个vSwitch上;Local Switching模式,同一个EPG内部的流量在vSwitch本地执行应用策略,跨EPG的流量送给ACI Leaf处理;Full Switching模式,vSwitch可以在本地处理处理同一个EPG内部的流量以及跨EPG的流量。后面两种模式只有AVS可以采用,因此本地执行应用策略要求vSwitch支持OpFlex。

(四)转发过程分析

先来看ACI对于ARP的处理。ARP的处理有两种方式,第一种就是泛洪,第二种就通过ACI Spine来做Proxy。第一种自不必说,第二种实现中当ACI Leaf收到ARP后封装VxLAN-GBP送给一个ACI Spine, ACI Spine的hardware database中存有MAC/IP的映射关系,ACI Spine将重新封装VxLAN-GPE的包头将其送给目的所在的ACI Leaf,从而抑制了ARP的泛洪。ACI默认开启的是第二种,第一种常用于默认网关位于ACI Fabric之外的情况下。

对于单播流量,如果ACI Leaf不知道目的地在哪,就封装VxLAN-GBP送给一个ACI Spine做代理,如果ACI Spine也不知道目的地在哪就在EPG内进行泛洪,否则查表后重写VxLAN-GBP进行定向的隧道单播。ACI Leaf的转发表项分为local entry和global entry,local entry存着所有本地VM的转发信息,global entry缓存着一些远端VM的转发信息,而ACI Spine中则记录着完整的global entry。对于L2/L3来说,其转发过程都是这样的,当ACI Leaf收到数据包时,如果目的MAC是否为分布式路由器的任播MAC则进行L3转发,否则进行L2转发。L2的转发参考MAC entry,L3的转发参考IPv4/v6 entry,而且L2的流量实际上也可以通过匹配IP地址来完成转发。需要注意的是,与标准VxLAN中VNI只能指代VxLAN Segment不同,当进行L2转发时VxLAN-GBP中的VNI指代L2对应的Bridge Domain,当进行L3转发时VxLAN-GBP中的VNI则指代L3对应的Network。

对于组播流量,同样是由Spine作为Proxy通过头端复制的形式进行伪广播,这样可以避免在ACI Fabric上使用IGMP和PIM。

当转发需要跨数据中心时,需要在ACI Border Leaf和远端VTEP间运行MP-BGP EVPN作为控制平面来学习转发信息。EVPN是一个标准协议,远端VTEP并不要求是ACI Leaf。

(五)再议ACI与SDN

ACI的技术实现就分析到这里了。概括地说,ACI就是北向GBP + 南向OpFlex,ACI的SDN完全是围绕着应用策略来做。“以应用为中心”,说白了就是一个向上开放API、向下能够自动部署的Policy Profile。其实,这更像是一个被Cisco明确喊出来的口号而已,由于数据中心向来有着自动化管理的诉求,因此绝大多数数据中心网络厂商在其解决方案中都可以提供Policy的编程能力,只不过一般都是针对一个EPG的,并没有向ACI提供ANP这种端到端的Policy Graph。端到端固然吸引人,但是这也必将导致Policy的制定异常复杂。对于网络管理员来说,写好一个ANP不会是件容易的事,甚至可能要比敲设备的CLI还让人头疼。

响亮的口号总是让用户很受用的,但实际上醉翁之意不在酒,这只是Cisco继续保留“网络黑盒”做SDN的幌子罢了。不过,在数据中心的场景中,“网络黑盒”确实也不会是一个大问题,毕竟用户更关心的是虚拟机上的应用负载,从用户的角度来看SDN的最大价值就仅仅是为应用提供更灵活的连接。从SDN界的角度来看,ACI的技术路线确实有点“半吊子”,很多人把ACI看做一个超级网管,或者说是“网管的网管”,关于“ACI究竟属不属于SDN”的讨论不绝于耳。

从我个人的观点来看,ACI仍属于广义上的SDN,只不过其“软件定义”的能力不那么彻底罢了。Cisco作为传统网络厂商中的“大哥大”,又怎么会情愿把设备的控制权开放给别人?技术路线的考量从来都是以商业目的为基点的,Cisco选择走ACI这条路线自然无可厚非。而且,为了将转发的控制权保留在设备本地,又要能在一定程度上体现集中式的控制,ACI在技术上有很多新颖的、值得学习的尝试。为此,Cisco颇费周折地设计了ACI Spine,为了在ACI Spine上支撑大规模的hardware mapping,当初Insieme甚至还为N9K设计了专用的芯片,这也导致ACI不仅仅不能兼容的厂家的设备,甚至连Cisco自家的其他N系列产品都没办法跑在ACI Fabric中。

从ACI发布的时候开始,Cisco就一直在制造舆论要干掉NSX,但实际上两者现在基本上是平分秋色,NSX还要处于稍稍领先的位置。前有NSX后有白牌,ACI未来究竟会发展如何,技术层面的东西都是次要的,最终还要看各方在市场上的博弈,这场战役反过来也可能会为数据中心SDN未来3-5年的技术形态奠定基调。

Q&A

Q1:转换成设备能够理解的配置是cli配置?

A1:不一定是转化为CLI,没有了人机交互,CL本身就也没什么意义了

Q2:请教下,aci里安全组怎么实现的?另外avs支持三层吗?

A2:安全组就是策略,通过Contract实现,可以用服务链串专业的安全设备。AVS没实际用过,个人猜测不支持三层

Q3:ACI下发策略不是要求服务器也用Cisco的吗?

A3:APIC要部署在UCS里。HOST无所谓

Q4:那个部件实施contact?avs还是leaf?

A4:都可以,avs也叫vleaf

Q5:总感觉通过GUI能做到的很少

A5:我都是Python做,不用GUI,很多客户也不用GUI,没必要GUI

Q6:对应aci是通过什么部件实现的?

A6:Neutron ACI driver先送到APIC VMM Manager,VMM转给ACI Policy Manager,PR转成MIT上的语意,通过OpFlex下发给N9000,如果是vleaf,通过N9000代理OpFlex,最后执行在N9000/AVS

Q7:VxLAN-GBP里的LB/LP位是干吗用的?

A7:LB用来做ECMP,LP用于策略

本文分享自微信公众号 - SDNLAB(SDNLAB)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2016-08-04

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏钱塘大数据

中国互联网协会发布:《2018中国互联网发展报告》

在2018中国互联网大会闭幕论坛上,中国互联网协会正式发布《中国互联网发展报告2018》(以下简称《报告》)。《中国互联网发展报告》是由中国互联网协会与中国互联...

13750
来自专栏微信公众号:小白课代表

不只是软件,在线也可以免费下载百度文库了。

不管是学生,还是职场员工,下载各种文档几乎是不可避免的,各种XXX.docx,XXX.pptx更是家常便饭,人们最常用的就是百度文库,豆丁文库,道客巴巴这些下载...

44630
来自专栏钱塘大数据

理工男图解零维到十维空间,烧脑已过度,受不了啦!

让我们从一个点开始,和我们几何意义上的点一样,它没有大小、没有维度。它只是被想象出来的、作为标志一个位置的点。它什么也没有,空间、时间通通不存在,这就是零维度。

33630
来自专栏Ken的杂谈

【系统设置】CentOS 修改机器名

18130
来自专栏haifeiWu与他朋友们的专栏

复杂业务下向Mysql导入30万条数据代码优化的踩坑记录

从毕业到现在第一次接触到超过30万条数据导入MySQL的场景(有点low),就是在顺丰公司接入我司EMM产品时需要将AD中的员工数据导入MySQL中,因此楼主负...

29740
来自专栏腾讯高校合作

【倒计时7天】2018教育部-腾讯公司产学合作协同育人项目申请即将截止!

15720
来自专栏腾讯社交用户体验设计

ISUX Xcube智能一键生成H5

51220
来自专栏FSociety

SQL中GROUP BY用法示例

GROUP BY我们可以先从字面上来理解,GROUP表示分组,BY后面写字段名,就表示根据哪个字段进行分组,如果有用Excel比较多的话,GROUP BY比较类...

5.2K20
来自专栏前端桃园

知识体系解决迷茫的你

最近在星球里群里都有小伙伴说道自己对未来的路比较迷茫,一旦闲下来就不知道自己改干啥,今天我这篇文章就是让你觉得一天给你 25 个小时你都不够用,觉得睡觉都是浪费...

21740
来自专栏怀英的自我修炼

考研英语-1-导学

英二图表作文要重视。总体而言,英语一会比英语二难点。不过就写作而言,英语二会比英语一有难度,毕竟图表作文并不好写。

11910

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励