收款定制开发在项目开发中，收款定制开发随着业务越来越多导致收款定制开发功能之间耦合性高，收款定制开发开发效率低，收款定制开发系统运行缓慢难以维护收款定制开发及不稳定等，收款定制开发而架构可以避免或者解收款定制开发决这些问题，而SpringCloud收款定制开发是微服务架构的实现，收款定制开发所以今天我们一起来学习一下SpringCloud。

一、收款定制开发系统架构演变

收款定制开发随着互联网的发展，收款定制开发网站应用的规模不断扩大。收款定制开发需求的激增，收款定制开发带来的是技术上的压力。

收款定制开发系统架构也因此也不断的演进、升级、迭代。收款定制开发从单一应用，收款定制开发到垂直拆分，收款定制开发到收款定制开发分布式服务，到SOA，收款定制开发以及现在火热的微服务架构，还有在Google收款定制开发带领下来势汹涌的Service 。收款定制开发所以我们今天就回顾历史，收款定制开发看一看系统架构演变的历程。

1.1收款定制开发集中式架构

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

优点：
- 收款定制开发系统开发速度快
- 收款定制开发维护成本低
- 收款定制开发适用于并发要求较低的系统
缺点：
- 收款定制开发代码耦合度高，收款定制开发后期维护困难
- 收款定制开发无法针对不同模块进行收款定制开发针对性优化
- 收款定制开发无法水平扩展（集群部署）
- 收款定制开发单点容错率低，收款定制开发并发能力差

1.2垂直拆分

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

优点：
- 收款定制开发系统拆分实现了流量分担，收款定制开发解决了并发问题
- 收款定制开发可以针对不同模块进行优化
- 收款定制开发方便水平扩展，负载均衡，收款定制开发容错率提高
缺点：
- 收款定制开发系统间相互独立，收款定制开发会有很多重复开发工作，收款定制开发影响开发效率

1.3分布式服务

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

优点：
- 收款定制开发将基础服务进行了抽取，收款定制开发系统间相互调用，收款定制开发提高了代码复用和开发效率
缺点：
- 收款定制开发系统间耦合度变高，收款定制开发调用关系错综复杂，难以维护

1.4收款定制开发面向服务架构（SOA）

SOA（Service Oriented Architecture）收款定制开发面向服务的架构：收款定制开发它是一种设计方法，收款定制开发其中包含多个服务，收款定制开发服务之间通过相互依赖收款定制开发最终提供一系列的功能。

一个服务收款定制开发通常以独立的形式存在收款定制开发与操作系统进程中。收款定制开发各个服务之间收款定制开发通过网络调用。

SOA收款定制开发结构图如下：

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

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

1.5微服务架构

微服务架构是使用一套小服务来开发单个应用的方式或途径，

每个服务基于单一业务能力构建，运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，并能够通过自动化部署机制来独立部署。

这些服务可以使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。

微服务结构图：

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

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

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

微服务的特点：
- 单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责
- 微：微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服务虽小，但“五脏俱全”。
- 面向服务：面向服务是说每个服务都要对外暴露Rest风格服务接口API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供Rest的接口即可。
- 自治：自治是说服务间互相独立，互不干扰
  - 团队独立：每个服务都是一个独立的开发团队，人数不能过多。
  - 技术独立：因为是面向服务，提供Rest接口，使用什么技术没有别人干涉
  - 前后端分离：采用前后端分离开发，提供统一Rest接口，后端不用再为PC、移动端开发不同接口
  - 数据库分离：每个服务都使用自己的数据源
  - 部署独立，服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护

微服务架构与SOA都是对系统进行拆分：微服务架构基于SOA思想，可以把微服务当做去除了ESB的SOA。ESB是SOA架构中的中心总线，设计图形应该是星形的，而微服务是去中心化的分布式软件架构。两者比较类似，但其实也有一些差别：

功能	SOA	微服务
组件大小	大块业务逻辑	单独任务或小块业务逻辑
耦合	通常松耦合	松耦合
管理	着重中央管理	着重分散管理
目标	确保应用能够交互操作	易维护、易扩展、更轻量级的交互

二、服务调用方式

2.1RPC和HTTP

无论是微服务还是SOA，都面临着服务间的远程调用。

那么服务间的远程调用方式有哪些呢？常见的远程调用方式有以下2种：

RPC：Remote Produce Call远程过程调用，RPC基于Socket，工作在会话层。自定义数据格式，速度快，效率高。早期的webservice，现在热门的dubbo，都是RPC的典型代表
Http：http其实是一种网络传输协议，基于TCP，工作在应用层，规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用Http协议，也可以用来进行远程服务调用。缺点是消息封装臃肿，优势是对服务的提供和调用方没有任何技术限定，自由灵活，更符合微服务理念。

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

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

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

2.2HTTP客户端工具

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

HttpClient
OKHttp
URLConnection（JDK默认的）

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

三、SpringCloud

微服务是一种架构方式，最终肯定需要技术架构去实施。

微服务的实现方式很多，但是最火的莫过于SpringCloud了。其原因主要有以下几点：

后台硬：作为Spring家族的一员，有整个Spring全家桶靠山，背景十分强大。
技术强：Spring作为Java领域的前辈，可以说是功力深厚。有强力的技术团队支撑，一般人还真比不了
群众基础好：可以说大多数程序员的成长都伴随着Spring框架
SpringCloud与Spring的各个框架无缝整合，对开发人员来比较熟悉
使用方便：相信大家都体会到了SpringBoot给我们开发带来的便利，而SpringCloud完全支持SpringBoot的开发，用很少的配置就能完成微服务框架的搭建

3.1简介

Spring Cloud是Spring旗下的项目之一，官网地址：，Spring最擅长的就是集成，把世界上最好的框架拿过来，集成到自己的项目中。

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

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

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

3.2SpringCloud整合的组件和版本特征

Spring Cloud不是一个组件，而是许多组件的集合，常见的组件有：eureka注册中心，Gateway网关，Ribbon负载均衡，Feign服务调用，Hystrix熔断器。在有需要的时候项目添加对于的启动器依赖即可。

它的版本命名比较特殊，是以A到Z的为首字母的一些单词（其实是伦敦地铁站的名字）组成。

四、微服务场景模拟

首先，我们需要模拟一个服务调用的场景。方便后面学习微服务架构，

假设我们现在有这样一个需求：查询数据库中的用户数据并输出到浏览器，我们一共创建三个工程，父工程springcloudDemo、用户服务工程user-service和服务消费工程consumer-demo

父工程springcloudDemo：添加SpringBoot父坐标和管理其它组件的依赖
用户服务工程userService：整合MyBatis查询数据库中用户数据，提供查询用户服务
服务消费工程consumerDemo：利用查询用户服务获取用户数据并输出到浏览器

4.1父工程

第一步我们创建父工程springcloudDemo，微服务中需要同时创建多个项目，先创建一个父工程，然后后续的工程都以这个工程为父，实现maven的聚合。在实际开发中，每个微服务可独立一个工程。

创建好了之后我们修改父工程的文件（提取码：q6g4），对后续要用到的依赖的版本进行了管理。

4.2用户服务工程

我们创建一个用户服务工程userService，作为springcloudDemo父工程的子工程，该工程需要提供根据id查询数据库中的用户功能，用户通过访问url来输出用户的数据，

其实现步骤为：

添加启动器依赖（web、通用器mapper）
创建启动引导类和配置文件
修改配置文件中的参数
编写测试代码（UserMapper，UserService，UserController）
测试

第一步我们在userService工程的pom.xml中添加启动器依赖，


<!--WEB工程启动器-->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<!--通用Mapper启动器-->
<dependency>
    <groupId>tk.mybatis</groupId>
    <artifactId>mapper-spring-boot-starter</artifactId>
</dependency>
<!--Mysql驱动-->
<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
</dependency>

第二步我们创建启动引导类和配置文件，首先我们创建启动引导类，


@SpringBootApplication
@MapperScan("com.laotang.user.mapper")//指定mapper扫描的包路径
public class UserApplication {
    public static void main(String[] args) {
        SpringApplication.run(UserApplication.class, args);
    }
}

然后是生成application.yml配置文件，


#配置数据源连接参数
spring:
  datasource:
    driver-class-name: com.mysql.jdbc.Driver
    url: jdbc:mysql://localhost:3306/mydb1
    username: root
    password: 3837
 
# mybatis配置
mybatis:
  # 实体类别名包路径
  type-aliases-package: com.laotang.user.pojo
 
#修改端口号，避免和其他工程冲突
server:
  port: 9091

这里我们还是用之前定义的User实体类以及数据库中的user表进行实验。dao层已经弄好了，接下来是mapper接口的定义，


import com.laotang.user.pojo.User;
import tk.mybatis.mapper.common.Mapper;
 
public interface UserMapper extends Mapper<User> {
}

然后是service业务层的代码编写，


@Service
public class UserService {
    @Autowired
    private UserMapper userMapper;
 
    public User findById(Long id){
        return userMapper.selectByPrimaryKey(id);//利用通用mapper的查询主键方法来查询user
    }
}

接着是controller层，处理url和对应方法的执行，


@RestController//相当于@ResponseBody ＋ @Controller
@RequestMapping("/user")
public class UserController {
    @Autowired
    private UserService userService;
 
    @GetMapping("/{id}")
    public User findById(@PathVariable Long id){
        return userService.findById(id);
    }
}

都写好之后我们启动main方法，访问，

4.3服务消费工程

接下来我们创建服务消费工程consumerDemo，编写测试类使用RestTemplate访问userService工程的路径，根据id查询用户，

换句话说，就是可以访问时，使用RestTemplate获取的数据。

实现步骤如下：

添加启动器依赖
创建启动引导类（注册RestTemplate）和配置文件
编写测试代码（ConsumerController中使用RestTemplate访问服务获取数据）
测试

首先第一步我们还是在consumerDemo工程中添加启动器依赖，


<dependencies>
    <!--WEB工程启动器-->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
</dependencies>

然后我们创建该工程的启动引导类，


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

接着编写controller的ConsumerController，使用RestTemplate访问服务获取数据，


@RestController
@RequestMapping("/consumer")
public class ConsumerController {
    @Autowired
    private RestTemplate restTemplate;
 
    @GetMapping("/{id}")
    public User findById(@PathVariable Long id){
        String url="http://localhost:9091/user/"+id;//指定要访问的url
        return restTemplate.getForObject(url, User.class);//访问url得到数据并返回
    }
}

然后我们就可以启动引导类的main方法了，（注意启动前需要先启动userService的引导类main方法），输入我们要访问的地址，

我们成功在该工程中访问到了另一个工程的方法。

4.4存在的问题

简单回顾一下，刚才我们写了两个工程：

userService：对外提供了查询用户的接口

consumerDemo：通过RestTemplate访问http://locahost:9091/user/{id} 接口，查询用户数据

上述实验中主要有以下几个问题：

在consumer中，我们把url地址硬编码到了代码中，不方便后期维护
consumer需要记忆userService的地址，如果出现变更，可能得不到通知，地址将失效
consumer不清楚userService的状态，服务宕机也不知道
userService只有1台服务，不具备高可用性
即便userService形成集群，consumer还需自己实现负载均衡

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

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

以上的这些问题，都将在SpringCloud中得到答案。

五、Eureka注册中心说明

5.1认识Eureka

首先我们来解决第一个问题，服务的管理。

在刚才的案例中，userService对外提供服务，需要对外暴露自己的地址。

而consumer-demo（调用者）需要记录服务提供者的地址。将来地址出现变更时需要及时更新。

这在服务较少的时候并不觉得有什么，但是在现在日益复杂的互联网环境，一个项目可能会拆分出十几，甚至几十个微服务。此时如果还人为管理地址，不仅开发困难，将来测试、发布上线都会非常麻烦，这与DevOps的思想是背道而驰的。（DevOps的思想是系统可以通过一组过程、方法或系统，去提高应用发布和运维的效率，降低管理成本）

例如在网约车出现以前，人们出门叫车只能叫出租车。

一些私家车想做出租却没有资格，被称为黑车。而很多人想要约车，但是无奈出租车太少，不方便。私家车很多却不敢拦，而且满大街的车，谁知道哪个才是愿意载人的。一个想要，一个愿意给，就是缺少引子，缺乏管理啊。

此时滴滴这样的网约车平台出现了，所有想载客的私家车全部到滴滴注册，记录你的车型（服务类型），身份信息（联系方式）。这样提供服务的私家车，在滴滴那里都能找到，一目了然。此时要叫车的人，只需要打开APP，输入你的目的地，选择车型（服务类型），滴滴自动安排一个符合需求的车到你面前为你服务。

Eureka就好比是滴滴，负责管理、记录服务提供者的信息。

服务调用者无需自己寻找服务，而是把自己的需求告诉Eureka，然后Eureka会把符合你需求的服务告诉你。

同时，服务提供方与Eureka之间通过“心跳” 机制进行监控，当某个服务提供方出现问题，Eureka自然会把它从服务列表中剔除。这就实现了服务的自动注册、发现、状态监控。

5.2原理图

Eureka的基本架构图如下：

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

5.3入门案例

5.3.1搭建eurekaServer工程

Eureka是服务注册中心，只做服务注册，自身并不提供服务也不消费服务。那么首先我们就需要搭建服务注册中心，即搭建一个eurekaServer的工程。

我们可以利用SpringBoot的方式搭建web工程使用Eureka进行学习，实现步骤如下：

创建工程，添加启动器依赖
编写启动引导类（添加Eureka的服务注解）和配置文件
修改配置文件
启动测试

首先我们创建eurekaServer工程，然后在pom.xml中添加eureka的启动器依赖，


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

然后我们编写启动引导类，注意要添加eureka的服务注解，


@EnableEurekaServer//生命当前应用是Eureka服务
@SpringBootApplication//指定当前类为SpringBoot项目启动引导类
public class EurekaServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(EurekaServerApplication.class, args);
    }
}

然后我们对配置项进行修改，配置端口以及eureka的一些配置，


server:
  port: 10086
 
#设置当前应用的名称
spring:
  application:
    name: eurekaServer
eureka:
  client:
    service-url:
      #eureka提供的服务地址（供其他服务进行访问），如果是集群的话，需要指定其他集群eureka地址
      defaultZone: http://127.0.0.1:10086/eureka
    #不注册自己到服务中
    register-with-eureka: false
    #不拉取服务
    fetch-registry: false

配置好了之后我们直接启动引导类，输入，看到如下界面就算配置成功了，

我们把eurekaServer服务注册中心搭建好了，下一步就是在实现服务然后在注册中心进行注册，我们直接将userService模块的服务注册到eureka中，并在consumerDemo模块通过服务名称调用。

5.3.2服务注册

首先我们要把userService模块的服务注册到eureka中，这里就要用到服务注册。

服务注册，就是在服务上添加Eureka的客户端依赖，客户端代码会自动把服务注册到EurekaServer中，其主要步骤如下：

添加Eureka依赖
修改启动引导类，添加开启eureka客户端发现的注解
修改配置文件，设置eureka服务地址

第一步我们在userService模块的pom.xml中添加eureka依赖，


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

然后修改启动引导类，添加开启eureka客户端发现的注解，


@SpringBootApplication
@MapperScan("com.laotang.user.mapper")//指定mapper扫描的包路径
@EnableDiscoveryClient//开启eureka客户端发现功能
public class UserApplication {
    public static void main(String[] args) {
        SpringApplication.run(UserApplication.class, args);
    }
}

接着修改配置文件，设置eureka服务地址，然后给该服务起一个名，


spring:
  application:
    name: userService
eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka

配置好了之后我们启动userService服务的启动类（前提先启动eureka注册中心服务类），我们再访问eureka注册中心就可以看到刚刚注册的服务了，application的名字就是我们配置的，

5.3.3服务发现

注册完了userService模块的服务，我们想在consumerDemo模块中调用服务，需要服务发现。

服务发现，也要在服务上添加Eureka的客户端依赖，这样就可以使用工具类根据服务名称获取对应的服务地址列表，其主要步骤如下：

添加Eureka依赖
修改启动引导类，添加开启eureka客户端发现的注解
修改配置文件，设置eureka服务地址
修改处理器类ConsumerController，可以使用工具类DiscoveryClient根据服务名称获取对应服务地址列表

第一步还是在consumerDemo模块中添加eureka的依赖，


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

然后修改启动引导类，同样需要添加eureka的注解，

@EnableDiscoveryClient//开启eureka客户端发现功能

然后是修改配置文件，设置eureka的服务地址，


#设置应用名字
spring:
  application:
    name: consumerDemo
#设置eureka服务地址
eureka:
  client:
    service-url:
      defaultZone: http://127.0.0.1:10086/eureka

最后我们还需要修改处理器类ConsumerController，使用工具类DiscoveryClient根据服务名称获取对应服务地址列表，


@RestController
@RequestMapping("/consumer")
public class ConsumerController {
    @Autowired
    private RestTemplate restTemplate;
 
    @Autowired
    private DiscoveryClient discoveryClient;
 
    @GetMapping("/{id}")
    public User findById(@PathVariable Long id) {
        List<ServiceInstance> serviceInstances = discoveryClient.getInstances("userService");//通过应用名获取eureka中注册的userService实例
        ServiceInstance userService = serviceInstances.get(0);//获取一个实例
        String url = "http://" + userService.getHost() + ":" + userService.getPort() + "/user/" + id;//动态获取服务地址
        return restTemplate.getForObject(url, User.class);//访问url得到数据并返回
    }
}

然后我们启动consumerDemo的启动类，输入url可以看到查询到了id=1的用户信息，

5.4Eureka详解

5.4.1基础架构

Eureka架构中的三个核心角色：

服务注册中心
- Eureka的服务端应用，提供服务注册和发现功能，就是刚刚我们建立的eurekaServer
服务提供者
- 提供服务的应用，可以是SpringBoot应用，也可以是其它任意技术实现，只要对外提供的是Rest风格服务即可。本例中就是我们实现的userService
服务消费者
- 消费应用从注册中心获取服务列表，从而得知每个服务方的信息，知道去哪里调用服务方。本例中就是我们实现的consumerDemo

5.4.2高可用的EurekaServer

EurekaServer即服务的注册中心，在刚才的案例中，我们只有一个EurekaServer，

但是EurekaServer是一个web应用，可以启动多个实例（配置不同端口避免启动冲突），所以EurekaServer也可以是一个集群，形成高可用的Eureka中心。

多个Eureka Server之间也会互相注册为服务，当服务提供者注册到EurekaServer集群中的某个节点时，该节点会把服务的信息同步给集群中的每个节点，从而实现数据同步。

因此无论客户端访问到EurekaServer集群中的哪个节点，都可以获取到完整的服务列表信息。

而作为客户端，需要把信息注册到每个Eureka中：

例如如果有三个Eureka，则每一个EurekaServer都需要注册到其它几个Eureka服务中，例如：有三个分别为10086、10087、10088，则：

10086要注册到10087和10088上
10087要注册到10086和10088上
10088要注册到10086和10087上

我们现在来试一下，假设要搭建两台EurekaServer的集群，端口分别为10086和10087，那么首先我们要修改一下eurekaServer工程的配置文件，


server:
  port: ${port:10086}
 
#设置当前应用的名称
spring:
  application:
    name: eurekaServer
eureka:
  client:
    service-url:
      #eureka提供的服务地址（供其他服务进行访问），如果是集群的话，需要指定其他集群eureka地址
      defaultZone: ${defaultZone:http://127.0.0.1:10086/eureka}
    #做eureka集群时，需要注册自己到服务中，让别的eureka发现自己
    register-with-eureka: true
    #从eureka集群拉取服务
    fetch-registry: true

然后对eurekaServer的启动项进行配置，

这里我们点开Environment，配置VM options启动参数，

配置好10086的eureka服务后，我们复制生成端口号为10087的eureka服务，

复制后我们修改一下名字，同样对VM options启动参数进行配置，

选择应用之后，我们先启动10086端口的eureka服务，然后我们再启动10087端口的eureka服务，

这样我们的高可用Eureka中心就搭建好了，接下来我们将userService服务启动，注册到10086端口的eureka中心，但是我们可以看到，由于eurekaServer是集群，所以当服务注册到某一个eureka上时，也会注册到集群的其他eurekaServer上，

此时可以看到两个eurekaServer上面都有userService服务，

同时我们还可以在注册服务时就指定多个注册地址，这样当一个注册中心不可用时保证可以正常注册到eureka服务中心上，


eureka:
  client:
    service-url:
      #指定服务注册时eureka的多个注册地址
      defaultZone: http://127.0.0.1:10086/eureka,http://127.0.0.1:10087/eureka

5.4.3Eureka客户端

服务提供者要向EurekaServer注册服务，并且完成服务续约等工作。服务消费者则向EurekaServer拉取服务，获得想要的服务。

1、服务注册

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

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

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


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

2、服务续约

在注册服务完成以后，服务提供者会维持一个心跳（定时向EurekaServer发起Rest请求），告诉EurekaServer该服务还处于有效状态，这个我们称为服务的续约（renew）。

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


eureka:
  instance:
    lease-expiration-duration-in-seconds: 90 # 若到了该续约的时间未续约，会继续等待90s才失效
    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设定的时间）从服务列表中移除，这两个值在生产环境不要修改，默认即可。

3、获取服务列表

当服务消费者启动时，会检测eureka.client.fetch-registry=true 参数的值，

如果为true，则会从EurekaServer服务的列表拉取只读备份，然后缓存在本地。并且每隔30秒会重新拉取并更新数据。可以在consumer-demo项目中通过下面的参数来修改：


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

5.4.4失效剔除和自我保护

下面的配置都是在Eureka Server服务端进行的。

1、服务下线

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

2、失效剔除

有时我们的服务可能由于内存溢出或网络故障等原因使得服务不能正常的工作，而服务注册中心并未收到“服务下线”的请求。

相对于服务提供者的“服务续约”操作，服务注册中心在启动时会创建一个定时任务，默认每隔一段时间（默认为60秒）将当前清单中超时（默认为90秒）没有续约的服务剔除，这个操作被称为失效剔除。

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

3、自我保护

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

这是触发了Eureka的自我保护机制。

当服务未按时进行心跳续约时，Eureka会统计服务实例最近15分钟心跳续约的比例是否低于了85%。

在实际生产环境下，因为网络延迟等原因，心跳失败实例的比例很有可能超标，但是此时就把服务剔除列表并不妥当，因为服务可能没有宕机。Eureka在这段时间内不会剔除任何服务实例，直到网络恢复正常。

在实际工作中这很有效，保证了大多数服务依然可用，不过也有可能获取到失败的服务实例，因此服务调用者必须做好服务的失败容错。

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


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

六、负载均衡Ribbon

在刚才的案例中，我们启动了一个userService服务，然后通过DiscoveryClient来获取服务实例信息，然后获取ip和端口来访问服务，

但是实际环境中，往往会开启很多个userService的集群。此时获取的服务列表中就会有多个，消费者到底该访问哪一个呢？一般这种情况下就需要写负载均衡算法，在多个实例列表中进行选择。

负载均衡是一个算法，可以通过该算法实现从地址列表中获取一个地址进行服务调用。

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

Ribbon是Netflix 发布的负载均衡器，它有助于控制HTTP和TCP客户端的行为。

为Ribbon配置服务提供者地址列表后，Ribbon就可基于某种负载均衡算法，自动地帮助服务消费者去请求。

Ribbon默认为我们提供了很多的负载均衡算法，例如轮询、随机等。当然，我们也可为Ribbon实现自定义的负载均衡算法。

接下来，我们就来使用Ribbon实现负载均衡，主要步骤如下：

启动多个userService服务实例（端口号分别为9091,9092）
修改RestTemplate实例化方法，添加负载均衡注解
修改ConsumerController处理器方法
测试

首先第一步要测试负载均衡，就先要有多个服务实例，这里我们配置启动两个userService 实例，一个端口号为9091，另一个端口号为9092。我们先修改userService的配置文件，


#如果有提供端口，则使用提供的端口，否则使用默认的9091端口
server:
  port: ${port:9091}

然后修改UserApplication的配置项，

修改好了之后再复制一个，修改端口号为9092，

全部修改好了之后点击应用，分别启动这两个服务实例（先启动eurekaServer），可以看到已经注册到eurekaServer中心了。

接下来我们就开始使用Ribbon进行负载均衡，因为Eureka中已经集成了Ribbon，所以我们无需引入新的依赖。我们直接修改consumerDemo消费工程启动类的RestTemplate实例化方法，在RestTemplate的配置方法上添加@LoadBalanced 注解：


@Bean
@LoadBalanced//添加负载均衡注解
public RestTemplate restTemplate(){
    return new RestTemplate();
}

然后修改ConsumerController的方法，


@GetMapping("/{id}")
public User findById(@PathVariable Long id) {
    String url = "http://userService/user/" + id;//使用服务名进行访问
    return restTemplate.getForObject(url, User.class);//访问url得到数据并返回
}

启动consumerDemo消费者工程，访问url查询用户信息，

看到这里大家是不是觉得有点奇怪，为什么只用service名称就可以访问了，之前不是一直用的ip和端口号吗，

String url = "http://userService/user/" + id

显然是有组件根据service名称，获取到了服务实例的ip和端口。

因为consumerDemo使用的是RestTemplate，spring的负载均衡自动配置类 LoadBalancerAutoConfiguration.LoadBalancerInterceptorConfig 会自动配置负载均衡拦截器（在spring-cloud-commons-**.jar包中的spring.factories中定义的自动配置类）

它就是LoadBalancerInterceptor ，这个类会在对RestTemplate的请求进行拦截，然后从Eureka根据服务id获取服务列表，随后利用负载均衡算法得到真实的服务地址信息，替换服务id。

并且Ribbon使用的默认负载均衡算法是轮循，即第一次先访问9091的服务，第二次就访问9092的服务，第三次9091，第四次9092，以此循环。

SpringBoot也帮提供了修改负载均衡规则的配置入口在consumerDemo的配置文件中添加如下，就变成随机的了：


userService:
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule

格式是： {服务名称}.ribbon.NFLoadBalancerRuleClassName

七、熔断器Hystrix

7.1Hystrix简介

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

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

7.2雪崩问题

微服务中，服务间调用关系错综复杂，一个请求，可能需要调用多个微服务接口才能实现，会形成非常复杂的调用链路：

如图，一次业务请求，需要调用A、P、H、I四个服务，这四个服务又可能调用其它服务。如果此时，服务 I 出现异常：

微服务 I 发生异常，请求阻塞，用户请求就不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞：

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

这就好比，一个汽车生产线，生产不同的汽车，需要使用不同的零件。

如果某个零件因为种种原因无法使用，那么就会造成整台车无法装配，陷入等待零件的状态，直到零件到位，才能继续组装。

此时如果有很多个车型都需要这个零件，那么整个工厂都将陷入等待的状态，导致所有生产都陷入瘫痪。一个零件的波及范围不断扩大。

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

线程隔离
服务熔断

7.3线程隔离和服务降级

7.3.1原理

线程隔离示意图：

Hystrix为每个依赖服务调用分配一个小的线程池，如果线程池已满调用将被立即拒绝，默认不采用排队，加速失败判定时间。
用户的请求将不再直接访问服务，而是通过线程池中的空闲线程来访问服务，如果线程池已满，或者请求超时，则会进行降级处理。

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

用户的请求故障时，不会被阻塞，更不会无休止的等待或者看到系统崩溃，至少可以看到一个执行结果（例如返回友好的提示信息）。

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

触发Hystrix服务降级的情况：

线程池已满
请求超时

7.3.2实践

首先第一步我们在consumerDemo消费者工程的pom.xml文件中添加hystrix的依赖，


<!--hystrix熔断器-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>

接着我们在启动类上添加注解@EnableCircuitBreaker 开启熔断，


@SpringBootApplication
@EnableDiscoveryClient//开启eureka客户端发现功能
@EnableCircuitBreaker//开启熔断
public class ConsumerApplication {
    //...
}

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


@SpringCloudApplication//上述三个的组合注解
public class ConsumerApplication {
    //...
}

第二步我们编写降级的逻辑，当目标服务的调用出现故障，我们希望快速失败，给用户一个友好提示。因此需要提前编写好失败时的降级处理逻辑，要使用HystrixCommand来完成。

这里我们修改ConsumerController处理器的处理方法，加上注解@HystrixCommand，

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

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

由于之前我们方法的返回值是User对象，所以如果要保持一致，降级逻辑方法也要返回User对象，但是失败逻辑中返回User对象没有太大意义，一般会返回友好提示。

所以把findById的方法改造为返回String，反正也是Json数据。这样失败逻辑中返回一个错误说明，会比较方便。


@RestController
@RequestMapping("/consumer")
@Slf4j
public class ConsumerController {
    @Autowired
    private RestTemplate restTemplate;
 
    @Autowired
    private DiscoveryClient discoveryClient;
 
    @GetMapping("/{id}")
    @HystrixCommand(fallbackMethod = "findByIdFallback")//指定降级逻辑的方法
    public String findById(@PathVariable Long id) {
        String url = "http://userService/user/" + id;//利用负载均衡获取服务
        return restTemplate.getForObject(url, String.class);//访问url得到数据并返回
    }
 
    public String findByIdFallback(Long id){
        log.error("查询用户信息失败。id：{}", id);
        return "服务忙，请稍后访问！";
    }
}

第三步我们进行测试，我们重新启动一下consumerDemo的启动类，当userService正常提供服务时，访问和以前一直，当userService服务宕机时，会发现页面返回了降级处理的信息，

7.3.3默认服务降级处理方法

这里我们把fallback写在了某个业务方法上，如果要降级的方法很多，就要写很多的降级处理方法。

为了解决这个问题，我们可以把Fallback配置加在类上，实现默认fallback（没有指定降级处理的方法，如果访问失败时会执行默认的fallback方法）。

这里我们对ConsumerController类进行修改，使用@HystrixCommand 注解开启服务降级，但是不给findById()方法指定降级处理方法，写一个默认的方法，


@RestController
@RequestMapping("/consumer")
@Slf4j
@DefaultProperties(defaultFallback = "defaultFallback")//指定默认的降级处理方法
public class ConsumerController {
    @Autowired
    private RestTemplate restTemplate;
 
    @Autowired
    private DiscoveryClient discoveryClient;
 
    @GetMapping("/{id}")
    @HystrixCommand//开启熔断服务降级
    public String findById(@PathVariable Long id) {
        String url = "http://userService/user/" + id;//动态获取服务地址
        return restTemplate.getForObject(url, String.class);//访问url得到数据并返回
    }
 
    public String defaultFallback(){
        return "默认提示：服务忙！";
    }
}

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

运行启动类，访问url可以看到默认的提示，

7.3.4超时设置

在之前的案例中，请求在超过1秒后都会返回错误信息，

这是因为Hystrix的默认超时时长为1，我们可以修改consumerDemo的配置文件进行设置，


hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            #设置默认超时时间为2000ms，即2s
            timeoutInMilliseconds: 2000

然后我们重新启动consumerDemo工程，可以看到超时时间超过2s后才执行的降级处理，

7.4服务熔断

7.4.1熔断原理

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

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

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

Hystrix的熔断状态机模型：

Closed：关闭状态（断路器关闭），所有请求都正常访问。
Open：打开状态（断路器打开），所有请求都会被降级。Hystrix会对请求情况计数，当一定时间内失败请求百分比达到阈值，则触发熔断，断路器会完全打开。默认失败比例的阈值是50%，请求次数最少不低于20次。
Half Open：半开状态，不是永久的，断路器打开后会进入休眠时间（默认是5S）。随后断路器会自动进入半开状态。此时会释放部分请求通过，若这些请求都是健康的，则会关闭断路器，否则继续保持打开，再次进行休眠计时。

7.4.2熔断实现

为了能够精确控制请求的成功或失败，在consumerDemo 的处理器业务方法中加入一段逻辑：


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

这样的话如果查询id为1的用户信息，一定失败，其它情况都成功。

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

此时（熔断发生5s内）你访问id为2的请求，会发现返回的也是失败，而且失败时间很短，只有20毫秒左右。由于默认的熔断触发要求较高，休眠时间窗较短，为了测试方便，我们可以通过配置修改熔断策略：


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

我们重启consumerDemo服务，然后疯狂查询id=1的用户，触发服务熔断机制，然后此时访问id=2的用户，会发现还是无法访问，

过了10s之后就可以再次访问到id=2的用户了。

收款定制开发SSM框架之SpringCloud——SpringCloud概述