0
点赞
收藏
分享

微信扫一扫

03_微服务之Nacos注册中心与Feign远程调用

萧让听雪 2022-03-14 阅读 138

文章目录

1. Nacos注册中心

国内公司一般都推崇阿里巴巴的技术,比如注册中心,SpringCloudAlibaba也推出了一个名为Nacos的注册中心, 现在是SpringCloud中的一个组件

同时Nacos相对于Eureka, 功能更加丰富, 例如Nacos不仅仅可以做服务的发现与注册, 还能做分布式的配置等, 因此在国内受欢迎程度较高

Nacos属于绿色软, 解压即安装,其中.tar.tz文件是Linux安装包, .zip文件是Windows安装包

安装后其中target是存放jar包的目录(因为Nacos也是Java写的), 其中conf存放配置文件, 可以在application.properties中修改默认端口(8848), 而bin目录存放可执行文件, 其中startup.cmd就是启动入口, 在bin目录输入:

startup.cmd -m standalone

即可启动Nacos, 注意standalone是单机启动而不是集群启动

或者直接双击startup.cmd也可启动

启动之后在控制台会弹出端口版本以及访问地址, 从访问地址访问即可, 默认账户密码都是nacos

1.1 服务注册到Nacos

Nacos是SpringCloudAlibaba的组件,而SpringCloudAlibaba也遵循SpringCloud中定义的服务注册、服务发现规范(SpringCloudCommon公共模块中的DiscoveryClient服务发现接口以及ServiceRegistry服务注册接口)。因此使用Nacos和使用Eureka对于微服务来说,代码层面并没有太大区别。

主要差异在于:

  • 依赖不同
  • 服务地址不同

因此只需要修改依赖以及修改配置的服务地址(下载时配置的Nacos地址, ip地址:8848)即可

注意:

  • Eureka需要搭建服务注册模块步骤, 但Nacos只要启动了下载的Nacos即可, 不需要再创建Nacos的服务注册模块
  • 服务拉取步骤Nacos与Eureka一致(注解+改url)
  • 都需要配置自己的服务名称(yml)

1.1.1 引入依赖

  1. 在父工程的<dependencyManagement>中声明SpringCloudAlibaba的依赖:
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-alibaba-dependencies</artifactId>
    <version>2.2.6.RELEASE</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>
  1. 在需要注册的微服务中引入nacos-discovery依赖:
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

1.1.2 在服务中配置nacos地址

使用Nacos之后的服务都需要将eureka的地址改为nacos地址:ip地址:端口号(由于Eureka的服务端也是一个微服务,因此Eureka地址配置时是一个完整的url):

spring:
  cloud:
    nacos:
      server-addr: localhost:8848

最后重启服务, 登录nacos管理页面,看到微服务信息即代表注册成功

1.2 服务分级存储模型

在前面, 我们知道一个服务可以有多个实例,例如我们的user-service,可以有:

  • 127.0.0.1:8081
  • 127.0.0.1:8082
  • 127.0.0.1:8083

假如这些实例分布于全国各地的不同机房,例如:

  • 127.0.0.1:8081,在上海机房
  • 127.0.0.1:8082,在上海机房
  • 127.0.0.1:8083,在杭州机房

那么Nacos就会将同一机房内的实例 划分为一个集群

也就是说,user-service是服务,一个服务可以包含多个集群,如杭州、上海,每个集群下可以有多个实例,形成分级模型,如图:

在这里插入图片描述

微服务互相访问时,应该尽可能访问同集群实例,因为本地访问速度更快(外地几百公里延迟太高)。当本集群内不可用时,才访问其它集群(家里没花了才去采野花)。例如杭州机房内的order-service应该优先访问同机房的user-service

类似于前面Ribbon中的Zone的概念

也就是说Nacos的服务分级存储模型一级是服务, 二级是集群, 三级才是实例

默认情况下, 一个服务的集群为default空, 我们可以通过修改yml文件来配置集群:

1.2.1 配置服务集群

在上面的yml文件基础上修改application.yml文件,添加集群配置:

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ # 集群名称,也就是机房位置

我们可以再次复制一个user-service启动配置,添加属性:

-Dserver.port=8083 -Dspring.cloud.nacos.discovery.cluster-name=SH

配置如图所示:

在这里插入图片描述

启动UserApplication3后再次查看nacos控制台:

在这里插入图片描述

1.2.2 配置同集群优先的负载均衡:NacosRule

默认的ZoneAvoidanceRule并不能实现根据同集群优先来实现负载均衡

因此Nacos中提供了一个NacosRule的实现,可以优先从同集群中挑选实例,同时在优先同集群的情况下使用随机方式进行负载均衡, 但当没有同集群的服务时也会访问不同集群(但是在消费者日志会打警告日志提醒跨集群访问)

配置步骤:

  1. 首先设置服务消费者所在集群
spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ # 集群名称
  1. 在yml文件中配置负载均衡规则(或者使用配置类):
userservice:
  ribbon:
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则 

1.3 权重配置

实际部署中会出现这样的场景:

服务器设备性能有差异,部分实例所在机器性能较好,另一些较差,我们希望性能好的机器承担更多的用户请求

但默认情况下NacosRule是同集群内随机挑选,不会考虑机器的性能问题

因此,Nacos提供了权重配置来控制访问频率,权重越大则访问频率越高

在nacos控制台,找到一个服务的实例列表,点击编辑,即可修改权重:

在这里插入图片描述

在弹出的编辑窗口,修改权重(0-1):

在这里插入图片描述

1.4 环境隔离

首先, 我们知道Nacos除了是注册中心还是一个数据中心, 因此在Nacos中为了去做服务和数据的管理, 会有一个隔离的概念

Nacos提供了namespace(命名空间)来实现环境隔离功能。

  • nacos中可以有多个namespace

  • namespace下可以有group, group下有service或Data等, 而服务下面是集群,再往下才是实例

    集群与实例的划分是基于业务的, 而命名空间的划分是基于生产环境的, 而组的划分是根据不同服务之间的业务相关度的(将业务相关度高的放在一个组, 一般情况下也很少配置group)

  • 不同namespace之间相互隔离,例如不同namespace的服务互相不可见

    在没设置的情况下,所有的服务都在默认的public命名空间下

如图:

在这里插入图片描述

1.4.1 创建namespace

在Nacos的控制台可以创建新的namespace:

在这里插入图片描述

接着填写命名空间名(例如dev)与描述即可(例如开发环境)

命名空间ID一般自动生成

1.4.2 给微服务配置namespace

给微服务配置namespace只能通过修改配置来实现。

例如,修改order-service的application.yml文件(ID在Nacos控制台查看):

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ
        namespace: 492a7d5d-237b-46a1-a99a-fa8e98e4b0f9 # 命名空间,填ID

接着重启服务, 在Nacos的控制台可以发现服务位于新的命名空间下

注意:

​ 由于此时俩个服务namespace不同, 因此无法远程调用

1.5 Nacos与Eureka的区别

Nacos和Eureka的服务健康监测有着明显的区别:Eureka通过"心脏"进行监测, 而Nacos除了"心脏"监测还会将服务实例分为俩种类型:

  • 临时实例:如果实例宕机超过一定时间(采用心跳监测,频率比Eureka快),会从服务列表剔除,默认的类型
  • 非临时实例:如果实例宕机,不会从服务列表剔除, 而是等他变健康, 不会做心跳, 而是由Nacos主动询问(主动关怀你还活着吗),也可以叫永久实例

对于一个服务属于什么实例可以在Nacos的服务列表中点击详情查看

同时Nacos会主动推送服务健康变更信息(pull+push)

而Eureka不会, 因此Eureka更新健康信息不及时(pull), 使用Eureka可能会访问到挂掉的服务实例

总结:

共同点:都支持服务注册,拉取以及心跳健康监测

区别:

  • Nacos对永久实例会主动监测健康状态, 临时实例才使用心跳模式
  • 永久实例不会被剔除, 但为了不给服务器太大压力, 不建议使用永久实例
  • Nacos信息推送更加及时, 而Eureka是定时拉取, 信息更新不及时
  • Nacos集群默认采用AP方式(强调数据与服务的可用性),当集群中存在非临时实例时,采用CP模式(强调数据的可靠性与一致性);Eureka采用AP方式

1.5.1 设置服务为永久实例:

在配置文件中进行如下配置:

spring:
  cloud:
    nacos:
      discovery:
        ephemeral: false # 设置为永久实例

1.6 Nacos提高:配置管理

前面提到Nacos除了可以做注册中心,同样可以做配置管理来使用, 这里讲的就是使用Nacos进行配置管理

1.6.1 统一配置管理

当微服务部署的实例越来越多,达到数十、数百时,逐个修改微服务配置就会让人抓狂,而且很容易出错。此时我们就需要一种统一配置管理方案,可以集中管理所有实例的配置

而Nacos一方面可以将配置集中管理,另一方面可以在配置变更时,及时通知微服务,实现配置的热更新:

在这里插入图片描述

那么如何在nacos中管理配置呢?

1.6.1.1 Nacos服务端配置

如图:

在这里插入图片描述

在这里插入图片描述

1.6.1.2 微服务拉取Nacos配置

微服务要拉取nacos中管理的配置,并且与本地的application.yml配置合并,才能完成项目启动

在没有Nacos之前, 微服务启动流程:

但此时要从Nacos读取配置, 流程就变为:

如果尚未读取application.yml,又如何得知nacos地址呢?

因此spring引入了一种新的配置文件:bootstrap.yaml文件,会在application.yml之前被读取,流程如下

使用姿势:

  1. 引入nacos-config依赖
<!--nacos配置管理依赖-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>
  1. 添加bootstrap.yaml

    在resources中添加一个bootstrap.yaml文件,内容如下:

spring:
  application:
    name: userservice # 服务名称
  profiles:
    active: dev #开发环境,这里是dev 
  cloud:
    nacos:
      server-addr: localhost:8848 # Nacos地址
      config:
        file-extension: yaml # 文件后缀名

在这里插入图片描述

配置完将application.yml中的重复内容删除

  1. 在user-service中的UserController中添加业务逻辑,读取前面Nacos中配置的pattern.dateformat配置(通过 @Value("${pattern.dateformat}")), 读取配置是可以通过@Value注解的
@Slf4j
@RestController
@RequestMapping("/user")
public class UserController {

    @Autowired
    private UserService userService;
    
	// 读取配置:
    @Value("${pattern.dateformat}")
    private String dateformat;
    
    @GetMapping("now")
    public String now(){
        return LocalDateTime.now().format(DateTimeFormatter.ofPattern(dateformat));
    }
    // ...略
}

1.6.2 配置热更新

我们最终的目的,是修改nacos中的配置后,微服务中无需重启即可让配置生效,也就是配置热更新, 这样子我们才可以修改配置时不需停止服务器

要实现Nacos配置热更新,可以使用两种方式:

1.6.2.1 方式一:@RefreshScope

前面我们读取配置文件内容使用了@Value("${pattern.dateformat}"), 现在要完成配置热更新只需在@Value注入的变量所在类上添加注解@RefreshScope:

@Slf4j
@RestController
@RequestMapping("/user")
@RefreshScope
public class UserController {

    @Autowired
    private UserService userService;
    
	// 读取配置:
    @Value("${pattern.dateformat}")
    private String dateformat;
    
    // ....
}

当增加@RefreshScope注解之后, Nacos配置发生变化会告知微服务, 并通过这个注解实现热更新

1.6.2.2 方式二:@ConfigurationProperties

使用@ConfigurationProperties注解的配置类获取配置属性值代替@Value注解

其中prefix属性设置前缀, 前缀与变量名拼接后与配置文件一致即可实现自动注入

在user-service服务中,添加一个类,专门读取patterrn.dateformat等配置属性:

示例:

@Component
@Data
@ConfigurationProperties(prefix = "pattern")
public class PatternProperties {
    private String dateformat;
}

在UserController中使用上面这个类代替@Value(需要@Autowired自动注入, 然后通过这个对象的get方法得到属性值), 示例:

@Slf4j
@RestController
@RequestMapping("/user")
public class UserController {

    @Autowired
    private UserService userService;

    @Autowired
    private PatternProperties patternProperties;

    @GetMapping("now")
    public String now(){
        return LocalDateTime.now().format(DateTimeFormatter.ofPattern(patternProperties.getDateformat()));
    }

    // 略
}

麻烦, 但是规范

1.6.2.3 总结

热更新:

  1. 通过@Value注解注入配置的属性值, 结合@RefreshScope来刷新
  2. 通过@ConfigurationProperties的配置类来自动注入与自动刷新

注意:

  1. 不建议把所有配置都放在配置中心, 维护起来比较麻烦
  2. 建议将一些关键参数, 需要运行时调整的参数放到Nacos配置中心, 一般都是自定义的配置

1.6.3 多环境配置共享

当一个配置在开发,生产与测试环境下的值是一样的时, 就需要微服务间的多环境配置共享, 否则在每个配置文件中都写一份就有些浪费, 改动也比较麻烦

其实, 微服务启动时,会去nacos读取多个配置文件,例如:

  • [spring.application.name]-[spring.profiles.active].yaml,例如:userservice-dev.yaml

  • [spring.application.name].yaml,例如:userservice.yaml

显然[spring.application.name].yaml不包含环境,因此可以被多个环境共享

我们只需将需要被多环境共享的配置放在[spring.application.name].yaml即可

步骤与上面Nacos服务端创建配置文件一致, 只需要ID即文件名使用不带生产环境的即可, 而在微服务这边不用修改配置文件(因为本来就会去读取俩种配置), 只需要多注入一个配置属性值即可

注意:

​ 当nacos、服务本地同时出现相同属性时,优先级有高低之分:

在这里插入图片描述

1.6.4 搭建Nacos集群

Nacos生产环境下一定要部署为集群状态

官方给出的Nacos集群图:

在这里插入图片描述

其中包含3个nacos节点,然后用户请求进来之后到达负载均衡器, 一个负载均衡器代理3个Nacos。这里负载均衡器可以使用nginx

我们计划的集群结构:

在这里插入图片描述

用户请求进来之后由Nginx负载均衡分发到不同的Nacos节点, 接着为了让Nacos集群之间能够完成数据共享(之前数据隔离的是微服务, 而Nacos作为配置中心与注册中心需要数据共享), 我们又搭建了一个MySQL集群, 让多个Nacos都来访问这个MySQL集群完成数据共享

综上所述, 搭建集群的基本步骤:

  • 搭建数据库,初始化数据库表结构
  • 下载nacos安装包
  • 配置nacos
  • 启动nacos集群
  • nginx反向代理

具体实现后续再说了

2. Feign远程调用

Feign是一个声明式的http客户端,官方地址:https://github.com/OpenFeign/feign, 可以替代RestTemplate完成远程调用, 所谓声明式, 可以参考Spring的声明式事务

先说一下RestTemplate中存在的问题:

  • 可读性差
  • 当参数十分复杂时. URL难以维护
  • 不够优雅

而基于Feign的远程调用可以帮助我们优雅的实现http请求的发送,解决上面提到的问题

2.1 Feign的使用姿势

说Feign的使用之前, 先回顾一下Rest的使用做对比:注册RestTemplate的bean, 在service中书写url再调用RestTemplate的方法发起请求

  1. 导入依赖:
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>
  1. 添加注解:@EnableFeignClients

    在启动类(在配置类可以吗?)添加注解开启Feign的功能(即扫描):

@EnableFeignClients
@SpringBootApplication
public class Application {
	public static void main(String[] args) {
		SpringApplication.run(Application.class, args);
	}
}
  1. 声明Feign的客户端:

    在服务消费者中新建一个接口(可以放在clients包下):

    其中@FeignClient(“userservice”)注解表示指定服务提供者的服务名称

@FeignClient("userservice")
public interface UserClient {
    @GetMapping("/user/{id}")
    User findById(@PathVariable("id") Long id);
}

这个客户端主要是基于SpringMVC的注解来声明远程调用的信息,比如:

  • @FeignClient : 声明服务名称:userservice
  • @GetMapping : 请求方式:GET
  • 请求路径:/user/{id}
  • 请求参数:Long id
  • 返回值类型:User

这就是Feign声明式客户端的特点, 我们只需要将发Http请求的所需信息声明出来就行了, 相当于写了一个controller类型的mapper接口来远程调用

这样,Feign就可以帮助我们发送http请求,无需自己使用RestTemplate来发送了

  1. 最后只需要进行远程调用即可:

    在service中使用@Autowired注解注入上面的UserClient接口

    调用这个接口的对应方法进行远程调用

同时, 在Feign的核心依赖中是集成了Ribbon的, 因此使用Feign进行远程调用是会自动完成负载均衡的

2.2 自定义配置

SpringBoot为我们做了很多默认的配置, 但同时Feign也支持很多的自定义配置,可以覆盖的自定义配置如下表所示:

类型作用说明
feign.Logger.Level修改日志级别包含四种不同的级别:NONE、BASIC、HEADERS、FULL
feign.codec.Decoder响应结果的解析器http远程调用的结果做解析,例如解析json字符串为java对象
feign.codec.Encoder请求参数编码将请求参数编码,便于通过http请求发送
feign. Contract支持的注解格式默认是SpringMVC的注解
feign. Retryer失败重试机制请求失败的重试机制,默认是没有,不过会使用Ribbon的重试

一般情况下,默认值就能满足我们使用,如果要自定义时,只需要创建自定义的@Bean覆盖默认Bean或者在配置文件中覆盖即可

下面以日志为例来演示自定义配置的俩种方式:

2.2.1 方式一:配置文件

基于配置文件修改feign的日志级别可以针对单个服务:

feign:  
  client:
    config: 
      userservice: # 针对某个微服务的配置
        loggerLevel: FULL #  日志级别 

也可以针对所有服务:

feign:  
  client:
    config: 
      default: # 这里用default就是全局配置,如果是写服务名称,则是针对某个微服务的配置
        loggerLevel: FULL #  日志级别 

而日志的级别分为四种:

  • NONE:不记录任何日志信息,这是默认值
  • BASIC:仅记录请求的方法,URL以及响应状态码和执行时间
  • HEADERS:在BASIC的基础上,额外记录了请求和响应的头信息
  • FULL:记录所有请求和响应的明细,包括头信息、请求体、元数据

2.2.2 方式二:代码实现Bean覆盖

方式二是基于Java代码来修改日志级别,先声明一个配置类,然后声明一个Logger.Level的对象:

public class DefaultFeignConfiguration  {
    @Bean
    public Logger.Level feignLogLevel(){
        return Logger.Level.BASIC; // 日志级别为BASIC
    }
}

但是可以看到这段代码我们没有加@Configuration注解, 因此并不会生效, 想要生效还要添加以下注解:

如果要全局生效,将这个类放到启动类的@EnableFeignClients这个注解的defaultConfiguration属性中:

@EnableFeignClients(defaultConfiguration = DefaultFeignConfiguration .class) 

如果是局部生效,则把它放到对应的@FeignClient这个注解中,前面只使用了value属性绑定服务提供者, 现在加上configuration属性绑定配置类:

@FeignClient(value = "userservice", configuration = DefaultFeignConfiguration .class) 

2.3 Feign使用优化

Feign底层发起http请求,依赖于其它的框架。其底层客户端实现包括:

• URLConnection:默认实现,不支持连接池

• Apache HttpClient :支持连接池, Spring底层默认的实现, 版本也已经被SpringBoot管理了

• OKHttp:支持连接池

可以看到默认的实现性能较差, 因此提高Feign的性能主要手段就是使用连接池代替默认的URLConnection

另外日志级别选择BASIC与NONE也会优化性能,毕竟打日志也是会浪费性能的

这里我们用Apache的HttpClient来演示。

1)引入依赖

在order-service的pom文件中引入Apache的HttpClient依赖:

<!--httpClient的依赖 -->
<dependency>
    <groupId>io.github.openfeign</groupId>
    <artifactId>feign-httpclient</artifactId>
</dependency>

2)配置连接池

在order-service的application.yml中添加配置:

feign:
  client:
    config:
      default: # default全局的配置
        loggerLevel: BASIC # 日志级别,BASIC就是基本的请求和响应信息
  httpclient:
    enabled: true # 开启feign对HttpClient的支持
    max-connections: 200 # 最大的连接数
    max-connections-per-route: 50 # 每个路径的最大连接数

总结,Feign的优化:

1.日志级别尽量用basic

2.使用HttpClient或OKHttp代替URLConnection

① 引入feign-httpClient依赖

② 配置文件开启httpClient功能,设置连接池参数

2.4 Feign的最佳使用姿势

观察可以发现,前面写的Feign的客户端与服务提供者的controller代码非常相似

因此我们可以简化这种重复的代码编写

有以下俩种方式:

2.4.1.继承方式

一样的代码可以通过继承来共享:

1)定义一个API接口,利用定义方法,并基于SpringMVC注解做声明。

2)Feign客户端和Controller都改为实现或继承接口

优点:

  • 简单
  • 实现了代码共享

缺点:

  • 服务提供方、服务消费方紧耦合

  • 参数列表中的注解映射并不会继承,因此Controller中必须再次声明方法、参数列表、注解

2.4.2.抽取方式

将Feign的Client抽取为独立模块,并且把接口有关的POJO、默认的Feign配置都放到这个模块中,提供给所有消费者使用。

例如,将UserClient、User、Feign的默认配置都抽取到一个feign-api包中,所有微服务引用该依赖包,即可直接使用。

在这里插入图片描述

2.4.3 抽取实现

  1. 首先创建一个module,命名为feign-api

    在feign-api中然后引入feign的starter依赖

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>
  1. 接着, 将UserClient、User、DefaultFeignConfiguration都复制到feign-api项目

  2. 删除order-service中的UserClient、User、DefaultFeignConfiguration等类或接口

    在消费者的pom文件中中引入feign-api的依赖:

    修改order-service中的所有与上述三个组件有关的导包部分,改成导入feign-api中的包

  3. 指定Feign应该扫描的包(因为feign-api中的包结构可能和调用者不同):

    有俩种方式:

@EnableFeignClients(basePackages = "cn.itcast.feign.clients")

// 或者:

@EnableFeignClients(clients = {UserClient.class})
举报

相关推荐

0 条评论