工作第二周 2018 0514~0520-CSDN博客

本文链接：https://blog.csdn.net/weixin_30531261/article/details/80384081

了解新模块

工作第二周，大佬是给我的任务是熟悉ETC圈存模块，前两天一直在看代码，但是看不下去，看的好困。也看的似懂非懂。但事实证明，就是不懂啦。也没有针对性的去看。

写接口

以前面试的时候，面试官跟我说过他们这边java的主要工作就是写接口以及写服务等等。写服务的话上星期接触了，而这个星期接触的这个模块，就是提供接口。
所谓提供接口，就是用来衔接第三方接口与我们这边的app端。

看了代码之后，我对写接口进一步的理解是，通过将请求参数按照第三方接口提供商的协议进行封装，然后发送数据报给接口提供商，然后获取到响应数据后，同样根据协议进行解析，解析完再将数据封装成一个dto，返回给调用者。

通过日志排查问题

第二天的时候，项目经理齐就经常来找我麻烦。因为用户那边经常向客服那边投诉程序有问题，客服那边又向他反馈。他就来找我，让我找出出错的原因。他扔段信息给我，大概像这样：“x年x月x日，用户手机号为xxx，订单号为xx，在执行圈存的时候出现了车牌号与车牌颜色不符的问题。”然后，就让我找错，我一脸懵逼？？？找什么错？？？什么意思？？？错误不就是车牌号与车牌颜色不符吗？？？要我找什么？？？

然后我就通过手机号，订单号去日志里查询，但也不知道要查什么，一脸懵逼，也没什么什么有效的信息。看了十几分钟，半个小时。事情也就不了了之了。但是齐经常发段信息过来让我找错，我找不到，他让我旁边的同事帮忙找错，他也找的很困难，但是他好像比我理解齐的目的。

后来，跟齐沟通过后，也跟同事沟通过后，才算是理解，要我找什么错。其实齐一开始就有解释，但是我不理解。操作之后再问一次，我猜算是理解了。但我觉得也不能怪我，因为我的整个流程不理解，对业务也不理解。

齐的目的

是这样的，用户通过app来进行一些充值、查询、圈存操作。比方说圈存操作，它个这个操作是一个流程，用户输入一系列的数据，然后提交，然后app就会调用我这边的接口，先后依次调用，最后反馈一个结果，显示在app界面上。然后，现在的问题就是，用户操作完后，反馈给他的信息是“操作失败，失败原因是车牌号与车牌信息不符”，然而用户确定他填写的车牌号与车牌信息是相符的，也就是说app显示的反馈结果是有问题的。用户就无法理解了，就向客服投诉，客服就跟齐反馈，于是，齐就找我，让我通过日志，找出出现这个问题的原因。

那出现这个问题的原因有哪些呢，我到现在还没完全搞懂。我只知道，有这么些可能，一个是app端的流程控制有问题。另一个原因，也是主要的原因，就是第三方接口提供商那么处理数据有问题。因此，齐让我找出出错的地方，意思就是说，找到整个流程中，最先出现的那个地方。然后通过那个错误码，时间，用户信息，把信息发给第三方接口提供商的员工，让他们帮忙查看究竟是什么问题。大概就是这个意思吧。

系统日志处理太糟糕

然后，尽管我理解了我看日志的目的是什么。可是，每次齐来找我，扔段信息给我，让我找错，我都没能找出来。因为，之前的日志写的真的是太烂了。

这里又有一段故事。第三天的时候，齐看我找了半天都没找到错误，就跟我说，这日志这样搞不行啊，每次都要找这么久。你看看这日志该怎么处理，重新弄过吧。我当时回答的是，这日志处理是老员工写的啊，怎么写也不会比我们写得差吧。但其实，当时我也意识到了日志写的不好，无法实现日志信息追踪。

这里再岔开讲一下什么叫做日志追踪，这都是我自己想出来的词，理解也不一定正确。首先，我们查看日志，就是为了找到某个用户的操作流程的记录，我们可以用手机号码来标识一个用户，然后我们可以通过手机号码来实现追踪，但是之前的日志系统，并不是说每个语句都要用手机号码来标记，有些地方又没有写日志，因此，最终导致的结果就是，各个用户的操作记录穿插在一起（也就是说第一行的记录是a用户的x1操作，第二行是b用户的m1操作，第三行是c用户的k1操作，第四行又是a用户的x2操作…），然后又没有唯一标识去追踪，这样，日志就没法看。有时用户a的两个操作步骤记录之间就隔了几百行。所以，真没法看。

回到那个故事，我一开始是下意识的觉得，我怎么可能写的比老员工好，毕竟我只是个应届生啊。也许是对该领域知识接触甚少，不自信吧。但是在查看日志的过程中，真的觉得没法追踪，这日志没法看。同时齐也给了新的任务，让我完善日志功能，于是就只好硬着头皮上了。

公司java的老员工都走了，因此只好我们应届生自己来做了，其实会怕，是因为没做过，不知道难度有多大。

然后就第三天下午还是第四天上午，就开始完善日志功能了。带着目的去看代码，效率确实会高很多，也看到了日志写得确实不好，比方说，A类中这样定义：

private Logger logger = LoggerFactory.getLogger(A.class);

然后，肯定是因为复制粘贴，然后B类中就出现这种情况：

private Logger logger = LoggerFactory.getLogger(A.class);

即都写了A.class，后面发现，有两个类都有这样的错误。这在看日志的时候，会让你懵逼。

还有这样的问题，一个service方法中，logger的关键字都用operation1 data来表示，这其实也还好。但是另一个方法，logger语句也是复制粘贴过来的，也出现了operation1 data，这就出现了service方法和日志的关键字不相符的问题。看日志的时候，就会混乱。

还有一个问题，就是有的关键的地方没写日志！！！

最要命的是，没有一个标识来追踪这些日志记录，有的记录里用了手机号码，有的因为没有传手机号码，因此用的是另一个标志，如订单号、卡号。这样下来，就让人崩溃了。没法追踪。

这些问题全部混在一起，就更混乱了。

钉钉机器人自动通知

这是日志的问题。另外，大佬，薛，说，不能每次都等用户投诉我们才去处理，我们要主动把问题给处理掉。他的意思是，当出错的时候，要自动报警，通过钉钉机器人发出通知，然后我们及时去跟进问题。他让我改进项目，通过钉钉机器人，拼接好数据，然后到时就可以直接将这段话复制粘贴发给第三方接口提供商的员工，让他们去排查问题了。说起来倒是简单，但实现起来不简单啊。这个后面再说。

改进花了3天

这里也不详细展开我怎么做，他给我的时间是2天，刚好是周四周五，我就顺着周末继续做了。花了4天吧，去掉中间聚餐，排查日志浪费的时间，应该就三天的时间吧。就算是把两个功能做出来了，但是还没发布，可能等今晚12点吧。也不知道会不会有问题，没有测试环境啊。尴尬。虽然也检查过了，但是也难保不会出现问题。

改进

我也就着之前日志存在的问题进行了改进，最大的问题就是如何实现追踪。齐说你可以传参去标识啊，我听了感到很无语，可能与他学的语言的不一样吧，也许他更精通的是业务。我觉得要是一直传参，那代码到处都要修改，而且这样写代码会越来越烂。我当时隐约记得有那么一个东西是可以实现追踪的啊。最后问了以前的大佬，他说可以通过线程号来表示。我在我的毕设作品上测试了一下，确实是可以，一个请求中Controller方法的日志，service层的日志，只要属于同一个请求，只要没有另外开辟线程，就是使用的同一个线程。这样，就能实现线程的追踪了。然后，就是日志的规范化处理，每个方法都统一，相应的位置都做好日志打印。

心慌

也不知道有没有少考虑什么情况。也不知道会不会这样改过之后，还是会出现“每次出现，都要花很长时间去找日志排查问题”。最怕就是这样了，这样的话，我就是白忙了。

##钉钉机器人自动报警，理想与现实

至于钉钉机器人的通知，其实也就是准备好数据，然后调用钉钉提供的接口，将数据发到指定的人的钉钉上。但是，齐让我实现的功能是这样的：

今天上午9点41分，133252xxxxx用户在生产环境，
卡号为17092210020xxxxx存在未圈存订单，发起圈存，
结果提示0xxx错误，系统忙，请稍后再试。
该笔未完成圈存的订单号为2018051xxxxxxxxx。

但是，我这边只能知道他调用了我什么接口，但没法知道他的操作流程啊。（一个操作流程可能需要依次调用多个接口）。像上面说的圈存操作，是几个操作拼接起来的一个流程啊。郁闷。

我最终只能把调用接口的过程打印到另一个文件上，即除了常规日志，再另外输出一个日志文件，存储的是app端调用的接口的记录。这样，通过查看日志，就能反向推出用户执行的是什么操作了。我也不知道是不是我能力有限，还是我知识面有限，才做不到。

##logback的学习

导出两份日志文件，之前也是不会的，没接触过。也是上网查资料学习的。参考网站为：https://www.cnblogs.com/userrain/p/5697186.html
还有这篇，详细的讲解logback的使用：https://blog.csdn.net/kittaaron/article/details/9151103