微服务重点解析

1. Spring Cloud 组件有哪些？

2. 服务注册和发现是什么意思？Spring Cloud 如何实现服务注册和发现的？

如果写过微服务项目，可以说做过的哪个微服务项目，使用了哪个注册中心，常见的有 eureka、nacos；

对于 eureka：

• 服务注册：服务提供者需要把自己的信息注册到 eureka 中，由 eureka 来保存这些信息，比如服务名称、ip、端口等等；
• 服务发现：消费者向 eureka 拉取指定的服务列表信息，如果服务提供者有集群，则消费者会利用负载均衡算法，选择一个进行调用；
• 服务监控：服务提供者会每隔 30 秒向 eureka 发送心跳，报告健康状态，如果 eureka 服务 90 秒没接受到心跳，从 eureka 中剔除；

对于 nacos（与 eureka 的区别）：

• 服务注册和服务发现跟 eureka 差不多；
• 主要是服务监控上有区别：服务分为两大类，临时实例与非临时实例，两种服务收到的待遇还不一样；
  1. nacos 服务端支持主动检测服务提供者的状态：临时实例采用心跳模式（与 eureka 一致），非临时实例采用主动检测心跳模式；
  2. 临时实例心跳不正常会被剔除，非临时实例则不会被剔除；
  3. nacos 支持服务列表变更的消息推送模式，服务列表更新更加及时；
  4. nacos 集群默认采用 AP（高可用），当集群中存在非临时实例的时候，采用 CP（强一致）；Eureka 采用 AP；
• nacos 还支持配置中心，eureka 只支持注册中心，这也是选择使用 nacos 的一个重要原因；

3. 你们项目负载均衡是如何实现的？

（结合实际情况回答）负载均衡用的是 Ribbon，在发起远程调用的时候（RestTemplate 或者 Feign），会使用到 Ribbon 选取服务；

3.1 Ribbon 负载均衡策略有哪些？

• RoundRobinRule：简单轮询服务列表来选择服务器；
• WeightedResponseTimeRule：按照权重来选择服务器，响应时间越长，权重越小；
• RandomRule：随机选择一个可用的服务器；
• BestAvailableRule：忽略那些短路的服务器，并选择并发数较低的服务器；
• RetryRule：重试机制的选择逻辑；
• AvailabilityFilteringRule：可用性敏感策略，先过滤非健康的，再选择连接数较小的实例；
• ZoneAvoidanceRule：以区域可用的服务器为基础进行服务器的选择。使用 Zone 对服务器进行分类，这个 Zone 可以理解为一个机房/机架等。而后再对 Zone 内的多个服务做轮询；

3.2 如果想自定义负载均衡策略如何实现？

1. 如何配置负载均衡策略：
   1. Bean 注入容器法：全局
   2. 配置文件指定法：局部

2. 自己创建类实现 IRule（自定义 IRule 实现 => 自定义负载均衡规则），然后配置一下即可；

4. 什么是服务雪崩？怎么解决这个问题？

例如图中表示的：

1. 服务 D 宕机，服务 A 无法建立连接，仍然进行额外的尝试；
2. 服务 D 宕机，服务 A 建立了连接，消耗了连接池的连接数，阻塞等待服务 D 的响应/心跳检测服务 D 的活性，甚至请求会重传；
3. 服务 A 很可能撑不住就也故障了，而越往上层的服务调用者，阻塞的时间几何增长，也压根支持不了多少并发量，也会雪崩式的崩溃；

这样服务 D 宕机可能会导致依赖于它的其他服务出现连锁反应式的故障，最终导致整个系统崩溃！

• 服务故障但是没拒绝或直接响应异常导致的；

服务限流也是不错的处理方法，可以用 nginx，网关，sentinel 限流…

• 非本章重点，之后会讲；

4.1 服务降级（解决）

服务降级是服务自我保护的一种方式，或者保护下游服务（雪崩下面的服务消费者）的一种方式，用于确保服务不会受请求突增影响变得不可用，确保服务不会崩溃；

• 当访问失败、响应时间过长、资源不足之类的就会触发服务降级；

其做法就是，换另一个服务，也就是一个 Plan B：

1. 返回“稍后尝试”；
2. 执行其他的业务…

一般在实际开发中与 Feign 接口整合，编写降级逻辑：

4.2 服务熔断（预防）

服务熔断是通过监控对特定服务的调用响应时间和错误率等指标，当达到设定的阈值时，触发的机制，即停止对该服务的调用，并且在一段时间内拒绝对该服务的调用，从而避免故障的扩散。

这里主要说说 Hystrix 熔断机制，用于监控微服务调用情况：

1. 默认是关闭的，如果需要开启需要在引导类上添加注解：@EnableCircuitBreaker
2. 启动后，如果检测到 10 秒内请求的失败率超过 50%（这里可以理解为请求走“降级”逻辑的比率），就触发熔断机制；之后每隔5秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求；

5. 你们微服务是怎么进行监控的？

为什么需要监控？

• 服务与服务之间的远程调用链太过于复杂，并且来自各个地方的不同的请求可能会通过网关、服务 A、…、服务 B、使用中间件/使用数据库…
• 就可能出现以下几个问题：
  1. 问题定位
  2. 性能分析
  3. 服务关系
  4. 服务告警

常见的服务监控工具：

• 或者说是分布式系统应用程序性能监控工具（APM，Application Performance Management）

1. SpringBoot-admin
   • 简单，局限性大；
2. prometheus + Grafana
   • 企业常用，很不错，搭建困难；
3. zipkin（链路追踪工具）
   • 与业务代码耦合；
4. skywalking（链路追踪工具）
   • 搭建容易，可以很好地解决刚才提到的问题；

5.1 skywalking

skywalking 是一个分布式系统的 APM 工具，提供了完善的链路追踪能力，是 apache 的顶级项目；

• 如何搭建可以自己去网上搜，开源的，看看就会；

监控的对象：

• 服务（service）：业务资源应用系统（微服务）；
• 端点（endpoint）：应用系统对外暴露的功能接口；
• 实例（instance）：服务所在的物理机；

5.2 微服务监控

1. 对服务、端点、物理实例的访问时长与健康程度的监控并排名

2. 链路追踪（服务到服务、服务内部的 MySQL 访问等等）

可见，也可以用一些APM工具来发现 SQL 慢查询和定位慢查询，例如 skywalking；

• 还可以用调试工具：Arthas；运维工具：Prometheus；

3. 服务关系

4. 服务告警

当然，可以设置自己的告警规则，也可以设置发现问题发送短信/邮件给指定负责人的；

5.3 回答

采用的是 skywalking 进行监控：

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