SpringCloudAlibaba

1.SpringCloud与Spring Cloud Alibaba的区别

1.springcloudAlibaba实际上是对我们的SpringCloud做的拓展组件的开发nacos，seata分布式解决框架。

2.目的是为了推广阿里的产品，如果使用了SpringCloudAlibaba,最好使用alibaba整个体系产品。

3.nacos分布式配置中心+nacos分布式注册中心=Eureka+config

2.SpringCloudAlibaba的组件？

1.Nacos：分布式注册和配置中心。

2.Sentinel：把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

3.Seata：一个易于使用的高性能微服务分布式事务解决方案。

4.RocketMQ：分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。

3.服务注册中心有哪些？什么是Alibaba Nacos？

首先说下什么是服务注册和发现：

服务注册和发现：

当服务消费者调用多个服务提供者组成的集群时，首先服务消费者会在本地配置文件中维护服务提供者集群的每个节点请求地址；其次服务提供者集群如果某个节点下线或者宕机，服务消费者本地配置文件中需要删除这些节点地址，防止请求这些地址发生请求失败。

这时需要引入服务注册中心，它需要这些功能：

服务的地址管理；服务注册；服务动态感知；

服务注册中心有nacos和eureka，zookeeper/consul;

接下来我介绍下nacos：

nacos解决微服务中的统一配置/服务注册和发现的问题，提供一套帮助开发者快速实现动态服务管理/服务配置及服务元数据的管理。

特性：

动态配置服务：nacos提供了简单的UI界面，帮助用户更好的实现对各个服务的管理和配置。

服务发现和服务健康检测： nacos提供了对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求。

服务注册原理：

1.服务提供方使用OpenApi发起服务注册请求；

2.Nacos服务端收到请求后，做以下三件事：

1.构建一个Service对象保存到ConcurrentHashMap中；

2.将服务缓存到内存中；

3.使用定时任务对当前的服务下的所有实例建立心跳机制；如果检测到当前服务下的某个实例最后发送的心跳包超时，则将健康状态设置为false，同时发送服务变更事件。

4.通过监听实现数据的一致性。

Nacos注册和发现的原理：

1、服务提供者在启动时，向注册中心注册自己提供的服务。

2、服务消费者在启动时，向注册中心订阅自己所需的服务，会在本地维护一个服务列表，获取实例是直接从本地获取，否则直接从注册中心获取。

3、注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

4、服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

5、服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。

4.LoadBalancer+Nacos实现负载均衡，默认为轮询配置？

• RandomLoadBalancer 随机
• RoundRobinLoadBalancer 轮询

5.SpringCloudAlibaba Nacos Config ？

nacos采用的是pull模式，不是简单的pull模式，而是一种长轮询的机制，他结合push和pull的操作两者之间的优势。客户端采用长轮询的机制定时发起pull请求，去检查服务端的配置信息是否发生变更，如果发生变更则根据变更的数据获取最新的配置。

如果客户端和服务端的数据保持一致，那么服务端会拿到这个链接之后在设置一个定时任务，延期29.5s，并把当前客户端的长连接轮询加入到allSubs队列中。如果在这段时间内配置没有发生变更，则会把结果返回给客户端。

在这段时间内任意时刻，对配置进行修改，就会触发事件机制，将变更的数据推送到客户端。

6.基于Sentinel的微服务限流及熔断？简单介绍下Sentinel？

为了保护微服务之间的稳定性，Sentinel以流量为切入点，从流量控制/流量路由/熔断降级等多个维度来保护服务的稳定性。

组成：

核心库：能够运行java所有的运行环境，同时对Dubbo/SpringCloud也有较好的支持

控制台：基于SpringBoot开发，打包后直接运行。

特征：

完善的实时监控，广泛的开源生态：与SpringCloud/Dubbo等框架进行整合。完善的Spi拓展机制。

服务限流/熔断

服务限流目的是为了更好的保护我们的服务 ，在高并发的情况下，如果客户端请求的数量达到一定极限（后台可以配置阈值），请求的数量超出了设置的阈值，开启自我的保护，直接调用我们的服务降级的方法，不会执行业务逻辑操作，直接走本地falback的方法，返回一个友好的提示。

服务降级

在高并发的情况下， 防止用户一直等待，采用限流/熔断方法，使用服务降级的方式返回一个友好的提示给客户端，不会执行业务逻辑请求，直接走本地的fallback的方法。返回一个友好的提示给到客户端。

服务的雪崩效应：

默认的情况下，Tomcat和Jetty服务器只有一个线程池去处理客户端的请求，这样的话就会在高并发的情况下，如果客户端所有的请求都会堆积到同一个服务接口上，那么就会产生tomcat服务器的所有接口都在处理接口，可能会导致其他接口无法访问。

服务的隔离机制：

信号量隔离机制：最多只有一定的阈值的线程数来处理我们的请求，超过阈值就会拒绝请求。

线程池隔离机制：每个服务接口都有自己独立的线程池，互不影响。

7.分布式事务理论模型有哪些？

AP：应用程序 TM：事务管理器,负责协调和管理事务 RM：资源管理器，比如数据库

7.1两阶段提交模式：

准备阶段：事务管理器通知资源管理器准备分支事务，记录事务日志，并告知事务管理器的准备结果。

提交/回滚阶段：如果所有的资源管理器在准备阶段都明确返回，则事务管理器向所有的资源管理器发起事务提交指令完成数据的变更。反之，任何一个资源管理器明确返回失败，则事务管理器会向所有的资源管理器发送事务回滚指令。

问题：

同步阻塞，所有的参与者都是事务阻塞型的， 对于任何一次指令都必须要有明确的响应才能进行下一步，否则会出现阻塞状态。

事务协调者的单点故障：如果协调者在第二阶段出现了故障，那么其他参与者会一直处于锁定状态。

脑裂导致数据的不一致：在第二阶段，因为局部网络的问题导致只有一部分参与者接收到commit请求。另一部分会执行事务。

7.2三阶段提交模式：

利用超时机制来解决同步阻塞的问题。

canCommit：询问阶段，事务协调者向参与者发送事务执行请求，询问是否可以完成指令，参与者只需要进行回答是或者不是即可。

preCommit：准备阶段，事务协调者会根据参与者返回的信息决定是否执行，如果所有参与者都返回可以执行操作，则事务协调者会向所有的参与者发送PreCommit操作，参与者接收到信息后会写redo和undo日志，执行事务但不提交事务。如果有任何一个参与者返回失败操作的结果，那么事务协调者会向所有的参与者发送中断事务操作。 DoCommit：事务协调者会向所有参与者发送事务提交命令，如果任何一个参与者返回失败，那么事务协调者就会发起中止指令操作。

7.3 CAP定理和BASE理论：

CAP:保证数据的一致性，降低可用性。

CAP理论：

C：一致性，数据在多个副本要保持强一致性。

A：可用性：系统对外提供 的服务一直处于可用的状态。

P：分区容错性：在分布式系统中遇到的任何网络分区故障，系统仍能正常对外提供服务。

CAP理论证明，在分布式系统中，要么是AP，要么是CP；

AP:保证了最终的一致性；

CP:实现了强一致性，前面提到的两/三阶段提交，可能因为一个操作用户需要等待很长时间。

BASE理论：牺牲强一致性，获得高可用性。

BA：（基本可用）分布式系统在出现故障时，允许损失一部分功能的可用性，保证核心功能可用。

S：（软状态）允许系统中的数据存在中间状态，不影响系统的可用性。

E：（最终一致性）中间状态的数据经过一段时间后，会达到最终的数据一致性。

8.分布式事务的解决问题方案？

TCC补偿方案：

Try：这个阶段主要对数据进行校验。

Confirm：确认真正执行的任务，只操作Try阶段预留的资源。

Cancel：释放Try阶段预留的资源。

它是一种两阶段提交的思想。第一段通过Try进行准备操作，第二阶段Confirm/Cancel表示Try阶段操作的回滚和确认。

基于可靠性消息的最终一致性方案：

生产者发送一条事务消息到消息队列中，消息队列只记录这条消息的数据，并不会被消费；

生产者执行具体的业务逻辑，完成本地事务操作；

接着生产者根据本地事务的执行结果发送一条确认消息给消息队列，如果本地事务执行成功，则发送一个Commit信息，表示在第一步中发送的消息可以被消费。

如果本地事务执行失败，那么消息队列服务器会定时回看生产者获取本地事务的执行结果，然后根据回查结果来决定这条消息是否消费；

消息队列服务器上的消息被胜差这确认后，消费者就可以消费这条消息，消息消费完成后，发送一个确认的标识给消息 队列服务器，表示该消息投递成功。

最大努力通知型：如果消费者没有发送消息进行确认，那消费者会不断的进行重试，直到收到一个消息确认或者达到最大重试次数。

9.为什么需要使用网关？

微服务通过分别调用多个服务获取到的数据:

1.服务的鉴权分布在每个微服务中，客户端 都需要对于每个服务的调用需要重复鉴权。

2.在后端的微服务架构中，可能不同的服务需要采用的协议不同。客户端调用多个服务，需要对不同的协议进行适配。

3.客户端发起多次请求，增加了网络通信的成本和客户端的处理的复杂性。

10.网关的作用有哪些？

1.针对统一请求进行鉴权/限流/熔断及日志；

鉴权：

客户端身份的验证，主要判断当前的用户是否是为合法用户，将用户名的账号和密码进行验证，对于一些复杂情景需要使用aksk及加密算法等；

客户端访问权限的控制：增加网关层，在网关层进行请求拦截，获取请求中附带的用户身份信息，调用统一认证中心对请求进行身份验证，再确认身份后再检查是否有访问的权限。

网关的本质是对请求进行路由转发/请求进行前置和后置的过滤。

api网关：Zuul/GateWay

11.你知道有哪些网关？介绍一下？

Zuul: 是Netflix开源的微服务网关

主要功能是路由的转发和过滤；会根据请求的路径不同，网关会定位到指定的微服务，并请求到不同的微服务接口，他对外隐蔽了微服务的真正接口地址。

Pre Filters:前置过滤器，请求被路由之前的调用，可以用于鉴权/限流。

Routing Filters:路由过滤器，将请求路由到后端的微服务中；

Post Filters：后置过滤器，路由过滤器中远程调用结束后执行，可以用作统计/监控/日志等。

Error Filters:错误过滤器，任意一个过滤器出现异常或者远程调用服务超时会被调用。

GateWay：Spring官方团队研究出来的API网关技术，取代zuul为微服务提供一种简单高效的API网关。

SpringCloudGateWay 由路由/谓语/过滤器组成；

Route：网关的基本组件，由ID/目标URL/Predicate集合

Predicate：如果Predicate的聚合判断结果为true，意味着该请求会被当前的Route进行转发。

Filfter：为请求提供前置和后置过滤

Spring Cloud Gateway启动时基于Netty Server 监听一个指定的端口，当客户端发送一个请求到网关时，网关根据一些列的Predicate的匹配结果来决定访问哪个Route，然后根据过滤器链进行请求的处理。

GateWay集成Sentinel实现限流的功能。

12.谈谈你对Seata的理解？

在微服务的架构下，由于数据库的应用和应用服务的拆分，导致原本一个事务单元中的多个DML操作，变成了跨进程或者跨数据库的多个事务单元的多个DML操作。传统的数据库事务无法解决这类问题，所以就引出了分布式事务；

分布式事务主要解决跨网节点的多个事务的数据一致性的问题，常用的方式由两种：

强一致性：就是所有事务参与者要么全部成功，要么全部失败，全局事务协调者需要知道每个事务的参与者的执行状态，在根据状态来决定数据的提交或者回滚。

弱一致性：也就是多个网络节点的数据允许出现不一致的情况，但是在最总的某个时间点达到数据的一致性。

强一致性方案可能对于应用的性能和可用性会有影响，所以对于数据一致性要求不高的场景就会用最终一致性的算法。

对于强一致性，我们可以通过二/三阶段提交来实现，对于弱一致性，可以基于Tcc事务模型/可靠性消息模型。

Seata就是其中一种分布式解决框架，封装了四种分布式事务：

AT模式：基于本地事务+二阶段协议来实现数据的最终一致性方案。

TCC模式：把一个完整的业务逻辑拆分成三个阶段，然后通过事务管理器在业务逻辑每个分支事务的执行情况分别调用该业务的Confirm或者Cancel方法。

Sega模式：sega模式是seata提供的长事务的解决方案，在Sega模式中，业务流程中的每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者。

XA模式：XA可以认为i是一种强一致性的事务解决方案，他利用事务资源对XA协议的支持，以XA协议的机制来管理分支事务的一种事务模式。

SpringCloud

1.SpringCloud的五大组件是啥？

Eureka：服务治理的组件，包含服务注册中心，服务注册与发现机制的实现；

Hytrix：容错管理组件，实现断路器模式，帮助服务依赖中出现延迟和为故障提供强大的容错能力。

Ribbon：客户端负载均衡的服务调用组件；

Zuul：网关组件，提供智能路由和访问过滤的等功能。

Feign：基于Ribbon和Hytrix的声明式服务调用组件，基于注解和选择的机器，拼接请求的URL地址发起请求。

2. Eureka和Zookeeper和Nacos的区别？

1.Eureka:保证AP，Eureka保证可用性，各个节点都是平等的，几个节点挂了不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。只要有有一台Eureka存在，就能保证服务的可用性。

Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端和注册中心出现了网络故障。

1.Eureka仍会接受新服务注册和查询请求，但是不会被同步到其他节点中。

2.当网络稳定后，当前的实例新的注册信息会被同步到其他节点中。

Eureka可以很好的解决因网络故障导致部分节点失去联系的问题。

2.Zookeeper： 保证CP。可以容忍注册中心返回的是几分钟以前的注册信息，但是不能接受服务直接挂掉，也就是服务注册对可用性的要求高于一致性。当master节点因为网络故障与其他节点失去联系，剩余节点会重新进行leader选举，在选举的时间内，整个zk的服务是不可用的。

3.Nacos： 注册的服务实例分为两种类型：临时实例和非临时实例，临时实例就是实例宕机超过一定时间，会从服务列表中删除，默认的类型。非临时实例就是如果实例宕机不会从服务列表中删除。Nacos默认采用的是AP方式，当集群中存在非临时实例时，采用的是CP模式。都是支持服务列表变更的消息推送模式，服务列表更新更及时 。

3.Eureka和Nacos的区别？

Nacos与Eureka均提供注册中心和服务治理功能。

1.Nacos具备服务优雅的上下线和流量管理（Api+后台管理界面），而Eureka后台只提供了展示，需要使用api操作上下线不具备流量管理。

2.从部署来看，Nacos整合了注册中心/配置中心的功能，把原来两套集群整合成一套。

3.从长远来看，Eureka开源工作已经停止，后续不在更新和维护。而Nacos后续会支持SpringCloud+Kubernets的组合。

4.在伸缩和扩容方面，Nacos比Eureka更优。

5.appollo容器化比较困难，Nacos有官网的镜像可以直接部署。

4.Eureka的服务注册和发现原理？

1.各个节点启动后会将它的ip地址等信息注册到EurekaServer；

2.在客户端应用启动后，从Eureka服务端拉取注册信息到本地缓存中，同时初始化3个定时器，发送心跳/缓存刷新/按需注册；

3.将会向Eureka Server发送心跳，通过发送心跳到Server以维持和更新注册表中服务实例元数据的有效性。在一定时长内，Server没有收到Client的心跳信息，将默认下线，会把服务实例信息从注册表中删除。

定时从eureka服务端拉取注册表的信息，更新本地缓存。

监控客户端自身的变化，如果变了重新发起注册。

5.Eureka的缺点？

当某个服务不可用时，各个Eureka Client不能及时的知道，需要1-3个心跳破周期才能感觉到。

6.Eureka的自我保护是什么？

如果Eureka Service 在一定的时间内没有接收到某个微服务的心跳，Eureka会进入到自我保护模式，在该模式下Eureka Service会保护服务注册表的信息，不在删除注册表中的数据，当网络故障回复后，Eureka Service节点会自动退出自我保护模式。

7.SpringCloud中的Eureka使用的负载均衡的方法？

1.RoundRobinRule:轮询策略，Ribbon以轮询的方式选择服务器。

2.RandomRule:随机选择，也就是说Ribbon会随机从服务器列表中选择一个进行访问。

3.BestAvailableRule:最大可用策略，即先过滤出故障服务器，选择一个当前并发请求数最小的。

4.WeightedResponseTimeRule:带有加权的轮询策略，对各个服务器相应的时间进行加权处理，然后在轮询的方式进行获取相应的服务器。

5.AvaliablityFilteringRule:可用过滤的策略，先过滤出故障的或并发请求大于阈值的一部分实例，然后在以线性轮询的方式从过滤后的实例清单中选出一个。。

8.微服务的优缺点？

单一职责：每个微服务仅负责自己业务领域的功能；

自治：一个微服务就是一个独立的实体，它可以独立部署/升级。

逻辑清晰：微服务的单一职责特性使微服务看起来逻辑清晰，易于维护。

技术异构：不同的微服务之间，可以根据自己的业务特点选择不同的技术架构，如 数据库。

缺点：

复杂度高：

运维复杂：系统由多个独立运行的微服务构成，需要设计一个良好的监控系统对对各个微服务的运行状态进行状态监控。

通信延迟：微服务之间调用会有时间损耗，造成通信延迟。

9.Ribbon是什么？

Ribbon是Netflix发布的开源项目，主要功能就是提供客户端的软件负载均衡算法。

Ribbon客户端组件提供一系列完善的配置项，简单的说就是在配置文件中列出所有后面的所有机器，Ribbon会自动的帮助你基于某种原则去链接这些机器。

底层原理：

Ribbon使用discoveryClient从注册中心读取目标服务信息。对同一个接口请求进行计数，使用相关的算法获取到相关的目标文件。

10.Nginx和Ribbon的区别？

Nginx是通过反向代理的同时可以实现负载均衡，nginx拦截客户端请求采用负载均衡的策略，根据UpStream配置进行转发，相当于通过nginx进行转发。

Ribbon是客户端负载均衡，从注册中心读取目标服务器信息，然后客户端采用轮询策略对服务直接访问，全程在客户端进行操作。

11.介绍一下Hystrix？

在分布式系统中，我们一定会依赖各种服务，那么这些服务一定会出现失败的情况，就会导致雪崩。Hystrix就是这样的一个工具，防雪崩利器。

服务降级：当客户端请求服务器端时候，防止客户端一直等待，不会处理业务的逻辑代码，直接返回一个友好的提示给客户端。

服务熔断：接口调用失败就会进入调用接口提前定义好的一个熔断方法，返回错误信息。

服务隔离：Hystrix为隔离的服务开启一个独立的线程池，这样在高并发的情况先不会影响其他服务。

服务监控：在服务发生调用时，会将每秒请求数/成功请求数等运行指标记录下来。

原理：

Hystrix实现服务降级的功能就是通过重写HystrixCommand中的getFallback()方法，当Hytrix的run方法或者construct方法发生错误的转而执行getFallback().

12.Feign是什么？

是SpringCloud组件中一个轻量级Restful的Http客户端，Feign内置了Ribbon，用来做客户端的负载均衡，去调用服务注册中心的服务。Feign的使用方式就是使用Feign的注解定义的接口，调用这个接口就可以直接调用服务注册中兴的服务。

KeyCloak

官网说的一句话就是：KeyCloak是以最少的麻烦为应用程序和安全服务添加身份验证，不需要存储用户和身份验证的用户，开箱即用。

KeyCloak默认使用的H2数据库，可以使用我们本地库，更方便的对keycloak的数据进行管理。

属性概念：

域： 相当于一个租户。 它允许创建隔离的应用程序组和用户组。 默认情况下，Keycloak中只有一个域叫做master。 这是专门用来管理的所有的域，不应该用于您自己的应用程序。

用户：相当于每个客户端使用到的用户。

客户端： 相当于一个APP.

我们为什么使用keycloak？

1.基于使用场景。因为我们需要将我们的几个应用程序打通，同一个用户可以使用多个应用。

2.KeyCloak为Web应用和Restful服务提供一站式的单点登录解决方案。同时为我们提供了可视化的管理界面，可以使用该界面进行用户的管理。

3.基于实践的开源，红帽良好的口碑决定了Keycloak的可靠性。

4.这个框架对Spring Security和Spring Boot做了适配，非常适合使用了这两种体系的迁移扩展。

缺点：

学习成本比较高，中文资料比较少，需要自己去啃官方的文档。

这个程序适合做统一认证授权门户构建，不太适合一些小应用，相对比较重。

今年二月份宣布Keycloak团队将不再提供针对Spring Security和Spring Boot的集成方案。

请求的步骤：

用户资源访问请求首先达到Gateway。

Gateway将用户登录信息发送给验证服务（keycloak），用于用户身份验证。验证通过后验证服务会传回一个token，用于标识用户信息（如用户名，权限，角色等）；

Gateway从discovery 服务中获取所有注册上来的微服务，从中找到需要使用的微服务；

Gateway将用户请求以及token路由至正确的微服务，微服务获取到请求后，会去验证token是否合法并解析token中包含的用户信息，用于判断所请求的资源是否有权限访问。

\