云效故障定位研究论文被ICSE 2021 SEIP track收录

近期,由阿里云云效团队联合复旦大学CodeWisdom研究团队、阿里技术风险部安全生产团队,合作完成的论文《MicroHECL: High-Efficient Root Cause Localization in Large-Scale Microservice Systems》被ICSE 2021 SEIP track录用。本文针对大规模微服务系统的三种可用性问题,提出了一种高效的根因定位方法MicroHECL。

MicroHECL基于动态构建的服务间的依赖图,分析了所有可能的异常传播链路,并基于相关性分析对候选根因进行了排序。本文将机器学习和统计方法相结合,并通过个性化的模型来检测不同类型的服务异常(如性能异常、可靠性异常、流量异常)。为了提高异常检测的效率,在异常传播链分析的过程中,MicroHECL采用了剪枝策略来消除不相关的服务调用。最后,通过实验研究,证明了MicroHECL在可用性问题异常检测的准确性和效率方面都显著优于两种先进的基线方法。MicroHECL已经在阿里巴巴内部落地实践,截止2020年7月,实际top-3的命中率达到了68%,根因定位的时间从原来的30分钟缩短到了5分钟。

研究背景

微服务架构已经成为构建云原生应用的最新趋势,越来越多的公司选择从单体系统迁移到微服务架构。工业微服务系统通常包含成百上千的应用,这些系统是高度动态和复杂的,一个服务可以有几个到几千个实例运行在不同的容器和服务器上,而可用性问题一直是大规模微服务系统面临的一个关键挑战。在这些系统中,服务质量(如性能、可靠性)的任何异常都有可能沿着服务调用链传播,并最终导致业务级别的可用性问题(如订单成功率下跌),这也是企业普遍碰到的问题。当监控系统监控到可用性问题时,它的根因服务和异常类型需要在短时间(如3分钟)内定位,以便开发人员快速解决问题。

 

阿里巴巴的电子商务系统每月活跃用户超过8.46亿人,它采用微服务架构,并且包含超过3万多个服务,这些服务都配备了一个称为EagleEye的大型监控基础设施。作为业务的载体,系统需要保证高可用。因此这些系统都部署了一个业务监控平台来及时的发出可用性问题报警。这些可用性问题通常表示业务运行中的问题,例如下单成功量下跌、交易成功率下跌等。这些可用性问题可能是由不同类型的异常引起的,异常可能从一个服务传播到另一个服务,最终导致可用性问题。在本文中,我们重点关注以下三种导致阿里巴巴大部分可用性问题的异常类型:

  1. 性能异常。性能异常表现为响应时间(RT)的异常增加。它通常是由有问题的系统实现或不正确的环境配置(例如容器或虚拟机的CPU/内存配置)引起的。
  2. 可靠性异常。可靠性异常表现为错误数量(EC)的异常增加,例如服务调用失败的次数。它通常由代码缺陷或环境故障(例如服务器或网络中断)引起的异常。
  3. 流量异常。流量异常表现为每秒异常增加或减少的查询数量(QPS)。流量的异常增加可能会导致服务中断,而异常流量的减少可能表明许多请求无法到达服务。它通常是由不正确的流量配置(例如Nginx的限流)、DoS攻击或意外的压测等引起。

相关研究

现有的方法不能有效的支持大规模微服务系统可用性问题根因定位,业界开发人员通常还需要依赖可视化工具来分析日志和链路,以识别可能的异常和异常传播链路,从而找到根本原因。研究人员已经提出了使用链路分析或服务依赖图的方法来自动定位微服务或更广泛的基于服务的系统的异常根因。基于链路分析的方法需要昂贵的链路数据收集和处理,因此不能有效的用于大规模系统。基于服务依赖图的方法是基于服务调用或因果关系来构造服务依赖图。这些方法通过遍历服务依赖图并用服务的指标数据(如响应时间)检测可能的异常来定位根因,然而这些方法由于对服务异常检测的不准确以及对服务依赖图的低效遍历而使用受限,尤其是在有很多服务和依赖关系的大规模微服务系统中。

方法概述

MicroHECL是一种解决可用性问题的高效的根因定位方法。在我们的场景中,可用性问题通常是从业务视角观测到的。例如,订单成功量下跌,它可能是由不同类型的异常引起的。目前MicroHECL支持三种类型的异常(即性能异常、可靠性异常、流量异常)。在定位特定类型的异常时,MicroHECL考虑相应的服务调用指标以及异常的传播方向。例如,在定位性能异常时,MicroHECL会主要考虑服务间调用的响应时间和异常传播方向(即从下游向上游传播)。MicroHECL的方法概述如图1所示,主要包括以下三个部分。

 

服务依赖图构建

当运行时的监控系统检测到可用性问题时,MicroHECL将启动根因分析过程。它基于运行时监控系统采集到的服务调用关系和指标,动态的构建一定时间窗口(例如最近30分钟)内的目标微服务系统的服务调用图。服务调用图是由一系列的服务节点S={S1, S2,..., Sn}组成,每一个节点都代表了该服务在最近30分钟内发生过调用关系。边Si-->Sj代表了在最近一个时间窗口内服务Si调用过服务Sj。为了对可用性问题进行根因分析,服务调用图上还记录了各种度量指标,例如响应时间(RT)、错误数量(EC)和每秒请求数(QPS),这些监控到的数据都被存储到了时间序列数据库(TSDB)。为了优化性能,服务调用关系是随着异常调用链分析的过程按需并增量构建的,只有在异常传播链分析过程中,到达了某个服务,才会去拉取与它相关的指标数据。

异常传播链分析

一个可用性问题最初是在某个服务(称为初始异常服务)上由监控系统发现的,但是异常的根因往往是它的上游或下游服务。根因服务和初始异常服务通常都处于由一系列的异常服务组成的异常传播链上。异常传播链分析的目的就是通过分析初始异常服务中可能的异常传播链来确定一组候选的异常根因服务,在分析的过程中,会沿着异常传播的相反方向。为了提高效率,MicroHECL采用了一种剪枝策略来消除和当前异常传播链不相关的服务调用。通过异常传播链的分析,最终可以得到一系列的候选异常根因服务。

候选根因排序

MicroHECL根据导致给定可用性问题的可能性对候选根因进行排序。通过对监测数据的分析,我们发现初始异常服务的异常指标数据与根因服务的异常指标有相似的变化趋势。注意这里初始异常服务的指标是某种业务指标(例如:订单成功量),而候选根因的异常指标是质量指标(如RT、EC、QPS)。因此我们使用皮尔逊相关性系数对这两个异常指标(X,Y)的变化趋势进行相关性分析,并基于相关性值P(X,Y)进行候选根因的排序。

 

异常传播链分析

分析过程

可用性问题可能是由不同类型的异常引起的。对于不同的异常类型,服务异常检测中考虑的指标和传播链分析中考虑的异常传播方向是不同的。如表1所示,性能异常、可靠性异常和流量异常考虑的主要指标分别是响应时间(RT)、错误数量(EC)和每秒请求数(QPS)。通常性能异常和可靠性异常的传播方向都是从下游到上游的,而流量异常的传播方向是从上游到下游的。

表1. 可用性问题的指标和异常传播方向

 

2、异常传播链路扩展

对于每个异常传播链,通过从起始节点(即检测到的初始异常服务的相邻异常节点)沿着异常传播方向进行迭代扩展。在每次迭代中,根据异常类型对当前节点的上下游节点进行异常检测,并将检测到的异常节点添加到当前异常传播链中。当不能向链中添加更多节点时,异常传播链的扩展结束。例如,对于S4的异常传播链,扩展以S1结束,S1是S4的上游节点并且符合流量异常的传播方向。相似的,对于S7的异常传播链,扩展以S9和S10结束。

3、候选根因排序

当初始异常服务的所有异常传播链分析结束时,将异常传播链扩展结束位置的所有服务作为候选的根因服务。例如,图中所示的分析过程得出的候选根因包括S1、S9和S10。

服务异常检测

在异常传播链分析过程中,我们需要根据一些指标数据不断的检测一个服务是否存在某种类型的异常。例如,在图2中,通过入口节点异常检测,我们首先确定了S4和S7,然后通过服务异常检测在异常传播链扩展中识别出异常服务S1、S9、S10。根据不同的指标的特点,我们为每种异常类型选择了不同的分析模型,这些分析模型是根据相应指标类型的波动特征和指标之间的关系设计的。

 

1、性能异常检测

性能异常检测是基于异常增加的响应时间(RT),这里的挑战是如何区分RT的异常波动和正常波动。图3(a)和图3(d)分别显示了两个小时和一周的响应时间波动。从中可以看出,在一天的不同时间段和一周的不同日子里,RT都有周期性的波动。如果我们使用像3-sigma这样的简单规则,这些周期性波动很可能会被认为是性能异常。为了识别异常波动,我们不仅考虑了当前时间段的指标,还需要考虑前一天的同一时间段和前一周的同一时间段的指标。而且,在历史数据中,响应时间大多数处于正常波动状态,只有少量的异常波动。

 

基于RT数据的特点,我们选择了OC-SVM(one class support vector machine)作为RT异常波动的预测模型。OC-SVM仅使用特定类别(正常RT波动)的信息来学习出一个分类器,该分类器可以识别出属于该类别的样本,并将其他样本识别为异常值(异常RT波动)。OC-SVM具有建模简单、可解释性强、泛化能力强等优点。我们为模型定义了以下4种特征:

  1. Number of Over-Max Values: 当前检测窗口中Response Time的值大于给定比较时间窗口内Response Time的最大值的数量。
  2. Delta of Maximum Values: 当前检测窗口中Response Time的最大值与给定比较时间窗口内的Response Time最大值的差值。
  3. Number of Over-Average Values: 当前检测时间窗口中超过给定比较时间窗口中Response Time滑动平均值最大值的数量。
  4. Ratio of Average Values: 当前检测窗口中Response Time的平均值与给定时间窗口内Response Time的滑动平均值的最大值的比值。

我们把最后10分钟作为异常检测的时间窗口。对于对比的时间段,我们考虑以下三种:当前检测窗口之前的最后一小时,前一天相同的时间段,前一周同一天的相同时间段。因此,我们一共可以得到12个特征值。

 

为了训练模型,我们在阿里巴巴的监控系统中从不同的系统收集到了100000个案例。我们也收集了600个正负比例1:1的案例用于模型的验证。模型训练结果如表2所示。

表2. 性能异常的模型训练效果

 

3、流量异常检测

流量异常检测是基于QPS的异常波动。如图3(c)和图3(f)所示,QPS从短期和长期来看是比较符合正态分布特点的。因此,我们选择使用3-sigma规则来检测异常的QPS波动。同样采用最后10分钟作为异常检测的时间窗口,并基于最近一个小时的QPS值,我们使用3-sigma规则来检测当前检测窗口中的异常值。

 

此外,经过观察发现,单纯使用3-sigma仍然会存在一定的误报行为。为了进一步消除误报,我们还计算了这些异常服务的QPS值和初始异常服务的业务指标之间的皮尔逊相关性系数,只有当相关性高于预定义的阈值(例如0.9)并且在当前检测窗口中识别出3-sigma异常值,才会认为当前服务存在流量异常。

剪枝策略

异常传播链路可能具有多个分支,并且分支的数量可以在异常传播链扩展期间继续增长。因此,异常传播链分析的一个主要挑战在于大规模服务依赖图上异常传播分支的数量可能成指数增长。而在这些分支中,一些异常服务和服务调用可能与当前可用性异常问题无关。为了解决这一问题,提高分析效率,我们采用剪枝策略来消除不相关的异常服务调用。剪枝策略是基于假设异常传播链中两个连续的服务调用的边具有相似的指标变化趋势。例如,在图2中,边S1 -> S4上的QPS应该和边S4->S5上的QPS具有相似的变化趋势,否则S1->S4这条边就应该被剪枝。类似的,S7->S9边上的RT的指标变化应该和边S5->S7上RT的指标变化具有相似的趋势。

 

检测策略在异常传播链分析的扩展过程中被使用,我们只考虑相邻两条边上相同异常类型的指标数据(例如RT、EC、QPS)在最近一个时间窗口(例如,最近60分钟)内的相似性。相似性的计算使用公式1。如果相似度值低于阈值(如0.7),那么当前异常边会被剪枝掉。

实验评估

为了评估MicroHECL的有效性和效率,我们进行了一系列的实验研究来回答下面三个研究问题:

  1. RQ1(定位精确度):MicroHECL在定位微服务系统的可用性问题的根因和特定异常类型的根因方面精确度如何?
  2. RQ2(定位效率):MicroHECL在根因定位过程中随着服务数量的增加,定位效率和可扩展性会有怎样的变化?
  3. RQ3(剪枝效果):MicroHECL在不同的相似度阈值下对定位的精确度和效率有何影响?

实验设置

从2020年2月到6月,我们在阿里巴巴的大型电子商务系统的28个子系统中收集了75个可用性问题异常案例,这些子系统平均包含265(最小7,最大1687,中位数82)个服务。在这75个可用性问题案例中,有37个是由性能异常导致,有43个是由可靠性问题导致,有21个是由流量异常导致。我们把MicroHECL与其它两种基线方法(MonitorRank、Microscope)进行了实验对比,并使用公式2中HR@k 和MRR来评估方法根因定位的精确度。

 

定位精确度(RQ1)

表4显示了MicroHECL和其它两种基线方法的总体精确度评估结果,可以看出MicroHECL在HR@1、HR@3和HR@5的命中率分别为0.48、0.67和0.72,MRR为0.58。在所有这些指标方面,MicroHECL都显著优于基线方法。

表4. 总体准确度评估

 

我们还评估了MicroHECL在不同异常类型方面的精确度。从表5可以看出,MicroHECL在这三种异常类型方面都优于基线方法。而且可以看出MicroHECL在性能异常方面的优势最为显著,在流量异常方面的优势不太显著。

表5. 不同异常类型的准确度

 

定位效率(RQ2)

本文中的75个可用性问题异常案例来自28个子系统,这些子系统有不同的服务数量。为了评估MicroHECL的效率和可扩展性,我们在这75个案例中分析了MicroHECL和两种基线方法的异常检测时间。并研究了异常检测的时间如何随目标系统的大小(服务数量)而变化,实验结果如图。请注意,从同一个子系统中收集的可用性问题可能有多个,每个可用性问题在图中都用一个点表示。总体来说,MicroHECL的执行时间比Microscope少22.3%,比MonitorRank少了31.7%。在这三种方法中,对于不同大小的子系统和大多数的可用性问题,MicroHECL使用的时间都是最少的。

 

图中的两条曲线分别显示了MicroHECL相对于两种基线方法平均时间差的变化。可以看出,当服务数量小于250个时,MicroHECL的优势并不显著;当服务数量超过250个时,MicroHECL的优势随着服务数量的增加而越来越显著。此外,MicroHECL(包括两种基线方法)的执行时间随着服务数量的增加而线性增加,表现出良好的可扩展性。

 

剪枝效果(RQ3)

剪枝策略是影响根因定位精确度和效率的关键。本文通过分析75个可用性问题的根因定位的精确度和时间消耗随不同的相似度阈值的变化来评价剪枝策略的效果, 并选择HR@3作为精确度的评估指标。评估结果如图5所示,从中可以看出,随着阈值的增加,精确度和时间都会有所下降。而且当阈值从0增加到0.7时,精确度保持在0.67,而时间从75秒减少到了46秒。实验结果验证了剪枝策略在保证精确度的前提下,显著提高异常定位效率的有效性,并且对于这些可用性案例,最佳相似度阈值为0.7。

 

企业实践

MicroHECL已经实现为一个基于EagleEye和其它监控基础设施的分布式系统在阿里巴巴部署运行。在实际应用中,MicroHECL还支持更细粒度的故障定位,比如将中间件(数据库,消息队列,缓存服务)等作为定位的目标,这些组件和交互的指标数据也会被记录到服务调用图上。在过去的5个多月里,MicroHECL处理了超过600个可用性问题,平均可以在76s产出定位结果,开发人员通常可以在监控系统检测到可用性问题后5分钟内确认并开始故障修复。来自开发人员的反馈表明,大多数开发人员都比较信任系统的推荐,默认会把推荐的结果作为异常的根因。

 

在实际应用中,除了一些系统因指标数据缺失导致无法准确定位之外,我们还分析了MicroHECL不能准确定位其它异常根因的案例,发现MicroHECL仍需要从多方面进行改进。例如,一些可用性异常被检测到后,它的服务质量指标可能没有任何异常。而且有一些异常可能是慢慢积累起来的,它的指标波动可能超过了异常监测的时间窗口。这些需要更先进的技术来改进目前的方法。

总结

本文针对微服务系统的可用性问题,提出了一种高效的根因定位方法MicroHECL, 它通过动态构造服务调用图并分析可能的异常传播链路。与现有方法不同,MicroHECL使用基于机器学习和统计方法的个性化模型来检测不同类型的服务异常(即性能异常、可靠性异常、流量异常),并在异常传播链分析中采用剪枝策略来消除不相关的服务调用。 实验研究和阿里巴巴的实际应用都证实了MicroHECL的精确度和有效性,未来我们也会在云效上提供风险预测定位的能力。

作者:Yvonne

原文链接 

本文为阿里云原创内容,未经允许不得转载

 

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/514309.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

CSDN 开学见面礼!3 周带你 Get 大厂工程师基础能力

暑假即将结束,金秋开学季来袭。别让年轻的自己虚度光阴,现在加入C友会,大厂CTO级别导师陪你加buff!10+场考前辅导,50个任务文档,600+分钟大咖讲解与答疑,3周带你掌握大厂…

迷雾世界无限号服务器,迷雾世界部分服务器互通公告_迷雾世界部分服务器3月31日数据互通详情分析_手心游戏...

迷雾世界部分服务器3月31日数据互通公告!迷雾世界亲爱的玩家:为了优化游戏体验,更好地提升组队、交互的互动体验,开发组在3.27 -3.30对所有玩家进行了关于数据互通的调查投票。结果显示,78%的玩家投票同意。因此&#…

一文读懂云上DevOps能力体系

简介: 阿里云ECS自动化运维套件架构师,深度拆解云上运维能力体系建设:自动化运维等级金字塔、自动化运维的进阶模式、DevOps的基础核心、云上标准化部署三大能力…… 序言 云计算行业已经有十多年的发展了,话题早已从“要不要上云…

mcem r语言代码_R语言阈值自回归模型(TAR)代码示例

原文链接:R语言时间序列TAR阈值模型分析​tecdat.cn阈值模型用于统计的几个不同区域,而不仅仅是时间序列。一般的想法是,当变量的值超过某个阈值时,过程可能表现不同。也就是说,当值大于阈值时,可以应用不同…

【洛谷算法题】P4414-[COCI2006-2007#2] ABC【入门2分支结构】Java题解

👨‍💻博客主页:花无缺 欢迎 点赞👍 收藏⭐ 留言📝 加关注✅! 本文由 花无缺 原创 收录于专栏 【洛谷算法题】 文章目录 【洛谷算法题】P4414-[COCI2006-2007#2] ABC【入门2分支结构】Java题解🌏题目描述&a…

EDAS微服务应用同城容灾最佳实践

简介: 大多数业务应用只要做到同城双活,就可以避免掉大多数数据中心不可用故障。本实践就是帮助大家高效、低成本地实现自己的业务应用具备同城双活容灾能力。 前言 上云目前已经是绝大数企业首选的IT基础设施建设方案,但是云上仍然存在一些…

脸书推出VR视频会议应用程序 正式跨出元宇宙第一步;三家公司新入选福布斯2021云计算百强榜;微软挖来亚马逊云业务顶级高管贝尔...

NEWS本周新闻回顾微软挖来亚马逊云业务顶级高管贝尔微软公司已经聘请亚马逊云业务高管查理贝尔担任其企业副总裁。鉴于微软的Azure 云业务正试图从亚马逊 AWS 手中争夺份额,这一挖角行动可以说是微软的一次胜利。在亚马逊前 AWS 主管安迪贾西被任命为亚马逊 CEO 后&…

三字经带拼音a4打印版_人教版八年级下册英语6单元重点单词带音标打印版

UNIT 6shoot [ʃu:t] v. 投篮,射击,发射stone [stəʊn] n. 石头weak [wi:k] adj. 虚弱的,柔弱的god [ɡɒd] n. 上帝,神remind [rɪmaɪnd] v. 提醒,使想起bit [bɪt] n. 一点,小块a little bit 有点儿&am…

拥抱云原生,Fluid结合JindoFS :阿里云OSS加速利器

简介: Fluid 是一个开源的 Kubernetes 原生的分布式数据集编排和加速引擎,主要服务于云原生场景下的数据密集型应用。在 Fluid 上使用和部署 JindoRuntime 实现数据集的可见性、弹性伸缩、数据迁移、计算加速等,并流程简单、兼容原生 k8s 环境…

【观点】传统企业如何在数字化时代实现进化?

简介: 我们看到的数字化的大多数场景集中于日常商业消费活动,背后其实是超越个体行为的场景变革。 究竟是谁在承载这个时代一步步走进数字化场景?又是谁通过数字化技术与解决方案帮助他们实现场景变革?这个过程是什么样的&#xf…

网易数帆发布轻舟低代码平台2.0,聚焦中等复杂度企业级应用

编辑 | 宋 慧 出品 | CSDN云计算 头图 | 轻舟低代码平台2.0发布会现场 8月26日,网易数帆正式发布轻舟低代码应用开发平台2.0版本(以下简称“轻舟低代码平台”),以全新的可视化编程语言为特色,针对中等复杂度的企业级应…

宝塔 开启_宝塔面板安装完的一些列操作

前言新安装的宝塔会有很多地方需要配置,如果懂的大佬可以跳过,如果是小白可以按照辉哥的教程一步步操作,辉哥是以虚拟机进行操作的,但是服务器也是一样的道理!安全入口因为现在使用宝塔面板的人数在激增。所以为了避免…

黑灰产攻击洪峰来袭,企业如何守住自己的钱袋子?

简介: 风控大考最佳实践 根据阿里云历史行业风险治理相关数据显示,未经风险管控的自然流量中,约三分之一比例属于疑似黑灰产的高风险行为;而在建立合理的风控指标监控体系并采取风险防控手段后,高风险用户比例下降至3%…

服务网格的最佳实践

简介: 服务网格是用于处理服务间通信的专用基础设施层。它负责通过包含现代云原生应用程序的复杂服务拓扑来可靠地传递请求。 微服务发展的这几年,新的技术和概念层出不穷,这些技术的引入本质上都是在围绕服务稳定性和业务开发效率提升&#…

高性能开发,别点,发际线要紧!

作者:轩辕之风O来源:编程技术宇宙-前言-程序员经常要面临的一个问题就是:如何提高程序性能?这篇文章,我们循序渐进,从内存、磁盘I/O、网络I/O、CPU、缓存、架构、算法等多层次递进,串联起高性能…

如何打造一个高性能的前端智能推理引擎

简介: 什么是前端智能推理引擎又该如何打造和应用呢? 什么是前端智能推理引擎 在前端智能推理引擎之前,我们先来说一下什么是”端智能”。 端智能(On-Device Machine Learning)是指把机器学习的应用放在端侧做。这里…

115配额怎么增加_笔电、平板接口少怎么办,ORICO八合一多功能扩展坞助你一臂之力...

现在笔记本电脑大多都往轻薄的外形上发展,保持性能的前提下可以增加移动的便捷性,但是弊端同样明显,那就是牺牲掉了一部分常用接口。比如我手上这部戴尔XPS,左右两侧加起来只有4个可怜的接口,其中还包括一个SD槽&#…

OpenYurt:延伸原生 Kubernetes 到边缘场景下的落地实践

简介: 随着云原生技术的逐步成熟,阿里云容器服务团队在具体落地实践过程中不断探索云原生技术的应用边界。同时随着物联网和 5G 的迅猛发展,传统的边缘计算架构已经不能满足业务发展的需要。 如何基于云原生技术构建新一代的边缘计算平台成为…

对象存储,为什么那么火?

作者|小枣君 来源|鲜枣课堂引言上期文章(链接:关于存储技术的最强入门科普),小枣君给大家详细介绍了数据存储技术的基本知识,其中重点对DAS、SAN和NAS技术进行了对比分析。我们知道,在很长的一段时间里&…

使用react实现select_React笔记——核心概念:9.表单

1、受控组件在 React 中,可变状态(mutable state)通常保存在组件的 state 属性中,并且只能通过使用 setState()来更新。state:唯一数据源渲染表单的 React 组件还控制着用户输入过程中表单发生的操作。被 React 以这种方式控制取值的表单输入…