微服务

什么是微服务
一种良好的分布式架构方案 用于解决大型企业项目开发高耦合的问题
优点：拆分粒度小，服务独立，耦合度低
缺点：架构复杂，运维，监控，部署难度高

微服务结构
微服务结构.png

微服务技术对比

微服务技术对比.png

值得注意的是：
feign定义的接口风格依然是以前的restful风格
而dubbo协议定义的接口风格是不同的dubbo风格

springcloud与springboot版本兼容

springboot与springcloud版本兼容.png

服务远程调用（服务之间发送HTTP请求）

基于RestTemplate发起http请求

1
2
3
4
5
6
7
8
9
10
11
//1.在配置类（可以是启动类）中声明RestTemplate bean对象交给IOC
@Bean
    public RestTemplate restTemplate(){
        return new RestTemplate();
    };
//2.注入依赖
@Autowired
pricate RestTemplate restTemplate;
//3.发起请求
//ex为get请求，并且指定返回的json数据封装为User.class对象，如果发送post请求则为postForObject
User user = restTemplate.getForObject(url, User.class);

Eureka+服务提供者与服务消费者+原理分析

服务提供者与服务消费者

  • 服务提供者：暴露接口
  • 服务消费者：调用接口
  • 两者是相对的
  • 一个服务可以两种身份皆有

Eureka原理分析

  • 消费者获取提供者信息：
    提供者启动时向Eureka注册中心注册自己的信息
    消费者根据提供者名字向Eureka拉取提供者信息

  • 多个提供者选择方案：
    负载均衡算法

  • Eureka注册中心感知提供者状态：
    提供者每30秒向注册中心发送一次心跳请求
    Eureka更新注册列表，剔除心跳不正常的提供者

为什么本机电脑环境变量路径没有指明jdk1.8 spring还是能找到

在Eureka架构中，微服务分为两类：

  • EurekaServer：注册中心，服务端

  • 记录服务信息

  • 心跳监控

  • EurekaClient：客户端

  • Provider：服务提供者，需要注册自己的信息到server端，并且发送心跳

  • consumer：服务消费者，根据服务名称从server中拉取提供者服务，并且可以运用负载均衡

具体代码：

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
//server端
//1.注入依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>
//2.server启动类上加上注解，设定此微服务为注册中心（服务端），并生成对应bean对象
@EnableEurekaServer
//3.配置文件注册提供者信息（将server也注册进去，为未来做集群准备，可能不止一个server，注册可以让不同server之间进行沟通）
server:
  port: 8083 #指定server端口号
#注册提供者信息
spring:
  application:
    name: eurekaserver #注册名称
eureka:
  client:
    service-url:	#eureka-server地址信息
      defaultZone: http://127.0.0.1:8083/eureka 
      
//client端
//1.注入依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
//2.配置文件注册
#注册提供者信息
spring:
  application:
    name: userserver #注册名称
eureka:
  client:
    service-url:	#eureka-server地址信息
      defaultZone: http://127.0.0.1:8083/eureka 
//3.负载均衡
//在RestTemplate上加上注解@LoadBalanced
//4.通过提供者名称发送请求
String url = "http://userserver/user/" + order.getUserId();
User user = restTemplate.getForObject(url, User.class);

负载均衡@LoadBalanced（基于Ribbon）

负载均衡原理

ribbon负载均衡流程.png

值得注意的是：
全部基于@LoadBalanced注解
先由LoadBalancerInterceptor拦截器将请求拦截下来，通过方法getHost（）获取其中的userservice交给RibbonLoadBanlancerClient，通过方法getLoadBalancer（）将id，userservice传给DynamicServerListLoadBalancer，并由他拉取userservice服务回到RibbonLoadBanlancerClient，调用方法getServer（）调用IRule进行负载均衡，得到单个server的地址

IRule负载均衡默认算法是：ZoneAvoidanceRule：（本质就是轮询算法，在轮询之前先选择区域）

Zone可以理解为一个机房，一个机架等区域，然后再对Zone内的多个服务进行轮询

自定义IRule规则

方法一：

1
2
3
4
5
6
//配置类或者启动类中加入
@Bean
public IRule randomRule(){
	return new RandomRule();
}
//全局配置，所有请求的提供服务都改成了随机调度

方法二：

1
2
3
4
5
#yml配置文件中加入
userservice: #指定提供者名字
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule #自定请求对应提供者时采用的方法
#指定配置，但是更改时不用重新打包

饥饿加载

Ribbon默认采用懒加载，只有在第一次访问时，LoadBlanceClient才会创建，饥饿加载则是在项目启动时就创建了一个新的LoadBlanceClient，降低了第一次访问的耗时

1
2
3
4
5
6
#yml配置文件中加入
ribbon:
  eager-load:
    enabled: true #开启饥饿加载
    clients: #指定饥饿加载的服务名称(列表)
      - userservice

Nacos

首先需要下载nacos的包，作为服务端启动（相当于Eureka的注册中心，服务端，在Eureka中需要自己新建一个服务（模块），并在启动类上声明@EnableEurekaServer为注册中心server）

1
2
3
4
#windows启动方式
startup.cmd -m standalone
#linux启动方式
sh startup.sh -m standalone

Nacos服务注册与发现

1.微服务中注入依赖

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<!-- nacos客户端依赖包 -->
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
        </dependency>
<!-- 父文件中进行版本管理 -->
<!-- nacos配置依赖 管理版本 -->
<dependencyManagement>
            <dependency>
                <groupId>com.alibaba.cloud</groupId>
                <artifactId>spring-cloud-alibaba-dependencies</artifactId>
                <version>2.2.5.RELEASE</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
</dependencyManagement>

2.配置nacos地址

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

3.其他配置（比如负载均衡，饥饿加载，自定义负载均衡IRule规则，调用方式（服务名），服务名定义）都不用更改，与Eureka都支持这些配置

Nacos服务多级存储模型

多级模型：

  • 一级是服务，如userservice
  • 二级是实例集群（多实例集合，以地点划分为多），比如杭州
  • 三级是实例，例如杭州某台服务器上部署了userservice

设置实例集群属性：

1
2
3
4
5
6
7
spring:
  cloud:
    nacos:
      server-addr: localhost:8848 #默认地址
      discovery: 
        cluster-name: HZ #配置集群名称（在提供服务上配置） 集群---服务，多个服务实例集合，一般以地点区域划分

Nacos集群内部负载均衡

1
2
3
4
#yml配置文件中加入
userservice: #指定服务名字
  ribbon:
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule #优先选择集群内部服务列表（所有集群内部服务都挂掉才会跨集群请求，并且会黄色警告） 采用随机策略

NacosRule负载均衡策略：
优先选择本地集群实例列表
本地集群找不到提供者实例，才会跨集群请求实例列表，并且黄色警告
拿到实例列表后，采取随机负载均衡策略进行选择

Nacos服务权重设置

  • nacos控制台可以设置实例的权重值，0~1
  • 权重越大，访问的可能性越高
  • 权重设置为0完全不会被访问（一般会用于不停机逐步更新）

Nacos环境隔离

1.在nacos控制台新建一个命名空间
2.将服务配置到指定命名空间

1
2
3
4
5
6
7
8
spring:
  cloud:
    nacos:
      server-addr: localhost:8848 #默认地址
      discovery: 
        cluster-name: HZ #配置集群名称（在提供服务上配置） 集群---服务，多个服务实例集合，一般以地点区域划分
        namespace: uuid #命名空间id 一般为自动生成的uuid

namespace用来做环境隔离
每个namespace都有唯一id（一般为自动生成的uuid）
不同namespace下的服务不可见（不能跨空间访问）

Nacos过程

nacos服务过程.png

Nacos中的临时实例与非临时实例

默认服务都是临时实例

修改为非临时实例：

1
2
3
4
5
6
7
8
9
10

spring:
  cloud:
    nacos:
      server-addr: localhost:8848 #默认地址
      discovery: 
        cluster-name: HZ #配置集群名称（在提供服务上配置） 集群---服务，多个服务实例集合，一般以地点区域划分
        namespace: uuid #命名空间id 一般为自动生成的uuid
        ephemeral: false #默认为true->临时实例

Nacos与Eureka对比

共同点：

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

不同点：

  • Nacos支持服务端主动检测提供者状态：临时实例采取心跳模式，非临时实例采取主动检测（一般不建议采取非临时实例，服务器压力大）
  • 临时实例不健康直接剔除，非临时实例不健康不会剔除
  • Nacos支持服务列表变更的消息推送模式，列表更改立即通知消费者（Eureka会在请求提供者服务列表之后在本地维持缓存（Nacos也会），但是每隔30s拉取一次列表，列表更改并不能立即发现）
  • Nacos默认采取AP模式，当集群中存在非临时实例采取CP模式，Eureka默认开去AP模式

Nacos配置管理

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

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

1.在配置列表添加配置文件（注意：配置文件只会在同一命名空间下生效）

2.填写配置信息
data ID格式：服务名称-profile.yaml(或者.properties) （profile是命名空间） ex：userservice-dev.yaml
group: 默认即可
配置格式：目前仅支持yaml和properties

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

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

1）引入nacos-config依赖

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

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

2）添加bootstrap.yaml

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

1
2
3
4
5
6
7
8
9
10
spring:
  application:
    name: userservice # 服务名称
  profiles:
    active: dev #开发环境，这里是dev 
  cloud:
    nacos:
      server-addr: localhost:8848 # Nacos地址
      config:
        file-extension: yaml # 文件后缀名

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

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

3）读取nacos配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
@Slf4j
@RestController
@RequestMapping("/user")
public class UserController {

    @Autowired
    private UserService userService;

    @Value("${pattern.dateformat}")
    private String dateformat; //读取配置文件数据
    
    @GetMapping("now")
    public String now(){
        return LocalDateTime.now().format(DateTimeFormatter.ofPattern(dateformat));
    }
    // ...略
}

配置热更新

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

方式一

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

方式二

使用@ConfigurationProperties注解代替@Value注解。

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

1
2
3
4
5
6
7

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

在controller中通过注入调用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

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

    @Autowired
    private UserService userService;

    @Autowired
    private PatternProperties patternProperties;

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

    // 略
}

配置共享

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

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

  • [spring.application.name].yaml，例如：userservice.yaml

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

配置共享的优先级

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

服务名-profile.yaml>服务名.yaml>本地配置文件

搭建Nacos集群

nacos集群.png

过程：

  • 消费者服务向注册中心发送请求
  • Nginx中心获取请求并且做反向代理，做负载均衡，选取Nacos服务器
  • 通过主从数据库实现Nacos服务消息统一

Feign

Feign是一个声明式的http客户端

Feign替代RestTemplate

Fegin的使用步骤如下：

1）引入依赖

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

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

2）添加注解

在order-service的启动类添加注解@EnableFeignClients开启Feign的功能.（imports自动配置）

3）编写Feign的客户端

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

1
2
3
4
5
6

@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）总结

使用Feign的步骤：

① 引入依赖

② 添加@EnableFeignClients注解

③ 编写FeignClient接口

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

自定义配置

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

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

一般情况下，默认值就能满足我们使用，如果要自定义时，只需要创建自定义的@Bean覆盖默认Bean即可。

下面以日志为例来演示如何自定义配置。

配置文件方式

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

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

也可以针对所有服务：

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

而日志的级别分为四种：

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

Java代码方式

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

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

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

1
@EnableFeignClients(defaultConfiguration = DefaultFeignConfiguration .class)

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

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

Feign使用优化

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

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

•Apache HttpClient ：支持连接池

•OKHttp：支持连接池

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

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

1）引入依赖

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

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

2）配置连接池

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

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

连接池参数，如最大连接数需要在实际过程中进行实际校验得出

总结，Feign的优化：

1.日志级别尽量用basic（或者None）

2.使用HttpClient或OKHttp代替URLConnection

① 引入feign-httpClient依赖

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

最佳实践

所谓最近实践，就是使用过程中总结的经验，最好的一种使用方式。

解决问题：Feign的客户端与服务提供者的controller代码非常相似（重复编写）

继承方式

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

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

2）Feign客户端和Controller都集成改接口

优点：

  • 简单
  • 实现了代码共享

缺点：

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

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

企业中这种方式应用的还是挺多的

抽取方式

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

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

核心就是：提供一个访问对应服务的feign-api-http客户端，消费者服务只需要引入这个api即可简化请求过程

实现基于抽取的最佳实践

1）抽取

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

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

然后，order-service中编写的UserClient、User、DefaultFeignConfiguration都复制到feign-api项目中

2）在order-service中使用feign-api

首先，删除order-service中的UserClient、User、DefaultFeignConfiguration等类或接口。

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

1
2
3
4
5
<dependency>
    <groupId>cn.itcast.demo</groupId>
    <artifactId>feign-api</artifactId>
    <version>1.0</version>
</dependency>

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

3）解决扫描包问题

order-service的@EnableFeignClients注解是在cn.itcast.order包下，不在同一个包，无法扫描到UserClient。

方式一：

指定Feign应该扫描的包：

1
2
//启动类中
@EnableFeignClients(basePackages = "cn.itcast.feign.clients")

方式二：

指定需要加载的Client接口：

1
2
//启动类中
@EnableFeignClients(clients = {UserClient.class})

Gateway服务网关

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

为什么需要网关

Gateway网关是我们服务的守门神，所有微服务的统一入口。

网关的核心功能特性：

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

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

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

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

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

  • gateway
  • zuul

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

gateway快速入门

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

  1. 创建SpringBoot工程gateway，引入网关依赖
  2. 编写启动类
  3. 编写基础配置和路由规则
  4. 启动网关服务进行测试

1）创建gateway模块，引入依赖

创建网关模块

引入依赖：

1
2
3
4
5
6
7
8
9
10
<!--网关-->
<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）编写启动类

1
2
3
4
5
6
7
@SpringBootApplication
public class GatewayApplication {

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

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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/开头就符合要求

网关服务依然要交给Nacos注册中心管理
我们将符合Path 规则的一切请求，都代理到 uri参数指定的地址。
本例中，我们将 /user/**开头的请求，代理到lb://userservice，lb是负载均衡，根据服务名拉取服务列表，实现负载均衡。

4）网关路由的流程图

整个访问的流程如下：

gateway访问过程.png

总结：

网关搭建步骤：

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

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

路由配置包括：

  1. 路由id：路由的唯一标示(自定义)

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

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

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

断言工厂

我们在配置文件中写的断言规则只是字符串，这些字符串会被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必须是指定范围 多用来限制IP访问 - RemoteAddr=192.168.1.1/24
Weight 权重处理

过滤器

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

gateway过滤器过程.png

入：先路由再过滤
出：先过滤再路由出去
可以有多个过滤器

路由过滤器的种类

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

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

过滤器使用

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

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

当前过滤器写在userservice路由下，因此仅仅对访问userservice的请求有效。
并且该过滤器中的Truth, Itcast is freaking awesome!等价于添加请求头Truth=Itcast is freaking awesome!

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

1
2
3
4
5
6
7
8
9
10
spring:
  cloud:
    gateway:
      routes:
      - id: user-service 
        uri: lb://userservice 
        predicates: 
        - Path=/user/**
      default-filters: # 默认过滤项
      - AddRequestHeader=Truth, Itcast is freaking awesome!

总结：

过滤器的作用是什么？

① 对路由的请求或响应做加工处理，比如添加请求头

② 配置在路由下的过滤器只对当前路由的请求生效

defaultFilters的作用是什么？

① 对所有路由都生效的过滤器

全局过滤器

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

全局过滤器作用

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

定义方式是实现GlobalFilter接口。

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

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

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

自定义全局过滤器

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

  • 参数中是否有authorization，

  • authorization参数值是否为admin

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

实现：

在gateway中定义一个过滤器：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

@Order(-1) //指定全局过滤器优先级 
@Component //需要交给IOC容器管理
public class AuthorizeFilter implements GlobalFilter {
    @Override
    //exchange是请求消息
    //chain是过滤器链
    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();
    }
}

过滤器执行顺序

请求进入网关会碰到三类过滤器：当前路由的过滤器、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排序，组织过滤器链

为什么这三者可以放在一个过滤器链中？
defaultFilter和路由过滤器本质都是GatewayFilter，并且GlobalFilter可以通过GatewayFilterAdapter适配成GatewayFilter，所以可以组织

跨域问题

什么是跨域问题

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

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

解决跨域问题

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
spring:
  cloud:
    gateway:
      # 。。。
      #和routes同级
      globalcors: # 全局的跨域处理
        #options请求---浏览器请求服务器让不让这次访问通过
        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 # 这次跨域检测的有效期

初识Docker

什么是Docker

应用部署的环境问题

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

  • 依赖关系复杂，容易出现兼容性问题

  • 开发、测试、生产环境有差异

例如一个项目中，部署时需要依赖于node.js、Redis、RabbitMQ、MySQL等，这些服务部署时所需要的函数库、依赖项各不相同，甚至会有冲突。给部署带来了极大的困难。

Docker解决依赖兼容问题

而Docker确巧妙的解决了这些问题，Docker是如何实现的呢？

Docker为了解决依赖的兼容问题的，采用了两个手段：

  • 将应用的Libs（函数库）、Deps（依赖）、配置与应用一起打包

  • 将每个应用放到一个隔离容器去运行，避免互相干扰

这样打包好的应用包中，既包含应用本身，也保护应用所需要的Libs、Deps，无需再操作系统上安装这些，自然就不存在不同应用之间的兼容问题了。

虽然解决了不同应用的兼容问题，但是开发、测试等环境会存在差异，操作系统版本也会有差异，怎么解决这些问题呢？

Docker解决操作系统环境差异

要解决不同操作系统环境差异问题，必须先了解操作系统结构。以一个Ubuntu操作系统为例，结构如下：

结构包括：

  • 计算机硬件：例如CPU、内存、磁盘等
  • 系统内核：所有Linux发行版的内核都是Linux，例如CentOS、Ubuntu、Fedora等。内核可以与计算机硬件交互，对外提供内核指令，用于操作计算机硬件。
  • 系统应用：操作系统本身提供的应用、函数库。这些函数库是对内核指令的封装，使用更加方便。

应用与计算机交互的流程如下：

1）应用调用操作系统应用（函数库），实现各种功能

2）系统函数库是对内核指令集的封装，会调用内核指令

3）内核指令操作计算机硬件

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

  • Docker将用户程序与所需要调用的系统(比如Ubuntu)函数库一起打包
  • Docker运行到不同操作系统时，直接基于打包的函数库，借助于操作系统的Linux内核来运行

小结：

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

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

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

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

Docker是一个快速交付应用、运行应用的技术，具备下列优势：

  • 可以将程序及其依赖、运行环境一起打包为一个镜像，可以迁移到任意Linux操作系统
  • 运行时利用沙箱机制形成隔离容器，各个应用互不干扰
  • 启动、移除都可以通过一行命令完成，方便快捷

Docker和虚拟机的区别

Docker可以让一个应用在任何操作系统中非常方便的运行。而以前我们接触的虚拟机，也能在一个操作系统中，运行另外一个操作系统，保护系统中的任何应用。

虚拟机（virtual machine）是在操作系统中模拟硬件设备，然后运行另一个操作系统，比如在 Windows 系统里面运行 Ubuntu 系统，这样就可以运行任意的Ubuntu应用了。

Docker仅仅是封装函数库，并没有模拟完整的操作系统

小结：

Docker和虚拟机的差异：

  • docker是一个系统进程；虚拟机是在操作系统中的操作系统

  • docker体积小、启动速度快、性能好；虚拟机体积大、启动速度慢、性能一般

镜像和容器

Docker中有几个重要的概念：

镜像（Image）：Docker将应用程序及其所需的依赖、函数库、环境、配置等文件打包在一起，称为镜像。

容器（Container）：镜像中的应用程序运行后形成的进程就是容器，只是Docker会给容器进程做隔离，对外不可见。

一切应用最终都是代码组成，都是硬盘中的一个个的字节形成的文件。只有运行时，才会加载到内存，形成进程。

而镜像，就是把一个应用在硬盘上的文件、及其运行环境、部分系统函数库文件一起打包形成的文件包。这个文件包是只读的。

容器呢，就是将这些文件中编写的程序、函数加载到内存中允许，形成进程，只不过要隔离起来。

因此一个镜像可以启动多次，形成多个容器进程。

DockerHub

开源应用程序非常多，打包这些应用往往是重复的劳动。为了避免这些重复劳动，人们就会将自己打包的应用镜像，例如Redis、MySQL镜像放到网络上，共享使用，就像GitHub的代码共享一样。

  • DockerHub：DockerHub是一个官方的Docker镜像的托管平台。这样的平台称为Docker Registry。

  • 国内也有类似于DockerHub 的公开服务，比如 网易云镜像服务、阿里云镜像库等。

Docker架构

我们要使用Docker来操作镜像、容器，就必须要安装Docker。

Docker是一个CS架构的程序，由两部分组成：

  • 服务端(server)：Docker守护进程，负责处理Docker指令，管理镜像、容器等

  • 客户端(client)：通过命令或RestAPI向Docker服务端发送指令。可以在本地或远程向服务端发送指令。

如图：

Docker架构.png

Docker的基本操作

自己测试需要把防火墙关闭一下（实际环境不可以乱关闭防火墙）

1
2
3
4
#关闭防火墙
systemctl stop firewalld
#禁止开机自启动 
systemctl disable firewalld
1
2
3
4
#针对docker-server 
systemctl start docker #启动
systemctl stop docker #停止
systemctl restart docker #重新启动

镜像操作

镜像名称

首先来看下镜像的名称组成：

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

mysql:5.7

这里的mysql就是repository，5.7就是tag，合一起就是镜像名称，代表5.7版本的MySQL镜像。

镜像命令

常见的镜像操作命令如图：

镜像操作.png

案例-镜像拉取、查看镜像

需求：从DockerHub中拉取一个nginx镜像并查看

1）首先去镜像仓库搜索nginx镜像，比如DockerHub:

2）根据查看到的镜像名称，拉取自己需要的镜像，通过命令：

1
docker pull nginx

3）通过命令： 查看拉取到的镜像

1
docker images

案例-保存、导入镜像

需求：利用docker save将nginx镜像导出磁盘，然后再通过load加载回来

1）利用docker xx –help命令查看docker save和docker load的语法

例如，查看save命令用法，可以输入命令：

1
docker save --help

命令格式：

1
docker save -o [保存的目标文件名称] [镜像名称]

2）使用docker save导出镜像到磁盘

运行命令：

1
docker save -o nginx.tar nginx:latest

3）使用docker load加载镜像

先删除本地的nginx镜像：

1
docker rmi nginx:latest

4）然后运行命令，加载本地文件：

1
docker load -i nginx.tar

容器操作

容器相关命令

容器操作的命令如图：

容器操作.png

容器保护三个状态：

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

其中：

  • docker run：创建并运行一个容器，处于运行状态

  • docker pause：让一个运行的容器暂停

  • docker unpause：让一个容器从暂停状态恢复运行

  • docker stop：停止一个运行的容器

  • docker start：让一个停止的容器再次运行

  • docker rm：删除一个容器

创建并运行一个容器

创建并运行nginx容器的命令：

1
docker run --name containerName -p 80:80 -d nginx

命令解读：

  • docker run ：创建并运行一个容器
  • –name : 给容器起一个名字，比如叫做mn
  • -p ：将宿主机端口与容器端口映射，冒号左侧是宿主机端口，右侧是容器端口
  • -d：后台运行容器
  • nginx：镜像名称，例如nginx
  • -e：指定运行环境，比如指定mysql密码

这里的-p参数，是将容器端口映射到宿主机端口。

默认情况下，容器是隔离环境，我们直接访问宿主机的80端口，肯定访问不到容器中的nginx。
现在，将容器的80与宿主机的80关联起来，当我们访问宿主机的80端口时，就会被映射到容器的80，这样就能访问到nginx了

案例-进入容器，修改文件

需求：进入Nginx容器，修改HTML文件内容

步骤：

1）进入容器。进入我们刚刚创建的nginx容器的命令为：

1
docker exec -it mn bash

命令解读：

  • docker exec ：进入容器内部，执行一个命令

  • -it : 给当前进入的容器创建一个标准输入、输出终端，允许我们与容器交互

  • mn ：要进入的容器的名称

  • bash：进入容器后执行的命令，bash是一个linux终端交互命令

2）进入nginx的HTML所在目录 /usr/share/nginx/html

我们执行命令，进入该目录：

1
cd /usr/share/nginx/html

3）修改index.html的内容

容器内没有vi命令，无法直接修改，我们用下面的命令来修改：

1
sed -i -e 's#Welcome to nginx#传智教育欢迎您#g' -e 's#<head>#<head><meta charset="utf-8">#g' index.html

上述进入容器修改文件的方法并不多用，很麻烦，并且不存在日志记录

容器相关的一些操作

查看容器日志的命令：

  • docker logs
  • 添加 -f 参数可以持续查看日志

查看容器状态：

  • docker ps
  • docker ps -a 查看所有容器，包括已经停止的

查看文件内容：

  • cat 文件名.后缀

查看文件夹下文件：

  • ls

帮助：

  • 指令 –help

数据卷（容器数据管理）

数据卷的作用：

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

什么是数据卷

数据卷（volume）是一个虚拟目录，指向宿主机文件系统中的某个目录。

一旦完成数据卷挂载，对容器的一切操作都会作用在数据卷对应的宿主机目录了。

数据集操作命令

数据卷操作的基本语法如下：

1
docker volume [COMMAND]

docker volume命令是数据卷操作，根据命令后跟随的command来确定下一步的操作：

  • create 创建一个volume
  • inspect 显示一个或多个volume的信息
  • ls 列出所有的volume
  • prune 删除未使用的volume
  • rm 删除一个或多个指定的volume

创建和查看数据卷

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

① 创建数据卷

1
docker volume create html #数据卷名字是html

② 查看所有数据卷

1
docker volume ls

③ 查看数据卷详细信息卷

1
docker volume inspect html

挂载数据卷

我们在创建容器时，可以通过 -v 参数来挂载一个数据卷到某个容器内目录，命令格式如下：

1
2
3
4
5
docker run \ #\为换行符
  --name mn \
  -v html:/root/html \
  -p 8080:80
  nginx \

这里的-v就是挂载数据卷的命令：

  • -v html:/root/htm ：把html数据卷挂载到容器内的/root/html这个目录中

案例-给nginx挂载数据卷

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

步骤：

① 创建容器并挂载数据卷到容器内的HTML目录

1
2
docker run --name mn -v html:/usr/share/nginx/html -p 80:80 -d nginx
#如果没有数据卷html 会自动创建

② 进入html数据卷所在位置，并修改HTML内容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 查看html数据卷的位置
docker volume inspect html
# 进入该目录
cd /var/lib/docker/volumes/html/_data
# 修改文件
vi index.html
#退出文件
#Esc回到命令行模式
:wq#保存退出
#:w 保存但不退出
#:wq 保存并退出
#:q 退出
#:q! 强制退出，不保存
#:e! 放弃所有修改，从上次保存文件开始再编辑命令历史

案例-给MySQL挂载本地目录

容器不仅仅可以挂载数据卷，也可以直接挂载到宿主机目录上。关联关系如下：

  • 带数据卷模式：宿主机目录 –> 数据卷 —> 容器内目录
  • 直接挂载模式：宿主机目录 —> 容器内目录

语法：

目录挂载与数据卷挂载的语法是类似的：

  • -v [宿主机目录]:[容器内目录]
  • -v [宿主机文件]:[容器内文件]

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

实现思路如下：

1）在将课前资料中的mysql.tar文件上传到虚拟机，通过load命令加载为镜像

2）创建目录/tmp/mysql/data

3）创建目录/tmp/mysql/conf，将课前资料提供的hmy.cnf文件上传到/tmp/mysql/conf

4）去DockerHub查阅资料，创建并运行MySQL容器，要求：

① 挂载/tmp/mysql/data到mysql容器内数据存储目录

② 挂载/tmp/mysql/conf/hmy.cnf到mysql容器的配置文件

③ 设置MySQL密码

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

Dockerfile自定义镜像

镜像结构

镜像是将应用程序及其需要的系统函数库、环境、配置、依赖打包而成。

我们以MySQL为例，来看看镜像的组成结构：

简单来说，镜像就是在系统函数库、运行环境基础上，添加应用程序文件、配置文件、依赖文件等组合，然后编写好启动脚本打包在一起形成的文件。

我们要构建镜像，其实就是实现上述打包的过程。

Dockerfile语法

构建自定义的镜像时，并不需要一个个文件去拷贝，打包。

我们只需要告诉Docker，我们的镜像的组成，需要哪些BaseImage、需要拷贝什么文件、需要安装什么依赖、启动脚本是什么，将来Docker会帮助我们构建镜像。

而描述上述信息的文件就是Dockerfile文件。

Dockerfile就是一个文本文件，其中包含一个个的**指令(Instruction)**，用指令来说明要执行什么操作来构建镜像。每一个指令都会形成一层Layer。

Dockerfile基本指令.png

基于Ubuntu构建Java项目

需求：基于Ubuntu镜像构建一个新镜像，运行一个java项目

  • 步骤1：新建一个空文件夹docker-demo

  • 步骤2：拷贝课前资料中的docker-demo.jar文件到docker-demo这个目录

  • 步骤3：拷贝课前资料中的jdk8.tar.gz文件到docker-demo这个目录

  • 步骤4：拷贝课前资料提供的Dockerfile到docker-demo这个目录

    其中的内容如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# 指定基础镜像
FROM ubuntu:16.04
# 配置环境变量，JDK的安装目录
ENV JAVA_DIR=/usr/local

# 拷贝jdk和java项目的包
COPY ./jdk8.tar.gz $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

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

  • 步骤5：进入docker-demo

    将准备好的docker-demo上传到虚拟机任意目录，然后进入docker-demo目录下

  • 步骤6：运行命令：

1
docker build -t javaweb:1.0 . #.指定Dockerfile所在目录为当前目录（在Dockerfile所在目录运行这条指令）

基于java8构建Java项目

虽然我们可以基于Ubuntu基础镜像，添加任意自己需要的安装包，构建镜像，但是却比较麻烦。所以大多数情况下，我们都可以在一些安装了部分软件的基础镜像上做改造。

例如，构建java项目的镜像，可以在已经准备了JDK的基础镜像基础上构建。

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

实现思路如下：

  • ① 新建一个空的目录，然后在目录中新建一个文件，命名为Dockerfile

  • ② 拷贝课前资料提供的docker-demo.jar到这个目录中

  • ③ 编写Dockerfile文件：

    • a ）基于java:8-alpine作为基础镜像

    • b ）将app.jar拷贝到镜像中

    • c ）暴露端口

    • d ）编写入口ENTRYPOINT

      内容如下：

1
2
3
4
FROM java:8-alpine #可能要改成openjdk:8-alpine
COPY ./app.jar /tmp/app.jar
EXPOSE 8090
ENTRYPOINT java -jar /tmp/app.jar

  • ④ 使用docker build命令构建镜像

  • ⑤ 使用docker run创建容器并运行

注意：

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

Docker-Compose

Docker Compose可以基于Compose文件帮我们快速的部署分布式应用，而无需手动一个个创建和运行容器！

初识DockerCompose

Compose文件是一个文本文件，通过指令定义集群中的每个容器如何运行。格式如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
version: "3.8"
 services:
  mysql:
    image: mysql:5.7.25
    environment:
     MYSQL_ROOT_PASSWORD: 123 
    volumes:
     - "/tmp/mysql/data:/var/lib/mysql"
     - "/tmp/mysql/conf/hmy.cnf:/etc/mysql/conf.d/hmy.cnf"
  web:
    build: .
    ports:
     - "8090:8090"

上面的Compose文件就描述一个项目，其中包含两个容器：

  • mysql：一个基于mysql:5.7.25镜像构建的容器，并且挂载了两个目录
  • web：一个基于docker build临时构建的镜像容器，映射端口时8090

DockerCompose的详细语法参考官网：https://docs.docker.com/compose/compose-file/
其实DockerCompose文件可以看做是将多个docker run命令写到一个文件，只是语法稍有差异。

案例-部署微服务集群

需求：将之前学习的cloud-demo微服务集群利用DockerCompose部署

实现思路：

① 查看课前资料提供的cloud-demo文件夹，里面已经编写好了docker-compose文件

② 修改自己的cloud-demo项目，将数据库、nacos地址都命名为docker-compose中的服务名

③ 使用maven打包工具，将项目中的每个微服务都打包为app.jar

④ 将打包好的app.jar拷贝到cloud-demo中的每一个对应的子目录中

⑤ 将cloud-demo上传至虚拟机，利用 docker-compose up -d 来部署

compose文件

docker-compose内容如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
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: 123
    volumes:
      - "$PWD/mysql/data:/var/lib/mysql"
      - "$PWD/mysql/conf:/etc/mysql/conf.d/"
  userservice:
    build: ./user-service
  orderservice:
    build: ./order-service
  gateway:
    build: ./gateway
    ports:
      - "10010:10010"

可以看到，其中包含5个service服务：

  • nacos：作为注册中心和配置中心
    • image: nacos/nacos-server： 基于nacos/nacos-server镜像构建
    • environment：环境变量
      • MODE: standalone：单点模式启动
    • ports：端口映射，这里暴露了8848端口
  • mysql：数据库
    • image: mysql:5.7.25：镜像版本是mysql:5.7.25
    • environment：环境变量
      • MYSQL_ROOT_PASSWORD: 123：设置数据库root账户的密码为123
    • volumes：数据卷挂载，这里挂载了mysql的data、conf目录，其中有我提前准备好的数据
  • userservice、orderservice、gateway：都是基于Dockerfile临时构建的

查看微服务目录，可以看到都包含Dockerfile文件：

内容如下：

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

修改微服务配置

因为微服务将来要部署为docker容器，而容器之间互联不是通过IP地址，而是通过容器名。这里我们将order-service、user-service、gateway服务的mysql、nacos地址都修改为基于容器名的访问。

如下所示：

1
2
3
4
5
6
7
8
9
10
11
spring:
  datasource:
    url: jdbc:mysql://mysql:3306/cloud_order?useSSL=false
    username: root
    password: 123
    driver-class-name: com.mysql.jdbc.Driver
  application:
    name: orderservice
  cloud:
    nacos:
      server-addr: nacos:8848 # nacos服务地址

打包

接下来需要将我们的每个微服务都打包。因为之前查看到Dockerfile中的jar包名称都是app.jar，因此我们的每个微服务都需要用这个名称。

可以通过修改pom.xml中的打包名称来实现，每个微服务都需要修改：

1
2
3
4
5
6
7
8
9
10
<build>
  <!-- 服务打包的最终名称 -->
  <finalName>app</finalName>
  <plugins>
    <plugin>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-maven-plugin</artifactId>
    </plugin>
  </plugins>
</build>

拷贝jar包到部署目录

编译打包好的app.jar文件，需要放到Dockerfile的同级目录中。注意：每个微服务的app.jar放到与服务名称对应的目录，别搞错了。

部署

最后，我们需要将文件整个cloud-demo文件夹上传到虚拟机中，由DockerCompose部署。

部署：

进入cloud-demo目录，然后运行下面的命令：

1
docker-compose up -d

Docker镜像仓库

搭建私有镜像仓库

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

1
2
3
4
5
6
7
8
# 打开要修改的文件
vi /etc/docker/daemon.json
# 添加内容：ip为虚拟机ip 
"insecure-registries":["http://192.168.150.101:8080"]
# 重加载
systemctl daemon-reload
# 重启docker
systemctl restart docker

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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

推送、拉取镜像

推送镜像到私有镜像服务必须先tag，步骤如下：

① 重新tag本地镜像，名称前缀为私有仓库的地址：192.168.150.101:8080/

1
docker tag nginx:latest 192.168.150.101:8080/nginx:1.0

② 推送镜像

1
docker push 192.168.150.101:8080/nginx:1.0

③ 拉取镜像

1
docker pull 192.168.150.101:8080/nginx:1.0

MQ

同步通讯

同步调用的优点：

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

同步调用的问题：

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

异步通讯

为了解除事件发布者与订阅者之间的耦合，两者并不是直接通信，而是有一个中间人（Broker）。发布者发布事件到Broker，不关心谁来订阅事件。订阅者从Broker订阅事件，不关心谁发来的消息。

好处：

  • 吞吐量提升：无需等待订阅者处理完成，响应更快速

  • 故障隔离：服务没有直接调用，不存在级联失败问题

  • 调用间没有阻塞，不会造成无效的资源占用

  • 耦合度极低，每个服务都可以灵活插拔，可替换

  • 流量削峰：不管发布事件的流量波动多大，都由Broker接收，订阅者可以按照自己的速度去处理事件

缺点：

  • 架构复杂了，业务没有明显的流程线，不好管理
  • 需要依赖于Broker的可靠、安全、性能

技术对比

MQ，中文是消息队列（MessageQueue），字面来看就是存放消息的队列。也就是事件驱动架构中的Broker。

比较常见的MQ实现：

  • ActiveMQ
  • RabbitMQ
  • RocketMQ
  • Kafka

几种常见MQ的对比：

RabbitMQ ActiveMQ RocketMQ Kafka
公司/社区 Rabbit Apache 阿里 Apache
开发语言 Erlang Java Java Scala&Java
协议支持 AMQP，XMPP，SMTP，STOMP OpenWire,STOMP，REST,XMPP,AMQP 自定义协议 自定义协议
可用性 高 一般 高 高
单机吞吐量 一般 差 高 非常高
消息延迟 微秒级 毫秒级 毫秒级 毫秒以内
消息可靠性 高 一般 高 一般

追求可用性：Kafka、 RocketMQ 、RabbitMQ

追求可靠性：RabbitMQ、RocketMQ

追求吞吐能力：RocketMQ、Kafka

追求消息低延迟：RabbitMQ、Kafka

RabbitMQ

MQ的基本结构：

RabbitMQ架构.png

RabbitMQ中的一些角色：

  • publisher：生产者
  • consumer：消费者
  • exchange：交换机，负责消息路由
  • queue：队列，存储消息
  • virtualHost：虚拟主机，隔离不同租户的exchange、queue、消息的隔离

RabbitMQ消息模型

RabbitMQ官方提供了5个不同的Demo示例，对应了不同的消息模型：

五种基本MQ模型.png

原生RabbitMQ过程（用的极少）

基本消息队列的消息发送流程：

  1. 建立connection

  2. 创建channel

  3. 利用channel声明队列

  4. 利用channel向队列发送消息

基本消息队列的消息接收流程：

  1. 建立connection

  2. 创建channel

  3. 利用channel声明队列

  4. 定义consumer的消费行为handleDelivery()

  5. 利用channel将消费者与队列绑定

SpringAMQP

SpringAMQP是基于RabbitMQ封装的一套模板，并且还利用SpringBoot对其实现了自动装配，使用起来非常方便。

SpringAMQP提供了三个功能：

  • 自动声明队列、交换机及其绑定关系
  • 基于注解的监听器模式，异步接收消息
  • 封装了RabbitTemplate工具，用于发送消息

Basic Queue 简单队列模型

在父工程mq-demo中引入依赖

1
2
3
4
5
<!--AMQP依赖，包含RabbitMQ-->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-amqp</artifactId>
</dependency>

消息发送

首先配置MQ地址，在publisher服务的application.yml中添加配置：

1
2
3
4
5
6
7
spring:
  rabbitmq:
    host: 192.168.150.101 # 主机名
    port: 5672 # 端口
    virtual-host: / # 虚拟主机
    username: itcast # 用户名
    password: 123321 # 密码

然后在publisher服务中编写测试类SpringAmqpTest，并利用RabbitTemplate实现消息发送：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
@RunWith(SpringRunner.class)
@SpringBootTest
public class SpringAmqpTest {

    @Autowired
    private RabbitTemplate rabbitTemplate;

    @Test
    public void testSimpleQueue() {
        // 队列名称
        String queueName = "simple.queue";//需要自己在中间件创建名为simple.queue的队列
        // 消息
        String message = "hello, spring amqp!";
        // 发送消息
        rabbitTemplate.convertAndSend(queueName, message);
    }
}

消息接收

首先配置MQ地址，在consumer服务的application.yml中添加配置：

1
2
3
4
5
6
7
spring:
  rabbitmq:
    host: 192.168.150.101 # 主机名
    port: 5672 # 端口
    virtual-host: / # 虚拟主机
    username: itcast # 用户名
    password: 123321 # 密码

然后在consumer服务的cn.itcast.mq.listener包中新建一个类SpringRabbitListener，代码如下：

1
2
3
4
5
6
7
8
9

@Component
public class SpringRabbitListener {

    @RabbitListener(queues = "simple.queue")
    public void listenSimpleQueueMessage(String msg) throws InterruptedException {
        System.out.println("spring 消费者接收到消息：【" + msg + "】");
    }
}

WorkQueue

Work queues，也被称为（Task queues），任务模型。简单来说就是让多个消费者绑定到一个队列，共同消费队列中的消息。

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

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

消息发送

这次我们循环发送，模拟大量消息堆积现象。

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
/**
     * 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服务的SpringRabbitListener中添加2个新的方法：

1
2
3
4
5
6
7
8
9
10
11
@RabbitListener(queues = "simple.queue")
public void listenWorkQueue1(String msg) throws InterruptedException {
    System.out.println("消费者1接收到消息：【" + msg + "】" + LocalTime.now());
    Thread.sleep(20);
}

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

注意到这个消费者sleep了1000秒，模拟任务耗时。

能者多劳

原生的单队列多consumer模型默认采取的是预取机制，就是当队列中有请求时，consumer会预取请求，并且是平均分配，所以，这也导致了并没有负载均衡（对性能差的consumer不利）

在spring中有一个简单的配置，可以解决这个问题。我们修改consumer服务的application.yml文件，添加配置：

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

发布/订阅

发布订阅的模型如图：

发布-订阅-交换机模型.png

可以看到，在订阅模型中，多了一个exchange角色，而且过程略有变化：

  • Publisher：生产者，也就是要发送消息的程序，但是不再发送到队列中，而是发给X（交换机）
  • Exchange：交换机，图中的X。一方面，接收生产者发送的消息。另一方面，知道如何处理消息，例如递交给某个特别队列、递交给所有队列、或是将消息丢弃。到底如何操作，取决于Exchange的类型。Exchange有以下3种类型：
    • Fanout：广播，将消息交给所有绑定到交换机的队列
    • Direct：定向，把消息交给符合指定routing key 的队列
    • Topic：通配符，把消息交给符合routing pattern（路由模式） 的队列
  • Consumer：消费者，与以前一样，订阅队列，没有变化
  • Queue：消息队列也与以前一样，接收消息、缓存消息。

Exchange（交换机）只负责转发消息，不具备存储消息的能力，因此如果没有任何队列与Exchange绑定，或者没有符合路由规则的队列，那么消息会丢失！

Fanout

在广播模式下，消息发送流程是这样的：

  • 1） 可以有多个队列
  • 2） 每个队列都要绑定到Exchange（交换机）
  • 3） 生产者发送的消息，只能发送到交换机，交换机来决定要发给哪个队列，生产者无法决定
  • 4） 交换机把消息发送给绑定过的所有队列
  • 5） 订阅队列的消费者都能拿到消息

声明队列和交换机

Spring提供了一个接口Exchange，来表示所有不同类型的交换机：

在consumer中创建一个类，声明队列和交换机：

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

@Configuration
public class FanoutConfig {
    /**
     * 声明交换机
     * @return Fanout类型交换机
     */
    @Bean
    public FanoutExchange fanoutExchange(){
        return new FanoutExchange("itcast.fanout");
    }

    /**
     * 第1个队列
     */
    @Bean
    public Queue fanoutQueue1(){
        return new Queue("fanout.queue1");
    }

    /**
     * 绑定队列和交换机
     */
    @Bean
    public Binding bindingQueue1(Queue fanoutQueue1, FanoutExchange fanoutExchange){
        return BindingBuilder.bind(fanoutQueue1).to(fanoutExchange);
    }

    /**
     * 第2个队列
     */
    @Bean
    public Queue fanoutQueue2(){
        return new Queue("fanout.queue2");
    }

    /**
     * 绑定队列和交换机
     */
    @Bean
    public Binding bindingQueue2(Queue fanoutQueue2, FanoutExchange fanoutExchange){
        return BindingBuilder.bind(fanoutQueue2).to(fanoutExchange);
    }
}

消息发送

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

1
2
3
4
5
6
7
8
@Test
public void testFanoutExchange() {
    // 队列名称
    String exchangeName = "itcast.fanout";
    // 消息
    String message = "hello, everyone!";
    rabbitTemplate.convertAndSend(exchangeName, "", message); //这里与之前的无交换机模型不同，publisher发送给交换机exchangeName
}

消息接收

在consumer服务的SpringRabbitListener中添加两个方法，作为消费者：

1
2
3
4
5
6
7
8
9
@RabbitListener(queues = "fanout.queue1")
public void listenFanoutQueue1(String msg) {
    System.out.println("消费者1接收到Fanout消息：【" + msg + "】");
}

@RabbitListener(queues = "fanout.queue2")
public void listenFanoutQueue2(String msg) {
    System.out.println("消费者2接收到Fanout消息：【" + msg + "】");
}

交换机总结

交换机的作用是什么？

  • 接收publisher发送的消息
  • 将消息按照规则路由到与之绑定的队列
  • 不能缓存消息，路由失败，消息丢失
  • FanoutExchange的会将消息路由到每个绑定的队列

声明队列、交换机、绑定关系的Bean是什么？

  • Queue
  • FanoutExchange
  • Binding

Direct

在Fanout模式中，一条消息，会被所有订阅的队列都消费。但是，在某些场景下，我们希望不同的消息被不同的队列消费。这时就要用到Direct类型的Exchange。

在Direct模型下：

  • 队列与交换机的绑定，不能是任意绑定了，而是要指定一个RoutingKey（路由key）
  • 消息的发送方在 向 Exchange发送消息时，也必须指定消息的 RoutingKey。
  • Exchange不再把消息交给每一个绑定的队列，而是根据消息的Routing Key进行判断，只有队列的Routingkey与消息的 Routing key完全一致，才会接收到消息

案例需求如下：

  1. 利用@RabbitListener声明Exchange、Queue、RoutingKey

  2. 在consumer服务中，编写两个消费者方法，分别监听direct.queue1和direct.queue2

  3. 在publisher中编写测试方法，向itcast. direct发送消息

基于注解声明队列和交换机

基于@Bean的方式声明队列和交换机比较麻烦，Spring还提供了基于注解方式来声明。两种方法都会自动创建队列和交换机，但是已经存在的队列和交换机是不能覆盖的，同时，注解式声明只能运用于存在交换机的模型，简单队列和work队列是不行的

在consumer的SpringRabbitListener中添加两个消费者，同时基于注解来声明队列和交换机：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
@RabbitListener(bindings = @QueueBinding(
    value = @Queue(name = "direct.queue1"),
    exchange = @Exchange(name = "itcast.direct", type = ExchangeTypes.DIRECT),
    key = {"red", "blue"}
))
public void listenDirectQueue1(String msg){
    System.out.println("消费者接收到direct.queue1的消息：【" + msg + "】");
}

@RabbitListener(bindings = @QueueBinding(
    value = @Queue(name = "direct.queue2"),
    exchange = @Exchange(name = "itcast.direct", type = ExchangeTypes.DIRECT),
    key = {"red", "yellow"}
))
public void listenDirectQueue2(String msg){
    System.out.println("消费者接收到direct.queue2的消息：【" + msg + "】");
}

消息发送

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

1
2
3
4
5
6
7
8
9
@Test
public void testSendDirectExchange() {
    // 交换机名称
    String exchangeName = "itcast.direct";
    // 消息
    String message = "红色警报！日本乱排核废水，导致海洋生物变异，惊现哥斯拉！";
    // 发送消息
    rabbitTemplate.convertAndSend(exchangeName, "red", message);
}

比较Direct 和 Fanout

描述下Direct交换机与Fanout交换机的差异？

  • Fanout交换机将消息路由给每一个与之绑定的队列
  • Direct交换机根据RoutingKey判断路由给哪个队列
  • 如果多个队列具有相同的RoutingKey，则与Fanout功能类似

基于@RabbitListener注解声明队列和交换机有哪些常见注解？

  • @Queue
  • @Exchange

Topic

说明

Topic类型的Exchange与Direct相比，都是可以根据RoutingKey把消息路由到不同的队列。只不过Topic类型Exchange可以让队列在绑定Routing key 的时候使用通配符！

Routingkey 一般都是有一个或多个单词组成，多个单词之间以”.”分割，例如： item.insert

通配符规则：

#：匹配一个或多个词

*：匹配不多不少恰好1个词

举例：

item.#：能够匹配item.spu.insert 或者 item.spu

item.*：只能匹配item.spu

举例：

  • Queue1：绑定的是china.# ，因此凡是以 china.开头的routing key 都会被匹配到。包括china.news和china.weather
  • Queue2：绑定的是#.news ，因此凡是以 .news结尾的 routing key 都会被匹配。包括china.news和japan.news

案例需求：

实现思路如下：

  1. 并利用@RabbitListener声明Exchange、Queue、RoutingKey

  2. 在consumer服务中，编写两个消费者方法，分别监听topic.queue1和topic.queue2

  3. 在publisher中编写测试方法，向itcast. topic发送消息

消息发送

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

1
2
3
4
5
6
7
8
9
10
11
12
/**
     * topicExchange
     */
@Test
public void testSendTopicExchange() {
    // 交换机名称
    String exchangeName = "itcast.topic";
    // 消息
    String message = "喜报！孙悟空大战哥斯拉，胜!";
    // 发送消息
    rabbitTemplate.convertAndSend(exchangeName, "china.news", message);
}

消息接收

在consumer服务的SpringRabbitListener中添加方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
@RabbitListener(bindings = @QueueBinding(
    value = @Queue(name = "topic.queue1"),
    exchange = @Exchange(name = "itcast.topic", type = ExchangeTypes.TOPIC),
    key = "china.#"
))
public void listenTopicQueue1(String msg){
    System.out.println("消费者接收到topic.queue1的消息：【" + msg + "】");
}

@RabbitListener(bindings = @QueueBinding(
    value = @Queue(name = "topic.queue2"),
    exchange = @Exchange(name = "itcast.topic", type = ExchangeTypes.TOPIC),
    key = "#.news"
))
public void listenTopicQueue2(String msg){
    System.out.println("消费者接收到topic.queue2的消息：【" + msg + "】");
}

比较Direct与Topic

描述下Direct交换机与Topic交换机的差异？

  • Topic交换机接收的消息RoutingKey必须是多个单词，以 **.** 分割
  • Topic交换机与队列绑定时的bindingKey可以指定通配符
  • #：代表0个或多个词
  • *：代表1个词

消息转换器

之前说过，Spring会把你发送的消息序列化为字节发送给MQ，接收消息的时候，还会把字节反序列化为Java对象。

只不过，默认情况下Spring采用的序列化方式是JDK序列化。众所周知，JDK序列化存在下列问题：

  • 数据体积过大
  • 有安全漏洞
  • 可读性差

配置JSON转换器

显然，JDK序列化方式并不合适。我们希望消息体的体积更小、可读性更高，因此可以使用JSON方式来做序列化和反序列化。

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

1
2
3
4
5
<dependency>
    <groupId>com.fasterxml.jackson.dataformat</groupId>
    <artifactId>jackson-dataformat-xml</artifactId>
    <version>2.9.10</version>
</dependency>

配置消息转换器。

在启动类中添加一个Bean即可：

1
2
3
4
@Bean
public MessageConverter jsonMessageConverter(){
    return new Jackson2JsonMessageConverter();
}

之后，再发送对象体消息时采用的就是JSON字符串了

elasticsearch

了解ES

elasticsearch是一款非常强大的开源搜索引擎，具备非常多强大功能，可以帮助我们从海量数据中快速找到需要的内容

ELK技术栈

elasticsearch结合kibana、Logstash、Beats，也就是elastic stack（ELK）。被广泛应用在日志数据分析、实时监控等领域：

而elasticsearch是elastic stack的核心，负责存储、搜索、分析数据。

elasticsearch和lucene

elasticsearch底层是基于lucene来实现的。

Lucene是一个Java语言的搜索引擎类库，是Apache公司的顶级项目，由DougCutting于1999年研发。官网地址：https://lucene.apache.org/ 。

elasticsearch的发展历史：

  • 2004年Shay Banon基于Lucene开发了Compass
  • 2010年Shay Banon 重写了Compass，取名为Elasticsearch。

倒排索引

倒排索引的概念是基于MySQL这样的正向索引而言的。

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

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

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

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

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

1）用户输入条件"华为手机"进行搜索。

2）对用户输入内容分词，得到词条：华为、手机。

3）拿着词条在倒排索引中查找，可以得到包含词条的文档id：1、2、3。

4）拿着文档id到正向索引中查找具体文档。
倒排索引过程.png

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

正向和倒排比较

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

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

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

是不是恰好反过来了？

那么两者方式的优缺点是什么呢？

正向索引：

  • 优点：
    • 可以给多个字段创建索引
    • 根据索引字段搜索、排序速度非常快
  • 缺点：
    • 根据非索引字段，或者索引字段中的部分词条查找时，只能全表扫描。

倒排索引：

  • 优点：
    • 根据词条搜索、模糊搜索时，速度非常快
  • 缺点：
    • 只能给词条创建索引，而不是字段
    • 无法根据字段做排序

es的一些概念

elasticsearch中有很多独有的概念，与mysql中略有差别，但也有相似之处。

文档和字段

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

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

索引和映射

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

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

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

mysql与elasticsearch

我们统一的把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实现
  • 两者再基于某种方式，实现数据的同步，保证一致性

分词器

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

1
docker volume inspect es-plugins

分词器以数据卷的形式上传到Elasticsearch的/var/lib/docker/volumes/es-plugins/_data目录中

分词器的作用是什么？

  • 创建倒排索引时对文档分词
  • 用户搜索时，对输入的内容分词

IK分词器有几种模式？

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

IK分词器如何拓展词条？如何停用词条？

  • 利用config目录的IkAnalyzer.cfg.xml文件添加拓展词典和停用词典
  • 在词典中添加拓展词条或者停用词条

索引库操作

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

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

mapping映射属性

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

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

例如下面的json文档：

1
2
3
4
5
6
7
8
9
10
11
12
{
    "age": 21,
    "weight": 52.1,
    "isMarried": false,
    "info": "黑马程序员Java讲师",
    "email": "zy@itcast.cn",
    "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；无需分词器

索引库的CRUD

这里我们统一使用Kibana编写DSL的方式来演示,基于Restful接口风格

  • GET 查询
  • POST 插入/新增
  • PUT 修改
  • DELETE 删除

创建索引库和映射

基本语法：

  • 请求方式：PUT
  • 请求路径：/索引库名，可以自定义
  • 请求参数：mapping映射

格式：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
PUT /索引库名称
{
  "mappings": {  //必须要
    "properties": {  //必须要
      "字段名":{
        "type": "text",
        "analyzer": "ik_smart"
      },
      "字段名2":{
        "type": "keyword",
        "index": "false"
      },
      "字段名3":{
        "properties": {
          "子字段": {
            "type": "keyword"
          }
        }
      },
      // ...略
    }
  }
}

查询索引库

基本语法：

  • 请求方式：GET

  • 请求路径：/索引库名

  • 请求参数：无

格式：

1
GET /索引库名

修改索引库

倒排索引结构虽然不复杂，但是一旦数据结构改变（比如改变了分词器），就需要重新创建倒排索引，这简直是灾难。因此索引库一旦创建，无法修改mapping。

虽然无法修改mapping中已有的字段，但是却允许添加新的字段到mapping中，因为不会对倒排索引产生影响。

语法说明：

1
2
3
4
5
6
7
8
PUT /索引库名/_mapping
{
  "properties": {
    "新字段名":{
      "type": "integer"
    }
  }
}

删除索引库

语法：

  • 请求方式：DELETE

  • 请求路径：/索引库名

  • 请求参数：无

格式：

1
DELETE /索引库名

小结

索引库操作有哪些？

  • 创建索引库：PUT /索引库名
  • 查询索引库：GET /索引库名
  • 删除索引库：DELETE /索引库名
  • 添加字段：PUT /索引库名/_mapping

文档操作

新增文档

语法：

1
2
3
4
5
6
7
8
9
10
POST /索引库名/_doc/文档id
{
    "字段1": "值1",
    "字段2": "值2",
    "字段3": {
        "子属性1": "值3",
        "子属性2": "值4"
    },
    // ...
}

查询文档

语法：

1
GET /{索引库名称}/_doc/{id}

删除文档

语法：

1
DELETE /{索引库名}/_doc/id值

修改文档

修改有两种方式：

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

全量修改

全量修改是覆盖原来的文档，其本质是：

  • 根据指定的id删除文档
  • 新增一个相同id的文档

注意：如果根据id删除时，id不存在，第二步的新增也会执行，也就从修改变成了新增操作了。

语法：

1
2
3
4
5
6
7
PUT /{索引库名}/_doc/文档id
{
    "字段1": "值1",
    "字段2": "值2",
    // ... 略
}

增量修改

增量修改是只修改指定id匹配的文档中的部分字段。

语法：

1
2
3
4
5
6
POST /{索引库名}/_update/文档id
{
    "doc": {
         "字段名": "新的值",
    }
}

小结

文档操作有哪些？

  • 创建文档：POST /{索引库名}/_doc/文档id { json文档 }
  • 查询文档：GET /{索引库名}/_doc/文档id
  • 删除文档：DELETE /{索引库名}/_doc/文档id
  • 修改文档：
    • 全量修改：PUT /{索引库名}/_doc/文档id { json文档 }
    • 增量修改：POST /{索引库名}/_update/文档id { “doc”: {字段}}

通过RestClient操作索引库

  • 基于RestHighLevelClient类

初始化RestClient

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

分为三步：

1）引入es的RestHighLevelClient依赖：

1
2
3
4
<dependency>
    <groupId>org.elasticsearch.client</groupId>
    <artifactId>elasticsearch-rest-high-level-client</artifactId>
</dependency>

2）因为SpringBoot默认的ES版本是7.6.2，所以我们需要覆盖默认的ES版本：

1
2
3
4
<properties>
    <java.version>1.8</java.version>
    <elasticsearch.version>7.12.1</elasticsearch.version>
</properties>

3）初始化RestHighLevelClient：

初始化的代码如下：

1
2
3
RestHighLevelClient client = new RestHighLevelClient(RestClient.builder(
        HttpHost.create("http://192.168.150.101:9200") //es的地址
));

这里为了单元测试方便，我们创建一个测试类HotelIndexTest，然后将初始化的代码编写在@BeforeEach方法中：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class HotelIndexTest {
    private RestHighLevelClient client;

    @BeforeEach
    void setUp() { //先创建RestHighLevelClient
        this.client = new RestHighLevelClient(RestClient.builder(
                HttpHost.create("http://192.168.150.101:9200")
        ));
    }

    @AfterEach //使用完之后关闭
    void tearDown() throws IOException {
        this.client.close();
    }
}

创建索引库

RestClient创建索引库.png

mapping映射分析

创建索引库，最关键的是mapping映射，而mapping映射要考虑的信息包括：

  • 字段名
  • 字段数据类型
  • 是否参与搜索
  • 是否需要分词
  • 如果分词，分词器是什么？

其中：

  • 字段名、字段数据类型，可以参考数据表结构的名称和类型
  • 是否参与搜索要分析业务来判断，例如图片地址，就无需参与搜索
  • 是否分词呢要看内容，内容如果是一个整体就无需分词，反之则要分词
  • 分词器，我们可以统一使用ik_max_word

ex：

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
47
48
49
50
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",
        "copy_to": "all"
      },
      "starName":{
        "type": "keyword"
      },
      "business":{
        "type": "keyword"
      },
      "location":{
        "type": "geo_point"
      },
      "pic":{
        "type": "keyword",
        "index": false
      },
      "all":{
        "type": "text",
        "analyzer": "ik_max_word"
      }
    }
  }
}

几个特殊字段说明：

  • location：地理坐标，里面包含精度、纬度
  • all：一个组合字段，其目的是将多字段的值 利用copy_to合并，提供给用户搜索，提高搜索效率

创建索引

三步走：

  • 1）创建Request对象。CreateIndexRequest对象
  • 2）准备参数。指定source
  • 3）发送请求。create方法

创建一个类，定义mapping映射的JSON字符串常量：

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
47
48
49
50
51
52
53
package cn.itcast.hotel.constants;

public class HotelConstants {
    public static final 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" +
            "}";
}

创建索引：

1
2
3
4
5
6
7
8
9
10
11
12
@Test
void createHotelIndex() throws IOException {
    // 1.创建Request对象
    CreateIndexRequest request = new CreateIndexRequest("hotel");
    // 2.准备请求的参数：DSL语句
    request.source(MAPPING_TEMPLATE, XContentType.JSON);
    //MAPPING_TEMPLATE为建表mapping，指定数据格式为JSON数据
    // 3.发送请求
    client.indices().create(request, RequestOptions.DEFAULT);
    //indices获取client面向索引的所有api方法，调用其中的create方法
    //RequestOptions.DEFAULT默认参数不用变
}

删除索引库

依然是三步走：

  • 1）创建Request对象。这次是DeleteIndexRequest对象
  • 2）准备参数。这里是无参
  • 3）发送请求。改用delete方法
1
2
3
4
5
6
7
@Test
void testDeleteHotelIndex() throws IOException {
    // 1.创建Request对象
    DeleteIndexRequest request = new DeleteIndexRequest("hotel");
    // 2.发送请求
    client.indices().delete(request, RequestOptions.DEFAULT);
}

判断索引库是否存在

因此与删除的Java代码流程是类似的。依然是三步走：

  • 1）创建Request对象。这次是GetIndexRequest对象
  • 2）准备参数。这里是无参
  • 3）发送请求。改用exists方法
1
2
3
4
5
6
7
8
9
@Test
void testExistsHotelIndex() throws IOException {
    // 1.创建Request对象
    GetIndexRequest request = new GetIndexRequest("hotel");
    // 2.发送请求
    boolean exists = client.indices().exists(request, RequestOptions.DEFAULT);
    // 3.输出
    System.err.println(exists ? "索引库已经存在！" : "索引库不存在！");
}

RestClient索引库总结

JavaRestClient操作elasticsearch的流程基本类似。核心是client.indices()方法来获取索引库的操作对象。

索引库操作的基本步骤：

  • 初始化RestHighLevelClient
  • 创建XxxIndexRequest。XXX是Create、Get、Delete
  • 准备DSL（ Create时需要，其它是无参）
  • 发送请求。调用RestHighLevelClient#indices().xxx()方法，xxx是create、exists、delete

RestClient操作文档

为了与索引库操作分离，我们再次参加一个测试类，做两件事情：

  • 初始化RestHighLevelClient
  • 我们的酒店数据在数据库，需要利用IHotelService去查询，所以注入这个接口
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

@SpringBootTest
public class HotelDocumentTest {
    @Autowired
    private IHotelService hotelService;

    private RestHighLevelClient client;

    @BeforeEach
    void setUp() {
        this.client = new RestHighLevelClient(RestClient.builder(
                HttpHost.create("http://192.168.150.101:9200")
        ));
    }

    @AfterEach
    void tearDown() throws IOException {
        this.client.close();
    }
}

新增文档

RestClient新增文档.png

与创建索引库类似，同样是三步走：

  • 1）创建Request对象
  • 2）准备请求参数，也就是DSL中的JSON文档
  • 3）发送请求

变化的地方在于，这里直接使用client.xxx()的API，不再需要client.indices()了。

因此，代码整体步骤如下：

  • 1）根据id查询酒店数据Hotel
  • 2）将Hotel封装为HotelDoc （可能数据库里的数据结构与索引库里的数据结构存在差异 需要转换一下）
  • 3）将HotelDoc序列化为JSON
  • 4）创建IndexRequest，指定索引库名和id
  • 5）准备请求参数，也就是JSON文档
  • 6）发送请求
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
@Test
void testAddDocument() throws IOException {
    // 1.根据id查询酒店数据
    Hotel hotel = hotelService.getById(61083L);
    // 2.转换为文档类型
    HotelDoc hotelDoc = new HotelDoc(hotel);
    // 3.将HotelDoc转json 
    String json = JSON.toJSONString(hotelDoc);
	//source只能传json数据 通过alibaba的fastJSON实现对象转json 需要引入依赖
    // 1.准备Request对象
    IndexRequest request = new IndexRequest("hotel").id(hotelDoc.getId().toString());
    //指定索引库名和文档id id默认类型是keyword 需要转成string
    // 2.准备Json文档
    request.source(json, XContentType.JSON);
    // 3.发送请求
    client.index(request, RequestOptions.DEFAULT);
}

查询文档

RestClient查询文档.png

代码大概分两步：

  • 准备Request对象
  • 发送请求

结果是一个JSON，其中文档放在一个_source属性中，因此解析就是拿到_source，反序列化为Java对象即可。

与之前类似，也是三步走：

  • 1）准备Request对象。这次是查询，所以是GetRequest
  • 2）发送请求，得到结果。因为是查询，这里调用client.get()方法
  • 3）解析结果，就是对JSON做反序列化
1
2
3
4
5
6
7
8
9
10
11
12
@Test
void testGetDocumentById() throws IOException {
    // 1.准备Request
    GetRequest request = new GetRequest("hotel", "61082");
    // 2.发送请求，得到响应
    GetResponse response = client.get(request, RequestOptions.DEFAULT);
    // 3.解析响应结果
    String json = response.getSourceAsString();

    HotelDoc hotelDoc = JSON.parseObject(json, HotelDoc.class);
    System.out.println(hotelDoc);
}

删除文档

与查询相比，仅仅是请求方式从DELETE变成GET，可以想象Java代码应该依然是三步走：

  • 1）准备Request对象，因为是删除，这次是DeleteRequest对象。要指定索引库名和id
  • 2）准备参数，无参
  • 3）发送请求。因为是删除，所以是client.delete()方法
1
2
3
4
5
6
7
@Test
void testDeleteDocument() throws IOException {
    // 1.准备Request
    DeleteRequest request = new DeleteRequest("hotel", "61083");
    // 2.发送请求
    client.delete(request, RequestOptions.DEFAULT);
}

修改文档

RestClient修改文档.png

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

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

这里不再赘述，我们主要关注增量修改。

与之前类似，也是三步走：

  • 1）准备Request对象。这次是修改，所以是UpdateRequest
  • 2）准备参数。也就是JSON文档，里面包含要修改的字段
  • 3）更新文档。这里调用client.update()方法
1
2
3
4
5
6
7
8
9
10
11
12
@Test
void testUpdateDocument() throws IOException {
    // 1.准备Request
    UpdateRequest request = new UpdateRequest("hotel", "61083");
    // 2.准备请求参数
    request.doc(
        "price", "952",
        "starName", "四钻"
    );
    // 3.发送请求
    client.update(request, RequestOptions.DEFAULT);
}

批量导入文档

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

其中提供了一个add方法，能添加的请求包括：

  • IndexRequest，也就是新增
  • UpdateRequest，也就是修改
  • DeleteRequest，也就是删除

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

其实还是三步走：

  • 1）创建Request对象。这里是BulkRequest
  • 2）准备参数。批处理的参数，就是其它Request对象，这里就是多个IndexRequest
  • 3）发起请求。这里是批处理，调用的方法为client.bulk()方法
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
@Test
void testBulkRequest() throws IOException {
    // 批量查询酒店数据
    List<Hotel> hotels = hotelService.list();

    // 1.创建Request
    BulkRequest request = new BulkRequest();
    // 2.准备参数，添加多个新增的Request
    for (Hotel hotel : hotels) {
        // 2.1.转换为文档类型HotelDoc
        HotelDoc hotelDoc = new HotelDoc(hotel);
        // 2.2.创建新增文档的Request对象
        request.add(new IndexRequest("hotel")
                    .id(hotelDoc.getId().toString())
                    .source(JSON.toJSONString(hotelDoc), XContentType.JSON));
    }
    // 3.发送请求
    client.bulk(request, RequestOptions.DEFAULT);
}

RestClient文档操作小结

文档操作的基本步骤：

  • 初始化RestHighLevelClient
  • 创建XxxRequest。XXX是Index、Get、Update、Delete、Bulk
  • 准备参数（Index、Update、Bulk时需要）
  • 发送请求。调用RestHighLevelClient#.xxx()方法，xxx是index、get、update、delete、bulk
  • 解析结果（Get时需要）

DSL查询分类

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

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

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

    • match_query
    • multi_match_query

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

    • ids
    • range
    • term

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

    • geo_distance
    • geo_bounding_box

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

    • bool
    • function_score

查询的语法基本一致：

1
2
3
4
5
6
7
8
GET /indexName/_search
{
  "query": {
    "查询类型": {
      "查询条件": "条件值"
    }
  }
}

我们以查询所有为例，其中：

  • 查询类型为match_all
  • 没有查询条件
1
2
3
4
5
6
7
8
// 查询所有
GET /indexName/_search
{
  "query": {
    "match_all": {
    }
  }
}

其它查询无非就是查询类型、查询条件的变化。

全文检索查询（分词查询）

使用场景

全文检索查询的基本流程如下：

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

比较常用的场景包括：

  • 商城的输入框搜索
  • 百度输入框搜索

基本语法

常见的全文检索查询包括：

  • match查询：单字段查询
  • multi_match查询：多字段查询，任意一个字段符合条件就算符合查询条件

match查询语法如下：

1
2
3
4
5
6
7
8
GET /indexName/_search
{
  "query": {
    "match": {
      "FIELD": "TEXT" //FIELD填查询字段 TEXT填查询内容
    }
  }
}

mulit_match语法如下：

1
2
3
4
5
6
7
8
9
GET /indexName/_search
{
  "query": {
    "multi_match": {
      "query": "TEXT",
      "fields": ["FIELD1", " FIELD12"]
    }
  }
}

但是，搜索字段越多，对查询性能影响越大，因此建议采用copy_to，然后单字段查询的方式。
不建议使用multi_match

精准查询（不分词查询）

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

  • term：根据词条精确值查询
  • range：根据值的范围查询

term查询

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

语法说明：

1
2
3
4
5
6
7
8
9
10
11
// term查询
GET /indexName/_search
{
  "query": {
    "term": {
      "FIELD": {
        "value": "VALUE" //完全匹配才会返回对应文档
      }
    }
  }
}

range查询

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

基本语法：

1
2
3
4
5
6
7
8
9
10
11
12
// range查询
GET /indexName/_search
{
  "query": {
    "range": {
      "FIELD": {
        "gte": 10, // 这里的gte代表大于等于，gt则代表大于
        "lte": 20 // lte代表小于等于，lt则代表小于
      }
    }
  }
}

地理坐标查询

矩形范围查询

查询时，需要指定矩形的左上、右下两个点的坐标，然后画出一个矩形，落在该矩形内的都是符合条件的点。

语法如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// 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）：查询到指定中心点小于某个距离值的所有文档。

语法说明：

1
2
3
4
5
6
7
8
9
10
// geo_distance 查询
GET /indexName/_search
{
  "query": {
    "geo_distance": {
      "distance": "15km", // 半径
      "FIELD": "31.21,121.5" // 圆心
    }
  }
}

复合查询

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

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

function_score查询

相关性算分

当我们利用match查询时，文档结果会根据与搜索词条的关联度打分（_score），返回结果时按照分值降序排列。

小结：elasticsearch会根据词条和文档的相关度做打分，算法由两种：

  • TF-IDF算法
  • BM25算法，elasticsearch5.1版本后采用的算法

TF-IDF.png

TF-IDF算法有一各缺陷，就是词条频率越高，文档得分也会越高，单个词条对文档影响较大。而BM25则会让单个词条的算分有一个上限，曲线更加平滑：

TF-IDF与BM25比较.png

语法说明

function_score.png

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）基于运算模式做运算，得到最终结果，作为相关性算分。

因此，其中的关键点是：

  • 过滤条件：决定哪些文档的算分被修改
  • 算分函数：决定函数算分的算法
  • 运算模式：决定最终算分结果
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
GET /hotel/_search
{
  "query": {
    "function_score": {
      "query": {  .... }, // 原始查询，可以是任意条件
      "functions": [ // 算分函数
        {
          "filter": { // 满足的条件，品牌必须是如家
            "term": {
              "brand": "如家"
            }
          },
          "weight": 2 // 算分权重为2
        }
      ],
      "boost_mode": "sum" // 加权模式，求和
    }
  }
}

布尔查询

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

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

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

  • 搜索框的关键字搜索，是全文检索查询，使用must查询，参与算分
  • 其它过滤条件，采用filter查询。不参与算分
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
GET /hotel/_search
{
  "query": {
    "bool": {
      "must": [
        {"term": {"city": "上海" }}
      ],
      "should": [
        {"term": {"brand": "皇冠假日" }},
        {"term": {"brand": "华美达" }}
      ],
      "must_not": [
        { "range": { "price": { "lte": 500 } }}
      ],
      "filter": [
        { "range": {"score": { "gte": 45 } }}
      ]
    }
  }
}

搜索结果处理

默认是根据计算得分排序

排序

普通字段排序

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

语法：

1
2
3
4
5
6
7
8
9
10
11
GET /indexName/_search
{
  "query": {
    "match_all": {}
  },
  "sort": [
    {
      "FIELD": "desc"  // 排序字段、排序方式ASC、DESC
    }
  ]
}

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

地理坐标排序

地理坐标排序略有不同。

语法说明：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
GET /indexName/_search
{
  "query": {
    "match_all": {}
  },
  "sort": [
    {
      "_geo_distance" : {
          "FIELD" : "纬度，经度", // 文档中geo_point类型的字段名、目标坐标点
          "order" : "asc", // 排序方式
          "unit" : "km" // 排序的距离单位
      }
    }
  ]
}

这个查询的含义是：

  • 指定一个坐标，作为目标点
  • 计算每一个文档中，指定字段（必须是geo_point类型）的坐标 到目标点的距离是多少
  • 根据距离排序

分页

elasticsearch 默认情况下只返回top10的数据。

基本的分页

分页的基本语法如下：

1
2
3
4
5
6
7
8
9
10
11
GET /hotel/_search
{
  "query": {
    "match_all": {}
  },
  "from": 0, // 分页开始的位置，默认为0
  "size": 10, // 期望获取的文档总数
  "sort": [
    {"price": "asc"}
  ]
}

深度分页问题

es的分页查询只可以查询全部数据并进行截取，集群查询时对cpu和内存消耗很大，所以设置了上限只能10000（是总数据量10000 不是size10000）

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

  • from + size：

    • 优点：支持随机翻页
    • 缺点：深度分页问题，默认查询上限（from + size）是10000
    • 场景：百度、京东、谷歌、淘宝这样的随机翻页搜索

  • after search：

    • 优点：没有查询上限（单次查询的size不超过10000）
    • 缺点：只能向后逐页查询，不支持随机翻页
    • 场景：没有随机翻页需求的搜索，例如手机向下滚动翻页

  • scroll：

    • 优点：没有查询上限（单次查询的size不超过10000）
    • 缺点：会有额外内存消耗，并且搜索结果是非实时的
    • 场景：海量数据的获取和迁移。从ES7.1开始不推荐，建议用 after search方案。

高亮结果显示

实现高亮

高亮的语法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
GET /hotel/_search
{
  "query": {
    "match": {
      "FIELD": "TEXT" // 查询条件，高亮一定要使用全文检索查询
    }
  },
  "highlight": {
    "fields": { // 指定要高亮的字段
      "FIELD": {
        "pre_tags": "<em>",  // 用来标记高亮字段的前置标签
        "post_tags": "</em>" // 用来标记高亮字段的后置标签
        //默认就是em
      }
    }
  }
}

注意：

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

小结：

查询的DSL是一个大的JSON对象，包含下列属性：

  • query：查询条件
  • from和size：分页条件
  • sort：排序条件
  • highlight：高亮条件

RestClient查询文档

查询的基本步骤是：

  1. 创建SearchRequest对象

  2. 准备Request.source()，也就是DSL。

    ① QueryBuilders来构建查询条件

    ② 传入Request.source() 的 query() 方法

  3. 发送请求，得到结果

  4. 解析结果（参考JSON结果，从外到内，逐层解析）

matchAll查询

matchAll.png

matchAll响应结果解析.png

完整代码如下：

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
@Test
void testMatchAll() throws IOException {
    // 1.准备Request
    SearchRequest request = new SearchRequest("hotel");
    // 2.准备DSL
    request.source()
        .query(QueryBuilders.matchAllQuery());
    // 3.发送请求
    SearchResponse response = client.search(request, RequestOptions.DEFAULT);

    // 4.解析响应
    handleResponse(response);
}

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);
        System.out.println("hotelDoc = " + hotelDoc);
    }
}

match查询

完整代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
@Test
void testMatch() throws IOException {
    // 1.准备Request
    SearchRequest request = new SearchRequest("hotel");
    // 2.准备DSL
    request.source()
        .query(QueryBuilders.matchQuery("all", "如家"));
    // 3.发送请求
    SearchResponse response = client.search(request, RequestOptions.DEFAULT);
    // 4.解析响应
    handleResponse(response);

}

multimatch同理 只是查询参数略有不同，并且用的很少 一般用copyto统一字段转换为match查询
term range查询都差不多，传入参数略有不同

multiMatchAndMatchInRestClient.png

布尔查询

布尔查询RestClient.png

完整代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
@Test
void testBool() throws IOException {
    // 1.准备Request
    SearchRequest request = new SearchRequest("hotel");
    // 2.准备DSL
    // 2.1.准备BooleanQuery
    BoolQueryBuilder boolQuery = QueryBuilders.boolQuery();
    // 2.2.添加term
    boolQuery.must(QueryBuilders.termQuery("city", "杭州"));
    // 2.3.添加range
    boolQuery.filter(QueryBuilders.rangeQuery("price").lte(250));

    request.source().query(boolQuery);
    // 3.发送请求
    SearchResponse response = client.search(request, RequestOptions.DEFAULT);
    // 4.解析响应
    handleResponse(response);

}

排序、分页

排序分页RestClient.png

完整代码示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
@Test
void testPageAndSort() throws IOException {
    // 页码，每页大小
    int page = 1, size = 5;

    // 1.准备Request
    SearchRequest request = new SearchRequest("hotel");
    // 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);
    // 3.发送请求
    SearchResponse response = client.search(request, RequestOptions.DEFAULT);
    // 4.解析响应
    handleResponse(response);

}

高亮

高亮RestClient.png

高亮的代码与之前代码差异较大，有两点：

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

请求高亮显示代码

完整代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
@Test
void testHighlight() throws IOException {
    // 1.准备Request
    SearchRequest request = new SearchRequest("hotel");
    // 2.准备DSL
    // 2.1.query
    request.source().query(QueryBuilders.matchQuery("all", "如家"));
    // 2.2.高亮
    request.source().highlighter(new HighlightBuilder().field("name").requireFieldMatch(false));
    // 3.发送请求
    SearchResponse response = client.search(request, RequestOptions.DEFAULT);
    // 4.解析响应
    handleResponse(response);

}

高亮结果解析

解析高亮结果.png

代码解读：

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

完整代码如下：

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
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);
    }
}

旅游案例

酒店搜索和分页

案例需求：实现黑马旅游的酒店搜索功能，完成关键字搜索和分页

需求分析

  • 请求方式：POST
  • 请求路径：/hotel/list
  • 请求参数：JSON对象，包含4个字段：
    • key：搜索关键字
    • page：页码
    • size：每页大小
    • sortBy：排序，目前暂不实现
  • 返回值：分页查询，需要返回分页结果PageResult，包含两个属性：
    • total：总条数
    • List<HotelDoc>：当前页的数据

因此，我们实现业务的流程如下：

  • 步骤一：定义实体类，接收请求参数的JSON对象
  • 步骤二：编写controller，接收页面的请求
  • 步骤三：编写业务实现，利用RestHighLevelClient实现搜索、分页

定义实体类

1）请求实体类

1
2
3
4
5
6
7
8
9
10
11
package cn.itcast.hotel.pojo;

import lombok.Data;

@Data
public class RequestParams {
    private String key;
    private Integer page;
    private Integer size;
    private String sortBy;
}

2）返回值实体类

1
2
3
4
5
6
7
8
9
10
11
12
13
14

@Data
public class PageResult {
    private Long total;
    private List<HotelDoc> hotels;

    public PageResult() {
    }

    public PageResult(Long total, List<HotelDoc> hotels) {
        this.total = total;
        this.hotels = hotels;
    }
}

定义controller

因此，我们在cn.itcast.hotel.web中定义HotelController：

1
2
3
4
5
6
7
8
9
10
11
12
@RestController
@RequestMapping("/hotel")
public class HotelController {

    @Autowired
    private IHotelService hotelService;
	// 搜索酒店数据
    @PostMapping("/list")
    public PageResult search(@RequestBody RequestParams params){
        return hotelService.search(params);
    }
}

实现搜索业务

我们在controller调用了IHotelService，并没有实现该方法，因此下面我们就在IHotelService中定义方法，并且去实现业务逻辑。

1）在cn.itcast.hotel.service中的IHotelService接口中定义一个方法：

1
2
3
4
5
6
/**
 * 根据关键字搜索酒店信息
 * @param params 请求参数对象，包含用户输入的关键字 
 * @return 酒店文档列表
 */
PageResult search(RequestParams params);

2）实现搜索业务，肯定离不开RestHighLevelClient，我们需要把它注册到Spring中作为一个Bean。在cn.itcast.hotel中的HotelDemoApplication中声明这个Bean：

1
2
3
4
5
6
@Bean
public RestHighLevelClient client(){
    return  new RestHighLevelClient(RestClient.builder(
        HttpHost.create("http://192.168.150.101:9200")
    ));
}

3）在cn.itcast.hotel.service.impl中的HotelService中实现search方法：

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
47
48
49
@Override
public PageResult search(RequestParams params) {
    try {
        // 1.准备Request
        SearchRequest request = new SearchRequest("hotel");
        // 2.准备DSL
        // 2.1.query
        String key = params.getKey();
        if (key == null || "".equals(key)) {
            request.source().query(QueryBuilders.matchAllQuery());
        } else {
            request.source().query(QueryBuilders.matchQuery("all", key));
        }

        // 2.2.分页
        int page = params.getPage();
        int size = params.getSize();
        request.source().from((page - 1) * size).size(size);

        // 3.发送请求
        SearchResponse response = client.search(request, RequestOptions.DEFAULT);
        // 4.解析响应
        return handleResponse(response);
    } catch (IOException e) {
        throw new RuntimeException(e);
    }
}

// 结果解析
private PageResult handleResponse(SearchResponse response) {
    // 4.解析响应
    SearchHits searchHits = response.getHits();
    // 4.1.获取总条数
    long total = searchHits.getTotalHits().value;
    // 4.2.文档数组
    SearchHit[] hits = searchHits.getHits();
    // 4.3.遍历
    List<HotelDoc> hotels = new ArrayList<>();
    for (SearchHit hit : hits) {
        // 获取文档source
        String json = hit.getSourceAsString();
        // 反序列化
        HotelDoc hotelDoc = JSON.parseObject(json, HotelDoc.class);
		// 放入集合
        hotels.add(hotelDoc);
    }
    // 4.4.封装返回
    return new PageResult(total, hotels);
}

酒店结果过滤

需求：添加品牌、城市、星级、价格等过滤功能

需求分析

包含的过滤条件有：

  • brand：品牌值
  • city：城市
  • minPrice~maxPrice：价格范围
  • starName：星级

修改实体类

修改在cn.itcast.hotel.pojo包下的实体类RequestParams：

1
2
3
4
5
6
7
8
9
10
11
12
13
@Data
public class RequestParams {
    private String key;
    private Integer page;
    private Integer size;
    private String sortBy;
    // 下面是新增的过滤条件参数
    private String city;
    private String brand;
    private String starName;
    private Integer minPrice;
    private Integer maxPrice;
}

修改搜索业务

多个查询条件组合，肯定是boolean查询来组合：

  • 关键字搜索放到must中，参与算分
  • 其它过滤条件放到filter中，不参与算分

buildBasicQuery的代码如下：(准备参数代码提取出来了)

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
private void buildBasicQuery(RequestParams params, SearchRequest request) {
    // 1.构建BooleanQuery
    BoolQueryBuilder boolQuery = QueryBuilders.boolQuery();
    // 2.关键字搜索
    String key = params.getKey();
    if (key == null || "".equals(key)) {
        boolQuery.must(QueryBuilders.matchAllQuery());
    } else {
        boolQuery.must(QueryBuilders.matchQuery("all", key));
    }
    // 3.城市条件
    if (params.getCity() != null && !params.getCity().equals("")) {
        boolQuery.filter(QueryBuilders.termQuery("city", params.getCity()));
    }
    // 4.品牌条件
    if (params.getBrand() != null && !params.getBrand().equals("")) {
        boolQuery.filter(QueryBuilders.termQuery("brand", params.getBrand()));
    }
    // 5.星级条件
    if (params.getStarName() != null && !params.getStarName().equals("")) {
        boolQuery.filter(QueryBuilders.termQuery("starName", params.getStarName()));
    }
	// 6.价格
    if (params.getMinPrice() != null && params.getMaxPrice() != null) {
        boolQuery.filter(QueryBuilders
                         .rangeQuery("price")
                         .gte(params.getMinPrice())
                         .lte(params.getMaxPrice())
                        );
    }
	// 7.放入source
    request.source().query(boolQuery);
}

我周边的酒店

需求：我附近的酒店

需求分析

基于前端传回的location坐标，然后按照距离对周围酒店排序。

修改实体类

修改在cn.itcast.hotel.pojo包下的实体类RequestParams：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
package cn.itcast.hotel.pojo;

import lombok.Data;

@Data
public class RequestParams {
    private String key;
    private Integer page;
    private Integer size;
    private String sortBy;
    private String city;
    private String brand;
    private String starName;
    private Integer minPrice;
    private Integer maxPrice;
    // 我当前的地理坐标
    private String location;
}

添加距离排序

RestClient距离排序.png

完整代码：

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
@Override
public PageResult search(RequestParams params) {
    try {
        // 1.准备Request
        SearchRequest request = new SearchRequest("hotel");
        // 2.准备DSL
        // 2.1.query
        buildBasicQuery(params, request);

        // 2.2.分页
        int page = params.getPage();
        int size = params.getSize();
        request.source().from((page - 1) * size).size(size);

        // 2.3.排序
        String location = params.getLocation();
        if (location != null && !location.equals("")) {
            request.source().sort(SortBuilders
                                  .geoDistanceSort("location", new GeoPoint(location))
                                  .order(SortOrder.ASC)
                                  .unit(DistanceUnit.KILOMETERS)
                                 );
        }

        // 3.发送请求
        SearchResponse response = client.search(request, RequestOptions.DEFAULT);
        // 4.解析响应
        return handleResponse(response);
    } catch (IOException e) {
        throw new RuntimeException(e);
    }
}

排序距离显示

排序完成后，页面还要获取我附近每个酒店的具体距离值，这个值在响应结果中是独立的：

1）修改HotelDoc类，添加距离字段

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
@Data
@NoArgsConstructor
public class HotelDoc {
    private Long id;
    private String name;
    private String address;
    private Integer price;
    private Integer score;
    private String brand;
    private String city;
    private String starName;
    private String business;
    private String location;
    private String pic;
    // 排序时的 距离值
    private Object distance;

    public HotelDoc(Hotel hotel) {
        this.id = hotel.getId();
        this.name = hotel.getName();
        this.address = hotel.getAddress();
        this.price = hotel.getPrice();
        this.score = hotel.getScore();
        this.brand = hotel.getBrand();
        this.city = hotel.getCity();
        this.starName = hotel.getStarName();
        this.business = hotel.getBusiness();
        this.location = hotel.getLatitude() + ", " + hotel.getLongitude();
        this.pic = hotel.getPic();
    }
}

2）在结果处理中，将获取到的距离取出赋给对应的HotelDoc

酒店竞价排名

需求：让指定的酒店在搜索结果中排名置顶

需求分析

这里的需求是：让指定酒店排名靠前。因此我们需要给这些酒店添加一个标记，这样在过滤条件中就可以根据这个标记来判断，是否要提高算分。

这样function_score包含3个要素就很好确定了：

  • 过滤条件：判断isAD 是否为true
  • 算分函数：我们可以用最简单暴力的weight，固定加权值
  • 加权方式：可以用默认的相乘，大大提高算分

修改HotelDoc实体

给cn.itcast.hotel.pojo包下的HotelDoc类添加isAD字段：

添加广告标记

接下来，我们挑几个酒店，添加isAD字段，设置为true：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
POST /hotel/_update/1902197537
{
    "doc": {
        "isAD": true
    }
}
POST /hotel/_update/2056126831
{
    "doc": {
        "isAD": true
    }
}
POST /hotel/_update/1989806195
{
    "doc": {
        "isAD": true
    }
}
POST /hotel/_update/2056105938
{
    "doc": {
        "isAD": true
    }
}

注意：这里只有局部的几个文档多了词条isAD，索引结构并不统一了 但是仍然可以增加

添加算分函数查询

RestClient算分.png

接下来我们就要修改查询条件了。之前是用的boolean 查询，现在要改成function_socre查询。

我们可以将之前写的boolean查询作为原始查询条件放到query中，接下来就是添加过滤条件、算分函数、加权模式了。所以原来的代码依然可以沿用。

添加算分函数查询：

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
47
48
private void buildBasicQuery(RequestParams params, SearchRequest request) {
    // 1.构建BooleanQuery
    BoolQueryBuilder boolQuery = QueryBuilders.boolQuery();
    // 关键字搜索
    String key = params.getKey();
    if (key == null || "".equals(key)) {
        boolQuery.must(QueryBuilders.matchAllQuery());
    } else {
        boolQuery.must(QueryBuilders.matchQuery("all", key));
    }
    // 城市条件
    if (params.getCity() != null && !params.getCity().equals("")) {
        boolQuery.filter(QueryBuilders.termQuery("city", params.getCity()));
    }
    // 品牌条件
    if (params.getBrand() != null && !params.getBrand().equals("")) {
        boolQuery.filter(QueryBuilders.termQuery("brand", params.getBrand()));
    }
    // 星级条件
    if (params.getStarName() != null && !params.getStarName().equals("")) {
        boolQuery.filter(QueryBuilders.termQuery("starName", params.getStarName()));
    }
    // 价格
    if (params.getMinPrice() != null && params.getMaxPrice() != null) {
        boolQuery.filter(QueryBuilders
                         .rangeQuery("price")
                         .gte(params.getMinPrice())
                         .lte(params.getMaxPrice())
                        );
    }

    // 2.算分控制
    FunctionScoreQueryBuilder functionScoreQuery =
        QueryBuilders.functionScoreQuery(
        // 原始查询，相关性算分的查询
        boolQuery,
        // function score的数组
        new FunctionScoreQueryBuilder.FilterFunctionBuilder[]{
            // 其中的一个function score 元素
            new FunctionScoreQueryBuilder.FilterFunctionBuilder(
                // 过滤条件
                QueryBuilders.termQuery("isAD", true),
                // 算分函数
                ScoreFunctionBuilders.weightFactorFunction(10)
            )
        });
    request.source().query(functionScoreQuery);
}

DSL数据聚合

聚合的种类

聚合常见的有三类：

  • 桶（Bucket）聚合：用来对文档做分组

    • TermAggregation：按照文档字段值分组，例如按照品牌值分组、按照国家分组
    • Date Histogram：按照日期阶梯分组，例如一周为一组，或者一月为一组

  • 度量（Metric）聚合：用以计算一些值，比如：最大值、最小值、平均值等

    • Avg：求平均值
    • Max：求最大值
    • Min：求最小值
    • Stats：同时求max、min、avg、sum等

  • 管道（pipeline）聚合：其它聚合的结果为基础做聚合

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

Bucket聚合语法

需求：现在，我们要统计所有数据中的酒店品牌有几种，其实就是按照品牌对数据分组。此时可以根据酒店品牌的名称做聚合，也就是Bucket聚合。

默认情况下，Bucket聚合会统计Bucket内的文档数量，记为_count，并且按照_count降序排序。
我们可以指定order属性，自定义聚合的排序方式

默认情况下，Bucket聚合是对索引库的所有文档做聚合，但真实场景下，用户会输入搜索条件，因此聚合必须是对搜索结果聚合。那么聚合必须添加限定条件。
我们可以限定要聚合的文档范围，只要添加query条件即可

语法如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
GET /hotel/_search
{
 "query": {
    "range": {
      "price": {
        "lte": 200 // 只对200元以下的文档聚合
      }
    }
  },
  "size": 0,  // 设置size为0，结果中不包含文档，只包含聚合结果
  "aggs": { // 定义聚合
    "brandAgg": { //给聚合起个名字
      "terms": { // 聚合的类型，按照品牌值聚合，所以选择term
        "field": "brand", // 参与聚合的字段
        "order": {
          "_count": "asc" // 按照_count升序排列
        },
        "size": 20 // 希望获取的聚合结果数量
      }
    }
  }
}

Metric聚合语法

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

这就要用到Metric聚合了，例如stat聚合：就可以获取min、max、avg等结果。

语法如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
GET /hotel/_search
{
  "size": 0, 
  "aggs": {
    "brandAgg": { 
      "terms": { 
        "field": "brand", 
        "size": 20
      },
      "aggs": { // 是brands聚合的子聚合，也就是分组后对每组分别计算
        "score_stats": { // 聚合名称
          "stats": { // 聚合类型，这里stats可以计算min、max、avg等
            "field": "score" // 聚合字段，这里是score
          }
        }
      }
    }
  }
}

这次的score_stats聚合是在brandAgg的聚合内部嵌套的子聚合。因为我们需要在每个桶分别计算。

另外，我们还可以给聚合结果做个排序，例如按照每个桶的酒店平均分做排序：把order里的排序改成score_stats.avg即可

小结

aggs代表聚合，与query同级，此时query的作用是？

  • 限定聚合的的文档范围

聚合必须的三要素：

  • 聚合名称
  • 聚合类型
  • 聚合字段

聚合可配置属性有：

  • size：指定聚合结果数量
  • order：指定聚合结果排序方式
  • field：指定聚合字段

RestAPI实现聚合

API语法

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

RestClient聚合查询.png

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

RestClient聚合结果解析.png

业务需求

需求：搜索页面的品牌、城市等信息不应该是在页面写死，而是通过聚合索引库中的酒店数据得来的：因为是对搜索结果聚合，因此聚合是限定范围的聚合，也就是说聚合的限定条件跟搜索文档的条件一致。

请求参数与搜索文档的参数完全一致。也就是说，搜索条件改变会导致搜索提示条目改变，并且聚合限定条件就是搜索条件

结果是一个Map结构：

  • key是字符串，城市、星级、品牌、价格
  • value是集合，例如多个城市的名称

业务实现

在cn.itcast.hotel.web包的HotelController中添加一个方法，遵循下面的要求：

  • 请求方式：POST
  • 请求路径：/hotel/filters
  • 请求参数：RequestParams，与搜索文档的参数一致
  • 返回值类型：Map<String, List<String>>

代码：

1
2
3
4
@PostMapping("filters")
public Map<String, List<String>> getFilters(@RequestBody RequestParams params){
    return hotelService.getFilters(params);
}

在cn.itcast.hotel.service.IHotelService中定义新方法：

1
Map<String, List<String>> filters(RequestParams params);

在cn.itcast.hotel.service.impl.HotelService中实现该方法：

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
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
@Override
public Map<String, List<String>> filters(RequestParams params) {
    try {
        // 1.准备Request
        SearchRequest request = new SearchRequest("hotel");
        // 2.准备DSL
        // 2.1.query
        buildBasicQuery(params, request);
        // 2.2.设置size
        request.source().size(0);
        // 2.3.聚合
        buildAggregation(request);
        // 3.发出请求
        SearchResponse response = client.search(request, RequestOptions.DEFAULT);
        // 4.解析结果
        Map<String, List<String>> result = new HashMap<>();
        Aggregations aggregations = response.getAggregations();
        // 4.1.根据品牌名称，获取品牌结果
        List<String> brandList = getAggByName(aggregations, "brandAgg");
        result.put("品牌", brandList);
        // 4.2.根据品牌名称，获取品牌结果
        List<String> cityList = getAggByName(aggregations, "cityAgg");
        result.put("城市", cityList);
        // 4.3.根据品牌名称，获取品牌结果
        List<String> starList = getAggByName(aggregations, "starAgg");
        result.put("星级", starList);

        return result;
    } catch (IOException e) {
        throw new RuntimeException(e);
    }
}

private void buildAggregation(SearchRequest request) {
    request.source().aggregation(AggregationBuilders
                                 .terms("brandAgg")
                                 .field("brand")
                                 .size(100)
                                );
    request.source().aggregation(AggregationBuilders
                                 .terms("cityAgg")
                                 .field("city")
                                 .size(100)
                                );
    request.source().aggregation(AggregationBuilders
                                 .terms("starAgg")
                                 .field("starName")
                                 .size(100)
                                );
}
//解析聚合结果
private List<String> getAggByName(Aggregations aggregations, String aggName) {
    // 4.1.根据聚合名称获取聚合结果
    Terms brandTerms = aggregations.get(aggName);
    // 4.2.获取buckets
    List<? extends Terms.Bucket> buckets = brandTerms.getBuckets();
    // 4.3.遍历
    List<String> brandList = new ArrayList<>();
    for (Terms.Bucket bucket : buckets) {
        // 4.4.获取key
        String key = bucket.getKeyAsString();
        brandList.add(key);
    }
    return brandList;
}

自动补全

需求：搜索引擎基本都具备的根据用户输入的拼音或者汉字补全用户可能查找的商品名称

拼音分词器

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

安装方式与IK分词器一样，分三步：

①解压

②上传到虚拟机中，elasticsearch的plugin目录

③重启elasticsearch

④测试

自定义分词器

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

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

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

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

分词器架构.png

需要注意的是，tokenizer分割的词条和filter过滤转换的词条都会保留

声明自定义分词器的语法如下：

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
PUT /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",
        "search_analyzer": "ik_smart"
      }
    }
  }
}

上述代码的分词器只会在索引库test内部生效
并且为了防止搜索比如狮子时出现狮子和虱子，不能在搜索时采用拼音分词器，拼音分词器会检索出pinyin，同音字，一起搜索出来

总结：

如何使用拼音分词器？

  • ①下载pinyin分词器

  • ②解压并放到elasticsearch的plugin目录

  • ③重启即可

如何自定义分词器？

  • ①创建索引库时，在settings中配置，可以包含三部分

  • ②character filter

  • ③tokenizer

  • ④filter

拼音分词器注意事项？

  • 为了避免搜索到同音字，搜索时不要使用拼音分词器

自动补全查询

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

  • 参与补全查询的字段必须是completion类型。

  • 字段的内容一般是用来补全的多个词条形成的数组。

ex

比如，一个这样的索引库：

1
2
3
4
5
6
7
8
9
10
11
12
13
// 创建索引库
PUT test
{
 //...省略了配置分词器的代码
  "mappings": {
    "properties": {
      "title":{
        "type": "completion"
        //...省略了分词器
      }
    }
  }
}

然后插入下面的数据：

1
2
3
4
5
6
7
8
9
10
11
12
13
// 示例数据
POST test/_doc
{
  "title": ["Sony", "WH-1000XM3"]
}
POST test/_doc
{
  "title": ["SK-II", "PITERA"]
}
POST test/_doc
{
  "title": ["Nintendo", "switch"]
}

查询的DSL语句如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// 自动补全查询
GET /test/_search
{
  "suggest": {
    "title_suggest": {//自定义自动补全名称
      "text": "s", // 关键字
      "completion": { //指定自动补全类型
        "field": "title", // 补全查询的字段
        "skip_duplicates": true, // 跳过重复的
        "size": 10 // 获取前10条结果
      }
    }
  }
}

实现酒店搜索框自动补全

因此，总结一下，我们需要做的事情包括：

  1. 修改hotel索引库结构，设置自定义拼音分词器

  2. 修改索引库的name、all字段，使用自定义分词器

  3. 索引库添加一个新字段suggestion，类型为completion类型，使用自定义的分词器

  4. 给HotelDoc类添加suggestion字段，内容包含brand、business

  5. 重新导入数据到hotel库

修改酒店映射结构

代码如下：

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
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
// 酒店数据索引库
PUT /hotel
{
  "settings": {
    "analysis": {
      "analyzer": {
        "text_anlyzer": {
          "tokenizer": "ik_max_word",
          "filter": "py"
        },
        "completion_analyzer": {
          "tokenizer": "keyword",
          "filter": "py"
        }
      },
      "filter": {
        "py": {
          "type": "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": {
      "id":{
        "type": "keyword"
      },
      "name":{
        "type": "text",
        "analyzer": "text_anlyzer",
        "search_analyzer": "ik_smart",
        "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": "text_anlyzer",
        "search_analyzer": "ik_smart"
      },
      "suggestion":{
          "type": "completion",
          "analyzer": "completion_analyzer"
      }
    }
  }
}

修改HotelDoc实体

HotelDoc中要添加一个字段，用来做自动补全，内容可以是酒店品牌、城市、商圈等信息。按照自动补全字段的要求，最好是这些字段的数组。

因此我们在HotelDoc中添加一个suggestion字段，类型为List<String>，然后将brand、city、business等信息放到里面。

代码如下：

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
@Data
@NoArgsConstructor
public class HotelDoc {
    private Long id;
    private String name;
    private String address;
    private Integer price;
    private Integer score;
    private String brand;
    private String city;
    private String starName;
    private String business;
    private String location;
    private String pic;
    private Object distance;
    private Boolean isAD;
    private List<String> suggestion;

    public HotelDoc(Hotel hotel) {
        this.id = hotel.getId();
        this.name = hotel.getName();
        this.address = hotel.getAddress();
        this.price = hotel.getPrice();
        this.score = hotel.getScore();
        this.brand = hotel.getBrand();
        this.city = hotel.getCity();
        this.starName = hotel.getStarName();
        this.business = hotel.getBusiness();
        this.location = hotel.getLatitude() + ", " + hotel.getLongitude();
        this.pic = hotel.getPic();
        // 组装suggestion
        if(this.business.contains("/")){
            // business有多个值，需要切割
            String[] arr = this.business.split("/");
            // 添加元素
            this.suggestion = new ArrayList<>();
            this.suggestion.add(this.brand);
            Collections.addAll(this.suggestion, arr);
        }else {
            this.suggestion = Arrays.asList(this.brand, this.business);
        }
    }
}

重新导入

重新执行之前编写的导入数据功能addDocuments，在测试类中，可以看到新的酒店数据中包含了suggestion：

实现搜索框自动补全

返回值是补全词条的集合，类型为List<String>

1）在cn.itcast.hotel.web包下的HotelController中添加新接口，接收新的请求：

1
2
3
4
@GetMapping("suggestion")
public List<String> getSuggestions(@RequestParam("key") String prefix) {
    return hotelService.getSuggestions(prefix);
}

2）在cn.itcast.hotel.service包下的IhotelService中添加方法：

1
List<String> getSuggestions(String prefix);

3）在cn.itcast.hotel.service.impl.HotelService中实现该方法：

RestAPI查询自动补全completion字段

RestClient自动补全请求.png

RestAPI解析结果：
RestClient自动补全结果解析.png

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
@Override
public List<String> getSuggestions(String prefix) {
    try {
        // 1.准备Request
        SearchRequest request = new SearchRequest("hotel");
        // 2.准备DSL
        request.source().suggest(new SuggestBuilder().addSuggestion(
            "suggestions",
            SuggestBuilders.completionSuggestion("suggestion")
            .prefix(prefix)
            .skipDuplicates(true)
            .size(10)
        ));
        // 3.发起请求
        SearchResponse response = client.search(request, RequestOptions.DEFAULT);
        // 4.解析结果
        Suggest suggest = response.getSuggest();
        // 4.1.根据补全查询名称，获取补全结果
        CompletionSuggestion suggestions = suggest.getSuggestion("suggestions");
        // 4.2.获取options
        List<CompletionSuggestion.Entry.Option> options = suggestions.getOptions();
        // 4.3.遍历
        List<String> list = new ArrayList<>(options.size());
        for (CompletionSuggestion.Entry.Option option : options) {
            String text = option.getText().toString();
            list.add(text);
        }
        return list;
    } catch (IOException e) {
        throw new RuntimeException(e);
    }
}

数据同步

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

思路分析

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

  • 同步调用
  • 异步通知
  • 监听binlog（对mysql服务器的压力较大）

同步调用

方案一：同步调用

esAndMysql同步调用.png

基本步骤如下：

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

异步通知

方案二：异步通知

esAndMysql异步通知.png

流程如下：

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

监听binlog

方案三：监听binlog

esAndMysql监听binlog.png

流程如下：

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

选择

方式一：同步调用

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

方式二：异步通知

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

方式三：监听binlog

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

实现数据同步

思路

步骤：

  • 导入提供的hotel-admin项目，启动并测试酒店数据的CRUD

  • 声明exchange、queue、RoutingKey

  • 在hotel-admin中的增、删、改业务中完成消息发送

  • 在hotel-demo中完成消息监听，并更新elasticsearch中数据

  • 启动并测试数据同步功能

具体实现

导入hotel-admin

服务注册到RabbitMQ 并且实现exchange、queue、RoutingKey

MQ结构如图：

hotelMQ架构.png

  • 引入依赖

在hotel-admin、hotel-demo中引入rabbitmq的依赖：

1
2
3
4
5
<!--amqp-->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-amqp</artifactId>
</dependency>

  • 在hotel-admin、hotel-demo中的配置application.yaml文件中配置连接mq服务器信息

  • 1
    2
    3
    4
    5
    6
    7
    spring:
      rabbitmq:
        host: 192.168.174.128
        port: 5672
        username: itcast
        virtual-host: /
        password: 123321

  • 声明队列交换机名称

在hotel-admin和hotel-demo中的cn.itcast.hotel.constatnts包下新建一个类MqConstants：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
package cn.itcast.hotel.constatnts;

    public class MqConstants {
    /**
     * 交换机
     */
    public final static String HOTEL_EXCHANGE = "hotel.topic";
    /**
     * 监听新增和修改的队列
     */
    public final static String HOTEL_INSERT_QUEUE = "hotel.insert.queue";
    /**
     * 监听删除的队列
     */
    public final static String HOTEL_DELETE_QUEUE = "hotel.delete.queue";
    /**
     * 新增或修改的RoutingKey
     */
    public final static String HOTEL_INSERT_KEY = "hotel.insert";
    /**
     * 删除的RoutingKey
     */
    public final static String HOTEL_DELETE_KEY = "hotel.delete";
}
  • 声明队列交换机

在hotel-demo中，定义配置类，声明队列、交换机：

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

@Configuration
public class MqConfig {
    @Bean
    public TopicExchange topicExchange(){
        return new TopicExchange(MqConstants.HOTEL_EXCHANGE, true, false);
    }

    @Bean
    public Queue insertQueue(){
        return new Queue(MqConstants.HOTEL_INSERT_QUEUE, true);
    }

    @Bean
    public Queue deleteQueue(){
        return new Queue(MqConstants.HOTEL_DELETE_QUEUE, true);
    }

    @Bean
    public Binding insertQueueBinding(){
        return BindingBuilder.bind(insertQueue()).to(topicExchange()).with(MqConstants.HOTEL_INSERT_KEY);
    }

    @Bean
    public Binding deleteQueueBinding(){
        return BindingBuilder.bind(deleteQueue()).to(topicExchange()).with(MqConstants.HOTEL_DELETE_KEY);
    }
}

发送MQ消息

在hotel-admin中的增、删、改业务中分别发送MQ消息：

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
   @Autowired //amqp发送端
   private RabbitTemplate rabbitTemplate;
   
   @Autowired
   private IHotelService hotelService;
   
   //新增
   @PostMapping
   public void saveHotel(@RequestBody Hotel hotel){

       hotelService.save(hotel);
//发送通知        
       rabbitTemplate.convertAndSend(MqConstants.HOTEL_EXCHANGE,MqConstants.HOTEL_INSERT_KEY,hotel.getId());

   }

//更新
   @PutMapping()
   public void updateById(@RequestBody Hotel hotel){
       if (hotel.getId() == null) {
           throw new InvalidParameterException("id不能为空");
       }
       hotelService.updateById(hotel);
       //发送通知        
       rabbitTemplate.convertAndSend(MqConstants.HOTEL_EXCHANGE,MqConstants.HOTEL_INSERT_KEY,hotel.getId());
   }

//删除
   @DeleteMapping("/{id}")
   public void deleteById(@PathVariable("id") Long id) {
       hotelService.removeById(id);
       //发送通知        
       rabbitTemplate.convertAndSend(MqConstants.HOTEL_EXCHANGE,MqConstants.HOTEL_DELETE_KEY,id);
   }

接收MQ消息

hotel-demo接收到MQ消息要做的事情包括：

  • 新增消息：根据传递的hotel的id查询hotel信息，然后新增一条数据到索引库
  • 删除消息：根据传递的hotel的id删除索引库中的一条数据

1）首先在hotel-demo的cn.itcast.hotel.service包下的IHotelService中新增新增、删除业务

1
2
3
void deleteById(Long id);

void insertById(Long id);

2）给hotel-demo中的cn.itcast.hotel.service.impl包下的HotelService中实现业务：

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
@Override
public void deleteById(Long id) {
    try {
        // 1.准备Request
        DeleteRequest request = new DeleteRequest("hotel", id.toString());
        // 2.发送请求
        client.delete(request, RequestOptions.DEFAULT);
    } catch (IOException e) {
        throw new RuntimeException(e);
    }
}

@Override
public void insertById(Long id) {
    try {
        // 0.根据id查询酒店数据
        Hotel hotel = getById(id);
        // 转换为文档类型
        HotelDoc hotelDoc = new HotelDoc(hotel);

        // 1.准备Request对象
        IndexRequest request = new IndexRequest("hotel").id(hotel.getId().toString());
        // 2.准备Json文档
        request.source(JSON.toJSONString(hotelDoc), XContentType.JSON);
        // 3.发送请求
        client.index(request, RequestOptions.DEFAULT);
    } catch (IOException e) {
        throw new RuntimeException(e);
    }
}

3）编写监听器

在hotel-demo中的cn.itcast.hotel.mq包新增一个类：

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

@Component
public class HotelListener {

    @Autowired
    private IHotelService hotelService;

    /**
     * 监听酒店新增或修改的业务
     * @param id 酒店id
     */
    @RabbitListener(queues = MqConstants.HOTEL_INSERT_QUEUE)
    public void listenHotelInsertOrUpdate(Long id){
        hotelService.insertById(id);
    }

    /**
     * 监听酒店删除的业务
     * @param id 酒店id
     */
    @RabbitListener(queues = MqConstants.HOTEL_DELETE_QUEUE)
    public void listenHotelDelete(Long id){
        hotelService.deleteById(id);
    }
}

es集群

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

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

ES集群相关概念:

  • 集群（cluster）：一组拥有共同的 cluster name 的 节点。

  • 节点（node) ：集群中的一个 Elasticearch 实例

  • 分片（shard）：索引可以被拆分为不同的部分进行存储，称为分片。在集群环境下，一个索引的不同分片可以拆分到不同的节点中

    解决问题：数据量太大，单点存储量有限的问题。

    此处，我们把数据分成3片：shard0、shard1、shard2

  • 主分片（Primary shard）：相对于副本分片的定义。

  • 副本分片（Replica shard）每个主分片可以有一个或者多个副本，数据和主分片一样。

数据备份可以保证高可用，但是每个分片备份一份，所需要的节点数量就会翻一倍，成本实在是太高了！

为了在高可用和成本间寻求平衡，我们可以这样做：

  • 首先对数据分片，存储到不同节点
  • 然后对每个分片进行备份，放到对方节点，完成互相备份

这样可以大大减少所需要的服务节点数量，如图，我们以3分片，每个分片备份一份为例：

es集群分片结构.png

现在，每个分片都有1个备份，存储在3个节点：

  • node0：保存了分片0和1
  • node1：保存了分片0和2
  • node2：保存了分片1和2

搭建ES集群

部署es集群可以直接使用docker-compose来完成，但这要求你的Linux虚拟机至少有4G的内存空间

创建es集群

首先编写一个docker-compose文件，内容如下：

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
47
48
49
50
51
52
53
54
55
56
57
58
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
      - 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

es运行需要修改一些linux系统权限，修改/etc/sysctl.conf文件

1
vi /etc/sysctl.conf

添加下面的内容：

1
vm.max_map_count=262144

然后执行命令，让配置生效：

1
sysctl -p

通过docker-compose启动集群：

1
docker-compose up -d

集群状态监控

使用cerebro来监控es集群状态，官方网址：https://github.com/lmenezes/cerebro

下载下来可以绿色点击启动，通过输入集群的节点ip进入查看集群的状态。

绿色的条，代表集群处于绿色（健康状态）。
黄色的条，代表集群处于危险状态（一般是集群的节点出现了再挂一个就会丢失分片的情况，一般是某个节点挂了导致的，但是同时集群如果识别到了这种危险状态会自行进行故障转移）

同时可以配置分片和备份数量+创建索引库，索引库一旦创建，分片数量不可更改！！！。

在DevTools中输入指令：（或者可视化配置）

1
2
3
4
5
6
7
8
9
10
11
12
PUT /itcast
{
  "settings": {
    "number_of_shards": 3, // 分片数量
    "number_of_replicas": 1 // 副本数量
  },
  "mappings": {
    "properties": {
      // mapping映射定义 ...
    }
  }
}

集群职责划分

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

es节点职责分类.png

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

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

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

职责分离可以让我们根据不同节点的需求分配不同的硬件去部署。而且避免业务之间的互相干扰。并且可以降低耦合性以及防止同一节点上出现cpu或者内存资源占用抢占的情况出现

一个典型的es集群职责划分如图：

es集群架构.png

脑裂问题

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

例如一个有三个节点的集群中，主节点node1与其它节点失联，此时，node2和node3认为node1宕机，就会重新选主，当node3当选后，集群继续对外提供服务，node2和node3自成集群，node1自成集群，两个集群数据不同步，出现数据差异。当网络恢复后，因为集群中有两个master节点，集群状态的不一致，出现脑裂的情况：

解决脑裂的方案是，要求选票超过 ( eligible节点数量 + 1 ）/ 2 才能当选为主，因此eligible节点数量最好是奇数。对应配置项是discovery.zen.minimum_master_nodes，在es7.0以后，已经成为默认配置，因此一般不会发生脑裂问题

例如：3个节点形成的集群，选票必须超过 （3 + 1） / 2 ，也就是2票。node3得到node2和node3的选票，当选为主。node1只有自己1票，没有当选。集群中依然只有1个主节点，没有出现脑裂。

集群分布式存储

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

分片存储原理

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

确定分片hash算法.png

说明：

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

新增文档的流程如下：

es集群根据id操作的相关流程.png

解读：

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

集群分布式查询

elasticsearch的查询分成两个阶段：

  • scatter phase：分散阶段，coordinating node会把请求分发到每一个分片

  • gather phase：聚集阶段，coordinating node汇总data node的搜索结果，并处理为最终结果集返回给用户

分布式查询.png

集群故障转移

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

1）例如一个集群结构如图：现在，node1是主节点，其它两个节点是从节点。

2）突然，node1发生了故障：宕机后的第一件事，需要重新选主，例如选中了node2：node2成为主节点后，会检测集群监控状态，发现：shard-1、shard-0没有副本节点。因此需要将node1上的数据迁移到node2、node3：

3）如果node1重新回归了正常，备份的分片数据会重新做负载均衡，放回到node1上

es集群故障转移.png