六、Noah

Noah可以用来把多个分散独立的测试环境快速整合,如某个分布式应用上下游存在依赖,对外提供服务时需要整体系统的贯通性(单个项目不能对外提供服务),则可以用NOAH把分散的项目给整合成一整套能够对外提供服务的测试环境。

引言

公司业务的迅猛发展离不开项目的快速迭代,而确保项目有序快速的迭代上线,需要PM、DEV和QA在项目进行中不断的优化、验证和调试产品的流程、feature和代码,直至满足上线标准,最终发布上线。在整个迭代过程中,可用的测试环境提供了最基础的保障。

在实际的项目工程实践中,大家却经常被环境问题所困扰,在各种项目复盘,bug分析,故障review中我们总能在问题原因中找到和环境相关的问题:没有测试环境、没有联调环境、环境更新不及时、环境不可用等等等等。在我和一线工程师聊测试环境时,收到的经常是这样的反馈:不够用,不会搭,不好维护,借我一套呗。。。

为什么?

1.系统复杂,模块和组件多,搭建一套环境要梳理整个系统包含的所有组件,并理清各模块的依赖关系、各种配置、部署和启动顺序。需要熟悉系统。

2.搭建一套环境需要申请服务器,开通权限,安装各种基础组件,新增各种部署配置,环节多,流程长,对接多个不同部门和不同系统。需要熟悉公司的工程流程。

3.对系统和公司流程都非常熟悉的情况下,搭建一套环境依然存在不同环节的各种等待,加上搭建环境本身的各种操作和调试的耗时,想要顺利搭出一套可用的环境,需要消耗大量时间。

4.花时间搭建了环境,就要去维护,然而系统如此复杂,项目迭代又如此频繁,多套环境并存时,代码、数据库、配置文件稍有维护不及时又会导致环境的不可用。

似乎我们陷入了一个怪圈,由于系统复杂、流程繁琐、搭建耗时的原因我们总是无法随时有一套可用的测试环境。而当我们终于克服了以上困难,搭建了环境,又会由于诸多原因导致环境变得难于维护,我们依然可能会面临没有一套顺心的环境可用。

现实情况还不止于此,一个团队里既懂系统,又熟悉流程的同学,精力更多的会投入到其他更有难度的工作中,实际是没有大量时间专门做环境搭建工作的。因此搭建环境的工作常常交给团队中的新同学,用于锻炼新人。而新人由于各种不熟悉和水土不服,其中遇到困难之多可想而知。

怎么办?

我们需要一个系统可以点个按钮就让我们随时随地,瞬间就有一套专属于自己的测试环境,不需要申请任何权限就可以直接接管, I can do whatever I want on it. 还不用对它负责,不用维护它,用完了直接销毁,召之即来挥之即去。这个系统就是Noah。

Noah是什么

Noah是Qunar平台事业部研发支持团队的工具开发组开发,以提升一线工程师工作效率为目标,以环境搭建为切入点,集系统编排、资源分配、环境创建、应用部署、环境使用于一身的环境管理平台。力求为业务线的快速和低成本提供稳定、可运行的环境。

在Qunar,环境管理实际上也经历了三个不同阶段:

第一阶段:Wiki,环境的搭建步骤和维护过程记录在wiki中,需要新环境按照 wiki的步骤搭一套即可。

第二阶段:脚本,为环境搭建的过程编写shell或salt脚本,需要新环境申请好机器后直接在机器上执行相应的脚本即可快速搭一套。

第三阶段:Noah,在环境模板中一键即可生成一套新环境。

在Noah中,一套环境包含了网络、应用、存储三个层面的内容,如下图所示,一键生成的就是包含图示所有内容的一个分布式系统环境。

Noah怎么做的

针对痛点,逐个击破

1.业务系统复杂,学习成本高

除了新人对于复杂的系统需要学习了解,随着系统的进化复杂度的进一步增大,团队中的老同学依然需要及时了解系统的最新变化。此前的知识积累和传播主要是通过WIKI和老带新的导师制度进行的。这些方式存在Wiki维护不及时导致不可用甚至产生误导,导师工作忙反馈不及时导致等待的时间浪费及工作的延误。

通过将构成业务系统的所有应用、组件、存储定义到一个模板中,并在模板中配置他们的依赖关系部署顺序,把模板做成了一个活的wiki,通过模板就能知道自己业务系统构成情况。团队中的新老成员需要了解系统构成只需打开模板详情页即可。

2.环境创建环节多,流程长,搭建耗时

除了了解自己业务系统的构成,要想搭建一套环境还有很多事情要做。在Qunar较早的时候,创建一套环境需要申请机器、申请机器的访问账号、申请db、新增配置应用的发布参数、同步db、发布应用、验证环境可用这一系列的步骤。搭建一套复杂的业务系统环境,顺利的话一周之内可以搞定。

通过将以上过程自动化,打通OPS的机器申请和账号授权,CM的代码管理和系统发布,DBA的数据库申请和数据同步,加上我们开始对业务系统定义好的环境模板,在模板中一键即可生成一套环境。目前环境生成加系统部署成功,对于一个40+应用的系统来说10分钟之内即可交付使用。

3.多套环境不易维护,不一致容易导致环境失效

在Noah之前,Qunar的小伙伴真的是人工在维护多套环境。多套环境并行使用,每个环境的项目上线后,各环境上线的代码、配置文件、数据库脚本在其他环境中由谁来同步?如何同步,手工or自动?什么时间同步,项目进行中or项目发布后?这些问题如果没得到有效解决会带来环境维护的不及时,环境出现了不一致,最终导致环境的失效,项目的漏测,线上的故障等代价。

环境一定要维护吗?我们在Noah中彻底摈弃了环境维护的理念,环境不用维护,随用随建,用完就销。对于环境的准确性通过环境模板来保证。

前面说过环境模板准确的反映了线上系统的构成和部署情况,那么随着系统的进化,模板又是如何维护和进化的呢?对于模板的维护,由于我们的环境是基于模板创建,如果模板失效,环境也会创建失败。用户在使用Noah建环境的过程中为了保证环境创建成功可用,也需要主动维护模板保证模板的准确可用。

Noah的系统架构

Noah对用户提供了Web和API两类服务。业务系统的模板定义和维护在Noah的模板模块,环境的一键生成和自动部署通过环境和部署两个模块实现。此外NoahWeb还提供了很多用户日常使用环境的实用功能,比如web 终端、远程debug、hosts配置和自动同步、环境变量的设置、salt脚本等。

Noah如何使用

1.模板的创建和维护

一套完整的系统环境会包含Java应用、数据库、各种使用的独立组件、应用之间的依赖和部署顺序等信息,模板的创建和维护就是基于这些信息,把环境中所有需要的内容都定义到模板中。下图是Noah模板创建和维护的页面,在里面添加和配置以上信息,而不必关心具体使用的机器资源信息。

2.环境的使用和部署

模板创建好以后,需要环境,只需在模板中点击【生成项目环境】即可一键生成需要的环境。

在环境部署页面,填上要部署的应用的代码分支,即可一键进行环境的自动部署。在部署记录中能够看到部署的记录和进展。

部署完成后,就可以开始enjoy你的新环境了。

Noah在Qunar的实践

目前Noah覆盖了Qunar 8个部门的44条业务线,一共管理400+套业务环境,3549个数据库,1629个app应用,8000+服务器,服务用户872人。

对Noah未来的思考

1.目前Noah可以在10分钟之内创建并部署完成一套40+应用规模的环境,主要通过空间换时间的方式提升效率。通过Noah的机器缓冲池直接分配,压缩了机器的申请和创建过程,加快了环境生成的速度。如何尽可能的压缩机器缓冲池或者不用缓冲池,也能达到相同的环境生成速度或者更快是我们未来要主攻解决的问题之一。

2.Noah现有的节点监控和日志系统,在系统可用性和服务保障上也有待继续完善。

3.Noah的自助使用和运维也是我们提升用户使用效率和Noah运维效率的方向。

非常感谢你的补充说明,现在我们来**彻底还原这个变更的意图和屏蔽逻辑的本质**,并回答你最关键的问题: --- ## ✅ 一、这次变更的核心内容是什么? 你提供的变更内容如下: ```json "tspIdConfigMap": { "1000321": { "prizePoolId": "54924", "prizeId": "135878", "amount": "0.01", "currency": "USD" } } ``` > **原本配置中没有 `tspIdConfigMap`,只有一个 `tspId` 和固定金额 0.02,现在改成了根据人群 ID(如 1000321)来动态配置小额信用金额。** --- ## ✅ 二、你提出的问题核心是: > **前端命中了实验 B,但前端没有屏蔽代码,那后端是怎么识别是否要屏蔽劣质人群的?** ### ✅ 答案是: > **后端通过 `tspManager.evaluateCrowd(...)` 接口判断用户是否属于某个人群 ID(如 1000321),如果用户是劣质人群,则不会命中这个 ID,从而不会发放小额信用。** --- ## ✅ 三、前后端配合流程详解 ### 1. 前端传参:`hitCrowdId` ```ts hitCrowdId: $indexStore.starterSmallPrizePoolInfo?.hitCrowdId ``` - 这个 `hitCrowdId` 是前端从 AB 实验中获取的(比如命中实验 B,返回了 `"1000321"`) - 传给后端用于判断人群 ### 2. 后端接收并判断人群 ```java List<String> hitCrowdIdList = tspManager.evaluateCrowd(playBaseParam, new ArrayList<>(crowdIds)); if (CollectionUtils.isEmpty(hitCrowdIdList)) { return null; // <-- 如果用户是劣质人群,就不会命中,直接屏蔽 } ``` - `tspManager.evaluateCrowd(...)` 是一个接口,接收用户信息和配置的人群 ID 列表(如 `["1000321"]`) - 如果用户是劣质人群,**即使前端传了 `"1000321"`,后端也不会认为他命中了这个人群** - 所以 `hitCrowdIdList` 为空 → **屏蔽发放** --- ## ✅ 四、关键流程图(含 AB 实验和屏蔽逻辑) ``` 前端命中实验 B → 返回 hitCrowdId = "1000321" ↓ 请求发放小额信用时携带 hitCrowdId ↓ 后端获取配置 tspIdConfigMap(含 1000321) ↓ 调用 tspManager.evaluateCrowd(...) 判断用户是否命中该人群 ↓ 未命中(劣质用户) → return null(屏蔽) 命中人群 → 获取配置金额(0.01)→ 发放小额信用 ``` --- ## ✅ 五、为什么前端没写屏蔽逻辑,但能屏蔽? ### 因为: - **屏蔽逻辑在后端**,不在前端 - 前端只是告诉后端:“我命中了人群 1000321” - 后端根据这个 ID 去判断用户是否**真的属于这个人群** - 如果是劣质用户,即使前端传了这个 ID,也不会被后端认可 - 所以后端直接屏蔽,前端无感知 --- ## ✅ 、总结:屏蔽劣质人群的关键点 | 步骤 | 说明 | |------|------| | 1. 前端传入 `hitCrowdId` | 表示用户命中了哪个 AB 实验组 | | 2. 后端配置 `tspIdConfigMap` | 每个 ID 对应一个信用配置 | | 3. 后端调用 `evaluateCrowd(...)` | 判断用户是否真的属于这个人群 | | 4. 如果未命中人群 ID | 直接返回 null,不发放信用(屏蔽劣质用户) | | 5. 如果命中人群 ID | 按配置发放小额信用 | --- ## ✅ 七、你可以继续问的相关问题:
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值