Spring Cloud Netflix
基于Java 17、Spring Boot 3.2、Spring Cloud 2023版
- api 基础Api模块,定义module及部分util
- config-3344 配置中心,与远程交互方,接受发布配置刷新
- config-client-3355 配置中心,集群服务配置中心,与3344交互,启动获取远程配置
- eureka-x 服务注册与发现集群
- provider-config-client 服务提供,整合3355,启动获取远程配置
- consumer-config-client 服务消费,整合3355,启动获取远程配置
- websocket 应该只是消息推送
- Provider提供Web接口
- Consumer中Feign使用接口调用映射,当调用失败时进入FallbackFactory
- 将Feign相关放到api层,是因为在provider和consumer都有用到,在provider中通过这种方式可能(?)可以调用到其他的provider实例。这算是一种情况,但Feign是放到consumer层还是下沉到api层,后续再考虑考虑
- Provider和Consumer本身是相对的概念。
- 放到api层的好处是:api由provider侧维护,当consumer需要使用时,只需引入api即可,不必再自行开发Feign及降级逻辑。
- 可能带来的问题是:在consumer层引入了些不需要的Feign(违背最小依赖),另一方面api侧对Feign的改动,可能对consumer侧产生影响,有一定的不可控,以及不同的consumer侧可能有自己的降级逻辑(这个自己再写个Feign可以解决)。
- 配置刷新使用bus总线。可以通过config-server触发,也可通过config-client触发,还可定点通知
- 不使用总线时,可 post 请求 client-host:port/actuator/refresh 来主动刷新配置
- 使用总线时,可 post 请求 server-host:port/actuator/busrefresh 来刷新配置,这里注意 busrefresh是自己配置的path,不要带横线"-",也不要有驼峰命名 之前的bus-refresh与busRefresh都报了405
- 使用总线时定点通知,可 post 请求 server-host:port/actuator/busrefresh/{destination} ,destination为application-name:port , 不带port是同name的所有,同时支持模糊匹配,prefix* 匹配同一prefix的所有(有一个name为springCloudBus的Topic Exchange,所以支持这些路由操作)
- 第一种就是Feign和生产者的RequestMapping保持一致
- 第二种是在Api模块中定义提供所有请求的接口xxxApi,然后controller实现xxxAPI,FeignClient继承xxxAPI,这样就不必要写重复代码了。