酷家乐多语言技术架构

简单描述就是前端代码和后端代码在不同语种情况下，都是通过获取CDN中存储的各类多语言的信息，也就是创建多语言词条会返回一个唯一KEY，这个KEY对应的是各类语种的value，但是由于酷家乐双发到国际化之后，是同一份代码，会导致有一部分中文忘记用词条了，或者后端服务没有用，就导致中文对外漏出。针对于目前国际化多语言的情况，测试团队现有的语言检测只有【接口扫描】

接口扫描流程图

即根据接口中返回是否为中英文以此作为判断，来校验是否包含中文，但是前端的内容大部分文本非接口返回，为词条中获取，以此为背景结合UI自动化对前端文本做中文扫描校验。以下图片中展示的是，22年至23年期间，出现的中文问题，几乎每个月都能出现一次，可以看出国际化的中文问题较多。

为了解决这类高频问题，思考通过别的途径解决该问题。
价值

现状：

1. 接口扫描所断言的中文信息不全
2. 扫描缺少交互性：各个业务场景所用到的中文，会根据入参变化。目前是固定参数来获取固定返回
3. 扫描覆盖度不高，不能完全覆盖各词条

解决的问题：

1. 全HTML文本：扫描并做检验
2. 根据用户操作习惯，所见即所得。将用户操作路径中携带交互所产生的文案，获取并检验
3. 校验接口扫描不能透出的各类词条文案

具体实施方案

流程图：

具体效果

• 我们假如当前页面是英文的情况下，出现了漏翻译的情况，如下图展示，几乎整片网页全是中文，具体如下

1. 页面效果：
   

我们想要的效果是将页面中的文字全部提取出来，然后对中英文做区分。

实现过程：以puppeteer为例，页面每次点击或者对于页面做hover的时候，页面元素都会产生相应变化，那么在页面产生变化的时候，将整个HTML DOM元素获取下来。则会得到一个动态情况下，网页文本情况，具体实现细节：我们获取HTML网页的时候，需要确保整个网页完全加载完了，这里采用【window.performance.timing.loadEventEnd -window.performance.timing.navigationStart】，windows下的方法，可以获取到整个浏览器完全加载完成的时间，减去网页刚开始加载的时间，获取到一个时间差，如果大于0则认为当前网页已经完全加载完。

然后通过：document.documentElement.innerHTML。方法获取整个网页的内容，最终存储在本地。

通过传入的元素，对getHtml再做一层封装，hover也类似，最终hover和click都具备网页爬取的能力。

分析HTML的逻辑是通过beautifulSoap的python标准库来进行扫描，通过将HTML内的中文提取出来，然后通过中文的Unicode的编码区间，来判断当前页面中是否有英文。

最终通过部署在远程机器的python脚本每天分析一次，将测试结果以邮件的形式推送出来。

最终报告：

最终得到的结果：截止2023-11-9  为起始时间至今（ 2024-2-20  ） 共扫描103次，非测试数据中文数：10个总共发现中文数：52次网络原因导致错误数：4次测试数据导致中文数：46次

后续的展望：

1. 和现有的平台做聚合网页巡检平台做配合，这样就可以脱离UI自动化代码，不需要人为去维护，只需要配置网页的URL自动去扒取网页中的文本，具体做法

我们网页巡检已经具备的能力：
从图中可以看到，当前网页如果存在A标签的话，会根据所设定的巡检层数来进行递归，例如当前巡检层数设置为3，网页有5个A标签，此时会将5个页面全部扫出来，5个网页继续打开，直到递归到第三层就算结束，但是由于此平台检测的能力只有3个

• console报错:浏览器F12控制台看到的Error类型内容
• 接口报错:状态码非200和非304的接口,响应内容中c!=0的接口
• 配置错误:外网网站配置了内网域名（需要开启“是否外网url巡检”开关）

2. AI扫描

我们目前只能做最基础的中文文本检测，但是我们是否能根据大模型的能力来进行扫描，目前调研的结果是可以的，以市面上常见的chatgpt就能将翻译后的英文，语义、错别字、等等都能一一扫描出，我们可以将python脚本提取出来的文本，传递给chatgpt从而达到，语言是否有中文，以及语言是否翻译准确了。

总结

多语言的要想做到精准验证接入AI的辅助必然是一个趋势，不然扫描出来的文本无法得到准确性，以及正确性的验证。团队内其他重复测试场景且现阶段无法做到自动化的还有很多，例如白标（简单理解白标的含义，各商家的logo是否包含特定酷家乐的标识）这类图标有各类长短分辨率大小不一的图片，要做到批量验证，也需要借助AI的能力，后续我们将提供更多的AI结合自动化的探索！

背景

酷家乐户型几何计算服务（下文简称kam）是计算密集型的服务，主要负责酷家乐户型业务的三维造体、渲染以及算量等模块，服务的特性是吞吐量低，cpu计算密集。


在高峰期进行动态扩缩容的时候，kam冷启动的表现一直以来都比较严峻，cpu使用率和cpu限制率会迅速飚高，进而影响服务的rt，严重时响应时间会到5s的程度，亟需治理。
在进行治理过程中，我们遇到2个奇怪的问题：

1. 高分期扩容时冷启动初始流量高，无权重变化。详细见一次服务预热问题的定位排查记录(1)。
2. prod环境开启预热反而比没有预热的效果更好，本文围绕这个问题，我们做了以下排查和定位。

问题表现

线上环境开启预热反而比没有预热的效果更好，表现如下：
开启预热：服务cpu使用率飙升到100%，cpu限制率飙升到150%，响应时间飙升到5s以上。
关闭预热：服务CPU使用率偶尔会有90%，cpu限制率基本还在40%以下，响应时间基本不波动，偶尔会抖。

定位过程

观察prod的启动秒级流量，截图如下：
而开启预热的情况，截图如下：
我们得到以下开启预热和关闭预热的两种启动流量趋势图：


可以看到，发现不开启预热的时候，会出现流量截断的情况，会在初始几秒进来流量，过了几秒之后发现流量降到0，持续60s，然后再涌入流量；而开启预热的时候没有出现这种流量截断的情况。

很奇怪，咨询了soa中间件，讨论后，发现这个是由于之前接入优雅上线的poststart脚本中，有soa下线和上线逻辑，两者中间刚好有个调服务预热的逻辑，而预热时间刚刚好是60秒。代码如下：

# 开始健康检查，直到成功或者超时（600秒超时）
http_code=0
for (( i = 0; i < 60; i++ )); do
        http_code=$(curl -s --max-time 10 -w "%{http_code}" -s -o /dev/null -X GET --header 'Accept: application/json' "${self_healthz_url}")
        if [ "${http_code}" = 200 ]; then
            echo "调用健康检查接口成功：url:${self_healthz_url}, code:${http_code}" >> ./logs/grace_log_
            break
        else
          echo "调用健康检查接口失败：url:${self_healthz_url}, code:${http_code}" >> ./logs/grace_log_
          sleep 10
        fi
done
 
# 健康检查是否通过
if [ "${http_code}" != 200 ]; then
        echo "健康检查未通过！" >> ./logs/grace_log_
            exit 1
fi
 
# 由于soa的原因，调用上线之前要先调用一下下线接口
self_shut_down_url=${self_start_up_url//"${DEFAULT_START_UP_PATH}"/"${DEFAULT_SHUT_DOWN_PATH}"}
resultCode=$(curl -s --max-time 10 -X POST -w "%{http_code}" -s -o /dev/null --header 'Accept: application/json' --header ${coops_header} "${self_shut_down_url}")
if [ "${http_code}" != 200 ]; then
      echo "调用shutDown接口出错，url:${self_shut_down_url},http_code：${resultCode}" >> ./logs/grace_log_
          exit 1
fi
 
 
# 调用预热加载功能，对接口不敏感
resultCode=$(curl -s --max-time 150 -X GET -w "%{http_code}" -s -o /dev/null --header 'Accept: application/json' --header ${coops_header} "${pre_start_up_url}")
 
 
# 调用上线接口
result=$(curl -s --max-time 10 -X POST --header 'Accept: application/json' --header ${coops_header} "${self_start_up_url}")
if [ "${result}"x = '"ALREADY_UP"'x ] || [ "${result}"x = '"OK"'x ]; then
        echo "soaPostStart成功：url:${self_start_up_url}, result:${result}" >> ./logs/grace_log_
else
  echo "soaPostStart失败：url:${self_start_up_url}, result:${result}" >> ./logs/grace_log_
  exit 1
fi

同时我们搜索了对应的日志，发现注册和注销时间点和秒级日志时间点也对的上。




也就是说，如上述流程所示，因为用户请求被截断，前置请求被作为了服务预热的一部分，再加上1分钟的自定义逻辑的预热，当脚本调用上线接口恢复用户流量时，prod环境的接口耗时，cpu限制率都处于一个比较能接受的水平，服务指标如下：

我们想到难道kam，用用户流量进行预热，比触发预热逻辑来进行预热，效果要更好。
由此，我们有一个思路，是否可以在当前预热现状（prod流量迁移至prod_warm环境，预热表现尚可）的基础上，在poststart脚本中模拟关闭预热的情况，来进一步改善预热，思路：先调用服务接口进行hbase/redis等连接→ 调用上线接口，等待5s用户请求→ 调用下线接口→ 进行服务预热逻辑→ 调用上线接口，流程如下。这样相比于关闭预热，我们可以预处理一些中间件的连接，保证服务上线后第一次用户请求不会有连接超时导致的错误，同时也能起到加速jit编译的效果。

验证

为了验证上述结论：

1. 是否是poststart脚本导致“prod关闭预热反而比开启预热效果更好”。
2. 新的思路“先调用服务接口进行hbase/redis等连接→ 调用上线接口，等待5s用户请求→ 调用下线接口→ 进行服务预热逻辑→ 调用上线接口”，是否可行，效果是否更好。

我们尝试进行内网压测验证，总结压测结果，表现如下：

压测结论：通过内网压测，可以看出来，冷启动在不同配置下，确实效果会有这样一个效果差异：用用户流量进行服务预热 > 关闭预热 > 开启预热

结论

所以我们可以得出结论：

1. poststart脚本导致“关闭预热反而比开启预热更好”。
2. 按照压测结果，先调用服务接口进行hbase/redis等连接→ 调用上线接口，等待5s用户请求→ 调用下线接口→ 进行服务预热逻辑→ 调用上线接口”，效果更好。

如何解决：

小流量服务预热模型：

相⽐于⼀般场景下，刚发布微服务应⽤实例跟其他正常实例⼀样⼀起平摊线上总 QPS。⼩流量预热⽅法通过在服务消费端根据各个服务提供者实例的启动时间计算权重，结合负载均衡算法控制刚启动应⽤流量随启动时间逐渐递增到正常⽔平的这样⼀个过程帮助刚启动运⾏进⾏预热，详细 QPS 随时间变化曲线如图所示：

服务提供端在向注册中⼼注册服务的过程中，将⾃身的预热时⻓ WarmupTime、服务启动时间StartTime 通过元数据的形式注册到注册中⼼中，服务消费端在注册中⼼订阅相关服务实例列表，调⽤过程中根据 WarmupTime、StartTime 计算个实例所分批的调⽤权重。刚启动StartTime 距离调⽤时刻差值较⼩的实例权重下，从⽽实现对刚启动应⽤分配更少流量实现对其进⾏⼩流量预热。
开源 Dubbo 所实现的⼩流量服务预热模型计算如下公式所示：

模型中应用 QPS 对应的 f(x) 随调用时刻 x 线性变化，x 表示调用时刻的时间，startTime 是应用开始时间，warmupTime 是用户配置的应用预热时长，k 是常数，一般表示各实例的默认权重。
这种方式需要soa做一次soa流量权重的控制，基于这个预热模型，再加上一层强制控制一段时间流量不超过上限，可以达到服务平稳上线的效果。

逐步开放流量：

通过冷启动机器的流量大小, 用低流量来先去诱发JIT, 再把发布机器的流量设置到正常水位, 避免在JIT过程中, 因为全量流量进来导致的CPU飚高、LOAD飚高、RT飚高等问题, 使得应用发布或重启时顺滑平稳。较为典型的是应用中的RPC服务，通过将项目中的HSF服务分批发布，逐步放开HSF调用的流量，可以减小由于大流量导致的JIT编译，缓解c2 compiler线程骤增对CPU占用过高的问题。应用启动后，利用网关的流量控制功能，按照时间间隔逐步放入流量，如：10%，20%...100%，或者给予不同的访问权重，使得服务能够逐渐到达正常访问的热度。例如，如果发现应用是重启，则开启流量分步加载策略，每当入口流量达到流量上限， 线程就Sleep下一秒，过后继续放量。根据时间间隔，逐步放开流量限制。

这种方式其实就是我们公司的soa流量权重控制，可以通过qunhe.service.warmUpTimeInSeconds进行配置权重变化的时间。但是这种方式显然就是本文第一个问题所阐述的没办法解决吞吐量小、上游多的时候，初始流量高、无权重变化的问题。

龙井预热：

阿里内部在OpenJdk的基础上进行了扩展形成Ajdk，拥有更多的功能，而龙井（DragonWell）是Ajdk定制版的开源版本，供各界使用学习。Jwarmup正是Ajdk的功能。

JwarmUp的基本原理：根据前一次程序运行的情况，记录热点代码以及类加载顺序等信息。在应用下一次启动的时候积极主动地对相关类进行加载，并积极编译相关代码，进而使得应用尽快使用上C2编译优化的指令。从而在流量进来之前，提前完成类的加载、初始化和方法编译, 跳过解释阶段, 直接执行编译好的native code, 避免一面解释执行一面后台编译带来的CPU与load飙高, rt超时等问题。

jwarmup使用的场景如下图蓝色曲线所示：项目发布阶段，大量的解释执行时把CPU占满，导致没有足够的CPU进行编译，会导致CPU打满并长时间在解释运行，没有机会编译，CPU的利用率会长时间居高不下。而开启了jwarmup后如下图红色曲线所示，大大缩短了编译的时间。也就是说jwamup可以跳过解释直接进入编译阶段。

对于kam来说，它是由于激进的jit编译导致cpu飙升。jwarmup可以跳过解释直接进入编译阶段，并不能解决kam的问题。

AppCDS-java10特性

CDS的全称是 Class-Data Sharing，CDS的作用是可以让类可以被预处理放到一个归档文件中，后续Java程序启动的时候可以直接带上这个归档文件，这样 JVM 可以直接将这个归档文件映射到内存中，以节约应用启动的时间。

这个特性其实JDK 1.5就开始引入了，但是CDS只能作用与Boot Class Loader加载的类，不能作用于App Class Loader或者自定义的 Class Loader 加载的类，其实有点鸡肋，而且这个是Oracle JDK的商业特性，在OpenJDK中似乎没有。

在Java 10中，则将CDS扩展为AppCDS，顾名思义，AppCDS不止能够作用于Boot Class Loader，App Class Loader和自定义的Class Loader也都能够起作用，大大加大了CDS的适用范围。有了AppCDS，可以给Java的应用程序带来两个方面的好处：

1. 可以提升一些大型的Java应用的启动速度。
2. 可以提升Serverless的应用程序的启动速度。我觉得这个点可能是 Java 10 提供 AppCDS 的主要原因，Serverless 极可能成为未来的应用的一种非常常见的形态，而把 Java 应用在 Serverless 上，相比于其他的语言来说，一个很大的劣势就是 JVM 的启动速度太慢了，虽然像 AWS 的Lambda，会给Java的Serverless应用加上-client来用Client模式跑加快启动速度，但是实际上效果甚微。有了AppCDS，可以大大加快Serverless应用的启动速度，按照 AppCDS 的 JEP 的说明，对于一个JEdit来说，AppCDS可以为JEdit提升20%到30%的启动速度。

AppCDS主要在于提高应用程序的启动速度，思路类似jwarmup，它可以跳过类加载提前进入解释和编译阶段，对于kam痛点主要在于初始流量高以及激进的jit编译导致的cpu超限问题，AppCDS不能解决kam的问题。而且公司目前仍旧使用java8，对于升级带来的工作量也是比较大的，但是可以作为一个新的思路尝试做探索。

总结

kam因为吞吐量低、cpu密集的特性，冷启动的情况严峻，具体包括两个方面：

1. 冷启动初始流量大，导致cpu限制率飙升，rt变高。
2. 会有反直觉的效果，开启服务预热，相比没有服务预热，效果反而会变差。

我们深入分析了这两个问题，原因分别是：

1. 上游过多，并发比较高的时候，到下游起始流量高。
2. 因为同时接入优雅上下线以及关闭了预热，导致有流量截断的情况，初始流量作为了预热的一部分，反而增强了服务冷启动性能。

从而得出kam更加倾向于用户流量进行预热的预热方式。预热新思路：目前kam的预热已经优化至比较理想的状况，在此基础上，我们在poststart脚本中模拟流量截断的过程，来进一步增强冷启动的性能。

参考

1. 谈谈Java应用发布时CPU抖动的优化
2. Alibaba Dragonwell
3. Sentinel
4. APPCDS
5. 《微服务治理技术白皮书》

在酷家乐设计工具测试中，总会有许多高频且较繁琐的工作，比如：

• 查询插件版本：需要打开Chrome控制台，输入好几个命令然后过滤出版本信息。
• 查询模型商品：需要先打开调试工具，查询得到模型商品id，然后跳转到测试平台进行加密，再去商家后台拼接url，最终访问到商品详情页。
• 修改定制高级配置：至少要点击4次页面跳转，才能开始配置。

类似的重复性工作实在太多，无形中影响工作效率与体验。并且大量的命令记忆对新手特别不友好。

仔细分析这类行为，大多都属于"数据查询"、“命令输入” 、“页面访问” 等简单操作的组合，其实非常适合“插件化”，封装成各种【一键操作】。

二、思路

基于上述背景，我们期望能开发一个插件来提高测试工作效率。

对于测试插件，主要有以下诉求：

• 开发门槛低。能让更多人参与进来，实现丰富的功能，满足各种需求。
• API 强大。便于扩展更多能力。
• 插件更新方便。便于新功能的推广。

最容易想到有两种方案： 酷家乐工具内部集成插件、Chrome 插件。但是很明显，这两种方式都存在开发门槛高、维护成本高、使用场景有限的缺点。

所以最后选择了另一种方案---油猴插件。

什么是油猴插件？

篡改猴 (Tampermonkey) 是拥有 超过 1000 万用户 的最流行的浏览器扩展之一。它适用于 Chrome、Microsoft Edge、Safari 等主流浏览器。
它允许用户自定义并增强您最喜爱的网页的功能。用户脚本是小型 JavaScript 程序，可用于向网页添加新功能或修改现有功能。使用 篡改猴，您可以轻松在任何网站上创建、管理和运行这些用户脚本。

简单说，油猴插件是一个 Chrome 插件，但是它的功能是一个脚本管理器，能将自定义的脚本注入到当前页面，让你的代码成为网页的一部分。

举例：在油猴脚本管理器中，仅用数十行代码就能在任意页面挂载一个刷新按钮。本质上就是一段H5代码。

所以它也正好符合我们的诉求：

• 开发门槛低。仅涉及H5开发，了解 DOM、javascript 知识即可。
• API 强大。脚本注入到当前page中，所以页面的元素、api都能直接访问。并且油猴还提供了许多内部Api，支持跨域、简单存储等。
• 更新方便。Tampermonkey 天然就是一个脚本管理器，脚本版本与更新管理非常便捷。
• 油猴工具作为一个前端插件，调用后端接口相对其他独立工具有一个天然优势，不需要额外登录，更加灵活高效

三、插件设计

3.1 功能组成

为了尽可能简单、易扩展，插件实现为一个悬浮的可拖拽菜单。并分为【小工具】，【常用链接】两种模块。

【小工具】主要集成一些交互操作，包括数据查询、前端数据修改、命令执行等。【常用链接】则内置了一些快捷跳转方式，可根据模型数据、粘贴板拼接 URL。

3.2 可维护性

为了便于功能扩展，菜单也采用配置的形式，动态挂载。在扩展功能时，无需关注 HTML、CSS，只需要给出工具需要触发的函数。为提升可用性，也支持配置每个小工具的显隐条件。

3.3 扩展性

油猴脚本的形态是单个 js 脚本，其开发过程相对简单直观。但是当代码量扩张后，单个js文件难以维护。尤其是酷家乐业务线众多，不同产品对于小工具诉求不同，维护多个js插件更难。为此，我们将插件脚本扩展成为一个 TS 项目，并支持快速扩展，轻松管理多个插件。

四、插件能力的扩展

前面用大约100多行代码，搭建了一个工具“壳子”，而真正有价值的是各种菜单功能的实现。要实现功能就需要借助各种API能力。下面介绍几类我们用到的API：

4.1 浏览器API

由于油猴脚本本身执行在当前页面中，所以浏览器提供的api都可以直接使用。如 window、document 对象，alert、prompt等。可以非常轻松地实现各种 url 操作、DOM 数据提取、前端数据提取等交互能力。

4.2 第三方库

油猴脚本甚至可以直接引用第三方库。浏览器内置的 alert 对话框不太能满足我们的需求，所以我们引用了一个非常轻量级的UI库---xtiper ，提供了多种实用的弹窗、toast 等。前例中，我们还通过静态资源引入了 jsoneditor。

4.3 接口请求

油猴插件支持跨域请求。往期的文章中介绍了我们内部的低代码平台--KUTA（服务端低代码实现和设计思路），其提供了非常多的优质接口工具。所以小工具插件也可以封装这些接口能力，减少在各个测试平台间切换的成本。

4.4 油猴API

油猴插件提供了非常多的内部API，可以极大的丰富脚本能力。如 剪切板操作、网络请求、文件下载，甚至能持久化存储一些简单数据。

4.5 工具前端API

往期的文章中也介绍过，酷家乐设计工具提供了许多前端api，可以直接通过控制台交互，方便我们的自动化测试获取模型数据、方案数据等。我们也用这些前端 api 封装了许多辅助工具。

五、插件功能演示

基于以上能力，我们将一些高频且繁琐的操作封装成快捷小工具。下面是几类典型的场景，以动画为大家演示接入油猴插件后的便捷操作方式：

数据查询

以前：1.打开酷家乐调试台工具-2.选择内外网环境-3.切换到用户数据查询页面-4.选择查询项目-5.输入用户信息

现在：酷家乐设计工具任意页面点击常驻的小工具，选择用户信息查询功能输入内容即可查询

模型交互

以前：1.选择模型后通过内部工具查看对应模型的id信息-2.打开商家后台页面-3.跳转到商品管理页面-4.切换到对应的行业线-5.点击一个其他不相关模型-6.替换模型id信息后刷新页面

现在：选择模型一键跳转到模型详情页

前端state数据访问与修改

以前：1.选择模型后通过内部工具查看对应模型的id信息-2.打开开发者工具-3.输入很长的命令执行相关API-4.再执行另一个复杂命令

现在：选择模型一键修改模型状态

url切换

以前：记忆不同环境的地址信息，记录当前方案信息后进行url拼接访问

现在：一键切换

六、总结

油猴脚本通常被网友广泛制作成各类神器，没想到引入到工作中也能有不错的效果。经过近一年的陆续迭代，测试插件里已集成了 40+ 小工具，整体代码仅1000多行。

由于其便利性，已经在产研、技术支持、实施团队内广泛使用，每天点击人次100+。

后续我们也会根据实际需要封装更多的便捷工具，提供更多个性化的配置能力。

渲染作为酷家乐通用的中台能力，一直承接面对较多上游业务。渲染类型多，渲染流量大。

面对大量业务问题反馈及工单数据，消耗了大量人工成本，尤其部分效果问题的沟通确认。

问题排查与回归压力大，快速迭代背景下对测试要求极高。

有限的人力面对海量业务时，总会捉襟见肘。

如何在此背景下做好业务质量保障，成为大家面对的一大难题。

我们的目标则是打造业务稳定质量可靠的中台，希望能做到以前几点：

• 业务快速对接
• 工单快速处理
• 质量稳定可靠
• 回归高效快捷

二、思路讨论

任何问题的解决都离不开人、工具和方法。对于业务质量问题，我们同样认为，流程、工具和团队建设都是必不可少的。

• 通过流程化规范化处理业务对接问题
• 通过平台工具建设提升业务效率，不断赋能业务
• 通过团队建设，建设一支协作紧密的团队，不断保障流程持续运转与平台建设

2.1对于流程体系建设

建立完善需求、设计、推测、部署、灰度、线上变更一系列规范，通过工具的方式完成关键节点识别与通知，不断完善各个节点的流程对接

• 产研流程建设：通过敏捷迭代治理，不断规范测试流程、线上操作与规范；规范发布标准流程，降低业务影响
• 业务线支持机制：统一中后台对接业务模式，设置关键角色跟进响应；整套体系赋能
• 应急与oncall：建立应急响应手册与oncall制度，线上问题高速高效处理

流程对不同业务大同小异，关键在于适用于当前团队，并能够持续推行完善。

2.2 团队共建

建设产研大团队，围绕不同业务属性，在对接和沟通中建设一支协作紧密运转流畅的团队。

对于测试本身来说，我们强调领头羊的作用，不断完善各项能力，鼓励探索各类有益实践。同时会将好的BP复制到其他业务线，实现以点带面的效果，并铺向大团队。

对于工作流，我们则跟进不同类型问题，推动相关角色的协作。如敏捷迭代治理，主要为产品、研发和测试同学的协作；工单问题排查，则为客服、技术支持、研发和测试对接模式。

2.3 工具建设

对于业务质量来说，从需求开始到上线后的一系列监控反馈，中间涉及多个环节，相应的也会有不同工具和平台支撑业务流转。

比如在敏捷迭代管理中，kaptain作为统一的任务管理平台系统，对于整个需求的生命周期管理非常重要。当然，这里更多会是基于流程的任务管理才会更加科学。

对业务测试与通用回归能力，我们有Apollo接口测试平台与Hades UI自动化测试框架，发布节点会执行CI卡点。

对于上线后的监控，有中间件监控以及业务巡检，可以实现日志、接口等不同维度的巡检能力，覆盖保障业务。

但是对于业务问题定位，及业务属性较强的回归能力，则需要业务线各自支持。

因而基于现状，我们实现了渲染的定位回归平台以及回归平台，进一步完善我们的质量保障手段。

三、平台能力建设

基于上述讨论结果，在充分利用当前已有能力和平台框架的基础上，紧贴业务建设多维度工具满足业务保障需求，实现工具平台化生态化

3.1定位能力建设：

面对业务线多，数据量大，所有问题必须从渲染侧倒序排查的问题，我们对定位工具实现以下几个关键目标

• 复杂链路下各个节点数据定位与排查能力
• 围绕渲染方案、渲染速度、渲染结果等各个维度的数据快速定位能力
• 复杂链路下的任务流转，串联场景并实现快速定位，并实现链接化定位能力
• 复杂业务场景数据的可视化建设
• 支持业务线数据定位能力快速接入
• 建设围绕渲染为核心的快速定位能力工具，支持业务线快速定位
• 围绕渲染链路数据，建设各类定位工具，完善渲染体系定位生态
• 赋能业务方与前线问题排查处理，释放人力

下图是定位平台核心能力，将所有渲染任务通过生命流转树的方式，记录所有关键节点数据，包括准入准出，从而为问题定位提供了极大便利。

并在此基础上，围绕渲染业务链路，不断拓展相关问题定位能力

关键能力一：任务流转树

如下图所示，定位平台实现任务全生命周期数据记录，并能够链路化展示关键节点状态，实现所有节点出入数据、状态、节点数据解析支撑。从而对渲染链路问题定位一目了然

上述的各个节点有不同的内部流转，比如 第一个关键节，点击我们可以看到该阶段下的关键数据和子节点

关键能力二：数据可视化

对于3D业务数据复杂不直观的问题，我们将业务数据可视化，支持3D拖动展示、业务数据过滤，从而业务线数据一目了然。为问题定位提供了极大便利，尤其是3维数据变更相关问题。

关键能力三：业务线赋能

任务流转树的概念，也通过二方包的形式提供给业务线，对于其他非渲染链路的数据，可以快速接入，从而实现定位能力的复用。

支持业务线数据快速接入，可以业务线链路节点自定义，将上下游场景化串联，从而打通断头路。如用户模型上传解析处理链路的各个节点，完成接入，方便相关问题的问题节点识别与处理。

关键能力四：渲染定位生态 丰富定位能力

除了上述渲染链路相关问题定位，围绕渲染其他数据，我们不断完善了相关数据的快速定位工具，如：方案图册数据快速查询、速度耗时快速诊断、渲染结果定位与数据修复，对于用户反馈问题可提供快速处理能力。

3.2回归能力建设

渲染上游对接了几十个不同业务，任务类型可达300+。

中台的快速迭代背景下，频繁改动不可能每次都协调上游业务协助回归测试。

同时，渲染场景的差异、速度和效果，都是我们需要提前考虑的情况。因此我们设计的大概思路如下

• 分别从前台、中台、后台三层，建设各类回归能力，多方位覆盖线上业务场景保障核心链路
• 提供用例快速生成及管理能力
• 支持回归结果的验收与效果的比对
• 打通回归能力与定位能力，回归能力工具化、业务化，通过回归能力实现快速问题定位，并反哺回归用例集
• 渲染回归能力好不好，如何评价？
• 如何实现渲染图效果的diff能力
• 回归能力如何快速实现问题定位
• 回归问题如何与定位能力快速打通
• 输出赋能业务线，降低中后台在业务线用例的回归成本

关键能力一：多样化的回归能力

回归能力分层，分别从前台、中台及后台不同维度支持独立回归能力，各自的业务回归不再强依赖上游， 只需关注自己业务的节点逻辑。实现发布与回归上的解耦，不再需要相互确认。

如下图所示，红线截断处即表示一个渲染任务在不同截断的节点。回归支持了从各个节点独立回归的能力，能保证互不依赖和数据的一致性。既可以独立回归，也可以为下游业务的回归提供协助。

关键能力二：用例快速生成与管理能力

测试用例一键录入、用例管理模块化场景化、定时回归与自由执行、中台场景收集、覆盖海量业务线、输出赋能业务线简单易上手

1、基于定位平台的任务流转树，我们可以快速将线上数据转化为测试用例，只需要提供一个任务的id，即可一键录入用例。极大提升了构造业务数据的效率。

录入方式上，支持多种方式的用例录入。除了流转树，也可以将用户自己保存的数据一键加入。

同时，可以根据不同业务线标识，快速从线上环境筛选数据转换。

2、用例标签管理。如下图，用例完成后支持用户自行打标签，平台也会根据用例数据识别一些关键标签，方便其他用户筛选复用。

3、同时将用例通过测试集的维度将同一类型的用例管理起来，方便同时回归测试。

4、对用例集分析，排查确认当前用例类型覆盖情况，以及任务结果执行整体概况，省时省力。减少人力维护成本。

关键能力三：回归结果验收与效果比对

快速展示回归进度与结果

支持类似任务效果比对，并通过diff效果图的方式展示，方便人工快速确认，如下图。

如同一类任务，上线前后，通过在beta环境和prod环境的效果验收对比，能够快速回归效果变化，尤其细微差异变化，能够减少人工误判

同样对视频，也支持同步播放能力，辅助确认效果变化差异

3.3发布拦截能力建设

围绕业务发布痛点，建立日志比对能力，最大化问题前置暴露。尤其海量error日志识别，需要在前期识别正常业务日志，并将可能异常的问题抛出来由开发确认，并纳入到发布流程规范中。

如下图，我们在各个阶段提供了新增日志与存量日志的识别能力，并通过灵活的更新与通知方式，提升各个阶段的测试验收确认

四、总结

通过一段时间的实践与完善，当前我们基本形成了以下固定协作模式

• 建立渲染各类对接机制，流程反馈完善工具的循环
• 工单响应流程化
• 问题高效对接标准化
• 不同角色各司其职
• 效能工具建设，工具支持流程建立与流程驱动
• 问题定位前置，释放研发资源
• 研发重点处理高优工单、疑难问题
• 新的能力与方法进一步平台化前置赋能，实现正循环
• 定位平台提升前线自助定位能力
• 业务对接与排查团队共建
• 团队全员工具建设能力
• 专项问题建设最佳实践团队

从结果来看，月均故障由6降到不足1个，每周发布时间由1d降到不足2h，高效响应支持30+业务线，平均问题处理时间下降70%，整体提效较为明显。

同时对于测试同学，各个业务团队合作更加高效，面对研发同学的相关问题对接沟通方式，也由反复督促变为通过监控变更和数据度量的方式。团队对接高效顺畅。

随着互联网的快速发展，邀请用户参与平台活动成为许多平台提升用户活跃度的重要手段。通过这类活动，平台可以实现拉新和促活的目标，同时也为用户提供了分享和推广的机会。然而，这类活动通常设置了诱人的激励机制，一些利益驱动者也看到了其中的机会，滥用活动规则进行不合规的薅羊毛行为。这些行为不仅会给平台带来经济损失，还会降低活动的公平性和用户参与的积极性。因此，每次进行邀请类活动的研发团队都需要高度重视如何尽可能地预防资损和薅羊毛事件的发生，以确保活动能够顺利进行并达到预期的效果。

二、激励活动框架

激励活动的核心流程是用户主动参与平台发布的活动，通过完成活动中设定的任务去获取相应的权益奖励。因此为了有效预防平台权益资损的问题，需要从用户、活动、奖励三方面去考虑相应的防控措施。

三、措施和效果

1、活动上线前

1.1 活动接口和页面的上下线验证

活动必须具有快速上下线的能力配置，这种配置不仅可以帮助运营在活动效果达到预期后快速下线活动使效益最大化，还可以帮助研发在发生故障时快速关闭活动入口从而降低资损故障扩大的风险。

活动上下线配置是活动发生资损故障时，快速止损的有效手段之一。针对这一措施，在测试时应当注意以下几点：

1、上下线的配置是否各环境独立，不独立的配置可能导致活动下线后无法在预发环境进行路径复现的问题。

2、配置的有效性验证。配置上线状态时，页面正常可访问，各链路接口调用正常；配置下线状态，页面不可访问或展示活动下线状态，接口无法调用或返回活动下线提示。其中需要重点关注的是接口下线情况的测试，防止活动下线后，出现通过调用接口的方式访问到活动并且获取奖励的违规行为。

1.2 活动用户人群验证

活动规则制定中很重要的一点是确定活动的目标人群。例如，一个面向人群A的活动中，一个非人群A中的用户可以完成活动任务并收到奖励，则会导致奖励超发从而引起资损。

针对这一项措施，在测试时应当注意以下几点：

1、活动页面的人群访问验证。不同用户人群访问页面需要给出相应的活动提示，提高用户的活动体验，也防止非活动人群参与活动出现客诉问题。

2、活动接口的人群访问验证。活动接口须对人群进行严格的判断，当非活动用户访问活动接口时需要有相应的错误提示，以免有非活动用户通过接口获取奖励。

1.3 用户信息的唯一性验证

用户信息包括用户id、手机号、邮箱、身份证、设备号等。参与活动的链路上根据活动规则校验用户信息的唯一性，是防止用户重复获取活动奖励的有效手段之一。

针对这一项措施，在测试时应当注意以下几点：

1、信息唯一性验证。根据活动规则，使用重复信息参与活动，验证接口是否会报错，页面是否给出相关引导提示。

2、数据存储验证。注意用户参与活动后，用户和设备信息存储的有效时间，是否和其他活动有冲突，以及存储内容是否正确。

1.4 奖励和规则验证

任务和奖励是确保邀请活动的成功与可持续性的关键因素。任务设置过难或奖励设置过小可能无法吸引用户参与，而任务设置过简单或奖励设置过大可能会对平台的成本收益产生负面影响。因此，设置合理的任务和奖励是非常重要的。

针对这一项措施，在测试时应当注意以下几点：

1、奖励发放准确性验证。奖励发放准确是活动测试最重要的点之一，若奖励超发那上线后会造成资损，若奖励发放不准确则会造成客诉。

2、奖励和规则的合理性验证。通过活动规则、任务难度和奖励价值，考虑价值匹配、奖励发放频率以及奖励的可变性是否合理。

3、规则在整个活动进行的过程中存在迭代优化的可能，因此记录测试方法、回归用例、测试数据、自动化测试脚本也十分重要，可以帮助在后续迭代中快速验证和回归。

1.5 同盾等第三方检测有效性验证

同盾等第三方的风控技术可以用于验证用户身份、检测欺诈行为和评估风险。在激励活动中，可以使用同盾等第三方检测服务来增加对用户身份的验证和风险评估的准确性。

例如：邀请注册活动通过第三方封控平台拦截风险注册账号4000+，平均每日拦截风险账号40+。

针对这一项措施，在测试时应当注意以下点：

风控有效性验证。上线前使用风控用户参与活动，验证第三方风控是否拦截成功。

2、活动上线后

2.1 奖励监测报警

一个激励活动会设定多种奖励类型，如会员资格、积分或第三方兑换券等。

在活动规划时，部分奖励会受到预算限制。为了避免达到预算后奖励超发对平台和用户双方造成损失，活动上线前设置奖励池余额的报警功能。当余额达到预设的阈值或出现异常波动时，系统会立即发出警报，以便进行进一步审查和处理。这样的措施有助于保护双方的利益和避免不必要的风险。

2.2 用户获得奖励数目监控报警

对于部分高价值的奖励，可以设置周期奖励数监控，当用户在某个周期内获得的奖励达到预设的阈值可以发出警报，并对该用户的获取路径进行排查，找出链路中是否有规则漏洞并及时完善。

2.3 奖励回收方法

当资损发生后，除了通过活动配置快速下线活动外，通过奖励回收工具对已发放但尚未使用的奖励进行最大程度的回收，也可以帮助平台有效减少损失。因此在上线前，需要准备相应奖励快速回收的手段，提供相关的回收工具等。

例如：邀请注册活动上线后，出现一次非目标人群用户可完成任务并获取奖励的资损故障，通过回收工具减少了70%的损失。

四、结语

通过以上的措施，可以尽可能的降低活动资损的风险，以及快速排查和应对资损的发生。随着技术的不断进步和经验的积累，我们相信激励活动将会变得更加智能和安全。通过不断改进和创新，平台可以更好地应对资损和薅羊毛问题，为用户提供更有吸引力和可信赖的活动。

背景

酷家乐户型几何计算服务（下文简称kam）是计算密集型的服务，主要负责酷家乐户型业务的三维造体、渲染以及算量等模块，服务的特性是吞吐量低，cpu计算密集。

在高峰期进行动态扩缩容的时候，kam冷启动的表现一直以来都比较严峻，cpu使用率和cpu限制率会迅速飚高，进而影响服务的rt，严重时响应时间会到5s的程度，亟需治理。
在进行治理过程中，我们遇到1个奇怪的问题：高分期扩容时冷启动初始流量高，无权重变化。围绕这个问题，我们做了一系列排查和定位。

问题表现

通过sentinel的秒级监控，我们统计了kam启动的前180s流量变化，趋势图如下：

服务冷启动的时候初始流量很高，瞬间达到线上平均QPS，虽然配置了180秒的流量预热时间（机器流量的权重会在180s内从0均匀增加到100），但是并没有看上去并没有生效。

而我们理想状况下，希望启动机器的流量如下分布，随着流量逐步增加，服务不会一下被打死，服务的性能随着jit编译预热的进行逐步提高。

定位过程

先来看下kam目前的客户端负载均衡算法，用到的是平滑加权轮询算法，类似代码如下，流程详看注释：

public Server choose(final ILoadBalancer lb) {
    int maxWeight = 0;
    int minWeight = Integer.MAX_VALUE;
    int weightSum = 0;
    // linked map记录加入顺序
    final LinkedHashMap<Server, IntegerWrapper> weightMap = new LinkedHashMap<>();
    final List<Server> svrs = serverList;

    for (int i = 0; i < svrs.size(); i++) {
        final int weight = getWeight(svrs.get(i));
        // 所有weight中的最大值
        maxWeight = Math.max(maxWeight, weight);
        // 所有weight中的最小值
        minWeight = Math.min(minWeight, weight);
        if (weight > 0) {
            weightMap.put(svrs.get(i), new IntegerWrapper(weight));
            weightSum += weight;
        }
    }

    final int curIndex = nextIndexAI.getAndIncrement();
    // 存在不同的权重，则使用weighted round robin算法
    if (maxWeight > 0 && minWeight < maxWeight) {
        // 在total weight中的位置
        int mod = curIndex % weightSum;
        // 逆向推算mod位置是什么元素
        for (int i = 0; i < maxWeight; i++) {
            // 按元素顺序轮询
            for (final Map.Entry<Server, IntegerWrapper> entry : weightMap.entrySet()) {
                final Server svr = entry.getKey();
                final IntegerWrapper w = entry.getValue();
                // 已完成mod次排放
                if (mod == 0 && w.getValue() > 0) {
                    return svr;
                }
                if (w.getValue() > 0) {
                    // 排放一个svr
                    w.decrement();
                    mod--;
                }
            }
        }
    }

    // 退化为取模轮询
    return svrs.get(curIndex % svrs.size());
}

搞个简单的单测看下不同权重的调用情况：

如果设置a的权重为3，b的权重为2，c的权重为1，并且是按照顺序调用的。那么结果的调用数量和调用顺序就是abc abc ab这样。 理论上kam新启动的机器应该有一个流量权重的变化。但是在问题表现中我们看到初始流量就很高了。
有点奇怪，我们和中间件一起做了定位，定位后发现负载均衡有一个固有缺陷，如下：

如果一个服务有6个consumer，每台consumer的qps有5，我们不考虑网络阻塞或者服务器抖动这种外界因素，虽然会通过加权轮训算法进行负载均衡，但是到达provider的流量为（consumer*consumer qps）/provider机器数，瞬间就能够到达30qps。
那么我们有理由猜测，没有权重变化的原因完全可能和服务特性和上游服务太多有关系，因为kam属于吞吐量小的服务，单台qps为20-30左右，而上游的consumer服务很多，有42个服务。
假设每个服务有10台机器，qps为4，那么到达kam的流量就会到达1600qps，kam线上高峰有70台机器，所以单台就有20-30的qps，起始就会有一个比较大的基础流量，符合问题表现中启动流量趋势的表现。

验证

我们再挑一个和kam本身比较类似的有较多上游服务A，以及一个上游数量少的服务B， 服务A上游有40个左右，服务B上游较少，只有7个。我们统计了他们的启动流量趋势，来做验证，趋势图如下：


从上图表现可以看出：

• 服务A上游较多，可以看到流量类似kam从一开始就到了一个比较高的水位50qps左右；
• 服务B上游较少，虽然没有明显的线性过程，但是有明显的从0到100权重变化的过程，到70s左右到达服务平均qps。

结论

所以我们就可以验证这个结论：上游越多，qps权重变化越明显，冷启动的qps越高；上游越少，qps权重变化越明显，冷启动的初始qps越低。
换个角度思考，如果能做到冷启动时候起始qps足够低，有权重的变化，服务应该就能够有充足的cpu资源进行预热编译，那么服务在预热完成后启动表现出来的性能也就能更加稳定。

如何解决以及总结

针对现实场景，对于kam这样上游如此多，流量基数特别大，而本身吞吐量又小的服务，在流量平稳的情况下，平滑加权轮询算法是非常合适的，它的流量分布比较均匀，有利于动态调整提供者权重。但是它仍然存在固有的缺陷：在冷启动的时候初始流量高。而且常用的客户端式负载均衡算法比如随机、加权轮训、最小连接数、最小活跃数等都会有相同的问题 ，无法避免。除非可以在客户端做一些全局的限流，但是有待验证可行性。而且经过调研（比如sentinel的warmup的流控模式是个研究方向，但是对于请求来说是有损），业界貌似也没有相关的实践来解决这个启动流量的问题。

但是我们可以换个角度来解决这个问题，既然初始流量高我们暂时解决不了，那么我们就需要从提升服务性能的角度来提高冷启动的性能。那如何针对实际情况来提高kam启动性能，我们留到下一篇文章再来讨论这个话题。

在美好的11月18日，我们将迎来备受期待的杭州第四届技术支持沙龙大会。本次盛会由酷家乐携手e签宝、科大讯飞技术支持团队以及Testerhome社区精心主办。作为此次活动的主办方，我们荣幸邀请到了业界一流的技术专家，他们将为我们呈现不可多得、精彩纷呈的演讲和分享，为广大技术支持同行们带来一场不可错过的盛宴。

借此机会，我们热情邀请您莅临参加。

议题介绍

活动地点

时间：2023年11月18日 13:00

地点：杭州市拱墅区余杭塘路515号莱茵矩阵国际2号楼13层培训室

日程安排

报名方式

扫描下方二维码即可参与报名

在这美丽的季节里，期待与您相聚！

本次分享将从酷家乐面临的稳定性问题和挑战，在稳定性保障上的工作思路，建设实践，保障体系，价值经验等几个方面，与大家一起分享交流。稳定性工作是一个非常复杂的工作，希望通过这次分享交流，我们可以一起持续探索这个领域的最佳实践。

一. 问题和挑战

随着用户体量变大和系统复杂度变高，酷家乐稳定性建设难度也越来越大。从酷家乐历年故障原因类型分析中可以看到，系统功能缺陷，系统设计缺陷，流程问题占比较高，接近80%。其中包括很多历史债，以及各种新的故障类型，在业务&架构变得更复杂后，稳定性建设工作进入到了“深水区”。在经过了仔细地复盘后，我们发现了非常多的问题，集中体现在：

• 能力问题
• 意识问题
• 流程机制

既然有这么多的问题和挑战，那么其他大厂是怎么做的呢？稳定性保障在很多“大厂”已经建设多年，在云原生观测，故障快速恢复&自愈，平台系统建设，智能化&移动化&数字化运营，以及完善的流程规范&度量&考核等各方面都形成了相对健全的稳定性保障体系。

而对比“大厂”，酷家乐在这些方面的建设相对落后较多。面临着业务监控建设缓慢，故障监控发现率低；快速恢复故障手段单一，恢复时间长；稳定性平台零散不成体系，缺少开发资源；流程和度量不统一，考核要求低等一系列挑战。

二.酷家乐稳定性工作思路针对这么多的问题和挑战，酷家乐的稳定性建设工作思路分别从组织管理，流程建设，数据运营&文化建设，系统&能力建设等四方面自上而下，循序渐进地做到日常工作中。

1.从组织管理出发，每年都要制定稳定性目标（比如：高P故障个数，故障平均恢复时长，高P警报个数，故障分等），从CTO到各业务线技术总监，再到研发经理&一线技术人员，自上而下的为结果负责。同时由CTO授权稳定性委员会对各业务线的稳定性工作运作进行监管和追踪，明确各角色职责，做到权责利统一。

2.完善流程规范，重新梳理和优化稳定性相关流程，确定流程负责人，明确流程指标，并进行宣讲和实践，让流程能真正运作起来。在线下跑通跑顺流程后，以流程指导系统建设，逐步将流程固化到IT系统（避免建设资源的浪费）。比如最基本的故障应急流程，谁来拉群组织应急，谁来协调资源，谁来同步信息，都要有明确的流程规范，以及IT系统支撑高效运转。关于应急流程，我会在下面再具体展开来讲。

3.从流程中提炼出核心结果指标和关键过程指标，定期自上而下的通晒稳定性目标数据，运营指标，驱动业务线改进，形成文化&氛围。比如我们会把故障分，故障恢复时长，故障监控发现率等通过周报，群内推送等方式通晒，自上而下的追踪和分析这些数据。包括做的好的业务线的一些最佳实践分享，以及定期组织一些演练比赛等等。

4.在指标数据推动各业务线同学分析改进的过程中，我们会将实践中的能力和经验沉淀到稳定性相关平台建设中。慢慢从单点突破，到由点带面，逐步形成体系能力。比如，通过故障原因分析，发现变更故障多，就重点抓变更管控系统建设，在业务高峰期，严格控制核心业务系统发布窗口等。再比如发现大家应急能力和预案不足，组织学习应急经验和实践，在提升能力的同时，也完善各种应急操作系统功能。

当然稳定性有很强的技术相关性，本次分享主要侧重点在整体体系的实践，所以会从整体角度来分享。

这四个步骤，相对直接借鉴“大厂”的体系化建设经验，搭建各种系统平台能力，会更“轻”一些，从成本上也能很好的控制。先从组织和流程能力双管齐下，通过数据运营和指标驱动，然后再逐步地完成系统和能力建设，有着先轻后重，先看效果，后建能力，低成本，重管理，抓指标的特点。

三.酷家乐稳定性建设实践

下面我们就具体展开来讲酷家乐的稳定性建设实践。
1.意识问题

首先，我们看下我们面临的第一个问题，意识问题。这里的每个问题，背后都是一个个故障，这些结论都是通过深入的故障复盘总结出来的。

线上意识薄弱

发布时和发布后，需要做业务观测，看业务表现，日志，监控，客诉反馈等。但有一次变更，发布后没有做观测，连最基本的告警报出来，都没及时处理，本来当天晚上可以及时发现解决的，硬是等到第二天早上用户批量反馈后，才开始解决。

管理不重视日常应用运维能力

研发忙于日常业务需求，针对基本的应急能力，平常不重视学习和演练。真正发生故障时，手忙脚乱，忙中出错。

比如某次故障，前端有个bug，导致请求流量翻倍，本来应该能通过限流快速解决，但错误的执行了切换集群，导致问题扩大化，本来只是打开慢，现在直接挂掉。

责任不清晰

部分同学的行为缺乏敬畏，认为出现故障很正常，修复就好了，反正也没有明确的责任要求。

比如某次故障，开发做一个线上配置变更，在没有完全搞清楚配置操作的影响范围的情况下，随意地执行了配置操作，直接导致线上所有文案类配置显示大量错误，导致各种用户投诉。

稳定性组织保障-三级责任制

针对上述问题，为了保障稳定性，各产品线、各敏捷组，都需要在OKR中背负一部分稳定性指标，并明确地将其完成度纳入绩效考核中。

稳定性建设工作需要多方配合，涉及到开发，测试，SRE，运维，监控团队，中间件团队等各个角色的协作和配合。因此，需要从组织管理的角度，思考如何更好地让相关方能在各自的领域完成工作的同时，又能高效配合，共同为结果负责。
首先，明确稳定性保障工作的主体为各业务研发团队。各业务团队研发总监，研发经理等要以身作则，与CTO自上而下一起承担稳定性结果指标，作为绩效考核的依据。在组织保障层面构建出 “总监->研发经理→应用Owner/一线研发”的三级责任制。

其次，酷家乐创造性地建设了“稳定性委员会”的横向虚拟组织，由CTO和各技术总监授权，挑选横向团队中的精英骨干组成稳定性委员会，运作稳定性日常工作。包括流程规范的制定，监管，问责，追踪各业务线稳定性工作等。

稳定性文化建设

有了组织保障之后，再配合文化意识建设等氛围的营造，往往能达到事半功倍的效果。

a.稳定性宣传针对稳定性目标和各种考核结果指标，定期通过海报，周报，月报等期刊通晒数据，以及同步最新的稳定性工作建设进展。同时，定期组织各种专项活动，比如突袭演练活动，让各业务线锻炼团队应急能力，验证服务容灾预案的合理性，提升团队应急止血速度，以及问题定位能力，选出故障应急最强战队，营造氛围。

b.稳定性培训&分享上面提到的各种应急能力和意识（怎么处理监控告警，怎么快速执行预案恢复故障），需要通过各种培训分享来推广落地，尤其是新人培训，必须要纳入到新人的入职培训体系中，并组织理论考试和实操考试（演练）。

此外，各业务线在稳定性方面做的好的方面，也要鼓励他们写出最佳实践的文档，在研发内部分享，推广到其他业务线使用。

c.稳定性奖针对做的好的同学和团队，设定稳定性奖项：从稳定性盘点，演练，应急监控，预案，复盘等事前，事中，事后各方面设置奖项，鼓励做的好的团队。

d.稳定性惩：对于违反红线等情况，实行绩效考核，以及研发内部通报批评等。

实际结果和价值
经过一段时间的治理：线上故障的平均响应时长大大降低，研发同学对警告的敏感度提升非常明显。在业务线和公司的整体应急警告处理群，都能有序的执行和运作起来。

2.流程机制问题

第二个大问题：流程机制问题。

1.流程不完善

很多流程缺失，导致很多稳定性工作变的很混乱。比如提到的数据变更类操作，在发生那次故障以前，完全没有流程和规范要求技术同学应该怎么做。除了流程缺失外，有一些流程也只是停留在文档上，出现无人维护，无人推动和无法落地等情况。没有人为流程结果负责。

比如有一次故障，做线上的批量数据更新，竟然没有按照数据变更流程去做数据的备份，出错之后无法短时间快速回滚，一堆开发花了4个小时重新修复了数据。

2.流程执行不到位

在故障应急时，各自为战，信息不通畅。比如有次故障应急，没有统一的指挥和协调，不同业务线的好几个同学大量做隔离和扩容操作，将原本负载偏高的机器再次推满，本来故障已经快恢复了，因为这些操作反而导致故障又恶化了，且恢复时间也变长了。

此外，我们的复盘流程规范对怎么做复盘做了非常明确的要求，部分开发同学在做复盘文档时出现分析不深入，改进措施无法避免再次发生等情况。比如在故障原因的分析方面，没有分析从故障引入到恢复的全部过程，而只是停留在表面上的技术原因。在原因分析不全面的情况下，制定出的改进措施可想而知效果也不会太好。导致故障的管理没有闭环。

流程建设实践----以应急流程为切入点

针对上述问题，我们整体上盘点了稳定性相关的流程规范，下面就应急流程举例说明。

线上应急作为稳定性保障的重要日常工作，应急效果的好坏直接关系到是否能快速恢复故障，以及降低故障对用户体验造成的影响。因此，在流程建设中，以线上故障应急流程为切入点，我们重点梳理和优化了该流程，打造技术支持&SRE值守&业务线值班长owner机制。让值班长owner故障应急全流程，在响应，判断，通告，拉群，升级，解决，验证等各个关键节点，以降低损失，恢复线上业务为第一优先级，做到有序高效地应急。

流程管理机制和指标建设
从应急流程切入后，由点及面的扩展相关流程建设，比如故障等级定义，监控&巡检规范，封网流程规范，发布规范，演练流程规范，变更红线规范等等一系列稳定性配套流程规范。

同时，在流程中，明确各种稳定性关键结果指标，比如故障分，故障恢复时长，故障监控发现率，故障复盘分，演练分等，以便做目标管理和考核。
在流程和指标建设中，需要特别注意以下两点：

1.每个流程都要有owner，为流程结果负责；定期更新和维护流程，并持续推动流程落地，做好监督和检查。最后，通过IT系统固化流程，做到自动或强制执行。避免流程成为摆设，无法落地。

2.稳定性关键结果指标，一定要从CTO到研发自上而下的负责，落到绩效考核结果中。

意识&流程机制建设概况
总结：针对上面提到的这些组织管理和流程能力的痛点，酷家乐进行了一系列针对性的措施。确认以稳定性委员会作为日常运营和监管的重要组织，明确各角色职责和流程规范。设立稳定性目标和各种结果指标，营造由CTO到一线研发自上而下的为稳定性结果负责的考核要求和文化氛围。以月报期刊，红黑榜，各种奖惩等手段，强化所有同学的稳定性意识。相对来说，成本适中，收效明显。

3.能力问题
第三个问题：能力问题。

能力问题，是一个较大的问题，包括告警的治理和闭环能力， 应急处理和改进能力，变更管控的能力等等。

1.能力痛点-----告警治理能力
为什么要做SRE监控值守和巡检？

通过观察酷家乐的高P告警数量，发现平均每天有180+的高P告警。对研发同学来说，每天跟进和处理这么多的告警，是有一定的压力的。另一方面，也说明我们的系统处于亚健康状态，需要不断的优化和治理。

此外，很多告警&巡检发现的问题，因无人跟进或排查难度大等原因，导致有一些问题没有被彻底解决，成为线上故障的隐患。

最后，做监控值守&巡检，最主要还是为了提前&主动发现和解决问题，避免因处理不及时导致故障。

监控值守&巡检闭环
a.基于上面提到的问题，SRE和监控团队的同学，打造了一整套的监控和巡检体系。梳理监控&巡检流程规范，打造7*24小时监控值守，聚合高P疑似故障告警，推送到公司监控大群，提前发现和解决隐患，并建立警报事件跟进排查出根因&改进。

b.针对云服务器，中间件，网络，应用等系统自动每日巡检，对发现的异常，创建任务确定优先级，并指派到对应的研发负责人跟进解决。

c.每日汇总高P告警数量，重点警告概述&分析，以及线上业务量情况等，形成SRE日报，每日推送到研发大群。

d.持续跟踪创建的任务，根除告警和巡检发现的问题，并完善全链路监控系统和监控诊断定位系统。

监控和巡检发现的问题会创建相应的任务，根据优先级和任务归属，指定给对应的研发owner，并要求在规定时间解决。定期会通晒解决数据情况。

2.能力痛点-----应急能力
a.应急协同

分工不明确，不知道应急的时候应该做什么。

b.信息同步

故障期间,各个群内消息杂乱，容易漏掉关键故障进展信息。

c.复盘管理

故障复盘信息没有平台统一存放，散落在各个文档，不方便查看和回顾。

a.应急响应能力：
一键拉群&一键外呼，发送故障通告信息到公司应急群。定期更新故障通告，保障信息同步通畅。

3.能力痛点-----变更管控能力
随着业务的快速发展，系统之间的依赖耦合也越来越复杂。历年来酷家乐出现了多次因为A业务的变更导致B业务线上异常而出现故障。此类问题出现，都是有一方做了线上变更导致另外一方异常，并且排查的时候受影响方影响，比较难在第一时间快速定位到是哪方的变更导致，尤其是涉及一些线上配置变更的问题。

经过梳理和分析酷家乐线上变更数量和相关系统，发现以下几个痛点：

• 变更数量多：平均每天350+变更量。
• 变更系统多：涉及到12+变更系统，包括发布，配置，数据变更，运维操作等。
• 定位变更难：故障时，无法快速定位到对应变更，无法快速准确的回滚。

变更和监控，巡检，故障应急，封网能力建设
因此，在变更管控方面我们做了以下几方面的事情：

• 线上变更统一收口：将酷家乐95%以上的变更系统接入到变更管理系统。
• 变更打通监控告警：在告警中展示最近变更情况。
• 变更打通巡检：收到变更消息后及时触发线上巡检能力，利用线上自动化测试能力和及早发现线上问题能力。
• 变更打通故障应急：在故障发生时，及时拉特定时间范围内特定服务的变更数据推送到故障分析群，辅助故障定位和快速恢复。
• 核心系统的发布接入封网管控：封网期间，推送封网信息到各核心发布变更平台，禁止线上变更。业务高峰期的高危变更推送提醒。
  

真正执行封网管控之后，从源头管控了无序变更导致的故障。

1.为什么要做故障演练

衡量稳定性工作做的好不好，最直接的方式就是多搞演练。

通过演练，至少可以有以下作用：

1.故障突袭、联合演练：以战养兵， 提升DevOps能力。处理问题的人是否熟练？沟通机制是否有疏漏？

2.架构容灾测试：主备切换、负载均衡，限流降级&熔断等手段的时效和效果，容灾手段本身健壮性如何。

3.预案等措施在故障发生时是否真的有效？

4.监控报警：报警的有无、提示消息是否准确。5.故障action验收。

2.演练平台建设

沉淀通用的故障场景，以可控成本将故障重现，以持续性的演练来暴露问题，不断验证和推动系统、工具、流程、人员能力的提升。

从前期准备，故障注入，演练期间，复盘等四个阶段展示了突袭演练的流程。

演练运营：

1.前期准备

分析历史故障，演练场景设计，活动方案和玩法制定，奖品准备，活动前期宣传和预热，报名等。

2.活动执行

每周执行突袭活动，演练后进行复盘&打分，通晒数据&营造氛围。

3.活动颁奖

根据打分评选优胜队伍，组织颁奖仪式，邀请CTO等颁奖嘉宾，活动总结复盘和推送。

四.酷家乐稳定性保障体系总结

最后：价值和经验

通过上面一整套体系化的治理和建设，我们的高P故障恢复时间缩短30%，高P告警准确率90%+，巡检发现和解决问题数量100+，改进措施完成率99%，90%以上变更系统接入变更管控。

除了本身对酷家乐的价值，对于其他公司实践可以从以下几个方面借鉴：

1.组织管理，自上而下的重视程度。

2.抓流程建设&流程owner落地。

3.重视文化建设&营造氛围。

4.以流程指导系统建设。

5.持续建设&将稳定性做到日常。

酷家乐是全球领先的3D云设计平台，作为一款主打室内装修设计软件，面向家居、公装、建筑、房产等领域，为企业和个人提供设计、营销、生产、管理等一站式解决方案，致力于“用设计让未来生活所见即所得”。那么要支撑云设计工具用户体验丝般顺滑，快速渲染出效果图、全景图和720°漫游图，离不开端到端的性能保障体系的支撑，这边重点介绍一下酷家乐前端性能保障体系：从2022年H2开始，明确提出前端性能领域体系化建设思路，全方位覆盖以云设计工具为主，包含酷家乐、美间、Coohom国际站、模袋云为产品代表的端到端用户体验的标准化性能保障体系。

二、性能标准&流程规约

目前酷家乐主要是2套性能标准、1套线下性能卡口流程规约：

• web页面标准一套：主要是酷家乐网站、美间网站、国际站主站使用。《 W3C标准 》、《 Google Lighthouse性能体验标准 》
• web应用标准一套：

线上：主要是酷家乐工具、美间工具、国际站工具、模袋云工具为代表。《 云设计工具性能标准 》

线下：《 线下宽口径性能标准及卡口流程规约 》；

那么我们接下来了解一下相关性能标准。

W3C性能标准

W3C-window.performance是W3C提供的用来测量网页和Web应用程序的性能api

按图所示，window.performance就记录从用户在浏览器输入url开始到前端页面onload达到页面加载完成达到完全可交互状态，酷家乐当前各业务站点的网页性能也是结合W3C业界通用标准梳理出相关核心性能指标。

• TTI:time to interactive，可交互时间，测量页面从开始加载到主要资源完成渲染
• FMP:first meanning print，首次绘制有意义内容，当整体页面的布局和文字内容全部渲染完成后时间
• TTFB:页面首字节响应的时间，衡量服务端响应以及网络情况。
• FP:白屏，衡量用户白屏等待的情况。页面开始展示的时间点(domLoading)-开始请求时间点(navigationStart)

Goole Lighthouse性能体验标准

Google在2020年5 月5日提出了新的基于用户体验量化方式 Web Vitals 来衡量网站的用户体验来综合评估移动友好性、浏览安全性，以及Core Web Vitals 中关于加载性能、交互性、视觉稳定性等，而且google本身提供系列指标项，将这些衡量结果用作其排名算法的一部分，所以我们一般会使用google lighthouse的指标做行业的竞争性能的排行。为了更好地理解这些内容，让我们来看看这些重要指标是什么

核心指标

• 加载性能（FCP指标）— 首次内容绘制
• 加载性能（LCP） — 最大内容绘制
• 交互性（TTI） — 持续可交互时间
• 视觉稳定性（CLS） — 累积布局配置偏移
• 渲染阻塞（TBT） — 总阻塞时间

目前这套标准部分指标，比如LCP（Largest Contentful Paint）用于衡量加载体验，从真实用户的角度衡量网页的加载速度，作为Coohom国际站主站线上很重要的一个性能指标。同时，网站线下性能自动化，也广泛地应用了这FCP、LCP、TTI、CLS、TBT进行web页面的线下性能自动化评判标准。那么怎么样算是优秀的，google通过给出一套标准的性能体验评级推荐。

例如，LCP耗时在2.5秒之内被认为当前页面处于性能优秀，LCP指标耗时在2.5秒和4秒内，性能有待提升，而大于4秒则属于性能较差

再比如，当某些时候网页中的元素在加载时出现移动，这不是用户期待的优秀体验。在这样的场景中，CLS（Cumulative Layout Shift）测量在页面的整个生命周期中发生的每个意外的样式移动的所有单独布局更改得分的总和，可以方便地用来度量 web 页面的视觉表现。布局的移动可能发生在可见元素从一帧到下一帧改变位置的任何时候。为了提供良好的用户体验，网站应努力使 CLS 分数小于 0.1

设计工具性能标准

作为酷家乐的主营业务，不可不提云设计工具，这套是公司自定义的性能标准。《 云设计工具性能标准 》 、《 线下宽口径性能卡口标准 》当前定义了非常详细的标准，主要分为加载类和消耗类两大类性能指标项，具体见下图：

其中难点在于卡顿类的指标，平均帧率和最长帧耗时、最长帧耗时之间的关系是怎么样的，可以从下面这部分内容了解

屏幕成像原理及卡顿原因

屏幕显示原理 屏幕会把像素点上，由左往右，完成第一行的像素扫描，然后等待水平同步信号的到来，电子枪会来到第二行的初始位置，这样由左往右，从上往下，逐行扫描，来到显示器的右下方，等待垂直同步信号（vertical synchronization）的到来。这样就完成第一帧画面的绘制，电子枪复位，回到左上角。上面第二张图，主要描述，计算机系统中CPU、GPU、显示器相关模块的协同工作。CPU 计算好显示内容提交到 GPU，GPU 渲染完成后将渲染结果放入帧缓冲区，随后视频控制器会按照 VSync 信号逐行读取帧缓冲区的数据，经过可能的数模转换传递给显示器显示。

屏幕卡顿 在 VSync 信号到来后，系统图形服务会通过 CADisplayLink 等机制通知 App，App 主线程开始在 CPU 中计算显示内容。随后 CPU 会将计算好的内容提交到 GPU 去，由 GPU 进行变换、合成、渲染。随后 GPU 会把渲染结果提交到帧缓冲区去，等待下一次 VSync 信号到来时显示到屏幕上。由于垂直同步的机制，如果在一个 VSync 时间内，CPU 或者 GPU 没有完成内容提交，则那一帧就会被丢弃，等待下一次机会再显示，而这时显示屏会保留之前的内容不变，中间这个等待的过程就造成了掉帧，也就是会卡顿。如图所示，是一个显示过程，第 1 帧在 VSync 到来前，处理完成，正常显示，第 2 帧在 VSync 到来后，仍在处理中，此时屏幕不刷新，依旧显示第 1 帧，此时就出现了掉帧情况，渲染时就会出现明显的卡顿现象

• 平均帧率（avgFps）：连续操作的帧率，如拖动家具等连续操作过程中的帧率，平均帧率的标准40帧，满帧一般情况60帧，即每一帧16.67毫秒
• 稳定帧率（stableFps）：当前工具稳定帧，是去除了前面3帧，最后3帧，剩下54帧的平静帧率
• 最大帧耗时（maxFrameDuration）：除之后一帧之外的行为最大帧耗时，单位毫秒，当前最大帧上限标准300ms 丢帧卡顿感主要参考指标
• 最后帧耗时（lastFrameDuration）：最后一帧耗时，单位毫秒，当前最后帧耗时上线标准300ms，为啥最后帧耗时作为单独指标，是因为当前酷家乐工具在尾帧的时有model层的数据提交，一般会比较卡，所以单独列出来进行性能度量，而美间工具会以设置首帧耗时，是因为首帧有一些耗时操作需要单独衡量。丢帧卡顿感主要参考指标

最长帧/最大帧耗时对屏幕是否卡顿进行辅助性能分析，大家看上图-卡顿掉帧原因，Vsync垂直同步信号发生的间隔为16.67毫秒，也就是一帧的耗时。蓝色CPU计算和红色GPU渲染并行处理时间如果在2次Vsync间隔时间也就是16.67毫秒内完成不了，那么这一帧就丢了，这种行为就像赶公交车，连续赶不上10趟公交车，那么总卡顿时长=16.67*10约为167ms，可能发生在中间就可能成为最大帧耗时，发生在最后就是最尾帧耗时。

性能卡口流程规约

参照云图发布流程 ，要求云图发布双周大版本实施性能卡口，卡口范围包含方案加载耗时、核心场景平均帧率/最长帧/最后帧&内存增长、包体积卡点，线下性能基线新老版本对比性能退化超5%卡住不予以发布。

测试owner在云图大版本迭代的前一周周三/周四/周五部署sit环境，当周周一/周二beta环境，进行性能自动化持续集成（定时任务不低于1小时/次，单日性能采样大于15次以上）。严重/大范围影响：方案加载耗时超20%；内存增长超10%（大范围表示核心场景超过50%及以上），不能走紧急报备，问题插件方排查修复后才能发布。局部/小范围影响:场景平均帧率/最大帧耗时/最大帧耗时超5%但小于10%局部场景、内存超5%局部场景，包体积：超5%短期不发修复，可走紧急发布邮件审批流程，限期整改修复上线。详见流程规约《 线下宽口径性能标准及卡口流程规约 》

性能卡口问题处理流程

三、性能体系优化方法&手段

性能监控度量分析体系

在整个性能保障体系中，性能度量及性能监控体系作为很重要的一环。通过监控发现问题，进行专项治理，结合性能标准等进行长效治理，做到性能长效保鲜防退化。同时结合线上/线下基线，结合业务关联特性，对监控体系的数据进行有效分析度量。

性能监控体系产品介绍

• tesseract数据小站：离线T+1数据，各个站点核心性能度量分析主要来自数据小站
• tetris：
• 监控告警数据：实时分钟级细分性能告警数据。
• 线下性能卡口性能基线看板，助力于线下性能卡口自动数据按照业务线维度展示。
• 用户行为分析（下钻）：给到技术团队，以及技术支持团队，进行线上单点性能问题排查，用户性能行为回朔提供很好的数据分析支撑。
• 性能月报综合度量分析：形成闭环，通过性能月报定义反馈线上性能大盘水位线，持续跟进线上问题情况，同时核心业务增设线下性能准出，对比性能基线，长效保险防退化。

监控完善关键事件

国内酷家乐工具前端前端监控告警建设-2023H1经过2023上半年的工具前端告警监控事项的推进，目前已覆盖国内酷家乐工具前端整体性能及云图工具、户型、定制、硬装、渲染、BIM施工图、水电等主要插件方。

• 工具性能整体及各插件告警监控范围确认
• 数据小站（离线T+1）迁移tetris实时告警库、告警监控需求完善落地
• 性能告警实时大盘：灰度gray实时告警监控大盘、灰度+人群实时告警大盘建设
• 工具性能整体和各插件方制定性能故障等级定义，和告警监控项形成一一映射&咬合

国内酷家乐线下性能卡口性能看板建设-2023H1 为支撑国内酷家乐工具前端在2023年1月启动云图大版本性能卡口事项，各业务插件方逐步完善核心场景性能检查项，通过tetris看板持续关注大版本发布前的线下性能表现情况

用户行为回朔-2023H1

• 【监控产品功能完善】tetris用户行为回溯，增加过滤PC崩溃率，客户端崩溃率的日志，方便排查线上用户崩溃情况；
• 基于tetris用户行为回溯，完成排查工具分析，产出文档&宣导并提供技术支持日常使用

美间性能优化性能看板建设-2023H1 为支撑美间工具及美间平台，美间工具性能攻坚项目：美间工具性能瓶颈和低性能优化、美间工具操作性能优化、美间工具加载性能（图片性能优化）、渲染耗时长的页面数据和分析、慢渲染；平台侧性能优化项目：客户端内核升级、客户端监控SDK对接、全站webp支持(美间主站、插件、企业版)

国际站性能一期-2022H2 国际化性能专项一期，结合国际站前端性能基线，完善国际站前端线上性能分析度量体系、前端性能监控SDK、基线告警（分国家）、静态资源网络性能等基础建设

大场景专题

大场景性能benchmark思路

酷家乐发展至今，其实大场景性能前面已经做了3期（ 2021年-工具大场景三期）了，架构为了适应业务快速增长不断垒叠本身已非常庞大负担不堪，本身所带来各种性能&用户体验问题，工具性能优化技术在当下已经进入性能深水区；那么随着我们的客户诉求提升，我们为了能支撑更大的面积，更复杂的模型，更流程的性能体验，于2022年底继续起航！

• 商业诉求聚焦商空办公行业：基于商空之前梳理的《 [2207]大场景需求描述 》逐个行业、案例分析讨论性能问题点，以及跟工具产品线的合作模式探讨。
• 工具性能各业务线大场景性能定义，阶段性找寻和商空办公行业商业诉求的match点，各业务线对齐大场景标准和定义后，针对商空办公行业，针对性提供几个典型方案，不同复杂度区间的方案，分别分析差距和缺口，时机合适立项优化。商空办公、全屋定制、云图工具平台启动P99大场景性能基线专项
• 震旦大场景性能优化项目：目前主要在支持震旦大场景的性能优化，具体见：《【震旦】性能&算量清单需求冲刺计划 》、《 施工图震旦项目仪表盘 》
• 性能极限探测：为了提升酷家乐设计工具的性能上限，目标支持一万平的设计方案，我们需要对云设计系统综合分析系统性问题对设计方案的性能极限探索所影响的点，并给出精细化的技术评估结论。《 云设计系统性能优化思路 》。第一轮：性能规模化问题分析：线上征集真实用户反馈的《 “崩溃/卡顿”问题跟进 》。第二轮：大场景（极限）复杂模型单一维度性能极限探测，不断地挑战技术能力上限。《 大场景性能极限探测 》

大场景性能自动化能力建设

大场景专题关键事项描述

线上P99大场景性能分析报告

大场景性能技术优化项

图片专题

图片性能标准

图片优化技术

对于图片性能优化，目前最有效且高ROI的主要是图片的压缩策略，目前酷家乐主要的CDN厂商腾讯云提供了几种标准的图片压缩策略，接下来主要讲一下webp图片转化技术

图片压缩指在图片质量保持不变的情况，尽可能地减小图片大小，以达到节省图片存储空间、减少图片访问流量、提升图片访问速度的效果。对象存储（Cloud Object Storage，COS）基于 数据万象（Cloud Infinite，CI） 产品推出了 WebP 压缩功能，可将图片转换为 webp 压缩图片格式，其在压缩方面相比 jpg 格式更优越。在相同图片质量的情况下，webp 格式图片要比 jpg 格式图片减小25%以上，可以适配多终端使用场景。那么webp图片转化策略，是通过支持将 jpg、png、bmp、gif、tpg、heif、avif 等格式图片转换为 webp 格式，从美间及酷家乐实测《 图片webp格式转化实测记录 》，对于png图片转webp压缩比在75%以上，jps图片转webp压测在25%以上。

图片优化效果

美间《 工具教程图片webp优化项目 》图片优化效果非常好，不仅是美间工具这边的教程图片，还是gif教程动图等，结果来看体积优化和耗时优化可以说都到了极限（比如之前图片性能优化webp75%，还实际提升了不少）

图片专题相关事项介绍图片问题跟进

图片监控完善

美间图片优化项目

酷家乐线下性能基建能力建设

性能自动化能力基础

从2023H1酷家乐国内工具开始对云图发布双周大版本实施线下性能卡口，为了能具备性能高度自动化持续集成能力，且覆盖核心业务线场景诸多性能指标项，在大版本发布前3天做到性能问题发现，有效拦截，定位并修复上线，给云图各业务插件提出非常高的要求和挑战。

应对挑战关键事项

提升业务线核心场景覆盖密度  覆盖密度从最开始不足20-30% ——> 95%性能自动化脚本能力提升 性能指标原理解读↑ && 编写技巧提升↑ && 性能公共方法API丰富↑性能自动化环境问题解决 工具半年累计持续集成 3万+ 次 && 发现问题 33+ && 不断总结积累↑

其他端到端性能优化技术介绍

前端性能优化总体策略：空间换时间，异步化，并行

如上图所示，从最开始容器初始化之后，把load JS、JS Parse&Run、请求发送之前都是串行的独立任务统一并行提前到初始化后，缩短整体端到端耗时，同时对页面dom节点数进行优化减小，同时对JS包体积进行瘦身也很关键，以及对JS包的提前预加载来缩减其downLoad耗时，这样提前自动更新，推送到用户本地侧，对页面性能加载优化提升起到了明显的效果。

SW缓存机制（Service worker）

Service Worker是运行在浏览器背后的一个脚本，可以使网页具备离线访问、推送通知和缓存数据等能力。其中，Service Worker的缓存机制是其重要功能之一。Service Worker缓存机制允许开发人员将资源（如HTML文件、CSS样式表、JavaScript脚本和图像等）存储在客户端，而无需每次请求都从服务器获取。这提供了更快的加载速度和离线访问功能。它有两重意义：1、JS资源在页面打开前就预先下载好，降低js下载时间；2、让JS到machine code的compile结果可以被缓存，从而降低js编译时间。

预加载（Prefatch）

在页面加载生命周期，把相关资源提前发起，同时利用浏览器的空闲时间进行异步任务，当前要保证几点：

• 不能阻塞主线程：即使开始prefetch的时刻浏览器是idle的，prefetch过程中涉及到的parse等计算，可能会占用比较长的CPU时间，在此过程中如果用户进行了交互，会感受到卡顿
• 不能占用太多内存：prefetch的数据和代码默认留在了内存中，如果占用内存过大，会增加程序整体OOM的崩溃风险
• 不能占用太多带宽：避免挤占带宽，导致其他正在使用的功能loading时间过长

懒加载（lazyLoad）

JS包体积瘦身

JS包体积，目前主要指云图yunDesign工具、BIM工具应用层代码包体积。其JS包代码体积大小和空方案/非方案加载有正相关性。在2022H2《 云图加载性能优化及包体积瘦身项目 》对于云图应用的代码体积包大小进行优化完成30%的瘦身。到2023年5月，云图和bim工具包体积持续下降创新低，云图包体积70多m接近80m左右，那会儿云图空方案12秒，最近云图总体积接近60m(瘦包26-28%左右)，空方案耗时8.5秒(28%)

项目优化成果保鲜持续防范挑战大，这是一个长期过程，还好从2023年开始云图发布大版本实施包体积大小性能卡口，从根本抑制了对云图&BIM工具整体及各插件微应用细分包大小随着不断的需求发布导致JS体积增长，效果非常明显

酷品秀端到端性能优化

• 前端
• SDK包下载耗时任务优化，->预加载
• 连接耗时优化（DNS查询+TCP+SSL）
• 页面渐进式加载体验优化：loading蒙层->页面骨架图秒开
• 后端：
• 参数化模型接口优化
• 架构设想→业务侧增加一层服务编排层

四、未来展望酷家乐是以分布式并行计算和多媒体数据挖掘为技术核心，推出的家居云设计平台，致力于云渲染、云设计、BIM、VR、AR、AI等技术的研发，实现“所见即所得”体验，5分钟生成装修方案，10秒生成效果图，一键生成VR方案，极大提升行业整体效率。作为“设计入口”，酷家乐致力于打造一个连接全球设计师、家居品牌商、装修公司以及业主的强生态平台，实现全人类的“所见即所得”体验。

正如酷家乐员工手册中映入眼帘的第一句话，我们在这条道路上始终坚信，并持之以恒......

重云端 利用云的CPU/GPU，将云端海量的运算及渲染能力发挥到极致，充分利用云端的资源，未来我们所有的产品设计理念及技术改造思路一定秉持这个理念继续前行。除了之前大量的篇幅介绍了前端性能之外，未来我们也会重点持续对应用集群的综合性能更清晰的去衡量和要求，作为稳定性&性能非常重要组成部分，整体的内存（频繁导致GC、OOM、内存异步化消峰）、方案大对象、长生命周期对象、是否支持分布式处理，计算维护：CPU飙高、请求维度：大量的请求出现流量尖峰（读写放大、负载不均衡、无线轮询、不合理不必要的请求）、任务积压、实例负载飙高等，配合长期的稳定性&性能专项保障及预案专项治理。

更大更复杂 未来，我们要实现1万平，甚至去探索10万平，支持更大更复杂的方案，更好的服务商业空间，商超，办公行业，室外建筑等大型生态行业客户。整体的架构为支持这个目标需要不断的迭代和革新，性能在此启动关键作用，作为评判用户交互体验的准绳。

国际化 驰骋在全球化的海洋中，做深做广，拥抱全人类。目标是宏远的，要做到此，未来还有很多事情需要去做，酷家乐当前的架构绝大部分还是以国内机房为主，升级改造衍生为国际化架构，解决跨国机房所有服务海外对等部署，全方位打造并逐步升级为跨国多机房标准模式，和海外云服务商共同合作，完善全球化网络拓扑节点，和国家POP边缘节点加速策略，以提升并有效适配海外不同国家和地区，努力打造访问酷家乐就如同访问本国本地机房的丝般顺滑的性能体感。

更智能 随着AI、AR等技术的飞度发展，酷家乐也会拥抱和全面迎接AI时代的到来。

～～未来所见即所得～～

酷家乐的UE中台项目，期望打造统一的酷家乐数据到UE（Unreal Engine，即虚幻引擎）的数据中台，已实现将酷家乐场景转换为UE场景，其中一个重要能力就是将场景内材质数据(vrscene)转换为UE材质格式。通过转换为UE材质后，该材质数据可以被UE引擎识别，用于具体的UE场景中。

由于项目前期UE材质转换算法存在大量效果问题，UE4中台将渲染效果的优化调整为项目当前阶段的核心目标。但另一方面项目前期的UE材质效果评估链路很长。从调整算法后部署材质服务，到确认渲染效果并输出报告，整个操作链路耗时可能长达半小时以上，非常影响算法同学工作效率。

架构设计

初版架构

为了解决UE材质效果验证的低效问题，我们在与相关人员对齐需求概要后，设计出了材质回归平台第一版的架构，涉及的相关服务方包括：

• 渲染回归平台：负责材质渲染测试数据、回归任务状态的管理
• 材质中台：酷家乐的材质处理中台，处理UE材质转换业务（UE材质转换算法就搭载于该服务中）
• 离线计算中台：酷家乐的离线计算业务中台，负责离线计算任务的调度工作
• 离线计算集群：由离线计算中台管理的服务器集群，负责执行定制化的离线计算任务，如图片渲染任务

材质回归平台整体架构设计：

1. 回归平台触发材质中台批量材质UE格式转换
2. 材质中台通知回归平台UE材质可用
3. 回归平台携带UE材质信息，向云计算平台提交一个UE材质渲染任务
4. 云计算中台将调度其下的计算集群，创建定制的windows容器下载指定UE材质并执行渲染，然后上传渲染图
5. 回归平台收到UE材质的渲染图，通过PSNR和SSIM算法，对比材质转换前后渲染图的差异，得出差异值；同时通过像素差异对比，输出图片差异可视化图像

方案调整

这套方案依赖的docker镜像是一个定制化的windows镜像，预期将包含UE渲染工具和一个渲染图上传工具。然而在前期容器构建调试过程中，我们遇到容器无法识别GPU硬件问题。

而UE渲染工具对GPU设备有强依赖。在一段时间探索确认win容器方案当下不可行之后，我们调整了系统架构设计。新架构的业务流程中，发生较大调整的是原先的云计算中台部分被替换为一台搭载GPU的真实windows物理机，调整架构之后整体的材质回归任务流程如下：

需求迭代

由于UE4中台项目工期非常紧迫，在材质回归平台的早期调试阶段，UE业务方就积极参与试用并提出了很多新需求.

材质转换本地化

回归平台加快了材质回归验收速度，UE算法工程师对转换算法迭代速度加快，这时他们迫切希望能将材质转换中台相关能力本地化部署，方便工程师直接修改算法并部署回归。由此我们对平台需求做出调整并开发新功能，落地了材质转换本地化需求：

1. 本地物理机部署材质转换服务
2. 回归服务支持发起本地的材质转换流程
3. 回归服务负责管理所有本地磁盘的材质缓存

稳定性需求

回归平台使用过程中频繁出现批量材质任务失败，经定位确认主要是以下两种情况导致：

1. UE材质转换服务本身存在概率失败（算法问题或网络抖动）
2. UE材质渲染图工具渲染失败
3. 网络抖动导致的回归任务运行失败

基于业务方的强烈需求，我们通过以下两个方向对平台后端逻辑进行了开发调整，并大幅提升了材质回归流程的稳定性。

UE材质转换任务检测

通过对比UE转换任务与材质渲染任务差异，判断是否出现了上述1类型的异常问题，并适时拉起本地材质转换服务再次运行UE转换逻辑。

渲染线程检测

回归任务状态管理逻辑调整，检测物理机上渲染中的任务数量与数据库中待处理渲染记录后，适时重启渲染任务，防止上述2、3类型的异常问题

其他需求

上面提到的两个需求之外，还有许多其他新增需求点：渲染多并发、动态渲染配置、材质转化提速、本地任务排队、独立基线等等，这里不再赘述了。

项目成果

材质回归平台实现了丰富的UE渲染回归功能选择，包括：

1. 选择回归物理节点
2. 指定材质所在环境
3. 数据转换类型分支
4. 自定义材质版本和引擎版本

UE回归任务结果数据展示：直观的基线对比与diff图，给出了通用的图像对比指标SSIM/PSNR，并且通过tag展示UE任务基本信息

截止12月12日已支持6批次测试集总计9000+的UE材质回归，发掘材质效果基础问题30+，回归效率相比原流程提升90%以上

阅读前你可能需要了解这些：

• 了解 TCP/IP、OSI 模型
• 了解 HTTP 协议
• 了解 Node.js

从几个问题入手：

• 服务间调用的长连接如何设置
• 服务器上 TCP 连接数限制
• 服务器上 TCP 连接数对业务的影响

服务间的长连接

假设我们的目标服务，存在服务的消费者和提供者，服务之间存在上下游依赖关系：

我们期望服务间的连接是长连接，即 TCP 连接只建立一次，无需每次请求调用都发起 3 次握手、4 次挥手，以提升网络 IO 吞吐量。但是事实跟期望可能有所出入。

假设微服务间通信使用的应用层协议是 HTTP 1.1，单个 TCP 连接同时只能发出单个 HTTP 请求。即当同一时间请求并发数为 n ，会存在 n 个 TCP 连接，并且会存在 3 * n + 4 * n 次握手挥手动作，甚至可能会触发 sockets 连接数用满。

长连接示例

我们通过一个示例，感受并发调用场景下，TCP 建连的过程。

以下为代码启动一个 HTTP server 作为上图中的 Provider Service：

• 建立 TCP 连接时，打印 new connection 日志
• 收到 HTTP 请求时，返回 ok 作为 response body，并打印 request 日志

const http = require('http');

var server = http.createServer(function (req, res) {
  res.end('ok');
  console.log('request');
});

server.on('connection', function (socket) {
  console.log('new connection');
});

server.listen(3000);

以下代码为客户端代码作为 Target Server（由于我们想要测试长连接，双方交互的服务一定是长期存活的，所以这里我们启动一个服务，而不是直接写个 client.js 做测试）：

• 服务端口监听在 3001
• 当收到 /batch 请求时，并发调用 Provider Service 10 次

const http = require('http');

var server = http.createServer(async function (req, res) {
  if (req.url === '/batch') {
    await Promise.all(Array(10).fill(1).map(request));
  }
  res.end('ok');
});

server.listen(3001);

async function request() {
  return new Promise((resolve) => {
    http
      .request('http://127.0.0.1:3000', (res) => {
        res.on('data', resolve);
      })
      .end();
  });
}

以 curl 作为客户端（或者作为 Consumer Service）

$ curl http://127.0.0.1:3001/batch

Provider Service 输出如下日志：

整理下完整的调用链为：curl -> Target Service -> Provider Service。

可见 10 次 HTTP 并发调用产生了 10 次 TCP 连接，符合预期，因为 HTTP 1.1 并发调用一定会产生相对应数量的 TCP 连接。

再次 curl ，Target Service 与 Provider Service 之间继续新建 10 条 TCP 连接，原因也很简单，之前的 TCP 连接都是用完即销毁的。

假设我们想要第二次并发的 10 次请求，继续复用之前的 10 个 TCP 连接就需要做如下处理，代码变更如下：

连续手动操作进行 3 次 curl 调用：

对输出做一下分析：

• 首次 curl 调用，建立 10 次 TCP 连接，符合预期
• 二次 curl 调用，复用原有的 TCP 连接，符合预期
• 三次 curl 调用，又建连了 10 次 TCP 连接，不符合预期

大家可能对第三次调用结果比较疑惑，这里直接放下结论：因为 TCP 连接只存活 5s ，超时后，自动断连了。

Wireshark 网络分析

为了对如上的调用做解释，我们需要一个工具去查看 TCP、HTTP 的完整过程，这里我们用到一个工具： Wireshark。

Wireshark 是一个强大的网络分析工具，它工作于 OSI 网络模型的 Data Link Layer 层，即数据链路层，所以可以分析 Data Link Layer以上的所有层数据，包括本次分析的 TCP、HTTP 过程。

Wireshark 相对于一些其他常用的网络分析工具，例如 Fiddler、Charles、Whistle 等工具，其有如下优势：

• 实现机制更底层，所以能捕获 Data Link Layer上层的数据，而其他代理工具只能看应用层数据，顶多再看个传输层数据
• 由于更底层，所以无需配置应用的代理配置（部分应用可能不走默认系统代理，需要手动配置，例如你启动的 Node.js 服务）

话不多数，关于 Wireshark 的使用，有兴趣直接看官网文档吧： https://www.wireshark.org/docs/wsug_html_chunked/

对单条请求做分析

为了减少干扰，我们仅发出一条请求 Target Server -> Provider Service。

关于图例说明下：

• 绿底的输入框，由于网卡比较活跃，减少干扰过滤出 Provider Service 3000 端口号的网络交互
• 图中我们可以很直观的看到熟悉的三次握手、HTTP 请求、四次挥手
• Keep Alive Check：我们还发现每隔 1s Target Service 于 Provider Service 都会进行一次双向交互，这是为了：

• 检查死连接，及时断连
• 防止长时间无网络交互，导致断连
• 具体参考：https://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html

对图例的细节进行分析：

• 存在四次挥手，而且是在大概 5s 后，这个我们从 HTTP response 中得到验证

对 curl 三次结果做分析

从上述单个请求分析中，我们基本可以论证 curl手动触发第三次不符合预期的原因，重复说明一下原因：因为 TCP 连接只存在 5s ，超时后，自动断连了。

我们再次重复 3 次手动 curl：

1. 触发第一次
2. 1s 后触发第二次
3. 8s 后触发第三次（此时之前的 TCP 长连接已断连，需要重新连接）

具体操作如下，到这一步已经非常清晰了：

如何操作长连接

回到问题，这里列一些解法：

如何配置长连接，以及超时时长

• 对于客户端，上述 Demo 已经很明确了，Node.js 上直接设置 http agent 即可。
• 对于服务端，可以调整 keepalive timeout 增长 TCP 连接的时长，可以设置 Server.keepAliveTimeout属性，但是也要注意其可能频繁 TCP Keep-Alive Check，需要做好取舍，多次测试找到合适的阈值

Demo 里 10 次批量的请求，在 TCP 连接还没销毁前，二次并发调用时会重用，那么这个最大重用限制多少？

与客户端配置 Agent.maxFreeSockets相关：

• 默认 256，即连接池的最大默认空闲容量，当下次请求来时会优先复用
• 当超过时，客户端在 http 结束时会立即发起断连

并发数过大时，TCP 连接数会建很多么，是否有限制？

与客户端配置 Agent.maxSockets和 Agent.maxTotalSockets相关：

• 前者限制单 host、后者针对所有 host
• Agent.maxSockets Node 0.12 以上就是不限制了
• 设置此值的效果为：超出的数量的 HTTP 请求不会发出，直到 TCP 空闲

• 例如设置为 1，则所有请求都会是串行的效果，TCP 连接也仅仅存在一个
• 具体示例如下图，No.23 为第二个请求，在 No.19 第一个请求完全结束后才发出

TCP 连接数限制

通过 {Source IP, Source Port, Destination IP, Destination Port} 四元组确定唯一的 TCP 连接。

对于服务提供方：只需要一个暴露一个端口给客户端，即可接收无限数量的 TCP 连接，在不考虑内存的前提下，客户端的 IP, Port 只要不同即可。

对于客户端：连接数量限制在 2^16 - 1 内，即 65535 个端口，去掉 0 这个特殊端口。

客户端存在限制的核心原因：TCP 规范的要求。

• 端口号只能是 16 bits 内，如果超出可能会导致对方服务无法解析或解析错误

• 以上为 Wireshark 的示例，整个 TCP header 都是固定顺序与固定格式的

作为客户端 65535 个数量是否够用

个人电脑当然够用的，假设每个程序 100 个 TCP 连接，同时运行 100 个程序，也才 10000 个罢了。

微服务中的一台服务：也是够用的

• 假设你的服务都是短连接，每次客户端请求过来都要转发给相对应数量的上游其他服务，并且假设每个请求你都需要处理 5s
• 那么 5s 你能接受的最大单机请求数是 6w+ 个，基本单个服务是达不到这个数量的。除非你接收一个请求，分散出 10+ 的请求。况且存在这么高的并发时，内存和 CPU 可能更先刚不住，而不需要先担心 TCP 的数量是否够用

HTTP 1.1 与 2

相比之下，HTTP 2 带来了如下特性：

• 二进制，而不是文本
• 完全多路复用，而不是有序和阻塞，故可以使用一个连接进行并行
• 使用 Header 压缩来减少开销
• 允许服务器主动将响应“推送”到客户端缓存中

具体参考：https://http2.github.io/faq/

那么，我们是不是可以把服务间的通信协议升级到 HTTP 2 来解决并发流量导致的重复 TCP 建连开销？

立即开干，以下是 Provider Server：

const http2 = require('http2');
const fs = require('fs');

const server = http2.createSecureServer(
  {
    key: fs.readFileSync('localhost-privkey.pem'),
    cert: fs.readFileSync('localhost-cert.pem'),
  },
  function (req, res) {
    res.end('ok');
    console.log('request');
  },
);

server.on('connection', function (socket) {
  console.log('new connection');
});

server.listen(3000);

我们创建了一个基于 TLS 的 HTTP 2，说明下为啥不使用 HTTP2 over TCP（即不加密的 HTTP 2）：

• 浏览器等客户端无法识别
• Wireshark 无法识别（重点，不方便看明细）

以下是 Target Server。

const http2 = require('http2');
const http = require('http');

var server = http.createServer(async function (req, res) {
  if (req.url === '/batch') {
    await Promise.all(Array(10).fill(1).map(request));
  }
  res.end('ok');
});

server.listen(3001);

const client = http2.connect('https://localhost:3000');
async function request() {
  return new Promise((resolve) => {
    const req = client.request({ ':path': '/', ':method': 'GET' });
    req.on('data', () => {});
    req.on('end', resolve);
    req.end();
  });
}

curl http://localhost:3001/batch -v 进行测试结果：

• TCP 连接只在 Target Server 启动时即建连，且不主动销毁
• 批量 10 次请求，复用现有单个 TCP 连接，结果符合预期

注意事项

如果你想要按照上面的示例进行测试，有一些 TLS 带来的调试问题注意事项：

• Provider Server：需要自行生成证书，参考：https://nodejs.org/api/http2.html#server-side-example
• Provider Server：增加 Node.js 启动参数 node --tls-keylog=/somewhere/ssllogfile.txt provider-server.js，用于 Wireshark
• Target Server：增加环境变量 NODE_TLS_REJECT_UNAUTHORIZED=0 node target-server.js解决自建证书的安全问题
• Wireshark：配置日志文件，用于解析 TLS 层数据包

总结

文章主要探讨了 TCP 长连接的相关知识。首先通过示例解释了长连接的基本原理和流程，包括 TCP 连接、HTTP 请求、Keep Alive 检查等。然后分析了在手动 curl 触发第三次请求时的问题，说明了因为 TCP 连接只存在5秒，超时后会自动断连。

接着，给出了如何配置长连接的解决方案，包括客户端和服务端的设置，以及超时时长的调整。同时还讲解了一些与客户端配置相关的参数，如 Agent.maxFreeSockets、Agent.maxSockets 和 Agent.maxTotalSockets 等，并解释了 TCP 连接数的限制和客户端存在限制的原因。

最后，我们探讨了 HTTP 2 对于微服务架构的可用性，我认为是可以实践的，不过要去掉 TLS ，走 HTTP2 over TCP。

完，希望对大家有所帮助。

参考

• https://zh.wikipedia.org/wiki/OSI模型
• https://www.wireshark.org/docs/wsug_html_chunked/
• https://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html
• https://www.geeksforgeeks.org/layers-of-osi-model/
• https://www.youtube.com/watch?v=o-EkdZW4zbA
• https://en.wikipedia.org/wiki/Transmission_Control_Protocol
• https://wiki.wireshark.org/TLS
• https://gist.github.com/dfrankland/0fec2cd565f1f7b78fb0e3ededf36b89
• https://http2.github.io/faq/
• https://nodejs.org/api/http2.html#server-side-example

小程序是一种全新的连接用户与服务的方式，它可以在微信内被便捷地获取和传播，同时具有出色的使用体验。

现在公司有许多产品通过小程序来进行使用与分享，了解微信小程序的测试常识变得必不可少

概述

本文主要介绍一下小程序测试的基础知识,自动化测试相关的实践

1.基础部分包含:小程序测试环境搭建、小程序测试基础、测试注意点

2.自动化测试使用在pytest中以插件的方式封装官方提供的MiniTest库

小程序测试环境搭建

微信开发者工具

在进行小程序测试的时候,有时候会有如下的一些需求

1. 查看小程序在不同机型上的展示
2. 查看接口请求与响应
3. 开发修改后快速验证
4. 查看js的报错
5. 分析代码质量\性能情况\主包大小...
6. ...

这时候可以使用「微信开发者工具」

1. 前往官网进行下载IDE
2. 联系小程序负责人申请小程序的开发者权限
3. 打包小程序
4. 使用微信开发者工具打开小程序打包产物

小程序测试基础知识

渲染层和逻辑层

小程序的渲染层和逻辑层分别由2个线程管理：

• 渲染层的界面使用了WebView 进行渲染；
• 逻辑层采用 JsCore 线程运行 JS 脚本。

一个小程序存在多个界面，所以渲染层存在多个 WebView 线程

这两个线程的通信会经由微信客户端（ Native ）做中转，逻辑层发送网络请求也经由 Native 转发。

小程序不同版本

不同版本的入口

• 开发版:使用「微信开发者工具」预览,二维码有效期30分钟

体验版:酷家乐小程序平台-对应的小程序-版本管理,二维码固定不变,永久有效

正式版:微信中直接搜索

在使用开发版或者体验版进行测试的时候需要开启调试模式

如果不开启调试会出现

1.无法访问没在小程序后台配置的域名    会提示表现为「获取失败,请检查网络链接」

2.无法查看调试信息

公司内部平台上可以进行环境切换

修改env变量切换线上或线下等环境

启动机制

为了保证⼩程序的快速访问和⽤户体验，微信会缓存整个⼩程序，包括⼩程序⽂件、授权数据、登录数据等等。因此⽤⼩程序常碰到缓存问题，例如切换环境（线上线下互切）、发布、登陆等有时候会发⽣数据切换不过来的场景，为了避免⼀些不必要的缓存问题，简单粗暴的⽅法就是，将⼩程序删掉重新进⼊。

• 冷启动:用户首次打开，或小程序销毁后被用户再次打开，此时小程序需要重新加载启动，即冷启动。
• 热启动:用户已经打开过某小程序，然后在一定时间内再次打开该小程序，此时小程序并未被销毁，只是从后台状态进入前台状态，这个过程就是热启动。

访问外部网页限制和公众号文章限制

很多小程序中会内嵌H5页面

在非正式版的时候可以选择「不校验合法域名、web-view(业务域名）、TLS 版本以及 HTTPS 证书」来进行测试,但是到了正式版本后需要将外部链接加入到白名单

小程序内关联的文章也是有限制，必须是当前小程序关联的公众号

程序包限制

目前小程序分包大小有以下限制：

• 整个小程序所有分包大小不超过 20M；
• 单个分包/主包大小不能超过 2M。

开发者工具中如何查看分包大小

性能数据

在「微信开发者工具」中的调试器中的「Show console drawer」中点击「Task」即可看到实时的性能数据了

Mock数据

有一个获取客户列表的接口:https://beta.kujiale.com/kuaida/intelligent/match/customer/pagelist

现在需要修改它的返回值

准备数据

数据格式为:

{
"data": "",
"statusCode": "",
"header": ""
}

这次mock后让它就返回一个客户的信息

{"c":"0","m":"","d":{"pageIndex":1,"pageSize":20,"rowTotal":1,"pageTotal":1,"data":[{"obsCustomerId":"3FO4K4VYBUKQ","customerName":"听白","customerPhone":"","designNames":null}]},"f":null}

合并一下

{
"data": {"c":"0","m":"","d":{"pageIndex":1,"pageSize":20,"rowTotal":1,"pageTotal":1,"data":[{"obsCustomerId":"3FO4K4VYBUKQ","customerName":"听白","customerPhone":"","designNames":null}]},"f":null},
"statusCode": 200,
"header": ""
}

匹配接口

使用正则的方式匹配的接口为https:\/\/beta.kujiale.com\/kuaida\/intelligent\/match\/customer\/pagelist

测试

刷新一下页面进行测试,查看是否mock成功

修改一下响应的内容

{
"obsCustomerId": "3FO4K4VYBUKQ",
"customerName": "听白1111111111111111111111111111111111111",
"customerPhone": "123",
"designNames": null
}

查看效果

测试注意点

免登录场景

分享出去的⻚⾯，这个链接⼀般是免登录的，需要使⽤完全没有登录过的⼿机或者清理干净缓存再去验证

右上角操作

右上⻆开放出了哪些功能，我们都需要验证⼀边，确保正常。

特别是浮窗切换，前台后台切换的时候，容易出现⻚⾯错乱或者⽩屏的现象

支付功能

• 微信支付
• 二维码支付
• 第三方支付

需要测试各个支付方式都能正常唤起并支付

缓存

⼩程序为了快速流畅的⽤户体验缓存了整个⼩程序，⼏乎每个⻚⾯都会存在⼤量的缓存.

我们需要明确哪些我们需要缓存，哪些⽆需缓存，注意⻚⾯切换或者账号切换时数据的正确性。

入口有效性

• 可以通过「发现」模块下的「⼩程序」中的搜索框搜索到对应的⼩程序；
• 可以通过「附近的⼩程序」找到⼩程序；
• 已打开过的⼩程序，还可以通过微信聊天⻚⾯的下拉框找到⼩程序；
• 分享链接可正常打开⼩程序；
• ⼩程序码扫描可正常打开⼩程序；
• 删除⼩程序后重新发现正常可正常进⼊。

兼容性

操作系统兼容性

不同运行环境下，脚本执行环境以及用于组件渲染的环境是不同的，性能表现也存在差异：

• 在 iOS、iPadOS 和 Mac OS 上，小程序逻辑层的 JavaScript 代码运行在 JavaScriptCore 中，视图层是由 WKWebView 来渲染的，环境有 iOS 14、iPad OS 14、Mac OS 11.4 等；
• 在 Android 上，小程序逻辑层的 JavaScript 代码运行在 V8 中，视图层是由基于 Mobile Chromium 内核的微信自研 XWeb 引擎来渲染的；
• 在 Windows 上，小程序逻辑层 JavaScript 和视图层都是用 Chromium 内核；
• 在 开发工具上，小程序逻辑层的 JavaScript 代码是运行在 NW.js 中，视图层是由 Chromium Webview 来渲染的。

JavaScriptCore 无法开启 JIT 编译 (Just-In-Time Compiler)，同等条件下的运行性能要明显低于其他平台。

机型兼容性

主要是屏幕的适配

微信小程序定义了一个新的尺寸单位 rpx(responsive pixel) 可以适配不同尺寸的屏幕，在页面上定义对象的单位是 rpx 就可以在不同的屏幕上适配。

部分机型会出现边框缺失:小程序1rpx边框不完美解决方案

微信版本兼容性

基础库

为了避免新版本的基础库给线上小程序带来未知的影响，微信客户端都是携带 上一个稳定版 的基础库发布的。

小程序的能力需要微信客户端来支撑，每一个基础库都只能在对应的客户端版本上运行，高版本的基础库无法兼容低版本的微信客户端。

有条件可以切换多个版本的微信来进行测试

交叉事件

• 与微信的交叉事件:微信视频,语言通话等打断小程序操作
• 与手机的交叉事件:手机电话,闹钟,文件接收等打断小程序操作

小程序不会阻止交叉事件的发生(不会打不进电话等)

查看小程序会不会出现中断,白屏,卡死,闪退等问题

网络

1. 测试3G、4G、5G、wifi 网络下应用运行的速度。
2. 网络不好时，提交数据是否一直处理提交中，是否会有延迟，数据交换失败是否会有提醒。
3. 有网到无网再到有网环境时，数据是否可以自动恢复，能正常加载。

自动化测试

pytest-mini

https://pypi.org/project/pytest-mini/

该项目基于MiniTest进行pytest改造

在保留原有特性的情况下,可以使用pytest来进行代码编写,提高编写效率

安装

pip install pytest-mini --upgrade

项目结构

页面元素:components_page.py

from pytest_mini import Mini, Locator

class ComponentsPage(Mini):
view_container = Locator('view', inner_text='视图容器', desc='组件页-视图容器')

前置条件:conftest.py

import pytest

from pytest_mini import plugins
from demo.pages import ComponentsPage

pytest_plugins = plugins(
"/Users/zhongxin/github/miniprogram-demo", # 待测试的小程序项目路径
"/Applications/wechatwebdevtools.app/Contents/MacOS/cli" # 微信开发者工具路径
)

@pytest.fixture(scope="session")
def components_page(mini):
yield ComponentsPage(driver=mini.driver)

测试代码:test_home.py

import allure

from pytest_mini import compose

@compose(feature="小程序官方组件展示", story="组件", title='容器视图操作')
def test_view_container(components_page):
with allure.step("点击容器视图"):
components_page.click(components_page.view_container)
assert False, "故意失败,查看报告截图"

demo测试结果

真实项目测试结果

查看网络请求信息

相关文档

微信官方文档-小程序

​

疫情至今，TesterHome社区已经有3年多没有举办线下沙龙了，目下花开正艳，TesterHome也将陆续恢复线下沙龙活动~

本次由酷家乐与TesterHome社区联合主办的【流量回放】主题技术沙龙，邀约大家共探：流量回放在质量保障中的技术实践。

鲜衣怒马少年时，不负韶华行且知。期待和各位对流量回放感兴趣的朋友们一起相约6月，共品一场质量保障的技术盛宴！

酷家乐简介

酷家乐是一家面向未来的大家居全案设计平台及生态解决方案提供商，致力于为数字化升级提供一站式的解决方案。平台以设计为入口，链接大家居行业生态，为家居企业提供设计、营销、生产、管理、供应链等场景的解决方案和服务，助力全行业实现 “所见即所得” 的愿景。

沙龙安排

日程安排：2023年6月3日下午

活动地点：杭州市拱墅区余杭塘路515号矩阵国际中心2号楼13楼  酷家乐

议题及讲师介绍

议题一：流量回放在酷家乐的实践

讲师介绍：

方胜军（花名：罗曼），测试开发专家，先后就职于新浪、51信用卡、酷家乐等公司，现为酷家乐大用户平台测试负责人，酷家乐流量回放平台负责人。

议题介绍：

流量回放是提升回归效率和质量的一种有效手段。酷家乐在实践流量回放能力的过程中，经历了基于 goreplay+diffy 的 kudiffy 平台到基于 jvm-sandbox-repeater 的 kurepeater 平台。

那这两种技术在流量回放方面各有什么优缺点？

它们的实现原理有什么区别？

基于 jvm-sandbox-repeater 的流量回放平台如何搭建？

常见的坑和解决之道有哪些？

平台的流量除了用于回放还有哪些较好的使用场景实践？

这些都将在这个议题中一一介绍。

议题二：得物流量录制回放落地实践

讲师介绍：

周官宝，资深后端开发工程师，先后在美团、喜马拉雅从事后端研发工作，目前在得物从事后端开发工作，主要负责流量回放。

议题简介：

1.流量录制回放如何在得物落地及最佳实践

2.演进过程中遇到的难题

3.沙箱挂载、录制等的稳定性

议题大纲：

1.平台成果

2.预发布 mock 回放

3.线下 mock 回放

4.稳定性

5.展望

议题三：移动端录制回放实践

讲师介绍：

李嘉华，阿里云EMAS技术专家，拥有长期的自动化测试工具研发、实施经验。

议题简介：

EMAS 移动测试为移动应用提供一站式的兼容、功能、性能测试平台。

这里主要介绍面对各种的应用，如何设计与实现录制回放工具，如各种回放步骤的实现；

如何提高回放的成功率与稳定性，如提升 wda 的稳定性与兼容性问题；

以及在生产过程中遇到的一些困难与解决方案。

报名方式

进入百格进行报名：https://www.bagevent.com/event/8353186

活动说明

1.报名沙龙收取的费用，将用于线下沙龙的茶点等。

2.报名后，会创建微信群邀请参会同学，若有更新消息也会通过群通知大家。

3.参加沙龙同学有机会获得由TesterHome社区提供的MTSC2023上海站大会门票、咖啡杯、T恤。