微服务技术栈
基础篇
本篇微服务技术栈参考: https://www.xn2001.com/archives/663.html
认识微服务
单体架构
单体架构: 将业务的所有功能集中在一个项目中开发,打成一个包部署。
优点: 架构简单,部署成本低
缺点: 耦合度高(维护困难,升级困难)
分布式架构
分布式架构: 根据业务功能对系统做拆分,每个业务功能模块作为独立项目开发,称为一个服务
优点: 降低服务耦合,有利于服务升级和扩展
缺点: 服务调用关系错综复杂
分布式架构虽然降低了服务耦合,但是服务拆分时也有很多问题需要思考:
- 服务拆分的粒度如何界定?
- 服务之间如何调用?
- 服务的调用关系如何管理?
人们需要指定一套行之有效的标准来约束分布式架构。
微服务
微服务的架构特征:
- 单一职责: 微服务拆分粒度更小,每一个服务都对应唯一的业务功能,做到单一职责
- 自治: 团队独立、技术独立、数据独立、独立部署和交付
- 面向服务: 服务提供统一标准的接口,与语言和技术无关
- 隔离性强: 服务调度做和隔离、容错、降级,避免出现级联问题
微服务的上述特性其实是在给分布式架构指定一个标准,进一步降低服务之间的耦合度,提供服务的独立性和灵活性。做到高内聚,低耦合。
因此,可以认为微服务是一种经过良好架构设计的分布式架构方案。
其中在Java领域最引人注目的就是SpringCloud提供的方案了。https://spring.io/projects/spring-cloud
SpringCloud
SpringCloud是目前国内使用最广泛的微服务架构。官网地址:https://spring.io/projects/spring-cloud
SpringCloud集成了各种微服务功能组件,并基于SpringBoot实现了这些组件的自动装配,从而提供了良好的开箱即用体验。
其中常见的组件包括:
另外,SpringCloud底层是依赖于SpringBoot的,并且有版本的兼容关系,如下:
内容知识
技术栈对比
服务拆分
服务器拆分注意事项
单一职责:不同微服务,不要重复开发相同业务
数据独立:不要访问其他微服务的数据库
面向服务:将自己的业务暴露为接口,供其他微服务调用
cloude-demo:夫工程,管理依赖
- order-service:订单微服务,负责订单相关业务
- user-service:用户微服务,负责用户相关业务
要求:
- 订单微服务和用户微服务都必须有各自的数据库,相互独立
- 订单服务和用户服务**都对外暴露Restful的接口
- 订单服务如果需要查询用户信息,只能调用用户服务的Restful接口, 不能查询用户数据库
微服务项目下,打开IDEA的Service,可以很方便地启动。
启动完成后,访问 http://localhost:8080/order/101
远程调用
服务拆分要求:
订单服务如果需要查询用户信息,只能调用用户服务的Restful接口,不能查询用户数据库
因此外卖需要知道Java如何去发送http请求,Spring提供了一个RestTemplate工具,只需要把它创建出来即可。(即注入Bean)
1 |
|
发送请求,自动序列化为java对象。
1 | public Order queryOrderById(Long orderId) { |
启动完成后,访问:http://localhost:8080/order/101
在上面代码的url中,我们可以发现调用服务的地址采用硬编码,这在后续的开发中肯定是不理想的,这就需要服务注册中心(Eureka) 来帮我们解决这个事情。
Eureka
Eureka注册中心
最广为人知的注册中心就是Eureka,其结构如下:
order-service如何得知user-service实例地址?
- user-service服务实例启动后,将自己的信息注册到eureka-service(Eureka服务端),也叫服务注册
- eureka-server保存服务名称到服务实例地址列表的映射关系
- order-service根据服务名称,拉取实例地址列表,这个叫服务发现或服务拉取
order-service如何从多个user-service实例中选择具体的实例?
order-service从实例列表中利用负载均衡算法选中一个实例地址,向该实例地址发起远程调用
order-service如何得知某个user-service实例是否依然健康,是不是已经宕机?
- user-service会每隔一段时间(默认30秒)向eureka-server发起请求,报告自己状态,称为心跳
- 当超过一定时间没有发送心跳时,eureka-server会认为微服务实例故障,将该实例从服务列表中剔除
- order-service拉取请求时,就能将故障实例排除了
接下来我们动手实践的步骤包括
搭建注册中心
1、搭建eureka-server
引入SpringCloud为eureka提供的starter依赖,注意这里是用server
1 | <dependency> |
2、编写启动类
注意要添加一个@EnableEurekaServer注解,开启eureka的注册中心功能
1 | package com.xn2001.eureka; |
3、编写配置文件
编写一个application.yml文件,内容如下:
1 | server: |
其中default-zone
是因为前面配置类开启了注册中心所需要配置的eureka的地址信息,因为eureka本事也是一个微服务,这里也要将自己注册起来,当后面eureka集群时,这里就可以填写多个,使用“ ;”隔开。
启动完成后,访问 http://localhost:10086/
服务注册
将user-service、order-service都注册到eureka
引入SpringCloud为eureka提供的starter依赖,注意这里是用client
1 | <dependency> |
在启动类上添加注解:@EnableEurekaClient
在application.yml文件,添加下面的配置:
1 | spring: |
3个项目启动后,访问 http://localhost:10086/
这里另外再补充个小技巧,我们可以通过 idea 的多实例启动,来查看 Eureka 的集群效果。
4个项目启动后,访问 http://localhost:10086/
服务拉取
在order-service中完成服务拉取,然后通过负载均衡挑选一个服务,实践远程调用
下面我们让 order-service 向 eureka-server 拉取 user-service 的信息,实现服务发现。
首先给 RestTemplate
这个 Bean 添加一个 @LoadBalanced
注解,用于开启负载均衡。(后面会讲)
1 |
|
修改orderService访问的url路径,用服务名代替ip、端口
spring会自动帮助我们从eureka-server中,根据uservice这个服务名称,获取实例列表后去完成负载均衡。
Ribbon
Ribbon负载均衡
我们添加了@LoalBalanced
注解,即可实现负载均衡功能,这是什么原理呢?
SpringCloud底层提供了一个名为Ribbon的组件,来实现负载均衡功能
1、源码跟踪
为什么我们只输入了service名称就可以访问了呢?为什么不需要获取ip和端口,这显然有人帮我们根据service名称,获取到了服务实例的ip和端口,他就是LoadBalancerInterceptor
,这个类会对RestTemplate的请求进行拦截,然后从Eureka根据服务id获取服务列表,随后根据负载均衡算法得到真实的服务地址信息,替换服务id。
我们进行源码跟踪:
这里的intercept()
方法,拦截了用户的HttpRequest请求,然后做了几件事:
request.getURL()
:获取请求uri,即http://user-service/user/8originalUri.getHost()
:获取uri路径的主机名,其实就是服务iduser-service
this.loadBalancer.execute()
:处理服务id,和用户请求
这里的this.loadBalancer.execute()
:处理服务id和请求
继续跟人execute()
方法:
getLoadBalancer(serviceId)
:根据服务id获取IloadBalancer
,而ILoadBancer
会拿着服务id去eureka中获取服务列表getServer(loadBalancer)
:利用内置的负载均衡算法,从服务列表中选择一个。在图中可以看到获取了8082端口的服务
可以看到获取服务时,通过一个getServer()
方法来做负载均衡:
我们继续跟入:
继续跟踪源码 chooseServer()
方法,发现这么一段代码:
![跟踪源码 chooseServer()方法](/img/跟踪源码 chooseServer()方法.png)
我们看看这个 rule
是谁:
这里的 rule 默认值是一个 RoundRobinRule
,看类的介绍:
负载均衡默认使用了轮训算法,当然我们也可以自定义。
2、流程总结
SpringCloud Ribbon 底层采用了一个拦截器,拦截了 RestTemplate 发出的请求,对地址做了修改。
基本流程如下:
- 拦截我们的
RestTemplate
请求 http://userservice/user/1 RibbonLoadBalancerClient
会从请求url中获取服务名称,也就是 user-serviceDynamicServerListLoadBalancer
根据 user-service 到 eureka 拉取服务列表- eureka 返回列表,localhost:8081、localhost:8082
IRule
利用内置负载均衡规则,从列表中选择一个,例如 localhost:8081RibbonLoadBalancerClient
修改请求地址,用 localhost:8081 替代 userservice,得到 http://localhost:8081/user/1,发起真实请求
3、负载均衡策略
负载均衡的规则都定义在 IRule 接口中,而 IRule 有很多不同的实现类:
不同规则的含义如下:
内置负载均衡规则类 | 规则描述 |
---|---|
RoundRobinRule | 简单轮询服务列表来选择服务器。它是Ribbon默认的负载均衡规则。 |
AvailabilityFilteringRule | 对以下两种服务器进行忽略:(1)在默认情况下,这台服务器如果3次连接失败,这台服务器就会被设置为“短路”状态。短路状态将持续30秒,如果再次连接失败,短路的持续时间就会几何级地增加。 (2)并发数过高的服务器。如果一个服务器的并发连接数过高,配置了AvailabilityFilteringRule 规则的客户端也会将其忽略。并发连接数的上限,可以由客户端设置。 |
WeightedResponseTimeRule | 为每一个服务器赋予一个权重值。服务器响应时间越长,这个服务器的权重就越小。这个规则会随机选择服务器,这个权重值会影响服务器的选择。 |
ZoneAvoidanceRule | 以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类,这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。 |
BestAvailableRule | 忽略那些短路的服务器,并选择并发数较低的服务器。 |
RandomRule | 随机选择一个可用的服务器。 |
RetryRule | 重试机制的选择逻辑 |
默认的实现就是 ZoneAvoidanceRule
,是一种轮询方案。
4、自定义策略
通过定义 IRule 实现可以修改负载均衡规则,有两种方式:
1 代码方式在 order-service 中的 OrderApplication 类中,定义一个新的 IRule:
2 配置文件方式:在 order-service 的 application.yml 文件中,添加新的配置也可以修改规则:
1 | userservice: # 给需要调用的微服务配置负载均衡规则,orderservice服务去调用userservice服务 |
注意:一般用默认的负载均衡规则,不做修改。
5、饥饿加载
当我们启动 orderservice,第一次访问时,时间消耗会大很多,这是因为 Ribbon 懒加载的机制。
Ribbon 默认是采用懒加载,即第一次访问时才会去创建 LoadBalanceClient,拉取集群地址,所以请求时间会很长。
而饥饿加载则会在项目启动时创建 LoadBalanceClient,降低第一次访问的耗时,通过下面配置开启饥饿加载:
1 | ribbon: |
Nacos
Nacos注册中心
SpringCloudAlibaba 推出了一个名为 Nacos 的注册中心,在国外也有大量的使用。
解压启动Nacos,详细请看Nacos安装指南
1 | # 单机启动 |
访问:http://localhost:8848/nacos/
1、服务注册
这里上来就直接服务注册,很多东西可能有疑惑,其实 Nacos 本身就是一个 SprintBoot 项目,这点你从启动的控制台打印就可以看出来,所以就不再需要去额外搭建一个像 Eureka 的注册中心。
引入依赖
在 cloud-demo 父工程中引入 SpringCloudAlibaba 的依赖:
1 | <dependency> |
然后在 user-service 和 order-service 中的pom文件中引入 nacos-discovery 依赖:
1 | <dependency> |
配置nacos地址
在 user-service 和 order-service 的 application.yml 中添加 nacos 地址:
1 | spring: |
项目重新启动后,可以看到三个服务都被注册进了 Nacos
浏览器访问:http://localhost:8080/order/101,正常访问,同时负载均衡也正常。
分级存储模型
一个服务可以有多个实例,例如我们的 user-service,可以有:
- 127.0.0.1:8081
- 127.0.0.1:8082
- 127.0.0.1:8083
假如这些实例分布于全国各地的不同机房,例如:
- 127.0.0.1:8081,在上海机房
- 127.0.0.1:8082,在上海机房
- 127.0.0.1:8083,在杭州机房
Nacos就将同一机房内的实例,划分为一个集群。
微服务互相访问时,应该尽可能访问同集群实例,因为本地访问速度更快。当本集群内不可用时,才访问其它集群。例如:杭州机房内的 order-service 应该优先访问同机房的 user-service。
配置集群
接下来我们给 user-service 配置集群
修改 user-service 的 application.yml 文件,添加集群配置:
1 | spring: |
重启两个 user-service 实例后,我们再去启动一个上海集群的实例。
1 | -Dserver.port=8083 -Dspring.cloud.nacos.discovery.cluster-name=SH |
查看 nacos 控制台
NacosRule
Ribbon的默认实现 ZoneAvoidanceRule
并不能实现根据同集群优先来实现负载均衡,我们把规则改成 NacosRule 即可。我们是用 orderservice 调用 userservice,所以在 orderservice 配置规则。
1 |
|
另外,你同样可以使用配置的形式来完成,具体参考上面的 Ribbon 栏目。
1 | userservice: |
然后,再对 orderservice 配置集群。
1 | spring: |
现在我启动了四个服务,分别是:
- orderservice - HZ
- userservice - HZ
- userservice1 - HZ
- userservice2 - SH
访问地址:http://localhost:8080/order/101
在访问中我们发现,只有同在一个 HZ 集群下的 userservice、userservice1 会被调用,并且是随机的。
我们试着把 userservice、userservice2 停掉。依旧可以访问。
在 userservice3 控制台可以看到发出了一串的警告,因为 orderservice 本身是在 HZ 集群的,这波 HZ 集群没有了 userservice,就会去别的集群找。
权重配置
实际部署中会出现这样的场景:
服务器设备性能有差异,部分实例所在机器性能较好,另一些较差,我们希望性能好的机器承担更多的用户请求。但默认情况下 NacosRule 是同集群内随机挑选,不会考虑机器的性能问题。
因此,Nacos 提供了权重配置来控制访问频率,0~1 之间,权重越大则访问频率越高,权重修改为 0,则该实例永远不会被访问。
在 Nacos 控制台,找到 user-service 的实例列表,点击编辑,即可修改权重。
在弹出的编辑窗口,修改权重
另外,在服务升级的时候,有一种较好的方案:我们也可以通过调整权重来进行平滑升级,例如:先把 userservice 权重调节为 0,让用户先流向 userservice2、userservice3,升级 userservice后,再把权重从 0 调到 0.1,让一部分用户先体验,用户体验稳定后就可以往上调权重啦。
环境隔离
Nacos 提供了 namespace 来实现环境隔离功能。
- Nacos 中可以有多个 namespace
- namespace 下可以有 group、service 等
- 不同 namespace 之间相互隔离,例如不同 namespace 的服务互相不可见
1、创建namespace
默认情况下,所有 service、data、group 都在同一个 namespace,名为 public(保留空间):
我们可以点击页面新增按钮,添加一个 namespace:
然后,填写表单:
就能在页面看到一个新的 namespace:
2、配置namespace
给微服务配置 namespace 只能通过修改配置来实现。
例如,修改 order-service 的 application.yml 文件:
1 | spring: |
重启 order-service 后,访问控制台。
public
dev
此时访问 order-service,因为 namespace 不同,会导致找不到 userservice,控制台会报错:
临时实例
Nacos 的服务实例分为两种类型:
- 临时实例:如果实例宕机超过一定时间,会从服务列表剔除,默认的类型。
- 非临时实例:如果实例宕机,不会从服务列表剔除,也可以叫永久实例。
配置一个服务实例为永久实例:
1 | spring: |
另外,Nacos 集群**默认采用AP方式(可用性),当集群中存在非临时实例时,采用CP模式(一致性)**;而 Eureka 采用AP方式,不可切换。(这里说的是 CAP 原理,后面会写到)
Nacos配置中心
Nacos除了可以做注册中心,同样可以做配置管理来使用。
当微服务部署的实例越来越多,达到数十、数百时,逐个修改微服务配置就会让人抓狂,而且很容易出错。我们需要一种统一配置管理方案,可以集中管理所有实例的配置。
创建配置
在 Nacos 控制面板中添加配置文件
然后在弹出的表单中,填写配置信息:
注意:项目的核心配置,需要热更新的配置才有放到 nacos 管理的必要。基本不会变更的一些配置(例如数据库连接)还是保存在微服务本地比较好。
拉取配置
首先我们需要了解 Nacos 读取配置文件的环节是在哪一步,在没加入 Nacos 配置之前,获取配置是这样:
加入 Nacos 配置,它的读取是在 application.yml 之前的:
这时候如果把 nacos 地址放在 application.yml 中,显然是不合适的,Nacos 就无法根据地址去获取配置了。
因此,nacos 地址必须放在优先级最高的 bootstrap.yml 文件。
引入 nacos-config 依赖
首先,在 user-service 服务中,引入 nacos-config 的客户端依赖:
1 | <!--nacos配置管理依赖--> |
添加 bootstrap.yml
然后,在 user-service 中添加一个 bootstrap.yml 文件,内容如下:
1 | spring: |
根据 spring.cloud.nacos.server-addr 获取 nacos地址,再根据${spring.application.name}-${spring.profiles.active}.${spring.cloud.nacos.config.file-extension}
作为文件id,来读取配置。
在这个例子例中,就是去读取 userservice-dev.yaml
使用代码来验证是否拉取成功
在 user-service 中的 UserController 中添加业务逻辑,读取 pattern.dateformat 配置并使用:
1 |
|
启动服务后,访问:http://localhost:8081/user/now
配置共享
其实在服务启动时,nacos 会读取多个配置文件,例如:
[spring.application.name]-[spring.profiles.active].yaml
,例如:userservice-dev.yaml[spring.application.name].yaml
,例如:userservice.yaml
这里的 [spring.application.name].yaml
不包含环境,因此可以被多个环境共享。
添加一个环境共享配置
我们在 nacos 中添加一个 userservice.yaml 文件:
在 user-service 中读取共享配置
在 user-service 服务中,修改 PatternProperties 类,读取新添加的属性:
在 user-service 服务中,修改 UserController,添加一个方法:
运行两个 UserApplication,使用不同的profile
修改 UserApplication2 这个启动项,改变其profile值:
这样,UserApplication(8081) 使用的 profile 是 dev,UserApplication2(8082) 使用的 profile 是test
启动 UserApplication 和 UserApplication2
访问地址:http://localhost:8081/user/prop,结果:
访问地址:http://localhost:8082/user/prop,结果:
可以看出来,不管是 dev,还是 test 环境,都读取到了 envSharedValue 这个属性的值。
上面的都是同一个微服务下,那么不同微服务之间可以环境共享吗?
通过下面的两种方式来指定:
- extension-configs
- shared-configs
1 | spring: |
1 | spring: |
配置优先级
当 nacos、服务本地同时出现相同属性时,优先级有高低之分。
更细致的配置
Nacos集群
架构介绍
其中包含 3 个Nacos 节点,然后一个负载均衡器 Nginx 代理 3 个 Nacos,我们计划的 Nacos 集群如下图,MySQL 的主从复制后续再添加。
三个 Nacos 节点的地址
节点 | ip | port |
---|---|---|
nacos1 | 192.168.150.1 | 8845 |
nacos2 | 192.168.150.1 | 8846 |
nacos3 | 192.168.150.1 | 8847 |
初始化数据库
Nacos 默认数据存储在内嵌数据库 Derby 中,不属于生产可用的数据库。官方推荐的最佳实践是使用带有主从的高可用数据库集群,主从模式的高可用数据库。这里我们以单点的数据库为例。
首先新建一个数据库,命名为 nacos,而后导入下面的 SQL
1 | CREATE TABLE `config_info` ( |
配置Nacos
进入 nacos 的 conf 目录,修改配置文件 cluster.conf.example,重命名为 cluster.conf
添加内容
1 | 127.0.0.1:8845 |
然后修改 application.properties 文件,添加数据库配置
1 | spring.datasource.platform=mysql |
将 nacos 文件夹复制三份,分别命名为:nacos1、nacos2、nacos3
然后分别修改三个文件夹中的 application.properties,
nacos1
1 | server.port=8845 |
nacos2
1 | server.port=8846 |
nacos3
1 | server.port=8847 |
然后分别启动三个 nacos
1 | startup.cmd |
Nginx反向代理
修改 nginx 文件夹下的 conf/nginx.conf 文件,配置如下
1 | upstream nacos-cluster { |
启动 nginx,在浏览器访问:http://localhost/nacos
在代码中的 application.yml 文件配置改为如下:
1 | spring: |
实际部署时,需要给做反向代理的 Nginx 服务器设置一个域名,这样后续如果有服务器迁移 Nacos 的客户端也无需更改配置。Nacos 的各个节点应该部署到多个不同服务器,做好容灾和隔离工作。
Feign
我们以前利用 RestTemplate 发起远程调用的代码:
- 代码可读性差,编程体验不统一
- 参数复杂URL难以维护
Feign 是一个声明式的 http 客户端,官方地址:https://github.com/OpenFeign/feign
其作用就是帮助我们优雅的实现 http 请求的发送,解决上面提到的问题。
Feign使用
引入依赖
我们在 order-service 引入 feign 依赖:
1 | <dependency> |
添加注解
在 order-service 启动类添加注解开启 Feign
请求接口
在 order-service 中新建一个接口,内容如下
1 | package com.xn2001.order.client; |
@FeignClient("userservice")
:其中参数填写的是微服务名
@GetMapping("/user/{id}")
:其中参数填写的是请求路径
这个客户端主要是基于 SpringMVC 的注解 @GetMapping
来声明远程调用的信息
Feign 可以帮助我们发送 http 请求,无需自己使用 RestTemplate 来发送了。
测试
1 |
|
自定义配置
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 | feign: |
也可以针对所有服务:
1 | feign: |
而日志的级别分为四种:
- NONE:不记录任何日志信息,这是默认值。
- BASIC:仅记录请求的方法,URL以及响应状态码和执行时间
- HEADERS:在BASIC的基础上,额外记录了请求和响应的头信息
- FULL:记录所有请求和响应的明细,包括头信息、请求体、元数据
也可以基于 Java 代码来修改日志级别,先声明一个类,然后声明一个 Logger.Level 的对象
1 | public class DefaultFeignConfiguration { |
如果要全局生效,将其放到启动类的 @EnableFeignClients
这个注解中:
1 |
如果是局部生效,则把它放到对应的 @FeignClient
这个注解中:
1 |
性能优化
Feign 底层发起 http 请求,依赖于其它的框架。其底层客户端实现有:
- URLConnection:默认实现,不支持连接池
- Apache HttpClient :支持连接池
- OKHttp:支持连接池
因此提高 Feign 性能的主要手段就是使用连接池代替默认的 URLConnection
另外,日志级别应该尽量用 basic/none,可以有效提高性能。
这里我们用 Apache 的HttpClient来演示连接池。
在 order-service 的 pom 文件中引入 HttpClient 依赖
1 | <!--httpClient的依赖 --> |
配置连接池
在 order-service 的 application.yml 中添加配置
1 | feign: |
在 FeignClientFactoryBean 中的 loadBalance 方法中打断点
Debug 方式启动 order-service 服务,可以看到这里的 client,底层就是 HttpClient
最佳实践
继承方式
一样的代码可以通过继承来共享:
1)定义一个 API 接口,利用定义方法,并基于 SpringMVC 注解做声明
2)Feign 客户端、Controller 都集成该接口
优点
- 简单
- 实现了代码共享
缺点
- 服务提供方、服务消费方紧耦合
- 参数列表中的注解映射并不会继承,因此 Controller 中必须再次声明方法、参数列表、注解
抽取方式
将 FeignClient 抽取为独立模块,并且把接口有关的 pojo、默认的 Feign 配置都放到这个模块中,提供给所有消费者使用。
例如:将 UserClient、User、Feign 的默认配置都抽取到一个 feign-api 包中,所有微服务引用该依赖包,即可直接使用。
接下来我们就用该方法在代码中实现
首先创建一个 module,命名为 feign-api
在 feign-api 中然后引入依赖
1 | <dependency> |
order-service中 的 UserClient、User 都复制到 feign-api 项目中
接下来在 order-service 中使用 feign-api
由于我们已经将 UserClient、User 放在 fegin-api 中共享了 ,所以可以删除 order-service 中的 UserClient、User,然后在 order-service 中引入 feign-api
1 | <dependency> |
修改注解
当定义的 FeignClient 不在 SpringBootApplication 的扫描包范围下时,这些 FeignClient 就不能使用。
修改 order-service 启动类上的 @EnableFeignClients
注解
1 |
Gateway
Spring Cloud Gateway 是 Spring Cloud 的一个全新项目,该项目是基于 Spring 5.0,Spring Boot 2.0 和 Project Reactor 等响应式编程和事件流技术开发的网关,它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。
Gateway 网关是我们服务的守门神,所有微服务的统一入口。
网关的核心功能特性:
- 请求路由
- 权限控制
- 限流
权限控制:网关作为微服务入口,需要校验用户是是否有请求资格,如果没有则进行拦截。
路由和负载均衡:一切请求都必须先经过 gateway,但网关不处理业务,而是根据某种规则,把请求转发到某个微服务,这个过程叫做路由。当然路由的目标服务有多个时,还需要做负载均衡。
限流:当请求流量过高时,在网关中按照下流的微服务能够接受的速度来放行请求,避免服务压力过大。
在 SpringCloud 中网关的实现包括两种:
- gateway
- zuul
Zuul 是基于 Servlet 实现,属于阻塞式编程。而 Spring Cloud Gateway 则是基于 Spring5 中提供的WebFlux,属于响应式编程的实现,具备更好的性能。
入门使用
- 创建 SpringBoot 工程 gateway,引入网关依赖
- 编写启动类
- 编写基础配置和路由规则
- 启动网关服务进行测试
1 | <!--网关--> |
创建 application.yml 文件,内容如下:
1 | server: |
我们将符合Path
规则的一切请求,都代理到 uri
参数指定的地址。
上面的例子中,我们将 /user/**
开头的请求,代理到 lb://userservice
,其中 lb 是负载均衡(LoadBalance),根据服务名拉取服务列表,实现负载均衡。
重启网关,访问 http://localhost:10010/user/1 时,符合 /user/**
规则,请求转发到 uri:http://userservice/user/1
多个 predicates 的话,要同时满足规则,下文有例子。
流程图
路由配置包括:
- 路由id:路由的唯一标示
- 路由目标(uri):路由的目标地址,http代表固定地址,lb代表根据服务名负载均衡
- 路由断言(predicates):判断路由的规则
- 路由过滤器(filters):对请求或响应做处理
断言工厂
我们在配置文件中写的断言规则只是字符串,这些字符串会被 Predicate Factory 读取并处理,转变为路由判断的条件。
例如 Path=/user/**
是按照路径匹配,这个规则是由
org.springframework.cloud.gateway.handler.predicate.PathRoutePredicateFactory
类来处理的,像这样的断言工厂在 Spring Cloud Gateway 还有十几个
名称 | 说明 | 示例 |
---|---|---|
After | 是某个时间点后的请求 | - After=2037-01-20T17:42:47.789-07:00[America/Denver] |
Before | 是某个时间点之前的请求 | - Before=2031-04-13T15:14:47.433+08:00[Asia/Shanghai] |
Between | 是某两个时间点之前的请求 | - Between=2037-01-20T17:42:47.789-07:00[America/Denver], 2037-01-21T17:42:47.789-07:00[America/Denver] |
Cookie | 请求必须包含某些cookie | - Cookie=chocolate, ch.p |
Header | 请求必须包含某些header | - Header=X-Request-Id, \d+ |
Host | 请求必须是访问某个host(域名) | - Host=**.somehost.org , **.anotherhost.org |
Method | 请求方式必须是指定方式 | - Method=GET,POST |
Path | 请求路径必须符合指定规则 | - Path=/red/{segment},/blue/** |
Query | 请求参数必须包含指定参数 | - Query=name, Jack或者- Query=name |
RemoteAddr | 请求者的ip必须是指定范围 | - RemoteAddr=192.168.1.1/24 |
Weight | 权重处理 |
一般的,我们只需要掌握 Path,加上官方文档的例子,就可以应对各种工作场景了。
1 | predicates: |
像这样的规则,现在是 2021年8月22日01:32:42,很明显 After 条件不满足,可以不会转发,路由不起作用。
过滤器工厂
GatewayFilter 是网关中提供的一种过滤器,可以对进入网关的请求和微服务返回的响应做处理。
Spring提供了31种不同的路由过滤器工厂。
官方文档:https://docs.spring.io/spring-cloud-gateway/docs/current/reference/html/#gatewayfilter-factories
名称 | 说明 |
---|---|
AddRequestHeader | 给当前请求添加一个请求头 |
RemoveRequestHeader | 移除请求中的一个请求头 |
AddResponseHeader | 给响应结果中添加一个响应头 |
RemoveResponseHeader | 从响应结果中移除有一个响应头 |
RequestRateLimiter | 限制请求的流量 |
下面我们以 AddRequestHeader 为例:
需求:给所有进入 userservice 的请求添加一个请求头:sign=xn2001.com is eternal
只需要修改 gateway 服务的 application.yml文件,添加路由过滤即可。
1 | spring: |
如何验证,我们修改 userservice 中的一个接口
1 |
|
重启两个服务,访问:http://localhost:10010/user/1
可以看到控制台打印出了这个请求头
全局过滤器
上面介绍的过滤器工厂,网关提供了 31 种,但每一种过滤器的作用都是固定的。如果我们希望拦截请求,做自己的业务逻辑则没办法实现。
全局过滤器的作用也是处理一切进入网关的请求和微服务响应,与 GatewayFilter 的作用一样。区别在于 GlobalFilter 的逻辑可以写代码来自定义规则;而 GatewayFilter 通过配置定义,处理逻辑是固定的。
需求:定义全局过滤器,拦截请求,判断请求的参数是否满足下面条件
- 参数中是否有 authorization
- authorization 参数值是否为 admin
如果同时满足则放行,否则拦截。
1 |
|
过滤器顺序
请求进入网关会碰到三类过滤器:DefaultFilter、当前路由的过滤器、GlobalFilter;
请求路由后,会将三者合并到一个过滤器链(集合)中,排序后依次执行每个过滤器.
排序的规则是什么呢?
- 每一个过滤器都必须指定一个 int 类型的 order 值,order 值越小,优先级越高,执行顺序越靠前。
- GlobalFilter 通过实现 Ordered 接口,或者使用 @Order 注解来指定 order 值,由我们自己指定。
- 路由过滤器和 defaultFilter 的 order 由 Spring 指定,默认是按照声明顺序从1递增。
- 当过滤器的 order 值一样时,会按照 defaultFilter > 路由过滤器 > GlobalFilter 的顺序执行。
跨域问题
不了解跨域问题的同学可以百度了解一下;在 Gateway 网关中解决跨域问题还是比较方便的。
1 | spring: |
RabbitMQ
Elasticsearch
高级篇