SpringBoot+SpringCloud面试题整理

什么是SpringBoot？
一、用来简化spring初始搭建和开发过程使用特定的方式进行配置(properties或者yml文件)
二、建立独立的spring引用程序main方法运行
三、嵌入Tomcat无需部署war包，直接打成jar包nohup java -jar – & 启动就好
四、简化了maven的配置
四、自动配置spring添加对应的starter自动化配置

SpringBoot经常使用的starter：
一、spring-boot-starter-web(嵌入Tomcat和web开发须要的servlet和jsp支持)
二、spring-boot-starter-data-jpa(数据库支持)
三、spring-boot-starter-data-Redis(Redis支持)
四、spring-boot-starter-data-solr(solr搜索应用框架支持)
五、mybatis-spring-boot-starter(第三方mybatis集成starter)

SpringBoot自动配置原理：
一、@EnableAutoConfiguration这个注解会"猜"你将如何配置spring，前提是你已经添加了jar依赖项，若是spring-boot-starter-web已经添加Tomcat和SpringMVC，这个注释就会自动假设您在开发一个web应用程序并添加相应的spring配置，会自动去maven中读取每一个starter中的spring.factories文件，该文件里配置了全部须要被建立spring容器中bean
二、在main方法中加上@SpringBootApplication和@EnableAutoConfiguration

SpringBoot starter工做原理：
一、SpringBoot在启动时扫描项目依赖的jar包，寻找包含spring.factories文件的jar
二、根据spring.factories配置加载AutoConfigure
三、根据@Conditional注解的条件，进行自动配置并将bean注入到Spring Context

SpringBoot的优势：
一、减小开发、测试时间和努力
二、使用JavaConfig有助于避免使用XML
三、避免大量的maven导入和各类版本冲突
四、提供意见发展方法
五、经过提供默认值快速开始开发
六、没有单独的web服务器须要，这就意味着再也不须要启动Tomcat、Glassfish或其余任何东西
七、须要更少的配置，由于没有web.xml文件。只需添加用@Configuration注释的类，而后添加用@Bean注释的方法，Spring将自动加载对象并像之前同样对其进行管理。甚至能够将@Autowired添加到bean方法中，以使用Spring自动装入须要的依赖关系中
Springcloud解决那些问题：
配置管理、（注册中心eureka、zk）、服务发现、服务注册、断路器、路由策略、全局锁、分布式会话、客户端调用、接口网关（zuul）、服务管理系统

SpringBoot与Springcloud：
1>、SpringBoot简化了xml配置，快速整合框架
2>、Springcloud是一套微服务解决方案—RPC远程调用
3>、关系Springcloud依赖与SpringBoot（web组件用的SpringMVC），为何Springcloud会依赖与SpringBoot？由于Springcloud写接口就是SpringMVC接口
4>、SpringBootproperties和yml中可使用${random}设置一些随机值

服务的调用：
rest、feign（均使用httpclient技术），负载均衡ribbon
服务调用的原理：
服务首先注册到注册中心eureka中(注册一个名字经过名字调用)
负载均衡
ribbon，先去注册中心取到对应的服务，而后交给我ribbon

配置详解：
1>、eureka.client.register-with-eureka：是否向注册中心注册本身，注册为true反之为false
2>、eureka.client.fetch-registry： 是否须要去检索服务，检索为true反之为false
3>、eureka.client.serviceUrl.defaultZone : 指定服务注册中心的地址
Eureka：
1>、eureka可分为三个角色：服务发现者、服务注册者、注册发现中心，可是这三个角色并不和实际部署的模型是一对一的关系
2>、全部的网络通讯都是基于http(s)协议的
3>、Eureka和AWS是紧密结合的，不管是配置仍是源码，好比Region、zone…，Region能够经过配置文件进行配置，若是不配置默认使用us-east-1。一样Zone也能够配置，若不配置默认使用defaultZone

高可用配置：
Eureka server 的高可用实际上就是将本身做为服务向其余服务注册中心注册本身，这样就能够造成一组互相注册的服务注册中心，以实现服务清单的互相同步，达到高可用效果。
微服务：
之前全部的代码都放在同一个工程中、部署在同一个服务器、同一项目的不一样模块不一样功能互相抢占资源，微服务就是将工程根据不一样的业务规则拆分红微服务，部署在不一样的服务器上，服务之间相互调用，java中有的微服务有dubbo(只能用来作微服务)、springcloud( 提供了服务的发现、断路器等)。
微服务的特色：
按业务划分为一个独立运行的程序，即服务单元
服务之间经过HTTP协议相互通讯
自动化部署
能够用不一样的编程语言
能够用不一样的存储技术
服务集中化管理
微服务是一个分布式系统
微服务的优点：
一、将一个复杂的业务拆分为若干小的业务，将复杂的业务简单化，新人只须要了解他所接管的服务的代码，减小了新人的学习成本。
二、因为微服务是分布式服务，服务于服务之间没有任何耦合。微服务系统的微服务单元具备很强的横向拓展能力。
三、服务于服务之间采用HTTP网络通讯协议来通讯，单个服务内部高度耦合，服务与服务之间彻底独立，无耦合。这使得微服务能够采用任何的开发语言和技术来实现，提升开发效率、下降开发成本。
四、微服务是按照业务进行拆分的，并有坚实的服务边界，若要重写某一业务代码，不需了解因此业务，重写简单。
五、微服务的每一个服务单元是独立部署的，即独立运行在某个进程中，微服务的修改和部署对其余服务没有影响。
六、微服务在CAP理论中采用的AP架构，具备高可用分区容错特色。高可用主要体如今系统7x24不间断服务，他要求系统有大量的服务器集群，从而提升系统的负载能力。分区容错也使得系统更加健壮。
微服务的不足：
一、微服务的复杂度：构建一个微服务比较复杂，服务与服务之间经过HTTP协议或其余消息传递机制通讯，开发者要选出最佳的通讯机制，并解决网络服务差时带来的风险。
二、分布式事物：将事物分红多阶段提交，若是一阶段某一节点失败仍会致使数据不正确。若是事物涉及的节点不少，某一节点的网络出现异常会致使整个事务处于阻塞状态，大大下降数据库的性能。
三、服务划分：将一个完整的系统拆分红不少个服务，是一件很是困难的事，由于这涉及了具体的业务场景
四、服务部署：最佳部署容器Docker
微服务和SOA的关系：
微服务相对于和ESB联系在一块儿的SOA轻便敏捷的多，微服务将复杂的业务组件化，也是一种面向服务思想的体现。对于微服务来讲，它是SOA的一种体现，可是它比ESB实现的SOA更加轻便、敏捷和简单。
springcloud如何实现服务注册与发现？
服务发布时指定对应的服务名(IP地址和端口号)，将服务注册到注册中心(eureka和zookeeper)，可是这一切是Springcloud自动实现的，只须要在SpringBoot的启动类上加上@EnableDisscoveryClient注解，同一服务修改端口就能够启动多个实例调用方法：传递服务名称经过注册中心获取全部的可用实例，经过负载均衡策略(Ribbon和Feign)调用对应的服务

Ribbon和Feign的区别：
Ribbon添加的maven依赖是spring-starter-ribbon，使用@RibbonClient(value=“服务名称”)使用RestTemplate调用远程服务对应的方法，
Feign添加的maven依赖是spring-starter-feign，服务提供方提供对外接口，调用方使用，在接口上使用FeignClient(“指定服务名”)，
具体区别：
一、启动类使用的注解不一样，Ribbon使用的是@RibbonClient，Feign使用的是@EnableFeignClients
二、服务的指定位置不一样，Ribbon是在@RibbonClient注解上声明，Feign则是在定义抽象方法的接口中使用@FeignClient声明
三、调用方式不一样，Ribbon须要本身构建http请求，模拟http请求而后使用RestTemplate发送给其余服务，步骤比较繁琐。Feign则是在Ribbon的基础上进行了一次改进，采用接口调用的方式，将须要调用的其余服务的方法定义成抽象方法便可，不须要本身构建http请求，不过要注意的是抽象方法的注解、方法签名要和提供方的彻底一致。

雪崩效应：
分布式系统中的服务通讯依赖于网络，网络很差，必然会对分布式系统带来很大的影响。在分布式系统中，服务之间相互依赖，若是一个服务之间出现了故障或者网络延迟，在高并发的状况下，会致使线程阻塞，在很短的时间内该服务的线程资源会消耗殆尽，最终使得该服务不可用。因为服务的相互依赖，可能会致使整个系统的不可用，这就是“雪崩效应”。为了防止此类事件的发生，分布式系统必然要采起相应的措施，如熔断机制（Springcloud采用的是Hystrix）

熔断机制：
一、当一个服务出现故障时，请求失败次数超过设定的阀值（默认50）以后，该服务就会开启熔断器，以后该服务就不进行任何业务逻辑操做，执行快速失败，直接返回请求失败的信息。其余依赖于该服务的服务就不会由于得不到响应而形成线程阻塞，这是除了该服务和依赖于该服务的部分功能不可用外，其余功能正常。
二、熔断器还有一个自我修复机制，当一个服务熔断后，通过一段时间（5s）半打开熔断器。半打开的熔断器会检查一部分请求（只能有一个请求）是否正常，其余请求执行快速失败，检查的请求若是响应成功，则可判断该服务正常了，就可关闭该服务的熔断器，反之则继续打开熔断器。这种自我熔断机制和自我修复机制可使程序更加健壮、也能够为开发和运维减小不少没必要要的工做。
三、熔断组件每每会提供一系列的监控，如：服务可用与否、熔断器是否被打开、目前的吞吐量、网络延迟状态的监控等，从而可让开发人员和运维人员的了解服务的情况。

Eureka基础架构：
1>、服务注册中心：Eureka提供的服务端，提供服务注册与发现的功能
1>>、失效剔除：对于那些非正常下线的服务实例（内存溢出、网络故障致使的），服务注册中心不能收到“服务下线”的请求，为了将这些没法提供服务的实例从服务列表中剔除，Eureka Server在启动的时候会建立一个定时任务，默认每隔一段时间（默认60s）将当前清单中超时（默认90s）没有续约的服务剔除出去。
2>>、自我保护：Eureka Server 在运行期间，会统计心跳失败的比例在15分钟以内是否低于85%，若是出现低于的状况（生产环境因为网络不稳定会致使），Eureka Server会降当前的实例注册信息保护起来，让这些实例不过时，尽量保护这些注册信息，可是在这保护期间内实例出现问题，那么客户端就很容易拿到实际上已经不存在的服务实例，会出现调用失败的状况，因此客户端必须有容错机制，好比可使用请求重试、断路器等机制。
在本地进行开发时可使用 eureka.server.enable-self-preseervation=false参数来关闭保护机制，以确保注册中心能够将不可用的实例剔除。
2>、服务提供者：提供服务的应用，能够是SpringBoot应用也能够是其余的技术平台且遵循Eureka通讯机制的应用。他将本身提供的服务注册到Eureka，以供其余应用发现，（如：service层）
1>>、服务注册：服务提供者在启动的时候会经过发送Rest请求的方式将本身注册到Eureka Server（服务注册中心）中，同时带上自身服务的一些元数据，Eureka Server 接收到这个Rest请求后，将元数据存储在一个双层结构Map中，第一层的key是服务名，第二层key是具体服务的实例名
2>>、服务同步：如有两个或两个以上的Eureka Server（服务注册中心）时，他们之间是互相注册的，当服务提供者发送注册请求到一个服务注册中心时，它会将该请求转发到集群中相连的其余注册中心，从而实现注册中心间的服务同步，这样服务提供者的服务信息能够经过任意一台服务中心获取到
3>>、服务续约：在注册完服务以后，服务提供者会维护一个心跳来持续告诉Eureka Server：“我还活着”，以防止Eureka Server的“剔除任务”将该服务实例从服务列表中排除出去。配置：eureka.instance.lease-renewal-in-seconds=30(续约任务的调用间隔时间，默认30秒，也就是每隔30秒向服务端发送一次心跳，证实本身依然存活)，eureka.instance.lease-expiration-duration-in-seconds=90(服务失效时间，默认90秒，也就是告诉服务端，若是90秒以内没有给你发送心跳就证实我“死”了，将我剔除)
3>、服务消费者：消费者应用从服务注册中心获取服务列表，从而使消费者能够知道去何处调用其所须要的服务，如：Ribbon实现消费方式、Feign实现消费方式
1>>、获取服务：当启动服务消费者的时候，它会发送一个Rest请求给注册中心，获取上面注册的服务清单，Eureka Server会维护一份只读的服务清单来返回给客户端，而且每三十秒更新一次
2>>、服务调用：在服务消费者获取到服务清单后，经过服务名能够得到具体提供服务的实例名和该实例的元信息，采用Ribbon实现负载均衡
3>>、服务下线：当服务实例进行正常的关闭操做时，它会触发一个服务下线的Rest请求给Eureka Server，告诉服务注册中心“我要下线了”。服务端接收到请求以后，将该服务状态设置为下线，并把下线时间传播出去。
Eureka和zookeeper均可以提供服务注册与发现的功能，二者的区别：
Zookeeper保证了CP(C：一致性，P：分区容错性)，Eureka保证了AP(A：高可用，P：分区容错)
一、Zookeeper-----当向注册中心查询服务列表时，咱们能够容忍注册中心返回的是几分钟之前的信息，但不能容忍直接down掉不可用的。也就是说服务注册功能对高可用性要求比较高，可是zk会出现这样的一种状况，当master节点由于网络故障与其余节点失去联系时，剩余的节点会从新选leader。问题在于，选取leader的时间过长(30~120s)，且选取期间zk集群都不可用，这样就会致使选取期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大几率会发生的事，虽然服务最终恢复，可是漫长的选择时间致使的注册长期不可用是不能容忍的
二、Eureka则看明白这一点，所以再设计的优先保证了高可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响到正常节点的工做，剩余的节点依然能够提供注册和查询服务。而Eureka的客户端再向某个Eureka注册时若是发现链接失败，则会自动切换至其余节点，只要有一台Eureka还在，就能保证注册服务的可用(保证可用性)，只不过查到的信息可能不是最新的(不保证一致性)。除此以外Eureka还有一种自我保护机制，若是在15分钟内超过85%的节点都没有正常心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时就会出现如下几种状况：
1>、Eureka再也不从注册列表移除由于长时间没收到心跳而应该过时的服务
2>、Eureka仍然可以接受新服务的注册和查询请求，可是不会被同步到其它节点上(保证当前节点可用)
3>、当网络稳定时，当前实例新的注册信息会被同步到其它节点中
Eureka还有客户端缓存功能(Eureka分为客户端程序和服务器端程序两个部分，客户端程序负责向外提供注册与发现服务接口)。因此即使Eureka集群中全部节点都失效，或者发生网络分隔故障致使客户端不能访问任何一台Eureka服务器；Eureka服务的消费者任然能够经过Eureka客户端缓存来获取全部的服务注册信息。甚至最极端的环境下，全部正常的Eureka节点都不对请求产生响应也没有更好的服务器解决方案来解决这种问题时；得益于Eureka的客户端缓存技术，消费者服务仍然能够经过Eureka客户端查询与获取注册服务信息，这点很重要，所以Eureka能够很好的应对网络故障致使部分节点失去联系的状况，而不像Zookeeper那样使整个注册服务瘫痪。
CAP理论：
一、Consistency：指数据的强一致性。若是写入某个数据成功，以后读取，读到的都是新写入的数据；若是写入失败，读到的都不是写入失败的数据。
二、Availability：指服务的可用性
三、Partition-tolerance：指分区容错
Ribbon和Nginx的区别：
Nginx性能好，但Ribbon能够剔除不健康节点，Nginx剔除比较麻烦，Ribbon是客户端负载均衡，Nginx是服务端负载均衡
服务注册与发现：
服务注册就是向服务注册中心注册一个服务实例，服务提供者将本身的服务信息（服务名、IP地址等）告知注册中心。服务发现是服务消费另外一个服务时，注册中心将服务的实例返回给服务消费者，一个服务既是服务提供者又是服务消费者。
服务注册中心健康检查机制，当一个服务实例注册成功之后，会定时向注册中心发送一个心跳证实本身可用，若中止发送心跳证实服务不可用将会别剔除。若过段时间继续想注册中心提供心跳，将会从新加入服务注册中心列表中。
服务的负载均衡：
      为何要用：微服务是将业务代码拆分为不少小的服务单元，服务之间的相互调用经过HTTP协议来调用，为了保证服务的高可用，服务单元每每都是集群化部署的，那么消费者该调用那个服务提供者的实例呢？
介绍：服务消费者集成负载均衡组件，该组件会向服务消费者获取服务注册列表信息，并隔一段时间从新刷新获取列表。当服务消费者消费服务时，负载均衡组件获取服务提供者全部实例的注册信息，并经过必定的负载均衡策略（能够本身配置）选择一个服务提供者实例，向该实例进行服务消费，这样就实现了负载均衡。