Spring Cloud构建微服务架构:Hystrix监控面板【Dalston版】

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 在上一篇《服务容错保护(hystrix断路器)》的介绍中,我们提到断路器是根据一段时间窗内的请求情况来判断并操作断路器的打开和关闭状态的。而这些请求情况的指标信息都是HystrixCommand和HystrixObservableCommand实例在执行过程中记录的重要度量信息,它们除了Hystrix断路器实现中使用之外,对于系统运维也有非常大的帮助。

在上一篇《服务容错保护(hystrix断路器)》的介绍中,我们提到断路器是根据一段时间窗内的请求情况来判断并操作断路器的打开和关闭状态的。而这些请求情况的指标信息都是HystrixCommand和HystrixObservableCommand实例在执行过程中记录的重要度量信息,它们除了Hystrix断路器实现中使用之外,对于系统运维也有非常大的帮助。这些指标信息会以“滚动时间窗”与“桶”结合的方式进行汇总,并在内存中驻留一段时间,以供内部或外部进行查询使用,Hystrix Dashboard就是这些指标内容的消费者之一。

下面我们基于之前的示例来结合Hystrix Dashboard实现Hystrix指标数据的可视化面板,这里我们将用到下之前实现的几个应用,包括:

  • eureka-server:服务注册中心
  • eureka-client:服务提供者
  • eureka-consumer-ribbon-hystrix:使用ribbon和hystrix实现的服务消费者

由于eureka-consumer-ribbon-hystrix项目中的/consumer接口实现使用了@HystrixCommand修饰,所以这个接口的调用情况会被Hystrix记录下来,以用来给断路器和Hystrix Dashboard使用。断路器我们在上一篇中已经介绍过了,下面我们来具体说说Hystrix Dashboard的构建。

动手试一试

在Spring Cloud中构建一个Hystrix Dashboard非常简单,只需要下面四步:

  • 创建一个标准的Spring Boot工程,命名为:hystrix-dashboard。
  • 编辑pom.xml,具体依赖内容如下:
<parent>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-parent</artifactId>
    <version>Dalston.SR1</version>
    <relativePath />
</parent>
<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-hystrix</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-hystrix-dashboard</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>
</dependencies>
  • 为应用主类加上@EnableHystrixDashboard,启用Hystrix Dashboard功能。
@EnableHystrixDashboard
@SpringCloudApplication
public class HystrixDashboardApplication {
    public static void main(String[] args) {
        SpringApplication.run(HystrixDashboardApplication.class, args);
    }
}
  • 根据实际情况修改application.properties配置文件,比如:选择一个未被占用的端口等,此步非必须。
spring.application.name=hystrix-dashboard
server.port=1301

到这里我们已经完成了基本配置,接下来我们可以启动该应用,并访问:http://localhost:1301/hystrix,我们可以看到如下页面:

这是Hystrix Dashboard的监控首页,该页面中并没有具体的监控信息。从页面的文字内容中我们可以知道,Hystrix Dashboard共支持三种不同的监控方式,依次为:

  • 默认的集群监控:通过URLhttp://turbine-hostname:port/turbine.stream开启,实现对默认集群的监控。
  • 指定的集群监控:通过URLhttp://turbine-hostname:port/turbine.stream?cluster=[clusterName]开启,实现对clusterName集群的监控。
  • 单体应用的监控:通过URLhttp://hystrix-app:port/hystrix.stream开启,实现对具体某个服务实例的监控。

前两者都对集群的监控,需要整合Turbine才能实现,这部分内容我们将在下一篇中做详细介绍。在本节中,我们主要实现对单个服务实例的监控,所以这里我们先来实现单个服务实例的监控。

既然Hystrix Dashboard监控单实例节点需要通过访问实例的/hystrix.stream接口来实现,自然我们需要为服务实例添加这个端点,而添加该功能的步骤也同样简单,只需要下面两步:

  • 在服务实例pom.xml中的dependencies节点中新增spring-boot-starter-actuator监控模块以开启监控相关的端点,并确保已经引入断路器的依赖spring-cloud-starter-hystrix
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
  • 确保在服务实例的主类中已经使用@EnableCircuitBreaker@EnableHystrix注解,开启了断路器功能。

到这里已经完成了所有的配置,我们可以在Hystrix Dashboard的首页输入http://localhost:2101/hystrix.stream,已启动对“eureka-consumer-ribbon-hystrix”的监控,点击“Monitor Stream”按钮,此时我们可以看到如下页面:

在对该页面介绍前,我们先看看在首页中我们还没有介绍的两外两个参数:

  • Delay:该参数用来控制服务器上轮询监控信息的延迟时间,默认为2000毫秒,我们可以通过配置该属性来降低客户端的网络和CPU消耗。
  • Title:该参数对应了上图头部标题Hystrix Stream之后的内容,默认会使用具体监控实例的URL,我们可以通过配置该信息来展示更合适的标题。

回到监控页面,我们来详细说说其中各元素的具体含义:

  • 我们可以在监控信息的左上部分找到两个重要的图形信息:一个实心圆和一条曲线。
    • 实心圆:共有两种含义。它通过颜色的变化代表了实例的健康程度,如下图所示,它的健康度从绿色、黄色、橙色、红色递减。该实心圆除了颜色的变化之外,它的大小也会根据实例的请求流量发生变化,流量越大该实心圆就越大。所以通过该实心圆的展示,我们就可以在大量的实例中快速的发现故障实例和高压力实例。


    • 曲线:用来记录2分钟内流量的相对变化,我们可以通过它来观察到流量的上升和下降趋势。
  • 其他一些数量指标如下图所示:


更多Spring Cloud内容请持续关注我的博客更新或在《Spring Cloud微服务实战》中获取。

代码示例

样例工程将沿用之前在码云和GitHub上创建的SpringCloud-Learning项目,重新做了一下整理。通过不同目录来区分Brixton和Dalston的示例。

相关阅读

目录
相关文章
|
1天前
|
监控 负载均衡 持续交付
构建高效微服务架构:后端开发的新趋势
【5月更文挑战第5天】在数字化转型的浪潮中,微服务架构以其灵活性、可扩展性和容错性成为企业追求的技术典范。本文深入探讨了微服务的核心组件、设计原则和实施策略,旨在为后端开发者提供构建和维护高效微服务系统的实用指南。通过分析微服务的最佳实践和常见陷阱,我们揭示了如何优化系统性能、保证服务的高可用性以及如何处理分布式系统中的复杂性。
|
1天前
|
缓存 NoSQL Java
构建高性能微服务架构:Java后端的实践之路
【5月更文挑战第5天】在当今快速迭代和高并发需求的软件开发领域,微服务架构因其灵活性、可扩展性而受到青睐。本文将深入探讨如何在Java后端环境中构建一个高性能的微服务系统,涵盖关键的设计原则、常用的框架选择以及性能优化技巧。我们将重点讨论如何通过合理的服务划分、高效的数据存储策略、智能的缓存机制以及有效的负载均衡技术来提升整体系统的响应速度和处理能力。
|
1天前
|
监控 持续交付 数据库
构建高效可靠的微服务架构:策略与实践
【5月更文挑战第5天】 在当今快速发展的软件开发领域,微服务架构已成为构建可扩展、灵活且容错的系统的首选模式。本文将探讨如何通过一系列经过验证的策略和最佳实践来构建一个高效且可靠的微服务系统。我们将深入分析微服务设计的核心原则,包括服务的细粒度划分、通信机制、数据一致性以及容错处理,并讨论如何利用现代技术栈来实现这些目标。文章将提供一套综合指南,旨在帮助开发者和架构师在保证系统性能的同时,确保系统的稳健性。
17 4
|
1天前
|
负载均衡 Java 数据库
构建高效微服务架构:后端开发的新趋势
【5月更文挑战第5天】在现代软件开发中,微服务架构已经成为一种流行的设计模式。它通过将大型应用程序分解为一组小型、松散耦合的服务来提高可维护性、可扩展性和敏捷性。本文将探讨如何构建高效的微服务架构,包括选择合适的技术栈、设计良好的服务接口、确保数据一致性以及实现高可用性和负载均衡。
|
2天前
|
Kubernetes 监控 Docker
构建高效微服务架构:Docker与Kubernetes的完美搭档
【5月更文挑战第4天】在现代软件开发中,微服务架构已成为实现可扩展、灵活且独立部署服务的流行解决方案。本文将探讨如何利用Docker容器化技术和Kubernetes容器编排平台来构建一个高效的微服务系统。我们将分析Docker和Kubernetes的核心优势,并指导读者如何通过这些工具优化微服务部署、管理和扩展过程。文章还将涉及监控和日志管理策略,以确保系统的健壮性和可靠性。
|
2天前
|
监控 Java 持续交付
构建高效微服务架构:后端开发者的终极指南
【5月更文挑战第4天】在当今快速迭代和竞争激烈的软件市场中,微服务架构已成为企业追求敏捷性、可扩展性和技术多样性的关键策略。本文深入探讨了如何构建和维护高效的微服务系统,从基本概念到高级实践,为后端开发者提供一套综合指南,以支持他们在这一变革性架构风格中扮演关键角色。
|
2天前
|
负载均衡 API 数据库
构建高效微服务架构的五大关键技术
【5月更文挑战第4天】 随着云计算和容器化技术的成熟,微服务架构已成为软件开发的主流模式。本文将详细探讨实现高效微服务架构的五个关键技术点:服务拆分策略、API网关设计、服务发现与注册、熔断机制以及分布式事务管理。这些技术点是确保微服务系统可扩展性、灵活性及稳定性的基石,对于后端开发者而言,掌握它们至关重要。文章将提供具体的实施建议和最佳实践,帮助读者构建和维护高性能的微服务系统。
|
3天前
|
JavaScript Java 持续交付
构建高效微服务架构:后端开发的新范式
【5月更文挑战第3天】 在现代软件开发的浪潮中,微服务架构以其灵活性、可扩展性和技术多样性而受到重视。本文深入探讨了如何构建一个高效的微服务系统,包括关键的设计原则、技术选型、以及实现细节。我们将通过分析微服务的核心概念,提供一套实用的步骤和最佳实践,以指导开发者构建出既健壮又易于维护的分布式系统。文章将重点讨论如何在保证系统性能和稳定性的前提下,实现服务的解耦与独立部署,从而推动后端开发工作流的优化和创新。
|
3天前
|
安全 数据管理 持续交付
构建高效微服务架构的五大核心策略
【5月更文挑战第3天】在当前软件开发领域,微服务架构已成为一种流行的设计模式,它通过将应用程序拆分成一组小型、松耦合的服务来提高系统的可维护性和扩展性。本文将详细探讨构建高效微服务架构的五大核心策略,包括服务划分原则、通信机制设计、数据管理、安全性考虑以及持续集成与部署。这些策略不仅有助于确保系统的高可用性和灵活性,同时也支持快速迭代和部署,是实现现代云原生应用的基石。
|
4天前
|
Kubernetes API 开发者
构建高效微服务架构:后端开发的新范式
【5月更文挑战第2天】 随着现代软件开发的演进,传统的单体应用已难以满足快速变化的业务需求和敏捷开发的挑战。本文探讨了如何通过构建高效的微服务架构来提升后端开发的灵活性、可维护性和扩展性。我们将深入分析微服务的核心组件,包括服务拆分、容器化、API网关和持续集成/持续部署(CI/CD)等关键技术,并讨论它们如何共同作用以支持复杂的业务场景和云原生应用的需求。
15 1