Java面试总结——SpringCloud面试总结

1、微服务之间的如何独立通讯？

• 同步通信：dubbo通过RPC远程过程调用、SpringCloud基于HTTP的REST方式。
• 异步：消息队列，如RabbitMq，ActiveM、Kafka等

2、SpringBoot和SpringCloud之间的关系

• SpringBoot：专注于快速方便的开发单个个体微服务（关注微观）；SpringCloud：关注全局的微服务协调治理框架，将SpringBoot开发的一个个单体微服务组合并管理起来（关注宏观）；Spring Boot 是 Spring 开源组织下的子项目，是 Spring 组件一站式解决方案，主要是简化了使用 Spring 的难度，简省了繁重的配置，提供了各种启动器，开发者能快速上手。
• SpringBoot可以离开SpringCloud独立使用，但是SpringCloud不可以离开SpringBoot，属于依赖关系。

3、什么是熔断和服务降级

• 服务熔断的作用类似于家用保险丝，当某服务出现不可用或响应超时的情况时，为了防止整个系统出现雪崩，暂时停止对该服务的调用
• 服务降级是从整个系统的负荷情况出现和考虑的，对某些负荷较高的情况。为了预防某些功能出现负荷过载或者响应慢的情况。在其内部暂时舍弃一些非核心的接口和数据的请求，而直接返回一个提前准备好的fallback（退路）错误处理信息，这样虽然提供的是一个有损的服务，但却保证了整个系统的稳定性和可用性

4、微服务的优缺点

• 有点：松耦合，聚焦单一业务功能，无关开发语言，图对规模降级，在开发中，不需要了解所有业务，只专注于当前功能，遍历集中，功能小而精。微服务是一个功能受损，其它功能影响不大，可以快速定位问题，微服务只关注于当前业务逻辑代码，不会和Html，css或者其它页面进行混合
• 缺点：随着服务数量增加，管理复杂，部署复杂，服务器需要增加，服务通信和调用压力增大，运维工程师压力增大，人力资源增多，系统依赖性强。

5、eureka和zookeeper的区别

• zookeeper是CP原则，强一致性和分区容错性
• eureka是AP原则，可用性和分区容错性
• zookeeper当主节点故障时，zk会在剩余节点重新选择主节点，耗时时长，虽然能够恢复，但是选取主节点期间会导致服务不可用，这是不能容忍的
• eureka各个节点是平等的，一个节点挂掉，其它节点仍会正常保证服务

6、微服务架构

• 微服务架构就是对微服务进行管理整合应用的

7、SpringCloud核心组件

• Eureka：服务注册与发现
• Feign：基于动态代理机制，根据注解和选择的机器，拼接请求url地址，发起请求
• Ribbon：实现负责均衡，从一个服务的多台机器中选择一台
• Hystrix：提供线程池，不同的服务走不通的线程池，实现了不同服务调用的隔离，避免了服务学风的问题
• Zuul：网关管理，由Zuul网关转发请求给对应的服务。

8、雪崩效应

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

9、熔断机制

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

10、Eureka基础架构

• 服务注册中心：Eureka提供的服务端，提供服务注册与发现的功能
• 失效剔除：对于那些非正常下线的服务实例（内存溢出，网络故障导致的），服务注册中心不能收到服务下线的请求，为了将这些无法提供服务的实例从服务列表汇总剔除，Eureka Server在启动的时候会创建一个定时任务，默认每隔一段时间（默认60s）将当前清单中超时（默认90s）没有续约的服务剔除出去
• 自我保护：Eureka Server在运行期间，会统计心跳失败的比例在15分钟之内是否低于85%，如果出现低于的情况（生产环境由于网络不稳定会导致），Eureka Server会将当前的实例注册信息保护起来，让这些实例不过期，尽可能保护这些注册信息，会出现调用失败的情况。所有客户端必须有容错机制，比如可以使用请求重试、断路器等机制。在本地进行开发时可以使用eureka.server.enable-self-preservation=false参数来关闭保存机制。以确保注册中心将不可用的实例剔除。
• 服务提供者：提供服务的应用，可以是SpringBoot应用也可以是其他的技术平台且遵循Eureka通信机制的应用，他讲自己提供的服务注册到Eureka，一共其它应用发现
• 服务注册：服务提供者在启动的时候会通过发送Rest请求的方式将自己注册到Eureka Server中，同时带上自身服务的一些元数据，Eureka Server 接收到这个Rest请求后，将元数据存储在一个双层结构Map，第一层的key是服务名，第二层key是具体服务的实例名
• 服务同步：若有两个或两个以上的Eureka Server时，他们之间是互相注册的，当服务提供者发送注册请求到一个服务注册中心时，它会将请求转发到及群众相连的其他注册中心，从而实现注册中心间的服务同步，这样服务提供者的服务信息可以通过任意一个服务中心内获取到对应的实例
• 服务续约：在注册完服务之后，服务提供者会维护一个心跳来持续告诉Eureka Server 我还活着，以防止Eureka Server的剔除任务将该服务实例从服务列表中排除出去。配置：eureka.instance.lease-renewal-in-seconds=30(续约任务的调用间隔时间，默认30秒，也就是每隔30秒向服务端发送一次心跳，证明自己依然存活)，eureka.instance.lease-expiration-duration-in-seconds=90(服务失效时间，默认90秒，也就是告诉服务端，如果90秒之内没有给你发送心跳就证明我“死”了，将我剔除)
• 服务消费者：消费者应用从服务注册中心获取服务列表，从而使消费者可以知道去何处调用其所需要的服务，如Ribbon实现消费方式、Feign实现消费方式
• 获取服务：当启动服务消费者的时候，它会发送一个Rest请求给注册中心，获取上面注册的服务清单，Eureka Server会维护一份只读的服务清单来返回给客户端，并且每三十秒更新一次
• 服务调用：在服务消费者获取到服务清单后，通过服务名可以获得具体提供服务的实例名和该实例的元信息，采用Ribbon实现负载均衡
• 服务下线：当服务实例进行正常的关闭操作时，它会触发一个服务下面的Rest请求给Eureka Server，告诉服务注册中心我要下线了，服务端接收到请求之后，将该服务状态设置为下线，并把下面时间传播出去。

11、Eureka和zookeeper的区别：

• Zookeeper保证了CP（C:一致性，P：分区容错性），Eureka保证了AP(A:高可用，P:分区容错）
• Zookeeper当master节点因为网络故障与其他节点拾取练市，剩余的节点会重新选leader，选举的过程时间过长（30-120s），且选举过程中zk集群不可用，这样就会导致选举期间注册服务瘫痪
• Eureka保证了高可用性，各个节点都是平等的，几个节点挂掉不会影响到正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时如何发生连接失败，则会自动切换至其他节点，只要有一台Eureka还在，就能保证注册服务的可用，只不过查到的信息可能不是最新的（不保证一致性）
• Eureka的自我保护机制：如果15分钟内超过85%的节点都没有正常心跳，那么Eureka就认为客户端豫注册中心出现了网络故障
• Eureka不再从注册猎豹标移除因为长时间没收到心跳而应该过期的服务
• Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上（保证当前节点可用）
• 当网络稳定时，当前实例新的注册信息会被同步到其它节点中

12、CAP理论：

• Consistency：指数居的强一致性，如果写入某个数据成功，之后读取，读取到的新写入的数据，如果写入失败，读取到的都不是写入失败的数据
• Availability：指服务的可用性
• Partition-tolerance:指分区容错

13、Springboot需要独立的容器运行

• 可以不需要，内置了Tomcat/Jetty等容器

14、运行SpringBoot的方式

• 打包用命令或者放到容器中运行
• 用Maven/Gradle插件运行
• 直接执行main方法运行

15、CSRF攻击

• CSRF代表跨站请求伪造，这是一种攻击，迫使最终用户在当前通过身份验证的web应用程序上执行不需要的操作，CSRF攻击专门针对状态改变请求，而不是数据窃取，因为攻击者无法查看对伪造请求的响应

16、WebSockets

• WebSocket是一种计算机通信协议，通过单个TCP连接提供全双工通信信道
• WebSocket是双向的-使用WebSocket客户端或服务器可以发起消息发送
• WebSocket是全双工的-客户端和服务器通信是相互独立的
• 单个TCP连接，初始连接使用HTTP，然后将此连接升级到基于套接字的连接，
• Light豫Http相比，WebSocket消息数据交换要轻得多。

17、Apache Kafka

• Apache Kafka是一个分布式发布——订阅消息系统。它是一个可扩展的，容错的发布——订阅消息系统，它使我们能够构建分布式应用程序。适合离线和在线信息消费。

18、Feign

• Feign是一个声明web服务客户端，这使得web服务客户端更容易
• 他将我们需要调用的服务方法定义成抽象方法保存在本地就可以了，不需要自己构建Http请求了，直接调用接口就行了，

19、Ribbon和Feign调用服务的区别

• 调用方式同：Ribbon需要我们自己构建Http请求，模式Http请求然后通过RestTemplate发给其他服务，步骤相当繁琐
• 而Feign则是在Ribbon的基础上进行了一次改进，采用接口的形式，将我们需要调用的服务方法定义成抽象方法保存在本地就可以了，不需要自己构建Http请求了，直接调用接口就行了，不过要注意，调用方法要和本地抽象方法的签名完全一致。

20、SpringCloud Config

• SpringCloud Config为分布式系统中的外部配置提供服务器和客户端支持，可以方便的对微服务各个环境下的配置进行集中式管理。Spring Cloud Config分为Config Server和Config Client两部分，Config Server负责读取配置文件，并且暴露Http API接口，Config Client 通过调用Config Server 的接口来读取配置文件。

21、