我乐了的博客

同样也是采用配置的方式来启用，对于 Feign 拦截器的配置采用的 @ConditionalOnClass 来判断当前 classpath 中是否有指定的类，因为有的项目依赖了 core，但是不需要使用 Feign，也就没有 Feign 的依赖，这个时候就会报错了，像网关中就是这样，所以加了 @ConditionalOnClass 来判断。前端页面只实现了 2 个，一个是登录的页面，负责登录的功能，一个是文章详情的页面，负责获取文章信息展示，同时在这边还有个退出登录的按钮，执行退出操作。

这其实就是服务发现的一个问题，当我们需要调用服务实例时，信息是从注册中心 Eureka 获取的，然后通过 Ribbon 选择一个服务实例发起调用，如果出现调用不到或者下线后还可以调用的问题，原因肯定是服务实例的信息更新不及时导致的，在面试中如果能解决这些问题会是很大的加分项，既能让面试官知道你是有真正实战经验的，又能让面试官对你刮目相看，因为你不仅会简单使用框架，对其背后的原理也相当熟知。如果采用的是服务发现方式，就可以通过服务名去进行转发，需要配置 Ribbon 的超时。

然后演示下效果，重新启动一个 article-service 的服务，版本为 1.01，然后访问对应的接口，可以看到正常的请求还是可以请求到之前的 article-service，新版本 1.01 由于在配置中心里指定成灰度的版本，所以正常请求是不能访问的，我们可以在请求头中增加 n-d-version 来访问这个灰度的版本，等这个版本没问题后，就将配置中心里的灰度内容去掉，这样就能被正常请求访问了，然后就可以继续发布下一个实例，通过这样的方式就实现了我们的灰度发布功能。其 GitHub 地址为。

如果在 2 个小时之内，这个 Token 被再次使用，那么 Redis 中有值，就会被拦截掉，如果过了 2 个小时，Redis 中的缓存也就失效了，这个时候 Token 本身也过期了，也会被拦截，通过增加外部存储的方式来达到注销的效果。当项目部署多个节点后，通过负载均衡器进行转发，session 可能会出现丢失，比如用户 A 进行登录，这时请求是到 A 节点，会话信息存储在 A 节点，用户登录成功之后跳转到首页，这时首页的请求被转发到 B 节点，由于 B 节点没有用户 A 的会话信息，就造成了丢失的现象。

记录详细的日志能够方便我们排查问题，在微服务架构下，一个请求经过了 N 个服务，输出 N 条日志，我们需要将日志统一收集起来，而存在的问题是日志是在各个服务节点中输出的，当服务器时间不一致时，是无法获得正确的日志顺序的，最严重的是不知道这些日志间的关系，不知道某个请求对应的日志有哪些。服务之间都存在相互调用的情况，如果不做梳理工作，随着时间的推移，整个调用关系将会变成一张蜘蛛网，梳理调用关系可以让我们在前期将服务之间的关系整理清楚，当需要对一个服务做改动时，可以明确的知道影响的范围。

返回结果给客户端了，客户端收到结果后重新拉取配置的信息进行覆盖本地的配置。配置跟代码是存储在一起的，一旦代码泄露就会导致你的配置信息也被别人知道了，比如数据库，一些比较敏感的信息是绝对不能泄露的，如果我们的配置在配置中心里，就算源代码泄露了，别人也无法获取到这个项目的配置信息，配置仍旧是安全的，当然在配置中心里我们也可以将敏感的配置进行加密存储来提高安全性。之所以说推送是必须要有的功能，是因为我们在配置中心修改配置之后，可以将配置实时地推送给客户端进行更新，这样项目不用重启，修改配置实时生效，延迟较低。

Zuul 中会默认为 Eureka 中所有的服务都进行路由转发，这种方式确实很方便，相当于我们不需要配置路由规则就可以直接使用默认的服务名称加 API 的 URI 方式去访问，不好的点在于 Eureka 中的服务是全量的，我们的某个网关对外提供服务，并不需要将所有的 API 都暴露给外部，但是默认的映射会让外部可以访问到，所以我们需要将这个默认的路由转发关闭，通过配置 zuul.ignored-services=* 关闭。当需要发布新版本的时候，不会立即将老的服务停止，去发布新的服务。

在日常工作中，我们经常会遇到需要调用内部 API 或者第三方 API 的情况，主要有以下方式：HttpClientOKHttp以上这四种是我们最常见的 API 调用方式，在调用 API 之前，我们首先需要知道 API 的地址，其次是 API 对应的参数，然后发起调用，本质上调用 API 的过程就是一个 HTTP 请求过程。如果你用过 Dubbo 框架，就会知道在 Dubbo 中发起远程调用是不需要使用者去关注服务提供者信息的，直接注入一个接口，然后调用接口中的方法，就像调用本地方法一样。

服务雪崩微服务架构下，会存在服务之间相互依赖调用的情况，当某个服务不可用时，很容易因为服务之间的依赖关系使故障扩大，甚至造成整个系统不可用的情况，这种现象称为服务雪崩效应。如上图所示，为服务雪崩效应发生的过程，首先是服务正常状态，当客户端对服务 A 发起请求，服务 A 依赖了服务 B，服务 B 又依赖了服务 C，当所有服务都处于正常状态时，整个请求链路是通畅的，结果会很快返回给客户端。

众所周知，随着用户量的增加，应用的访问量也会随之增加，单台服务器已经远不能满足高并发的业务需求，这时就需要多台服务器组成集群来应对高并发带来的业务压力，同时也需要负均衡器来对流量进行合理分配。负载均衡是一种基础的网络服务，它的核心原理是按照指定的负载均衡算法，将请求分配到后端服务集群上，从而为系统提供并行处理和高可用的能力。负载均衡的方式有很多种，在 Spring Cloud 体系中，Ribbon就是负载均衡的组件，所有的请求都是通过 Ribbon 来选取对应的服务信息的。

如果提供方的数量减少，消费方会定时从注册中心拉取最新的信息，无效的服务信息会自动剔除，整个流程都是自动化的，不需要人工维护节点信息、修改配置文件。还有一点就是前面讲的集群模式，会将注册的信息复制给其他节点，更加验证了不可能采用数据库来存储注册信息，通过复制的模式我们可以推断，注册信息肯定会在每个节点都存储一份，信息的变更通过复制的形式解决，那么信息肯定是存储在 Eureka Server 的节点内部的，通过源码可以验证答案，Eureka 的注册信息是存储在 ConcurrentHashMap 中的。

众所周知，Spring Boot 是由 Pivotal 团队提供的全新框架，并于 2014 年 4 月发布第一个版本，其设计目的是用来简化 Spring 应用的搭建，以及开发过程。Spring Boot 有以下特点：Spring Boot 通过简单的步骤就可以创建一个 Spring 应用。Spring Boot 为 Spring 整合第三方框架提供了开箱即用功能。Spring Boot 的核心思想是约定大于配置。使用 Spring Boot 可以大大简化开发模式，提高开发效率。