SpringCould--微服务
互联网服务架构的演变 : 由简到繁 单体架构 -- 分布式架构 -- SOA架构 --微服务架构 -- service mesh 单体架构 : 在早期的互联网产品中，用户数量少，并发量小，单个应用程序可以满足需求. 总结 : 将所有功能集中在一个项目中，并将其部署为节点 优点 : 结构简单，成本低 缺点 : 耦合度高 分布式架构 : 根据业务需要拆分系统功能，每个业务模块称为服务 优点 : 降低服务之间的耦合度，有利于服务的升级和扩展 缺点 : 维护成本高,服务之间调用的复杂度增加
微服务架构 : 微服务是系统架构的设计风格，将原有的独立服务分为多个小服务，每个服务在自己的过程中独立运行，服务之间通过HTTP RESTFul API通信；每一个小服务都围绕着系统这个高耦合度的业务构建 优点 : 拆分粒度小，服务更独立，耦合度低 缺点 : 架构非常复杂，运维、监控和部署难度相对增加 微服务架构的特点 : 官网地址：https://spring.io/projects/spring-cloud 1.单一职责 : 微服务拆分粒度小，每个服务对应唯一的业务能力 2.自治 : 团队独立,技术独立,数据独立,独立部署和交付 3.面向服务 : 服务提供与语言和技术无关的统一标准接口 4.隔离性 : 隔离、容错、降级服务之间的调用，避免等级问题
SpringCould基于各种微服务功能组件的集成SpringBoot实现这些组件的自动组装
服务提供者 : 其他微服务在业务中调用的服务.(为其他微服务提供接口) 服务消费者 : 一次业务中调用其他微服务的服务.(调用其他微服务提供的接口)
远程调用微服务的方式Fegin : 1.RestTemplate是spring基于HTTP实现远程调用.(他同步执行HTTP请求，底层使用JDK原生的HttpURLConnection API 使用方式 : 1.注册RestTemplate 2.使用RestTemplate.getForObject(url,T.class)远程调用 缺点 : 代码可读性差，编程体验不统一，参数复杂URL难以维护 2.Feign : 1. 使用方式 : 1.引入依赖 2.在启动类上添加注释@EnableFeignClients开启Feign功能 3.定义远程调用接口，在接口中指定远程调用的【服务名字】、【方法签名】.注解 : @FeignClient(value = "被调用的服务名称") 4.注入接口，远程调用(接口) 2. 主要是基于SpringMVC注释声明远程调用的信息 1.服务名称 2.请求方式 3.请求路径 4.请求参数 3. Fegin自定义配置可以覆盖默认配置 类型 作用 说明 | ---------------------- | ----------------| --------------------------------------------------- | **feign.Logger.Level** | 修改日志级别 | 包括四个不同的级别：NONE、BASIC、HEADERS、FULL | | feign.codec.Decoder | 解析器的响应结果 | http分析远程调用的结果，如分析json字符串为java对象| | feign.codec.Encoder | 请求参数编码 | 请求参数编码，便于通过http请求发送 | | feign. Contract | 支持注释格式 | 默认是SpringMVC的注解 | | feign. Retryer | 失败重试机制 | 默认没有要求失败的重试机制，不过会使用Ribbon的重试 | NONE:默认的，不显示任何日志 BASIC:只记录请求方法，URL、响应状态码、执行时间 HEADERS:除了BASIC除了定义的信息，还有请求和响应的头信息 FULL:除了HEADERS除了定义的信息，还有文本和元数据的请求和响应 3.Fegin日志配置 -- 必须结合SpringBoot日志使用才能生效 feign: client: config: default: #这里用default如果是全局配置default换成服务名称，配置微服务 loggerLevel: FULL #日级别 4.Fegin性能优化 它的底层客户端实现是 : 1.URLConnection : 默认的,不支持连接池 2.Apache HttpClient : 支持连接池 (需要引入依赖) 配置文件配置: httpclient: enabled: true #开启feign对HttpClient的支持 max-connections: 200 #最大的连接数 max-connections-per-route: 50 #每个路径的最大连接数 3.OKHttp : 支持连接池 (需要引入依赖) 性能优化主要包括 : 1.使用连接池代替默认的URLConnection 2.日志级别，最好用basic或none 实现方式 : 1.(继承)给消费者的FeignClient和提供者的controller定义统一的父接口作为标准。(注:父接口的参数列表中的映射不会被继承) 2.(抽取-最佳实现方式 : 可以很好的管理远程调用的接口)将FeignClient抽取为独立模块，并且把接口有关的POJO、默认的Feign配置都放到这个模块中，提供给所有消费者使用 注: 当定义的FeignClient不在SpringBootApplication的扫描包范围时，这些FeignClient无法使用。 1.指定FeignClient所在包 (@EnableFeignClients(basePackages = "com.itheima.user.feign")) 2.指定FeignClient字节码 (@EnableFeignClients(clients = {UserClient.class}))
Eureka微服务自带的注册中心 : 1.服务启动后,服务提供者向注册中心注册服务信息 : 服务名称以及IP端口 1.1.服务提供者每个30秒向注册中心发送一次心跳 1.2.注册中心在90秒内没有收到某个服务提供者节点的心跳,注册中心将会注销这个服务节点 2.服务消费者根据服务名称向注册中心拉取服务信息 3.如果有多个服务提供者,那么服务消费者是根据负载均衡算法从服务列表中获取一个服务 Eureka搭建 : 服务注册 1.引入Eureka依赖 2.创建Eureka启动类,添加@EnableEurekaServer注解 服务发现 ： 3.配置文件中配置Eureka信息 4.微服务中引入EurekaClient依赖 5.远程调用中开启负载均衡 注解 : @LoadBalanced//开启负载均衡 6.用服务提供者的服务名称远程调用(由原来的ip:port改服务名(spring.application.name))
Nacos注册中心 : SpringCloudAlibaba推出的注册中心。 访问地址 : http://localhost:8848/nacos 控制台账号：nacos 密码：nacos 实现方式 : 1.引入依赖 2.配置nacos spring: cloud: nacos: server-addr: localhost:8848 服务分级存储 : 一个服务可以有多个实例 例 : 相同IP不同的端口 我们可以将nacos看做一个机房,机房里有多个服务看做是一个集群,集群下有多个实例,微服务之间相互访问是尽可能的访问本地的,本地的速度比较快,当本地集群不可用时采访问其他集群 配置文件 : spring: cloud: nacos: server-addr: localhost:8848 discovery: cluster-name: SZ # 集群名称 同集群优先负载均衡 : nacos提供了NacosRule实现优先从同集群中调用 ribbon: NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则 权重配置 : 场景 : 1.服务器设备性能差,部分实例所在的服务器性能好 2.默认情况下NacosRule是同集群内随机挑选，不会考虑机器的性能问题 因此Nacos提供了权重配置来控制访问频率，权重越大则访问频率越高。 操作 : 在nacos的控制台配置权重,权重为0,该实例永远不会被访问 隔离环境 : Nacos提供了namespace来实现环境隔离功能。 1.nacos中可以有多个namespace（环境隔离:test dev pro） 2.namespace下有group(项目隔离 探花项目 头条项目)、service(实例隔离tanhua-server tanhua-service)等 3.不同namespace之间相互隔离，例如不同namespace的服务互相不可见 创建 : 默认情况下，所有service、data、group都在同一个namespace，名为public(空间名称) 配置文件 : 在上面 集群名称同级下加 namespace: devnamespace # 命名空间，填空间ID Nacos与Eureka的区别 : Nacos的服务实例分为两种l类型： 临时实例：如果实例宕机超过一定时间，会从服务列表剔除，默认的类型。 非临时实例：如果实例宕机，不会从服务列表剔除，也可以叫永久实例。 配置 : discovery: ephemeral: false # 设置为非临时实例 Nacos与eureka的共同点 : 都支持服务注册和服务拉取 都支持服务提供者心跳方式做健康检测 Nacos与Eureka的区别 : Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式 临时实例心跳不正常会被剔除，非临时实例则不会被剔除 Nacos支持服务列表变更的消息推送模式，服务列表更新更及时 Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式；Eureka采用AP方式（CAP理论:C一致性,A高可用,P分区容错性） Nacos使用的netty和服务进行连接,属于长连接。eureka使用定时发送和服务进行连接,属于短连接
nacos配置中心 : Nacos一方面可以将配置集中管理，另一方可以在配置变更时，及时通知微服务，实现配置的热更新。 在nacos中添加配置文件 : 配置管理--配置列表 ID : 微服务名称-环境.配置文件后缀 group : 分组 配置格式 : 配置文件的类型 注意：项目的核心配置，需要热更新的配置才有放到nacos管理的必要。基本不会变更的一些配置还是保存在微服务本地比较好
微服务要拉取nacos中管理的配置，并且与本地的application.yml配置合并，才能完成项目启动。 spring引入了一种新的配置文件：bootstrap.yaml文件，会在application.yml之前被读取 流程 : 项目启动--加载bootstrap.yaml文件,获取nacos地址,配置文件的id--读取nacos配置--读取application.yml,加载本地配置,与nacos的配置进行合并--创建spring容器--加载bean 需要引入nacos-config依赖 配置 : 根据spring.cloud.nacos.server-addr获取nacos地址 config: file-extension: yaml # 文件后缀名 server-addr: localhost:8848 #nacos配置中心地址 namespace: devnamespace #空间id 修改nacos中的配置后，微服务中无需重启即可让配置生效，也就是配置热更新 读取配置的方式 : 1.控制层添加注解 @RefreshScope //刷新配置 2.@ConfigurationProperties(prefix = "user") //配置读取注解
配置共享 : 微服务启动时，会去nacos读取多个配置文件 [spring.application.name].yaml不包含环境，因此可以被多个环境共享。 配置共享的优先级 : 例 : itheima-user-dev.yaml(当前环境配置) > itheima-user.yaml(共享配置) > application.yml（本地配置）>bootstrap.yml(本地配置)
nacos集群搭建 : Nacos生产环境下一定要部署为集群状态 Nacos默认数据存储在内嵌数据库Derby中，不属于生产可用的数据库。 官方推荐的最佳实践是使用带有主从的高可用数据库集群，主从模式的高可用数据库可以参考**传智教育**的后续高手课程。
Ribbon : 负载均衡 作用 : 有助于HTTP客户端行为, 基于负载均衡算法,自动帮助服务消费者请求 负载均衡流程 : 服务消费者发送请求 -- 进入ribbon负载均衡(负载均衡拦截器拦截获取请求路径中的服务id) -- 去注册中心拉取服务 -- 返回服务列表 -- 算法 : 默认轮询的方式(选择某个服务) -- 根据服务的ip端口修改请求URL,调用微服务 负载均衡算法策略 : RoundRobinRule : 简单轮询服务列表选择服务器 AvailabilityFilteringRule : 对以下两种服务器进行忽略： 1.在默认情况下，这台服务器如果3次连接失败，这台服务器就会被设置为“短路”状态。短路状态将持续30秒，如果再次连接失败，短路的持续时间就会几何级地增加。 2.并发数过高的服务器。如果一个服务器的并发连接数过高，配置了AvailabilityFilteringRule规则的客户端也会将其忽略。并发连接数的上限， 可以由客户端的<clientName>.<clientConfigNameSpace>.ActiveConnectionsLimit属性进行配置。 WeightedResponseTimeRule : 为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重就越小。这个规则会随机选择服务器，这个权重值会影响服务器的选择。 ZoneAvoidanceRule : 以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。它是Ribbon默认的负载均衡规则。 BestAvailableRule : 忽略哪些短路的服务器，并选择并发数较低的服务器。 RandomRule : 随机选择一个可用的服务器 RetryRule : 重试机制的选择逻辑 负载均衡使用方式 : 1.启动类中添加负载均衡算法(注入Bean方式) -- 可以做到全局配置,如需修改需要项目重新打包 2.配置文件中指定某个服务只有指定的负载均衡算法 -- 无法做到全局配置,但修改方便,无需重新打包 Ribbon默认采用的是懒加载方式,也就是第一次访问的时候才会去创建LoadBalanceClient,请求的时间很长;饥饿加载会在项目启动时就会创建,降低了第一次请求时间,所以我们需要在配置文件中开启ribbon的饥饿加载
微服务网关gateway : 为微服务提供简单有效且统一的API路由管理方式(掌握 : 路由过滤器,全局过滤器,跨域问题) gateway是基于Spring5.0,SpringBoot2.0实现的属于响应式编程事件流技术开发的网关,具有很好的性能 核心功能 : 1.权限控制 : 网关是作为微服务的入口,所以我们需要校验用户是否有请求资格,如果没有则进行拦截 2.请求路由 : 网关不出来任何业务,但一切的请求都必须经过网关.他会根据负载均衡的策略将请求路由到微服务 3.限流 : 当请求流量过高时,在网关中按照下流的微服务所能够承受的速度放行请求,避免服务的压力过大 4.还能解决跨域问题 5.所有请求的统一入口 6.请求和响应处理 配置文件相关配置 : spring: cloud: gateway: routes: # 网关路由配置 - id: user-service # 路由id，自定义，只要唯一即可 # uri: http://127.0.0.1:18081 # 路由的目标地址 http就是固定地址 uri: lb://itheima-user # 路由的目标地址 lb就是负载均衡，后面跟服务名称 filters: # 过滤器 - AddRequestHeader=Heima,szheima119 nb! # 添加请求头 predicates: # 路由断言，也就是判断请求是否符合路由规则的条件 - Path=/user/** # 这个是按照路径匹配，只要以/user/开头就符合要求 断言工厂 : 配置文件中写的断言规则只是字符串，这些字符串会被Predicate Factory读取并处理，转变为路由判断的条件 | 名称 | 说明 | 示例 | | ---------- |------------------------------|------------------------------------------------------------| | 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 | 权重处理 | | 过滤器工厂 : GatewayFilter是网关中提供的一种过滤器，可以对进入网关的请求和微服务返回的响应做处理 spring提供了31种不同的过滤器工厂,主要常用的有 : | 名称 | 说明 | | -------------------- | ---------------------------| | AddRequestHeader | 给当前请求添加一个请求头 | | RemoveRequestHeader | 移除请求中的一个请求头 | | AddResponseHeader | 给响应结果中添加一个响应头 | | RemoveResponseHeader | 从响应结果中移除有一个响应头 | | RequestRateLimiter | 限制请求的流量 | 网关过滤器的作用 : 1.对路由请求或响应做加工处理 2.配置在路由下的过滤器只对当前路由的请求生效 3.default-filters 对所有路由的请求都生效 全局过滤器的作用 : 也是处理一切进入网关的请求和微服务的响应 实现方式 : 实现GlobalFilter接口即可 在filter中编写自定义逻辑，可以实现下列功能： 1.登录状态判断 2.权限校验 3.请求限流等 过滤器的执行顺序 : 请求进入网关会碰到三类过滤器：当前路由的过滤器、DefaultFilter、GlobalFilter 请求路由后，会将当前路由过滤器和DefaultFilter、GlobalFilter，合并到一个过滤器链（集合）中，排序后依次执行每个过滤器 排序的规则是什么呢？ 1.每一个过滤器都必须指定一个int类型的值，值越小，优先级越高，执行顺序越靠前。 2.GlobalFilter通过实现Ordered接口，或者添加@Order注解来指定order值，由我们自己指定 2.路由过滤器和defaultFilter的order由Spring指定，默认是按照声明顺序从1递增。 2.当过滤器的order值一样时，会按照 defaultFilter > 路由过滤器 > GlobalFilter的顺序执行。 源码 : org.springframework.cloud.gateway.route.RouteDefinitionRouteLocator#getFilters()方法是先加载defaultFilters，然后再加载某个route的filters，然后合并。 org.springframework.cloud.gateway.handler.FilteringWebHandler#handle()方法会加载全局过滤器，与前面的过滤器合并后根据order排序，组织过滤器链
跨域问题 : 域名不一致就是跨域 例 : 域名不同 : www.taobao.com 和 www.taobao.org 域名相同,端口不同 : localhost:8080和localhost8081 跨域问题指 : 浏览器禁止请求的发起者与服务端发生跨域ajax请求，请求被浏览器拦截的问题 解决方式 : 配置文件配置 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 # 这次跨域检测的有效期
微服务雪崩问题及解决方案 : 微服务之间相互调用，因为调用链中的一个服务故障，引起整个链路都无法访问的情况。 微服务中,服务之间调用是错终复杂的,一个微服务往往依赖多个其他微服务,如果有一个服务发生了故障那么就会导致整个微服务发生瘫痪 详解 : 1.如果服务提供者I发生了故障，当前的应用的部分业务因为依赖于服务I，因此也会被阻塞。此时，其它不依赖于服务I的业务似乎不受影响。 2.但是，依赖服务I的业务请求被阻塞，用户不会得到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞 3.服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，那么当前服务也就不可用了。 4.那么，依赖于当前服务的其它服务随着时间的推移，最终也都会变的不可用，形成级联失败，雪崩就发生了 雪崩处理方式 : 1.超时处理 : 设定超时时间,请求超过一定的时间没有响应就会返回错误信息,不会进入无休止的等待 2.仓壁模式(线程池隔离) : 这个方式来源于船舱设计,限定每个业务使用的线程数避免耗尽整个tomcat资源,因此叫线程池隔离 3.断路器 : 由断路器去统计业务执行发生的异常比例,如果超出了阈值就会熔断该业务,拦截访问该业务的一切请求 达到阈值后默认进入熔断,五秒内拦截一切请求,五秒后试着放行一个请求,如果成功访问了,则断路器进入关闭状态,整个过程是循环的 4.限流(流量控制) : 限制业务访问的QPS阈值(每秒处理请求的数量),避免服务因流量突增而发送故障 超时处理、线程隔离、降级熔断是在部分服务故障时，将故障控制在一定范围，避免雪崩。是一种补救措施。
服务保护技术对比 (Sentinel : 访问http://localhost:8090页面 账号和密码，默认都是：sentinel): Netfix Hystrix 断路器 : Resilience4J : Sentinel 哨兵机制(常用) : Sentinel是阿里巴巴开源的一款微服务流量控制组件。官网地址：https://sentinelguard.io/zh-cn/index.html 丰富的应用场景 : (可以承受阿里巴巴10年来双十一大促流量的核心场景),消息削峰填谷,集群流量控制,实时熔断下游不可用的应用等 完备的实时监控 : Sentinel可以提供实时的监控功能,可以在控制台中看到接入应用的单台机器秒级数据,甚至500台以下规模集群的汇总运行情况 广泛的开源生态 : Sentinel 提供开箱即用的与其它开源框架/库的整合模块，只需要引入相应的依赖并进行简单的配置即可快速地接入Sentinel。 完善的SPI扩展点 : Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。
Sentinel控制台 : 相关配置可查询SpringCould第三天资料 流控、熔断等都是针对簇点链路中的资源来设置的 流控 : 流量控制 降级 : 熔断降级 热点 : 热点参数限流,属于限流的一种 授权 : 请求的权限控制 配置后可以利用jmeter测试 流控模式 : 在添加限流规则时，点击高级选项，可以选择三种流控模式 : 直接：统计当前资源的请求，触发阈值时对当前资源直接限流，也是默认的模式 关联：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流 语法说明：当/write资源访问量触发阈值时，就会对/read资源限流，避免影响/write资源。 使用场景：比如用户支付时需要修改订单状态，同时用户要查询订单。查询和修改操作会争抢数据库锁，产生竞争。业务需求是优先支付和更新订单的业务，因此当修改订单业务触发阈值时，需要对查询订单业务限流。 满足该条件可以使用关联 : 1.两个有竞争关系的资源 2.一个优先级高,一个优先级低 链路：统计从指定链路访问到本资源的请求，触发阈值时，对指定链路限流 流控规则 : 对那个接口限流,就在后面点击流控进行配置
链路模式 : 只针对指定链路访问到本资源的请求做统计,判断是否超过阈值