本地调试: 这里是指在开发环境中,部署了一整套的某个项目或者产品的服务,开发人员开发时,本地会起一个或多个服务,这些服务和开发环境中部署的服务是相同的,这种情况下,一个服务就会有多个实例,大多数微服务中的默认负载均衡策略都是轮询,这些实例会轮流被调用。
为了方便 本地调试,需要提供一种策略,可以指定在负载均衡时,选择哪个实例进行调用。在使用 Nacos 作为注册中心时,可以通过 上线和下线 的方式来选择使用哪个实例,但是这种方式只能强制调用某个实例,如果开发环境还有其他人在调试,自己程序 设置断点 时会阻塞所有调用,非常不利于多人调试的协调。
为了解决 本地调试 的问题,本文实现了一种简单实用的策略,可以通过 Nacos 动态配置服务路由,还可以基于用户,部门,组织等级别配置服务路由,实现 本地调试 的同时,实际上也实现 灰度发布。
本文基于 Spring Cloud Alibaba 框架,和 Spring Cloud 相比增加了一部分针对 Dubbo 的方案,因此本文适合以下框架参考:
下图是 Spring Cloud Alibaba 框架中,一次方法调用的可能情况,Ailbaba 这部分多的是图中 ServiceA -> ServiceB
部分使用 Dubbo 协议。Spring Cloud 框架中,用的是 ServiceA -> ServiceC
这种 Feign(HTTP) 方式。
图中的所有过滤器和拦截器,虽然名称不同,但是作用相同。这部分的主要作用就是 获取或传递路由规则,例如,可以实现基于 HTTP Header 设置路由规则的配置,可以基于 HTTP 和 token 实现基于用户的路由规则配置,这部分的实现和需求有关,没有统一的实现。
这里以这两种场景简单举个例子。
在这个方案中,按照上面的流程图叙述一遍。
service-route
请求头,请求头的内容为servicea:10.10.10.130;serviceb:10.10.10.100;servicec:10.10.10.0/24
,在请求头中指明需要控制路由的服务信息(不需要控制的直接省略走默认)。ThreadLocal
)ThreadLocal
)RpcContext
将路由信息记录到attachment
中,这样可以把路由配置传递到 ServiceB,如果 ServiceB 还需要调用其他服务,路由仍然会起到作用。remote.application
配置的规则进行调用。RpcContext
获取路由配置,记录下来(如ThreadLocal
),如果后续调用其他服务,逻辑和 4,5,6一样。在 6 这一步的 Provider Filter 结束调用的时候,注意清空路由信息(如ThreadLocal.clear()
),避免对其他调用产生污染。IRule
实现基于自己路由规则的调用。RequestInterceptor
拦截器添加service-route
头,将服务路由传递下去。基于操作用户的方案中,和上面类似,但是不需要在每次请求的时候设置 HTTP Header,但是需要一种方式存取服务路由的配置。
这里以使用 Nacos 配置管理实现服务路由配置的存取。
服务名.user-routes
,使用 Spring Cloud Alibaba 的默认组dubbo
,用户服务路由的配置规则可以自己定义,这里举个简单例子:ThreadLocal
)。ConfigService
,根据服务名.user-routes
查询配置信息,同时监听该配置信息,根据这里的配置选择优先路由的服务。ThreadLocal
)。RpcContext
将用户信息记录到attachment
中,这样可以把用户信息传递到 ServiceB,如果 ServiceB 还需要调用其他服务,用户信息仍然会起到作用。remote.application
配置的规则进行调用。RpcContext
获取用户信息,记录下来(如ThreadLocal
),如果后续调用其他服务,逻辑和 4,5,6一样。在 6 这一步的 Provider Filter 结束调用的时候,注意清空用户信息(如ThreadLocal.clear()
),避免对其他调用产生污染。IRule
实现基于自己路由规则的调用。RequestInterceptor
拦截器设置token或用户信息,将操作用户传递下去。本文选择第 2 种方案,针对 1~9 步,分别讲解需要实现的接口和接口应用(生效)的配置。
上面提到的 ThreadLocal
,实现时使用一个 static
变量存储,提供相应的存取清空的静态方法,方便跨接口的 用户信息 传递。
假设有一个 UserGlobalFilter
,该过滤器根据 token
获取并缓存用户信息,在请求完成后需要清空缓存的用户信息。
Spring Cloud Gateway 中的过滤器,直接在 @Configuration
的配置类中用 @Bean
提供即可。
实现 ribbon-loadbalancer 中的 com.netflix.loadbalancer.IRule
接口,将来调用具体服务时通过 choose
接口返回符合条件的实例。
实现这个接口之后,需要特殊的方式注册该接口,在启动类增加注解 @RibbonClients(defaultConfiguration = UserRuleConfiguration.class)
,
注解中指定了一个配置类,这个类一定不要添加 @Configuration
注解!!!。
在这个类中,通过 @Bean
注解返回一个 IRule
接口的实现。
在 Ribbon 中,会创建一个新的 ApplicationContext 来初始化这些配置,在这个新的 ApplicationContext 中,配置的 IRule
实现会被使用。
实现 HandlerInterceptor
拦截器,从请求获取用户信息并记录下来。
拦截器想要生效,需要提供一个配置类,继承 WebMvcConfigurer
接口,实现 addInterceptors
方法,在这个方法实现中添加拦截器的实现类。
实现Dubbo 的Filter接口,通过 RpcContext
传递前面记录的用户信息。
可以在实现类添加 @Activate
注解,指定 group
为 CommonConstants.CONSUMER
。
按照 dubbo SPI 要求,添加 META-INF/dubbo/org.apache.dubbo.rpc.Filter
文件,写上实现类。
实现负载均衡接口,然后配置 LoadBalance
的 SPI 配置文件。
负载均衡想要生效,还需要配置使用,可以通过 dubbo.consumer.loadbalance
配置调用其他服务时,使用自己定义的负载均衡实现。
本方案中配置信息使用的 config-center,因此在实现中,可以使用下面的方式读取和监听配置
GovernaceRuleRepository repository = ExtensionLoader. getExtensionLoader(GovernanceRuleRepository.class).getDefaultExtension(); //获取配置方式 String config = repository.getRule("配置名", "group,默认dubbo"); //监听配置变更 repository.addListener("配置名", 监听实现);
如果使用 nacos,可以增加配置
dubbo.config-center.address=nacos://ip:port
实现Dubbo 的Filter接口,通过 RpcContext
获取传递过来的用户信息。
可以在实现类添加 @Activate
注解,指定 group
为 CommonConstants.PROVIDER
。
按照 dubbo SPI 要求,添加 META-INF/dubbo/org.apache.dubbo.rpc.Filter
文件,写上实现类。
这个实现类可以和 4.4 的放一个 Filter 实现中,需要自己区分当前是 consumer 还是 provider 实现不同的逻辑。
这一步的实现和 4.2 一样,4.2 是用在 Spring Cloud Gateway 中,这里是配置到具体的服务中。配置方式一样。
首先实现 RequestInterceptor
接口,在实现中往 requst 的 Header 中放置要传递的数据。
接口想要生效,需要和 Ribbon 类似的配置。
在 @EnableFeignClients
的注解中,通过 defaultConfiguration
设置一个 Feign 的配置类。在这个配置中通过 @Bean
提供 RequestInterceptor
接口的实现。
4.3 中是网关调用服务,4.9是服务通过 Feign (或resttemplate)调用服务,对被调用的服务来说都是 HTTP 请求,因此都会执行 Spring MVC 的拦截器,所以这里的实现是一样的。
本文提供了本地调试的方案和主要的实现要点,可以根据文中的关键指引和自己的实际需求实现自己的方案。关于本地调试如果有更好的方案,欢迎留言讨论。
判断IP是否相等或输入子网IP的方法:
remote.application
获取被调用的服务,这种方案比 Router 含义更准确(最初选择 Router 是受官方条件路由影响,没选LB是因为这种方案太简单)。