springcloud进阶

• 1.配置中心：
• 2.nacose配置中心，配置文件加载顺序：
• 3.通过dataId，来读取对应的微服务配置文件。
• 4.nacos配置热更新：
• 5.自动刷新没有优先级:
• 6.多环境配置优先级：
• 7.等修改本地配置文件无法生效的时：
• 8.idea的Configuration选项卡配置参数：
• 9.命名空间的id:自动生成就好，不要自己填写。
• 10.小型微服务，可以使用多环节配置，大项目，强烈使用环境隔离。
• 11.nacos集群（面试题）的负载均衡的实现原理：
• 12.热更新配置的原理：
• 13.RestTemplate方式调用存在的问题：
• 14.Feign （伪装）： 是一个http请求调用的轻量级框架。
• 15.feign的日志优先级？？？
• 16.feign发请求关注：地址，参数，返回结果。
• 17.Feign最佳实践（☆☆☆☆☆）
• 18.httpclient-http连接池:
• 19.@enablefeignclients：
• 20.在本地项目里新建一个feigndefaultConfiguration，然后注入feign-api中的，可以嘛?
• 21.网关核心功能：
• 22.在SpringCloud中网关的实现包括两种：
• 23.网关的专业术语（理解）
• 24.网关通过nginx反向代理，实现的负载均衡到服务中心nacoa。？？？
• 25.uri: lb/xxx/xx。Ib（loadbalancer）：负载均衡器
• 26.断言和断言工厂：
• 27.鉴权的方案：
• 28.filters（过滤器）：可以对进入网关的请求和微服务返回的响应做处理。
• 29.过滤器执行顺序：？？？
• 30.自定义过滤器：用的是流式编程。响应式编程。
• 31.401状态码：没有权限。
• 32.高并发：请求限流和算法。
• 33.请求网关-微服务的流程：先满足断言条件后 ，可以路由 ，进行过滤拦截 。
• 34.每个框架的位置。和作用。
• 35.从order里调用user还会走网关吗？
• 36.网关的配置，也可以配置在中心配置。
• 37.禁止跳过网关直接访问后端服务？
• 38.浏览器有好多个cookies，一个域名可能都有多个cookies。
• 39.同源：协议、域名、端口都一样。
• 40.跨域：
• 41.跨域报错Access-Control-Allow-Origin
• 42.跨域解决方案：CORS
• 43.前后端分离的架构：一般需要设置一下跨越。
• 44.解决跨域问题：

1.配置中心：

可能会发生修改的，放到配置中心。不变的放到本地配置文件中。

2.nacose配置中心，配置文件加载顺序：

1）根据bootstrap.yml文件找到配置中心nacos。

2）配置中心先加载，再加载本地配置文件，最后合并。

3）有冲突的话配置中心优先级高。

3.通过dataId，来读取对应的微服务配置文件。

4.nacos配置热更新：

修改nacos中的配置后，微服务中无需重启即可让配置生效，也称为配置热更新。

1）局部：范围性当前类具有自动刷新

2）全局：一次定义所有类就具有自动刷新

5.自动刷新没有优先级:

全局和局部的配置，都是连接的配置中心的配置，这个配置是唯一的，所以是没有优先级区分的。

6.多环境配置优先级：

环境配置文件userservice-dev>共享配置文件userservice>本地配置文件application.yaml

7.等修改本地配置文件无法生效的时：

看一下是不是和远程配置冲突，导致无法生效。

8.idea的Configuration选项卡配置参数：

1）VM options：配置运行参数，其实就是application.yml配置文件里的参数

2）Active profiles：当前运行环境，如开发环境dev

Configuration选项卡
1）Environment
VM options
配置运行参数，其实就是application.yml配置文件里的参数，点击输入框右侧的按钮可以将单行输入框变成多行文本域。
如application,yml文件

server:
  port: 8080
spring:
  application:
    name: orderServer

变成VM oprions就是

-Dserver.port=8083
-Dspring.application.name=orderServer

2）SpringBoot
Active profiles：当前运行环境，如开发环境dev，测试环境test，线上环境prod，具体指取决于项目中配置文件命名。
原文链接：https://blog.csdn.net/JWbonze/article/details/123148181

9.命名空间的id:自动生成就好，不要自己填写。

10.小型微服务，可以使用多环节配置，大项目，强烈使用环境隔离。

11.nacos集群（面试题）的负载均衡的实现原理：

SLB-服务器负载均衡（Server Load Balancing）

1）nginx负载均衡（反向代理）来进行nacos集群。

2）nacos集群共享配置。用数据库来持久化存储共享配置。

12.热更新配置的原理：

Nacos和Apollo配置推送都是基于HTTP长轮询，客户端和配置中心建立HTTP长联接，当配置变更的的时候，配置中心把配置推送到客户端。

13.RestTemplate方式调用存在的问题：

1）入侵，远程调用和业务代码混合。

2）参数和url比较繁琐，

3）代码可读性差，不优雅。

14.Feign （伪装）： 是一个http请求调用的轻量级框架。

帮助微服务消费者优雅的实现http请求的发送。

1）Feign默认集成了Ribbon，所以默认实现了负载均衡。

2）Feign 底层通过反射和动态代理来对RestTemplate进行封装。

15.feign的日志优先级？？？

写在启动类是全局，写在某个接口上是局部的。

我感觉是局部大于全局。

16.feign发请求关注：地址，参数，返回结果。

17.Feign最佳实践（☆☆☆☆☆）

将Feign的Client抽取为独立模块，并且把接口有关的POJO（实体类）、默认的Feign配置都放到这个模块中，提供给所有消费者使用。

注意:feign-api:有实体类，所以需要导入mybaties-plus坐标。

18.httpclient-http连接池:

Feign底层发起http请求，依赖于其它的框架。其底层客户端实现包括：

• URLConnection：默认实现，不支持连接池，每次请求都是新建连接
• Apache HttpClient ：支持连接池
• OKHttp：支持连接池

因此提高Feign的性能主要手段就是使用连接池代替默认的URLConnection。

19.@enablefeignclients：

默认扫描的是当前模块下的包的，创建代理对象。

1）扫描的包太多，占用内存。

@EnableFeignClients(basePackages = "com.itheima.feign.client", defaultConfiguration = FeignDefaultConfiguration.class)
public class OrderApplication {}

2）可以指定扫描的类。

@EnableFeignClients(clients = {UserClient.class}, defaultConfiguration = FeignDefaultConfiguration.class)
public class OrderApplication {}

20.在本地项目里新建一个feigndefaultConfiguration，然后注入feign-api中的，可以嘛?

这个不行，因为api是接口不是对象。

21.网关核心功能：

• 身份认证和权限校验
• 服务路由、负载均衡
• 请求限流

22.在SpringCloud中网关的实现包括两种：

• zuul：基于Servlet的实现，属于阻塞式编程（后期不维护了）
• gateway：基于Spring5中提供的WebFlux，属于响应式编程的实现，具备更好的性能

23.网关的专业术语（理解）

• 路由（route）： 网关最基础的部分，也是⽹关⽐较基础的⼯作单元。（路由的理解，终端请求千里迢迢到达服务器的路程）
• 断⾔（predicates）：开发⼈员可以匹配Http请求中的所有内容（包括请求头、请求参数等），如果断⾔与请求相匹配则路由。
• 过滤器（filter）：使⽤过滤器，可以在请求之前或者之后执⾏业务逻辑。

24.网关通过nginx反向代理，实现的负载均衡到服务中心nacoa。？？？

25.uri: lb/xxx/xx。Ib（loadbalancer）：负载均衡器

uri: lb://userservice # 目标 URI，获取注册中心微服务地址，并支持负载均衡

26.断言和断言工厂：

1）断言：如限制ip，不能访问其他国家的网络。

2）断言工厂：我们配置的断言规则只是字符串，最终是有predicate factory来处理，并转化为路由判断条件。

27.鉴权的方案：

1）cookies,session

2）jwt等

28.filters（过滤器）：可以对进入网关的请求和微服务返回的响应做处理。

有内置的和自定义的。

29.过滤器执行顺序：？？？

1）默认（内置）过滤器跟声明顺序来的123456自上而下的。

2）当过滤器的order值一样时，内置过滤器 优先级高于 自定义过滤器

3）自定义过滤器注解@order的值为负数或0，优先于默认过滤器执行。？？？

4）无论order是多少，内置的过滤器优先级总是高于自定义的。

30.自定义过滤器：用的是流式编程。响应式编程。

public interface GlobalFilter {
 
/**
     *  处理当前请求，有必要的话通过{@link GatewayFilterChain}将请求交给下一个过滤器处理
  *
     * @param exchange 包含Request、Response等信息
     * @param chain 用来把请求委托给下一个过滤器 
     * @return {@code Mono<Void>} 返回标示当前过滤器业务结束
  */
 Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain);
 
	 return response.setComplete()
}

1）Void作为泛型，代表没有返回值。

2）return response.setComplete()的意思：

它向responseheader里set了Location 然后return 了response.setComplete(); 而这个方法正好返回一个

我们可以使用这个方法实现页面的重定向。

http://t.csdn.cn/m4meI

31.401状态码：没有权限。

32.高并发：请求限流和算法。

1）漏桶算法：

漏桶（Leaky Bucket）算法思路很简单，水（请求）先进入到漏桶里，漏桶以一定的速度出水（接口有响应速率），当水流入速度过大会直接溢出（访问频率超过接口响应速率），然后就拒绝请求，可以看出漏桶算法能强行限制数据的传输速率

2）令牌桶算法（Token Bucket）：

令牌桶算法是和漏桶算法效果一样但方向相反的算法，更加容易理解。随着时间流逝，系统会按恒定 1/QPS 时间间隔（如果 QPS=100，则间隔是 10ms）往桶里加入 Token（想象和漏洞漏水相反，有个水龙头在不断的加水），如果桶已经满了就不再加了。新请求来临时，会各自拿走一个 Token，如果没有 Token 可拿了就阻塞或者拒绝服务。

http://t.csdn.cn/3bCns

33.请求网关-微服务的流程：先满足断言条件后 ，可以路由 ，进行过滤拦截 。

启动网关服务，访问http://localhost/user/1时，符合/user/**规则，过滤鉴权等，请求转发到uri：http://userservice/user/1，得到了结果：

34.每个框架的位置。和作用。

http（网关/服务）请求 -Gateway（路由）-nginx（负载均衡nacos集群）-nacos+ribbon（LoadBalancerInterceptor获取到了服务实例的ip和端口，服务id获取服务列表，随后利用负载均衡算法得到真实的服务地址信息，替换服务id。）[-feign（微服务内部的相互调用）-nacos+ribbon]{循环起来}。

35.从order里调用user还会走网关吗？

不用

微服务内部的相互调用不需要访问网关，直接访问nacos服务中心。

网关相当于防盗门，微服务内部的相互相当于从卧室到厨房，不用走防盗门

36.网关的配置，也可以配置在中心配置。

///咸鱼学长好像啊

37.禁止跳过网关直接访问后端服务？

• 网络隔离

后端普通服务都部署在内网，通过防火墙策略限制只允许网关应用访问后端服务。

• 应用层拦截

请求后端服务时通过拦截器校验请求是否来自网关，如果不来自网关则提示不允许访问。

实现思路

实现思路其实也很简单，在请求经过网关的时候给请求头中增加一个额外的Header，在后端服务中写一个拦截器，判断请求头是否与在网关设置的请求Header一致，如果不一致则不允许访问并给出提示。

当然为了防止在每个后端服务都需要编写这个拦截器，我们可以将其写在一个公共的starter中，让后端服务引用即可。而且为了灵活，可以通过配置决定是否只允许后端服务访问。

38.浏览器有好多个cookies，一个域名可能都有多个cookies。

39.同源：协议、域名、端口都一样。

40.跨域：

浏览器从一个域名的网页去请求另一个域名的资源时，域名、端口、协议任一不同。

41.跨域报错Access-Control-Allow-Origin

保证用户信息的安全，防止恶意的网站窃取数据。

42.跨域解决方案：CORS

CORS是一个W3C标准，全称“跨域资源共享”（Cross-origin resource sharing）。

需要服务器实现CORS接口。

CORS需要浏览器（默认都支持）和服务器同时支持。只要服务器实现了CORS接口，就可以跨源通信。

原理：

CORS通信过程，都是浏览器自动完成，不需要用户参与。CORS通信与同源的AJAX通信没有差别，代码完全一样。

浏览器一旦发现AJAX请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求，但用户不会有感觉。

43.前后端分离的架构：一般需要设置一下跨越。

44.解决跨域问题：

在gateway服务的application.yml文件中，添加下面的配置：

spring:
  cloud:
    gateway:
      # 。。。
      globalcors: # 全局的跨域处理
        add-to-simple-url-handler-mapping: true # 解决options请求被拦截问题
        corsConfigurations:
          '[/**]':
            allowedOrigins: # 允许哪些网站的跨域请求 
              - "*"
            allowedMethods: # 允许的跨域ajax的请求方式
              - "GET"
              - "POST"
              - "DELETE"
              - "PUT"
              - "OPTIONS"
            allowedHeaders: "*" # 允许在请求中携带的头信息
            allowCredentials: true # 是否允许携带cookie
            maxAge: 360000 # 这次跨域检测的有效期