Spring Cloud Config + Gateway + Eureka(native+手动更新+不重启+切换数据源)

前言叙述：

Spring Cloud Config 配置服务端与配置客户端，配置服务端Config Server 主要的作用集中保管与获取配置信息；

配置客户端的配置信息(大部分)放置在配置服务端，配置客户端本地不存放配置信息；

配置客户端启动后会首先去配置服务端取获取基本的配置信息(http://uri/{spring.cloud.config.name}/{spring.cloud.config.profile},uri为通过配置的spring.cloud.config.uri或者通过注册中心的spring.cloud.config.discovery.serviceId获取注册的uri)

Gateway 作为网关，同时作为Config Client与Eureka Client，Config Server与Config Client均作为Eureka Client；

网关能拦截过滤通过网关的请求，并且可以处理请求；

注册中心集中提供注册在其上的服务；

配置中心提供配置信息服务，开放的endpoint是(不用手动配置，bus-refresh需要配置)：http://配置服务端ip:配置服务端port/{name}/{profile}，并且nio实现实时访问实时获取本地文件最新配置信息；

配置客户端的配置刷新需要：1依赖actuator；2开放刷新endpoint:refresh;3依赖注解@RefreshScope(实现特征Bean的属性更新)；4触发更新；

需求分析：

1.原始的application.yml配置文件 spring.profiles.active 可以指定用哪个具体的配置文件，现在采用了Config Server能不能实现通过配置profile实现Config Client的配置文件的整体切换，且不用重启呢？

2.注解@RefreshScope能实现属性的更新，但是能不能实现数据源的更新呢？

解决方案：

首先分析项目框架的各个角色的主要功能

1.配置服务端主要用来集中保管与提供最新的配置信息，也就是说配置服务端的功能很单一，简单说native模式就是一个本地文件系统，然后开放访问api，保证最新，然后就没了，至于其他模式(git/svn/jdbc)，应该亦复如是，不外乎是提供bus-refresh进行更新本地文件信息，访问时提供最新的配置信息罢了，总体来说设计很单纯；

2.配置客户端，就是去配置服务端获取配置信息，于本地系统区别就是获取资源的方式不同，但是主体配置放在bootstrap中，配置客户端启动或者手动更新请求时会向配置的配置服务端的资源地址发起请求；

3.网关与注册中心的功能在前言叙述中已经说过了，不复多言；

其次解决思路

一.配置文件的整体切换，不外乎有两种方案：a.修改配置服务端的对应的配置文件；b.修改配置客户端的请求地址；

配置客户端的配置不改变，直接修改对应的配置服务端对应配置文件的配置内容，不免改动动静太大了，举个例子：配置客户端请求的配置文件时application-dev.yml,现在的做法是直接在配置服务端修改application-dev.yml，然后更新配置客户端取最新的配置文件即可，会不会发现这种的修改真是太粗鲁了；

配置客户端的配置不改变，然后在配置服务端有各种配置文件application-dev.yml，application-test.yml，application-prod.yml等等，然后再通过配置dev/test/prod等然后通过更新配置客户端，自动实现配置客户端配置文件的全文切换；然后怎么办呢？一开始的思路，配置服务端有没有这样的配置呢？分析一下会发现，配置服务端的功能定位很单纯，似乎不能做到直接配置进行切换，但是别忘了网关的存在，通过网关拦截过滤处理请求不就好了。

最终的解决方案是，通过网关进行配置请求的过滤处理即可，当然需要把网关也作为Config Client并且结合注解@RefreshScope实现具体配置客户端的请求的转发配置获取，然后对配置请求路径进行修改即可；

网关过滤重写配置请求

配置客户端请求、重发与配置服务端服务路径获取bean

配置客户端请求、重发与配置服务端服务路径配置文件  

注意：

1.所有的配置请求都写在了网关的配置文件里，所以更新配置客户端前需要先更新网关的配置文件

2.网关的路由都是在请求到达前先写入内存的，所以需要在更新时重写路由信息，也就是需要利用注解@RefreshScope在更新网关配置时刷新路由

3.配置客户端不能再直接配置配置服务端的uri或者serviceId，因为需要网关的过滤处理，所以全改成网关的uri或者serviceId

二.上文已经实现了配置文件的更新切换，数据源的配置信息自然也能获取到，这就需要分析切换数据源的关键问题所在。

我们使用的Spring框架，所有的东西都是和Spring整合，都交给Spring容器进行统一管理，Dao层用的Mybatis也不例外。

最直接也最简单的思路就是从Spring容器取出来对应的数据源对应的Bean，然后直接进行数据源的替换即可。

从容器中取出SqlSessionFactory，然后进行数据源替换

获取更新的数据源配置信息

思路很重要~方向对了，就只是方法的问题

注：

在配置服务端会存在配置文件的merge问题，即application.yml与application-dev.yml文件的，相同的属性访问后者时以后者为准(覆盖)，前者有而后者没有的属性，访问后者时也会有(合并在一起)；作用：前者可以存放共同的配置

application-prod.yml与application-dev.yml配置信息不会相互影响

application-dev.yml与application-dev-test.yml配置信息，application-dev-test只会合并application-dev一级，不会继续合并application

更新：

本着模块职责单一明确的原则：网关最好不做配置相关信息的转发与处理

配置客户端也不应该对配置做过多的处理，最好的方式是在配置服务端处理

处理思路分析：配置服务端拦截配置客户端的配置更新请求，然后判断请求文件里的spring.profiles.active属性是否与请求的profile一致，不一致时对请求地址进行替换即可。(Spring Cloud Config Server 基于Spring Mvc实现的可以实现请求的拦截处理)