云计算的基本概念和常见测试点

大数据 专栏收录该内容
18 篇文章 0 订阅

云计算的定义

对云计算的定义有很多方式,其实每种定义都能反映云计算的一些特点,比较常见的定义如下:

  • 美国国家标准与技术研究院(NIST):云计算是一种按使用量付费的模式,这种模式提供可用的、便捷的、按需的网络访问,进入可配置的计算资源共享池(资源包括网络、服务、存储、应用软件、服务),这些资源能够快被快速提供,只需投入很少的管理工作,或与服务进行很少的交互。
  • 刘鹏教授对云计算给出了长、短两种定义:
  • 长定义是:云计算是一种商业计算模型。它将计算任务分布在大量计算机构成的资源池上,使各种应用系统能够根据需要获取计算力、存储空间和信息服务。
  • 短定义是:云计算是通过网络按需提供可动态伸缩的廉价计算服务

云计算的特点

  • 并行计算(Parallel Computing)、
  • 分布式计算(Distributed Computing)
  • 网格计算(Grid Computing)
  • 虚拟化(Virtualization)
  • 效用计算(Utility Computing)
  • 将基础设施作为服务IaaS(Infrastructureas a Service): 消费者通过internet可以从完善的的计算机基础设施获取服务(硬件服务器租用)
  • 将平台作为服务PaaS(Platform as a Service) :软件的个性化定制开发
  • 将软件作为服务SaaS(Software as a Service):通过internet提供软件的模式

云化的基本概念

Cloud Native概念:核心改变是应用适合基础设施,而不是基础设施适合应用

应用上云

  1. 微服务架构:不是开发一个巨大的单体式的应用,而是将应用分解为小的、互相连接的微服务。一个微服务一般完成某个特定的功能,如下单管理、客户管理等,每个服务都有自己的数据库,微服务之间的数据传递可以通过服务暴露出的API来完成。
  2. Docker: 构建在LXC之上、基于进程容器的轻量级VM,非常适合微服务。

大数据上云

数据上云,一般来说有两种经典模式:

  1. 托管模式: 核心是通过云的能力简化了集群的创建、运维,以Amazon EMR为典型代表。
  2. 服务化模式:进一步简化了大数据的使用,用户不用关心集群、资源这些事情,只需要将大数据任务提交给大数据云,享受相应的服务即可,经典代表是微软的Azure Data Lake Analytics。

上云测试

功能性测试点

  • 功能测试:即确保被测系统所提供的服务符合预期,主要包括如下方面:
  • 系统验证测试:端到端的测试
  • 用户验收测试:
  • 互操作性测试:切换基础设施,仍然能无缝工作

非功能性测试点

这些非功能性硬核关键点和云计算的特性有着必然的关系,同时也和服务的可靠性,服务的计量和治理有着密切的关系。简单来说你要保证你的云服务的可靠性,可用性,可管理性,必须具有一些云化后的非功能性指标,因为你业务功能再好用,不可靠,对用户来说是没有保障的,如下8个硬核点就是云化的非功能指标,后续一节再分别讲述,这些硬核点的的定义以及如何来测试这些点,特别是第1,第2,第3,这三个缺一不可,否则你的软件只是搬到云端,并不具备任何云计算的特性,也就是假云。

  1. 弹性,也叫自动伸缩
  • 说起弹性,先从常说的云服务器,ecs 说起,它就是Elastic Compute Service的缩写 ,是一种处理能力可弹性伸缩的计算服务器,这是从IAAS (更偏硬件资源:CPU,内存,磁盘,网络)层来实现弹性,这解决了硬件或是底层资源的弹性;实际从提供云服务的软件层现来看,还要有软件自身的弹性,例如,需要根据时间或是其他的策略(基于流量,或是硬件资源的特定基线)横向扩展,如高峰期,挂号服务需要10个节点才能保证支撑高峰期的并发量,非高峰期,再减少挂号服务节点,腾出计算资源做其他事情。在云上,实现集群节点的扩展是很简单的事,配置好扩展策略即可。测试的时候, 必须把弹性作为一个check point ,如何验证,从前面其定义就能明白,这里就不再重复了。现在问题来了,动态扩的服务,如何让集群感知,且可用呢,请看如下第2项
  1. 服务无状态
  • 接上一个问题,动态扩的服务,如何让集群感知,且可用呢?让集群感知有两个办法,一是服务在横扩的时候,向ELB(负载均衡)动态注册(如果扩展了节点,需要手动配配置并重启负载均匀相关组件,这不叫弹性),或是通过服务发现注册组件来实现,这有很多成熟的技术,这里就不多说明,重点是,新横扩出来的服务,加到集群后,要让他能对处提供服务,这要求服务是无状态的 ( 比如会话session ,或其他上下文,不依赖服务所在属主容器,如tomcat ,jetty,weblogic ,iis等),否则某个请求被路由到新扩的服务节点时,可能会为因为会话或上下文的问题,导致服务在业务上不可用。测试的时候, 必须把服务无状态作为一个 check point,如果服务实现方,是通过在负载均衡上通过“ 黏住” 策略,来实现会话共享,的话,有一个大问题,当服务节点减少,或是某些服务节点挂掉时,之前这些服务节的服务的客户端后续的请求,转移到其他节点,session 就会丢失,通常做法是,把session或上文下外置在服务线程所在容器(tomcat ,jetty,weblogic ,iis等)之外,如memcache 中,redis 中。

  • 如何验证这个无服务的检查点呢?假定是一个Web 程序,通过关闭单一节点,再重启检查,是否为同一个session。测试这个完全可以在非云环境来验证,用一个单单一节点来测试(非集群模式),比如先登录,进入到某页面,且准备做某个对session 有依赖的操作,这时,停下正要操作的功能,先停掉这个节点,然后重启这个节点,,重启后再在之前登录的页面上,接着做这前的作操作,并没有提示要重登录,或是session过期,操作成功,可以验证;当然也可以用两个节点来验证(集群模 式),每个节点上,放两个相面的页面,在上面,打印出session id ,以及节点的名称,先请求这页面,记下打印的session id 及节点名,关掉任意一个节点,再刷新这页面,看看打印的session id 一样不,如一样,只是节点名变了,说明服务是无状态的。还有其他方法,这里只是抛砖引玉,提供一下思路。如纯后台API ,只要检认证信息是否过期,或是是否是同一个认证信息。

  1. 多租户支持
  • 既然是云上的服务,必须要求不同的客户(租户/单位/组织)都能使用,且互不影响,实现多租户,通常有两种隔离方式,逻辑隔离和物理隔离;逻辑隔离指,大家其用一套系统,只是在数据库层在表中加一个字段,数据所属租户;物理隔离,这每个租户单独部一套系统。测试的时候, 必须把多租户支持作为一个 check point,测试方法,通过对隔离的阐述,自然就知道如验证,支不支持多租户,以及是以什么方式隔离。上面示例中,租户注册成功后,调用CloudFormation接口,自动部署的云进销存业务系统,这实际是物理隔离
  1. 故障转移/隔离
  • 云服务,一定会有出故障的时候,为了保政故障产生的影响最小,必须有应对故障的策略,故障转移也分两个层面的,,一个是IAAS层的,一个是业务服务自身的故障转移。如整个系统宕机,或是有故障,利用镜像,自动重新实例化一个实例,只是网络属性未变,这是IAAS层面的,在PAAS看来,实际是和之前是无差别的,相当于,传统方式下,快速启用冗余或备用的服务器、系统、或者硬件接替它们工作;另一个是软件层面,业务服务系统,在服务不可用时,支持的重试逻辑,同时支持重试,就要求保持幂等性(简单说,对同一个数据做同一个操作,做一次和做N次,结果是一样的),或对出错的服务进行隔离,不隔离会引发雪蹦效应,或是采用服务降低的错施。一句话,测试的时候, 必须把故障转移/隔离作为一个 check point, IAAS层的转移,只需向云厂商确认即可,基本上云厂商这层面都已实现,软件方面的故障处理,需要根据隔离策略来执行相应的测试,细节具体根据具体应用再详查,主要是不要漏过这个测试点
  1. 服务限流保护
  • 既然是公有云,面向的是所有你的客户,某些情况下,访问量会爆增,或是受到恶意的访问攻击,这时服务的可靠性,隐定性也必须得到保障,通过对并发访问/请求进行限制或者一个时间窗口内的请求进行限速来保护系统,一旦达到限制速率则可以拒绝服务或者排队等待,从而使服务不会引过多的访问而崩溃,这就是限流。

  • 测试方法,通过压测,或是增加到并发量,到系统支持的极限后,系统有没有因访问量太大而崩溃。测试的时候, 必须把服务限流保护作为一个 check point

  1. 应用安全
  • 服务放云上,面向整个互连网,除了要应对恶意的攻击,还要防止服务器被劫持,还要保证数据安全,和授权内访问等等,安全是一个很专业的一个方向,测试的时候, 也必须把安全作为一个 check point, 测试人员在这方面,只能做一些常规的安全测试,如SQL 注入,XSS跨站攻击,敏感信息是否明文传输, API的访问是否要通过验证,一些等存级别高的业务,还需要双向认证,甚至实名认证等,其他的则需要请专业的安全公司进行全面的安全测试,他们能扫描出系统存在的安全漏洞和不安全的因素,并给出好的整改建议。
  1. 调用链追踪
  • 这要看服务是否是一个分布式应用,分布式应用中,系统存在互相调用的情况,形成一个 调用链,通常一个请求,会引发A组件,调用B,组件,B组件调用C ,C调用D,可能还有更长的调用链,实话说,调用链追踪,有点偏向于运维,在测试时,分布式环境下,不借助调用链追踪有些问题根本没法定位,比如说,某个请求出错了,实际是错调用链的哪个节点上,或是某个功能很慢,慢在哪,不借助于调用链追踪,你都没办法跟程序,就算让研发自己打断点,也要搞死人的,分布式加集群,同一个服务,每次调用时,调用链都可能不一样。上云的应用,通常是分布式用,作为测试人员,也有必要把调用链追踪作为一个 check point,才能在分布式场景下,提出定位更准,更专业的问题,而不只在BUG的表像上。开源调用链追踪有zipkin,pinpoint,skywalking等。调用链跟踪需要研发那边来集成,测试这边要get到这个点和会使用。下图是昨天用zipkin 的一个截屏示例
  1. 可视化服务治理(可观测,可自动健康检查,服务优雅关闭等)
  • 服务治理,也是偏运维的东东,他自身的定义,各位可以自行百度;在这里,我只简单场景上来说明,服务治理的大概意思,你的服务在云上,可靠性要有保障,主要在于预防,不能抓瞎,真正问题发生了,就炸锅了,需要通过可视化的方式,观测到服务的状态,健康状态,流量情况,响应速度,并发量,资源使用情况等,并根据于些,采用自动或半自动的方式启动弹性扩展,或是采取隔离,熔断等措施,以保障服务的可用性。在devOps 大行其道的当下,测试人员向运维多靠一点不是坏事,会给测试提供更多灵感和带来更多测试手段。云上的服务。服务优雅关闭,顺带提一下,要关闭某个服务时,正在服务中运行相关业务线程会同进被关掉,也就意味着这些业务操作肯定要失败,与之相反服务优雅关闭,指在关闭前,他会拒绝新的进求进来,同时要完成当前的所有业务后,才关闭,有点像银行的窗口,不接受业务了,但要把当前正办理的业务处理完。测试人员以此作为一个 check point ,可用来验证云服务实现水平的高低,又能为服务的可靠性测试提代相关测试手段/方法,这个点也要get 到。

参考文章:

  1. 大数据架构详解从数据获取到深度学习2016版第9章-大数据云化
  2. https://blog.csdn.net/MYPM_AndyLiu/article/details/90170835
  3. https://blog.csdn.net/weixin_41918841/article/details/95218043
  • 3
    点赞
  • 3
    评论
  • 2
    收藏
  • 打赏
    打赏
  • 扫一扫,分享海报

©️2022 CSDN 皮肤主题:大白 设计师:CSDN官方博客 返回首页

打赏作者

Sugar爻爻

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值