微服务
Q:为什么要用微服务？微服务有哪些优势？
单体应用把所有功能都堆放在一起，改动影响大，风险高。
微服务具有以下优势：
针对特定服务发布，影响小，风险小，成本低。
频繁发布版本，快速交付需求。
低成本扩容，弹性伸缩，适应云环境。
Q:怎么解决服务调用闭环(循环依赖)？
服务分层，设定groupId。比如分为上层服务，中间层服务，底层服务。
上层服务可以调用中间层、底层服务，底层服务不允许调用上层服务。
Q:如何拆分微服务？
按功能模块拆分。按DDD（领域驱动设计）拆分。
Q:你们的服务划分了几个模块？分别是哪些模块？
几十个模块。
DDD
Q:DDD的聚合根，实体，值对象的区别和联系是什么？
参见： https://www.cnblogs.com/netfocus/p/5145345.html
Rpc
Q:RPC和Restful分别有哪些优劣性？
RPC协议性能要高的多，吞吐量比http大。响应也更快。
RPC常见的序列化协议包括json、xml、hession、protobuf、thrift、text、bytes等；
Restful使用http协议。http相对更规范，更标准，更通用，无论哪种语言都支持http协议
Q:为什么Rpc的性能比RestFul好一些？
RESTful是基于HTTP协议进行交互的，HTTP协议包含大量的请求头、响应头信息。
而Rpc（比如dubbo)是基于(dubbo)自定义的二进制协议进行传输，消息体比较简单，传输数据要小很多。
Q:如果想实现一个Rpc框架，需要考虑哪些东西？
动态代理、反射、序列化、反序列化、网络通信(netty)、编解码、服务发现和注册、心跳与链路检测。
参考资料：https://www.cnblogs.com/flzs/p/12174686.html
Q:服务端如何确定客户端要调用的函数？
在远程调用中，客户端和服务端分别维护一个【ID->函数】的对应表， ID在所有进程中都是唯一确定的。客户端在做远程过程调用时，附上这个ID，服务端通过查表，来确定客户端需要调用的函数，然后执行相应函数的代码。(如果自己去设计一个RPC，可以使用一个Map去保存这些键值对)
Dubbo
Q:讲一下Dubbo
服务提供者提供服务，服务消费者可以通过Rpc进行服务消费。
Q:Dubbo支持哪些协议？
Dubbo支持Dubbo、rmi、hessian、http、webservice、thrift、Redis等多种协议
Q:Dubbo默认的协议是什么？
Dubbo协议。
Q:Dubbo的序列化有哪些方式？
默认协议：dubbo协议。序列化：hession二进制。
dubbo协议。连接方式：长连接。
其他协议：
rmi协议。连接方式：短连接。序列化：java自带的二进制。
hessian。连接方式：短连接。序列化：表单序列化。
Q:Dubbo和SpringCloud有哪些区别？
Dubbo是Soa(面向服务的架构)，SpringCloud是微服务架构，除了服务，还有注册中心、熔断、配置中心。
Dubbo基于Rpc(远程过程调用)，SpringCloud基于restFul，基于http协议。
Q:Soa和微服务架构，有哪些区别？
Q:Dubbo的服务提供者、服务消费者需要配置哪些信息？
服务提供者需要配置ip、端口、Dubbo协议、注册中心地址等
Q:Dubbo有哪些负载均衡策略？
一致性Hash均衡算法、随机调用法、轮询法、最少活动调用法。
Q:讲一下Dubbo的SPI机制。
Q:你们用的是哪个版本的Dubbo?
SpringCloud(微服务)
Q:你用过SpringCloud的哪些组件？
服务协调，注册中心，熔断，降级，配置中心，网关。
Eureka 注册中心/服务治理
Q:讲一下Eureka.
Eureka分为服务注册中心，服务提供者 ，服务消费者。服务提供者 、服务消费者都必须指定注册中心。服务提供者提供服务，而服务消费者可以调用提供者的服务。
Q:Eureka是怎么和服务通信的？
心跳机制。
Q:Eureka有哪些特性？
服务提供者有以下特性：
服务续约：在注册完服务之后，服务提供者会维护一个心跳机制用来持续告诉Eureka Server: "我还活着 ” 。
EurekaServer有以下特性：
失效剔除：默认每隔一段时间（默认为60秒） 将当前清单中超时（默认为90秒）没有续约的服务剔除出去。
自我保护：EurekaServer 在运行期间，会统计心跳失败的比例在15分钟之内是否低于85%(通常由于网络不稳定导致)。 Eureka Server会将当前的实例注册信息保护起来， 让这些实例不会过期，尽可能保护这些注册信息。
Q:Eureka怎么保证高可用？
多个注册中心互相注册。
Eureka Server的高可用实际上就是将自己作为服务向其他服务注册中心注册自己,这样就可以形成一组互相注册的服务注册中心,以实现服务清单的互相同步,达到高可用的效果。
Q:Eureka注册中心和Zookeeper注册中心，有什么区别？
Eureka注重高可用，属于CAP中的AP。
Zookeeper注重一致性，属于CAP中的CP。
Q:除了Zookeeper，你用过哪些注册中心?有什么区别？
Zookeeper，Redis，Eureka
Zookeeper，是分布式中的CP，能够更好地保证分布式一致性。
Redis基于发布/订阅模式。
Eureka在SpringCloud中应用较多。Eureka是分布式中的AP，也就是注重可用性。
服务消费 Feign
Q:讲一下Feign。
Q:为什么要使用Feign？
Feign可以进行服务消费，Feign内置了Hystrix和Eureka。
1.feign采用的是基于接口的注解。
2.feign整合了ribbon，具有负载均衡的能力。
3.整合了Hystrix，具有熔断的能力。
Q:Feign使用了哪些协议？
Http协议。
Q:Feign底层原理。
动态代理。
服务消费 Ribbon
Q:SpringCloud如何进行负载均衡？
使用Ribbon.
Q:Ribbon有哪些功能？
负载均衡，重试机制。
Q:Ribbon有哪些负载均衡的策略？
常用的有：轮询，随机，加权。
随机策略：随机选择server.
轮询策略：按照顺序选择server（ribbon默认策略）.
重试策略：在一个配置时间段内，当选择server不成功，则一直尝试选择一个可用的server.
最低并发策略：逐个考察server，如果server断路器打开，则忽略，再选择其中并发链接最低的server.
可用过滤策略：过滤掉一直失败并被标记为circuit tripped的server，过滤掉那些高并发链接的server（active connections超过配置的阈值）.
响应时间加权重策略:根据server的响应时间分配权重，响应时间越长，权重越低，被选择到的概率也就越低。响应时间越短，权重越高，被选中的概率越高，这个策略很贴切，综合了各种因素，比如：网络，磁盘，io等，都直接影响响应时间.
区域权重策略: 综合判断server所在区域的性能，和server的可用性，轮询选择server并且判断一个AWS Zone的运行性能是否可用，剔除不可用的Zone中的所有server.
参考： https://www.cnblogs.com/idoljames/p/11698923.html
Hystrix熔断
Q:讲一下Hystrix。为什么要使用熔断？
当某个服务发生故障（类似用电器发生短路）之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个错误响应，而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放，避免了故障在分布式系统中的蔓延。
使用熔断，可以避免服务雪崩。
Q:Hystrix熔断的原理是什么？
"舱壁模式"，实现进程线程池的隔离，它会为每一个服务创建一个独立的线程池，这样就算某个服务出现延迟过高的情况，也不会拖慢其他的服务。
Q:Hystrix熔断有哪几种方隔离方式？
线程池隔离。信号量隔离。
Q:这两种隔离模式，有什么区别？
在大部分情况下，使用线程池隔离会有非常微小的延迟(9ms)，可以忽略不计。
如果对延迟的要求非常高的话，可以使用信号量隔离。
信号量的开销远比线程池的开销小，但是信号量不能设置超时，也没法实现异步访问。
Q:什么时候会触发熔断？什么时候断路器的状态会发生变化？
当QPS达到20，或者请求失败率达到50%，断路器就会变成打开，就会触发熔断。
断路器变成打开状态后，会进行休眠，默认5秒，在到达休眠时间后，将再次允许请求尝试访问，此时为"半开状态"，若此时请求继续失败，那断路器又会进入"打开状态"，如此循环。
Q:熔断如何设置超时时间，重试次数？
如果超时时间设置过短，或者重试次数过多，会频繁地重试，加大服务的压力。
如果超时时间设置过长，可能会导致请求响应慢，导致阻塞、卡顿。
超时时间设置：方案一，按照服务提供者线上真实的服务水平，取 P999 或者 P9999 的值，也就是以 99.9% 或者 99.99% 的调用都在多少毫秒内返回为准。
方案二，按照接口重要性来进行设置，并发低的接口设置的超时时间可以多点，比如2s，并发高的接口设置的超时时间可以设置的低点，比如200ms。
重试时间设置：一两次即可。大部分情况下，调用失败都是因为偶发的网络问题或者个别服务提供者节点有问题导致的，如果能换个节点再次访问说不定就能成功。
如果是读比较多的服务，重试次数设置多一些也没关系。如果是写比较多的服务，最好还是减少重试次数，或者不设置重试，否则容易出错。
Q:讲一下熔断和降级的区别？
熔断是直接返回一个错误响应。
服务降级是采取备用逻辑。
服务降级：当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运作或高效运作。
在服务降级逻辑中，我们需要实现一个通用的响应结果，并且该降级逻辑应该是从缓存或者是一些降级逻辑中获取，而不是依赖网络请求获取，这样能够稳定地返回结果的处理逻辑。
Q:Hystrix什么时候会触发服务降级？
当前Hystrix命令处于"熔断/短路"状态，断路器是打开的时候。
当前Hystrix命令的线程池，请求队列，或者信号量被占满的时候。
Zuul网关
Q:Zuul网关，有什么功能？
Zuul能够进行过滤(Filter)，设置白名单。
Zuul还能进行请求路由/服务路由。
路由功能，负责将外部请求功能转发到具体的微服务实例上，是实现外部访问统一入口的基础。
Q:Zuul网关如何实现路由？
通过服务路由的功能，在对外提供服务的时候，只需要通过暴露Zuul中配置的调用地址就可以让调用方统一的来访问我们的服务，而不需要了解具体提供服务的主机信息了。
Q:Zuul有几种过滤器类型？
4种。
pre : 可以在请求被路由之前调用。
适用于身份认证的场景，认证通过后再继续执行下面的流程。
route : 在路由请求时被调用。
适用于灰度发布场景，在将要路由的时候可以做一些自定义的逻辑。
post :在 route 和 error 过滤器之后被调用。
这种过滤器将请求路由到达具体的服务之后执行。适用于需要添加响应头，记录响应日志等应用场景。
error : 处理请求时发生错误时被调用。
在执行过程中发送错误时会进入 error 过滤器，可以用来统一记录错误信息。
Q:Gateway和Zuul有什么区别和联系？
Zuul：
使用的是阻塞式的 API，不支持长连接，比如 websockets。
底层是servlet，Zuul处理的是http请求
没有提供异步支持，流控等均由hystrix支持。
依赖包spring-cloud-starter-netflix-zuul。
Gateway：
底层依然是servlet，但使用了webflux，多嵌套了一层框架。
依赖spring-boot-starter-webflux和/ spring-cloud-starter-gateway。
提供了异步支持，提供了抽象负载均衡，提供了抽象流控，并默认实现了RedisRateLimiter。
-
相同点：
1、底层都是servlet
2、两者均是web网关，处理的是http请求 -
不同点：
1、内部实现：
gateway对比zuul多依赖了spring-webflux，在spring的支持下，功能更强大，内部实现了限流、负载均衡等，扩展性也更强，但同时也限制了仅适合于Spring Cloud套件
zuul则可以扩展至其他微服务框架中，其内部没有实现限流、负载均衡等。
2、是否支持异步：
zuul仅支持同步。
gateway支持异步。理论上gateway则更适合于提高系统吞吐量（但不一定能有更好的性能），最终性能还需要通过严密的压测来决定。
3、框架设计的角度：
gateway具有更好的扩展性，并且其已经发布了2.0.0的RELESE版本，稳定性也是非常好的。
4、性能：
WebFlux 模块的名称是 spring-webflux，名称中的 Flux 来源于 Reactor 中的类 Flux。Spring webflux 有一个全新的非堵塞的函数式 Reactive Web 框架，可以用来构建异步的、非堵塞的、事件驱动的服务，在伸缩性方面表现非常好。使用非阻塞API。 Websockets得到支持，并且由于它与Spring紧密集成，所以将会是一个更好的开发体验。
参考：https://www.cnblogs.com/lgg20/p/12507845.html
SpringCould Config配置中心
Q:讲一下Config。
配置管理工具包，让你可以把配置放到远程服务器，集中化管理集群配置，目前支持本地存储、Git以及Subversion。
"一次配置，随处可用"。