2.6 Spring Cloud 微服务 API 的监控 Hystrix| 学习笔记

本文涉及的产品
注册配置 MSE Nacos/ZooKeeper,118元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
云原生网关 MSE Higress,422元/月
简介: 快速学习 2.6 Spring Cloud 微服务 API 的监控 Hystrix

开发者学堂课程【Spring Cloud 微服务架构设计与开发实战 2.6 Spring Cloud 微服务API 的监控 Hystrix】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址:https://developer.aliyun.com/learning/course/60/detail/1089


2.6 Spring Cloud 微服务 API 的监控 Hystrix

 

内容介绍

一、Spring Cloud 微服务监控

二、Spring Cloud 微服务 Hystrix 监控面板

 

下面来讲微服务架构的限流,提到的 Hystrix 也是 Netflix 提供的,之前提过Netflix Spring Cloud 微服务架构最早期核心的贡献公司,提供了许多重要的组件,Hystrix 就是其中之一。

 

一、Spring Cloud 微服务监控

1、Netflix Hystrix

(1)Netflix 发布了 Hystrix 熔断器框架,保护系统

(2)通过控制那些访问远程系统、服务和第三方库的节点

(3)从而对延迟和故障提供更强大的容错能力

4Fallback 灾备操作,出错以后返回的值

(5)Hystrix 中, 主要通过线程池来实现资源隔离

(6)Hystrix 的信号模式(Semaphores)来隔离资源

(7)Hystrix 支持 dashboard 控制面板监控信息

(8)Feign 可以和 Hystrix 结合使用,也可以独立使用

(9)Hystrix 使用了命令模式,对命令对象抽象了两个抽象: HystrixCommand 和 HystrixObservableCommand

Hystrix 本意指的是豪猪,之前在微服务架构已经演示过在生产环境下有知识高并发,可能有成百上千的实例,但也有可能有十台服务器支持的并发是一万,但是双十一支持的并发瞬间达到了十万,这时就有一个问题,那就是这个系统是直接崩溃还是做限流,还是一定程度上做一些措施去限制一部分流量,服务器中留一部分流量。现在的淘宝双十一已经做得很好了,基本不限流,还能过滤掉一些微请求和低攻击,但对于大部分公司来说服务器规模达不到这样的程度,这个时候就要保证系统的高可用,不让系统过载出现大面积崩溃,可以适当的接入部分请求服务部分请求,这样的话整个系统还是可用的,当瞬间流量过载的时候可用消除部分的峰值请求,相当于用了隔离的策略,实行隔离工作,但是 Java 本身没有像 Hystrix 倒班的概念,实际上他的隔离是通过线程池进行隔离的,为了避免某个服务调度出错引发整个系统崩溃的问题,这里面也出现了 dashboard 监控面板,可以监控服务的调度数据,当然 Hystrix 可以部署在服务端,也可以部署在调用端,一般是放在调用端,尤其是放在代理服务器上,网关服务器调度所有的服务,所以可以统一看到流量的监控信息,也可以针对某一个服务执行熔断策略。还有底层一个面试题需要注意,Hystrix 是设计模式里面经典的 Command  模式的应用,也就是命令模式,其中封装了各种不同的操作来做解耦工作。

2、断路器模式

如下图整个熔断工具 Hystrix 一般是放在服务调度中,因为服务调度端的话会调用多个服务,对于做限流是比较方便的,就是说常见的限流和高速公转的限流一定是在闸机口,在流量的入口,在全部流量经过的地方进行限流才有意义。

image.png

 

二、Spring Cloud 微服务 Hystrix 监控面板

Spring Cloud 监控面板在后面进行实战练习,它提供了 Hystrix dashboard 和还要再加上两个引用。下面做练习,看下具体的实战项目。为了简化方便就在之前Feign的基础上做实训。

1、Hystrix 监控面板实训

第一步加上两个引用依赖,然后保存进行拉包,这里面有 Hystrix,还有 dashboard,当然 dashboard 可以单独做一个独立的项目,做一个监控面板的程序,而 Hystrix 是用做采集,所以这两个引用可以分开,就是搭建包的时候有单独的项目,监控数据源是一个项目,还有一个重要的是 actuator,这个依赖是 Spring Cloud2.2 提供的叫数据采集的一个组件,而且不能没有,因为 actuator 要暴露一些核心的数据,以上操作改完后还要加上两个很重要的注解,@EnableHystrix 和 @EnableHystrixDashboard,@EnableHystrixDashboard 为启用监控面板,要把监控面板剥离成独立的也是可以的,@EnableHystri 为启用监控,代码如下:

@EnableHystrix

@EnableHystrixDashboard

<dependency>

<groupId>org. springframework. cloud</ groupId>

<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>

</dependency>

<dependency>

<groupId>org. springframework. cloud</ groupId>

<artifactId>spring-cloud- starter- netflix- hystrix- dashboard</artifactId>

</dependency>

<dependency>

<groupId>org. springframework. boot</ groupId>

<artifactId>spring- boot -starter- actuator</artifactId>

</dependency>

然后还要改配置文件,在文件中要暴露监控数据源地址,只有暴露数据才能进行采集,否则采不到,而现在 Spring Cloud 版本之间有默认的安全差异,很多规则都改掉了,所以要通过 management.endpoints.web.exposure.include 得到监控地址,其次还要改9002的测试端口,然后启动9002的端口,application 代码为:

server.port=9002

#暴露监控数据源地址

management.endpoints.web.exposure.include=*

运行后可以发现并没有很大的变动9002,只是加上了注解和三个依赖包,然后再访问 localhost:9002/hystrix,会进入监控面板的入口界面,入口界面是有点像豪猪的一个 logo,需要给出监控地址才能采集监控数据,输入采集地址为http://localhost:9002/actutor/hystrix.stream,如下图:

image.png 

2、进一步优化

这时候会出现一个错误,这个错误在以后做监控的时候也一定会遇到,错误为无法连接到监控数据流,是因为默认在2.2级以后版本又更改了,不允许直接去连接,而且本身这种数据也属于安全数据,那要进行连接就要在配置里面允许本地服务器进行调用,并且这里面采集面板和代理服务器还有一个依赖关系,如果不这样的话,这个错误会一直出现,看不见采集数据的,增加代码为:

#允许展示监控服务器

hystrix.dashboard.proxy-stream-al1ow-list=localhost,192.168.1.101

暴露的协议也是可以改的,默认的使用 web 也就是 http协议,以及 REST 协议,再次回到浏览器运行则页面加载为 Loading,然后就要主动触发调用9002新的微服务程序,触发后才有数据源,等待一会后正常的话会出现触发的数据,不正常的话再打开 http://localhost:9002/actutor/hystrix.stream 会发现里面的数据流为空,是不会展示的,在练习中此处运行为不正常,所以回到代码中进行检查。

代码中.exposure.include=*,* 号表示所有,也可以代表健康信息,其他信息都可以拿来用,继续检查会发现代理服务器在想办法去监控数据量,此时浏览器再进行触发一次,页面就会显示数据,如图:
image.png

所以数据流要重新打开一次,此时监控界面就可以看到数据了,然后进行多次手动的测试调用,回到监控界面就会发现手动点击速度为1.2次每秒,如图:

image.png

以上则说明调度成功。通过监控面板可以看到上面的界面,这里面只做了一个 test 微服务,当然也可以做多个,多个的话体现的就比较明显,如下可以在案例中再加入 hi 的微服务调度,效果是一样的,调度两个的话就是按照两个策略来执行监控的,增加代码为:

@RequestMapping("/hi")

public String hi() {

return proxy .hi();

}

页面进行访问 localhost:9002/hi,调度 hi 后界面如下:

image.png

如果有多个服务的话监控页面看起来就更内容丰富,都是通过 OderProxy来进行调度,做这个练习需要注意注解,在配置文件中可做的参数,三个重要的依赖包,中间一旦出现错误就会导致连接不上数据流,没有数据的情况,如果正常的话数据流里面应该有监控日志,而且不断刷新默认应该是1秒左右或者500毫秒,以上这个策略就到处结束。下节课介绍熔断和限流怎么实现,而这里已经实现了数据采集,后面就知道其他的怎么做。

相关文章
|
24天前
|
Cloud Native API
微服务引擎 MSE 及云原生 API 网关 2024 年 9 月产品动态
微服务引擎 MSE 及云原生 API 网关 2024 年 9 月产品动态。
|
25天前
|
Java API 数据库
构建RESTful API已经成为现代Web开发的标准做法之一。Spring Boot框架因其简洁的配置、快速的启动特性及丰富的功能集而备受开发者青睐。
【10月更文挑战第11天】本文介绍如何使用Spring Boot构建在线图书管理系统的RESTful API。通过创建Spring Boot项目,定义`Book`实体类、`BookRepository`接口和`BookService`服务类,最后实现`BookController`控制器来处理HTTP请求,展示了从基础环境搭建到API测试的完整过程。
38 4
|
27天前
|
XML JSON API
ServiceStack:不仅仅是一个高性能Web API和微服务框架,更是一站式解决方案——深入解析其多协议支持及简便开发流程,带您体验前所未有的.NET开发效率革命
【10月更文挑战第9天】ServiceStack 是一个高性能的 Web API 和微服务框架,支持 JSON、XML、CSV 等多种数据格式。它简化了 .NET 应用的开发流程,提供了直观的 RESTful 服务构建方式。ServiceStack 支持高并发请求和复杂业务逻辑,安装简单,通过 NuGet 包管理器即可快速集成。示例代码展示了如何创建一个返回当前日期的简单服务,包括定义请求和响应 DTO、实现服务逻辑、配置路由和宿主。ServiceStack 还支持 WebSocket、SignalR 等实时通信协议,具备自动验证、自动过滤器等丰富功能,适合快速搭建高性能、可扩展的服务端应用。
86 3
|
5天前
|
监控 安全 应用服务中间件
微服务架构下的API网关设计策略与实践####
本文深入探讨了在微服务架构下,API网关作为系统统一入口点的设计策略、实现细节及其在实际应用中的最佳实践。不同于传统的摘要概述,本部分将直接以一段精简的代码示例作为引子,展示一个基于NGINX的简单API网关配置片段,随后引出文章的核心内容,旨在通过具体实例激发读者兴趣,快速理解API网关在微服务架构中的关键作用及实现方式。 ```nginx server { listen 80; server_name api.example.com; location / { proxy_pass http://backend_service:5000;
|
10天前
|
监控 测试技术 API
确保微服务的API版本控制策略能够适应不断变化的业务需求
确保微服务的API版本控制策略能够适应不断变化的业务需求
|
15天前
|
监控 测试技术 API
如何确保微服务的API版本控制策略能够适应不断变化的业务需求?
如何确保微服务的API版本控制策略能够适应不断变化的业务需求?
|
21天前
|
监控 负载均衡 API
Web、RESTful API 在微服务中有哪些作用?
在微服务架构中,Web 和 RESTful API 扮演着至关重要的角色。它们帮助实现服务之间的通信、数据交换和系统的可扩展性。
43 2
|
28天前
|
运维 Cloud Native 应用服务中间件
阿里云微服务引擎 MSE 及 云原生 API 网关 2024 年 09 月产品动态
阿里云微服务引擎 MSE 面向业界主流开源微服务项目, 提供注册配置中心和分布式协调(原生支持 Nacos/ZooKeeper/Eureka )、云原生网关(原生支持Higress/Nginx/Envoy,遵循Ingress标准)、微服务治理(原生支持 Spring Cloud/Dubbo/Sentinel,遵循 OpenSergo 服务治理规范)能力。API 网关 (API Gateway),提供 APl 托管服务,覆盖设计、开发、测试、发布、售卖、运维监测、安全管控、下线等 API 生命周期阶段。帮助您快速构建以 API 为核心的系统架构.满足新技术引入、系统集成、业务中台等诸多场景需要
|
1月前
|
监控 测试技术 API
如何确保微服务的API版本控制策略能够适应不断变化的业务需求?
如何确保微服务的API版本控制策略能够适应不断变化的业务需求?
|
17天前
|
缓存 监控 API
微服务架构下RESTful风格api实践中,我为何抛弃了路由参数 - 用简单设计来提速
本文探讨了 RESTful API 设计中的两种路径方案:动态路径和固定路径。动态路径通过路径参数实现资源的 CRUD 操作,而固定路径则通过查询参数和不同的 HTTP 方法实现相同功能。固定路径设计提高了安全性、路由匹配速度和 API 的可维护性,但也可能增加 URL 长度并降低表达灵活性。通过对比测试,固定路径在性能上表现更优,适合微服务架构下的 API 设计。
下一篇
无影云桌面