SpringCloud组件有哪些

• 注册中心/配置中心（eureka/nacos）：微服务之间需要相互远程调用，这些每个服务的地址需要动态的管理起来。
• 远程调用（Feign）：微服务需要相互调用。
• 负载均衡（Ribbon）：如果服务器是进行集群的，需要进行负载均衡。
• 服务熔断/服务保护（Hystrix/Sentinel）：在远程调用过程中可能会产生降级，甚至熔断，需要用到服务熔断。
• 网关（Gateway、Zuul）：如果微服务想对外暴露接口，统一使用的网关是服务的入口。

SpringCloud中服务注册和发现是什么意思？如何实现

在微服务中，当一个order服务想要调用user服务，这个时候order服务就是服务消费者，user服务是服务提供者，如果直接调用，后期user服务端口进行修改，甚至user服务集群，对于order服务来说都是非常麻烦的，这个时候就需要一个注册中心（eureka）用来管理服务之间的信息。服务通过心跳向注册中心同步，如果某个服务在90s内没有心跳，则eureka会将这个服务的信息删除，当服务启动，会将自己的信息注册到注册中心，当order从eureka中拉取user的服务信息，这个时候user是一个集群，需要通过负载均衡判断调用哪一个服务。

• 服务注册：当服务启动，会将自己的信息注册到注册中心。
• 服务发现：服务消费者需要从注册中心中拉去服务提供者的信息。
• 服务的健康监控：如果某个服务90s内没有心跳，则eureka会将这个服务的信息删除。

nacos和eureka的区别

在nacos提供了临时实例和非临时实例两种状态。默认情况下是true，这种状态和eureka是一样的。如果没有设置，则是非临时实例

• nacos会主动询问服务是否存活。
• 如果nacos中服务提供者信息进行了变更，那么nacos会主动向消费者push推送变更信息，服务列表更新会更及时。
• 临时实例的话当服务器心跳异常会在注册中心中删除，非临时实例不会。
• nacos集群默认AP（高可用）模式，当集群中存在非临时实例，则采用CP（高一致）模式，eureka中采用AP方式。
• nacos还支持配置中心，eureka只有注册中心。

负载均衡是如何实现的

当order需要调用user时，需要先调用负载均衡（Ribbon）这个时候Ribbon需要先从注册中心拉取user服务的信息，然后通过一定的负载均衡策略选择其中一个发起远程调用。

Ribbon的负载均衡策略有哪些

• Round Robin Rule：简单轮询服务列表来选择服务器。
• WeightedResponseTimeRule：按照权重来选择服务器，响应时间越长，权重越小。
• Random Rule：选择一个随机可用的服务器。
• 选择可用的并发较低的服务器。
• 选择可用的连接数量较少的服务器。
• Zone Avoidance Rule：以区域可用的服务器为基础进行选择。使用Zone对服务器进行分类，Zone可以理解为一个机房，比如两个机房一个在北京一个在上海，选择比较近的机房。没有区域概念就是轮询。

如何自定义负载均衡策略

可以通过常见类来实现IRule接口来修改负载均衡的规则和配置文件去自定义负载均衡。通过配置类配置的时候时全局生效的，通过配置文件去配置的话只有在哪个服务下哪个服务就是该策略。

什么是服务雪崩，怎么解决这个问题

在微服务中会有多个服务，服务之间通过Feign进行相互调用，此时一个服务突然异常，而这个服务的消费者服务比较多，就会造成服务雪崩。

解决方式有：

• 服务降级：当服务消费者调用时发生了异常就会返回一个网络异常，进行降级处理。服务降级是服务的自我保护的一种方式，用于确保服务不会受请求突增影响变得不可用，去报服务不会崩溃。一般实际开发中与Feign接口整合，编写降级逻辑。如果此时还是有大量请求访问，可能会触发熔断。
• 熔断降级（Hystix）：服务熔断降级可以直接解决服务雪崩问题，熔断有三种状态Closed、Open、Half-Open。Hystrix熔断机制，用于监控微服务的调用状态，默认是关闭的，如果需要开启需要在引导类上添加注解@EnableCircuit。如果检测到10s内的请求失败率超过50%，就会触发熔断机制，之后每隔5s尝试重新请求微服务，如果不能响应，继续熔断，如果可以到达，则关闭熔断机制，恢复正常请求。
• 限流（预防）。

微服务是如何监控的

首先是微服务为什么需要监控？首先就是当微服务中某个服务挂掉之后可以迅速定位，其次当微服务链路中出现性能问题能快速定位到是哪个服务性能的问题，还有就是需要维护复杂的服务关系，当链路中某个服务出现异常能够快速定位。问题定位、性能分析、服务关系、服务告警。

• 我们项目采用的是skywalking进行监控的。
• skywalking：分布式系统的应用程序性能监控工具（APM），提供了完善的链路追踪能力。
• skywalking主要监控的是服务、端点、实例。
  • 服务（service）：业务资源应用系统（微服务）。
  • 端点（endpoint）：应用程序对外暴露的接口。
  • 实例（instance）：物理机（物理地址）。
• 在进入skywalking之后我们可以看到有仪表盘、拓扑图、追踪、性能剖析、日志、警告功能。
  • 在仪表盘中可以查看目前我们集成的微服务，还有比较慢的微服务，不健康的微服务，接口的性能排序。
  • 在性能剖析中我们可以接口的性能的排序一级接口加载的耗时，也可以直观的看到接口都经过了哪些微服务，点击数据库接口还可以看到数据库的查询语句，如果有慢查询还可以通过explan去分析。
  • 在拓扑图中清晰的展示了服务和服务之间的关系，如果服务标红就是异常。
  • 在警告中，当服务达到告警规则就会进行告警。比如在过去10分钟的3分钟内平均响应时间超过1s3次，过去10分钟内服务器成功率低于80%达到两次，过去10分钟内服务器响应超过1s达到2次，过去10分钟内端口响应超过1s达到2次。

我们在项目中采用的是skywalking进行监控的，skywalking主要可以监控接口、服务、物理实例的一些状态，特别是在压测的时候可以看到众多服务中哪些服务和接口比较慢，我们可以针对性的分析和优化。我们还在skywalking中设置了告警规则，特别是项目上线之后，如果报错，我们设置了可以给相关负责人发送短信和邮件，第一时间知道项目bug情况并进行修复。

项目中有没有做限流，怎么做的

为什么限流？并发量过大、防止恶意刷接口，个人的话就是为大并发量做准备，使用压测工具进行实践。

• 限流的方式：tomcat可以设置最大连接数、Nginx中的漏桶算法、网关中的令牌桶算法、自定义拦截器。
• Nginx限流：
  • 使用漏桶算法，以固定的速率漏出，可以应对突发流量，可以设置漏桶的存储请求，可以设置漏桶以固定的速率漏出请求，多余的请求等待或抛弃。
  • 控制并发连接数，可以在配置中设置单个IP最多能持有的连接，也能设置虚拟主机（server）同时能处理并发连接的总数。
• 网关限流：可以在微服务路由中添加局部过滤器RequestRateLimiter可以根据IP或路径进行限流，可以设置每秒平均速率和令牌桶总容量，当请求达到令牌桶之后会获取令牌进行处理，没有获取令牌的会被阻塞或丢弃。

CAP和BASE

CAP主要是由Consistency（一致性）、Availabilit（可用性）、Partition tolerance（分区容错性）这三点组成，然不是系统无法同时满足这三个指标，这个结论就是CAP定理。

• 一致性：用户访问分布式系统中的任意节点，得到的数据必须一致，如果有修改就要进行同步操作。
• 可用性：用户访问集群中任意健康节点都能得到响应，而不是超时或拒绝，如果有节点异常，就不会去访问这个节点。
• 分区：因为网络或其他原因导致分布式中部分节点与其他节点失去连接，形成独立分区，这时只能等待网络连接进行数据同步。
• 容错：集群出现分区时，整个系统也要持续对外提供服务，分布式系统节点之间肯定是需要网络连接的，分区（P）是必然存在的。
• AP高可用，可以持续对外提供服务，但是不能保证CP强一致性。

BASE一共也有三个思想，是对CAP的一种解决思路。

• Basically Available（基本可用）：分布式在出现故障时，允许损失部分可用性，即保证核心可用。
• Soft State（软状态）：在一定时间内允许出现中间状态，如临时不一致状态。
• Eveatually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后最终达到数据一致。

分布式事务的解决方案

分布式服务的接口幂等性如何设计