微服务理解、Nacos与Eureka、Feign和Gateway

目录

分布式架构

微服务是一种经过良好架构设计的分布式架构方案

SpringCloud是目前国内使用最广泛的微服务框架

服务拆分原则

Eureka

Ribbon负载均衡

Ribbon负载均衡的原理

Ribbon负载均衡策略IRule

Ribbon饥饿加载

Nacos注册中心

Nacos同集群优先的负载均衡

权重配置

环境隔离

Nacos与Eureka的区别

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

配置热更新

配置共享的优先级

Feign远程调用

如何使用

自定义配置

Feign使用优化

最佳实践

Gateway服务网关

网关作用

断言

过滤器工厂

路由过滤器的种类

过滤器的作用是什么？

全局过滤器

过滤器执行顺序

Gateway解决跨域问题

解决跨域问题

分布式架构

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

分布式架构的优缺点：

优点：1.降低服务耦合2.有利于服务升级和拓展

缺点：服务调用关系错综复杂

微服务是一种经过良好架构设计的分布式架构方案

微服务的架构特征：

• 单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责

• 自治：团队独立、技术独立、数据独立，独立部署和交付

• 面向服务：服务提供统一标准的接口，与语言和技术无关

• 隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题

微服务的上述特性其实是在给分布式架构制定一个标准

SpringCloud是目前国内使用最广泛的微服务框架

集成了各种优秀微服务功能组件

服务拆分原则

• 不同微服务，不要重复开发相同业务

• 微服务数据独立，不要访问其它微服务的数据库

• 微服务可以将自己的业务暴露为接口，供其它微服务调用

Eureka

1.搭建注册中心

2.服务注册，把服务注册eureka

3.服务发现，通过负载均衡挑选一个服务，实现远程调用

Ribbon负载均衡

SpringCloud底层其实是利用了一个名为Ribbon的组件，来实现负载均衡功能的

为什么我们只输入了service名称就可以访问了呢？之前还要获取ip和端口。

显然有人帮我们根据service名称，获取到了服务实例的ip和端口。它就是LoadBalancerInterceptor，这个类会在对RestTemplate的请求进行拦截，然后从Eureka根据服务id获取服务列表，随后利用负载均衡算法得到真实的服务地址信息，替换服务id

Ribbon负载均衡的原理

SpringCloudRibbon的底层采用了一个拦截器，拦截了RestTemplate发出的请求，对地址做了修改。用一幅图来总结一下：

基本流程如下：

• 拦截我们的RestTemplate请求http://userservice/user/1

• RibbonLoadBalancerClient会从请求url中获取服务名称，也就是user-service

• DynamicServerListLoadBalancer根据user-service到eureka拉取服务列表

• eureka返回列表，localhost:8081、localhost:8082

• IRule利用内置负载均衡规则，从列表中选择一个，例如localhost:8081

• RibbonLoadBalancerClient修改请求地址，用localhost:8081替代userservice，得到http://localhost:8081/user/1，发起真实请求

Ribbon负载均衡策略IRule

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

Ribbon饥饿加载

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

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

Nacos注册中心

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

Nacos就将同一机房内的实例 划分为一个集群。

user-service是服务，一个服务可以包含多个集群，如杭州、上海，每个集群下可以有多个实例，形成分级模型。

Nacos同集群优先的负载均衡

默认的ZoneAvoidanceRule并不能实现根据同集群优先来实现负载均衡。

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

权重配置

服务器设备性能有差异，部分实例所在机器性能较好，另一些较差，我们希望性能好的机器承担更多的用户请求。

但默认情况下NacosRule是同集群内随机挑选，不会考虑机器的性能问题。

因此，Nacos提供了权重配置来控制访问频率，权重越大则访问频率越高。

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

环境隔离

Nacos提供了namespace来实现环境隔离功能。

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

Nacos与Eureka的区别

• Nacos的服务实例分为两种类型：
  • 临时实例：如果实例宕机超过一定时间，会从服务列表剔除，默认的类型。

  • 非临时实例：如果实例宕机，不会从服务列表剔除，也可以叫永久实例。

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

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

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

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

配置热更新

方式一：在@Value注入的变量所在类上添加注解@RefreshScope

方式二：使用@ConfigurationProperties注解代替@Value注解。 在user-service服务中，添加一个类，读取patterrn.dateformat属性

配置共享的优先级

Feign远程调用

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

其作用就是帮助我们优雅的实现http请求的发送，解决RestTemplate的代码可读性差，编程体验不统一 ，参数复杂URL难以维护。

如何使用

使用Feign的步骤： ① 引入依赖 ② 添加@EnableFeignClients注解 ③ 编写FeignClient接口 ④ 使用FeignClient中定义的方法代替RestTemplate

自定义配置

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

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

Feign使用优化

1.日志级别尽量用basic

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

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

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

•Apache HttpClient ：支持连接池

•OKHttp：支持连接池

最佳实践

1、继承方式

简化这种重复的代码编写

2、抽取方式

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

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

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，属于响应式编程的实现，具备更好的性能。

断言

server:port: 10010 # 网关端口spring:application: name: gateway # 服务名称 gateway:routes: # 网关路由配置 - id: user-service # 路由id，自定义，只要唯一即可 # uri: http://127.0.0.1:8081 # 路由的目标地址 http就是固定地址uri: lb://userservice # 路由的目标地址 lb就是负载均衡，后面跟服务名称predicates: # 路由断言，也就是判断请求是否符合路由规则的条件 - Path=/user/** # 这个是按照路径匹配，只要以/user/开头就符合要求

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

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

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

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

过滤器工厂

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

路由过滤器的种类

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

过滤器的作用是什么？

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

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

defaultFilters的作用是什么？

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

全局过滤器

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

过滤器执行顺序

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

排序的规则是什么呢？

• 每一个过滤器都必须指定一个int类型的order值，order值越小，优先级越高，执行顺序越靠前。

• GlobalFilter通过实现Ordered接口，或者添加@Order注解来指定order值，由我们自己指定

• 路由过滤器和defaultFilter的order由Spring指定，默认是按照声明顺序从1递增。

• 当过滤器的order值一样时，会按照 defaultFilter > 路由过滤器 > GlobalFilter的顺序执行。

Gateway解决跨域问题

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

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

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

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

解决跨域问题

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

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