SpringCloud学习笔记

自学视频：SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式

1.认识微服务

1.1单体架构

单体架构：将业务的所有功能集中在一个项目中开发，打成一个包部署

优点：

• 架构简单
• 部署成本低

缺点：

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

1.2分布式架构

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

优点：

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

缺点：

• 服务调用关系错综复杂

1.3微服务

微服务的架构特征：

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

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

1.4SpringCloud

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

其中常见的组件包括：

2.服务拆分和远程调用

2.1服务拆分原则

这里我总结了微服务拆分时的几个原则：

• 不同微服务，不要重复开发相同业务
• 微服务数据独立，不要访问其它微服务的数据库
• 微服务可以将自己的业务暴露为接口，供其它微服务调用

2.2服务拆分示例

要求：

• 订单微服务和用户微服务都必须有各自的数据库，相互独立
• 订单服务和用户服务都对外暴露Restful的接口
• 订单服务如果需要查询用户信息，只能调用用户服务的Restful接口，不能查询用户数据

所以订单模块实现查询订单的功能，用户模块实现查询用户信息的功能，当用户要查询订单信息时候，所返回的数据不止有订单数据，还要有用户信息，但是此时用户调用的接口是订单模块的接口，则订单模块要向用户模块发送请求获取用户信息，再整合订单信息一起返回。

2.2.1远程调用实现

订单模块发送请求给用户模块获取用户信息就是远程调用，流程如下：

1. 注册一个RestTemplate的实例到Spring容器

2. 修改order-service服务中的OrderService类中的queryOrderById方法，根据Order对象中的userId查询User

3. 将查询的User填充到Order对象，一起返回

2.2.2注册RestTemplate

首先，我们在order-service服务中的OrderApplication启动类中，注册RestTemplate实例

package cn.itcast.order;

import org.mybatis.spring.annotation.MapperScan;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.annotation.Bean;
import org.springframework.web.client.RestTemplate;

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

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

    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

2.2.3实现远程调用

修改order-service服务中的cn.itcast.order.service包下的OrderService类中的queryOrderById方法：

启动之后访问http://localhost:8080/order/101，则会返回结果

2.3提供者和消费者

在服务关系中，有两种角色：

• 服务提供者：一次业务中，被其它微服务调用的服务。（提供接口给其它微服务）

• 服务消费者：一次业务中，调用其它微服务的服务。（调用其它微服务提供的接口）

• 服务提供者与服务消费者的角色并不是绝对的，而是相对于业务而言。

3.Eureka注册中心

假如我们的服务提供者user-service部署了多个实例，如图：

• order-service在发起远程调用的时候，该如何得知user-service实例的ip地址和端口？

  • 答：order-service和user-service可以在Eureka中注册自己的信息，然后当order-service需要拉取user-service服务的时候，就可以通过Eureka获取到是否有这个user服务。

• 有多个user-service实例地址（多个端口号），order-service调用时该如何选择？

  • 答：order-service从实例列表中利用负载均衡算法选中一个实例地址，向该实例地址发起远程调用

• order-service如何得知某个user-service实例是否依然健康，是不是已经宕机？

  • user-service会每隔一段时间（默认30秒）向eureka-server发起请求，报告自己状态，称为心跳
  • 当超过一定时间没有发送心跳时，eureka-server会认为微服务实例故障，将该实例从服务列表中剔除
  • order-service拉取服务时，就能将故障实例排除了

3.1Eureka微服务角色

3.2搭建注册中心

• 搭建eureka-server

  引入 SpringCloud 为 eureka 提供的 starter 依赖，注意这里是用 server

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

• 编写启动类

  注意要添加一个 @EnableEurekaServer 注解，开启 eureka 的注册中心功能

  import org.springframework.boot.SpringApplication;
  import org.springframework.boot.autoconfigure.SpringBootApplication;
  import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;
  
  @SpringBootApplication
  @EnableEurekaServer
  public class EurekaApplication {
      public static void main(String[] args) {
          SpringApplication.run(EurekaApplication.class, args);
      }
  }
  

• 编写配置文件

  编写一个 application.yml 文件，内容如下：

  server:
    port: 10086 #服务端口
  spring:
    application:
      name: eureka-server #eureka服务名称
  eureka:
    client:
      service-url: 
        defaultZone: http://127.0.0.1:10086/eureka #eureka地址信息
  

  

3.3服务注册

• 将user-service、order-service 都注册到 eureka

1.引入 SpringCloud 为 eureka 提供的 starter 依赖，注意这里是用 client

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

2.在启动类上添加注解**@EnableEurekaClient**

3.在配置类中添加：

spring:
  application:
      #name：orderservice
    name: userservice #注册服务名称
eureka:
  client:
    service-url: #eureka的地址信息
      defaultZone: http:127.0.0.1:10086/eureka

4.如果要使一个服务有多个实例，可以：

重新启动项目之后就可以发现user服务中有两个端口实例：

3.4服务拉取

在 order-service 中完成服务拉取，然后通过负载均衡挑选一个服务，实现远程调用

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

2.给 RestTemplate 这个 Bean 添加一个 @LoadBalanced 注解，用于开启负载均衡。

@Bean
@LoadBalanced
public RestTemplate restTemplate(){
    return new RestTemplate();
}

• spring 会自动帮助我们从 eureka-server 中，根据 userservice 这个服务名称，获取实例列表后去完成负载均衡。

3.5Ribbon负载均衡

我们添加了 @LoadBalanced 注解，即可实现负载均衡功能,SpringCloud 底层提供了一个名为 Ribbon 的组件，来实现负载均衡功能。

• 源码分析：

LoadBalancerInterceptor，这个类会在对 RestTemplate 的请求进行拦截，然后从 Eureka 根据服务 id 获取服务列表，随后利用负载均衡算法得到真实的服务地址信息，替换服务 id。

• 在这个拦截器中intercept() 方法，拦截了用户的 HttpRequest 请求，然后进行：

  • request.getURI()：获取请求uri，即 http://user-service/user/8
  • originalUri.getHost()：获取uri路径的主机名，其实就是服务id user-service
  • this.loadBalancer.execute()：处理服务id，和用户请求
  • this.loadBalancer 是 LoadBalancerClient 类型
  • 然后进入execute() 方法：

  

• 在execute() 方法中：

  • getLoadBalancer(serviceId)：根据服务id获取 ILoadBalancer，而 ILoadBalancer 会拿着服务 id 去 eureka 中获取服务列表。
  • getServer(loadBalancer)：利用内置的负载均衡算法，从服务列表中选择一个。在图中可以看到获取了8082端口的服务

• 在getServer()方法中

• 在chooseServer() 方法中

• 在rule里面

• rule 默认值是一个 RoundRobinRule

• 负载均衡默认使用了轮训算法

3.5.1调用总结

SpringCloud Ribbon 底层采用了一个拦截器，拦截了 RestTemplate 发出的请求，对地址做了修改。

基本流程如下：

• 拦截我们的 RestTemplate 请求 http://userservice/user/1
• RibbonLoadBalancerClient 会从请求url中获取服务名称，也就是 user-service
• DynamicServerListLoadBalancer 根据 user-service 到 eureka 拉取服务列表
• eureka 返回列表，localhost:8081、localhost:8082
• IRule 利用内置负载均衡规则，从列表中选择一个，例如 localhost:8081
• RibbonLoadBalancerClient 修改请求地址，用 localhost:8081 替代 userservice，得到 http://localhost:8081/user/1，发起真实请求

3.5.2 负载均衡策略

负载均衡的规则都定义在 IRule 接口中，而 IRule 有很多不同的实现类：

• 不同规则含义如下：

内置负载均衡规则类	规则描述
RoundRobinRule	简单轮询服务列表来选择服务器。它是Ribbon默认的负载均衡规则。
AvailabilityFilteringRule	对以下两种服务器进行忽略：（1）在默认情况下，这台服务器如果3次连接失败，这台服务器就会被设置为“短路”状态。短路状态将持续30秒，如果再次连接失败，短路的持续时间就会几何级地增加。 （2）并发数过高的服务器。如果一个服务器的并发连接数过高，配置了AvailabilityFilteringRule 规则的客户端也会将其忽略。并发连接数的上限，可以由客户端设置。
WeightedResponseTimeRule	为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重就越小。这个规则会随机选择服务器，这个权重值会影响服务器的选择。
ZoneAvoidanceRule	以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。
BestAvailableRule	忽略那些短路的服务器，并选择并发数较低的服务器。
RandomRule	随机选择一个可用的服务器。
RetryRule	重试机制的选择逻辑

默认的实现就是 ZoneAvoidanceRule，是一种轮询方案。

3.5.3自定义策略

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

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

@Bean
public IRule randomRule(){
    return new RandomRule();//开启随机负载均衡策略
}

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

userservice: # 给某个微服务配置负载均衡规则，这里是userservice服务
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 负载均衡规则

3.5.4饥饿加载

当我们启动 orderservice，第一次访问时，时间消耗会大很多，这是因为 Ribbon 懒加载的机制。

• Ribbon 默认是采用懒加载，即第一次访问时才会去创建 LoadBalanceClient（Ribbon 的客户端），拉取集群地址，所以请求时间会很长

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

ribbon:
  eager-load:
    enabled: true # 开启饥饿加载
    clients: userservice # 项目启动时直接去拉取userservice的集群，多个用","隔开

4.Nacos注册中心

4.1认识和安装Nacos

在Nacos的GitHub页面，提供有下载链接，可以下载编译好的Nacos服务端或者源代码：

GitHub主页：https://github.com/alibaba/nacos

GitHub的Release下载页：https://github.com/alibaba/nacos/releases

将这个包解压到任意非中文目录下:目录说明：

• bin：启动脚本
• conf：配置文件

Nacos的默认端口是8848，如果你电脑上的其它进程占用了8848端口，请先尝试关闭该进程。

如果无法关闭占用8848端口的进程，也可以进入nacos的conf目录，修改配置文件(application.properties)中的端口：

• 下载好之后对安装包进行解压，解压之后的目录是：

  • 进入bin目录：
    

• 可以打开cmd窗口，输入：

  • startup.cmd -m standalone
    

    执行之后在浏览器中输入http://127.0.0.1:8848/nacos即可。

    默认的账号和密码都是nacos。

4.2使用Nacos进行服务注册

Nacos是SpringCloudAlibaba的组件，而SpringCloudAlibaba也遵循SpringCloud中定义的服务注册、服务发现规范。因此使用Nacos和使用Eureka对于微服务来说，并没有太大区别。

主要区别在于：

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

1.引入依赖

在cloud-demo父工程的pom文件中的<dependencyManagement>中引入SpringCloudAlibaba的依赖：

<!--nacos管理依赖-->
<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>

然后在user-service和order-service中的pom文件中注释掉eureka依赖，引入nacos-discovery依赖：

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

2.配置nacos地址

• 在user-service和order-service的application.yml中注释erueka配置，添加nacos地址：

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

4.3服务分级存储模型

一个服务可以有多个实例，这些实例分布于全国各地的不同机房，Nacos就将同一机房内的实例，划分为一个集群。

微服务互相访问时，应该尽可能访问同集群实例，因为本地访问速度更快。当本集群内不可用时，才访问其它集群。

4.4配置集群

修改 user-service 的 application.yml 文件，添加集群配置：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848
      discovery:
        cluster-name: HZ # 集群名称 HZ杭州

重启两个 user-service 实例后，我们再去启动一个上海集群的实例

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

即可在Nacos控制台中查看到两个集群中的实例了。

4.4.1同集群优先负载均衡

默认情况下不能实现根据同集群优先来实现负载均衡。

因此Nacos中提供了一个NacosRule的实现，可以优先从同集群中挑选实例。

• 修改负载均衡规则

修改order-service的application.yml文件，修改负载均衡规则：

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

4.5权重配置

默认情况下NacosRule是同集群内随机挑选，不会考虑机器的性能问题。因此，Nacos提供了权重配置来控制访问频率，权重越大则访问频率越高。在nacos控制台，找到user-service的实例列表，点击编辑，即可修改权重：

编辑实例：

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

4.6环境隔离

Nacos提供了namespace来实现环境隔离功能（对服务进行隔离，而集群则是对服务中的实例进行隔离）。

• nacos中可以有多个namespace
• namespace下可以有group、service等
• 不同namespace之间相互隔离，例如不同namespace的服务互相不可见

4.6.1配置namespace

1.创建namespace：

​ 默认情况下，所有service、data、group都在同一个namespace，名为public

2.点击页面新增按钮，添加一个namespace：

3.填写表单

4.在页面中就可以看到

5.给微服务配置namespace

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

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

这时在启动微服务，该服务就会在另外一个命名空间中的了。

总结：

• 每个namespace都有唯一的id
• 不同的namespace下服务是不可见的（两个命名空间中的服务不能互相调用）

4.7Nacos与Eureka的区别

Nacos的服务实例分为两种类型：

• 临时实例：如果实例宕机超过一定时间，会从服务列表剔除，默认的类型。
• 非临时实例：如果实例宕机，不会从服务列表剔除，也可以叫永久实例。

配置一个服务的永久实例：

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

• Nacos与eureka的共同点
  • 都支持服务注册和服务拉取
  • 都支持服务提供者心跳方式做健康检测
• Nacos与Eureka的区别
  • Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
  • 临时实例心跳不正常会被剔除，非临时实例则不会被剔除
  • Nacos支持服务列表变更的消息推送模式，服务列表更新更及时；eureka之支持定时拉取服务列表所以可能不及时。
  • Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式

5.Nacos配置中心

Nacos除了可以做注册中心，同样可以做配置管理来使用。

5.1统一配置管理

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

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

5.1.1在nacos中添加配置文件

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

5.1.2从微服务中拉取配置

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

如果尚未读取application.yml，又如何得知nacos地址呢？因此spring引入了一种新的配置文件：bootstrap.yaml文件，会在application.yml之前被读取，流程如下：

1.引入nacos-config依赖：

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

<!--nacos配置管理依赖-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>

2.添加bootstrap.yaml

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

spring:
  application:
    name: userservice # 服务名称
  profiles:
    active: dev #开发环境，这里是dev 
  cloud:
    nacos:
      server-addr: localhost:8848 # Nacos地址
      config:
        file-extension: yaml # 文件后缀名
        #因为在上面的在nacos中定义的配置文件是userservice-dev.yaml

3.读取nacos配置

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

测试止呕发现获取到的系统时间是指定的格式，则nacos中配置生效。

5.2配置热更新

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

要实现热更新，可以使用两种方式：

5.2.1方式一使用注解@RefreshScope

通过在@Value注入的变量所在类上添加注解@RefreshScope：

5.2.2方式二@ConfigurationProperties

在user-service服务中，添加一个类，读取patterrn.dateformat属性：

import lombok.Data;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.stereotype.Component;

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

在UserController中使用这个类代替配置中的@Value：

5.3配置共享

微服务启动时，会去nacos读取多个配置文件，如：

• [spring.application.name]-[spring.profiles.active].yaml，例如：userservice-dev.yaml
• [spring.application.name].yaml，例如：userservice.yaml

而[spring.application.name].yaml不包含环境，因此可以被多个环境共享。

1.添加一个环境共享配置

在nacos中添加一个userservice.yaml文件：

2.在user-service中读取共享配置

在user-service服务中，修改PatternProperties类，读取新添加的属性(该属性为配置文件的共享配置)：

在user-service服务中，修改UserController，添加一个方法

3.运行两个UserApplication，使用不同的profile环境

修改UserApplication2这个启动项，改变其profile值

• 修改UserApplication2这个启动项，改变其profile值

• 可以看出来，不管是dev，还是test环境，都读取到了envSharedValue这个属性的值。

4.配置共享的优先级

nacos、服务本地同时出现相同属性时，优先级有高低之分：

5.4搭建Nacos集群

1.集群框架图

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

三个 Nacos 节点的地址

节点	ip	port
nacos1	192.168.150.1	8845
nacos2	192.168.150.1	8846
nacos3	192.168.150.1	8847

5.4.1初始化数据库

Nacos 默认数据存储在内嵌数据库 Derby 中，不属于生产可用的数据库。官方推荐的最佳实践是使用带有主从的高可用数据库集群，主从模式的高可用数据库。这里我们以单点的数据库为例。

首先新建一个数据库，命名为 nacos，而后导入下面的 SQL

CREATE TABLE `config_info` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
  `data_id` varchar(255) NOT NULL COMMENT 'data_id',
  `group_id` varchar(255) DEFAULT NULL,
  `content` longtext NOT NULL COMMENT 'content',
  `md5` varchar(32) DEFAULT NULL COMMENT 'md5',
  `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '修改时间',
  `src_user` text COMMENT 'source user',
  `src_ip` varchar(50) DEFAULT NULL COMMENT 'source ip',
  `app_name` varchar(128) DEFAULT NULL,
  `tenant_id` varchar(128) DEFAULT '' COMMENT '租户字段',
  `c_desc` varchar(256) DEFAULT NULL,
  `c_use` varchar(64) DEFAULT NULL,
  `effect` varchar(64) DEFAULT NULL,
  `type` varchar(64) DEFAULT NULL,
  `c_schema` text,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_configinfo_datagrouptenant` (`data_id`,`group_id`,`tenant_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='config_info';

/******************************************/
/*   数据库全名 = nacos_config   */
/*   表名称 = config_info_aggr   */
/******************************************/
CREATE TABLE `config_info_aggr` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
  `data_id` varchar(255) NOT NULL COMMENT 'data_id',
  `group_id` varchar(255) NOT NULL COMMENT 'group_id',
  `datum_id` varchar(255) NOT NULL COMMENT 'datum_id',
  `content` longtext NOT NULL COMMENT '内容',
  `gmt_modified` datetime NOT NULL COMMENT '修改时间',
  `app_name` varchar(128) DEFAULT NULL,
  `tenant_id` varchar(128) DEFAULT '' COMMENT '租户字段',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_configinfoaggr_datagrouptenantdatum` (`data_id`,`group_id`,`tenant_id`,`datum_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='增加租户字段';


/******************************************/
/*   数据库全名 = nacos_config   */
/*   表名称 = config_info_beta   */
/******************************************/
CREATE TABLE `config_info_beta` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
  `data_id` varchar(255) NOT NULL COMMENT 'data_id',
  `group_id` varchar(128) NOT NULL COMMENT 'group_id',
  `app_name` varchar(128) DEFAULT NULL COMMENT 'app_name',
  `content` longtext NOT NULL COMMENT 'content',
  `beta_ips` varchar(1024) DEFAULT NULL COMMENT 'betaIps',
  `md5` varchar(32) DEFAULT NULL COMMENT 'md5',
  `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '修改时间',
  `src_user` text COMMENT 'source user',
  `src_ip` varchar(50) DEFAULT NULL COMMENT 'source ip',
  `tenant_id` varchar(128) DEFAULT '' COMMENT '租户字段',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_configinfobeta_datagrouptenant` (`data_id`,`group_id`,`tenant_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='config_info_beta';

/******************************************/
/*   数据库全名 = nacos_config   */
/*   表名称 = config_info_tag   */
/******************************************/
CREATE TABLE `config_info_tag` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
  `data_id` varchar(255) NOT NULL COMMENT 'data_id',
  `group_id` varchar(128) NOT NULL COMMENT 'group_id',
  `tenant_id` varchar(128) DEFAULT '' COMMENT 'tenant_id',
  `tag_id` varchar(128) NOT NULL COMMENT 'tag_id',
  `app_name` varchar(128) DEFAULT NULL COMMENT 'app_name',
  `content` longtext NOT NULL COMMENT 'content',
  `md5` varchar(32) DEFAULT NULL COMMENT 'md5',
  `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '修改时间',
  `src_user` text COMMENT 'source user',
  `src_ip` varchar(50) DEFAULT NULL COMMENT 'source ip',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_configinfotag_datagrouptenanttag` (`data_id`,`group_id`,`tenant_id`,`tag_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='config_info_tag';

/******************************************/
/*   数据库全名 = nacos_config   */
/*   表名称 = config_tags_relation   */
/******************************************/
CREATE TABLE `config_tags_relation` (
  `id` bigint(20) NOT NULL COMMENT 'id',
  `tag_name` varchar(128) NOT NULL COMMENT 'tag_name',
  `tag_type` varchar(64) DEFAULT NULL COMMENT 'tag_type',
  `data_id` varchar(255) NOT NULL COMMENT 'data_id',
  `group_id` varchar(128) NOT NULL COMMENT 'group_id',
  `tenant_id` varchar(128) DEFAULT '' COMMENT 'tenant_id',
  `nid` bigint(20) NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`nid`),
  UNIQUE KEY `uk_configtagrelation_configidtag` (`id`,`tag_name`,`tag_type`),
  KEY `idx_tenant_id` (`tenant_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='config_tag_relation';

/******************************************/
/*   数据库全名 = nacos_config   */
/*   表名称 = group_capacity   */
/******************************************/
CREATE TABLE `group_capacity` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键ID',
  `group_id` varchar(128) NOT NULL DEFAULT '' COMMENT 'Group ID，空字符表示整个集群',
  `quota` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '配额，0表示使用默认值',
  `usage` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '使用量',
  `max_size` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '单个配置大小上限，单位为字节，0表示使用默认值',
  `max_aggr_count` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '聚合子配置最大个数，，0表示使用默认值',
  `max_aggr_size` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '单个聚合数据的子配置大小上限，单位为字节，0表示使用默认值',
  `max_history_count` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '最大变更历史数量',
  `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '修改时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_group_id` (`group_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='集群、各Group容量信息表';

/******************************************/
/*   数据库全名 = nacos_config   */
/*   表名称 = his_config_info   */
/******************************************/
CREATE TABLE `his_config_info` (
  `id` bigint(64) unsigned NOT NULL,
  `nid` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `data_id` varchar(255) NOT NULL,
  `group_id` varchar(128) NOT NULL,
  `app_name` varchar(128) DEFAULT NULL COMMENT 'app_name',
  `content` longtext NOT NULL,
  `md5` varchar(32) DEFAULT NULL,
  `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `src_user` text,
  `src_ip` varchar(50) DEFAULT NULL,
  `op_type` char(10) DEFAULT NULL,
  `tenant_id` varchar(128) DEFAULT '' COMMENT '租户字段',
  PRIMARY KEY (`nid`),
  KEY `idx_gmt_create` (`gmt_create`),
  KEY `idx_gmt_modified` (`gmt_modified`),
  KEY `idx_did` (`data_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='多租户改造';


/******************************************/
/*   数据库全名 = nacos_config   */
/*   表名称 = tenant_capacity   */
/******************************************/
CREATE TABLE `tenant_capacity` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键ID',
  `tenant_id` varchar(128) NOT NULL DEFAULT '' COMMENT 'Tenant ID',
  `quota` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '配额，0表示使用默认值',
  `usage` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '使用量',
  `max_size` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '单个配置大小上限，单位为字节，0表示使用默认值',
  `max_aggr_count` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '聚合子配置最大个数',
  `max_aggr_size` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '单个聚合数据的子配置大小上限，单位为字节，0表示使用默认值',
  `max_history_count` int(10) unsigned NOT NULL DEFAULT '0' COMMENT '最大变更历史数量',
  `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '修改时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_tenant_id` (`tenant_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='租户容量信息表';


CREATE TABLE `tenant_info` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'id',
  `kp` varchar(128) NOT NULL COMMENT 'kp',
  `tenant_id` varchar(128) default '' COMMENT 'tenant_id',
  `tenant_name` varchar(128) default '' COMMENT 'tenant_name',
  `tenant_desc` varchar(256) DEFAULT NULL COMMENT 'tenant_desc',
  `create_source` varchar(32) DEFAULT NULL COMMENT 'create_source',
  `gmt_create` bigint(20) NOT NULL COMMENT '创建时间',
  `gmt_modified` bigint(20) NOT NULL COMMENT '修改时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_tenant_info_kptenantid` (`kp`,`tenant_id`),
  KEY `idx_tenant_id` (`tenant_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='tenant_info';

CREATE TABLE `users` (
    `username` varchar(50) NOT NULL PRIMARY KEY,
    `password` varchar(500) NOT NULL,
    `enabled` boolean NOT NULL
);

CREATE TABLE `roles` (
    `username` varchar(50) NOT NULL,
    `role` varchar(50) NOT NULL,
    UNIQUE INDEX `idx_user_role` (`username` ASC, `role` ASC) USING BTREE
);

CREATE TABLE `permissions` (
    `role` varchar(50) NOT NULL,
    `resource` varchar(255) NOT NULL,
    `action` varchar(8) NOT NULL,
    UNIQUE INDEX `uk_role_permission` (`role`,`resource`,`action`) USING BTREE
);

INSERT INTO users (username, password, enabled) VALUES ('nacos', '$2a$10$EuWPZHzz32dJN7jexM34MOeYirDdFAZm2kuWj7VEOJhhZkDrxfvUu', TRUE);

INSERT INTO roles (username, role) VALUES ('nacos', 'ROLE_ADMIN');

5.4.2配置Nacos

进入 nacos 的 conf 目录，修改配置文件 cluster.conf.example，重命名为 cluster.conf

添加内容

127.0.0.1:8845
127.0.0.1.8846
127.0.0.1.8847

然后修改 application.properties 文件，添加数据库配置

spring.datasource.platform=mysql
db.num=1
db.url.0=jdbc:mysql://127.0.0.1:3306/nacos?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useUnicode=true&useSSL=false&serverTimezone=UTC
db.user.0=root
db.password.0=123456

将 nacos 文件夹复制三份，分别命名为：nacos1、nacos2、nacos3

然后分别修改三个文件夹中的 application.properties，

nacos1

server.port=8845

nacos2

server.port=8846

nacos3

server.port=8847

然后分别启动三个 nacos

startup.cmd

5.4.3Nginx反向代理

修改 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;
    }
}

启动 nginx，在浏览器访问：http://localhost/nacos

在代码中的 application.yml 文件配置改为如下：

spring:
  cloud:
    nacos:
      server-addr: localhost:80 # Nacos地址

实际部署时，需要给做反向代理的 Nginx 服务器设置一个域名，这样后续如果有服务器迁移 Nacos 的客户端也无需更改配置。Nacos 的各个节点应该部署到多个不同服务器，做好容灾和隔离工作。

6.Fegin远程调用

以前利用RestTemplate发起远程调用的代码：

存在下面的问题：

• 代码可读性差，编程体验不统一
• 参数复杂URL难以维护

Feign是一个声明式的http客户端，官方地址：https://github.com/OpenFeign/feign

其作用就是帮助我们优雅的实现http请求的发送，解决上面提到的问题

6.1Feign替代RestTemplate

1.引入依赖

在order-service服务的pom文件中引入feign的依赖：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

2.添加注解

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

3.编写Feign的客户端

在order-service中新建一个接口，内容如下：

import cn.itcast.order.pojo.User;
import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;

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

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

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

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

4.测试

修改order-service中的OrderService类中的queryOrderById方法，使用Feign客户端代替RestTemplate：

而且也已经自动引入了ribbon负载均衡。

5.总结

使用Feign的步骤：

① 引入依赖

② 添加@EnableFeignClients注解

③ 编写FeignClient接口

④ 使用FeignClient中定义的方法代替RestTemplate

6.2自定义配置

Feign可以支持很多的自定义配置，如下表所示：

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

配置日志的两种方式：

6.2.1配置文件方式

基于配置文件修改feign的日志级别：

可以针对单个服务：

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

也可以针对所有服务：

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

而日志的级别分为四种：

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

6.2.2.Java代码方式

也可以基于Java代码来修改日志级别，先声明一个类，然后声明一个Logger.Level的对象：

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

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

@EnableFeignClients(defaultConfiguration = DefaultFeignConfiguration .class) 

如果是局部生效，则把它放到具体接口clients对应的 @FeignClient这个注解中：

//在orderservice中的userclients接口中添加
@FeignClient(value = "userservice", configuration = DefaultFeignConfiguration .class) 

6.3Feign性能优化

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

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

因此提高Feign的性能主要手段就是使用连接池代替默认的URLConnection。

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

1.引入依赖

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

2.配置连接池

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

Feign优化方向：

• 日志级别尽量用basic级别
• 使用HttpClient或OKHttp代替URLConnection

6.4最佳实践

1. 继承方式：

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

• 定义一个 API 接口，利用定义方法，并基于 SpringMVC 注解做声明
• Feign 客户端、Controller 都实现该接口

优点：

• 简单
• 实现代码的共享

缺点：

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

2.抽取方式：

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

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

6.4.1抽取方式的实现

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

2.在 feign-api 中然后引入依赖

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

3.order-service中 的 UserClient、User 都复制到 feign-api 项目中

4.在 order-service 中使用 feign-api

由于我们已经将 UserClient、User 放在 fegin-api 中共享了 ，所以可以删除 order-service 中的 UserClient、User，然后在 order-service 中引入 feign-api

<dependency>
    <groupId>com.xn2001.feign</groupId>
    <artifactId>feign-api</artifactId>
    <version>1.0</version>
</dependency>

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

5.重启测试

发信存在报错，因为UserClient现在在cn.itcast.feign.clients包下，@Autowired扫描的是当前包下的类来创建对象，所以扫描不到，无法实现自动注入，解决方案如下：

• 方式一：

  在实现启动类中指定Feign应该扫描的包：

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

• 方式二：

  在实现启动类中指定需要加载的Client接口：

@EnableFeignClients(clients = {UserClient.class})

7.Gateway网关

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

7.1概念

网关的核心功能特性：

• 请求路由
• 权限控制
• 限流

网关的作用：

• 网关作为微服务入口，需要校验用户是是否有请求资格，如果没有则进行拦截
• 一切请求都必须先经过gateway，但网关不处理业务，而是根据某种规则，把请求转发到某个微服务，这个过程叫做路由。当然路由的目标服务有多个时，还需要做负载均衡。
• 当请求流量过高时，在网关中按照下流的微服务能够接受的速度来放行请求，避免服务压力过大。

在SpringCloud中网关的实现包括两种：gateway和zuul；

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

7.2gateway快速入门

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>

2.编写启动类

package cn.itcast.gateway;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class GatewayApplication {

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

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

创建application.yml文件，内容如下：

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://userservice            # 路由的目标地址 lb就是负载均衡，后面跟服务名称
          predicates:                      # 路由断言，也就是判断请求是否符合路由规则的条件
            - Path=/user/**                # 这个是按照路径匹配，只要以/user/开头就符合要求，所以当路路径是/user/1的时候，就会通过负载均衡发送请求。
            - id: order-service
             uri: lb://orderservice
             predicates:
              - Path=/user/**

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

重启网关，访问http://localhost:10010/user/1时，符合/user/**规则，请求转发到uri：http://userservice/user/1，就能得到结果

5.网关路由流程图

6.总结

网关搭建步骤：

• 创建项目，引入nacos服务发现和gateway依赖

• 配置application.yml，包括服务基本信息、nacos地址、路由

路由配置包括：

• 路由id：路由的唯一标示

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

• 路由断言（predicates）：判断路由的规则，

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

7.3断言工厂

• 在配置文件中写的断言规则只是字符串，这些字符串会被Predicate Factory读取并处理，转变为路由判断的条件

• 如Path=/user/**是按照路径匹配，这个规则是由

  org.springframework.cloud.gateway.handler.predicate.PathRoutePredicateFactory类来

  处理的，像这样的断言工厂在SpringCloudGateway还有十几个:

名称	说明	示例
After	是某个时间点后的请求	- After=2037-01-20T17:42:47.789-07:00[America/Denver]
Before	是某个时间点之前的请求	- Before=2031-04-13T15:14:47.433+08:00[Asia/Shanghai]
Between	是某两个时间点之前的请求	- Between=2037-01-20T17:42:47.789-07:00[America/Denver], 2037-01-21T17:42:47.789-07:00[America/Denver]
Cookie	请求必须包含某些cookie	- Cookie=chocolate, ch.p
Header	请求必须包含某些header	- Header=X-Request-Id, \d+
Host	请求必须是访问某个host（域名）	- Host=**.somehost.org, **.anotherhost.org
Method	请求方式必须是指定方式	- Method=GET,POST
Path	请求路径必须符合指定规则	- Path=/red/{segment},/blue/**
Query	请求参数必须包含指定参数	- Query=name, Jack或者- Query=name
RemoteAddr	请求者的ip必须是指定范围	- RemoteAddr=192.168.1.1/24
Weight	权重处理

官方文档：https://docs.spring.io/spring-cloud-gateway/docs/current/reference/html/#gateway-request-predicates-factories

7.5过滤器工厂

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

7.5.1路由过滤器的种类

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

名称	说明
AddRequestHeader	给当前请求添加一个请求头
RemoveRequestHeader	移除请求中的一个请求头
AddResponseHeader	给响应结果中添加一个响应头
RemoveResponseHeader	从响应结果中移除有一个响应头
RequestRateLimiter	限制请求的流量

7.5.2请求头过滤器

以AddRequestHeader 为例

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

只需要修改gateway服务的application.yml文件，添加路由过滤即可：

spring:
  cloud:
    gateway:
      routes:
      - id: user-service 
        uri: lb://userservice 
        predicates: 
        - Path=/user/** 
        filters: # 过滤器
        - AddRequestHeader=Truth, Itcast is freaking awesome! # 添加请求头，只针对user-service这个路由生效

修改 userservice 中的一个接口验证请求头是否实现：

@GetMapping("/{id}")
public User queryById(@PathVariable("id") Long id, @RequestHeader(value = "Truth", required = false) String sign) {
    System.out.println("Truth = " + Truth);
    return userService.queryById(id);
}

运行即可看到控制台打印出的信息Truth = Itcast is freaking awesome!

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

spring:
  cloud:
    gateway:
      default-filters:
        - AddRequestHeader=Truth,  Itcast is freaking awesome! # 添加请求头，这是对所有的路由都生效

7.6全局过滤器

由于上面的过滤器都是Spring写死的，一些规则无法自定义，所以要想自定义一些复杂的规则，则要通过全局过滤器。

7.6.1全局过滤器的作用

全局过滤器的作用也是处理一切进入网关的请求和微服务响应，与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);
}

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

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

7.6.2自定义全局过滤器

• 需求：定义全局过滤器，拦截请求，判断请求的参数是否满足下面条件：
  • 参数中是否有authorization，
  • authorization参数值是否为admin
• 如果同时满足则放行，否则拦截

代码实现：

在gateway中定义一个过滤器：

package cn.itcast.gateway.filters;

import org.springframework.cloud.gateway.filter.GatewayFilterChain;
import org.springframework.cloud.gateway.filter.GlobalFilter;
import org.springframework.core.annotation.Order;
import org.springframework.http.HttpStatus;
import org.springframework.stereotype.Component;
import org.springframework.web.server.ServerWebExchange;
import reactor.core.publisher.Mono;

@Order(-1)//定义过滤器的优先级，也可以通过实现Ordered接口重写方法来代替注解
@Component
public class AuthorizeFilter implements GlobalFilter {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        // 1.获取请求参数
        MultiValueMap<String, String> params = exchange.getRequest().getQueryParams();
        // 2.获取authorization参数
        String auth = params.getFirst("authorization");
        // 3.校验
        if ("admin".equals(auth)) {
            // 放行
            return chain.filter(exchange);
        }
        // 4.拦截
        // 4.1.禁止访问，设置状态码为禁止
        exchange.getResponse().setStatusCode(HttpStatus.FORBIDDEN);
        // 4.2.结束处理
        return exchange.getResponse().setComplete();
    }
}

7.6.3过滤器执行顺序

请求进入网关会碰到三类过滤器：当前路由的过滤器、DefaultFilter、GlobalFilter

请求路由后，会将当前路由过滤器和DefaultFilter、GlobalFilter，合并到一个过滤器链（集合）中，排序后依次执行每个过滤器：

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

7.7跨域问题

7.7.1什么是跨域问题

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

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

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

跨域问题：浏览器禁止请求的发起者与服务端发生跨域ajax请求，请求被浏览器拦截的问题
解决方案：CORS，这个以前应该学习过，这里不再赘述了。

不知道的小伙伴可以查看https://www.ruanyifeng.com/blog/2016/04/cors.html

7.7.2解决跨域问题

在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 # 这次跨域检测的有效期

8.初识Docker

8.1项目部署的问题

大型项目组件较多，运行环境也较为复杂，部署时会碰到一些问题：

• 依赖关系复杂，容易出现兼容性问题
• 开发、测试、生产环境有差异

Docker如何解决依赖的兼容问题

• 将应用的Libs（函数库）、Deps（依赖）、配置与应用一起打包
• 将每个应用放到一个隔离容器去运行，避免互相干扰

Docker如何解决不同系统环境的问题

不同环境的操作系统不同，Docker如何解决？我们先来了解下操作系统结构

• 用户程序【MySQL】：基于系统函数库实现功能
• 系统应用【ubuntu】：封装内核指令为函数，便于程序员调用
• Linux内核：与硬件交互，提供操作硬件的指令

Ubuntu和CentOS都是基于Linux内核，只是系统应用不同，提供的函数库有差异。此时，如果将一个Ubuntu版本的MySQL应用安装到CentOS系统，MySQL在调用Ubuntu函数库时，会发现找不到或者不匹配，就会报错了：

Docker如何解决不同系统环境的问题？

• Docker将用户程序与所需要调用的系统(比如Ubuntu的)函数库一起打包
• Docker运行到不同操作系统时，借助于已经打包好的库函数，直接调用Linux内核来运行
• 也就是说，Docker打包好的程序包可以运行在任何一个基于Linux内核的操作系统上

总结：

Docker如何解决大型项目依赖关系复杂，不同组件依赖的兼容性问题？

• Docker允许开发中将应用、依赖、函数库、配置一起打包，形成可移植镜像
• Docker应用运行在容器中，使用沙箱机制，相互隔离

Docker如何解决开发、测试、生产环境有差异的问题

• Docker镜像中包含完整运行环境，包括系统函数库，仅依赖系统的Linux内核，因此可以在任意Linux操作系统上运行

8.2Docker与虚拟机

• 虚拟机（virtual machine）是在操作系统中模拟硬件设备，然后运行另一个操作系统，比如在 Windows 系统里面运行Ubuntu 系统，这样就可以运行任意的Ubuntu应用了。
• Docker仅仅是封装函数库，并没有模拟完整的操作系统。

总结：

• docker是一个系统进程；虚拟机是在操作系统中的操作系统
• docker体积小、启动速度快、性能好；虚拟机体积大、启动速度慢、性能一般

8.3Docker安装

1.卸载已安装的旧版本（非必需）：

yum remove docker \
                  docker-client \
                  docker-client-latest \
                  docker-common \
                  docker-latest \
                  docker-latest-logrotate \
                  docker-logrotate \
                  docker-selinux \
                  docker-engine-selinux \
                  docker-engine \
                  docker-ce

2.安装docker

• 首先需要大家虚拟机联网，并安装yum工具

yum install -y yum-utils \
           device-mapper-persistent-data \
           lvm2 --skip-broken

• 然后更新本地镜像源

# 设置docker镜像源
yum-config-manager \
    --add-repo \
    https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
    
sed -i 's/download.docker.com/mirrors.aliyun.com\/docker-ce/g' /etc/yum.repos.d/docker-ce.repo

yum makecache fast

• 然后输入命令

yum install -y docker-ce

• docker-ce为社区免费版本。稍等片刻，docker即可安装成功。

3.启动docker

• Docker应用需要用到各种端口，逐一去修改防火墙设置。因此建议大家直接关闭防火墙

• 启动docker前，一定要关闭防火墙后

# 关闭
systemctl stop firewalld
# 禁止开机启动防火墙
systemctl disable firewalld

• 通过命令启动docker：

systemctl start docker  # 启动docker服务

systemctl stop docker  # 停止docker服务

systemctl restart docker  # 重启docker服务

• 然后输入命令，可以查看docker版本：

docker -v

4.配置镜像仓库加速

• docker官方镜像仓库网速较差，我们需要设置国内镜像服务：
• 参考阿里云的镜像加速文档：https://cr.console.aliyun.com/cn-hangzhou/instances/mirrors

8.4Docker基本操作

8.4.1镜像操作

• 镜像操作相关命令
  • 镜像名称一般分两部分组成：[repository]:[tag]。
  • 在没有指定tag时，默认是latest，代表最新版本的镜像

镜像操作指令：

• docker images 查看镜像
• docker rmi 移除镜像
• docker pull 拉取镜像
• docker push
• docker save 保存镜像，保存成一个xx.tar文件
• docker load 加载镜像，将xxx.tar文件加载成镜像

• 案例1：从DockerHub中拉取一个nginx镜像并查看

  

8.4.2容器操作

容器保护的三个状态：

• 运行：进程正常运行
• 暂停：进程暂停，CPU不再运行，并不释放内存
• 停止：进程终止，回收进程占用的内存、CPU等资源

案例1：创建运行一个Nginx容器

总结：

docker run命令的常见参数有哪些？

• –name：指定容器名称
• -p：指定端口映射
• -d：让容器后台运行

查看容器日志的命令：

• docker logs [容器名称]
• 添加 -f 参数可以持续查看日志

查看容器运行状态：docker ps

案例2 进入Nginx容器，修改HTML文件内容，添加“传智教育欢迎您”

总结：

查看容器状态：

• docker ps
• 添加-a参数查看所有状态的容器

删除容器：

• docker rm
• 不能删除运行中的容器，除非添加 -f 参数

进入容器：

• 命令是docker exec -it [容器名] [要执行的命令]
• exec命令可以进入容器修改文件，但是在容器内修改文件是不推荐的

容器内部会模拟一个独立的Linux文件系统，看起来如同一个linux服务器一样，nginx的环境、配置、运行文件全部都在这个文件系统中，包括我们要修改的html文件。但是容器内没有vi命令【没有多余的命令】，无法直接修改

案例：创建并运行一个redis容器，并且支持数据持久化

案例：进入redis容器，并执行redis-cli客户端命令，存入num=666

8.4.3数据卷操作

• 数据卷（volume）是一个虚拟目录，指向宿主机文件系统中的某个目录。一旦完成数据卷挂载，对容器的一切操作都会作用在数据卷对应的宿主机目录了。
• 这样，我们操作宿主机的/var/lib/docker/volumes/html目录，就等于操作容器内的/usr/share/nginx/html目录了

操作数据卷

案例：创建一个数据卷，并查看数据卷在宿主机的目录位置

总结：

数据卷的作用：

• 将容器与数据分离，解耦合，方便操作容器内数据，保证数据安全

数据卷操作：

• docker volume create
• docker volume ls
• docker volume inspect
• docker volume rm
• docker volume prune

8.4.4挂载数据卷

案例：创建一个nginx容器，修改容器内的html目录内的index.html内容

总结：

数据卷挂载方式：

• -v 数据卷名称: /容器内的文件目录
• 如果容器运行时volume不存在，会自动被创建出来

案例：创建并运行一个MySQL容器，将宿主机目录直接挂载到容器

• 容器不仅仅可以挂载数据卷，也可以直接挂载到宿主机目录上。关联关系如下
  • 带数据卷模式：宿主机目录 --> 数据卷 —> 容器内目录
  • 直接挂载模式：宿主机目录 —> 容器内目录

docker run \
  --name mymysql \
  -e MYSQL_ROOT_PASSWORD=123 \
  -p 3306:3306 \   #端口配置
  -v /tmp/mysql/conf/hmy.cnf:/etc/mysql/conf.d/hmy.cnf \   #宿主机文件目录:容器中的配置文件目录
  -v /tmp/mysql/data:/var/lib/mysql \  #宿主机数据存储的目录：容器中的数据存储目录
  -d \
  mysql:5.7.25

总结：
docker run的命令中通过 -v 参数挂载文件或目录到容器中：

• -v volume名称:容器内目录
• -v 宿主机文件:容器内文件
• -v 宿主机目录:容器内目录

数据卷挂载与目录直接挂载的

• 数据卷挂载耦合度低，由docker来管理目录，但是目录较深，不好找
• 目录挂载耦合度高，需要我们自己管理目录，不过目录容易寻找查看

8.5Dockerfile自定义镜像

• 镜像结构
  • 镜像是将应用程序及其需要的系统函数库、环境、配置、依赖打包而成。
  • 镜像是分层结构，每一层称为一个Layer
    • Entrypoint：入口，是镜像中应用启动的命令
    • 其它：在BaseImage基础上添加依赖、安装程序、完成整个应用的安装和配置
    • BaseImage层：包含基本的系统函数库、环境变量、文件系统

8.5.1Dockerfile语法

• Dockerfile就是一个文本文件，其中包含一个个的指令(Instruction)，用指令来说明要执行什么操作来构建镜像。每一个指令都会形成一层Layer。
• 更新详细语法说明，请参考官网文档： https://docs.docker.com/engine/reference/builder

8.5.2构建java项目

案例1：基于Ubuntu镜像构建一个新镜像，运行一个Java项目

• Dockerfiler

# 指定基础镜像
FROM ubuntu:16.04
# 配置环境变量，JDK的安装目录
ENV JAVA_DIR=/usr/local

# 拷贝jdk和java项目的包
COPY ./jdk8.tar.gz $JAVA_DIR/ #JAVA_DIR是上面定义的一个变量
COPY ./docker-demo.jar /tmp/app.jar

# 安装JDK
RUN cd $JAVA_DIR \
 && tar -xf ./jdk8.tar.gz \
 && mv ./jdk1.8.0_144 ./java8

# 配置环境变量
ENV JAVA_HOME=$JAVA_DIR/java8
ENV PATH=$PATH:$JAVA_HOME/bin

# 暴露端口：docker-demo.jar打包时暴露的是8090端口
EXPOSE 8090
# 入口，java项目的启动命令
ENTRYPOINT java -jar /tmp/app.jar

docker build -t javaweb:1.0 .最后的这个.代表的是Dockfile所在的位置【目录】

案例2：基于java:8-alpine镜像，将一个Java项目构建为镜像

• Dockerfiler

# 指定基础镜像
FROM java:8-alpine

# 拷贝jdk和java项目的包
COPY ./docker-demo.jar /tmp/app.jar

# 暴露端口
EXPOSE 8090
# 入口，java项目的启动命令
ENTRYPOINT java -jar /tmp/app.jar

• 总结：
  • Dockerfile的本质是一个文件，通过指令描述镜像的构建过程
  • Dockerfile的第一行必须是FROM，从一个基础镜像来构建
  • 基础镜像可以是基本操作系统，如Ubuntu。也可以是其他人制作好的镜像，例如：java:8-alpine

8.6DockerCompose

• 什么是DockerCompose
  • Docker Compose可以基于Compose文件帮我们快速的部署分布式应用，而无需手动一个个创建和运行容器！
  • Compose文件是一个文本文件，通过指令定义集群中的每个容器如何运行。
  • DockerCompose的详细语法参考官网：https://docs.docker.com/compose/compose-file/
  • 其实DockerCompose文件可以看做是将多个docker run命令写到一个文件，只是语法稍有差异

8.6.1CentOS7安装DockerCompose

下载

• Linux下需要通过命令下载：

# 安装
curl -L https://github.com/docker/compose/releases/download/1.23.1/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose

• 如果下载速度较慢，或者下载失败，可以使用课前资料提供的docker-compose文件上传到/usr/local/bin/目录也可以。

修改文件权限

# 修改权限
chmod +x /usr/local/bin/docker-compose

basse自动补全命令

• 补全命令

curl -L https://raw.githubusercontent.com/docker/compose/1.29.1/contrib/completion/bash/docker-compose > /etc/bash_completion.d/docker-compose

• 如果这里出现错误，需要修改自己的hosts文件：

echo "199.232.68.133 raw.githubusercontent.com" >> /etc/hosts

8.6.2部署微服务集群

将cloud-demo微服务集群利用DockerCompose部署

• docker-compose.yml：

version: "3.2"

services:
  nacos:
    image: nacos/nacos-server
    environment:
      MODE: standalone
    ports:
      - "8848:8848"
  mysql:
    image: mysql:5.7.25
    environment:
      MYSQL_ROOT_PASSWORD: root
    volumes:
      - "./mysql/data:/var/lib/mysql"
      - "./mysql/conf:/etc/mysql/conf.d/"
  userservice:
    build: ./user-service
  orderservice:
    build: ./order-service
  gateway:
    build: ./gateway
    ports:
      - "10010:10010"

• user-service、order-service、gateway的Dockerfile：

FROM java:8-alpine
COPY ./app.jar /tmp/app.jar
ENTRYPOINT java -jar /tmp/app.jar

注意：

• 由于nacos服务有可能启动的比其他服务晚，因此最好重启一下gateway、userservice、orderservice【命令：docker-compose restart gateway userservice orderservice】
• 或者也可以提前部署好Nacos服务，然后再利用DockerCompose来部署其他微服务集群。

8.7Docker镜像仓库

镜像仓库（ Docker Registry ）有公共的和私有的两种形式：

• 公共仓库：例如Docker官方的 Docker Hub，国内也有一些云服务商提供类似于 Docker Hub 的公开服务，比如 网易云镜像服务、DaoCloud 镜像服务、阿里云镜像服务等。
• 除了使用公开仓库外，用户还可以在本地搭建私有 Docker Registry。企业自己的镜像最好是采用私有Docker Registry来实现。

8.7.1配置Docker信任地址

• 搭建私有Docker镜像仓库之前需要先配置一下这个

• 我们的私服采用的是http协议，默认不被Docker信任，所以需要做一个配置：

# 打开要修改的文件
vi /etc/docker/daemon.json
# 添加内容：
"insecure-registries":["http://机器的ip地址:8080"]
# 重加载
systemctl daemon-reload
# 重启docker
systemctl restart docker

8.7.2搭建私有Docker镜像仓库

• 方法一：简化版镜像仓库

  • Docker官方的Docker Registry是一个基础版本的Docker镜像仓库，具备仓库管理的完整功能，但是没有图形化界面。

  • 搭建方式比较简单，命令如下：

  • docker run -d \
        --restart=always \
        --name registry	\
        -p 5000:5000 \
        -v registry-data:/var/lib/registry \
        registry
    

  • 命令中挂载了一个数据卷registry-data到容器内的/var/lib/registry 目录，这是私有镜像库存放数据的目录。

  • 访问http://YourIp:5000/v2/_catalog 可以查看当前私有镜像服务中包含的镜像

• 方法二：带有图形化界面版本

  • 使用DockerCompose部署带有图象界面的DockerRegistry，命令如下：

  • version: '3.0'
    services:
      registry:
        image: registry
        volumes:
          - ./registry-data:/var/lib/registry
      ui:
        image: joxit/docker-registry-ui:static
        ports:
          - 8080:80
        environment:
          - REGISTRY_TITLE=私有仓库名称
          - REGISTRY_URL=http://registry:5000
        depends_on:
          - registry
    

  • 搭建成功后，在浏览器页面输入：http://192.168.150.101:8080即可访问。

8.7.3在私有镜像仓库推送或拉取镜像

总结：

• 推送本地镜像到仓库之前都必须重命名(docker tag)镜像，以镜像仓库地址为前缀
• 镜像仓库推送前需要把仓库地址配置到docker服务的daemon.json文件中，被docker信任

9.初始MQ

• 同步和异步通讯
  • 微服务间通讯有同步和异步两种方式：
    • 同步通讯：就像打电话，需要实时响应。
    • 异步通讯：就像发邮件，不需要马上回复。
• 两种方式各有优劣，打电话可以立即得到响应，但是你却不能跟多个人同时通话。
• 发送邮件可以同时与多个人收发邮件，但是往往响应会有延迟。

9.1同步调用

之前学习的Feign调用就属于同步方式，虽然调用可以实时得到结果，但存在下面的问题：

总结：

同步调用的优点：

• 时效性较强，可以立即得到结果

同步调用的问题：

• 耦合度高
• 性能和吞吐能力下降
• 有额外的资源消耗
• 有级联失败问题

9.2异步调用

异步调用常见实现就是事件驱动模式：

事件驱动优势：

• 优势一：服务解耦

• 优势二：性能提升，吞吐量提高

• 优势三：服务没有强依赖，不担心级联失败问题

• 优势四：流量消峰

• 总结：
  • 异步调用的好处：
    • 耦合度低，每个服务都可以灵活插拔，可替换
    • 吞吐量高：无需等待订阅者处理完成，响应更快速，就可以处理更多的用户请求
    • 故障隔离：服务没有直接调用，不存在级联失败问题
    • 流量削峰：不管发布事件的流量波动多大，都由Broker接收，订阅者可以按照自己的速度去处理事件
  • 异步调用的缺点：
    • 架构复杂了，业务没有明显的流程线，不好追踪管理
    • 需要依赖Broker的可靠性、可用性、稳定性、安全性、吞吐能力等（好在现在开源软件或云平台上 Broker 的软件是非常成熟的，比较常见的一种就是我们今天要学习的MQ技术。）

9.3什么是MQ及四大MQ对比

• MQ （MessageQueue），中文是消息队列，字面来看就是存放消息（消息可以理解为“事件”）的队列。也就是事件驱动架构中的Broker。

9.4RabbitMQ

9.5SpringAMQP

• 什么是SpringAMQP
  • SpringAmqp的官方地址：https://spring.io/projects/spring-amqp

9.5.1简单队列接收消费消息

案例：利用SpringAMQP实现HelloWorld中的基础消息队列功能

1.因为publisher和consumer服务都需要amqp依赖，因此这里把依赖直接放到父工程mq-demo中：

 <!--AMQP依赖，包含RabbitMQ-->
 <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-amqp</artifactId>
 </dependency>
 
 <!--待会儿还需要用到单元测试-->
 <!--单元测试-->
 <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-test</artifactId>
 </dependency>

2.在publisher服务中编写application.yml，添加mq连接信息：

spring:
  rabbitmq:
    host: 192.168.152.134
    port: 5672
    username: itcast
    password: 123321
    virtual-host: /

3.在publisher服务中新建一个测试类，编写测试方法：

@RunWith(SpringRunner.class)
@SpringBootTest
public class SpringAMQPTest {
    @Autowired
    private RabbitTemplate rabbitTemplate;

    @Test
    public void testSendSimpleQueue() {
        String queueName = "simple.queue";
        String message = "Hello, SpringAMQP! I am LP!";
        rabbitTemplate.convertAndSend(queueName, message);
    }
}

编写消费者来对信息进行消费

4.在consumer服务中编写application.yml，添加mq连接信息：

5.在consumer服务中新建一个类，编写消费逻辑：

@Component //告诉spring这个类的存在
public class SpringAMQPListener {
    //括号中的是要监听队列的名称
    @RabbitListener(queues = "simple.queue")
    public void receiveSimpleQueueMessage(String message) {
        System.out.println("接收到了simple.queue的消息：【" + message + "】");
    }
}

6.运行消费者启动类，消费信息

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

9.5.2WorkQueue工作队列

当消息处理比较耗时的时候，可能生产消息的速度会远远大于消息的消费速度。长此以往，消息就会堆积越来越多，无法及时处理。

此时就可以使用 work 模型，多个消费者共同处理消息处理，速度就能大大提高了。

案例：模拟WorkQueue，实现一个队列绑定多个消费者

/**
 * workQueue
 * 向队列中不停发送消息，模拟消息堆积。
 */
@Test
public void testWorkQueue() throws InterruptedException {
    // 队列名称
    String queueName = "simple.queue";
    // 消息
    String message = "hello, message_";
    for (int i = 0; i < 50; i++) {
        // 发送消息
        rabbitTemplate.convertAndSend(queueName, message + i);
        Thread.sleep(20);
    }
}

• 消息接收：

要模拟多个消费者绑定同一个队列，我们在 consumer 服务的 RabbitMQListener 中添加2个新的方法

@RabbitListener(queues = "simple.queue")
public void listenWorkQueue1(String msg) throws InterruptedException {
    System.out.println("消费者1接收到消息：【" + msg + "】" + LocalTime.now());
    Thread.sleep(20);//接收一次休眠20ms，快的消费者
}

@RabbitListener(queues = "simple.queue")
public void listenWorkQueue2(String msg) throws InterruptedException {
    System.err.println("消费者2........接收到消息：【" + msg + "】" + LocalTime.now());
    Thread.sleep(200);//接收一次休眠200ms，慢的消费者
}

• 启动 ConsumerApplication 后，在执行 publisher 服务中刚刚编写的发送测试方法 testWorkQueue

• 看到消费者1很快完成了自己的25条消息。消费者2却在缓慢的处理自己的25条消息。也就是说消息是平均分配给每个消费者，并没有考虑到消费者的处理能力。这是因为 RabbitMQ 默认有一个消息预取机制。

• 所以要解决消息预取出现的问题，则在 spring 中有一个简单的配置，设置 prefetch 属性，我们修改 consumer 服务的 application.yml 文件，添加配置

spring:
  rabbitmq:
    listener:
      simple:
        prefetch: 1 # 每次只能获取一条消息，处理完成才能获取下一个消息

Work 模型的使用：

• 多个消费者绑定到一个队列，同一条消息只会被一个消费者处理
• 通过设置 prefetch 来控制消费者预取的消息数量

9.5.3发布/订阅

• 发布订阅模式与之前案例的区别就是允许将同一消息发送给多个消费者。实现方式是加入了exchange（交换机）。

• 常见exchange类型包括：

  • Fanout：广播
  • Direct：路由
  • Topic：话题

总结：交换机的作用是什么？

• 接收publisher发送的消息
• 将消息按照规则路由到与之绑定的队列
• exchange负责消息路由，而不是存储，路由失败则消息丢失

9.5.3.1FanoutExchange【广播】

• Fanout Exchange 会将接收到的消息广播到每一个跟其绑定的queue

案例：利用SpringAMQP演示FanoutExchange的使用

• SpringAMQP提供了声明交换机、队列、绑定关系的API，例如：

• 在consumer进行声明

@Configuration
public class FanoutExchangeConfig {
    // 声明Fanout交换机
    @Bean
    public FanoutExchange fanoutExchange() {
        return new FanoutExchange("itcast.fanout");
    }
    // 声明第1个队列
    @Bean
    public Queue fanoutQueue1() {
        return new Queue("fanout.queue1");
    }
    //绑定队列1和交换机
    @Bean
    public Binding bindingQueue1(FanoutExchange fanoutExchange, Queue fanoutQueue1) {
        return BindingBuilder.bind(fanoutQueue1).to(fanoutExchange);
    }
    // 声明第2个队列
    @Bean
    public Queue fanoutQueue2() {
        return new Queue("fanout.queue2");
    }
    //绑定队列2和交换机
    @Bean
    public Binding bindingQueue2(FanoutExchange fanoutExchange, Queue fanoutQueue2) {
        return BindingBuilder.bind(fanoutQueue2).to(fanoutExchange);
    }
}

• 在消费者服务中声明两个消费者，分别监听fanout.queue1和fanout.queue2

@Component
public class SpringAMQPListener {
    @RabbitListener(queues = "fanout.queue1")
    public void listenFanoutQueue1(String message) {
        System.err.println("fanoutQueue1-----------接收到了消息：【" + message + "】");
    }

    @RabbitListener(queues = "fanout.queue2")
    public void listenFanoutQueue2(String message) {
        System.err.println("fanoutQueue2接收到了消息：【" + message + "】");
    }
}

• 在publisher服务的SpringAmqpTest类中添加测试方法：

9.5.3.2DirectExchange【路由】

Direct Exchange 会将接收到的消息根据规则路由到指定的Queue，因此称为路由模式（routes）。

• 每一个Queue都与Exchange设置一个BindingKey
• 发布者发送消息时，指定消息的RoutingKey
• Exchange将消息路由到BindingKey与消息RoutingKey一致的队列

案例：利用SpringAMQP演示DirectExchange的使用

• 在consumer中声明：

@Component
public class SpringAMQPListener {
    //直接一个注解解决声明和绑定
    @RabbitListener(
            bindings = @QueueBinding(
                    value = @Queue(name = "direct.queue1"),
                    exchange = @Exchange(name = "itcast.direct", type = "direct"),
                    key = {"blue", "red"}
            )
    )
    public void listenDirectExchangeQueue1(String message) {
        System.out.println("listenDirectExchangeQueue1：message：【" + message + "】");
    }

    @RabbitListener(
            bindings = @QueueBinding(
                    value = @Queue(name = "direct.queue2"),
                    exchange = @Exchange(name = "itcast.direct", type = ExchangeTypes.DIRECT),
                    key = {"yellow", "red"}
            )
    )
    public void listenDirectExchangeQueue2(String message) {
        System.err.println("listenDirectExchangeQueue2——>message：【" + message + "】");
    }

}

• 在消息发布者publisher中的

@RunWith(SpringRunner.class)
@SpringBootTest
public class SpringAMQPTest {
    @Autowired
    private RabbitTemplate rabbitTemplate;

    @Test
    public void testDirectExchangeQueue() {
        String exchangeName = "itcast.direct";

//        String message = "Hello, blue!";
//        发送消息，参数依次为：交换机名称，RoutingKey，消息
//        rabbitTemplate.convertAndSend(exchangeName, "blue", message);

//        String message = "Hello, yellow!";
//        rabbitTemplate.convertAndSend(exchangeName, "yellow", message);

        String message = "Hello, red!";
        rabbitTemplate.convertAndSend(exchangeName, "red", message);
    }
}

总结：

• 描述下Direct交换机与Fanout交换机的差异？
  • Fanout交换机将消息路由给每一个与之绑定的队列
  • Direct交换机根据RoutingKey匹配BindingKey来判断应该路由给哪个队列
  • 如果多个队列具有相同的BindingKey，则与Fanout功能类似，比如上边的【red】

9.5.3.3TopicExchange【话题】

• TopicExchange与DirectExchange类似，区别在于routingKey必须是多个单词的列表，并且以 . 分割。
• Queue与Exchange指定bindingKey时可以使用通配符：
  • #：代指0个或多个单词
  • *：代指一个单词

案例：利用SpringAMQP演示TopicExchange的使用

• 在consumer中，修改完启动：

@Component
public class SpringAMQPListener {
    @RabbitListener(
            bindings = @QueueBinding(
                    value = @Queue(name = "topic.queue1"),
                    exchange = @Exchange(name = "itcast.topic", type = ExchangeTypes.TOPIC),
                    key = "china.#"
            )
    )
    public void listenTopicExchangeQueue1(String message) {
        System.err.println("listenTopicExchangeQueue1——>message：【" + message + "】");
    }


    @RabbitListener(
            bindings = @QueueBinding(
                    value = @Queue(name = "topic.queue2"),
                    exchange = @Exchange(name = "itcast.topic", type = ExchangeTypes.TOPIC),
                    key = "#.news"
            )
    )
    public void listenTopicExchangeQueue2(String message) {
        System.out.println("listenTopicExchangeQueue2==>message：【" + message + "】");
    }

}

• 消息发布者中

@RunWith(SpringRunner.class)
@SpringBootTest
public class SpringAMQPTest {
    @Autowired
    private RabbitTemplate rabbitTemplate;

    @Test
    public void testTopicExchangeQueue() {
        String exchangeName = "itcast.topic";

//        String message = "新闻：传智教育【教育行业IPO第一股】上市了！";
//        rabbitTemplate.convertAndSend(exchangeName, "china.news", message);

        //当发送的key是china.weather，则队列1可以接收消息，队列2不能接收消息
        String message = "天气：晴天，34摄氏度";
        rabbitTemplate.convertAndSend(exchangeName, "china.weather", message);
    }
}

9.5.4消息转换器

• 当发送之后，观察到所获得的消息已经被自动序列化了：

• Spring的对消息对象的处理是由org.springframework.amqp.support.converter.MessageConverter来处理的。

  而默认实现是SimpleMessageConverter，基于JDK的ObjectOutputStream完成序列化。

  如果要修改只需要定义一个 MessageConverter 类型的Bean即可

• 推荐用JSON方式序列化，步骤如下：

  • 在 publisher 和 consumer 两个服务中都引入依赖

  <dependency>
      <groupId>com.fasterxml.jackson.dataformat</groupId>
      <artifactId>jackson-dataformat-xml</artifactId>
      <version>2.9.10</version>
  </dependency>
  

• 配置消息转换器。

  • 在各自的启动类中添加一个 Bean 即可

    @Bean
    public MessageConverter jsonMessageConverter(){
        return new Jackson2JsonMessageConverter();
    }
    

• 定义一个消费者，监听队列并消费消息

10.ElasticSearch分布式搜索

10.1ES基础概念

ES概述：

ELK（Elastic Stack）是以Elastic为核心的技术栈，如下图所示：

ElasticSearch底层是Lucene（侧面说明了ES和Hadoop千丝万缕的关系）

10.2倒排索引

Lucene的核心就是倒排索引：

倒排索引中有两个非常重要的概念：

• 文档（Document）：用来搜索的数据，其中的每一条数据就是一个文档。例如一个网页、一个商品信息
• 词条（Term）：对文档数据或用户搜索数据，利用某种算法分词，得到的具备含义的词语就是词条。例如：我是中国人，就可以分为：我、是、中国人、中国、国人这样的几个词条

创建倒排索引是对正向索引的一种特殊处理，流程如下：

• 将每一个文档的数据利用算法分词，得到一个个词条
• 创建表，每行数据包括词条、词条所在文档 id、位置等信息
• 因为词条唯一性，可以给词条创建索引，例如 hash 表结构索引

倒排索引的搜索流程如下（以搜索"华为手机"为例）

1. 用户输入条件"华为手机"进行搜索
2. 对用户输入内容分词，得到词条：华为、手机
3. 拿着词条在倒排索引中查找，可以得到包含词条的文档 id 有 1、2、3
4. 拿着文档 id 到正向索引中查找具体文档

虽然要先查询倒排索引，再查询正向索引，但是词条和文档id 都建立了索引，查询速度非常快！无需全表扫描。

为什么一个叫做正向索引，一个叫做倒排索引呢？

正向索引是最传统的，根据 id 索引的方式。但根据词条查询时，必须先逐条获取每个文档，然后判断文档中是否包含所需要的词条，是根据文档找词条的过程

倒排索引则相反，是先找到用户要搜索的词条，根据得到的文档 id 获取该文档。是根据词条找文档的过程

10.3与mysql的概念对比

• 文档：

elasticsearch 是面向文档（Document）存储的，可以是数据库中的一条商品数据，一个订单信息。文档数据会被序列化为 json 格式后存储在 elasticsearch。

JSON 文档中往往包含很多的字段（Field），类似于数据库中的列。

• 索引和映射：

索引（Index），就是相同类型的文档的集合。

• 所有用户文档，就可以组织在一起，称为用户的索引；
• 所有商品的文档，可以组织在一起，称为商品的索引；
• 所有订单的文档，可以组织在一起，称为订单的索引；

因此，我们可以把索引当做是数据库中的表。

数据库的表会有约束信息，用来定义表的结构、字段的名称、类型等信息。因此，索引库中就有映射（mapping），是索引中文档的字段约束信息，类似表的结构约束。

mysql 与 elasticsearch

MySQL	Elasticsearch	说明
Table	Index	索引(index)，就是文档的集合，类似数据库的表(table)
Row	Document	文档（Document），就是一条条的数据，类似数据库中的行（Row），文档都是JSON格式
Column	Field	字段（Field），就是JSON文档中的字段，类似数据库中的列（Column）
Schema	Mapping	Mapping（映射）是索引中文档的约束，例如字段类型约束。类似数据库的表结构（Schema）
SQL	DSL	DSL是elasticsearch提供的JSON风格的请求语句，用来操作elasticsearch，实现CRUD

• Mysql：擅长事务类型操作，可以确保数据的安全和一致性

• Elasticsearch：擅长海量数据的搜索、分析、计算

• 在企业中，往往是两者结合使用：

  • 对安全性要求较高的写操作，使用 MySQL 实现
  • 对查询性能要求较高的搜索需求，使用 ELasticsearch 实现
  • 两者再基于某种方式，实现数据的同步，保证一致性

10.4安装Elasticsearch

我们还需要部署 kibana 容器，需要让 es 和 kibana 容器互联。这里先创建一个网络：

docker network create es-net 

安装：

docker run -d \
--name es \
-e "ES_JAVA_OPTS=-Xms512m -Xmx512m" \
-e "discovery.type=single-node" \
-v es-data:/usr/share/elasticsearch/data \
-v es-plugins:/usr/share/elasticsearch/plugins \
--privileged \
--network es-net \
-p 9200:9200 \
-p 9300:9300 \
elasticsearch:7.12.1

解释：

• -e "cluster.name=es-docker-cluster"：设置集群名称
• -e "http.host=0.0.0.0"：监听的地址，可以外网访问
• -e "ES_JAVA_OPTS=-Xms512m -Xmx512m"：内存大小
• -e "discovery.type=single-node"：非集群模式
• -v es-data:/usr/share/elasticsearch/data：挂载逻辑卷，绑定es的数据目录
• -v es-logs:/usr/share/elasticsearch/logs：挂载逻辑卷，绑定es的日志目录
• -v es-plugins:/usr/share/elasticsearch/plugins：挂载逻辑卷，绑定es的插件目录
• --privileged：授予逻辑卷访问权
• --network es-net ：加入一个名为 es-net 的网络中
• -p 9200:9200：端口映射配置

10.5安装kibana

kibana 可以给我们提供一个 elasticsearch 的可视化界面，便于我们学习命令。

docker run -d \
--name kibana \
-e ELASTICSEARCH_HOSTS=http://es:9200 \
--network=es-net \
-p 5601:5601  \
kibana:7.12.1  \\版本要和Elasticsearch一致

解释：

• --network es-net ：加入一个名为 es-net 的网络中，与 elasticsearch 在同一个网络中
• -e ELASTICSEARCH_HOSTS=http://es:9200"：设置 elasticsearch 的地址，因为 kibana 已经与 elasticsearch 在一个网络，因此可以用容器名直接访问 elasticsearch
• -p 5601:5601：端口映射配置

访问地址：http://192.168.211.128:5601，即可看到结果

10.6安装IK分词器

安装插件需要知道 elasticsearch 的 plugins 目录位置，而我们用了数据卷挂载，因此需要查看 elasticsearch 的数据卷目录，通过下面命令查看

docker volume inspect es-plugins

显示结果：

[
    {
        "CreatedAt": "2022-05-06T10:06:34+08:00",
        "Driver": "local",
        "Labels": null,
        "Mountpoint": "/var/lib/docker/volumes/es-plugins/_data",
        "Name": "es-plugins",
        "Options": null,
        "Scope": "local"
    }
]

说明 plugins 目录被挂载到了 /var/lib/docker/volumes/es-plugins/_data 这个目录中

重启容器

# 4、重启容器
docker restart es

# 查看es日志
docker logs -f es

IK分词器包含两种模式：

• ik_smart：智能切分，粗粒度
• ik_max_word：最细切分，细粒度

我们在上面的 Kibana 控制台测试

GET /_analyze
{
  "analyzer": "ik_max_word",
  "text": "钟老师你好菜啊"
}

• 拓展词词典

上面的IK分词器我们可以随着热点词来扩展，可以自己添加，比如 ”钟老师应该是一个热点词“，另外你也可以配置一些停用掉的敏感词，让其不进行分词。

打开IK分词器 config 目录是 IKAnalyzer.cfg.xml，添加一个文件名，我们以 ext.dic 文件名为例。

去创建 ext.dic ，在其中添加热点词就好了，一个词一行。

停止词典同理，可以在配置目录添加stopword.dic

• 总结：

10.7索引库操作

10.7.1Mapping属性映射

索引库就类似数据库表，mapping 映射就类似表的结构

我们要向 es 中存储数据，必须先创建“库”和“表”

mapping 是对索引库中文档的约束，常见的 mapping 属性包括：

• type：字段数据类型，常见的简单类型有：
  • 字符串：text（可分词的文本）、keyword（不可分词文本，精确值，例如：品牌、国家、ip地址）
  • 数值：long、integer、short、byte、double、float、
  • 布尔：boolean
  • 日期：date
  • 对象：object
• index：是否创建索引，默认为 true，默认创建倒排索引
• analyzer：使用哪种分词器
• properties：该字段的子字段

以需要存储下面的 JSON 为例来讲解

{
    "age": 21,
    "weight": 52.1,
    "isMarried": false,
    "info": "钟老师真菜",
    "email": "jialna@qq.com",
    "score": [99.1, 99.5, 98.9],
    "name": {
        "firstName": "湖",
        "lastName": "心"
    }
}

首先对应的每个字段映射（mapping）情况如下：

• age：类型为 integer；参与搜索，index 为 true；无需分词器
• weight：类型为 float；参与搜索，index 为 true；无需分词器
• isMarried：类型为boolean；参与搜索，index 为 true；无需分词器
• info：类型为字符串，需要分词，因此是 text；参与搜索，index为true；分词器可以用 ik_smart
• email：类型为字符串，但是不需要分词，因此是 keyword；不参与搜索，index 为 false；无需分词器
• score：虽然是数组，但是我们只看元素的类型，类型为 float；参与搜索，index 为 true；无需分词器
• name：类型为 object，需要定义多个子属性
  • name.firstName：类型为字符串，不需要分词，keyword；参与搜索，index 为 true；无需分词器
  • name.lastName：类型为字符串，不需要分词，keyword；参与搜索，index 为 true；无需分词器

创建索引库和映射

PUT /索引库名称
{
  "mappings": {
    "properties": {
      "字段名":{
        "type": "text",
        "analyzer": "ik_smart"
      },
      "字段名2":{
        "type": "keyword",
        "index": "false"
      },
      "字段名3":{
        "properties": {
          "子字段": {
            "type": "keyword"
          }
        }
      }
      // ...略
    }
  }
}

将上面的json数据转换得：

PUT /xn2001
{
  "mappings": {
    "properties": {
      "info":{
        "type": "text",
        "analyzer": "ik_smart"
      },
      "email":{
        "type": "keyword",
        "index": "false"
      },
      "name":{
        "properties": {
          "firstName": {
            "type": "keyword"
          },
          "lastName": {
            "type": "keyword"
          }
        }
      }
    }
  }
}

10.7.2查询、修改、删除索引库

• 查看索引库：GET /索引库名
• 删除索引库：DELETE /索引库名
• 修改索引库从设计上被禁止了，索引库和mapping一旦创建无法修改，但是可以添加新的字段 (该字段必须是全新的字段) 。

# 查询
GET /heima

# 修改（必须添加一个全新的字段）
PUT /heima/_mapping
{
  "properties":{
  #添加全新的字段age
    "age":{
      "type": "integer"
    }
  }
}

# 删除
DELETE /heima

10.8文档操作

索引库相当于数据库的table，文档就相当于数据库的行。

• 添加文档

# 插入一个文档
POST /heima/_doc/1
{
  "info": "黑马程序员java讲师",
  "email": "112837@qq.com",
  "name":{
  #有两个子属性
    "firstName":"云",
    "lastName":"赵"
  }
}

• 查看、删除文档

# 查询
GET /heima/_doc/1

# 删除
DELETE /heima/_doc/1

每次写操作的时候，都会使得文档的"_version"字段+1

• 修改文档

它会删除旧文档，新增新文档

方式一：全量修改语法：和新增的语法完全一致，只不过新增是POST，全量修改是PUT

# 插入一个文档
PUT /heima/_doc/1
{
  "info": "黑马程序员java讲师",
  "email": "112837@qq.com",
  "name":{
    "firstName":"云",
    "lastName":"赵"
  }
}

如果id在索引库里面不存在，并不会报错，而是直接新增，如果索引库存在该记录，就会先删掉该记录，然后增加一个全新的。

方式二：增量修改语法：只修改某记录的指定字段值

语法：

# 局部修改文档字段
# 第三行，必须跟一个doc
POST /heima/_update/1
{
  "doc": {  
    "email":"lbwnb@qq.com"
  }
}

文档操作总结：

10.9RestClient操作索引库和文档

• ES官方为各种语言操作ES提供了客户端API，用来操作ES。其实本质都是组装ES语句，通过http请求发送给ES。 官方文档地址：https://www.elastic.co/guide/en/elasticsearch/client/index.html

可以看到很多语言版本

• 案例和代码位置

代码位置(大量代码写在测试类中)，该案例需要导入数据库，数据库执行脚本位置同代码目录：

• 编写DSL语句，创建索引库（相当与MySQL中建表）

# 酒店的mapping
PUT /hotel
{
  "mappings": {
    "properties": {
      "id":{
        "type": "keyword"         
      },
      "name":{
        "type": "text"
        , "analyzer": "ik_max_word",
        "copy_to": "all"
      },
      "address":{
        "type": "keyword"
        , "index": false
      },
      "price":{
        "type": "integer"
      },
      "score":{
        "type": "integer"
      },
      "brand":{
        "type": "keyword",
        "copy_to": "all"
      },
      "city":{
        "type": "keyword"
      },
      "starName":{
        "type": "keyword"
      },
      "business":{
        "type": "keyword",
        "copy_to": "all"
      },
      "location":{
        "type": "geo_point"
      },
       "pic":{
        "type": "keyword"
        , "index": false
      },
      "all":{
        "type": "text",
        "analyzer": "ik_max_word"
      }
    }
  }
}

• 特殊字段说明：
  • location：地理坐标，里面包含精度、纬度
  • all：一个组合字段，其目的是将多字段的值利用 copy_to 合并，提供给用户搜索，这样一来就只需要搜索一个字段就可以得到结果，性能更好。

10.9.1初始化RestClient

在 elasticsearch 提供的 API 中，elasticsearch 一切交互都封装在一个名为 RestHighLevelClient 的类中，必须先完成这个对象的初始化，建立与 elasticsearch 的连接。

• 引入依赖

<dependency>
    <groupId>org.elasticsearch.client</groupId>
    <artifactId>elasticsearch-rest-high-level-client</artifactId>
</dependency>

• SpringBoot 默认的 ES 版本是 7.6.2，我们需要覆盖默认的ES版本

<properties>
    <java.version>1.8</java.version>
    <elasticsearch.version>7.12.1</elasticsearch.version>
</properties>

• 初始化 RestHighLevelClient，初始化的代码如下：

RestHighLevelClient client = new RestHighLevelClient(RestClient.builder(
        HttpHost.create("http://192.168.211.128:9200")
));

• 我们创建一个测试类 HotelIndexTest，然后将初始化的代码编写在 @BeforeEach 方法

public class HotelIndexTest {

    private RestHighLevelClient restHighLevelClient;

    @Test
    void testInit(){
        System.out.println(this.restHighLevelClient);
    }

    @BeforeEach
    //build里面的参数是虚拟机地址加端口号
    void init(){
        this.restHighLevelClient = new RestHighLevelClient(RestClient.builder(
                HttpHost.create("http://192.168.211.128:9200")
        ));
    }

    @AfterEach
    void down() throws IOException {
        this.restHighLevelClient.close();
    }
}

10.9.2索引库操作

创建索引库

@Test
void createHotelIndex() throws IOException {
    //指定索引库名
    CreateIndexRequest hotel = new CreateIndexRequest("hotel");
    //写入JSON数据，这里是Mapping映射，MAPPING_TEMPLATE是常量
    hotel.source(HotelConstants.MAPPING_TEMPLATE, XContentType.JSON);
    //创建索引库
    restHighLevelClient.indices().create(hotel, RequestOptions.DEFAULT);
}

public class HotelConstants {
    public static String MAPPING_TEMPLATE = "{\n" +
            "  \"mappings\": {\n" +
            "    \"properties\": {\n" +
            "      \"id\": {\n" +
            "        \"type\": \"keyword\"\n" +
            "      },\n" +
            "      \"name\":{\n" +
            "        \"type\": \"text\",\n" +
            "        \"analyzer\": \"ik_max_word\",\n" +
            "        \"copy_to\": \"all\"\n" +
            "      },\n" +
            "      \"address\":{\n" +
            "        \"type\": \"keyword\",\n" +
            "        \"index\": false\n" +
            "      },\n" +
            "      \"price\":{\n" +
            "        \"type\": \"integer\"\n" +
            "      },\n" +
            "      \"score\":{\n" +
            "        \"type\": \"integer\"\n" +
            "      },\n" +
            "      \"brand\":{\n" +
            "        \"type\": \"keyword\",\n" +
            "        \"copy_to\": \"all\"\n" +
            "      },\n" +
            "      \"city\":{\n" +
            "        \"type\": \"keyword\",\n" +
            "        \"copy_to\": \"all\"\n" +
            "      },\n" +
            "      \"starName\":{\n" +
            "        \"type\": \"keyword\"\n" +
            "      },\n" +
            "      \"business\":{\n" +
            "        \"type\": \"keyword\"\n" +
            "      },\n" +
            "      \"location\":{\n" +
            "        \"type\": \"geo_point\"\n" +
            "      },\n" +
            "      \"pic\":{\n" +
            "        \"type\": \"keyword\",\n" +
            "        \"index\": false\n" +
            "      },\n" +
            "      \"all\":{\n" +
            "        \"type\": \"text\",\n" +
            "        \"analyzer\": \"ik_max_word\"\n" +
            "      }\n" +
            "    }\n" +
            "  }\n" +
            "}";
}

删除索引库

@Test
void deleteHotelIndex() throws IOException {
    DeleteIndexRequest hotel = new DeleteIndexRequest("hotel");
    restHighLevelClient.indices().delete(hotel,RequestOptions.DEFAULT);
}

判断索引库

@Test
void existHotelIndex() throws IOException {
    GetIndexRequest hotel = new GetIndexRequest("hotel");
    boolean exists = restHighLevelClient.indices().exists(hotel, RequestOptions.DEFAULT);
    System.out.println(exists);
}

10.9.3文档操作

新增文档index

@SpringBootTest
public class HotelDocumentTest {

    private RestHighLevelClient restHighLevelClient;

    @Autowired
    private IHotelService hotelService;

    @Test
    void testInit(){
        System.out.println(this.restHighLevelClient);
    }

//新增文档
    @Test
    void createHotelIndex() throws IOException {
   		//查询到数据
        Hotel hotel = hotelService.getById(61083L);
        //要转换成索引库所要的文档格式的数据
        HotelDoc hotelDoc = new HotelDoc(hotel);
        // 1.准备Request对象，IndexRequest("索引库名").id(hotelDoc.getId().toString()//获取指定id)
        IndexRequest hotelIndex = new IndexRequest("hotel").id(hotelDoc.getId().toString());
        // 2.准备Json文档，要将对象序列化成json格式
        hotelIndex.source(JSON.toJSONString(hotelDoc), XContentType.JSON);
        // 3.发送请求
        restHighLevelClient.index(hotelIndex, RequestOptions.DEFAULT);
    }

    @BeforeEach
    void init(){
        this.restHighLevelClient = new RestHighLevelClient(RestClient.builder(
                HttpHost.create("http://192.168.211.128:9200")
        ));
    }

    @AfterEach
    void down() throws IOException {
        this.restHighLevelClient.close();
    }
}

查询文档get

@Test
void testGetDocumentById() throws IOException {
    // 1.准备Request
    GetRequest hotel = new GetRequest("hotel", "61083");
    // 2.发送请求，得到响应
    GetResponse hotelResponse = restHighLevelClient.get(hotel, RequestOptions.DEFAULT);
    // 3.解析响应结果
    String hotelDocSourceAsString = hotelResponse.getSourceAsString();
    // 4.json转实体类
    HotelDoc hotelDoc = JSON.parseObject(hotelDocSourceAsString, HotelDoc.class);
    System.out.println(hotelDoc);
}

修改文档update

修改文档有两种方式：

• 全量修改：直接覆盖原来的文档
• 增量修改：修改文档中的部分字段

在 RestClient 的 API 中，全量修改与新增的 API 完全一致，判断依据是 ID

• 如果新增时，ID已经存在，则修改
• 如果新增时，ID不存在，则新增

所以全量修改写法与新增文档一样，下面主要是介绍增量修改。

@Test
void testUpdateDocument() throws IOException {
    // 1.准备Request
    UpdateRequest request = new UpdateRequest("hotel", "61083");
    // 2.准备请求参数
    request.doc(
        "price", "952",
        "starName", "四钻"
    );
    // 3.发送请求
    restHighLevelClient.update(request, RequestOptions.DEFAULT);
}

删除文档delete

@Test
void testDeleteDocumentById() throws IOException {
    DeleteRequest hotel = new DeleteRequest("hotel", "61083");
    restHighLevelClient.delete(hotel,RequestOptions.DEFAULT);
}

文档操作总结

批量导入数据

案例需求：利用 BulkRequest 批量将数据库数据导入到索引库中。

• 利用 mybatis-plus 查询酒店数据
• 将查询到的酒店数据（Hotel）转换为文档类型数据（HotelDoc）
• 利用 JavaRestClient 中的 BulkRequest 批处理，实现批量新增文档

批量处理 BulkRequest，其本质就是将多个普通的 CRUD 请求组合在一起发送。

因此Bulk中添加了多个IndexRequest，就是批量新增功能了。示例：

利用这一点，我们可以写出自己需要的代码，如下

@Test
void testBulk() throws IOException {
    BulkRequest bulkRequest = new BulkRequest();
    //批量查询数据
    List<Hotel> hotelList = hotelService.list();
    //将查询到的数据转换成HotelDoc数据，再添加到bulkRequest里面
    hotelList.forEach(item -> {
        HotelDoc hotelDoc = new HotelDoc(item);
        bulkRequest.add(new IndexRequest("hotel")
                .id(hotelDoc.getId().toString())
                .source(JSON.toJSONString(hotelDoc), XContentType.JSON));
    });
    restHighLevelClient.bulk(bulkRequest, RequestOptions.DEFAULT);
}

10.10DSL查询语法

Elasticsearch 提供了基于 JSON 的 DSL(Domain Specific Language)来定义查询。常见的查询类型包括：

查询所有：查询出所有数据，一般测试用。例如：match_all

全文检索（full text）查询：利用分词器对用户输入内容分词，然后去倒排索引库中匹配。例如：

• match_query
• multi_match_query

精确查询：根据精确词条值查找数据，一般是查找 keyword、数值、日期、boolean 等类型字段。例如：

• ids：根据id进行精确查询
• range：根据数值范围进行查询
• term：按照数据的值进行精确查询

地理（geo）查询：根据经纬度查询。例如：

• geo_distance
• geo_bounding_box

复合（compound）查询：复合查询可以将上述各种查询条件组合起来，合并查询条件。例如：

• bool
• function_score

10.10.1查询所有(match查询)

// 查询所有
GET /索引库名/_search
{
  "query": {
    "match_all": {
    }
  }
}

10.10.2全文检索查询

使用场景：全文检索查询的基本流程如下：

• 对用户搜索的内容做分词，得到词条
• 根据词条去倒排索引库中匹配，得到文档id
• 根据文档id找到文档，返回给用户

因为是拿着词条去匹配，因此参与搜索的字段也必须是可分词的text类型的字段。

• 全文检索查询包括：
  • match 查询：单字段查询
  • multi_match 查询：多字段查询，任意一个字段符合条件就算符合查询条件

match 查询语法如下：

GET /indexName/_search
{
  "query": {
    "match": {
    #一般"FIELD"里面写all，代表全部字段
      "FIELD": "TEXT"
    }
  }
}

mulit_match 查询语法如下：

GET /indexName/_search
{
  "query": {
    "multi_match": {
    #"TEXT"代表要查询的文本
      "query": "TEXT",
      #[]内的是所要查询的字段
      "fields": ["字段1", " 字段2"]
    }
  }
}

• 总结：match方法是将所有字段合并到all字段里面查，而mulit_match 则是在指定的多个字段里面查，当查询的字段越多，效率越低

10.10.3精确查询

精确查询一般是查找 keyword、数值、日期、boolean 等类型字段。所以不会对搜索条件分词。

• term：根据词条精确值查询（地点是广州）
• range：根据值的范围查询（价格在100-200以内…）

term查询

因为精确查询的字段搜是不分词的字段，因此查询的条件也必须是不分词的词条。查询时，用户输入的内容跟自动值完全匹配时才认为符合条件。如果用户输入的内容过多，反而搜索不到数据。

语法如下：

// term查询
GET /indexName/_search
{
  "query": {
    "term": {
      "FIELD": {
      #精确值里不会在进行分词处理
        "value": "精确值"
      }
    }
  }
}

range查询

范围查询，一般应用在对数值类型做范围过滤的时候。比如做价格范围过滤。

语法如下：

// range查询
GET /indexName/_search
{
  "query": {
    "range": {
      "FIELD": {
        "gte": 10, // 这里的gte代表大于等于，gt则代表大于
        "lte": 20 // lte代表小于等于，lt则代表小于
      }
    }
  }
}

• 总结
  • term 查询：根据词条精确匹配，一般搜索 keyword 类型、数值类型、布尔类型、日期类型字段
  • range 查询：根据数值范围查询，可以是数值、日期的范围

10.10.4地理坐标查询

地理坐标查询，其实就是根据经纬度查询，官方文档：https://www.elastic.co/guide/en/elasticsearch/reference/current/geo-queries.html

常见的使用场景包括：

• 携程：搜索我附近的酒店
• 滴滴：搜索我附近的出租车
• 微信：搜索我附近的人

矩形范围查询

矩形范围查询，也就是 geo_bounding_box 查询，查询坐标落在某个矩形范围的所有文档，查询时，需要指定矩形的左上、右下两个点的坐标，然后画出一个矩形，落在该矩形内的都是符合条件的点。

// geo_bounding_box查询
GET /indexName/_search
{
  "query": {
    "geo_bounding_box": {
      "FIELD": {
        "top_left": { // 左上点
          "lat": 31.1,
          "lon": 121.5
        },
        "bottom_right": { // 右下点
          "lat": 30.9,
          "lon": 121.7
        }
      }
    }
  }
}

附近查询

附近查询，也叫做距离查询（geo_distance）：查询到指定中心点小于某个距离值的所有文档

在地图上找一个点作为圆心，以指定距离为半径，画一个圆，落在圆内的坐标都算符合条件：

// geo_distance 查询
GET /indexName/_search
{
  "query": {
    "geo_distance": {
      "distance": "15km", // 半径
      "FIELD": "31.21,121.5" // 圆心
    }
  }
}

10.10.5复合查询

复合（compound）查询：复合查询可以将其它简单查询组合起来，实现更复杂的搜索逻辑。

• fuction score：算分函数查询，可以控制文档相关性算分，控制文档排名
• bool query：布尔查询，利用逻辑关系组合多个其它的查询，实现复杂搜索

相关性算分

TF-IDF 算法（es5.0版本之前）， BM25 算法（es5.0版本之后）

fuction score

• function score 查询中包含四部分内容：

  • 原始查询条件：query 部分，基于这个条件搜索文档，并且基于BM25算法给文档打分，原始算分（query score)
  • 过滤条件：filter 部分，符合该条件的文档才会重新算分
  • 算分函数：符合 filter 条件的文档要根据这个函数做运算，得到的函数算分（function score），有四种函数
    • weight：函数结果是常量
    • field_value_factor：以文档中的某个字段值作为函数结果
    • random_score：以随机数作为函数结果
    • script_score：自定义算分函数算法
  • 运算模式：算分函数的结果、原始查询的相关性算分，两者之间的运算方式，包括：
    • multiply：相乘
    • replace：用 function score 替换 query score
    • sum、avg、max、min

• function score 的运行流程如下：

1. 根据原始条件查询搜索文档，并且计算相关性算分，称为原始算分（query score）
2. 根据过滤条件，过滤文档
3. 符合过滤条件的文档，基于算分函数运算，得到函数算分（function score）
4. 将原始算分（query score）和函数算分（function score）基于运算模式做运算，得到最终结果，作为相关性算分。

• 例如：我们给“如家”这个品牌的酒店排名靠前一些

GET /hotel/_search
{
  "query": {
    "function_score": {
      "query": {  .... }, // 原始查询，可以是任意条件
      "functions": [ // 算分函数
        {
          "filter": { // 满足的条件，品牌必须是如家
            "term": {
              "brand": "如家"
            }
          },
          "weight": 10 // 算分权重为10
        }
      ],
      "boost_mode": "sum" // 加权模式，求和
    }
  }
}

boolean query

布尔查询是一个或多个查询子句的组合，每一个子句就是一个子查询。子查询的组合方式有

• must：必须匹配每个子查询，参与算分，类似“与”
• should：选择性匹配子查询，参与算分，类似“或”
• must_not：必须不匹配，不参与算分，类似“非”
• filter：必须匹配，不参与算分

比如在搜索酒店时，除了关键字搜索外，我们还可能根据品牌、价格、城市等字段做过滤

每一个不同的字段，其查询的条件、方式都不一样，必须是多个不同的查询，而要组合这些查询，就必须用 bool查询了

搜索时，参与打分的字段越多，查询的性能也越差。因此这种多条件查询时，建议这样做

• 搜索框的关键字搜索，是全文检索查询，使用 must 查询，参与算分

• 其它过滤条件，采用 filter 查询，不参与算分

• 例如：搜索名字包含“如家”，价格不高于 400，在坐标 31.21,121.5 周围 10km 范围内的酒店。

  • 名称搜索，属于全文检索查询，应该参与算分，放到 must 中
  • 价格不高于 400，用 range 查询，属于过滤条件，不参与算分，放到 must_not 中
  • 周围 10km 范围内，用 geo_distance 查询，属于过滤条件，不参与算分，放到 filter 中

10.10.6搜索结果处理

排序

elasticsearch 默认是根据相关度算分（_score）来排序，但是也支持自定义方式对搜索结果排序。可以排序字段类型有：keyword 类型（按字母顺序排序）、数值类型、地理坐标类型、日期类型等

• keyword、数值、日期类型排序的语法基本一致

GET /indexName/_search
{
  "query": {
    "match_all": {}
  },
  #sort查询和query查询属于同级
  "sort": [
    {
      "字段名1": "desc"  // 排序字段、排序方式ASC、DESC
    },
    {
      "字段名2": "desc"  // 排序字段、排序方式ASC、DESC
    }
  ]
}

排序条件是一个数组，也就是可以写多个排序条件。按照声明的顺序，当第一个条件相等时，再按照第二个条件排序。

• 地理坐标排序略有不同

GET /indexName/_search
{
  "query": {
    "match_all": {}
  },
  "sort": [
    {
      "_geo_distance" : {
          "FIELD" : "纬度，经度", // 文档中geo_point类型的字段名、目标坐标点
          "order" : "asc", // 排序方式
          "unit" : "km" // 排序的距离单位
      }
    }
  ]
}

举例：

GET /hotel/_search
{
  "query": {
    "match_all": {}
  },
  "sort": [
    {
      "_geo_distance" : {
          "location": "31.034661,121.612282", 
          "order" : "asc", 
          "unit" : "km" 
      }
    }
  ]
}

分页

elasticsearch 默认情况下只返回 top10 的数据。而如果要查询更多数据就需要修改分页参数了。

elasticsearch 通过修改 from、size 参数来控制要返回的分页结果：

• from：从第几个文档开始
• size：总共查询几个文档

类似于mysql中的limit ?, ?

GET /hotel/_search
{
  "query": {
    "match_all": {}
  },
  "from": 0, // 分页开始的位置，默认为0
  "size": 10, // 期望获取的文档总数，默认数值是10
  "sort": [
    {"price": "asc"}
  ]
}

• 深度分页问题

如果要查询990开始的数据，也就是 第990~第1000条 数据。

GET /hotel/_search
{
  "query": {
    "match_all": {}
  },
  "from": 990, // 分页开始的位置，默认为0
  "size": 10, // 期望获取的文档总数
  "sort": [
    {"price": "asc"}
  ]
}

注意：elasticsearch 内部分页时，必须先查询 0~1000条，然后截取其中的 990 ~ 1000 的这10条

• 如果 es 是单点模式，这并无太大影响。但是 elasticsearch 将来一定是集群因此要想获取整个集群的 TOP1000，必须先查询出每个节点的 TOP1000，汇总结果后，重新排名，重新截取 TOP1000。

当查询分页深度较大时，汇总数据过多，对内存和CPU会产生非常大的压力，因此 elasticsearch 会禁止from+ size 超过10000的请求。

针对深度分页，ES提供了两种解决方案，官方文档：

• search after：分页时需要排序，原理是从上一次的排序值开始，查询下一页数据。官方推荐使用的方式。缺点：不过只能向后翻页，不能向前翻页
• scroll：原理将排序后的文档id形成快照，保存在内存。官方已经不推荐使用。缺点：一次性将所有数据保留数据快照，极大消耗内存，而且得到的数据不是实时的。

总结

分页查询的常见实现方案以及优缺点

• from + size
  • 优点：支持随机翻页
  • 缺点：深度分页问题，默认查询上限（from + size）是10000
  • 场景：百度、京东、谷歌、淘宝这样的随机翻页搜索
• search after
  • 优点：没有查询上限（单次查询的size不超过10000）
  • 缺点：只能向后逐页查询，不支持随机翻页
  • 场景：没有随机翻页需求的搜索，例如手机向下滚动翻页
• scroll
  • 优点：没有查询上限（单次查询的size不超过10000）
  • 缺点：会有额外内存消耗，并且搜索结果是非实时的
  • 场景：海量数据的获取和迁移。从ES7.1开始不推荐，建议用 after search方案。

高亮

我们在百度，京东搜索时，关键字会变成红色，比较醒目，这叫高亮显示

高亮显示的实现分为两步：

• 1）给文档中的所有关键字都添加一个标签，例如<em>标签
• 2）页面给<em>标签编写CSS样式

GET /hotel/_search
{
  "query": {
    "match": {
      "字段名": "关键字" // 查询条件，高亮一定要使用全文检索查询，所以这里不可用使用match_all
    }
  },
  "highlight": {
    "fields": { // 指定要高亮的字段
      "字段名": {
        "pre_tags": "<em>",  // 用来标记高亮字段的前置标签
        "post_tags": "</em>" // 用来标记高亮字段的后置标签
        required_field_match=false //加了之后和搜索区域的字段名不一致也能高亮
      }
    }
  }
}

注意：

• 高亮是对关键字高亮，因此搜索条件必须带有关键字，而不能是范围这样的查询。
• 默认情况下，高亮的字段，必须与搜索指定的字段一致（就是match区域和fields的区域里面的字段名要相同），否则无法高亮
• 如果要对非搜索字段高亮，则需要添加一个属性：required_field_match=false

DSL总体结构

10.11RestClient文档查询

10.11.1发起查询请求

@SpringBootTest
public class HotelSearchTest {

    private RestHighLevelClient restHighLevelClient;

    @Autowired
    private IHotelService hotelService;

    @Test
    public void match_All() throws IOException {
        //1.准备request
        SearchRequest request = new SearchRequest("hotel");
        //2.准备DSL
        request.source()
                .query(QueryBuilders.matchAllQuery());
        //3.发送请求得到响应结果
        SearchResponse response = restHighLevelClient.search(request, RequestOptions.DEFAULT);
    }

    @BeforeEach
    void init() {
        this.restHighLevelClient = new RestHighLevelClient(RestClient.builder(
                HttpHost.create("http://192.168.211.128:9200")
        ));
    }

    @AfterEach
    void down() throws IOException {
        this.restHighLevelClient.close();
    }
}

• 第一步，创建SearchRequest对象，指定索引库名

• 第二步，利用request.source()构建 DSL，DSL 中可以包含查询、分页、排序、高亮等

  • query()：代表查询条件，利用 QueryBuilders.matchAllQuery() 构建一个 match_all 查询的 DSL

• 第三步，利用 client.search() 发送请求，得到响应

• 关键API有两个：

  • 一个是 request.source()，其中包含了查询、排序、分页、高亮等所有功能

  

  • 一个是 QueryBuilders，其中包含 match、term、function_score、bool 等各种查询

  

10.11.2解析查询响应

Elasticsearch 返回的结果是一个 JSON 字符串，结构包含

• hits：命中的结果
  • total：总条数，其中的value是具体的总条数值
  • max_score：所有结果中得分最高的文档的相关性算分
  • hits：搜索结果的文档数组，其中的每个文档都是一个 json 对象
    • _source：文档中的原始数据，也是 json 对象

因此，我们解析响应结果，就是逐层解析 JSON 字符串，流程如下

• SearchHits：通过 response.getHits() 获取，就是 json 中的最外层的 hits，代表命中的结果
  • SearchHits.getTotalHits().value：获取总条数信息
  • SearchHits.getHits()：获取 SearchHit 数组，也就是文档数组
    • SearchHit.getSourceAsString()：获取文档结果中的 _source，也就是原始的 json 文档数据

@Test
    public void match_All() throws IOException {
        SearchRequest request = new SearchRequest("hotel");
        request.source()
                .query(QueryBuilders.matchAllQuery());
        SearchResponse response = restHighLevelClient.search(request, RequestOptions.DEFAULT);
        //4.解析响应
        SearchHits searchHits = response.getHits();
        //4.1获取总条数
        System.out.println("hits.getTotalHits().条数 = " + searchHits.getTotalHits().value);
        //4.2获取文档数组
        SearchHit[] hits = searchHits.getHits();
        //4.3遍历文档数组
        for (SearchHit hit : hits) {
            //获取文档source
            String sourceAsString = hit.getSourceAsString();
            //反序列化
            HotelDoc hotelDoc = JSON.parseObject(sourceAsString, HotelDoc.class);
            System.out.println(hotelDoc);
        }
    }

10.11.3match查询

• 例如：QueryBuilders.matchQuery(“all”,“如家”)查询包含如家这个词条的文档数据

10.11.4精确查询

精确查询主要是两者

• term：词条精确匹配
• range：范围查询

10.11.5布尔查询

布尔查询是用 must、must_not、filter等方式组合其它查询，代码示例如下

@Test
void testBool() throws IOException {
    // 1.准备Request
    SearchRequest request = new SearchRequest("hotel");
    // 2.准备DSL
    request.source()
            .query(
        //2.1创建布尔查询
                    QueryBuilders.boolQuery()
        //2.2添加must条件
                            .must(QueryBuilders.termQuery("city", "上海"))
        //2.3添加filter过滤条件
        .filter(QueryBuilders.rangeQuery("price").lte(300))
            );
    // 3.发送请求
    SearchResponse response = restHighLevelClient.search(request, RequestOptions.DEFAULT);
    // 4.解析响应
    SearchHits searchHits = response.getHits();
    System.out.println("hits.getTotalHits().条数 = " + searchHits.getTotalHits().value);
    SearchHit[] hits = searchHits.getHits();
    for (SearchHit hit : hits) {
        String sourceAsString = hit.getSourceAsString();
        HotelDoc hotelDoc = JSON.parseObject(sourceAsString, HotelDoc.class);
        System.out.println(hotelDoc);
    }
}

10.11.6排序和分页

搜索结果的排序和分页是与 query 同级的参数，因此同样是使用 request.source() 来设置。

// 2.准备DSL
    // 2.1.query
    request.source().query(QueryBuilders.matchAllQuery());
    // 2.2.排序 sort
    request.source().sort("price", SortOrder.ASC);
    // 2.3.分页 from、size
    request.source().from((page - 1) * size).size(5);

10.11.7高亮

• 查询的 DSL：其中除了查询条件，还需要添加高亮条件，同样是与 query 同级。
• 结果解析：结果除了要解析 _source 文档数据，还要解析高亮结果

高亮结果解析：

• 第一步：从结果中获取 source。hit.getSourceAsString()，这部分是非高亮结果，json 字符串，需要反序列为 HotelDoc 对象
• 第二步：获取高亮结果。hit.getHighlightFields()，返回值是一个 Map，key 是高亮字段名称，值是HighlightField 对象，代表高亮值
• 第三步：从 map 中根据高亮字段名称，获取高亮字段值对象 HighlightField
• 第四步：从 HighlightField 中获取 Fragments，并且转为字符串。这部分是真正的高亮字符串
• 第五步：用高亮的结果替换 HotelDoc 中的非高亮结果

代码如下：

private void handleResponse(SearchResponse response) {
    // 4.解析响应
    SearchHits searchHits = response.getHits();
    // 4.1.获取总条数
    long total = searchHits.getTotalHits().value;
    System.out.println("共搜索到" + total + "条数据");
    // 4.2.文档数组
    SearchHit[] hits = searchHits.getHits();
    // 4.3.遍历
    for (SearchHit hit : hits) {
        // 获取文档source
        String json = hit.getSourceAsString();
        // ***反序列化***
        HotelDoc hotelDoc = JSON.parseObject(json, HotelDoc.class);
        // 获取高亮结果
        Map<String, HighlightField> highlightFields = hit.getHighlightFields();
        if (!CollectionUtils.isEmpty(highlightFields)) {
            // 根据字段名获取高亮结果
            HighlightField highlightField = highlightFields.get("name");
            if (highlightField != null) {
                // 获取高亮值
                String name = highlightField.getFragments()[0].string();
                // 覆盖非高亮结果
                hotelDoc.setName(name);
            }
        }
        System.out.println("hotelDoc = " + hotelDoc);
    }
}

10.12数据聚合

**聚合（aggregations）**可以让我们极其方便的实现对数据的统计、分析、运算。

聚合常见的有三类

• **桶（Bucket）**聚合：用来对文档做分组
  • TermAggregation：按照文档字段值分组，例如按照品牌值分组、按照国家分组
  • Date Histogram：按照日期阶梯分组，例如一周为一组，或者一月为一组
• **度量（Metric）**聚合：用以计算一些值，比如：最大值、最小值、平均值等
  • Avg：求平均值
  • Max：求最大值
  • Min：求最小值
  • Stats：同时求 max、min、avg、sum 等
• **管道（pipeline）**聚合：其它聚合的结果为基础做聚合

注意：参加聚合的字段必须是keyword、日期、数值、布尔类型

10.12.1Bucket聚合语法

GET /hotel/_search
{
  "size": 0,  // 设置size为0，结果中不包含文档，只包含聚合结果
  "aggs": { // 定义聚合
    "brandAgg": { //给聚合起个名字
      "terms": { // 聚合的类型，按照品牌值聚合，所以选择term
        "field": "brand", // 参与聚合的字段
        "size": 20 // 希望获取的聚合结果数量，默认值为10
      }
    }
  }
}

结果显示：

• 默认情况下，Bucket 聚合会统计 Bucket 内的文档数量，记为 _count，并且按照 _count 降序排序。

• 指定 order 属性，自定义聚合的排序方式

GET /hotel/_search
{
  "size": 0, 
  "aggs": {
    "brandAgg": {
      "terms": {
        "field": "brand",
        "order": {
          "_count": "asc" // 按照_count升序排列
        },
        "size": 20
      }
    }
  }
}

• 默认情况下，Bucket 聚合是对索引库的所有文档做聚合,如果想限制范围，则要添加限制条件

GET /hotel/_search
{
  "query": {
    "range": {
      "price": {
        "lte": 200 // 只对200元以下的文档聚合
      }
    }
  }, 
  "size": 0, 
  "aggs": {
    "brandAgg": {
      "terms": {
        "field": "brand",
        "size": 20
      }
    }
  }
}

• aggs代表聚合，与query同级

10.12.2Metric聚合

对酒店按照品牌分组，形成了一个个桶。现在我们需要对桶内的酒店做运算，获取每个品牌的用户评分的 min、max、avg 等值。

GET /hotel/_search
{
  "size": 0, 
  "aggs": {
    "brandAgg": { 
      "terms": { 
        "field": "brand", 
        "size": 20,
        "order":{
        	"scoreAgg.avg":"desc"//按照查询出来的平均值进行排序
        }
      },
      "aggs": { // 是brands聚合的子聚合，也就是分组后对每组分别计算
        "score_stats": { // 聚合名称，子聚合
          "stats": { // 聚合类型，这里stats可以计算min、max、avg等
            "field": "score" // 聚合字段，这里是score
          }
        }
      }
    }
  }
}

10.12.3RestAPI数据聚合

聚合条件与 query 条件同级别，因此需要使用 request.source() 来指定聚合条件

@Test
public void testAggregation() throws IOException {
	//1.准备request
    SearchRequest request = new SearchRequest("hotel");
//2.准备DSL
request.source().aggregation(AggregationBuilders.terms("聚合名称").field("聚合字段").size(聚合的结果条数));
    SearchResponse response = client.search(request, RequestOptions.DEFAULT);
    Terms brandAgg = response.getAggregations().get("brandAgg");
    List<? extends Terms.Bucket> buckets = brandAgg.getBuckets();
    for (Terms.Bucket bucket : buckets) {
        String key = bucket.getKeyAsString();
        System.out.println("key = " + key);
    }
}

• 聚合的结果也与查询结果不同，API 也比较特殊。不过同样是 JSON 逐层解析

10.13自动补全

当用户在搜索框输入字符时，我们应该提示出与该字符有关的搜索项，提示完整词条的功能，就是自动补全了。

10.13.1拼音分词器

如果我们需要根据拼音字母来推断，因此要用到拼音分词功能。

• 要实现根据字母做补全，就必须对文档按照拼音分词。插件地址：https://github.com/medcl/elasticsearch-analysis-pinyin

• 使用 docker volume inspect es-plugins 查看插件目录，将下载的文件解压上传，重启 Elasticsearch

• 检测是否安装成功：

POST /_analyze
{
  "text": "如家酒店还不错",
  "analyzer": "pinyin"
}

• 得到的结果就是按照拼音对输入的文本进行分割

10.13.2自定义分词器

默认的拼音分词器会将每个汉字单独分为拼音，而我们希望的是每个词条形成一组拼音，需要对拼音分词器做个性化定制，形成自定义分词器。

elasticsearch 中分词器（analyzer）的组成包含三部分：

• character filters：在 tokenizer 之前对文本进行处理。例如删除字符、替换字符
• tokenizer：将文本按照一定的规则切割成词条（term）。例如 keyword，就是不分词；还有 ik_smart
• tokenizer filter：将 tokenizer 输出的词条做进一步处理。例如大小写转换、同义词处理、拼音处理等

文档分词时会依次由这三部分来处理文档：

声明自定义分词器：

PUT /test  //定义一个test库
{
  "settings": {
    "analysis": {
      "analyzer": { // 自定义分词器
        "my_analyzer": {  // 分词器名称
          "tokenizer": "ik_max_word",
          "filter": "py"
        }
      },
      "filter": { // 自定义tokenizer filter
        "py": { // 过滤器名称
          "type": "pinyin", // 过滤器类型，这里是pinyin
          "keep_full_pinyin": false,
          "keep_joined_full_pinyin": true,
          "keep_original": true,
          "limit_first_letter_length": 16,
          "remove_duplicated_term": true,
          "none_chinese_pinyin_tokenize": false
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "name": {
        "type": "text",
        "analyzer": "my_analyzer",
      }
    }
  }
}

使用：

POST /_analyze
{
  "text": "如家酒店还不错",
  "analyzer": "my_analyzer"//自定义的分词器名称
}

注意：因为搜索的时候也用拼音分词器会导致搜索到同音字，所以搜索的时候不要用拼音分词器，创建倒排索引的时候在使用拼音分词器。

10.13.3自动补全查询

elasticsearch 提供了 Completion Suggester 查询来实现自动补全功能。这个查询会匹配以用户输入内容开头的词条并返回；为了提高补全查询的效率，对于文档中字段的类型有一些约束

• 参与补全查询的字段必须是 completion 类型。
• 字段的内容一般是用来补全的多个词条形成的数组。

查询补全的DSL语句：

// 自动补全查询
GET /test/_search
{
  "suggest": {
    "title_suggest": {
      "text": "s", // 关键字
      "completion": { //自动补全类型
        "field": "title", // 补全查询的字段
        "skip_duplicates": true, // 跳过重复的
        "size": 10 // 获取前10条结果
      }
    }
  }
}

• 演示：

// 创建索引库
PUT test
{
  "mappings": {
    "properties": {
      "title":{
        "type": "completion"
      }
    }
  }
}
// 插入示例数据
POST test/_doc
{
  "title": ["Sony", "WH-1000XM3"]
}
POST test/_doc
{
  "title": ["SK-II", "PITERA"]
}
POST test/_doc
{
  "title": ["Nintendo", "switch"]
}

//如果输入关键字是s则会得到三条数据：Sony、SK-II、switch

10.13.4RestAPI实现自动补全

结果解析：

10.14数据同步

elasticsearch 中的数据来自于 mysq l数据库，因此 mysql 数据发生改变时，elasticsearch 也必须跟着改变，这个就是 elasticsearch 与 mysql 之间的数据同步

常见的数据同步方案有三种

• 同步调用
• 异步通知
• 监听 binlog

10.14.1同步调用

• hotel-demo对外提供接口，用来修改 elasticsearch 中的数据
• 酒店管理服务在完成数据库操作后，直接调用 hotel-demo 提供的接口

10.14.2异步通知

• hotel-admin 对 mysql 数据库数据完成增、删、改后，发送 MQ 消息
• hotel-demo监听 MQ，接收到消息后完成 elasticsearch 数据修改

10.14.3监听binlog

• mysql 开启 binlog 功能
• mysql 完成增、删、改操作都会记录在 binlog 中
• hotel-demo 基于canal 监听 binlog 变化，实时更新 elasticsearch 中的内容

10.14.4优缺点

方式一：同步调用

• 优点：实现简单，粗暴
• 缺点：业务耦合度高

方式二：异步通知

• 优点：低耦合，实现难度一般
• 缺点：依赖 mq 的可靠性

方式三：监听binlog

• 优点：完全解除服务间耦合
• 缺点：开启 binlog 增加数据库负担、实现复杂度高

11.Elasticsearch集群

单机的 Elasticsearch 做数据存储，必然面临两个问题：海量数据存储问题、单点故障问题。

解决方案：

• 海量数据存储问题：将索引库从逻辑上拆分为N个分片（shard），存储到多个节点
• 单点故障问题：将分片数据在不同节点备份（replica ）

11.1ES集群相关概念

• 集群（cluster）：一组拥有共同的 cluster name 的 节点。
• 节点（node) ：集群中的一个 Elasticearch 实例
• 分片（shard）：索引可以被拆分为不同的部分进行存储，称为分片。在集群环境下，一个索引的不同分片可以拆分到不同的节点中，解决数据量太大，单点存储量有限的问题。

11.2部署集群

11.2.1搭建Elasticsearch

在单机上利用 Docker （因为容器之间相互独立）容器运行多个 Elasticsearch 实例来模拟集群。

可以直接使用 docker-compose 来完成，这要求你的Linux虚拟机至少有4G以上的内存空间。

• 编写docker-compose.yml（在文本里去描述多个容器的部署方式，从而实现一键部署）

version: '2.2'
services:
  es01:
    image: elasticsearch:7.12.1 //镜像
    container_name: es01  //容器名称
    environment:
      - node.name=es01  //节点名称
      - cluster.name=es-docker-cluster  //集群名称（机器的集群名称一样则会分配到一个集群）
      - discovery.seed_hosts=es02,es03  //另外两个节点的ip地址
      - cluster.initial_master_nodes=es01,es02,es03  //选举主节点
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"  //堆内存大小
    volumes:
      - data01:/usr/share/elasticsearch/data  //数据卷
    ports:
      - 9200:9200  //映射
    networks:
      - elastic
  es02:
    image: elasticsearch:7.12.1
    container_name: es02
    environment:
      - node.name=es02
      - cluster.name=es-docker-cluster
      - discovery.seed_hosts=es01,es03
      - cluster.initial_master_nodes=es01,es02,es03
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
    volumes:
      - data02:/usr/share/elasticsearch/data
    ports:
      - 9201:9200
    networks:
      - elastic
  es03:
    image: elasticsearch:7.12.1
    container_name: es03
    environment:
      - node.name=es03
      - cluster.name=es-docker-cluster
      - discovery.seed_hosts=es01,es02
      - cluster.initial_master_nodes=es01,es02,es03
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
    volumes:
      - data03:/usr/share/elasticsearch/data
    networks:
      - elastic
    ports:
      - 9202:9200
volumes:
  data01:
    driver: local
  data02:
    driver: local
  data03:
    driver: local
networks:
  elastic:
    driver: bridge

修改 Linux 系统权限，修改 /etc/sysctl.conf 文件

vi /etc/sysctl.conf

添加下面的内容

vm.max_map_count=262144

让配置生效：

sysctl -p

通过docker-compose启动集群

docker-compose up -d

11.2.2集群状态监控

kibana 可以监控 Elasticsearch 集群，但是更推荐使用 cerebro

下载解压打开 /bin/cerebro.bat

访问 http://localhost:9000 即可进入管理界面

创建索引库

可以通过 cerebro 创建索引库，当然你需要使用 kibana 也可以。

填写索引库信息

回到首页，即可查看索引库分片效果

11.3集群职责划分

Elasticsearch 中集群节点有不同的职责划分

默认情况下，集群中的任何一个节点都同时兼职上述四种角色。

真实的集群一定要将集群职责分离

• master 节点：对 CPU 要求高，但是内存要求低
• data 节点：对 CPU 和内存要求都高
• coordinating 节点：对网络带宽、CPU 要求高

职责分离可以让我们根据不同节点的需求分配不同的硬件去部署。而且避免业务之间的互相干扰。

11.4集群脑裂问题

脑裂是因为集群中的节点失联导致的。

例如一个集群中，主节点 node1 与其它节点失联，此时node2 和 node3 认为 node1 宕机，就会重新选主。当 node3 当选后，集群继续对外提供服务，node2 和 node3 自成集群，node1 自成集群，两个集群数据不同步，出现数据差异。

当网络恢复后，因为集群中有两个 master 节点，集群状态的不一致，出现脑裂的情况

• 解决方案：要求选票超过 (eligible节点数量+1)/2 才能当选为 master，因此 eligible 节点数量最好是奇数。

• 对应配置项是discovery.zen.minimum_master_nodes，在版本 7.0 以后，已经成为默认配置，因此一般不会发生脑裂问题。

11.5集群分布式存储

当新增文档时，应该保存到不同分片，保证数据均衡，那么 coordinating node 如何确定数据该存储到哪个分片呢？

Elasticsearch 会通过 hash 算法来计算文档应该存储到哪个分片

• _routing 默认是文档的 id
• 算法与分片数量（number_of_shards）有关，因此索引库一旦创建，分片数量不能修改！

新增文档的流程如下图:

1. 新增一个 id=1 的文档
2. 对 id 做 hash 运算，假如得到的是 2，则应该存储到 shard-2
3. shard-2 的主分片在 node3 节点，将数据路由到 node3，node3 保存文档
4. 同步给 shard-2 的副本分片2(R-2)，在 node2 节点
5. 返回结果给 coordinating-node 节点(node1)

11.6集群分布式查询

Elasticsearch 查询分成两个阶段

• scatter phase：分散阶段，coordinating node 会把请求分发到每一个分片。
• gather phase：聚集阶段，coordinating node 汇总 data node 的搜索结果，并处理为最终结果集返回给用户。

11.7集群故障转移

集群的 master 节点会监控集群中的节点状态，如果发现有节点宕机，会立即将宕机节点的分片数据迁移到其它节点，确保数据安全，这个叫做故障转移。

• node1 是主节点，其它两个节点是从节点。突然，node1 发生了故障宕机,后的第一件事，需要重新选主，例如选中了 node2,node2 成为主节点后，会检测集群监控状态，将 node1 上的数据迁移到 node2、node3，确保数据依旧正常访问。

• 当node1重新恢复正常之后，node2节点依旧是主节点，而且nide2节点会将原来node1的数据重新给回给node1

完结…