当前位置: 首页 > news >正文

微服务保护和分布式事务-01.雪崩问题-原因分析

一.雪崩问题

我们将单体架构拆分成微服务架构,在拆分的过程中我们就遇到了各种各样的问题。比如我们在拆分后各个微服务之间要进行相互调用,这种跨服务之间的远程调用,我们使用OpenFeign来解决。

这样的调用错综复杂,我们要维护微服务之间的地址和状态,这就要用到nacos服务治理组件。

服务多了之后不仅仅服务之间调用复杂,前端也不清楚哪个请求要调用哪个微服务。因此我们引入了网关,网关一方面可以实现前端请求路由转发到对应的微服务。另一方面也可以对前端请求进行身份的认证。

后来我们又发现微服务越来越多,每个微服务都有自己的配置文件,这些配置太多太复杂,如果配置出现变更我们还需要重启服务,这样一来服务的可用性就降低了,为了解决这一问题我们又学习了配置管理。还是nacos的功能。一方面可以显示配置的抽取和共享,简化微服务的配置。另一方面还可以实现微服务的配置热更新,修改配置无需重启,这样可以提高整个服务的可用性。

以上就是我们目前学习的所有微服务组件。

但是我们还要掌握一下能力:

1.服务保护:如果有的服务出现了故障,应该对于这个情况有对应的方案和健壮性的处理。

2.分布式事务:以前单体项目不管项目多复杂,都能够满足事务的ACID特性,但是拆分成微服务后由于每个服务是独立的,他们各自去操作数据库。这样就破坏了事物的ACID特性。这又该怎么处理。

我们首先来看服务保护经常会碰到的问题:雪崩问题。

二.雪崩问题

如果商品服务由于故障崩溃了,会导致很多由购物车服务发向商品服务的请求得不到响应。这就会导致越来越多的请求堆积到购物车服务这里。从而导致很多用户对购物车服务的请求得不到处理。最后很多服务堆积来不及处理会导致Tomcat资源耗尽。

一旦资源耗尽,就算有新的请求进入到购物车服务,就算他不是请求商品服务的,而是请求其他服务的,但是由于资源耗尽也无法请求。就会导致整个服务瘫痪。

http://www.dtcms.com/a/354569.html

相关文章:

  • LeetCode-279. 完全平方数
  • 楼宇自控系统应需而生为现代建筑装上智能化翅膀
  • 【论文阅读】CLIP: 从自然语言监督中学习可迁移的视觉模型
  • 移动端网页调试实战,iOS WebKit Debug Proxy 的应用与替代方案
  • 《口令猜测研究进展》——论文阅读
  • springboot连接不上redis,但是redis客户端是能连接上的
  • ⸢ 贰 ⸥ ⤳ 安全架构:数字银行安全体系规划
  • iOS混淆工具实战,社交类 App 的隐私与安全防护混淆流程
  • 【C++详解】用哈希表封装实现myunordered_map和 myunordered_set
  • Redis 保证数据不丢失
  • 系统架构设计师备考第10天——网络技术-局域网以太网
  • [n8n] 全文检索(FTS)集成 | Mermaid图表生成
  • 基于django的梧桐山水智慧旅游平台设计与开发(代码+数据库+LW)
  • [p2p-Magnet] docs | HTTP API与Web界面 | 搜索查询引擎
  • OpenAI重组受阻:微软“锁链”与生态博弈
  • [p2p-Magnet] 数据模型(GORM) | DHT爬虫 | 分类器
  • 华为云OBS+HMS+EMRonEC2+HiveSparkFlink+GaussDB
  • GaussDB 修改schema属主时报:must be member of role “dtest“
  • 架构设计模式七大原则
  • 如何将iPhone上的隐藏照片传输到电脑
  • 零基础开发应用:cpolar+Appsmith平民化方案
  • AbpVnext 阿里云ssl证书多个生产环境自动更新
  • 观远BI仪表板智能洞察场景实战:如何破解门店销售、渠道转化与经营分析难题
  • 用React写一个技能冷却的案例,关于节流
  • C++《哈希表》
  • Day16_【机器学习常见术语】
  • Qt自定义聊天消息控件ChatMessage:初步实现仿微信聊天界面
  • Python 数据分析学习笔记:Pandas 逻辑运算
  • 97、23种设计模式之桥接模式(6/23)
  • 鸿蒙Harmony-从零开始构建类似于安卓GreenDao的ORM数据库(四)