Spring Cloud(1)

Q:
什么是微服务?

微服务架构是一种架构模式或者说是一种架构风格,它提倡将单一应用程序划分为一组小的服务,每个服务运行在其独立的自己的进程中,服务之间相互协调、互相配合,为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API),每个服务都围绕着具体的业务进行构建,并且能够被独立的构建在生产环境、类生产环境等。另外,应避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建,可以有一个非常轻量级的集中式管理来协调这些服务,可以使用不同的语言来编写服务,也可以使用不同的数据存储。

Q:
Spring Cloud由哪些组件组成?

Eureka:服务注册与发现
Zuul:服务网关
Ribbon:客户端负载均衡
Feign:声明性的Web服务客户端
Hystrix:断路器
Config:分布式统一配置管理
等20几个框架,开源一直在更新
组件图

Q:
Spring Cloud和 dubbo区别?

服务调用方式:

dubbo是 RPC
springcloud 是Rest Api
注册中心:

dubbo是 zookeeper;
springcloud是 eureka,也可以是 zookeeper
服务网关:

dubbo本身没有实现,只能通过其他第三方技术整合;
springcloud有Zuul路由网关,作为路由服务器,进行消费者的请求分发;springcloud支持断路器,与git完美集成配置文件支持版本控制,事物总线实现配置文件的更新与服务自动装配等等一系列的微服务架构要素。

Q:
Eureka的工作原理?

Eureka:服务注册中心(可以是一个集群),对外暴露自己的地址
提供者:启动后向Eureka注册自己信息(地址,提供什么服务)
消费者:向Eureka订阅服务,Eureka会将对应服务的所有提供者地址列表发送给消费者,并且定期更新
心跳(续约):提供者定期通过http方式向Eureka刷新自己的状态(每30s定时向EurekaServer发起请求)

Q:
说说Eureka的自我保护机制?

当一个服务未按时进行心跳续约时,在生产环境下,因为网络延迟等原因,此时就把服务剔除列表并不妥当,因为服务可能没有宕机。Eureka就会把当前实例的注册信息保护起来,不予剔除。生产环境下这很有效,保证了大多数服务依然可用。但是有可能会造成一些挂掉的服务被剔除有延迟。

Q:
Eureka和ZooKeeper的区别?

1、ZooKeeper中的节点服务挂了就要选举,在选举期间注册服务瘫痪,虽然服务最终会恢复,但是选举期间不可用的, 选举就是改微服务做了集群,必须有一台主其他的都是从。
2、Eureka各个节点是平等关系,服务器挂了没关系,只要有一台Eureka就可以保证服务可用,数据都是最新的。如果查询到的数据并不是最新的,就是因为Eureka的自我保护模式导致的。
3、Eureka本质上是一个工程,而ZooKeeper只是一个进程。
4、Eureka可以很好的应对因网络故障导致部分节点失去联系的情况,而不会像ZooKeeper 一样使得整个注册系统瘫痪。
5、ZooKeeper保证的是CP,Eureka保证的是AP

CAP:
C:一致性Consistency (取舍:强一致性、单调一致性、会话一致性、最终一致性、弱一致性)
A:可用性 Availability
P:分区容错性Partition tolerance

Q:
什么是zuul?

zuul是对SpringCloud提供的成熟对的路由方案,他会根据请求的路径不同,网关会定位到指定的微服务,并代理请求到不同的微服务接口,他对外隐蔽了微服务的真正接口地址。
三个重要概念:

动态路由表:Zuul支持Eureka路由,手动配置路由,这俩种都支持自动更新
路由定位:根据请求路径,Zuul有自己的一套定位服务规则以及路由表达式匹配
反向代理:客户端请求到路由网关,网关受理之后,在对目标发送请求,拿到响应之后在 给客户端
Zuul的应用场景:对外暴露,权限校验,服务聚合,日志审计等

Q:
zuul的工作流程?

在Spring Cloud Netflix中,Zuul巧妙的整合了Eureka来实现面向服务的路由。
实际上,API网关将自己注册到Eureka服务注册中心上,也会从注册中心获取所有服务以及它们的实例清单。在Eureka的帮助下,API网关已经维护了系统中所有serviceId与实例地址的映射关系。当有外部请求到达API网关的时候,根据请求的URL找到最匹配的path,API网关就可以知道要将该请求"路由"到哪个具体的serviceId上去。最终通过Ribbon的负载均衡策略实现请求的路由。

Q:
什么是feign?

1.feign采用的是基于接口的注解
2.feign整合了ribbon,具有负载均衡的能力
3.整合了Hystrix,具有熔断的能力

Q:
feign的工作流程?

1、通过动态代理生成实现类
2、根据接口类的注解生命规则,解析出底层的methodhandler
3、拦截器负责对请求和返回进行包装和处理
4、通过均衡负载http去访问远程服务

Q:
什么是Hystrix?

在分布式系统,我们一定会依赖各种服务,那么这些个服务一定会出现失败的情况,就会导致雪崩,Hystrix就是这样的一个工具,防雪崩利器,它具有服务降级,服务熔断,服务隔离,监控等一些防止雪崩的技术。
Hystrix有四种防雪崩方式:

服务降级:接口调用失败就调用本地的方法返回一个空
服务熔断:接口调用失败就会进入调用接口提前定义好的一个熔断的方法,返回错误信息
服务隔离:隔离服务之间相互影响
服务监控:在服务发生调用时,会将每秒请求数、成功请求数等运行指标记录下来。

Q: Hystrix流程? 1、构造一个 HystrixCommand或HystrixObservableCommand对象,用于封装请求,并在构造方法配置请求被执行需要的参数; 2、执行命令,Hystrix提供了4种执行命令的方法; 3、判断是否使用缓存响应请求,若启用了缓存,且缓存可用,直接使用缓存响应请求。Hystrix支持请求缓存,但需要用户自定义启动; 4、判断熔断器是否打开,如果打开,跳到第8步; 5、判断线程池/队列/信号量是否已满,已满则跳到第8步; 6、执行HystrixObservableCommand.construct()或HystrixCommand.run(),如果执行失败或者超时,跳到第8步;否则,跳到第9步; 7、统计熔断器监控指标; 8、走Fallback备用逻辑 9、返回请求响应