总结复盘
连着两天了，被一个功能折磨死了，准确地说，这个需求已经陆陆续续折磨我2个多月了。我需要好好复盘一下：这是一个跨系统的对接需求，首先跨部门的沟通就是一大难点，大家都不认识，对前路一无所知，需求写的也并没有特别清楚，导致了前期大量的沟通成本。有时候别人说完，你去复述一遍和他确认，他确认完过了会就不认账了；前期沟通完，真正的开发其实花不了多少时间，用Cursor的话几下就写完了。最费时间还是联调，首先是我的VPN没用，大概是权限不够（后面调测用了yan的没问题），用postman把流程跑通就费老劲了。到处问别人，找yan用她的postman去调，后面总算通了；结果呢，后面需求变了？与常规的OAuth2.0认证相比，多了两步流程，需要去获取系统登录时候的accessToken，这个accessToken是OAuth2.0认证里面的核心内容。由此为入口，我连接到了有接口服务，portal服务，业务服务，系统在接口服务里面去获取accessToken，然后呢没有人用到这个值，也没有保存下来。于是想到了第一版方案，将accessToken保存到Session中，然后业务侧去取，通过打日志的方式，发现在接口服务里面，session还没有生成，无法获取。于是呢，有了第二版方案，将accessToken放到缓存里面，第二种方案其实正常来说没啥问题，但是坑就坑在有多个地市，每个地市都有一套自己的业务缓存，而接口服务又有一套缓存，要不是正好第一次发生产的时候有个地市和接口服务的缓存地址是一样的，然后另外的几个不一样，导致的现象是有的地市能获取到，有的地市获取不到，这才发现了缓存地址不一致的坑。于是有了第三版方案，portal将接口服务返回的accessToken保存到Session，然后业务侧去取，由于是分布式的，Session其实是存在缓存中的，这样用户才能在多个地市间切换，所以Session对象其实是维护在公共的缓存里面的，全省都是一套，至此业务侧才成功获取到了accessToken。但是坑的地方还没有结束，有了这个accessToken，业务侧需要去调一个编排的接口来获取code，这个code其实是外系统的code，向统一认证去获取，这一步其实应该外系统去做的，但是他们丢给我们这边做，因为是https，需要用到TLSv1.2的加密算法来生成会话密钥，而环境上的jdk版本貌似不支持，这点还有待验证，希望明天可以解决这个问题。好在幸运的是，今天用yan的账号在我本地成功调通了这个接口，昨天还在怀疑是不是因为没有编排的证书的问题，后来仔细想了下明显不是，因为这是去调统一认证，而不是编排，去调编排才需要编排的证书。不过也涨见识了，mentor之前踩过这个坑，目前公司的工具类还没有可以发送请求绑定证书的方法，他自己写了一个，本质就是去加载resource里的证书然后放到请求中。
仔细想来，这过程中我有几点是可以做的更好的，第一个就是打日志，我刚开始打的日志很差，一些关键信息没有打印出来，导致了去排查问题，看个毛线，于是只能再去加日志，完全可以做到一次性加完，用以终为始的角度去看，假如出了问题让你去排查，你需要哪些信息才可以定位到问题，那么在一开始，这些日志就是要加上去的。第二个是调测，我完全可以找yan借他的VPN账号来用，这就解决了很大一部分的沟通成本。剩下的我觉得也只能走一步看一步。
Nanjing University of Information Science & Technology.
