0703 - Spring Cloud
2021-04-18 10:10:11 4 举报AI智能生成
登录查看完整内容
架构师技术栈-微服务
作者其他创作
大纲/内容
理论知识
两种解决方案
Zookeeper+Dubbo
SpringCloud全家桶
SOA面向服务
Spring Cloud
分布式微服务架构的一站式解决方案，是多种微服务架构落地技术的集合体，俗称微服务全家桶
中文文档：https://www.bookstack.cn/read/spring-cloud-docs/docs-user-guide-eureka.md
RestTemplate
定义
RestTemplate提供了多种便捷访问远程Http服务的方法，是一种简单便捷的访问restful服务的模板类，是Spring提供的用于访问Rest服务的客户端模板工具集
最新API
https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/web/client/RestTemplate.html
使用
使用RestTemplate访问restful接口非常的简单粗暴无脑（url、requestMap、ResponseBean.class）这三个参数分别代表REST请求地址、请求参数、HTTP响应转换被转换成的对象类型
组成
HttpMessageConverter 对象转换器
ClientHttpRequestFactory 默认是JDK的HttpURLConnection
ResponseErrorHandler 异常处理
ClientHttpRequestInterceptor 请求拦截器
什么是服务治理
在传统的RPC远程调用框架中，管理每个服务与服务之间依赖关系比较复杂，管理比较复杂，所以需要使用服务治理，管理服务于服务之间依赖关系，可以实现服务调用、负载均衡、容错等，实现服务发现和注册。
微服务要解决的四大问题（高可用、高并发、高性能）：网络的不可靠性
1、客户端如何访问这么多的服务
API网关
2、服务与服务之间如何通信
同步通信
HTTP（Apache Http Client）
RPC（Dubbo只支持Java，Apache Thrif，gRPC）
异步通信
Kafka、RabbitMQ、RocketMQ
3、这么多服务、如何管理
服务治理
服务注册与发现
基于客户端的服务注册与发现
Apache Zookeeper
基于服务端的注册与发现
Netflix Eureka
4、服务挂了、怎么办
重试机制
服务熔断
服务降级
服务限流
服务注册发现
客户端注册
客户端注册是服务自身要负责注册与注销的工作。当服务启动后向注册中心注册自身，当服务下线时注销自己。期间还需要和注册中心保持心跳。心跳不一定要客户端来做，也可以由注册中心负责（这个过程叫探活）。这种方式的缺点是注册工作与服务耦合在一起，不同语言都要实现一套注册逻辑。
第三方注册
第三方注册由一个独立的服务Registrar 负责注册与注销。当服务启动后以某种方式通知Registrar，然后Registrar 负责向注册中心发起注册工作。同时注册中心要维护与服务之间的心跳，当服务不可用时，向注册中心注销服务。这种方式的缺点是Registrar 必须是一个高可用的系统，否则注册工作没法进展。
API Gateway 是一个服务器，也可以说是进入系统的唯一节点。这跟面向对象设计模式中的Facade 模式很像。API Gateway 封装内部系统的架构，并且提供API 给各个客户端。它还可能有其他功能，如授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等。下图展示了一个适应当前架构的API Gateway。
技术选型
Spring Cloud技术栈
服务注册中心
Eureka
Zookeeper
Consul
Nacos
Zookeeper、Consul和Ereka的区别
负载均衡
Ribbon
LoadBalancer
服务调用
Feign
OpenFeign
Hystrix
resilience4j
sentienl
服务网关
Zuul
gateway
服务配置
config
服务总线
Bus
版本截止到2020.2.15
Hoxton.SR1
Spring Boot
2.2.2.RELEASE
Spring Cloud Alibaba
2.1.0.RELEASE
Java
Java8
Maven
3.5及以上
MySQL
5.7及以上
项目实战
如何实现热部署
第一步 添加devtools依赖
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> <scope>runtime</scope> <optional>true</optional> </dependency>
第二步 添加插件到pom.xml中
<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> <configuration> <fork>true</fork> <addResources>true</addResources> </configuration> </plugin> </plugins> </build>
第三步 在IDEA中开启自动编译的权限
Settings->Build->Compiler
Automatically、Display、Build、Compile开头的选项勾选
第四步 更新值配置
快捷键：ctrl+shift+alt+/ 选择 Registry
勾选compiler.automake.allow.when.app.running、actionSystem.assertFocusAccessFromEdt
第五步 重启IDEA
pom.xml
dependencyManagement的作用
Spring Cloud NetFlix
注册中心：Eureka
工作原理
Eureka工作原理图
1、Eureka Server 启动成功，等待服务端注册。在启动过程中如果配置了集群，集群之间定时通过 Replicate 同步注册表，每个 Eureka Server 都存在独立完整的服务注册表信息2、Eureka Client 启动时根据配置的 Eureka Server 地址去注册中心注册服务3、Eureka Client 会每 30s 向 Eureka Server 发送一次心跳请求，证明客户端服务正常4、当 Eureka Server 90s 内没有收到 Eureka Client 的心跳，注册中心则认为该节点失效，会注销该实例5、单位时间内 Eureka Server 统计到有大量的 Eureka Client 没有上送心跳，则认为可能为网络异常，进入自我保护机制，不再剔除没有上送心跳的客户端6、当 Eureka Client 心跳请求恢复正常之后，Eureka Server 自动退出自我保护模式7、Eureka Client 定时全量或者增量从注册中心获取服务注册表，并且将获取到的信息缓存到本地8、服务调用时，Eureka Client 会先从本地缓存找寻调取的服务。如果获取不到，先从注册中心刷新注册表，再同步到本地缓存9、Eureka Client 获取到目标服务器信息，发起服务调用10、Eureka Client 程序关闭时向 Eureka Server 发送取消请求，Eureka Server 将实例从注册表中删除
简介
Eureka是Netflix开发的，一个基于 REST 服务的，服务注册与发现的组件，它主要包括两个组件：Eureka Server 和 Eureka Client
两个组件
Eureka Server
服务注册
服务提供者启动时，会通过Eureka Client向Eureka Server注册信息，Eureka Server会存储该服务的信息，Eureka Server内部有二层缓存机制来维护整个注册表
提供注册表
服务消费者在调用服务时，如果 Eureka Client 没有缓存注册表的话，会从 Eureka Server 获取最新的注册表
同步状态
Eureka Client 通过注册、心跳机制和 Eureka Server 同步当前客户端的状态
Eureka Client
Eureka Client 是一个 Java 客户端，用于简化与 Eureka Server 的交互。Eureka Client 会拉取、更新和缓存 Eureka Server 中的信息。因此当所有的 Eureka Server 节点都宕掉，服务消费者依然可以使用缓存中的信息找到服务提供者，但是当服务有更改的时候会出现信息不一致。
概念解析
服务的提供者，将自身注册到注册中心，服务提供者也是一个 Eureka Client。当 Eureka Client 向 Eureka Server 注册时，它提供自身的元数据，比如 IP 地址、端口，运行状况指示符 URL，主页等
服务续约
Eureka Client 会每隔 30 秒发送一次心跳来续约。 通过续约来告知 Eureka Server 该 Eureka Client 运行正常，没有出现问题。 默认情况下，如果 Eureka Server 在 90 秒内没有收到 Eureka Client 的续约，Server 端会将实例从其注册表中删除，此时间可配置，一般情况不建议更改。
服务续约的两个重要属性
服务续约任务的调用间隔时间，默认为30秒eureka.instance.lease-renewal-interval-in-seconds=30服务失效的时间，默认为90秒。eureka.instance.lease-expiration-duration-in-seconds=90
Eviction 服务剔除
当 Eureka Client 和 Eureka Server 不再有心跳时，Eureka Server 会将该服务实例从服务注册列表中删除，即服务剔除
Cancel 服务下线
Eureka Client 在程序关闭时向 Eureka Server 发送取消请求。 发送请求后，该客户端实例信息将从 Eureka Server 的实例注册表中删除。该下线请求不会自动完成，它需要调用以下内容：DiscoveryManager.getInstance().shutdownComponent()；
GetRegisty 获取注册列表信息
Eureka Client 从服务器获取注册表信息，并将其缓存在本地。客户端会使用该信息查找其他服务，从而进行远程调用。该注册列表信息定期（每30秒钟）更新一次。每次返回注册列表信息可能与 Eureka Client 的缓存信息不同，Eureka Client 自动处理。
Remote Call 远程调用
当 Eureka Client 从注册中心获取到服务提供者信息后，就可以通过 Http 请求调用对应的服务；服务提供者有多个时，Eureka Client 客户端会通过 Ribbon 自动进行负载均衡。
自我保护机制（好死不如赖活着）
原因
在微服务架构下服务之间通常都是跨进程调用，网络通信往往会面临着各种问题，比如微服务状态正常，网络分区故障，导致此实例被注销。
原理
Eureka 自我保护机制是为了防止误杀服务而提供的一个机制。当个别客户端出现心跳失联时，则认为是客户端的问题，剔除掉客户端；当 Eureka 捕获到大量的心跳失败时，则认为可能是网络问题，进入自我保护机制；当客户端心跳恢复时，Eureka 会自动退出自我保护机制。Eureka Server 进入自我保护机制，会出现以下几种情况：(1) Eureka 不再从注册列表中移除因为长时间没收到心跳而应该过期的服务(2) Eureka 仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)(3) 当网络稳定时，当前实例新的注册信息会被同步到其它节点中
高可用
集群搭建搭建原理：互相注册、相互守望
负载均衡：Ribbon
概述
是什么
Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡工具
官网
https://github.com/Netflix/ribbon/wiki/Getting-Started
Ribbon目前已进入维护模式
未来替换方案-SpringCloud Loadbalance
能干什么
集中式负载均衡
即在服务的消费方和提供方之间使用独立的LB设施(可以是硬件、软件)由该设施负责把访问请求通过某种策略转发至服务的提供方
进程内负载均衡
将LB逻辑集成到消费方，消费方从服务注册中心获知由哪些地址可用，然后自己再从这些地址种选择出一个合适的服务器
Ribbon就属于进程内LB，它只是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方的地址
LB负载均衡是什么
简单的说就是将用户的请求分摊的分配到多个服务上，从而达到系统的HA(高可用)，最常见的负载均衡软件Nginx、LVS、硬件F5等
Ribbon本地负载均衡 VS Nginx服务端负载均衡
Nginx是服务器负载均衡，客户端所有请求都会交给nginx，然后由nginx实现转发请求，即负载均衡是由服务端实现的；Ribbon本地负载均衡，在调用微服务接口的时候，会在注册中心上获取注册信息服务列表之后缓存到JVM本地，从而在本地实现RPC远程服务调用技术。
Ribbon负载均衡演示
负责均衡+RestTemplate
第一步先选择EurekaServer，它优先选择在同一个区域内负载较少的server第二步再根据用户指定的策略，在从server取到的服务注册列表种选择一个地址其中Ribbon提供了多种策略：比如轮询、随机和根据响应时间加权等
Ribbon架构原理图
Ribbon核心组件IRule
描述
IRule：根据特定算法从服务列表中选取一个要访问的服务
七种负载策略
com.netflix.loadbalancer.RandomRule 随机
随机策略
com.netflix.loadbalancer.RoundRobinRule 轮询
轮询策略
com.netflix.loadbalancer.RetryRlue 先按照RoundRobinRule的策略获取服务，如果获取服务失败则在指定时间内进行重试
重试策略
com.netflix.loadbalancer.WeightedResponseTimeRule 根据响应时间加权，对RoundRobinRule的扩展，响应速度越快的实例选择权限越大，约容易被选择
响应时间加权策略
com.netflix.loadbalancer.BestAvailableRule 先过滤掉由于多次访问故障而处于断路跳闸状态的服务，然后选择一个并发量最小的服务
最小并发策略
com.netflix.loadbalancer.AvailabilityFilteringRule 先过滤掉故障实例，再选择并发较小的实例
com.netflix.loadbalancer.ZoneAvoidanceRule 默认规则，复合判断server所在区域的性能和server的可用性选择服务器
IRule接口的实现类有以下几种
IRule接口
Ribbon负载均衡算法
LoadBalancerClient（RibbonLoadBalancerClient是实现类）在初始化的时候（execute方法），会通过ILoadBalance（BaseLoadBalancer是实现类）向Eureka注册中心获取服务注册列表，并且每10s一次向EurekaClient发送“ping”，来判断服务的可用性，如果服务的可用性发生了改变或者服务数量和之前的不一致，则从注册中心更新或者重新拉取。LoadBalancerClient有了这些服务注册列表，就可以根据具体的IRule来进行负载均衡。
Ribbon框架源码设计缺陷及优化
接口调用：Feign
已过时，OpenFeign代替
熔断降级：Hystrix
Hystrix是一个处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，Hystrix能够保证一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。
功能
大神论文
https://martinfowler.com/
实现原理
命令模式
舱壁模式
隔离策略
应用在复杂的分布式结构中，可能会依赖许多其他的服务，并且这些服务都不可避免地有失效的可能。如果一个应用没有与依赖服务的失效隔离开来，那么它将有可能因为依赖服务的失效而失效。Hystrix将货仓模式运用到了服务调用者上。为每一个依赖服务维护一个线程池（或者信号量），当线程池占满，该依赖服务将会立即拒绝服务而不是排队等待。每个依赖服务都被隔离开来，Hystrix 会严格控制其对资源的占用，并在任何失效发生时，执行失败回退逻辑。
观察者模式
Hystrix通过观察者模式对服务进行状态监听。每个任务都包含有一个对应的Metrics，所有Metrics都由一个ConcurrentHashMap来进行维护，Key是CommandKey.name() 在任务的不同阶段会往Metrics中写入不同的信息，Metrics会对统计到的历史信息进行统计汇总，供熔断器以及Dashboard监控时使用。
熔断机制
熔断是参考电路而产生的一种保护性机制，即系统中如果存在某个服务失败率过高时，将开启熔断器，对于后续的调用，不在继续请求服务，而是进行Fallback操作。熔断所依靠的数据即是Metrics中的HealthCount所统计的错误率。
服务网关：Zuul
官方网站
是什么，能干什么
zuul是spring cloud的网关组件，可以构建动态路由、服务降级、负载均衡的服务网关，通过filter链式调用进行扩展，实现统一认证、调用监控、日志管理等等功能。
组件
ZuulFilter
这是zuul的核心，分为pre、route、post三种类型，分别对应服务调用之前、之中、之后的处理。
ZuulServlet
一个HttpServlet，执行所有ZuulFilter的入口。
Route
路由的一个节点，通常对应某个微服务。
RouteLocator
获取所有Route的接口，有SimpleRouteLocator和DiscoveryClientRouteLocator两种实现，后者继承自前者，前者通过配置文件配置获得，后者扩展了通过服务发现找到所有服务，并默认为所有服务生成path为/serviceId/**的Route。
ZuulController
需要路由的请求的统一处理器，继承自ServletWrappingController，把请求统一代理给ZuulServlet处理。
ZuulHandlerMapping
继承自spring mvc模块的AbstractUrlHandlerMapping，通过RouteLocator 获取到所有Route之后把route的fullPath和ZuulController注册到到HandlerMap中，把网关需要路由的路径统一映射到ZuulController。
Spring Cloud 自研发
消息驱动：Stream
一句话：屏蔽底层消息中间件的差异，降低切换成本
声明式服务调用：OpenFeign
Feign是一个声明式WebService客户端，使用Feigh能让编写Web Service给客户端更加简单
Feign旨在使编写Java Http客户端变得更容易。前面在使用Ribbon+RestTemplate时，利用RestTemplate对Http请求的封装处理，形成了一套模板化的调用方法。但是在实际开发中，由于对服务依赖的调用可能不止一处，往往一个接口会被多处调用，所以通常都会针对每个微服务自行封装一些客户端类来包装这些依赖服务的调用。所以，Feign在此基础上做了进一步的封装，由他来帮助我们定义和实现依赖服务接口的定义。在Feign的实现下，我们只需创建一个接口并使用注解的方式来配置它（以前是Dao接口上标注Mapper注解，现在是一个微服务接口上面标注一个Feign注解即可），即可完成对服务提供方的接口绑定，简化了使用Spring Cloud Ribbon时，自动封装服务调用客户端的开发量。
超时控制
日志打印
服务网关：GateWay
服务动态路由
服务统一限流熔断
服务统一缓存
服务统一授权认证
服务统一性能监控
服务统一灰度发布
配置中心：Config
分布式系统面临的配置问题
能干嘛
解决方案
消息总线：Bus（Kafka、RabbitMQ）
链路追踪：Sleuth
Spring Cloud 其它
分布式配置中心
Nacos、Apollo、Config区别
携程Apollo
Apollo（阿波罗）是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。
官方文档
https://github.com/ctripcorp/apollo/wiki/Apollo%E9%85%8D%E7%BD%AE%E4%B8%AD%E5%BF%83%E4%BB%8B%E7%BB%8D
背景
程序功能日益复杂，配置日益增多，各种功能的开关、参数的配置、服务器地址等等越来越难管理；因此针对程序配置的期望越来越高（配置修改后实时生效、灰度发布、分环境、分集群管理配置、完善的权限审核机制等等）在这样的大环境下传统的通过配置文件、数据库等方式越来越无法满足开发人员对配置管理的需求。
优点
统一管理不同环境、不同集群的配置
Apollo提供了一个统一界面集中式管理不同环境（environment）、不同集群（cluster）、不同命名空间（namespace）的配置。同一份代码部署在不同的集群，可以有不同的配置，比如zookeeper的地址等通过命名空间（namespace）可以很方便地支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖
配置修改实时生效（热发布）
用户在Apollo修改完配置并发布后，客户端能实时（1秒）接收到最新的配置，并通知到应用程序
版本发布管理
所有的配置发布都有版本概念，从而可以方便地支持配置的回滚
灰度发布
支持配置的灰度发布，比如点了发布后，只对部分应用实例生效，等观察一段时间没问题后再推给所有应用实例
权限管理、发布审核、操作审计
应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误。所有的操作都有审计日志，可以方便地追踪问题
客户端配置信息监控
可以在界面上方便地看到配置在被哪些实例使用
提供Java和.Net原生客户端
提供开放平台API
Apollo自身提供了比较完善的统一配置管理界面，支持多环境、多数据中心配置管理、权限、流程治理等特性。不过Apollo出于通用性考虑，不会对配置的修改做过多限制，只要符合基本的格式就能保存，不会针对不同的配置值进行针对性的校验，如数据库用户名、密码，Redis服务地址等对于这类应用配置，Apollo支持应用方通过开放平台API在Apollo进行配置的修改和发布，并且具备完善的授权和权限控制
部署简单
配置中心作为基础服务，可用性要求非常高，这就要求Apollo对外部依赖尽可能地少目前唯一的外部依赖是MySQL，所以部署非常简单，只要安装好Java和MySQL就可以让Apollo跑起来Apollo还提供了打包脚本，一键就可以生成所有需要的安装包，并且支持自定义运行时参数
工作模型
1、用户在配置中心对配置进行修改并发布2、配置中心通知Apollo客户端有配置更新3、Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用
Appolo工作模型
高级特性
application（应用）
这个很好理解，就是实际使用配置的应用，Apollo客户端在运行时需要知道当前应用是谁，从而可以去获取对应的配置每个应用都需要有唯一的身份标识 -- appId
environment (环境)
配置对应的环境，Apollo客户端在运行时需要知道当前应用处于哪个环境，从而可以去获取应用的配置我们认为环境和代码无关，同一份代码部署在不同的环境就应该能够获取到不同环境的配置所以环境默认是通过读取机器上的配置（server.properties中的env属性）指定的，不过为了开发方便，我们也支持运行时通过System Property等指定
cluster (集群)
一个应用下不同实例的分组，比如典型的可以按照数据中心分，把上海机房的应用实例分为一个集群，把北京机房的应用实例分为另一个集群。对不同的cluster，同一个配置可以有不一样的值，如zookeeper地址。集群默认是通过读取机器上的配置（server.properties中的idc属性）指定的，不过也支持运行时通过System Property指定
namespace (命名空间)
一个应用下不同配置的分组，可以简单地把namespace类比为文件，不同类型的配置存放在不同的文件中，如数据库配置文件，RPC配置文件，应用自身的配置文件等应用可以直接读取到公共组件的配置namespace，如DAL，RPC等应用也可以通过继承公共组件的配置namespace来对公共组件的配置做调整，如DAL的初始数据库连接数
总体设计
1、Config Service提供配置的读取、推送等功能，服务对象是Apollo客户端2、Admin Service提供配置的修改、发布等功能，服务对象是Apollo Portal（管理界面）3、Config Service和Admin Service都是多实例、无状态部署，所以需要将自己注册到Eureka中并保持心跳4、在Eureka之上我们架了一层Meta Server用于封装Eureka的服务发现接口5、Client通过域名访问Meta Server获取Config Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Client侧会做load balance、错误重试6、Portal通过域名访问Meta Server获取Admin Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Portal侧会做load balance、错误重试7、为了简化部署，我们实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM进程中
Appolo总体设计（官方）
Appolo总计设计
客户端实现
1、客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。2、客户端还会定时从Apollo配置中心服务端拉取应用的最新配置。--这是一个fallback机制，为了防止推送机制失效导致配置不更新--客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304 - Not Modified--定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property: apollo.refreshInterval来覆盖，单位为分钟。3、客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中4、客户端会把从服务端获取到的配置在本地文件系统缓存一份--在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置5、应用程序从Apollo客户端获取最新的配置、订阅配置更新通知
Apollo客户端实现
部署
快速部署
https://github.com/ctripcorp/apollo/wiki/Quick-Start
分布式部署指南
https://github.com/ctripcorp/apollo/wiki/%E5%88%86%E5%B8%83%E5%BC%8F%E9%83%A8%E7%BD%B2%E6%8C%87%E5%8D%97
分布式注册中心
介绍
Consul是一套开源的分布式服务发现和配置管理系统，由HashiCorp公司用Go语言开发
提供了微服务系统中的服务治理、配置中心、控制总线等功能，这些功能中的每一个都可以根据需要单独使用，也可以一起使用以构建全方位的服务网络，总之Consul提供了一种完整的服务网格解决方案。
服务发现
提供HTTP和DNS两种发现方式
健康监测
支持多种方式HTTP、TCP、Docker、Shell脚本定制化
KV存储
key、value的存储方式
多数据中心
Consul支持多数据中心
可视化Web界面
注册配置中心：Nacos
服务注册与发现详解
服务心跳与下线详解
服务健康检测详解
Nacos集群架构实战
Nacos集群节点间服务数据同步详解
Nacos集群架构CAP原理详解
AP架构详解
CP架构详解
集群脑裂问题及解决方案
Nacos源码高并发设计精髓
防止读写并发冲突CopyOnWrite设计思路
异步任务及内部队列有效提升系统并发
异步批量同步集群节点数据有效提供系统性能
阿里云超大规模微服务注册中心设计架构详解
Docker下安装nacos
安装镜像[root@localhost ~]# docker pull nacos/nacos-server:1.1.4-----------------------------------------------------------------------------------------------------------------------------启动镜像[root@localhost ~]# docker run --env MODE=standalone --name nacos -d -p 8848:8848 nacos/nacos-server:1.1.4
服务限流降级熔断：Sentinel
限流源码剖析
限流类型详解
QPS限流
线程数限流源码剖析
限流模式详解
限流效果详解
请求快速失败
请求预热
请求排队
限流算法详解
计数器限流
滑动时间窗口限流
令牌桶限流
漏桶限流
熔断降级
服务断路设计思想
接口平均响应时间超时熔断
接口异常比例过高熔断
接口异常数过多熔断
服务降级注解自动化配置
热点限流规则
秒杀场景指定热点参数限流实现
系统负载限流
系统级负载Load限流
系统级平均响应时间限流
系统级线程数限流
系统级QPS限流
系统CPU使用率限流
系统黑白名单授权规则限流
分布式事务：Seata
Seata全局事务注册
Seata分支事务客户端全局锁冲突自旋设计原理剖析
Seata分支事务服务端全局锁设计源码剖析
全局事务提交
全局事务回滚
分支事务第二阶段异步提交
分支事务第二阶段生成反向SQL执行回滚
服务调用：Dubbo
分布式消息：RocketMQ
微服务的用户认证与授权详解
微服务API安全机制详解
微服务安全之Oauth2协议
微服务安全之传统的Session认证与授权
微服务安全之Token机制的认证与授权
JWT安全认证方案详解
0 条评论
回复 删除
下一页
