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

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. 在父工程的中声明SpringCloudAlibaba的依赖：

<dependency>
    <groupId>com.alibaba.cloudgroupId>
    <artifactId>spring-cloud-alibaba-dependenciesartifactId>
    <version>2.2.6.RELEASEversion>
    <type>pomtype>
    <scope>importscope>
dependency>

2. 在需要注册的微服务中引入nacos-discovery依赖：

<dependency>
    <groupId>com.alibaba.cloudgroupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discoveryartifactId>
dependency>

注意：不要忘了注释掉eureka的依赖。

1.1.2 在服务中配置nacos地址

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

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

注意：不要忘了注释掉eureka的地址

最后重启服务, 登录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 # 集群名称

2. 在yml文件中配置负载均衡规则(或者使用配置类):

userservice:
  ribbon:
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则 

1.3 权重配置

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

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

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

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

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

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

注意：如果权重修改为0，则该实例永远不会被访问

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服务端配置

如图:

注意：项目的核心配置，需要热更新的配置才有放到nacos管理的必要。基本不会变更的一些配置还是保存在微服务本地比较好

1.6.1.2 微服务拉取Nacos配置

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

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

项目启动–>读取本地配置文件application.yml–>创建Spring容器–>加载bean

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

项目启动–>读取Nacos配置文件–>与本地配置文件application.yml合并–>创建Spring容器–>加载bean

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

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

项目启动–>读取bootstrap.yaml得到Nacos地址–>读取Nacos配置文件–>与本地配置文件application.yml合并–>创建Spring容器–>加载bean

使用姿势:

1. 引入nacos-config依赖

<dependency>
    <groupId>com.alibaba.cloudgroupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-configartifactId>
dependency>

2. 添加bootstrap.yaml

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

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

这里会根据spring.cloud.nacos.server-addr获取nacos地址，再根据

${spring.application.name}-${spring.profiles.active}.${spring.cloud.nacos.config.file-extension}作为文件id，来读取配置

如图:

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

3. 在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.cloudgroupId>
    <artifactId>spring-cloud-starter-openfeignartifactId>
dependency>

2. 添加注解:@EnableFeignClients

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

@EnableFeignClients
@SpringBootApplication
public class Application {
	public static void main(String[] args) {
		SpringApplication.run(Application.class, args);
	}
}

3. 声明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来发送了

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

   在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依赖：

<dependency>
    <groupId>io.github.openfeigngroupId>
    <artifactId>feign-httpclientartifactId>
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.cloudgroupId>
    <artifactId>spring-cloud-starter-openfeignartifactId>
dependency>

2. 接着, 将UserClient、User、DefaultFeignConfiguration都复制到feign-api项目

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

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

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

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

   有俩种方式:

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

// 或者:

@EnableFeignClients(clients = {UserClient.class})