阿里云SDN、NFV技术揭秘

摘要:阿里云的网络产品,为海量的客户提供了私密、灵活、高效、可靠、安全的基础服务,在由和阿里云网络团队联合主办的2017阿里云网络技术在线高峰论坛上,阿里云高级技术专家仙侠就为大家揭开了阿里云的网络产品背后技术架构,并且分享了阿里云网络团队对SDN和NFV相关技术的理解和实践。

本文内容根据演讲嘉宾分享视频以及PPT整理而成。

一、什么是NFV

公有云客户的需求:“既要”、“又要”、“还要”
SDN、NFV的概念对于很多同学而言是比较陌生的,其实在阿里云网络团队最开始设计SDN和NFV的时候对于这两个概念也并没有非常深刻的理解。其实在最开始,阿里云是一切以客户的需求作为出发点来做的。那么问题来了,阿里云是一家面向公有云用户的云计算公司,而做云计算,客户到底需要什么样的功能呢?经过阿里云长期对于客户的调研和分析发现,阿里云所提供的公有云需要能够满足客户们各种各样的诉求,这些需求可以使用三个词形象地概括:“既要”、“又要”、“还要”。

阿里云所面向的是公有云的用户,大体上客户的需求可以分为以下七点:海量租户、隔离性、互联、安全、高性能、可靠性、私密。

  • 海量租户;对于阿里云而言,首先需要解决的问题就是海量租户的问题。海量租户会对于阿里云的系统容量造成巨大的挑战,那么对于用户或者租户而言,他们首先需要考虑的问题就是自己能否与其他人隔离起来。
  • 隔离;所以对于公有云用户,首先需要提供的功能就是隔离。
  • 互联;在实现了隔离之后,用户又会提出新的需求,就是需要实现互联。因为每个租户自己的资源不是一个完全孤立的岛屿,彼此之间必然会存在资源的互联互通,除此之外还需要满足和公网流量进行互通,甚至需要跨机房、跨地区以及出海等各种各样的互联互通需求。
  • 安全;对于公有云用户而言,在云上往往会非常关注的一件事情就是自身产品以及数据的安全,而且用户对于云上安全的需求是非常强烈的。
  • 高性能;当用户上云之后,其所接到的需求也会递增,所以也会期望能够获取性能更高的产品来满足提供更高的PPS以及BPS的需求。
  • 可靠;看似用户的一系列问题都已经满足了,但是实际上还会有更多的需求出现。比如虚拟机一定是存活于某一个宿主物理机上的,那么如果宿主物理机宕机了应该怎样处理,如果整个机房都挂掉了又应该怎么处理,这就是客户对于阿里云的可靠性诉求。
  • 私密;除此之外,客户还会产生一些保护私密性的诉求。比如想要和自己的办公网互通的时候并不会将办公网暴露在公网上,那么就需要将自己的办公网与阿里云的VPC打通,并使得两者能够互联互通而且还能够保护客户的私密性。

以上就是客户对于阿里云所提出的诉求,总结而言就是“既要”、“又要”、“还要”的诉求。

先把网络隔开

阿里云首先需要去满足公有云用户对于网络的第一个需求:隔离。如果对于整个网络进行抽象,那么先隔离开就是为每个租户提供一个完全属于自己的网络空间。在这个网络空间里,用户可以自行购买计算、存储等一系列资源,这样网络对于用户而言称为虚拟网络,而虚拟网络最终是由物理网络承载的。

如上图所示,“先隔开”的概念实际上是包含两个层面含义的。第一层含义是租户与租户之间网络的隔开,也就是每个租户都会有自己的虚拟网络,彼此之间是没有任何关联的完全隔开的网络。可以看到,在虚拟网络中会提供一个虚拟路由器,并且会提供很多个虚拟交换机,而在虚拟交换机下面会挂载计算节点ECS、负载均衡器SLB、云数据库RDS以及缓存OCS等云产品。在整个虚拟网络流量转发路径中,ECS、负载均衡器SLB和云数据库RDS等构成了东西向的流量路径;而ECS的流量需要出公网和其他的网络互联互通,就会需要经过虚拟交换机和虚拟路由器进行流量交换,以上就是虚拟网络层面的隔开。

而在另外一个层面的隔开是这样的理念:阿里云希望用户与用户的流量可以完全隔开,并且采用通用的Overlay技术方案。Overlay并不是一个新的概念,其有很多的实现方案比如IPONIP、XLAN等,阿里云采用的是XLAN方案。在XLAN方案中,为每个用户提供了一个具有XLAN地址空间的VPC网络,在这个网络里面实现了虚拟网络隔开和物理网络隔开。在物理网络隔开方面,普通的组网里面有一个核心交换机、一个接入交换机以及最下面的物理服务器,这是物理网络接入的基本情况。如果在传统的网络里面,路由以及流量的交换等一系列功能实际上是由传统的交换设备来实现的,那么如果想使用Overlay的技术把这些功能分开,把路由以及交换的功能做到虚拟网络里面之后就会发现物理网络变得非常简单,这也就意味着物理网络的可靠性以及稳定性会更好,这也是阿里云网络团队多年以来得出的经验。所以对于物理网络的需求就是只要物理网络达到2层或者3层互通即可,而一系列复杂的逻辑会在虚拟网络中完成,如此就能够形成上下完全隔离的一张网络。这样的做法会带来非常多的好处,比如对于物理网络而言,它并不知道虚拟网络的流量是如何转发的,而只知道将虚拟流量包装成为XLAN之后在物理网络中去跑,这是一个非常简单的拓扑关系。在虚拟网络中的虚拟路由器、虚拟交换机等实际上都是虚拟的网络设备,这也就是NFV的概念。

光隔离不够,还要互通

在实现了隔离之后,实际上还远远不够。用户的诉求还有很多,其中比较典型的就是互通。云上的客户对互通的需求大致可分为四类:

  • 私网互通。私网互通不仅包括VPC内部的私网互通,还需要包括同一用户的两张网络之间的互通。
  • 公网互通。公网互通属于必备的功能之一,它也是混合云接入的一种方案。ECS搭配公网IP来联通公网是其中的一种方式,除此之外,用户还会需要另外的方式。举个例子现在每个家庭中都会有自己的无线网络,自己的手机等设备连接上无线网络之后就可以连接到公网,也就能够享受到SNAT服务。所以对于用户网络而言,是具有联通公网的需求的,也就是用户网络会具有SNAT和DNAT的一系列需求。
  • 用户IDC。对于普通用户而言,私网互通和公网互通这两种形态已经能够满足绝大部分的需求了,但是实际中还会有一些用户具有特殊的需求,比如这些用户的线下机房是属于IDC的,线下机房扛起平时的流量已经足够了,但是会有一些流量的高峰出现,比如举办活动或者新闻热点出现的时候,所以需要有一个弹性扩展的机房空间。对于这样的场景,阿里云提供了专线接入方案,最后得到的效果就是把用户的IDC就近接入一个阿里云的POP点,这样就可以实现IDC和阿里云VPC之间的互联互通。就阿里云对于用户的了解来看,对于上述这样的方案,用户会存在两种诉求:第一种诉求就是用户需要非常可靠的接入,不仅可靠还需要延迟比较低,这是一种硬专线的接入方式。还有一种诉求就是需要较为灵活的接入方式,也就是软专线的接入。
  • 跨地域互通。除了能够用上述三种方案满足需求的用户之外,阿里云还有一些用户的业务分散在全国各地甚至世界各地,这样的用户往往就会产生跨地区甚至全球互通的需求。

自研是解决互通之道
如下图所示的是阿里云设计的整体网络拓扑图。阿里云在为用户提供网络解决方案的时候也会考虑几套方案,其中第一种方案就是使用交换设备来解决问题,而这种方案会带来两个问题,第一个问题就是包括交换设备在内的硬件的研发周期往往会比较长,这样就容易跟不上用户需求发展的节奏,可能导致当用户的需求提出之后,却迟迟无法实现,所以这样的方案就会受制于硬件。而依赖于硬件也会带来另外一个问题,因为像交换设备这些硬件设备的升级都是需要重启的,而设备重启会对于用户的业务产生时间点不可精确控制的影响。所以从整体层面上来看,阿里云认为通过硬件方式实现解决用户网络的问题会存在很多弊端,因此阿里云选择了软件的方式,通过自研一些网络设备解决了上述的问题。

上图中有几点需要说明,其中的虚拟交换机、网络设备和控制器这三部分都是阿里云自研的产品。从上向下看这张图,自研网络设备会承载用户IDC机房的流量和VPC流量的专线流量互通,也就是自研设备会承载两个设备之间的流量,将其打通。除了用户IDC之外,还有公网南北向的流量,南北向的流量是由自研的网络设备承载的。虚拟交换机承载的是东西向流量,比如VM和RDS数据库进行东西向数据交换的时候,是需要经过虚拟交换机的。所以,从数据层面上来看,自研网络设备和虚拟交换机设备之间的分工都非常明确。而在控制层面,自研的控制器对自研的网络设备和虚拟交换机会进行流表和转发表的下发,实际上是由自研控制器来控制整个转发行为。在控制器上面可以见到的控制台以及售卖等一系列的配套周边资源。对于整体网络拓扑图而言,从上往下以及从左往右的分工都是非常清晰明确的。

自研节点可靠吗?
这里可能有同学会产生疑问:这么多自研的东西是否靠谱呢?对于这个问题,阿里云网络团队在研发的时候也经常自问,这些设计真的靠谱吗?真的能够解决问题吗?当发生故障的时候真的能够把对于用户的影响降到最低吗?所以在阿里云网络团队设计整个产品的时候就已经把产品的可靠性考虑在内了。阿里云网络团队思考了很多,认为冗余容灾仍旧是最重要的手段。在如下图所示的拓扑图中,自研的网络设备是集群化的,而集群是由多台设备组成的,也就是说首先这个集群是可以水平扩展的,当流量达到水位之后就可以通过水平扩展来抗住更多的流量。第二点,设备之间实际上是没有关系的,也就是说当集群中某台设备宕机了,流量可以自动被其他的正常的设备承担,这样就可以做到对于用户没有影响,用户无感知热升级也是阿里云的技术优势所在。

除此之外,如果网络节点只在一个机房,如果机房挂掉怎么办?这就涉及到容灾的另外一个层面,也就是机房和机房之间的容灾。比如在上图中,机房1中自研的网络设备和机房2中自研的网络设备之间形成的是互为主备的备份关系,这样在没有网络设备故障的时候,机房1和机房2的设备都抗住自己的流量,此时机房1的备也是机房2,而机房2的备也是机房1,他们互为主备都是Active的。而当机房1发生了故障之后流量就会自动迁移到机房2上去,这样就可以实现瞬时的容灾。而自研的控制器采用的也是类似的方案。也就是从这个层面上来看,所有的自研方案都可实现容灾和备份,并且能够实现机房之间的容灾冗余,使得机房能够非常可靠地提供服务。

安全、安全、还是安全
安全永远是公有云用户排在第一位的诉求。这里的安全特指公网层面的安全,公网其实是一个非常脆弱的地方,如果用户将自己的服务暴露在公网上,往往会有黑客进行攻击或者破坏。接下来就分享阿里云对于公网安全的处理逻辑和采取的方案。

首先,当公网流量进入到阿里云的时候,会有一个旁路的检测设备,这就是流量的清洗中心。当流量进入到机房之后,旁路检测设备就会对于流量进行检测和分析,如果发现其中包含攻击流量就会对它进行清洗。而且这里旁路检测设备的清洗能力是TB级别的,也就是说如果TB级别的流量过来都能够在这里清洗完成。当然清洗的过程是需要一定的时间反应的,在这一时刻流量也会透到下一层的自研的边界网关设备上。在边界网关设备上也需要有TB级别的容量,也就是当清洗设备还没有完成清洗工作之前,边界网关设备需要扛起全部流量,这里包括了正常流量和攻击流量。当流量到了边界网关设备之后接下来会经过一系列的处理流程对流量进行分析和限速。如果流量达到了限速的标准,就会将流量限制下来,到这一步就能够抵抗住大概60%~70%以上的攻击流量,经过限速处理完了之后流量就会通过黑名单的过滤流程。其实限速这个环节是比较模糊的处理手段,而过滤这个环节则是比较明确的处理,谁有问题就直接丢掉谁,在经过了过滤阶段之后,就能够抵抗住大概90%以上的攻击流量。最后流量会到调度中心,调度中心会对于流量进行采样分析,将攻击流量甚至包括一些畸形包检测出来最终反馈给过滤环节,以此来丰富过滤环节的处理,让过滤环节更好地处理流量。

控制器抽象出虚拟的网络组件

在虚拟网络上已经有很多的虚拟组件了,比如大家在VPC中所见到的虚拟交换机、虚拟路由器,这是两个最常见的虚拟组件。虚拟交换机为其下的ECS、RDS等产品提供数据交换的服务,而虚拟路由器则允许用户在其上加一些路由来控制整个网络流量的转发。虚拟边界路由器可能大家看到的比较少,其主要应用在有专线接入的场景中。虚拟边界路由器一端连接用户的IDC,另一端连接阿里云的VPC,这里的VPC会与阿里云上的虚拟路由器关联起来,但是又不是直接和虚拟路由器直接连接起来的,实际上中间需要借助路由器接口,也就是虚拟路由器和虚拟边界路由器都会有一个接口,这样中间连接起来。还有就是虚拟NAT网关,以及阿里云刚刚推出的虚拟VPN网关等虚拟网络组件。

阿里云的云市场
在介绍了这么多阿里云官方提供的NFV之后,其实用户可能还不过瘾,因为用户的需求层出不穷,所以还可以去阿里云的云市场上去搜寻相应的功能。

阿里云的云市场能够提供丰富的产品,并且打包成镜像,如果大家有需要可以按照镜像去购买一个ECS,这个ECS就能够达到想要的功能,比如云市场能够提供路由器、防火墙、VPN以及DNS等各种各样的NFV。那么如何玩转这些NFV组件呢?其实这些NFV组件都是存在于ECS中的,也就是用户可以选择云市场中的镜像,并用镜像来生产一个ECS,这个镜像中就提供了VPN等一系列的NFV功能。而对于用户而言,他们所需要的是可靠的NFV服务,那么想要实现可靠性至少需要两台ECS,如同上图中所示的1.4和1.3就是一个NFV组件的两台机器,这两台机器之间在跑一个VRRP的协议,这样可以形成一个主备的高可用服务。当组装出NFV服务以后,问题就来了:1.2和它之间还能联通吗?其实还需要另外一个环节在于路由表。阿里云向用户提供开放用户对路由表控制的一整套方案,比如需要访问哪一个地址,下一跳需要跳到哪里,形成这样自定义的一个路由将流量导到这两台NFV的服务器上的一台上,因为两台中一个为主,另外一个为备。这就是在云市场上,用户通过DIY方式解决自己需求的方案。

二、什么是SDN

上面主要介绍了NFV以及虚拟网路组件以及NFV如何去满足用户的互联互通、安全、隔离等等一系列的需求,那么问题又来了,究竟什么是SDN呢?

阿里云的SDN架构
阿里云网络团队在最初设计网络产品的时候对于SDN这个概念也不是十分理解的,但是随着产品以及技术架构的逐渐演化,发现所做的东西就是SDN的产品。阿里云的SDN架构图如下所示,最下面一层是硬件层,这一层包括服务器、网卡、交换机、路由器、物理网络以及光纤等硬件设备。在硬件层之上是数据层,数据层则包括了之前所提到的边界网关、虚拟网关以及虚拟交换机等转发层面的东西。在数据层之上是两个管控层——控制层和自治层,控制层主要负责生产虚拟机以及IP等,而自治层主要负责对于整个SDN系统的部署、运维、自制以及整个运维故障的发现和自愈这样一系列的管控。在自制层中有很多个模块对于业务进行监控、信息采集以及流量采样,之后会根据这些信息进行趋势的预判和预测,并且根据采集的数据来判断是否报警或者进行故障的自愈。在管控层面之上是产品层,这里包括了VPC、负载均衡以及公网IP等云产品。

对于SDN的一点浅见:运维自动化
其实阿里云网络团队对于SDN的理解中最重要的一点就是自治和自愈,SDN需要能够管理得了这个网络、治理网络并且发现问题之后需要让网络能够自愈,将故障修复。也就是说运维的自动化是对于SDN最核心的一点理解。

用户看得到也摸得着的SDN
除此之外,阿里云还希望开放整个SDN的功能给用户,赋能用户来管理自己的这张网络,让用户能够看得见并且摸得着还能用得了。比如在网络层面,阿里云希望能够使得用户想要怎么连接就能够怎样连接,想要怎样控制就怎样控制,按照用户自己的需求去跑。阿里云还希望赋能用户网络的弹性伸缩以及迁移的能力,当用户的业务流量压力上来之后,可以实现整体业务的扩展来抵抗业务的高峰,当高峰过去之后,希望能够自动地缩回去。并且阿里云希望能够为用户提供自动热迁移这样的一系列功能,帮助用户能够更快速地解决自己业务中的问题。对于弹性公网IP而言,阿里云为用户提供了一系列的方案,弹性公网IP既可以绑定给ECS也可以绑定给SLB,还可以绑定给HIVIP等,总而言之就是公网IP可以随意绑定,并且可以随意变配,并且通过Open API 、混合云产品以及可选择的计费方式来为用户提供更多的网络管理方式。

三、NFV与SDN实践

新浪微博的实践案例
对于微博而言,每当出现新闻热点、大型活动或者除夕、春晚等节日的时候往往会有突发的流量上来。实际上,微博选择基于阿里云构建混合云平台,微博自己的IDC机房和阿里云之间拉了一根专线,那么这就相当于微博在阿里云上获得了一个弹性的机房,在这个弹性机房VPC里面,微博系统可以非常快速地扩展自己的计算资源,某一年的除夕当天,微博日活跃用户首次突破1亿,同比上一年同期大幅增长了近50%。通常大家的印象是当用户量上来之后,成本也会随之上升,但是实际情况是即使微博的业务量上升了那么多,但是其成本却降低了很多,这就是阿里云的VPC以及ECS所带来的一系列技术红利。阿里云可以实现在10分钟的时间内为微博提供数千台ECS,可以让微博系统的计算资源规模翻倍,提供更高的计算能力。

很多同学在搭建网站或者做一些服务的时候,传统情况下需要租赁机房和机柜,还会需要购买电力、搭建网络,这一系列的活动可能需要花费很久的时间才能获得计算资源,但是对于微博而言,阿里云仅用10分钟就可以将其计算资源的规模翻倍,这是技术进步所带来的效率的巨大提升。

四、如何面对飞速发展的未来

其实阿里云的步伐已经很快了,但是这个世界的变化得更快,客户的需求会更多,未来应该怎么办呢?其实对于阿里云网络产品而言,未来主要有以下三个层面的发展方向:

  • NFV。从产品形态层面而言,阿里云会加大对NFV以及相关云产品的研发。包括为用户提供智能DNS私网定制,为用户提供VPC内部的一套域名解析方案,能够帮助用户很容易地实现两地三中心的网络架构,从而使得用户能够快速地应对突发情况。IPSEC接入网关属于VPN网关,这个目前已经实现了,并且目前已经处于公测期了,未来VPN除了支持IPSEC之外,还会支持SSL2协议。除此之外,还会有GRE接入网关和子网路由,让用户在子网中自己定义路由来控制更细粒度的流量的转发。
  • 拥抱大数据。由于目前用户的反馈是认为VPC像是一个黑盒子,用户看不到整个VPC的流量是如何走的,也看不到每个包是怎样流动的。所以阿里云网络产品未来会在数据方面进行一系列的加强,会采集数据并对于数据进行分析,为用户提供数据流动的解决方案,让用户能够看到每个数据包在网络中是如何流动的。
  • 增强用户体验。当实现了数据采集以及数据分析以后就可以为用户做更多优化用户体验的事情,比如实现网络可视化,可以实现所见即所得,使得业务可视化。除此之外,还需要实现能力的拓展,比如实现全球加速和接入的能力,让更多的用户能够找到最近的接入点能够将自己的IDC机房或者资源与阿里云进行打通,这也是阿里云努力的方向。最后,因为用户的需求是层出不穷的,没有办法满足所有用户的需求,所以阿里云也会开放第三方开发者云生态平台,提供一系列的API让用户调用,形成第三方的市场来让更多的开发者为用户提供NFV的服务。
时间: 2024-11-01 22:22:36

阿里云SDN、NFV技术揭秘的相关文章

阿里云SDN/NFV之架构与实践

摘要:在10月23日阿里云网络技术演讲上,来自阿里云网络产品团队孙成浩(花名:梵叶)分享了<阿里云SDN/NFV之架构与实践--一次自然的技术演进>.作为网络产品团队中负责产品相关的技术架构架构师,他结合阿里云的网络云产品探讨了阿里云虚拟网络的网络技术架构,并且结合SDN和NFV分享了阿里云的思考和实践. 他的演讲内容主要分为三个方面:1.为什么抽象出来了SDN和NFV的概念,如何一步一步摸索出这两套架构 2.如何理解SDN和NFV?.3未来的SDN/NFV架构上的展望.以下是本次演讲上的发言

数据库诞生40年,阿里云AWS用技术推动第三次变革

本文讲的是数据库诞生40年,阿里云AWS用技术推动第三次变革,数据库诞生于上世纪50/60年代.1961年美国通用公司研发第一个数据库系统DBMS诞生.1976年霍尼韦尔公司(Honeywell)开发第一个商用关系数据库系统-Multics Relational Data Store.至此,数据库就开始融入各行各业,改变人类对数据的管理和认知,发展到如今诸如登录淘宝购物.社交软件聊天,都离不开数据库. 数据库,无处不在 在2017杭州云栖大会前夕的9月21日,阿里云发布全新一代云数据库产品POL

蚂蚁金服&amp;阿里云在线金融技术峰会全套资料(视频+PDF)公开!

8月30-31日我们成功举办了"蚂蚁金服&阿里云在线金融技术峰会".本次峰会聚焦数据库.应用架构.移动开发.机器学习等热门领域,帮助金融业技术开发者深入解析互联网应用的前沿应用与技术实践.目前相关活动视频.整理文章已经出炉,整理如下,供大家参考. 蚂蚁金服&阿里云在线金融技术峰会精彩回顾:https://yq.aliyun.com/activity/109 为了让大家更好的了解本次峰会议题和分享讲师,我们汇总了本次议题介绍如下,供大家参考.在峰会开始前,邀请大家仔细看下

视频内容谁来保护?阿里云视频加密技术大揭秘,打造云上视频安全体系

视频行业的从业者--尤其是在线教育.财经分析等重视内容版权的播放平台都知道,视频安全是一个非常重要的基础需求.用户通过一次付费行为,就可以拿到付费视频的播放URL,将播放URL进行二次分发,这种行为叫做盗链:用户直接将视频下载到本地,然后再进行二次上传分发,这种行为叫做盗播,这两种行为都会给内容版权方造成十分严重的经济损失,面对日渐增多的盗链和盗播情况,我们应该怎么样去保护内容呢? 阿里云最新推出的 视频加密解决方案 对视频版权的保护可以从视频处理的各个环节来分别实现.阿里云通过转码.播放.分发

阿里云表格存储技术分享

  下面是之前在一个技术群里面分享的阿里云表格存储的内容,因为时间因素,只对[技术分享附件]中的少部分内容进行了分享,下面是分享内容,欢迎下载附件并就里面的内容深入交流.   接下来的内容分为几个方面,第一是背景,就是为什么要做这个东西:第二是几个使用场景,让大家有个感性的认识:第三是系统架构以及该架构如何做到高性能.高可靠.高可用:第四是一些工程经验:我也比较希望大家看看最后的附录中我对垂直和分层两大设计体系的思考,这部分我们可以做更深入的交流.     好,下面正式开始.先介绍为什么要做,大

未来已来!阿里小蜜AI技术揭秘

1.双11的挑战与服务模式的转型 在全球人工智能领域不断发展的今天,包括Google.Facebook.Microsoft.Amazon.Apple等互联公司相继推出了自己的智能私人助理和机器人平台,智能人机交互成为各大公司在人工智能战场上激烈竞争的入口级领域. 智能人机交互通过拟人化的交互体验逐步在智能客服.任务助理.智能家居.智能硬件.互动聊天等领域发挥巨大的作用和价值. 在2015年7月,我们阿里也推出了自己的智能私人助理-阿里小蜜,一个围绕着电子商务领域中的服务.导购以及任务助理为核心的

大数据成健康中国新机遇 阿里云”铺路”医疗技术革新

扎克伯格在给女儿的信中,20次提到"健康"."医疗"等关键词,并坚信"随着科技的发展,我们有望在未来的100年间预防.治疗和处理所有或大部分剩下的疾病."马云也表示,"我们今天如何在医药上面做工作?大数据的目的是让用药更精准,让医院变得更高效." 这并非是企业家高谈阔论,这样的愿景正在逐步实现.在"互联网+"的大趋势下,中国互联网医疗发展迅速.借助云计算低成本和弹性扩展的优势,以及计算的力量,医疗行业正在为

100%移植阿里云移动测试技术,竟仅需1周?! ——移动测试专有云(1)

移动设备大量涌现,终端类型浩如烟海,任何一款设备的兼容性问题都将导致大量用户流失! 移动终端的配置千差万别,碎片化严重又导致APP的全机型适配成本巨大且异常困难! 不仅如此,有一些企业和开发者还面临着以下问题: 安全生产要求 测试数据严禁外泄,使用公有云平台存在数据泄露风险.某些测试包依赖本地网络 . 缺少自动化测试技术经验 搭建一套自动化测试平台成本巨大,对自动化测试的技术深度要求高. 缺少移动机房搭建经验 移动机房不像传统机房,对机房环境有着更加苛刻的要求,运维难度大. 测试终端管理混乱,资

12/08,与阿里云来场&quot;技术约会&quot;

谁要来约会? 良仓孵化器创始人, 运维帮创始人, 卓见云首席架构师, The Associate of Cognizant Technology Solutions, 自发为阿里云做了40余场技术分享的开发者, 等等 听说他们在接到一个神秘电话之后, 觉得意犹未尽,决定从四面八方赶来,赴一场"技术约会" 阿里云的各位同学,也都在紧张的筹备这场"技术约会",希望尽可能的"牵手成功": 大数据产品负责人, 阿里云全线产品用户体验负责人, 阿里云安全产