Springcloud和Dubbo的区别。Eureka和Ribbon和Hystrix和zuul

netty 是什么？

“netty 是一个基于nio的客户、服务器端编程框架,netty提供异步的,事件驱动的网络应用程序框架和工具,可以快速开发高可用的客户端和服务器。netty是基于nio的,它封装了jdk的nio,让我们使用起来更加方法灵活。”

Springcloud和Dubbo的区别？
Spring Cloud抛弃了Dubbo 的RPC通信，采用的是基于HTTP的REST方式。Dubbo 支持多协议（dubbo协议，hessian协 https://blog.csdn.net/lzhcoder/article/details/85631571

RPC即远程过程调用：它是一个计算机通信协议。它允许像调用本地服务一样调用远程服务。一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。

 Dubbo缺省协议：采用单一长连接和NIO异步通讯，使用基于于netty+hessian（序列化方式）交互。适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。Dubbo缺省协议不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低。

hessian序列化协议：多个短连接，适用于提供者数量比消费者数量还多，适用于文件的传输，一般较少用

eureka和zookeeper都可以提供服务注册与发现的功能，请说说两个的区别(优点)？ 　　

zookeeper： 当主节点故障时，zk会在剩余节点重新选择主节点，耗时过长，虽然最终能够恢复，但 是选取主节点期间会导致服务不可用，这是不能容忍的。 　　  　　　    eureka： 各个节点是平等的，一个节点挂掉，其他节点仍会正常保证服务。

总结： 著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分
区容错性P在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。因此，Zookeeper 保证
的是CP, Eureka 则是AP。

Eureka还有一种自我保护机制？

Eureka Client：负责将这个服务的信息注册到Eureka Server中

Eureka Server：注册中心，里面有一个注册表，保存了各个服务所在的机器和端口号

首先eureka client每隔30往eureka  server服务端发送心跳，15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

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

2、Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)。

3、当网络稳定时，当前实例新的注册信息会被同步到其它节点中因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。

Ribbon 与 Nginx 的区别？

1、nginx 是客户端所有请求统一交给 nginx，由 nginx 进行实现负载均衡请求转发，属于服务器端负载均衡。既请求由 nginx 服务器端进行转发。

　　Nginx 适合于服务器端实现负载均衡 比如 Tomcat 

2、Ribbon 是从 eureka 注册中心服务器端上获取服务注册信息列表，缓存到本地，然后在本地实现轮询负载均衡策略。既在客户端实现负载均衡。

　Ribbon 适合与在微服务中 RPC 远程调用实现本地服务负载均衡，比如 Dubbo、SpringCloud 中都是采用本地负载均衡。

 

Ribbon 怎么实现客户端负载均衡？

由于 Spring Cloud Ribbon 的封装， 我们在微服务架构中使用客户端负载均衡调用非常简单， 只需要如下两步

1、启动多个服务提供者实例并注册到一个服务注册中心或是服务注册中心集群
2、服务消费者通过被＠LoadBalanced 注解修饰过的 RestTemplate 来调用服务提供者。
这样，我们就可以实现服务提供者的高可用以及服务消费者的负载均衡调用。

Zuul的四大过滤器？

(1) PRE：这种过滤器在请求被路由之前调用。我们可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。

(2) ROUTING ：这种过滤器用于构建发送给微服务的请求，并使用Apache HttpClient或Netfilx Ribbon请求微服务。

(3) POST：这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的HTTP Header、收集统计信息和指标、将响应从微服务发送给客户端等。

(4) ERROR：在其他阶段发生错误时执行该过滤器。

 Hystrix的作用？

相关链接：https://www.jianshu.com/p/aa79fb6d96f3

如果一个用户服务调另一个库存服务，库存服务挂了。用户服务可以正常访问，只不过调库存服务的时候就会报错。会卡着几分钟。

这时候直接做一个服务熔断，在几分钟内请求库存服务直接fallback返回一个异常页面。

服务熔断和服务降级的区别？

　　服务熔断：一般是某个服务异常引起的，相当于“保险丝”，当某个异常条件被触发，直接熔断整个服务，返回，不是等到此服务超时。

　　  　　 　　通过@HystrixCommand(fallbackMethod ="hystrix_GET" )  //去找备选响应，进行服务降级

 　  服务降级：降级一般是从整体负荷考虑，当某个服务熔断之后，服务器将不再被调用，客户端可自己准备一个本地的fallback回调，返回一个缺省值，虽然服务水平下降，当能用，比直接挂掉要强。

微服务怎么做高可用？

1、从技术看高可用：

主要使用的技术手段是服务和数据的冗余备份和失效转移，一组服务或一组数据都能在多节点上，之间相互备份。

当一台机器宕机或出现问题的时候，可以从当前的服务切换到其他可用的服务，不影响系统的可用性，也不会导致数据丢失。

2、从架构看高可用：

保持简单的架构，目前多数网站采用的是比较经典的分层架构，应用层，服务层，数据层。

应用层是处理一些业务逻辑，服务层提供一些数据和业务紧密相关服务，数据层负责对数据进行读写。

简单的架构可以使应用层，服务层可以保持无状态化进行水平扩展，这个属于计算高可用。

3、从硬件看高可用：

首先得确认硬件总是可能坏的，网络总是不稳定的。解决它的方法也是一个服务器不够就来多几个，一个机柜不够就来几个，一个机房不够就来几个。

4、从软件看高可用：

软件的开发不严谨，发布不规范也是导致各种不可用出现，通过控制软件开发过程质量监控，通过测试，预发布，灰度发布等手段也是减少不可用的措施。

5、从服务管理看：

将服务规范化，事前做好服务分割，做好服务监控，预判不可用的出现，在不可用出现之前发现问题，解决问题。