原文标题：这些年背过的面试题——SpringCloud篇
原文作者：阿里云开发者
冷月清谈：
- Spring Cloud和Spring Boot概述: 解释了两者之间的关系，以及Spring Boot解决的问题和优势。
- 服务注册与发现: 介绍了Eureka和Zookeeper作为服务注册中心的作用，以及Eureka的缓存机制和自我保护机制。
- API调用: 讲解了Feign和Ribbon的使用方式，包括Feign的最佳实践和Ribbon的负载均衡算法。
- 服务容错: 探讨了Hystrix和Sentinel在服务雪崩场景下的作用，以及Hystrix的使用技巧和Sentinel的优势。
- 配置管理: 介绍了Nacos作为配置中心的功能特性和数据模型。
- 消息驱动: 简述了Spring Cloud Stream在构建消息驱动微服务中的作用。
- 分布式追踪: 解释了Sleuth和Zipkin如何实现全链路追踪，以及其在耗时分析、链路优化和聚合展示方面的应用。
- 安全认证: 讨论了Session认证、HTTP Basic认证、Token认证和JWT认证的机制，以及Token的最佳实践。
- 灰度发布和多版本隔离: 阐述了灰度发布的痛点和解决方案，以及多版本隔离的实现方式。
- 组件调优: 提供了针对网关、Hystrix、Ribbon和Feign等组件的调优建议，以提升微服务的性能和稳定性。
- 动态路由和日志: 介绍了如何结合配置中心实现Gateway的动态路由和Feign的动态日志。
怜星夜思：
2、Hystrix 和 Sentinel 都可以实现服务容错，它们之间有什么区别？在实际应用中如何选择？
3、如何保障微服务架构中的安全性？除了文中提到的方法，还有哪些安全措施可以采用？
原文内容
阿里妹导读
Why SpringCloud
Spring cloud 是一系列框架的有序集合。它利用 spring boot 的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用 spring boot 的开发风格做到一键启动和部署。
SpringBoot是Spring推出用于解决传统框架配置文件冗余，装配组件繁杂的基于Maven的解决方案，旨在快速搭建单个微服务，SpringCloud是依赖于SpringBoot的，而SpringBoot并不是依赖与SpringCloud，甚至还可以和Dubbo进行优秀的整合开发。
-
RestTemplate：基于HTTP协议；
-
Feign：封装了ribbon和Hystrix 、RestTemplate 简化了客户端开发工作量；
-
RPC：基于TCP协议，序列化和传输效率提升明显；
-
MQ：异步解耦微服务之间的调用；
Spring Boot
Spring Boot 通过简单的步骤就可以创建一个 Spring 应用。Spring Boot 为 Spring 整合第三方框架提供了开箱即用功能。Spring Boot 的核心思想是约定大于配置。
-
搭建后端框架时需要手动添加 Maven 配置，涉及很多 XML 配置文件，增加了搭建难度和时间成本。
-
将项目编译成 war 包，部署到 Tomcat 中，项目部署依赖 Tomcat，这样非常不方便。
-
应用监控做的比较简单，通常都是通过一个没有任何逻辑的接口来判断应用的存活状态。
spring-boot-starter-web //用于快速构建基于 Spring MVC 的 Web 项目。spring-boot-starter-data-redis //用于快速整合并操作 Redis。spring-boot-starter-data-mongodb //用于对 MongoDB 的集成。spring-boot-starter-data-jpa //用于操作 MySQL。
自定义一个Starter
-
创建 Starter 项目，定义 Starter 需要的配置（Properties）类，比如数据库的连接信息；
-
编写自动配置类，自动配置类就是获取配置，根据配置来自动装配 Bean；
-
编写 spring.factories 文件加载自动配置类，Spring 启动的时候会扫描 spring.factories 文件；
-
编写配置提示文件 spring-configuration-metadata.json（不是必须的），在添加配置的时候，我们想要知道具体的配置项是什么作用，可以通过编写提示文件来提示；
-
在项目中引入自定义 Starter 的 Maven 依赖，增加配置值后即可使用。
-
显示应用程序的监控状态、查看 JVM 和线程信息
-
应用程序上下线监控
-
可视化的查看日志、动态切换日志级别
-
HTTP 请求信息跟踪等实用功能
GateWay / Zuul
GateWay⽬标是取代Netflflix Zuul，它基于Spring5.0+SpringBoot2.0+WebFlux等技术开发，提供统⼀的路由⽅式（反向代理）并且基于 Filter(定义过滤器对请求过滤，完成⼀些功能) 链的⽅式提供了⽹关基本的功能，例如：鉴权、流量控制、熔断、路径重写、⽇志监控。
-
路由route： ⽹关最基础的⼯作单元。路由由⼀个ID、⼀个⽬标URL、⼀系列的断⾔（匹配条件判断）和Filter过滤器组成。如果断⾔为true，则匹配该路由。
-
断⾔predicates：参考了Java8中的断⾔Predicate，匹配Http请求中的所有内容（类似于nginx中的location匹配⼀样），如果断⾔与请求相匹配则路由。
-
过滤器filter：标准的Spring webFilter，使⽤过滤器在请求之前或者之后执⾏业务逻辑。
请求前pre类型过滤器：做参数校验、权限校验、流量监控、⽇志输出、协议转换等；
请求前post类型的过滤器：做响应内容、响应头的修改、⽇志的输出、流量监控等。
Eureka / Zookeeper
服务注册中⼼本质上是为了解耦服务提供者和服务消费者，为了⽀持弹性扩缩容特性，⼀个微服务的提供者的数量和分布往往是动态变化的。
-
us-east-1c、us-east-1d，us-east-1e代表不同的机房，每⼀个Eureka Server都是⼀个集群；
-
Service作为服务提供者向Eureka中注册服务，Eureka接受到注册事件会在集群和分区中进⾏数据同步，Client作为消费端（服务消费者）可以从Eureka中获取到服务注册信息，进⾏服务调⽤；
-
微服务启动后，会周期性地向Eureka发送⼼跳（默认周期为30秒）以续约⾃⼰的信息；
-
Eureka在⼀定时间内（默认90秒）没有接收到某个微服务节点的⼼跳，Eureka将会注销该微服务节点；
-
Eureka Client会缓存Eureka Server中的信息。即使所有的Eureka Server节点都宕掉，服务消费者依然可以使⽤缓存中的信息找到服务提供者；
新服务上线后，服务消费者不能立即访问到刚上线的新服务，需要过⼀段时间后才能访问？或是将服务下线后，服务还是会被调⽤到，⼀段时候后才彻底停⽌服务，访问前期会导致频繁报错！
-
第⼀层缓存是readOnlyCacheMap，采⽤ConcurrentHashMap来存储数据的，主要负责定时与readWriteCacheMap进⾏数据同步，默认同步时间为 30 秒⼀次。
-
第⼆层缓存是readWriteCacheMap，采⽤Guava来实现缓存。缓存过期时间默认为180秒，当服务下线、过期、注册、状态变更等操作都会清除此缓存中的数据。
-
如果两级缓存都无法查询，会触发缓存的加载，从存储层拉取数据到缓存中，然后再返回给 Client。
Eureka之所以设计⼆级缓存机制，也是为了提⾼ Eureka Server 的响应速度，缺点是缓存会导致 Client获取不到最新的服务实例信息，然后导致⽆法快速发现新的服务和已下线的服务。
-
我们可以缩短读缓存的更新时间让服务发现变得更加及时，或者直接将只读缓存关闭，同时可以缩短客户端如ribbon服务的定时刷新间隔，多级缓存也导致C层⾯（数据⼀致性）很薄弱。
-
Eureka Server 中会有定时任务去检测失效的服务，将服务实例信息从注册表中移除，也可以将这个失效检测的时间缩短，这样服务下线后就能够及时从注册表中清除。
-
期望最小每分钟能够续租的次数（实例* 频率 * 比例==10* 2 *0.85）
-
期望的服务实例数量（10）
-
Eureka Client 会定时发送心跳给 Eureka Server 来证明自己处于健康的状态；
-
集成SBA以后可以把所有健康状态信息一并返回给eureka；
Feign / Ribbon
-
Feign 可以与 Eureka 和 Ribbon 组合使用以支持负载均衡；
-
Feign 可以与 Hystrix 组合使用，支持熔断回退；
-
Feign 可以与ProtoBuf实现快速的RPC调用；
-
InvocationHandlerFactory 代理
采用 JDK 的动态代理方式生成代理对象，当我们调用这个接口，实际上是要去调用远程的 HTTP API；
-
Contract 契约组件
比如请求类型是 GET 还是 POST，请求的 URI 是什么；
-
Encoder 编码组件 \ Decoder 解码组件
通过该组件我们可以将请求信息采用指定的编码方式进行编解码后传输；
-
Logger 日志记录
负责 Feign 中记录日志的，可以指定 Logger 的级别以及自定义日志的输出；
-
Client 请求执行组件
负责 HTTP 请求执行的组件，Feign 中默认的 Client 是通过 JDK 的 HttpURLConnection 来发起请求的，在每次发送请求的时候，都会创建新的 HttpURLConnection 链接，Feign 的性能会很差，可以通过扩展该接口，使用 Apache HttpClient 等基于连接池的高性能 HTTP 客户端。
-
Retryer 重试组件
负责重试的组件，Feign 内置了重试器，当 HTTP 请求出现 IO 异常时，Feign 会限定一个最大重试次数来进行重试操作。
-
RequestInterceptor 请求拦截器
可以为 Feign 添加多个拦截器，在请求执行前设置一些扩展的参数信息。
-
继承特性
-
拦截器
比如添加指定的请求头信息，这个可以用在服务间传递某些信息的时候。
-
GET 请求多参数传递
-
日志配置
FULL 会输出全部完整的请求信息。
-
异常解码器
异常解码器中可以获取异常信息，而不是简单的一个code，然后转换成对应的异常对象返回。
-
源码查看是如何继承Hystrix
HystrixFeign.builder 中可以看到继承了 Feign 的 Builder，增加了 Hystrix的SetterFactory， build 方法里，对 invocationHandlerFactory 进行了重写， create 的时候返回HystrixInvocationHandler， 在 invoke 的时候会将请求包装成 HystrixCommand 去执行，这里就自然的集成了 Hystrix。
-
原生 API，Ribbon 是 Netflix 开源的，没有使用 Spring Cloud，需要使用 Ribbon 的原生 API；
-
Ribbon + RestTemplate，整合Spring Cloud 后，可以基于 RestTemplate 提供负载均衡的服务；
-
Ribbon + Feign；
-
RoundRobinRule 是轮询的算法，A和B轮流选择。
-
RandomRule 是随机算法，这个就比较简单了，在服务列表中随机选取。
-
BestAvailableRule 选择一个最小的并发请求 server。
-
实现 Irule 接口
-
继承 AbstractLoadBalancerRule 类
-
灰度发布
灰度发布是能够平滑过渡的一种发布方式，在发布过程中，先发布一部分应用，让指定的用户使用刚发布的应用，等到测试没有问题后，再将其他的全部应用发布。如果新发布的有问题，只需要将这部分恢复即可，不用恢复所有的应用。
-
多版本隔离
多版本隔离跟灰度发布类似，为了兼容或者过度，某些应用会有多个版本，这个时候如何保证 1.0 版本的客户端不会调用到 1.1 版本的服务，就是我们需要考虑的问题。
-
故障隔离
当线上某个实例发生故障后，为了不影响用户，我们一般都会先留存证据，比如：线程信息、JVM 信息等，然后将这个实例重启或直接停止。然后线下根据一些信息分析故障原因，如果我能做到故障隔离，就可以直接将出问题的实例隔离，不让正常的用户请求访问到这个出问题的实例，只让指定的用户访问，这样就可以单独用特定的用户来对这个出问题的实例进行测试、故障分析等。
Hystrix / Sentinel
-
封装请求会将用户的操作进行统一封装，统一封装的目的在于进行统一控制。
-
资源隔离限流会将对应的资源按照指定的类型进行隔离，比如线程池和信号量。
-
计数器限流，例如5秒内技术1000请求，超数后限流，未超数重新计数；
-
滑动窗口限流，解决计数器不够精确的问题，把一个窗口拆分多滚动窗口；
-
令牌桶限流，类似景区售票，售票的速度是固定的，拿到令牌才能去处理请求；
-
漏桶限流，生产者消费者模型，实现了恒定速度处理请求，能够绝对防止突发流量；
-
失败回退其实是一个备用的方案，就是说当请求失败后，有没有备用方案来满足这个请求的需求。
-
断路器这个是最核心的，，如果断路器处于打开的状态，那么所有请求都将失败，执行回退逻辑。如果断路器处于关闭状态，那么请求将会被正常执行。有些场景我们需要手动打开断路器强制降级。
-
指标监控会对请求的生命周期进行监控，请求成功、失败、超时、拒绝等状态，都会被监控起来。
-
配置可以对接配置中心进行动态调整
Hystrix 的配置项非常多，如果不对接配置中心，所有的配置只能在代码里修改，在集群部署的难以应对紧急情况，我们项目只设置一个 CommandKey，其他的都在配置中心进行指定，紧急情况如需隔离部分请求时，只需在配置中心进行修改以后，强制更新即可。
-
回退逻辑中可以手动埋点或者通过输出日志进行告警
当请求失败或者超时，会执行回退逻辑，如果有大量的回退，则证明某些服务出问题了，这个时候我们可以在回退的逻辑中进行埋点操作，上报数据给监控系统，也可以输出回退的日志，统一由日志收集的程序去进行处理，这些方式都可以将问题暴露出去，然后通过实时数据分析进行告警操作。
-
用 ThreadLocal配合线程池隔离模式需当心
当我们用了线程池隔离模式的时候，被隔离的方法会包装成一个 Command 丢入到独立的线程池中进行执行，这个时候就是从 A 线程切换到了 B 线程，ThreadLocal 的数据就会丢失。
-
Gateway中多用信号量隔离
网关是所有请求的入口，路由的服务数量会很多，几十个到上百个都有可能，如果用线程池隔离，那么需要创建上百个独立的线程池，开销太大，用信号量隔离开销就小很多，还能起到限流的作用。
Sentinel是⼀个⾯向云原⽣微服务的流量控制、熔断降级组件。替代Hystrix，针对问题：服务雪崩、服务降级、服务熔断、服务限流
-
独⽴可部署Dashboard（基于 Spring Boot 开发）控制台组件；
-
不依赖任何框架/库，减少代码开发，通过UI界⾯配置即可完成细粒度控制；
-
Sentinel不会像Hystrix那样放过⼀个请求尝试⾃我修复，就是明明确确按照时间窗⼝来，熔断触发后，时间窗⼝内拒绝请求，时间窗⼝后就恢复。
-
Sentinel Dashboard中添加的规则数据存储在内存，微服务停掉规则数据就消失，在⽣产环境下不合适。可以将Sentinel规则数据持久化到Nacos配置中⼼，让微服务从Nacos获取。
Config / Nacos
Nacos是阿⾥巴巴开源的⼀个针对微服务架构中服务发现、配置管理和服务管理平台。Nacos就是注册中⼼+配置中⼼的组合（Nacos=Eureka+Confifig+Bus）
-
服务发现与健康检查
-
动态配置管理
-
动态DNS服务
-
服务和元数据管理
-
Namespace 代表不同的环境，如开发dev、测试test、⽣产环境prod
-
Group 代表某项⽬，⽐如爪哇云项⽬
-
Service 某个项⽬中具体xxx服务
-
DataId 某个项⽬中具体的xxx配置⽂件
Bus / Stream
Spring Cloud Stream 消息驱动组件帮助我们更快速，更⽅便的去构建消息驱动微服务的；本质：屏蔽掉了底层不同MQ消息中间件之间的差异，统⼀了MQ的编程模型，降低了学习、开发、维护MQ的成本，⽬前⽀持Rabbit、Kafka两种消息；
Sleuth / Zipkin
安全认证
-
Session
认证中最常用的一种方式，也是最简单的。存在多节点session丢失的情况，可通过nginx粘性Cookie和Redis集中式Session存储解决。
-
HTTP Basic Authentication
服务端针对请求头中base64加密的Authorization 和用户名和密码进行校验。
-
Token
Session 只是一个 key，会话信息存储在后端。而 Token 中会存储用户的信息，然后通过加密算法进行加密，只有服务端才能解密，服务端拿到 Token 后进行解密获取用户信息。
-
JWT认证
JWT（JSON Web Token）用户提供用户名和密码给认证服务器，服务器验证用户提交信息的合法性；如果验证成功，会产生并返回一个 Token，用户可以使用这个 Token 访问服务器上受保护的资源。
-
认证服务提供认证的 API，校验用户信息，返回认证结果；
-
通过JWTUtils中的RSA算法，生成JWT token，token里封装用户id和有效期；
-
服务间参数通过请求头进行传递，服务内部通过 ThreadLocal 进行上下文传递；
-
Hystrix导致ThreadLocal失效的问题可以通过，重写 Hystrix 的 Callable 方法，传递需要的数据；
-
设置较短（合理）的过期时间。
-
注销的 Token 及时清除（放入 Redis 中做一层过滤）。
虽然不能修改 Token 的信息，但是能在验证层面做一层过滤来进行处理。
-
监控 Token 的使用频率。
为了防止数据被别人爬取，最常见的就是监控使用频率，程序写出来的爬虫程序访问频率是有迹可循的
-
核心功能敏感操作可以使用动态验证（验证码）。
比如提现的功能，要求在提现时再次进行验证码的验证，防止不是本人操作。
-
网络环境、浏览器信息等识别。
银行 APP 对环境有很高的要求，使用时如果断网，APP 会自动退出，重新登录，因为网络环境跟之前使用的不一样了，还有一些浏览器的信息之类的判断，这些都是可以用来保证后端 API 的安全。
-
加密密钥支持动态修改。
如果 Token 的加密密钥泄露了，也就意味着别人可以伪造你的 Token，可以将密钥存储在配置中心，以支持动态修改刷新，需要注意的是建议在流量低峰的时候去做更换的操作，否则 Token 全部失效，所有在线的请求都会重新申请 Token，并发量会比较大。
灰度发布
-
服务数量多，业务变动频繁，一周一发布；
-
灰度发布能降低发布失败风险，减少影响范围；
通过灰度发布，先让一部分用户体验新的服务，或者只让测试人员进行测试，等功能正常后再全部发布，这样能降低发布失败带来的影响范围；
-
当发布出现故障时，可以快速回滚，不影响用户；
灰度后如果发现这个节点有问题，那么只需回滚这个节点即可，当然不回滚也没关系，通过灰度策略隔离，也不会影响正常用户；
基于Discovery 服务注册发现、Ribbon 负载均衡、Feign 和 RestTemplate 调用等组件的企业级微服务开源解决方案，包括灰度发布、灰度路由、服务隔离等功能。
-
首先将需要发布的服务从转发过程中移除，等流量剔除之后再发布。
-
部分机器中的版本进行升级，用户默认还是请求老的服务，通过版本来支持测试请求。
-
测试完成之后，让新的版本接收正常流量，然后部署下一个节点，以此类推。
grayVersions = {"discovery-article-service":["1.01"]}
多版本隔离
各组件调优
server.tomcat.accept-count //请求队列排队数server.tomcat.max-threads //最大线程数server.tomcat.max-connections //最大连接数
Hystrix 的信号量（semaphore）隔离模式，并发量上不去很大的原因都在这里，信号量默认值是 100，也就是最大并发只有 100，超过 100 就得等待。
//信号量zuul.semaphore.max-semaphores //信号量：最大并发数//线程池hystrix.threadpool.default.coreSize //最大线程数hystrix.threadpool.default.maximumSize //队列的大hystrix.threadpool.default.maxQueueSize //等参数
gateway.host.max-per-route-connections //每个路由的连接数 gateway.host.max-total-connections //总连接数
ribbon.MaxConnectionsPerHost //单服务并发数ribbon.MaxTotalConnections //总并发数
feign.httpclient.max-connections-per-route//每个路由的连接数feign.httpclient.max-connections //总连接数