spring cloud 入门

1. 系统架构演变

 

随着互联网的发展，网站应用的规模不断扩大。需求的激增，带来的是技术上的压力。系统架构也因此也不断的演进、升级、迭代。从单一应用，到垂直拆分，到分布式服务，到SOA，以及现在火热的微服务架构，还有在Google带领下来势汹涌的Service Mesh。我们到底是该乘坐微服务的船只驶向远方，还是偏安逸得过且过？

 

其实生活不止眼前的苟且，还有诗和远方。所以我们今天就回顾历史，看一看系统架构演变的历程；把握现在，学习现在最火的技术架构；展望未来，争取成为一名优秀的Java工程师。

 

1.1. 集中式架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。

 

                                               

 

• 优点：

• • 系统开发速度快
  • 维护成本低
  • 适用于并发要求较低的系统

 

• 缺点：

• • 代码耦合度高，后期维护困难
  • 无法针对不同模块进行针对性优化
  • 无法水平扩展
  • 单点容错率低，并发能力差

 

 

1.2. 垂直拆分

当访问量逐渐增大，单一应用无法满足需求，此时为了应对更高的并发和业务需求，我们根据业务功能对系统进行拆分：

                   

     

 

• 优点：

• • 系统拆分实现了流量分担，解决了并发问题
  • 可以针对不同模块进行优化
  • 方便水平扩展，负载均衡，容错率提高

 

• 缺点：

• • 系统间相互独立，会有很多重复开发工作，影响开发效率

 

1.3. 分布式服务

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求

 

                       

 

• 优点：

• • 将基础服务进行了抽取，系统间相互调用，提高了代码复用和开发效率

 

• 缺点：

• • 系统间耦合度变高，调用关系错综复杂，难以维护

 

1.4. 面向服务架构（SOA）

 

SOA（Service Oriented Architecture）面向服务的架构：它是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中。各个服务之间 通过网络调用。

SOA结构图:

 

 

ESB（企业服务总线），简单 来说 ESB 就是一根管道，用来连接各个服务节点。为了集 成不同系统，不同协议的服务，ESB 做了消息的转化解释和路由工作，让不同的服务互联互通。

 

SOA缺点：每个供应商提供的ESB产品有偏差，自身实现较为复杂；应用服务粒度较大，ESB集成整合所有服务和协议、数据转换使得运维、测试部署困难。所有服务都通过一个通路通信，直接降低了通信速度。

 

SOA和分布式的区别(来源网络)

概念不太一样

 

SOA是面向服务的架构，将业务逻辑提炼成共用服务，对外提供服务，也不一定就用webservice通信，也可以是socket、EJB等等。目标就是建成一个服务组件的“超市”，供别人自行选用。

 

分布式，主要还是从部署的角度，将应用按照访问压力进行归类，主要目标是充分利用服务器的资源，避免资源分配不均，譬如流行的三层架构等。

 

SOA倾向于概念,分布式倾向于实实在在的集群

 

1.5. 微服务架构

 

微服务架构是使用一套小服务来开发单个应用的方式或途径，每个服务基于单一业务能力构建，运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，并能够通过自动化部署机制来独立部署。这些服务可以使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。

 

微服务结构图:

 

API Gateway网关是一个服务器，是系统的唯一入口。为每个客户端提供一个定制的API。

API网关核心是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。如它还可以具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。

通常，网关提供RESTful/HTTP的方式访问服务。而服务端通过服务注册中心进行服务注册和管理。

 

微服务的特点：

• 单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责
• 微：微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服务虽小，但“五脏俱全”。
• 面向服务：面向服务是说每个服务都要对外暴露Rest风格服务接口API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供Rest的接口即可。
• 自治：自治是说服务间互相独立，互不干扰

• • 团队独立：每个服务都是一个独立的开发团队，人数不能过多。
  • 技术独立：因为是面向服务，提供Rest接口，使用什么技术没有别人干涉
  • 前后端分离：采用前后端分离开发，提供统一Rest接口，后端不用再为PC、移动端开发不同接口
  • 数据库分离：每个服务都使用自己的数据源部署独立，服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护

 

微服务架构与SOA都是对系统进行拆分；微服务架构基于SOA思想，可以把微服务当做去除了ESB的SOA。ESB是

SOA架构中的中心总线，设计图形应该是星形的，而微服务是去中心化的分布式软件架构。两者比较类似，但其实也

有一些差别：

       

 

 

 

2. 服务调用方式

2.1. RPC和HTTP

 

RPC：Remote Produce Call远程过程调用，RPC基于Socket，工作在会话层。自定义数据格式，速度快，效率高。早期的webservice，现在热门的dubbo，都是RPC的典型代表

 

Http：http其实是一种网络传输协议，基于TCP，工作在应用层，规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用Http协议，也可以用来进行远程服务调用。缺点是消息封装臃肿，优势是对服务的提供和调用方没有任何技术限定，自由灵活，更符合微服务理念。

 

现在热门的Rest风格，就可以通过http协议来实现。

 

区别：RPC的机制是根据语言的API（language API）来定义的，而不是根据基于网络的应用来定义的。如果你们公司全部采用Java技术栈，那么使用Dubbo作为微服务架构是一个不错的选择。

 

相反，如果公司的技术栈多样化，而且你更青睐Spring家族，那么Spring Cloud搭建微服务是不二之选。在我们的项目中，会选择Spring Cloud套件，因此会使用Http方式来实现服务间调用。

 

2.2. Http客户端工具

既然微服务选择了Http，那么我们就需要考虑自己来实现对请求和响应的处理。不过开源世界已经有很多的http客户端工具，能够帮助我们做这些事情，例如：

HttpClient

OKHttp

URLConnection

不过这些不同的客户端，API各不相同。而Spring也有对http的客户端进行封装，提供了工具类叫RestTemplate。

 

2.3. Spring的RestTemplate

Spring提供了一个RestTemplate模板工具类，对基于Http的客户端进行了封装，并且实现了对象与json的序列化和反序列化，非常方便。RestTemplate并没有限定Http的客户端类型，而是进行了抽象，目前常用的3种都有支持：

HttpClient

OkHttp

JDK原生的URLConnection（默认的）

 

 

• 已经在导入的项目中的 HttpDemoApplication 注册一个 RestTemplate 对象，可以在启动类位置注册：

 

@SpringBootApplication
public class HttpDemoApplication {
    public static void main(String[] args) {
        SpringApplication.run(HttpDemoApplication.class, args);
    }
    @Bean
    public RestTemplate restTemplate(){
        return new RestTemplate();
    }
}

 

 

• 启动springboot项目，在项目中的测试类中直接 @Autowired 注入：

@RunWith(SpringRunner.class)
@SpringBootTest
public class RestTemplateTest {
    @Autowired
    private RestTemplate restTemplate;
    @Test
    public void test(){
        //如果要测试需要启动spring boot项目，以便获取数据
        String url = "http://localhost/user/8";
        User user = restTemplate.getForObject(url, User.class);
        System.out.println(user);
    }
}

 

• 通过RestTemplate的getForObject()方法，传递url地址及实体类的字节码，RestTemplate会自动发起请求，接收响应，并且帮我们对响应结果进行反序列化
• 注意:

• • 该地址必须是可以访问的地址

 

3. 初识Spring Cloud

3.1. 简介

Spring Cloud是Spring旗下的项目之一，官网地址：http://projects.spring.io/spring-cloud/

 

Spring最擅长的就是集成，把世界上最好的框架拿过来，集成到自己的项目中。

 

Spring Cloud也是一样，它将现在非常流行的一些技术整合到一起，实现了诸如：配置管理，服务发现，智能路由，负载均衡，熔断器，控制总线，集群状态等功能；协调分布式环境中各个系统，为各类服务提供模板性配置。其主要涉及的组件包括:

 

• Eureka：注册中心
• Zuul、Gateway：服务网关
• Ribbon：负载均衡
• Feign：服务调用
• Hystrix或Resilience4j：熔断器

 

以上只是其中一部分，架构图：

                           

 

3.2. 版本

Spring Cloud不是一个组件，而是许多组件的集合；它的版本命名比较特殊，是以A到Z的为首字母的一些单词（其实是伦敦地铁站的名字）组成:

 

       

 

我们介绍的是最新稳定的Greenwich版本。

 

5. 微服务场景模拟

 

在实际开发中，每个微服务可独立一个工程

 

5.1. 创建父工程

修改pom.xml文件

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.1.5.RELEASE</version>
    <relativePath/>
</parent>
<properties>
    <java.version>1.8</java.version>
    <spring-cloud.version>Greenwich.SR1</spring-cloud.version>
    <mapper.starter.version>2.1.5</mapper.starter.version>
    <mysql.version>5.1.46</mysql.version>
</properties>
<dependencyManagement>
    <dependencies>
        <!-- springCloud -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>${spring-cloud.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
        <!-- 通用Mapper启动器 -->
        <dependency>
            <groupId>tk.mybatis</groupId>
            <artifactId>mapper-spring-boot-starter</artifactId>
            <version>${mapper.starter.version}</version>
        </dependency>
        <!-- mysql驱动 -->
        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
            <version>${mysql.version}</version>
        </dependency>
    </dependencies>
</dependencyManagement>
<dependencies>
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
    </dependency>
</dependencies>
<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

 

5.2. 服务提供者

5.2.1. 创建服务提供者

 

5.2.2. 修改pom.xml

<dependencies>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
  </dependency>
  <dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
  </dependency>
  <dependency>
    <groupId>tk.mybatis</groupId>
    <artifactId>mapper-spring-boot-starter</artifactId>
  </dependency>
</dependencies>

 

5.2.3. 编写配置文件

 

server:
    port: 9091
spring: 
  datasource:
    driver-class-name: com.mysql.jdbc.Driver
    url: jdbc:mysql://localhost:3306/springcloud
    username: root
    password: root
mybatis:
    type-aliases-package: com.moon.user.pojo

 

5.2.4. 启动类

 

@SpringBootApplication
@MapperScan("com.moonhu.user.mapper")
public class UserApplication {
  public static void main(String[] args) {
    SpringApplication.run(UserApplication.class, args);
  }
}

 

5.2.5. 编写User类

 

@Table(name = "tb_user")
@Data
public class User {
  @Id
  @KeySql(useGeneratedKeys = true)
  private Long id;
  private String userName; // 用户名
  private String password; // 密码
  private String name;// 姓名
  private Integer age;// 年龄
  private Integer sex;// 性别，1男性，2女性
  private Date birthday;// 出生日期
  private Date created;// 创建时间
  private Date updated;// 更新时间
  private String note;// 备注
}

 

5.2.6. 编写UserMapper.java

 

public interface UserMapper extends Mapper<User> {
}

 

5.2.7.编写UserService.java

 

@Service
public class UserService {
  @Autowired
  private UserMapper userMapper;
  public User queryById(Long id){
    return userMapper.selectByPrimaryKey(id);
 }
}

 

5.2.8.编写UserController.java

 

@RestController
@RequestMapping("/user")
public class UserController {
    @Autowired
    private UserService userService;
    @GetMapping("/{id}")
    public User queryById(@PathVariable Long id){
        return userService.queryById(id);
    }
}

 

5.2.9.启动  

user-service 项目,访问接口：http://localhost:9091/user/8

 

5.3. 服务调用者

5.3.1. 创建工程

修改pom.xml

<dependencies>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
  </dependency>
</dependencies>

 

5.3.2.编写启动类

 

@SpringBootApplication
public class ConsumerApplication {
  public static void main(String[] args) {
    SpringApplication.run(ConsumerApplication.class, args);
  }
  @Bean
  public RestTemplate restTemplate(){
    return new RestTemplate();
  }
}

 

5.3.3.创建实体类User.java

 

@Data
public class User {
  private Long id;
  private String userName; // 用户名
  private String password; // 密码
  private String name;// 姓名
  private Integer age;// 年龄
  private Integer sex;// 性别，1男性，2女性
  private Date birthday;// 出生日期
  private Date created;// 创建时间
  private Date updated;// 更新时间
  private String note;// 备注
}

 

5.3.4.编写ConsumerController.java

 

@RestController
@RequestMapping("/consumer")
public class ConsumerController {
    
    @Autowired
    private RestTemplate restTemplate;
    
    @GetMapping("{id}")
    public User queryById(@PathVariable Long id){
        String url = "http://localhost:9091/user/" + id;
        return restTemplate.getForObject(url, User.class);
    }
}

 

5.3.5. 启动测试

启动  consumer-demo 引导启动类；因为  consumer-demo 项目没有配置端口，那么默认就是8080

 

一个简单的远程服务调用案例就实现了。

 

 

5.4问题思考

user-service：对外提供了查询用户的接口

consumer-demo：通过RestTemplate访问 http://locahost:9091/user/{id} 接口，查询用户数据存在什么问题？

在consumer中，我们把url地址硬编码到了代码中，不方便后期维护

consumer需要记忆user-service的地址，如果出现变更，可能得不到通知，地址将失效

consumer不清楚user-service的状态，服务宕机也不知道

user-service只有1台服务，不具备高可用性

即便user-service形成集群，consumer还需自己实现负载均衡

 

其实上面说的问题，概括一下就是分布式服务必然要面临的问题：

• 服务管理
• 如何自动注册和发现
• 如何实现状态监管
• 如何实现动态路由
• 服务如何实现负载均衡
• 服务如何解决容灾问题
• 服务如何实现统一配置

 

 

6.Eureka注册中心

6.1. 认识Eureka注册中心

           

 

• Eureka：就是服务注册中心（可以是一个集群），对外暴露自己的地址
• 提供者：启动后向Eureka注册自己信息（地址，提供什么服务）
• 消费者：向Eureka订阅服务，Eureka会将对应服务的所有提供者地址列表发送给消费者，并且定期更新
• 心跳(续约)：提供者定期通过http方式向Eureka刷新自己的状态

 

6.2. 入门案例

6.2.1. 搭建eureka-server工程

 

• 修改 pom.xml

<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
    </dependency>
</dependencies>

 

• 编写启动类

//声明当前应用为eureka服务
@EnableEurekaServer
@SpringBootApplication
public class EurekaServerApplication {
  public static void main(String[] args) {
    SpringApplication.run(EurekaServerApplication.class);
 }
}

 

• 编写配置文件application.yml

server:
port: 10086
spring:
application:
 name: eureka-server # 应用名称，会在Eureka中作为服务的id标识（serviceId）
eureka:
client:
 service-url: # EurekaServer的地址，现在是自己的地址，如果是集群，需要写其它Server的地址。
  defaultZone: http://127.0.0.1:10086/eureka
 register-with-eureka: false # 不注册自己
 fetch-registry: false #不拉取

 

• 启动服务

启动  eureka-server 访问：http://127.0.0.1:10086

 

6.2.2. 服务注册

注册服务，就是在服务上添加Eureka的客户端依赖，客户端代码会自动把服务注册到EurekaServer中。

在服务的pom文件重ianjia注册的依赖

 

<!-- Eureka客户端 -->
<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

 

• 修改启动类

@SpringBootApplication
@MapperScan("com.moon.user.mapper")
@EnableDiscoveryClient // 开启Eureka客户端发现功能
public class UserServiceDemoApplication {
  public static void main(String[] args) {
    SpringApplication.run(UserServiceDemoApplication.class, args);
  }
}

 

 

• 修改配置文件

server:
port: 9091
spring:
datasource:
 driver-class-name: com.mysql.jdbc.Driver
 url: jdbc:mysql://localhost:3306/springcloud
 username: root
 password: root
application:
  #应用名
 name: user-service
mybatis:
type-aliases-package: cn.itcast.user.pojo
eureka:
client:
 service-url:
  defaultZone: http://localhost:10086/eureka

 

这里我们添加了spring.application.name属性来指定应用名称，将来会作为服务的id使用。

 

• 重启 user-service 项目，访问Eureka监控页面

 

6.2.3 服务发现

修改消费服务

 

• 添加依赖

<!-- Eureka客户端 -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

 

 

• 修改启动类

@SpringBootApplication
@EnableDiscoveryClient
public class ConsumerApplication {
  public static void main(String[] args) {
    SpringApplication.run(ConsumerApplication.class, args);
  }
  @Bean
  public RestTemplate restTemplate(){
    return new RestTemplate();
  }
}

 

• 修改配置文件

server:
port: 8080
spring:
application:
 name: consumer-demo # 应用名称
eureka:
client:
 service-url: # EurekaServer地址
  defaultZone: http://127.0.0.1:10086/eureka

 

• 修改控制器

@RestController
@RequestMapping("/consumer")
public class ConsumerController {
    
    @Autowired
    private RestTemplate restTemplate;
    
    @Autowired
    private DiscoveryClient discoveryClient;
    
    @GetMapping("{id}")
    public User queryById(@PathVariable Long id){
        String url = "http://localhost:9091/user/" + id;
        //获取eureka中注册的user-service实例列表
        List<ServiceInstance> serviceInstanceList = discoveryClient.getInstances("user-service");
        
        ServiceInstance serviceInstance = serviceInstanceList.get(0);
        
        url = "http://" + serviceInstance.getHost() + ":" + serviceInstance.getPort() + "/user/" + id;
        return restTemplate.getForObject(url, User.class);
    }
}

 

6.3 Eureka详解

6.3.1基础架构

• 服务注册中心

• • Eureka的服务端应用，提供服务注册和发现功能，就是刚刚我们建立的eureka-server

• 服务提供者

• • 提供服务的应用，可以是SpringBoot应用，也可以是其它任意技术实现，只要对外提供的是Rest风格服务即 可。本例中就是我们实现的user-service

• 服务消费者

• • 消费应用从注册中心获取服务列表，从而得知每个服务方的信息，知道去哪里调用服务方。本例中就是我们实 现的consumer-demo

 

6.3.2 高可用的Eureka Server

 

Eureka Server即服务的注册中心，在刚才的案例中，我们只有一个EurekaServer，事实上EurekaServer也可以是一 个集群，形成高可用的Eureka中心

 

多个Eureka Server之间也会互相注册为服务，当服务提供者注册到Eureka Server集群中的某个节点时，该节点会把 服务的信息同步给集群中的每个节点，从而实现数据同步。因此，无论客户端访问到Eureka Server集群中的任意一 个节点，都可以获取到完整的服务列表信息

 

   

 

我们假设要搭建两台EurekaServer的集群，端口分别为：10086和10087

 

server:
# 如果制定端口则使用制定的端口,如果没有制定端口则使用10086作为端口
port: ${port:10086}
spring:
application:
  # 应用名称，会在eureka中作为服务的id(serviceId)
 name: eureka-server
eureka:
client:
 service-url:
   # eureka服务地址；如果是集群则是其它服务器地址，后面要加/eureka
  defaultZone: ${defaultZone:http://127.0.0.1:10086/eureka}
  # 是否注册自己，自身不提供服务所以不注册
  #register-with-eureka: false
  # 是否拉取服务
  #fetch-registry: false

 

所谓的高可用注册中心，其实就是把EurekaServer自己也作为一个服务，注册到其它EurekaServer上，这样多个

EurekaServer之间就能互相发现对方，从而形成集群。因此我们做了以下修改

注意

把register-with-eureka和fetch-registry修改为true或者注释掉

把service-url的值改成了另外一台EurekaServer的地址，而不是自己

 

• 修改原来的启动配置组件；在如下界面中的 VM options 中

 

启动                                              

 

启动第二个: -Dport=10087 -DdefaultZone=http:127.0.0.1:10086/eureka

 

• 启动结果                                              

 

 

• 客户端注册服务到集群

• • 修改

eureka:
client:
 service-url: # EurekaServer地址,多个地址以','隔开
  defaultZone: http://127.0.0.1:10086/eureka,http://127.0.0.1:10087/eureka

 

 

6.3.3. Eureka客户端

 

服务注册

 

服务提供者在启动时，会检测配置属性中的： eureka.client.register-with-erueka=true 参数是否正确，事实上 默认就是true。如果值确实为true，则会向EurekaServer发起一个Rest请求，并携带自己的元数据信息，Eureka Server会把这些信息保存到一个双层Map结构中。

 

• 第一层Map的Key就是服务id，一般是配置中的 spring.application.name 属性
• 第二层Map的key是服务的实例id。一般host+ serviceId + port，例如： localhost:user-service:8081
• 值则是服务的实例对象，也就是说一个服务，可以同时启动多个不同实例，形成集群。

 

默认注册时使用的是主机名或者localhost，如果想用ip进行注册，可以在 user-service 中添加配置如下：

eureka:
instance:
 ip-address: 127.0.0.1 # ip地址
 prefer-ip-address: true # 更倾向于使用ip，而不是host名

 

修改完后先后重启 user-service 和 consumer-demo ；在调用服务的时候就已经变成ip地址；需要注意的是：不是在 eureka中的控制台服务实例状态显示。

 

服务续约

 

在注册服务完成以后，服务提供者会维持一个心跳（定时向EurekaServer发起Rest请求），告诉EurekaServer：“我 还活着”。这个我们称为服务的续约（renew）

 

有两个重要参数可以修改服务续约的行为；可以在 user-service 中添加如下配置项

 

eureka:
instance:
 lease-expiration-duration-in-seconds: 90
 lease-renewal-interval-in-seconds: 30

lease-renewal-interval-in-seconds：服务续约(renew)的间隔，默认为30秒

lease-expiration-duration-in-seconds：服务失效时间，默认值90秒

 

也就是说，默认情况下每隔30秒服务会向注册中心发送一次心跳，证明自己还活着。如果超过90秒没有发送心跳， EurekaServer就会认为该服务宕机，会定时（eureka.server.eviction-interval-timer-in-ms设定的时间）从服务列表 中移除，这两个值在生产环境不要修改，默认即可

 

获取服务列表

当服务消费者启动时，会检测 eureka.client.fetch-registry=true 参数的值，如果为true，则会从Eureka Server服务的列表拉取只读备份，然后缓存在本地。并且每隔30秒会重新拉取并更新数据。可以在 consumer-demo 项目中通过下面的参数来修改

 

eureka:
  client:
    registry-fetch-interval-seconds: 30

 

6.4.4. 失效提出和自我保护

如下的配置都是在Eureka Server服务端进行：

 

服务下线

当服务进行正常关闭操作时，它会触发一个服务下线的REST请求给Eureka Server，告诉服务注册中心：“我要下线 了”。服务中心接受到请求之后，将该服务置为下线状态

 

失效剔除

有时我们的服务可能由于内存溢出或网络故障等原因使得服务不能正常的工作，而服务注册中心并未收到“服务下 线”的请求。相对于服务提供者的“服务续约”操作，服务注册中心在启动时会创建一个定时任务，默认每隔一段时间 （默认为60秒）将当前清单中超时（默认为90秒）没有续约的服务剔除，这个操作被称为失效剔除。

 

可以通过 eureka.server.eviction-interval-timer-in-ms 参数对其进行修改，单位是毫秒

 

自我保护

我们关停一个服务，很可能会在Eureka面板看到一条警告：

 

这是触发了Eureka的自我保护机制。当服务未按时进行心跳续约时，Eureka会统计服务实例近15分钟心跳续约的比例是否低于了85%。在生产环境下，因为网络延迟等原因，心跳失败实例的比例很有可能超标，但是此时就把服务 剔除列表并不妥当，因为服务可能没有宕机。Eureka在这段时间内不会剔除任何服务实例，直到网络恢复正常。生 产环境下这很有效，保证了大多数服务依然可用，不过也有可能获取到失败的服务实例，因此服务调用者必须做好服 务的失败容错。

可以通过下面的配置来关停自我保护

 

eureka:
  server:
   enable-self-preservation: false # 关闭自我保护模式（缺省为打开)

 

7.负载均衡Ribbon

实际环境中，往往会开启很多个 user-service 的集群。此时获取的服务列表中就会有多个，到底该访问哪一个

 

一般这种情况下就需要编写负载均衡算法，在多个实例列表中进行选择。

不过Eureka中已经集成了负载均衡组件：Ribbon，简单修改代码即可使用。

 

什么是Ribbon：

 

7.1.启动两个服务实例

user-service 实例，一个9091，一个9092

 

 

7.2 开启负载均衡

因为Eureka中已经集成了Ribbon，所以我们无需引入新的依赖。

 

直接修改消费者服务的启动类

 

@Bean
@LoadBalanced
public RestTemplate restTemplate() {
  return new RestTemplate();
}

 

修消费端控制类

 

@GetMapping("{id}")
public User queryById(@PathVariable("id") Long id){
  String url = "http://user-service/user/" + id;
  User user = restTemplate.getForObject(url, User.class);
  return user;
}

 

访问页面，查看结果；并可以在9091和9092的控制台查看执行情况：

 

了解：Ribbon默认的负载均衡策略是轮询。SpringBoot也帮提供了修改负载均衡规则的配置入口在consumerdemo的配置文件中添加如下，就变成随机的了

 

注意:    

如果在调用的时候出现错误: HttpClientErrorException$NotFound: 404 null

查看服务后边的路径是否写错,需要加上controller类上的路径和方法名上的路径

 

如果后台不报错,前段获得的内容为404,尝试在方法上加@ResponseBody解决

 

user-service:
ribbon:
 NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

 

8. 熔断器

8.1 简介

Hystrix 在英文里面的意思是 豪猪，它的logo 看下面的图是一头豪猪，它在微服务系统中是一款提供保护机制的组 件，和eureka一样也是由netflix公司开发。

主页：https://github.com/Netflix/Hystrix/

 

Hystrix是Netflix开源的一个延迟和容错库，用于隔离访问远程服务、第三方库，防止出现级联失败。

 

服务器支持的线程和并发数有限，某一服务错误导致请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，形成雪 崩效应。    

 

Hystrix解决雪崩问题的手段主要是服务降级，包括：

线程隔离

服务熔断

 

8.2线程隔离&服务降级

 

Hystrix为每个依赖服务调用分配一个小的线程池，如果线程池已满调用将被立即拒绝，默认不采用排队，加速 失败判定时间

用户的请求将不再直接访问服务，而是通过线程池中的空闲线程来访问服务，如果线程池已满，或者请求超 时，则会进行降级处理，什么是服务降级？

 

服务降级：优先保证核心服务，而非核心服务不可用或弱可用。

 

服务降级虽然会导致请求失败，但是不会导致阻塞，而且最多会影响这个依赖服务对应的线程池中的资源，对其它服 务没有响应

 

触发Hystrix服务降级的情况：

线程池已满

请求超时

 

 

8.3服务降级

 

• 修改pom文件

<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>

 

• 修改消费者启动类,开启熔断

@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker
public class ConsumerApplication {
  // ...
}

 

可以看到，我们类上的注解越来越多，在微服务中，经常会引入上面的三个注解，于是Spring就提供了一个组合注解：@SpringCloudApplication

 

注解替换

 

@SpringCloudApplication
public class ConsumerApplication {
  // ...
}

 

 

• 编写降级逻辑

@RestController
@RequestMapping("/consumer")
@Slf4j
public class ConsumerController {
  @Autowired
  private RestTemplate restTemplate;
  @Autowired
  private DiscoveryClient discoveryClient;
  @GetMapping("{id}")
  @HystrixCommand(fallbackMethod = "queryByIdFallback")
  public String queryById(@PathVariable Long id){
    String url = "http://localhost:9091/user/" + id;
    return restTemplate.getForObject(url, String.class);
 }
 // 定义内部类处理降级情况
  public String queryByIdFallback(Long id){
    log.error("查询用户信息失败。id：{}", id);
    return "对不起，网络太拥挤了！";
 }
}

要注意；因为熔断的降级逻辑方法必须跟正常逻辑方法保证：相同的参数列表和返回值声明。

失败逻辑中返回User对象没有太大意义，一般会返回友好提示。所以把queryById的方法改造为返回String，

反正也是Json数据。这样失败逻辑中返回一个错误说明，会比较方便

 

@HystrixCommand(fallbackMethod = "queryByIdFallBack")：用来声明一个降级逻辑的方法

 

默认的Fallback

 

才把fallback写在了某个业务方法上，如果这样的方法很多，那岂不是要写很多。所以可以把Fallback配置加在类上，实现默认fallback；

 

@RestController
@RequestMapping("/consumer")
@Slf4j
@DefaultProperties(defaultFallback = "defaultFallback")
public class ConsumerController {
  @Autowired
  private RestTemplate restTemplate;
  @Autowired
  private DiscoveryClient discoveryClient;
  @GetMapping("{id}")
  //@HystrixCommand(fallbackMethod = "queryByIdFallback")
  @HystrixCommand
  public String queryById(@PathVariable Long id){
    String url = "http://localhost:9091/user/" + id;
    return restTemplate.getForObject(url, String.class);
 }
  public String queryByIdFallback(Long id){
    log.error("查询用户信息失败。id：{}", id);
    return "对不起，网络太拥挤了！";
 }
  public String defaultFallback(){
    return "默认提示：对不起，网络太拥挤了！";
 }
}

@DefaultProperties(defaultFallback = "defaultFallBack")：在类上指明统一的失败降级方法；该类中所有方法返回类型要与处理失败的方法的返回类型一致

注意:

方法级别熔断,请求路径错误不会报错,类级别的熔断如果请求路径不对会报路径错误

 

超时设置

在之前的案例中，请求在超过1秒后都会返回错误信息，这是因为Hystrix的默认超时时长为1，我们可以通过配置修改这个值；

修改消费服务的配置文件

 

hystrix:
command:
 default:
  execution:
   isolation:
    thread:
     timeoutInMilliseconds: 2000

 

8.4服务熔断

在服务熔断中，使用的熔断器，也叫断路器，其英文单词为：Circuit Breaker

 

熔断机制与家里使用的电路熔断原理类似；当如果电路发生短路的时候能立刻熔断电路，避免发生灾难。在分布式系统中应用服务熔断后；服务调用方可以自己进行判断哪些服务反应慢或存在大量超时，可以针对这些服务进行主动熔断，防止整个系统被拖垮。

 

Hystrix的服务熔断机制，可以实现弹性容错；当服务请求情况好转之后，可以自动重连。通过断路的方式，将后续请求直接拒绝，一段时间（默认5秒）之后允许部分请求通过，如果调用成功则回到断路器关闭状态，否则继续打

开，拒绝请求的服务。

 

Hystrix的熔断状态机模型：

                   

 

状态机有3个状态：

 

• • Closed：关闭状态（断路器关闭），所有请求都正常访问。

 

• • Open：打开状态（断路器打开），所有请求都会被降级。Hystrix会对请求情况计数，当一定时间内失败请求百分比达到阈值，则触发熔断，断路器会完全打开。默认失败比例的阈值是50%，请求次数最少不低于20次。

 

• • Half Open：半开状态，不是永久的，断路器打开后会进入休眠时间（默认是5S）。随后断路器会自动进入半开状态。此时会释放部分请求通过，若这些请求都是健康的，则会关闭断路器，否则继续保持打开，再次进行休眠计时

 

 

• 熔断实践

 

修改消费服务的控制类

 

@GetMapping("{id}")
@HystrixCommand
public String queryById(@PathVariable("id") Long id){
  if(id == 1){
    throw new RuntimeException("太忙了");
 }
  String url = "http://user-service/user/" + id;
  String user = restTemplate.getForObject(url, String.class);
  return user;
}

 

这样如果参数是id为1，一定失败，其它情况都成功。（不要忘了清空user-service中的休眠逻辑）

我们准备两个请求窗口：

• 一个请求：http://localhost:8080/consumer/1，注定失败
• 一个请求：http://localhost:8080/consumer/2，肯定成功

 

当我们疯狂访问id为1的请求时（超过20次），就会触发熔断。断路器会打开，一切请求都会被降级处理。

此时你访问id为2的请求，会发现返回的也是失败

 

熔断相关参数修改

 

# 配置熔断策略：
hystrix:
command:
 default:
  circuitBreaker:
   errorThresholdPercentage: 50 # 触发熔断错误比例阈值，默认值50%
   sleepWindowInMilliseconds: 10000 # 熔断后休眠时长，默认值5秒
   requestVolumeThreshold: 10 # 熔断触发最小请求次数，默认值是20
  execution:
   isolation:
    thread:
     timeoutInMilliseconds: 2000 # 熔断超时设置，默认为1秒

 

Feign

使用了Ribbon的负载均衡功能，大大简化了远程调用时的代码：

 

String url = "http://user-service/user/" + id; 

String url = "http://user-service/user/" + id; 
​​​​​​​User user = this.restTemplate.getForObject(url, User.class)

如果就学到这里，你可能以后需要编写类似的大量重复代码，格式基本相同，无非参数不一样。有没有更优雅的方式，来对这些代码再次优化呢？

这就是接下来要学的Feign的功能了

 

1. 简介:

Feign也叫伪装：

 

Feign可以把Rest的请求进行隐藏，伪装成类似SpringMVC的Controller一样。你不用再自己拼接url，拼接参数等等操作，一切都交给Feign去做。

在 consumer-demo 项目的 pom.xml 文件中添加如下依赖

 

<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>

 

2. Feign的客户端

 

@FeignClient("user-service")
public interface UserClient {
  @GetMapping("/user/{id}")
  User queryById(@PathVariable("id") Long id);
}

 

• 首先这是一个接口，Feign会通过动态代理，帮我们生成实现类。这点跟mybatis的mapper很像
• @FeignClient ，声明这是一个Feign客户端，同时通过 value 属性指定服务名称
• 接口中的定义方法，完全采用SpringMVC的注解，Feign会根据注解帮我们生成URL，并访问获取结果
• @GetMapping中的/user，请不要忘记；因为Feign需要拼接可访问的地址
• 注意:

• • 方法的参数类型必须和调用的controller中得一致
  • 可变长度参数必须制定参数名称,否则报错: PathVariable annotation was empty on param 0.
  • 注意类上mapping地址不要忘记

 

编写新的控制器类 ConsumerFeignController ，使用UserClient访问：

 

@RestController
@RequestMapping("/cf")
public class ConsumerFeignController {
  @Autowired
  private UserClient userClient;
  @GetMapping("/{id}")
  public User queryById(@PathVariable Long id){
    return userClient.queryById(id);
 }
}

 

3. 开启Feign功能

在 ConsumerApplication 启动类上，添加注解，开启Feign功能

 

/*@SpringBootApplication
@EnableDiscoveryClient
@EnableCircuitBreaker*/
@SpringCloudApplication
@EnableFeignClients//开启Feign功能
public class ConsumerApplication {
  public static void main(String[] args) {
    SpringApplication.run(ConsumerApplication.class, args);
 }
  @Bean
  @LoadBalanced
  public RestTemplate restTemplate(){
    return new RestTemplate();
 }
}

 

Feign中已经自动集成了Ribbon负载均衡，因此不需要自己定义RestTemplate进行负载均衡的配置

 

启动测试

访问接口：http://localhost:8080/cf/2

 

Feign的负载均衡

 

         

 

Fegin内置的ribbon默认设置了请求超时时长，默认是1000，我们可以通过手动配置来修改这个超时时长：

 

ribbon:
ReadTimeout: 2000 # 读取超时时长
ConnectTimeout: 1000 # 建立链接的超时时长

 

因为ribbon内部有重试机制，一旦超时，会自动重新发起请求。如果不希望重试，可以添加配置：

修改  consumer-demo\src\main\resources\application.yml 添加如下配置：

 

ribbon:
ConnectTimeout: 1000 # 连接超时时长
ReadTimeout: 2000 # 数据通信超时时长
MaxAutoRetries: 0 # 当前服务器的重试次数
MaxAutoRetriesNextServer: 0 # 重试多少次服务
OkToRetryOnAllOperations: false # 是否对所有的请求方式都重试

 

重新给UserService的方法设置上线程沉睡时间2秒可以测试上述配置

Hystrix支持

Feign默认也有对Hystrix的集成

 

只不过，默认情况下是关闭的。需要通过下面的参数来开启；

修改  consumer-demo\src\main\resources\application.yml 添加如下配置：

 

feign:
hystrix:
 enabled: true # 开启Feign的熔断功能

 

但是，Feign中的Fallback配置不像Ribbon中那样简单了。

1）首先，要定义一个类，实现刚才编写的UserFeignClient，作为fallback的处理类

 

@Component
public class UserClientFallback implements UserClient {
  @Override
  public User queryById(Long id) {
    User user = new User();
    user.setId(id);
    user.setName("用户异常");
    return user;
 }
}

2）然后在UserFeignClient中，指定刚才编写的实现类

 

@FeignClient(value = "user-service", fallback = UserClientFallback.class)
public interface UserClient {
  @GetMapping("/user/{id}")
  User queryById(@PathVariable("id") Long id);
}

 

3）重启测试

重启启动  consumer-demo 并关闭 user-service 服务，然后在页面访问：

http://localhost:8080/cf/8

feign:
compression:
 request:
  enabled: true # 开启请求压缩
 response:
  enabled: true # 开启响应压缩

 

 

 

请求压缩

 

Spring Cloud Feign 支持对请求和响应进行GZIP压缩，以减少通信过程中的性能损耗。通过下面的参数即可开启请求与响应的压缩功能

 

feign:
compression:
 request:
  enabled: true # 开启请求压缩
 response:
  enabled: true # 开启响应压缩

 

同时，我们也可以对请求的数据类型，以及触发压缩的大小下限进行设置：

 

feign:
compression:
 request:
  enabled: true # 开启请求压缩
  mime-types: text/html,application/xml,application/json # 设置压缩的数据类型
  min-request-size: 2048 # 设置触发压缩的大小下限

注：上面的数据类型、压缩大小下限均为默认值

 

日志级别

 

前面讲过，通过 logging.level.xx=debug 来设置日志级别。然而这个对Fegin客户端而言不会产生效果。因为@FeignClient 注解修改的客户端在被代理时，都会创建一个新的Fegin.Logger实例。我们需要额外指定这个日志的级别才可以。

 

1）在 consumer-demo 的配置文件中设置com.moonhu包下的日志级别都为 debug

修改  consumer-demo\src\main\resources\application.yml 添加如下配置：

logging:
level:
 com.moonhu: debug

 

2）在 consumer-demo 编写FeignConfig配置类，定义日志级别

 

@Configuration
public class FeignConfig {
  @Bean
  Logger.Level feignLoggerLevel(){
    //记录所有请求和响应的明细，包括头信息、请求体、元数据
    return Logger.Level.FULL;
 }
}

这里指定的Level级别是FULL，Feign支持4种级别：

NONE：不记录任何日志信息，这是默认值。

BASIC：仅记录请求的方法，URL以及响应状态码和执行时间

HEADERS：在BASIC的基础上，额外记录了请求和响应的头信息

FULL：记录所有请求和响应的明细，包括头信息、请求体、元数据。

 

3）在 consumer-demo 的 UserClient 接口类上的@FeignClient注解中指定配置类：

 

@FeignClient(value = "user-service", fallback = UserClientFallback.class,
configuration = FeignConfig.class)
public interface UserClient {
  @GetMapping("/user/{id}")
  User queryById(@PathVariable Long id);
}

 

4）重启项目，访问：http://localhost:8080/cf/8

 

Spring Cloud Gateway网关

简介

• Spring Cloud Gateway是Spring官网基于Spring 5.0、 Spring Boot 2.0、Project Reactor等技术开发的网关服务。
• Spring Cloud Gateway基于Filter链提供网关基本功能：安全、监控／埋点、限流等。
• Spring Cloud Gateway为微服务架构提供简单、有效且统一的API路由管理方式。
• Spring Cloud Gateway是替代Netflix Zuul的一套解决方案。

 

Spring Cloud Gateway组件的核心是一系列的过滤器，通过这些过滤器可以将客户端发送的请求转发（路由）到对应的微服务。 Spring Cloud Gateway是加在整个微服务最前沿的防火墙和代理器，隐藏微服务结点IP端口信息，从而加强安全保护。Spring Cloud Gateway本身也是一个微服务，需要注册到Eureka服务注册中心。

网关的核心功能是：过滤和路由

 

Gateway加入后的架构

不管是来自于客户端（PC或移动端）的请求，还是服务内部调用。一切对服务的请求都可经过网关，然后再由网关来实现 鉴权、动态路由等等操作。Gateway就是我们服务的统一入口。

 

核心概念

• 路由（route） 路由信息的组成：由一个ID、一个目的URL、一组断言工厂、一组Filter组成。如果路由断言为真，说明请求URL和配置路由匹配。
• 断言（Predicate） Spring Cloud Gateway中的断言函数输入类型是Spring 5.0框架中的ServerWebExchange。Spring Cloud Gateway的断言函数允许开发者去定义匹配来自于Http Request中的任何信息比如请求头和参数。
• 过滤器（Filter） 一个标准的Spring WebFilter。 Spring Cloud Gateway中的Filter分为两种类型的Filter，分别是Gateway Filter和Global Filter。过滤器Filter将会对请求和响应进行修改处理。

 

快速入门

新建工程

配置pom文件

 

  <dependencies>
    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-gateway</artifactId>
    </dependency>
    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
    </dependency>
  </dependencies>

 

编写启动类

创建 GatewayApplication 启动类

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

 

编写配置

 

server:
port: 10010
spring:
application:
 name: api-gateway
eureka:
client:
 service-url:
  defaultZone: http://127.0.0.1:10086/eureka
instance:
 prefer-ip-address: true

 

编写路由规则

需要用网关来代理 user-service 服务，先看一下控制面板中的服务状态：

 

 

server:
port: 10010
spring:
application:
 name: api-gateway
cloud:
 gateway:
  routes:
    # 路由id，可以随意写
   - id: user-service-route
     # 代理的服务地址
    uri: http://127.0.0.1:9091
     # 路由断言，可以配置映射路径
    predicates:
     - Path=/user/**
eureka:
client:
 service-url:
  defaultZone: http://127.0.0.1:10086/eureka
instance:
 prefer-ip-address: true

 

将符合 Path 规则的一切请求，都代理到  uri 参数指定的地址

本例中，我们将路径中包含有  /user/** 开头的请求，代理到http://127.0.0.1:9091

 

启动测试

访问的路径中需要加上配置规则的映射路径，我们访问：http://localhost:10010/user/8

 

面向服务的路由

在刚才的路由规则中，把路径对应的服务地址写死了！如果同一服务有多个实例的话，这样做显然不合理。应该根据服务的名称，去Eureka注册中心查找 服务对应的所有实例列表，然后进行动态路由！

 

修改映射配置，通过服务名称获取

因为已经配置了Eureka客户端，可以从Eureka获取服务的地址信息。

application.yml 文件如下

 

server:
port: 10010
spring:
application:
 name: api-gateway
cloud:
 gateway:
  routes:
    # 路由id，可以随意写
   - id: user-service-route
     # 代理的服务地址；lb表示从eureka中获取具体服务
         uri: lb://user-service
     # 路由断言，可以配置映射路径
    predicates:
     - Path=/user/**
eureka:
client:
 service-url:
  defaultZone: http://127.0.0.1:10086/eureka
instance:
 prefer-ip-address: true

 

路由配置中uri所用的协议为lb时（以uri: lb://user-service为例），gateway将使用 LoadBalancerClient把user-service通过eureka解析为实际的主机和端口，并进行ribbon负载均衡

 

启动测试

 

路由前缀

添加前缀

在gateway中可以通过配置路由的过滤器PrefixPath，实现映射路径中地址的添加；

application.yml 文件：

 

server:
port: 10010
spring:
application:
 name: api-gateway
 cloud:
 gateway:
  routes:
    # 路由id，可以随意写
   - id: user-service-route
     # 代理的服务地址；lb表示从eureka中获取具体服务
    uri: lb://user-service
     # 路由断言，可以配置映射路径
    predicates:
     - Path=/**
    filters:
      # 添加请求路径的前缀
     - PrefixPath=/user
eureka:
client:
 service-url:
  defaultZone: http://127.0.0.1:10086/eureka
instance:
 prefer-ip-address: true

 

通过 PrefixPath=/xxx 来指定了路由要添加的前缀。

也就是：

• PrefixPath=/user http://localhost:10010/8 --》http://localhost:9091/user/8
• PrefixPath=/user/abc http://localhost:10010/8 --》http://localhost:9091/user/abc/8

以此类推。

 

去除前缀

在gateway中可以通过配置路由的过滤器StripPrefix，实现映射路径中地址的去除；

application.yml 文件：

 

server:
port: 10010
spring:
application:
 name: api-gateway
cloud:
 gateway:
  routes:
    # 路由id，可以随意写
   - id: user-service-route
     # 代理的服务地址；lb表示从eureka中获取具体服务
    uri: lb://user-service
     # 路由断言，可以配置映射路径
    predicates:
     - Path=/api/user/**
    filters:
      # 表示过滤1个路径，2表示两个路径，以此类推
     - StripPrefix=1
eureka:
client:
 service-url:
  defaultZone: http://127.0.0.1:10086/eureka
instance:
 prefer-ip-address: true

 

通过 StripPrefix=1 来指定了路由要去掉的前缀个数。如：路径 /api/user/1 将会被代理到 /user/1 。

也就是：

• StripPrefix=1 http://localhost:10010/api/user/8 --》http://localhost:9091/user/8
• StripPrefix=2 http://localhost:10010/api/user/8 --》http://localhost:9091/8

以此类推

 

过滤器

简介

Gateway作为网关的其中一个重要功能，就是实现请求的鉴权。而这个动作往往是通过网关提供的过滤器来实现的。前面的  路由前缀 章节中的功能也是使用过滤器实现的。

 

Gateway自带过滤器有几十个，常见自带过滤器有：

 

过滤器名称 说明

 

AddRequestHeader	对匹配上的请求加上Header
AddRequestParameters	对匹配上的请求路由添加参数
AddResponseHeader	对从网关返回的响应添加Header
StripPrefix	对匹配上的请求路径去除前缀

 

   

详细的说明在官网链接

 

配置全局默认过滤器

这些自带的过滤器可以和使用  路由前缀 章节中的用法类似，也可以将这些过滤器配置成不只是针对某个路由；而是可以对所有路由生效，也就是配置默认过滤器：

 

了解如下：

 

server:
port: 10010
spring:
application:
 name: api-gateway
cloud:
 gateway:
   # 默认过滤器，对所有路由生效
     default-filters:
    # 响应头过滤器，对输出的响应设置其头部属性名称为X-Response-Default-MyName，值为moon；
如果有多个参数多则重写一行设置不同的参数
   - AddResponseHeader=X-Response-Default-MyName, moon
  routes:
    # 路由id，可以随意写
   - id: user-service-route
     # 代理的服务地址；lb表示从eureka中获取具体服务
    uri: lb://user-service
     # 路由断言，可以配置映射路径
    predicates:
     - Path=/api/user/**
    filters:
      # 表示过滤1个路径，2表示两个路径，以此类推
     - StripPrefix=1

 

过滤器类型：Gateway实现方式上，有两种过滤器；

1. 局部过滤器：通过 spring.cloud.gateway.routes.filters 配置在具体路由下，只作用在当前路由上；自带的过滤器都可以配置或者自定义按照自带过滤器的方式。如果配置spring.cloud.gateway.default-filters 上会对所有路由生效也算是全局的过滤器；但是这些过滤器的实现上都是要实现GatewayFilterFactory接口。

 

2. 全局过滤器：不需要在配置文件中配置，作用在所有的路由上；实现  GlobalFilter 接口即可。

 

执行生命周期

Spring Cloud Gateway 的 Filter 的生命周期也类似Spring MVC的拦截器有两个：“pre” 和 “post”。“pre”和 “post” 分别会在请求被执行前调用和被执行后调用。

   

这里的  pre 和  post 可以通过过滤器的 GatewayFilterChain 执行filter方法前后来实现。

 

使用场景

常见的应用场景如下：

• • 请求鉴权：一般 GatewayFilterChain 执行filter方法前，如果发现没有访问权限，直接就返回空。
  • 异常处理：一般 GatewayFilterChain 执行filter方法后，记录异常并返回。
  • 服务调用时长统计： GatewayFilterChain 执行filter方法前后根据时间统计。

 

 

自定义过滤器

自定义局部过滤器

需求：在application.yml中对某个路由配置过滤器，该过滤器可以在控制台输出配置文件中指定名称的请求参数的值。

编写过滤器

工程编写过滤器工厂类MyParamGatewayFilterFactory

 

@Component
public class MyParamGatewayFilterFactory extends
AbstractGatewayFilterFactory<MyParamGatewayFilterFactory.Config> {
  public static final String PARAM_NAME = "param";
  public MyParamGatewayFilterFactory() {
    super(Config.class);
 }
  @Override
  public List<String> shortcutFieldOrder() {
    return Arrays.asList(PARAM_NAME);
 }
  @Override
  public GatewayFilter apply(Config config) {
    return (exchange, chain) -> {
      ServerHttpRequest request = exchange.getRequest();
      if (request.getQueryParams().containsKey(config.param)) {
        request.getQueryParams().get(config.param)
           .forEach(value -> System.out.printf("----------局部过滤器-----%s
= %s-----",
                config.param, value));
     }
      return chain.filter(exchange);
   };
 }
  public static class Config {
    private String param;
    public String getParam() {
      return param;
   }
    public void setParam(String param) {
      this.param = param;
   }
 }
}

修改配置文件

application.yml 配置文件

 

server: 
  port: 10010
  spring:
  application:
   name: api-gateway
  cloud:
   gateway:
    routes:
      # 路由id，可以随意写
     - id: user-service-route
       # 代理的服务地址；lb表示从eureka中获取具体服务
      uri: lb://user-service
       # 路由断言，可以配置映射路径
      predicates:
       - Path=/api/user/**
      filters:
        # 表示过滤1个路径，2表示两个路径，以此类推
       - StripPrefix=1
        # 自定义过滤器    -MyParam(自定义过滤工厂前缀),name(类中需要的参数)
       - MyParam=name
  eureka:
  client:
   service-url:
    defaultZone: http://127.0.0.1:10086/eureka
  instance:
   prefer-ip-address: true

注意：自定义过滤器的命名应该为：***GatewayFilterFactory

测试

 

自定义全局过滤器

需求：模拟一个登录的校验。基本逻辑：如果请求中有token参数，则认为请求有效，放行。

编写全局过滤器类MyGlobalFilter

 

@Component
public class MyGlobalFilter implements GlobalFilter, Ordered {
  @Override
  public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
    System.out.println("-----------------全局过滤器MyGlobalFilter-------------------
--");
    String token = exchange.getRequest().getQueryParams().getFirst("token");
    if (StringUtils.isBlank(token)) {
      exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
      return exchange.getResponse().setComplete();
   }
    return chain.filter(exchange);
 }
  @Override
  public int getOrder() {
    //值越小越先执行
    return 1;
 }
}

 

访问 http://localhost:10010/api/user/8

 

负载均衡和熔断

Gateway中默认就已经集成了Ribbon负载均衡和Hystrix熔断机制。但是所有的超时策略都是走的默认值，比如熔断超时时间只有1S，很容易就触发了。因此建议手动进行配置：

 

hystrix:
command:
 default:
  execution:
   isolation:
    thread:
     timeoutInMilliseconds: 6000
ribbon:
ConnectTimeout: 1000
ReadTimeout: 2000
MaxAutoRetries: 0
MaxAutoRetriesNextServer: 0

Gateway跨域配置

一般网关都是所有微服务的统一入口，必然在被调用的时候会出现跨域问题。

 

跨域：在js请求访问中，如果访问的地址与当前服务器的域名、ip或者端口号不一致则称为跨域请求。若不解决则不能获取到对应地址的返回结果。

 

如：从在http://localhost:9090中的js访问 http://localhost:9000的数据，因为端口不同，所以也是跨域请求。

具体配置如下:

 

spring:
cloud:
 gateway:
  globalcors:
   corsConfigurations:
    '[/**]':
      #allowedOrigins: * # 这种写法或者下面的都可以，*表示全部
     allowedOrigins:
     - "http://docs.spring.io"
     allowedMethods:
     - GET

 

上述配置表示：可以允许来自 http://docs.spring.io 的get请求方式获取服务数据。

allowedOrigins 指定允许访问的服务器地址，如：http://localhost:10000 也是可以的。

'[/**]' 表示对所有访问到网关服务器的请求地址

官网具体说明：https://cloud.spring.io/spring-cloud-static/spring-cloud-gateway/2.1.1.RELEASE/multi/multi__cors_configuration.html

 

Gateway的高可用

启动多个Gateway服务，自动注册到Eureka，形成集群。如果是服务内部访问，访问Gateway，自动负载均衡，没问题。

但是，Gateway更多是外部访问，PC端、移动端等。它们无法通过Eureka进行负载均衡，那么该怎么办？

此时，可以使用其它的服务网关，来对Gateway进行代理。比如：Nginx

 

Gateway与Feign的区别

• Gateway 作为整个应用的流量入口，接收所有的请求，如PC、移动端等，并且将不同的请求转发至不同的处理微服务模块，其作用可视为nginx；大部分情况下用作权限鉴定、服务端流量控制
• Feign 则是将当前微服务的部分服务接口暴露出来，并且主要用于各个微服务之间的服务调用

 

Spring Cloud Config分布式配置中心

简介

在分布式系统中，由于服务数量非常多，配置文件分散在不同的微服务项目中，管理不方便。为了方便配置文件集中管理，需要分布式配置中心组件。在Spring Cloud中，提供了Spring Cloud Config，它支持配置文件放在配置服务的本地，也支持放在远程Git仓库（GitHub、码云）。

使用Spring Cloud Config配置中心后的架构如下图：

                           

 

配置中心本质上也是一个微服务，同样需要注册到Eureka服务注册中心！

 

Git配置管理

远程Git仓库

知名的Git远程仓库有国外的GitHub和国内的码云（gitee）；但是使用GitHub时，国内的用户经常遇到的问题是访问速度太慢，有时候还会出现无法连接的情况。如果希望体验更好一些，可以使用国内的Git托管服务——码云（gitee.com）。

与GitHub相比，码云也提供免费的Git仓库。此外，还集成了代码质量检测、项目演示等功能。对于团队协作开发，码云还提供了项目管理、代码托管、文档管理的服务。本章中使用的远程Git仓库是码云。

码云访问地址：https://gitee.com/

 

创建远程仓库

首先要使用码云上的私有远程git仓库需要先注册帐号；请先自行访问网站并注册帐号，然后使用帐号登录码云控制台

 

并创建公开仓库

 

       

 

   

 

创建配置文件

在新建的仓库中创建需要被统一配置管理的配置文件。

配置文件的命名方式：{application}-{profile}.yml 或 {application}-{profile}.properties

 

application为应用名称

profile用于区分开发环境，测试环境、生产环境等

如user-dev.yml，表示用户微服务开发环境下使用的配置文件。

这里将user-service工程的配置文件application.yml文件的内容复制作为user-dev.yml文件的内容，具体配置如下：

 

 

创建  user-dev.yml ；内容来自  user-service\src\main\resources\application.yml （方便后面测试user-

service项目的配置），可以如下：

 

server:
port: ${port:9091}
spring:
datasource:
 driver-class-name: com.mysql.jdbc.Driver
 url: jdbc:mysql://localhost:3306/springcloud
 username: root
 password: root
application:
  #应用名
 name: user-service
mybatis:
type-aliases-package: com.moon.user.pojo
eureka:
client:
 service-url:
  defaultZone: http://127.0.0.1:10086/eureka
instance:
 ip-address: 127.0.0.1
 prefer-ip-address: true
 lease-expiration-duration-in-seconds: 90
 lease-renewal-interval-in-seconds: 30

 

创建完user-dev.yml配置文件之后，gitee中的仓库如下：

 

搭建配置中心微服务

创建工程

创建配置中心微服务工程：

添加依赖，修改 config-server\pom.xml 如下：

 

 <dependencies>
    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
    </dependency>
    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-config-server</artifactId>
    </dependency>
  </dependencies>

 

启动类

创建配置中心工程 config-server 的启动类ConfigServerApplication.java 如下

 

@SpringBootApplication
@EnableConfigServer
public class ConfigServerApplication {
  public static void main(String[] args) {
    SpringApplication.run(ConfigServerApplication.class, args);
 }
}

 

配置文件

application.yml 如下：

 

server:
port: 12000
spring:
application:
 name: config-server
cloud:
 config:
  server:
   git:
    uri: https://gitee.com/liaojianbin/moon-config.git
eureka:
client:
 service-url:
  defaultZone: http://127.0.0.1:10086/eureka

 

注意上述的 spring.cloud.config.server.git.uri 则是在码云创建的仓库地址；可修改为你自己创建的仓库地址

启动测试

启动eureka注册中心和配置中心；然后访问http://localhost:12000/user-dev.yml ，查看能否输出在码云存储管理的

user-dev.yml文件。并且可以在gitee上修改user-dev.yml然后刷新上述测试地址也能及时到最新数据。

 

获取配置中心配置

添加依赖

pom.xml文件中添加如下依赖

 

    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-starter-config</artifactId>
      <version>2.1.1.RELEASE</version>
    </dependency>

 

修改配置

1. 删除 user-service 工程的 user-service\src\main\resources\application.yml 文件（因为该文件从配置中心获取）

2. 创建 user-service 工程 user-service\src\main\resources\bootstrap.yml 配置文件

 

spring:
cloud:
 config:
   # 与远程仓库中的配置文件的application保持一致
  name: user
   # 远程仓库中的配置文件的profile保持一致
  profile: dev
   # 远程仓库中的版本保持一致
     label: master
  discovery:
    # 使用配置中心
   enabled: true
    # 配置中心服务id
   service-id: config-server
eureka:
client:
 service-url:
  defaultZone: http://127.0.0.1:10086/eureka

 

user-service 工程修改后结构：

bootstrap.yml文件也是Spring Boot的默认配置文件，而且其加载的时间相比于application.yml更早。

application.yml和bootstrap.yml虽然都是Spring Boot的默认配置文件，但是定位却不相同。bootstrap.yml

可以理解成系统级别的一些参数配置，这些参数一般是不会变动的。application.yml 可以用来定义应用级别的参数，如果搭配 spring cloud config 使用，application.yml 里面定义的文件可以实现动态替换

总结就是，bootstrap.yml文件相当于项目启动时的引导文件，内容相对固定。application.yml文件是微服务

的一些常规配置参数，变化比较频繁。

启动测试

启动注册中心 eureka-server 、配置中心 config-server 、用户服务 user-service ，如果启动没有报错其实已经使用上配置中心内容，可以到注册中心查看，也可以检验 user-service 的服务。

 

Spring Cloud Bus服务总线

问题

前面已经完成了将微服务中的配置文件集中存储在远程Git仓库，并且通过配置中心微服务从Git仓库拉取配置文件，当用户微服务启动时会连接配置中心获取配置信息从而启动用户微服务。

如果我们更新Git仓库中的配置文件，那用户微服务是否可以及时接收到新的配置信息并更新呢？

修改远程Git配置

修改在码云上的user-dev.yml文件，添加一个属性test.name。

 

修改UserController

修改 user-service 工程中的处理器类；

UserController.java 如下：

 

@RestController
@RequestMapping("/user")
public class UserController {
  @Autowired
  private UserService userService;
  @Value("${test.name}")
  private String name;
  @GetMapping("/{id}")
  public User queryById(@PathVariable Long id){
    System.out.println("配置文件中的test.name = " + name);
    return userService.queryById(id);
 }
}

 

测试

依次启动注册中心 eureka-server 、配置中心 config-server 、用户服务 user-service ；然后修改Git仓库中的配置信息，访问用户微服务，查看输出内容。

 

结论：通过查看用户微服务控制台的输出结果可以发现，我们对于Git仓库中配置文件的修改并没有及时更新到用户微服务，只有重启用户微服务才能生效。

 

如果想在不重启微服务的情况下更新配置该如何实现呢? 可以使用Spring Cloud Bus来实现配置的自动更新。需要注意的是Spring Cloud Bus底层是基于RabbitMQ实现的，默认使用本地的消息队列服务，所以需要提前启动本地RabbitMQ服务（安装RabbitMQ以后才有），如下：

 

Spring Cloud Bus简介

Spring Cloud Bus是用轻量的消息代理将分布式的节点连接起来，可以用于广播配置文件的更改或者服务的监控管理。也就是消息总线可以为微服务做监控，也可以实现应用程序之间相互通信。 Spring Cloud Bus可选的消息代理有RabbitMQ和Kafka。

使用了Bus之后：

改造配置中心

在 config-server 项目的pom.xml文件中加入Spring Cloud Bus相关依赖

 

    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-bus</artifactId>
    </dependency>
    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-stream-binder-rabbit</artifactId>
    </dependency>

 

在 config-server 项目修改application.yml文件如下

 

server:
port: 12000
spring:
application:
 name: config-server
cloud:
 config:
  server:
   git:
    uri: https://gitee.com/liaojianbin/heima-config.git
 # rabbitmq的配置信息；如下配置的rabbit都是默认值，其实可以完全不配置
  rabbitmq:
 host: localhost
 port: 5672
 username: guest
 password: guest
eureka:
client:
 service-url:
  defaultZone: http://127.0.0.1:10086/eureka
management:
endpoints:
 web:
  exposure:
    # 暴露触发消息总线的地址
   include: bus-refresh

 

改造用户服务

在用户微服务 user-service 项目的pom.xml中加入Spring Cloud Bus相关依赖

 

    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-bus</artifactId>
    </dependency>
    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-stream-binder-rabbit</artifactId>
    </dependency>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>

 

修改 user-service 项目的bootstrap.yml如下：

 

spring:
cloud:
 config:
   # 与远程仓库中的配置文件的application保持一致
  name: user
   # 远程仓库中的配置文件的profile保持一致
  profile: dev
   # 远程仓库中的版本保持一致
  label: master
  discovery:
    # 使用配置中心
   enabled: true
           # 配置中心服务id
   service-id: config-server
 # rabbitmq的配置信息；如下配置的rabbit都是默认值，其实可以完全不配置
rabbitmq:
 host: localhost
 port: 5672
 username: guest
 password: guest
eureka:
client:
 service-url:
  defaultZone: http://127.0.0.1:10086/eureka

 

改造用户微服务 user-service 项目的UserController

 

测试

前面已经完成了配置中心微服务和用户微服务的改造，下面来测试一下，当我们修改了Git仓库中的配置文件，用户

微服务是否能够在不重启的情况下自动更新配置信息。

测试步骤：

第一步：依次启动注册中心 eureka-server 、配置中心 config-server 、用户服务 user-service

第二步：访问用户微服务http://localhost:9091/user/8；查看IDEA控制台输出结果

第三步：修改Git仓库中配置文件 user-dev.yml 的 test.name 内容

第四步：使用Postman或者RESTClient工具发送POST方式请求访问地址http://127.0.0.1:12000/actuator/bus-refresh

 

第五步：访问用户微服务系统控制台查看输出结果

 

说明：

1、Postman或者RESTClient是一个可以模拟浏览器发送各种请求（POST、GET、PUT、DELETE等）的工具

2、请求地址http://127.0.0.1:12000/actuator/bus-refresh中 /actuator是固定的，/bus-refresh对应的是配置中心config-server中的application.yml文件的配置项include的内容

3、请求http://127.0.0.1:12000/actuator/bus-refresh地址的作用是访问配置中心的消息总线服务，消息总线服务接收到请求后会向消息队列中发送消息，各个微服务会监听消息队列。当微服务接收到队列中的消息后，会重新从配置中心获取最新的配置信息。

 

如果是指只想通知某一个客户端刷新：指定该客户端即可

http://127.0.0.1:12000/actuator/bus-refresh/{server-name}:{port}

Spring Cloud 体系技术综合应用概览