SpringCloud

一.什么是springcloud

是微服务系统架构解决方案
包括:

注册中心

eureka nacos consul
硬编码服务提供者地址的方式有不少问题。要想解决这些问题，服务消费者需要一个强大的服务发现机制，服务消费者使用这种机制获取服务提供者的网络信息。不仅如此，即使服务提供者的网络地址发生变化，服务消费者也无须修改配置文件。

配置中心

springcloudconfig nacos 

远程调用

feign dubbo
以优雅的方式完成服务之间的通信

客户端负载均衡

ribbon
Ribbon 的作用是负载均衡，服务进行远程调用的时候，如果服务提供方搭建了集群,Ribbon通过负载均衡算法选择其中一个。

网关

springcloudgateway zuul
负责网络路由，可以做统一的认证、限流、认证授权、安全，等等。

服务监控和保护

hystrix sentinel  
服务链上，因为某个微服务的异常，而导致雪崩效应，整条服务链宕机的问题。

二.微服务架构的优点

降低了业务之间的耦合度
每个服务中只包含一种业务
便于服务的拓展
如果用户服务访问压力很大；我们就可以针对用户这个服务搭建集群，其他服务不能动；

三.微服务监控用的是什么技术

微服务架构监控通常使用的就是链路追踪
目前主流的链路追踪技术
SkyWalking
Zipkin+Sleuth
这些链路追踪技术都实现opentrace标准

四.CAP理论，BASE理论

CAP理论

	作为分布式系统架构应该遵守三个指标
		Consistency (一致性)
			即更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致。
			对于客户端来说，一致性指的是并发访问时更新过的数据如何获取的问题。
			从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致
	Availability (可用性)
		即服务一直可用，而且是正常响应时间。系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况
	Partition Tolerance (分区容错性)
		即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。分区容错性要求能够使应用虽然是一个分布式系统，而
	CP和AP：分区容错是必须保证的，当发生网络分区的时候，如果要继续服务，那么强一致性和可用性只能 2 选 1

BASE理论

	BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）
	BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
基本可用
		响应时间上的损失: 正常情况下，处理用户请求需要 0.5s 返回结果，但是由于系统出现故障，处理用户请求的时间变为 3 s。
		系统功能上的损失：正常情况下，用户可以使用系统的全部功能，但是由于系统访问量突然剧增，
		系统的部分非核心功能无法使用。
软状态
		数据同步允许一定的延迟
最终一致性
		系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态，不要求实时一致

五.Ribbon负载均衡算法、类型，如何配置

Ribbon负载均衡算法的类型

RoundRobinRule：轮询；
RandomRule：随机；
AvailabilityFilteringRule：会先过滤掉由于多次访问故障而处于断路器状态的服务，还有并发的连接数量超过阈值的服务，然后对剩余的服务列表按照轮询策略进行访问；
WeightedResponseTimeRule：根据平均响应时间计算所有服务的权重，响应时间越快的服务权重越大被选中的概率越大。刚启动时如果统计信息不足，则使用RoundRobinRule（轮询）策略，等统计信息足够，会切换到WeightedResponseTimeRule；
RetryRule：先按照RoundRobinRule（轮询）策略获取服务，如果获取服务失败则在指定时间内进行重试，获取可用的服务；
BestAvailableRule：会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务，然后选择一个并发量最小的服务；
ZoneAvoidanceRule：复合判断Server所在区域的性能和Server的可用性选择服务器；

如何配置

@Bean
public IRule xx() {
return new …
}

六.分布式架构下，Session 共享有什么方案

1.使用cookie来完成

用户登录成功后，将用户信息存储到cookie中
下次客户端访问服务器，通过判断是否有cookie从而判断是否登录

2.使用数据库同步session（效率不高）

用户登录成功后，将用户信息存储到session,然将session存储到数据库。
下次客户端访问服务器，从数据库中获取用户session；判断用户是否登录

3.使用token代替session（推荐）

七.分布式id生成方案

uuid

UUID长度过长，不适用于存储，耗费数据库性能。 ID无一定业务含义，可读性差。

基于redis、mongodb、zk等中间件生成

雪花算法

八.分布式锁解决方案

需要这个锁独立于每一个服务之外，而不是在服务里面,找一个公证人,这个人可以是:
数据库：利用主键冲突控制一次只有一个线程能获取锁，非阻塞、不可重入、单点、失效时间
Zookeeper分布式锁
Redis分布式锁

九.高并发场景下如何实现系统限流

Nginx限流
Redis+Lua限流
Spring Cloud Gateway限流
OpenResty限流
Sentinel限流