秋招第二周面试经验

前言

秋招开始接到面试的第二周，真的很感谢在这个寒冬这些公司愿意给我机会，当然自己面试感觉也确实是越来越好了，首先我觉得我们需要注意答题的思路：先听清楚想好再回答，先整体再局部，注意自己回答的这个思路，可以水平拓展，但不要扯太远了，尤其是针对八股文的那种，还是建议尽量把深度往下挖，感觉最近的面试很舒服。有些公司面试就像是在技术交流，很喜欢这种技术氛围。
再就是一些HR面，要尽量地展现自己的综合能力，也别怕说错话，把自己的观点尽量简短表述清楚，注意条理，我强烈建议大家可以考虑这样说话：第一，第二.... 这样自己表达的时候潜意识里面也会有更多的逻辑在里面。注意你是来推销自己的，是你觉得你能行，可以胜任这个岗位，我们都是一块宝玉，公司得到了是它的幸运，然后我们也很感谢得到一个锻炼和发展的平台并会继续努力下去，为公司创造更多的收益。然后本文有一些问题没有完全解答，因为博主有些文章已经写了相关内容，这里就不再过多赘述了，这里发上周面试相关知识点链接：上周面试经验，觉得不错的可以收藏一下，这种环境下接到面试确实不太容易，另外可以关注博主一波，后续也会经常更新一些技术博文。
想进秋招群一起学习交流的友友可以评论或私聊博主，大家一起加油。

第一家一面

聊一下你上次实习的收获在哪些方面，参与实际的开发了吗？

这个阶段最主要的不是关注最新的技术栈，而是要知道企业级项目的流程，具备企业级开发的能力。

你对SpringCloud组件的认知是怎样的？

SpringCloud：是一套目前完整的微服务框架，它是一系列框架的有序集合。它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过SpringBoot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简易易懂、易部署和易维护的分布式系统开发工具包。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用SpringBoot的开发风格做到一键启动和部署

其中一些具体组件

1. Nacos 是阿里巴巴推出来的一个新开源项目，这是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台 Nacos是以服务为主要服务对象的中间件，Nacos支持所有主流的服务发现、配置和管理。Nacos主要提供以下功能：服务发现和服务健康监测、动态配置服务（维护的时候）。在系统开发过程中，开发者通常会将一些需要变更的参数、变量等从代码中分离出来独立管理，以独立的配置文件的形式存在。目的是让静态的系统工件或者交付物（如 WAR，JAR 包等）更好地和实际的物理运行环境进行适配。配置管理一般包含在系统部署的过程中，由系统管理员或者运维人员完成。配置变更是调整系统运行时的行为的有效手段

   如果微服务架构中没有使用统一配置中心时，所存在的问题：

   1. 配置文件分散在各个项目里，不方便维护
   2. 配置内容安全与权限
   3. 更新配置后，项目需要重启

   Nacos配置中心：系统配置的集中管理（编辑、存储、分发）、动态更新不重启、回滚配置（变更管理、历史版本管理、变更审计）等所有与配置相关的活动

2. Gateway：负载均衡、熔断降级、统一鉴权、请求过滤、路径重写、限流保护。面向服务的路由，如果写的是IP地址的话相当于地址写死了，无法做到负载均衡，应该把网关工程注册到Nacos注册中心，通过服务名去访问不同微服务。网关限流有这么一些算法：

   1. 令牌桶算法：所有请求在处理之前都需要拿到一个可用的令牌才会被处理，根据限流大小，设置按照一定的速率往桶里添加令牌；桶设置最大的放置令牌限制，当桶满时，新添加的令牌就会被丢弃或者拒绝；请求到达后首先要获取令牌桶中的令牌，拿着令牌才可以进行其他的业务逻辑，处理完业务逻辑之后，将令牌直接删除；令牌桶有最低限额，当桶中的令牌达到最低限额的时候，请求处理完之后将不会删除令牌，以此保证足够的限流。guaua和redis客户端就有其实现
   2. 漏桶算法：水(请求)从上方倒入水桶内，从水桶下方流出(被处理)；来不及流出的水存在水桶中(缓冲)，以固定速率流出；水桶满后水溢出(丢弃)；这个算法的核心是：缓存请求、匀速处理、多余的请求直接丢弃
   3. 两种算法的区别：两者主要区别在于“漏桶算法”能够强行限制数据的传输速率，而"令牌桶算法"在能够限制数据的平均传输数据外，还允许某种程度的突发传输。在"令牌桶算法"中，只要令牌桶中存在令牌，那么就允许突发地传输数据直到达到用户配置的门限，所以它适合于具有突发特性的流量

3. Sentinel：是面向分布式服务架构的轻量级流量控制组件，主要以流量为切入点，从**限流、流量整形、熔断降级、**系统负载保护等多个维度来帮助您保障微服务的稳定性。Sentinel 熔断降级会在调用链路中某个资源出现不稳定状态时（例如调用超时或异常比例升高），对这个资源的调用进行限制，让请求快速失败，避免影响到其它的资源而导致级联错误。当资源被降级后，在接下来的降级时间窗口之内，对该资源的调用都自动熔断（默认行为是抛出 DegradeException） 。流量控制有以下几个角度:

   1. 资源的调用关系，例如资源的调用链路，资源和资源之间的关系
   2. 运行指标，例如 QPS、线程数等
   3. 控制的效果，例如**直接限流（快速失败）、冷启动（Warm Up）、匀速排队（排队等待）**等Sentinel 的设计理念是让您自由选择控制的角度，并进行灵活组合，从而达到想要的效果
   4. Sentinel 的设计理念是让您自由选择控制的角度，并进行灵活组合，从而达到想要的效果

4. OpenFeign：微服务之间的相互调用，相较于Feign它支持SpringMVC的注解，如@RequestMapping等等。OpenFeign的FeignClient可以解析SpringMVC的@RequestMapping注解下的接口，并通过动态代理方式产生实现类，实现类中做负载均衡并调用其他服务

5. Zipkin：链路追踪： 能展示完整调用链的耗时。还能展示各个部分调用的耗时

你有了解过RBAC吗

RBAC（基于角色的权限控制 role base access control）是一种设计模式，是用来设计和管理权限相关数据的一种模型。这种表结构大致如下

SpringAOP和拦截器过滤器的区别？

AOP(Aspect-Oriented Programming:⾯向切⾯编程)能够将那些与业务⽆关，却为业务模块所共同调⽤的逻辑或责任（例如事务处理、⽇志管理、权限控制等）封装起来，便于减少系统的重复代码，降低模块间的耦合度，并有利于未来的可拓展性和可维护性。 Spring AOP就是基于动态代理的，如果要代理的对象，实现了某个接⼝，那么Spring AOP会使⽤JDK Proxy，去创建代理对象，⽽对于没有实现接⼝的对象，使⽤Cglib ，这时候Spring AOP会使⽤ Cglib ⽣成⼀个被代理对象的子类来作为代理。

过滤器拦截器都体现了AOP的编程思想

1. 过滤器的配置比较简单，直接实现Filter接口即可，也可以通过@WebFilter注解实现对特定URLl拦截，看到Filter接口中定义了三个方法：

   1. init() ：该方法在容器启动初始化过滤器时被调用，它在 Filter 的整个生命周期只会被调用一次。注意：这个方法必须执行成功，否则过滤器会不起作用
   2. doFilter() ：容器中的每一次请求都会调用该方法， FilterChain 用来调用下一个过滤器 Filter
   3. destroy()： 当容器销毁 过滤器实例时调用该方法，一般在方法中销毁或关闭资源，在过滤器 Filter 的整个生命周期也只会被调用一次

2. 拦截器(Interceptor)：拦截器它是链式调用，一个应用中可以同时存在多个拦截器Interceptor， 一个请求也可以触发多个拦截器 ，而每个拦截器的调用会依据它的声明顺序依次执行。 将自定义好的拦截器处理类进行注册，并通过**addPathPatterns、excludePathPatterns**等属性设置需要拦截或需要排除的 URL。

   首先编写一个简单的拦截器处理类，请求的拦截是通过HandlerInterceptor 来实现，看到HandlerInterceptor 接口中也定义了三个方法。

   1. preHandle() ：这个方法将在请求处理之前进行调用。注意：如果该方法的返回值为false ，将视为当前请求结束，不仅自身的拦截器会失效，还会导致其他的拦截器也不再执行
   2. postHandle()：只有在 preHandle() 方法返回值为