【 Java架构师面试网】收集整理了几乎整个架构师学习途中会遇到的面试题，但愿你们都能早日圆本身的架构师梦~
公众号： Java架构师面试网，关注回复“ 资料”便可领取精美整理的面试资料一份哦~
一、微服务的优缺点分别是什么?说下你在项目开发中碰到的坑。java
优势： 1) 每个服务足够内聚,代码容易理解 2) 开发效率提升,一个服务只作一件事 3) 微服务可以被小团队单独开发 4) 微服务是松耦合的,是有功能意义的服务 5) 能够用不一样的语言开发,面向接口编程 6) 易于与第三方集成 7) 微服务只是业务逻辑的代码,不会和HTML,CSS或者其余界面组合 8) 开发中,两种开发模式 9) 先后端分离 10) 全栈工程师 11) 能够灵活搭配,链接公共库/链接独立库 缺点： 1) 分布式系统的负责性 2) 多服务运维难度,随着服务的增长,运维的压力也在增大 3) 系统部署依赖 4) 服务间通讯成本 5) 数据一致性 6) 系统集成测试 7) 性能监控
二、什么是Spring Cloud？
Spring cloud流应用程序启动器是基于Spring Boot的Spring集成应用程序，提供与外部系统的集成。Spring cloud Task，一个生命周期短暂的微服务框架，用于快速构建执行有限数据处理的应用程序。git
三、SpringBoot和SpringCloud面试
1) SpringBoot专一于快速方便的开发单个个体的微服务 2) SpringCloud是关注全局的微服务协调整理治理框架,整合并管理各个微服务,为各个微服务之间提供,配置管理,服务发现,断路器,路由,事件总线等集成服务 3) SpringBoot不依赖于SpringCloud,SpringCloud依赖于SpringBoot,属于依赖关系 4) SpringBoot专一于快速,方便的开发单个的微服务个体,SpringCloud关注全局的服务治理框架
四、SpringCloud和Dubbospring
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通过多年的积累文档至关成熟,对于微服务的架构体系各个公司也有稳定的现状
五、你所知道的微服务技术栈有哪些?请列举一二。维度(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
六、负载平衡的意义什么？
在计算中，负载平衡能够改善跨计算机，计算机集群，网络连接，中央处理单元或磁盘驱动器等多种计算资源的工做负载分布。负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间并避免任何单一资源的过载。使用多个组件进行负载平衡而不是单个组件可能会经过冗余来提升可靠性和可用性。负载平衡一般涉及专用软件或硬件，例如多层交换机或域名系统服务器进程。api
七、微服务之间是如何独立通信的缓存
1) 远程过程调用（Remote Procedure Invocation） 也就是咱们常说的服务的注册与发现，直接经过远程过程调用来访问别的service。 优势： 简单，常见,由于没有中间件代理，系统更简单 缺点： a. 只支持请求/响应的模式，不支持别的，好比通知、请求/异步响应、发布/订阅、发布/异步响应； b. 下降了可用性，由于客户端和服务端在请求过程当中必须都是可用的 2) 消息 使用异步消息来作服务间通讯。服务间经过消息管道来交换消息，从而通讯。 优势: a. 把客户端和服务端解耦，更松耦合 b. 提升可用性，由于消息中间件缓存了消息，直到消费者能够消费 c. 支持不少通讯机制好比通知、请求/异步响应、发布/订阅、发布/异步响应 缺点: 消息中间件有额外的复杂性
八、springcloud如何实现服务的注册和发现
服务在发布时 指定对应的服务名（服务名包括了IP地址和端口） 将服务注册到注册中心（eureka或者zookeeper）
这一过程是springcloud自动实现 只须要在main方法添加@EnableDisscoveryClient 同一个服务修改端口就能够启动多个实例
调用方法：传递服务名称经过注册中心获取全部的可用实例 经过负载均衡策略调用（ribbon和feign）对应的服务服务器
九、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只是一个进程
十、eureka自我保护机制
当 Eureka Server 节点在短期内丢失了过多实例的链接时（好比网络故障或频繁的启动关闭客户端），那么这个节点就会进入自我保护模式，一旦进入到该模式，Eureka server 就会保护服务注册表中的信息，再也不删除服务注册表中的数据（即不会注销任何微服务），当网络故障恢复后，该 Ereaka Server 节点就会自动退出自我保护模式（个人 Eureka Server 已经几个月了，至今未自动退出该模式）
十一、什么是服务熔断?什么是服务降级
在复杂的分布式系统中,微服务之间的相互调用,有可能出现各类各样的缘由致使服务的阻塞,在高并发场景下,服务的阻塞意味着线程的阻塞,致使当前线程不可用,服务器的线程所有阻塞,致使服务器崩溃,因为服务之间的调用关系是同步的,会对整个微服务系统形成服务雪崩
为了解决某个微服务的调用响应时间过长或者不可用进而占用愈来愈多的系统资源引发雪崩效应就须要进行服务熔断和服务降级处理。
所谓的服务熔断指的是某个服务故障或异常一块儿相似显示世界中的“保险丝"当某个异常条件被触发就直接熔断整个服务，而不是一直等到此服务超时。
服务熔断就是至关于咱们电闸的保险丝,一旦发生服务雪崩的,就会熔断整个服务,经过维护一个本身的线程池,当线程达到阈值的时候就启动服务降级,若是其余请求继续访问就直接返回fallback的默认值
十二、如何使用Eureka
1) 添加pom依赖
2) 配置文件添加相关配置
3) 启动类添加注解@EnableDiscoveryClient
1三、什么是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添加拦截器，进而交给负载均衡器去处理。
1四、什么是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作到了负载均衡。
1五、Ribbon和Feign的区别：
Ribbon和Feign都是用于调用其余服务的，不过方式不一样。 1.启动类使用的注解不一样，Ribbon用的是@RibbonClient，Feign用的是@EnableFeignClients。 2.服务的指定位置不一样，Ribbon是在@RibbonClient注解上声明，Feign则是在定义抽象方法的接口中使用@FeignClient声明。 3.调用方式不一样，Ribbon须要本身构建http请求，模拟http请求而后使用RestTemplate发送给其余服务，步骤至关繁琐。 Feign则是在Ribbon的基础上进行了一次改进，采用接口的方式，将须要调用的其余服务的方法定义成抽象方法便可， 不须要本身构建http请求。不过要注意的是抽象方法的注解、方法签名要和提供服务的方法彻底一致。
1六、什么是Spring Cloud Bus？
Spring Cloud Bus 将分布式的节点用轻量的消息代理链接起来。它能够用于广播配置文件的更改或者服务之间的通信，也能够用于监控。 若是修改了配置文件，发送一次请求，全部的客户端便会从新读取配置文件 使用： 一、添加依赖 二、配置rabbitmq
1七、什么是zuul?
Zuul的主要功能是路由转发和过滤器。路由功能是微服务的一部分，好比／api/user转发到到user服务，/api/shop转发到到shop服务。zuul默认和Ribbon结合实现了负载均衡的功能。 使用： 一、添加pom依赖 二、配置文件添加相关配置 三、启动类添加注解@EnableZuulProxy 在zuul中， 整个请求的过程是这样的，首先将请求给zuulservlet处理，zuulservlet中有一个zuulRunner对象，该对象中初始化了RequestContext：做为存储整个请求的一些数据，并被全部的zuulfilter共享。zuulRunner中还有 FilterProcessor，FilterProcessor做为执行全部的zuulfilter的管理器。FilterProcessor从filterloader 中获取zuulfilter，而zuulfilter是被filterFileManager所加载，并支持groovy热加载，采用了轮询的方式热加载。有了这些filter以后，zuulservelet首先执行的Pre类型的过滤器，再执行route类型的过滤器，最后执行的是post 类型的过滤器，若是在执行这些过滤器有错误的时候则会执行error类型的过滤器。执行完这些过滤器，最终将请求的结果返回给客户端。
1八、什么是Hystrix？它如何实现容错？
Hystrix是一个延迟和容错库，旨在隔离远程系统，服务和第三方库的访问点，当出现故障是不可避免的故障时，中止级联故障并在复杂的分布式系统中实现弹性。 一般对于使用微服务架构开发的系统，涉及到许多微服务。这些微服务彼此协做。 使用： 一、添加pom依赖 二、启动类使用注解@EnableHystrix 三、在Service方法上加上@HystrixCommand注解。该注解对该方法建立了熔断器的功能，并指定了fallbackMethod熔断方法
1九、springcloud断路器的做用
当一个服务调用另外一个服务因为网络缘由或者自身缘由出现问题时 调用者就会等待被调用者的响应 当更多的服务请求到这些资源时，致使更多的请求等待 这样就会发生连锁效应（雪崩效应） 断路器就是解决这一问题。 断路器有彻底打开状态：必定时间内 达到必定的次数没法调用 而且屡次检测没有恢复的迹象 断路器彻底打开，那么下次请求就不会请求到该服务 半开：短期内 有恢复迹象 断路器会将部分请求发给该服务 当能正常调用时 断路器关闭 关闭：当服务一直处于正常状态 能正常调用 断路器关闭
20、Spring Cloud Config
在分布式系统中，因为服务数量巨多，为了方便服务配置文件统一管理，实时更新，因此须要分布式配置中心组件。在Spring Cloud中，有分布式配置中心组件spring cloud config ，它支持配置服务放在配置服务的内存中（即本地），也支持放在远程Git仓库中。在spring cloud config 组件中，分两个角色，一是config server，二是config client。 使用： 一、添加pom依赖 二、配置文件添加相关配置 三、启动类添加注解@EnableConfigServer
2一、Spring Cloud Gateway
Spring Cloud Gateway是Spring Cloud官方推出的第二代网关框架，取代Zuul网关。网关做为流量的，在微服务系统中有着很是做用，网关常见的功能有路由转发、权限校验、限流控制等做用。 使用了一个RouteLocatorBuilder的bean去建立路由，除了建立路由RouteLocatorBuilder可让你添加各类predicates和filters，predicates断言的意思，顾名思义就是根据具体的请求的规则，由具体的route去处理，filters是各类过滤器，用来对请求作各类判断和修改。
2二、架构：
在微服务架构中，须要几个基础的服务治理组件，包括服务注册与发现、服务消费、负载均衡、断路器、智能路由、配置管理等，由这几个基础组件相互协做，共同组建了一个简单的微服务系统 在Spring Cloud微服务系统中，一种常见的负载均衡方式是，客户端的请求首先通过负载均衡（zuul、Ngnix），再到达服务网关（zuul集群），而后再到具体的服。，服务统一注册到高可用的服务注册中心集群，服务的全部的配置文件由配置服务管理，配置服务的配置文件放在git仓库，方便开发人员随时改配置。
嗨，你好呀，将来的架构师，本文由Java架构师面试网 www.javajiagoushi.com收集整理并进行编辑发布，谢谢你们的支持~