如何获得讲师PPT：
扫码关注公众号，后台回复「5132」即可获得讲师PPT哟～
还能一键订阅后续精彩活动内容～
Q&A环节答疑：
一、测试的用例是不是可以用流量录制回放来做？
这个地方它可能说的是自动化的一个过程。自动化过程其实分读和写读的场景是我们用线上的日志来做的，就是我们的标准，我们有统一的 TC 组件，是标准化的，所以我们的请求都是完整的。但是对于写场景我们直接用线上的那个是不可以的。线上的日志是不行的，因为它有对外调用，我直接在回放的时候就会出现问题。所以我们写场景就是用的刚才丹丹同学说的那个录制回放的数据做的，这地方刚才讲的没有细分展开讲是有用到。
二、本地化测试的时候能够解决联调的问题。（比如说两边都在开发的时候，联调可能会比较耗时，主要是想说一方在解决问题的时候，另外一方还需要等一下这种问题怎么比较有效的来解决呢？）
本地化，现在我们用到最多的一种是两边一起联调。它无论是 a 直接调b，或者是 a 调b，再间接调到 c 的话。现在都是在本地环境上去做的。就是两者他可能在 3 楼，我在 4 楼，我们沟通好，开始联调，前面讲到一个软路由或者叫泳道环境，当带着这个分支标识的时候，当请求打过来的时候就会就会打到a上，它就会debug。debug 之后会将请求打到b，再打到c。如果它是c，它会接到这个请求，它在自己的gvm 本地上进行调试，它都是在本地调试的。
现在联调的成本是降低的比较大。我可以简单介绍一下。这里边就会遇到一个网络是否通的问题。这里确实做软路由的时候做的、遇到的，因为本地是网络环境，跟 beta 工作区的网络是不一样的，所以这地方做了特殊的处理。而且网卡有多个，可能会造成识别的 IP 有问题。怎么解决这个识别网络的问题？比如 double 注册的那个 IP 端口，我们会先将本地发一个请求到我们的 beta 环境，我们 beta 环境就能拿到我们 IP 的来源。通过这个来识别正确的 IP 端口，所以将 beta 和本地网络打通，就能够实现 beta 环境调到本地，本地本来就能够访问到beta。
这里边儿还有一个易用性的问题就是，这个配置是不需要我们人工来做的，就是我们做了很多 idea 插件，刚才讲到的通用的插件需要把那个环境的名称配在我们的idea Tom cat 的那个标题上，这样它启动的时候会自动将 beta 环境对应的环境下的IP code 拉取到我们本地，我环境变量了它的 IP or double 的一些配置都会代替换掉，这样就实现了这个本地能够实现路由的这种能力。大体是这个样子。
三、本地化测试，A-B-C这样调用链路，本地服务如何接替B服务啊？
本地服务阶梯就是我本地这个A。本地化的时候是在本地的其他环境有一套基准的环境，它发布的时候，线上的代码和它的配置，它的数据等等都是比较标准的。然后本地承接 B的，其实是绑定了一个有软路由的环境，另一种是标识，我们现在做的就是将我们的浏览器绑定到这一个软路由环境上，那么每个浏览器它都会有的一个设备号码，理解为你无论手机和浏览器都是相似的，这样这个浏览器发出的请求都会带着我们的软路由的信息。
这样请求的时候，通过我们之前做的软路由的这样一个事情，就能识别到这个请求的来源，就把这个请求打到我们的 B的下面，其实 b 就是跟那个软路由是一样的。前面刚才也讲到了，是我们起 idea 插件的时候，把 beta 环境的那个配置拉到我们本地了，所以就能打到我们本地。
四、老师好，可以详细说说软路由吗？在本地服务接替环境服务的时候，如何保证请求到的是本地服务？改造网关负载策略吗？注册中心是什么？
第一种是我们只在软路由环境下，比如我们的那个浏览器打过来的这种请求打到我们本地，这是一种场景。另一种场景是因为beta 环境的机器也有自己的域名，比如它给这一个应用，或者它那指定的机器都是配有域名的，改动的时候会同步改 or 的一些域名的，就or 和理解为 ngx。我们公司用的是 open read 那个 or，简称 or，其实可以理解为就是网关，就 ng，我们把 ng 的那个 beta 的那台机器的网关也是改动的。但是实际上，如果我们只在在关联到的浏览器上去请求的时候，它是带着软路由标识，它会用软路由标识打到我们本地，就直接有标识能够打到本地。
第二个是注册中心，说的是 double ，因为 double 它有ZK，那一般是需要我的 provider 或往服务端那提供服务的时候是要先注册到 d c k 上去，但是在 beta 环境的时候，测试环境它已经注册过了，这时候。在启动本地化的时候，就会把注册中心的注册去掉，用本地的 IP 替换掉它注册中心那个IP。这样的话，当其它的请求再打，再请求这个 provider 的时候就会打到我们本地来。这里面有一个点，就是刚才提到的多网卡的问题，因为这个 IP 有可能会写错，我们也确实遇到过这个问题，所以我们解决这个问题，就是用本地先请求一次 beta 就能够拿到真实使用的那个IP，再注册到注册中心去。
如何保证请求达到本地化本地服务的？它是跟软路由的机制实现的就是泳道，这个实现方案会比较细节，可能比较多一些，其实它大体原理就是将它的配置改变改动了，然后它那个请求其实是它有个环境的概念，先有了环境之后就有一个路由的这种能力。路由的能力，我们常规是用我们代码分支关联的，给这个路由的环境打了一个标识。
有了这种软路由环境之后，就要有一个触发到软路由的能力，就我们这边叫设备，无论是浏览器，还是用手机、ipad、小程序等等，点击一下这个软路由的这个按钮，它就会自动识别到这个请求的来源，会绑定你这个 the session 的一个值，也就是说我们浏览器的那个标识。这样这个浏览器在发送请求的时候，只会打到我们这个路软路由环境上，这是它大体的一个实现流程。
去哪儿网的技术公众号上，会详细的介绍了软路由的实现本地化的实现细节，以及我们的一些坑点都已经记录的比较详细，可以得到更详细的细节的一个讲解。
五、话题互动：压测报告一般怎么识别服务瓶颈点，想问下压测结束之后怎么判断当前的瓶颈点是哪个？
鲁老师：
全链路压测这个事情，压测报告其实在用户感官上只是发了一个请求得到一个返回结果。我们的评判就会有多种、多个维度。
第一个维度是最外层的，就是现在的压测都是梯度的，并且是 RPS 的那种，就是按照一定流量去 QPS 去打请求。嗯，那会看响应时间是不是变化了。第一个是响应时间，它响应时间就包含了平均响应时间和 tp 50， tp 99， tp 95999，它的响应时间是不是有那种不稳定的现象？这是第一个维度。
第二个维度我们是有统一的报警的，就是压测的时候会在压测场景那配置，这个要它压的是哪个入口？入口都有对应的报警配置，会监听它所有的业务监控以及应用机器的一些性能，当出现一些波动或者报警时就会提示到用户，我们也有一些熔断策略。当然那是为了别压出故障来。
第三个就是在压测过程中会考虑到这个入口，因为全链路它会穿透很多应用，我们一般压测涉及到上百个应用，那么压测的时候就会出现子链路的这种情况。我们公司的有一个平台叫 trace 平台， trace 平台可以就是一个请求，它会有一个唯一的trace，并且这个 trace 它打到了哪些应用接口之间的 URI 信有哪些，都能拿到，所以就拿到了请求的URI，以及响应时间是否有异常以及异常的日志都能拿到。
第二个、第三个判断的瓶颈点，是在发请求的时候，会看到子链路节点在压测前、压测后的一个对比，一般是拿上一个高峰期，比如按天高峰期或者按活动五一的高峰期，会拿它当时的各个节点的监控，因为应用之间的调用都是有 watch 监控的，就是所有的 atp double 都有监控，所以它的响应时长在压测过程中会对比，如果它响应时间突增了，就会把它标红增长了。响应时间增长多少认为它异常了，异常比例是多少，会把它给标注出来。在压测报告里会有那么一个链路对比的能力，对比它的响应时间，还有异常。
第四个是直接返回结果的断言。除了返回的响应时长，因为压测功能测试经常会注重返回结果，压测注重返回结果不多，但仍然是有断言的能力。我们有返回内容的时候，会看它失败率有多少，就比如说它判断了必须返回结果里必须包含生单成功这个字段。那么就会看失败率是不是增加了？是不是突增了这种现象？大体是有这种四个方案来断言，是不是压出了问题？是不是达到了瓶颈点？其实现在是用压测的模式去用梯度慢慢涨上去的这种模式来做的。
沙老师：
压测报告的话，我们是有几种维度的对比：一种就是刚刚如果宁老师讲的就是对比，会去对比它这个返回值是不是正常，比如说：一共发了多少个请求，我正常的有多少个返回？异常的有多少个返回？这个是有一个数据对比的，还有一部分是我们会把压测之前的链路还有压测之后的链路都给它拿出来，还有压测之前每一个子调用，就是每一个对外调用。每一个应用的每一个调用，它的当时的 QPS 还有响应时间，从监控里面都给它取出来。还有压测之后的它，当时在压测期间它的 QPS 和响应时间也都拿出来，给它进行一个对比，这样就可以识别出来哪一个服务它是瓶颈点。
另外还有一个可以验证压测效果的，就是会看压测前的链路和压测后的链路，它的应用和接口的覆盖度，如果我发现压测走的应用，或者走的接口覆盖度低的话，那就说明压测没有达到效果，很多流程都没有测到，这个是从：核心应用覆盖度、核心接口覆盖度，这几个维度来去看这个压测的效果。
本文来自投稿，不代表TakinTalks稳定性技术交流平台立场，如若转载，请联系原作者。
微信扫一扫 