成功案例 酒店测试环境 V30 设计和实践 来源: 发表时间: 2022-08-20 来源:火狐体育最新官网登录入口 作者:火狐体育app

  李景康,2018 年加入去哪儿旅行,测试开发工程师,负责酒店直连和国际酒店的测试工作。期间负责酒店环境 3.0 设计和实践,获得公司金项奖潜力奖,推动公司软路由推广。目前致力于提升测试环境的工作效率和用户体验。

  去哪儿旅行非常重视测试环境治理,提高开发和测试人员的使用效率。从2018 年就开始了测试环境治理和优化之路,到目前为止总共进行了三轮环境治理和优化。

  环境 1.0 中使用的固定环境,总共有十台固定机器组成,每台机器部署全链路的环境,但随着业务不断发展,原有环境已经不能满足需求:

  测试环境 2.0 使用了基础研发自研的 noah 环境管理系统(下面简称 Noah ),通过模板化解决测试环境微服务应用的管理问题。所有环境信息(应用配置,数据库,配置)都在模板中维护。

  创建环境速率的提升,从配置一套固定环境的几天到 noah 拉起一套酒店环境 30 分钟左右(整个环境约 200+ 服务(应用+数据库/ redis / es ));

  测试环境 2.0 在同规模环境管理/创建方面已经做到行业前列,在 2021 年进行环境效率摸底,收集环境使用痛点问题,准备进行下一轮优化。

  第一个方案,和基础研发同学分析一下,单个模块的时间优化空间不大(投入时间长收益较少),最终我们选择从第二个思路开始优化,是否能够降低单个环境的应用规模。

  而在实际项目中,项目环境其实并不需要全部模块,我们可以让项目环境按需拉取所需要的模块即可,这种方式既可以降低整体创建时间,也可以提高测试环境资源利用率。

  基准环境, 基准环境是一套全链路的稳定环境,当线上代码发布的时候,基准环境代码也会同步更新;

  软路由环境,软路由是我们日常使用的项目环境。每个项目都只需要按需拉取自己使用的模块即可,缺省的模块会由基准环境的稳定服务代替,组成一套互不干扰的软路由环境。

  环境使用者通过 Noah 环境绑定工具将 uid (去哪儿用户标识,下称 uid )和环境绑定,建立环境绑定关系并存储。绑定完环境后,请求到网关(openresty)时读取环境绑定关系,将 uid 转换成环境标识,然后将环境标识植入 HTTP Header 中,方便后续的流量分发。

  流量分发中涉及 or/dubbo/qmq(去哪儿消息中间件)三个中间件,主要分为服务感知和服务选择两个步骤:

  Or:所有环境入口使用同一套域名(比如),在环境创建/更新时新增/更新 对应的upstream。

  Dubbo:使用一套 Zookeeper,保证软路由服务被及时发现,各软路由环境服务注册时带上环境标识。

  Or:通过识别请求中的路由信息和域名中转发规则进行匹配,匹配成功转发到对应软路由环境。如果匹配不到则转发到基准环境。

  Dubbo:根据链路中的软路由标识,和注册中心的环境标识做匹配选择。如果能匹配上,则选择对应环境 dubbo 服务。如果匹配不到对应环境则选择基准环境的 dubbo 服务。

  Qmq:根据消息体中的软路由标识识别,只消费软路由标识匹配上的消息,如果软路由环境没消费则由基准消费。

  软路由方案中数据存储部分没有使用数据流量路由机制,开发和维护成本较高,而是使用较为成熟的物理隔离方案,通过智能推荐策略将选择的应用依赖的数据库和 redis 拉取出来,保证环境中所依赖的数据存储环境隔离,提高环境的稳定性。

  网关隔离使用的是逻辑隔离方案,通过请求中不同的路由标识来将请求转发到不同环境。同时网关层作为流量的入口,还承担路由解析的功能。

  当后续携带用户信息的请求到网关(or/nginx)后通过 uid 解析出环境标识,然后将环境标识植入 HTTP Header 中,往下透传。

  软路由环境和基准环境公用同一套域名。当软路由环境创建成功时,Noah 在会在 or 上给对应域名增加软路由环境的 upstream(用于后续服务选择)。

  如果没有匹配上的说明软路由环境没有对应模块(或者服务不可用),此时则路由到基准环境(图中从软路由 A1 路由到基准环境 B 模块)。

  服务隔离的思想是通过标识 Provider 与 Consumer ,再通过自定义负载均衡算法,让 Consumer 调用指定的 Provider 服务,达到环境隔离的效果。

  第一步 服务感知在 Provider 注册时从 Noah(环境管理系统)获取当前环境标识,然后在 dubbo 服务注册时添加一个参数( routerId )用来标识当前环境。

  第二步 服务路由,consumer 调用时根据链路中的环境标识 id 筛选出对应的 provider,如果匹配不上则默认调用基准环境 provider 。

  qmq consumer 端注册和上报环境标识,同时生成环境隔离的 group 来订阅消息。

  qmq server 处理拉取请求时,根据拉取请求携带的软路由标识和消息携带的软路由标识来判断消息是否要过滤掉。如果能匹配上则可以拉取到消息,不能匹配则过滤消息(如图中环境 A 匹配成功,可以拉取到消息)。

  存储隔离一直是环境隔离的一个痛点问题,在环境 3.0 中根据业务线复杂的存储依赖的情况开发了智能推荐方案,保证软路由环境链路完整且数据隔离。智能数据推荐方案分为两个核心步骤,数据依赖感知和智能推荐。

  应用服务会在代码中配置需要的数据库/redis 缓存的配置信息。Noah 会从发布系统获取应用和数据的依赖关系,并将数据依赖关系存储下来。

  智能推荐通过分析上面采集的数据依赖关系,拉取模块时将依赖的数据库/redis 和公用数据源(同一个数据写入和读取)的模块推荐出来,来保证软路由环境测试链路的完整性。

  如下图,在创建模块 A1 的软路由环境时,首先会根据模块 A1 从依赖关系找到需要的数据库 A1 ,再通过数据库 A1 拉取公用数据源的模块(图中 B1,C1 ),同时再次触发推荐过程。

  说到测试环境稳定性,大多数同学第一反应是测试环境不稳定,将问题详细分类,主要由以下原因造成:

  第一个问题:基础可靠性,受制于成本问题,测试环境无法享受线上服务的基础设施。只能在现有情况下,设计了基准环境保障计划进行可靠性的保证。

  第二个问题:业务可靠性,我们通过链路级别业务检查,及时发现环境中不稳定代码及时进行反馈和定位。

  基准环境是全模块的稳定环境,部署的最新的线上代码,理论上不会受到代码不稳定的干扰,我们希望他能够提供稳定的服务(目标 99%可用),在设计上会为基准环境提供额外的基准环境保障(基准环境保障计划)。

  为了提高基准环境稳定性和降低环境维护成本 提出了环境保障计划,主要包括日常环境使用中最容易出现问题的三个部分,代码,配置,数据库。通过建立同步机制来提高基准环境稳定性。

  Noah 系统会一个小时同步这段时间的线上发布到基准环境,通过基准环境特殊的双机部署,保证基准链路不中断,部署完成触发业务检查,检查环境的链路可用性。

  第一种方案为同步线上配置,这样可以保证测试环境的配置和线上一致性,不再需要手动维护测试环境配置。但从安全的角度出发,这个方案可能带了系统层面的风险,比如 同步线上配置,可能会导致测试流量请求到线)同步测试环境配置

  第二种方案为同步测试环境配置,将项目上线过程中准备的测试环境配置,同步到基准环境来使用,这个方案在安全性上有显著提高(测试环境配置一般认为是低风险,可重复使用)。但线上配置变更时,该方案就无法获取到最新的线上配置,在这种情况下 Noah 会通知值班热线,需要人工判断和处理配置变更。

  为了解决这个问题,我们在环境保障计划中加入数据库表结构同步,noah 收集关注数据库的线上变更情况,每个小时利用 DBA 同步工具

  同步一次线上表结构。并在同步结束后触发环境业务检查,检查基准环境的可用性,并通知环境管理员。

  软路由环境中会部署不稳定的代码,天然会存在不稳定的因素,对环境的可靠性上要求并不像基准环境那么高。软路由环境的可靠性策略是主动发现和快速定位。

  (2)虚拟机检测&重启:对于虚拟机服务,配合软路由探测机制,把不在线的服务自动重启,当重启失败后推送给环境管理员,进行进一步处理。

  业务连通性是最接近环境使用层面的指标,如何证明当前环境是否能让开发/测试同学上手开箱即用,各种复杂应用之间的业务连通性是否正常。

  当两个模块中应用都有改动,且需要联调时,此时会创建两个不同模板的软路由环境 如图中主流程环境A和酒店评论环境 B ;

  当用户同时绑定环境 A 和环境 B 时,后续用户请求根据软路由标识机制转发到对应软路由模块(图中红色链路,从图中 模块 D1 请求到模块 J1 )。

  后续软路由标识无法和酒店评论软路由环境匹配,会通过软路由机制将请求转发到基准环境模块J(从软路由模块 D1 到基准环境 J )。

  当用户不绑定软路由环境时,用户请求会走基准链路(图中黑色链路,从模块D 路由到模块 J )。

  侦察系统从业务场景出发,一个业务场景中包括业务链路上不同模块的测试用例,下面我们以报价页面展示的业务举例。

  当业务场景不通过时,可以通过业务检查结果快速定位问题,定位到对应的模块和接口,同时可以用 qtrace 排查问题。

  目前业务检查已经覆盖固化数据 99% 业务场景( 300+ 业务测试用例),覆盖酒店所有核心主流程。

  通过三种方式触发环境业务检查来检查环境可靠性(目前每天执行约 1800 次),在环境不可用时,侦察系统可以帮忙开发/测试同学来快速定位环境问题(从原来约 30 分钟降低到 30 s)。

  触发检查,环境变更触发。其中定时任务检查更关注基准环境,而 cicd 触发检查更关注于软路由环境(项目环境)。

  软路由环境 全量环境一个小时检查一次(项目环境主要靠流水线触发),如果未通过项目群通知对应开发/测试同学,可以根据业务检查结果排查和解决。

  目前将持续集成和业务检查起来,在项目分支上,每次有代码提交,把项目分支最新代码部署到软路由环境上,并且跑一遍链路级别的检查,确保项目新代码不影响环境使用。

  目前环境 3.0 模块数对比环境 2.0 平均模块数降低 90%(从平均 200 个模块到目前平均 10 个模块), 环境创建时间也随之降低(环境创建时间减少70%)。

  2.1 维护核心环境数量变化,快速定位解决从原来 60+ 独立环境到目前一个核心基准环境,环境维护的同学可以提供更及时和可靠的环境支持,快速解决业务连通性问题。

  通过多种业务检查触发途径(定时/ cicd /环境变更),触发业务检查,主动发现环境中问题并反馈给环境维护者进行解决。

  通过软路由的逻辑隔离方案,让仿真环境人手一套(比如图中的环境 A 和环境 B ),真正做到 Test in Production 。

上一篇:开发一套CRM客户管理系统大概多少钱 CRM系统开发价格 下一篇:维修管理系统的数据权限——工单数据单位部门成员
关注我们
©2022 火狐体育最新登录网址_官网app入口 京公网安备110177777720125 火狐体育最新登录网址|火狐体育app