共计 7617 个字符,预计需要花费 20 分钟才能阅读完成。
【Java 架构师面试网】收集整理了简直整个架构师学习途中会遇到的面试题,心愿大家都能早日圆本人的架构师梦~
公众号:Java 架构师面试网 ,关注回复“ 材料”即可支付精美整顿的面试材料一份哦~
1、微服务的优缺点别离是什么? 说下你在我的项目开发中碰到的坑。
长处:1) 每一个服务足够内聚, 代码容易了解 | |
2) 开发效率进步, 一个服务只做一件事 | |
3) 微服务可能被小团队独自开发 | |
4) 微服务是松耦合的, 是有性能意义的服务 | |
5) 能够用不同的语言开发, 面向接口编程 | |
6) 易于与第三方集成 | |
7) 微服务只是业务逻辑的代码, 不会和 HTML,CSS 或者其余界面组合 | |
8) 开发中, 两种开发模式 | |
9) 前后端拆散 | |
10) 全栈工程师 | |
11) 能够灵便搭配, 连贯公共库 / 连贯独立库 | |
毛病:1) 分布式系统的负责性 | |
2) 多服务运维难度, 随着服务的减少, 运维的压力也在增大 | |
3) 零碎部署依赖 | |
4) 服务间通信老本 | |
5) 数据一致性 | |
6) 系统集成测试 | |
7) 性能监控 |
2、什么是 Spring Cloud?
Spring cloud 流应用程序启动器是基于 Spring Boot 的 Spring 集成应用程序,提供与内部零碎的集成。Spring cloud Task,一个生命周期短暂的微服务框架,用于疾速构建执行无限数据处理的应用程序。
3、SpringBoot 和 SpringCloud
1) SpringBoot 专一于疾速不便的开发单个个体的微服务 | |
2) SpringCloud 是关注全局的微服务协调整顿治理框架, 整合并治理各个微服务, 为各个微服务之间提供, 配置管理, 服务发现, 断路器, 路由, 事件总线等集成服务 | |
3) SpringBoot 不依赖于 SpringCloud,SpringCloud 依赖于 SpringBoot, 属于依赖关系 | |
4) SpringBoot 专一于疾速, 不便的开发单个的微服务个体,SpringCloud 关注全局的服务治理框架 |
4、SpringCloud 和 Dubbo
1) 区别 | |
a. 服务的调用形式 Dubbo 应用的是 RPC 近程调用, 而 SpringCloud 应用的是 Rest API, 其实更合乎微服务官网的定义 | |
b. 服务的注册核心来看,Dubbo 应用了第三方的 ZooKeeper 作为其底层的注册核心, 实现服务的注册和发现,SpringCloud 应用 Spring Cloud Netflix Eureka 实现注册核心, 当然 SpringCloud 也能够应用 ZooKeeper 实现, 但个别咱们不会这样做 | |
c. 服务网关,Dubbo 并没有自身的实现, 只能通过其余第三方技术的整合, 而 SpringCloud 有 Zuul 路由网关, 作为路由服务器, 进行消费者的申请散发,SpringCloud 还反对断路器, 与 git 完满集成分布式配置文件反对版本控制, 事务总线实现配置文件的更新与服务主动拆卸等等一系列的微服务架构因素 | |
2) 技术选型 | |
a. 目前国内的分布式系统选型次要还是 Dubbo 毕竟国产, 而且国内工程师的技术熟练程度高, 并且 Dubbo 在其余维度上的缺点能够由其余第三方框架进行集成进行补救 | |
b. 而 SpringCloud 目前是国外比拟风行, 当然我感觉国内的市场也会缓缓的偏差 SpringCloud, 就连刘军作为 Dubbo 重启的负责人也发表过观点,Dubbo 的倒退方向是踊跃适应 SpringCloud 生态, 并不是起抵触 | |
3) Rest 和 RPC 比照 | |
其实如果仔细阅读过微服务提出者马丁福勒的论文的话能够发现其定义的服务间通信机制就是 Http Rest。RPC 最次要的缺点就是服务提供方和调用形式之间依赖太强, 咱们须要为每一个微服务进行接口的定义, 并通过继续继承公布, 须要严格的版本控制才不会呈现服务提供和调用之间因为版本不同而产生的抵触 | |
而 REST 是轻量级的接口, 服务的提供和调用不存在代码之间的耦合, 只是通过一个约定进行标准, 但也有可能呈现文档和接口不统一而导致的服务集成问题, 但能够通过 swagger 工具整合, 是代码和文档一体化解决, 所以 REST 在分布式环境下比 RPC 更加灵便 | |
这也是为什么当当网的 DubboX 在对 Dubbo 的加强中减少了对 REST 的反对的起因 |
4) 文档品质和社区活跃度
SpringCloud 社区活跃度远高于 Dubbo, 毕竟因为梁飞团队的起因导致 Dubbo 进行更新迭代五年, 而中小型公司无奈承当技术开发的老本导致 Dubbo 社区重大高涨, 而 SpringCloud 异军突起, 迅速霸占了微服务的市场, 背靠 Spring 混的风生水起 | |
Dubbo 通过多年的积攒文档相当成熟, 对于微服务的架构体系各个公司也有稳固的现状 | |
5、你所晓得的微服务技术栈有哪些? 请列举一二。维度(SpringCloud)
1) 服务开发:SpringBoot、Spring、SpringMVC | |
2) 服务配置与治理:Netfilx 公司的 Archaiusm, 阿里的 Diamond | |
3) 服务注册与发现:Eureka,ZooKeeper | |
4) 服务调用:Rest,RPC,gRPC | |
5) 服务熔断器:Hystrix | |
6) 服务负载平衡:Ribbon,Nginx | |
7) 服务接口调用:Feign | |
8) 音讯队列:Kafka,RabbitMq,ActiveMq | |
9) 服务配置核心治理:SpringCloudConfing | |
10) 服务路由(API 网关):Zuul | |
11) 事件音讯总线:SpringCloud Bus |
6、负载平衡的意义什么?
在计算中,负载平衡能够改善跨计算机,计算机集群,网络链接,地方处理单元或磁盘驱动器等多种计算资源的工作负载散布。负载平衡旨在优化资源应用,最大化吞吐量,最小化响应工夫并防止任何繁多资源的过载。应用多个组件进行负载平衡而不是单个组件可能会通过冗余来进步可靠性和可用性。负载平衡通常波及专用软件或硬件,例如多层交换机或域名零碎服务器过程。
7、微服务之间是如何独立通信的
1) 近程过程调用(Remote Procedure Invocation)也就是咱们常说的服务的注册与发现,间接通过近程过程调用来拜访别的 service。长处:简略,常见, 因为没有中间件代理,零碎更简略 | |
毛病:a. 只反对申请 / 响应的模式,不反对别的,比方告诉、申请 / 异步响应、公布 / 订阅、公布 / 异步响应;b. 升高了可用性,因为客户端和服务端在申请过程中必须都是可用的 | |
2) 音讯 | |
应用异步音讯来做服务间通信。服务间通过音讯管道来替换音讯,从而通信。长处: | |
a. 把客户端和服务端解耦,更松耦合 | |
b. 进步可用性,因为消息中间件缓存了音讯,直到消费者能够生产 | |
c. 反对很多通信机制比方告诉、申请 / 异步响应、公布 / 订阅、公布 / 异步响应 | |
毛病: | |
消息中间件有额定的复杂性 |
8、springcloud 如何实现服务的注册和发现
服务在公布时 指定对应的服务名(服务名包含了 IP 地址和端口)将服务注册到注册核心(eureka 或者 zookeeper)
这一过程是 springcloud 主动实现 只须要在 main 办法增加 @EnableDisscoveryClient 同一个服务批改端口就能够启动多个实例
调用办法:传递服务名称通过注册核心获取所有的可用实例 通过负载平衡策略调用(ribbon 和 feign)对应的服务
9、Eureka 和 ZooKeeper 都能够提供服务注册与发现的性能, 请说说两个的区别。
1) Eureka 取 CAP 中的 AP,重视可用性。Zookepper 取 CAP 实践中的 CP 强调高的一致性。ZooKeeper 在选举期间注册服务瘫痪, 尽管服务最终会复原, 然而选举期间不可用的 | |
Eureka 各个节点是平等关系, 只有有一台 Eureka 就能够保障服务可用, 而查问到的数据并不是最新的自我爱护机制会导致 | |
Eureka 不再从注册列表移除因长时间没收到心跳而应该过期的服务 | |
Eureka 依然可能承受新服务的注册和查问申请, 然而不会被同步到其余节点(高可用) | |
当网络稳固时, 以后实例新的注册信息会被同步到其余节点中(最终一致性) | |
Eureka 能够很好的应答因网络故障导致局部节点失去分割的状况, 而不会像 ZooKeeper 一样使得整个注册零碎瘫痪 | |
2) ZooKeeper 有 Leader 和 Follower 角色,Eureka 各个节点平等 | |
3) ZooKeeper 采纳过半数存活准则,Eureka 采纳自我爱护机制解决分区问题 | |
4) Eureka 实质上是一个工程, 而 ZooKeeper 只是一个过程 |
10、eureka 自我爱护机制
当 Eureka Server 节点在短时间内失落了过多实例的连贯时(比方网络故障或频繁的启动敞开客户端),那么这个节点就会进入自我保护模式,一旦进入到该模式,Eureka server 就会爱护服务注册表中的信息,不再删除服务注册表中的数据(即不会登记任何微服务),当网络故障复原后,该 Ereaka Server 节点就会主动退出自我保护模式(我的 Eureka Server 曾经几个月了,至今未主动退出该模式)
11、什么是服务熔断? 什么是服务降级
在简单的分布式系统中, 微服务之间的互相调用, 有可能呈现各种各样的起因导致服务的阻塞, 在高并发场景下, 服务的阻塞意味着线程的阻塞, 导致以后线程不可用, 服务器的线程全副阻塞, 导致服务器解体, 因为服务之间的调用关系是同步的, 会对整个微服务零碎造成服务雪崩
为了解决某个微服务的调用响应工夫过长或者不可用进而占用越来越多的系统资源引起雪崩效应就须要进行服务熔断和服务降级解决。
所谓的服务熔断指的是某个服务故障或异样一起相似显示世界中的“保险丝 ” 当某个异样条件被触发就间接熔断整个服务,而不是始终等到此服务超时。
服务熔断就是相当于咱们电闸的保险丝, 一旦产生服务雪崩的, 就会熔断整个服务, 通过保护一个本人的线程池, 当线程达到阈值的时候就启动服务降级, 如果其余申请持续拜访就间接返回 fallback 的默认值
12、如何应用 Eureka
1) 增加 pom 依赖 | |
2) 配置文件增加相干配置 | |
3) 启动类增加注解 @EnableDiscoveryClient |
13、什么是 Ribbon?
ribbon 是一个负载平衡客户端,能够很好的管制 htt 和 tcp 的一些行为。Feign 默认集成了 ribbon。应用:1) 增加 pom 依赖 | |
2) 配置文件增加相干配置 | |
3) 启动类增加注解 @EnableEurekaServer | |
4) 向程序的 ioc 注入一个 bean: restTemplate; 并通过 @LoadBalanced 注解表明这个 restRemplate 开启负载平衡的性能 | |
5) 写一个测试类 HelloService,通过之前注入 ioc 容器的 restTemplate 来生产 service-hi 服务的“/hi”接口 |
源码:
Ribbon 的负载平衡,次要通过 LoadBalancerClient 来实现的,而 LoadBalancerClient 具体交给了 ILoadBalancer 来解决,ILoadBalancer 通过配置 IRule、IPing 等信息,并向 EurekaClient 获取注册列表的信息,并默认 10 秒一次向 EurekaClient 发送“ping”, 进而查看是否更新服务列表,最初,失去注册列表后,ILoadBalancer 依据 IRule 的策略进行负载平衡。
而 RestTemplate 被 @LoadBalance 注解后,能过用负载平衡,次要是保护了一个被 @LoadBalance 注解的 RestTemplate 列表,并给列表中的 RestTemplate 增加拦截器,进而交给负载均衡器去解决。
14、什么是 Feign?它的长处是什么?
Feign 是一个申明式的伪 Http 客户端,它使得写 Http 客户端变得更简略。应用 Feign,只须要创立一个接口并注解。它具备可插拔的注解个性,可应用 Feign 注解和 JAX-RS 注解。Feign 反对可插拔的编码器和解码器。Feign 默认集成了 Ribbon,并和 Eureka 联合,默认实现了负载平衡的成果。简而言之:Feign 采纳的是基于接口的注解 | |
Feign 整合了 ribbon,具备负载平衡的能力 | |
整合了 Hystrix,具备熔断的能力 | |
应用:1) 增加 pom 依赖 | |
2) 配置文件增加相干配置 | |
3) 启动类增加注解 @EnableFeignClients | |
4) 定义一个接口,应用注解 @ FeignClient(“服务名”),来指定调用哪个服务 | |
源码实现过程:首先通过 @EnableFeignCleints 注解开启 FeignCleint | |
依据 Feign 的规定实现接口,并加 @FeignCleint 注解 | |
程序启动后,会进行包扫描,扫描所有的 @ FeignCleint 的注解的类,并将这些信息注入到 ioc 容器中。当接口的办法被调用,通过 jdk 的代理,来生成具体的 RequesTemplate | |
RequesTemplate 在生成 Request | |
Request 交给 Client 去解决,其中 Client 能够是 HttpUrlConnection、HttpClient 也能够是 Okhttp | |
最初 Client 被封装到 LoadBalanceClient 类,这个类联合类 Ribbon 做到了负载平衡。 |
15、Ribbon 和 Feign 的区别:
Ribbon 和 Feign 都是用于调用其余服务的,不过形式不同。1. 启动类应用的注解不同,Ribbon 用的是 @RibbonClient,Feign 用的是 @EnableFeignClients。2. 服务的指定地位不同,Ribbon 是在 @RibbonClient 注解上申明,Feign 则是在定义形象办法的接口中应用 @FeignClient 申明。3. 调用形式不同,Ribbon 须要本人构建 http 申请,模仿 http 申请而后应用 RestTemplate 发送给其余服务,步骤相当繁琐。Feign 则是在 Ribbon 的根底上进行了一次改良,采纳接口的形式,将须要调用的其余服务的办法定义成形象办法即可,不须要本人构建 http 申请。不过要留神的是形象办法的注解、办法签名要和提供服务的办法完全一致。
16、什么是 Spring Cloud Bus?
Spring Cloud Bus 将分布式的节点用轻量的音讯代理连接起来。它能够用于播送配置文件的更改或者服务之间的通信,也能够用于监控。如果批改了配置文件,发送一次申请,所有的客户端便会从新读取配置文件 | |
应用:1、增加依赖 | |
2、配置 rabbitmq |
17、什么是 zuul?
Zuul 的次要性能是路由转发和过滤器。路由性能是微服务的一部分,比方/api/user 转发到到 user 服务,/api/shop 转发到到 shop 服务。zuul 默认和 Ribbon 联合实现了负载平衡的性能。应用:1、增加 pom 依赖 | |
2、配置文件增加相干配置 | |
3、启动类增加注解 @EnableZuulProxy | |
在 zuul 中,整个申请的过程是这样的,首先将申请给 zuulservlet 解决,zuulservlet 中有一个 zuulRunner 对象,该对象中初始化了 RequestContext:作为存储整个申请的一些数据,并被所有的 zuulfilter 共享。zuulRunner 中还有 FilterProcessor,FilterProcessor 作为执行所有的 zuulfilter 的管理器。FilterProcessor 从 filterloader 中获取 zuulfilter,而 zuulfilter 是被 filterFileManager 所加载,并反对 groovy 热加载,采纳了轮询的形式热加载。有了这些 filter 之后,zuulservelet 首先执行的 Pre 类型的过滤器,再执行 route 类型的过滤器,最初执行的是 post 类型的过滤器,如果在执行这些过滤器有谬误的时候则会执行 error 类型的过滤器。执行完这些过滤器,最终将申请的后果返回给客户端。 |
18、什么是 Hystrix?它如何实现容错?
Hystrix 是一个提早和容错库,旨在隔离近程零碎,服务和第三方库的拜访点,当呈现故障是不可避免的故障时,进行级联故障并在简单的分布式系统中实现弹性。通常对于应用微服务架构开发的零碎,波及到许多微服务。这些微服务彼此合作。应用:1、增加 pom 依赖 | |
2、启动类应用注解 @EnableHystrix | |
3、在 Service 办法上加上 @HystrixCommand 注解。该注解对该办法创立了熔断器的性能,并指定了 fallbackMethod 熔断办法 |
19、springcloud 断路器的作用
当一个服务调用另一个服务因为网络起因或者本身起因呈现问题时 调用者就会期待被调用者的响应 当更多的服务申请到这些资源时,导致更多的申请期待 这样就会产生连锁效应(雪崩效应)断路器就是解决这一问题。断路器有齐全关上状态:肯定工夫内 达到肯定的次数无奈调用 并且屡次检测没有复原的迹象 断路器齐全关上,那么下次申请就不会申请到该服务 | |
半开:短时间内 有复原迹象 断路器会将局部申请发给该服务 当能失常调用时 断路器敞开 | |
敞开:当服务始终处于失常状态 能失常调用 断路器敞开 |
20、Spring Cloud Config
在分布式系统中,因为服务数量巨多,为了不便服务配置文件对立治理,实时更新,所以须要分布式配置核心组件。在 Spring Cloud 中,有分布式配置核心组件 spring cloud config,它反对配置服务放在配置服务的内存中(即本地),也反对放在近程 Git 仓库中。在 spring cloud config 组件中,分两个角色,一是 config server,二是 config client。应用:1、增加 pom 依赖 | |
2、配置文件增加相干配置 | |
3、启动类增加注解 @EnableConfigServer |
21、Spring Cloud Gateway
Spring Cloud Gateway 是 Spring Cloud 官网推出的第二代网关框架,取代 Zuul 网关。网关作为流量的,在微服务零碎中有着十分作用,网关常见的性能有路由转发、权限校验、限流管制等作用。应用了一个 RouteLocatorBuilder 的 bean 去创立路由,除了创立路由 RouteLocatorBuilder 能够让你增加各种 predicates 和 filters,predicates 断言的意思,顾名思义就是依据具体的申请的规定,由具体的 route 去解决,filters 是各种过滤器,用来对申请做各种判断和批改。
22、架构:
在微服务架构中,须要几个根底的服务治理组件,包含服务注册与发现、服务生产、负载平衡、断路器、智能路由、配置管理等,由这几个根底组件相互协作,独特组建了一个简略的微服务零碎 | |
在 Spring Cloud 微服务零碎中,一种常见的负载平衡形式是,客户端的申请首先通过负载平衡(zuul、Ngnix),再达到服务网关(zuul 集群),而后再到具体的服。,服务对立注册到高可用的服务注册核心集群,服务的所有的配置文件由配置服务治理,配置服务的配置文件放在 git 仓库,不便开发人员随时改配置。 |
嗨,你好呀,将来的架构师,本文由 Java 架构师面试网 www.javajiagoushi.com 收集整理并进行编辑公布,谢谢大家的反对~