springboot+springcloud相关问题

什么是springboot

1.用来简化spring应用的初始搭建以及开发过程 使用特定的方式来进行配置（properties或yml文件）

2.创建独立的spring引用程序 main方法运行

3.创建独立的spring引用程序 main方法运行

4.简化maven配置

5.自动配置spring添加对应功能starter自动化配置

springboot常用的starter有哪些
1. spring-boot-starter-web 嵌入tomcat和web开发需要servlet与jsp支持
2. spring-boot-starter-data-jpa 数据库支持
3. spring-boot-starter-data-redis redis数据库支持
4. spring-boot-starter-data-solr solr支持 
5. mybatis-spring-boot-starter 第三方的mybatis集成starter

springboot自动配置的原理
1.在spring程序main方法中 添加@SpringBootApplication或者@EnableAutoConfiguration
2.会自动去maven中读取每个starter中的spring.factories文件  该文件里配置了所有需要被创建spring容器
中的bean

springboot读取配置文件的方式
 springboot默认读取配置文件为application.properties或者是application.yml

springboot集成mybatis的过程
添加mybatis的starter maven依赖
                

                        org.mybatis.spring.boot

                        mybatis-spring-boot-starter

                        1.2.0

                

 在mybatis的接口中 添加@Mapper注解
 在application.yml配置数据源信息

springboot如何添加【修改代码】自动重启功能


	
		org.springframework.boot
		spring-boot-devtools
		true
	


什么是微服务

 以前的模式是 所有的代码在同一个工程中 部署在同一个服务器中 同一个项目的不同模块不同功能互相
抢占资源

  微服务 将工程根据不同的业务规则拆分成微服务 微服务部署在不同的机器上 服务之间进行相互调用

  Java微服务的框架有 dubbo（只能用来做微服务），spring cloud（提供了服务的发现，断路器等）

springcloud如何实现服务的注册和发现

1.服务在发布时 指定对应的服务名（服务名包括了IP地址和端口） 将服务注册到注册中心（eureka
或者zookeeper）

2. 这一过程是springcloud自动实现 只需要在main方法添加@EnableDisscoveryClient  同一个服务
修改端口就可以启动多个实例

3. 调用方法：传递服务名称通过注册中心获取所有的可用实例 通过负载均衡策略调用（ribbon和feign）
对应的服务

ribbon和feign区别

1.Ribbon添加maven依赖 spring-starter-ribbon 使用@RibbonClient(value="服务名称") 
使用RestTemplate调用远程服务对应的方法

2.feign添加maven依赖 spring-starter-feign 服务提供方提供对外接口 调用方使用 在接口上
使用@FeignClient("指定服务名")

Ribbon和Feign的区别：
Ribbon和Feign都是用于调用其他服务的，不过方式不同。
  1.启动类使用的注解不同，Ribbon用的是@RibbonClient，Feign用的是@EnableFeignClients。
  2.服务的指定位置不同，Ribbon是在@RibbonClient注解上声明，Feign则是在定义抽象方法的接口中
使用@FeignClient声明。
  3.调用方式不同，Ribbon需要自己构建http请求，模拟http请求然后使用RestTemplate发送给其他
服务，步骤相当繁琐。Feign则是在Ribbon的基础上进行了一次改进，采用接口的方式，将需要调用的
其他服务的方法定义成抽象方法即可，不需要自己构建http请求。不过要注意的是抽象方法的注解、
方法签名要和提供服务的方法完全一致。

springcloud断路器的作用
  当一个服务调用另一个服务由于网络原因或者自身原因出现问题时 调用者就会等待被调用者的响应当更多
的服务请求到这些资源时导致更多的请求等待 这样就会发生连锁效应（雪崩效应） 断路器就是解决这一问题

Spring Cloud底层原理

概述

毫无疑问，Spring Cloud是目前微服务架构领域的翘楚，无数的书籍博客都在讲解这个技术。不过大多数讲解
还停留在对Spring Cloud功能使用的层面，其底层的很多原理，很多人可能并不知晓。

实际上，Spring Cloud是一个全家桶式的技术栈，包含了很多组件。也就是Eureka、Ribbon、
Feign、Hystrix、Zuul这几个组件。

一、业务场景介绍

假设咱们现在开发一个电商网站，要实现支付订单的功能，流程如下：

1.创建一个订单之后，如果用户立刻支付了这个订单，我们需要将订单状态更新为“已支付”
2.扣减相应的商品库存
3.通知仓储中心，进行发货
4.给用户的这次购物增加相应的积分

针对上述流程，我们需要有订单服务、库存服务、仓储服务、积分服务。整个流程的大体思路如下：
1.用户针对一个订单完成支付之后，就会去找订单服务，更新订单状态
2.订单服务调用库存服务，完成相应功能
3.订单服务调用仓储服务，完成相应功能
4.订单服务调用积分服务，完成相应功能

至此，整个支付订单的业务流程结束

下图这张图，清晰表明了各服务间的调用过程：

有了业务场景之后，咱们就一起来看看Spring Cloud微服务架构中，这几个组件如何相互协作，各自发挥的
作用以及其背后的原理。

二、Spring Cloud核心组件：Eureka

订单服务想要调用库存服务、仓储服务，或者是积分服务，怎么调用？

1.订单服务压根儿就不知道人家库存服务在哪台机器上啊！他就算想要发起一个请求，都不知道发送给谁，
有心无力！

2.这时候，就轮到Spring Cloud Eureka出场了。Eureka是微服务架构中的注册中心，专门负责服务的注册
与发现。

库存服务、仓储服务、积分服务中都有一个Eureka Client组件，这个组件专门负责将这个服务的信息注册
到Eureka Server中。说白了，就是告诉Eureka Server，自己在哪台机器上，监听着哪个端口。而
Eureka Server是一个注册中心，里面有一个注册表，保存了各服务所在的机器和端口号

订单服务里也有一个Eureka Client组件，这个Eureka Client组件会找Eureka Server问一下：库存服务在
哪台机器啊？监听着哪个端口啊？仓储服务呢？积分服务呢？然后就可以把这些相关信息从Eureka Server的
注册表中拉取到自己本地缓存起来。

这时如果订单服务想要调用库存服务，不就可以找自己本地的Eureka Client问一下库存服务在哪台机器？
监听哪个端口吗？收到响应后，紧接着就可以发送一个请求过去，调用库存服务扣减库存的那个接口！同理，
如果订单服务要调用仓储服务、积分服务，也是如法炮制。

总结一下：
1.Eureka Client：负责将这个服务的信息注册到Eureka Server中
2.Eureka Server：注册中心，里面有一个注册表，保存了各个服务所在的机器和端口号

三、Spring Cloud核心组件：Feign

现在订单服务确实知道库存服务、积分服务、仓库服务在哪里了，同时也监听着哪些端口号了。但是新问题又
来了：难道订单服务要自己写一大堆代码，跟其他服务建立网络连接，然后构造一个复杂的请求，接着发送请求
过去，最后对返回的响应结果再写一大堆代码来处理吗？

看完上面的代码什么感觉？是不是感觉整个世界都干净了，又找到了活下去的勇气！没有底层的建立连接、
构造请求、解析响应的代码，直接就是用注解定义一个 FeignClient接口，然后调用那个接口就可以了。
人家Feign Client会在底层根据你的注解，跟你指定的服务建立连接、构造请求、发起靕求、获取响应、
解析响应，等等。这一系列脏活累活，人家Feign全给你干了。

Feign的一个关键机制就是使用了动态代理。咱们一起来看看下面的图，结合图来分析：
1.首先，如果你对某个接口定义了@FeignClient注解，Feign就会针对这个接口创建一个动态代理
2.接着你要是调用那个接口，本质就是会调用 Feign创建的动态代理，这是核心中的核心
3.Feign的动态代理会根据你在接口上的@RequestMapping等注解，来动态构造出你要请求的服务的地址
4.最后针对这个地址，发起请求、解析响应

四、Spring Cloud核心组件：Ribbon

说完了Feign，还没完。现在新的问题又来了，如果人家库存服务部署在了5台机器上，如下所示：

192.168.169:9000

192.168.170:9000

192.168.171:9000

192.168.172:9000

192.168.173:9000

这下麻烦了！人家Feign怎么知道该请求哪台机器呢？

这时Spring Cloud Ribbon就派上用场了。Ribbon就是专门解决这个问题的。它的作用是负载均衡，会帮你在
每次请求时选择一台机器，均匀的把请求分发到各个机器上

Ribbon的负载均衡默认使用的最经典的Round Robin轮询算法。这是啥？简单来说，就是如果订单服务对库存
服务发起10次请求，那就先让你请求第1台机器、然后是第2台机器、第3台机器、第4台机器、第5台机器，接着
再来—个循环，第1台机器、第2台机器。。。以此类推。

 此外，Ribbon是和Feign以及Eureka紧密协作，完成工作的，具体如下：
1.首先Ribbon会从 Eureka Client里获取到对应的服务注册表，也就知道了所有的服务都部署在了哪些机器
上，在监听哪些端口号。
2.然后Ribbon就可以使用默认的Round Robin算法，从中选择一台机器
3.Feign就会针对这台机器，构造并发起请求。

对上述整个过程，再来一张图，帮助大家更深刻的理解：

五、Spring Cloud核心组件：Hystrix

在微服务架构里，一个系统会有很多的服务。以本文的业务场景为例：订单服务在一个业务流程里需要调用三个
服务。现在假设订单服务自己最多只有100个线程可以处理请求，然后呢，积分服务不幸的挂了，每次订单服务
调用积分服务的时候，都会卡住几秒钟，然后抛出—个超时异常。

咱们一起来分析一下，这样会导致什么问题？

1.如果系统处于高并发的场景下，大量请求涌过来的时候，订单服务的100个线程都会卡在请求积分服务这块。
导致订单服务没有一个线程可以处理请求

2.然后就会导致别人请求订单服务的时候，发现订单服务也挂了，不响应任何请求了

上面这个，就是微服务架构中恐怖的服务雪崩问题，如下图所示：

如上图，这么多服务互相调用，要是不做任何保护的话，某一个服务挂了，就会引起连锁反应，导致别的服务
也挂。比如积分服务挂了，会导致订单服务的线程全部卡在请求积分服务这里，没有一个线程可以工作，瞬间
导致订单服务也挂了，别人请求订单服务全部会卡住，无法响应。

但是我们思考一下，就算积分服务挂了，订单服务也可以不用挂啊！为什么？

我们结合业务来看：支付订单的时候，只要把库存扣减了，然后通知仓库发货就OK了

如果积分服务挂了，大不了等他恢复之后，慢慢人肉手工恢复数据！为啥一定要因为一个积分服务挂了，
就直接导致订单服务也挂了呢？不可以接受！

现在问题分析完了，如何解决？

Hystrix是隔离、熔断以及降级的一个框架。啥意思呢？说白了，Hystrix会搞很多个小小的线程池，比如订单
服务请求库存服务是一个线程池，请求仓储服务是一个线程池，请求积分服务是一个线程池。每个线程池里的
线程就仅仅用于请求那个服务。

打个比方：现在很不幸，积分服务挂了，会咋样？

当然会导致订单服务里的那个用来调用积分服务的线程都卡死不能工作了啊！但是由于订单服务调用库存服务、
仓储服务的这两个线程池都是正常工作的，所以这两个服务不会受到任何影响。

这个时候如果别人请求订单服务，订单服务还是可以正常调用库存服务扣减库存，调用仓储服务通知发货。
只不过调用积分服务的时候，每次都会报错。但是如果积分服务都挂了，每次调用都要去卡住几秒钟干啥呢？
有意义吗？当然没有！所以我们直接对积分服务熔断不就得了，比如在5分钟内请求积分服务直接就返回了，
不要去走网络请求卡住几秒钟，这个过程，就是所谓的熔断！

那人家又说，兄弟，积分服务挂了你就熔断，好歹你干点儿什么啊！别啥都不干就直接返回啊？没问题，咱们
就来个降级：每次调用积分服务，你就在数据库里记录一条消息，说给某某用户增加了多少积分，因为积分服务
挂了，导致没增加成功！这样等积分服务恢复了，你可以根据这些记录手工加一下积分。这个过程，就是所谓的
降级。

为帮助大家更直观的理解，接下来用一张图，梳理一下Hystrix隔离、熔断和降级的全流程：

六、Spring Cloud核心组件：Zuul

Zuul，也就是微服务网关。这个组件是负责网络路由的。不懂网络路由？行，那我给你说说，如果没有Zuul的
日常工作会怎样？

假设你后台部署了几百个服务，现在有个前端兄弟，人家请求是直接从浏览器那儿发过来的。打个比方：人家要
请求一下库存服务，你难道还让人家记着这服务的名字叫做inventory-service？部署在5台机器上？就算人家
肯记住这一个，你后台可有几百个服务的名称和地址呢？难不成人家请求一个，就得记住一个？你要这样玩儿，
那真是友谊的小船，说翻就翻！

上面这种情况，压根儿是不现实的。所以一般微服务架构中都必然会设计一个网关在里面，像android、ios、
pc前端、微信小程序、H5等等，不用去关心后端有几百个服务，就知道有一个网关，所有请求都往网关走，
网关会根据请求中的一些特征，将请求转发给后端的各个服务。

而且有一个网关之后，还有很多好处，比如可以做统一的降级、限流、认证授权、安全，等等。

七、总结：

最后再来总结一下，上述几个Spring Cloud核心组件，在微服务架构中，分别扮演的角色：

1.Eureka：各个服务启动时，Eureka Client都会将服务注册到Eureka Server，并且Eureka Client还可以
反过来从Eureka Server拉取注册表，从而知道其他服务在哪里
2.Ribbon：服务间发起请求的时候，基于Ribbon做负载均衡，从一个服务的多台机器中选择一台
3.Feign：基于Feign的动态代理机制，根据注解和选择的机器，拼接请求URL地址，发起请求
4.Hystrix：发起请求是通过Hystrix的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的
隔离，避免了服务雪崩的问题
5.Zuul：如果前端、移动端要调用后端系统，统一从Zuul网关进入，由Zuul网关转发请求给对应的服务

通过一个电商业务场景，阐述了Spring Cloud微服务架构几个核心组件的底层原理。

我们将Spring Cloud的5个核心组件通过一张图串联起来，再来直观的感受一下其底层的架构原理：

Spring Cloud

什么是Spring Cloud？

一个生命周期短暂的微服务框架，用于快速构建执行有限数据处理的应用程序。

使用Spring Cloud有什么优势？

使用Spring Boot开发分布式微服务时，我们面临以下问题
1.与分布式系统相关的复杂性-这种开销包括网络问题，延迟开销，带宽问题，安全问题。
2.服务发现-服务发现工具管理群集中的流程和服务如何查找和互相交谈。它涉及一个服务目录，
在该目录中注册服务，然后能够查找并连接到该目录中的服务。
3.冗余-分布式系统中的冗余问题。
4.负载平衡 --负载平衡改善跨多个计算资源的工作负荷
5.性能-问题 由于各种运营开销导致的性能问题。
6.部署复杂性-Devops技能的要求。

服务注册和发现是什么意思？Spring Cloud如何实现？

Eureka服务注册和发现可以在这种情况下提供帮助。由于所有服务都在Eureka服务器上注册并通过调用Eureka
服务器完成查找，因此无需处理服务地点的任何更改和处理。

负载平衡的意义什么？
1.负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间并避免任何单一资源的过载。
2.使用多个组件进行负载平衡而不是单个组件可能会通过冗余来提高可靠性和可用性。

什么是Hystrix？它如何实现容错？ 

1.Hystrix是一个延迟和容错库，旨在隔离远程系统，服务和第三方库的访问点，当出现故障是不可避免的
故障时，停止级联故障并在复杂的分布式系统中实现弹性。

2.通常对于使用微服务架构开发的系统，涉及到许多微服务。这些微服务彼此协作。

什么是Netflix Feign？它的优点是什么？

1.Feign是受到Retrofit，JAXRS-2.0和WebSocket启发的java客户端联编程序。
2.使用功能区进行负载平衡。
3.获取服务实例，然后获取基本URL。
4.利用REST模板来使用服务。 前面的代码如下

SpringCloud

1.SpringCloud和Dubbo

SpringCloud和Dubbo都是现在主流的微服务架构

SpringCloud是Apache旗下的Spring体系下的微服务解决方案

Dubbo是阿里系的分布式服务治理框架

从技术维度上,其实SpringCloud远远的超过Dubbo,Dubbo本身只是实现了服务治理,而SpringCloud现在以及
有21个子项目以后还会更多

服务的调用方式Dubbo使用的是RPC远程调用,而SpringCloud使用的是 Rest API,其实更符合微服务官方的定义

服务的注册中心来看,Dubbo使用了第三方的ZooKeeper作为其底层的注册中心,实现服务的注册和
发现,SpringCloud使用Spring Cloud Netflix Eureka实现注册中心,当然SpringCloud也可以
使用ZooKeeper实现,但一般我们不会这样做.

服务网关,Dubbo并没有本身的实现,只能通过其他第三方技术的整合,而SpringCloud有Zuul路由网关,作为路由
服务器,进行消费者的请求分发,SpringCloud还支持断路器

2.技术选型
1)目前国内的分布式系统选型主要还是Dubbo毕竟国产,而且国内工程师的技术熟练程度高,并且Dubbo在其他维度
上的缺陷可以由其他第三方框架进行集成进行弥补
2)SpringCloud目前是国外比较流行,当然我觉得国内的市场也会慢慢的偏向SpringCloud,就连刘军作为Dubbo
重启的负责人也发表过观点,Dubbo的发展方向是积极适应SpringCloud生态,并不是起冲突

3.Rest和RPC对比
1)微服务提出者马丁福勒的论文的话可以发现其定义的服务间通信机制就是Http Rest
2)RPC最主要的缺陷就是服务提供方和调用方式之间依赖太强,我们需要为每一个微服务进行接口的定义,并通过
持续继承发布,需要严格的版本控制才不会出现服务提供和调用之间因为版本不同而产生的冲突
3)而REST是轻量级的接口,服务的提供和调用不存在代码之间的耦合,只是通过一个约定进行规范,但也有可能
出现文档和接口不一致而导致的服务集成问题,但可以通过swagger工具整合,是代码和文档一体化解决,所以
REST在分布式环境下比RPC更加灵活
4)当当网的DubboX在对Dubbo的增强中增加了对REST的支持

4.文档质量和社区活跃度
1)SpringCloud社区活跃度远高于Dubbo,毕竟由于梁飞团队的原因导致Dubbo停止更新迭代五年,而中小型
公司无法承担技术开发的成本导致Dubbo社区严重低落
2)而SpringCloud异军突起,迅速占领了微服务的市场,背靠Spring混的风生水起
3)Dubbo经过多年的积累文档相当成熟,对于微服务的架构体系各个公司也有稳定的现状

二.SpringBoot和SpringCloud

1.SpringBoot是Spring推出用于解决传统框架配置文件冗余,装配组件繁杂的基于Maven的解决方案,旨在快速
搭建单个微服务

2.而SpringCloud专注于解决各个微服务之间的协调与配置,服务之间的通信,熔断,负载均衡等

3.技术维度并相同,并且SpringCloud是依赖于SpringBoot的,而SpringBoot并不是依赖与SpringCloud,
甚至还可以和Dubbo进行优秀的整合开发

总结:
1.SpringBoot专注于快速方便的开发单个个体的微服务

2.SpringCloud是关注全局的微服务协调整理治理框架,整合并管理各个微服务,为各个微服务之间提供,
配置管理,服务发现,断路器,路由,事件总线等集成服务

3.SpringBoot不依赖于SpringCloud,SpringCloud依赖于SpringBoot,属于依赖关系

4.SpringBoot专注于快速,方便的开发单个的微服务个体,SpringCloud关注全局的服务治理框架

三.Eureka和ZooKeeper都可以提供服务注册与发现的功能,请说说两个的区别

1.ZooKeeper保证的是CP,Eureka保证的是AP

2.ZooKeeper在选举期间注册服务瘫痪,虽然服务最终会恢复,但是选举期间不可用的

3.Eureka各个节点是平等关系,只要有一台Eureka就可以保证服务可用,而查询到的数据并不是最新的

自我保护机制会导致

1.Eureka不再从注册列表移除因长时间没收到心跳而应该过期的服务

2.Eureka仍然能够接受新服务的注册和查询请求,但是不会被同步到其他节点(高可用)

3.当网络稳定时,当前实例新的注册信息会被同步到其他节点中(最终一致性)

Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像ZooKeeper一样使得整个注册系统
瘫痪

2.ZooKeeper有Leader和Follower角色,Eureka各个节点平等

3.ZooKeeper采用过半数存活原则,Eureka采用自我保护机制解决分区问题

4.Eureka本质上是一个工程,而ZooKeeper只是一个进程

四.微服务之间是如何独立通讯的

远程过程调用（Remote Procedure Invocation）

也就是我们常说的服务的注册与发现

直接通过远程过程调用来访问别的service。

优点：
简单，常见,因为没有中间件代理，系统更简单

缺点：
只支持请求/响应的模式，不支持别的，比如通知、请求/异步响应、发布/订阅、发布/异步响应
降低了可用性，因为客户端和服务端在请求过程中必须都是可用的

二、消息

使用异步消息来做服务间通信。服务间通过消息管道来交换消息，从而通信。

优点:

把客户端和服务端解耦，更松耦合

提高可用性，因为消息中间件缓存了消息，直到消费者可以消费

支持很多通信机制比如通知、请求/异步响应、发布/订阅、发布/异步响应

缺点:

消息中间件有额外的复杂性

20.什么是服务熔断?什么是服务降级

1.在复杂的分布式系统中,微服务之间的相互调用,有可能出现各种各样的原因导致服务的阻塞,在高并发场景
下,服务的阻塞意味着线程的阻塞,导致当前线程不可用,服务器的线程全部阻塞,导致服务器崩溃,由于服务
之间的调用关系是同步的,会对整个微服务系统造成服务雪崩

2.为了解决某个微服务的调用响应时间过长或者不可用进而占用越来越多的系统资源引起雪崩效应就需要
进行服务熔断和服务降级处理。

3.所谓的服务熔断指的是某个服务故障或异常一起类似显示世界中的“保险丝"当某个异常条件被触发就直接
熔断整个服务，而不是一直等到此服务超时。

4.服务熔断就是相当于我们电闸的保险丝,一旦发生服务雪崩的,就会熔断整个服务,通过维护一个自己的
线程池,当线程达到阈值的时候就启动服务降级,如果其他请求继续访问就直接返回fallback的默认值

21.微服务的优缺点分别是什么?说下你在项目开发中碰到的坑

优点
1.每一个服务足够内聚,代码容易理解
2.开发效率提高,一个服务只做一件事
3.微服务能够被小团队单独开发
4.微服务是松耦合的,是有功能意义的服务
5.可以用不同的语言开发,面向接口编程
6.易于与第三方集成
7.微服务只是业务逻辑的代码,不会和HTML,CSS或者其他界面组合
8.开发中,两种开发模式
    前后端分离
    全栈工程师
9.可以灵活搭配,连接公共库/连接独立库

缺点
1.多服务运维难度,随着服务的增加,运维的压力也在增大
2.多服务运维难度,随着服务的增加,运维的压力也在增大
3.服务间通信成本
4.数据一致性
5.系统集成测试
6.性能监控

22.你所知道的微服务技术栈有哪些?请列举一二

维度(SpringCloud)

服务开发
SpringBoot
Spring
SpringMVC

服务配置与管理
Netfilx公司的Archaiusm,阿里的Diamond

服务注册与发现
Eureka,ZooKeeper

服务调用
Rest,RPC,gRPC

服务熔断器
Hystrix

服务负载均衡
Ribbon,Nginx

服务接口调用
Feign

消息队列
Kafka,RabbitMq,ActiveMq

服务配置中心管理
SpringCloudConfing

服务路由(API网关)
Zuul

事件消息总线
SpringCloud Bus