微服务部分面试题

微服务部分面试题

 

背景：蹲小僵尸 蹲小僵尸 蹲小僵尸；整理下微服务相关的部分面试题，以备不时之需！

 

一、什么是微服务Micoreservice?

微服务的核心就是将传统的一站式应用,根据业务拆分成一个一个的服务,彻底地去耦合,每个微服务提供单个业务功能的服务,一个服务只做一件事; 从技术角度来看就是一种小而独立的处理过程,类似进程的概念; 每个微服务能够自行独立的启动或销毁,拥有自己独立的数据库。

二、微服务的优缺点有哪些？

优点:
    1.每个服务足够内聚,足够小,代码容易理解,这样能聚焦一个具体的业务功能或业务需求;
    2.开发简单,提高开发效率,一个服务可能专门只做一件事;
    3.微服务能够被小团队单独开发,这个小团队可以有2-5个开发人员组成;
    4.微服务是松耦合的,是具有功能意义的服务,无论是在开发阶段,还是部署阶段都是独立的;
    5.微服务可以使用不同的语言开发;
    6.易于第三方集成,微服务允许以容易且灵活的方式集成自动部署,通过持续集成工具,如:Jendis, Hudson;
    7.微服务易于被一个开发人员理解、修改和维护,这样小团队能够更关注自己的工作成果,无需通过合作来体现价值;
    8.微服务只是业务逻辑代码,不会与HTML和css等其他界面组件混合;
    9.每个微服务都有独立的存储能力,可以由自己的数据库管理,也可以由统一的数据库管理。

缺点:
    1.开发人员要处理分布式系统的复杂性;
    2.多运维难度大,随着服务的增加,运维的压力也在增大;
    3.系统部署依赖;
    4.系统集成测试;
    5.服务间通信成本;
    6.数据一致性;
    7.性能监控;
    ...等。

三、微服务和微服务架构的区别？

1.微服务强调的是一个一个的个体,每个个体做自己的事情;
2.微服务架构强调的是整体,其把一个个的微服务组装起来,对外提供服务。

四、微服务技术栈有哪些？

技术栈: 多种技术的集合体;
    1.服务开发: SpringBoot, Spring, SpringMVC;
    2.服务配置与管理: Netflix公司的Archaius, Alibaba的Diamond等;
    3.服务注册与发现: Eureka, Zookeeper;
    4.服务调用: Rest, RPC, gRPC;
    5.服务熔断器: Hystrix, Envoy;
    6.服务负载均衡: Ribbon, Nginx;
    7.服务接口调用: Feign;
    8.消息队列: Kafaka, RabbitMQ, ActiveMQ;
    9.消息配置中心管理: SpringCloudConfig, Chef
    10.服务监控: Zabbix, Nagios, Metrics, Spectator;
    11.服务路由(API网关): Zuul;
    12.全链路跟踪: Zipkin, Brave, Dapper
    13.服务部署: Docker, OpenStack, Kubernetes;
    14.数据流操作开发包: SpringCloud Stream;
    15.事件消息总线: SpringCloud Bus;
    ...等。

五、为什么要选择SpringCloud作为微服务架构？

选型依据:
    1.整体解决方案(SpringCloud框架有全家桶的一站式整体解决方案,类似宜家家居那样,从厨房到卧室再到浴室等所有家居都可以在一个地方全套购买,方便快捷),并且框架成熟度高;
    2.社区热度高,使用的人群多;
    3.可维护性;
    4.学习曲线等;

六、什么是SpringCloud？

SpringCloud是一个基于SpringBoot的快速构建分布式系统的工具集, 其基于SpringBoot提供了一套微服务一站式解决方案,包括服务注册与发现, 配置中心, 全链路监控, 服务网关, 负载均衡, 熔断器等组件; 除了基于Netflix的开源组件做高度抽象封装之外,还有一些选型中立的开源组件。

七、什么是微服务"全家桶"？

分布式微服务架构下的一站式解决方案,是各个微服务架构落地技术的集合体俗称微服务"全家桶"。

八、SpringBoot 与 SpringCloud 的关系？

1.SpringBoot专注于快速方便的开发单个个体微服务;
2.SpringCloud是专注于全局的微服务协调治理框架,它将SpirngBoot开发的一个个单体微服务整合并统一管理, 为各个微服务之间提供配置管理, 服务发现, 断路器, 路由,微代理, 事件总线, 全局锁, 决策竞选, 分布式会话等集成服务;
3.SpringBoot可以离开SpringCloud独立使用开发项目, 但SpringCloud离不开SpringBoot,二者属于依赖关系。

九、SpringCloud与Dubbo的区别？

1.两者的最大区别就是SpringCloud抛弃了Dubbo的RPC通信,采用的是HTTP的REST方式;
2.严格来说,这两种方式各有优劣,虽然从一定程度上讲,REST牺牲了服务调用的性能,但也避免了原生RPC带来的问题; 而且,REST相比RPC更为灵活,服务提供方和调用方的依赖只依靠一纸契约,不存在代码级别的强依赖,这在强调快速演化的微服务环境下,显得更加适合;
3.Dubbo只实现了服务治理,而SpringCloud的子项目分别覆盖了微服务架构下的众多部件,服务治理只是其中的一个方面; 但是Dubbo提供了Filter,各种核心要素可以通过扩展Filter来完善。

十、微服务的注册与发现是怎么玩的？

微服务的注册与发现是通过Eureka组件实现的，Eureka包含两大内容：Eureka Server 和 Eureka Client；
Eureka Server提供服务注册服务，各个节点启动后，会在Eureka Server中进行注册，这样Eureka Server中的服务注册表中将会存储所有可用服务的节点信息，服务节点的信息可以在界面中直观看到；Eureka Client是一个Java客户端用于简化Eureka Server的交互，客户端同时也具备一个内置的、使用轮询(round-robin)负载算法的负载均衡器；在应用启动后，将会向Eureka Server发送心跳(默认周期为30s)；如果Eureka Server在多个心跳周期内没有接受到某个节点的心跳，Eureka Server将会从服务注册表中把这个服务节点移除(默认90秒)。
注；在EurekaServer7001_App主启动类中加入 @EnableEurekaServer 注解即可！

十一、作为服务注册中心Eureka比Zookeeper好在哪里?

1.Eureka遵守AP原则,Zookeeper遵守CP原则;
2.根据CAP理论,一个分布式系统不可能同时满足一致性,可用性和分区容错性,由于分区容错性是分布式系统中必须保证的,因此我们只能在一致性和可用性之间权衡;
3.Zookeeper采用CP,节点采用主从,一旦主机down机,就会在多个从中进行决策选举一个从作为主,但是选举时间为30-120s之间,时间太长,在选举期间会导致集群不可用,从而导致整个注册中心瘫痪;
4.Eureka采用AP,所有节点平等,没有主从,如果有一个节点挂掉,就会自动切换到下一个可用的节点,只要有一个Eureka节点正常运行,就能保证注册中心可用;只不过查询到的信息可能不是最新的(不保证强一致性);
5.除此之外, Eureaka还有自我保护机制; 因此Eureka可以很好地应对因网络故障而导致部分节点失去联系的情况,而不会像Zookeeper那样使整个注册服务瘫痪。

十二、Eureka保护机制？

1.Eureka自我保护机制是一种应对网络异常的安全保护措施,它的架构哲学是宁可保留所有的微服务(健康的和不健康的微服务都保留),也不盲目注销任何健康的微服务,使用自我保护模式,可以让Eureka集群更加健壮,稳定;
2.默认情况下,如果Eureka Server在一定时间内没有接收到某个微服务实例的心跳，Eureka Server将会注销该实例(默认90秒),但是当网络发生故障时,微服务与Eureka Server之间无法正常通信,以上行为可能变得非常危险--因为服务本身其实是健康的,此时本不应该注销这个服务;
3.Eureka通过"自我保护模式"来解决这个问题--当Eureka Server在短时间丢失过多客户端时(可能发生了网络分区故障),那么该节点就会进入自我保护模式; 一旦进入该模式,Eureaka Server就会保护注册表中的信息,不再删除服务注册表中的数据(也不会注销任何微服务),当网络故障恢复后，该Eureka Server节点会自动退出自我保护模式。

 十三、传统的 ACID 分别是什么？

A (Atomicity) 原子性;
C (Consistency) 一致性;
I (Isolation) 隔离性;
D (Durability) 持久性。

十四、CAP 分别是什么？

C (Consistency) 强一致性;
    同样数据在分布式系统中所有地方都是被复制成相同的;
A (Availability) 可用性;
    所有在分布式系统活跃的节点都能够处理操作并且能响应查询;
P (Partition Tolerance) 分区容错性;
    在两个复制系统之间,如果发生了计划之外的网络连接问题,对于这种情况,有一套容错性设计来保证;
CAP理论的核心是: 一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性, 最多只能同时实现两种。

十五、什么是Ribbon？

SpringCloud Ribbon 是基于Netfix Ribbon 实现的一套客户端负软载均衡工具。

十六、什么是负载均衡 ？

负载均衡(Load Balance) 简单的说就是将用户的请求平摊到多个服务上,从而达到系统的HA，即高可用;
分类: 集中式LB,  进程内LB。

十七、什么是 Feign？

Feign是一个声明式的WebService客户端, 其内置了Ribbon的负载均衡,还有它的面向接口编程，优雅而简单的实现了服务的调用，让编写WebService客户端更简单。

十八、分布式系统面临的问题？

复杂分布式系统结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将面临不可避免的依赖失败。

十九、什么是服务雪崩？

多个微服务之间调用的时候,假设微服务A调用微服务B和C,微服务B和C又调用其他微服务,这就是所谓的"扇出"; 如果扇出链路上的某个微服务的调用不可用或响应时间过长,对微服务A的调用就会占用越来越多的系统资源,进而引起系统崩溃,所谓的"雪崩效应"(是一种 服务提供者 的不可用导致 服务调用者的不可用，并将不可用逐渐放大的过程)。

二十、什么是 Hystrix？

Hystrix 是一个用于处理分布式系统的延迟和容错的开源库(基于Netfix); 在分布式系统里,许多依赖不可避免的会失败,比如超时,异常等, Hystrix能够保证在一个依赖出现问题的情况下,不会导致整体服务失败,避免级联故障,以提高分布式系统的弹性;断路器本事是一种开关装置,当某个服务单元发生故障后,通过断路器的故障监控(类似熔断保险丝),向调用方返回一个符合预期的,可处理的备选响应(FallBack),而不是长时间的等待或者抛出调用方无法处理的异常,这样就保证了服务调用方的线程不会被长时间,不必要地占用, 从而避免了故障在分布式系统的蔓延，乃至雪崩。

二十一、Hystrix 能干什么？

服务降级、服务熔断、服务限流、服务监控。

二十二、什么是服务熔断？

熔断机制是应对雪崩效应的一种微服务链路保护机制; 当扇出链路的某个微服务不可用或响应时间过长时,会进行服务降级,进而熔断该节点微服务的调用,快速返回错误的响应信息; 当检测到该节点微服务调用响应正常后恢复调用链路; 在SpringCloud框架里,熔断机制通过Hystrix实现,Hystrix会监控服务间的调用状况,当失败的调用达到一定阀值,就会启动熔断机制,默认是5秒内调用20次；(熔断机制的注解是@HystrixCommand)

二十三、服务降级是什么？

1.当服务器压力剧增的情况下,根据实际业务情况及流量,对一些服务和页面有策略的不处理或换种简单的方式处理,从而释放释放服务器资源以保证核心交易正常运作;
2.服务降级一般是从整体负荷考虑,就是当某个服务熔断之后,服务器将不再被调用,此时客户端可以自己准备一个本地的fallback回调,返回一个默认值; 这样做,虽然服务水平下降了,但好歹还可以用,比服务直接挂掉的要强;
3.服务降级处理是在客户端完成的，与服务端无关。

二十四、什么是服务监控 (Hystrix Dashboard)？

除了隔离依赖服务的调用之外,Hystrix还提供了准实时的调用监控(Hystrix Dashboard)，Hystrix会持续的记录所有通过Hystrix 发起请求的执行信息, 并以统计报表和图形的形式展示给用户,包括每秒执行多少请求、多少成功、多少失败等信息，并转化为可视化界面。

二十五、Zuul 是什么？

Zuul(路由网关)包含了对请求的路由和过滤两个重要的功能;
其中路由功能负责将外部请求转发到具体的微服务实例上,是实现外部访问统一入口的基础；而过滤功能则负责对请求的处理过程进行干预,是实现请求校验,服务聚合等功能的基础。

二十六、SpringCloud Config分布式配置中心是什么？

SpringCloud Config为服务构架中的微服务提供集中化的外部配置支持,配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置, 集中管理配置文件, 将配置信息已REST接口的形式暴露。

 

蹲小僵尸

蹲小僵尸

蹲小僵尸