SpringCloud系列学习

SpringCloud学习

讲述了它是什么,有什么作用,包含的一些功能, 例如服务发现,配置中心、消息总线、负载均衡、断路器、数据监控等。

以及它包含的一些核心成员,例如 Netflix Eureka, Netflix Hystrix, Netflix Zuul, Netflix Archaius , Spring Cloud Config , 

Spring Cloud Bus, Spring Cloud For Cloud Foundry,Spring Cloud Cluster, Spring Cloud Consul, Spring Cloud Secutiry,

Spring Cloud Sleuth, Spring Cloud Data Flow, Spring Cloud Stream , Spring Cloud Task , Spring Cloud Zookeeper, 

Spring Cloud Connectors, Spring Cloud Starters , Spring Cloud CLI

 

一款开源的提供了服务注册和发现的产品。

服务中心又称为注册中心,管理各种服务功能包括服务的注册、发现、熔断、负载、降级等,比如dubbo admin后台的各种功能。

它的简单使用,集群的方式使用,及如何使用eureka服务注册中心,搭建一个简单的服务端注册服务,客户端去调用服务的案例。

 

雪崩效应

在微服务架构中通常会有多个服务层的调用,基础服务的故障可能会导致级联故障,进而造成整个系统不可用的情况,

这种现象被称为雪崩效应。服务雪崩效应是一种因服务提供者的不可用导致服务消费者的不可用,并将不可用逐渐放大的过程。

  熔断器,可以实现快速失败;如果在一段时间内侦测到许多类似的错误,会强迫其以后的多个调用快速失败,不再访问远程服务器,

从而防止应用程序不断尝试执行可能会失败的操作,使得应用程序继续执行而不用等待修正错误,或者浪费CPU时间去等到长时间的超时产生。

  熔断器也可以使应用程序能够诊断错误是否已经修正,如果已经修正,应用程序会再次尝试调用操作。

Hystrix的特性:断路器机制,Fallback, 资源隔离。熔断只是作用在服务调用这一端,即客户端。简单案例。

 

Hystrix-dashboard是一款针对Hystrix进行实时监控的工具,通过Hystrix Dashboard 可以使我们直观的看到各Hystrix Command的请求响应时间,请求成功率等数据。

但是,通过Hystrix Dashboard 只能看到单个应用内的服务信息,这明显不够。我们需要一个工具能让我们汇总系统内多个服务的数据

并显示到Hystrix Dashboard上,这个工具就是Turbine.

Hystrix Dashborder 和 Turbine的使用。

 

Spring Cloud Config项目是一个解决分布式系统的配置管理方案。

包含Client和Server两个部分,Server提供配置文件的存储、以接口的形式将配置文件的内容提供出去。

Client通过接口获取数据,并依据此数据初始化自己的应用。

Spring Cloud 使用git或svn存放配置文件,默认是git.

使用git方式创建配置中心示例。

前面的介绍中,客户端都是直接调用配置中心的server端来获取配置文件信息。

但是,这样会有客户端和服务端耦合性太高的问题,不符合spring cloud服务治理的理念。

spring cloud提供这样的解决方案,我们只需要将server端当做一个服务注册到eureka中,

clientdaunt去eureka中获取配置中心server端的服务即可。

加入eureka实现服务化,以及配置中心使用集群实现高可用的示例。

 

之前讲过,如果客户端要获取最新的配置信息需要执行 refresh,

我们可以利用webhook的机制每次提交代码发送请求来刷新客户端,

但是客户端越来越多的时候,需要每个客户端都执行一遍,这种方案就不合适了。

使用Spring Cloud Bus可以完美解决这一问题。

Spring Cloud Bus通过轻量消息代理连接各个分布的节点。

Spring Cloud Bus的一个核心思想是通过分布式的启动器对Spring Boot的应用进行扩展,也可以用来建立一个多个应用直接的通信频道。

本质是利用了MQ的广播机制在分布式系统中传播消息,目前常用的有Kafka和RabbitMQ。

使用示例

为什么需要API Gateway?

简化客户端调用复杂度、数据裁剪以及聚合、多渠道支持、遗留系统的微服务化改造

Spring Cloud Zuul 路由是微服务架构的不可或缺的一部分,提供动态路由、监控、弹性、安全等边缘服务。Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。

如何使用zuul.

除了上篇文章介绍的zuul网关使用模式以及自动转发机制,zuul还有更多的应用场景,比如:鉴权、流量转发、请求统计等等。

Filter是Zuul的核心,用来实现对外服务的控制。Filter的生命周期有4个:PRE, ROUTING, POST, ERROR.

Zuul有其默认实现的Filter,可以实现自定义Filter, 但需要继承ZuulFilter类,并覆盖其中4个方法。

路由熔断,建议最新版直接继承类 FallbackProvider.Zuul目前只支持服务级别的熔断,不支持具体到某个URL进行熔断。

路由重试,Zuu也帮我们实现了此功能,需要结合Spring Retry一起来实现。

高可用,要保证Zuul的高可用,可以同时启动多个Zuul实例进行负载。

随着业务发展,系统拆分导致系统调用链路愈发复杂,一个前端请求可能最终需要调用很多次后端服务才能完成,当整个请求变慢或不可用时,我们是无法得知该请求是由哪个或者哪些后端服务引起的,这时候,就需要解决如何快速定位服务故障点,以对症下药。

于是就有了分布式系统调用跟踪的诞生。

一个分布式服务跟踪系统,主要有三部分:数据收集,数据存储和数据展示。

Spring Cloud Sleuth为服务之间调用提供链路追踪。通过Sleuth可以很清楚的了解到一个服务请求经过了哪些服务,每个服务处理花费了多长,从而让我们可以很方便的理清各微服务间的调用关系。此外,Sleuth可以帮我们:耗时分析、可视化错误、链路优化;

Spring Cloud Sleuth可以结合zipkin,将信息发送到zipkin,利用zipkin的存储来存储信息,利用zipkin来展示数据。

Consul用于实现分布式系统的服务发现和配置。

与其他分布式服务注册与发现的方案相比,Consul的方案更一站式,内置了服务注册与发现框架,分布一致性协议实现、健康检查,key/value存储,多数据中心方案,不再需要依赖其他工具(比如ZooKeeper等)。

 相比之前我们使用的 Zuul(1.x) 它有哪些优势呢?Zuul(1.x) 基于 Servlet,使用阻塞 API,它不支持任何长连接,如 WebSockets,Spring Cloud Gateway 使用非阻塞 API,支持 WebSockets,支持限流等新特性。

它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。

Spring Cloud Gateway 作为 Spring Cloud 生态系统中的网关,目标是替代 Netflix Zuul,其不仅提供统一的路由方式,并且基于 Filter 链的方式提供了网关基本的功能,例如:安全,监控/指标,和限流。

Route(路由),Predicate(断言),Filter(过滤器)

还可以做限速、熔断、重试

 

posted @ 2020-12-02 21:54  Vincent-yuan  阅读(162)  评论(0编辑  收藏  举报