域名解析错误是怎么回事_一次比较耗时的线上问题排查

一个比较耗时的在线故障排除前言

大家好，我是朱日。现在成都人太多了，今天趁着还是阴天（现在谁也不知道什么时候会晴）的时候，太阳又出来了，出去骑了一段天府绿道，几乎没有人，相比之前人山人海的场面，还是有点不适应。下午回去之后，写一篇最近一次问题排查的记录。

我在新公司工作了几个月，一切都很顺利。和以前做程序员不一样的是，我不再是一个只顾着做好手头工作的士兵了，我成为了一个小公司的研发负责人，手下有好几个初中级程序员。可能有人觉得还不错，就是个小人物。我想说说我的感受。这个词是什么意思呢？就是说这个业务出了任何问题，你都是最终负责的人。事情很多，基本涵盖了需求、开发、测试、上线、上线维护的整个流程。开发阶段你要负责各种小事情，比如持续集成、git仓库、服务端申请、架构搭建；如果需求涉及到其他团队，你还要操心给对方提需求，还要协调时间；这些其实都很正常。如果是小公司，就没有那么多人手。总之，一个公司的研发负责人，基本就是各种角色的结合体。 我之前在腾讯的时候，有一个虚拟的组织形式叫xx业务承包团队，里面包括了与业务相关的产品、开发、测试、运维等各个职责的同事。

我感觉我现在有点像家庭联产承包责任制了。

暂时不说太多，上周四上午我正在写代码，然后其他业务组的两个同事来找我，说有个需求，同事A（比我入职早，算是中级程序员，领导就给他安排了这个业务）做了，现在上线了，app端访问报错，同事A说

他想不通，所以就找到了我。

我完全不知道有这个需求，进公司后负责开发另一个系统，但是下属无法胜任，所以就由我来承担这个任务。

调查第一天

排查问题第一步是加入微信群，加入群之后看到了问题截图，大致就是app上有一个h5的应用列表，后台可以维护这个列表，app动态获取这个列表并渲染出来，当用户点击某个应用的时候，就可以获取到这个应用对应的h5 url并加载进去，进入之后h5就是一些html+js，这时候就会调用后端接口来启动业务逻辑。

我们的问题是，应用程序入口已经有了，但是我们点击进去的时候，出现错误：

其实我对这种从后端开始排查的模式是有些意见的，看到这个接口的时候也不知道这个错误是怎么报的，h5前端同事应该先查看一下，知道错误提示是什么。至于为什么是我们来排查，当时也没想太多，因为这个问题必须得解决。其实我猜是因为之前他们已经排查了一两天，前端h5那边传给了A同事，说这个提示是后端接口出错导致的，大概给了点证据。然后A同事又没有证据证明不是他的问题，所以排查的责任就落到了A同事身上，然后又落到了我身上。另外因为部门拆分，前端同事已经不在我们部门了，估计问题排查对他来说可能不是高优先级的事情。

因为同事A当时还有其他紧急事情需要处理，我想还是不要浪费他的时间了，于是就没有详细询问之前的情况，就开始自主介入。

进组之后先认了下属，然后去跟前端同事线下沟通，问了几个事情：

h5的url是（真实地址已经隐藏了），我们的接口会在h5::8017//json中请求，由于我们的接口是一个很老的框架，所以接口url是一样的，但是真实的接口地址会携带在参数中，假设是函数A，我们的接口可能是这样的：:8017//json?=A。

现在回想起来，我忘了问他为什么确定是后端的问题了。得到上述信息后，我回来，邀请运维同事进群，问1.1.1.1:8017是什么服务，运维同事说这个机器是其他部门负责的。我加了其他部门的运维同事微信，刚问了几个问题，前端小伙就说地址不对，1.1.1.1不是调上线的，是另外一个域名：。

嗯，这个域名确实是我们维护的，这个域名的情况我还不清楚，当时只知道这个请求会进入一个接入层的机器，这个机器上部署了接入层的服务，后来发现上面还有ng，会转发到当前机器上的接入层服务，后续流程如下。

我其实感觉这个架构图是不完整的，但是我的运维同事太忙，经常找不到，所以暂时没法验证。

按照我的猜测，后端域名应该会被加载到两个nginx上（不管是dns做的还是ng前面有一层f5），每个ng都会转发到本机的接入层服务上。后面你就知道我为什么会这么估计了。

为什么接入层服务后面还有私有协议，而且是加密的？因为这些不是自研产品，是购买的。购买的产品，卖家肯定守得严，只教你怎么用，不教原理。这给我们排查问题带来了很大难度。

了解到这些之后，当天我就去找维护同事，告诉他我要在接入层的机器上抓包，然后我把rpm发给他，他就开始安装，但是安装报错，这个版本的依赖和机器上已有的依赖冲突，安装失败，我第一次看到这种错误，不知道怎么解决冲突，抓包计划失败了，我之前的文章讲过这个。

于是，我们只好想别的办法，我们又看了nginx的日志文件，什么也没发现。嗯，日志没有打开，甚至配置文件里也没有日志。然后，我的意思是h5是放在域名里的，h5请求我们打开，对应的机器应该和我们有网络连接，我查了一下，发现没有。其实这是因为我对h5不够了解，h5的域名不重要，h5加载到app里之后，是请求后端的，这个时候就是上网，也就是说用户和我们后端直接通信。这时候我就有点没主意了，运维同事开始在群里找前端交流，了解详细情况。

我拿着电脑找了个nginx的日志配置，但是由于没有验证过，所以不敢直接改。

没办法，nginx那层不行，本地nginx没有记录任何日志，然后微服务那边也没有日志，有点疑惑，请求去哪了？

后来我说不行就去网关层。我怎么就没想到先看看网关呢？因为我只是为了大家理解，才把这个东西叫网关的。其实它内部叫消息转发，我觉得它就是一个简单的转发服务，没什么好处。

当时没办法，就去查看了一下，grep了下日志，发现确实有，而且明确写到请求被转发到了微服务A的机器上，但是没有请求体，也没有响应体。

于是，我们开始怀疑是微服务A出了问题，排查了快一个小时，我们运维同事也很忙，所以只能从微服务A上拿两样东西，一个是微服务A和网关之间的抓包（后来发现是二进制的，妈的），一个是最近上线的业务jar包（微服务A其实相当于被一个这样的容器启动，容器会把请求转到你的jar包里去处理，就像把请求转到war包里一样，所以每次上线都会抛出一个jar包来升级，这是十年前的容器了，第三方公司卖的，不知道有没有人听过Sidi，太垃圾了，比垃圾还要垃圾多了，.sh就是一个脚本，最后还是用java命令启动，jmap，jstat都可以用，但是这个容器不行，为了防止客户破解，专门弄了一个二进制程序来启动容器，所以jmap等各种工具 不能使用）

一天的排查基本没什么结果，最后我们说，不如在测试环境多试一下，看看问题能不能重现。

第二天调查

今天的排错是我一个人的。我向测试同事要了服务器的 ssh 密码。同事说按照规定不能给，如果要用只能在固定位置的测试电脑上操作。于是同事就登录了那台测试电脑的 shell，我坐在那里查了差不多一天。

因为怀疑是微服务出了问题，所以就把这次升级的业务jar扔到测试环境里，发现没问题，然后微服务里有很多配置文件，我各种改，但是无法复现问题。

然后我一边在测试环境的接入层机器上抓包一边继续修改，最后搞到下午四点左右还是没能复现问题，只得出了一些结论。

例如，如果接口逻辑失败，错误信息将是：

图像-

如果删除这个接口，错误信息如下：

如果服务停止了，网关会报错，错误如下：

我发现在测试环境中，报错的时候，错误信息里会包含出错的服务名。而且这里的错误提示在app端会原封不动的显示出来。

但是网上的错误并没有显示报错的服务名，这时我就产生了怀疑，这个请求是不是到达了我们这边，之前的网关日志显示请求确实到达了我们这边，但是如果接口的错误不是我们这边导致的呢？如果是请求其他服务报错呢？

所以，到了这一步，我没法再继续下去了，我又要开会了，就停了下来。当我跟同事提到这件事情的时候，他帮我联系了一个更熟悉这个事情的人（他调到了其他部门）。那家伙说，这肯定是微服务的问题，那为什么不把整个线上容器文件夹都下载下来呢？我有了这个想法，就去找了运维同事，把整个线上容器文件夹都下载下来了。

拿到之后就开始查看网上的配置，发现在某个配置文件里，有一个地方接口需要配置两次，而且是重复的。然后，我就开心的以为是这里出了问题。由于下班后是周五，测试环境的电脑很慢，没法验证，所以打算等到下周再验证一下。

下周 - 星期一

周一一上班，暂时没管别的，赶紧跑到测试机前，发现并没有卡住，开始模拟重复配置的场景，发现就算重复配置也没什么影响，功能正常。

于是抱着试试看的态度，把网上重复的配置改了一下，果然还是出现这个错误信息。

周末在家研究了一下为什么之前的版本在接入层机器安装时会发生冲突，找到了解决办法。于是周一又发了一个版本给维护同事，这次安装成功了，就等着在接入层机器上抓包了。

周一下午三点左右，维护同事有时间，在接入层机器开启抓包功能后，抓取了nginx与接入层服务之间的网络包，然后在手机APP上操作复现问题，抓包完成。

我开始分析抓包，花了我不少时间，因为很难区分哪个包是我们的手机发过来的，根据我在测试环境对抓包的分析，点击h5应用肯定会先调用埋点统计接口1，再调用埋点统计接口2，然后再调用其他业务接口。

在抓包文件中，我只发现了埋点统计接口1和埋点统计接口2两个包，并没有发现对业务接口的调用。但我不确定这两个包是不是我们触发的。

对比之后发现不符，不是我们订的，这就奇怪了，他们怎么没抓到我们的包呢？

这就是为什么我怀疑肯定还有另外一个nginx，我们当时的包肯定跑到另外一个nginx去了。

我有些灰心丧气的坐在座位上，跟运维同事联系了好几次，但是他们都很忙，处理起来确实有点困难。

我开始怀疑，还有其他解决方案吗？

想了想，又想到了负责 app 的另外一个人，想看看他们之前遇到这个问题的时候是怎么做的。我现在在后端抓包，但是存在一些问题，第一，我不知道这个包是不是按照预期的路径走的，如果是的话，为什么抓不出来？第二，想看看 app 端有没有日志。

我去找app的负责人请教，他给我指了个办法，说如果手机连接电脑，电脑代理访问的话，那么网络数据包是可以看到的。于是我就在他那里现场试了一下，看到的请求包分别是：跟踪点统计接口1，跟踪点统计接口2，然后，我们的业务接口就没再被调用了。

现在证据在手，我开始在群里标记前端，说你没有调用我们的接口，你能先检查一下吗？

图像-

到这时，我感觉问题已经不在我们这边了，心情好多了。然后业务同事也准备周二去“捣乱”前端。

周二之前，晚上的时候前端发来请求日志，提示接口还是有问题。

看起来好像可以正常工作了，那么问题是不是立刻就被抛出来了？为什么代理刚才没有捕获数据包？奇怪吗？

但是我查看抓包发现内嵌接口里面有h5应用的appId，我们检查发现这个appId确实是我们的h5。

然后我就拿着这个ID去找运维同事帮忙比对接入层机器抓到的包，发现对不上，这证实了接入层机器抓到的包有问题，我们当时的操作确实不包含其中，肯定是另外一个nginx。

下周 - 星期二

排查了好几天，也没多少线索，也有点累了。请求大概是到达了微服务（之前网关也显示是转发到微服务的），如果处理正常的话，日志里会打印请求体，既然没有打印，那很可能是容器的框架层报错。

这时我想到可能得在这个微服务的黑盒上下功夫了。我把这个黑盒的框架层lib的jar包全部反编译成java，搜索“ to load ”，没找到；我仔细找了好久，还真没找到这几个字。

下午就想，既然线上的整个包都拉下来了，那我也应该在开发环境启动一下，看看能不能复现（之前为什么不这么做呢，因为我第一次用这个东西，连微服务怎么启动都不知道；之前想着先看看问题出在哪儿，于是到处抓包）。就没改线上那一堆配置，只是改了部分IP端口连接开发网关，本地居然也启动起来了（这个容器是国内公司做的，自然都是gbk编码，我的shell各种乱码，也不知道启动成功没有）。虽然错误很多，乱码也很多，但是看了一下监听端口，确实启动成功了。

然后我请求业务接口，问题复现了！

到这里我大概知道容器本身有一个日志文件，我查看了一下，发现如下内容：

找不到类？由于我的同事 A 在这段代码中确实使用了 JSON 解析，所以我认为这就是问题所在。

我怎么没在网上看过这个文件？我也是第一次知道这个容器，根本不知道有这么一个日志文件。同事A可能也不知道。说白了，我对这个容器了解不够多。

由于这是内部类，估计很快就会被加载，如果没有找到，

我查看了一下，发现容器的lib目录下确实没有json相关的jar包，也就是说这些jar包线上不存在，但是我们的业务代码用到了，上线的时候就只把业务jar包放到线上，自然就出问题了。

说实话，这种上线模式是有问题的，因为部门划分的原因，有些系统开发是其他部门接手的，但是运维在我们这边。所以上线的时候，必须到我们部门来。领导让我去查，之前看到升级包里只有几个class文件，就要上线了，问原因，他们说线上和本地差别太大了，没人敢全上线。

我也对比了本地开发业务代码的项目的pom依赖，和线上的差别实在太大了，如果不注意的话，以后必然会出现这样的问题。

解决方案

解决办法也很简单，如果网上没有，就上传；或者，改代码，网上有的就别用，网上有的就用，网上有的就用它的类，反正功能都差不多。

集装箱编码研究

本地开发环境已经启动，就尝试跟阿里巴巴对接，没想到竟然连上了，可以说是天大的好消息。

我记得没有jmap，而且容器是二进制的，所以很难找到入口。那我怎么没看到这个错误呢？

图像-

这个.java我之前没见过，在框架的jar包里找了好久都没找到，一头雾水，难道是二进制程序里动态生成的java类？我用连接找到了这个类，反编译了一下，发现如下代码：

图像-

这里我们加载类，并获取对应的实例，如果加载失败，则会抛出错误，返回-1011，跟前端哥们报的错误一致：

{"error_no":"-1011","error_info":"无法载入业务组件"}

总结

有几点我想谈一下。