了解java架构之微服务架构—雪崩效应

前言

微服务化产品线,每一个服务专心于自己的业务逻辑,并对外提供相应的接口,看上去似乎很明了,其实还有很多的东西需要考虑,比如:服务的自动扩充,熔断和限流等,随着业务的扩展,服务的数量也会随之增多,逻辑会更加复杂,一个服务的某个逻辑需要依赖多个其他服务才能完成。

一但一个依赖不能提供服务很可能会产生雪崩效应,最后导致整个服务不可访问。

微服务之间进行rpc或者http调用时,我们一般都会设置调用超时,失败重试等机制来确保服务的成功执行,看上去很美,如果不考虑服务的熔断和限流,就是雪崩的源头。

假设我们有两个访问量比较大的服务A和B,这两个服务分别依赖C和D,C和D服务都依赖E服务

A和B不断的调用C,D处理客户请求和返回需要的数据。当E服务不能供服务的时候,C和D的超时和重试机制会被执行

由于新的调用不断的产生,会导致C和D对E服务的调用大量的积压,产生大量的调用等待和重试调用,慢慢会耗尽C和D的资源比如内存或CPU,然后也down掉。

A和B服务会重复C和D的操作,资源耗尽,然后down掉,最终整个服务都不可访问。

常见的导致雪崩的情况有以下几种:

  • 程序bug导致服务不可用,或者运行缓慢
  • 缓存击穿,导致调用全部访问某服务,导致down掉
  • 访问量的突然激增。
  • 硬件问题,这感觉只能说是点背了⊙︿⊙。

虽然雪崩效应的产生千万条,保证服务的不挂机,和流畅运行是我们不可推卸的责任,对应雪崩效应还是有很多保护方案的。

服务的横向扩充

现在我们可以利用很多工具来保证服务不会挂掉,然后流量比较大的时候,可以横向扩充服务来保证业务的流畅。比如我们最常使用k8s,能保证服务的运行状态,也可以让服务自动的横向扩充。对于用户访问量的激增情况这样处理还是很不错的,但是,横向扩充也是有尽头的,如果在一定环境下E服务的响应时间过长,依然有可能导致雪崩效应的产生。

限流

限制客户端的调用来达到限流的做法是很常见的,比如,我们限制每秒最大处理200个请求,超过个数量直接拒绝请求。常见的算法如令牌桶算法

以一定的速度在桶里放令牌,当客户端请求服务的时候,要先从桶里得到令牌,才能被处理,如果桶里的令牌用完了,则拒绝访问。

熔断

在客户端控制对依赖的访问,如果调用的依赖不可用时,则不再调用,直接返回错误,或者降级处理。开源的库比如hystrix-go,也是我接下来要写的源码分析的一个库。很好的实现了熔断和降级的功能。他的主要思想是,设置一些阀值,比如,最大并发数,错误率百分比,熔断尝试恢复时间等。能过这些阀值来转换熔断器的状态:

关闭状态,允许调用依赖
打开状态,不允许调用依赖,直接返回错误,或者调用fallback
半开状态,根据熔断尝试恢复时间来开启,允许调用依赖,如果调用成功则关闭失败则继续打开

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • java使用三层架构实现电影购票系统

    使用三层架构实现电影购票系统,分用户和管理员,用户功能:展示电影,查找电影(模糊查询),查看电影详情,查找场次,购买影票,订制座位,退订影票等功能,界面美观漂亮,逻辑严谨,附加电影评论功能,订票超过五张打0.9折的打折功能.管理员功能:影院的增删改查,场次的增删改查,电影的增删改查,影票管理等. 管理员账号:admin  密码:admin 下载地址:java实现电影购票系统 效果展示图: 登录界面: 用户主界面: 查看热门电影: 点击电影进入查看详情,可以看到该电影的所有评论,可以进行评论. 点

  • Java高级架构之FastDFS分布式文件集群详解

    FastDFS简介 FastDFS是一款开源的轻量级分布式文件系统,使用C实现,支持Linux.BSD等unix-like操作系统.值得注意的是,fastdfs并不是通用的文件系统,只能通过专用的API访问. fastdfs为互联网应用量身定做,解决了大容量文件存储的问题,fastdfs追求高性能和高扩展性.fastdfs的主要概念: tracker-server:跟踪服务器.用于跟踪文件,主要起调度作用.在内存中记录了所有存储组和存储服务器的状态信息,是客户端和数据存储的主要枢纽.相比GFS更

  • 浅析JavaWeb项目架构之Redis分布式日志队列

    摘要: 架构.分布式.日志队列,标题自己都看着唬人,其实就是一个日志收集的功能,只不过中间加了一个Redis做消息队列罢了. 为什么需要消息队列? 当系统中出现"生产"和"消费"的速度或稳定性等因素不一致的时候,就需要消息队列,作为抽象层,弥合双方的差异. 架构.分布式.日志队列,标题自己都看着唬人,其实就是一个日志收集的功能,只不过中间加了一个Redis做消息队列罢了. 为什么需要消息队列? 当系统中出现"生产"和"消费"的

  • 10本Java架构师必读书籍

    Java架构师必读书籍,分享给大家 1.大型网站系统与JAVA中间件实践 本书围绕大型网站和支撑大型网站架构的Java中间件的实践展开介绍. 从分布式系统的知识切入,让读者对分布式系统有基本的了解:然后介绍大型网站随着数据量.访问量增长而发生的架构变迁:接着讲述构建Java中间件的相关知识:之后的几章都是根据笔者的经验来介绍支撑大型网站架构的Java中间件系统的设计和实践.希望读者通过本书可以了解大型网站架构变迁过程中的较为通用的问题和解法,并了解构建支撑大型网站的Java中间件的实践经验. 对

  • java学生信息管理系统MVC架构详解

    本文实例为大家分享了java学生信息管理系统MVC架构,供大家参考,具体内容如下 一.项目结构 学生信息管理系统分三层进行实现.student.java主要提供数据,cotroller.java的功能是绑定试图和计算数据.Stuview.java用于单一的用来显示数据. 二.源码 1.1.Student 类 /* * @FileName: Student.class * @version:1.0 * @author:nazi * 描述:模型层 * */ import java.io.Serial

  • bs架构和cs架构的区别_动力节点Java学院整理

    1.CS.BS架构定义 CS(Client/Server):客户端----服务器结构.C/S结构在技术上很成熟,它的主要特点是交互性强.具有安全的存取模式.网络通信量低.响应速度快.利于处理大量数据.因为客户端要负责绝大多数的业务逻辑和UI展示,又称为胖客户端.它充分利用两端硬件,将任务分配到Client 和Server两端,降低了系统的通讯开销.C/S结构的软件需要针对不同的操作系统系统开发不同版本的软件,加之产品的更新换代十分快,已经很难适应百台电脑以上局域网用户同时使用. C/S 架构是一

  • 浅谈架构模式变迁之从分层架构到微服务架构

    前言 谈到软件系统设计的方法论,在代码层面,有我们熟悉的23种设计模式(design pattern),对应到架构层面,则有所谓的架构模式(architecture pattern).它们分别从微观和宏观的角度指导着我们设计出良好的软件系统,因此,作为一个软件工程师,我们不仅要熟悉设计模式,对常见的架构模式也要熟稔于心.正如看到一个设计模式的名字脑里就能浮现出大致的结构图,当我们看到一个架构模式的名字时,也要马上想到对应的架构图及其基本特点.比如,当谈到分层架构时,我们就应该想起它的架构图是怎样

  • 了解java架构之微服务架构—雪崩效应

    前言 微服务化产品线,每一个服务专心于自己的业务逻辑,并对外提供相应的接口,看上去似乎很明了,其实还有很多的东西需要考虑,比如:服务的自动扩充,熔断和限流等,随着业务的扩展,服务的数量也会随之增多,逻辑会更加复杂,一个服务的某个逻辑需要依赖多个其他服务才能完成. 一但一个依赖不能提供服务很可能会产生雪崩效应,最后导致整个服务不可访问. 微服务之间进行rpc或者http调用时,我们一般都会设置调用超时,失败重试等机制来确保服务的成功执行,看上去很美,如果不考虑服务的熔断和限流,就是雪崩的源头. 假

  • 解析SpringCloud简介与微服务架构

    1. 微服务架构 1.1 微服务架构理解 微服务架构(Microservice Architecture)是一种架构概念,旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦.你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则.微服务架构是个很有趣的概念,它的主要作用是将功能分解到离散的各个服务当中,从而降低系统的耦合性,并提供更加灵活的服务支持. 概念:把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务,它可扩展单个组件而不是整个的应用程序堆栈,从而满足服务等

  • 详解Java 微服务架构

    一.传统的整体式架构 传统的整体式架构都是模块化的设计逻辑,如展示(Views).应用程序逻辑(Controller).业务逻辑(Service)和数据访问对象(Dao),程序在编写完成后被打包部署为一个具体的应用.如图所示: 系统的水平扩展 如果要对系统进行水平扩展,通常情况下,只需要增加服务器的数量,并将打包好的应用拷贝到不同的服务器,然后通过负载均衡器(Nginx)就可以轻松实现应用的水平扩展. 整体式架构的缺点 应用复杂度增加,更新.维护困难. 易造成系统资源浪费. 影响开发效率. 应用

  • Java中dubbo+zookeeper微服务架构简介

    目录 1.Apache Dubbo概述 1.1.Dubbo简介 1.2.Dubbo的服务架构 2.服务注册中心 Zookeeper 2.1.ZooKeeper介绍 2.2.ZooKeeper安装 2.3.启动 ZooKeeper 3.ZooKeeper快速入门 3.1.服务提供方 3.2.服务消费方 3.3.问题思考 4. Dubbo管理控制台 4.1.安装 5. Dubbo相关配置 5.1.包扫描 5.2.Dubbo 协议 5.3.负载均衡 5.4. Dubbo无法发布被事务代理的服务 1.A

  • 微服务架构之服务注册与发现实践示例详解

    目录 1 服务注册中心 4种注册中心技术对比 2 Spring Cloud 框架下实现 2.1 Spring Cloud Eureka 2.1.1 创建注册中心 2.1.2 创建客户端 2.2 Spring Cloud Consul 2.2.1 Consul 的优势 2.2.2 Consul的特性 2.2.3 安装Consul注册中心 2.2.4 创建服务提供者 3 总结 微服务系列前篇 详解微服务架构及其演进史 微服务全景架构全面瓦解 微服务架构拆分策略详解 微服务架构之服务注册与发现功能详解

  • 浅谈SpringCloud实现简单的微服务架构

    Spring Cloud是一系列框架的有序集合.它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册.配置中心.消息总线.负载均衡.断路器.数据监控等,都可以用Spring Boot的开发风格做到一键启动和部署.Spring并没有重复制造轮子,它只是将目前各家公司开发的比较成熟.经得起实际考验的服务框架组合起来,通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理,最终给开发者留出了一套简单易懂.易部署和易维护的分布式系统开发工具包. 接下

  • Spring Cloud微服务架构的构建:分布式配置中心(加密解密功能)

    前言 要会用,首先要了解.图懒得画,借鉴网上大牛的图吧,springcloud组建架构如图: 微服务架构的应用场景: 1.系统拆分,多个子系统 2.每个子系统可部署多个应用,应用之间负载均衡实现 3.需要一个服务注册中心,所有的服务都在注册中心注册,负载均衡也是通过在注册中心注册的服务来使用一定策略来实现. 4.所有的客户端都通过同一个网关地址访问后台的服务,通过路由配置,网关来判断一个URL请求由哪个服务处理.请求转发到服务上的时候也使用负载均衡. 5.服务之间有时候也需要相互访问.例如有一个

  • 漫谈架构之微服务

    目录 一.简介 二.微服务和单体服务 三.微服务的特征 3.1.组件服务化 3.2.组织的划分 3.3.服务之间的通信 3.4.去中心化治理 3.5.去中心化数据管理 3.6.自动化部署 3.7.对异常的响应 四.总结 一.简介 服务的划分是根据具体的业务来的,并且可以通过完全自动化的部署机制独立部署.虽然大家都在谈论微服务,但是什么时候应该使用微服务,使用微服务需要注意哪些问题对于很多人来说仍然是一个模糊的概念.本文将会和大家一起探讨一下微服务相关的一些问题. 二.微服务和单体服务 在最开始的

  • 微服务架构设计RocketMQ基础及环境整合

    目录 概述&选型 单机安装配置 双机主从高可用搭建 启动多个NameServer 和 Broker 重要参数说明 可视化管理平台 SpringBoot整合RocketMQ 引入组件rocketmq-spring-boot-starter 依赖 修改application.yml,添加RocketMQ相关配置 编写消息生产者 MessageProduce 编写消息消费者 MessageConsumer 编写单元测试发送消息 测试 概述&选型 消息队列作为高并发系统的核心组件之一,能够帮助业务

随机推荐