微服务理解、Nacos与Eureka、Feign和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可以支持很多的自定义配置，如下表所示：
类型作用说明feign.Logger.Level修改日志级别包含四种不同的级别：NONE、BASIC、HEADERS、FULLfeign.codec.Decoder响应结果的解析器http远程调用的结果做解析，例如解析json字符串为java对象feign.codec.Encoder请求参数编码将请求参数编码，便于通过http请求发送feign. Contract支持的注解格式默认是SpringMVC的注解feign. Retryer失败重试机制请求失败的重试机制，默认是没有，不过会使用Ribbon的重试
一般情况下，默认值就能满足我们使用，如果要自定义时，只需要创建自定义的@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种不同的路由过滤器工厂。例如：
名称****说明AddRequestHeader给当前请求添加一个请求头RemoveRequestHeader移除请求中的一个请求头AddResponseHeader给响应结果中添加一个响应头RemoveResponseHeader从响应结果中移除有一个响应头RequestRateLimiter限制请求的流量

过滤器的作用是什么？

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

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

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