分布式——面试专题

一、传统单机架构到分布式架构的演变

1、传统单机架构

缺点： 开发速度慢 启动时间长 依赖庞大 优点： 易于测试 便于集成 小型项目友好

2、分布式架构

缺点：分布式系统-》分布式事务问题 需要管理多个服务-》服务治理 优点：独立的部署和启动 易开发、理解和维护

二、微服务架构核心组件

1、网关

路由转发 + 过滤器

/api/v1/video/ 视频服务/api/v1/order/ 订单服务/api/v1/user/ 用户服务

2、服务发现注册

调用和被调用方的信息维护

3、配置中心

管理配置，动态更新 application.properties

4、链路追踪

分析调用链路耗时 例子：下单-》查询商品服务获取商品价格-》查询用户信息-》保存数据库

5、负载均衡器

分发流量到多个节点，降低压力

6、熔断

保护自己和被调用方

三、微服务架构常见解决方案

1、ServiceComb

华为内部的CSE(Cloud Service Engine)框架开源, 一个微服务的开源解决方案,社区相对于下面几个比较小文档不多，通信领域比较强

2、dubbo

zookeeper + dubbo + springmvc/springboot

官方地址：http://dubbo.apache.org/#!/?lang=zh-cn

配套

通信方式：rpc注册中心：zookeper/redis/nacos配置中心：diamond、nacos

3、SpringCloud

全家桶+轻松嵌入第三方组件(Netflix 奈飞)

官网：https://spring.io/projects/spring-cloud

配套

通信方式：http restful注册中心：eruka配置中心：config 断路器：hystrix 网关：zuul/gateway 分布式追踪系统：sleuth+zipkin

4、Spring Alibaba Cloud

全家桶+阿里生态多个组件组合+SpringCloud支持

官网 https://spring.io/projects/spring-cloud-alibaba

配套

通信方式：http restful注册中心：nacos配置中心：nacos 断路器：sentinel 网关：gateway 分布式追踪系统：sleuth+zipkin

四、服务之间调用的几种方式

1、RPC:

远程过程调用，像调用本地服务(方法)一样调用服务器的服务支持同步、异步调用客户端和服务器之间建立TCP连接，可以一次建立一个，也可以多个调用复用一次链接 RPC数据包小 protobuf thrift rpc：编解码，序列化，链接，丢包，协议

2、Rest(Http):

http请求，支持多种协议和功能开发方便成本低http数据包大 java开发：resttemplate或者httpclient

五、注册中心

注册中心（服务治理）

1、服务注册：

服务提供者provider，启动的时候向注册中心上报自己的网络信息

2、服务发现：

服务消费者consumer,启动的时候向注册中心上报自己的网络信息，拉取provider的相关网络信息

3、核心:

服务管理,是有个服务注册表，心跳机制动态维护，服务实例在启动时注册到服务注册表，并在关闭时注销。

为什么要用

微服务应用和机器越来越多，调用方需要知道接口的网络地址，如果靠配置文件的方式去控制网络地址，对于动态新增机器，维护带来很大问题主流的注册中心：zookeeper、Eureka、consul、etcd、Nacos

AlibabaCloud搭配最好的是Nacos，且服务的注册发现之外，还支持动态配置服务

4、常见注册中心对比

结论：

分布式系统中P,肯定要满足，所以只能在CA中二选一没有最好的选择，最好的选择是根据业务场景来进行架构设计如果要求一致性，则选择zookeeper/Nacos，如金融行业 CP如果要求可用性，则Eureka/Nacos，如电商系统 AP CP ： 适合支付、交易类，要求数据强一致性，宁可业务不可用，也不能出现脏数据 AP: 互联网业务，比如信息流架构，不要求数据强一致，更想要服务可用

六、负载均衡

1、定义

分布式系统中一个非常重要的概念，当访问的服务具有多个实例时，需要根据某种“均衡”的策略决定请求发往哪个节点，这就是所谓的负载均衡，原理是将数据流量分摊到多个服务器执行，减轻每台服务器的压力，从而提高了数据的吞吐量

通过硬件来进行解决，常见的硬件有NetScaler、F5、Radware和Array等商用的负载均衡器，但比较昂贵的通过软件来进行解决，常见的软件有LVS、Nginx等,它们是基于Linux系统并且开源的负载均衡策略

2、常见的负载均衡策略

1、节点轮询

简介：每个请求按顺序分配到不同的后端服务器

2、weight 权重配置

简介：weight和访问比率成正比，数字越大，分配得到的流量越高

3、固定分发

简介：根据请求按访问ip的hash结果分配，这样每个用户就可以固定访问一个后端服务器

4、随机选择、最短响应时间等等

3、Ribbon

什么是Ribbon Ribbon是一个客户端负载均衡工具，通过Spring Cloud封装，可以轻松和AlibabaCloud整合

1、Ribbon支持的负载均衡策略

随机策略、轮询策略（默认）、重试策略、可用过滤策略、响应时间加权重策略、区域权重策略

4、新一代负载均衡组件feign

原先ribbon代码存在的问题：不规范，风格不统一，维护性比较差

1、什么是Feign:

SpringCloud提供的伪http客户端(本质还是用http)，封装了Http调用流程，更适合面向接口化让用Java接口注解的方式调用Http请求.不用像Ribbon中通过封装HTTP请求报文的方式调用 Feign默认集成了Ribbon

Nacos支持Feign,可以直接集成实现负载均衡的效果

5、 Ribbon和feign两个的区别和选择

选择feign默认集成了ribbon写起来更加思路清晰和方便采用注解方式进行配置，配置熔断等方式方便

七、CAP理论

CAP定理: 指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可同时获得

1、一致性（C）：所有节点都可以访问到最新的数据2、可用性（A）：每个请求都是可以得到响应的，不管请求是成功还是失败 3、分区容错性（P）： 除了全部整体网络故障，其他故障都不能导致整个系统不可用

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡

1、CA：

如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的

2、CP:

如果不要求A（可用），每个请求都需要在服务器之间保持强一致，而P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统

3、AP：

要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。

4、BASE理论

CAP 中的一致性和可用性进行一个权衡的结果，核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性, 来自 ebay 的架构师提出Basically Available(基本可用)

假设系统，出现了不可预知的故障，但还是能用, 可能会有性能或者功能上的影响

1、Soft state（软状态）

允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时

2、Eventually consistent（最终一致性）

系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问最终都能够获取到最新的值

八、微服务架构容错方案

1、限流

2、漏斗

不管流量多大，均匀的流入容器，令牌桶算法，漏桶算法

3、熔断：

保险丝，熔断服务，为了防止整个系统故障，包含当前和下游服务 下单服务 -》商品服务-》用户服务 -》（出现异常-》熔断风控服务

4、降级：

抛弃一些非核心的接口和数据，返回兜底数据 旅行箱的例子：只带核心的物品，抛弃非核心的，等有条件的时候再去携带这些物品

5、隔离：

服务和资源互相隔离，比如网络资源，机器资源，线程资源等，不会因为某个服务的资源不足而抢占其他服务的资源

熔断和降级互相交集

相同点：从可用性和可靠性触发，为了防止系统崩溃最终让用户体验到的是某些功能暂时不能用

不同点：服务熔断一般是下游服务故障导致的，而服务降级一般是从整体系统负荷考虑，由调用方控制想进行微服务的容错，业界目前有Sentinel、Hystrix，相对于AlibabaCloud而言，Sentinel是最好的搭配

分布式系统的流量防卫兵Sentinel

什么是Sentinel

阿里巴巴开源的分布式系统流控工具以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性丰富的应用场景：消息削峰填谷、集群流量控制、实时熔断下游不可用应用等完备的实时监控：Sentinel 同时提供实时的监控功能 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合

1、流量控制规则

1、基于统计并发线程数的流量控制

并发数控制用于保护业务线程池不被慢调用耗尽Sentinel 并发控制不负责创建和管理线程池，而是简单统计当前请求上下文的线程数目（正在执行的调用数目）如果超出阈值，新的请求会被立即拒绝，效果类似于信号量隔离。

2、基于统计QPS的流量控制

当 QPS 超过某个阈值的时候，则采取措施进行流量控制

2、流量控制的效果

1、直接拒绝

默认的流量控制方式，当QPS超过任意规则的阈值后，新的请求就会被立即拒绝

2、Warm Up

冷启动/预热，如果系统在此之前长期处于空闲的状态，我们希望处理请求的数量是缓步的增多，经过预期的时间以后，到达系统处理请求个数的最大值

3、匀速排队

严格控制请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法，主要用于处理间隔性突发的流量，如消息队列，想象一下这样的场景，在某一秒有大量的请求到来，而接下来的几秒则处于空闲状态，我们希望系统能够在接下来的空闲期间逐渐处理这些请求，而不是在第一秒直接拒绝多余的请求

匀速排队等待策略是 Leaky Bucket 算法结合虚拟队列等待机制实现的。 匀速排队模式暂时不支持 QPS > 1000 的场景

3、Sentinel 熔断策略

1、慢调用比例(响应时间):

选择以慢调用比例作为阈值，需要设置允许的慢调用 RT（即最大的响应时间），请求的响应时间大于该值则统计为慢调用

比例阈值：修改后不生效-目前已经反馈给官方那边的bug熔断时长：超过时间后会尝试恢复最小请求数：熔断触发的最小请求数，请求数小于该值时即使异常比率超出阈值也不会熔断

2、异常比例

当单位统计时长内请求数目大于设置的最小请求数目，并且异常的比例大于阈值，则接下来的熔断时长内请求会自动被熔断比例阈值熔断时长：超过时间后会尝试恢复最小请求数：熔断触发的最小请求数，请求数小于该值时，即使异常比率超出阈值也不会熔断

3、异常数

当单位统计时长内的异常数目超过阈值之后会自动进行熔断

异常数:熔断时长：超过时间后会尝试恢复最小请求数：熔断触发的最小请求数，请求数小于该值时即使异常比率超出阈值也不会熔断

4、服务熔断状态

1、熔断关闭（Closed）

服务没有故障时，熔断器所处的状态，对调用方的调用不做任何限制

2、熔断开启（Open）

后续对该服务接口的调用不再经过网络，直接执行本地的fallback方法

3、半熔断（Half-Open）

所谓半熔断就是尝试恢复服务调用，允许有限的流量调用该服务，并监控调用成功率

4、熔断恢复

经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态）尝试恢复服务调用，允许有限的流量调用该服务，并监控调用成功率。

如果成功率达到预期，则说明服务已恢复，进入熔断关闭状态；如果成功率仍旧很低，则重新进入熔断状态

九、JDK

1、OpenJDK和OracleJDK版本区别

OpenJDK是JDK的开放源码版本，以GPL协议的形式发布（General Public License）Oracle JDK采⽤了商业实现

2、LTS 是啥意思？

Long Term Support ⻓期⽀持的版本，如JDK8、JDK11都是属于LTSJDK9 和 JDK10 这两个被称为“功能性的版本”不同, 两者均只提供半年的技术⽀持甲⻣⽂释出Java的政策，每6个⽉会有⼀个版本的释出，⻓期⽀持版本每三年发布⼀次，根据 后续的发布计划，下⼀个⻓期⽀持版 Java 17 将于2021年发布

3、8u20、11u20是啥意思？

就是Java的补丁，⽐如JDK8的 8u20版本、8u60版本; java11的 11u20、11u40版本

十、微服务的网关和应用场景

什么是网关

API Gateway，是系统的唯一对外的入口，介于客户端和服务器端之间的中间层，处理非业务功能 提供路由请求、鉴权、监控、缓存、限流等功能

1、统一接入

智能路由AB测试、灰度测试负载均衡、容灾处理日志埋点（类似Nignx日志）

2、流量监控

限流处理服务降级

3、安全防护

鉴权处理监控机器网络隔离

1、主流的网关

1、zuul：

是Netflix开源的微服务网关，和Eureka,Ribbon,Hystrix等组件配合使用，依赖组件比较多，性能教差

2、kong:

由Mashape公司开源的，基于Nginx的API gateway

3、nginx+lua：

是一个高性能的HTTP和反向代理服务器,lua是脚本语言，让Nginx执行Lua脚本，并且高并发、非阻塞的处理各种请求

4、springcloud gateway:

Spring公司专门开发的网关，替代zuul

2、gateway

什么是 SpringCloud Gateway

Spring官方出品，基于Spring5+Reactor技术开发的网关性能强劲基于Reactor+WebFlux、功能多样基于springboot2.x, 直接可以jar包方式运行

1、路由：

是网关的基本单元，由ID、URI、一组Predicate、一组Filter组成，根据Predicate进行匹配转发

route组成部分id：路由的IDuri：匹配路由的转发地址predicates：配置该路由的断言，通过PredicateDefinition类进行接收配置。order：路由的优先级，数字越小，优先级越高。

2、交互流程

客户端向Spring Cloud Gateway发出请求如果网关处理程序映射确定请求与路由匹配则将其发送到网关Web处理程序通过特定过滤器链运行，前置处理-后置处理

3、Gateway内置的路由断言

什么是Gateway路由断言

Predicate 来源于Java8，接受输入参数，返回一个布尔值结果Spring Cloud Gateway 中 Spring 利用 Predicate 的特性实现了各种路由匹配规则转发的判断条件，SpringCloud Gateway支持多种方式，常见如：Path、Query、Method、Header等支持多个Predicate请求的转发是必须满足所有的Predicate后才可以进行路由转发

4、Gateway过滤器

过滤器生命周期

PRE： 这种过滤器在请求被路由之前调用,一般用于鉴权、限流等POST：这种过滤器在路由到微服务以后执行，一般用于修改响应结果，比如增加header信息、打点结果日志

网关过滤器分类

局部过滤器GatewayFilter：应用在某个路由上,每个过滤器工厂都对应一个实现类，并且这些类的名称必须以 GatewayFilterFactory 结尾全局过滤器：作用全部路由上,内置很多局部过滤器，顶级接口 GatewayFilterFactory,

内置很多全局过滤器，顶级接口 GlobalFilter

十一、微服务下的链路追踪系统

抛两个常见的问题

微服务调用链路出现了问题怎么快速排查？微服务调用链路耗时长怎么定位是哪个服务？

链路追踪系统

分布式应用架构虽然满足了应用横向扩展的需求，但是运维和诊断的过程变得越来越复杂，例如会遇到接口诊断困难、应用性能诊断复杂、架构分析复杂等难题，传统的监控工具并无法满足，分布式链路系统由此诞生核心：将一次请求分布式调用，使用GPS定位串起来，记录每个调用的耗时、性能等日志，并通过可视化工具展示出来

注意：AlibabaCloud全家桶还没对应的链路追踪系统，我们使用Sleuth和zipking（内部使用的鹰眼）

1、Sleuth

一个组件，专门用于记录链路数据的开源组件

2、zipkin

大规模分布式系统的APM工具（Application Performance Management）,基于Google Dapper的基础实现，和sleuth结合可以提供可视化web界面分析调用链路耗时情况

同类产品

鹰眼（EagleEye）CATtwitter开源zipkin，结合sleuthPinpoint，运用JavaAgent字节码增强技术

zipkin组成：Collector、Storage、Restful API、Web UI组成

3、使用Zipkin+Sleuth业务分析调用链路分析

sleuth收集跟踪信息通过http请求发送给zipkin serverzipkin server进行跟踪信息的存储以及提供Rest API即可Zipkin UI调用其API接口进行数据展示默认存储是内存，可也用mysql 或者elasticsearch等存储

十二、配置中心

统一管理配置, 快速切换各个环境的配置

总结

本文介绍了分布式面试相关信息的全部内容，后续我会不断更新，喜欢的请点击关注，我将会持续更新下去。