微服务重点解析
1. Spring Cloud 组件有哪些？
2. 服务注册和发现是什么意思？Spring Cloud 如何实现服务注册和发现的？
如果写过微服务项目，可以说做过的哪个微服务项目，使用了哪个注册中心，常见的有 eureka、nacos；
对于 eureka：
- 服务注册：服务提供者需要把自己的信息注册到 eureka 中，由 eureka 来保存这些信息，比如服务名称、ip、端口等等；
- 服务发现：消费者向 eureka 拉取指定的服务列表信息，如果服务提供者有集群，则消费者会利用负载均衡算法，选择一个进行调用；
- 服务监控：服务提供者会每隔 30 秒向 eureka 发送心跳，报告健康状态，如果 eureka 服务 90 秒没接受到心跳，从 eureka 中剔除；
对于 nacos（与 eureka 的区别）：
- 服务注册和服务发现跟 eureka 差不多；
- 主要是服务监控上有区别：服务分为两大类，临时实例与非临时实例，两种服务收到的待遇还不一样；
- nacos 服务端支持主动检测服务提供者的状态：临时实例采用心跳模式（与 eureka 一致），非临时实例采用主动检测心跳模式；
- 临时实例心跳不正常会被剔除，非临时实例则不会被剔除；
- nacos 支持服务列表变更的消息推送模式，服务列表更新更加及时；
- 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 如果想自定义负载均衡策略如何实现？
- 如何配置负载均衡策略：
- Bean 注入容器法：全局
- 配置文件指定法：局部
- 自己创建类实现 IRule（自定义 IRule 实现 => 自定义负载均衡规则），然后配置一下即可；
4. 什么是服务雪崩？怎么解决这个问题？
例如图中表示的：
- 服务 D 宕机，服务 A 无法建立连接，仍然进行额外的尝试；
- 服务 D 宕机，服务 A 建立了连接，消耗了连接池的连接数，阻塞等待服务 D 的响应/心跳检测服务 D 的活性，甚至请求会重传；
- 服务 A 很可能撑不住就也故障了，而越往上层的服务调用者，阻塞的时间几何增长，也压根支持不了多少并发量，也会雪崩式的崩溃；
这样服务 D 宕机可能会导致依赖于它的其他服务出现连锁反应式的故障，最终导致整个系统崩溃！
- 服务故障但是没拒绝或直接响应异常导致的；
服务限流也是不错的处理方法，可以用 nginx，网关，sentinel 限流…
- 非本章重点，之后会讲；
4.1 服务降级（解决）
服务降级是服务自我保护的一种方式，或者保护下游服务（雪崩下面的服务消费者）的一种方式，用于确保服务不会受请求突增影响变得不可用，确保服务不会崩溃；
- 当访问失败、响应时间过长、资源不足之类的就会触发服务降级；
其做法就是，换另一个服务，也就是一个 Plan B：
- 返回“稍后尝试”；
- 执行其他的业务…
一般在实际开发中与 Feign 接口整合，编写降级逻辑：
4.2 服务熔断（预防）
服务熔断是通过监控对特定服务的调用响应时间和错误率等指标，当达到设定的阈值时，触发的机制，即停止对该服务的调用，并且在一段时间内拒绝对该服务的调用，从而避免故障的扩散。
这里主要说说 Hystrix 熔断机制，用于监控微服务调用情况：
- 默认是关闭的，如果需要开启需要在引导类上添加注解：@EnableCircuitBreaker
- 启动后，如果检测到 10 秒内请求的失败率超过 50%（这里可以理解为请求走“降级”逻辑的比率），就触发熔断机制；之后每隔5秒重新尝试请求微服务，如果微服务不能响应，继续走熔断机制。如果微服务可达，则关闭熔断机制，恢复正常请求；
5. 你们微服务是怎么进行监控的？
为什么需要监控？
- 服务与服务之间的远程调用链太过于复杂，并且来自各个地方的不同的请求可能会通过网关、服务 A、…、服务 B、使用中间件/使用数据库…
- 就可能出现以下几个问题：
- 问题定位
- 性能分析
- 服务关系
- 服务告警
常见的服务监控工具：
- 或者说是分布式系统应用程序性能监控工具（APM，Application Performance Management）
- SpringBoot-admin
- 简单，局限性大；
- prometheus + Grafana
- 企业常用，很不错，搭建困难；
- zipkin（链路追踪工具）
- 与业务代码耦合；
- skywalking（链路追踪工具）
- 搭建容易，可以很好地解决刚才提到的问题；
5.1 skywalking
skywalking 是一个分布式系统的 APM 工具，提供了完善的链路追踪能力，是 apache 的顶级项目；
- 如何搭建可以自己去网上搜，开源的，看看就会；
监控的对象：
- 服务（service）：业务资源应用系统（微服务）；
- 端点（endpoint）：应用系统对外暴露的功能接口；
- 实例（instance）：服务所在的物理机；
5.2 微服务监控
- 对服务、端点、物理实例的访问时长与健康程度的监控并排名
- 链路追踪（服务到服务、服务内部的 MySQL 访问等等）
可见，也可以用一些APM工具来发现 SQL 慢查询和定位慢查询，例如 skywalking；
- 还可以用调试工具：Arthas；运维工具：Prometheus；
- 服务关系
- 服务告警
当然，可以设置自己的告警规则，也可以设置发现问题发送短信/邮件给指定负责人的；
5.3 回答
采用的是 skywalking 进行监控：
- skywalking 主要可以监控接口、服务、物理实例的一些状态。特别是在压测的时候可以看到众多服务中的哪些服务和接口比较慢，例如慢查询之类的，我们可以针对性的分析与优化；
- 我们还在 skywalking 设置了告警规则，特别是在项目上线后，我们分别给微服务设置了给相关负责人，如果出错，可以给 TA 发送短信/邮件，第一时间知道项目的 bug 情况，并尽可能快的去修复；
