背景
阿里巴巴集团大淘宝技术全面推进云原生2.0战役——serverless 架构升级，此次升级不仅可以帮助业务提升效率，也可以降低业务资源成本。淘宝首页作为响应此次战役的第一个试点业务，是否可以平稳升级，决定了后续其他业务的升级工作是否可以顺利进行。因此，首页侧的质量保障工作变得尤为重要。
系统改造方案
此次升级不仅涉及接入层以及上层业务的代码改造，也涉及底层链路的改造。新架构对底层所依赖的容器、环境资源等与之前相比差异较大，并且对应的预发、安全生产、生产等环境，与旧架构的完全隔离。首页侧作为上层应用，拟从三个方面进行改造，分别是业务代码改造、发布流程改造和切流方式改造。
▐ 业务代码改造
首先需要在新环境上抽出业务基座层，并将部分业务二方包下沉到业务基座层。其次是改造mvn profile功能，支持一套代码能够同时运行于新旧环境（新环境代指serverless环境，旧环境代指改造前的非serverless 环境）中，且两类环境可以分别部署不同的二方包，实现依赖隔离。此外，依赖隔离时，也需要变更bean的初始化配置。
▐ 发布流程改造
将从切流前，切流中和切流后三个环节进行改造。切流前支持新旧环境使用各自流水线进行独立发布，切流中实现单流水线向双环境发布，切流完成后流水线仅保留向新环境发布的环节。
▐ 切流方式改造
从老架构过渡到新架构需要灰度放量，对应实现方式为接入层切流。本次切流，底层依赖集团内部切流系统，新旧环境分别使用不同的应用分组，而不同应用分组又绑定不同的集群KEY，统一接入层通过路由到不同的集群KEY实现流量控制。
从上述改造思路可以看出，本次改造范围较广，对业务稳定性影响较大。因此，在测试过程中需要尽可能覆盖所有的场景，确保改造后的业务功能可以正常如初。首页后端系统，本次升级改造架构图如下：
风险分析
本次架构升级具有高度不确定性，影响面未知，需要全回归验证，尽可能覆盖所有的业务场景。此外，由于涉及底层链路的改动，而底层测试具有局限性，因此也需要依赖上层业务进行全链路验证。基于首页精细化运营的特点，覆盖所有业务场景几乎是一件不可能的事情，且首页业务沉淀多年，历史包袱较重，包含大量复杂的业务场景。
质量保障方案
鉴于上述风险分析，从保障稳定性、减少核心业务损失以及降低测试成本等因素综合考虑，基于全流程层层拦截是一种有效的手段。在线下环节尽可能保证业务的全面覆盖，在上线后通过细致的数据观察来做后续的放量决策。放量过程中如果发现问题，可以通过切流的方式实现快速回滚。整体测试保障流程如下：
▐ 预发验证阶段
- 核心功能梳理、验证——主要对核心功能以及下沉二方包涉及的业务场景进行梳理并验证。
- 录制回放——通过录制回放辅助验证遗漏的业务场景。
首页版面本质是基于多业务组件（卡片）组合而成，升级后可能会引发一些潜在问题，比如某类卡片缺失造成无法在淘宝透出；透出时缺少一些利益点，ui信息；或者点击无法跳转，点击时业务埋点参数丢失等，如下图所示。此类问题可能在逐步切流过程中导致相关业务曝光减少，ctr降低，功能无法正常使用等。若依赖人工回归这些内容，可能无法100%覆盖且耗时较长，性价比极低。为此，在预发阶段使用录制回放，从线上引流，然后在新旧环境分别回放，通过对比结果进行验证。
但是，采用这种方式又面临两个问题：一是淘宝通用录制回放工具平台无法支持指定两个IP进行回放，然后对回放结果进行对比；二是首页对比规则是基于业务特性产生的，较复杂，平台侧无法较好支持。
▐ 发布阶段
- 加白验证——通过加白名单方式对核心业务场景进行再次验证。
- 录制回放——利用录制回放能力并行验证。此时，录制回放流程与预发验证的有所差异，改为从线上引流后，直接在serverless进行回放与对比。
- 单机压测——切流前，需要对新旧环境的各项参数指标进行压测对比，将新环境的各项参数调至最优，以减少机器差异造成的影响。压测方案如下：
压测环境：隔离环境，通过在header中增加标识，分流到新老不同架构
接口选择：选择首页主接口和购后信息流两个主接口（主接口和购后信息流是首页访问量最大的两个接口，比较具有代表性）
压测步骤：两套隔离环境同步压测，观察各项系统指标
灰度期间，如何保障大促例行化压测？
切流过程较长，期间会叠加大促场景，而大促前需要对集群进行例行化压测摸底。初次切流后压测，可能会存在一些潜在问题。首页作为流量入口层，很多下游业务的压测流量都对其有依赖，首页压测出现问题时，会对下游的压测实施产生影响。因此我们需要确保新环境压测出现问题后不影响原有压测计划继续执行。
综合考虑，最终采用双环境压测隔离方式，如下图所示。构造两套压测模型供新旧环境使用，旧环境按照100%流量压测，新环境根据流量比例压测 。当新环境压测出现问题时，停止即可，而旧环境可以继续执行压测。
