四六级一键查询项目复盘
1.背景：
官方将在2月27日公布四六级成绩。
2月24日凌晨时和欧阳讨论四六级准考证号查询或进一步发展为四六级一键查询的可能性及难点。24日中午正式决定开始开展项目，下午后端主要代码完成，当日晚后端完成准考证号的缓存。
25日下午四点左右前端发现已可查询成绩，项目组三人进行了深入的交流。25日晚前端完成后将产品链接发入大群，学长学姐介入，并立即决定当晚发布产品。
26日九点左右成绩又不可提前查询。
27日九点成绩正式公布，几分钟后端崩溃，直到一个半小时后才恢复。27日下午cet官方准考证号查询api不可用。

2.后端程序结构 && 目标
共有三个api。
查询准考证号的api将先尝试从缓存取出准考证号，如果没有则用爬虫获取准考证号，然后存入数据库，获取准考证号后再尝试用准考证号和数据库的身份证号从不需要验证码的学信网获取成绩，如果成功则将获取数据返回，失败则返回准考证号和姓名。
另外两个api一个是获取中国教育考试网的验证码，另一个是以用户输入的验证码去获取成绩。

程序设计时考虑到学信网非常容易崩，且到时候会有一定的改版，便在学信网爬虫部分使用了很多try，并且在服务器上根据实际情况修改请求的timeout，避免很多用户长时间的阻塞在这，从而占用过多线程数导致服务不可用。
为保证可用性，准备了两个爬虫，在查询准考证号的api里如果学信网不可用则只返回准考证号和姓名，接着使用中国教育考试网的爬虫来获取成绩。
为避免到时候cet官方准考证号查询接口不可用，提前缓存了所有大二大三的准考证号，使主体用户在情况最糟糕的情况下都能使用核心功能（此时大一还没考四六级）。

3.遇到的问题 && 当时该怎么做更好
25日发现成绩能提前查询时，在服务器上直接将查询准考证号api里使用学信网爬虫的代码删掉，避免在这里无意义的浪费时间（当时学信网还不可用）。
27日临近九点时使用git checkout --恢复代码，并将学信网请求部分的timeout设为2秒，几分钟内服务可用。随后学信网开始以一定概率爆出验证码，服务开始不可用，但以后端代码的设计逻辑来讲，服务并不会因此崩溃，所以当时的猜测是因为中国教育考试网太过拥挤或我们服务器的ip已被ban掉，进行curl和wget后确认没有被ban，丢包率也确实非常高，再加上后端的监控系统没有报与timeout相关以外的错误，便没有怀疑是代码本身有问题，而将目光放在了丢包上。于是当时直接在服务器上，提高中国教育考试网的爬虫的请求数，如果单次调用爬虫，发出5次网络请求都还没有成功才会返回。但随后发现服务依然不可用，便开始感到焦虑。本地进行了一些测试后发现这部分代码效果提升不明显，便git checkout --恢复了这部分代码。
开始将目光放到学信网上，研究了当时学信网页面的逻辑，再次确认从代码上讲爬虫无论如何都会返回布尔值为false的值或成绩。此时离公布成绩的时间已经过去了快一个半小时，心态已经非常焦急，便抱着试试的心态又将使用学信网爬虫的几行代码删掉，随后发现服务可用。
当时非常不解为什么那几行代码会出问题，本地跑了后端部分后，用postman测试并没有出现问题，学信网的爬虫也确实返回了一个布尔值为false的值，而docker+virtualenv一般也不会因为环境问题使服务不可用。当时也没有考虑使用log在生产环境调试，不过现在觉得应该做一下看看到底发生了什么。

现在看来当时有很明显的证据证明问题出在哪——准考证号没有返回，那就说明查询准考证号的api出了问题，而自己的准考证号又已经缓存，检查过redis后便只可能是学信网的爬虫部分出了问题。
而这部分当初设计时是觉得无论如何都要返回的，所以便在觉得可能出问题的地方使用了try。可如果要保证服务的可用性，又不确定爬虫到时会出如何的错误，建议在调用爬虫的外面加一层try，这样即使这个爬虫出了你完全没有预想到的错误，也不会影响服务的可用性。

4.总结
1.出问题时首先明确哪出了问题，像这次就很明显是查询准号api不可用，首先应看到并修复它，再考虑之后别的api丢包的问题。
2.在出成绩的时候爬虫普遍都会阻塞很久甚至失败，这时候应该首先保证服务的可用性，比起长时间的网络请求，try的性能牺牲并不大，而如果不是百分百确定哪会出问题，则可以在调用爬虫时套层try。