平台迁移那些事 | 企业级消息系统测试之道

原创金涛 eBay技术荟

供稿 | eBay CCOE EEE Team

作者 | 金涛

编辑 | 顾欣怡

本文3629字，预计阅读时间12分钟

更多干货请关注“eBay技术荟”公众号

导读

“平台迁移那些事”是eBay EEE (Engineering Ecosystem and Experience) 团队最新推出的系列文章，从V3平台的陈旧应用无缝转移到eBay最新的Raptor.io平台，该项目涉及eBay百亿级流量的迁转，并要求在整个迁移过程中不影响任何实时服务，对eBay用户保持透明。本文将介绍迁移团队如何利用利用引流回放机制的自动化测试平台，成功完成多个消息系统的迁移。

一、给飞行中的飞机换引擎

随着eBay上一代的平台(V3)逐渐退出历史舞台，基于老平台开发的各种应用就必须要迁移到新的平台(Raptor)之上，这其中就包括了消息系统应用的迁移。要在一定的时限内，高质量地把应用从一个平台迁移到另一个平台本身就难度不小，而相比与其他类型的应用，消息系统的特殊性更是加大了迁移的难度。如何保证迁移的质量，如何提供完备的测试方案是迁移团队重点要攻克的难题。

从技术上看，消息系统迁移有如下测试难点:

业务逻辑不清，测试用例不足。
许多应用因为年代久远，中间又几经转手，基本都没有测试用例了。再加上大部分团队都不是很清楚老应用的业务逻辑，需要大量的时间来读代码，制定实际测试方案，从而进行测试。
数据流向不固定，消费对象难定位。
理论上，新老平台上的消费者都能并行地消费消息，很难保证特定的消息被特定的消费者消费，也就没办法比较消息被新老平台处理后的结果了。
数据流动非同步，跟踪测试不直观。
消息系统是一个异步系统，这就大大增加了追踪测试数据、衡量测试结果的难度。

根据以上难点，迁移团队认为理想的测试方案应该具备以下特性：

可控制
消息的流向是可以完全被控制的，这个目标主要是解决测试中消息跟踪难的问题。
自动化
要迁移的应用众多，每个应用中消费的消息类型种类繁多，要通过自动化的测试来覆盖所有的消息类型。这个目标要解决效率和测试用例覆盖率的问题，要在没有人为干预的情况下高效、高覆盖地完成测试。
可衡量
无论是对于功能完整性，还是对于非功能的性能、JVM 内存使用、GC Overhead 等性能指标，要有办法进行比较，原则上迁移应用应该不输甚至更胜过老的应用。这个目标就是要解决测试质量的问题。这些可比较可衡量的指标，不仅要让拆迁团队对于交付的质量有信心，同时也会使得用户对于接下来的验证工作有信心。

从上述目标来看，消息系统的迁移就像是给飞行中的飞机换引擎，时间紧，任务重。要在用户无感知的情况下，高效又平滑地完成对消息系统应用的迁移，这看上去就是个不可能完成的任务。迁移团队却选择迎难而上，挑战这个不可能。

下文将详细介绍迁移团队是如何抽丝剥茧，把这个不可能任务分而治之的。

二、见招拆招

如何构建测试用例

对一个承载多个消息系统应用迁移重任的团队来说，我们不了解用户的业务逻辑，也没有办法从头去梳理所有的老系统的大部分无效的测试用例。如何构建出可靠稳定并且能够覆盖各种边界情况的测试用例是当务之急。

引流测试 -- 以彼之道还施彼身

在多轮头脑风暴之后，引流测试这几个字就像是一道闪电，划破重重迷雾，照亮了迁移之路。

如果能将老的系统消费的消息引流到新的系统中，然后比较两边消费消息的结果，不就是一种低成本高覆盖的无需深度了解内部逻辑的测试之道吗？这就类似武侠小说中常出现的招数， “以彼之道还施彼身”或者“借力打力”，借线上流量之力，引流回放，比较新旧系统的处理结果，从而达到测试迁移后新应用的目的。同时利用大规模的线上消息做回放也能完成新应用的性能测试，简直是一举两得。

主意有了，接下来就看怎么实现了，我们的目标是要搭建一个自动化测试平台，能够高效地帮助我们解决迁移中的测试问题，为整个迁移保驾护航。

eBay内部的消息系统(BES)是借助数据库作为消息的载体的，大体结构如下图所示，消息发布者不断地将消息发送到数据库中，消费者去查询数据库，拿到消息并消费。

图1（点击可查看大图）

既然这样就可以直接从数据库中获取线上消费的消息，直接复制一份引流到新平台上的应用即可。通过这样的分析，测试数据将不再成为问题，我们的测试目标也就可以一一实现。

如何控制消息流向

解决了数据来源后，我们又发现了另一个问题: 因为新老平台上的消费者都是等价的，对消费者来说，只要数据库里有新消息，就拿来消费，很可能出现我们为新应用准备的引流消息被老应用夺走消费了，这就无法达到我们比较消费结果的目的了。如何使得引流的消息定向地被指定的消费者消费是引流回放机制必须要解决的问题。

一个完善的消息系统平台应该提供消息隔离的机制，具体来说就是特定的消息可以定向地被指定的消费者消费，BES就提供了类似的功能，称之为消息亲和(Affinity)。所谓消息亲和即在消息和消费者上都做相应的配置，类似打上相同的标签，使得消费者只会识别消费具有相同标签的消息。利用亲和机制，引流回放的策略就应该是从消息数据库中获取消息并且复制一份，为两份消息打上不同的标签，对新旧平台之上的消费者也打上相应的标签。这样具有相同标签的消息就会被分别引流到新旧平台上消费，再通过比较两个平台上的消费结果是否一致(对照测试），来确保迁移后的消息系统能够保持和之前一样的行为。

如何衡量测试结果

当引流的消息被消费后，就需要追踪测试结果，并且进行多维度的结果比较，包括：

比较消息的处理状态。
如果消息被两边平台处理后的状态都是成功，那从某种角度来说新老应用的行为没有因为迁移而发生变化。
比较日志系统中生成的日志。
如果在新的平台上产生了异常信息，而在老平台上没有相应的异常，那就说明迁移中应用行为发生了改变，需要花时间去解决。
比较消息处理的时间以及系统的性能参数。
对于消息处理的SLA的比较，以及消费者机器的CPU，Memory，GC overhead等性能的比较，能够确保迁移后的应用没有任何性能上的问题。

基于以上的见招拆招，我们的拆迁团队在即使不深度了解应用的内部逻辑的前提下，也能保证完成高质量的迁移。

三、解决方案

自动化的测试平台

迁移团队基于引流回放的测试方法，利用消息亲和机制，实现了一套完整的消息系统的对照测试平台(BES Mirror)，有助于高效地保证平台迁移的质量。具体的结构如下图所示。

图2（点击可查看大图）

BES Mirror 会从老平台 (V3) 和新平台 (Raptor) 上分别选取一个消费者，用来做对照测试，在两个消费者上做相应的消息亲和配置。
BES Mirror从消息数据库中选取一定的消息，复制一份并且加上与消费者一致的亲和配置，重新写入数据库并等待消费者来消费消息。
两个消费者根据亲和配置，分别消费属于自己的消息，并且记录结果。
BES Mirror从各个渠道(记录消息处理结果的数据库，日志中心）获取并聚合不同平台上消费者的处理结果，做多维度的比较，并且得出对照测试的结果。

在BES Mirror的内部，提供了基于job的工作流模式，用户只需要简单地配置测试的内容，并且触发工作流，整个测试的过程就会自动化完成。下图即为BES Mirror的工作流图。

图3（点击可查看大图）

BES mirror 提供了前端用户操作界面以及后台API的支持，使得自动化测试变得相当简单。用户只需要选取要做对照测试的消费者，并且给出做引流回放的消息类型，然后触发自动化测试工作流，测试框架便会获取到这次待测试的内容，并且自动化地完成上述的1-4步，生成最后的测试结果。测试结果具体包括：

两个平台处理消息的状态是否一致。
相应的性能指标是否一致。
在日志中心生成的日志是否大体相同，是否没有新的错误日志出现。

基于这样的自动化测试的结果，能够清楚地知道在平台迁移过程中是否有未知的问题发生，以及消息系统的行为是否发生了改变。

成果

BES mirror所带来的效果是非常显著的，它很好地解决了迁移过程中的测试问题。主要表现在以下几个方面：

测试效率高
自动化的测试流程大大缩短了测试所需要的时间，一个大中型的消息系统，如果要从头去理解内部逻辑，整理回归测试集，没有几个月时间根本完不成。但是BES Mirror大大简化了这个过程，只需要提供简单的配置，一键便能完成测试，总过程只需要大约1天时间。BES Mirror提供多维度自动比较，并通过丰富的GUI很好地展示出来，帮助迁移团队节约了大量发现问题的时间。
测试覆盖全
利用引流回放的测试方法，可以在无需知道应用内部逻辑的前提下，覆盖所有的消息类型，从而保证各种边界情况都被照顾到，各种边界的问题较早地暴露了出来并且被及时地修复了，上线再也不用心慌慌了。
使用范围广
这个自动化测试平台不仅可以用来满足拆迁的需求，更能被广义地用来测试消息系统应用，满足用户新功能开发、维护和系统升级的测试需求。

展望

利用引流回放机制的自动化测试平台不仅可以应用在平台迁移的场景下，它也为基于不同实现的消息系统(如Kafka)提供了普遍意义上的测试解决方案。此测试平台可以为消息系统的各类新特性的开发测试、底层平台的改动测试、集成测试以及性能测试提供支持，成为保障消息系统质量的利器。

四、结语

消息系统的迁移不是一件简单的事情，需要迁移的应用数目颇多，消息的类型层出不穷，有许多消息更是与eBay线上交易息息相关，稍有不慎，迁移便会影响业务的运行，给公司带来损失。正是因为有了这样低成本高覆盖的消息系统自动化测试平台，让许多问题在测试阶段暴露出来，才保证了迁移后的上线质量，给用户和迁移团队提供了信心。到目前为止，迁移团队利用此自动测试框架，已经成功完成了多个消息系统的迁移。这套方案也将继续为更多的消息系统的质量提供保障。