本月是入职的第二个月，月初对上个月做的动态数据源进行了封装，抽出到common公共包里，需要使用的地方直接添加依赖即可。这里也碰到了一些问题，比如抽出到common后由于springboot先加载自己内部的类，再加载引入的类，这导致原来的配置在抽出去后不能够正常加载。原先是通过实现 InitializingBean接口后重写afterPropertiesSet方法就可以实现在mybaits 的bean初始化之前进行初始化数据源，抽出到common包后，原先的办法不再有效。我先后尝试了很多方法，比如让common-db变成一个starter，使用ConditionalOnClass注解等等。都无法实现，最后发现让使用动态数据源的springboot项目继承我的动态数据源配置类，单这样是不优雅的让启动类去继承你的实现，明显不符合实际使用的需求。后来翻墙出去查资料发现了BeanPostProcessor接口，debug后发现，实现它的类会被先加载，而且实现它之后，不需要做处理即可实现我想要的效果。
然后我顺手做了基于springboot2.x的实现，动态数据源的事就暂时告一段落。
然后做了一个基于RibbitMQ的回调钩子，在服务异常关闭时，推送一个消息，通知给注册中心，让注册中心将该服务移除。这里，我学到了eureka服务发现是定时去扫描可用的服务，然后将它变成一个service。如果他发现请求不到，会尝试多次请求该服务 默认5次，然后将它剔除出服务列表。
之后做了项目的发布，发布到了正式环境。这里学到了一些jmap的使用，top命令的使用等等，修改了网关的fallback模式，原来的发现是线程不安全的。原先使用了一个全局静态的异常，在多线程情况下会出问题。最后改造了一下，效果如下
异常信息在返回处写死。
之后封装了spring cloud zipkin进行服务调用发现，封装了spring boot admin2.x 监控服务健康。实现了使用spring boot1.5也能使用admin2.0的大部分功能。网上没有相关资料，我去查了官方api发现可以实现，最后实现了他。
再之后我发现了我们的网关测试接口很不方便，还要依赖于postman，我发现网上有一个网关聚合swagger的博客，就想到我们的网关是否也能聚合swagger，但是他的博客是基于zuul网关实现的，基于spring cloud gateway的实现只做了模糊的介绍。使用它的介绍我无法完成这个功能。花了两天时间完成了这个功能，并且发现了swagger2.6.1源码中的一处bug，在github 上提交给了swagger官方。我暂时采用重写了gateway的org.springframework.cloud.gateway.filter.headers.ForwardedHeadersFilter接口，暂时处理了这个bug。
之后进行了易流云导航头的开发，包括前期交互讨论，工程初始化，代码的编写。期间参加了3天公司的培训，写导航头接口没有遇到什么问题，就是普通的接口开发，但是接口的调用量还是挺大的，里面做了一些内存缓存。比较有意思的就一个接口，出现了一些问题，思路整理后，也解决了。
