Gateway

过滤器和网关的对比

过滤器:对单个服务器的请求进行拦截控制
网关:对所有的服务器的请求进行拦截控制

zuul 和 spring cloud gateway 的对比

zuul:是 Netflix 的,基于 servlet,阻塞式的 api,不支持长连接。
gateway:是 springcloud 的,基于 Spring5 构建,响应式非阻塞的 Api,支持长连接。

网关与 nginx 区别

相同点:都是可以实现对 api 接口的拦截,负载均衡、反向代理、请求过滤等,可以实现和网关一样的效果。
不同点:
Nginx 采用 C 语言编写,Gateway 是用 Java 语言编写的,能够更好让我们使用 java 语言来实现对请求的处理。
Nginx 属于服务器端负载均衡器,Gateway 属于本地负载均衡器。

Gateway 的组成

路由:网关的基本模块,有 ID,目标 URI,一组断言和一组过滤器组成;
断言:是访问该路由的访问规则,可以用来匹配来自 http 请求的任何内容,例如 headers 或者参数;
过滤器:这个就是我们平时说的过滤器,用来过滤一些请求的,gateway有自己默认的过滤器,我们也可以自定义过滤器,要实现两个接口,Ordered 和 Globalfilter。

Gateway的过滤器都有哪些
  1. 局部过滤器GatewayFilter
    内置局部过滤器工厂:AddRequestHeader、AddRequestParameter、AddResponseHeader、Hytrix、RedirectTo、SaveSession等;
  2. 全局过滤器GlobalFilter
    内置全局过滤器:
  • LoadBalanceClientFilter:通过负载均衡客户端,根据路由的url解析转换成真实的请求url;
  • NettyRoutingFilter、NettyWriteResponseFilter:通过HttpClient转发请求真实的url,并将响应写入到当前的请求响应中;
  • WebsocketRoutingFilter:负责处理Websocket类型的请求响应信息;
  • ForwardPathFilter:解析路径,并将路径转发;
  • RouteToRequestUrlFilter:转换路由中的uri
  • WebClientHttpRoutingFilter、WebClientWriteResponseFilter:通过WebClient转发请求真是的url,并将响应写入到当前的请求响应中。
怎么用Gateway做负载均衡

在gateway的配置文件中,使用lb配置服务,而非直接使用IP:PORT

routes: 
	- id: predicated_domo_route
	  uri: lb://spring-cloud-one-service
	  ……
Gateway配置文件说明
spring: 
  cloud:
    gateway:
      routes: 
        - id: demo_route
          uri: lb://spring-cloud-one-service # 路由到one-service模块,要实现负载均衡,不能直接写IP和端口
          predicates: # 断言,如果有多个,必须同时满足
            - Path=/gateway/**
            - Parameter=emailAddr
          filter: 
            - StripPrefix=1 # 表示去除1个前缀
      httpclient:
        connect-timeout: 1000 # 配置连接超时
        response-timeout: 5s # 配置响应超时

注册中心

CAP

一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)

Eureka和Zookeeper的区别
CAP

Eureka是AP的,Zookeeper是CP的。

节点宕机处理

Zookeeper会出现一种情况,就是当master节点宕掉,需要重新进行leader选举,这个时间在30~120s,期间整个zk集群都是不可用的。
而Eureka有限保证了可用性,节点平等,几个节点挂掉也不会影响其他节点的正常工作。但是查到的信息可能不是最新的,不保证强一致性。
此外,Eureka还有一种自我保护机制:如果在15分钟内超过**85%**的节点都没有正常的心跳,那么Eureka就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:

  1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务;
  2. Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其它节点上(即保证当前节点依然可用);
  3. 当网络稳定时,当前实例新的注册信息会被同步到其它节点中。
Eureka和Nacos的区别
CAP

Eureka只支持AP;
Nacos支持CP和AP两种:如果注册Nacos的client节点注册时是ephemeral=true,即为临时节点,那么Nacos集群对这个client节点就是AP,反之不是临时节点,就是CP。

Nacos支持CP和AP两种:默认是AP,设置CP有两种方式:

  1. curl -X PUT ‘$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP’;
  2. 配置修改:

#false为永久实例,true表示临时实例开启,注册为临时实例 spring.cloud.nacos.discovery.ephemeral=false

连接方式

Eureka使用定时发送和服务进行联系,属于短连接;
Nacos使用的是Netty和服务直接进行了连接,属于长连接。

操作实例方式

Eureka仅提供了实例列表、状态、错误信息,相比于Nacos过于简单;
Nacos提供了Nacos Console可视化控制界面,可以对实例列表进行监听,对实例进行上下线、配置权重等,并且config server对服务实例提供配置中心,且可以对配置进行CRUD、版本管理。

自我保护机制
  1. 保护方式不同
    Eureka保护方式:当在短时间内,统计续约失败的比例,如果达到一定阈值,则会出发自我保护机制,在该机制下,Eureka Server不会剔除任何的微服务,等到正常后,再退出自我保护机制。自我保护开关(eureka.server.enable-self-preservation: false);
    Nacos保护方式:当域名健康实例占总服务实例的比例小于阈值时,无论实例是否健康,都会将这个实例返回给客户端。这样做虽然损失了一部分流量,但保证了集群的剩余健康实例能正常工作。
  2. 范围不同
    Nacos的阈值是针对某个具体Service的,而不是针对所有服务的。但Eureka的自我保护阈值是针对所有服务的。
Nacos配置中心
spring:
  application:
    name: nacos-config
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848
      config:
        server-addr: 127.0.0.1:8848
        prefix: ${spring.application.name}
        file-extension: yml
        namespace: 0133bd1e-25c3-4985-96ed-a4e34efdea2e
DataId完整规则
${prefix}-${spring.profiles.active}.${file-extension}
多个项目配置一个共享的Nacos配置怎么实现
config:
  server-addr: 127.0.0.1:8848
  prefix: ${spring.application.name}
  file-extension: yml
  shared-dataids: shareconfig1.yml,shareconfig2.yml
  refreshable-dataids: shareconfig1.yml,shareconfig2.yml
配置多个Nacos的config
config:
  server-addr: 172.26.142.83:8850
    namespace: unify-passport-ci
    group: UP_GROUP
    file-extension: yaml
    extension-configs:
      - data-id: unify-passport-data.yaml
        group: UP_GROUP
        refresh: true
      - data-id: unify-passport-common.yaml
        group: UP_GROUP
        refresh: true
Nacos保存数据用的什么数据库,能不能改用MySQL

默认使用derby数据库,可以改为MySQL,步骤如下:

  1. 创建一个数据库,并将nacos/conf目录下的几个sql文件执行;
  2. 打开nacos/conf下的application.properties文件,其中有一个Config Module Related Configurations配置模块,按照提示配置即可;
#*************** Config Module Related Configurations ***************#
### If use MySQL as datasource:
spring.datasource.platform=mysql

### Count of DB:
db.num=1

### Connect URL of DB:
db.url.0=jdbc:mysql://127.0.0.1:3306/nacos?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useUnicode=true&useSSL=false&serverTimezone=UTC
db.user.0=nacos
db.password.0=nacos
Consul(了解)

用于实现分布式系统的服务发现与配置。
安装包仅包含一个可执行文件,方便部署,与 Docker 等轻量级容器可无缝配合。


Ribbon 负载均衡

Ribbon是什么

Ribbon的主要功能是提供客户端的软件负载均衡算法;

Nginx和Ribbon的区别

Nginx是反向代理同时实现,是服务端的负载均衡,Ribbon是客户端的负载均衡。

Ribbon实现原理

Ribbon使用discoveryClient从注册中心读取目标服务信息,对同一接口请求进行计数,使用%取余算法获取目标服务集群索引,返回获取到的目标服务信息。

Hytrix 断路器

为什么需要断路器

当一个服务调用另外一个服务因为网络缘由或自身缘由出现问题,调用者就会等待被调用者的响应。当更多的服务请求到这些资源致使更多的请求等待,发生连锁效应(雪崩效应)

Hystrix有四种防雪崩方式:

服务降级:接口调用失败就调用本地的方法返回一个空
服务熔断:接口调用失败就会进入调用接口提早定义好的一个熔断的方法,返回错误信息
服务隔离:隔离服务之间相互影响
服务监控:在服务发生调用时,会将每秒请求数、成功请求数等运行指标记录下来。


Feign

什么是Feign
  • Feign 是一个声明web服务客户端,这使得编写web服务客户端更容易;
  • 他将需要调用的服务方法定义成抽象方法保存在本地就能够了,不需要构建Http请求了,直接调用接口就好了。
Feign的实现原理

通过基于面向接口的动态代理方式生成实现类,将请求调用委托到动态代理的实现类。

Ribbon和Feign的不同

调用方式不同:Ribbon必须构建Http请求,而后经过RestTemplate发送请求;
而Feign是在Ribbon的基础上进行了一次改进,采用接口的形式,将需要调用的服务方法定义成抽象方法保存在本地,直接调用接口就好了。


BUS 消息总线

  • Bus就像一个分布式执行器,用于扩展的Spring Boot应用程序的配置文件,但也能够用做应用程序之间的通讯通道。
  • Bus不能单独完成通讯,须要配合MQ支持。
  • Bus通常是配合Config作配置中心的。
  • Config实时刷新也必须采用Bus消息总线。

Stream

轻量级事件驱动微服务框架,可使用简单的声明式模型来发送及接收消息,主要实现为Apache Kafka及RabbitMQ。


Config

什么是Config

为了方便对微服务各个环境下的配置进行集中式管理。Spring Cloud Config分为Config Server和Config Client两部分。Config Server负责保存配置文件,而且暴露Http API接口,Config Client经过调用Config Server的接口来读取配置文件。

是否可以实现实时刷新

可以,配合BUS


Security

作用
  • 对Zuul代理中的负载均衡从前端到后端服务中获取SSO令牌;
  • 资源服务器之间的中继令牌;
  • 使Feign客户端表现得像OAuth2RestTemplate(获取令牌等)的拦截器;
  • 在Zuul代理中配置下游身份验证。
  • 在Spring Boot和Spring Security OAuth2的基础上,能够快速建立实现常见模式的系统,如单点登陆,令牌中继和令牌交换。

Sleuth 链路追踪 & Zipkin 跟踪系统

Sleuth功能
  • 链路追踪
  • 性能分析
  • 数据分析优化链路
  • 可视化
Zipkin说明

分布式的跟踪系统。致力于收集服务的定时数据,以解决微服务架构中的延迟问题,包括数据的收集、存储、查找和展现。
zipkin会根据调用关系通过Zipkin UI生成依赖关系图,显示了多少跟踪请求通过每个服务,该系统让开发者可通过一个 Web 前端轻松的收集和分析数据,例如用户每次请求服务的处理时间等,可方便的监测系统中存在的瓶颈。
Zipkin提供了可插拔数据存储方式:In-Memory、MySql、Cassandra以及Elasticsearch。

Sleuth上报数据到Zipkin
spring.zipkin.enabled=true                     # 启用
spring.zipkin.base-url=http://127.0.0.1:9411/  # sleuth默认为上报为false, 现设置上报zipkin的服务地址
spring.sleuth.sampler.probability = 1          # span的采样率,默认为 0.1
spring.sleuth.sampler.rate = 10000

Admin

Admin是什么

Admin是基于SpringCloud微服务的开发平台,其中包含具备用户管理、资源权限管理、网关API管理等多个模块。


喜欢本文的朋友不要忘记点一个免费的赞哦,你的赞将是我最大的动力。