cardinality详解[二]
# 2.2 从请求到验证的全流程详解 全链路跟踪
通过一个真实 API 请求案例,我们细致梳理 Ambari cardinality
校验的执行流程,包括前端参数提交、后端 Java 控制器分发
、StackAdvisor 脚本校验,以及最终错误信息的回显。
# 第一步:发起验证请求
我们采用 curl
请求验证 ZooKeeper 组件的部署情况。可以看到不同 host_group 组合,响应返回内容也会有差异。
# 请求内容如下
curl 'http://localhost:28080/api/v1/stacks/BIGTOP/versions/3.2.0/validations' \
-H 'Accept: application/json, text/javascript, */*; q=0.01' \
-H 'Accept-Language: zh-CN,zh;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6' \
-H 'Cache-Control: no-cache' \
-H 'Connection: keep-alive' \
-H 'Content-Type: text/plain' \
-H 'Cookie: _ga=GA1.1.1039361229.1720495067; ...' \
-H 'Origin: http://localhost:28080' \
-H 'Pragma: no-cache' \
-H 'Referer: http://localhost:28080/' \
-H 'X-Requested-By: X-Requested-By' \
-H 'X-Requested-With: XMLHttpRequest' \
--data-raw '{"hosts":["centos1","centos2","centos3"],"services":["ZOOKEEPER"],"validate":"host_groups","recommendations":{"blueprint":{"host_groups":[{"name":"host-group-1","components":[{"name":"ZOOKEEPER_SERVER"},{"name":"ZOOKEEPER_CLIENT"}]},{"name":"host-group-2","components":[{"name":"ZOOKEEPER_SERVER"}]},{"name":"host-group-3","components":[{"name":"ZOOKEEPER_CLIENT"}]}]},"blueprint_cluster_binding":{"host_groups":[{"name":"host-group-1","hosts":[{"fqdn":"centos2"}]},{"name":"host-group-2","hosts":[{"fqdn":"centos1"}]},{"name":"host-group-3","hosts":[{"fqdn":"centos3"}]}]}}}'
2
3
4
5
6
7
8
9
10
11
12
13
14
# 第二步:请求流转到 ValidationService 控制器
此时请求被发送到 Ambari 的 ValidationService
控制器,并进入 getValidation
方法。
# 第三步:进入 ValidationResourceProvider 的 createResources 方法
系统会调用 ValidationResourceProvider
的 createResources
方法,该方法负责组装请求上下文,准备校验所需信息。
此处通过 prepareStackAdvisorRequest
方法,生成了一个 StackAdvisorRequest
,包含所有参数。
# 第四步:Java 层调用核心校验逻辑 关键代码
准备好校验请求后,执行核心校验逻辑:
final ValidationResponse response;
try {
response = saHelper.validate(validationRequest);
} catch (StackAdvisorRequestException e) {
LOG.warn("Error occurred during validation", e);
throw new IllegalArgumentException(e.getMessage(), e);
} catch (StackAdvisorException e) {
LOG.warn("Error occurred during validation", e);
throw new SystemException(e.getMessage(), e);
}
2
3
4
5
6
7
8
9
10
# 第五步:进入 Python 端 StackAdvisor 实际校验
saHelper.validate(validationRequest)
实际会通过进程调用 StackAdvisor 的 Python 脚本,根据 stack
版本动态路由到对应子类(如 BIGTOP320StackAdvisor
),进一步执行 getComponentLayoutValidations
,针对 blueprint 和 metainfo
配置进行 cardinality
校验。
在这里,getComponentLayoutValidations
方法将根据 metainfo 配置的 cardinality,逐一判断实际部署数量和分布,捕获不符合条件的分配。
# 第六步:回传校验结果及错误明细
当校验流程完成,Ambari 会将完整的错误结果以 JSON 格式返回,帮助用户直观定位组件部署是否满足 cardinality 规则:
{
"resources": [
{
"items": [
{
"level": "ERROR",
"host": "centos3",
"type": "host-component",
"message": "Host is not used"
},
{
"component-name": "ZOOKEEPER_CLIENT",
"level": "ERROR",
"type": "host-component",
"message": "At least 1 ZooKeeper Client components should be installed in cluster."
}
]
}
]
}
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Cardinality 不满足将阻断部署
如上响应明确指出,ZooKeeper Client 未满足至少 1 个的要求,需补齐后才可继续。