订单同步工程标准化改造事记

说起来，也是一段比较有挑战有压力的经历。做完之后，有一种云淡风轻的感觉，故记之。

缘起

周二下午，忽报：QA 环境下单之后，订单搜索不出来了。

略排查，发现订单记录并未同步到 ES 索引里。进一步发现，订单同步工程 S 虽然进程还在，但已经不再处理消息了。昨天因为一个项目的需求才测试过 QA 环境订单同步无问题，上午也没动静，怎么下午就突然报问题了呢？

很快联想到，前两日，框架层发了通告：3.2.x 以下的 dubbo 不再提供自动注册 dubbo 服务的能力。很可能是 S dubbo 版本过低，无法注册和访问 dubb 服务，无法进行订单同步，进而影响订单搜索和详情，严重阻塞了项目的测试。订单是核心嘛~~

于是我将 pom 里的 dubbo 版本改成了 3.2.x 以上。可还是不行。要找框架同学一起排查下了。

旧世界 ClassVisitor

框架同学东顺说，早上貌似改过 zan 版本，也许是这个导致的。于是，我请求降回到原来的版本，先解决问题再说。sadly，即使降回到原来的版本进行部署， S 的服务依然起不来。退路已断。

框架同学子杰的第一个想法，是在本地启动调试。因为这样方便且高效。不过 S 应用已经很久没有在本地启动。而且 S 依赖比较多，在本地恐怕很难启动。

报 ClassVisitor should be a interface , not a class 。此类错误通常是 jar 冲突导致。因此，我在工程里搜索了下 ClassVisitor ，果然发现有两个，一个是接口，一个是类。 看来要排掉那个有类 ClassVisitor 的 jar 包。

<dependency> <groupId>com.youzan.platform</groupId> <artifactId>bootstrap</artifactId> <version>3.2.7.3-RELEASE</version> <exclusions> <exclusion> <groupId>org.ow2.asm</groupId> <artifactId>asm</artifactId> </exclusion> </exclusions> </dependency>

排掉之后，就不再报这个错了。 然而， S 依然不处理消息。

一边是测试同学在催促，一边是毫无头绪。心里有些急，可一时也想不到如何解决。子杰期望本地调试，可本地启动总是报奇怪的 groovy 不兼容错误。调了一晚上，终于把这个问题解决了。 但 S 依然不处理消息。

补丁

周三早上，继续战斗。子杰发了一段配置，让放在 S 工程的 XML 配置里。说这段配置是用来注册 dubbo 服务的。 加入之后，报错： cause: Could not initialize class com.coreos.jetcd.api.KVGrpc, dubbo version: 1.0.1-SNAPSHOT, current host: x.x.x.x 。 ZJ 说，这个错误之前见过，可能 protobuf 版本冲突了。

<dependency> <groupId>org.apache.hbase</groupId> <artifactId>hbase-server</artifactId> <version>1.2.6</version> <exclusions> <exclusion> <groupId>com.google.protobuf</groupId> <artifactId>protobuf-java</artifactId> </exclusion> </exclusions> </dependency>

排除 protobuf-java 包之后，终于可以起来了。 验证了下，订单同步 OK 了。 松了一口气。

间歇性跪

才没轻松多久， 又跪了。又跪了。又跪了。又跪了。 测试同学又来催了。

沟通

在这种情形下，发生一点小“纠纷”总是可能的。有一次，在吃饭的时候，S 跪了。 测试同学群里喊：进度如何了，找到根本原因了么？ 心里有点恼火：作为开发，我肯定要尽职尽责尽早排查和解决问题；可是你也不能只是催，在这样尴尬的时刻，可以支援一下嘛。 不过，大家都很通情达理，我提供了“临时启动服务”的方法，测试同学就帮忙先启动服务了。

反思一下，测试同学的做法也是合情合理的，因为他们要负责保障更大域范围的环境稳定，需要知道进度和原因。解决棘手问题时，同步进度和原因也是很重要的，心里应该装下更大的世界。此外，若我能及早同步“临时解决方案”，让测试同学知道怎么解决，也不会有这样的“纠纷”。有话好好说，总能找到更柔和的方式来解决。

于是我在群里回复：他们的担心和考虑是合理的，且已经快接近成功了。稍安。其实我也不知道距离成功还有多远。

蛛丝马迹

排查问题，只能从错误日志里寻找一切蛛丝马迹。ZJ 找了一段 JVMExitHook 的代码，加在启动的时候，这样方便在进程退出的时候，打印一些线索。 不过，这招没起效果，打印出的信息似乎没有派上用场。

同时，我也在仔细观察日志里出现的各种细微错误。不能放过一个嫌疑份子。确认了有四种可能的影响因素：1. 应用 M 跪； 2. Hbase 读写失败； 3. 脏数据； 4. 底层 jar 不兼容，导致某种隐藏的问题。

M跪