网站建设一年600,js做的网站,帝国cms手机网站,wordpress展示页面模板下载java微服务面试题 Q:为什么要用微服务#xff1f;微服务有哪些优势#xff1f; 单体应用把所有功能都堆放在一起#xff0c;改动影响大#xff0c;风险高。 微服务具有以下优势#xff1a; 针对特定服务发布#xff0c;影响小#xff0c;风险小#xff0c;成本低。 频…java微服务面试题 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)自定义的二进制协议进行传输基于TCP长连接消息体比较简单传输数据要小很多。 Q:如果想实现一个Rpc框架需要考虑哪些东西 动态代理、反射、序列化、反序列化、网络通信(netty)、编解码、服务发现和注册、心跳与链路检测。 参考资料https://www.cnblogs.com/flzs/p/12174686.html Q:服务端如何确定客户端要调用的函数 在远程调用中客户端和服务端分别维护一个【ID-函数】的对应表 ID在所有进程中都是唯一确定的。客户端在做远程过程调用时附上这个ID服务端通过查表来确定客户端需要调用的函数然后执行相应函数的代码。(如果自己去设计一个RPC可以使用一个Map去保存这些键值对) Q:讲一下Rpc的整个过程。 两台服务器AB一个应用部署在A服务器上想要调用B服务器上应用提供的函数/方法由于不在一个内存空间不能直接调用需要通过网络来表达调用的语义和传达调用的数据。 比如说A服务器想调用B服务器上的一个方法 1、建立通信 首先要解决通讯的问题即A机器想要调用B机器首先得建立起通信连接。 主要是通过在客户端和服务器之间建立TCP连接远程过程调用的所有交换的数据都在这个连接里传输。连接可以是按需连接调用结束后就断掉也可以是长连接多个远程过程调用共享同一个连接。 通常这个连接可以是按需连接需要调用的时候就先建立连接调用结束后就立马断掉也可以是长连接客户端和服务器建立起连接之后保持长期持有不管此时有无数据包的发送可以配合心跳检测机制定期检测建立的连接是否存活有效多个远程过程调用共享同一个连接。 2、服务寻址 要解决寻址的问题也就是说A服务器上的应用怎么告诉底层的RPC框架如何连接到B服务器如主机或IP地址以及特定的端口方法的名称名称是什么。 通常情况下我们需要提供B机器主机名或IP地址以及特定的端口然后指定调用的方法或者函数的名称以及入参出参等信息这样才能完成服务的一个调用。 可靠的寻址方式主要是提供服务的发现是RPC的实现基石比如可以采用Zookeeper来注册服务等等。 2.1、从服务提供者的角度看 当服务提供者启动的时候需要将自己提供的服务注册到指定的注册中心以便服务消费者能够通过服务注册中心进行查找 当服务提供者由于各种原因致使提供的服务停止时需要向注册中心注销停止的服务 服务的提供者需要定期向服务注册中心发送心跳检测服务注册中心如果一段时间未收到来自服务提供者的心跳后认为该服务提供者已经停止服务则将该服务从注册中心上去掉。 2.2、从调用者的角度看: 服务的调用者启动的时候根据自己订阅的服务向服务注册中心查找服务提供者的地址等信息 当服务调用者消费的服务上线或者下线的时候注册中心会告知该服务的调用者服务调用者下线的时候则取消订阅。 3、网络传输 3.1、序列化 当A机器上的应用发起一个RPC调用时调用方法和其入参等信息需要通过底层的网络协议如TCP传输到B机器由于网络协议是基于二进制的所有我们传输的参数数据都需要先进行序列化Serialize或者编组marshal成二进制的形式才能在网络中进行传输。然后通过寻址操作和网络传输将序列化或者编组之后的二进制数据发送给B机器。 3.2、反序列化 当B机器接收到A机器的应用发来的请求之后又需要对接收到的参数等信息进行反序列化操作序列化的逆操作即将二进制信息恢复为内存中的表达方式然后再找到对应的方法寻址的一部分进行本地调用一般是通过生成代理Proxy去调用, 通常会有JDK动态代理、CGLIB动态代理、Javassist生成字节码技术等之后得到调用的返回值。 4、服务调用 B机器进行本地调用通过代理Proxy和反射调用之后得到了返回值此时还需要再把返回值发送回A机器同样也需要经过序列化操作然后再经过网络传输将二进制数据发送回A机器而当A机器接收到这些返回值之后则再次进行反序列化操作恢复为内存中的表达方式最后再交给A机器上的应用进行相关处理一般是业务逻辑处理操作。 通常经过以上四个步骤之后一次完整的RPC调用算是完成了另外可能因为网络抖动等原因需要重试等。 详情见 https://blog.csdn.net/m0_48795607/article/details/116237861 Dubbo面试题 想了解Dubbo可以多看一下Dubbo的官方文档。 官方文档地址 https://dubbo.apache.org/zh/docs/introduction/ Q:讲一下Dubbo 0.服务容器负责启动加载运行服务提供者。 1.服务提供者在启动时向注册中心注册自己提供的服务。 2.服务消费者在启动时向注册中心订阅自己所需的服务。 3.注册中心返回服务提供者地址列表给消费者如果有变更注册中心将基于长连接推送变更数据给消费者。 4.服务消费者从提供者地址列表中基于负载均衡算法选一台提供者进行调用如果调用失败再选另一台调用。 5.服务消费者和提供者在内存中累计调用次数和调用时间定时每分钟发送一次统计数据到监控中心。 Q:讲一下Dubbo的分层架构图。 官网地址 https://dubbo.apache.org/zh/docs3-v2/java-sdk/concepts-and-architecture/code-architecture/ Dubbo大的三层分别为 Business业务层、RPC 层、Remoting并且还分为 API 层和 SPI 层。 Dubbo的整体设计分 10 层 接口服务层Service该层与业务逻辑相关根据provider和consumer的业务设计对应的接口和实现 配置层Config对外配置接口以ServiceConfig和ReferenceConfig为中心服务 代理层Proxy服务接口透明代理生成服务的客户端Stub 和服务端的Skeleton以ServiceProxy 为中心扩展接口为ProxyFactory。 服务注册层Registry封装服务地址的注册和发现以服务URL为中心扩展接口为RegistryFactory、Registry、RegistryService。 路由层Cluster封装多个提供者的路由和负载均衡并桥接注册中心以Invoker为中心扩展接口为Cluster、Directory、Router和LoadBlancce。 监控层MonitorRPC调用次数和调用时间监控以Statistics 为中心扩展接口为MonitorFactory、Monitor和 MonitorService。 远程调用层Protocal封装RPC调用以Invocation和Result为中心扩展接口为Protocal、Invoker和Exporter。 信息交换层Exchange封装请求响应模式同步转异步。以 Request和Response为中心扩展接口为Exchanger、 ExchangeChannel、ExchangeClient和ExchangeServer。 网络传输层Transport抽象mina和 netty 为统一接口以 Message为中心扩展接口为Channel、Transporter、Client、Server和Codec。 数据序列化层Serialize可复用的一些工具扩展接口为Serialization、ObjectInput、ObjectOutput和ThreadPool。 Dubbo的服务治理 Q:Dubbo的服务提供者、服务消费者需要配置哪些信息 服务提供者需要配置ip、端口、Dubbo协议、注册中心地址等 Q:Dubbo Consumer(服务消费者)每次调用服务都要去查一次注册中心么 可以在消费端会进行缓存通过配置缓存文件的路径开启。 dubbo:registry idzookeeper addresszookeeper://192.*.*.*:2181 filed:/dubbo-server /Q:Dubbo可以对结果进行缓存吗 为了提高数据访问的速度。Dubbo提供了声明式缓存以减少用户加缓存的工作量dubbo:reference cache“true” / 其实比普通的配置文件就多了一个标签 cache“true”。 Q:Dubbo的注册中心集群挂掉发布者和订阅者之间还能通信么 可以通讯。启动Dubbo 时消费者会从Zookeeper拉取注册的生产者的地址接口等数据缓存在本地。每次调用时按照本地存储的地址进行调用。 注册中心对等集群任意一台宕机后将会切换到另一台注册中心全部宕机后服务的提供者和消费者仍能通过本地缓存通讯。 服务提供者无状态任一台宕机后不影响使用服务提供者全部宕机服务消费者会无法使用并无限次重连等待服务者恢复 Q:Dubbo服务调用是阻塞的吗 默认是阻塞的可以异步调用没有返回值的可以这么做。 Dubbo是基于NIO的非阻塞实现并行调用客户端不需要启动多线程即可完成并行调用多个远程服务相对多线程开销较小异步调用会返回一个Future对象。 Q:Dubbo异步调用的原理是什么 在 Dubbo 中发起异步调用。从 2.7.0 开始Dubbo 的所有异步编程接口开始以 CompletableFuture 为基础 基于 NIO 的非阻塞实现并行调用客户端不需要启动多线程即可完成并行调用多个远程服务相对多线程开销较小。 服务消费者调用服务提供者: //调用服务 asyncService.sayHello(world); // 拿到调用的Future引用当结果返回后会被通知和设置到此Future CompletableFutureString future RpcContext.getContext().getCompletableFuture(); // 为Future添加回调 future.whenComplete((retValue, exception) - {if (exception null) {System.out.println(retValue);} else {exception.printStackTrace();} });异步调用的官网地址 https://dubbo.apache.org/zh/docs/v2.7/user/examples/async-call/ Q:Dubbo服务调用超时了会怎么样 重试可以设置超时的时间以及设置重试的次数。 !-- 延迟到Spring初始化完成后再暴露服务,服务调用超时设置为6秒,超时重试3次-- dubbo:provider delay-1 timeout6000 retries3/Q:Dubbo 超时时间怎样设置 Dubbo 超时时间设置有两种方式 服务提供者端设置超时时间在 Dubbo 的用户文档中推荐如果能在服务端多配置就尽量多配置因为服务提供者比消费者更清楚自己提供的服务特性。服务消费者端设置超时时间如果在消费者端设置了超时时间以消费者端为主即优先级更高。因为服务调用方设置超时时间控制性更灵活。如果消费方超时服务端线程不会定制会产生警告。 Q:dubbo线程池满了怎么办? dubbo的线程池有多种类型 fixed:包含固定个数线程 cached:不限制线程个数线程空闲一分钟会被回收当新请求到来时会创建新线程 limited:线程个数随着任务增加而增加但不会超过最大阈值。空闲线程不会被回收 eager:当所有核心线程数都处于忙碌状态时优先创建新线程执行任务而不是立即放入队列。dubbo默认的线程池配置 dubbo:protocol namedubbo dispatcherall threadpoolfixed threads200 /线程池打满了可以先改成 cached 类型的线程池。并提高支持的threads线程数。(存疑) 线程池打满的问题排查 线程池打满后拒绝策略会输出线程快照文件以保护现场在分析线程快照文件时BLOCKED和TIMED_WAITING线程状态需要我们重点关注。如果发现大量线程阻塞或者等待状态则可以定位到具体代码行。 详情见 https://blog.csdn.net/woshixuye/article/details/115797017 Q:Dubbo使用过程中都遇到了些什么问题 (1)在注册中心找不到对应的服务,检查service实现类是否添加了service注解或者xml配置 检查下dubbo的服务提供者、消费者是否配置了接口。 如果服务暴露时和服务订阅时使用了 group 和 version 配置 要确认服务方provider 和消费方consumer 之间的group/version要对应得上 如果没有对应上也会报 RpcException 这个错误。 详情见 https://www.cnblogs.com/expiator/p/16496244.html (2)无法连接到注册中心,检查配置文件中的对应的ip、端口是否正确。 Q:服务上线怎么兼容旧版本 可以用版本号version过渡多个不同版本的服务注册到注册中心版本号不同的服务相互间不引用。 Q:Dubbo的集群容错模式有哪些 默认的容错方案是Failover Cluster。 集群容错模式(策略)特性缺点Failover Cluster(失败自动切换)当出现失败重试其它服务器通常用于读操作推荐使用重试会带来更长延迟Failfast Cluster(快速失败)只发起一次调用失败立即报错,通常用于非幂等性的写操作如果有机器正在重启可能会出现调用失败Failsafe Cluster(失败安全)出现异常时直接忽略通常用于写入审计日志等操作调用信息丢失Failback Cluster(失败自动恢复)后台记录失败请求定时重发通常用于消息通知操作不可靠重启丢失Forking Cluster(并行调用多个服务器)只要一个成功即返回通常用于实时性要求较高的读操作需要浪费更多服务资源Broadcast Cluster(广播调用所有提供者)逐个调用任意一台报错则报错通常用于更新提供方本地状态速度慢任意一台报错则报错 Q:Dubbo有哪些负载均衡策略 随机调用法、轮询法、最少活跃调用数、一致性Hash均衡算法。 (1)Random LoadBalance随机按权重设置随机概率推荐使用 缺陷在一个截面上碰撞的概率高重试时可能出现瞬间压力不均 推荐使用的原因在一个截面上碰撞的概率高但调用量越大分布越均匀而且按概率使用权重后也比较均匀有利于动态调整提供者权重。 (2)RoundRobin LoadBalance轮询按公约后的权重设置轮询比率 缺陷存在慢的机器累积请求问题比如第二台机器很慢但没挂当请求调到第二台时就卡在那久而久之所有请求都卡在调到第二台上。 极端情况可能产生雪崩。 (3)LeastActive LoadBalance最少活跃调用数相同活跃数的随机活跃数指调用前后计数差使慢的机器收到更少请求 缺陷不支持权重在容量规划时不能通过权重把压力导向一台机器压测容量 (4)ConsistentHash LoadBalance一致性Hash相同参数的请求总是发到同一提供者当某一台提供者挂时原本发往该提供者的请求基于虚拟节点平摊到其它提供者不会引起剧烈变动 缺陷压力分摊不均 Q:Dubbo SPI和Java SPI区别 答JDK SPI JDK标准的SPI会一次性加载所有的扩展实现如果有的扩展吃实话很耗时但也没用上很浪费资源。 所以只希望加载某个的实现就不现实了。 DUBBO SPI 1对 Dubbo进行扩展不需要改动Dubbo的源码 2延迟加载可以一次只加载自己想要加载的扩展实现。 3增加了对扩展点IOC和AOP的支持一个扩展点可以直接setter注入其它扩展点。 4Dubbo的扩展机制能很好的支持第三方IoC容器默认支持Spring Bean。 Q:Dubbo支持哪些协议 Dubbo支持Dubbo、rmi、hessian、http、webservice、thrift、Redis等多种协议。 默认协议Dubbo协议。 Dubbo单一长连接和NIO异步通讯适合大并发小数据量的服务调用以及消费者远大于提供者。传输协议TCP异步 Hessian序列化。Dubbo推荐使用Dubbo协议。 RMI 采用JDK标准的RMI协议实现传输参数和返回参数对象需要实现 Serializable 接口使用 Java 标准序列化机制使用阻塞式短连接传输数据包大小混合消费者和提供者个数差不多可传文件传输协议TCP。 多个短连接 TCP协议传输同步传输适用常规的远程服务调用和RMI互操作。在依赖低版本的Common-Collections 包Java 序列化存在安全漏洞。 WebService基于WebService的远程调用协议集成CXF实现提供和原生WebService的互操作。多个短连接基于 HTTP 传输同步传输适用系统集成和跨语言调用。 HTTP 基于 Http 表单提交的远程调用协议使用Spring的HttpInvoke 实现。多个短连接传输协议HTTP传入参数大小混合提供者个数多于消费者需要给应用程序和浏览器JS调用。 Hessian集成 Hessian 服务基于 HTTP 通讯采用 Servlet暴露服务Dubbo 内嵌 Jetty 作为服务器时默认实现提供与 Hession 服务互操作。多个短连接同步 HTTP 传输Hessian 序列化传入参数较大提供者大于消费者提供者压力较大可传文件。 Memcache基于Memcache实现的RPC协议。 Redis基于Redis实现的RPC协议。 Q:Dubbo的序列化有哪些方式 hession、Duddo、Json、java序列化 Q:Dubbo协议有什么特点 连接个数单连接 连接方式长连接 传输协议TCP 传输方式NIO 异步传输 序列化Hessian 二进制序列化 适用范围传入传出参数数据包较小建议小于100K消费者比提供者个数多单一消费者无法压满提供者 尽量不要用 dubbo 协议传输大文件或超大字符串。 适用场景常规远程服务方法调用 Q:dubbo 通信协议 dubbo 协议为什么采用异步单一长连接 因为服务的现状大都是服务提供者少通常只有几台机器 而服务的消费者多可能整个网站都在访问该服务 比如 Morgan 的提供者只有 6 台提供者却有上百台消费者每天有 1.5 亿次调用 如果采用常规的 hessian 服务服务提供者很容易就被压跨 通过单一连接保证单一消费者不会压死提供者 长连接减少连接握手验证等 并使用异步 IO复用线程池。 – 参考自《Dubbo面试专题及答案》 Q:Dubbo Monitor实现原理 (1)Consumer端在发起调用之前会先走 filter 链provider端在接收到请求时也是先走filter链然后才进行真正的业务逻辑处理。默认情况下在consumer和provider的filter链中都会有Monitorfilter。 MonitorFilter向DubboMonitor发送数据。 (2)DubboMonitor将数据进行聚合后默认聚合 1min 中的统计数据暂存到ConcurrentMapStatistics, AtomicReference statisticsMap然后使用一个含有3个线程线程名字DubboMonitorSendTimer的线程池每隔 1min 钟调用SimpleMonitorService遍历发送statisticsMap中的统计数据每发送完毕一个就重置当前的 Statistics 的AtomicReference。 (3)SimpleMonitorService 将这些聚合数据塞入BlockingQueue queue中队列大写为 100000 (4)SimpleMonitorService 使用一个后台线程线程名为DubboMonitorAsyncWriteLogThread 将queue中的数据写入文件该线程以死循环的形式来写 (5)SimpleMonitorService 还会使用一个含有1个线程线程名字DubboMonitorTimer的线程池每隔5min钟将文件中的统计数据画成图表 Q:Dubbo和SpringCloud有哪些区别 Dubbo是Soa(面向服务的架构)SpringCloud是微服务架构除了服务还有注册中心、熔断、配置中心。 Dubbo基于Rpc(远程过程调用)SpringCloud基于restFul基于http协议。 最大的区别 Dubbo 底层是使用 Netty 这样的 NIO 框架是基于TCP 协议传输的配合序列化完成 RPC 通信。 而 SpringCloud 是基于 Http 协议Rest 接口调用通信相对来说 Http 请求会有更大的报文占的带宽也会更多。 Q:讲一下Dubbo的SPI机制。 Q:你们用的是哪个版本的Dubbo? Q:Dubbo配置文件是如何加载到Spring中的 Spring容器在启动的时候会读取到Spring默认的一些schema以及Dubbo自定义的schema每个schema都会对应一个自己的NamespaceHandlerNamespaceHandler里面通过BeanDefinitionParser来解析配置信息并转化为需要加载的 bean 对象。 Q:Dubbo用到哪些设计模式 Dubbo框架在初始化和通信过程中使用了多种设计模式可灵活控制类加载、权限控制等功能。 (1)工厂模式: Provider在export服务时会调用ServiceConfig的export方法。ServiceConfig中有个字段 private static final Protocol protocol ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();Dubbo里有很多这种代码。这也是一种工厂模式只是实现类的获取采用了JDKSPI的机制。这么实现的优点是可扩展性强想要扩展实现只需要在classpath下增加个文件就可以了代码零侵入。另外像上面的Adaptive实现可以做到调用时动态决定调用哪个实现但是由于这种实现采用了动态代理会造成代码调试比较麻烦需要分析出实际调用的实现类。 (2)装饰器模式: Dubbo在启动和调用阶段都大量使用了装饰器模式。以 Provider提供的调用链为例具体的调用链代码是在ProtocolFilterWrapper 的buildInvokerChain完成的具体是将注解中含有groupprovider的Filter实现按照order排序。 EchoFilter - ClassLoaderFilter - GenericFilter - ContextFilter - ExecuteLimitFilter - TraceFilter - TimeoutFilter - MonitorFilter - ExceptionFilter更确切地说这里是装饰器和责任链模式的混合使用。例如EchoFilter的作用是判断是否是回声测试请求是的话直接返回内容这是一种责任链的体现。而像ClassLoaderFilter则只是在主功能上添加了功能更改当前线程的ClassLoader这是典型的装饰器模式。 (3)观察者模式: Dubbo的Provider启动时需要与注册中心交互先注册自己的服务再订阅自己的服务订阅时采用了观察者模式开启一个listener。注册中心会每5秒定时检查是否有服务更新如果有更新向该服务的提供者发送一个notify消息provider接受到notify消息后即运行NotifyListener的notify方法执行监听器方法。 (4)动态代理模式: Dubbo扩展JDK SPI的类ExtensionLoader的Adaptive实现是典型的动态代理实现。Dubbo需要灵活地控制实现类即在调用阶段动态地根据参数决定调用哪个实现类所以采用先生成代理类的方法能够做到灵活的调用。生成代理类的代码是ExtensionLoader的createAdaptiveExtensionClassCode方法。代理类的主要逻辑是获取URL参数中指定参数的值作为获取实现类的key。 ###Zookeeper 面试题 参考资料 https://blog.csdn.net/wanghaiping1993/article/details/125396988 ###Zookeeper 注册中心 Q:Zookeeper为什么能做注册中心 Zookeeper的数据模型是树型结构由很多数据节点组成zk将全量数据存储在内存中可谓是高性能而且支持集群可谓高可用。 另外Zookeeper支持事件监听(watch命令)。客户端可以对zookeeper上的数据节点进行Watch监听数据节点的变化如果数据节点发生变化那么所有订阅的客户端都能够接收到通知。 Q:Zookeeper做为注册中心主要存储哪些数据存储在哪里 ip、端口、协议。数据存储在Zookeeper的节点上面。 Q:心跳机制有什么用 Q:服务提供者能实现失效踢出是什么原理 服务失效剔除基于zookeeper 的临时节点原理。 Q:讲一下Zookeeper的系统架构。 1ZooKeeper分为服务器端Server 和客户端Client客户端可以连接到整个ZooKeeper服务的任意服务器上除非 leaderServes 参数被显式设置 leader 不允许接受客户端连接。 2客户端使用并维护一个 TCP 连接通过这个连接发送请求、接受响应、获取观察的事件以及发送心跳。如果这个 TCP 连接中断客户端将自动尝试连接到另外的 ZooKeeper服务器。客户端第一次连接到 ZooKeeper服务时接受这个连接的 ZooKeeper服务器会为这个客户端建立一个会话。当这个客户端连接到另外的服务器时这个会话会被新的服务器重新建立。 3每一个Server代表一个安装Zookeeper服务的机器即是整个提供Zookeeper服务的集群或者是由伪集群组成 4组成ZooKeeper服务的服务器必须彼此了解。它们维护一个内存中的状态图像以及持久存储中的事务日志和快照 只要大多数服务器可用ZooKeeper服务就可用 5ZooKeeper 启动时将从实例中选举一个 leaderLeader 负责处理数据更新等操作一个更新操作成功的标志是当且仅当大多数Server在内存中成功修改数据。每个Server 在内存中存储了一份数据。 6Zookeeper是可以集群复制的集群间通过Zab协议Zookeeper Atomic Broadcast来保持数据的一致性 7Zab协议包含两个阶段leader election阶段和Atomic Brodcast阶段。 a) 集群中将选举出一个leader其他的机器则称为follower所有的写操作都被传送给leader并通过brodcast将所有的更新告诉给follower。 b) 当leader崩溃或者leader失去大多数的follower时需要重新选举出一个新的leader让所有的服务器都恢复到一个正确的状态。 c) 当leader被选举出来且大多数服务器完成了 和leader的状态同步后leadder election 的过程就结束了就将会进入到Atomic brodcast的过程。 d) Atomic Brodcast同步leader和follower之间的信息保证leader和follower具有形同的系统状态。 Q:Zookeeper的原理是什么 Q:Zookeeper是怎么保证一致性的 zab协议。 zab协议有两种模式它们分别是恢复模式选主和广播模式同步。当服务启动或者在领导者崩溃后zab就进入了恢复模式当领导者被选举出来且大多数server完成了和 leader的状态同步以后恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。 Q:Zookeeper有哪些应用场景 Zookeeper可以作为服务协调的注册中心。还可以做分布式锁(如果没有用过分布式锁就不要说) Q:Zookeeper的节点有哪些类型有什么区别 临时节点永久节点。 更加细分就是临时有序节点、临时无序节点、永久有序节点、永久无序节点。　　 临时节点 当创建临时节点的程序停掉之后这个临时节点就会消失存储的数据也没有了。 Q:说说Zookeeper中的ACL 权限控制机制。 UGOUser/Group/Others目前在 Linux/Unix 文件系统中使用也是使用最广泛的权限控制方式。是一种粗粒度的文件系统权限控制模式。 ACLAccess Control List访问控制列表包括三个方面 权限模式Scheme 1IP从 IP 地址粒度进行权限控制 2Digest最常用用类似于 username:password 的权限标识来进行权限配置便于区分不同应用来进行权限控制 3World最开放的权限控制方式是一种特殊的 digest 模式只有一个权限标识“world:anyone” 4Super超级用户 授权对象授权对象指的是权限赋予的用户或一个指定实体例如 IP 地址或是机器灯。 权限 Permission 1CREATE数据节点创建权限允许授权对象在该 Znode 下创建子节点 2DELETE子节点删除权限允许授权对象删除该数据节点的子节点 3READ数据节点的读取权限允许授权对象访问该数据节点并读取其数据内容或子节点列表等 4WRITE数据节点更新权限允许授权对象对该数据节点进行更新操作 5ADMIN数据节点管理权限允许授权对象对该数据节点进行 ACL 相关设置操作 zookeeper分布式锁 Q:Zookeeper是怎么实现分布式锁的 分布式锁基于Zookeeper一致性文件系统,实现锁服务。锁服务分为保存独占及时序控制两类。 保存独占将Zookeeper上的一个znode看作是一把锁通过createznode的方式来实现。所有客户端都去创建 /distribute_lock 节点最终成功创建的那个客户端也即拥有了这把锁。用完删除自己创建的distribute_lock 节点就释放锁。 时序控制基于/distribute_lock锁所有客户端在它下面创建临时顺序编号目录节点和选master一样编号最小的获得锁用完删除依次方便。 更详细的回答如下 其实基于Zookeeper就是使用它的临时有序节点来实现的分布式锁。 原理就是当某客户端要进行逻辑的加锁时就在Zookeeper上的某个指定节点的目录下去生成一个唯一的临时有序节点 然后判断自己是否是这些有序节点中序号最小的一个如果是则算是获取了锁。如果不是则说明没有获取到锁那么就需要在序列中找到比自己小的那个节点并对其调用exist()方法对其注册事件监听当监听到这个节点被删除了那就再去判断一次自己当初创建的节点是否变成了序列中最小的。如果是则获取锁如果不是则重复上述步骤。 当释放锁的时候只需将这个临时节点删除即可。 Q:Zookeeper 是如何保证事务的顺序一致性的呢 Zookeeper 采用了递增的事务 id 来识别所有的 proposal 提议都在被提出的时候加上了zxid 。 zxid 实际上是一个 64 位数字。高 32 位是 epoch 用来标识 Leader 是否发生了改变如果有新的Leader 产生出来 epoch 会自增。 低 32 位用来递增计数。 当新产生的 proposal 的时候会依据数据库的两阶段过程首先会向其他的 Server 发出事务执行请求如果超过半数的机器都能执行并且能够成功那么就会开始执行。 Q:ZooKeeper 集群中个服务器之间是怎样通信的 Leader 服务器会和每一个 Follower/Observer 服务器都建立 TCP 连接同时为每个Follower/Observer 都创建一个叫做 LearnerHandler 的实体。LearnerHandler 主要负责 Leader 和Follower/Observer 之间的网络通讯包括数据同步请求转发和 proposal 提议的投票等。Leader 服务器保存了所有 Follower/Observer 的 LearnerHandler 。 Q:Zookeeper的广播模式有什么缺陷 广播风暴。 Q:讲一下Zookeeper的读写机制。 Leader主机负责读和写。 Follower负责读并将写操作转发给Leader。Follower还参与Leader选举投票参与事务请求Proposal投票。 Observer充当观察者的角色。Observer和Follower的唯一区别在于Observer不参与任何投票。 zookeeper集群 Q:Zookeeper 集群服务器有哪些角色有哪些状态 Zookeeper 集群服务器有以下 3 种角色 Leader主Follower从参与投票Observer观察者不参与投票 Zookeeper 集群服务器有以下 4 种状态 LOOKING 寻找 Leader 状态当服务器处于该状态时表示当前集群没有 Leader因此会进入 Leader 选举状态。FOLLOWING 跟随者状态表示当前服务器角色是 Follower。LEADING 领导者状态表示当前服务器角色是 Leader。OBSERVING 观察者状态表示当前服务器角色是 Observer。 Q:讲一下Zookeeper的选举机制。 简单版集群初始化或者集群Leader不可用时会重新选举Leader。Observer不参与投票。 超过半数的Follower选举投票即可选出新的Leader投票相同的情况下根据 myid 和 zxid 的大小共同决断zxid 更大的优先成为 Leader。 详细版 (1)基础概念集群机器 ID 是指 myid它是每一个集群机器中的编号文件代表 ZooKeeper 集群服务器的标识手动生成全局全一。 事务 ID 是指 zxidZookeeper 会给每个更新请求分配一个事务 ID它是一个 64 位的数字由 Leader 统一进行分配全局唯一不断递增在一个节点的状态信息中可以查看到最新的事务 ID 信息。 (2)选举方式 Zookeeper 提供了 3 种选举方式 LeaderElectionAuthFastLeaderElectionFastLeaderElection 最新默认 (3)选举场景 Zookeeper 会在以下场景进行选举 Zookeeper 集群启动初始化时进行选举Zookeeper 集群 Leader 失联/宕机时重新选举 (4)集群启动初始化时进行选举选举大致流程 1、初始投票 服务器启动后每个 Server 都会给自己投上一票每次投票会包含所投票服务器的 myid 和 zxid这里使用 Servermyid, zxid的方式表示此时的投票结果为zk11, 0zk22, 0zk33, 0 2、同步投票结果 集群中的服务器在投票后会将各自的投票结果同步给集群中其他服务器。 3、检查投票有效性 各服务器在收到投票后会检查投票的有效性如是否本轮投票是否来自 LOOKING 状态的服务器的投票等。 4、处理投票 服务器之间会进行投票比对规则如下 优先检查 zxid较大的服务器优先作为 Leader 如果 zxid 相同则 myid 较大的服务器作为 Leader 如zk1 和 zk2 进行比对此时 zk2 胜出zk1 更新自己的投票为zk12, 0 5、统计投票结果 每轮投票比对之后都会统计投票结果确认是否有超过半数的机器都得到相同的投票结果如果是则选出 Leader否则继续投票。 本轮选举中zk1 和 zk2 都得到了相同的投票结果2, 02 指 zk2并且超过了半数的机器2 3 / 2所以此时 zk2 就成为了本轮选举的 Leader。 所以即使 zk3 启动了因为集群已经有了 Leader所以选举也结束了zk3 不再参与选举后面进来的都是小弟。 6、更改服务器状态 一旦选出 Leader每个服务器就会各自更新自己的状态 zk1 FOLLOWING zk2 LEADING Zk3 FOLLOWING Zookeeper 集群按 myid 从小到大依次启动初始化时在超过半数机器的投票的情况下谁的 myid 最大谁就是 Leader。 (5)集群 Leader 挂掉时重新选举集群重新选举. 选举大致过程 1、状态变更 既然过去的老大 Leader 不可用了那所有的 Follower 服务器就需要从 FOLLOWING 状态变更为LOOKING开始新的一轮 Leader 选举。 其他步骤与集群启动时的选举是一致的。 集群重新选举时根据 myid 和 zxid 的大小共同决断zxid 更大的优先成为 Leader。 参考资料 https://mp.weixin.qq.com/s/RdTDJSMYBqkZGnGsmwoDvw Q:Zookeeper在选举过程中会对外提供服务么 zk集群选举过程中不对外提供服务。 如果leader宕机,集群会马上进行新的leader选举,在选举期间是不对外提供服务的,不满足可用性。 Q:你们的zookeeper集群配置了几个节点 3个节点。注意zookeeper集群节点最好是奇数个的。 集群中的zookeeper节点需要超过半数整个集群对外才可用。 这里所谓的整个集群对外才可用是指整个集群还能选出一个Leader来zookeeper默认采用quorums来支持Leader的选举。 如果有2个zookeeper那么只要有1个死了zookeeper就不能用了因为1没有过半所以2个zookeeper的死亡容忍度为0同理要是有3个zookeeper一个死了还剩下2个正常的过半了所以3个zookeeper的容忍度为1同理你多列举几个2-0;3-1;4-1;5-2;6-2会发现一个规律2n和2n-1的容忍度是一样的都是n-1所以为了更加高效何必增加那一个不必要的zookeeper呢。 Q:zookeeper的集群节点如果不是奇数的可能会出现什么问题 可能会出现脑裂。 假死由于心跳超时网络原因导致的认为master死了但其实master还存活着。 脑裂由于假死会发起新的master选举选举出一个新的master但旧的master网络又通了导致出现了两个master 有的客户端连接到老的master 有的客户端链接到新的master。 详情见https://my.oschina.net/wangen2009/blog/2994188 Q:zookeeper是怎么解决脑裂的 过半数机制。超过半数的Follower选举投票才可以选出新的Leader。 SpringCloud面试题(微服务) SpringColud的理解详情见 https://www.cnblogs.com/expiator/p/9597071.html 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挂了服务能正常访问么 Eureka Client(服务消费者) 从 Eureka Server 上获取服务的注册信息「并将其缓存在本地」这句是关键。 当 Eureka Client 在需要调用远程服务时会从该信息中查找远程服务所对应的 IP 地址、端口等信息。Eureka Client 上缓存的服务注册信息会定期更新(30 秒)如果 Eureka Server 返回的注册表信息与本地缓存的注册表信息不同的话Eureka Client 会自动处理。 这里也涉及到两个属性 是否允许获取注册表信息eureka.client.fetch-registrytrue。Eureka Client 上缓存的服务注册信息定期更新的时间间隔 默认 30 秒可以通过如下属性自行修改eureka.client.registry-fetch-interval-seconds30。 参考资料https://blog.csdn.net/feiying0canglang/article/details/122937727 Q:Eureka注册中心和Zookeeper注册中心有什么区别 Eureka注重高可用属于CAP中的AP。 Zookeeper注重一致性属于CAP中的CP。 Q:除了Zookeeper你用过哪些注册中心?有什么区别 ZookeeperRedisEureka Zookeeper是分布式中的CP能够更好地保证分布式一致性。 Redis基于发布/订阅模式。 Eureka在SpringCloud中应用较多。Eureka是分布式中的AP也就是注重可用性。 Nacos面试题 – Nacos注册中心 Q:Nacos服务是如何判定服务实例的状态 通过发送心跳包5秒发送一次如果15秒没有回应则说明服务出现了问题 如果30秒后没有回应则说明服务已经停止。 Q:服务消费方是如何调用服务提供方的资源 通过RestTemplate第三方类来实现。 Q:Nacos中的负载均衡底层是如何实现的? 通过Ribbon实现,Ribbon中定义了一些负载均衡算法,然后基于这些算法从服务 实例中获取一个实例为消费方提供服务。 Q:如何理解Nacos中的命名空间 用于进行租户粒度的配置隔离。不同的命名空间下可以存在相同的 Group 或 Data ID 的配置。Namespace 的常用场景之一是不同环境的配置的区分隔离例如开发测试环境和生产环境的资源如配置、服务隔离等。 命名空间也就是namespace其实这个概念并不是Nacos中独有的在Nacos中不管是配置还是服务都是属于某一个命名空间中的默认情况下都是属于pulibc这个命名空间中的我们可以在Nacos中新增命名空间也就相当于开辟了另外一套存放服务和配置的地方命名空间之间是独立的完全不冲突的所以我们可以利用Nacos中的命名空间来实现不同环境、不同租户之间的服务注册和配置。 Q:Nacos中保证的是CP还是AP 通常我们说Nacos技能保证CP也能保证AP具体看如何配置只有注册中心的数据需要进行集群节点之间的同步从而涉及到是CP还是AP如果注册的节点是临时节点那么就是AP如果是非临时节点那么就是CP默认是临时节点。 Q:Nacos的就近访问是什么意思 首先在Nacos中一个服务可以有多个实例并且可以给实例设置cluster-name就是可以再进一步的给所有实例划分集群那如果现在某个服务A想要调用服务B那么Naocs会看调用服务A的实例是属于哪个集群的并且调用服务B时那就会调用同样集群下的服务B实例根据cluster-name来判断两个实例是不是同一个集群这就是Nacos的就近访问。 Q:什么是健康保护阈值 为了防止因过多实例 (Instance) 不健康导致流量全部流向健康实例 (Instance) 继而造成流量压力把健康实例 (Instance) 压垮并形成雪崩效应应将健康保护阈值定义为一个 0 到 1 之间的浮点数。当域名健康实例数 (Instance) 占总服务实例数 (Instance) 的比例小于该值时无论实例 (Instance) 是否健康都会将这个实例 (Instance) 返回给客户端。这样做虽然损失了一部分流量但是保证了集群中剩余健康实例 (Instance) 能正常工作。 服务消费 Feign Q:讲一下Feign。 Q:为什么要使用Feign Feign可以进行服务消费Feign内置了Hystrix 和 Ribbon。 1.feign采用的是基于接口的注解。 2.feign整合了ribbon具有负载均衡的能力。 3.整合了Hystrix具有熔断的能力。 Q:Feign使用了哪些协议 Http协议。 Q:Feign底层原理。 动态代理。 服务消费 Ribbon Q:SpringCloud如何进行负载均衡 使用Ribbon. Q:Ribbon有哪些功能 负载均衡重试机制。 Q:Ribbon有哪些负载均衡的策略 常用的有轮询随机加权。 随机策略随机选择server. 轮询策略按照顺序选择serverribbon默认策略. 重试策略在一个配置时间段内当选择server不成功则一直尝试选择一个可用的server. 最低并发策略逐个考察server如果server断路器打开则忽略再选择其中并发链接最低的server. 可用过滤策略过滤掉一直失败并被标记为circuit tripped的server过滤掉那些高并发链接的serveractive 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。 底层是servletZuul处理的是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 Nacos面试题 – Nacos配置中心 Q:为什么使用配置中心 集中管理配置信息动态发布配置信息。减少多个服务中的冗余配置。 Q:项目中为什么要定义 bootstrap.yml 文件 bootstrap.yml 文件被读取的优先级比较高可以在服务启动时读取配置中心的数据) Q:Nacos配置中心宕机了我们的服务还可以读取到配置信息吗? 可以从内存客户端获取配置中心的配置信息以后会将配置信息在本地存储一份) Q:微服务应用中我们的客户端如何从配置中心获取信息 我们的服务一般会先从内存中读取配置信息同时我们的微服务还可以定时向nacos配置中心发请求拉取(pull)更新的配置信息 SpringCould Config配置中心 Q:讲一下Config。 配置管理工具包让你可以把配置放到远程服务器集中化管理集群配置目前支持本地存储、Git以及Subversion。 “一次配置随处可用”。 SkyWalking链路追踪 待补充 参考资料 Dubbo面试题 https://blog.csdn.net/m0_48795607/article/details/116237861