微服务架构——SpringCloud快速入门_springcloud项目搭建

认识微服务

随着互联网行业的发展，对服务的要求也越来越高，服务架构也从单体架构逐渐演变为现在流行的微服务架构。这些架构之间有怎样的差别呢？

单体架构

将业务的所有功能集中在一个项目中开发，打成一个包部署。

优点：

• 架构简单
• 部署成本低

缺点：

• 耦合度高（维护困难、升级困难）

分布式架构

根据业务功能对系统做拆分，每个业务功能模块作为独立项目开发，称为一个服务。

优点：

• 降低服务耦合
• 有利于服务升级和拓展

缺点：

• 服务调用关系错综复杂

分布式架构虽然降低了服务耦合，但是服务拆分时也有很多问题需要思考：

• 服务拆分的粒度如何界定？
• 服务之间如何调用？
• 服务的调用关系如何管理？

人们需要制定一套行之有效的标准来约束分布式架构。

微服务

微服务的架构特征：

• 单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责
• 自治：团队独立、技术独立、数据独立，独立部署和交付
• 面向服务：服务提供统一标准的接口，与语言和技术无关
• 隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题

微服务的上述特性其实是在给分布式架构制定一个标准，进一步降低服务之间的耦合度，提供服务的独立性和灵活性。做到高内聚，低耦合。

因此，可以认为微服务是一种经过良好架构设计的分布式架构方案 。

但方案该怎么落地？选用什么样的技术栈？全球的互联网公司都在积极尝试自己的微服务落地方案。在国内最知名的就是SpringCloud和阿里巴巴的Dubbo。

微服务技术对比

SpringCloud

• SpringCloud是目前国内使用最广泛的微服务框架。官网地址：https://spring.io/projects/spring-cloud。

• SpringCloud集成了各种微服务功能组件，并基于SpringBoot实现了这些组件的自动装配，从而提供了良好的开箱即用体验：

服务拆分的及远程调用

服务拆分

1. 单一职责：不同微服务，不要重复开发相同业务

2. 数据独立：不要访问其它微服务的数据库，不同微服务都应该有自己独立的数据库

3. 面向服务：将自己的业务暴露为接口，供其它微服务调用

微服务远程调用方式

案例：根据订单id查询订单功能

需求：根据订单id查询订单的同时，把订单所属的用户信息一起返回

远程调用方式分析：

当我们使用浏览器请求数据时，可以直接发起http请求获取到对应的数据。同理，当我们在一个服务中想要获取另一个服务的某些数据，那我们可以用代码来实现发起一个对应的http请求到目标服务获取我们想要的数据。

• 基于RestTemplate发起的http请求实现远程调用

• http请求做远程调用是与语言无关的调用，只要知道对方的ip、端口、接口路径、请求参数即可。

可以在order-service中使用RestTemplate发起HTTP请求，调用user-servise中获取用户信息的接口

@MapperScan("cn.itcast.order.mapper")
@SpringBootApplication
public class OrderApplication {

    public static void main(String[] args) {
        SpringApplication.run(OrderApplication.class, args);
    }

    /**
     * 创建RestTemplate 并注入Spring容器
     * @return 
     */
    @Bean
    public RestTemplate restTemplate(){
        return new RestTemplate();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

@Service
public class OrderService {

    @Autowired
    private OrderMapper orderMapper;
    
    @Autowired
    private RestTemplate restTemplate;

    public Order queryOrderById(Long orderId) {
        // 1.查询订单
        Order order = orderMapper.findById(orderId);
        // 2.发起http请求，查询用户
        String url = "http://localhost:8081/user/" + order.getUserId();
        User user = restTemplate.getForObject(url, User.class);
        // 3.封装user到order
        order.setUser(user);
        // 4.返回
        return order;
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

Eureka注册中心

服务调用存在的问题

• 服务消费者该如何获取服务提供者的地址信息？

• 如果有多个服务提供者，消费者该如何选择？

• 消费者如何得知服务提供者的健康状态？

Eureka的作用

针对上面几个问题，eureka给出了答案：

• 服务消费者该如何获取服务提供者的地址信息？

  1. 服务提供者启动时向eureka注册自己的信息
  2. eureka保存这些信息
  3. 消费者根据服务名称向eureka拉取提供者信息

• 如果有多个服务提供者，消费者该如何选择？

  • 服务消费者利用负载均衡算法，从服务列表中挑选一个

• 消费者如何得知服务提供者的健康状态？

  1. 服务提供者会每隔30秒向EurekaServer发送心跳请求，报告健康状态
  2. eureka会更新记录服务列表信息，心跳不正常会被剔除
  3. 消费者就可以拉取到最新的信息

在Eureka架构中，微服务角色有两类：

• EurekaServer：服务端，注册中心

  • 记录服务信息
  • 心跳监控

• EurekaClient：客户端

  • Provider：服务提供者，例如案例中的 user-service

    • 注册自己的信息到EurekaServer

    • 每隔30秒向EurekaServer发送心跳

  • consumer：服务消费者，例如案例中的 order-service

    • 根据服务名称从EurekaServer拉取服务列表

    • 基于服务列表做负载均衡，选中一个微服务后发起远程调用

使用Eureka

搭建EurekaServer

搭建EurekaServer服务步骤如下：

1. 创建项目，引入spring-cloud-starter-netflix-eureka-server的依赖

   <dependency>
       <groupId>org.springframework.cloud</groupId>
       <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
   </dependency>
   1
   2
   3
   4

2. 在启动类添加@EnableEurekaServer注解

3. 添加application.yml文件，编写下面的配置：

   server:
     port: 10086   #服务端口
   spring:
     application:
       name: eureka-server   #服务名称
   eureka:
     client:
       service-url:  # eureka自己的地址信息，之后如果做eureka集群需要用到
         defaultZone: http://127.0.0.1:10086/eureka/
   1
   2
   3
   4
   5
   6
   7
   8
   9

注册user-service

将user-service服务注册到EurekaServer步骤如下：

1. 在user-service项目引入spring-cloud-starter-netflix-eureka-client的依赖

   <dependency>
       <groupId>org.springframework.cloud</groupId>
       <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
   </dependency>
   1
   2
   3
   4

2. 在application.yml文件，编写下面的配置：

   spring:
     application:
       name: user-service   #服务名称
   eureka:
     client:
       service-url:
         defaultZone: http://127.0.0.1:10086/eureka/
   1
   2
   3
   4
   5
   6
   7

我们可以将user-service多次启动， 模拟多实例部署，但为了避免端口冲突，需要修改端口设置：

order-service完成服务注册

order-service虽然是消费者，但与user-service一样都是eureka的client端，同样可以实现服务注册：

1. 在order-service项目引入spring-cloud-starter-netflix-eureka-client的依赖

2. 在application.yml文件，编写下面的配置：

   spring:
     application:
       name: order-service   #服务名称
   eureka:
     client:
       service-url:
         defaultZone: http://127.0.0.1:10086/eureka/
   1
   2
   3
   4
   5
   6
   7

在order-service完成服务拉取

服务拉取是基于服务名称获取服务列表，然后在对服务列表做负载均衡

1. 修改OrderService的代码，修改访问的url路径，用服务名代替ip、端口：

   // 2.发起http请求，查询用户
   // String url = "http://localhost:8081/user/" + order.getUserId();
   String url = "http://user-service/user/" + order.getUserId();
   1
   2
   3

2. 在order-service项目的启动类OrderApplication中的RestTemplate添加负载均衡注解：

   @Bean
   @LoadBalanced   // 负载均衡
   public RestTemplate restTemplate(){
       return new RestTemplate();
   }
   1
   2
   3
   4
   5

Ribbon负载均衡

ribbon实现负载均衡的基本流程：当order-service发起请求后，ribbon会拦截处理请求（到eureka-server根据服务名称获取服务列表，根据负载均衡策略选择出一个服务），对选择出的服务发起请求。

负载均衡原理

负载均衡策略

Ribbon的负载均衡规则是一个叫做IRule的接口来定义的，每一个子接口都是一种规则，默认实现是ZoneAvoidanceRule，根据zone选择服务列表，然后轮询

通过定义IRule实现可以修改负载均衡规则，有两种方式：

1. 代码发布方式：在order-service中的OrderApplication类中，定义一个新的IRule：

   /**
    * @return 配置负载均衡的方式为随机
    */
   @Bean
   public IRule RandomRule(){
       return new RandomRule();
   }
   1
   2
   3
   4
   5
   6
   7

   通过这种方式配置的负载均衡规则会作用于全体，即order-service访问任何微服务都将采用这种规则。这种方式配置灵活，但修改时需要重新打包发布

2. 配置文件方式：在order-service的application.yml文件中，添加新的配置也可以修改规则：

   user-service:	#指定服务名称
     ribbon:
       NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule  #负载均衡规则 
   1
   2
   3

   配置文件方式配置的规则则只会作用于指定的微服务。这种方式直观，方便，无需重新打包发布，但是无法做全局配置。

懒加载与饥饿加载

Ribbon默认是采用懒加载，即第一次访问时才会去创建LoadBalanceClient，所以会导致第一次请求时间很长。

而饥饿加载则会在项目启动时创建LoadBalanceClient，降低第一次访问的耗时，可以通过下面配置开启饥饿加载：

ribbon:
  eager-load:
    clients: 	#指定对user-service这个服务饥饿加载，可以指定多个service
      - user-service
      - xx-service
    enabled: true	#开启饥饿加载
1
2
3
4
5
6

Nacos注册中心

Nacos是阿里巴巴的产品，现在是SpringCloud中的一个组件。相比Eureka功能更加丰富，在国内受欢迎程度较高。

服务注册到Nacos

1. 在cloud-demo父工程中添加spring-cloud-alilbaba的管理依赖：

   <!--nacos的管理依赖-->
   <dependency>
       <groupId>com.alibaba.cloud</groupId>
       <artifactId>spring-cloud-alibaba-dependencies</artifactId>
       <version>2.2.9.RELEASE</version>
       <type>pom</type>
       <scope>import</scope>
   </dependency>
   1
   2
   3
   4
   5
   6
   7
   8

2. 注释掉order-service和user-service中原有的eureka依赖。

3. 添加nacos的客户端依赖：

   <dependency>
       <groupId>com.alibaba.cloud</groupId>
       <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
   </dependency>
   1
   2
   3
   4

4. 修改user-service&order-service中的application.yml文件，注释eureka地址，添加nacos地址：

   spring: 
     cloud:
       nacos:
         server-addr: localhost:8848   #nacos服务地址
   1
   2
   3
   4

5. 启动并测试

   

Nacos服务分级存储模型

Nacos服务分级存储模型

1. 一级是服务，例如user-service
2. 二级是集群，例如杭州或上海
3. 三级是实例，例如杭州机房的某台部署了user-service的服务器

服务跨集群调用问题

如果杭州集群的order-service想要访问user-service，那么他可以选择访问杭州的user-service或者上海的user-service，显然访问同一集群的访问效率会更高。

所以服务调用应该尽可能选择本地集群的服务，跨越集群调用的延迟较高。当本地集群不可用时，再去访问其他集群。

服务集群属性配置

修改application.yml文件，添加spring.cloud.nacos.discovery.cluster-name属性：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848   #nacos服务地址
      discovery:
        cluster-name: HZ  #配置集群名称，也就是机房位置，例如：HZ，杭州
1
2
3
4
5
6

我们将user-service和order-service的集群分别设置为SH和HZ，可以在nacos的管理页面看到以下信息：

根据集群负载均衡

NacosRule负载均衡策略

1. 优先选择同集群服务实例列表
2. 本地集群找不到提供者，才去其它集群寻找，并且会报警告
3. 确定了可用实例列表后，再采用随机负载均衡挑选实例

在服务中设置负载均衡的IRule为NacosRule，优先寻找与自己同集群的服务：

user-service: #指定服务名称
  ribbon:
#    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule  #负载均衡规则
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule  #Nacos负载均衡规则
1
2
3
4

根据权重负载均衡

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

服务器设备性能有差异，部分实例所在机器性能较好，另一些较差，我们希望性能好的机器承担更多的用户请求。Nacos提供了权重配置来控制访问频率，权重越大则访问频率越高：

实例的权重控制

1. Nacos控制台可以设置实例的权重值，0~1之间
2. 同集群内的多个实例，权重越高被访问的频率越高
3. 权重设置为0则完全不会被访问（比如线上版本更新的时候就可以用到）

环境隔离——namespace

Nacos中服务存储和数据存储的最外层都是一个名为namespace的东西，用来做最外层隔离。比如我们开发、测试、生产就应该是不同的namepace，而一些业务相关度比较高的就可以放在一个group。

• 每个namespace都有唯一id
• 服务设置namespace时要写id而不是名称
• 不同namespace下的服务互相不可见

nacos默认是一个名为public的命名空间，现在我们在这里新建一个dve开发环境：

修改order-service的application.yml，添加namespace：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848   #nacos服务地址
      discovery:
        cluster-name: HZ  #配置集群名称，也就是机房位置，例如：HZ，杭州
        namespace: f15cf64a-74e6-4f4e-9e23-1d6ba3047c8f		#命名空间的ID
1
2
3
4
5
6
7

重启order-service之后就可以在服务列表的dev环境看到order-service:

此时访问order-service，因为namespace不同，会导致找不到user-service，控制台会报错。

Nacos注册中心细节分析

Nacos与eureka的共同点

• 都支持服务注册和服务拉取
• 都支持服务提供者心跳方式做健康检测

Nacos与Eureka的区别

• Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
• 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
• Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
• Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式。（A：可用性，C：一致性，P：分区容错性）

临时实例和非临时实例

服务注册到Nacos时，可以选择注册为临时或非临时实例，通过下面的配置来设置：

spring.cloud.nacos.discovery.ephemeral: false  #设置为非临时实例
1

临时实例宕机时，会从nacos的服务列表中剔除，而非临时实例则不会

Nacos配置管理

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

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

统一配置管理

在Nacos中添加配置文件

注意：不是所有的配置都适合放到配置中心，维护起来比较麻烦，一般来讲只有项目的核心配置、需要热更新的配置才有放到nacos管理的必要。基本不会变更的一些配置还是保存在微服务本地比较好。

微服务拉取配置

微服务要拉取nacos中管理的配置，并且与本地的application.yml配置合并，才能完成项目启动。但如果尚未读取application.yml，又如何得知nacos地址呢？

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

1. 引入Nacos的配置管理客户端依赖：

   在user-service服务中，引入nacos-config的客户端依赖：

   <!--nacos配置管理依赖-->
   <dependency>
       <groupId>com.alibaba.cloud</groupId>
       <artifactId>spring-cloud-alibaba-nacos-config</artifactId>
       <version>2.1.1.RELEASE</version>
   </dependency>
   1
   2
   3
   4
   5
   6

2. 添加bootstrap.yaml：

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

   spring:
     application:
       name: user-service # 服务名称
     profiles:
       active: dev #开发环境，这里是dev 
     cloud:
       nacos:
         server-addr: localhost:8848 # Nacos地址
         config:
           file-extension: yaml # 文件后缀名
           namespace: f15cf64a-74e6-4f4e-9e23-1d6ba3047c8f	#这里注意，因为我们的的config是放在dev这个命名空间下的，所以这里要指定config的命名空间，不然会拉取不到
   1
   2
   3
   4
   5
   6
   7
   8
   9
   10
   11

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

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

3. 读取nacos配置

   在user-service中的UserController中添加业务逻辑，读取pattern.dateformat配置：

   @Slf4j
   @RestController
   @RequestMapping("/user")
   public class UserController {
   
       @Value("${pattern.dateformat}")
       private String dateFormat;
       
       @GetMapping("/now")
       public String getTime(){
           return LocalDateTime.now().format(DateTimeFormatter.ofPattern(dateFormat));
       }
   }
   1
   2
   3
   4
   5
   6
   7
   8
   9
   10
   11
   12
   13

   访问页面可以看到效果：

   

总结下来将配置交给Nacos管理的步骤：

1. 在Nacos中添加配置文件
2. 在微服务中引入nacos的config依赖
3. 在微服务中添加bootstrap.yml，配置nacos地址、当前环境、服务名称、文件后缀名。这些决定了程序启动时去nacos读取哪个文件

配置热更新

所谓的配置热更新，也就是修改nacos中的配置后，微服务中无需重启即可让配置生效。

有以下两种配置方式可以实现热更新：

@RefreshScope

通过@Value注解注入配置，结合@RefreshScope注解来刷新配置，在@Value注入变量的类上使用注解@RefreshScope:

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

    @Value("${pattern.dateformat}")
    private String dateFormat;
    
    @GetMapping("/now")
    public String getTime(){
        return LocalDateTime.now().format(DateTimeFormatter.ofPattern(dateFormat));
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

@ConfigurationProperties

使用@ConfigurationProperties注解代替@Value注解实现自动刷新，在user-service服务中，添加一个类，用来读取patterrn.dateformat属性：

@Component
@Data
@ConfigurationProperties(prefix = "pattern")
public class PatternProperties {
    private String dateformat;
}
1
2
3
4
5
6

在UserController中使用PatternProperties这个类来获取属性：

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

    @Autowired
    private UserService userService;

    // @Value("${pattern.dateformat}")
    // private String dateFormat;

    @Autowired
    private PatternProperties patternProperties;

    @GetMapping("/now")
    public String getTime(){
        return LocalDateTime.now().format(DateTimeFormatter.ofPattern(patternProperties.getDateformat()));
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

配置共享

多环境共享

微服务启动时会从nacos读取前缀为服务名的多个配置文件：

1. [服务名]-[spring.profile.active].yaml，环境配置，如user-service-dev.yaml
2. [服务名].yaml，默认配置，多环境共享，如user-serviceyaml，一些与运行环境无关的通用配置不需要在每一个配置文件中都写一遍，就可以写在这里

新建的user-service.yaml配置文件中的内容：

pattern:
  envSharedValue: 共享属性值
1
2

在PatternProperties类中获取属性envSharedValue:

@Component
@Data
@ConfigurationProperties(prefix = "pattern")
public class PatternProperties {
    private String dateformat;
    private String envSharedValue;
}
1
2
3
4
5
6
7

UserController中新增一个prop接口，用来测试属性值的获取：

@GetMapping("/prop")
public PatternProperties getProp(){
    return patternProperties;
}
1
2
3
4

现在我们在8081和8082端口分别启动一个user-service，其中8081的环境为dev,8082的环境为sit，调用/user/prop分别可以看到以下返回情况：

我们可以看到环境为dev的user-service同时获取到了user-service-dev.yaml和user-service.yaml配置文件中的内容，而环境为sit的user-service只获取到了user-service.yaml配置文件的内容。显然user-service.yaml是被user-service服务在不同环境下所共享的。

当同一个属性出现在多个配置文件中的时候，配置属性的优先级为：[服务名]-[环境].yaml >[服务名].yaml > 本地配置

多服务共享配置

通过以上的例子我们知道了一个服务在多环境下可以共享配置文件，其实nacos中不同为服务之间也可以共享配置文件，主要可以通过配置ext-config或shared-dataids这两种方式实现：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848 # Nacos地址
      config:
        file-extension: yaml # 文件后缀名
        namespace: f15cf64a-74e6-4f4e-9e23-1d6ba3047c8f
        ext-config:	#多微服务间共享的配置列表
          - data-id: extend.yaml	#要共享的配置文件id
        shared-dataids:	#多微服务间共享的配置列表
          common.yaml	#要共享的配置文件id
1
2
3
4
5
6
7
8
9
10
11

我们在nacos在新增extend.yaml和common.yaml这两个配置文件，并且在bootstrap.yaml中完成以上两个配置后，启动user-service，在控制台可以看到：

说明user-service服务成功读取到了新增的两个配置文件，跟上面的多环境配置不同的是，这两个文件的读取和服务名称是无关的，只需要在bootstrap.yaml中指定他的id就能读取到，所以我们在其他的微服务中也可以通过配置ext-config或shared-dataids属性指定要读取的配置文件即可，从而实现了多服务共享配置。

多种配置的优先级：环境配置 >服务名.yaml > ext-config > shared-datdaids > 本地配置

搭建Nacos集群

集群结构图

nacos官方给出的Nacos集群搭建图：

其中包含3个nacos节点，一个负载均衡器（SLB）代理3个Nacos，这里负载均衡器可以使用nginx。

准备三个nacos节点的地址：

集群搭建步骤

1. 搭建数据库，初始化数据库表结构
2. 配置nacos
3. 启动nacos集群
4. nginx反向代理

初始化数据库

在本地新建一个nacos-config的数据库，将nacos安装目录下conf文件夹下的mysql-schema.sql在新建的数据库中运行一下

运行之后的会得到以下这样几张表：

将conf目录下的cluster.conf.example，重命名为cluster.conf，并添加我们nacos的ip地址：

#
# Copyright 1999-2021 Alibaba Group Holding Ltd.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#

#it is ip
#example
127.0.0.1:8845
127.0.0.1.8846
127.0.0.1.8847
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

配置nacos

然后在application.properties文件中添加数据库配置，一般文件里都是有这一部分内容的，只不过是被注释掉了，找到改成自己的数据库配置就好了。

启动

将nacos文件夹赋三份，分别命名为nacos1，nacos2，nacos3，分别修改三个文件夹的application.properties：

#nacos1
server.port=8845
1
2

#nacos2
server.port=8846
1
2

#nacos3
server.port=8847
1
2

然后分别启动三个nacos节点。

nginx反向代理

修改nginx安装目录下的conf/nginx.conf文件

添加如下配置：

upstream nacos-cluster {
    server 127.0.0.1:8845;
	server 127.0.0.1:8846;
	server 127.0.0.1:8847;
}

server {
    listen       80;
    server_name  localhost;

    location /nacos {
        proxy_pass http://nacos-cluster;
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

而后在浏览器访问：http://localhost/nacos即可。再把application.yml文件的nacos地址改为localhost:80，启动服务就能在nacos的服务列表找到新启动的服务了。

• 实际部署时，需要给做反向代理的nginx服务器设置一个域名，这样后续如果有服务器迁移nacos的客户端也无需更改配置.

• Nacos的各个节点应该部署到多个不同服务器，做好容灾和隔离

Feign远程调用

Feign替代RestTemplate

RestTemplate方式调用存在的问题

先来看我们以前利用RestTemplate发起远程调用的代码：

String url = "http://user-service/user/" + order.getUserId();
User user = restTemplate.getForObject(url, User.class);
1
2

存在问题：

• 代码可读性差，编程体验不统一

• 参数复杂URL难以维护

Feign介绍

Feign是一个声明式的http客户端，官方地址：https://github.com/OpenFeign/feign，其作用就是帮助我们优雅的实现http请求的发送，解决上面提到的问题，并且Feign集成了Ribbon自动实现负载均衡。

定义和使用Feign客户端

1. 引入依赖

   <dependency>
       <groupId>org.springframework.cloud</groupId>
       <artifactId>spring-cloud-starter-openfeign</artifactId>
   </dependency>
   1
   2
   3
   4

2. 在order-service的启动类添加@EnableFeignClients注解开启Feign的功能：

3. 编写FeignClient接口

   @FeignClient("user-service")
   public interface UserClient {
       @GetMapping("/user/{id}")
       User findById(@PathVariable("id") Long id);
   }
   1
   2
   3
   4
   5

   UserClient主要是基于SpringMVC的注解来声明远程调用的信息：

   • 服务名称：user-service
   • 请求方式：GET
   • 请求路径：/user/{id}
   • 请求参数：Long id
   • 返回值类型：User

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

4. 用FeignClient中定义的方法代替RestTemplate

   @Service
   public class OrderService {
   
       @Autowired
       private OrderMapper orderMapper;
   
       // @Autowired
       // private RestTemplate restTemplate;
       
       @Autowired
       private UserClient userClient;
   
       public Order queryOrderById(Long orderId) {
           // 1.查询订单
           Order order = orderMapper.findById(orderId);
           // 2.发起http请求，查询用户
           // String url = "http://localhost:8081/user/" + order.getUserId();
           //使用RestTemplate发起远程调用：
           // String url = "http://user-service/user/" + order.getUserId();
           // User user = restTemplate.getForObject(url, User.class);
           //使用Feign远程调用：
           User user = userClient.findById(orderId);
           // 3.封装user到order
           order.setUser(user);
           // 4.返回
           return order;
       }
   }
   1
   2
   3
   4
   5
   6
   7
   8
   9
   10
   11
   12
   13
   14
   15
   16
   17
   18
   19
   20
   21
   22
   23
   24
   25
   26
   27
   28

测试可以成功获取到数据：

自定义配置

SpringBoot帮我们实现了自动装配，但是也允许Feign运行自定义配置来覆盖默认配置，可以修改的配置如下：

一般情况下，默认值就能满足我们使用，如果要自定义时，只需要创建自定义的@Bean覆盖默认的Bean即可。下面以日志为例来演示如何自定义配置。

日志的级别分为四种：

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

配置Feign日志有两种方式：

方式一：配置文件方式

feign:
  client:
    config:
      default: #用default就是全局配置
#     user-service: 这里写服务名称就是对某个指定的微服务生效
        loggerLevel: FULL #日志级别
1
2
3
4
5
6

方式二：Java代码方式

先声明一个类，然后声明一个Logger.Level的对象：

public class DefaultFeignConfig {
    @Bean
    public Logger.Level feignLogLevel(){
        return Logger.Level.BASIC; // 日志级别为BASIC
    }
}
1
2
3
4
5
6

如果要全局生效，将其放到启动类的@EnableFeignClients这个注解中：

@EnableFeignClients(defaultConfiguration = DefaultFeignConfig.class) 
1

如果是局部生效，则把它放到指定的@FeignClient这个注解中：

@FeignClient(value = "user-service", configuration = DefaultFeignConfig.class) 
1

Feign优化配置

Feign底层的客户端实现：

• URLConnection：默认实现，不支持连接池
• Apache HttpClient ：支持连接池
• OKHttp：支持连接池

因此优化Feign的性能主要包括：

1. 使用连接池代替默认的URLConnection
2. 日志级别，最好用basic或none

连接池配置

例：Feign添加HttpClient的支持。

引入依赖：

<!--httpClient依赖-->
<dependency>
    <groupId>io.github.openfeign</groupId>
    <artifactId>feign-httpclient</artifactId>
</dependency>
1
2
3
4
5

配置连接池：

feign:
  httpclient:
    enabled: true   #支持httpClient
    max-connections: 200  #最大连接数
    max-connections-per-route: 50   #单个路径的最大连接数
1
2
3
4
5

最佳实践

观察我们之前的代码可以发现，Feign的客户端与服务提供者的controller代码非常相似：

@FeignClient(value = "user-service", configuration = DefaultFeignConfig.class)
public interface UserClient {
    @GetMapping("/user/{id}")
    User findById(@PathVariable("id") Long id);
}
1
2
3
4
5

@GetMapping("/user/{id}")
public User queryById(@PathVariable("id") Long id) {
    return userService.queryById(id);
}
1
2
3
4

都包含接口请求方式、请求路径、请求参数这三部分。那么有什么办法可以把这部分抽取出来呢？

方式一（继承）

给消费者的FeignClient和提供者的controller定义统一的父接口作为标准。

不过一般我们不推荐这种客户端和服务端之间共享接口的方式，主要有以下两点原因：

• 服务紧耦合
• 父接口参数列表中的映射不会被继承，因此Controller中必须再次声明方法、参数列表、注解

方式二（抽取）

方式二（抽取）：将FeignClient抽取为独立模块，并且把接口有关的POJO、默认的Feign配置都放到这个模块中，提供给所有消费者使用

步骤如下：

1. 首先创建一个module，命名为feign-api，然后引入feign的starter依赖

2. 将order-service中编写的UserClient、User、DefaultFeignConfiguration都复制到feign-api项目中

   

3. 在order-service中引入feign-api的依赖

   <!--引入我们自己写的feign-api-->
   <dependency>
       <groupId>cn.itcast.demo</groupId>
       <artifactId>feign-api</artifactId>
       <version>1.0</version>
   </dependency>
   1
   2
   3
   4
   5
   6

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

5. 重启测试…然后重启失败

   

   原因是当定义的FeignClient不在SpringBootApplication的扫描包范围时，这些FeignClient无法使用。有两种方式解决：

   方式一：指定FeignClient所在包，这种方法会把指定包下面的所有Client都加载进来

   @EnableFeignClients(basePackages = "cn.itcast.demo.client")
   1

   方式二：指定FeignClient字节码，这种方法只会加载指定的Client

   @EnableFeignClients(clients = {UserClient.class})
   1

Gateway网关

Spring Cloud Gateway 是 Spring Cloud 的一个全新项目，该项目是基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等响应式编程和事件流技术开发的网关，它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。

为什么需要网关？

最简单的例子，有的时候我们不希望一些没有权限的请求访问到我们的微服务，这个时候就可以用网关来进行身份认证。Gateway网关是我们服务的守门神，所有微服务的统一入口。

网关的核心功能特性：

• 请求路由：将用户请求路由到微服务，并实现负载均衡
• 权限控制：对用户请求做身份认证、权限校验
• 限流：控制流量

权限控制：网关作为微服务入口，需要校验用户是是否有请求资格，如果没有则进行拦截。

路由和负载均衡：一切请求都必须先经过gateway，但网关不处理业务，而是根据某种规则，把请求转发到某个微服务，这个过程叫做路由。当然路由的目标服务有多个时，还需要做负载均衡。

限流：当请求流量过高时，在网关中按照下流的微服务能够接受的速度来放行请求，避免服务压力过大。

网关技术的实现

在SpringCloud中网关的实现包括两种：

• gateway
• zuul

Zuul是基于Servlet的实现，属于阻塞式编程。而SpringCloud Gateway则是基于Spring5中提供的WebFlux，属于响应式编程的实现，具备更好的性能。

Gateway网关快速入门

下面，我们就看一下网关的基本路由功能。基本步骤如下：

1. 创建SpringBoot工程gateway，引入网关依赖

   <!--网关-->
   <dependency>
       <groupId>org.springframework.cloud</groupId>
       <artifactId>spring-cloud-starter-gateway</artifactId>
   </dependency>
   <!--nacos服务发现依赖-->
   <dependency>
       <groupId>com.alibaba.cloud</groupId>
       <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
   </dependency>
   1
   2
   3
   4
   5
   6
   7
   8
   9
   10

2. 编写GatewayApplication.java启动类

3. 编写application.yml基础配置和路由规则

   路由配置包括：

   1. 路由id：路由的唯一标示

   2. 路由目标（uri）：路由的目标地址，http代表固定地址，lb代表根据服务名负载均衡

   3. 路由断言（predicates）：判断路由的规则，如果请求不符合这个规则会404

   4. 路由过滤器（filters）：对请求或响应做处理

   server:
     port: 10010 # 网关端口
   spring:
     application: 
       name: gateway # 服务名称
     cloud:
       nacos:
         server-addr: localhost:8848 # nacos地址
       gateway:
         routes: # 网关路由配置
           - id: user-service # 路由id，自定义，只要唯一即可
             # uri: http://127.0.0.1:8081 # 路由的目标地址 http就是固定地址
             uri: lb://user-service # 路由的目标地址 lb就是负载均衡，后面跟服务名称
             predicates: # 路由断言，也就是判断请求是否符合路由规则的条件
               - Path=/user/** # 这个是按照路径匹配，只要以/user/开头就符合要求
   1
   2
   3
   4
   5
   6
   7
   8
   9
   10
   11
   12
   13
   14
   15

4. 启动网关服务进行测试

   直接访问10010端口即可访问到user-service服务：

   

整个访问的流程如下：

断言工厂Route Predicate Factory

我们在配置文件中写的断言规则只是字符串，这些字符串会被Predicate Factory读取并处理，转变为路由判断的条件。例如Path=/user/**是按照路径匹配，这个规则是由org.springframework.cloud.gateway.handler.predicate.PathRoutePredicateFactory类来处理的，像这样的断言工厂在SpringCloud Gateway还有十几个。

当我们需要用到这些Predicate Factory的时候可以直接去查看官方文档：https://docs.spring.io/spring-cloud-gateway/docs/current/reference/html/#gateway-request-predicates-factories

过滤器工厂

过滤器的作用是什么？

1. 对路由的请求或响应做加工处理，比如添加请求头
2. 配置在路由下的过滤器只对当前路由的请求生效

GatewayFilter是网关中提供的一种过滤器，可以对进入网关的请求和微服务返回的响应做处理：

Spring提供了31种不同的路由过滤器工厂。例如：

下面我们以AddRequestHeader 为例来讲解。

需求：给所有进入user-service的请求添加一个请求头：Truth=itcast is freaking awesome!

实现方式：在gateway中修改application.yml文件，给user-service的路由添加过滤器：

spring:
  cloud:
    gateway:
      routes:
      - id: user-service 
        uri: lb://user-service 
        predicates: 
        - Path=/user/** 
        filters: #过滤器
        - AddRequestHeader=Hello Gateway! #添加请求头
1
2
3
4
5
6
7
8
9
10

当前过滤器写在user-service路由下，因此仅仅对访问user-service的请求有效。

如果要对所有的路由都生效，则可以将过滤器工厂写到default-filters下：

spring:
  cloud:
    gateway:
      routes: # 网关路由配置
        - id: user-service
          uri: lb://user-service
          predicates:
            - Path=/user/** 
#          filters: #过滤器
#            - AddRequestHeader=Truth, Hello Gateway! #添加请求头
        - id: order-service
          uri: lb://order-service
          predicates:
            - Path=/order/**
      default-filters:
        - AddRequestHeader=Hello Gateway!
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

全局过滤器GlobalFilter

上面学习的过滤器，网关提供了31种，但每一种过滤器的作用都是固定的。如果我们希望拦截请求，做自己的业务逻辑则没办法实现。

全局过滤器的作用也是处理一切进入网关的请求和微服务响应，与GatewayFilter的作用一样。区别在于GatewayFilter通过配置定义，处理逻辑是固定的；而GlobalFilter的逻辑需要自己写代码实现。定义方式是实现GlobalFilter接口。

public interface GlobalFilter {
    /**
     *  处理当前请求，有必要的话通过{@link GatewayFilterChain}将请求交给下一个过滤器处理
     *
     * @param exchange 请求上下文，里面可以获取Request、Response等信息
     * @param chain 用来把请求委托给下一个过滤器 
     * @return {@code Mono<Void>} 返回标示当前过滤器业务结束
     */
    Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain);
}
1
2
3
4
5
6
7
8
9
10

在filter中编写自定义逻辑，可以实现下列功能：

• 登录状态判断
• 权限校验
• 请求限流等

案例：定义全局过滤器，拦截请求，判断请求的参数是否满足下面条件：

1. 参数中是否有authorization
2. authorization参数值是否为admin

如果同时满足则放行，否则拦截

package com.itcast.gateway.filter;

import org.springframework.cloud.gateway.filter.GatewayFilterChain;
import org.springframework.cloud.gateway.filter.GlobalFilter;
import org.springframework.core.Ordered;
import org.springframework.core.annotation.Order;
import org.springframework.http.HttpStatus;
import org.springframework.http.server.reactive.ServerHttpRequest;
import org.springframework.http.server.reactive.ServerHttpResponse;
import org.springframework.stereotype.Component;
import org.springframework.util.MultiValueMap;
import org.springframework.web.server.ServerWebExchange;
import reactor.core.publisher.Mono;

/**
 * @title: AuthorizeFilter
 * @Author 
 * @Date: 2023/4/9 19:46
 * @Version 1.0
 */
@Component
// @Order(-1)  // order的值越小，优先级越高，也可以通过实现Ordered接口来设置优先级
public class AuthorizeFilter implements GlobalFilter, Ordered {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        // 1.获取请求参数
        ServerHttpRequest request = exchange.getRequest();
        MultiValueMap<String, String> queryParams = request.getQueryParams();
        // 2.获取authorization参数
        String authorization = queryParams.getFirst("authorization");
        // 3.判断参数值是否等于admin
        if ("admin".equals(authorization)) {
            // 4.是，放行
            return chain.filter(exchange);
        }
        // 5.否，拦截
        ServerHttpResponse response = exchange.getResponse();
        response.setStatusCode(HttpStatus.UNAUTHORIZED);
        return response.setComplete();
    }

    @Override
    public int getOrder() {
        return -1;
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46

测试：

过滤器的执行顺序

请求进入网关会碰到三类过滤器：当前路由的过滤器、DefaultFilter、GlobalFilter。请求路由后，会将当前路由过滤器和DefaultFilter、GlobalFilter，合并到一个过滤器链（集合）中，排序后依次执行每个过滤器。

排序的规则是什么呢？

• 每一个过滤器都必须指定一个int类型的order值，order值越小，优先级越高，执行顺序越靠前。
• GlobalFilter通过实现Ordered接口，或者添加@Order注解来指定order值，由我们自己指定
• 路由过滤器和defaultFilter的order由Spring指定，默认是按照声明顺序从1递增。
• 当过滤器的order值一样时，会按照 defaultFilter > 路由过滤器 > GlobalFilter的顺序执行。

详细内容，可以查看源码：

org.springframework.cloud.gateway.route.RouteDefinitionRouteLocator#getFilters()方法是先加载defaultFilters，然后再加载某个route的filters，然后合并。org.springframework.cloud.gateway.handler.FilteringWebHandler#handle()方法会加载全局过滤器，与前面的过滤器合并后根据order排序，组织过滤器链。

跨域问题

什么是跨域问题？

跨域：域名不一致就是跨域，主要包括：

• 域名不同： www.taobao.com 和 www.taobao.org 和 www.jd.com 和 miaosha.jd.com

• 域名相同，端口不同：localhost:8080和localhost8081

跨域问题：浏览器禁止请求的发起者与服务端发生跨域ajax请求，请求被浏览器拦截的问题。

解决方案：CORS

跨域问题处理

在gateway服务的application.yml文件中，添加下面的配置：

spring:
  cloud:
    gateway:
      globalcors: # 全局的跨域处理
        add-to-simple-url-handler-mapping: true # 解决options请求被拦截问题
        corsConfigurations:
          '[/**]':
            allowedOrigins: # 允许哪些网站的跨域请求 
              - "http://localhost:8090"
            allowedMethods: # 允许的跨域ajax的请求方式
              - "GET"
              - "POST"
              - "DELETE"
              - "PUT"
              - "OPTIONS"
            allowedHeaders: "*" # 允许在请求中携带的头信息
            allowCredentials: true # 是否允许携带cookie
            maxAge: 360000 # 这次跨域检测的有效期
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18