【模块九】Spring全家桶篇SpringCloud篇☞参考答案
- 简介
1、是什么？
SpringCloud是基于SpringBoot基础之上开发的微服务框架，SpringCloud是一套目前非常完整的微服务解决方案框架，其内容包含服务治理、注册中心、配置管理、断路器、智能路由、微代理、控制总线、全局锁、分布式会话等。
2、为什么选择SpringCloud？
因为SpringCloud出现,对微服务技术提供了非常大的帮助，因为SpringCloud 提供了一套完整的微服务解决方案，不像其他框架只是解决了微服务中某个问题。
- Spring Boot和Spring Cloud的区别
SpringBoot是一个快速开发框架，能够帮助我们快速整合第三方框架，完全采用注解化，简化XML配置，最终以Java应用程序执行。
是单体。
SpringCloud是目前一套完整微服务解决框架，功能非常强大。微服务通讯是以Http+Json(Restful风格),轻量级进行数据传输。
是将各个单体统筹起来综合管理的分布式的服务治理框架，可以理解为是将多个单体统筹起来的整体，并且这个整体提供了一套开发过程中这些多个单体的问题的解决方案。
打个比方：将SpringBoot比作是医院的一个个科室，SpringCloud则就是医院。医院不仅仅是一个个科室的简单叠加，还能为某个科室出现问题，协调其他部门解决问题。
关系：
SpringBoot实现快速开发,Web组件默认集成SpringMVC
SpringCloud依赖于SpringBoot实现微服务，使用SpringMVC编写微服务接口。
总结：
1.Spring boot可以离开Spring Cloud独立使用开发项目，但是Spring Cloud离不开Spring boot
2.SpringBoot+SpringCloud实现微服务开发
- Spring Cloud和Dubbo的区别
本质区别：
dubbo 是基于RPC远程过程调用
cloud 是基于Http的Rest API调用
Dubbo使用了第三方的ZooKeeper作为其底层的注册中心,实现服务的注册和发现,SpringCloud使用Spring Cloud Netflix Eureka实现注册中心,当然SpringCloud也可以使用ZooKeeper实现,但一般我们不会这样做.
- Spring Cloud核心组件及其作用
服务治理：Eureka
客户端负载均衡：Ribbon
容错保护：Hystrix
声明式服务调用：Fegin
网关服务：Zuul
配置中心：Config
消息总线：Bus
消息驱动：Strem
链路跟踪：Sleuth
- Eureka注册中心
- CAP理论
所谓的CAP：C:Consistency一致性 A:Availability可用性 P:Partition tolerance分区容错性
一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性P在是分布式系统中必须要保证的,因此只能在A和C之间进行权衡
zookeeper遵守CP
当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用。也就是说,服务注册功能对一致性的要求要高于可用性。
但是zookeeper会出现这样一种情况,当 master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。
问题在于,选举leader的时间太长,30~120s,目选举期间整个zookeeper集群都是不可用的,这就导致在选举期间注册服务瘫痪。
在云部署的环境下,因网络问题使得zookeeper 集群失去 master节点是较大概率会发生的事,虽然服务能够最终恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的。
或许这个回答太过于抽象 用一种其他说法来说 就是 ：
当有一个zookeeper挂了,那其他的zookeeper会进行一次选举(强一致性 ： 我一定要保持数据一致性）,而在此选举期间zookeeper是不可用的,而当前 有用户正在使用,用户就不爽了
eureka遵守AP
Eureka:看明白了这一点,因此在设计时就优先保证可用性。
Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。
而Eureka的客户端在向某个Eureka注册时,如果发现连接失败,则会自动切换至其它节点,
只要有一台Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的不保证强一致性)。
除此之外, Eureka还有一种自我保护机制,如果在15分钟内超过85%的节点都没有正常的心跳,那么 Eurekas就认为客户端与注册中心出现了网络故障,此时会出现以下几种情况:
1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
2. Eureka仍然能够接受新服务的注册和査询请求,但是不会被同步到其它节点上(即保证当前节点依然可用)
3.当网络稳定时,当前实例新的注册信息会被同步到其它节点中
因此, Eureka可以很好的应对因网络故障导致部分节点失去联系的情況,而不会像 zookeeper那样使整个注册服务瘫痪。
2．Eureka和Zookeeper的区别
1.ZooKeeper保证的是CP,Eureka保证的是AP
ZooKeeper在选举期间注册服务瘫痪,虽然服务最终会恢复,但是选举期间不可用的
Eureka各个节点是平等关系,只要有一台Eureka就可以保证服务可用,而查询到的数据并不是最新的。
自我保护机制会导致：
Eureka不再从注册列表移除因长时间没收到心跳而应该过期的服务
Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其他节点(高可用)
当网络稳定时,当前实例新的注册信息会被同步到其他节点中(最终一致性)
Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像ZooKeeper一样使得整个注册系统瘫痪
2.ZooKeeper有Leader和Follower角色,Eureka各个节点平等
3.ZooKeeper采用过半数存活原则,Eureka采用自我保护机制解决分区问题
4.Eureka本质上是一个工程,而ZooKeeper只是一个进程
- Eureka基本原理
服务启动后向Eureka注册，Eureka Server会将注册信息向其他Eureka Server进行同步。
当消费者调用提供者，则向服务注册中心获取服务提供者地址，然后将服务提供者地址缓存到本地，下次再调用的时候，直接从本地缓存中读取，完成一次调用。
当服务注册中心EurekaServer检测到提供者，由于宕机、网络原因等不可用时，则在服务注册中心将服务置为Down状态，并把当前服务提供者的状态向订阅者发布，订阅过的消费者更新本地缓存。
服务提供者在启动后，周期性(默认30秒)向Eureka Server发送心跳，以证明当前服务时可用状态。Eureka Server在一定时间(默认90秒)未收到客户端的心跳，则认为服务宕机，注销该实例。
总结：选择Eureka作为服务注册中心更好，因为注册服务更重要的是可用性，我们可以接受短时间内达不到一致性的状况。
- Ribbon负载均衡
1. 简介
2. Ribbon与Nginx区别
Nginx：服务器端负载均衡
nginx是客户端所有请求统一交给nginx，由nginx进行实现负载均衡请求转发，属于服务器端负载均衡。
Ribbon：客户端负载均衡
ribbon是从eureka注册中心服务器端上获取服务注册信息列表，缓存到本地JVM中，然后在本地实现轮询负载均衡策略实现RPC远程调用技术进行接口调用。
3. 应用场景的区别
Nginx适合于服务器端实现负载均衡， 比如Tomcat、Jetty ;
Ribbon适合于在微服务中RPC远程调用实现本地服务负载均衡，比如Dubbo、SpringCloud。
- Hystrix熔断器
1．熔断器产生背景
为了解决某个微服务的调用响应时间过长或者不可用进而占用越来越多的系统资源引起雪崩效应，而采取的服务熔断和服务降级策略。
2．熔断器策略
请求熔断
服务降级
服务熔断就是相当于我们电闸的保险丝,一旦发生服务雪崩的,就会熔断整个服务,通过维护一个自己的线程池,当线程达到阈值的时候就启动服务降级,如果其他请求继续访问就直接返回fallback的默认值
3．实际开发中怎么用
4．重要参数说明
- Feign客户端调用工具
1. 简介
feign 整合了rabbion 和 hytrix,完美兼容了spring mvc,使服务调用变得简单。
2. Ribbon与Fegin的区别
Ribbon和Feign都是用于调用其他服务的，不过方式不同。
1.启动类使用的注解不同，Ribbon用的是@RibbonClient，Feign用的是@EnableFeignClients。
2.服务的指定位置不同，Ribbon是在@RibbonClient注解上声明，Feign则是在定义抽象方法的接口中使用@FeignClient声明。
3.调用方式不同，Ribbon需要自己构建http请求，模拟http请求然后使用RestTemplate发送给其他服务，步骤相当繁琐。
Feign则是在Ribbon的基础上进行了一次改进，采用接口的方式，将需要调用的其他服务的方法定义成抽象方法即可，
不需要自己构建http请求。不过要注意的是抽象方法的注解、方法签名要和提供服务的方法完全一致。
Spring Cloud中支持两种客户端调用工具：
1.是Ribbon中的RestTemplate
2.是Feign
Ribbon :是一个基于 HTTP 和 TCP 客户端的负载均衡器
Feign: Spring Cloud Netflix 的微服务都是以 HTTP 接口的形式暴露的，所以可以用 Apache 的 HttpClient 或 Spring 的 RestTemplate 去调用,
是在Ribbon的基础上进一步进行Http封装的Http客户端，它是一种以接口+注解 形式实现微服务调用的声明式客户端调用工具。
它还整合了Spring Cloud Ribbon和Spring Cloud Hystrix。
特别指出：可以查看spring-cloud-netflix-core的jar包层级结构，清晰看出Netflix、Feign和Ribbon的关系
总结：
Ribbon的RestTemplate接口调用方式，一般不用；
Feign声明式接口调用方式，建议使用。
- Zuul服务网关
1.为什么需要网关？
①.安全性：
1.最主要的一点是网关可以将所有服务的API接口统一聚合，并统一对外暴露。外界系统调用API接口时，都是由网关对外暴露的API接口，外界系统不需要知道微服务系统中各个服务之间相互调用的复杂性。微服务系统也保护了系统内部微服务单元的API接口，防止其被外部直接调用，导致服务的敏感信息泄露。
2.网关可以做用户身份认证和权限认证，防止非法请求操作API接口，对服务器起保护作用。
②.性能：
1.zuul、ribbon、eureka相结合，可以实现路由和负载均衡的功能，zuul可以将请求流量按照默认轮询策略分发到集群状态下的不同服务实例。
作用：
1.可以实现负载均衡、路由转发、实时日志输出、权限控制、系统监控等
2.可以实现流量监控，在高流量的情况下，对服务进行降级
2.如何使用Zuul实现请求拦截从而实现身份验证？
Spring Cloud组件开发三板斧：pom.xml、application.properties、代码业务
第一步：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zuul</artifactId>
</dependency>
第二步：
第三步：实现ZuulFilter抽象类，重写run()方法
public class LoginFilter extends ZuulFilter {
@Override
public Object run() {
RequestContext ctx = RequestContext.getCurrentContext();
HttpServletRequest request = ctx.getRequest();
//编写业务逻辑：实现身份验证
return null;
}
@Override
public boolean shouldFilter() {// 是否执行该过滤器，此处为true，说明需要过滤
return true;
}
@Override
public int filterOrder() {// 优先级为0，数字越大，优先级越低
return 100000;
}
@Override
public String filterType() {
return "error";// 在请求被处理之后，会进入该过滤器
}
}
- 其他组件
微服务之配置中心：Config
微服务之消息总线：Bus
微服务之消息驱动：Strem
微服务之链路跟踪：Sleuth
- application.properties文件中各组件配置有哪些参数及其作用
十二、RESTful
1．是什么
实质：一种网络应用程序的设计风格和开发方式
REST：Representational State Transfer，REST倾向于用更加简单轻量的方法设计和实现。
REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。
2．特点
1、每一个URI代表一种资源；
2、客户端使用GET、POST、PUT、DELETE，四个表示操作方式的动词对服务端资源进行操作，实现“表现层状态转化”
GET用来获取资源，
POST用来新建资源（也可以用于更新资源），
PUT用来更新资源，
DELETE用来删除资源；
3、通过操作资源的表现形式来操作资源；
4、资源的表现形式是XML或者HTML；
5、客户端与服务端之间的交互在请求之间是无状态的，从客户端到服务端的每个请求都必须包含理解请求所必需的信息。
3．RESTful架构
①．RESTful架构是对MVC架构改进后所形成的一种架构，通过使用事先定义好的接口与不同的服务联系起来。在RESTful架构中，浏览器使用POST，DELETE，PUT和GET四种请求方式分别对指定的URL资源进行增删改查操作。因此，RESTful是通过URI实现对资源的管理及访问，具有扩展性强、结构清晰的特点。
②．RESTful架构将服务器分成前端服务器和后端服务器两部分，前端服务器为用户提供无模型的视图；后端服务器为前端服务器提供接口。浏览器向前端服务器请求视图，通过视图中包含的AJAX函数发起接口请求获取模型。
③.项目开发引入RESTful架构，利于团队并行开发。在RESTful架构中，将多数HTTP请求转移到前端服务器上，降低服务器的负荷，使视图获取后端模型失败也能呈现。但RESTful架构却不适用于所有的项目，当项目比较小时无需使用RESTful架构，项目变得更加复杂。
4. REST vs RPC
在做 API 服务器开发时，很多人都会遇到这个问题 —— 选择 REST 还是 RPC。RPC 相比 REST 的优点主要有 3 点：
1、RPC+Protobuf 采用的是 TCP 做传输协议，REST 直接使用 HTTP 做应用层协议，这种区别导致 REST 在调用性能上会比 RPC+Protobuf 低
2、RPC 不像 REST 那样，每一个操作都要抽象成对资源的增删改查，在实际开发中，有很多操作很难抽象成资源，比如登录操作。所以在实际开发中并不能严格按照 REST 规范来写 API，RPC 就不存在这个问题
3、RPC 屏蔽网络细节、易用，和本地调用类似
但是 REST 相较 RPC 也有很多优势：
1、轻量级，简单易用，维护性和扩展性都比较好
2、REST 相对更规范，更标准，更通用，无论哪种语言都支持 HTTP 协议，可以对接外部很多系统，只要满足 HTTP 调用即可，更适合对外，RPC 会有语言限制，不同语言的 RPC 调用起来很麻烦
3、JSON 格式可读性更强，开发调试都很方便
4、在开发过程中，如果严格按照 REST 规范来写 API，API 看起来更清晰，更容易被大家理解
其实业界普遍采用的做法是，内部系统之间调用使用 RPC，对外调用使用 REST，因为内部系统之间可能调用很频繁，需要 RPC 的高性能支撑。对外用 REST 更易理解，更通用些。
以上是 【模块九】Spring全家桶篇SpringCloud篇☞参考答案 的全部内容， 来源链接： utcz.com/z/512653.html
