Spring Cloud(二十二):服务容错 Hystrix 框架核心原理
Netflix Github 官方文档:https://github.com/Netflix/Hystrix/wiki
在分布式环境中,系统所依赖的服务的稳定性存在不可控因素,不可避免地会存在失败。
Hystrix 通过隔离服务之间的访问点、阻止它们之间的级联故障并提供回退选项来做到这一点,所有这些都可以提高系统的整体弹性。
Netflix Github 官方文档:https://github.com/Netflix/Hystrix/wiki
在分布式环境中,系统所依赖的服务的稳定性存在不可控因素,不可避免地会存在失败。
Hystrix 通过隔离服务之间的访问点、阻止它们之间的级联故障并提供回退选项来做到这一点,所有这些都可以提高系统的整体弹性。
Spring Cloud Gateway 网关除了核心的路由判断表达式(predicate :有的译为谓词)和过滤器外,还有一些其它的设置,以便于可以更好的配置和应用 Gateway。
例如,元数据配置,超时处理,跨域处理,HTTPS 安全配置,监控/指标 收集,问题定位等。可以添加一些全局配置,可以收集健康数据,便于快速定位问题等等。
Spring Cloud Gateway 项目提供了一个基于 Spring 生态体系构建的 API 网关,包括:Spring 5,Spring Boot 2。
Spring Cloud Gateway 旨在提供一种简单而有效的方试将前端请求 URI 路由到后端服务的接口,它还提供了其它的附加实用的功能,例如:安全性,监控/指标,可伸缩性等。
即将开发的新平台在网关组件上选择了 Gateway,Spring 官方主推 Gateway。Zuul 1 虽然很成熟,但不再维护,Zuul 2 已闭源。
网关组件,不管是 Zuul 还是 Gateway,其核心技术脱离不了 代理请求 和 过滤器。本篇根据 Spring Cloud Gateway 官方文档对其功能,配置,应用进行详细描述。
Spring Cloud Stream 提供了 Rabbit 和 Kafka 的绑定器实现,但 Rabbit 与 Kafka 的实现结构并不完全相同,这两者与 Spring Cloud Stream 提供的绑定器实现的关联概念需要了解清楚。
Spring Cloud Stream Kafka Binder 参考指南,Spring Cloud Stream RabbitMQ Binder 参考指南,Github > spring-cloud-stream-binder-rabbit,Github > spring-cloud-stream-binder-kafka。
本篇主要描述 Spring Cloud Stream 编程模型的三个核心概念:Destination Binders(目标绑定器)、Destination Bindings(目标绑定)、Message(消息),还包含错误处理。
理解这些核心概念,了解具体使用及其背后一些运行机制,可以更好的理解 Spring Cloud Stream 这款组件。
Spring Cloud Stream 官方文档,Spring Cloud Stream Project,Github > Spring Cloud Stream,Github > Spring-Retry。
Spring Cloud Stream 是一个用于构建消息驱动的微服务应用的框架。Spring Cloud Stream 构建于Spring Boot之上,用于创建独立的生产级 Spring 应用程序,并使用 Spring Integration 提供与消息代理的连接。
Spring Cloud Stream 还为一些供应商的消息中间件提供了个性化的独立配置实现。还引入了持久化发布 - 订阅,消费者组 和 分区 的概念。
在微服务分布式架构中,通常多个服务需要订阅同一个消息主题来做一些相同的操作,例如配置更新等。对于这类需求,通常会使用轻量级的消息代理来构建一个共用的消息主题,让微服务实例连接上来,该主题中的消息会被所有订阅的实例消费,所以称之为 消息总线。
Spring Cloud Bus 使用轻量级消息代理连接分布式系统的节点。 此代理也可用于广播状态更改(例如:配置更改)或其它和管理指令,也可以用作应用程序之间的通信通道。Spring Cloud Bus 为 AMQP 或 Kafka 作为消息代理提供了 starter 支持。
Sleuth 通过 traceId 实现了对分布式系统调用链路的跟踪。在一次服务请求链路中,会保持并传递一个 traceId,从而将不同服务的请求跟踪信息串联起来,不同服务的 traceId 相同表示处在同一请求链中。
基于 HTTP 请求的数据传递有两种方式:一种是做为参数传递,另一种是做为头信息传递。而 Sleuth 的 traceId 属于附加信息,不参与实际的业务,所以做为参数传递并不合适,实际也是作为头信息来传递的。
微服务架构下,会有很多微服务,服务之间调用关系会非常复杂,就非常有必要对每个请求的完整调用链进行跟踪,了解调用了那些服务,当出现问题时可以快速定位。
Spring Cloud Sleuth 为 Spring Cloud 实现了一个分布式跟踪解决方案 Sleuth,该组件大量借签了 Dapper、Zipkin 和 HTrace。
对于大多数用户来说,Sleuth 应该是不可见的,它会自动检测系统的交互,可以在日志中捕获跟踪数据,或将其它送到远程日志收集服务器。
Spring Cloud Sleuth 官方文档,Sleuth Zipkin 日志存储跟踪示例,Zipkin GitHub Zipkin UI 示例、OpenZipkin/Brave 捕获延迟信息的库。