SpringCloud

0.学习目标

·了解系统架构的演变

·了解RPC与Http的区别

·掌握HttpClient的简单使用

·知道什么是SpringCloud

·独立搭建Eureka注册中心

·独立配置Robbin负载均衡

1.了解系统架构的演变

之前只学习了简单的SSM框架，还没有实际项目开发经验，直接学习微服务架构是跨度非常大的，所以让我们先了解一下最简单的集中式架构

1.1 何为集中式架构

就是把所有的项目功能全部加在一个项目里面去，也就是我们之前做的那些项目实践（学生管理系统、商品销售系统等）

存在的问题：

1.代码耦合，开发维护困难

——例如：在比较大型的公司，如淘宝，京东，他们的应用功能非常的复杂，那么每个功能可能都有几个人在维护，如果每个功能都是放在同一个项目，那么相互的耦合就很大，只要一个人改了一点很有可能会影响到其他的功能，那么就不好管理维护。

2.无法针对不同模块进行针对性优化

——功能都放在一起，很难针对性的对某个功能进行优化，比如在双十一抢购节的时候，订单管理和购物车管理等功能的并发量、数据量都是极大的，而相对权限管理等没有那么大的数据量，那么我们要针对某些功能做针对性的优化（比如加集群增加缓存），但冗杂在一起就很难针对，可能会导致浪费（因为权限管理根本不用那么多缓存

3.无法水平扩展

4.单点容错率低，并发能力差

适用场景

一般的传统行业，如仓管管理系统，就是内部人员自己使用，那么就不用太考虑用户量小，而且功能单一，维护人员也不多优化时可以相互商量

1.2.垂直拆分

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

优点：

1.系统拆分实现了流量分担，解决了并发问题

2.可以针对不同模块进行优化

3.方便水平扩展，负载均衡，容错率提高

缺点：

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

比如商品，用户管理里面都有添加的功能，就造成代码重复浪费，所以进一步优化成分布式服务

1.3.分布式服务

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式调用是关键。
(例如商品、和用户管理中都有添加功能，那么商品的添加功能就可以调用用户的添加，这样就不用重复写添加功能了）

优点：

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

缺点：

系统间耦合度变高，调用关系错综复杂，难以维护
（调用来调用去很复杂）

1.4.服务治理（SOA）

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键
（之前，在每个功能服务中相互有调度，但如果每次的调度都要记住对应调度服务的id，地址，那么维护起来会很困难，比如某个服务改了，那么调度它的服务也要跟着改，这时候就有各种中心，把这些服务统一管理）

以前出现了什么问题？

服务越来越多，需要管理每个服务的地址

调用关系错综复杂，难以理清依赖关系
服务过多，服务状态难以管理，无法根据服务情况动态管理

服务治理要做什么？

服务注册中心，实现服务自动注册和发现，无需人为记录服务地址
服务自动订阅，服务列表自动推送，服务调用透明化，无需关心依赖关系
动态监控服务状态监控报告，人为控制服务状态

缺点：

服务间会有依赖关系，一旦某个环节出错会影响较大
服务关系复杂，运维、测试部署困难，不符合DevOps思想
（服务和服务之间有强依赖关系，就算是有中心，但底层还是相互调用，而且这种强依赖关系会导致如果一个服务挂了，那么有可能会导致所有的服务如雪崩一样全挂了）

1.5.微服务

前面说的SOA，英文翻译过来是面向服务。微服务，似乎也是服务，都是对系统进行拆分。因此两者非常容易混淆，但其实缺有一些差别：

微服务的特点：

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

微服务结构图：

2.服务调用方式

(我们之前学的都是启动tomcat，然后打开浏览器输入localhost:8080/xxx，那么为什么这个能调用呢，实际上就是浏览器把这个请求的信息包装好（请求头，参数等等）然后根据域名发送到对应端口（localhost域名就是本机的意思，8080就是端口）然后由我们启动的tomcat（端口号8080）接收到，在就是mvc那些到service层再到dao层等等）那么我们再开一个tomcat服务器，如何实现两个tomcat的相互调用呢

2.1RPC和HTTP

无论是微服务还是SOA，都面临着服务间的远程调用。那么服务间的远程调用方式有哪些呢？

常见的远程调用方式有以下几种：

RPC：

Remote Produce Call远程过程调用，类似的还有RMI（远程方法调用和前面一样）。自定义数据格式，基于原生TCP通信（三次握手建立连接，四次挥手关闭连接，因为RPC创建连接和断开连接比较消耗性能所以他会基于TCP建立上连接以求提高性能），速度快，效率高。早期的webservice，现在热门的dubbo（阿里巴巴的框架），都是RPC的典型

HTTP：

HTTP其实是一种网络传输协议，基于TCP，规定了数据传输的格式（实际上并不是一个传输协议并不是调用方法，所以只要满足协议要求即可，那么就会很灵活，RPC就要规定语言规定格式等，所以优点就是灵活）。现在客户端浏览器与服务端通信基本都是采用Http协议。也可以用来进行远程服务调用。缺点是消息封装臃肿。

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

2.1.认识RPC

RPC，即 Remote Procedure Call（远程过程调用），是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。说得通俗一点就是：A计算机提供一个服务，B计算机可以像调用本地服务那样调用A计算机的服务。

通过上面的概念，我们可以知道，实现RPC主要是做到两点：

实现远程调用其他计算机的服务
要实现远程调用，肯定是通过网络传输数据。A程序提供服务，B程序通过网络将请求参数传递给A，A本地执行后得到结果，再将结果返回给B程序。这里需要关注的有两点：

1）采用何种网络通讯协议？

现在比较流行的RPC框架，都会采用TCP作为底层传输协议

2）数据传输的格式怎样？

两个程序进行通讯，必须约定好数据传输格式。就好比两个人聊天，要用同一种语言，否则无法沟通。所以，我们必须定义好请求和响应的格式。另外，数据在网路中传输需要进行序列化，所以还需要约定统一的序列化的方式。
像调用本地服务一样调用远程服务
如果仅仅是远程调用，还不算是RPC，因为RPC强调的是过程调用，调用的过程对用户而言是应该是透明的，用户不应该关心调用的细节，可以像调用本地服务一样调用远程服务。所以RPC一定要对调用的过程进行封装
RPC调用流程图：

1525568965976

想要了解详细的RPC实现，给大家推荐一篇文章：自己动手实现RPC

2.2.认识HTTP

HTTP协议：超文本传输协议，是一种应用层协议。规定了网络传输的请求格式、响应格式、资源定位和操作的方式等。但是底层采用什么网络传输协议，并没有规定，不过现在都是采用TCP协议作为底层传输协议。说到这里，大家可能觉得，Http与RPC的远程调用非常像，都是按照某种规定好的数据格式进行网络通信，有请求，有响应。没错，在这点来看，两者非常相似，但是还是有一些细微差别。

RPC并没有规定数据传输格式，这个格式可以任意指定，不同的RPC协议，数据格式不一定相同。
Http中还定义了资源定位的路径，RPC中并不需要
最重要的一点：RPC需要满足像调用本地服务一样调用远程服务，也就是对调用过程在API层面进行封装。Http协议没有这样的要求，因此请求、响应等细节需要我们自己去实现。

优点：RPC方式更加透明，对用户更方便。Http方式更灵活，没有规定API和语言，跨语言、跨平台
缺点：RPC方式需要在API层面进行封装，限制了开发的语言环境。

例如我们通过浏览器访问网站，就是通过Http协议。只不过浏览器把请求封装，发起请求以及接收响应，解析响应的事情都帮我们做了。如果是不通过浏览器，那么这些事情都需要自己去完成。

2.3.如何选择？
既然两种方式都可以实现远程调用，我们该如何选择呢？

速度来看，RPC要比http更快，虽然底层都是TCP，但是http协议的信息往往比较臃肿，不过可以采用gzip压缩。
难度来看，RPC实现较为复杂，http相对比较简单
灵活性来看，http更胜一筹，因为它不关心实现细节，跨平台、跨语言。
因此，两者都有不同的使用场景：

如果对效率要求更高，并且开发过程使用统一的技术栈，那么用RPC还是不错的。
如果需要更加灵活，跨语言、跨平台，显然http更合适

那么我们该怎么选择呢？

微服务，更加强调的是独立、自治、灵活。而RPC方式的限制较多，因此微服务框架中，一般都会采用基于Http的Rest风格服务。

3.Http客户端工具

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

HttpClient

OKHttp

URLConnection

不过这些都有着不同的客户端，API各不相同，我们选择Spring提供的（因为Spring擅长的就是整合）

3.3.Spring的RestTemplate

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

HttpClient
OkHttp
JDK原生的URLConnection（默认的）

过程：

先在启动类配置我们要用来传输的类Spring的RestTemplate，参数里面就可以填上面这三种类型
再编写测试方法调用RestTemplate的getForObject方法（参数一个是另一个tomcat的访问路径，一个是接收到的数据类型）

4.初始SpringCloud

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

微服务的实现方式很多，但是最火的莫过于Spring Cloud了。为什么？

后台硬：作为Spring家族的一员，有整个Spring全家桶靠山，背景十分强大。
技术强：Spring作为Java领域的前辈，可以说是功力深厚。有强力的技术团队支撑，一般人还真比不了

群众基础好：可以说大多数程序员的成长都伴随着Spring框架，试问：现在有几家公司开发不用Spring？SpringCloud与Spring的各个框架无缝整合，对大家来说一切都是熟悉的配方，熟悉的味道。

使用方便：相信大家都体会到了SpringBoot给我们开发带来的便利，而SpringCloud完全支持SpringBoot的开发，用很少的配置就能完成微服务框架的搭建

4.1.简介

SpringCloud是Spring旗下的项目之一，官网地址：
SpringCloud官方网站

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

SpringCloud也是一样，它将现在非常流行的一些技术整合到一起，实现了诸如：配置管理，服务发现，智能路由，负载均衡，熔断器，控制总线，集群状态等等功能。其主要涉及的组件包括：

Netflix
Eureka：注册中心
Zuul：服务网关
Ribbon：负载均衡
Feign：服务调用
Hystix：熔断器
以上只是其中一部分，架构图：
![在这里插入图片描述](https://img-blog.csdnimg.cn/20200217023054263.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubm

4.2.版本

SpringCloud的版本命名比较特殊，因为它不是一个组件，而是许多组件的集合，它的命名是以A到Z的为首字母的一些单词组成：

我们在项目中，会是以Finchley的版本。

其中包含的组件，也都有各自的版本，如下表：

Component Edgware.SR3 Finchley.RC1 Finchley.BUILD-SNAPSHOT
spring-cloud-aws 1.2.2.RELEASE 2.0.0.RC1 2.0.0.BUILD-SNAPSHOT
spring-cloud-bus 1.3.2.RELEASE 2.0.0.RC1 2.0.0.BUILD-SNAPSHOT
spring-cloud-cli 1.4.1.RELEASE 2.0.0.RC1 2.0.0.BUILD-SNAPSHOT
spring-cloud-commons 1.3.3.RELEASE 2.0.0.RC1 2.0.0.BUILD-SNAPSHOT
spring-cloud-contract 1.2.4.RELEASE 2.0.0.RC1 2.0.0.BUILD-SNAPSHOT
spring-cloud-config 1.4.3.RELEASE 2.0.0.RC1 2.0.0.BUILD-SNAPSHOT
spring-cloud-netflix 1.4.4.RELEASE 2.0.0.RC1 2.0.0.BUILD-SNAPSHOT
spring-cloud-security 1.2.2.RELEASE 2.0.0.RC1 2.0.0.BUILD-SNAPSHOT
spring-cloud-cloudfoundry 1.1.1.RELEASE 2.0.0.RC1 2.0.0.BUILD-SNAPSHOT
spring-cloud-consul 1.3.3.RELEASE 2.0.0.RC1 2.0.0.BUILD-SNAPSHOT
spring-cloud-sleuth 1.3.3.RELEASE 2.0.0.RC1 2.0.0.BUILD-SNAPSHOT
spring-cloud-stream Ditmars.SR3 Elmhurst.RELEASE Elmhurst.BUILD-SNAPSHOT
spring-cloud-zookeeper 1.2.1.RELEASE 2.0.0.RC1 2.0.0.BUILD-SNAPSHOT
spring-boot 1.5.10.RELEASE 2.0.1.RELEASE 2.0.0.BUILD-SNAPSHOT
spring-cloud-task 1.2.2.RELEASE 2.0.0.RC1 2.0.0.RELEASE
spring-cloud-vault 1.1.0.RELEASE 2.0.0.RC1 2.0.0.BUILD-SNAPSHOT
spring-cloud-gateway 1.0.1.RELEASE 2.0.0.RC1 2.0.0.BUILD-SNAPSHOT
spring-cloud-openfeign 2.0.0.RC1 2.0.0.BUILD-SNAPSHOT

接下来，我们就一一学习SpringCloud中的重要组件。

5.微服务场景模拟

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

5.1.服务提供者

我们新建一个项目，对外提供查询用户的服务。

5.1.1.SpringCloud创建工程

借助于Spring提供的快速搭建工具：
这里我们通过maven用两个子工程来模拟两个项目之间的调用（好讲解）
然后他们子工程所要调用的依赖亦可以在父工程里面先导入（这样就不用重复）
以及打包方式要用pom

SpringCloud的依赖

其中这里注意的是：spring-cloud-dependencies是SpringCloud的版本管理pom
里面就是定义各组件的版本
spring-cloud-dependencies里面
其他几个依赖（mysql，projectlombok，springboot）（这几个依赖没有设置dependencyManagesent则是所有子项目都共有的依赖，而上面的要手动调用才可以）

创建子工程

注意子工程要创建到父工程目录下
子工程依赖
由于父工程以及导入了这些依赖，所以不用写版本
子工程各功能部署
这个就很熟悉了就是（Springboot那个创建项目）

子工程1（被调用）

1.先配置文件
2.开启启动器（配置类）
3.配置Pojo类
4.配置mapper层

5.配置service层
6.配置controller层

子工程2（调用类）

调用类就很简单了，只需要配置
1.开启启动类和创建一个RestTemplate2.配置Pojo类（用于接收）
3.配置controller层

启动项目

发现两个子项目都启动后
流程概括：先访问子项目2（调用者customer），子项目2通过RestTemplate传输访问到子项目1（被调用者user），子项目1被访问再通过controller层、service层、mapper层逻辑实现后再返回数据，再由项目2接收到封装到User并展示

5.3.有没有问题？

简单回顾一下，刚才我们写了什么：

use-service-demo：一个提供根据id查询用户的微服务
consumer-demo：一个服务调用者，通过RestTemplate远程调用user-service-demo
流程如下：

存在什么问题？（注意括号的8081）

1.在consumer中，我们把url地址硬编码到了代码中，不方便后期维护
（例如8081服务后面改了端口号，那么之前调用过这个服务都要修改代码，这样就很麻烦）
2.consumer需要记忆user-service的地址，如果出现变更，可能得不到通知，地址将失效
（如果80801改了，却没有通知调用他的cunsumer，那么这个就是失效了）
3.consumer不清楚user-service的状态，服务宕机也不知道
（而且consumer只是单纯的调用user，并没有判断是否状态可用）
4.user-service只有1台服务，不具备高可用性
（在多个consumer调用同一个user，一个tomcat实际上访问上限就是六七百，如果太多consumer访问同一个会降低性能）
5.即便user-service形成集群，consumer还需自己实现负载均衡
（而如果多配置几台user，那么就要自己进行分配，否则多配出来的没有被调用，导致资源空闲浪费）

分析（如何解决）：这时候需要一个统一管理服务的东西，即注册中心，它里面管理各种服务，当有consumer调用时访问它，由注册中心把状态良好user地址返回给consumer，并进行择优调控，这样就不会出现资源浪费，而且统一管理也好修改，也会实时监控各服务的状态（是否挂了）

注册中心的功能

1.服务管理

如何自动注册和发现
如何实现状态监管
如何实现动态路由

2.服务如何实现负载均衡
3.服务如何解决容灾问题
4.服务如何实现统一配置

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

6.Eureka注册中心

6.1.认识Eureka

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

问题分析

在刚才的案例中，user-service对外提供服务，需要对外暴露自己的地址。而consumer（调用者）需要记录服务提供者的地址。将来地址出现变更，还需要及时更新。这在服务较少的时候并不觉得有什么，但是在现在日益复杂的互联网环境，一个项目肯定会拆分出十几，甚至数十个微服务。此时如果还人为管理地址，不仅开发困难，将来测试、发布上线都会非常麻烦，这与DevOps的思想是背道而驰的。

网约车

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

此时滴滴这样的网约车平台出现了，所有想载客的私家车全部到滴滴注册，记录你的车型（服务类型），身份信息（联系方式）。这样提供服务的私家车，在滴滴那里都能找到，一目了然。

此时要叫车的人，只需要打开APP，输入你的目的地，选择车型（服务类型），滴滴自动安排一个符合需求的车到你面前，为你服务，完美！

Eureka做什么？

Eureka就好比是滴滴，负责管理、记录服务提供者的信息。服务调用者无需自己寻找服务，而是把自己的需求告诉Eureka，然后Eureka会把符合你需求的服务告诉你。

同时，服务提供方与Eureka之间通过“心跳”机制进行监控，当某个服务提供方出现问题，Eureka自然会把它从服务列表中剔除。

这就实现了服务的自动注册、发现、状态监控。

6.2.原理图

基本架构：
1.Eureka：就是服务注册中心（可以是一个集群），对外暴露自己的地址
（类似家政中心，得对外告诉自己的地址）
2.提供者：启动后向Eureka注册自己信息（地址，提供什么服务）
（类似工作人员，要在家政中心注册自己的信息（如名字，地址，能做什么工作），以便雇主查找并调用）
3.消费者：向Eureka订阅服务，Eureka会将对应服务的所有提供者地址列表发送给消费者，并且定期更新
（类似家政中心定期也要更新自己的服务列表（员工列表）给雇主，通知他们）
4.心跳(续约)：提供者定期通过http方式向Eureka刷新自己的状态
（类似工作人员要定期更新自己的状态给家政中心，如果超过时间间隔，那么就说明工作人员已经毁约了，家政中心即可删除该服务，否则即续约）

6.3.入门案例

6.3.1.编写EurekaServer（eureka——找到了）

接下来我们创建一个项目，启动一个EurekaServer：

1.选择依赖：
（只需导入eureka依赖即可而且版本也在父工程导入了，其他的都在父工程导入过了（mybatis，spring启动器等））

2.编写启动类（需要添加@EnableEurekaServer标识该类是eureka注册中心）
3.编写配置文件（因为启动类默认端口是8080，就和其他冲突了，所以要手动改掉端口号
4.启动程序
这里会报错，报一个eureka-client包的错误，可是导入的eureka-server依赖为什么会有eureka-client依赖呢
实际上，注册中心就像zookeeper一样，是有自己的集群的，因为如果注册中心自己挂了，那么全部服务都一起挂了，所以需要有自己的客户端（即类似家政中心自己内部的工作人员），所以它既是客户端又是服务端即相互注册，自己注册到自己上，而这里他的客户端并没有注册到自己上所以报错了
为client注册到eureka
错误写法：直接写url（注册eureka路径）

实际上，service-url我们要通过源码才能得知里面的数据结构是hashmap
而这个hashmap里面有默认的一对<key，value>
key是DEFAULT_ZONE，value是DEFAULT_URL
而这对<key，value>都是定义好了的
key默认值是"defaultZone"
value默认值是"http://localhost:8761"+DEFAULT_PREFIX
（eureka默认端口就是8761）
DEFAULT_PREFIX默认值是"eureka"
那么我们就要改下配置文件，将eureka注册路径配置好（配到自己的端口号上)
这时候刚启动的时候还是会报错，因为eureka还没完全启动完毕就开始注册会报错一次，然后等eureka完全启动后，eureka-client就能成功注册

还有两个注意事项

1.eureka-client服务名称问题（默认为UNKNOWN）
2.eureka-client访问域名问题（192.0.100并不是本地域名）

解决方法
1.方法名：通过配置spring：name
2.域名：通过配置开启自定义ip-aaddress（实际上把wifi断了就是本地了）

这时候就可以完成注册eureka-client了，然年访问eureka路径进入官网
就可以发现注册成功了，以及eureka当前的使用情况

6.3.2.将user-service注册到Eureka

注册服务，就是在服务上添加Eureka的客户端依赖，客户端代码会自动把服务注册到EurekaServer中。
(进行工作人员对注册中心的注册，这时候就不用引入服务端了，只是外部人员，只需客户端依赖即client）
1.我们在user-service-demo中添加Eureka客户端依赖：
2.在启动器（配置类）里加上eureka依赖
（其中这里可以直接指定使用Eureka客户端的依赖@EnableEurekaClient，但这个只能使用eureka了，但如果使用通用的@EnableDiscoveryClient，则可以兼容多种注册中心（如zookeeper等））
3.配置文件（加上eureka的注册路径，以及自己的服务名字）
4.运行（eureka成功注册）

6.3.3.消费者从Eureka获取服务

接下来我们修改consumer-demo，尝试从EurekaServer获取服务。

方法与消费者类似，只需要在项目中添加EurekaClient依赖，就可以通过服务名称来获取信息了！

过程重复就不再截图做演示了

到了最后一步，获取服务

第一种方式：动态获取Eureka

1.先通过自动注入，把DiscoveryClient（用来发现客户端里的服务）
2.通过调用DiscoveryClient的getInstance()方法通过id获得服务
（服务id是同样的，但实例是不同的，服务类似行业（类），实例类是员工（对象），所以一个增加服务可能有很多个实例，但服务id都是一样的，所以都是user-service作为参数但获得的可能多个实力就要用list保存）
3.通过list拿出实例得到对应的服务访问域名地址和端口号

6.4.Eureka详解

接下来我们详细讲解Eureka的原理及配置。

6.4.1.基础架构

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

服务注册中心

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

服务提供者

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

服务消费者

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

6.4.2.高可用的Eureka Server

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

服务同步

多个Eureka Server之间也会互相注册为服务，当服务提供者注册到Eureka Server集群中的某个节点时，该节点会把服务的信息同步给集群中的每个节点，从而实现数据同步。因此，无论客户端访问到Eureka Server集群中的任意一个节点，都可以获取到完整的服务列表信息。
而作为客户端，需要把信息注册到每个Eureka中：
（即每个Eureka都相互把自己的客户端服务注册到对方的服务端（之前是自己客户端注册到自己服务端），那么这样一个消费者调用自己的服务没有，那么就可以通过自己的客户端服务去访问另外一个Eureka查看是否有该服务（类似两个家政中心共享内部信息建立联系，一家家政中心没有客户需要的服务，即可通过该联系去找另一家家政中心，如果有就返回调用哪个服务的地址（即那个员工的联系方式）而客户就把全部家政中心都关注了但只找一个）

动手搭建高可用的EurekaServer

如果我们有两个Eureka，则每一个EurekaServer都需要注册到其他Eureka服务器中，例如端口分别为：10086和10087

1）我们修改原来的EurekaServer配置：
端口号为10087的Eureka，访问路径是端口号为10086的Eureka（其中如果先创建的是10087，当写上访问路径10086时启动会报错，因为还没创建10086的Eureka，等他创建完了即不会报错了

端口号为10086的Eureka，访问路径是端口号为10087的Eureka

消费者Customer的访问路径要把这两个都写上（因为你无法得知哪个注册中心会挂掉，如果只写一个就会也跟着挂了）

6.4.3.服务提供者

服务提供者要向EurekaServer注册服务，并且完成服务续约等工作。

服务注册

服务提供者在启动时，会检测配置属性中的：eureka.client.register-with-erueka=true参数是否正确，事实上默认就是true（正是因为这个参数是true，那么每次启动时都会对自己注册，但自己没有启动完所以报错，那么如果不想有这个报错可以改成false）。如果值确实为true，则会向EurekaServer发起一个Rest请求，并携带自己的元数据信息，Eureka Server会把这些信息保存到一个双层Map结构中。第一层Map的Key就是服务名称，第二层Map的key是服务的实例id。
第一层Map
key：服务id（USER-SERVICE，类似于类名）
value：则是各个实例的id（localhoast:user-service:8081，每个实例都有自己独特的id，由域名+用户名+端口号组成，类似于对象名）
第二层Map
key：就是第一层Map的value，即上面这个各个实例的id
value：就是各个实例本身（每个实例有自己的属性等，就类似于对象本身）

服务续约

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

eureka:instance:lease-expiration-duration-in-seconds: 90lease-renewal-interval-in-seconds: 30lease-renewal-interval-in-seconds：服务续约(renew)的间隔，默认为30秒
lease-expiration-duration-in-seconds：服务失效时间，默认值90秒

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

但是在开发时，这个值有点太长了，经常我们关掉一个服务，会发现Eureka依然认为服务在活着。所以我们在开发阶段可以适当调小。

eureka:instance:lease-expiration-duration-in-seconds: 10 # 10秒即过期lease-renewal-interval-in-seconds: 5 # 5秒一次心跳

6.4.4.服务消费者

获取服务列表

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

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

生产环境中，我们不需要修改这个值。

但是为了开发环境下，能够快速得到服务的最新状态，我们可以将其设置小一点。

6.4.5.失效剔除和自我保护

失效剔除

有些时候，我们的服务提供方并不一定会正常下线，可能因为内存溢出、网络故障等原因导致服务无法正常工作。Eureka Server需要将这样的服务剔除出服务列表。因此它会开启一个定时任务，每隔60秒对所有失效的服务（超过90秒未响应）进行剔除。

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

这个会对我们开发带来极大的不变，你对服务重启，隔了60秒Eureka才反应过来。开发阶段可以适当调整，比如10S

自我保护

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

这是触发了Eureka的自我保护机制。当一个服务未按时进行心跳续约时，Eureka会统计最近15分钟心跳失败的服务实例的比例是否超过了85% 在生产环境下，因为网络延迟等原因（比如30S的时候服务进行心跳续约，但由于网络问题延迟了一点，导致这个服务就崩了，那么Eureka就会统计这些失败的次数如果达到总次数15%，那么就说明这段时间的网络状况不好，就会保护起来）心跳失败实例的比例很有可能超标，但是此时就把服务剔除列表并不妥当，因为服务可能没有宕机。Eureka就会把当前实例的注册信息保护起来，不予剔除。生产环境下这很有效，保证了大多数服务依然可用。

但是这给我们的开发带来了麻烦，因此开发阶段我们都会关闭自我保护模式：

eureka:server:enable-self-preservation: false # 关闭自我保护模式（缺省为打开）eviction-interval-timer-in-ms: 1000 # 扫描失效服务的间隔时间（缺省为60*1000ms）

7.负载均衡Robbin

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

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

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

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

什么是Ribbon：

接下来，我们就来使用Ribbon实现负载均衡。

7.1.启动两个服务实例

首先我们启动两个user-service实例，一个8081，一个8082。
（两个实例，来演示负载均衡）
直接复制一个
成功启动两个user-service

customer引用Ribbon依赖（因为是他来接收user-service的集群并调用）

方案一：默认方式轮询

方案二
现在启动类中加上负载均衡的注解@loadBalanced
那么这个RestTemplate发出去的请求（其中这个请求的路径就可以是之前要找服务的请求路径）就会被负载均衡拦截下来，在通过这个请求路径去做了上面一系列的操作（即先得到集群，在通过负载均衡得到单个实例），得到对应的实例请求路径覆盖上去
以上负载均衡原理：
查看源码：
负载均衡拦截器（会拦截一切RestTemplate请求）
然后就会执行这个方法（这个地址就是我们一开始设置的，就依靠这个集群地址（类名）去找一个服务实例地址回来）
再通过getHost取出服务id（即集群，也就是类似的类名）
再通过负载均衡器的客户端（里面有负载均衡的客户端，里面有个负载均衡器）

我们在跟进execute()方法，里面一个内置的负载均衡器（IloadBalancer）然后通过这个负载均衡器就能得到一个实例，并返回这个实例的地址
第一次是8082，第二次就是8081（符合轮询负载均衡）

getServer方法轮询底层实现
继续跟进chooseServer()
发现是一个接口，那么就要找这个方法的实现（即重载），有三个
我们通过调试跟踪到，是BasicCounter
再跟进rule（负载均衡规则）
我们发现IRule类定义了很多规则，而这里默认是DEFAULT，而上面定义的DEFAULT就是RoundRobinRule，这个就是众多规则中的轮询规则
判断完是轮询后就调用轮询算法（参数就是能获得的服务实例集合，还有长度）
轮询算法就是通过一个自增长的变量，不断取余长度，那么每次得到的数都是一个下标，就能取地list中的某一个元素
SpringBoot也帮我们提供了修改负载均衡规则的配置入口：

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

格式是：

{服务名称}.ribbon.NFLoadBalancerRuleClassName，值就是IRule的实现类。

7.5.重试机制

Eureka的服务治理强调了CAP原则中的AP，即可用性和可靠性。它与Zookeeper这一类强调CP（一致性，可靠性）的服务治理框架最大的区别在于：

Eureka为了实现更高的服务可用性，牺牲了一定的一致性，极端情况下它宁愿接收故障实例也不愿丢掉健康实例，正如我们上面所说的自我保护机制。

但是，此时如果我们调用了这些不正常的服务，调用就会失败，从而导致其它服务不能正常工作！这显然不是我们愿意看到的。

我们现在关闭一个user-service实例：

因为服务剔除的延迟，consumer并不会立即得到最新的服务列表，此时再次访问你会得到错误提示：

但是此时，8081服务其实是正常的。

因此Spring Cloud 整合了Spring Retry 来增强RestTemplate的重试能力，当一次服务调用失败后，不会立即抛出一次，而是再次重试另一个服务。

只需要简单配置即可实现Ribbon的重试：

spring:cloud:loadbalancer:retry:enabled: true # 开启Spring Cloud的重试功能
user-service:ribbon:ConnectTimeout: 250 # Ribbon的连接超时时间ReadTimeout: 1000 # Ribbon的数据读取超时时间OkToRetryOnAllOperations: true # 是否对所有操作都进行重试MaxAutoRetriesNextServer: 1 # 切换实例的重试次数MaxAutoRetries: 1 # 对当前实例的重试次数

根据如上配置，当访问到某个服务超时后，它会再次尝试访问下一个服务实例，如果不行就再换一个实例，如果不行，则返回失败。切换次数取决于MaxAutoRetriesNextServer参数的值

引入spring-retry依赖

<dependency><groupId>org.springframework.retry</groupId><artifactId>spring-retry</artifactId>
</dependency>

我们重启user-consumer-demo，测试，发现即使user-service2宕机，也能通过另一台服务实例获取到结果！

Day2：SpringCloud入门学习——传智播客学习笔记【微服务电商】相关推荐

Day7：Vue入门学习——传智播客学习笔记【微服务电商】
本节依旧是前端内容,但还是了解一下基础的入门知识学习目标会创建Vue实例,知道Vue的常见属性会使用Vue的生命周期的钩子函数会使用vue常见指令会使用vue计算属性和watch监控会编写 ...
php 传智播客学习内容
第一阶段:(PHP+MySQL核心编程) 课程名称阶段课程课程内容学习目标 PHP+MySQL核心编程(21天) PHP基本语法加强 Apache--directory配置段一个IP和多个域名 ...
武汉校区南非“留学生”：来传智播客学习是“独特的机会”
随着社会的飞速发展.进步,国家对于"高精尖"IT技术开发人才的需求也愈加旺盛. 肩负"为莘莘学子改变命运而讲课,为万千学生少走弯路而著书"使命的传智播客,在IT ...
传智播客学习之就业班有感
今天终于走入了就业班的课堂,听到这个班级的名字--"就业班",似乎有些紧张,虽然是四个半月后的事情,但是当走进教室的那一霎那,有点窒息的感觉,教室的学习气氛比预热班更浓厚了,早上八 ...
传智播客学习和生活总结
在传智播客三个月的学习结束了.真的,服了.传智果然是名不虚传. 这三个月的学习,累的我要死啊.天天8点起床,在道边买个鸡蛋饼,人多的还得排队.8:50到教室,开电脑,吃早饭.9点准时上课.中午下课基本 ...
传智oracle,传智播客Oracle笔记
Oracle笔记 oracle 传智播客_ORACLE经典视频教程笔记(2008-09-09 15:32:34) 标签:it 分类:Oracle 1.3个默认用户 sys chang_on_inst ...
传智播客学习之day59-mybatis初步
工具和环境:apache-maven-3.2.3 eclipse_luna_4.4.0_winX86 1.配置环境 1.用提供的eclipse版本4.4.1 2.在eclipse界面打开window- ...
jQuery基础(传智播客学习笔记)
JQuery 基础: 1. 概念: 一个JavaScript框架.简化JS开发* jQuery是一个快速.简洁的JavaScript框架,是继Prototype之后又一个优秀的JavaScript代码 ...
传智播客学习之Spring——装配Bean
昨天和大家分享了Spring的起源和作用,以及它所运用到得几大模块,算是基本对Spring有了一个整体的认识,并通过了一个小实例让我们体会了以下spring,今天详细和大家分享一下装配Bean的相关问 ...