java面试题整理（8）

一、什么是微服务
答： 以前的模式是所有的代码在同一个工程中部署在同一个服务器中同一个项目的不同模块不同功能互相抢占资源
微服务将工程根据不同的业务规则拆分成微服务,微服务部署在不同的机器上,服务之间进行相互调用
Java微服务的框架有dubbo（只能用来做微服务），spring cloud（提供了服务的发现，断路器等）

二、spring cloud如何实现服务的注册和发现
答：服务在发布时指定对应的服务名（服务名包括了IP地址和端口）将服务注册到注册中心（eureka或者zookeeper）
这一过程是spring cloud自动实现只需要在main方法添加@EnableDisscoveryClient同一个服务修改端口就可以启动多个实例
调用方法：传递服务名称通过注册中心获取所有的可用实例通过负载均衡策略调用（ribbon和feign）对应的服务

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

四、什么是服务熔断？什么是服务降级？
答： 在复杂的分布式系统中,微服务之间的相互调用,有可能出现各种各样的原因导致服务的阻塞,在高并发场景下,服务的阻塞意味着线程的阻塞,导致当前线程不可用,服务器的线程全部阻塞,导致服务器崩溃,由于服务之间的调用关系是同步的,会对整个微服务系统造成服务雪崩
为了解决某个微服务的调用响应时间过长或者不可用进而占用越来越多的系统资源引起雪崩效应就需要进行服务熔断和服务降级处理。
所谓的服务熔断指的是当某个异常条件被触发就直接熔断整个服务，而不是一直等到此服务超时。
类似现实世界中的“保险丝"，服务熔断就是相当于我们电闸的保险丝,一旦发生服务雪崩的,就会熔断整个服务,通过维护一个自己的线程池,当线程达到阈值的时候就启动服务降级,如果其他请求继续访问就直接返回fallback的默认值

五、你所知道的微服务技术栈有哪些?
微服务技术栈 ： 多种技术的结合体
我们在讨论分布式的微服务架构的时候它需要有哪些维度？
1 服务治理 2 服务注册 3 服务调用 4 负载均衡 5 服务监控
这五点称为落地维度 为什么叫落地呢？
天上飞的理念肯定要有落地的实现
也就是说分布式微服务架构当作天上飞的理念
落地的实现可以总结为
1 服务开发 ：spring boot spring mvc spring
2 服务的配置与管理 ： netfix 公司 archaius 阿里的diamond等
3 服务的注册于发现 ：spriing cloud 所采用的 eureka ，consul,zookeeper 等
4 服务的调用:rest GRPC RPC
5 服务的熔断器 ：hystrix envoy等
6 负载均衡 ：ribbon .nginx
7 服务接口调用(客户端调用服务的简化工具) Feign等消息队列Kafka、 Rabbitmq、 Activemq等
8 服务配置管理中心 Spring Cloud Config、Chef等服务路由(API网关)Zuul等
9 服务监控Zabbix、 Nagios、 Metrics、 Spectator等
10 全链路追踪Zipkin, Brave、 Dapper等
11 服务部罟Docker、 Open Stack、 Kubernetes等
12 数据流操作开发包Spring Cloud Stream(封装与 Redis, Rabbit、 Kafka等发送接收消息)
13 事件消息总线Spring Cloud Bus

六、Eureka和zookeeper都可以提供服务注册与发现的功能，请说说两个的区别？
答：Zookeeper保证了CP（C：一致性，P：分区容错性），Eureka保证了AP（A：高可用）
1.当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的信息，但不能容忍直接down掉不可用。也就是说，服务注册功能对高可用性要求比较高，但zookeeper会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新选leader。问题在于，选取leader时间过长，30 ~ 120s，且选取期间zookeeper集群都不可用，这样就会导致选取期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够恢复，但是漫长的选取时间导致的注册长期不可用是不能容忍的。
2.Eureka保证了可用性，Eureka各个节点是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点仍然可以提供注册和查询服务。而Eureka的客户端向某个Eureka注册或发现时发生连接失败，则会自动切换到其他节点，只要有一台Eureka还在，就能保证注册服务可用，只是查到的信息可能不是最新的。除此之外，Eureka还有自我保护机制，如果在15分钟内超过85%的节点没有正常的心跳，那么Eureka就认为客户端与注册中心发生了网络故障，此时会出现以下几种情况：
①、Eureka不再从注册列表中移除因为长时间没有收到心跳而应该过期的服务。
②、Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上（即保证当前节点仍然可用）
③、当网络稳定时，当前实例新的注册信息会被同步到其他节点。
因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像Zookeeper那样使整个微服务瘫痪。