hystrix

Spring Cloud整体核心架构只有一点：Rest服务，也就是说在整个Spring Cloud配置过程之中，所有的配置处理都是围绕着Rest完成的，在这个Rest处理之中，一定要有两个端：服务的提供者（Provider）、服务的消费者（Consumer），所以对于整个Spring Cloud基础的结构就如下所示。 SpringCloud基础架构 既然Spring Cloud的核心是Restful结构，那么如果要想更好的去使用Rest这些微服务还需要考虑如下几个问题。 1、所有的微服务地址一定会非常的多，所以为了统一管理这些地址信息，也为了可以及时的告诉用户哪些服务不可用，所以应该准备一个分布式的注册中心，并且该注册中心应该支持有HA机制，为了高速并且方便进行所有服务的注册操作，在Spring Cloud里面提供有一个Eureka的注册中心。 微服务结构图 2、对于整个的WEB端的构架（SpringBoot实现）可以轻松方便的进行WEB程序的编写，而后利用Nginx或Apache实现负载均衡处理，但是你WEB端出现了负载均衡，那么业务端呢？应该也提供有多个业务端进行负载均衡。那么这个时候就需要将所有需要参与到负载均衡的业务端在Eureka之中进行注册。 多业务端-负载均衡 在进行客户端使用Rest架构调用的时候，往往都需要一个调用地址，即使现在使用了Eureka作为注册中心

都 2020 年了 还没用过 微服务 吗？ 面试的时候高并发回答的总是不能让面试官满意？ 一个互联网项目究竟有多少细节？ 网上搜了一堆秒杀系统方案，究竟真实的线上电商该怎么做？ 那么你缺乏这两个字 实 战 消除痛点、解决面试、积累实战经验 欢迎你参加马士兵教育 微服务与高并发 训练营 本号粉丝： 免 费 两天你将学到 快速 · 上手微服务，了解各个组件的作用 极简 · 从点到面，内容绝不拖泥带水 实战 · 构建微服务项目 架构 · 高并发系统中组件解析与选型 健壮 · 互联网项目常用中间件服务 做到 · 从传统项目转向微服务互联网系统架构 吊打 · 面试官，独家解析淘宝网秒杀系统需求 马士兵是谁？ 马士兵 马士兵老师，清华大学， 推动Java生根中国 ， 推动大数据生根中国 ， 推动AI生根中国 ，视频课程下载次数累计数 27000万次 。 训练营时间： 7月29日-7月30日，20:00 开营前：发放预习的基础资料 长按扫码，领预习资料，入群学习 遇到扫码频繁，请再次识别 福利较大，限前200人 第一天：快速上手SpringCloud微服务系统架构+常用中间件服务 SOA、Webservice、Dubbo、SpringCloud究竟什么是微服务？ 单体应用向微服务异构平台架构演变 SpringCloud微服务组件生态体系 从零开始构建微服务项目各组件应用场景及代码实现

一、FeignClient注解 FeignClient注解被@Target(ElementType.TYPE)修饰，表示FeignClient注解的作用目标在 接口上 1 2 3 4 5 @FeignClient(name = "github-client" , url = "https://api.github.com" , configuration = GitHubExampleConfig. class ) public interface GitHubClient { @RequestMapping(value = "/search/repositories" , method = RequestMethod.GET) String searchRepo(@RequestParam( "q" ) String queryStr); } 　声明接口之后，在代码中通过@Resource注入之后即可使用。@FeignClient标签的常用属性如下： name：指定FeignClient的名称，如果项目使用了Ribbon，name属性会作为微服务的名称，用于服务发现 url: url一般用于调试，可以手动指定@FeignClient调用的地址 decode404:当发生http 404错误时，如果该字段位true，会调用decoder进行解码，否则抛出FeignException

目录 前言 一、常用指标 响应时间 并发数 QPS TPS 二、夺命三高 高并发 高性能 高可用 三、常见招式 分流 缓存 队列 CDN 池化 扩容 熔断 限流 降级 分层 部署分级 日志监控 查询优化 读写分离 分库分表 前言 冰冻三尺非一日之寒，葵花宝典也不是一天写出来的，系统设计也如此，好的架构是不断演进的。 一般来说能用单块架构解决的问题，尽量不要采用分布式。 分布式虽然可以提高系统的响应能力，也带来了更高的复杂性，如果团队技术人员水平hold不住的话，反而会产生更多问题，例如问题难以定位、系统性能下降、某种业务实现困难或无法实现等问题。 以下内容由伟大的诗人chenqionghe整理，light weight baby~ 一、常用指标 响应时间 直观反应系统快慢，一般控制在200ms以内，超过1s用户已经能感觉到慢了 并发数 同时处理请求的数目 QPS 每秒查询请求数 TPS 每秒执行事务数，着重反应写 二、夺命三高 没错，就是高血压、高血糖和高血脂，开玩笑啦~ 高并发 通过设计让系统能接收更多的用户并发请求，承担更大的流量。 一般考查并发数、QPS和TPS。 示例：庐山百龙霸，并发百龙 高性能 一般指服务响应时间快 用户视角。APP、浏览器上能直观感受快 开发视角。响应延迟低，系统吞吐量大，并发处理能力强 运维视角。基础设施配置高，CPU多核心，内存容量大 示例

1 背景 像我们去面试一些大公司的时候，就会遇到一些关于缓存的问题。可能很多同学都是接触过，多多少少了解一些，但是如果没有好好记录这些内容，不熟练精通的话，在真正面试的时候，就很难答出来了。 在我们的平常的项目中多多少少都会使用到缓存，因为一些数据我们没有必要每次查询的时候都去查询到数据库。 特别是高 QPS 的系统，每次都去查询数据库，对于你的数据库来说将是灾难。 今天我们不牵涉多级缓存的知识，就把系统使用到的缓存方案，不管是一级还是多级的都统称为缓存，主要是为了讲述使用缓存的时候可能会遇到的一些问题以及一些解决办法。 我们使用缓存时，我们的业务系统大概的调用流程如下图： 当我们查询一条数据时，先去查询缓存，如果缓存有就直接返回，如果没有就去查询数据库，然后返回。这种情况下就可能会出现一些现象。 2 缓存穿透 2.1 什么是缓存穿透 正常情况下，我们去查询数据都是存在。 那么请求去查询一条压根儿数据库中根本就不存在的数据，也就是缓存和数据库都查询不到这条数据，但是请求每次都会打到数据库上面去。 这种查询不存在数据的现象我们称为 缓存穿透 。 2.2 穿透带来的问题 试想一下，如果有黑客会对你的系统进行攻击，拿一个不存在的id 去查询数据，会产生大量的请求到数据库去查询。可能会导致你的数据库由于压力过大而宕掉。 2.3 解决办法 2.3.1 缓存空值 之所以会发生穿透

问题一、请求 /hystrix.stream 报错，我这里以端口9001为例 　　请求 http://localhost:9001/hystrix.stream 报404 　　 　 　是因为Srping Boot 2.0以后仪表盘的默认路径不在是 /hystrix.stream，这时就需要我们自己去设置，在主类中添加以下代码： 　　@Bean public ServletRegistrationBean getServlet() { HystrixMetricsStreamServlet streamServlet = new HystrixMetricsStreamServlet(); ServletRegistrationBean registrationBean = new ServletRegistrationBean(streamServlet); registrationBean.setLoadOnStartup( 1 ); registrationBean.addUrlMappings( "/hystrix.stream" ); registrationBean.setName( "HystrixMetricsStreamServlet" ); return registrationBean; } 　　 重启项目，访问 http://localhost:9001

本文源码： GitHub·点这里 || GitEE·点这里 一、流量控制 1、基本概念 流量控制的核心作用是限制流出某一网络的某一连接的流量与突发，使这类报文以比较均匀的速度流动发送，达到保护系统相对稳定的目的。通常是将请求放入缓冲区或队列内，然后基于特定策略处理请求，匀速或者批量处理，该过程也称流量整形。 流量控制的核心算法有以下两种：漏桶算法和令牌桶算法。 2、漏桶算法 基础描述 漏桶算法是流量整形或速率限制时经常使用的一种算法，它的主要目的是控制数据注入到网络的速率，平滑网络上的突发流量。漏桶算法提供了一种机制，通过它，突发流量可以被整形以便为网络提供一个稳定的流量。 漏桶算法基本思路：请求（水流）先进入到容器（漏桶）里，漏桶以一定的速度出水，这里就是指流量流出的策略，当流量流入速度过大容器无法承接就会直接溢出，通过该过程限制数据的传输速率。 核心要素 通过上述流程，不难发现漏桶算法涉及下面几个要素： 容器容量 容器的大小直接决定能承接流量的多少，容器一但接近饱和，要么溢出，要么加快流速； 流出速度 流量流出的速度取决于服务的请求处理能力，接口支撑的并发越高，流速就可以越大； 时间控制 基于时间记录，判断流量流出速度，控制匀速模式， 注意：需要一个基本的判定策略，漏桶算法在系统能承接当前并发流量时，不需要启用。 3、令牌桶算法 基础描述

Spring Cloud 是一个基于 Spring Boot 实现的微服务框架，它包含了实现微服务架构所需的各种组件。 注：Spring Boot 简单理解就是简化 Spring 项目的搭建、配置、组合的框架。因为与构建微服务本身没有直接关系，所以本文不对 Spring Boot 进行展开。 另外本文有一些例子涉及到 Spring 和 Spring Boot，建议先了解一下 Spring 和 Spring Boot 再阅读本文。 本文的阅读对象主要是没有接触过服务架构，想对其有一个宏观的了解的同学。 本文将从 Spring Cloud 出发，分两小节讲述微服务框架的「五脏六腑」： 第一小节「服务架构」旨在说明的包括两点，一服务架构是什么及其必要性；二是服务架构的基本组成。为什么第一节写服务架构而不是微服务架构呢？原因主要是微服务架构本身与服务架构有着千丝万缕的关系，服务架构是微服务架构的根基。 第二小节「五脏六腑」则将结合 Spring Cloud 这个特例来介绍一个完整的微服务框架的组成。 「服务架构」 为了方便理解，我先讲一个小故事：（改编自一知乎答主） Martin（微服务提出者也叫 Martin）刚来到公司时是一个基层员工，它上面有经理、老板，那个时候所有人都听老板的指挥。 但是过了两年，公司的人越来越多，原来的模式下整个公司的运作效率太低，管理也很混乱。

Resilience4j是一个轻量级、易于使用的容错库，其灵感来自Netflix Hystrix，但专为Java 8和函数式编程设计。轻量级，因为库只使用Vavr，它没有任何其他外部库依赖项。相比之下，Netflix Hystrix对Archaius有一个编译依赖关系，Archaius有更多的外部库依赖关系，如Guava和Apache Commons。 Resilience4j提供高阶函数（decorators）来增强任何功能接口、lambda表达式或方法引用，包括断路器、速率限制器、重试或舱壁。可以在任何函数接口、lambda表达式或方法引用上使用多个装饰器。优点是您可以选择所需的装饰器，而无需其他任何东西。 有了Resilience4j，你不必全力以赴，你可以选择你需要的。 https://resilience4j.readme.io/docs/getting-started 概览 Resilience4j提供了两种舱壁模式 （Bulkhead） ，可用于限制并发执行的次数： SemaphoreBulkhead（信号量舱壁，默认），基于Java并发库中的Semaphore实现。 FixedThreadPoolBulkhead（固定线程池舱壁），它使用一个有界队列和一个固定线程池。 本文将演示在Spring Boot2中集成Resilience4j库

什么是网关 在微服务架构里，服务的粒度被进一步细分，各个业务服务可以被独立的设计、开发、测试、部署和管理。这时，各个独立部署单元可以用不同的开发测试团队维护，可以使用不同的编程语言和技术平台进行设计，这就要求必须使用一种语言和平台无关的服务协议作为各个单元间的通讯方式。 换句话说就是网关为所有的请求提供了统一的入口，方便我们对服务请求和响应做统一管理。 为什么要用网关 API 网关是一个处于应用程序或服务（提供 REST API 接口服务）之前的系统，用来管理授权、访问控制和流量限制等，这样 REST API 接口服务就被 API 网关保护起来，对所有的调用者透明。 什么是gateway Spring Cloud Gateway是Spring官方基于Spring 5.0，Spring Boot 2.0和Project Reactor等技术开发的网关，Spring Cloud Gateway旨在为微服务架构提供一种简单而有效的统一的API路由管理方式。Spring Cloud Gateway作为Spring Cloud生态系中的网关，目标是替代ZUUL，其不仅提供统一的路由方式，并且基于Filter链的方式提供了网关基本的功能，例如：安全，监控/埋点，和限流等。 gateway工作原理 客户端向Spring Cloud网关发出请求。如果网关处理程序映射确定请求与路由匹配