目标
在原来系统中对接灯塔的数据接口，定时拉数据，注意超时
流程
老板给了一个postman脚本， 从导入脚本、查请求头，看灯塔文档、灯塔网关接入文档、数据上报查数据、设计数据表、封装灯塔查询接口、接口测试
遇到的问题：
- 老板给了一个postman脚本，自己花了时间去学习postman变量的设置、获取。耗时较多，不知道怎么拿变量。
- 用拦截器给feign增加请求头，共用了请求头。发现有两个不同的feign，分别请求不同的服务，分别要用不同的请求头
- 从上下文Environment中读取配置项，被原来的代码误导，并且即使没有类注解@Component，也要用@Autowired
- 设计表结构。耗时较多，想参考piwik的，增加多余的表
- 复杂的json转类结构。静态内部类改出了问题，有多余的类
- 静态内部类不能接收泛型，转成非静态的后，又json反序列化报错
- 封装feign接口总体耗时长
- 数据上报灯塔查不到数据
- 灯塔对接找灯塔小秘要了网关接入文档
- Feign Client请求接口的响应是text/plain，而postman请求接口的响应是application/json，导致Feign Client请求的响应无法反序列化
消耗时间： 一天半
预计时间：半天
问题分析
- 对postman的pre-request不了解。想要从{{applicationId}}之类的变量中拿到接入网关的请求头，花费了比较长的时间去学postman。结果{{sign}}还是计算得到的，不能直接复制。拿到了基本的固定值。
- 接入网关，应该找灯塔的对接人要iwiki文档，而不是想着只从postman的请求头里拿到参考信息。
- 设计表结构过于复杂。领导已经给出表结构的设计了，自己为了方便扩展和管理，由花了大量时间去看piwik的表结构，并且参考设计。最终只多出了一个管理行为的表，用处也不大。
- 用GsonFormatPlus插件通过postman接口返回的json生成了复杂的、包含静态内部类的DTO，发现不能传泛型，把复杂的内部类拆成了几个普通的类，可以正常接受泛型数据，但是类的数量较多，存在大量不需要的属性，后面优化DTO，只要了响应状态和基本的响应对象。在用工具生成复杂的结构后，要参考对接文档，精确的优化类结构。
- 对FeignClient的配置生效范围不熟。配置类上加@Component或者@Configuration注解的配置，是默认全局生效，不管有多少个FeignClient。去掉类注解后，加到@FeignClient的Configuration属性上后，是针对单个FeignClient生效
- 不要花大量时间看灯塔的对外文档，应该找灯塔对接人要网关接口文档
- 花了几个小时去查上报的数据
- 对Feign Client请求拦截器的了解一般，只知道是增加请求头的
值得肯定的地方
- 的确从postman脚本中拿到了网关的基本信息，也后续找对接人拿到了网关接入的文档，成功对接
- 在json结构较复杂的情况下，使用了idea插件自动生成了基本的类结构，虽然生成的复杂
- 没查到上报的数据，及时找了对接人处理，没继续自己摸索
解决方案
- 了解postman的脚本、console用法
- 以后接入网关，要先找对接要iwiki文档
- 设计表结构要尽量简单
- idea的各种插件可以用，但是不一定简单，需要自己后续优化，不能原样使用
- FeignClient使用起来是很简单，但就是简单才容易出错，要看官方文档和实现原理
- 内部对接就不要看对外的文档，参考性一般
实施计划
- 记录Feign、Environment的基本使用记录
- 了解Feign拦截器、配置加载的原理
- 去掉想把表结构设计的灵活的习惯
预期效果
- 后续接入其他服务的网关时，直接要文档、要基本参数、看算法，希望时间在一个小时内
