“二方包升级难!”
“XXX升级后,项目起不来了!”
“这次就升级了XXX,外网运行就报错了!”
应用编译过程就报错
中间件依赖的二方包和业务依赖二方包的版本冲突,这个被依赖的二方包本身是不兼容升级,比较容易出现这个问题
中间件二方包升级的版本不一致,比如有些功能需要hunter和soa配合升级
中间件二方包的不兼容升级
应用运行后报错
运行期的二方包问题,这种问题会比较难以发现,问题表现为各种FoundError&Exception
多个版本存在时,采用最短路径原则和优先声明原则,如果两个依赖版本在依赖树里的深度是一样的时候,第一个被声明的依赖将会被使用
直接的指定手动创建的某个版本被使用
依赖树可以直接通过mvn dependency:tree命令或者更方便的pom dependency analyzer查看
2.完成类的选择,类是如何加载的呢?
class字节码通过ClassLoader被转换成内存中的对象,这个转换过程采用按需加载的原则,即用到该类才加载
JVM运行实例会存在多个ClassLoader,这些ClassLoader是如何加载类的呢?
JVM内置3个重要的ClassLoader
BootstrapClassLoader
ExtensionClassLoader
AppClassLoader
ClassLoader加载类遵循双亲委派模型
所以,二方包升级过程碰到的ClassNotFoundException、NoClassDefFoundError、NoSuchMethodError、ClassCastException、LinkageError问题都可以解释了,加载了非预期的二方包导致的各种冲突和异常
我们已经了解了二方包在升级过程中存在的问题,那么有什么方法来降低升级的成本,提前测试二方包的兼容性呢
运行前
白盒静态检查
采用了基于javassist的开源工具japicmp,静态检查本次升级的二方包的改动,包括new+modify+delete的class、method、constructors
将静态检查过程已经通过moon融入到测试流程中,帮助测试识别潜在的风险
版本依赖检查
maven的依赖树非常好用,确认升级的各个中间件版本一致
运行期
前面提到,有些兼容性问题只有运行期才会发现,暂时没有一劳永逸的方法,提高接口测试的覆盖度,通过接口测试来触达可能的潜在问题
上面提到的测试手段,本质并不能解决中间件二方包和业务二方包冲突的问题,因此中间件团队已经在调研实现类隔离的方法,从本质上解决这个问题
方法
原理清楚了,需要做的是把对应的二方包数据整合
准备三件套
将二方包测试覆盖率已经通过moon融入到测试流程中
理想是丰满的,现实然并卯,运营运营
会有同学疑问,二方包是怎么做性能测试的,二方包性能测试的关注点在哪里?这个问题可以从一个P0故障开始说起...
首先需要说明,中间件的二方包使用是基于应用的,所以性能测试也是基于应用的。目前在做的二方包的性能测试主要是soa和hunter,测试应用是网关site & 被测应用soatest
测试路径
测试指标
重点需要关注内存,进程内存和机器内存的使用情况,内存使用逻辑非常复杂。如果在测试发现问题,需要根据问题具体分析,这里说的是二方包性能测试,就需要关注有没有因为二方包引起类似这个故障的内存泄露问题
性能基线
由于基础设施的问题,像网关这样大并发的性能基线暂时不能自动化,手工测试的过程也比较复杂,好在网关也不是隔山差五的升级版本
应用的中间件性能测试是可以做到的,因此专门建立了一个二方包测试repo用于各种中间件的测试,融入发布流程
演练目标
测试rds集群/es集群/redis集群发生不可抗拒故障时和故障恢复后,tddl/es client/rops中间件层面行为是否可靠
测试rds集群/es集群/redis集群故障恢复后,应用的自动恢复情况
针对rds集群/es集群/redis集群不可抗拒故障,产出对应BP,帮助用户缩短定位问题的时间,提高解决问题的能力
测试rds集群/es集群/redis集群发生不可抗拒故障时和故障恢复后,tddl/es client/rops中间件层面告警详情
业务同学实际故障演练时,可以review对应的测试结果,参考故障发生时的解决方案(重要,重要,重要!)