云设备控制方案优化思考

1,306 阅读6分钟

作为一个测试,日常工作不是在发现bug路上,就是和研发battle设计的缺陷。如果对研发设计的功能不能做到比研发直接还熟悉的话,那接下来就会被研发忽悠啦。

云概念流行几年了,很多大厂都推出了SAAS、Laas、Paas等云服务。为了紧跟时代步伐,将手机等IOT测试设备通过网络方式,汇聚到网页端构建云真机系统。借此机会学习一下行业中常见的云真机控制的业务逻辑。

背景

根据网上学习资料,最常见适合中小企业C-APS框架的介绍,一般云真机架构通常由4层组成:设备层、服务层、应用层和用户层。

image.png

暂时无法在飞书文档外展示此内容

  • 用户层:系统一般以WEB网页形式呈现,研发和测试可以通过登录网页方式进行使用云真机设备进行调式和测试使用
  • 应用层:可以根据系统中服务能力提供包括设备控制、在线操作、自动执行等二次功能开发
  • 服务层:包含对设备信息、状态存储的MySQL,存储设备排队执行任务缓存信息的Redis等
  • 资源层:包含所要使用的云真机、还包括控制云真机的硬件设备

框架介绍完了,实验室里存放着两三百台安卓设备一起在线上,除了能做到即用即取外,还需要承接执行自动化测试任务。那么行业最常见的做法是给予每个设备STATUS状态标志位来管理,例如:

  • 红色:设备异常
  • 蓝色:执行任务
  • 绿色:设备空闲

借鉴操作系统中进程七态模型思想,就绪-->运行-->终止 进行改良,初始的云真机调度方式出炉啦

image.png

云真机设备同一段时间内,会存在个人使用和执行任务资源抢占的情况,那么程序上要怎么处理?

首先同一时间,设备可能会出现如下形式的任务,如下:

  • 个人任务
  • Devops任务
  • 手工临时调式
  • 设备功能展示
  • ....等

像前面两种类型的任务分配到设备执行时,会对设备进行锁定,但是对于临时使用的场景,无法对设备进行锁定。当有执行进来时,你所使用的设备将不被自己控制。

大家应该和我一样,找到RD,动之以情地要求增加对临时使用云真机的设备控制,可能就会出现以下场景对话:

我:临时使用设备时,会被自动化任务打断,对用户非常不友好。必须增加一个用户占用功能

RD:这是一个新需求,要排期才可以做...

我:那什么时候可以完成,这个功能对用户非常重要

RD:未知,我尽快安排吧

2000 years later....

RD: 你之前提的那个临时占用的功能开始搞了,现在需求确认

我:要确认哪一些?

RD:你期望这个功能怎么做?

我:与任务执行状态占用设备逻辑一致,但也要与任务执行进行区别吧。简单一点,任务执行设备占用为蓝色,用户占用则为黄色

RD:我要想一想怎么做

优化一:新增用户占用状态

在原基础上,只有空闲、执行和维修三个状态,现在新增一个用户占用,功能很简单,但是需要涉及三个方面:

  • 设备是空闲,用户手动占用。可以执行用户触发的个人任务
  • 设备执行任务过程中,用户可以手动占用,但不能影响正在执行的任务
  • 设备维修状态,无用户占用功能

image.png

占用功能上线后,解决了个人用户在使用过程中,被其他任务中断的场景。新功能上线,用户使用很开心,两天之后,系统又出现问题了。

用户在平台上选择了云真机占用,使用完后大家都不手动释放的。大大造成了,Devops自动化分发的任务无法下发到云真机上使用,大量任务堆积排队等待....

优化二:自动释放功能

由于新增的用户占用功能,没有考虑到设备的回收,导致大量设备被锁定,无法循环使用。紧急联系RD,添加自动释放功能。同样考虑对用户友好性,需要考虑如下几点:

  • 用户手动占用设备前,让用户自定义填入使用时长,默认3H,最大时长72H
  • 设备占用期间有计时器计时,当距离结束15min,邮件提醒是否继续使用
  • 如果用户选择是,则程序自动重新根据初始时间倒计时

根据向RD描述的需求,RD给出的 使用Redis 订阅key来通知和释放超期设备,思路大致如下:

image.png

看到上述实现方案,通过订阅key的方式,可以实时动态监测,且对资源占用少,只用在接收到消息的时候再做处理。

但是该方案会存在,当Redis出现宕机、死锁时,无法对设备状态进行更新,又会出现设备一直占用,任务无法执行情况。

优化三:搭建分布式任务调度平台

行业中找到一款开源框架是XXL-JOB框架,提供一整套分布式任务调度解决方案。

根据开发文档介绍,其核心设计思想是由调度中心和执行器两部分组成,调度中心负责发起调度请求,执行器负责接收调度请求并执行对于的JOBHandle中业务逻辑。调度和任务两部分互相解耦,提高系统的整体稳定性和扩展性。

但该系统,对于刚开始要实行搭建的人来说,要花大量的时间进行学习该框架和熟悉部署文档等,同时该系统需要一个独立的应用部署、配置等成本大。

较于要看到实际结果为导向的,最终该方案被纳入优先最低的,暂时运行方案二。

总结

在实际工作中,前期的需求如果没有理清楚,后续会出N方案来填补前期的坑。针对云设备控制场景优化方案进行总结和梳理。对于测试来说需要与RD一样,熟悉整个方案的设计思想和潜在风险才能将系统bug降到最低。

以上是本期内容,欢迎大佬们点赞评论,下期见~~

本文正在参加 「金石计划 . 瓜分6万现金大奖」