
springcloud框架学习
文章平均质量分 97
springcloud框架阶段的学习
抱走江江
最近忙着开题,所以更新会慢点啦
展开
专栏收录文章
- 默认排序
- 最新发布
- 最早发布
- 最多阅读
- 最少阅读
-
SpringCloud框架学习(第七部分:分布式事务Seata)
SimpleExtensibleAutonomousTransactionArchitecture:简单可扩展自治事务框架阿里巴巴作为国内最早一批进行应用分布式(微服务化)改造的企业,很早就遇到微服务架构下的分布式事务问题。2019年1月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案:2014 年,阿里中间件团队发布 TXC(Taobao Transaction Constructor),为集团内应用提供分布式事务服务。原创 2024-12-02 19:42:46 · 922 阅读 · 0 评论 -
SpringCloud框架学习(第六部分:Sentinel实现熔断与限流)
等价于 Spring Cloud Circuit BreakerSentinel 能够对流量进行控制,主要是监控应用的 QPS 流量或者并发线程数等指标,如果达到指定的阈值时,就会被流量进行控制,以避免服务被瞬时的高并发流量击垮,保证服务的高可靠性。1资源名资源的唯一名称,默认就是请求的接口路径,可以自行修改,但是要保证唯一。2针对来源具体针对某个微服务进行限流,默认值为default,表示不区分来源,全部限流。3阈值类型QPS表示通过QPS进行限流,并发线程数表示通过并发线程数限流。4单机阈值。原创 2024-11-29 21:12:24 · 1740 阅读 · 0 评论 -
SpringCloud框架学习(第五部分:SpringCloud Alibaba入门和 nacos)
2018.10.31,Spring Cloud Alibaba 正式入驻了 Spring Cloud 官方孵化器,并在 Maven 中央库发布了第一个版本。前四个字母分别为Naming 和Configuration 的前两个字母,最后的s为 ServiceNacos:一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。(Nacos就是注册中心 + 配置中心的组合,等价于 Spring Cloud Consul)替代 Eureka / Consul 做服务注册中心。原创 2024-11-23 23:30:10 · 1299 阅读 · 0 评论 -
SpringCloud框架学习(第四部分:Gateway网关)
是在 Spring 生态系统之上构建的 API 网关服务,基于 Spring6,Spring Boot 3和 Project Reactor 等技术。它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式,并为它们提供跨领域的关注点,例如:安全性、监控/度量和恢复能力。Cloud 全家桶中有个很重要的组件就是网关,在 1.x 版本中都是采用的Zuul网关;原创 2024-11-22 16:57:35 · 1288 阅读 · 0 评论 -
SpringCloud框架学习(第三部分:Resilience4j 与 Micrometer)
Hystrix 是一个用于处理分布式系统的延迟和容错的开源库,在分布式系统里,许多依赖不可避免的会调用失败,比如超时、异常等。Hystrix 能够保证在一个依赖出问题的情况下,不会导致整体服务失败,避免级联故障,以提高分布式系统的弹性。但 Hystrix 目前已经进入了维护模式,我们不再使用。Hystrix 新的替代方案是 Resilience4j,接下来将进行介绍。Sleuth 目前已经进入了维护模式,它的核心功能已转移至 Micrometer Tracing!原创 2024-11-14 23:04:19 · 1377 阅读 · 0 评论 -
SpringCloud框架学习(第二部分:Consul、LoadBalancer和openFeign)
Question1:Consul是什么?Consul是一款开源的分布式服务发现与配置管理系统,由HashiCorp公司使用Go语言开发。官方:http://consul.io/Question2:为什么不使用Eureka了?① Eureka 停更了,不在开发新版本了② Eureka 对初学者不友好,有自我保护机制③ 我们希望注册中心能够从项目中分离出来,单独运行(解耦),而 Eureka 做不到这一点Question3:Consul能干什么?① 服务发现:提供HTTP和DNS两种发现方式。原创 2024-11-11 20:35:23 · 1877 阅读 · 0 评论 -
SpringCloud框架学习(第一部分:初始项目搭建)
将业务的所有功能集中在一个项目中开发,打成一个包部署架构简单部署成本低当随着业务越来越多,代码量将上升至几万行甚至几十万行,开发人员也会需要越来越多!各业务之前存在耦合性,编写、提交代码时,可能会产生冲突。同时,代码量过高也会造成编译,打包时间过长。某些业务存在高并发,就会很容易将服务器资源耗尽,其他业务就只能等待,访问时就会卡顿。团队协作成本高系统发布效率低系统可用性差单体架构适合开发功能相对简单,规模较小的项目。原创 2024-11-08 22:35:29 · 1838 阅读 · 0 评论