如何获得讲师PPT：
扫码关注公众号，后台回复「1071」即可获得讲师PPT哟～
还能一键订阅后续精彩活动内容～
直播间问题答疑：
问题1：老师有讲链路监控这块的定位，除了压测平台，还有哪些工具在配合使用？或者有没有比较好的工具推荐？
首先，先说一下调用链监控。我们公司级别，目前的话，涉及到的一个调用链监控。使用的是一个CAT，在此基础上，自研的DevOps平台也做了一些调用链的功能，这里面就涉及到整个链路，以及链路里面的一些端点分析，在这块做了一些完整的功能。所以在链路监控分析这块，我们是基于自研新平台所提供的监控能力，在平台上去做一些聚合分析以及以及相关展示。
工具推荐的话，像是APM的监控平台，业界也是挺多的，例如CAT、Zipkin，Skywaking等很多公司都有在用这些开源的IPM工具去做，目前主流的一些监控工具可能就是这几个吧。
问题2：工具模拟的场景和真实用户使用的场景有什么区别？是否能够完全匹配？（图片加载、是否走缓存）
工具模拟的场景尽可能的去模拟真实的一个业务场景，100%的模拟用户场景实际上是很难的。前面也提到了，我们梳理出来的100多个核心链路场景、链路接口、及一些非常核心的接口，针对重点场景也是会有一些打点的。比如说，比如说进店的一个逻辑。这一块是非常非常重要的一个接口，也是非常核心的一个场景。进店可以分成很多的进店场景，比如说：单网店的一个进店，包括根据LBS定位的这样一个进店。
所以说在去梳理场景的时候，像这些非常核心的接口且场景多的，我们会对核心接口的场景做一些埋点。然后去梳理出这个接口下不同场景的一个比例情况是什么样的。所以说针对于同一个接口，可能都会有四五种，甚至于更多的这种场景去做在不同链路上的规划。想做到100%完全和用户场景一样，实际上是非常非常困难的，只能说尽可能的去往真实场景上去靠拢。
问题3：针对现有架构环境，开源监控和自研有哪些优劣？
监控这一块的话，我了解下来，基本上说现有开源的。都需要基于自己公司的业务场景，包括整个技术架构等，去做非常多的一些技术改造的。而开源的一个优点，是说它的一些核心能力，不需要我们重复的去开发，去重复造轮子，然后更多的是基于业务场景去做一些适配。这样能够更快捷的将监控能力给搭建起来。然后自研的话，是基于自身的业务系统，我们开发出来更多的这种啊，符合我们公司，或者说自己的技术站特点的这种监控数据啊，像我们前面也提到，我们公司也是有不同的监控工具，以前的话是基于CAT去做的一些调用链的分析，现在整个基础站的升级，包括整个应用的升级，想要适配整体的监控能力，需要去做非常多的一些改造，所以整个技术平台这一块，也针对于整个调用链这块，做了一些自研的东西。当然底层核心的一些监控能力，还是基于开源提供的一些基础能力去做的一些有自己业务特性的开发。
问题4：怎么模拟混合场景进行不同业务的容量测试呢？
这个实际上就是涉及到了全链路压测，非常核心的两个点：一个是业务场景的梳理，就是说要怎么能够梳理出来，全链路的场景以及它的流量模型。前面也提到了很多通用的全链路压测模型。另外，还有很多的促销场景，包括不同渠道的流量场景。首先第一步，先要梳理出来每个业务，它的一个核心交易比例的模型。针对这种模型，才能够在工具里面去模拟，并发起对应不同比例模型的压力。所以最核心的点，实际上就是梳理业务模型。前面PPT里面也给大家展示了，像我们核心的电商零售场景，它不同的业务比例，从首页到商城订单加购等，每一步大概都会有这样的一个转化比例，包括每一步、每一个场景里面的流量占比。实际上在整个交易链路里，读场景是占了非常非常大的一个比例的。也就是说，针对于不同场景里面，不同的一个步骤，它都是会有不同的一个流量比例，所以说根据不同业务场景模拟不同的流量模型，是非常非常核心的。
问题5 ：老师你好，请问这边对于双11压测，可以分享下您遇到的一些对于性能提升较大的实践吗？
PPT分享内容的最后，在双11压测的一个实践收益那一块也看到了，通过第三轮到第四轮的压测，QPS得到了很大的提升。这里面涉及到了当时商品查询记录的一个问题。商品搜索实际上也是一个非常核心的一个接口，每一次搜索之后，关键字都会记录到数据库里面，当时这个场景下，是实时去写SQL的，就是说在单独压测时，它没有出现这个问题，在全链路压测，包括前面两轮压测都没有出现，在第三轮压测的时候到了这个瓶颈点之后，定位到这个实时写SQL之后，导致了整个搜索这一块的数据连接池被打满了，商品服务是一个非常基础的服务，有很多服务都是要依赖于商品这块的，所以导致了后续其他所有的场景出现了很多的一些业务超时。包括一些失误率、陡增等等。通过最终定位发现了这样一个问题，在优化之后，把这个点改成异步的这种方式，去做了一些落库，这样的话就解决了我们数据库连接池被打满的这样一个瓶颈。在下一轮压测中，可以看到，从三万多上升到九万多，实际上提升是非常明显的。这也就是为什么在做一些单独业务链的压测，包括单接口压测很多问题是压不出来的。只有通过整个全链路压测的方式才能够暴露出，整个业务系统它的一个瓶颈点。这个是当时针对于全链路压测这块体现非常明显的一个具体案例。
问题6：各个业务容量测试是怎么分析出来的？
前面PPT里面也展示了当时是通过活动期间的一个数据模型来做容量测试的。实际上每年我们都会有好几场大型的促销活动，比如说”6.18″、“11.11”，甚至“8.18”、”10.10″等，都会有很多商家去做一些促销活动。在2020年，我们做全链路压测的比例模型，就是以“6.18”期间的一个流量模型去做的一个流量翻倍，当时的一个模型倍数预计是“6.18”的两倍。实际上到后面压的话，都不止两倍的量，还要往上去压。这就是涉及到了，压测数据是怎么提取出来的？因为我们也有调用链监控系统，所以实际上每个链路、比如导航场景-首页里面，可能会涉及到非常多的接口，在对流量入口的监控，包括整个前端的监控也好，或者说后端的入口流量应用也好，在调用链里面，每个接口都会有它的一个峰值数据，能够给它通过手段去提取出来，比如说：一分钟它的调用量是什么样的情况？在大促期间，整体的峰值情况是什么样的？我们当时是提取了“6.18”期间核心链路场景的一个峰值，作为双11压测的一个基础指标。然后在这个指标基础上翻倍的去压测。
本文来自投稿，不代表TakinTalks稳定性技术交流平台立场，如若转载，请联系原作者。
微信扫一扫 