目录
3.1 resttemplate（底层：JDK原生的URLConnection）
基础4大件：远程调用，注册中心，配置中心，网关
其中：负载均衡策略在注册中心和网关的底层，本质是客户请求拦截器
负载均衡策略有：地区内轮询，轮询，随机等等，默认是地区内轮询
1.（理解）微服务出现的原因
1.1 三种架构
-
单体架构：简单方便，高度耦合，扩展性差，适合小型项目。例如：学生管理系统
-
分布式架构：松耦合，扩展性好，但架构复杂，难度大。适合大型互联网项目，例如：京东、淘宝
-
微服务：一种良好的分布式架构方案
①优点：拆分粒度更小、服务更独立、耦合度更低
②缺点：架构非常复杂，运维、监控、部署难度提高
-
SpringCloud是微服务架构的一站式解决方案，集成了各种优秀微服务功能组件
1.2 对分布式系统架构的理解
1.2.1 出现原因
为了解决传统单体服务架构带来的各种问题，代码数量庞大，迭代测试维护困难，可能因为一处改动测试不到位造成整个服务瘫痪等问题，分布式系统就是将一个大的服务拆分成几十个甚至上百个微小的服务。
1.2.2 理解
通俗点讲就把整个业务系统拆分成很多的服务，每个服务责任到人，服务之间代码都没有冲突，服务可以自治，每个服务到技术也可以自己选型，只要遵循统一的服务调用协议就可以了。每次发布如果就改动一个服务那就上线一个服务，不用所有人一起联调，这样每次发布牵扯到的改动影响也是可控的。不像传统单体架构服务，动辄几百万行代码融在一起。
1.3 分布式系统有哪些优点及面临的问题
1.3.1 优点
-
系统并发能力提升，可水平扩展
-
系统容错能力提升
-
低延迟
-
系统可用性提升
1.3.2 面临的问题
-
分布式服务依赖网络
-
维护成本高
-
一致性，可用性，分区容错性无法同时满足
1.3.3 缺点：
-
依赖网络，会因为网络问题导致系统数据丢失或不一致性；
-
系统复杂化，系统监控维护，版本迭代发布变得相对复杂，成本高；
-
一致性，可用性，分区容错性无法同时满足。
-
2.微服务的介绍
2.1 spring cloud
2.1.1 是什么
2.1.1.1 Spring cloud
Spring cloud 流应用程序启动器是基于 Spring Boot 的 Spring 集成应用程序，提供与外部系统的集成。Spring cloud Task，一个生命周期短暂的微服务框架，用于快速构建执行有限数据处理的应用程序。
2.1.1.2 微服务
微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分为一组小的服务，每个服务运行在其独立的自己的进程中，服务之间相互协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）,每个服务都围绕着具体的业务进行构建，并且能够被独立的构建在生产环境、类生产环境等。另外，应避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。
2.1.2 优势
2.1.2.1 spring cloud优势
1、服务拆分粒度更细，有利于资源重复利用，有利于提高开发效率
2、可以更精准的制定优化服务方案，提高系统的可维护性
3、微服务架构采用去中心化思想，服务之间采用Restful等轻量级通讯
4、适于互联网时代，产品迭代周期更短
2.1.2.2 微服务优势
（1）每个服务直接足够内聚，代码容易理解
（2）开发效率高，一个服务只做一件事，适合小团队开发
（3）松耦合，有功能意义的服务。
（4）可以用不同语言开发，面向接口编程。
（5）易于第三方集成
（6）微服务只是业务逻辑的代码，不会和HTML,CSS或其他界
（7）可以灵活搭配，连接公共库/连接独立库
微服务缺点
（1）分布式系统的责任性
（2）多服务运维难度加大。
（3）系统部署依赖，服务间通信成本，数据一致 ，系统集成测试，性能监控。
2.1.3 特点
微服务的架构特征：
-
单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责
-
自治：团队独立、技术独立、数据独立，独立部署和交付
-
面向服务：服务提供统一标准的接口，与语言和技术无关
-
隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题
2.1.3 （面试题）spring cloud与springboot
2.1.3.1 区别
Spring Boot专注于快速方便的开发单个个体微服务。
Spring Cloud是关注全局的微服务协调整理治理框架，它将Spring Boot开发的一个个单体微服务整合并管理起来，为各个微服务之间提供，配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务Spring Boot可以离开Spring Cloud独立使用开发项目， 但是Spring Cloud离不开Spring Boot ，属于依赖的关系。
Spring Boot专注于快速、方便的开发单个微服务个体，Spring Cloud关注全局的治理框架。
2.1.3.2 版本依赖
2.2 常用组件
3.远程调用的解决方法
微服务都是以HTTP接口的形式暴露自身服务的，因此在调用远程服务时就必须使用HTTP客户端
3.1 resttemplate（底层：JDK原生的URLConnection）
3.1.1 是什么
RestTemplate是Spring提供的用于访问Rest服务(Rest风格、Rest架构)的客户端。 RestTemplate提供了多种便捷访问远程Http服务的方法,能够大大提高客户端的编写效率。
3.1.2 实现
3.1.3 缺点
-
可读性差
-
参数复杂的url路径难以维护
是spring提供的发送http请求的一个模板类，和JdbcTemplate、JmsTemplate概念相似，都是Spring提供的模板类。
3.1.4 写出使用RestTemplate发送http请求，完成远程调用的流程
3.2 Feign
3.2.1 实现步骤
① 引入依赖
② 添加@EnableFeignClients注解
③ 编写FeignClient接口
④ 使用FeignClient中定义的方法代替RestTemplate
3.2.2 Feign使用优化
Feign底层发起http请求，依赖于其它的框架。其底层客户端实现包括：
•URLConnection：默认实现，不支持连接池
•Apache HttpClient ：支持连接池
•OKHttp：支持连接池
因此提高Feign的性能主要手段就是使用连接池代替默认的URLConnection。
总结，Feign的优化：
1.日志级别尽量用basic
2.使用HttpClient或OKHttp代替URLConnection
① 引入feign-httpClient依赖
② 配置文件开启httpClient功能，设置连接池参数
3.2.3 日志即相关配置
日志的级别分为四种：
-
NONE：不记录任何日志信息，这是默认值。
-
BASIC：仅记录请求的方法，URL以及响应状态码和执行时间
-
HEADERS：在BASIC的基础上，额外记录了请求和响应的头信息
-
FULL：记录所有请求和响应的明细，包括头信息、请求体、元数据。
基于配置文件修改feign的日志级别可以针对单个服务：
feign:
client:
config:
userservice: # 针对某个微服务的配置
loggerLevel: FULL # 日志级别 也可以针对所有服务：
feign:
client:
config:
default: # 这里用default就是全局配置，如果是写服务名称，则是针对某个微服务的配置
loggerLevel: FULL # 日志级别 Feign可以支持很多的自定义配置，如下表所示：
| 类型 | 作用 | 说明 |
|---|---|---|
| feign.Logger.Level | 修改日志级别 | 包含四种不同的级别：NONE、BASIC、HEADERS、FULL |
| feign.codec.Decoder | 响应结果的解析器 | http远程调用的结果做解析，例如解析json字符串为java对象 |
| feign.codec.Encoder | 请求参数编码 | 将请求参数编码，便于通过http请求发送 |
| feign. Contract | 支持的注解格式 | 默认是SpringMVC的注解 |
| feign. Retryer | 失败重试机制 | 请求失败的重试机制，默认是没有，不过会使用Ribbon的重试 |
一般情况下，默认值就能满足我们使用，如果要自定义时，只需要创建自定义的@Bean覆盖默认Bean即可。
3.2.4 最佳实际
将Feign的Client抽取为独立模块，并且把接口有关的POJO、默认的Feign配置都放到这个模块中，提供给所有消费者使用。
例如，将UserClient、User、Feign的默认配置都抽取到一个feign-api包中，所有微服务引用该依赖包，即可直接使用。
4.注册中心
4.1 出现的原因
4.2 是什么
注册中心的作用一句话概括就是存放和调度服务，实现服务和注册中心，服务和服务之间的相互通信。注册中心可以说是微服务架构中的”通讯录“，它记录了服务和服务地址的映射关系。在分布式架构中，服务会注册到这里，当服务需要调用其它服务时，就到这里找到服务的地址，进行调用。
4.3 常用的注册中心中间件
4.4 Eureka
4.4.1 执行流程
-
注册服务信息（30s心跳，90s死亡判断）
服务提供者在启动时，会向EurekaServer发起一次请求，将自己注册到Eureka注册中心中去
-
拉取服务
-
负载均衡，@loadbalanced，内置ribbon
-
远程调用
4.5 Nacos 注册中心
4.5.1 （面试题）Nacos与Eureka的区别
Nacos与eureka的共同点
-
都支持服务注册和服务拉取
-
都支持服务提供者心跳方式做健康检测
Nacos与Eureka的区别
-
Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式
-
临时实例心跳不正常会被剔除，非临时实例则不会被剔除
-
Nacos支持服务列表变更的消息推送模式，服务列表更新更及时
-
Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式
4.5.2 其他
服务分级存储模型
权重配置
环境隔离
5.Nacos配置中心
笔记：统一配置隔离，热更新，配置共享，配置的优先级
6.网关
6.1 网关的核心功能特性：
权限控制：网关作为微服务入口，需要校验用户是是否有请求资格，如果没有则进行拦截。
路由和负载均衡：一切请求都必须先经过gateway，但网关不处理业务，而是根据某种规则，把请求转发到某个微服务，这个过程叫做路由。当然路由的目标服务有多个时，还需要做负载均衡。
限流：当请求流量过高时，在网关中按照下流的微服务能够接受的速度来放行请求，避免服务压力过大。
在SpringCloud中网关的实现包括两种：
-
gateway
-
zuul
Zuul是基于Servlet的实现，属于阻塞式编程。而SpringCloudGateway则是基于Spring5中提供的WebFlux，属于响应式编程的实现，具备更好的性能。
响应式
就是丢给其他线程，然后不傻等，线程执行过程中去执行其他任务，执行完进行回调通知
例如：netty的eventloop接收http请求，执行redis操作的时候通过redis响应式API，eventloop会立刻返回（将数据丢给redis客户端线程），redis底层基于epol进行非阻塞IO，redis客户端线程将数据丢给网络然后返回，这个过程都非阻塞的。等redis 处理完成之后，epoll的机制去通知redis线程执行回调时间，完成整个网络。整个执行过程中线程各司其职（完全cpu密集操作），eventloop只负责接收以及传递，redis负责丢网络以及监听返回。当然你可以理解将阻塞交给了操作系统。
6.2 实现
网关搭建步骤：
-
创建项目，引入nacos服务发现和gateway依赖
-
配置application.yml，包括服务基本信息、nacos地址、路由
路由配置包括：
-
路由id：路由的唯一标示
-
路由目标（uri）：路由的目标地址，http代表固定地址，lb代表根据服务名负载均衡
-
路由断言（predicates）：判断路由的规则，
-
路由过滤器（filters）：对请求或响应做处理
server:
port: 10010 # 网关端口
spring:
application:
name: gateway # 服务名称
cloud:
nacos:
server-addr: localhost:8848 # nacos地址
gateway:
routes: # 网关路由配置
- id: user-service # 路由id，自定义，只要唯一即可
# uri: http://127.0.0.1:8081 # 路由的目标地址 http就是固定地址
uri: lb://userservice # 路由的目标地址 lb就是负载均衡，后面跟服务名称
predicates: # 路由断言，也就是判断请求是否符合路由规则的条件
- Path=/user/** # 这个是按照路径匹配，只要以/user/开头就符合要求6.3 （了解）断言工厂
| 名称 | 说明 | 示例 |
|---|---|---|
| After | 是某个时间点后的请求 | - After=2037-01-20T17:42:47.789-07:00[America/Denver] |
| Before | 是某个时间点之前的请求 | - Before=2031-04-13T15:14:47.433+08:00[Asia/Shanghai] |
| Between | 是某两个时间点之前的请求 | - Between=2037-01-20T17:42:47.789-07:00[America/Denver], 2037-01-21T17:42:47.789-07:00[America/Denver] |
| Cookie | 请求必须包含某些cookie | - Cookie=chocolate, ch.p |
| Header | 请求必须包含某些header | - Header=X-Request-Id, \d+ |
| Host | 请求必须是访问某个host（域名） | - Host=.somehost.org,.anotherhost.org |
| Method | 请求方式必须是指定方式 | - Method=GET,POST |
| Path | 请求路径必须符合指定规则 | - Path=/red/{segment},/blue/** |
| Query | 请求参数必须包含指定参数 | - Query=name, Jack或者- Query=name |
| RemoteAddr | 请求者的ip必须是指定范围 | - RemoteAddr=192.168.1.1/24 |
| Weight | 权重处理 |
6.3 过滤器
过滤器排序的规则是什么呢？
-
每一个过滤器都必须指定一个int类型的order值，order值越小，优先级越高，执行顺序越靠前。
-
GlobalFilter通过实现Ordered接口，或者添加@Order注解来指定order值，由我们自己指定
-
路由过滤器和defaultFilter的order由Spring指定，默认是按照声明顺序从1递增。
-
当过滤器的order值一样时，会按照 defaultFilter > 路由过滤器 > GlobalFilter的顺序执行。
6.3.1 （面试题）权限校验的全局过滤器的具体实现
@Order(-1)
@Component
public class AuthorizeFilter implements GlobalFilter {
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
// 1.获取请求参数
MultiValueMap<String, String> params = exchange.getRequest().getQueryParams();
// 2.获取authorization参数
String auth = params.getFirst("authorization");
// 3.校验
if ("admin".equals(auth)) {
// 放行
return chain.filter(exchange);
}
// 4.拦截
// 4.1.禁止访问，设置状态码
exchange.getResponse().setStatusCode(HttpStatus.FORBIDDEN);
// 4.2.结束处理
return exchange.getResponse().setComplete();
}
}-
实现全局过滤器implements GlobalFilter
-
注入官方2个参数ServerWebExchange exchange, GatewayFilterChain chain
-
获取url请求参数列表 exchange.getRequest().getQueryParams()
-
获取第一个key值为authorization，进行判断
-
成功：放行chain.filter(exchange)
失败：设置状态码，401权限不足问题，打回exchange.getResponse().setComplete()
6.3 跨域问题---解决方案CORS
6.3.1 是什么---浏览器不允许
跨域：域名不一致就是跨域，主要包括：
-
域名不同： www.taobao.com 和 www.taobao.org 和 www.jd.com 和 miaosha.jd.com
-
域名相同，端口不同：localhost:8080和localhost8081
跨域问题：浏览器禁止请求的发起者与服务端发生跨域ajax请求，请求被浏览器拦截的问题
6.3.2 解决
在gateway.yml加配置
spring:
cloud:
gateway:
# 。。。
globalcors: # 全局的跨域处理
add-to-simple-url-handler-mapping: true # 解决options请求被拦截问题
corsConfigurations:
'[/**]':
allowedOrigins: # 允许哪些网站的跨域请求
- "http://localhost:8090"
allowedMethods: # 允许的跨域ajax的请求方式
- "GET"
- "POST"
- "DELETE"
- "PUT"
- "OPTIONS"
allowedHeaders: "*" # 允许在请求中携带的头信息
allowCredentials: true # 是否允许携带cookie
maxAge: 360000 # 这次跨域检测的有效期6.3.3 CORS
两次请求
对应配置：maxAge: 360000 # 这次跨域检测的有效期
1611
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
