前言
上篇文章用了很长的篇幅讲述了全链路压测从零开始落地实施的主要过程，其中在准备阶段是最耗费时间和精力的。全链路压测是个复杂的跨团队协作的技术工程，所以在实施之前，需要明确项目的范围边界和尽可能提前识别可能存在的风险。这篇文章，就来聊聊落地过程中，如何确定范围边界和识别存在的风险。
确定范围
全链路压测，见名知意，其本质是一个技术验证手段和过程。即通过一系列的准备工作和测试手段，来验证系统在生产环境的“三高”是否能满足某些特定情况下的业务需要。
所谓三高，指的是：高并发、高性能、高可用。
就像我在这个技术系列文章的开篇提到的一句话：“全链路压测适合某一部分具有特定业务需求的公司，能否实施取决于是否有合适的组织管理能力和对应的技术架构”。
那么如何来确定全链路压测涉及的范围呢？流程图如下：
如上述2张图所示，以电商双十一大促举例说明。
1、确定业务范围
电商业务，比较核心的是导购→活动→交易的业务，因为这些业务能带来比较直接的交易额和利润，也是用户直接访问频次较高的业务场景。
确定业务范围，可以参考下面这张思维导图：
2、梳理应用范围
确定大促的业务范围后，根据业务和应用的对照关系，梳理出对应的应用列表。
PS：这个过程可能有多次的沟通协调和battle妥协，因为谁也不想由于自己的应用不在范围内而导致出事故背锅。
3、识别核心链路
目前互联网行业大多是微服务这种分布式系统架构，服务之间的内部互相调用关系很复杂，一般会借用链路追踪工具来识别他们的调用关系以及调用频次，以此来判断哪些是核心链路，以及他们的强弱依赖关系。
PS：强弱依赖关系，影响到稳定性预案如何设计，比如强依赖一般不可降级，弱依赖可通过降级和熔断或异步解耦来解决高并发下的流量冲击。这点我会在后续的文章中重点说明。
4、识别核心接口
知道了核心应用以及核心的链路，那么核心的接口基本就可以梳理出来了。梳理出来的核心接口，一般也是我们在做全链路压测时候的接口。
PS：到这里测试同学就可以开始着手准备对应的测试case、数据和压测脚本了，其中准备测试数据会耗时较久。
5、明确范围边界
如上图所示，交易是个实时且高频的场景，但订单支付成功后的仓储、物流以及收货后的社区分享，就是个非实时且流量更分散的情况，因此这些业务场景可以视其为非核心业务场景。
PS：当然，业务涉及的一些基本功能或者外部应用，如消息push、短信通知以及三方物流等，根据具体情况和对应供应商沟通协调好即可。
识别风险
除了确认压测范围之外，提前识别风险也是很重要的一项工作。常见的风险有如下几种：
1、交付风险
交付风险常见的有：拆分的细项任务无法按期完成，比如核心链路梳理，强弱依赖梳理。这些会导致后续的某些工作无法正常进行。因为在准备阶段，越是前面的准备工作，他的优先级和前置性越高，后续工作对它进度依赖更大。
核心任务拆解，可以参考下面这张思维导图：
2、依赖风险
前面提到了强弱依赖，最核心的原因在于：生产全链路压测甚至是应对双十一流量峰值的场景，需要准备很多的稳定性预案，常见的有限流降级熔断甚至主备切换和容灾恢复等。
这些预案需要考虑很多因素，最核心的是服务和中间件等组件的强弱依赖关系。如我上述所述，强依赖一般不可降级，弱依赖可通过降级和熔断或异步解耦来解决高并发下的流量冲击。
3、环境风险
全链路压测，无论是在单独的性能测试环境进行单机单接口、单机单链路、单机混合链路压测，还是在生产进行压测，对环境的要求是比较高的，特别是生产环境，需要考虑的更多。如流量路由的组件接入情况、mock准备、影子表、数据准备、预热甚至监控的覆盖度，都是会影响到环境的因素。
4、数据风险
生产全链路压测，最大的风险就是压测产生的数据影响到正常的用户业务数据，导致的数据污染。还有一种场景就是业务会出很多的报表，这些数据都是通过从业务库离线写入数据分析团队的库进行计算分析的，如果不能对压测数据和正常业务数据进行识别和隔离，会带来很大的问题。
上面的内容就是在全链路压测实施过程中，需要考虑的确定范围以及风险识别相关的内容，仅供参考。下一篇，我会和大家聊聊，关于核心链路梳理相关的一些技术细节，敬请期待。
往期技术文章推荐
